Phillip Longman’s book “Best Care
Anywhere,” just released in its second edition, had a strong
effect on me that cascaded off of several other experiences and
encounters I’ve had recently. The material should have been more
familiar to me. The Department of Veterans Affairs’ quality efforts have
become health care industry buzz, and its illustrious VistA software
has also often made the news, a couple times for its near-death
experiences. But VistA is still not the subject of daily discussion in
American public life.
I’m beginning to think our blind spot about the VA and VistA comes
from the sheer magnitude of the whole achievement. Longman’s
modest-length book is just an introduction to the swirling mass of
issues that come with this topic: what VA’s quality program has to say
about health care, about business motivations, about government, about
software development, even about ordinary people and how they handle
the most important aspects of their own lives.
There’s just too much there for us to absorb, and the lessons of VistA
force us to relinquish too many prejudices. I’m beginning to make the
necessary shift to understanding VistA after talking to doctors,
hearing from the people porting it to new environments, and now
reading Longman’s book. For other people without so many contacts in
the health care field, his book is a good start. Don’t expect it to
answer all your questions, but just to make you uncomfortable enough
to change the way you think — and act.
I’ll focus on the development and technical aspects of VistA in this
blog, because I’m writing for a computer technology website. But we
should recognize the big points made by Longman, a journalist with a
clear public policy agenda:
- The VA is way ahead of most U.S. providers in quality — Some of the quality control measures have been in place for 30 years and are incredibly simple, but are still nearly unique to the VA. They also have very sophisticated uses for data, including intensive and routine data mining, and hook-ups of devices in people’s homes.
- The VA provides a model being adopted around the world — Leading health care institutions in several countries, notably Jordan and Mexico, have implemented or are implementing VistA and its information-driven care model. It’s happening in the U.S. too. Adoption is slow to start with because there are only a few small companies actively marketing VistA solutions (and they don’t cooperate as well as they should). But the huge provider Kaiser Permanente interoperates with the VA and uses many of its techniques.
- The mainstream health care industry can’t change because of business models — The culprit to which Longman points is the long-criticized
fee-for-service model. He cites many private institutions that tried to do the right thing for their patients and provide long-term treatments, including life style changes. All these institutions went bankrupt because they weren’t reimbursed for making patients healthier, and could not recoup the cost savings created by keeping patients healthy. He ascribes similar problems to the HMO movement, which began with wonderful ideals and degenerated into one of the most hated businesses in the U.S.
- Modern health care requires a life-long relationship to the patient — Longman says that the key to the VA’s quality approach was their realization that they would remain responsible for their patients throughout their life spans. Quality controls that didn’t make business sense in private institutions did wonders for the VA. But
this doesn’t mean we need socialized medicine (depending on how you define that emotion-laden term) or even a public insurance option. Rather, we should create a national system based on the VA’s successes, where doctors are rewarded for following evidence-based medicine.
There’s a lot more in this pithy and readable book, such as how to
encourage providers to report errors and how to expand the VA health
care system. I’ll let you get the book for yourself to enjoy the
details. I’ll turn now to the software-related issues raised by the
Bottom-up development wins big
VistA software was most decidedly a bazaar, not a cathedral. It was
conceived by doctors in the late 1970s, and built either by health
care providers or by programmers working closely (sometimes having
chairs literally side by side) with health care providers. VistA is
actually a loosely interconnected system containing over 100
integrated, patient-focused applications.
Distributed development started because many different doctors had
bright ideas at about the same time. The distributed approach
continued despite (perhaps even because of) overt persecution. When
the developers tried to get together to formalize their relationships,
they were discovered and disciplined (through firings or having their
computers confiscated) because they were bucking the official
mainframe-based IT team. The developers’ tenuous position was
reflected in the name they picked for themselves, the Hard Hats, and
even more in the name attributed to them later by the head of the VA:
the Underground Railroad.
Conceptually, VistA also emerged in a bazaar-like fashion. No one
originally thought of the comprehensive life-long health management
system VistA has become. Rather, each piece of the system emerged from
a narrow need recognized by a health care provider: keeping track of
diagnoses, analyzing diabetic nutrition, ensuring that medicine was
administered to patients properly, and so on. Eventually, once the VA
administration got on board the railroad, everything was linked
It’s a truism that open source software development (and perhaps all
software development ) is best driven by the people who will
ultimately use it. So we can understand why VistA meets certain
essential needs — such as allowing an emergency room doctor enter an
order within a few seconds — that are missed by most proprietary
software in the health care field. But I find it surprising that the
system could work so well when each piece was developed in isolation.
Perhaps the software used can provide a clue.
The MUMPS language and database
VistA, like most proprietary products offered for sale to health care
providers, is written in a language called MUMPS, invented at
Massachusetts General Hospital in 1966 and standardized as M by ANSI
and ISO. MUMPS is little more than an interface to a hierarchical,
key-value database (pretty much an associative array). What SQL is for
relational databases, MUMPS is for this hierarchical database. The
rest of the language, to my mind, is just a thin wrapper with
essential language traits such as flow control constructs and string
As a child of the’ 60s, MUMPS shares the hippie libertarian trappings
of languages from that time. For instance, it has no concept of
packaging, and certainly no concern for “GOTOs considered harmful.”
Instead of formal functions, it lets a programmer jump to a label at
any point in the program, even in another file. However, GOTOs are not
required for MUMPS programs any more than they are for C programs, and
MUMPS has features that modern programmers expect, such as
parameter-passing, localizing variables to particular scopes, block
structure, etc. It also comes with features to write applications that
use multiple, cooperating processes.
Perhaps this extreme open architecture for programs made integration
easy. But tying programs together isn’t the only task in integration;
data from one program must also be accessible to others.
Here we turn to the hierarchical database. Persistence in MUMPS is
achieved simply by marking data as “global,” which is like tied
variables in Perl. Every read or write to a global variable involves
the file system.
The VA, Department of Defense, and Indian Health Service have
licensed, for use with VistA and its derivatives, a proprietary
database called Caché from the company InterSystems. An open
source implementation of MUMPS, led by K.S. Bhaskar and called GT.M,
is available from FIS, a large public corporation, with support on
commercial terms. GT.M has its own database and is popular for VistA
implementations outside the Federal government.
Most databases assign types to data. If one database calls an ID a
Patient and another calls it a Client, you have to write special
conversion code to tie them together. Things are even harder if
Patient is stored as an integer and Client as a string.
In MUMPS, everything is a string (a choice that was popular with other
scripting languages as well, notably Tcl). MUMPS offers “canonical
numbers,” strings that encode numeric values and can be input to
mathematical operations. So there’s no such thing as data conversion
What you do need to do, however, is find the exact path to a data
item. Unlike SQL, you can’t simply ask the database to tell you
everything it knows about a patient. You have to know where the
patient is in the hierarchy. MUMPS provides just two simple functions
for retrieving data: you can specify a node in the hierarchy, or start
at an arbitrary point in the hierarchy and cycle through it in order,
somewhat like an SQL cursor.
While it may not be obvious how these very simple operations and data
structures can produce highly interconnected, robust systems, the VA
has proven that it can be done. The key to using such fundamental — but
powerful — data structuring and representation is to create
higher-level data abstractions that map real-world information at a
Furthermore, you don’t need to learn MUMPS unless you want to program
VistA internals. VistA exposes its functionality through remote
procedure calls, and open source wrappers provide access to this
functionality from modern languages such as Python and Java, OVID from Medsphere being one example.
If you’d like to learn more about VistA, help to add features so it
can become the nation’s electronic health record system, or just meet
the fascinating people who work with it, check out the WorldVistA community. As Longman
points out, doctors are moving quickly to install electronic record
systems so they can benefit from government funding. To play in this
space, VistA needs both more promotion and (according to one project
leader, Joseph Dal Molin) changes to simplify deployment and