Difference between revisions of "How does VistA work"

Revision as of 19:37, 31 January 2010

• CPRS is a client program that runs on a user's own computer.
• The VistA server can be running on a standalone computer anywhere on the network, within a virtual machine on the user's own computer, or even within a virtual machine on another computer in the network.

The RPC client - RPC Broker connection

• CPRS uses a software module called the RPC Client to connect through the network to the main VistA server. The RPC client uses standard networking protocols to connect to the server (wherever it is located).
• A software module that is part of the VistA server (called the RPC Broker) "listens" on the network for connection attempts from RPC Clients scattered across the network. It most often "listens" on port 9260.
• The RPC Broker acts as an interface (or "proxy") between the main MUMPS database (of the VistA server) and the network. It accepts queries from an RPC Client (of CPRS) and then looks for the answers to the queries within the MUMPS database (using MUMPS subroutines). The results that are then generated are returned to the RPC Client (of CPRS) by the RPC Broker. Each instance of such an RPC client-RPC Broker connection is maintained as an independent session. (If multiple users are accessing the database at once, there will be multiple sessions established.)

• Example:

• CPRS might generate a request: "I am this person, authorize me."
• The RPC proxy (RPC Broker) then uses the access code and verify code which was sent with the request (by the RPC client), and tries to authorize that person's CPRS session with the MUMPS database.

• If it succeeds, a "success" message is returned by the RPC Broker to the RPC Client (this is known as a "handshake" in networking terms), then other requests will be allowed to be forwarded through the session's proxy connection. These requests for information (such as patient information, lab information, etc.) from the database are allowed from the CPRS RPC client, passed over the network to the RPC Broker (which interfaces with the MUMPS modules on the VistA server to look for the data) and the results sent back through the established session connection.
• Of course, if the handshake does not succeed, then the proxy waits for a proper authorized user.

• Eventually, the person using CPRS finishes with their work. If the RPC proxy on the VistA server doesn't get any requests for a while, it "times out" and drops the connection. (In computer jargon, the amount of time it waits is known as the "time to live", or TTL).

Developments in VistA interfaces

Web browser based clients

There are alternatives to using the RPC Client (or CPRS) <--> RPC Broker conduit as a method to "mine" data from the MUMPS database.

This is a time honored method that has been very reliable and stable for the VA for many years. However, the Internet and World Wide Web developed some time after VistA (and its predecessor, DHCP) were already in use.

Newer communications interfaces have been developed that allow "packet"-based queries for information from databases. They do not require that a communications session remain open for a specified "time to live" (TTL). The request for information from the database is made and the information found (from the database), returned to the requesting client, and the connection closed. it does not remain open for a predetermined "time to live."

This allows more users simultaneous access to the database without stressing network bandwidth as much, and this type of communications is what makes the World Wide Web able to handle so much traffic.

Web browsers (Firefox, Internet Explorer, Safari) are the ubiquitous clients that generate these packet-based requests.

EWD

Using EWD, new interfaces for VistA that will respond to this type of request are being developed. Requests for database information from a web browsers will be sent to EWD, which will itself establish a connection to the RPC Broker. The RPC Broker will again query the MUMPS database, retrieve the requested information, send it to EWD which will then return the packet-based information to the web browser acting as a client.

This method of communication is actively in development at team VistA. Look for updates and improvements in the VistA Community Meetings and in the Google HardHats group.

m2web

At the Veterinary Medical Training Hospital of UC Davis, an interface called m2web was developed by Jim Self for the VMACS veterinary EHR (a derivative of VistA). This module also uses packet-based information exchange over the network, but directly interacts with the MUMPS database (bypassing the RPC Broker). Like web browsers, it operates over port 80.