Guest Commentary: Tom Munnecke on VistA lessons learned

Tools

As one of the original designers of the Department of Veterans Affairs' VistA system, I watch with interest department efforts to create a next generation electronic health record.

I fear that many of the lessons learned from the development of the Veterans Health Information Systems and Technology Architecture aren't sufficiently counted in planning tomorrow's VistA.

To begin with, we need to recognize how well VistA works. Given other large-scale government information technology efforts, this might even be considered miraculous. The billions spent on the Defense Department's AHLTA (it might as well stand for "Ah Heck, Let's Do it Again") have led to a system which is so bad that it is one of the leading complaints cited by doctors when they leave military service. And here we come to a first lesson learned: Evolutionary development.

In contrast to DoD's "break and replace" development strategy, VistA has been under continuous evolution over the past 32 years. There have been thousands of errors made in the evolution of VistA, but generally they have been caught in the early stages. Like biological evolution, there VistA progressed by a series of small steps--even with people working on similar ideas in different parts of the country. VistA never started with a vision of the one correct way to the perfect EHR. Rather, it was a process of discovery, searching and amplifying what worked.

Secondly, our design philosophy was to get something that was "good enough" out in the user's hands, and then make it better. Rather than writing elaborate specifications, we wanted to introduce iterative generations of software.

VistA was designed from day one around a kernel architecture. As a software architect, I have often dealt with users who wanted the software equivalent of a penthouse suite on a skyscraper. They didn't want to talk about the lower 22 floors, the basement or the sewer system. To begin work by digging a foundation was sure to elicit, "You idiot! We need to build up, not down!" These pressures to jump directly to the gold-plated endpoint are enormous. As a result, we have all these very flimsy penthouse suites floating around on very shaky foundations. Rather than investing in appropriate foundations in the first place, they end up trying to retrofit changes that only lead to a more brittle end product.

This is a little like a salesman offering to sell the world's finest car by proposing you acquire the seats from Rolls Royce, an engine from Ferrari, and transmission from Porsche. "All you would need to do," the salesman says as he delivers a trailer full of parts, "is a little bit of integration."

Thirdly, our goal was to create a path of least resistance toward a better system, while not forgetting that an electronic health record system has requirements different from a merely complex IT system. Peter Drucker noted that the hospital is one of the most complex organizations in modern society. While at the VA, I would occasionally ride on the elevator with a gurney on the way to the morgue. Whereas an error in a banking system can cause accounting errors, an error in a medical informatics system can kill someone.

I rejected the standard SQL/relational data base model, and its mantra: "A place for every datum, and every datum in its place." The VistA file manager was designed as a medical informatics tool, structured around the complex and sparse information that is used in medicine.

To give a flavor of the design issue, imagine a spreadsheet with fixed rows and columns, and a rule that all cells in the spreadsheet must be filled in. The rows are numbered and the columns are labeled A-Z. Now, imagine that there are 10,000 columns, and that each row only has a few entries in the columns, creating a very sparse data structure.

Now, add context-dependent columns: If a row has a column with a "sex=male," then it needs another column for prostate, whereas another column with "sex=female" would have a column for ovaries. Now, add time-dependent logic, for example, if someone goes through a sex-change operation. Now, add personal genomic data, 80 gigabytes of information that will tell us who-knows-what in the future.

To try to pigeonhole all of this information into a predefined row/column structure is an exercise in futility, but this is the standard mindset that I see from computer professionals coming to medical informatics problems for the first time. Banking systems are very complex, they reason, so the lessons learned from processing a million ATM transactions ought to apply to medical informatics.

Not so. This is a little like expecting Cobol programmers to be good at Photoshop because they "know computers."  Banks use very well defined transactions. They want their databases to be dense; having a transaction in a journal without a debit/credit flag would be disastrous. The dense-table model of the relational database works well for banking, but is messy, if not catastrophic, for medical information.

And here we come to the topics of MUMPS, the computer language we used to develop VistA. MUMPS is universally criticized as being "non-standard" or "non-interoperable" with "normal" IT operations. It is the nefarious "other" being attacked by the "us" who understand the virtuous norm.

The problem is that MUMPS has proven itself time and time again to be a successful tool for medical informatics, both inside and outside of the VA.

The original VistA programmers were recruited from the MUMPS users group meetings, mostly in the 1970s. The problem of representing complex medical information in the computer permeated the air--how do we capture all the rich complexity of medical information and knowledge in the computer? A band of these programmers went off to become the "hardhats" who developed VistA.

The original MUMPS was funded at Massachusetts General Hospital by an National Institutes of Health research grant to G. Octo Barnett. After a bit of creative wandering into dialects, the National Bureau of Standards (now the National Institute of Standards and Technology) stepped in to create a 1975 NBS Standard MUMPS, which then evolved to the American National Standard MUMPS. This was adopted by the VA for DHCP/VistA, and then Indian Health Services' RPMS, and DoD's CHCS. 

This 30 year trajectory, from NIH research lab funding to support of the medical records in the United States, should be seen as one of the great success stories in government funding and application of technology. Yes, MUMPS is old, and there are many shiny new things out there that may seem better, particularly to those unaware of the unique characteristics of medical informatics.

Despite my earlier moniker of "Mr. MUMPS," I don't consider myself to be pro-MUMPS. I think that other open source technologies can be applied for the future of an open VistA. But I am extremely wary of those who would ignore what made the current VistA system successful out of the fascination with the shiny new things we see everywhere around us. The AHLTA experience should make people wary of the notion that lots of money and paperwork will create a successful system.

Tom Munnecke has been involved with computers and technology his entire life and was a computer specialist at the Veterans Affairs Department from 1978 to 1986. He was a chief software architect for VistA and the Defense Department's Composite Health Care System. He took early retirement as a vice president and chief scientist at Science Applications International Corp. in order to support technology for broader health, humanitarian and education purposes. These days he lives in Encinitas, Calif. where he founded the Uplift Academy and is a senior fellow at Civic Ventures. He also consults in the health care industry, and is involved in some Health IT startups.  He can be reached at tom@munnecke.com.

Related Articles:
AHLTA is a $2 billion disappointment
VA's Baker: No wholesale dumping of MUMPS
VA investigates VistA EHR open source
VA cancels financial IT modernization portions of FLITE project
Industry group urges VA to embrace open source