The HL7 Evolution

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 informatists. Consequently, the initial use and focus for each standard is keenly different.

How was HL7 V2 created?

As noted above, there are three primary types of HL7 users – clinical interface specialists, government entities, and medical informatists.  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.

What is HL7 V2’s value?

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, HTTP, 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 a significant cost savings as quickly as possible.

The result: HL7 V2

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 community needed more users and vendors to adopt the standard
• The more flexible and vague the standard, the easier it would be for applications to adopt it
• If the standard was too rigid, it would be easy to dismiss as “unworkable” because every healthcare entity and application is “special”
• Early versions of HL7 only needed to specify about 80 percent of the interface in the framework

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 latest version of HL7 (V2.3 or V2.3.1)
• The version of HL7 that their first healthcare application or vendor had already implemented (typically versions 2.2, 2.3, or 2.3.1)

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.

The HL7 community grows

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 informatists.  These new users placed strong demands on HL7 that stretched its patchwork data model.

HL7’s wider adoption brings several significant changes:

• The V2 standard becomes better refined
• The pool of volunteers creating the standard increases in size, including more users from government entities and medical informatists
• The international community starts to use HL7 and extends V2 to support healthcare environments and business rules outside of the US

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.

Philosophy of V3

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:

• Lack of consistent application data model which is only implied in the V2 standard ─ The display/storage of data by a clinical application directly impacts what portions of HL7 it can successfully implement.
• Lack of formal methodologies to model data elements and messages ─ This causes inconsistencies within the standard and difficulties understanding how message elements relate to each other.
• Lack of well-defined application and user roles ─ Without defined roles, which portions of HL7 are supported is a vendor choice causes large variation on which messages are used for a given set of clinical functions when two applications attempt to use the HL7 V2 standard.
• Lack of precision in the standard ─ The very vagueness and flexibility that led to “simple adoption” of HL7 V2 causes it to be exactly what it was intended to be: an 80 percent solution.
• In the late 1990s, a subset of the HL7 standards community decided to address these HL7 V2 challenges. The goals in creating the new HL7 V3 standard were:
• Internationalization — HL7 V3 needs to be able to be used by the worldwide HL7 organization while supporting the need for local variants.
• Consistent data model — HL7 V3 needs to define the data model used by HL7 applications in order to have consistent data available for implementation.
• Precise standard — HL7 V3 needs to take the information learned from all the HL7 V2 versions and create a standard that contains all the necessary data and is less vague and therefore less flexible.
• New standard — As the community began to define HL7 V3, it decided that V3 would not be compatible with V2 for a number of reasons. Primarily, if V3 was backwards compatible with V2, the newer standard would be hamstrung with many legacy issues.  Any attempt to retrofit an explicit data or application role model into V2 would be difficult and the antithesis of the vague V2 world.  Finally, the standard needed breathing room so it could radically change in order to improve the quality of clinical interfaces.

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.

HL7 V3 vs. V2: A Comparison

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.