What's HL7v2?!

HL7 (Health Level 7) is a set of technical specifications for computerized exchanges of clinical, financial and administrative data between hospital information systems (HIS). These specifications are variously integrated into the corpus of formal American (ANSI) and international (ISO) standards.

The L7 of HL7 indicates that it is a standard that operates at layer 7, in other words at the application layer, of the OSI model. This means that HL7 does not have to take into account exchange security considerations, or those of message transport (this being ensured by lower-level layers such as SSL/TLS for security or TCP for the transport of data for example). To be more precise, layer 7 supports communications for end-user processes and applications and the presentation of data for user-facing software applications. As the highest layer of the OSI model, and the closest to the end user, layer 7 provides application-specific functions such as identifying communication partners and the quality of service between them, determining resource availability, considering privacy and user authentication, and synchronizing communication, as well as connecting the application to the lower levels of the OSI model.

Returning to the HL7 standard, the HL7 version 2 standard (also known as Pipehat) was originally created in 1989 but is still being used and updated regularly, resulting in versions 2.1, 2.2, 2.3, 2.3.1, 2.4, 2.5, 2.5.1, 2.6, 2.7, 2.7.1, 2.8, 2.8.1, 2.8.2 and 2.9. The v2.x standards are backward compatible (e.g., a message based on version 2.3 will be understood by an application that supports version 2.6) and in higher versions, you will see some fields are left just for it.

Despite it being more than 30 years old, HL7v2 remains the most widely used healthcare interface standard by a large margin according to the HL7.org portal that tells that:

• 95% of U.S. healthcare organizations use HL7v2 interface standards
• More than 35 countries have HL7 interface implementations

Over time the HL7 interface standards have largely succeeded in helping healthcare providers and technology organizations:

• Ensure uniform EHR data for a consistent, complete patient view
• Automate workflows by reducing and eliminating manual data entry
• Help exchange health reporting electronically with regulators
• Open digital health records and data access for patients
• Reduce investments in new technology upgrades by building on a common standard

Messages

The standard is written from the assumption that an event in the real world of healthcare creates the need for data to flow among systems. The real-world event is called the trigger event.  

A trigger event is a message, or a data block exchanged describing an event that happened. HL7v2 standard defines messages (and their contents) that are sent between participating entities of the healthcare lifecycle. There are several HL7v2 types of messages. Some of them are presented in the table:

As the standard was updated and the version was increased, new types of messages appeared and some of them went out of use. Thus, different versions of the HL7v2 standard have a different number of supported messages (which increases). For example, there are over 200 different HL7 messages available for use in HL7 messages in version 2.8.

Let's now look at the segments in more detail.

Segment

A segment is a logical grouping of data fields. Segments of a message may be required or optional. They may occur only once in a message or they may be allowed to repeat. Each segment is given a name[...] Each segment is identified by a unique three-character code known as the Segment ID.  

In an HL7 message, each segment of the message contains one specific category of information, for example, patient information or patient visit data.  Different types of HL7 messages contain different HL7 segments. To be precise, the message type determines the expected segment types in the message. At the same time, every message has MSH as its first segment, which includes a field that identifies the message type. The segment types used in a particular message type are specified by the segment grammar notation used in the HL7 standards. For example, there are more than 170 segments in HL7 messages in version 2.8.

In general segments have fields separated by the composite delimiter. A composite can have sub-composites (components) separated by the sub-composite delimiter, and sub-composites can have sub-sub-composites (subcomponents) separated by the sub-sub-composite delimiter. The default delimiters are carriage returns for the segment separator, vertical bar or pipe (|) for the field separator, caret (^) for the component separator, ampersand (&) for the subcomponent separator, and pound sign (#) for the default truncation separator. The tilde (~) is the default repetition separator. Each segment starts with a 3-character string that identifies the segment type.

In order to be as flexible as possible and achieve a consensus, the HL7 committees were forced to define many segment fields as optional. The downside of this decision is that you cannot be certain that particular information will be present in a given message. This is one of the reasons why the same message may vary significantly from vendor to vendor.

Moreover, with HL7 messages being used to communicate all kinds of healthcare-related information to a variety of disparate systems, sometimes HL7 messages need to contain customized data that cannot be included in any defined segment for its message type. To accommodate this, the HL7 Standard enables system vendors to create a Z-segment with customized fields to transmit this data.

By convention, all custom segments begin with the letter Z. For example, a ZPD segment could be created to contain customized patient demographics information. Z-segments can be placed anywhere in an HL7 message, however, are typically located as the last segment in a message. Applications that process HL7 messages are usually configured to ignore HL7 Z-segments that they do not know how to handle.

Data types

The basic building block used to construct or restrict the contents of a data field[...] Each field is assigned a data type that defines the value domain of the field – the possible values that it SHALL take. The data type SHALL have a type taken from the list of data types defined[...] Data types may be either primitive or composite. Primitive data types consist of a series of characters as specified by the data type. Composite data types are made up of a set of components that are themselves assigned to a data type, which may again be either primitive or composite data types. In the case of composite data types, the components of a component are called sub-components, and they SHALL only be assigned primitive data types.

Each field defined in the standard has its datatype. Those can be, for example, string, time, money, date, address, arrays and more. 

Tables

Apart from values of the fields, defined by users, there are also tables of values, defined by the standard. They list all the valid values for fields using that table. There are 4 different types of such tables:

• HL7 standard - these values may not be redefined locally; however, the table itself may be extended to accommodate locally defined values.
• User-defined - these values are defined locally and vary from institution to institution
• External - these values are defined and published by other standards organizations
• Local - these values are also defined locally and may be used in Z segments

In the following articles, we'll look at some of the messages, their segments and fields, and see some examples.

That's it for now. Please leave a comment if you have any questions or suggestions.