This is currently a WIP.

Name of GuideVersionStatusDate
PDex IG Companion Guide Template0.1DRAFT2019-06-26

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:

  • Provider
  • Member
  • 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.

Resource Mappings

Mapping Assumptions


  • 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:
    • cardinality
    • 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

Mapping Artifacts

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

Earlier versions


Example1: HbA1c

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.

Provenance Resource


sourceintermediary (who)targetcomments
ref lab
payersimplest use case
ref labproviderpayeras claim w/ results
payerin-house lab 
providerpayer (former)payer (new)PCDE use case

Data received from (transport and payload):

  • HL7 V2
  • C-CDA
  • 837 Claim
  • "Paper Chart"

  • Provider Attestation (Pass through billing)
  • Payer Intermediate Translation
  • Provider by copy of formal lab report

Other HRex Provenance Notes:

Source = originator

On agent.role 

  • 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 (Template)

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 

FHIR Resources from the PDex 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.


Data Crosswalks

Identify the source to target field mapping by FHIR Resource


FHIR FieldValue/Coding Set usedExample values Health Plan Source Data FieldIndustry Standard document/field source

Data Preparations

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

Mark Scrimshire, NewWave,

  • No labels