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-ballot 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
Official URL: http://hl7.org/fhir/uv/v2mappings/message-adt-a06-to-bundle | Version: 1.0.0-ballot | |||
Active as of 2024-10-30 | Computable Name: MessageADT_A06ToBundle | |||
Copyright/Legal: Copyright (c) 2020, HL7 International, Inc., All Rights Reserved. |
This ConceptMap represents a mapping from the HL7 V2 Message ADT_A06 to the FHIR Message Bundle.
This ConceptMap represents the mapping from the HL7 V2 ADT_A06 Message to the FHIR Message Bundle. See also the FHIR Shorthand or the CSV Source.
HL7 v2 | Condition (IF True, args) | HL7 FHIR | Comments | |||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
Sort Order | Identifier | Syntax | Name | Cardinality - Min | Cardinality - Max | Computable ANTLR | Computable FHIRPath | Narrative | Primary Target | Segment Map | References | |
1 | ADT_A06.MSH | MSH | Message Header | 1 | 1 | Bundle | MSH[Bundle] | |||||
1 | ADT_A06.MSH | MSH | Message Header | 1 | 1 | MessageHeader | MSH[MessageHeader] | Processing of the MSH segment results in the creation of a new MessageHeader resource. | ||||
1 | ADT_A06.MSH | MSH | Message Header | 1 | 1 | If there is a source in MSH-4, or known based on the configuration. | Provenance | MSH[Provenance-Source] | Provenance[1].target.reference=Bundle.id; Provenance[1].target.reference=MessageHeader[1].id | If the FHIR transformation does not yield a FHIR message, but only a set of resource (APIs, repository, etc.) than one should consider attaching this Provenance resource instance to the relevant FHIR resources generated. | ||
1 | ADT_A06.MSH | MSH | Message Header | 1 | 1 | Provenance | MSH[Provenance-Transformation] | Provenance[2].target.reference=Bundle.id | If the FHIR transformation does not yield a FHIR Bunlde, but only a set of resource (APIs, repository, etc.) than one should consider attaching this Provenance resource instance to the relevant FHIR resources generated. | |||
2 | ADT_A06.ARV | [{ ARV }] | Access Restrictions | 0 | -1 | |||||||
3 | ADT_A06.SFT | [{ SFT }] | Software Segment | 0 | -1 | If the software does represent not the original source system | Provenance.entity.what(Device) | SFT[Device] | Provenance[1].entity.what.reference=Device.id Provenance[1].entity.role="derivation" | |||
3 | ADT_A06.SFT | [{ SFT }] | Software Segment | 0 | -1 | If the software represents the original source system | Provenance.entity.what(Device) | SFT[Device] | Provenance[1].entity.what.reference=Device.id Provenance[1].entity.role="source" | |||
4 | ADT_A06.UAC | [ UAC ] | User Authentication Credential | 0 | 1 | |||||||
5 | ADT_A06.EVN | EVN | Event Type | 1 | 1 | Provenance | EVN[Provenance] | Provenance[3].target.reference=MessageHeader[1].id | ||||
5 | ADT_A06.EVN | EVN | Event Type | 1 | 1 | IF EVN-5 NOT VALUED AND (MSH-22 IS VALUED OR MSH-4 IS VALUED) | Provenance | MSH[Provenance-Operator] | Provenance[3].target.reference=MessageHeader[1].id | If EVN-5 is not valued, then the MSH may have either the sending responsible organization (MSH-22) or the sending facility (MSH-4) to reasonable approximate the agent relevant for this Provenance instance. | ||
6 | ADT_A06.PID | PID | Patient Identification | 1 | 1 | Patient | PID[Patient] | Processing of the PID segment results in the creation of a new Patient resource | ||||
6 | ADT_A06.PID | PID | Patient Identification | 1 | 1 | Account | PID[Account] | Account[1].subject.reference=Patient[1].id | ||||
6 | ADT_A06.PID | PID | Patient Identification | 1 | 1 | IF PID-33 AND PID-34 VALUED | One may drop PID-33 from the condition if PID-34 Last Update Facility is still sufficient without a date. | Provenance | PID[Provenance-Patient] | Provenance[4].target.reference=Patient[1].id | ||
7 | ADT_A06.PD1 | [ PD1 ] | Additional Demographics | 0 | 1 | Patient | PD1[Patient] | Incorporate PD1 content into the Patient created from the PID segment. | ||||
7 | ADT_A01.PD1 | [ PD1 ] | Additional Demographics | 0 | 1 | IF PD1-7 VALUED | Observation | PD1[Observation-LivingWill] | Observation[1].subject.reference=Patient[1].id | |||
8 | ADT_A06.OH1 | [{ OH1 }] | Employment Status | 0 | -1 | |||||||
9 | ADT_A06.OH2 | [{ OH2 }] | Past or Present Job | 0 | -1 | |||||||
10 | ADT_A06.OH3 | [ OH3 ] | Usual Work | 0 | 1 | |||||||
11 | ADT_A06.OH4 | [{ OH4 }] | Combat Zone Work | 0 | -1 | |||||||
12 | ADT_A06:follow:PID.ARV | [{ ARV }] | Access Restrictions | 0 | -1 | FHIR does not yet support field level security tags. The ARV, when located with the PID/PD1 in the v2 message, is meant to only apply to the patient. However, technically it could point to other places in the messageas as well. That is considered out of scope as. | ||||||
13 | ADT_A06:follow:PID.ROL | [{ ROL }] | Role | 0 | -1 | IF ROL-3.1 EQUALS "PP" AND ROL-3.3 EQUALS "HL70443" | (element("3.1")="PP")and(element("3.3")="HL70443") | Patient | ROL[Patient-GeneralPractitioner] | |||
13 | ADT_A06:follow:PID.ROL | [{ ROL }] | Role | 0 | -1 | IF ROL-3.3 EQUALS "HL70443" AND ROL-3.1 IS NOT "PP" | (element("3.1")!="PP")or(element("3.3")!="HL70443") | When the ROL includes entries with roles in Table HL70443 other than "PP", then they may be candidates for CareTeam, but not all. That is implementation specific. | CareTeam | ROL[CareTeam] | CareTeam[1].subject.reference=Patient[1].id | |
14 | ADT_A06:follow:PID.PRT | [{ PRT }] | Participation | 0 | -1 | IF PRT-4 IS "PP" | Patient | PRT[Patient-GeneralPractitioner-Practitioner] | ||||
14 | ADT_A06:follow:PID.PRT | [{ PRT }] | Participation | 0 | -1 | IF PRT-4 IS IN ("AD", "AP", "ARI", "AT", "CP", "FHCP", "OP", "PH", "PP", "PRI", "RP", "RT", "VP", "PO") | CareTeam | PRT[CareTeam] | CareTeam[1].subject.reference=Patient[1].id | |||
15 | ADT_A06.MRG | [ MRG ] | Merge Information | 0 | 1 | Account | MRG[Account] | Account[2].subject.reference=Patient[1].id | It will be left to implementation negotiation to determine whether disparate systems merely change the patient class, or close and open a new account. The current active account number should appear in field PID-18 - Patient Account Number; the prior account number can be included optionally in MRG-3 - Prior Patient Account Number. Depending on the relationship between the old and new account, the implementer should consider whether Account.partOf should be used as well to link the two accounts appropriately. | |||
16 | ADT_A06.NEXT_OF_KIN | [{ | --- NEXT_OF_KIN begin | 0 | -1 | |||||||
16.1 | ADT_A06.NEXT_OF_KIN.NK1 | NK1 | Next of Kin / Associated Parties | 1 | 1 | RelatedPerson | NK1[RelatedPerson] | RelatedPerson[2].patient.reference=Patient[1].id | Typically, each NK1 will be translated to either a new RelatedPerson resource or added as a new occurrence of Patient.contact, but it's possible to insert the NK1 data into both structures. | |||
16.1 | ADT_A06.NEXT_OF_KIN.NK1 | NK1 | Next of Kin / Associated Parties | 1 | 1 | Patient | NK1[Patient] | |||||
16.2 | ADT_A06.NEXT_OF_KIN.OH2 | [{ OH2 }] | Past or Present Job | 0 | -1 | |||||||
16.2 | ADT_A06.NEXT_OF_KIN.OH3 | [ OH3 ] | Usual Work | 0 | 1 | |||||||
16.3 | /ADT_A06.NEXT_OF_KIN | }] | --- NEXT_OF_KIN end | |||||||||
17 | ADT_A06.PV1 | PV1 | Patient Visit | 1 | 1 | Encounter | PV1[Encounter] | Encounter[1].subject.reference=Patient[1].id | Processing of the PV1 segment results in the creation of a new Encounter resource. Note also that per A06 and A07 trigger event definitions PV1-19 - Visit Number may also be changed during this event. | |||
17 | ADT_A06.PV1 | PV1 | Patient Visit | 1 | 1 | IF PV1-43 VALUED | EncounterHistory | PV1[EncounterHistory] | EncounterHistory.subject.reference=Patient[1].id | |||
17 | ADT_A06.PV1 | PV1 | Patient Visit | 1 | 1 | Patient | PV1[Patient] | |||||
17 | ADT_A06.PV1 | PV1 | Patient Visit | 1 | 1 | IF PV1-20 VALUE | Coverage | PV1[Coverage] | Coverage.beneficiary.reference=Patient[1].id | |||
18 | ADT_A06.PV2 | [ PV2 ] | Patient Visit - Additional Info. | 0 | 1 | Encounter | PV2[Encounter] | Incorporate PV2 content into the Encounter created from the PV1 segment. | ||||
19 | ADT_A06:follow:PV1.ARV | [{ ARV }] | Access Restrictions | 0 | -1 | FHIR does not yet support field level security tags. The ARV, when located with the PV1/PV2 in the v2 message, is meant to only apply to the encounter. However, technically it could point to other places in the messageas as well. That is considered out of scope as. | ||||||
20 | ADT_A06:follow:PV1.ROL | [{ ROL }] | Role | 0 | -1 | Encounter | ROL[Encounter-PractitionerRole] | |||||
21 | ADT_A06:follow:PV1.PRT | [{ PRT }] | Participation | 0 | -1 | |||||||
22 | ADT_A06.DB1 | [{ DB1 }] | Disability Information | 0 | -1 | |||||||
23 | ADT_A06.OBSERVATION | [{ | --- OBSERVATION begin | 0 | -1 | |||||||
23.1 | ADT_A06.OBSERVATION.OBX | OBX | Observation/Result | 1 | 1 | Based on profiles, such as Vital Signs, certain observations are represented on the Observation, while others on its components. No computable guidance available yet. | Observation | OBX[Observation] | Observation[3].subject.reference=Patient[1].id | One cannot determine whether this observation made during the PV1/PV2 communicated above, or from a prior visit/stay. It is therefore up to the implementer whether to populate Observation.encounter.reference with the Encounter[1].id or not. Only when the ADT message involves an event before the encounter occurs, e.g., the intiial registration, it is clear that the observation is NOT associated with Encounter[1]. | ||
23.1 | ADT_A06.OBSERVATION.OBX | OBX | Observation/Result | 1 | 1 | Based on profiles, such as Vital Signs, certain observations are represented on the Observation, while others on its components. No computable guidance available yet. | Observation | OBX[Observation-Component] | Observation[3].subject.reference=Patient[1].id | One cannot determine whether this observation made during the PV1/PV2 communicated above, or from a prior visit/stay. It is therefore up to the implementer whether to populate Observation.encounter.reference with the Encounter[1].id or not. Only when the ADT message involves an event before the encounter occurs, e.g., the intiial registration, it is clear that the observation is NOT associated with Encounter[1]. | ||
23.2 | ADT_A06.OBSERVATION.PRT | [{ PRT }] | Participation | 0 | -1 | |||||||
23.3 | /ADT_A06.OBSERVATION | }] | --- OBSERVATION end | |||||||||
24 | ADT_A06.AL1 | [{ AL1 }] | Allergy Information | 0 | -1 | AllergyIntolerance | AL1[AllergyIntolerance] | AllergyIntolerance.patient.reference=Patient[1].id | Processing of the AL1 segment results in the creation of a new AllergyIntolerance resource | |||
25 | ADT_A06.IAM | [{ IAM }] | Patient Advers Reaction Information | 0 | -1 | |||||||
26 | ADT_A06.DG1 | [{ DG1 }] | Diagnosis Information | 0 | -1 | If in context of the patient | Condition | DG1[Condition] | Condition[1].subject.reference=Patient[1].id | Processing of the DG1 segment results in the creation of a new Condition resource | ||
26 | ADT_A06.DG1 | [{ DG1 }] | Diagnosis Information | 0 | -1 | If in context of an encounter | Encounter | DG1[Encounter] | Encounter[1].diagnosis.reference=Condition[1].id | |||
26 | ADT_A06.DG1 | [{ DG1 }] | Diagnosis Information | 0 | -1 | If in context of a episode of care | EpisodeOfCare | DG1[EpisodeOfCare] | EpisodeOfCare.patient.reference=Patient[1].id; EpisodeOfCare.diagnosis.reference=Condition[1].id | |||
27 | ADT_A06.DRG | [ DRG ] | Diagnosis Related Group | 0 | 1 | |||||||
28 | ADT_A06.PROCEDURE | [{ | --- PROCEDURE begin | 0 | -1 | |||||||
28.1 | ADT_A06.PROCEDURE.PR1 | PR1 | Procedures | 1 | 1 | Procedure | PR1[Procedure] | Procedure.subject.reference=Patient[1].id | ||||
28.2 | ADT_A06.PROCEDURE.ROL | [{ ROL }] | Role | 0 | -1 | |||||||
28.3 | ADT_A06.PROCEDURE.PRT | [{ PRT }] | Participation | 0 | -1 | |||||||
28.4 | /ADT_A06.PROCEDURE | }] | --- PROCEDURE end | |||||||||
29 | ADT_A06.GT1 | [{ GT1 }] | Guarantor | 0 | -1 | |||||||
30 | ADT_A06.INSURANCE | [{ | --- INSURANCE begin | 0 | -1 | |||||||
30.1 | ADT_A06.INSURANCE.IN1 | IN1 | Insurance | 1 | 1 | Coverage | IN1[Coverage] | Processing of the IN1 segment results in the creation of a new Coverage resource | ||||
30.2 | ADT_A06.INSURANCE.IN2 | [ IN2 ] | Insurance Additional Info. | 0 | 1 | |||||||
30.3 | ADT_A06.INSURANCE.IN3 | [{ IN3 }] | Insurance Additional Info - Cert. | 0 | -1 | CareTeam.participant | IN3[CareTeam] | CareTeam[1].subject.reference=Patient[1].id | Incorporate IN3 content into the Coverage created from the IN1 segment. | |||
30.4 | ADT_A06.INSURANCE.ROL | [{ ROL }] | Role | 0 | -1 | |||||||
30.5 | ADT_A06.INSURANCE.PRT | [{ PRT }] | Participation | 0 | -1 | |||||||
30.8 | /ADT_A06.INSURANCE | }] | --- INSURANCE end | |||||||||
31 | ADT_A06.ACC | [ ACC ] | Accident Information | 0 | 1 | |||||||
32 | ADT_A06.UB1 | [ UB1 ] | Universal Bill Information | 0 | 1 | |||||||
33 | ADT_A06.UB2 | [ UB2 ] | Universal Bill 92 Information | 0 | 1 |
Generated Narrative: ConceptMap message-adt-a06-to-bundle
Mapping from ADT_A06 to Bundle
Group 1 Mapping from unspecified code system
to unspecified code system
Source Code | Relationship | Target Code | Comment |
ADT_A06.MSH (Message Header) | is equivalent to | Bundle | |
ADT_A06.MSH (Message Header) | is equivalent to | MessageHeader[1] | Processing of the MSH segment results in the creation of a new MessageHeader resource. |
ADT_A06.MSH (Message Header) | is equivalent to | Provenance[1] | If the FHIR transformation does not yield a FHIR message, but only a set of resource (APIs, repository, etc.) than one should consider attaching this Provenance resource instance to the relevant FHIR resources generated. |
ADT_A06.MSH (Message Header) | is equivalent to | Provenance[2] | If the FHIR transformation does not yield a FHIR Bunlde, but only a set of resource (APIs, repository, etc.) than one should consider attaching this Provenance resource instance to the relevant FHIR resources generated. |
ADT_A06.SFT (Software Segment) | is equivalent to | Provenance[1].entity.what(Device) | |
ADT_A06.SFT (Software Segment) | is equivalent to | Provenance[1].entity.what(Device) | |
ADT_A06.EVN (Event Type) | is equivalent to | Provenance[3] | |
ADT_A06.EVN (Event Type) | is equivalent to | Provenance[3] | If EVN-5 is not valued, then the MSH may have either the sending responsible organization (MSH-22) or the sending facility (MSH-4) to reasonable approximate the agent relevant for this Provenance instance. |
ADT_A06.PID (Patient Identification) | is equivalent to | Patient[1] | Processing of the PID segment results in the creation of a new Patient resource |
ADT_A06.PID (Patient Identification) | is equivalent to | Account[1] | |
ADT_A06.PID (Patient Identification) | is equivalent to | Provenance[4] | |
ADT_A06.PD1 (Additional Demographics) | is equivalent to | Patient[1] | Incorporate PD1 content into the Patient created from the PID segment. |
ADT_A01.PD1 (Additional Demographics) | is equivalent to | Observation[1] | |
ADT_A06:follow:PID.ROL (Role) | is equivalent to | Patient[1] | |
ADT_A06:follow:PID.ROL (Role) | is equivalent to | CareTeam[1] | |
ADT_A06:follow:PID.PRT (Participation) | is equivalent to | Patient[1] | |
ADT_A06:follow:PID.PRT (Participation) | is equivalent to | CareTeam[1] | |
ADT_A06.MRG (Merge Information) | is equivalent to | Account[2] | It will be left to implementation negotiation to determine whether disparate systems merely change the patient class, or close and open a new account. The current active account number should appear in field PID-18 - Patient Account Number; the prior account number can be included optionally in MRG-3 - Prior Patient Account Number. Depending on the relationship between the old and new account, the implementer should consider whether Account.partOf should be used as well to link the two accounts appropriately.\ |
ADT_A06.NEXT_OF_KIN.NK1 (Next of Kin / Associated Parties) | is equivalent to | RelatedPerson[2] | Typically, each NK1 will be translated to either a new RelatedPerson resource or added as a new occurrence of Patient.contact, but it's possible to insert the NK1 data into both structures. |
ADT_A06.NEXT_OF_KIN.NK1 (Next of Kin / Associated Parties) | is equivalent to | Patient[1] | |
ADT_A06.PV1 (Patient Visit) | is equivalent to | Encounter[1] | Processing of the PV1 segment results in the creation of a new Encounter resource. Note also that per A06 and A07 trigger event definitions PV1-19 - Visit Number may also be changed during this event. |
ADT_A06.PV1 (Patient Visit) | is equivalent to | EncounterHistory | |
ADT_A06.PV1 (Patient Visit) | is equivalent to | Patient[1] | |
ADT_A06.PV1 (Patient Visit) | is equivalent to | Coverage[1] | |
ADT_A06.PV2 (Patient Visit - Additional Info.) | is equivalent to | Encounter[1] | Incorporate PV2 content into the Encounter created from the PV1 segment. |
ADT_A06:follow:PV1.ROL (Role) | is equivalent to | Encounter[1] | |
ADT_A06.OBSERVATION.OBX (Observation/Result) | is equivalent to | Observation[3] | One cannot determine whether this observation made during the PV1/PV2 communicated above, or from a prior visit/stay. It is therefore up to the implementer whether to populate Observation.encounter.reference with the Encounter[1].id or not. Only when the ADT message involves an event before the encounter occurs, e.g., the intiial registration, it is clear that the observation is NOT associated with Encounter[1]. |
ADT_A06.OBSERVATION.OBX (Observation/Result) | is equivalent to | Observation[3] | One cannot determine whether this observation made during the PV1/PV2 communicated above, or from a prior visit/stay. It is therefore up to the implementer whether to populate Observation.encounter.reference with the Encounter[1].id or not. Only when the ADT message involves an event before the encounter occurs, e.g., the intiial registration, it is clear that the observation is NOT associated with Encounter[1]. |
ADT_A06.AL1 (Allergy Information) | is equivalent to | AllergyIntolerance | Processing of the AL1 segment results in the creation of a new AllergyIntolerance resource |
ADT_A06.DG1 (Diagnosis Information) | is equivalent to | Condition[1] | Processing of the DG1 segment results in the creation of a new Condition resource |
ADT_A06.DG1 (Diagnosis Information) | is equivalent to | Encounter[1] | |
ADT_A06.DG1 (Diagnosis Information) | is equivalent to | EpisodeOfCare[1] | |
ADT_A06.PROCEDURE.PR1 (Procedures) | is equivalent to | Procedure | |
ADT_A06.INSURANCE.IN1 (Insurance) | is equivalent to | Coverage[1] | Processing of the IN1 segment results in the creation of a new Coverage resource |
ADT_A06.INSURANCE.IN3 (Insurance Additional Info - Cert.) | is equivalent to | CareTeam[1].participant[2] | Incorporate IN3 content into the Coverage created from the IN1 segment. |