Rhapsody site logo

HL7 resources

Versions of the HL7 Standard

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.

Optimize resource productivity with the most trusted and flexible HL7 and API integration tools in the market

HL7 V2

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.

HL7 V3

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.

HL7 Timeline

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

You might also like

HL7 resources

HL7 Data Types

HL7 data types define the kind of data included in a field used in the HL7 message structure. Examples include a string, text, timestamp, address, or coded element.

Read more >

HL7 resources

RIM-Reference Information Model

The HL7 Reference Information Model (RIM) represents a static model of healthcare workflows as viewed by the HL7 standards development group.

Read more >

HL7 resources

Minimum Layer Protocol – MLP

MLP is how an application should wrap an HL7 message to ensure HL7 compliant applications know where a message starts and stops, and where the next message begins.

Read more >