The dawn of modern information systems is arguably the invention of the C programming language and Unix by Dennis Ritchie and others at Bell Labs. The C programming language and the Unix operating system gave birth to an industry that now includes Microsoft Windows, the Apple iPhone, and most of the other tech goodies that we know and love. Almost all software engineers are used to working on C-style programming languages. Even the physical layout of code (usually whitespace invariant) in modern programming languages is based on C.

Important attempts to computerize healthcare date back slightly earlier in the same era, which explains one of the central differences in health IT: MUMPS.

MUMPS stands for Massachusetts General Hospital Utility Multi-Programming System. It is typical nerd humor that a programming language sponsored by a hospital was named after a disease. Unlike C and Unix, there was no strong separation between the programming language of MUMPS and the operating system of MUMPS. In fact, originally, MUMPS was a programming language, database, and operating system all rolled into one. MUMPS was built by Dr. Octo Barnette in his animal lab and became the foundation of a hospital information system.

From the beginning, MUMPS was built to be a hierarchical database, rather than the table-based SQL databases that most programmers and information managers are familiar with. Until recently, this was something difficult to explain about MUMPS, but now databases with a similar hierarchical structure are on the market. Much of the recent NoSQL movement has been a return to design principles that have been in MUMPS for more than four decades.

As a fundamental data model, SQL works really well for data that is highly repetitive so that it can be well-modeled using a table. SQL starts to break down when the data structure varies greatly for each individual, which is the norm in healthcare.

MUMPS is significantly different from C-based languages. The syntax can be much terser, and it is not whitespace-invariant. This makes a block of MUMPS code look very intimidating to programmers who are not familiar with it—which is almost everyone. At one time there were several important vendors for MUMPS and the language was commonly used in finance as well as healthcare, but as the financial industry moved away from MUMPS the vendors consolidated. Now there are only two common MUMPS providers; Intersystems, which provides Cache, and the open source GT.M implementation. You might have seen Intersystems advertising an object database; they are talking about MUMPS. The name MUMPS was viewed by some commercial vendors as a marketing barrier, and as a result, they started calling the language M in an obvious reference to C. People who wanted to compromised between the original name and the market-friendly name often write [M]UMPS.

At least three of the most important health IT systems still available are based on the MUMPS programming language: MEDITECH, Epic, and VA VistA. VA VistA is the most widely feature-comprehensive EHR installed in the United States, running at every VA hospital in the country. MEDITECH, by many reports, is the largest proprietary hospital health IT vendor. Epic is generally regarded as the leading provider of health IT systems for very large hospitals. If you are running an EHR in a hospital in the United States, it is a good bet that you are running a MUMPS database.

MUMPS is only one of the “shared histories” of health IT software vendors. One of the early revolutions in healthcare was the X-ray, which allowed people to see accurately the skeletons of people while they were still living.

As the value of X-rays to medical science became obvious, the technology was addressed by several companies with prior expertise in the required technologies—meaning that they made light bulbs. Later, the spread of computerization made it obvious that the photographic process in X-rays should be digitized, and medical imaging was the first area to be substantially computer based several decades before meaningful use began forcing normal doctors to computerize the contents of a medical chart.

The companies that had made the first light bulbs in the century before shepherded this early adoption of health IT and wrote software to run their various imaging machines. Usually, this software was the first enterprise software to run inside hospitals and clinics. It made sense for these same vendors to expand into general health IT. This is the reason why GE and Siemens are leaders in the modern health IT space.

Interestingly the companies that invested heavily in radiological systems also invested in early interoperability efforts around medical images. The resulting set of standards, called digital imaging and communications in medicine (DICOM), were among the earliest attempts to get different health IT systems inside hospitals to talk together. Originally, DICOM was used mostly to get different types of image sources (X-ray, MRI, CAT, etc.) to save medical image data to a central server. Eventually, it was understood that all of the different systems inside a large hospital needed to communicate, and the IHE efforts were born to define how each system should work together. IHE is a heavyweight, and comprehensive approach to healthcare information exchange. Generally, this means that the “light bulb companies” are often somewhat deeper into interoperability than other companies. For instance, General Electric employee Keith Boone, wryly dubbed motorcycle guy, is a full-time standards geek. He is often found either participating or leading efforts at IHE, HL7, Direct, and other standards bodies, and is one of the most outspoken advocates for good healthcare interoperability standards.

For unclear reasons, no one health IT vendor has ever become dominant. A new company would start selling health IT systems, expand for a time, and then either stall out and shrivel up or become acquired by some other company.

The largest health IT vendor at the clinic level (and because 80% of healthcare happens in clinics, perhaps the largest health IT vendor of them all) is Allscripts. By some estimates, Allscripts has 15% of its market. But that 15% percent is not the result of organic growth. Today’s Allscripts is the result of a merger between Misys and the original Allscripts, both of which in turn are the products of previous mergers.

