MSH - Message Header Segment

The MSH segment defines the intent, source, destination, and some specifics of the syntax of a message.

HL7 Attribute Table - MSH - message header segment

Seq#	Data Element Name	DataType	Usage	Vocabulary	Cardinality	Item #	Length	C.LEN	Flags
MSH
1	Field Separator	ST	R		[1..1]	00001	[1..1]
2	Encoding Characters	ST	R		[1..1]	00002	[4..5]
3	Sending Application	HD	O	0361 Application	[0..1]	00003
4	Sending Facility	HD	O	0362 Facility	[0..1]	00004
5	Receiving Application	HD	O	0361 Application	[0..1]	00005
6	Receiving Facility	HD	O	0362 Facility	[0..*]	00006
7	Date/Time of Message	DTM	R		[1..1]	00007
8	Security	ST	O		[0..1]	00008		40	#
9	Message Type	MSG	R		[1..1]	00009
10	Message Control ID	ST	R		[1..1]	00010	[1..199]	199	#
11	Processing ID	PT	R		[1..1]	00011
12	Version ID	VID	R		[1..1]	00012
13	Sequence Number	NM	O		[0..1]	00013
14	Continuation Pointer	ST	O		[0..1]	00014		180	#
15	Accept Acknowledgment Type	ID	C	0155(R) Accept/Application Acknowledgment Conditions(Required)	[0..1]	00015	[2..2]
16	Application Acknowledgment Type	ID	C	0155(R) Accept/Application Acknowledgment Conditions(Required)	[0..1]	00016	[2..2]
17	Country Code	ID	O	0399(S) Country Code(Suggested)	[0..1]	00017	[3..3]
18	Character Set	ID	O	0211(R) Alternate Character Sets(Required)	[0..*]	00692	[5..15]
19	Principal Language Of Message	CWE	O	0609	[0..1]	00693
20	Alternate Character Set Handling Scheme	ID	O	0356(R) Alternate Character Set Handling Scheme(Required)	[0..1]	01317	[3..13]
21	Message Profile Identifier	EI	O		[0..*]	01598
22	Sending Responsible Organization	XON	O		[0..1]	01823
23	Receiving Responsible Organization	XON	O		[0..1]	01824
24	Sending Network Address	HD	O		[0..1]	01825
25	Receiving Network Address	HD	O		[0..1]	01826
26	Security Classification Tag	CWE	C	0952(S) Confidentiality Classification(Suggested)	[0..1]	02429
27	Security Handling Instructions	CWE	O	0953	[0..*]	02430
28	Special Access Restriction Instructions	ST	O		[0..*]	02431

MSH-1: Field Separator (ST) 00001

Definition: This field contains the separator between the segment ID and the first real field, MSH-2 Encoding Characters. As such it serves as the separator and defines the character to be used as a separator for the rest of the message. Recommended value is | (ASCII 124).

MSH-2: Encoding Characters (ST) 00002

Definition: This field contains five characters in the following order: the component separator, repetition separator, escape character, subcomponent separator, and truncation character. Recommended values are ^~\& #(ASCII 94, 126, 92, 38, and 35, respectively). See Section 2.5.4, "Message delimiters'.

MSH-3: Sending Application (HD) 00003

Definition: This field uniquely identifies the sending application among all other applications within the network enterprise. The network enterprise consists of all those applications that participate in the exchange of HL7 messages within the enterprise. Entirely site-defined. User-defined Table 0361- Application in Chapter 2C, Code Tables, is used as the user-defined table of values for the first component.

MSH-4: Sending Facility (HD) 00004

Definition: This field further describes the sending application, MSH-3 Sending Application. With the promotion of this field to an HD data type, the usage has been broadened to include not just the sending facility but other organizational entities such as a) the organizational entity responsible for sending application; b) the responsible unit; c) a product or vendor's identifier, etc. Entirely site-defined. User-defined Table 0362 - Facility in Chapter 2C, Code Tables, is used as the HL7 identifier for the user-defined table of values for the first component.

MSH-5: Receiving Application (HD) 00005

Definition: This field uniquely identifies the receiving application among all other applications within the network enterprise. The network enterprise consists of all those applications that participate in the exchange of HL7 messages within the enterprise. Entirely site-defined User-defined Table 0361- Application in Chapter 2C, Code Tables, is used as the HL7 identifier for the user-defined table of values for the first component.

MSH-6: Receiving Facility (HD) 00006

