How does VistA work

• CPRS is a client program that runs on a user's own computer (usually a Windows-based computer). It connects to a VistA server through standard networking protocols.
• 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 VistA server stores its information in a very fast, very efficient type of database that is generically known as MUMPS (even though it is actually a descendant of the original MUMPS database). The VistA server/database combination can be Windows-based (using a proprietary version of the database) or Linux-based (using a free, open-source version of the database).
• The MUMPS database stores its data and uses different subroutines to find the stored data, depending on the way the information is requested (the "query"). For example, a query may be generated that requests all the temperature values for an admitted patient on a certain date. A MUMPS subroutine would run to find all the data, place it in a logical order, and then return the ordered list of results. The returned list would show up in the CPRS display, for the user to review.

The RPC client - RPC Broker connection

• The client program on the user's computer, 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 sessions opened.)
• 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 (i.e. queries). 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 the RPC conduit has been a very time-tested and reliable method that has been very stable for VA users for years, the Internet and World Wide Web have developed in the interim.

Newer communications interfaces have been developed that have allowed "packet"-based queries (for information) to 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, the information found (within the database), and the information is then returned to the requesting client, closing the session immediately. It does not remain open for a predetermined "time to live" waiting for further queries.

This allows access to the database by many more users simultaneously, without stressing the network bandwidth nearly 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 browser would be sent to EWD (residing on the VistA 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 which 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.

Inclusion of the EWD interface is planned for inclusion in future versions of the Astronaut VistA server packages.

m2web

At the Veterinary Medical Training Hospital of UC Davis, an interface called m2web has been 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 entirely). Like web browsers, it operates over port 80.

This interface is included in VistA server packages that are installed using the Astronaut installers.