Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

This is currently a WIP.


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

...

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.

Mapping from Sources:

...


Approach

  • 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

...

Examples

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 

https://www.hl7.org/fhir/provenance.html

Agent

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


Data received from (transport and payload):

  • Provider via HL7 V2
  • Provider via C-CDA
  • Provider via 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

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

...

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.

Terminologies

Data Crosswalks

Identify the source to target field mapping by FHIR Resource

...