HL7 Version 2 to FHIR
1.0.0 - STU 1

HL7 Version 2 to FHIR - Downloaded Version 1.0.0 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
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] | source[1] |
MSH-3 | Sending Application | IF MSH-24 NOT VALUED | is equivalent to | source[1].endpoint | 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) | sender(Organization) |
MSH-5 | Receiving Application |  | is equivalent to | destination[1].target(Device) | 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 | destination[1].name |
MSH-5 | Receiving Application | IF MSH-25 NOT VALUED | is equivalent to | destination[1].endpoint | destination[1].endpoint |
MSH-6 | Receiving Facility | IF MSH-23 NOT VALUED | is equivalent to | destination[1].receiver(Organization) | destination[1].receiver(Organization) |
MSH-8 | Security |  | is equivalent to | meta.security | meta.security |
MSH-9 | Message Type |  | is equivalent to | eventCoding | eventCoding |
MSH-11 | Processing ID |  | is equivalent to | meta | meta |
MSH-17 | Country Code |  | is equivalent to | sender(Organization.address.country) | sender(Organization.address.country) |
MSH-19 | Principal Language Of Message |  | is equivalent to | language | language | 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?
MSH-22 | Sending Responsible Organization |  | is equivalent to | responsible(Organization) | responsible(Organization) |
MSH-23 | Receiving Responsible Organization |  | is equivalent to | destination[1].receiver(Organization) | destination[1].receiver(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.
MSH-24 | Sending Network Address |  | is equivalent to | source | source | 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.
MSH-24 | Sending Network Address | IF MSH-24 NOT VALUED AND MSH-3 NOT VALUED | is equivalent to | source.endpoint.extension.url | source.endpoint.extension.url |
MSH-24 | Sending Network Address | IF MSH-24 NOT VALUED AND MSH-3 NOT VALUED | is equivalent to | source.endpoint.extension.valueCode | source.endpoint.extension.valueCode | 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.
MSH-25 | Receiving Network Address |  | is equivalent to | destination[1] | destination[1] | 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.
MSH-25 | Receiving Network Address | IF MSH-25 NOT VALUED AND MSH-5 NOT VALUED | is equivalent to | destination[1].endpoint.extension.url | destination[1].endpoint.extension.url |
MSH-25 | Receiving Network Address | IF MSH-25 NOT VALUED AND MSH-5 NOT VALUED | is equivalent to | destination[1].endpoint.extension.valueCode | destination[1].endpoint.extension.valueCode |
MSH-26 | Security Classification Tag |  | is equivalent to | meta.security[2] | meta.security[2] |
MSH-27 | Security Handling Instructions |  | is equivalent to | meta.security[2] | meta.security[2] |

### Notes: