The HL7 Evolution

Executive Summary

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.

What is HL7?

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.

Who Uses HL7?

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:

1. Clinical interface specialists are tasked with moving clinical data, creating tools to move such data, or creating clinical applications that need to share or exchange data with other systems. These users are responsible for moving clinical data between applications or between healthcare providers.
2. Government or other politically homogeneous entities that are looking to the future of sharing data across multiple entities or in future data movement – generally, few legacy systems are present. Often these users are looking to move clinical data in a new area not covered by current interfaces and have the ability to adopt or mandate a messaging standard.
3. Medical informaticists who work within the field of health informatics, which is the study of the logic of healthcare and how clinical knowledge is created. These users seek to create or adopt a clinical ontology – a sort of hierarchical structure of healthcare knowledge (a data model), terminology (a vocabulary), and workflow (how things get done). An informaticist is interested in the theoretical representation, semantic interoperability, and extensive modeling of the acts and actors of healthcare.

Why was HL7 created?

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.

How was HL7 V2 created?

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.

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 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 informaticists.  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 informaticists
• 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.

Outlined below is a summary assessment of the two HL7 versions.

Standard	Benefits	Challenges
HL7 V2	Reflects the complex “everyone is special” world of healthcare.Much less expensive to build HL7 interfaces compared to custom interfaces.Provides 80 percent of the interface and a framework to negotiate the remaining 20 percent on an interface-by-interface basis.Historically built in an ad hoc way, allowing the most critical areas to be defined firstGenerally provides compatibility between 2.X versions.	Provides a “one size fits none” standard.“Loose and optional ridden” HL7 definitions lead to discrepancies in HL7 interfaces.Not inclusive of international needs.No compatibility with HL7 V3.Defining a detailed list of items to be discussed and negotiated before interfacing can occur is required.Application vendors do not support the latest and best-defined versions of HL7.
HL7 V3	More of a “true standard” and less of a “framework for negotiation”.Model-based standard provides consistency across entire standard.Application roles well defined.Much less message optionality.Less expensive to build and maintain mid-to-long term interfaces.Many decades of effort over ten year period reflecting “best and brightest” thinking.	For clinical interface specialists: No compatibility with HL7 V2.Adoption will be expensive and take time.Long adoption cycle, unless strong business case or regulatory requirement changes.Retraining and retooling necessary.Applications will have to support both V2 and V3 in the foreseeable future.

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.

V3 Status and Direction

The early adoption of V3 has been in the following areas:

• Applications without legacy communication requirements – environments where each end of the interface can be tightly controlled and where exchange of data with legacy applications is not required. Examples include the US Centers for Disease Control with state-level reporting for the National Electronic Disease Surveillance System and the US Food and Drug Administration’s clinical trial reporting purposes of electrocardiograms.
• New communications environments – those where HL7 V2 was never or rarely used historically – for example, in the Netherlands for physician-to-physician communications.
• Politically homogeneous deployments – in locations/regions of the world where one government agency can focus the efforts and force the use of V3. Examples include:
  • National Health Service, National Programme for IT, and Connecting for Health projects in the United Kingdom where many clinical software applications are being replaced or upgraded and a national data exchange spine is being built.
  • Canadian Institute for Health Information has some localization standards produced for V3 primarily in the area of Claims and Reimbursements.

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.

Suggested Next Steps

For software vendors:

• Remember that V3’s use of XML is only 5 percent of the value of the standard.
• Discuss with your clients (buyers) their needs for HL7 V3. Often users ask for V3 interfaces without an understanding of the scope of the standard or the costs incurred to implement V3.
• Review the HL7 Reference Information Model (RIM) and study the explicit data model.
• Compare the relationships stored in your application database with those modeled in the RIM.
• If building a new application, use the RIM’s basic concepts and relationships. Early experience shows that you cannot use the exact RIM model as a database schema because performance is too slow.
• Understand that almost all applications that speak V3 must also speak V2 ─ the installed base of V2 interfaces means that typical applications must speak both.
• Review the application roles in V3 to see what additional application functionality will be needed to support V3.
• Educate your users around HL7 V3 and your plans to support the V3 standard or stick only with V2 (so far a common approach.)
• Gain education on the HL7 3 standard and start to understand the impact it will have on your application. Depending on the application, there could be many changes required to adopt V3.
• Become involved in the HL7 organization – this will keep you up-to-date on the most recent developments and allow you to be part of the process.

For healthcare providers:

• Decide if V3 has true value in your environment. What do you expect V3 to do that existing V2 interfaces are not already doing?
• Discuss interfacing strategy with your vendors. If you are moving towards V3, review existing vendors’ development plans to add V3 or pick new vendors with V3 interfaces.
• Demand V3 from vendors only when there is a solid business or clinical motivation because the costs to have V3 in your environment will be high.
• Expect that mapping between V2 and V3 will be challenging and expensive. Interface engines must be augmented with substantial data repository functionality in order to provide any mapping.
• Weigh costs of continuing to build “80 percent standard” HL7 V2 interfaces against entering the expensive world of V3.
• Understand how early your site will be in the V3 learning curve ─ ask any vendor who proposed a V3 interface how many other sites have the same V3 interface running and how many different applications are communicating using the interface.
• Consider if your site should become an early adopter of the V3 standard – how much local interface expertise do you have? What is the backlog of interfaces? How will V3 help solve your business requirements short and long term?
• Gain education on the HL7 3 standard and start to understand the impact it will have on your interfacing environment.
• Become involved in the HL7 organization – this will keep you up-to-date on the most recent developments and allow you to be part of the process.

Want to learn more about HL7? Enroll in the Academy’s HL7 training course now!