DFT-Ballot - The specification is a DFT-Ballot version of CA Core+ for collecting ballot feedback. For a full list of available versions, see the Directory of published versions

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 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. There is a table at the bottom of each of the CA Core+ Profiles listing all mappings relevant to that profile.

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

Mapping Outputs and Table Behavior

Profiles will have a mapping table below their terminology bindings showing how the profile maps to the CACDI. For guidance on the relationship between CA Core+, the PCHDCF, and the CACDI see Relationship to PCHDCF, which has more information on the PCHDCF and the CACDI.

• Mappings from StructureDefinitions are displayed in IG mapping tables.
• mapping.comment content may be included to clarify nuances or intent.
• Mappings will continue to evolve as CACDI, PCHDCF and jurisdictional implementations mature.