Segment MSH to MessageHeader Map - HL7 Version 2 to FHIR v1.0.0

HL7 Version 2 to FHIR
1.0.0 - STU 1 International flag

HL7 Version 2 to FHIR, published by HL7 International / Orders and Observations. This guide is not an authorized publication; it is the continuous build for version 1.0.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/v2-to-fhir/ and changes regularly. See the Directory of published versions

ConceptMap: Segment MSH to MessageHeader Map (Experimental)

Official URL: http://hl7.org/fhir/uv/v2mappings/ConceptMap/segment-msh-to-messageheader				Version: 1.0.0
Standards status: Informative				Computable Name: SegmentMSHToMessageHeader
Copyright/Legal: Copyright (c) 2025, HL7 International, Inc., All Rights Reserved.

This ConceptMap represents a mapping from the HL7 V2 Segment MSH to the FHIR MessageHeader Resource.

This ConceptMap represents the mapping from the HL7 V2 MSH Segment to the FHIR MessageHeader Resource. See also the FHIR Shorthand or the CSV Source.

HL7 v2						Condition (IF True, args)			HL7 FHIR								Comments
Sort Order	Identifier	Name	Data Type	Cardinality - Min	Cardinality - Max	Computable ANTLR	Computable FHIRPath	Narrative	FHIR Attribute	Extension	Data Type	Cardinality - Min	Cardinality - Max	Data Type Mapping	Vocabulary Mapping (IS, ID, CE, CEN, CWE)	Assignment	Comments
1	MSH-1	Field Separator	ST	1	1												Field separators are not used in FHIR.
2	MSH-2	Encoding Characters	ST	1	1												Encoding characters are not used in FHIR.
3	MSH-3	Sending Application	HD	0	1				MessageHeader.source			1	1	HD[MessageHeader.source-name]
3	MSH-3	Sending Application	HD	0	1	IF MSH-24 NOT VALUED			MessageHeader.source.endpoint		uri	1	1	HD[MessageHeader.source-endpoint]			We believe that if MSH-24 is vaued, although MSH-24 is rarely valued, it contains better information for the MessageHeader.source.endpoint than MSH-3. However, one may either still want to use MSH-3 in total or a combination of content from MSH-3 and MSH-24. That is a local implementation decision to adjust the mapping accordingly based on clear knowledge of the content. If both MSH-3 and MSH-24 are not valued, which is valid in HL7 v2, then the implementer needs to resolve how to assign MessageHeader.source as it is a required attribute. Note that a data absent reason extension could be used to provide a reason and satisfy the mandatory FHIR attribute rules. But do note that the use of the data-absent-reason extension may result in a FHIR resource that is not usable by the recipient.
4	MSH-4	Sending Facility	HD	0	1				MessageHeader.sender(MessageHeader.Organization)		Reference(MessageHeader.Organization)	0	1	HD[Organization]
5	MSH-5	Receiving Application	HD	0	1				MessageHeader.destination.target(MessageHeader.Device)		Reference(MessageHeader.Device)	0	1	HD[Device]			Similar as for MSH-3, MSH-5 is paired with MSH-25 and depending on local use may need to use one, the other, or a combination of both. We believe that MSH-25, when valued, provides the better information given its addition to the standard more recently.
5	MSH-5	Receiving Application	HD	0	1	IF MSH-25 VALUED			MessageHeader.destination.name		MessageHeader.name			HD[MessageHeader.destination-name]
5	MSH-5	Receiving Application	HD	0	1	IF MSH-25 NOT VALUED			MessageHeader.destination.endpoint		url			HD[MessageHeader.destination-endpoint]
6	MSH-6	Receiving Facility	HD	0	-1	IF MSH-23 NOT VALUED			MessageHeader.destination.receiver(MessageHeader.Organization)		Reference(MessageHeader.Organization)	0	1	HD[Organization]
7	MSH-7	Date/Time of Message	DTM	1	1												If a message is always conveyed in a Bundle, then Bundle.timestamp could work. However, Bundle.timestamp may be better used to reflect the conversion. See https://chat.fhir.org/#narrow/stream/179188-v2-to.20FHIR/topic/MessageHeader.2Etimestamp for a discussion on this topic.
7	MSH-7	Date/Time of Message	DTM	1	1
8	MSH-8	Security	ST	0	1				meta.security		string	0	-1
9	MSH-9	Message Type	MSG	1	1				MessageHeader.eventCoding		Coding	0	1	MSG[Coding]
10	MSH-10	Message Control ID	ST	1	1												Need a gForge to request a MessageHeader.identifier (https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=20704&start=0) Note that if a message is part of a batch, then the MSH goes to a "sub-bundle".. Note that as messages switch from V2 to FHIR and the response back from FHIR to V2, the "mapping engine" needs to track the actual MSH.10.00.00 value and Bundle.identifier value to connect responses correctly.
11	MSH-11	Processing ID	PT	1	1				Meta		Meta	0	-1	PT[Meta]
12	MSH-12	Version ID	VID	1	1												We agreed that the version of the v2 message that was used to transform into FHIR is addressed through Provenance. Either the Provenance instance representing the original message can include in Provenance.entity.what a binary of the total original message, or the proposed MessageHeader.identifier containing MSH-10 provides the link to the original message.
13	MSH-13	Sequence Number	NM	0	1
14	MSH-14	Continuation Pointer	ST	0	1												There is no continuation pointer concept in FHIR. When a continuation is used, the mapper needs to continue to obtain the additional data that is defined in the mappings.
15	MSH-15	Accept Acknowledgment Type	ID	0	1												This field is not mapped as there is no continuation of a system level acknowledgement request beyond the mapping engine. Any subsequent acknowledgement methods would be performed in the applicable subsequent transport methods.
16	MSH-16	Application Acknowledgment Type	ID	0	1												Interacting with the recipient on what type/level or validation is asked to be reported and it is not yet clear what the appropriate mechanism is, e.g., using interactions using Task (as it is more application level interactions) and/or HTTP header and/or other mechanisms. Note that the MSH-16 values are typically pre-determined through an implementation guide. Until then we encourage implementers to share feedback on how they are planning to address this that we can consider for inclusion
17	MSH-17	Country Code	ID	0	1				MessageHeader.sender(MessageHeader.Organization.address.country)		string	0	1		CountryCode
18	MSH-18	Character Set	ID	0	-1					extension??-characterSet
19	MSH-19	Principal Language Of Message	CWE	0	1				MessageHeader.language		code	0	1	CWE[Code]	PrincipalLanguageOfMessage		This does only cover the MessageHeader resource. Need to have clarity that if other resources that are part of the message that do not have Resource.meta.language valued, then it is assumed to follow MessageHeader.meta.language?? Doesn't seem RESTful, so what is the default for Resource.meta.language?
20	MSH-20	Alternate Character Set Handling Scheme	ID	0	1
21	MSH-21	Message Profile Identifier	EI	0	-1					extension??-v2ProfileID.uri	uri	0	1				Need to support multiple profiles. Also, comment on implicitRules is highly idealistic.
21	MSH-21	Message Profile Identifier	EI	0	-1					extension??-v2ProfileID.valueString	string	1	1
22	MSH-22	Sending Responsible Organization	XON	0	1				MessageHeader.responsible(MessageHeader.Organization)		Reference(MessageHeader.Organization)	0	1	XON[Organization]
23	MSH-23	Receiving Responsible Organization	XON	0	1				MessageHeader.destination.receiver(MessageHeader.Organization)		Reference(MessageHeader.Organization)	0	-1	XON[Organization]			This is an alternate representation of MSH-6. The local implementation needs to determine whech components of HD vs. XON to be used and whether it may even yield a separate Organization reference.
24	MSH-24	Sending Network Address	HD	0	1				MessageHeader.source		string	0	1	HD[MessageHeader.source-endpoint]			We believe that if MSH-24 is vaued, although it is rarely valued, it contains better information for the MessageHeader.source.endpoint. However, one may either still want to use MSH-3 in total or a combination of content from MSH-3 and MSH-24. That is a local implementation decision to adjust the mapping accordingly.
24	MSH-24	Sending Network Address	HD	0	1	IF MSH-24 NOT VALUED AND MSH-3 NOT VALUED			MessageHeader.source.endpoint.extension.url		uri	0	1			"http://hl7.org/fhir/R4/extension-data-absent-reason.html"
24	MSH-24	Sending Network Address	HD	0	1	IF MSH-24 NOT VALUED AND MSH-3 NOT VALUED			MessageHeader.source.endpoint.extension.valueCode		code	0	1			"unknown"	If both MSH-3 and MSH-24 are not valued, which is valid, then the implementer needs to resolve whether to assign this a known value since they know the context, or add the data absent reason extension to provide a reason and satisfies the mandatory FHIR attribute rules. Note that the use of the data-absent-reason extension may result in a FHIR resource that is not usable by the recipient.
25	MSH-25	Receiving Network Address	HD	0	1				MessageHeader.destination		uri	0	-1	HD[MessageHeader.destination-endpoint]			We believe that if MSH-25 is vaued, although it is rarely valued, it contains better information for the MessageHeader.source.endpoint. However, one may either still want to use MSH-5 in total or a combination of content from MSH-5 and MSH-25. That is a local implementation decision to adjust the mapping accordingly.
25	MSH-25	Receiving Network Address	HD	0	1	IF MSH-25 NOT VALUED AND MSH-5 NOT VALUED			MessageHeader.destination.endpoint.extension.url		uri	0	-1			"http://hl7.org/fhir/R4/extension-data-absent-reason.html"
25	MSH-25	Receiving Network Address	HD	0	1	IF MSH-25 NOT VALUED AND MSH-5 NOT VALUED			MessageHeader.destination.endpoint.extension.valueCode		code	0	-1			"unknown"
26	MSH-26	Security Classification Tag	CWE	0	1				meta.security		Coding	0	-1	CWE[Coding]	ConfidentialityClassification
27	MSH-27	Security Handling Instructions	CWE	0	-1				meta.security		Coding	0	-1	CWE[Coding]	SecurityLabelHandlingInstructions
28	MSH-28	Special Access Restriction Instructions	ST	0	-1

