Message --> Segments --> Composites --> Other composites or primitive data types.

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|EPICADT|SMS|SMSADT|199912271408|CHARRIS|ADT^A04|1817457|D|2.3
EVN|A04|199912271408|||CHARRIS
PID||0493575^^^2^ID1|454721||DOE^JOHN^^^^|DOE^JOHN^^^^|19480203M||B|254E2
38ST^^EUCLID^OH^44123^USA|| (216)7... |||M|NON|400003403~1129086|999-
NK1||CONROY^MARI^^^^|SPO|| (216) 731-4359 ||EC
PV1||O|168~219~C~PMA^^^^^^^^^||||277^ALLENFADZL^BONNIE^^^^||2688684||||||
|||||||||||||||||||199912271408||||||002376853

HL7 messages are ASCII messages, and the standard requires that they 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. Each segment has its own semantic purpose. This means that it contains information of a specific type. For example, MSH segment contains information about the Sender and Receiver of the message, the type of the message, a time stamp, and so on. EVN contains information about the type of message, for example, A04 (Register a patient). PID contains demographic information about the patient such as name, ID codes, address, and so on. PV1 contains information regarding the patient's stay in the hospital, such as location assigned, referring doctor, and so on.

The sample message in the previous section contains MSH, EVN, PID, NK1 and PV1 segments. There are more than 120 segments defined in Version 2.3 of the standard. Any typical message is a combination of the segments represented in sequence.Thus, segments are the units that comprise a message. A segment is defined as a sequence of fields that also may or may not repeat. An HL7 message definition also states whether each segment is mandatory or not. Segments consist of fields that are composites. Composites are delimited by a vertical pipe (|). Each field has its own unique purpose and is defined by the HL7 standard for each segment.

In order to be flexible and achieve a consensus, the HL7 committees define many optional fields. However, as a result, you cannot be certain that particular information will be present in a given message. This is the reason why the same message may vary significantly from vendor to vendor.

x

Composites are the building blocks of segments. Composites may be a primitive data type (string, number, and so on), or be made up of other composites. Composites cannot have a recursive reference to themselves. The components of each composite are separated 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 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 like the following:

'''MSH|^~\&|...^...|'''

Some HL7 implementations may choose to use different delimiter characters in the message. For example:

MSH$%#!($...%...$

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:

OBR|||||""||||

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 above consists of MSH, EVN, PID, NK1 and PV1. According to the HL7 (version 2.2) 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|EPICADT|SMS|SMSADT|199912271408|CHARRIS|ADT^A04|1817457|D|2.3|
EVN|A04|199912271408|||CHARRIS
PID||0493575^^^2^ID 1|454721||DOE^JOHN^^^^|DOE^JOHN^^^^|19480203|M||B|254 E238ST^^EUCLID^OH^44123^USA||              (216)7...       |||M|NON|400003403~1129086|999-|
NK1||CONROY^MARI^^^^|SPO||              (216)731-4359       ||EC|||||||||||||||||||||||||||
NK1||DOE^JOHN ^^^^|SPO||              (216)731-4222       ||EC|||||||||||||||||||||||||||
NK1||DOE^ROBERT ^^^^|SPO||              (216)731-4222       ||EC|||||||||||||||||||||||||||
PV1||O|168   ~219~C~PMA^^^^^^^^^||||277^ALLEN FADZL^BONNIE^^^^|||||||||| ||2688684|||||||||||||||||||||||||199912271408||||||002376853

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

There is a proprietary message structure where you are free to define your our structure. Since HL7 messages can be customized, the HL7 committee provides a framework for the addition of custom information into HL7 messages.

You may define a custom segment by yourself and include it in any HL7 message. These segments should be named starting with letter Z, for example, ZPD for custom patient demographics information. For more information, see Defining a Z Segment.

x

To date, the HL7 committee has released 7 versions of the 2.x HL7 standard: 2.1, 2.2, 2.3, 2.3.1, 2.4, 2.5, and 2.6. Each version should be a backwardly compatible increment of the previous one.

x

HL7 2.x is designed to be backward compatible. This means that fields are only added to HL7 2.x, and never removed. For example, an HL7 Ebix for Version 2.5 can also be used for Version 2.3.

A good example to clarify this comes from considering a Patient ID field in a PID segment. Early versions of HL7 declares 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. Where additional fields are not present, the trailing delimiters do not need to be displayed.

|234324^^^|

is equivalent to:

|234324|