Definition: This field identifies the receiving application among multiple identical instances of the application running on behalf of different organizations. User-defined Table 0362 - Facility in Chapter 2C, Code Tables, is used as the HL7 identifier for the user-defined table of values for the first component. Entirely site-defined.

MSH-7: Date/Time of Message (DTM) 00007

Definition: This field contains the date/time that the sending system created the message. If the time zone is specified, it will be used throughout the message as the default time zone.

Note:     This field was made required in version 2.4. Messages with versions prior to 2.4 are not required to value this field. This usage supports backward compatibility.

MSH-8: Security (ST) 00008

Definition: In some applications of HL7, this field is used to implement security features. For codified expression of security tags use MSH-26 through MSH-29.

MSH-9: Message Type (MSG) 00009

Definition: This field contains the message type, trigger event, and the message structure ID for the message.

Refer to HL7 Table 0076 - Message Type in Chapter 2C, Code Tables, for valid values for the message type code. This table contains values such as ACK, ADT, ORM, ORU etc.

Refer to HL7 Table 0003 – Event Type in Chapter 2C, Code Tables, for valid values for the trigger event. This table contains values like A01, O01, R01 etc.

Refer to HL7 Table 0354 - Message Structure in Chapter 2C, Code Tables, for valid values for the message structure. This table contains values such as ADT_A01, ORU_R01, SIU_S12, etc.

The receiving system uses this field to recognize the data segments, and possibly, the application to which to route this message. For certain queries, which could have more than a single response event type, the second component MAY, in the response message, vary to indicate the response event type. See the discussion of the display query variants in chapter 5.

MSH-10: Message Control ID (ST) 00010

Definition: This field contains a number or other identifier that uniquely identifies the message. The receiving system echoes this ID back to the sending system in the Message acknowledgment segment (MSA).

MSH-11: Processing ID (PT) 00011

Definition: This field is used to decide whether to process the message as defined in HL7 Application (level 7) Processing rules.

MSH-12: Version ID (VID) 00012

Definition: This field is matched by the receiving system to its own version to be sure the message will be interpreted correctly. Beginning with Version 2.3.1, it has two additional "internationalization" components, for use by HL7 international affiliates. The <internationalization code> is CE data type (using the ISO country codes where appropriate) which represents the HL7 affiliate. The <internal version ID> is used if the HL7 Affiliate has more than a single 'local' version associated with a single US version. The <international version ID> has a CE data type, since the table values vary for each HL7 Affiliate. Refer to HL7 Table 0104 – Version ID in Chapter 2C, Code Tables, for valid values.

MSH-13: Sequence Number (NM) 00013

Definition: A non-delete indicator value in this field implies that the sequence number protocol is in use. This numeric field is incremented by one for each subsequent value.

MSH-14: Continuation Pointer (ST) 00014

Definition: This field is used to define continuations in application-specific ways.

Only the sender of a fragmented message values this field.

MSH-15: Accept Acknowledgment Type (ID) 00015

Definition: This field identifies the conditions under which accept acknowledgments are required to be returned in response to this message. Conditionality: Either both MSH-15 and MSH-16 SHALL be populated OR both SHALL be empty.. Refer to HL7 Table 0155 - Accept/Application Acknowledgment Conditions in Chapter 2C, Code Tables, for valid values.

MSH-16: Application Acknowledgment Type (ID) 00016

Definition: This field contains the conditions under which application acknowledgments are required to be returned in response to this messageEither both MSH-15 and MSH-16 SHALL be populated OR both SHALL be empty..Required for enhanced acknowledgment mode.

Refer to HL7 Table 0155 - Accept/Application Acknowledgment Conditions in Chapter 2C, Code Tables, for valid values for MSH-15 Accept Acknowledgment Type and MSH-16 Application Acknowledgment Type.

MSH-17: Country Code (ID) 00017

Definition: This field contains the country of origin for the message. It will be used primarily to specify default elements, such as currency denominations. The values to be used are those of ISO 3166,.. The ISO 3166 table has three separate forms of the country code: HL7 specifies that the 3-character (alphabetic) form be used for the country code.

Refer to External Table 0399 - Country Code in Chapter 2C, Code Tables, for the 3-character codes as defined by ISO 3166-1.

MSH-18: Character Set (ID) 00692

Definition: This field contains the character set for the entire message. Refer to HL7 Table 0211 - Alternate Character Sets in Chapter 2C, Code Tables, for valid values.

