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:
|7||26||TS||O||Date/Time of Message|
|10||20||ST||R||Message Control Id|
|12||8||ID is a coded value data type. The value of such a field follows the formatting rules for a ST field except that it is drawn from a table of legal values. Examples of ID fields include religion and sex.||R||Version Id|
|15||2||ID||O||Accept Acknowledgement Type|
|16||2||ID||O||Application Acknowledgement Type|
|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 is a Standards Developing Organization accredited by the American National Standards Institute (ANSI) to author consensus-based standards representing a board view from healthcare system stakeholders. HL7 has compiled a collection of message form... More 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:
||||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:
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.
How Corepoint Integration Engine works with HL7
The #1 Integration Engine Nine Consecutive Years
Customers have confidence in Corepoint Health’s history of focusing on healthcare interoperability, as evident by our #1 KLAS® ranking nine years in a row. Discover the power Corepoint Integration Engine offers healthcare providers of all sizes and specialties.