currently a WIP.
|Name of Guide||Version||Status||Date|
|PDex IG Companion Guide Template||0.1|
Mapping from Sources:
Why this companion guide
Purpose: To provide a guide for translating from different sources including providing a provenance resource to describe the actions taken to translate to the observation resource.
Most likely sources:
- HL7 V2: v2.3, v2.5.1
- C-CDA: R1.1, R2.1
- X12: 837 transaction
Three target audiences:
- Next Payer
We are working with US Core resources. Each profile has a minimum set of required fields. Beyond those fields additional data SHALL be provided if it is available. When dealing with different data sources there will likely be different levels of data granularity.
In the context of this guide this document provides a mapping of different data sources to the observation profile. The objective of this guide is to enable Payers to map their data from different sources consistently.
A provenance resource SHALL be constructed for each record to identify the originator of the data (the provider/organization etc.), the transmission format (C-CDA, ADT, 837 etc.) which indicates the type of translation performed.
- To leverage the work already being done in the community. This may include the existing work from:
- O&O - HL7v2-to-FHIR project
- C-CDA on FHIR project
- To address Provenance from the payer perspective
- Develop mappings for payer-specific sources (e.g.: 837 claims)
We want to complement rather than duplicate work.
- We will leverage the ongoing work from the O&O HL7v2-to-FHIR mapping project where possible, however PDex will have its variations for a number of reasons:
- The HL7v2-to-FHIR worksheet mappings contain segments from HL7v2.7 (e.g.: PRT). HL7v2 messages received by payers in our use case are v2.5.1 or v2.3. Still pending further research with examples, but ideally, the v2-to-FHIR mapping is meant to be cumulative so even if a field from a prior version is deprecated, the spot is still there effectively.
- PDex will align with US Core R4 which will impose further constraints on cardinality and coding systems not in these mappings.
- Payer-relevant elements and coding systems may further extend or constrain the FHIR target mappings.
- HL7v2.5.1 will be the source data standard which will be mapped to FHIR. While there are other more recent versions of HL7v2, version 2.5.1 is cited for CLIA conformance.
- Semantic mappings might be approximate in cases where the term descriptions are ambiguous.
- Structural mappings might not align in several ways noted below:
- data type
- non-existent elements
The HL7v2-to-FHIR sub-team is currently working through these mapping alignment issues and noting them within the documentation of each HL7v2 segment mapping
The attached Spreadsheet provides a mapping from Health Plan data sources to the FHIR US Core (R4) Profile:
Latest: Observation-FHIR_R4 v1.4.xlsx
The following FHIR instances are in context with the HL7v2 ORU^R01 example for an HbA1c. They contain references to each other adn should be considered as a group.
|ref lab||payer||simplest use case|
|ref lab||provider||payer||as claim w/ results|
|provider||payer (former)||payer (new)||PCDE use case|
Data received from (transport and payload):
- Provider via HL7 V2
- Provider via CCDA
- Provider via C-CDA
- 837 Claim
- Provider via "Paper Chart"
- Provider Attestation (Pass through billing)
- Payer Intermediate Translation
- Provider by copy of formal lab report
Other HRex Provenance Notes:
Source = originator
- provider could be a validator or transcriber.
- payer could be a transcriber.
What is the scope/grounding on identifying intermediaries?
- keep in mind...we're doing this through the lens of the payer and what visibility do they have in the data received?
- e.g.: if there's a claim that only states that a lab test was done then what can be deduced fro that content?
- e.g.: if there is a translation from HL7v2 to C-CDA, does there need to be an intermediary here? (is it secondary data at this point?)
Health Plan Data Exchange
Document how the health plan will support the use case scenario outlined above....
Health Plan Data Sources
Identify the potential data sources the Health Plan would use to support the data exchange...
PDex/HRex FHIR Resources
Identify the FHIR Resources from the PDex IG and HRex IGs that are used to support the data exchange...:
Other Dependent FHIR Resources
- US Core Patient
- US Core Laboratory Result Reporting
Value Sets and Terminologies
Identify the value sets, codings and terminologies that will support the data exchange.
Identify the source to target field mapping by FHIR Resource
|FHIR Field||Value/Coding Set used||Example values||Health Plan Source Data Field||Industry Standard document/field source|
Identify the dependencies for creating FHIR resources.....
For example, Patient and Practitioner Resources need to be created before Encounter, Procedure etc.
Author/contact person with contact information for this page
Tony Benson , BCBS Alabama