How does VistA work: Difference between revisions

From VistApedia
Jump to navigationJump to search
Perspectoff (talk | contribs)
No edit summary
 
(38 intermediate revisions by 2 users not shown)
Line 1: Line 1:
* [[CPRS]] is a client program that runs on a user's own computer.
* [[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.
* CPRS uses a software module called the RPC Client to connect to the main VistA server.
* 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 [http://en.wikipedia.org/wiki/MUMPS 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 VistA server can be running on a standalone computer anywhere on the network, or within a virtual machine on the user's own computer (or even on another computer in the network). The RPC client will use standard networking protocols to connect to the server (wherever it is located).
* 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 [[Introduction_To_Programming_VistA_with_MUMPS|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.
* 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 around the network. It 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 RPC Client (portion of CPRS) to handle queries and respond to those requests for information from the database that are generated by CPRS. Each instance of 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.
== 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:
* Example:
:* CPRS might generate a request: "I am this person, authorize me."
:* 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.   
:* 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 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.
::* 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.
::* 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 ==
== Developments in VistA interfaces ==


=== Web browser based clients ===
=== 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.
There are alternatives to using the RPC Client (of CPRS) <--> RPC Broker conduit as a method to "mine" data from the MUMPS database.
 
[[file:BROWSER-SERVER_Communicationsjpg.jpg|thumb|800px|]]
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.
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 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."
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 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.  
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.
Web browsers (Firefox, Internet Explorer, Safari) are the ubiquitous clients that generate these packet-based requests.


==== EWD ====
==== 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.
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.


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.
Inclusion of the EWD interface is planned for inclusion in future versions of the Astronaut VistA server packages.


=== m2web ===
=== 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.
At the Veterinary Medical Training Hospital of UC Davis, an interface called [[M2Web|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.

Latest revision as of 13:44, 29 April 2016

  • 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.