HL7 MSH Message Header
HL7 field reference MSH fields from HL7 v2.5.1 Show fields
These are the generated fields for the version selected at the top of the page. The document stays the same, but the reference panel follows that version.
Fields
| Field | Name | Required | Repeatable | Type | Table |
|---|---|---|---|---|---|
| MSH.1 | Field Separator | Yes | No | ST | |
| MSH.2 | Encoding Characters | Yes | No | ST | |
| MSH.3 | Sending Application | No | No | HD | 0361 |
| MSH.4 | Sending Facility | No | No | HD | 0362 |
| MSH.5 | Receiving Application | No | No | HD | 0361 |
| MSH.6 | Receiving Facility | No | No | HD | 0362 |
| MSH.7 | Date/Time Of Message | Yes | No | TS | |
| MSH.8 | Security | No | No | ST | |
| MSH.9 | Message Type | Yes | No | MSG | 0076 |
| MSH.10 | Message Control ID | Yes | No | ST | |
| MSH.11 | Processing ID | Yes | No | PT | 0103 |
| MSH.12 | Version ID | Yes | No | VID | 0104 |
| MSH.13 | Sequence Number | No | No | NM | |
| MSH.14 | Continuation Pointer | No | No | ST | |
| MSH.15 | Accept Acknowledgment Type | No | No | ID | 0155 |
| MSH.16 | Application Acknowledgment Type | No | No | ID | 0155 |
| MSH.17 | Country Code | No | No | ID | 0399 |
| MSH.18 | Character Set | No | Yes | ID | 0211 |
| MSH.19 | Principal Language Of Message | No | No | CE | |
| MSH.20 | Alternate Character Set Handling Scheme | No | No | ID | 0356 |
| MSH.21 | Message Profile Identifier | No | Yes | EI | 0449 |
Every HL7 v2 message starts with MSH. It is the envelope for the whole message: encoding characters, sender, receiver, message timestamp, message type, control ID, processing mode, HL7 version, acknowledgment rules, character set, and sometimes a conformance profile.
When MSH is wrong, the receiver may not even get far enough to care about the patient, order, result, appointment, or document content. In real interfaces, MSH is where routing, duplicate detection, ACK matching, environment separation, and version-specific parsing begin.
Most production messages populate the first dozen fields and leave the trailing fields empty unless an implementation guide asks for them. Optional does not mean useless, but it does mean you should have a reason before filling a field.
A small MSH example
Open the sample in HL7 Soup Web and inspect the field split. MSH is a useful teaching segment because MSH-1 and MSH-2 define the separators that the rest of the line then uses.
MSH-1 is the field separator. In normal HL7 v2 messages this is the pipe character, |. It is unusual because the separator itself is also counted as the first field.
MSH-2 is the encoding characters field. The normal value is ^~\&, meaning component separator, repetition separator, escape character, and subcomponent separator. You can technically change these values, but in practical integration work that is a gift to nobody. Keep the defaults unless you are trapped by a very specific legacy contract.
If the receiver parses these two fields incorrectly, every later field and component may be split incorrectly. That is why MSH-1 and MSH-2 are worth checking before chasing mysterious downstream errors.
MSH-3 and MSH-4 identify the sending application and sending facility. MSH-5 and MSH-6 identify the receiving application and receiving facility. These are usually HD values, so they can carry a namespace ID and, when needed, a universal ID.
These fields drive routing and ownership. An interface engine may use them to choose a channel, transformation, facility-specific mapping, or ACK destination. Keep the names stable and agreed. A small spelling change in MSH-3 can look harmless while quietly bypassing the route a receiver expected.
Use facility values to distinguish real sending or receiving locations, not as a junk drawer for environment names. Environment is normally better expressed in MSH-11 and the transport configuration.
MSH-7 is the timestamp the sending application put on the message. It is commonly a DTM value such as 20260715123000.
Receivers often log it, display it, or use it for troubleshooting. Do not rely on it as proof that the business event happened at that exact time. A resent message, replay, queued interface, or batch process may have a message timestamp that differs from the clinical event timestamp in EVN, OBR, OBX, PV1, or another domain segment.
MSH-8 is rarely populated in the everyday interfaces most teams maintain. Older systems sometimes put a shared secret, rolling value, or local security token here, but modern integrations usually handle authentication, authorization, and transport security outside the HL7 payload.
If a receiver requires MSH-8, document the exact value, rotation rule, and failure behavior. Do not treat this field as a substitute for TLS, VPNs, authenticated APIs, certificate-based transport, or network controls.
MSH-9 tells the receiver what kind of message this is. In modern HL7 v2 it is usually a MSG value with message code, trigger event, and message structure, such as ADT^A01^ADT_A01, ORU^R01^ORU_R01, or ORM^O01^ORM_O01.
This field is the main routing switch in many engines. ADT_A01, ORU_R01, and ACK are not just labels; they imply different structures and workflows. An integration engine such as Integration Soup should make this routing explicit so a message type change does not become a quiet production surprise.
The third component matters. Older messages sometimes send only two components, like ADT^A01. Many receivers can infer the structure, but newer profiles often expect the explicit message structure as well.
MSH-10 is the sender's unique identifier for this message instance. It is the value the receiver returns in MSA-2 when it sends an ACK.
Use a value that is unique enough for the receiver's duplicate-detection and audit window. It does not have to be globally meaningful, but it does need to be stable for a resend of the same message if the receiver uses it to identify duplicates.
MSH-11 tells the receiver how the message should be treated. The first component is commonly P for production, T for training, or D for debugging. The second component can indicate processing mode, such as archive, restore from archive, or initial load.
Do not assume a receiver will protect production just because MSH-11 says T. The listener, network route, database, and receiver configuration still need to point at the right environment. MSH-11 is a useful signal, not a safety rail by itself.
Pmeans production: normal live processing.Tmeans training: only safe if the receiving route is also non-production.Dmeans debugging: use only when both sides have agreed how debug traffic is handled.P^Iis a production initial load signal: useful for migration or backfill traffic, but it should be handled separately from live deltas.
MSH-12 states the HL7 version the message claims to follow, usually with the VID datatype. Common values include 2.3.1, 2.4, 2.5.1, and later v2 releases.
Version is not just trivia. Fields, datatypes, optionality, and message structures can differ by version. If the payload says 2.5.1 but the receiver is parsing it with a 2.3.1 assumption, subtle field shifts are very possible.
MSH-13 supports sequence-number protocol behavior. Many interfaces leave it empty because they rely on transport-level delivery guarantees, application ACKs, or engine-managed queues instead.
If you use it, both systems must agree how gaps, retries, duplicates, resets, and recovery work. A sequence field with no recovery policy is mostly a support argument waiting for a bad day.
MSH-14 supports continuation, usually when a response or batch-like interaction is split across more than one message. In modern query/response work you will more often see continuation handled in segments such as DSC.
Leave it empty unless the specific message workflow says how to use it. Continuation pointers are only useful when the receiver knows exactly how to request or correlate the next piece.
MSH-15 controls accept acknowledgments and MSH-16 controls application acknowledgments. These fields are part of HL7 enhanced acknowledgment mode. They tell the receiver whether the sender wants acknowledgment at the transport/accept stage, the application-processing stage, always, only on error, only on success, or never.
The common values are compact, but the operational behavior is not. AL means always, ER means error or reject, SU means success only, and NE means never. The receiver's ACK policy must match the sender's retry policy, or you can end up with messages that were processed but retried forever, or messages that failed without anyone noticing.
For ordinary ACK content, see ACK, MSA, and ERR.
MSH-17 can identify the country of origin for the message. It is usually empty in local private feeds, but it can matter when country-specific tables, identifiers, or localization rules apply.
If you populate it, use the code set required by the implementation guide. Do not use it as a substitute for facility, assigning authority, jurisdiction, or patient country fields elsewhere in the message.
MSH-18 tells the receiver what character set is used. Many older feeds assume ASCII or a local single-byte encoding; modern systems often expect UTF-8, but the agreement still needs to be explicit.
This field becomes important when patient names, addresses, reports, or notes include accents, non-Latin scripts, or copied text from other systems. If the bytes on the wire are not the encoding the receiver expects, the data can look valid while names and narratives become damaged.
MSH-19 can carry the principal language of the message text, commonly with a coded element such as CE in older versions or CWE in newer versions.
This is about the message content, not necessarily the patient's preferred language. Patient language normally belongs in patient-demographic fields such as PID-15, depending on the profile.
MSH-20 describes how alternate character sets are handled when a message uses more than one character set. Most everyday interfaces leave this empty.
If you are using it, you are already in territory where the interface guide needs to be precise. Test with real multilingual examples, not just ASCII-only fixtures.
MSH-21 identifies the conformance profile or implementation guide the message claims to follow. It is commonly an EI value and may repeat.
This is useful when the same base message type has several local or national profiles. For example, two systems may both send ORU^R01^ORU_R01, but one is a lab result profile and another is a public health profile with different required fields. MSH-21 gives the receiver a profile-level clue before it starts validating the rest of the payload.
Only populate MSH-21 with a profile identifier the receiver understands. A random local label may make the message look more formal while adding no interoperability value.
Link and layout notes
The field reference table is generated from the selected HL7 version near the top of this page. That generated panel is the right place for field length, datatype, optionality, repeatability, and table links. The prose here stays focused on how the fields behave in real interfaces.