HL7 Version 2 to FHIR
0.1.0 - STU1 Ballot
HL7 Version 2 to FHIR
0.1.0 - STU1 Ballot
This page is part of the HL7 Version 2 to FHIR (v0.1.0: STU 1 Ballot 1) based on FHIR R4. . For a full list of available versions, see the Directory of published versions 
This sections outlines implementation specific considerations that will have to be addressed during the implementation of v2-to-FHIR transformation project. Not all of these issues will apply to every implementation, but each implementation should review and consider he entire list to assess whether or not they are relevant for the project at hand. This list is not comprehensive and other implementation considerations may emerge as transforms are developed, tested and implemented in a Production environment.
In older versions, e.g., v2.3.1 the message structure in MSH-9 may have been omitted as the standard did not always include that in the message structure definition. For example, the message definition for RDE^O01 in v2.3.1 does not include the message structure, thus implementers omitted that, even though in Table 0354 there was a structure defined RDE_O01. When MSH-9.3 is empty, we suggest to derive the message structure to get to the proper map by using the message code and trigger event. I.e., when message code and trigger event is ABC^Nnn then use ABC_Nnn. For RDE^O01 that would be RDE_O01. We will be listing any known exceptions to that rule here as we find them.
In several maps, the v2 field or element has a larger maximum cardinality than the mapped FHIR attributes. That is, some v2 elements are allowed to repeat while the cognate FHIR element is not allowed to repeat. We still provide these mappings, but if your implementation allows these v2 elements to repeat, data may be lost. Implementers should evaluate the likelihood of this happening. The project team welcomes examples where this occurs in existing implementations so that we can discuss possible solutions.
When the v2 message is mapped into a FHIR Bundle, resources need to have a resource.id. At the time of the mapping the actual Resource.id may not be known if the intent is to update or reference an existing resource. The following guidance should be followed:
Depending on the next step, the Bundle may be forwarded in a FHIR message, the resource may be persisted as FHIR resources or translated into local data structures, or used in subsequent RESTful APIs. The system managing one or more of these steps may therefore opt to not follow all of the above guidance as they may be able to already be capable of resolving the Resource.id to the correct existing or new .id.
This implementation guide recognizes the distinction between stand-alone and contained resources but does not provide guidance in the mappings as the appropriate usage of contained resources. Implementers should consider the appropriateness of using contained resources during the transformation process where insufficient data is available in the v2 message to create a stand-alone FHIR resource. For example, if an ROL segment is transformed into a PractitionerRole resource including the address of the provider office in ROL-11 but lacks the provider’s location in ROL-13 there may not be enough information to create a stand-alone Location resource, but contained Location resource (including the address) may be included in the PractitionerRole resource.
The FHIR standard includes extensive content related to workflow management and task management. While many v2 message types don’t infer tasks (eg, they report on a previously completed event), some message types (eg. order messages) may imply the need for an external system to complete a task (eg. fullfill the order being requested). This implementation does include some mappings to the Task resource but it is up to implementers to determine if it is appropriate to create Task resources during the transformation process. For example, an order message may be directed to a system with the intent of notifying the system of the existence of the order without any expectation that the receiving system will fulfill the order. In this case, the creation of a Task resource is likely to not be appropriate. Implementers must understand the workflows associated with the data exchange to implement tasks correctly.
The concept of data provenance is typically only indirectly addressed within the v2 standard, however provenance can often be inferred by the data in various fields in the v2 message. For example, provenance may be inferred from data in the MSH segment (eg. the responsible sending organization), the ORC segment (eg. the entering user) or TXA segment (eg. the authenticator). This implementation guide does include some mapping to the Provenance resource but it is up to implementors to determine the level of data provenance that should be captured during the transformation process. At a minimum, the authors of this document feel that it may be appropriate to capture the provenance of the message source and the v2-to-FHIR transformation process. Additional provenance may be captured from additional fields as appropriate for the implementation.
Under Construction.
Identity management and patient merging/unmerging are complex processes at the best of times. Implementers should carefully consider how these activities will be impacted by a v2-to-FHIR transformation project. In particular, the workflow chosen (eg. messaging versus RESTful actions) and how Patient.id is populated may significantly impact how Patient resources are created, updated and deleted by the receiving system.
Clinically focused v2 messages (eg. ORM/OML, ORU, MDM) may contain limited data regarding an associated patient encounter. This data content may or may not be sufficient to unambiguously identify a matching encounter in the receiving system. The creation of Encounter resources should be carefully considered during the implementation process. The use of contained Encounter resources may be appropriate.
In v2 messages, it is common for multiple fields (using the XCN data type) to document the data for the same provider (eg, the same person may be the attending provider in the PV1 segment of an order message as well as the ordering provider in both the ORC and OBR segments of the same message). In this case, it may be most efficient if the Encounter and ServiceRequest resources reference the same Practitioner resource. It is critical that implementers consider how they will recognize duplicate provider references in a given v2 message and reuse Practitioner resources efficiently. Deduplication logic based on data including identifiers, name and credentials should be employed as part of the transformation strategy to identify potentially reusable resources.
In most FHIR resources, elements which allow a reference to a Practitioner resource also allow a reference to a PractitionerRole resource. In most scenarios, a v2 field using the XCN data type will typically be mapped to the Practitioner resource, but implementers may choose to map to the PractitionerRole resource instead. In a few places, an XCN field will be mapped to a PractitionerRole resource when other fields in the segment can contribute content to the PractitionerRole resource to create a more robust resource (for example, the ORC segment when mapped to ServiceRequest maps the Ordering Provider (ORC-12) field to PractitionerRole because the Ordering Facility fields in ORC (ORC-21 through -23) can also contribute to the PractitionerRole resource).
Depending on context and content an OBX segment in a v2 message may represent a wide variety of different types of data. Typically however, the OBX segment will map to an Observation resource which in turn is referenced in some other resource (eg, the result containing OBX segments in an ORU message will typically be transformed into Observation resources which are referenced in DiagnosticReport.result). Even when an OBX segment clearly maps to an Observation resource, complications may arise when the contents of multiple OBX segments must be considered as a whole in order to be fully understood or when there are multiple parts to a single result (that is each OBX segment is a component of an Observation (eg Observation.component). It is critical that implementers fully understand the type of content that may be presented in an OBX segment.
OBX-5 (Observation Value) is allowed to repeat in the v2 base standard however Observation.value[x] is constrained to a cardinality of 0..1. In this case, the transform may take a number of forms:
The values of OBX-3 and/or OBX-4 in multiple OBX segments may indicate a relationship between individual observations that must be maintain during the transformation process in order for the data to remain accurate and of use. For example, when two OBX segments contain the systolic and diastolic values of a blood pressure reading, the relationship between the two observations must be maintained. Observation.component can be used to maintain the relationship between related results. Implementers are encouraged to read the base standard documentation available describing the use of Observation.component as well as think about how related observations will be identified during the transformation process.
Some v2 implementations may adhere to constraints made on the base standard by an implementation guide. Where this happens it may be necessary to extend or constrain the standard mappings provided by this project. For example, in the US the v2.5.1 immunization messaging implementation guide describes how to use OBX segments to convey information related patient eligibility, distribution of educational materials and vaccine funding source. While these concepts are part of the FHIR Immunization resource, the VXU mappings from this project do not include these transformations as they are defined by the implementation guide, not the base standard. Implementers should consider local variations from the base standard when developing their transformations.
IG © 2020+ HL7 International. Package hl7.fhir.uv.v2mappings#0.1.0 based on FHIR 4.0.1. Generated 2020-08-12
Links: Table of Contents |
QA Report | Search
| Version History |
|
Propose a change