An HL7 message uses field MSH-18 Character Set to specify the character set(s) in use. Valid values for this field are specified in HL7 Table 0211 - Alternate Character Sets. MSH-18 Character Set MAY be left blank, or MAY contain one or more values delimited by the repetition separator. If the field is left blank, the character set in use is understood to be the 7-bit ASCII set, decimal 0 through decimal 127 (hex 00 through hex 7F). This default value MAY also be explicitly specified as ASCII.

More than one character set MAY be used in a message. The first occurrence, if supplied, of the MSH-18 SHALL indicate the default encoding of the message. The second and subsequent occurrences of MSH-18-character set are used to specify additional character sets that are used.

The repetitions of this field to specify different character sets apply only to fields of the FT, ST and TX data types. See also section 2.7.3, "Escape sequences supporting multiple character sets".

Any encoding system, single-byte or multi-byte, MAY be specified as the default character encoding in MSH-18 Character Set. If the default encoding is other than 7-bit ASCII, sites SHALL document this usage in the dynamic conformance profile or other implementation agreement. This is particularly effective in promoting interoperability between nations belonging to different HL7 Affiliates, while limiting the amount of testing required to determine the encoding of a message.

By using built-in language functions for string and character manipulation, parsers and applications need not be concerned whether a single or double byte character set is in use, provided it is applied to the entire message. Using a built in function to extract the fourth CHARACTER will always yield the field separator character, regardless of coding set. On the other hand, if the parser looks at the fourth BYTE, it is then limited to single byte character sets, since the fourth byte would contain the low order 8 bits of the character S in a double-byte system.

1. if the field is not valued, the default single-byte character set (ASCII ("ISO IR6")) SHOULD be assumed. No other character sets are allowed in the message.

2. if the field repeats, but the first element is empty(I.e. unvalued), the single-byte ASCII ("ISO IR6") is assumed as the default character set.

3. elements in the remainder of the sequence (i.e., elements 2..n) are alternate character sets that MAY be used.

The reader is referred to the following references for background information on character sets and encodings:

• Unicode Technical Report #17 - Character Encoding Model (http://www.unicode.org/unicode/reports/tr17/)