All of this speaks to the most unusual aspect of the health IT market: its fragmentation. In other software industries, a clear winner usually emerges. For some reason, this has never happened in health IT. The large companies in health IT are either extremely old and grew very slowly, or they are the result of several mergers and acquisitions.

This process of acquisition has been accelerating in the face of meaningful use. Although the standards are fair, they do serve as an impediment to health IT startups and young companies. Many have chosen to sell their solutions to competitors, rather than bear the costs of certification.

To establish a fair market, both the buyer and the seller must have access to the same amount of information. Economists sometimes call this concept information parity. In the market for EHRs, a typical vendor has substantially more information than any potential buyer.

This is particularly difficult to remedy. In other markets, Consumers Union provides the service of evaluating products fairly. Consumer Reports, which is published by the Consumers Union, buys all of the products that it evaluates retail and does not accept payments from vendors in order to prevent bias in its ratings.

To do this with an EHR, an evaluating organization would need to have a hospital or clinic that it could use to install an EHR system and then uninstall it and repeat. Obviously, running a hospital merely to test EHR systems is not a viable approach.

There are several services that offer to provide insights into the performance of EHR systems. The most famous of these is KLAS, which bills itself as “Accurate, Honest, and Impartial.” Admittedly, they are honest in being open about receiving about 50% of their income directly from EHR vendors. But accepting money from the companies that they evaluate (which is the norm for the EHR evaluation companies) is not even the most significant issue with KLAS’s evaluation method. The main problem is subtly tied in with their use of survey tools to have the technical leadership of hospitals and clinics evaluate the results of EHR deployments. That method tends to undervalue the impact of the EHR on front-line clinicians, and ignores important intangibles such as the financial stability of a given vendor. For instance, EHR vendor AcerMED was rated as “best in KLAS” by KLAS Research before being sued out of existence in 2007.

This is not to say that the KLAS organization does not live up to its moniker. In fact, they probably are accurate and honest, and to the degree that they are not impartial, at least they are transparent about their conflict of interests. The real problem is that the EHR industry is very difficult to evaluate objectively, no matter how honest the evaluator is. The danger with organizations like KLAS is that they give the impression of providing reliable data, when in fact their information might not actually help to establish information parity. It is reasonable to conclude that KLAS, and organizations like them, are doing the best they can. But their data is fundamentally limited.

One fundamental reason for the limitations on evaluators’ data is the clauses in most agreements between proprietary EHR vendors and their customers, stipulating that the customer cannot discuss or criticize the product publicly, or even say how much they paid for it. In many ways, it’s surprising that CIOs and other technical leadership at clinics and hospitals respond to the KLAS survey at all. Most contracts with EHR companies serve to ensure that the information parity needed to build a fair market can never reach the market. Indeed, only a small percentage of the information that KLAS gathers is ever publicly released.

There are movements within health IT seeking to overturn these types of gag orders, and it is possible that future versions of the meaningful use regulations will forbid these types of business practices. For now, it is very difficult to objectively evaluate the proprietary EHR marketplace, because most vendors want to keep it that way.

In the late 1970s, a group of rogue programmers working at local VA hospitals began collaboratively developing software they called the Decentralized Hospital Computer Program (DHCP). Eventually, they were discovered by the central office at the VA and several of them were fired. This took the development process underground, ironically forcing the community of programmers working on DHCP to collaborate in a manner that would later appear in open source distributed development practices. People were free to use and modify each other’s code, and the clinicians and programmers doing so spontaneously contributed their improvements back to the original author. This collaboration could not be centrally coordinated, because to do so might incur the wrath of the VA central office. This movement became known as the Underground Railroad at the VA.

Eventually, enlightened leadership at the VA discovered the work of the Underground Railroad and realized that this community had achieved what the central office had failed to provide for years: the skeleton of a system that could fully computerize healthcare delivery at the VA. The VA administration blessed the project and it was renamed VistA.

This group of rebel programmers not only eventually turned VistA into the most comprehensive EHR in the United States, but used it to drive forward the improvements that make the VA one of the most effective healthcare delivery systems in the world. This is the basic thesis of the book by Phillip Longman that we recommended in the introduction: The Best Care Anywhere. You can also read about the history of VistA firsthand at HardHats.org or read a summary of the VistA project in the “What Is VistA Really” article on the WorldVistA sponsored VistApedia site.

Probably the most significant detail regarding VistA is that, because it was developed entirely by federal employees, it is available for download under the Freedom of Information Act (FOIA). Essentially that makes the source code for VistA available in the public domain. Public domain software can be used for the basis of both open source projects and proprietary projects.