How does VistA work

• 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 that may be scattered across the network. It most often "listens" on port 9260. Each time an RPC client-RPC Broker connection is made, an independent "session" is created. (If multiple users are accessing the database at the same time, there will be multiple open sessions.)
• 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.
• Eventually, the person using CPRS finishes with their work. The session will remain open for a specific amount of time, waiting for further queries. (In computer jargon, the amount of time it waits is known as the "time to live", or TTL). If the RPC proxy on the VistA server doesn't get any further requests within this time frame, it will "time out" and close the session connection.

• 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 is initially provided with the first request by the RPC client) to try to authorize a 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 the "handshake") and the session is opened. Requests for information from the database (such as patient information, lab information, etc.) will now be allowed by the RPC Broker proxy to be passed from the (CPRS) RPC client to the database (within the boundaries of this session). The generated results are then sent back through the established connection from the RPC Broker to the RPC client.
• Of course, if the handshake does not succeed, then the proxy waits for a proper authorized user.

Developments in VistA interfaces

Web browser based clients

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

Although this has been a very time-tested and stable method that has been very reliable for the VA for years, the Internet and World Wide Web have developed in the interim.

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" waiting for further queries.

This allows more users simultaneous access to the database without stressing network bandwidth as much. (This type of communications paradigm 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 the VistA server that will respond to this type of request are being developed. Requests for database information from a web browsers would be sent to EWD on the server, which would itself establish a connection to the RPC Broker. The RPC Broker would again query the MUMPS database as usual, retrieve the requested information, but this time send it back to EWD. EWD would then return the packet-based information to the web browser that is acting as a client (in place of CPRS).

This method of communication is actively being developed at team VistA, in co-ordination with the brilliant efforts of M/Gateway. 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.