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

Technical Context

The CA Core+ Implementation Guide (IG) provides a foundational set of FHIR profiles designed to ensure consistent, reliable interoperability across Canadian jurisdictions and products.

These profiles align with the Pan-Canadian Health Data Content Framework (pCHDCF) Version 1, ensuring that the defined constraints, data structures, and interoperability standards reflect pan-Canadian data content requirements. This alignment helps provide a common foundation for jurisdictional and product-specific implementations while supporting consistent data exchange across Canada. It also incorporates real-world implementation experiences, including jurisdictional and product-specific implementation guides already in production.

CA Core+ establishes a harmonized, modular foundation that supports pan-Canadian interoperability while accommodating jurisdictional needs. Rather than defining all possible Canadian FHIR profiles, it focuses on a core set of foundational profiles and constraints that establish a common data model, while modules, such as the Workflow Module, introduce additional functionality to support specific processes and interoperability requirements. These modules allow CA Core+ to remain adaptable to evolving healthcare needs while maintaining a consistent base for jurisdictional and product-specific use cases.

In this section:

• Artifact Status Summary
• Profiling Conventions & Approach
• General Guidance
• Mapping Logic
• Security And Privacy

Understanding CA Core+ and Its Structure

CA Core+ provides a structured framework for pan-Canadian FHIR interoperability, built on two complementary layers that provide a flexible foundation for interoperability across jurisdictions and products:

1. Common Data Exchange Profiles
   These profiles define broadly applicable constraints on FHIR resources, including structural constraints, terminology bindings, and cardinality rules, to support consistent data exchange across Canadian implementations. They serve as the foundation of this guide and are designed to be reused in jurisdictional and use-case-specific contexts.

2. Workflow Module and Future Extensions
   In addition to foundational profiles, CA Core+ includes modulues that address workflow and interoperability needs.

   The current release includes a workflow module, which provides structured profiles for processes such as:

   • Task management
   • Referrals
   • Scheduling
   • Approvals

   Future releases will introduce additional modules, including:

   • Health Section Modules (e.g., problem list, medications, allergies, procedures)
   • Health Domain Modules (e.g., assessments, screening tools, immunizations)
   • Operational Domain Modules (e.g., privacy, security, consent management, administrative processes)

These modules ensure that CA Core+ remains adaptable, supporting evolving interoperability needs while maintaining consistency with foundational data exchange profiles.

Relationship Between Common Data Exchange Profiles and Modules

CA Core+ is designed to balance foundational data exchange capabilities with the flexibility required for diverse healthcare use cases. The framework consists of two main components:

How to Use Common Data Exchange Profiles and Modules Together

To ensure consistency and interoperability, implementation guides across Canada should follow these guidelines:

• Start with Common Data Exchange Profiles as the base for individual, organization, and encounter data.
• Use Modules to incorporate workflows, privacy, security, and domain-specific functionalities, such as task tracking or consent capture.
• Add jurisdictional or product-specific constraints in implementation guides while maintaining alignment with CA Core+ for broader interoperability.
• Avoid redefining foundational data elements unless absolutely necessary, ensuring consistency across implementations.

This approach provides a flexible yet standardized model for FHIR-based interoperability in Canada.

Design Principles

The design of CA Core+ is shaped by practical implementation realities, pan-Canadian objectives, and collaborative development. The following principles guide profile development and harmonization:

1. Reusable and Consistent Across Contexts

• Profiles are structured for reuse across multiple implementations with minimal modifications.
• Consistent data structures and rules reduce variation, accelerate implementation, and simplify vendor adoption.

2. Designed for Real-World Interoperability

• CA Core+ focuses on data exchange between systems, not internal workflows.
• Constraints are chosen based on their real-world relevance in health data interoperability.

3. Modular and Testable

• Each profile is independently testable to allow Canadian IG authors and implementers to validate their solutions.
• Implementers can layer jurisdictional or use-case-specific requirements on top of the core profiles.

4. Adaptable to Jurisdictional Requirements

• Recognizing varying policy environments and operational needs, CA Core+ supports local adaptations while maintaining pan-Canadian alignment.

5. Minimizing Disruption for Vendors & Stakeholders

• By aligning shared constraints across jurisdictions, CA Core+ reduces redundant effort and minimizes frequent, disruptive changes.
• Vendors can implement CA Core+ once and extend only when necessary.

6. Accommodates Regulatory and Policy Constraints

• The guide supports compliance with regional privacy, security, and health information laws.
• Jurisdictions can layer on additional constraints while maintaining alignment with the pan-Canadian profiles.

