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

Profiling Conventions & Approach

This page outlines key conventions and decisions used when authoring profiles in CA Core+. It includes consistent strategies for terminology binding, use of extensions, and structural choices like slicing. These conventions support alignment across profiles, enable safe reuse by downstream guides, and help promote pan-Canadian consistency in data representation across jurisdictions, including at the data element and terminology levels. Before reviewing this page, it's highly recommended that a reviewer read the Technical Context page for information about cardinality and MustSupport.

Terminology Binding Conventions

• Binding Strengths: CA Core+ uses required bindings only where complete conformance is expected across jurisdictions and where the value set has complete coverage for all possible concepts, both now and in the future. example and preferred bindings are more common to accommodate legacy systems and differing provincial code systems.
• Pan-Canadian ValueSets: Where applicable, bindings use value sets from the Canadian Clinical Drug Data Set (CCDD), SNOMED CT CA edition, or other curated sources informed by the CIHI Logical Data Model.
• Terminology Harmonization: In cases where overlapping value sets exist (e.g., medication products, indications), profiles may define candidate bindings using the additionalBindings extension to support multiple systems.

In a future update more guidance will be added on retrieving normative versions of these valuesets from the Infoway Teriminology Server.

Extension Management

• Criteria for Inclusion: Extensions are only introduced when core FHIR elements cannot meet pan-Canadian policy or data requirements.
• Naming and Canonical Structure: All extensions initially defined in the CA Core+ specification follow a canonical URL pattern under the cacore namespace
• International Alignment: Where possible, CA Core+ reuses or aligns with extensions defined in HL7 FHIR Core, International Patient Summary (IPS) or other existing implementation guides before creating a new one. Many of the extensions used in CA Core+ can be found in the HL7 Extension Registry.
• Jurisdictional Extensions: Many jurisdictional extensions—particularly those with broad applicability across Canadian jurisdictions—have been incorporated into CA Core+ to promote reuse and reduce duplication.

Slicing and Pattern Use

One of the key features of FHIR profiling used in CA Core+ is Slicing, a way to apply different sets of constraints to repeated elements or groups of complex elements in a resource. Slicing allows implementers to define specific rules for known data patterns while still supporting additional, system-specific content. In CA Core+, most slices are open (i.e., slicing.rules is not set to closed), which means that instances may include additional elements beyond those explicitly defined, provided they still meet the overall profile constraints. This approach supports extensibility across jurisdictions and vendor systems.

• Open Slicing Strategy: Unless specifically closed, slices in CA Core+ are open to allow for future additions by jurisdictions or systems.
• Common Slicing Use Cases: Typical slicing is used on identifier, category, coding, and performer elements.
• FHIR Patterns: Profiles reference FHIR base patterns (e.g., Observation, Request, Composition) where applicable, and slicing rules reflect those expected in downstream systems.

Reference Targets in CA Core+

In CA Core+, we generally constrain references (e.g., AllergyIntolerance.subject, Encounter.subject, PractitionerRole.practitioner) to point to CA Core+ administrative profiles rather than the corresponding core FHIR resources. For example:

• AllergyIntolerance.subject → Patient (CA Core)
• PractitionerRole.practitioner → Practitioner (CA Core)

This approach reflects the intent of CA Core+ as a foundational implementation guide that encourages consistent use of administrative resources across implementations in Canada. By referencing CA Core+ profiles rather than unconstrained FHIR base resources:

• We promote shared expectations for identity, demographic, and organizational structures.
• We enable better interoperability, as systems can rely on a consistent minimal set of constraints (e.g., identifiers, name, address) without needing to handle variability at runtime.
• We retain flexibility where appropriate. References to clinical resources (e.g., Observation, DiagnosticReport) are intentionally left less prescriptive, since they will often be further specialized by jurisdictional or use-case-specific implementation guides. In contrast, the administrative layer is expected to remain consistent across those specializations.

In cases where a CA Core+ administrative profile is referenced, we expect it to be broad enough to support even legacy or external data sources. Where divergence or legitimate variation is anticipated (e.g., in clinical resources with evolving structures), we allow referencing either the CA Core+ profile or the base resource.

In derived guides that build on CA Core+ (e.g., by reusing the Patient profile), it's expected that those guides may define new references using their own profile names. Functionally, these profiles should be treated as compatible with the corresponding CA Core+ profiles and subject to the same core expectations. See Example Patient Profile for an example of how a profile derived from CA Core+ Patient might look.

Use of translation Extension on CodeableConcept

CA Core+ supports the use of the translation extension on CodeableConcept in the CodeableConcept (CA-Core), and specifically on the Coding (CA-Core) profile, to represent multilingual display values. This is particularly relevant for bilingual or multilingual jurisdictions (e.g., English and French labels in Canada).

Guidance for Implementers:

• Systems SHOULD display the appropriate translated value when available and appropriate based on user language preference.
• Systems MAY include multiple translation extensions per coding, each with its own language and content.
• If display is also present, implementers MAY prioritize the localized translation over display when rendering for end-users.
• Downstream guides MAY add constraints (e.g., requiring a French translation) where legally or operationally necessary.

Example:

"code": {
    "coding": [
      {
        "code": "73211009",
        "system": "http://snomed.info/sct",
        "display": "Diabetes mellitus",
        "_display": {
          "extension": [
            {
              "url": "http://hl7.org/fhir/StructureDefinition/translation",
              "extension": [
                {
                  "url": "lang",
                  "valueCode": "fr"
                },
                {
                  "url": "content",
                  "valueString": "Diabète sucré"
                }
              ]
            }
          ]
        }
      }
    ]
  },

