HL7 Version 3 is released and available for use by the clinical application community. Medical informaticists are already using it as a vocabulary to discuss worldwide healthcare issues. Government entities have begun to look forward to using it to create interfaces between systems that have previously been completely separate. Healthcare entities in Europe, Canada, Germany, and several others have launched initiatives to implement Version 3. Even with these activities, HL7 V3 is in the infant maturity stage while HL7 V2 is still growing in its usage (see Figure 1).
HL7 V3 addresses some of the problems inherent in HL7 V2 while creating a few new challenges. HL7 V3 builds upon much that was learned from the development of V2 but without the burden of the V2 legacy issues.
This article provides a background on HL7 and highlights the key differences between HL7 V3 and V2.
HL7 is a Standards Developing Organization accredited by the American National Standards Institute to author consensus-based standards representing a broad view from healthcare system stakeholders. What this definition means from a practical standpoint is that HL7 has compiled a collection of message formats and related clinical standards that loosely define an ideal presentation of clinical information, and together the standards provide a framework in which data may be exchanged.
The HL7 standard is often called the “non-standard standard.” While not entirely fair, it does reflect the fact that almost every hospital, clinic, imaging center, lab, and care facility is “special” and, therefore, there is no such thing as a standard business or clinical model for interacting with patients, clinical data, or related personnel.
In order to set the context for both HL7 V2 and V3, it is critical to understand the user types for the messaging standards and how each user type influences both the development and use of the standard. Users can be divided into three segments:
Before HL7 V2, every interface between systems was custom designed and required programming on the part of both the sending and receiving application vendors. Interfaces were expensive because there was no standard collection of patient attributes or standard set of “interesting events.” As shown in Figure 2, in the 1980s, the number of clinical interfaces in a typical hospital was small, and the cost per interface was very high.
The primary reason for the challenge of interfacing is that as internal hospital teams or software vendors create new clinical applications, each application is developed without input or collaboration with other application development teams. That is, rarely do commercial development teams share proprietary data on how their applications are built, so it is difficult for other teams to build compatible applications.
Some forward-thinking, like-minded, healthcare community members formed a volunteer group to make interfacing “easier” – HL7 was born. It is critical to recognize that HL7 V2 was initially created by clinical interface specialists while V3 has been mostly created by medical informaticists. Consequently, the initial use and focus for each standard is keenly different.
As noted above, there are three primary types of HL7 users – clinical interface specialists, government entities, and medical informaticists. HL7 V2 was mostly created by the users of applications – the clinical interface specialists. Accordingly, the development approach for HL7 V2 was user-led and real-world-focused.
Clinical interface specialists in the healthcare industry decided that there had to be a better method to interface applications besides large amounts of custom, expensive coding. A small number of mostly acute care hospitals and software vendors formed a volunteer group to create a more standard way of building interfaces. In retrospect, the group’s goal was to substantially reduce the cost of building interfaces.
Without a standards history to rely on but with a drive to limit 100% custom interfaces, the group started to loosely define an implied data model and messaging “touch points” between applications. The primary challenges faced by the group were the small number of volunteers and a lack of interest on the part of major application vendors.
To meet the vision of a magnitude reduction in the cost of interfacing, it is only necessary to predefine about 80 percent of the interface framework upfront.
This allows a given facility to reflect special business, clinical, and workflow rules in the final 20 percent of the interface.
This 80/20 approach was practical in meeting the requirements of the clinical specialization and uniqueness that brings so many challenges across the continuum of care. This practicality was critical for widespread acceptance of the standard.
The value of the standard is driven by the type of user. For a clinical interface specialist, evaluating the power of any new technology or IT standard requires understanding the “Network Effect”; in other words, the standard’s value vastly increases as more sites and vendors adopt it.
Consider any of the popular de facto standards in use today: TCP, IP, , HTML, POP, telnet, Windows, or even the ASCII character set. They are all valuable because the user base has grown to be large and the standards work in the real world. Similarly, the Network Effect for HL7 would come if many healthcare applications started using it.
Ultimately, HL7 balanced the points that drove its creation: Solve 80 percent of the clinical interfacing problem in a flexible way using a consensus, volunteer-driven process. The focus was on making the standard easy to adopt so that the Network Effect would occur and create significant cost savings as quickly as possible.
It is fair to say that early releases of HL7 (V2.1 and V2.2) were vague and under-documented when compared to later releases. In early V2, little was formally specified for a number of reasons:
The tipping point for HL7 V2 acceptance came in 1998. About this time, enough vendors and healthcare providers had implemented HL7 that it was more advantageous for newly connected applications to take advantage of the 80 percent standard interface. Building a 100 percent custom interface was no longer justifiable or needed.
The V2 standard grew over time as it became more defined and covered more areas. The first usable version was 2.1 (released in 1990) with minor additions in 2.2 (1994) and ultimately 2.3 (1997) and 2.3.1 (1999).
The exact version of HL7 used by an application is not critical since the V2 versions are mostly compatible with one another. Said another way, HL7’s V2 philosophy is that newer versions of HL7 V2 should be backwards compatible with older versions of 2.X.
As data elements and messages are added to new V2 releases, they are marked as optional elements. The backwards compatibility means that, in general, a newer application can process a message from an older application and an older application can process a newer message. This is a very attractive idea but can be challenging to implement.
In the late 1990s, as vendors peered across the interfaces and began the HL7 adoption cycle, most took one of two approaches in choosing which version to support:
The Network Effect drives almost all users to adopt the de facto standard of HL7. As shown previously in Figure 1, the majority of applications use HL7 V2.3 or V2.3.1.
From 1998 to 2002, the HL7 community continued to grow and the value of HL7 V2 increased. As newer versions of HL7 were released, the community ultimately achieved the goal of defining 80 percent of an interface and in solidifying a framework for negotiation to resolve the remaining 20 percent on an interface-by-interface basis.
With market success, the community began to grapple with the challenge that an 80 percent standard interface means that there is still substantial work left as each interface is constructed. The broader, growing user base was often frustrated with the “non-standard” HL7 standard.
The V2 standard was now being reviewed, essentially, for the first time by the government and medical informaticists. These new users placed strong demands on HL7 that stretched its patchwork data model.
HL7’s wider adoption brings several significant changes:
With these changes, tension entered into the community between the clinical interface specialists who are current HL7 users versus those who want to adopt a new HL7 approach.
In general, the healthcare application users and vendors who have already implemented an 80 percent standard interface have little business motivation to replace it with something new, especially if it would only establish an 82 percent or 94 percent standard. Nevertheless, V3 efforts began in earnest, and a new HL7 standard has emerged.
As indicated, HL7 V2 is a market success, yet it continues to be refined. Many HL7 community members volunteer to enhance HL7 messaging and improve the methods used to define it. Most agree that the primary challenges with HL7 V2 are:
In late 2005, the HL7 community released the first version of HL7 V3 ─ the Normative Edition 2005. In mid-2006, the Normative Edition 2006 was published. With these two initial releases, many sections of the standard are complete, yet there are still several significant areas left to define or create in later releases. The planned V3 release cycle is four times a year, including three Implementation Editions for balloting and testing within the volunteer community and one Normative Edition for general use (released at the end of each year).
From the outset, V3 promises to be a brave new world with “90 percent or more” of the interface predefined. The primary value in the new standard will be an explicit data model, clear definitions, and more use cases that enable much less flexibility in individual message elements. The tighter standard promises “easier” interfaces for users.
While the HL7 V2 standard was created mostly by clinical interface specialists, the V3 standard has been influenced strongly by work from volunteers representing the government and medical informatist users. This means that the level of formal modeling, complexity, and internal consistency is radically higher in V3 when compared to V2. Illustrated below (see Figure 3) is a sample of the difference in message formats between a V2 and V3 message.
Outlined below is a summary assessment of the two HL7 versions.
||For clinical interface specialists:
The early decision to make V3 non-compatible with V2 means that existing V2 interfaces will not, without considerable modification, be able to communicate with newer V3 interfaces. This will create a new “digital divide” where applications that need to speak V3 will also need to speak V2. Early to mid-term adopters of V3 will often need both V2 and V3 interfaces to communicate between applications and healthcare providers. The double expense of implementing two HL7 versions may deter or delay the V3 adoption.
The early adoption of V3 has been in the following areas:
To date, HL7 V3 has not been widely adopted within the United States as a means to exchange clinical data. With one Normative Edition coming out per year, current V2 users often express uncertainty as to when to enter the V3 world. Current HL7 V2 US-centric vendors are generally in a wait-and-see mode, until their customers (US hospitals, clinics, labs, imaging centers) or a regulatory agency demand it.
An obvious question can be asked: “Will HL7 V2 simply disappear now that V3.0 is released?” We believe the answer is “no.” Millions of dollars and countless hours have gone into developing and maintaining HL7 V2 interfaces worldwide. From a financial perspective alone, it is inconceivable that HL7 V2 would quickly disappear.
Another common question is: “When will clinical interfacing switch to HL7 V3?” The likely answer to this question is: “When the buyers of interfaces demand it, and the dollars are available to make the transition.” In the US, barring a regulatory change, HL7 V2 and V3 will coexist. In other countries, adoption will likely continue to unfold.
V3 adoption likely will occur in a slow and methodical fashion. For healthcare professionals, it will be essential to continue to gain education on V3 and get involved in the HL7 Working Groups. Sharing lessons learned, watching trends, and evaluating early implementations will assist in determining the next prudent step for your organization.