7. Supports Incremental Transition

• Not all jurisdictions or systems can immediately adopt a fully harmonized framework.
• CA Core+ provides a structured approach to support gradual adoption, ensuring alignment over time.
• A versioning system will be used in future releases, with an emphasis on backward compatibility to promote increased interoperability.
• Jurisdictions can adopt CA Core+ incrementally, layering in additional profiles and modules as their infrastructure evolves.

8. Jurisdictional Adaptation and Derivation

• Jurisdictions building on CA Core+ are encouraged to reuse core profiles and structures wherever possible, adapting where necessary.
• Any local customizations, such as extensions, terminology bindings, or slicing, should be implemented in a way that preserves compatibility with CA Core+.

Mandatory Values and Must Support Expectations

This section covers the conformance expectations, including cardinality, Must Support, and handling missing data to ensure interoperability across implementations.

Key Topics Covered:

• Handling missing data using data-absent-reason
• Definition and application of Must Support elements
• Cardinality expectations for required vs. optional elements
• Guidance for sending and receiving systems

For more details on the design of the CA Core+ profiles, see the Profiling Conventions & Approach and General Guidance pages.

Mandatory Values

Mandatory elements are defined as having a minimum cardinality of 1 (min=1), meaning the data is generally expected to be present. MS bay be present on some 1..1 elements to emphasize its importance.

In rare cases where data is not available, use the data-absent-reason extension to explicitly indicate why the expected data is missing.

Must Support (MS) Expectations – Pan-Canadian Context

Must Support flags play a key role in defining Profiling Conventions & Approach. More information can be found in the General Guidance on how implementation guide authors and implementers should treat Must Support.

Must Support expectations are inherited by derivative guides and are designed to reflect System conformance: The ability of a system to send, receive, and handle data elements marked as Must Support.

This applies at the sub-element level too—for example, identifier.system and identifier.value may both be 1..1 and marked as Must Support.

Sending Data (Content Creation)

• SHALL be capable of populating the element if the data is known and allowed.
• SHALL be capable of transmitting (sending or relaying) the element when it is populated.

Note: Systems that do not yet support a Must Support element are expected to identify such gaps during onboarding or testing. Jurisdictions may define timelines or expectations for progressive support.

Receiving Data (Content Consumption)

• SHALL be capable of handling (e.g., parsing, storing) instances that include Must Support elements without causing errors or application failure.
• SHALL not return an error for elements that are present but marked as missing using data-Absent-Reason.

Clarifying "Processing"

Processing includes:

• Storing data
• Rendering for human review
• Supporting domain-specific workflows (e.g., PS-CA, eReC)

Codings and CodeableConcepts

• SHALL populate Must Support codings if data is available and clinically appropriate
• SHALL accept, parse, and store these codings without errors

• SHOULD support display or use in downstream logic
• SHALL NOT reject codings simply because they are present, even if not marked as Must Support

Cardinality and Must Support

Obligations in CA Core+

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

The CA Core specification defines Producer and Consumer as primary actors for exchanging FHIR data and events.
Obligations describe the expectations placed on each actor type. These obligations are an evolving mechanism, and will be refined as adoption grows and new exchange patterns (e.g., REST, messaging, subscriptions) are supported.

• Producer
  Makes CA Core+ profiled data and events available to other systems that initiate retrieval, invoke operations, or subscribe/receive messages.

• Consumer
  Initiates retrieval or receives content conformant to CA Core+ to access, process, or manage health data.

More information on these actors can be found on Actor Definitions (CA-Core).

Obligations in CA Core+ are defined using the FHIR Obligations extension.
Since CA Core+ is based on FHIR R4, this specification uses the Obligation Extension to backport the feature from FHIR R5, enabling consistent declaration of requirements and expectations across CA Core+ artifacts. Obligations are defined according to the Obligation Codes ValueSet to specify how the system's expected capabilities.

For all obligations, no data should be populated or processed in any way that conflicts with regional laws, regulations or policies. For additional context, see the Security And Privacy section of this implementation guide.

Handling Missing Data with data-absent-reason

In CA Core+, missing data SHALL be represented using the data-absent-reason extension or an absent/unknown code when a profile element:

• Has a minimum cardinality of 1, and
• The data is unavailable at the time of data exchange.
• Is not a required binding on a codeableConcept.

CA Core+ does not explicitly require or prohibit use of the data-absent-reason extension.

Implementers MAY use this extension anywhere the base FHIR specification permits it, including for both primitive and complex elements, to indicate when information is missing and the reason is known.

