Mapping Logic

The following logic was created in response to disparate requests during the CA Core+ v0.1 DFT Ballot to have mappings shown across the hierarchy (e.g., parent elements, value elements, slices).

For the purposes of understanding the mapping logic below:

  • Primary mapping is the mapping that accurately matches pCHDCF concept (with the closest precision)
    • These mappings do not contain an asterisk and are the mappings that are housed in the mappings table of the guide page
  • Secondary mapping is a mapping that helps provide additional context but lacks the precision of the primary mapping.
    • These mappings contain an asterisk with a matching note in mapping.comment to indicate details on why the mapping is not precise (e.g., a secondary mapping on an element with choice of data types that conveys the specific data type / slice that is relevant for the primary mapping)

Note: Obligation towards patient/subject is assumed (even if domain in pCHDCF doesn't explicitly have a concept for a mapping to be applied).

Extensions

When a pCHDCF concept is conveyed by an extension or complex extension, the following shall take place:

  • Mapping will be done at the profile that applies the extension
  • If the extension is re-profiled, mapping can also be done inside the extension
    • There is still an outstanding decision whether to reprofile all extensions to show this if nothing else changes about the extension (though this will be less likely as pCHDCF adds more constraints) – in v0.2 DFT re-profiling extensions is only done when there is a change required for the extension (e.g., re-profiling for R4, to add comments, etc.)

Data Type Sub-Elements

Where a pCHDCF concept maps to a CodeableConcept:

  • If the concept description is not explicitly targeted towards conveying a code or code system, the Primary mapping will be applied on the element level (rather than applying to coding and text).

Where a pCHDCF concept mapping is under an element with subsequent data type details (e.g., identifier.system, identifier.value):

  • Primary Mapping will applied at the top level (e.g., telecom)
  • Secondary mapping will be applied to the element that is closest to the value
  • If this pattern occurs regularly, a profiled data type might be considered (e.g., drug-quantity profile)

Slices

Where a pCHDCF concept maps to a slice (used when multiple elements are combined to convey a single concept):

  • Primary Mapping should be applied at the slice level
  • Secondary Mapping should be applied to the element that is closest to the value

Combination of Elements

Where a single concept requires two elements together to be met (e.g., frequency and period in MedicationRequest)

  • Primary mapping should tie back to the element closest to the resulting value,
  • Secondary mapping with asterisk should be applied with note on the other element
    • Note should be applied to additional element(s) indicating that it is needed to meet current concept as defined
    • Both will show up in the mapping table of the implementation guide page

Other Mapping Methods

When a single element could contain multiple mappings (e.g., medicationCodeableConcept could contain details for brand name, generic name, etc):

  • Primary mapping should include all of those (rather than slicing to show how each one could map to a sub-element)

Backbone Elements

Where mapping is under a backbone element:

  • Mapping only applies to the element itself
  • However obligations should still be applied upwards to indicate demonstration expectations

Where a concept could be met by multiple backbone sub-elements (e.g., name.given and name.text):

  • Primary mapping will go to the structured element closest to the value
  • Secondary mapping (with asterisk) is applied to the text concept with mapping note indicating the element may be used to convey multiple pCHDCF name attributes (e.g., first name, last name) in a single string
    • Consumer and Receiver Obligations will be applied to the structured elements, whereas the text elements will only carry the receiving obligation of SHALL:no-error

Data Types

When an element has a choice of data types, and a single concept ties to a single data type (e.g., Date of Death concept ties to deceasedDateTime, Allergy Onset concept maps to allergyIntolerance.onsetDateTime):

  • It is encouraged to still represent this as a slice to indicate the datatypes are open and there may be cascading requirements tied to the datatype for the primary mapping
  • Primary Mapping should be applied at the element[x]:slice DataType level
    • The mapping table in the IG should reference the slice path
  • Secondary Mapping (with asterisk) should be applied at the element[x] level with a mapping note indicating the data type that is the target
  • Obligation should be applied to the slice of the data type (since it is the only data type expected to be supported for the concept)

When an element has a choice of data types and a single concept does not distinguish between types (e.g., doseRange vs doseQuantity):

  • Primary Mapping should be applied at the element[x] level with a note indicating that the concept doesn’t distinguish between data types
  • Secondary Mappings can be applied to the individual slices to ensure they show up on the generated mapping table and implementation guide page mapping table
  • Obligations will be applied to all potentially matching data type slices with intent that the framework will continue to refine its expectations about supported data types

When an element has a choice of data types and a single concept could be met by multiple data types (medicationReference, medicationCodeableConcept)

  • Primary Mapping should be applied at the element[x] level with a note of which data types are targets
  • Secondary Mappings are applied on the specific data type targets

References

When an element in a profile is a reference to another profile that contains those details:

  • Generalized mapping (with asterisk) is included to indicate (e.g., General practitioner details) to avoid providing excessive mappings that should otherwise be conveyed within the profile itself
  • These can be called out in the implementation guide page mapping table