Mapping from (not specified) to (not specified)

Group 1 Mapping from unspecified code system to unspecified code system

Source Concept Details

Relationship

Target Concept Details

Comment

Codes from

ComputableANTLR

Codes from

MSH-3

Sending Application

is equivalent to

source[1]

MSH-3

Sending Application

IF MSH-24 NOT VALUED

is equivalent to

source[1].endpoint

We believe that if MSH-24 is vaued, although MSH-24 is rarely valued, it contains better information for the MessageHeader.source.endpoint than MSH-3. However, one may either still want to use MSH-3 in total or a combination of content from MSH-3 and MSH-24. That is a local implementation decision to adjust the mapping accordingly based on clear knowledge of the content. If both MSH-3 and MSH-24 are not valued, which is valid in HL7 v2, then the implementer needs to resolve how to assign MessageHeader.source as it is a required attribute. Note that a data absent reason extension could be used to provide a reason and satisfy the mandatory FHIR attribute rules. But do note that the use of the data-absent-reason extension may result in a FHIR resource that is not usable by the recipient.\

MSH-4

Sending Facility

is equivalent to

sender(Organization)

MSH-5

Receiving Application

is equivalent to

destination[1].target(Device)

Similar as for MSH-3, MSH-5 is paired with MSH-25 and depending on local use may need to use one, the other, or a combination of both. We believe that MSH-25, when valued, provides the better information given its addition to the standard more recently.

MSH-5

Receiving Application

IF MSH-25 VALUED

is equivalent to

destination[1].name

MSH-5

Receiving Application

IF MSH-25 NOT VALUED

is equivalent to

destination[1].endpoint

MSH-6

Receiving Facility