The HL7 Standard was created and is maintained by Health Level Seven, an American National Standards Institute (ANSI) accredited Standards Developing Organization (SDO) that operates in the healthcare arena. The HL7 Standard is broadly divided into two categories – Version 2 (V2) and Version 3 (V3). The majority of HL7 messaging employs messages that use the 2.3 or 2.3.1 versions of the standard. Newer versions of the standard, including V3, represent only a small portion of real-world usage in interfacing. HL7 is also working on an emerging standard called HL7 FHIR.
With the passage of ARRA / HITECH, HL7 version 2.5.1 is specifically selected as the healthcare standard to meet certain certification requirements. Consolidated CDA, part of the V3 standard, was specified as well.
The HL7 V2 standard was created mostly by clinical interface specialists and was designed to provide a framework in which data could be exchanged between disparate clinical systems.
The V2 standard provides 80 percent of the interface framework, plus the ability to negotiate the remaining 20 percent of needs on an interface-by-interface basis. The standard achieves this goal by:
Defining HL7 encoding rules, groupings, cardinality, and the default character set (i.e. ASCII).
Providing support for local variations in data interchanges by allowing optional fields, additional messages, or additional portions of messages.
Evolving and adapting to changes required in local implementations, or to issues discovered via real-world usage of the standard.
Supporting batch processing of message file transfers.
Considering the relationship between the HL7 standard protocol with other protocols, such as lower layer protocols (i.e. avoiding replication of features), applications protocols (notably DICOM and X12, and protocols published by ASTM and IEEE), and other proprietary healthcare protocols.
Generally, all 2.X versions are backward-compatible with earlier versions because the V2 standard allows applications to ignore message elements they do not expect. This means that an older application can receive and process messages from newer applications using newer HL7 versions – i.e., messages containing more segments and/or fields – without producing an error.
The HL7 V3 standard was first released in late 2005, and was strongly influenced by the government and medical information users rather than clinical interface specialists. The V3 version is not backwards compatible with V2 versions of the standard, so existing V2 interfaces will not (without considerable modification) be able to communicate with interfaces using V3.
HL7 V3 was created to address some specific challenges identified in the HL7 V2 standard, including:
An implied, rather than consistent, data model.
An absence of formal methodologies with data modeling, creating inconsistencies and difficulties in understanding.
A lack of well-defined roles for applications and messages used in different clinical functions.
Too much flexibility and not enough of a full solution.
The goals of HL7 V3 were to increase worldwide adoption of the standard, define a consistent data model, create a more precise and less vague standard, and create an entirely new standard that would not be hindered by legacy issues. The decision to make HL7 V3 a new standard (and incompatible with older and more widely implemented V2 versions) means that it is has not been widely adopted thus far.
To adopt HL7 V3, users would need to create and maintain HL7 V2-based interfaces with HL7 V2-based applications, while deploying new V3-based applications and implementing interfaces between them. For this reason, HL7 V3 has been adopted primarily for use in applications without legacy communication requirements, without historical use of HL7 V2 in communications, or in regions/locations that have high government enforcement of HL7 V3 usage.
Fast Health Interoperable Resources (FHIR) is a next generation standards framework that combines the best features of HL7 V2, HL7 V3, and HL7 Clinical Document Architecture (CDA), while leveraging the latest web service technologies. The design of FHIR is based on RESTful web services, and is based on modular components called ‘resources’. FHIR supports both XML and JSON. The first normative edition is expected in 2017.