HL7 MSH Segment: Message Header
The HL7 MSH segment (Message Header) is the first segment in every HL7 v2 message. It defines the encoding characters, identifies the sending and receiving applications, specifies the message type, and carries metadata like the message control ID and HL7 version number.
MSH Field Reference
Section titled “MSH Field Reference”| Seq | Name | Type | Opt | Description |
|---|---|---|---|---|
★ MSH-1 | Field Separator | ST | R | Always the pipe character | |
★ MSH-2 | Encoding Characters | ST | R | Component, repetition, escape, sub-component |
| Nearly always ^~\& — component (^), repetition (~), escape (\), sub-component (&). Changing these is technically allowed but extremely rare in practice. | ||||
★ MSH-3 | Sending Application | HD | O | Source application name |
| Used by integration engines for message routing. Combined with MSH-4 to identify the source system. | ||||
★ MSH-4 | Sending Facility | HD | O | Source facility identifier |
| In multi-facility environments, different transformation logic may apply based on this field. | ||||
★ MSH-5 | Receiving Application | HD | O | Destination application name |
★ MSH-6 | Receiving Facility | HD | O | Destination facility identifier |
★ MSH-7 | Date/Time of Message | TS | R | Message creation timestamp |
MSH-8 | Security | ST | O | Security classification |
★ MSH-9 | Message Type | MSG | R | Message type^Trigger event^Structure |
| Three components: MSG.1 (message code, e.g., ADT), MSG.2 (trigger event, e.g., A01), MSG.3 (message structure, e.g., ADT_A01). | ||||
★ MSH-10 | Message Control ID | ST | R | Unique message identifier |
| Must be unique across all messages. Used for deduplication and ACK correlation (echoed in MSA-2). Use UUID or timestamp+sequence. | ||||
★ MSH-11 | Processing ID | PT | R | P (Production), T (Training), D (Debug) |
| Production systems should reject messages with Processing ID other than P. Integration engines use this to route to the correct environment. | ||||
★ MSH-12 | Version ID | VID | R | HL7 version (2.3, 2.5.1, etc.) |
| More indicative than contractual — many interfaces use v2.3 messaging even when this says v2.5.1. Validate against the interface spec, not this field. | ||||
MSH-13 | Sequence Number | NM | O | Message sequence number |
MSH-14 | Continuation Pointer | ST | O | Continuation of prior message |
★ MSH-15 | Accept Acknowledgment Type | ID | O | AL (Always), NE (Never), SU (Success), ER (Error) |
| Network/transport level acknowledgment. Most common configuration: AL (always send accept ACK). | ||||
★ MSH-16 | Application Acknowledgment Type | ID | O | AL, NE, SU, ER |
| Application level acknowledgment. Most common configuration: NE (never), relying on MSH-15 for transport-level ACKs only. | ||||
MSH-17 | Country Code | ID | O | ISO 3166 country code |
MSH-18 | Character Set | ID | O | Character encoding (ASCII, UTF-8) |
MSH-19 | Principal Language | CE | O | Message language |
MSH-20 | Alternate Character Set Handling | ID | O | How alternate character sets are handled |
MSH-21 | Message Profile Identifier | EI | O | Conformance profile for this message |
★ MSH-2 R Component, repetition, escape, sub-component
Nearly always ^~\& — component (^), repetition (~), escape (\), sub-component (&). Changing these is technically allowed but extremely rare in practice.
★ MSH-3 O Source application name
Used by integration engines for message routing. Combined with MSH-4 to identify the source system.
★ MSH-4 O Source facility identifier
In multi-facility environments, different transformation logic may apply based on this field.
★ MSH-9 R Message type^Trigger event^Structure
Three components: MSG.1 (message code, e.g., ADT), MSG.2 (trigger event, e.g., A01), MSG.3 (message structure, e.g., ADT_A01).
★ MSH-10 R Unique message identifier
Must be unique across all messages. Used for deduplication and ACK correlation (echoed in MSA-2). Use UUID or timestamp+sequence.
★ MSH-11 R P (Production), T (Training), D (Debug)
Production systems should reject messages with Processing ID other than P. Integration engines use this to route to the correct environment.
★ MSH-12 R HL7 version (2.3, 2.5.1, etc.)
More indicative than contractual — many interfaces use v2.3 messaging even when this says v2.5.1. Validate against the interface spec, not this field.
★ MSH-15 O AL (Always), NE (Never), SU (Success), ER (Error)
Network/transport level acknowledgment. Most common configuration: AL (always send accept ACK).
★ MSH-16 O AL, NE, SU, ER
Application level acknowledgment. Most common configuration: NE (never), relying on MSH-15 for transport-level ACKs only.
R = Required, O = Optional, C = Conditional, W = Withdrawn (backward compatibility only)
MSH-2: Encoding Characters
Section titled “MSH-2: Encoding Characters”The four encoding characters after the field separator define how the rest of the message is parsed:
MSH|^~\&|...| Position | Character | Name | Purpose |
|---|---|---|---|
| 1 | ^ | Component separator | Separates components within a field |
| 2 | ~ | Repetition separator | Separates repeated values |
| 3 | \ | Escape character | Escapes special characters in text |
| 4 | & | Sub-component separator | Separates sub-components |
These four characters are virtually always ^~\& — changing them is technically allowed by the spec but extremely rare in practice. Any receiving system should read MSH-2 dynamically rather than hardcoding the assumption.
MSH-9: Message Type
Section titled “MSH-9: Message Type”MSH-9 has up to three components identifying the message:
MSH|...|ADT^A01^ADT_A01|...| Component | Name | Example | Meaning |
|---|---|---|---|
| MSG.1 | Message Code | ADT | Message category |
| MSG.2 | Trigger Event | A01 | Specific event |
| MSG.3 | Message Structure | ADT_A01 | Abstract message definition |
Common message type values:
| MSH-9 | Description |
|---|---|
| ADT^A01 | Admit notification |
| ADT^A08 | Update patient info |
| ORM^O01 | General order |
| ORU^R01 | Unsolicited observation result |
| SIU^S12 | New appointment |
| MDM^T02 | Original document notification |
| DFT^P03 | Post detail financial transaction |
| ACK | General acknowledgment |
MSH-10: Message Control ID
Section titled “MSH-10: Message Control ID”MSH-10 is a unique identifier for the message. It serves two critical functions:
- Deduplication: Receiving systems use it to detect and reject duplicate messages
- Acknowledgment correlation: The ACK message echoes MSH-10 in MSA-2 to confirm which message is being acknowledged
Best practices:
- Generate a truly unique value (UUID, timestamp + sequence, or monotonic counter)
- Never reuse control IDs — even after system restarts
- Keep the value reasonably short (under 20 characters is common)
MSH-11: Processing ID
Section titled “MSH-11: Processing ID”| Code | Meaning | Use |
|---|---|---|
| P | Production | Live clinical data |
| T | Training | Training environment data |
| D | Debug | Development/testing data |
Production systems should reject or quarantine messages with Processing ID other than P. Integration engines typically use this field to route messages to the correct environment.
MSH-15 / MSH-16: Acknowledgment Types
Section titled “MSH-15 / MSH-16: Acknowledgment Types”HL7 v2 supports two levels of acknowledgment. See the ACK message reference for complete acknowledgment handling guidance.
- MSH-15 (Accept): Network/transport level — “I received your message and it parsed correctly”
- MSH-16 (Application): Application level — “I processed your message successfully”
| Code | Meaning |
|---|---|
| AL | Always acknowledge |
| NE | Never acknowledge |
| SU | Acknowledge on success only |
| ER | Acknowledge on error only |
The most common configuration is MSH-15 = AL and MSH-16 = NE, meaning the sender expects a transport-level ACK for every message but does not require application-level acknowledgment.
Sample MSH Segment
Section titled “Sample MSH Segment”MSH|^~\&|EPIC|MAIN_HOSP|LAB_SYS|PATHOLOGY|202603011430||ADT^A01^ADT_A01|MSG00001|P|2.5.1|||AL|NE||ASCIIField-by-Field Breakdown
Section titled “Field-by-Field Breakdown”| Field | Value | Meaning |
|---|---|---|
| MSH-1 | | | Pipe field separator |
| MSH-2 | ^~\& | Standard encoding characters |
| MSH-3 | EPIC | Sending application |
| MSH-4 | MAIN_HOSP | Sending facility |
| MSH-5 | LAB_SYS | Receiving application |
| MSH-6 | PATHOLOGY | Receiving facility |
| MSH-7 | 202603011430 | March 1, 2026 at 2:30 PM |
| MSH-8 | (empty) | No security classification |
| MSH-9 | ADT^A01^ADT_A01 | Admit notification |
| MSH-10 | MSG00001 | Message control ID |
| MSH-11 | P | Production |
| MSH-12 | 2.5.1 | HL7 version 2.5.1 |
| MSH-15 | AL | Always send accept ACK |
| MSH-16 | NE | Never send application ACK |
| MSH-18 | ASCII | Character set |
Key Implementation Considerations
Section titled “Key Implementation Considerations”MSH-3/MSH-4 for Routing
Section titled “MSH-3/MSH-4 for Routing”Integration engines use MSH-3 (Sending Application) and MSH-4 (Sending Facility) to route messages to the correct processing channel. In a multi-facility environment, the same message type from different facilities may need different transformation logic based on these fields.
Version Negotiation
Section titled “Version Negotiation”MSH-12 declares the HL7 version. In practice, many interfaces use v2.3 or v2.3.1 messaging even when the field says v2.5.1, because the actual segments and fields used are backward-compatible. The version field is more of an indication than a strict contract — always validate against the actual interface specification rather than relying solely on MSH-12.