Message ADT_A06 to Bundle Map

This ConceptMap represents a mapping from the HL7 V2 Message ADT_A06 to the FHIR Message Bundle.
V2 SegmentDisplayFHIR TargetEquivalence
ADT_A06.MSHMessage Header
Bundle
MessageHeader[1]

Processing of the MSH segment results in the creation of a new MessageHeader resource.

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.

If there is a source in MSH-4, or known based on the configuration.

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.

equivalentequivalentequivalentequivalent
ADT_A06.SFTSoftware Segment
Provenance[1].entity.what(Device)

If the software does represent not the original source system

Provenance[1].entity.what(Device)

If the software represents the original source system

equivalentequivalent
ADT_A06.EVNEvent Type
Provenance[3]
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.

equivalentequivalent
ADT_A06.PIDPatient Identification
Patient[1]

Processing of the PID segment results in the creation of a new Patient resource

Account[1]
Provenance[4]

One may drop PID-33 from the condition if PID-34 Last Update Facility is still sufficient without a date.

equivalentequivalentequivalent
ADT_A06.PD1Additional Demographics
Patient[1]

Incorporate PD1 content into the Patient created from the PID segment.

equivalent
ADT_A01.PD1Additional Demographics
Observation[1]
equivalent
ADT_A06:follow:PID.ROLRole
Patient[1]
CareTeam[1]

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.

equivalentequivalent
ADT_A06:follow:PID.PRTParticipation
Patient[1]
CareTeam[1]
equivalentequivalent
ADT_A06.MRGMerge Information
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.\

equivalent
ADT_A06.NEXT_OF_KIN.NK1Next of Kin / Associated Parties
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.

Patient[1]
equivalentequivalent
ADT_A06.PV1Patient Visit
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.

Basic
Patient[1]
Coverage[1]
equivalentequivalentequivalentequivalent
ADT_A06.PV2Patient Visit - Additional Info.
Encounter[1]

Incorporate PV2 content into the Encounter created from the PV1 segment.

equivalent
ADT_A06:follow:PV1.ROLRole
Encounter[1]
equivalent
ADT_A06.OBSERVATION.OBXObservation/Result
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].

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].

equivalentequivalent
ADT_A06.AL1Allergy Information
AllergyIntolerance

Processing of the AL1 segment results in the creation of a new AllergyIntolerance resource

equivalent
ADT_A06.DG1Diagnosis Information
Condition[1]

Processing of the DG1 segment results in the creation of a new Condition resource

If in context of the patient

Encounter[1]

If in context of an encounter

EpisodeOfCare[1]

If in context of a episode of care

equivalentequivalentequivalent
ADT_A06.PROCEDURE.PR1Procedures
Procedure
equivalent
ADT_A06.INSURANCE.IN1Insurance
Coverage[1]

Processing of the IN1 segment results in the creation of a new Coverage resource

equivalent
ADT_A06.INSURANCE.IN3Insurance Additional Info - Cert.
CareTeam[1].participant[2]

Incorporate IN3 content into the Coverage created from the IN1 segment.

equivalent

Equivalence Legend

equivalentExact match
wider/narrowerBroader/more specific meaning
relatedtoRelated but not exact
unmatchedNo equivalent in target