NeoTool — Singular Focus, Healthcare Integrated

Posted in HL7 Messaging, HL7 Standard

HL7 messaging provides a method to move or transfer information between two or more clinical software applications within a healthcare setting. There are two major versions of HL7: HL7 2.x and HL7 3.x. In the United States, today almost all production HL7 interfaces use the HL7 2.x message format. This posting introduce the motivation for mapping between different vendor’s HL7 implementations. (Also available on this web site is an extensive 14 page paper covering the history of HL7 2.X and the pros/cons of HL7 3.X.)

The need to map HL7 messages is typically caused by one or more of the following:

1. Applications implementing different versions of the HL7 standard
2. Different workflows or application data models in the sending and receiving applications
3. Applications not correctly implementing the published HL7 standard

Each of these is covered in more detail below.

Applications implementing different versions of the HL7 standard: During the past 20 years the HL7 community has released several versions of the HL7 2.x messaging standard. The first version of HL7 was HL7 2.1 and, when released in 1987, consisted of approximately 38 “useful” messages (not counting ACKs) and 27 segments.

Over time the complexity of HL7 has grown through a series of releases: 2.2, 2.3, 2.3.1, 2.4, 2.5, and soon 2.6. In addition, HL7 2.7 is already in development. As I discuss during HL7 education sessions, these versions of HL7 are “mostly” backwards and forwards compatible. What started out as a “small standard” has grown into HL7 2.5 with approximately 361 messages and 145 segments.

The massive growth in the scale of the HL7 standard has meant that there is no single “right way” to implement HL7. Application development teams look at the standard and “pick and choose” the messages and data elements they will implement. Ultimately this means that each product speaks a different flavor of HL7.

Different workflows or application data models in the sending and receiving applications: The need to map can also be driven by the different interpretations of HL7 itself and the different workflows that each facility or application chooses to implement. There are an infinite number of examples and here are a few typical cases:

1. HL7 allows for zero to many insurance carriers. A sending application might support a fixed number (say, seven) while the receiver may support a subset (say, three). Thus, the sending application will collect data on up to four insurance carriers that will not be visible in the receiving application
2. HL7 allows for one to many patient identifiers. A sender may only collect one patient identifier (say, the medical record number) while the receiver needs a different identifier (say, a master patient index value.)
3. As noted above, HL7 2.5 has over 300 different trigger events including several for patient tracking and over a dozen for different types of merges. The likelihood that the sender and receiver will not agree on the workflow – and thus the trigger events – is very high.

Applications not correctly implementing the published HL7 standard: While it is easy to blame the application vendor for mis-implementing the standard, it is also critical to understand why the applications do not follow the standard. Typically the data models of the “misbehaving” applications don’t support certain constructs or there is minimal business value in fixing the interface to behave.

Regardless of the motivation for mapping, ultimately the gap between sender and receiver must be closed. Typically, an HL7 engine is deployed as part of the network to help with the mapping process. If an interface engine is not available, the vendor on the sending or receiving side of the HL7 interface must perform the mapping as part of the import/export logic.

Last 5 posts by Dave Shaver

• HL7 Working Group Meeting Includes Strong International Attendance - September 16th, 2008
• Integrating EMRs with Reference Labs - September 3rd, 2008
• Massachusetts Hospitals Must Have CPOE by 2012 and CCHIT-Certified EHRs by 2015 - August 13th, 2008
• HL7 Dates and Times - July 25th, 2008
• HL7 Time Zone Qualification - July 25th, 2008