General Guidance

• Follow the FHIR core specification for how to represent missing data for both primitive and complex elements.
• If an element’s minimum cardinality is 0, it may be omitted when no data is available.
• If an element’s minimum cardinality is 1 or more, it shall be present.
  • If the value is unknown or unavailable, it may include data-absent-reason as permitted by the FHIR specification.
• This extension SHOULD only be used on non-coded elements.
  • Coded elements should use codes from the recommended Data Absent Reason Code System (e.g. unknown.

Guidance for IG Authors and Implementations

• IG authors and specific implementations may choose to specify where use of data-absent-reason is expected or required for consistent exchange.

  • Example: an implementation guide may call out use of data-absent-reason on date elements (e.g., effective[x], performed[x], occurrence[x]) to promote uniform handling across systems.

• In the absence of such requirements:

  • Sending and receiving systems are not required to interpret or act on data-absent-reason.
  • Implementers are encouraged to document how their systems handle data-absent-reason to promote transparency.

Use of the data-absent-reason on Non-Coded Data Elements

If a required primitive or complex element (e.g., birthDate, name) is missing:

If a required primitive or complex element (e.g., birthDate, name) is missing:

• Use the data-absent-reason extension to explain the absence of data.
• For complex datatypes (e.g., HumanName, Address), the extension is placed inside the element.
• For primitive datatypes (e.g., date, string, boolean), the extension is represented on a sibling element prefixed with an underscore (e.g., _birthDate) when using JSON. This structure allows a primitive value to be omitted while still expressing metadata such as extensions.

Example: Birth date is not known

{
  "resourceType": "Patient",
  "_birthDate": {
    "extension": [
      {
        "url": "http://hl7.org/fhir/StructureDefinition/data-absent-reason",
        "valueCode": "unknown"
      }
    ]
  }
}

Recommended data-absent-reason Codes

The data-absent-reason extension should not be used on coded elements where an unknown or absent code can be used in place of the extension.

Use codes from the Data Absent Reason Code System, such as:

• unknown: Value is expected but not known
• asked-unknown: Source was asked but did not know
• temp-unknown: Temporarily unavailable
• not-asked: Not asked due to workflow or context
• masked: Hidden due to privacy concerns
• unsupported: System cannot capture the value

In cases where a system has information for a coded value, but no code e.g. the text for a Condition.code = Diabetes, but is lacking the SNOMED code 73211009 "Diabetes mellitus", the system SHOULD send the text and not flag it as a data absent reason.

Profile Conformance Rules

• Elements with Must Support and min = 0: MAY be omitted if no data is available. Use of data-absent-reason is optional.
• Elements with Must Support and min > 0:
  • For primitive elements, if no value is available, use data-absent-reason.
  • For complex elements which do not involve codeableConcepts, if the element cannot be populated, use data-absent-reason only if the profile explicitly allows it on that element or one of its required children. If the element contains a codeableConcept a data absent reason code should be used as described above.
• Elements with required ValueSet binding that lacks an “unknown” concept: data-absent-reason SHALL NOT be used. A valid code from the ValueSet MUST be provided (or if the cardinality supports, the element must be omitted) to remain conformant.

Specific Application of data-absent-reason

Some profiles—such as Immunization (CA-Core) explicitly mention the use of data-absent-reason to encourage consistent implementation across systems. In these cases, implementers SHOULD ensure their systems are able to both send and receive this extension. It will commonly be on date elements such as effective[x], performed[x], occurence[x].

While data-absent-reason may also be applied to other elements across CA Core+ profiles, receiving systems are not required to interpret or act on it unless explicitly noted in the profile. Implementers SHOULD document how their systems handle data-absent-reason to support transparency and promote consistent behavior across jurisdictions.

Jurisdictional Considerations and Implementation Guidance

See General Guidance for additional Implementation Guide authoring and implementation recommendations.

IG Authors should:

• Align with CA Core+ constraints unless there is strong justification not to
• Use consistent naming and structure definitions
• Limit new extensions to those with clear policy/clinical rationale
• Document all adaptations clearly

Implementers should:

• Adopt CA Core+ as a foundational and layer on local constraints incrementally
• Define the relevant subset of profiles for their context
• Maintain conformance with profiles they use

Feedback and Evolution

This guide is developed in collaboration with jurisdictions, vendors, and stakeholders. Feedback is actively sought to ensure the profiles remain relevant, clear, and implementable.

Visit the Specification Feedback page to contribute.