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

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



Observations, Including Results


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