A complete example can be seen here: Example Condition Diabetes.

The CodeableConceptCACore will be applied to elements which are CodeableConcept and have a CA Core+ valueset and/or MustSupport applied to them. Other default CodeableConcept datatypes will be considered to have the CodeableConceptCACore profile applied as needed.

Use of additionalBindings Extension

• CA Core+ uses the additionalBindings extension to document alternative or candidate terminology bindings.
• This enables broader interoperability across provinces with differing terminology systems (e.g., CCDD vs. WHO ATC).
• Implementers are encouraged to review the binding strengths and their meaning from HL7 and the AdditionalBindings Purpose ValueSet.
• These are not required for conformance when the additional binding purpose is any value except: maximum, minimum or required. These bindings otherwise serve as guidance for implementers and vocabulary services.

Nested Expectations and Element Strength Inheritance

CA Core+ applies structured conventions when defining expectations on nested or composite elements such as identifier, coding, or reference. While FHIR allows sub-elements to carry their own cardinality and Must Support flags, CA Core+ provides the following guidance to clarify how implementers and downstream guides should interpret these expectations.

Key Considerations

• Sub-elements May Be Must Support Even If the Parent Is Not
  CA Core+ allows sub-elements (e.g., identifier.system, identifier.value) to be marked as Must Support even if the parent (identifier) is not.

  • If the parent is present, the Must Support sub-elements MUST also be present if appropriate and available.

• Sub-element Cardinality May Be More Constrained Than the Parent
  A parent element may have a cardinality of 0..1 or 0..*, while its sub-elements may be 1..1.

  • If the parent appears in the instance, then the required sub-elements must be present as children of that element..

Conditional Presence

In some cases, CA Core+ documentation or profiles may specify that certain sub-elements are required only when their parent is present. This allows for precise data modeling without forcing top-level elements to always be present.

• identifier.system and identifier.value may be marked as Must Support, while identifier is optional.
• coding.code may be required (1..1), even if coding is 0..*. This indicates that if coding is populated, that coding.code MUST be populated.

Use of Invariants

The CA Core+ Implementation Guide includes FHIR invariants to enforce specific rules that reflect Canadian requirements more precisely than international base profiles. These invariants are defined using FHIRPath and help ensure data consistency and conformance to expectations in key areas. These are:

• Used only where necessary to express logic not enforceable through cardinality or bindings alone.
• Accompanied by clear error messages and naming conventions.
• Validated using standard FHIR tooling (e.g., IG Publisher).

This guide defines several invariants including:

• One invariant on the Patient (CA-Core) profile, enforcing constraints relevant to identity or demographic representation in the Canadian context.
• One invariant on the Immunization (CA-Core) profile, ensuring key clinical data is captured appropriately for immunization events.

As pan-Canadian recommendations and jurisdictional needs become more clearly defined, additional invariants will be introduced to reflect those consensus requirements. These constraints aim to promote better data quality, interoperability, and alignment across Canadian health systems.

PCHDCF Translation Practices

This section will continue to expand in future iterations as content is further developed in the Pan-Canadian Health Data Content Framework (PCHDCF). This version focuses on 1) mapping the data element definitions from the pCHDCF CACDI, 2) outlining a potential logic for translating initial expectations into FHIR profiles, 3) initial introduction of terminology for select concepts.

Mappings to the Data Content Standard data elements are defined in-line within the profiles and can be found on each profile's page when applicable. Visit the Relationship to PCHDCF to learn how pCHDCF and CA Core+ work together, and for more details on the mapping approach visit the Mapping Logic page.

FHIR Maturity Model In This Guide

Note: These are proposed definitions and we are seeking feedback.

All artifacts in this specification are assigned a Maturity Level, known as Canadian FHIR Maturity Model (CFMM) (after the FHIR Maturity Model (FMM) grades).
The FMM level can be used by implementers to judge how advanced — and therefore stable — an artifact is.

The following FMM levels are defined:

• CFMM 0
  The resource or profile (artifact) has been published on the current build.
  This level is synonymous with Draft.

• CFMM 1
  DRAFT 0 PLUS the artifact produces no warnings during the build process and the responsible WG has indicated that they consider the artifact substantially complete and ready for implementation.

• CFMM 2
  FMM 1 PLUS the artifact has been tested and successfully supports interoperability among at least three independently developed systems leveraging most of the scope (e.g., at least 80% of the core data elements) using semi-realistic data and scenarios based on at least one of the declared scopes of the artifact (e.g., at a connectathon).
  These interoperability results must have been reported to and accepted by the responsible working group.

• CFMM 3
  FMM 2 PLUS the artifact is presently used in two or more implementation guides including pan-Canadian Specs (either direct use, or derived from) in at least two jurisdictions; has been subject to a round of formal balloting; has at least 10 distinct implementer comments recorded in the tracker drawn from at least 3 organizations resulting in at least one substantive change.

• CFMM 4
  FMM 3 PLUS the artifact is implemented in multiple prototype projects across all of its defined scopes where the resource has a domain specific use.
  As well, the responsible work group agrees the artifact is sufficiently stable to require implementer consultation for subsequent non-backward compatible changes.

• CFMM 5
  FMM 4 PLUS the artifact has been implemented in at least 5 independent production systems, and used in at least two jurisdictions.

• Normative
  The artifact is now considered stable.

Tested across scope is defined as:

• The CA Core+ WG has signed off on the list of example contexts defined for the artifact
• For each example context, the artifact has either been:
  • reviewed and approved by a domain expert for that scope area,
  • mapped to an existing implemented scope-area-specific standard, or
  • tested in an implementation