Message --> Segments --> Elements

x

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.

MSH|^~\&|EPIC||SMS||201501011408||ADT^A04|9000123|D|2.7
EVN|A04|201501011408
PID||0493575^^^2^ID1|454721||DOE^JOHN
PV1||O|168~219~C|R
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).

x

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.

x

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.

x

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

Character	Purpose
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 (\).

x

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:

Character	Escape Sequence
& (Ampersand)	\T\
^ (Caret)	\S\
| (Vertical pipe)	\F\
~ (Tilde)	\R\
\ (Backward slash)	\E\

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.

x

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:

MSH$^~\&$EPIC$$SMS$$201501011408$$ADT^A04$9000123$D$2.7

MSH|^~\&|EPIC||SMS||201501011408||ADT^A04|9000123|D|2.7

x

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:

ZBR|||||""||||

x

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:

MSH|^~\&|EPIC||SMS|SMSDT|201501011408||ADT^A04|9000123|D|2.7|
EVN|A04|201501011408
PID||0493575^^^2^ID 1|454721||DOE^JOHN
NK1||CONROY^MARI|SPO||(216)731-4359
NK1||DOE^JOHNNY^^^^|CHD||(216)731-4222
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:

MSH PID PD1

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:

MSH PID PD1 OBR OBX OBX OBX OBR OBX OBX

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)

x

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:

|PatientID|

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.

|234324^^^|

is equivalent to:

|234324|

x

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.