HL7 MSH – Message Header

The HL7 MSH (Message Header) segment is present in every HL7 message type and defines the message’s source, purpose, destination, and certain syntax specifics like delimiters (separator characters) and character sets. It is always the first segment in the HL7 message, with the only exception being HL7 batch messages.

There are 19 fields in the MSH segment, six of which (field separator, encoding characters, message type, message control ID, processing ID, and version ID) are required for all messages processed using the HL7 standard. The most important of the MSH fields, and perhaps the most important field in the entire message, is the MSH-9 (Message Type) field. This field specifies what type of message is being transmitted (ADT, ORM, ORU, ACK, etc.) and what the trigger event is. When a message is loaded, often the first field examined in order to determine processing is the value in this field.

The fields in the MSH segment are as follows:

SEQ LEN DT OPT RP/# ELEMENT NAME
1 1 ST R   Field Separator
2 4 ST R   Encoding Characters
3 180 HD O   Sending Application
4 180 HD O   Sending Facility
5 180 HD O   Receiving Application
6 180 HD O   Receiving Facility
7 26 TS O   Date/Time of Message
8 40 ST O   Security
9 7 CM_MSG R   Message Type
10 20 ST R   Message Control Id
11 3 PT R   Processing Id
12 8 ID R   Version Id
13 15 NM O   Sequence Number
14 180 ST O   Continuation Pointer
15 2 ID O   Accept Acknowledgement Type
16 2 ID O   Application Acknowledgement Type
17 2 ID O   Country Code
18 6 ID O   Character Set
19 3 CE O   Principal Language of Message

*Note: For the complete HL7 Standard, please go to the HL7 organization website.

The first two fields in the MSH segment define the separator characters to be used throughout the message. The MSH-1 field defines the field separator, and the MSH-2 field defines the other separator characters for the message in this order: component, field repeat, escape character, subcomponent.

The HL7 standard requires that a carriage return (ASCII 13 or HEX 0D) be used as the segment separator, so this value cannot be changed. However the HL7 recommended values for the other separator characters include the following:

CHARACTER NAME PURPOSE
| Field separator (pipe) Separates fields in a message
^ Component separator (hat) Separates components in a field
~ Field repeat separator Separates repeated fields in a segment
\ Escape character Used to signal special characters in a field of text (i.e. \H\ = start highlighting; \F\ = component separator)
& Sub-component separator Separates components within components (see Data Types)

The values in the chart are recommended values – and are generally utilized by most systems – but you may elect to use different separator characters in your message if you choose (with the exception of the segment separator). If you do elect to use other separator characters, the chosen values must be specified in the MSH-2 segment for the message.

The beginning of an HL7 message using the recommended values looks like this:


MSH|^~\&|…

The other required MSH fields are described below:

  • MSH-9 (Message Type) – the type of message and trigger event
  • MSH-10 (Message Control ID) – a number or other unique identifier for the message.
  • MSH-11 (Processing ID) – specifies the HL7 processing ID or processing mode; HL7 processing IDs include D (debugging), P (production), T (training); HL7 processing modes include A (archive), R (restore from archive), I (initial load), not present (default value, means "current processing")
  • MSH-12 (Version ID) – the HL7 version used in the message (i.e. 2.1, 2.3, 3.0, etc.); allows the receiving system to select the appropriate HL7 version to interpret the message.

Non-conformance to the MSH segment

Not all systems will send messages with MSH segments that conform to the HL7 requirements described above. For instance, the messages may not include a Message ID or Version ID, or they may include additional fields of information that are not specified in the HL7 standard. For this reason, it is important that your system be able to anticipate non-conformant messages and know how to process these messages in an effective manner.