Difference between revisions of "What is VistA Really"

From VistApedia
Jump to: navigation, search
(What is CPRS?: smoothing and tightening)
(Added glossary link to Clinical Users~)
 
(45 intermediate revisions by 4 users not shown)
Line 1: Line 1:
VistA is a Electronic Health Record programmed by Federal (US) employees working for the Department of Veterans Affairs (previously Veterans Administration) for several decades, since the late 1970s. Because it was developed by Federal Employees, it is available under a Freedom of Information Act (FOIA) request. The version of VistA available directly from the US Government is usually referred to as FOIA VistA.  
+
VistA is an '''Electronic Health Record''' programmed by federal (US) employees working for the Department of Veterans Affairs (previously the Veterans Administration) for several decades. Because it was created by federal employees, it is available to the public under a Freedom of Information Act (FOIA) request. (The version of VistA available directly from the US Government is usually referred to as FOIA VistA.)
  
But what is exciting about that? What is VistA really? Why do people have such strong feelings about it? This is the WorldVistA wiki, and we tend to be fans of VistA, so here is the page that will give some insight to what is great about VistA.
+
== A Disputed History ==
 +
The [http://www.hardhats.org/history/hardhats.html history of VistA available from Hardhats.org] indicates that VistA development began in the late 1970's. VA documents, such as the [http://www.va.gov/vista_monograph/ VistA Monograph], date the start of VistA to the mid 1980's. Why the discrepancy? In short, the version at Hardhats is the real version. It documents how VistA moved from an underground movement to a celebrated system.
  
== Disputed History ==
+
VistA (and the vision that led to it) was a programmer-led counter-culture within the VA. Programmers and administrators often risked their jobs (and some lost them) in order to develop a system that would satisfy clinical needs at local hospitals. Each programmer was primarily interested in the needs of the [[clinical users~|Clinical Users]] who worked at the same local VA hospital that the programmer worked at. Nevertheless, they desired that the software they created would be able to be used throughout the VA system.
The [http://www.hardhats.org/history/hardhats.html history of VistA available from hardhats.org] indicates that VistA development began in the late 1970's. VA documents, such as the [http://www.va.gov/vista_monograph/ VistA Monograph] date  the start of VistA as in the mid 1980's. Why the discrepancy? In short the version at hardhats is the real version. It documents how VistA moved from an underground movement to a celebrated system.
 
  
VistA and the vision of VistA was a programmer led counter-culture within the VA. Programmers and administrators often risked their jobs (and some lost them) in order to develop a system that would satisfy clinical needs at the local hospital. Each programmer was primarily interested in the needs of clinical users who worked at the same local VA hospital that the programmer did. However, they were committed to building software that could be used across the VA system.
+
The software platform that eventually resulted was unique because it represented a combination of modules developed by a distributed team. The method of the creation of VistA was, therefore, a precursor to the distributed "open source" development style now popular today.  
  
What is unique about this is that it represented one combined system that was developed by a distributed team. In short, the creation of VistA was a precursor  to the distributed "open source" development style way before the concept came into vogue in the 1990's. The best description of this style of distributed development is in a paper called [http://catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ "The Cathedral and the Bazaar"] by Eric Raymond.
+
Even the original name reflected the nature of its development: Decentralized Hospital Computer Program (DHCP). (The name "VistA" was not chosen until much later.)
  
The VA dates "VistA" from the time when they approved the software. The VA was using VistA long before they approved it, but only in some of their hospitals, instead of across the VA system. In fact, the name "VistA" was not created until much later, the original name was DHCP (for Decentralized Hospital Computer Program). The VA bureaucracy is primarily concerned (as it should be) with the care of veterans. As one can imagine, this is a highly political issue with tremendous pressure from Washington. Enlightenment with regard to the development of VistA is largely independent of bureaucratic ability. When the VA is lead by VistA-enlightened leadership, VistA tends to thrive and move forward. When the VA is led by those ignorant of VistA and software generally, VistA tends to stagnate.  
+
The VA officially dates "VistA" from the time they approved the software, of course, but, it was using the VistA software (in some of its hospitals) long before it was officially approved.  
  
The tension between those who actually make VistA good (the VistA programmers, ADPACs, and CACs) and the bureaucracy in charge of the VA resources still exists. In many ways the purpose of WorldVistA is to ease this tension. WorldVistA is intended to be neutral meeting place for VA programmers, VA bureaucrats and those external to the VA. The only common theme in the WorldVistA community is the interest in VistA and making VistA better.
+
The VA bureaucracy is primarily concerned (as it should be) with the care of veterans. As one can imagine, this is a highly political issue with tremendous pressure from Washington. Enlightenment with regard to the development of VistA is largely independent of bureaucratic ability. When the VA is lead by VistA-enlightened leadership, VistA tends to thrive and move forward. When the VA is led by those ignorant of VistA and software generally, VistA tends to stagnate.
 +
 
 +
The tension between those who actually make VistA work well (the VistA programmers, ADPACs, and CACs) and the bureaucracy that is in charge of the VA resources still exists. In many ways the purpose of WorldVistA is to ease this tension. WorldVistA was intended to be a neutral meeting place that can include VA programmers and VA bureaucrats that is external to the VA.
 +
 
 +
Recently the VA has created a new non-profit called [http://www.osehra.org/ OSEHRA] to manage the development of VistA and to coordinate between VistA development inside and outside the VA.  
  
 
== Licensing of FOIA VistA ==
 
== Licensing of FOIA VistA ==
  
Despite the way in which VistA was developed, it is a common misconception that VistA is "Open Source" software. Technically, VistA is in the [http://en.wikipedia.org/wiki/Public_domain public domain]. As a result VistA can legally be the basis of both proprietary software and Free and Open Source Software. [http://www.linuxmednews.com/974769856/index_html FOIA VistA does meet the strict definition of "Free Software"].
+
Despite the way in which VistA was developed, there is a common misconception that VistA is "open source" software. Technically, VistA is in the [http://en.wikipedia.org/wiki/Public_domain public domain]. As a result FOIA VistA can legally be the basis of both proprietary software and "free and open source" software. [http://www.linuxmednews.com/974769856/index_html FOIA VistA does meet the strict definition of "free software"]. VistA can also be licensed under a combination of proprietary and Open Source license, which is often called a hybrid approach.
 +
 
 +
The fact that VistA can be proprietary software AND free software creates an ongoing tension between different portions of the VistA community. For instance, WorldVistA has a policy of releasing software under the [http://en.wikipedia.org/w/index.php?title=GPL General Public License (GPL)]. The GPL is a "keep-it-free" license that prevents one from controlling the software source code and making it unavailable to others. However, some VistA vendors favor licenses (such as the Apache License), that allow for Open Source development to be used in proprietary products.  
  
The fact that VistA can be proprietary software AND free software creates an ongoing tension between different portions of the VistA community. For instance WorldVistA has a policy of releasing software under the [[http://en.wikipedia.org/w/index.php?title=GPL General Public License (GPL)]]. The GPL is a "keep-it-free" license that prevents someone from controlling the software and making it unavailable to others. Some proprietary VistA vendors favor other licenses that allow for proprietarization.
+
Some in the VistA community favor the open core concept, where a proprietary-friendly Open Source license is chosen for the core software package. This allows both Open Source and proprietary modules as add-ons to the core. Currently this is the licensing approach taken by [http://www.osehra.org/ OSEHRA]  
  
 
== What do you mean by... ==
 
== What do you mean by... ==
  
The first barrier to really understanding VistA is one of overlapping vocabularies. Often people who are technically savvy have a more difficult time with this than those with less technological experience. This problem is directly related to the age of VistA. VistA developed in parallel with many technologies that we take for granted. Often names for technologies in VistA overlap with the names for more common technologies and give tremendous headaches to new VistA developers.  
+
A barrier to understanding VistA is often one of overlapping vocabularies. Paradoxically, people who are technically savvy may have a more difficult time with the vocabulary than those with less IT experience. This is because VistA was developed in parallel with many technologies that today we take for granted. Names for technologies in the time-honored VistA lexicon may overlap with names of more recent technologies (causing a degree of confusion for new VistA developers).  
  
"RPC" is a good example. When most people outside the VistA Community say RPC they are referring to a common *nix messaging system. This [http://en.wikipedia.org/wiki/Remote_procedure_call standard meaning of RPC] is based on the same basic idea as the [[VistA RPC]] mechanism, but otherwise, and in detail, bears no resemblance.  CPRS connects to VistA using the [[VistA RPC]] methods, so it is an important part of the VistA technology model, but its name often causes confusion with those familiar with the more common meaning of RPC.
+
"RPC" is a good example. When people outside the VistA Community refer to [http://en.wikipedia.org/wiki/Remote_procedure_call RPC], they usually are referring to a somewhat ubiquitous *nix messaging system. VistA developers and users, in contrast, speak of the the [[VistA RPC]], a method of connecting CPRS clients to a VistA server. While the more recent XML-RPC network protocol is based on the same basic idea as the [[VistA RPC]], on closer inspection they do bear little resemblance to each other.
  
There are two things that you can do to avoid being confused: first, do not assume that you know what a "VistA person" means when they use these technological terms, and second, read the [[Confusing Terms]] section of this website.
+
Here are some other [[Confusing Terms]].
  
 
== Your programming language is named after a disease? ==
 
== Your programming language is named after a disease? ==
  
VistA is written in [http://en.wikipedia.org/wiki/MUMPS MUMPS]. There are several facts about MUMPS that often confound first time programmers.
+
VistA is written in [http://en.wikipedia.org/wiki/MUMPS MUMPS]. There are several characteristics of MUMPS that can confound first-time programmers.
  
 
* MUMPS is not a C-based syntax, as most modern programming languages are. This means that MUMPS code looks strange to outsiders.
 
* MUMPS is not a C-based syntax, as most modern programming languages are. This means that MUMPS code looks strange to outsiders.
* MUMPS is not white space invariant. This means that you must pay attention to where you put spaces. Many modern program languages allow you to freely put in spaces at any point (following FORTRAN rules originally) With MUMPS you must be careful where you indent using spaces. Putting multiple spaces in some places is not allowed at all, which will really bother you if you like python (which forces indentation as part of the syntax instead of using periods as MUMPS does)
+
* MUMPS is not white space invariant. This means that you must pay attention to where you put spaces. Many modern program languages allow you to freely put in spaces at any point. With MUMPS you must be careful where you indent using spaces. Putting multiple spaces in some places is not allowed at all. (This will really bother those who like Python which forces indentation as part of the syntax instead of using periods as MUMPS does).
* MUMPS is its own database, but its database is not SQL. It's a [http://en.wikipedia.org/wiki/Hierarchical_model Hierarchical Database] that is ideally suited to healthcare
+
* MUMPS is its own database, but its database is not SQL. It's a [http://en.wikipedia.org/wiki/Hierarchical_model Hierarchical Database] that is ideally suited to healthcare. MUMPS can be thought of as an old-school NoSQL database.
* Globals (variables) means something in the permanent database, ie: global across all processes in the system, not the typical programming meaning of global across all the subparts of a single program (variables that are shared within all parts of a single program are called locals in MUMPS).
+
* Global variables mean something in the permanent database, i.e., global across all processes in the system, not the typical programming meaning of global across all the subparts of a single program (variables that are shared within all parts of a single program are called locals in MUMPS).
* MUMPS often behaves like an operating system. Due to space limitations, some original implementations of MUMPS actually were the operating systems on the machine, and this legacy still influences the behavior of MUMPS.
+
* MUMPS often behaves like an operating system. Due to space limitations, some original implementations of MUMPS actually were the operating systems on the machine. This legacy still influences the behavior of MUMPS.
 +
 
 +
Some business analysts have also expressed apprehension regarding the prevalence and longevity of MUMPS, and some misconceptions have been propagated as a result.
  
Business people might be a little jarred by some of the business implications of MUMPS.
+
* "We will not be able to find a MUMPS programmer." While there are more MUMPS programmers than there are for SNOBOL (or other programming languages of the same generation), there clearly are less than for other more common programming languages. You can find MUMPS programmers, but they are retiring and not being replaced by new programmers who have an interest in learning the language. So this is certainly a problem, but it is not an absolute.
  
* There are very very few qualified MUMPS programmers, compared to the much larger number of programmers in mainstream languages.  There are more MUMPS people than SNOBOL or many of other programming languages of the same generation, but for the market segment the number of programmers is definitely disproportional.  Just because MUMPS is commonly used in healthcare does not mean that it is easy to find non-healthcare programmers who use MUMPS.
+
* "It takes a competent computer scientist much longer to learn MUMPS than other languages." MUMPS maintains backward compatibility to ideas that recent computer science graduates don't see much (except in assembly language programming), such as the GOTO command or line tags. It does take programmers longer to pick up, but it is possible.
* It takes a competent computer scientist much longer to learn MUMPS than other languages because MUMPS maintains backward compatibility to ideas that modern computer scientists don't see except in assembly language programming, such as the GOTO command or line tags.
+
* Because they are rare, MUMPS programmers are often expensive
+
* "Because they are rare, MUMPS programmers are often expensive." Just like diamonds, platinum, and titanium.
  
MUMPS is too often written off as an obscure language having little or no value. Here are some of the really good things about MUMPS
+
MUMPS is too often written off as an obscure language having little or no value (often by competing database vendors). Here are some of the really good things about MUMPS, though.
  
 
* Excellent string handling
 
* Excellent string handling
* The database is really really good, especially for healthcare
+
* It is unbelievably fast. It was designed to run on ancient hardware, so it flies on modern hardware.
* It is unbelievably fast, as it was designed to run on ancient hardware, so it flies on modern hardware.
 
  
== VistA is a text based (command line) system. CPRS is only the GUI. ==
+
== The terminal interface versus the CPRS GUI ==
  
Many many people who have used VistA think that CPRS '''is''' VistA. Most of VistA is what is known as "roll and scroll" or a terminal application. VistA was designed long before monitors where capable of complex graphics displays. Old monitors that only displayed text were called terminals. Modern computers use [http://en.wikipedia.org/wiki/Terminal_emulator Terminal Emulators] which allow modern computers to interface with applications as though they were terminals.
+
Many people who have used VistA think that CPRS '''is''' VistA. However, CPRS is only a GUI frontend for some of the functions the VistA server/database can provide. Many of the other functions are accessed by "command-line" or "roll and scroll" terminal [[application~|Application]]s.
  
Much of VistA is only available on terminals. CPRS is a [[GUI~|GUI]] client written in Borland's Delphi (Pascal) that uses VistA-RPC calls to connect to VistA. Most of the underlying architecture of VistA will not be discussed here, but it is important to clarify that CPRS is only part of what VistA has to offer.
+
Because clinicians often need graphical displays (for charts, for example) that are not possible in terminal [[application~|Application]]s, CPRS was created to perform most of the common clinical functions in a GUI environment. CPRS is written in Borland's Delphi (Pascal). It uses VistA-RPC calls to connect to the VistA server/database. (For more clarification, read about the [[How_does_VistA_work|basic VistA architecture]].)
  
[[Image:Server.png|Basic VistA architecture]]
+
However, VistA was initially designed before monitors were capable of complex graphics displays. Older monitors that only could display text were called "terminals".  
  
Many people unjustly dismiss terminal applications. GUIs make learning programs faster, but terminals make using programs faster. Once the initial learning curve is overcome, terminals offer faster data entry and better response times than most modern GUI applications. When given the choice, experienced users often prefer the terminal, and lose productivity when forced to use GUIs. Some of this is because Graphical interfaces use both a mouse and a keyboard, and some of this is because GUIs can change the location of information on the screen, whereas text applications are highly predictable about where they display information.
+
Therefore, most of the functionality of the VistA server/ MUMPS database was initially accessed through terminal ("command-line" or "roll-and-scroll") interfaces. In fact, much of VistA is still only available through such terminal [[application~|Application]]s (currently). (Many consumer-grade desktop computers use [http://en.wikipedia.org/wiki/Terminal_emulator Terminal Emulators], allowing them to interface with [[application~|Application]]s in the same way a terminal would.)
  
People who only rarely use a program have to figure out how to use it from scratch every time. For them a GUI is the best program system, because they can use their general knowledge about computer systems to figure out how to use the program anew.
+
Many people unjustly dismiss terminal [[application~|Application]]s. While GUIs may make learning to use a software programs easier, terminal [[application~|Application]]s are generally faster to use on a routine basis. Once the initial learning curve is overcome, terminals offer faster data entry and better response times than most GUI [[application~|Application]]s. When given the choice, experienced users often prefer the terminal (and lose productivity when forced to use GUIs). Text-based (i.e. terminal-based) [[application~|Application]]s are highly predictable about where they display information, whereas GUIs can often change the location of information on the screen and require time to manipulate the mouse around the screen to figure out where to enter data.
  
Often clinicians need graphical displays that are not possible in terminal applications, such as for graphing results or seeing trends. CPRS is intended to perform most of the common clinical functions in a GUI environment.
+
A person who only rarely uses a program must usually figure out how to use it again every time. For such a person a GUI is generally a desirable interface, with pull-down menus that can eventually tell them which option to select.
  
 
== What is CPRS? ==
 
== What is CPRS? ==
[[CPRS]] is the dominant GUI for VistA. It takes a small percentage of the underlying VistA functionality and presents it in a graphical fashion. CPRS focuses on those activities that are most frequently used by clinicians. Often those without direct patient contact, such as pharmacists, do not have a GUI based interface, and must use the traditional roll-and-scroll terminal interface. Since so many clinicians are trained with CPRS, and because they often use only this interface, many clinicians assume that CPRS is VistA.
+
[[CPRS]] is the primary GUI for VistA. It is able to display part of the VistA system's total functionality in a graphical fashion. CPRS focuses on those activities that are most frequently used by clinicians, but those without direct patient contact, such as pharmacists, may not have a well-developed GUI equivalent to display their own functions. They must use a traditional "roll-and-scroll" terminal interface.  
  
This is not entirely a bad thing. CPRS provides a very well thought out approach to the underlying VistA capabilities. It is relatively easy to use, given the complexity and depth that it contains. A quick look at the [http://scholar.google.com/scholar?hl=en&lr=&q=CPRS+VistA&btnG=Search Google Scholar search for "VistA" and "CPRS"] reveals that CPRS is one of the most studied EHR interfaces available.  
+
CPRS provides a very well-thought-out approach to its interfacing with VistA's capabilities. It is relatively easy to use, given its complexity and depth. A quick look at the [http://scholar.google.com/scholar?hl=en&lr=&q=CPRS+VistA&btnG=Search Google Scholar search for "VistA" and "CPRS"] reveals that CPRS is one of the most studied EHR interfaces available.  
  
CPRS is also very, very customizable. In the VA, the [[Clinical Application Coordinator]] (CAC) role, is essentially responsible for the care and feeding of CPRS. A competent CAC is capable of tuning CPRS in numerous ways to the preferences of departments, floors, or even individual clinicians. The CPRS menu is capable of linking to other programs, so that clinical programs that are actually separate applications can appear to be a part of CPRS.
+
CPRS is also very customizable. In the VA, a "[[Clinical Application Coordinator]]" (CAC) is responsible for the care and maintenance of local installations of the CPRS client on clinicians' computers. A competent CAC is capable of tuning CPRS in numerous ways to the preferences of individual departments or even individual clinicians. The CPRS menu can even link to other programs, so that clinical programs that are actually separate [[Application~|application]]s can appear to be a part of CPRS.
  
CPRS is often criticized by recent programmers for being "long in the tooth" (that means too old for you Yankees). It is written in Delphi, which is no longer a popular programming language as it was in the mid 1990s. Like the rest of VistA, CPRS was written when computers were much slower, and as a result CPRS is comparatively light-weight. While the community is seeking a [[Compelling CPRS Replacement]] CPRS itself continues to run on computers that are too old to run any commonly deployed proprietary EHR systems.
+
CPRS is often criticized for being "long in the tooth" (too old). It is written in Delphi (which is no longer as popular a programming language as it was in the mid 1980s). Like the rest of VistA, CPRS was written at a time when computers were much slower. As a result CPRS is quite lightweight and fast. While the IT community might seek a [[Compelling CPRS Replacement|compelling CPRS replacement]], CPRS itself is one of the only solutions that can run (and continues to run) on computers that are too old to run any other commonly deployed proprietary EHR systems.
  
== Contact the Editor ==
+
== Other Resources ==
This page was originally written and is currently edited by [http://www.fredtrotter.com Fred Trotter]. If you have comments or suggestions about the contents of the article please [http://www.fredtrotter.com contact Fred Trotter] directly.
+
* This page was originally written by Fred Trotter. Please send comments and suggestion to him directly at [http://www.fredtrotter.com his blog].
 +
*The best description of the style of distributed software development is in a paper called [http://catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ "The Cathedral and the Bazaar"] by Eric Raymond.

Latest revision as of 08:00, 28 February 2012

VistA is an Electronic Health Record programmed by federal (US) employees working for the Department of Veterans Affairs (previously the Veterans Administration) for several decades. Because it was created by federal employees, it is available to the public under a Freedom of Information Act (FOIA) request. (The version of VistA available directly from the US Government is usually referred to as FOIA VistA.)

A Disputed History

The history of VistA available from Hardhats.org indicates that VistA development began in the late 1970's. VA documents, such as the VistA Monograph, date the start of VistA to the mid 1980's. Why the discrepancy? In short, the version at Hardhats is the real version. It documents how VistA moved from an underground movement to a celebrated system.

VistA (and the vision that led to it) was a programmer-led counter-culture within the VA. Programmers and administrators often risked their jobs (and some lost them) in order to develop a system that would satisfy clinical needs at local hospitals. Each programmer was primarily interested in the needs of the Clinical Users who worked at the same local VA hospital that the programmer worked at. Nevertheless, they desired that the software they created would be able to be used throughout the VA system.

The software platform that eventually resulted was unique because it represented a combination of modules developed by a distributed team. The method of the creation of VistA was, therefore, a precursor to the distributed "open source" development style now popular today.

Even the original name reflected the nature of its development: Decentralized Hospital Computer Program (DHCP). (The name "VistA" was not chosen until much later.)

The VA officially dates "VistA" from the time they approved the software, of course, but, it was using the VistA software (in some of its hospitals) long before it was officially approved.

The VA bureaucracy is primarily concerned (as it should be) with the care of veterans. As one can imagine, this is a highly political issue with tremendous pressure from Washington. Enlightenment with regard to the development of VistA is largely independent of bureaucratic ability. When the VA is lead by VistA-enlightened leadership, VistA tends to thrive and move forward. When the VA is led by those ignorant of VistA and software generally, VistA tends to stagnate.

The tension between those who actually make VistA work well (the VistA programmers, ADPACs, and CACs) and the bureaucracy that is in charge of the VA resources still exists. In many ways the purpose of WorldVistA is to ease this tension. WorldVistA was intended to be a neutral meeting place that can include VA programmers and VA bureaucrats that is external to the VA.

Recently the VA has created a new non-profit called OSEHRA to manage the development of VistA and to coordinate between VistA development inside and outside the VA.

Licensing of FOIA VistA

Despite the way in which VistA was developed, there is a common misconception that VistA is "open source" software. Technically, VistA is in the public domain. As a result FOIA VistA can legally be the basis of both proprietary software and "free and open source" software. FOIA VistA does meet the strict definition of "free software". VistA can also be licensed under a combination of proprietary and Open Source license, which is often called a hybrid approach.

The fact that VistA can be proprietary software AND free software creates an ongoing tension between different portions of the VistA community. For instance, WorldVistA has a policy of releasing software under the General Public License (GPL). The GPL is a "keep-it-free" license that prevents one from controlling the software source code and making it unavailable to others. However, some VistA vendors favor licenses (such as the Apache License), that allow for Open Source development to be used in proprietary products.

Some in the VistA community favor the open core concept, where a proprietary-friendly Open Source license is chosen for the core software package. This allows both Open Source and proprietary modules as add-ons to the core. Currently this is the licensing approach taken by OSEHRA

What do you mean by...

A barrier to understanding VistA is often one of overlapping vocabularies. Paradoxically, people who are technically savvy may have a more difficult time with the vocabulary than those with less IT experience. This is because VistA was developed in parallel with many technologies that today we take for granted. Names for technologies in the time-honored VistA lexicon may overlap with names of more recent technologies (causing a degree of confusion for new VistA developers).

"RPC" is a good example. When people outside the VistA Community refer to RPC, they usually are referring to a somewhat ubiquitous *nix messaging system. VistA developers and users, in contrast, speak of the the VistA RPC, a method of connecting CPRS clients to a VistA server. While the more recent XML-RPC network protocol is based on the same basic idea as the VistA RPC, on closer inspection they do bear little resemblance to each other.

Here are some other Confusing Terms.

Your programming language is named after a disease?

VistA is written in MUMPS. There are several characteristics of MUMPS that can confound first-time programmers.

  • MUMPS is not a C-based syntax, as most modern programming languages are. This means that MUMPS code looks strange to outsiders.
  • MUMPS is not white space invariant. This means that you must pay attention to where you put spaces. Many modern program languages allow you to freely put in spaces at any point. With MUMPS you must be careful where you indent using spaces. Putting multiple spaces in some places is not allowed at all. (This will really bother those who like Python which forces indentation as part of the syntax instead of using periods as MUMPS does).
  • MUMPS is its own database, but its database is not SQL. It's a Hierarchical Database that is ideally suited to healthcare. MUMPS can be thought of as an old-school NoSQL database.
  • Global variables mean something in the permanent database, i.e., global across all processes in the system, not the typical programming meaning of global across all the subparts of a single program (variables that are shared within all parts of a single program are called locals in MUMPS).
  • MUMPS often behaves like an operating system. Due to space limitations, some original implementations of MUMPS actually were the operating systems on the machine. This legacy still influences the behavior of MUMPS.

Some business analysts have also expressed apprehension regarding the prevalence and longevity of MUMPS, and some misconceptions have been propagated as a result.

  • "We will not be able to find a MUMPS programmer." While there are more MUMPS programmers than there are for SNOBOL (or other programming languages of the same generation), there clearly are less than for other more common programming languages. You can find MUMPS programmers, but they are retiring and not being replaced by new programmers who have an interest in learning the language. So this is certainly a problem, but it is not an absolute.
  • "It takes a competent computer scientist much longer to learn MUMPS than other languages." MUMPS maintains backward compatibility to ideas that recent computer science graduates don't see much (except in assembly language programming), such as the GOTO command or line tags. It does take programmers longer to pick up, but it is possible.
  • "Because they are rare, MUMPS programmers are often expensive." Just like diamonds, platinum, and titanium.

MUMPS is too often written off as an obscure language having little or no value (often by competing database vendors). Here are some of the really good things about MUMPS, though.

  • Excellent string handling
  • It is unbelievably fast. It was designed to run on ancient hardware, so it flies on modern hardware.

The terminal interface versus the CPRS GUI

Many people who have used VistA think that CPRS is VistA. However, CPRS is only a GUI frontend for some of the functions the VistA server/database can provide. Many of the other functions are accessed by "command-line" or "roll and scroll" terminal Applications.

Because clinicians often need graphical displays (for charts, for example) that are not possible in terminal Applications, CPRS was created to perform most of the common clinical functions in a GUI environment. CPRS is written in Borland's Delphi (Pascal). It uses VistA-RPC calls to connect to the VistA server/database. (For more clarification, read about the basic VistA architecture.)

However, VistA was initially designed before monitors were capable of complex graphics displays. Older monitors that only could display text were called "terminals".

Therefore, most of the functionality of the VistA server/ MUMPS database was initially accessed through terminal ("command-line" or "roll-and-scroll") interfaces. In fact, much of VistA is still only available through such terminal Applications (currently). (Many consumer-grade desktop computers use Terminal Emulators, allowing them to interface with Applications in the same way a terminal would.)

Many people unjustly dismiss terminal Applications. While GUIs may make learning to use a software programs easier, terminal Applications are generally faster to use on a routine basis. Once the initial learning curve is overcome, terminals offer faster data entry and better response times than most GUI Applications. When given the choice, experienced users often prefer the terminal (and lose productivity when forced to use GUIs). Text-based (i.e. terminal-based) Applications are highly predictable about where they display information, whereas GUIs can often change the location of information on the screen and require time to manipulate the mouse around the screen to figure out where to enter data.

A person who only rarely uses a program must usually figure out how to use it again every time. For such a person a GUI is generally a desirable interface, with pull-down menus that can eventually tell them which option to select.

What is CPRS?

CPRS is the primary GUI for VistA. It is able to display part of the VistA system's total functionality in a graphical fashion. CPRS focuses on those activities that are most frequently used by clinicians, but those without direct patient contact, such as pharmacists, may not have a well-developed GUI equivalent to display their own functions. They must use a traditional "roll-and-scroll" terminal interface.

CPRS provides a very well-thought-out approach to its interfacing with VistA's capabilities. It is relatively easy to use, given its complexity and depth. A quick look at the Google Scholar search for "VistA" and "CPRS" reveals that CPRS is one of the most studied EHR interfaces available.

CPRS is also very customizable. In the VA, a "Clinical Application Coordinator" (CAC) is responsible for the care and maintenance of local installations of the CPRS client on clinicians' computers. A competent CAC is capable of tuning CPRS in numerous ways to the preferences of individual departments or even individual clinicians. The CPRS menu can even link to other programs, so that clinical programs that are actually separate applications can appear to be a part of CPRS.

CPRS is often criticized for being "long in the tooth" (too old). It is written in Delphi (which is no longer as popular a programming language as it was in the mid 1980s). Like the rest of VistA, CPRS was written at a time when computers were much slower. As a result CPRS is quite lightweight and fast. While the IT community might seek a compelling CPRS replacement, CPRS itself is one of the only solutions that can run (and continues to run) on computers that are too old to run any other commonly deployed proprietary EHR systems.

Other Resources

  • This page was originally written by Fred Trotter. Please send comments and suggestion to him directly at his blog.
  • The best description of the style of distributed software development is in a paper called "The Cathedral and the Bazaar" by Eric Raymond.