HL7 MSH Segment: Message Header

Every HL7 v2 message starts with MSH. It is the envelope: it names who sent the message and who it is for, stamps the creation time, declares the message type and trigger event, carries a unique control id, sets the processing mode, and pins the HL7 version. Two of its fields are structurally special - MSH-1 defines the field separator and MSH-2 defines the encoding characters - so the parser learns the delimiters from the message itself before reading anything else. If MSH is malformed, nothing else can be parsed. It is the one segment present in every HL7 v2 message.

Purpose

MSH tells the receiver who sent the message, who it is for, what kind of message it is, when it was sent, and which HL7 version to parse it as. Because MSH-1 and MSH-2 carry the delimiters, the parser reads them first and uses them for the rest of the message.

Used in

MSH is the first segment of every HL7 v2 message - ADT, ORM, ORU, MDM, SIU, DFT, ACK, MFN, BAR, and all others. See the messages index for the full list; every message page opens with MSH.

Field-by-field reference

Source: official HL7 v2-to-FHIR IG. R = required (cardinality min ≥ 1). Repeat = field may repeat. Length pending authoritative v2.5.1 data.

Most-used fields

MSH-9 Message Type is the field that decides everything downstream. ADT^A01^ADT_A01 means message code ADT, trigger event A01, abstract structure ADT_A01. The third component (structure) was added in v2.3.1; older systems send only ADT^A01.

MSH-10 Message Control ID must be unique per sender; the receiver echoes it in MSA-2 so senders can correlate ACKs to the original.

MSH-7 Date/Time of Message drives ordering and audit. MSH-11 Processing ID is a guard rail: P versus T. Routing test traffic into a production feed because this said P is a classic incident.

Version differences (2.3 to 2.8.2)

• 2.3.1: third component of MSH-9 (message structure) introduced.
• 2.4: MSH-7 and other dates standardize on the DTM/TS long form with optional fractional seconds and timezone.
• 2.5 / 2.5.1: fields MSH-21 (Message Profile Identifier) onward added; MSH grows to 21+ fields.
• 2.7+: MSH-22 through MSH-28 added (responsible orgs, network addresses, security tags). Receivers built for 2.3 simply ignore trailing fields they don't know.

Common mistakes

• Treating MSH-1 as a normal field and shifting all field numbers by one.
• Hard-coding ^~& instead of reading the actual encoding characters from MSH-2.
• Reusing a Message Control ID (MSH-10) - breaks ACK correlation and dedup.
• Sending P in MSH-11 from a test system.

Examples

Minimal valid MSH (required fields only):

MSH|^~&|||||20260609120000||ADT^A01^ADT_A01|MSG00001|P|2.5.1

Fully-populated MSH:

MSH|^~&|EPIC|HOSP_A|LAB|HOSP_B|20260609120000.000-0500||ORU^R01^ORU_R01|CTRL20260609-0001|P|2.5.1|||AL|NE|USA|UNICODE UTF-8|en^English^ISO639

Annotated breakdown of the minimal example:

MSH                 ← segment ID
|                   ← MSH-1  Field Separator
^~&                ← MSH-2  Encoding Characters
                    ← MSH-3..6 empty (sending/receiving app & facility)
20260609120000      ← MSH-7  Date/Time of Message
                    ← MSH-8  empty
ADT^A01^ADT_A01     ← MSH-9  Message Type (code^event^structure)
MSG00001            ← MSH-10 Message Control ID
P                   ← MSH-11 Processing ID (Production)
2.5.1               ← MSH-12 Version ID

In-context inside an ADT^A01 (admit):

MSH|^~&|EPIC|HOSP_A|RECV|HOSP_B|20260609120000||ADT^A01^ADT_A01|MSG00001|P|2.5.1
EVN|A01|20260609120000
PID|1||123456^^^HOSP^MR||DOE^JOHN^A||19800101|M
PV1|1|I|ICU^101^A|||||||MED

In-context inside an ORU^R01 (result):

MSH|^~&|LAB|HOSP_B|EHR|HOSP_A|20260609131500||ORU^R01^ORU_R01|CTRL-9931|P|2.5.1
PID|1||123456^^^HOSP^MR||DOE^JOHN^A||19800101|M
OBR|1||ORD123|CBC^Complete Blood Count^L
OBX|1|NM|718-7^Hemoglobin^LN||13.5|g/dL|13.0-17.0|N|||F

FHIR mapping

Target resources: MessageHeader (primary), plus Bundle, Encounter, Provenance. Official ConceptMap: ConceptMap-segment-msh-to-messageheader (JSON).

Not mapped or handled out-of-band: MSH-1, MSH-2 (delimiters - implicit in FHIR), MSH-13, MSH-14, MSH-15, MSH-16, MSH-20, MSH-28. MSH-12 (Version ID) informs parsing rather than mapping to a single FHIR element.

Engine considerations

• Parse MSH-1 and MSH-2 first. Never assume | and ^~&; read them from the message and use them for the rest of the parse.
• Required in practice: MSH-3 to MSH-6 are technically optional but virtually every real interface requires them for routing, and many engines reject messages without them.
• Escape-character pitfalls: the escape character (4th encoding char, default ) governs `F`, `S`, `R`, `T`, `E` sequences. A literal or | in data must be escaped or it corrupts field boundaries.
• Failure mode: a missing or shifted MSH-9 trigger event causes routing rules to drop or misroute the entire message.

How Vorro parses and produces MSH

Vorro reads MSH-1 and MSH-2 to seed the delimiter set, then validates MSH-9 against the configured message catalog to select the parse profile. On the produce side, Vorro stamps a unique MSH-10, sets MSH-7 to send time, and pins MSH-11 and MSH-12 per channel config so test traffic can never inherit a production processing id by accident.

Related pages

• MSA - the acknowledgement segment that echoes MSH-10.
• EVN - the event segment that follows MSH in ADT messages.
• ADT messages - where MSH-9 drives trigger-event routing.

Sources

• HL7 v2-to-FHIR IG - segment maps index
• HL7 v2-to-FHIR IG - MSH to MessageHeader ConceptMap
• HL7 Version 2.5.1 product brief