Page tree
Skip to end of metadata
Go to start of metadata

MBTS Ballot Draft


DRAFT Mappings for CDS Hooks Use Case - Opioid Prescribing Support Implementation Guide, Recommendation #4

For Atlanta WGM Discussion


Background Memo on CDS Hooks Mappings

For Atlanta WGM Discussion

May 2019 Ballot for Comment materials 

CrossParadigmMay2019Ballot.zip

Draft Datatype Mapping

Background information on Spreadsheets for Ballot

Header Elements


Problem Observation to Condition: This mapping has been prepared in anticipation of changes to the CCDA R2.1 standard that allow a problem observation entry to be nested directly within a Problem Section, without a Problem Concern "wrapper"


Problem/Condition Elements


Medication Activity Elements (Note two tabs: EVN and INT)


Provenance as Author Entry

Immunizations

Procedure

Observations, Including Results

Goal


Notes on CCDA elements mapped to multiple FHIR elements

There are many elements in CCDA header that map to multiple elements in multiple resources in FHIR. In many cases this is to ensure ideal bidirectional mapping from FHIR to CCDA. For example, guardian.code is mapped to both USCore.Patient.contact.relationship & RelatedPerson.relationship. This supports the ideal transformation from FHIR to CCD.

A proper CCD would include a list of participants in an encounter. In the CCD, this information is in the header participant entry. For a transformation from CCDA to FHIR, direct mapping of guardian.code to USCore.patient.contact.relationship is the only mapping necessary. However, mapping FHIR RelatedPerson to participant includes detailed information on participants in the transformation to CCD, which is the ideal format for the CCD.

Another type of mapping to multiple elements and resources occurs when the same information is from CCDA is represented in different resources, or portions or an entry are represented in different resources, so identifiers, names, and other static, identifying elements must be repeated across the resources. This is especially evident in CCDA header entries such as Author, Informant, Custodian, etc., which all are represented in the USCore Profile via extensions, but which are equally well represented using the Provenance Resource with different codes signifying the appropriate entry role. Again, the mapping to the Provenance resource increases the usability of the data in the FHIR server.

  • No labels