• Extensible Markup Language (XML) 1.0 (Second Edition), Section F Autodetection of Character Encodings (http://www.w3.org/TR/REC-xml#sec-guessing)

The first occurrence of MSH-18 Character Set MAY reference a character set other than 7-bit ASCII. Western alphabetic languages other than English are accommodated by the ISO 8859 series of character encodings. For example, if MSH-18 Character Set is valued 8859/1, the ISO character set commonly known as "8-bit ASCII" is in use in the message. This includes all values from decimal 0 through decimal 127 (hex 00 through hex 7F), plus an additional 128 values from decimal 128 through decimal 255 (hex 80 through hex FF). The latter values include the accented Latin letters used in common Western European languages, plus some symbolic values such as the paragraph mark (¶) and the trademark symbol (™).

Other ISO character sets in the 8859 series accommodate non-Latin character sets. For example, MSH-18 Character Set could be valued 8859/2 to specify the default character encoding in use in Eastern Europe, while 8859/6 indicates the use of the Arabic alphabet.

The ASCII and ISO character sets all allow the specification of any character in a single byte.

HL7 Table 0211 includes values for languages that do not use alphabets. These include ideographic written languages, such as the Japanese Graphic Character Set which is specified as ISO IR87.

There are non-alphabetic encoding systems for which HL7 Table 0211 does not provide specific entries. One of these is the Traditional Chinese character set, CNS 11643, which is used in Taiwan. This character set can, however, be encoded using the Unicode Standard, which does have a value in HL7 0211.

The Unicode Standard (which is now coordinated with ISO 10646) permits the specification of multiple-byte characters in a much larger range than is available in a single-byte ASCII or ISO character set. Unicode Version 3.1 (http://www.unicode.org) includes almost 100,000 characters, including many Chinese, Japanese, and Korean ideographs. This is particularly valuable to implementers who need to encode messages in more than one character set, as for example to accommodate the use of both alphabetic and ideographic characters.

Non-alphabetic encoding systems do not restrict characters to a length of one byte. Unicode incorporates three encoding forms that allow for the use of multiple bytes to encode a message. The most flexible Unicode encoding form is UTF-8, which uses high-order bits to specify the number of bytes (from one to six) used to encode each character.

Interestingly, Unicode UTF-8 incorporates the 7-bit ASCII character set as single-byte codes. This means that a message encoded in 7-bit ASCII can be submitted to a destination using Unicode UTF- 8 with no modification.

MSH-19: Principal Language Of Message (CWE) 00693

Definition: This field contains the principal language of the message. Codes come from ISO 639. Refer to Table 0609 - Principal Language Of Message in Chapter 2C for valid values.

MSH-20: Alternate Character Set Handling Scheme (ID) 01317

Definition: When any alternative character sets are used (as specified in the second or later iterations of MSH-18 Character Set), and if any special handling scheme is needed, this component is to specify the scheme used, according to HL7 Table 0356- Alternate Character Set Handling Scheme as defined in Chapter 2C, Code Tables,.

MSH-21: Message Profile Identifier (EI) 01598

Definition: Sites MAY use this field to assert adherence to, or reference, a message profile. Message profiles contain detailed explanations of grammar, syntax, and usage for a particular message or set of messages. See section 2B, "Conformance Using Message Profiles".

Repetition of this field allows more flexibility in creating and naming message profiles. Using repetition, this field can identify a set of message profiles that the message conforms to. For example, the first repetition could reference a vendor's message profile. The second could reference another compatible provider's profile or a later version of the first vendor profile.

As of v2.5, the HL7 message profile identifiers might be used for conformance claims and/or publish/subscribe systems. Refer to sections 2B.1.1"Message profile identifier" and 2.B.1.2, "Message profile publish/subscribe topics" for details of the message profile identifiers. Refer to sections 2.B.4.1, "Static definition identifier" and 2.B.4.2, "Static definition publish/subscribe topics" for details of the static definition identifiers.

Prior to v2.5, the field was called Conformance Statement ID. For backward compatibility, the Conformance Statement ID can be used here. Examples of the use of Conformance Statements appear in Chapter 5, "Query."

MSH-22: Sending Responsible Organization (XON) 01823

Definition: Business organization that originated and is accountable for the content of the message.

Currently, MSH provides fields to transmit both sending/receiving applications and facilities (MSH.3 – MSH.6). However, these levels of organization do not necessarily relate to or imply a legal entity such as a business organization. As such, multiple legal entities (organizations) mightshare a service bureau, with the same application and facility identifiers. Another level of detail is required to delineate the various organizations using the same service bureau.

Therefore, the Sending Responsible Organization field provides a complete picture from the application level to the overall business level. The Business Organization represents the legal entity responsible for the contents of the message.

Use Case #1: A centralized system responsible for recording and monitoring instances of communicable diseases enforces a stringent authentication protocol with external applications that have been certified to access its information base. In order to allow message exchange, the centralized system mandates that external applications must provide the identity of the business organization sending the message (Sending Responsible Organization), the organization it is sending the message to (Receiving Responsible Organization, in this case the "owner" of the communicable diseases system), the network address from which the message has originated (Sending Network Address), the network address the message is being transmitted to (Receiving Network Address). The organization responsible for protecting the information stored within the communicable disease system requires this authentication due to the sensitive nature of the information it contains.

MSH-23: Receiving Responsible Organization (XON) 01824

Definition: Business organization that is the intended receiver of the message and is accountable for acting on the data conveyed by the transaction.

This field has the same justification as the Sending Responsible Organization except in the role of the Receiving Responsible Organization. The receiving organization has the legal responsibility to act on the information in the message.

See MSH-22 above for Use Case.

MSH-24: Sending Network Address (HD) 01825

Definition: Identifier of the network location the message was transmitted from. Identified by an OID or text string (e.g., URI). The reader is referred to the "Report from the Joint W3C/IETF URI Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations".⁷

As with the Sending/Receiving Responsible Organization, the Sending Network Address provides a more detailed picture of the source of the message. This information is lower than the application layer, but is often useful/necessary for routing and identification purposes. This field SHOULD only be populated when the underlying communication protocol does not support identification of sending network locations.

An agreement about the specific values and usage must exist among messaging partners. Use Case:

Dr. Hippocrates works for the ''Good Health Clinic" (Sending facility) with a laptop running application XYZ (Sending App). He needs to talk to the provincial pharmacy system. He dials in and is assigned a network address. He then sends a message to the pharmacy system, which transmits a response back to him. Because the underlying network protocol does not have a place to communicate the sender and receiver network addresses, it therefore requires these addresses to be present in a known position in the payload.

There might be many doctors running application XYZ. In addition, the network address assigned to the laptop might change with each dial-in. This means there is not a 1..1 association between either the facility or the application and the network address.

MSH||RX|GHC|||||OMP^O09^OMP_O09||||||||||||||||05782|

Example 1: The Lone Tree Island satellite clinic transmits a notification of patient registration to its parent organization Community Health and Hospitals. The communication protocol does not support the identification of sending network location, so the sending network location is identified in the message by using its enterprise-wide network identifier "HNO2588".

MSH||Reg|Lone|||||ADT^A04^ADT_A04||||||||||||||||HN02588|

Example 2: The Stone Mountain satellite clinic transmits a notification of patient registration to its parent organization Community Health and Hospitals. The sending network location is identified by using its URI.

MSH||Reg|Stone|||||ADT^A04^ADT_A04|||||||||||||||| ^ftp://www.goodhealth.org/somearea/someapp^URI|

Example 3: The Three Rivers satellite clinic transmits a notification of patient registration to its parent organization Community Health and Hospitals. The sending network location is identified by using its Ipv4 address, port 5123 at node 25.152.27.69. The following example shows how to represent a port and DNS address using HD as the scheme

MSH||Reg|TRC||||| ADT^A04^ADT_A04||||||||||||||||5123^25.152.27.69^DNS|

Example 4: The Bayview satellite clinic transmits a notification of patient registration to its parent organization Community Health and Hospitals. The sending network location is identified by using "4086::132:2A57:3C28" its IPv6 address.

MSH||REG|BAY||||| ADT^A04^ADT_A04||||||||||||||||^4086::132:2A57:3C28^IPv6|

MSH-25: Receiving Network Address (HD) 01826

Definition: Identifier of the network location the message was transmitted to. Identified by an OID or text string (e.g., URL).

This is analogous with the Sending Network Address, however in the receiving role.

This field SHOULD only be populated when the underlying communication protocol does not support identification receiving network locations

MSH-26: Security Classification Tag (CWE) 02429

Definition: This field defines the security classification (as defined by ISO/IEC 2382-8:1998(E/F)/ T-REC-X.812-1995) of an IT resource, in this case the message, which MAY be used to make access control decisions.

Conditionality Predicate: Required if MSH-27 or MSH-28 is valued, Optional if neither MSH-27 nor MSH-28 is valued."Use of this field supports the business requirement for declaring the level of confidentiality (classification) for a given message.

Note: This field is used to declare the ‘high watermark’, meaning the most restrictive handling that needs to be applied to the message based on its content requiring a certain security classification level and SHOULD be viewed as the v2 equivalent of the document header in CDA, in v3 models, and in FHIR Security Labels

the high water mark in the header of message content is -described in the Guide to the HL7 Healthcare Privacy and Security Classification System, Release 1, which is platform independent.

Refer to Externally-defined HL7 Table 0952 – HL7 Confidentiality Code in Chapter 2C, Code Tables, for suggested values. Use of this table is recommended. The codes in this table are comprehensive, non-overlapping hierarchical codes: Very Restricted > Restricted > Normal > Moderate > Low > Unrestricted. Restrictions to a comprehensive, non-overlapping set of codes is required for purposes of access control system algorithms such as Bell–LaPadula Mode, which is used to adjudicate access requests against privacy policies.

MSH-27: Security Handling Instructions (CWE) 02430

Definition: This field is repeatable and conveys instructions to users and receivers for secure distribution, transmission, and storage; dictate obligations or mandated actions; specify any action prohibited by refrain policy such as dissemination controls; and stipulate the permissible purpose of use of an IT resource.

Refer to Externally define HL7 Table 0953 – Security Control in Chapter 2C, Code Tables, for suggested values.

MSH-28: Special Access Restriction Instructions (ST) 02431

Definition: Used to convey specific instructions about the protection of the patient's data, which must be rendered to end users in accordance with patient consent directive, organizational policy, or jurisdictional law. For example, in US law 42 CFR Part 2, disclosed information made with patient consent must include a renderable “Prohibition on re-disclosure” warning (§ 2.32⁸) In addition, organizational policy might require that some or all of the ARV field privacy tag values be rendered to end users, e.g., marking a consult note with “Restricted Confidentiality” or with sensitivity tags such as “VIP” or “EMP” for employee of the organization.

This field MAY also be used to specify instructions about the release of information to family and friends (e.g., "Do not release information to patient's brother, Adam Everyman"). These instructions MAY be in conjunction with other fields (as elected by the system).