HL7 is a standar for health’s clinical and administrative data. One of objective of this standard is to develop a coherent, extendible standard that permit structured, encoded health care information of the type required to support patient care, to be exchanged between computer applications while preserving meaning.

How a HL7 Message looks like

MSH|^~\&|GHH LAB|ELAB-3|GHH OE|BLDG4|200202150930||ORU^R01|CNTRL-3456|P|2.4
PID|||555-44-4444||EVERYWOMAN^EVE^E^^^^L|JONES|19620320|F|||153 FERNWOOD DR.^^STATESVILLE^OH^35292||(206)3345232|(206)752-121||||AC555444444||67-A4335^OH^20030520
OBR|1|845439^GHH OE|1045813^GHH LAB|15545^GLUCOSE|||200202150730|||||||||555-55-5555^PRIMARY^PATRICIA P^^^^MD^^|||||||||F||||||444-44-4444^HIPPOCRATES^HOWARD H^^^^MD
OBX|1|SN|1554-5^GLUCOSE^POST 12H CFST:MCNC:PT:SER/PLAS:QN||^182|mg/dl|70_105|H|||F

Yes… Looks strange at first sight… but believe me, it is perfectly logic.

Dissecting the message

An HL7 message consists of the following data elements.

Message type

An HL7 message type is a unique identifier for the business purpose of a message. Every message must contain a message type id as way to announce the purpose of the message. For example, ADT is a unique message ID to Patient Administration.

However, it is rather not a unique classification on the structure of a message. One message type can have more than one message structure.

The message type is advertised in the message header segment

Message event

The message event, sometimes called a trigger, is a unique identifier to the context in which message is generated. The message event consists of an upper case letter and two digits. For example, A01 is for admission/visit notification and A61 is for changing consulting doctor. Both A01 and A61 are used with ADT messages

Event type is advertised in the message header segment.

Message structure

The message structure is a data structure used to express an association of a message type with an event for a class of messages. Each message structure also contains a unique ID.

It structurally consists of a well-defined list of HL7 segments. Segments can be optional, and can repeat. There is no limit on how many times a segment can repeat.

Segments can be aggregated together to form a segment group, which can repeat as well. In the standard specification, segment group is indicated by {} or [], where {} signifies repetition and [] signifies optionality.

Relative position of segments in a message structure and segment groups is well defined. At the message structure level, segment is the atomic data type.

Message structures are defined by both message type and events. One message type can associate with more than one event, but one event can only associate with exactly one message type. Furthermore, some events with a given message type associate with the same message structure. For example message type ADT with both event A01 and event A04 uses message structure ADT_A01

Message structure of ADT_A61

Segments

Segment is a well-defined list attributes, each of an HL7 data type. All segments start with three upper case letter segment IDs. Segment attributes can be optional and can repeat. The maximum number of how many times an attribute can repeat is specified. Various tables define the validity of certain attribute value.

Note: The relative position of segment attribute is significant in how it is defined.

Every segment ends with a segment terminator, either the ASCII carriage return or x0D.

HL7 calls the segment attribute Field. The standard designates a delimiter, whose value is a defined by the user on per message instances basis, to separate fields.

When the fields repeat, the standard designates a user-defined delimiter, whose value is defined on per message instance basis, to separate repeating fields. Delimiters that separate repeating instances of a field are also defined by use, and call repetition

MSH segment specification

Note: In the previous table, “Len” stands for maximum length in number of characters; “DT” stands for data type; “OPT” stands for optionality; “Element Name” stands for brief descriptive name of the field.

The structures of many segments are statically defined and can be shared in many message structures. There are also some segments that share the same segment ID but have a different structure — different attribute in name and data type. QPD, QED, RCP, QAK belong to this category of segments

Data types

HL7 defines a long list of data types. Some are as defined as a primitive type, while others are defined as a complex type. A complex data type consists of more than one attribute of the primitive type. HL7 calls the attributes of a complex data type a component

For example, the following HD data type uses three components, namespace ID, universal ID, and universal ID type.

<namespace ID (IS)>^<universal ID (ST)>^<universal ID type )ID)>

The standard designates a delimiter, whose value is defined by the user on per message instances basis, to separate components.

Other complex data type can further define a component of a given data type. HL7 calls the attribute of this complex data type subcomponent. The complex data type must have all attributes be of primitive type.

The standard also designates a delimiter to separate subcomponents whose value is defined by the user on per message instances basis.

The component delimiter of the data type that defines a component is then demoted to subcomponent delimiter.

HL7 also designates an escape character for escapting characters that are identical to various delimiters. These are defined by the user on per message instance basis.

Most data types are well are statically specified as distinct data structures in the standard. A few data types, notably the CM and * data type, exhibit dynamic behavior, and warrant special attention.

Custom made data types

CM is also called a Composite data type. This data type is a custom construction using previously defined data types for each unique situation, in a different segment, or at different field of the same segment. There are number of data structures associated with the CM data type.

The data structures for the CM types, which can differ widely from one another, are solidified at time when segments they belong to are defined. The CM data type is known at design time.

In earlier versions of the HL7 standard, CM is meant to be custom-made data type, data type defined on local site of deployment. For this reason, CM data type represents endless number of structures with different combination and permutation of readily defined data types.

Version 2.4 of HL7 only has finite number of data structures that is labeled with CM data type.

Polymorphic data type

This is the data type that is marked with * symbol or with “varies” data type label, instead of the usual two or three capital letters.

This data type exhibits a common behavior that it can be any one of the already defined data type and the data type is declare in some other place. For example, OBX-2 declares the data type of OBX-5, which is actual data carrier of this polymorphic data type. For ease of discussion, lets call the field that announce the data type of polymorphic data type data Data Type Announcer, and call the field that contains the actual data of the polymorphic data type Data Carrier.

The data type announcer and data carrier can coexist in the same segment; they can also exist on different segments. For example, OBX segment has OBX-2 field being the data type announcer and OBX-5 field being the data carrier. RDF segment contains a field of RCD data type, of which each instance of the RCD field acts as a data announcer for data carrier in the RDT segment. The relationship of the RDF and RDT segment is in analogues to relationship database’s table description meta-data and rows of actual data.

In the case of both data type announcer and data carrier residing in the same segment, the relative position of the announcer field and the data carrier field can also vary. Data type announcer can precede data carrier, or the other way around.

There is no fixed number of fields that sets data type announcer and data carrier apart. Their relationship is shown in the following diagram.

Delimiter and enhaced data model

The delimiters for segment, field, component, and subcomponent are all user-defined Delimiters are announced in the message header for each individual message.

A segment delimiter is defined as an ASCII carriage return or x0A. When data containing the characters identical to these delimiters, an escape sequence is used to mark the character.

Component delimiters can be demoted to subcomponent delimiters when a data type is used on anther data type’s components. The use of repetition delimiters in most data elements is contextual depending the nature of its data elements, with certain excpetions.

The repetition delimiter is used between repeating instances of data type element segment fields. The common character used is “~”. Components of data type element are generally not expected to repeat, except for MA, NA, and QIP data types.