Before the Senate Committee on Veterans Affairs
Oct 6, 2010
Thank you, Chairman Akaka, Ranking Member Burr, and members of the committee. As someone who has been passionately involved with health IT in the VA for 32 years, it is a pleasure to appear at this hearing to discuss the elements that led to success in VistA as well as how this might contribute to a Health IT system of the future.
Thanks to modern day communications technology, your staff reached me to invite me to this hearing during a vacation in the middle of Oregon’s Cascades mountains. I only had one day at home to prepare for the hearing, so please understand that this is a rather hurried set of comments.
I was one of a small set of programmers hired by the VA in 1978 to work on a ANS MUMPS-based decentralized hospital computer system, what is now called VistA. I was a computer specialist employed at VA Loma Linda, California, working with a network of others around the country who pulled together a most remarkable effort to bring computing technology to clinical users in the VA. I was one of the lead software architects of the effort until 1986, when I went to Science Applications International Corporation in San Diego to play a similar role for the Composite Health Care System (CHCS) an adaptation of VistA. I was a consultant to VHA in the late 1990’s in which I wrote a number of papers looking at future applications of IT in the VA (see Appendix). I took an early retirement as a VP and Chief Scientist at SAIC to pursue a broader field of philanthropic, humanitarian, and educational uses of technology, particularly with regard to those at the “bottom of the pyamid.” I became a fellow at Stanford University, and was funded by Omidyar Foundation to develop a social network toolkit for philanthropic activities. I founded a group called the Uplift Academy, and have held workshops and salons around the world on the broader role of technology and society, including health care.
I appear at this committee as a private citizen at my own expense, with the sole motivation of improving service to our veterans through appropriate uses of information technology.
28 years ago, the Decentralized Hospital Computer Program (DHCP, later called VistA) was at a fever pitch of innovation. Tens of thousands of VA employees were connected on an electronic FORUM on a daily basis, sharing ideas, giving feedback, starting up new projects, complaining about others, and contributing in one way or another to the clinical application of computer technology to the delivery of service to our veterans. I would install a new version of the software one night, and the next day at the hospital cafeteria I would hear about what was good and what was bad about the changes. I would communicate these ideas to the developers via FORUM, and we would see changes in the software in hours or days. I installed a computer running VistA at the March Air Force Base hospital, an early instance of VA/DoD IT sharing.
Lesson Learned: Clinical information is vastly different from administrative information. One of VistA’s strengths was that it was able to focus directly on the clinical.
VistA was developed directly as a clinical tool, by clinicians, for direct patient care. While there are many administrative needs of an enterprise for logistics, cost accounting, billing, payroll, and the like, these are a fundamentally different kind of computing.
Lesson Learned: Decentralization works. The extensive end-user collaboration was a key factor to the success of VistA.
When I first started at the VA, I ran into the bureaucratic “stovepipe” mentality everywhere I went, even though everyone had a supposedly common goal of providing health care to our veterans. Recalling the words of the Sheriff in Cool Hand Luke, it seemed that the core problem could be expressed as “What we have here is a failure to communicate.”
In college, I was struck by the Sapir-Whorf hypothesis that language shapes our thought. I began to focus my attention on ways of using IT to overcome the failure to communicate. This led to the development of an integrated data dictionary that served as a “roadmap” to the patient data. Today, this would be called a “Semantic Web” (See http://www.caregraf.org/semanticvista for a modern semanitc web interface to the VistA database). We integrated electronic mail directly into the clinical interface, allowing database activities to generate email messages through an email/discussion/workflow system called MailMan. I was amazed at how heavily used MailMan was – in some cases, 25% of the traffic in a VistA system was email traffic. This demonstrated how communications-intensive clinical care is, even outside the formal communications traffic in the specific applications such as pharmacy, laboratory, or radiology. I think that VistA broke down many of the bureaucratic stovepipe barriers, allowing people to focus on what was best for their clinical practice.
Lesson Learned: The fundamental goal in health IT should be to improve communications. The medical record is but one form of communication.
All of the initial developers of VistA were employed in the field, working closely with end users. Riding the elevator with a gurney headed to the morgue was a sobering experience, and helped keep me focused on the implications of the software I was developing. The trust we placed in the VistA community was well-placed. People felt respected, and acted accordingly, knowing that they were contributing to a larger, more successful whole.
The goal of our system was to produce a constantly improving, evolutionary system. Our goal was to get something “good enough” out into the field, and then begin the improvement process. We had neither money nor time for gold-plated requirements and specifications. Our motto was, “generations, not specifications.” We didn’t claim to know the end point of the system when we started, but rather created tools for users to adapt. Someone used to waterfall/requirements driven life cycle process might find this appalling – that users could interactively develop a system in tandem with developers – but it was a key factor to the success of VistA.
Lesson Learned: Generations, not Specifications. Start with “good enough” and allow it to continuously improve through end user interaction.
VistA was designed to be adaptable to change. When we began, we were using PDP-11 computers, which now exist only in museums. Over the years, the system was hosted on VAX, Alpha, IBM Mainframe, PowerPC, and Intel computers with little or no modification. VistA was designed around a “kernel” architecture, consisting of common foundation that was used by all applications, but customized for specific needs of the various departmental needs such as laboratory, pharmacy, radiology, etc. The closest modern day equivalent to this is Facebook, which provides all users with a common set of tools, and then allows them to install “apps” to do specific tasks. We used a trimmed down version of the ANS MUMPS language, using only 19 commands and 22 functions.
Lesson Learned: Create a Path of Least Resistance to where you want to go.
For example, at the 1978 Oklahoma City conference, we decided on a standard format for storing dates in the computer. We knew that some patients had been born in the 1900’s, and we also knew that we would eventually be dealing with dates in the 2000’s. We created a program that would handle dates in this way, making it easier to do it the right way. We had a design ethic of making it easier to do the right thing: creating a path of least resistance to where we wanted to go.
Comments on the Vista Modernization Report: From Legacy to Leadership
The report is an impressive effort by a large number of committed industry advisors. I applaud the recommendation to move toward open source, and many of the recommendations.
However, I did not see the elements that lead to the success of VistA particularly well-represented in the report. The report focused on a heavily centralized, Washington-based development effort. User involvement was not stressed to the degree that it drove the original VistA development. It did not seem to fully recognize the unique needs of medical informatics, and seemed to make the all-to-common mistake of lumping clinical information with transaction-based administrative and billing systems.
Comments on MUMPS:
Key to the success of VistA was the ANS MUMPS programming language. The federal health IT systems that have been written have all been successful, stable systems: VistA, DoD’s CHCS, IHS’ RPMS. The Health IT systems that have been programmed in non-MUMPS languages (TRIMIS, IOCs, AHLTA) have been failures. Kaiser Permanente’s EHR system is based on MUMPS (Epic), and a leading contender for the AHLTA replacement is also MUMPS-based.
Yes, MUMPS is an old language, but the fact that it has enjoyed all of this success bears close scrutiny by those seeking to replace it.
Question: is the weakness of the current VistA due to MUMPS, or the VA’s management of development process?
The report criticizes MUMPS as being a legacy system, as being brittle and difficult to maintain. However, VA Central Office has been responsible for the architecture for 25 years now, and has had 25 years to address these problems. Instead of investing in its basic infrastructure, it has deferred its maintenance reach the breaking point we see today.
If you asked a carpenter to build a house for you, and the house turned out to be crooked, you wouldn’t accept the carpenter saying, “That darn hammer made the house crooked. You are going to have to buy me a better hammer.” VA Central Office has been using a tool for 25 years, and rather than keeping it current and up to date, is now blaming the tool, not their management of it, for the problems we see today.
If indeed the VA needs to move away from a MUMPS-based architecture, it is imperative that it understands exactly what worked in the past. I think that this will require a deeper dive into the foundations of VistA to be fully appreciated.
Lesson Learned: VistA is not just computer screens.
VistA was an outpouring of creativity of thousands of VA employees working together to improve service to veterans. This created many bonds of innovation and a shared sense of purpose that drove the community. The report seems to reduce VistA to strictly an IT issue – replicating the screens of the old system. VistA needs a broader organizational context in order to thrive in the future.
Is the VA just “paving the cowpaths” with new technology?
The recommendation that VA freeze development of the legacy system while engineering a new one that is functionally equivalent is a high-risk approach that threatens to stall IT innovation in the VA for a significant period. If the new approach is delayed or fails, the VA would be freezing itself out of innovation and years of new development.
A mobile phone today has about 1000 times the computing and communications capacity of the computer I first used to install VistA at Loma Linda Hospital. It costs about one one-thousandth the price: a million-fold price-performance improvement. One would expect that this drop in the cost of the electronics would lead to a corresponding drop in the cost of Health IT. Internet users today have access to an incredible array of free services for email, social networking, photo and video sharing, text messaging, mailing lists, auction sites, and the ability to search billions of web pages instantly.
Unfortunately, this is not the case. Health IT costs are spirally upwards rapidly, and systems that used to cost millions in the 1980s are costing in the billions today.
Why is this? Why is it that costs outside of health IT are plummeting and functionality exploding, while the cost of health IT is exploding and the functionality creeping forward slowly, if at all?
Imagine someone trying to sell the world’s greatest automobile. He offers the best car parts: an engine from a Corvette, the seats from a Rolls Royce, and a transmission from a Porsche. All that is required, he says, as a customer leaves with a truckload of these best of breed parts is “a little bit of integration.”
So it is with Health IT today. Vendors are offering “best of breed” components (with corresponding premium prices) and then offering integration services to customize them to specific customer needs. Yet the integration costs – connecting the dots – are the overwhelming factor.
One way out of this to reframe our thinking of IT architecture as a “space” rather than a “system.” Consider what Tim Berners-Lee said about the creation of the World Wide Web:
What was often difficult for people to understand about the
design of the web was that there was nothing else beyond URLs, HTTP, and
HTML. There was no central computer “controlling” the web, no single
network on which these protocols worked, not even an organization anywhere
that “ran” the Web. The web was not a physical “thing” that existed
in a certain “place.” It was a “space” in which information could exist.”
This opens up an extremely fertile discussion on how health IT might be supported using web-like information structures, as well as reduce the complexity we see in our systems today.
I have written other papers on this topic, (see appendix) Some of the more directly pertinent include:
HealthSpace architecture: http://munnecke.com/papers/HealthSpace.doc
Ensembles and Transformations http://munnecke.com/papers/D16.doc
Concepts of the Health Data Vault: http://munnecke.com/papers/D03.doc
VistA was an amazing outpouring of innovative collaboration within the VA that changed both its information technology and its organization. Decentralization and direct user involvement were key to its success, as well as having a technical infrastructure capable of supporting it.
Going forward, the VA should look to a theme of personalization of health – both in its IT infrastructure and its delivery of health care in today’s rapidly changing environment.
I would be happy to answer any questions you may have now or from those reading this transcript.
Table of Contents