The history and accomplishments attributed to VistA, the Veterans
Administration's core administrative software, mark it as one of the
most impressive software projects in history. Still, lots of smart
people in the health care field deprecate VistA and cast doubt that it
could ever be widely adopted. Having spent some time with people on
both sides, I'll look at their arguments in this blog, and then
summarize other talks I heard today at the
href="http://www.oscon.com/oscon2010">Open Source Convention
health care track.
Yesterday, as
href="http://radar.oreilly.com/2010/07/day-one-of-the-health-care-it.html">I
described in my previous blog, we heard an overview of trends in
health care and its open source side in particular. Two open source
free software projects offering electronic health records were
presented, Tolven and
href="http://www.oemr.org/">openEMR. Today was VistA day, and
those who stayed all the way through were entertained by accolades of
increasing fervor from the heads of
href="http://www.oscon.com/oscon2010/public/schedule/detail/15291">vxVistA,
href="http://www.oscon.com/oscon2010/public/schedule/detail/15255">Medsphere,
and
href="http://www.oscon.com/oscon2010/public/schedule/detail/15255">ClearHealth. (Anyone
who claims that VistA is cumbersome and obsolete will have to explain
why it seems to back up so many successful companies.) In general, a
nice theme to see today was so many open source companies making a go
of it in the health care field.
VistA: historical anomaly or the future of electronic medical systems?
We started our exploration of VistA with a
href="http://www.oscon.com/oscon2010/public/schedule/detail/15274p">stirring
overview by Phillip Longman, author of the popular paperback book,
Best Care Anywhere: Why VA Health Care is Better Than
Yours. The story of VistA's development is a true medical
thriller, with scenes ranging from sudden firings to actual fires
(arson). As several speakers stressed, the story is also about how the
doctors at the VA independently developed the key aspects of open
source development: programming by the users of the software, loose
coordination of independent coders, freedom to fork, and so on.
Longman is convinced that VistA could and should be the basis of
universal health records in the U.S., and rains down omens of doom on
the comprehensive health care bill if it drives physicians to buy
proprietary health record systems.
VistA is much more than an electronic health record system, and even
bigger than a medical system. It is really a constellation of hundreds
of applications, including food preparation, library administration,
policing, and more.
The two main objections to VistA are:
That it is clunky old code based on an obsolete language and database technology
-
As a project begun by amateurs, VistA probably contains some fearsome
passages. Furthermore, it is written in MUMPS (standardized by ANSI as
simply M), a language that dates from the time of LISP and
COBOL. Predating relational databases, MUMPS contains a hierarchical
database based on a B*-tree data structure.
Supporters of Vista argue that anything qualifying as "legacy code"
can just as well be called "stable." They can also answer each of
these criticisms:
-
The code has been used heavily by the VA long enough to prove that
it is extendable and maintainable.
-
It is strangely hypocritical to hear VistA's use of MUMPS criticized
by proprietary vendors when so any of them are equally dependent on
that language. Indeed, the best-known vendors of proprietary health
care software, including Epic and InterSystems, use MUMPS. Need I
remind readers that we put a man on the moon using 1960s-style
FORTRAN?
It's interesting to learn, however, that ClearHealth is migrating
parts of VistA away from MUMPS and does most of its coding in
higher-level languages (and many modern programmers would hardly offer
praise for the language chosen for ClearHealth's interface, PHP).
-
Similarly, many current vendors use the Cache hierarchical
database. Aspersions concerning pre-relational databases sound less
damning nowadays in an age of burgeoning interest in various NoSQL
projects. Still, Medsphere and the community-based
href="http://www.worldvista.org/">WorldVistA project are
creating a SPARQL interface and a mechanism for extracting data from
VistA into a MySQL database.
That it works well only in the unique environment of the Veterans Administration
-
This critique seems to be easier to validate through experience. The
VA is a monolithic, self-contained environment reflected in VistA. For
instance, the critical task of ordering prescriptions in VistA depends
on the pharmacy also running VistA.
Commercial pharmacies could theoretically interact with VistA, but it
would require effort on the part of those companies, which in turn
would depend on VistA being adopted by a substantial customer base of
private hospitals.
Several successful deployments of VistA by U.S. hospitals, as well as
adoption by whole networks of hospitals in several other countries,
indicate that it's still a viable option. And the presence of several
companies in the space shows that adopters can count on support.
On the other hand, the competing implementations by vxVistA,
Medsphere, and ClearHealth complicate the development landscape. It
might have been easier if a single organization such as WorldVistA
could have unified development as the Apache or GNOME foundation does.
vxVistA has come in for particular criticism among open source
advocates. In fact, the speakers at today's conference started
out defensive, making me feel some sympathy for them.
vxVistA's developers, the company DSS, kept their version of VistA
closed for some time until they had some established customers.
Speaker Deanne Clark argued that they did this to make sure they had
enough control over their product to produce some early successes,
warning that any failure would hurt the image of the whole VistA
community. I don't know why a closed development process is necessary
to ensure quality, but I'll accept her explanation. And DSS seems to
be regarded highly for its quality work by everyone, including those
who embroil
More galling to other open source advocates is that when DSS did
release vxVistA as open source, they did so under an Eclipse license
that is incompatible with the GPL used by WorldVistA.
I wouldn't dare guess whether VistA will continue as a niche product
or will suddenly emerge to eat up the U.S. market for electronic
medical systems. But I think it's definitely something to watch.
The odd position of the VA as the source for new versions of VistA, as
well as its role as VistA's overwhelmingly largest user, could also
introduce distortions into the open source development pattern outside
the VA. For instance, commercial backers of VistA are determined to
get it certified for meaningful use so that their clients can win
financial rewards from the Department of Health and Human
Services. But the VA doesn't have to be certified for meaningful use
and doesn't care about it. (As David Uhlman of ClearHealth pointed
out, nearly everything in the meaningful use criteria was done thirty
years ago by the VA using VistA.)
The VA even goes through periods of refusing bug fixes and
improvements from the outside community. Luckily, the VA lets some of
its programmers participate on WorldVistA forums, and seems interested
in getting more involved.
Other presentations
Attendance varies between 30 and 70 people for today's health care
session. Roni Zeiger of Google brought out a big crowd for his
href="http://www.oscon.com/oscon2010/public/schedule/detail/15272">discussion
of Google's interest in health care, with a focus on how its API
accepts data from devices.
Zeiger pointed out that we lead most of our lives outside doctor's
offices (unless we're very unlucky) and that health information should
be drawn from everyday life as well. A wide range of devices can
measure everything from how fast we walk to our glucose levels. Even
if all you have is a smart phone, there are a lot of things you can
record. Collecting this kind of data, called Observations of Daily
Living, is becoming more and more popular.
-
One app uses GPS to show your path during a run.
-
Another app uses the accelerometer to show your elevation during a
bike ride.
-
One researcher uses a sensor, stuck into an inhaler, to feed data to a
phone and collect information on where and when people have asthma
attacks. If we collect a lot of data from a lot of people over time,
we may learn more about what triggers these attacks.
-
On the fun side, a Google employee figured out how to measure the
rotation of bike pedals using the magnet in an Android phone. This
lets employees maintain the right aerobic speed and record what how
fast and their friends are peddling.
You can set up Google Health to accept data from these
devices. Ultimately, we can also feed the data automatically to our
doctors, but first they'll need to set up systems to accept such
information on a regular basis.
Will Ross
href="http://www.oscon.com/oscon2010/public/schedule/detail/14944">described
a project to connect health care providers across a mostly rural
county in California and exchange patient data. The consortium
found that they had barely enough money to pay a proprietary vendor of
Health Information Exchange systems, and no money for maintenance. So
they contracted with Mirth
Corporation to use an open source solution. Mirth supports
CONNECT, which I described in
href="http://radar.oreilly.com/2010/07/day-one-of-the-health-care-it.html">yesterday's
blog, and provides tools for extracting data from structured
documents as well as exchanging it.
Nagesh Bashyam, who runs the large consulting practice that Harris
Corporation provides to CONNECT,
href="http://www.oscon.com/oscon2010/public/schedule/detail/15267">talked
about how it can lead to more than data exchange--it can let a doctor
combine information from many sources and therefore be a platform for
value-added services.
Turning to academic and non-profit research efforts, we also heard
today from
href="http://www.oscon.com/oscon2010/public/schedule/detail/15279">
Andrew Hart of NASA's Jet Propulsion Laboratory and some colleagues at
Children's Hospital Los Angeles. Hart described a reference
architecture that has supported the sharing of research data among
institutions on a number of large projects. The system has to be able
to translate between formats seamlessly so that researchers can
quickly query different sites for related data and combine it.
Sam Faus of Sujansky & Associates
href="http://www.oscon.com/oscon2010/public/schedule/detail/15275">recounted
a project to create a Common Platform for sharing Observations of
Daily Living between research projects. Sponsored by the Robert Wood
Johnson Foundation to tie together a number of other projects in the
health care space, Sujansky started its work in 2006 before there were
systems such as Google Health and Microsoft Health Vault. Even after
these services were opened, however, the foundation decided to
continue and create its own platform.
Currently, there are several emerging standards for ODL, measuring
different things and organizing them in different ways. Faus said this
is a reasonable state of affairs because we are so early in the
patient-centered movement.
I talked about standards later with David Riley, the government's
CONNECT initiative lead. HHS can influence the adoption of standards
through regulation. But Riley's office has adopted a distributed and
participatory approach to finding new standards. Whenever they see a
need, they can propose an area of standardization to HHS's
specification advisory body. The body can prioritize these
requests and conduct meetings to hammer out a standard. To actually
enter a standard into a regulation, however, HHS has to follow the
federal government's rule-making procedures, which require an
eighteen-month period of releasing draft regulations and accepting
comments.
It's the odd trait of standards that discussions excite violent
emotions among insiders while driving outsiders to desperate
boredom. For participants in this evening's Birds of a Feather
session, the hour passed quickly discussing standards.
The 800-pound gorilla of health care standards is the HL7 series,
which CONNECT supports. Zeiger said that Google (which currently
supports just the CCR, a lighter-weight standard) will have to HL7's
version of the continuity of care record, the CCD. HL7 standards have
undergone massive changes over the decades, though, and are likely to
change again quite soon. From what I hear, this is urgently
necessary. In its current version, the HL7 committee layered a
superficial XML syntax over ill-structured standards.
A major problem with many health care standards, including HL7, is the
business decision by standard-setting bodies to fund their activities
by charging fees that put standards outside the reach of open source
projects, as well as ordinary patients and consumers. Many standards
bodies require $5.00 or $10.00 per seat.
Brian Behlendorf discussed the recent decision of the NHIN Direct
committee to support both SOAP versus SMTP for data exchange. Their
goal was to create a common core that lets proponents of each system
do essentially the same thing--authenticate health care providers and
exchange data securely--while also leaving room for further
development.
PlanetMySQL Voting:
Vote UP /
Vote DOWN
