Components of an HL7 Message


HL7 has a message-oriented architecture. This means that the application in which an event occurs will send a message to other applications rather than serving a request.

Note: The application that issues the message is called a Sender or Sending Application, and the addressee (recipient) of the message is called a Receiver or Receiving Application.

The structure of an HL7 Version 2.x message has the following format:

Message --> Segments --> Elements


This section provides a use case of a typical HL7 ADT^A04 message. This message is sent when a new patient arrives at the hospital. The demographics of the patient are entered into a hospital information system (HIS) and then the information is communicated to all the other systems to avoid multiple entries of the patient's demographic information.

IN1||ABC123|Blue Cross Blue Shield

HL7 messages are ASCII messages, and the standard defines them to be human readable. Messages are a defined sequence of segments and/or segment groups. Each segment, group, or message set within a message, can be optional and/or repeating. Each message consists of the segments that are delimited by carriage return characters ("\r" or 0x0D).


Every line in a message is called a segment and contains information of a specific type. For example, the MSH segment contains information about the Sender and Receiver of the message, the type of the message, a time stamp, and so on. The EVN segment contains information about the type of message, for example, A04 (Register a patient). The PID segment contains demographic information about the patient such as name, ID codes, address, and so on. The PV1 segment contains information regarding the patient's stay in the hospital, such as location assigned, referring doctor, and so on. The IN1 segment contains information regarding the patient’s insurance plan.

The sample message in the previous section contains MSH, EVN, PID, PV1, and IN1 segments. There are more than 183 segments defined in Version 2.7 of the HL7 standard. An HL7 message is a combination of the segments represented in sequence. An HL7 message definition states whether each segment is mandatory or not. Segments consist of elements that may be composites. Elements are delimited by a vertical pipe (|). Each element is defined by the HL7 standard.


Elements are the building blocks of segments. Elements may be a primitive data type (string, number, and so on), or be made up of other composites. Elements cannot have a recursive reference to themselves. The components of each element are delimited by characters and the sub-components of these components themselves can be delimited using ampersand (&) characters.

Delimiter Characters

An important part of the HL7 protocol is the use of delimiter characters. The following table lists the default delimiter characters used in HL7:



0x0D -- <cr> (Carriage Return)

Marks the end of each segment

| (Vertical pipe)

Field Delimiter

^ (Caret)

Sub-Field Delimiter

& (Ampersand)

Sub-Sub-Field Delimiter

Two other important characters are the tilde character (~), which is used to separate repeating fields, and the escape character (\).

Escape Characters

Some user data may contain these special delimiter characters. For this reason, HL7 has a system for escaping them. Unlike a language like C, each character in the system has a unique escape sequence. The following table shows the escape sequences for each of the different characters:


Escape Sequence

& (Ampersand)


^ (Caret)


| (Vertical pipe)


~ (Tilde)


\ (Backward slash)


Unprintable hex characters are also escaped in the format \0xXX\, unicode characters in the format \UXXXX\, and multi-byte character sequences \MXXXXXX\ for far eastern language support.

Delimiter Redefinition

The delimiter characters can be redefined on the fly in the MSH segment of each message. Each HL7 message starts with a MSH segment. Some HL7 implementations may choose to use different delimiter characters in the message. For example:


Present but Null

When a field is absent from a message, it should mean that the system does not use that field or that the field has not changed. But what if a system supports the given field, but the value of the field is null? The HL7 protocol requires a method of making this clear. This is done by putting two double quote characters (““) together in a field like this:


Repetition and Optionality of HL7 Segments

In the message definition, each segment can be either mandatory or optional. Each message starts with an MSH segment that is always mandatory (required). Another example of a mandatory field is PID (Patient identification). Without patient identification data, messages like ADT^A04 (Register Patient) do not have any relevance. Some segments, such as AL1 (Allergies), are optional because patients may or may not have allergies. The message in the example below consists of MSH, EVN, PID, NK1 and PV1. According to the HL7 Version 2.7 definition, in an ADT^A04 message the MSH, EVN, PID and PV1 segments are required and the NK1 segment is optional. DG1, PR1 and AL1 are also optional segments that could be in this message, but are not.

HL7 is order-sensitive. Order is important to both segments and fields inside the segment.

Segments in HL7 messages can also be repeating. For example, NK1 (Next of Kin/Associated Parties) will repeat several times if a person has several next of kin relationships:

PID||0493575^^^2^ID 1|454721||DOE^JOHN
NK1||DOE^ROBERT ^^^^|CHD||(216)731-4222
PV1||O|168 ~219~C~P

A group of segments may be optional as a group and may repeat as a group. For example, ORU^R01 message has a group that contains one OBR (Observation request) and 0 to N OBX (Observation result) segments. This group is optional in the message so it may not appear at all. The message will then look like this:


On the other hand, the message may contain a number of observation groups. Then the OBR-OBX group will repeat and the message will look like this:


The first three observation results may belong to the first observation request, and the next two observation results may belong to the second observation request.

MSH PID PD1 - header and patient demographics
OBR OBX OBX OBX  - first observation group (e.g. height and weight)
OBR OBX OBX  - second observation group (e.g. lab results)

HL7 Version 2.x Backward Compatibility

HL7 2.x is designed to be backward compatible.

A good example to clarify this comes from considering a Patient ID field in a PID segment. Early versions of HL7 declare a Patient ID to be just a simple one field identifier, such as:


In more recent versions, the Patient ID has become embellished with composite data types:

|PatientID^Check Digit^Assigning Authority NameSpace&...|

Most of the time, extra fields are optional in HL7 2.x. When additional fields are not present, the trailing delimiters are not displayed.


is equivalent to:


Withdrawn Segments

In newer versions of HL7, segments can become obsolete or withdrawn. This is noted by the W data type.

These elements remain in the metadata as placeholders. Their data types have been changed to allow any legacy data to pass through transformation. The user may modify the Ebix to reintroduce validation for these elements if desired.