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 Open Source Convention health care track.

Yesterday, as 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 openEMR. Today was VistA day, and those who stayed all the way through were entertained by accolades of increasing fervor from the heads of vxVistA, Medsphere, and 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 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?

  Update, July 23: The previous paragraph was written a bit too hastily. I should have listed InterSystems as the makers of Caché, mentioned later, as well as many other types of proprietary health care software but not an EHR vendor. KS Bhaskar, one of the speakers at the conference, created the open-source GT.M t provide both the M language and a replacement database for Caché.

  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 Caché 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 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 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 how fast they 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 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, Chief Architect for Harris Healthcare Solutions, which is the prime contractor for CONNECT, talked about how CONNECT 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 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 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 late 2007 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.