Mapping Logic

This page describes how the mapping elements in CA Core+ StructureDefinitions are used to document semantic alignment with the Pan-Canadian Health Data Content Framework (PCHDCF) and the Canadian Core Data for Interoperability (CACDI). It is recommended that readers review the Relationship to PCHDCF before reviewing this page.

Mappings in StructureDefinitions appear in the element.mapping fields and use the identity PCHDCF-CACDI. These mappings document where an individual FHIR element corresponds to a concept from the Logical Data Model or CACDI, supporting semantic traceability and informing implementation decisions.

These mappings help:

• Clarify how CA Core+ elements relate to pan-Canadian data concepts
• Support semantic alignment reviews and gap analysis
• Guide implementation and conformance, including MustSupport evaluation

Mappings can be viewed in the "Tree View" of each Profile where the mapping field has been populated. These mappings are authored in FSH or JSON and maintained in the StructureDefinition resource.

Mapping Classifications

To reflect the precision and intent of each mapping, CA Core+ uses the following conventions:

• Primary Mapping
  A direct mapping that most precisely represents the PCHDCF concept.
  These mappings do not include an asterisk (*) and appear as the authoritative entry in mapping tables throughout the guide.

• Secondary Mapping
  An indirect or supportive mapping used for clarity, context, or completeness.
  These mappings are marked with an asterisk (*) and include a mapping.comment field to explain limitations (e.g., element choice ambiguity, structural variance, or contextual representation).

Note: All mappings are made under the assumption that the data is associated with a subject (e.g., a Patient), even if not explicitly stated in the source framework.

Mapping Conventions in StructureDefinitions

Extensions

• Mapping is recorded at the profile level where the extension is used.
• If the extension is re-profiled, mapping may also appear inside the extension StructureDefinition.

Data Type Sub-Elements

• If the mapped concept refers to a broad construct, the mapping is added to the parent element.
• Secondary mappings may appear on sub-elements (e.g., identifier.system, coding.code) with appropriate comments.
• Where useful, generalized mappings may be captured through profiled data types.

Slices

• Mappings apply at the slice level where relevant.
• Additional mappings may appear within slice sub-elements to support structure and cardinality interpretation.

Combination of Elements

• When multiple elements are required to express a concept (e.g., frequency + period), the mapping is split between primary (most meaningful field) and secondary (supporting elements) entries with comments.

Multi-Mapping Within a Single Element

• If one FHIR element supports more than one LDM concept, a primary mapping is used for the broader field.
• Slicing is avoided unless required by downstream constraints or implementation variation.

Backbone Elements

• Mapping is applied to the most granular applicable sub-element (e.g., name.given).
• Broader obligations (e.g., use of name) may be implied but not separately mapped unless required.

Choice Elements ([x])

• If one type is expected, mapping is applied to the specific type slice (e.g., onsetDateTime).
• If multiple types are valid, mapping may be applied at the [x] level with explanatory comments or extended to each type as secondary entries.

References

• The referring element includes a mapping (e.g., generalPractitioner).
• The referenced resource (e.g., Practitioner) contains its own mappings to document internal alignment.