CA Core+ to pCHDCF Mapping

This page provides a detailed mapping between CA Core+ FHIR profile elements and their corresponding concepts in the Pan-Canadian Health Data Content Framework (PCHDCF), specifically the Logical Data Model (LDM). Where available, it also identifies which elements are flagged in CACDI as Essential for Exchange.

The mapping supports transparency, semantic alignment, and implementation clarity across jurisdictions, helping implementers understand:

• How CA Core+ profiles trace to PCHDCF semantics
• Which data elements are prioritized for exchange
• Where jurisdictional adaptation or specialization may be needed

For a full explanation of how mappings are represented in the FHIR Profiles is can be found on Mapping Logic.

Download the Mapping Table

A download link on Infoscribe to the mapping table will be added here.

This file includes:

• FHIR Element Path and Type
• Logical Data Model Attribute and Entity
• CACDI "Essential for Exchange" flag
• Data Type
• Mapping Condition
• Notes and NoAbsent enforcement

Future versions of this mapping will also include:

• Min/Max Cardinality for each element
• ValueSet bindings and references to pan-Canadian terminology
• Jurisdictional usage flags where applicable

Sample Table (Excerpt)

FHIR Element Path	Element Path Type	LDM Attribute	LDM Related Entity	Mapping Condition	DataType	CACDI Essential for Exchange	NoAbsent	Mapping Notes
AllergyIntolerance.code	Element	[Patient Allergy-Intolerance].[Allergy-Intolerance Code]	Patient Allergy-Intolerance		CodeableConcept	Yes	NoAbsent	Required to identify substance
AllergyIntolerance.onset[x]	Element	[Patient Allergy-Intolerance].[Onset Date Time]	Patient Allergy-Intolerance		dateTime			Use onsetDateTime if known
AllergyIntolerance.reaction	BackboneElement	[Reaction].causes	Allergy-Intolerance Reaction		BackboneElement			Structure for manifestations and severity
Appointment.participant	BackboneElement	[Appointment Participant]	Appointment		BackboneElement			Includes patient and provider participants
Appointment.basedOn	Reference	[Service Request].based on	Service Request		Reference			Indicates the request that led to the booking

NoAbsent — Meaning and Enforcement

The NoAbsent indicator means that the attribute must be populated with a valid value, and that value must conform to:

• The attribute’s logical data type
• Any relevant business rules (e.g., format, structure, validation)

Examples:

• A Social Insurance Number must be 9 digits
• A code must come from a valid terminology
• A dateTime must follow the ISO format

This strengthens conformance and ensures minimum data quality for interoperable exchange.

---

Mapping Logic

Overview

This page describes the methodology used to map concepts from the Pan-Canadian Health Data Content Framework (PCHDCF) and the Canadian Core Data for Interoperability (CACDI) to FHIR artifacts defined in CA Core+. It supports transparency, semantic traceability, and consistency between national models and FHIR implementation profiles.

• For the complete list of mapping entries, see the Download Mapping Table.
• For an overview of how CA Core+ aligns with the national models, see PCHDCF Relationship.

Purpose of the Mapping

The mappings bridge semantic models and implementation artifacts by:

• Translating concepts from the Logical Data Model (LDM) and CACDI into FHIR
• Identifying FHIR elements that implement pan-Canadian data expectations
• Supporting consistent representation of constraints, MustSupport, and conformance flags
• Informing jurisdictional extensions and identifying semantic alignment gaps

Mappings are visible:

• In the Tree View of each CA Core+ profile (for mapped elements)
• In the Downloadable Mapping Table, which also flags CACDI’s Essential for Exchange elements and includes LDM attribute references

Methodology and Source Models

Mappings are derived from:

• The Logical Data Model (LDM) within the PCHDCF
• The CACDI subset, which highlights essential-for-exchange elements
• Canadian jurisdictional FHIR implementation guides and national production systems

Mappings were validated through:

• Structured Gap Analysis comparing LDM and FHIR coverage
• Iterative review with jurisdictions and subject matter experts
• Alignment with existing semantic and implementation patterns

---

Mapping Classifications

To reflect mapping precision and intent, each entry is classified as follows:

• Primary Mapping
  A direct, semantically accurate match between a FHIR element and an LDM attribute. Considered authoritative. No asterisk used.

• Secondary Mapping
  A supporting, indirect, or partial mapping. Used for structure, context, or combined fields. Marked with an asterisk * and explained in the notes.

Note: Mappings assume an association with a subject (typically a Patient), even if not explicitly stated in LDM or CACDI.

---

Mapping Scenarios & Conventions

Extensions

• Mapping is recorded at the profile level where the extension is applied
• If re-profiled, it may also appear in the extension definition

Data Types

• Primary mapping applies to the parent (e.g., CodeableConcept)
• Sub-elements (e.g., .value, .system) may have secondary mappings

[x] Choice Elements

• If one expected type → map to that specific type
• If multiple → primary on [x], secondaries on slices
• If optional → primary on [x], note both supported types

References

• Noted on the referring element
• The referenced profile contains its own mappings

Backbone Elements

• Mappings apply to sub-elements (e.g., name.given)
• Conformance flags may appear on the parent

Combination of Elements

• Primary mapping on the main carrier
• Secondary mappings (*) for supporting fields with explanatory notes

Slicing

• Primary mappings at the slice level
• Secondary mappings clarify internal structure or cardinality

Multi-Use Elements

• Broader element gets primary mapping
• No slicing unless required by jurisdictional or downstream usage

---

Mapping Output: Table and Profile Integration

The downloadable table includes:

• FHIR Element Path
• Element Path Type
• LDM Attribute
• LDM Related Attribute
• LDM Related Entity
• Mapping Condition
• Mapping Notes
• CACDI "Essential for Exchange" Flag
• DataType
• NoAbsent

These mappings also appear in the CA Core+ profiles' StructureDefinition.tree and mapping elements.

---

NoAbsent — Rule Explanation

The NoAbsent flag indicates an element must have a valid, non-null value. This is stricter than min=1 in FHIR.

A value must be:

• Present
• Conformant to its logical data type
• Aligned with business rules, such as:
  • Correct format (e.g., SIN = 9 digits)
  • No placeholder values (e.g., "unknown", "n/a")
  • No empty or whitespace-only strings

This ensures better conformance and interoperability in shared systems.

---

Maintenance and Feedback

The mapping logic will evolve alongside:

• CACDI and LDM updates
• New domain-specific requirements
• Jurisdictional feedback

To submit feedback or suggest additions, please visit Specification Feedback.

Future Releases

Future releases of the mapping table will also include: Cardinality (Min/Max) from both the Logical Data Model and FHIR profiles ValueSet bindings, where applicable, including links to national and jurisdictional terminologies