Reflections on the history of interoperability in hospitals

Abstract

Objective

To discuss the origins of HL7 and its subsequent impact on interoperability in hospitals.

Process

Reconstruction of historical events from review of personal notes, interviews with key participants and review of relevant publications.

Conclusions

The first versions of HL7 were based on the StatLAN protocol developed at the University of California, San Francisco and later commercialized by Simborg Systems Corporation. With the emergence of specialty clinical and departmental systems in the 1990s, a debate ensued between proponents of “open architecture” vs. “single vendor” systems. Although HL7 became the most widely used data-interchange protocol worldwide in healthcare, open architecture did not prevail in healthcare as it did in other industries. This is due to the unique market characteristics of the healthcare provider industry. The result today is the dominance of the healthcare IT marketplace by a small number of large vendors with relatively few options for in-depth specialty clinical systems.

It was 1987. The board of my start-up company, Simborg Systems, had just approved placing our proprietary StatLAN protocol in the public domain so that the newly formed HL7 standards organization could use it as the basis for its first version of their data-interchange standard. As one of the founding organizers of HL7, I knew this was needed to jump start our attempt to enable hospitals to integrate systems more easily and less expensively from multiple vendors. It was also needed to enable my company to succeed in introducing “open architecture” as an alternative to the then-dominant single-vendor mainframe-based solutions offered by such companies as Technicon and SMS. It was a period when minicomputer-based systems were just emerging for use in various hospital departments. Although minicomputer-based clinical laboratory systems were already widely used, departmental or specialty systems were just entering the marketplace in dozens of other areas.

If these new specialty system vendors had any hope of surviving, they could not operate as stand-alone systems. The cost and errors of reentering patient identification and tracking admissions/discharge/transfer (ADT) information in each were too great. An interface was required to the mainframe ADT system. If that mainframe vendor also provided the order entry and results reporting functions, those functions required interfaces as well. Finally, the main applications of the mainframe systems were their billing and other financial functions, again, requiring other transactions with other systems. Prior to HL7, the effort required by hospital and vendor IT departments to interface any 2 systems required negotiation and agreement on what transactions were required, the trigger events for such transactions, their data content definitions, and many other technical specifications regarding the physical and logical connection. As the number of such systems increased, this became known as the N²–N problem which was the number of such negotiations required for N systems. In 1987, the typical cost in software development fees to interface a clinical laboratory system to the mainframe was about $100,000. Repeating this for many other departments was clearly an impediment to open architecture. On the other hand, these specialty systems typically were developed by informatics pioneers in each area familiar with the needs and functions of those areas. It was unlikely that any 1 vendor could compete with that depth of knowledge and quality in every area.

Simborg Systems resulted from my previous job as CIO of the UCSF hospital for 8 years. Although I practiced internal medicine as a full-time faculty member, I was recruited to UCSF because of my informatics background incubated at Johns Hopkins where I was responsible for all clinical systems at that hospital.^1–4 At UCSF, I became dedicated to promoting specialty clinical systems and trying to solve the N²–N problem. Fortunately, this overlapped with the period when local area networks (LANs) were emerging as a new technology. At Hopkins, I had become acquainted with Steve Tolchin at the Johns Hopkins Applied Physics laboratory (APL) who was an expert on LANs and agreed to work with me to develop a LAN for UCSF.

At that time, there were several other hospitals experimenting with LANs. They were not the type of LAN I wanted to build at UCSF, however. They were what we called in those days “front-end” LANs. Their function was to enable a single terminal in any location to log onto any system on the network. This prevented the need to put multiple terminals in those locations, each dedicated to a different system. Although this saved the costs and wiring of the extra terminals, it required the users to learn how to use each system and no data were exchanged on the network between the systems.

Instead, I wanted to build the first “back-end” LAN in a hospital. That is the type of LAN we have today in which each system can exchange data with any other system on the network through a “data-interchange” protocol on the network. This protocol is what HL7 was standardizing for healthcare. It is the same type of protocol that was currently being created for each of the N²–N connections when there is no network. Since each of those individual protocols differed from each other and required $100 000 each to create, I wanted to reduce N²–N to N.

Steve Tolchin educated me that data-interchange protocols were in use in other industries and could be a model for UCSF. Such protocols consist of complex layers of functions that were described in a model published by the International Standards Organization (ISO) called the Open Systems Interconnection (OSI) model. There are 7 layers of functions in this ISO-OSI model. The lower 6 levels are standards that can be used in any industry. The highest level, level 7, is called the “application level” and is unique to each industry. That is why healthcare needed its own standard and why we called it Health Level 7. Each lower level has options for the standard that can be used at that level. For example, level 2 is called the data link level where the commonly used standard “Ethernet” is an option. Levels 3 and 4 contain the Internet Protocol and Transmission Control Program, the famous TCP/IP combination which is the basis for today’s Internet.

The main job for us at UCSF was to develop the level 7 protocol specification. Our plan was to link 4 separate minicomputer-based systems that we would install on this first LAN. Those systems were patient identification/ADT, outpatient pharmacy, radiology reporting, and clinical laboratory. That protocol needed to define every transaction, including error detection and recovery messages, that would enable us to communicate all patient identification, ADT data, outpatient prescriptions, laboratory and radiology orders, and displays from each system and then embed this protocol into each system on the LAN. APL built the hardware containing the lower 6 protocol layers in custom boxes called network interface units which would be connected to each computer. Our first open architecture “back-end” LAN system in any hospital went live in 1979. It worked!^5–7

Being an academic desiring to further research and publish about this new approach to hospital interoperability, I needed to continue to raise funding. I solicited Ralph Ungermann, the CEO of a silicon-valley company called Ungermann-Bass which was one of the leading companies commercializing LANs. He was very impressed with what we were doing but said he would not be willing to contribute to our funding. Instead, he proposed that we commercialize what we were doing in a new company he would cofound with me and raise venture funding as he had done with his own company. That changed my life.

Simborg Systems was founded in 1984. I hired Wes Rishel to be our technical VP and his team improved the protocol we had developed at UCSF and sold it as part of a hospital interoperability system called StatLAN. By the time we contributed the protocol to HL7 in 1987, we had 4 hospital customers. I went on the board of HL7, Sam Schultz who was the CIO at one of our hospital customers became HL7’s first president, and Wes Rishel led the team producing version 1 of HL7 which was largely based on the StatLAN protocol as was version 2.

The early years of HL7 were a struggle. Clearly, the large mainframe vendors which dominated the hospital market had little interest in seeing open architecture replace their monopoly on large centralized single-vendor systems. Most of HL7’s early vendor membership were laboratory and other specialty system start-up companies with little overall market share. Our Simborg Systems customers consisted of like-minded CIOs seeing the vision of open architecture and willing to risk their careers on this model.

What ensued over the next decade was a debate between “open architecture” and “single-vendor” for the hearts and minds of hospital decision-makers. We had already demonstrated at Simborg Systems’ early customers that using a standard data-interchange protocol on a LAN eliminated 90% of the effort to integrate a new system. That is, the interface cost per new system was now around $10 000. This allowed much greater flexibility in selecting specialty systems that added functions not available on the mainframe or were clearly superior to any that existed. In some ways, this turned out to be a battle between the clinicians and the financial decision-makers regarding systems in hospitals. The latter are risk-averse and CIOs in hospitals want to make sure they keep their jobs.

Other industries were having much greater success in converting to open architecture. Examples included the auto manufacturing industry which needed to integrate systems from many vendors in a single plant. The same was true for the airline manufacturing industry. Each of these industries had standards organizations analogous to HL7 for their industries. In studying those industries, what became clear to me was the success of their standards organizations in proliferating their use pivoted on 1 factor. The most dominant buyers of systems in their industry adopted the standard and required its use by the vendors who wanted to sell to them. For the auto industry, it was the big 3 auto manufacturers: GM, Ford, and Chrysler. For airline manufacturing it was Boeing. The best example of all was the biggest buyer in the world of systems serving the US Defense industry which required TCP/IP to be used by any defense contractor desiring a contract.

That lesson hit me like a ton of bricks. In healthcare, the biggest buyers of systems were hospitals. But unlike those other industries, there is no dominant hospital buyer that compared to those counterparts in other industries in market clout. The closest thing I could think of was the organization that represented most hospitals—the American Hospital Association (AHA). Although the AHA did not actually buy any of these systems, their endorsement and recommendation that all hospitals require their vendors to adopt HL7 would be a major step forward. I proposed this to the leadership of the AHA, emphasizing of course the tremendous cost savings it would bring their hospitals, even those that did not choose open architecture but still had occasional need to implement an interface to a new departmental system like the clinical laboratory, cardiac catheterization, emergency department, etc. My proposal went nowhere. The feedback I received was this would be too controversial a topic for them to pursue and beyond the type of issues they normally address as an organization.

Ultimately, most hospitals did adopt the HL7 standard in some manner as did most vendors, including the “total solution” type vendors. But this happened slowly. During the 1990s, HL7 grew in membership and scope, becoming international, and released more advanced versions of its standard. It is, by far, the mostly widely used healthcare data-interchange standard in the world today. However, open architecture did not parallel that growth. In fact, it languished.

This seeming paradox can be attributed to the unique healthcare marketplace. Hospital organizations evolved during this period and became increasingly absorbed into larger and broader organizations mostly through acquisition of other hospitals, physician practices, and other components. With it came increased management complexity and the need to focus on their broad financial picture. CIOs typically reported to CFOs or VPs having financial responsibility. Existing computer systems serving those organizations had likely been in place for long periods and although their dominant system vendors continually released new versions, the occasions when a provider organization or even an individual hospital would contemplate a switch to another vendor were infrequent. Such switches were complicated and costly. The option to consider open architecture seemed even more risky to the finance folk. Clinicians heading up various specialties or department heads simply did not have enough influence on these decisions.

The result is that the great proliferation of specialty system vendors that occurred in the late 80s and early 90s dwindled to a relatively small number of functions. Broad choices are no longer available even if an enterprising CIO desired to take the open architecture route. The entire health information system industry has consolidated to the point today where a small number of vendors, including Epic Systems and Cerner dominate the healthcare market. This is in no way intended to denigrate these remaining vendors. They have done a magnificent job and generally serve the market well. However, I believe an opportunity has been lost to provide higher-quality specialty and departmental systems, particularly to clinicians.

Author contributions

Donald W. Simborg, MD, is the sole author of this article.

Funding

This research received no specific grant from any funding agency in the public, commercial, or not-for-profit sectors.

Conflict of interest

None declared.

Data availability

No new data were generated or analyzed in support of this research.