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

General Guidance

This page offers general implementation and authoring guidance that applies to all CA Core+ artifacts and modules. It supports a common understanding of profiling philosophy, behavior across systems, and best practices for promoting interoperability.

Guidance for Implementation Guide Authors

CA Core+ is structured to support reuse and consistency across Canada. The Business Context and Technical Context pages have more information on the business and general needs to derive from CA Core+. This section contains specific recommendations.

When defining or adapting profiles for jurisdictional or domain-specific use, IG authors should apply the following recommendations to ensure alignment with the CA Core+ framework:

• Reuse before redefining: Base new profiles on CA Core+ wherever possible. Modify only when justified by local policy, technical limitations, or clinical context. Participating in pan-Canadian discussions, even when designing for a local context, can improve alignment and increase the likelihood that your specifications will be supported or reused more broadly.
• Preserve conformance: When adding constraints (e.g., slicing, required bindings), do so in a way that does not conflict with CA Core+ expectations unless a strong justification exists.
• Mark min=1 elements as Must Support when they are clinically meaningful and interoperable across systems, especially when used in pan-Canadian data exchange and are meaningful beyond being required for exchange. For guidance on how Must Support and cardinality interact, see Technical Context.
• Clearly document adaptations: Extensions, added constraints, terminology adaptations, or removed elements should be explained in the derived guide to aid future harmonization efforts.
• Express constraints using computable artifacts: Avoid relying solely on narrative text to describe constraints. Use FHIR StructureDefinitions, ValueSets, CodeSystems, CapabilityStatements, and other formal artifacts to define expectations in a machine-readable way. This ensures implementers and tools can interpret the guide consistently. Where narrative explanations are needed, accompany them with formal definitions.
• Consider if your extension has broader use: When introducing extensions, consider whether they are truly specific to your use case or if they could be candidates for a future CA Core+ release. Also check for existing extensions from international or other jurisdictional sources (e.g., HL7 International, US Core) before defining new ones. Submit proposed extensions or changes via the Specification Feedback page.
• Evaluate constraints at the sub-element level: If a parent element is optional but a child is min=1 and Must Support, ensure that downstream implementers understand the conditions under which that child is required.
• Be explicit about data-absent-reason: When extending profiles, specify when and how to apply data-absent-reason, particularly for jurisdiction-specific constraints on privacy (e.g., masked, not-asked).
• Do not ascribe meaning to repetitions: Only interpret the order or count of repeated elements if the core FHIR specification defines such meaning. If ordering or categorization is required, use additional elements or extensions to express it explicitly.
• Use slicing or tighter bindings: to enforce specific usage patterns instead of removing data elements.
• Avoid unnecessarily reducing max cardinality: Systems should tolerate the presence of unneeded data and only prohibit additional repetitions when it is clearly erroneous in the business context (e.g.Patient.desceased[x] is prohibited because submitting a deceased patient would violate the use-case). If a receiving system requires only one instance where multiple are valid, use extensions or a distinguishing element to indicate the relevant instance instead of restricting valid data from being sent.
• Avoid narrowing cardinality: Consider the impact of narrowing cardinality on interoperability with other systems.

Refer to the Technical Context page for more on CA Core+ adaptation strategy and how profiles are designed to balance pan-Canadian interoperability with jurisdictional flexibility.

Guidance for Implementers

Implementers working with CA Core+ or downstream guides based on it should consider the following when handling required elements and Must Support expectations:

• Evaluate each element individually: Do not assume that a parent element is Must Support unless explicitly marked. Child elements marked as Must Support (or with min > 0) indicate specific implementation responsibilities.
• If a parent element is present, the system MUST support and process any required or Must Support children. For example, if identifier is included, the system must also handle identifier.system and identifier.value if marked Must Support.
• Child elements may carry more strict constraints than their parents (e.g., 0..1 parent with 1..1 child). This indicates that if the parent is used, the child must be populated. See Technical Context for more on this convention.
• Missing values on required elements: If data for a min=1 or Must Support element is unavailable, use data-absent-reason to indicate why. See the “Handling Missing Data” section below for specific rules and examples.
• Systems should process Must Support data when received, including:
  • Parsing and storing values
  • Displaying them for human review (where applicable)
  • Using them in relevant workflows (e.g., decision support, routing, reporting)
• Receiving systems must not fail when receiving instances that comply with a CA Core+ profile, even if they include optional data elements or additional extensions. However, they may enforce business rules relating to such elements, particularly around unexpected values in modifier elements.

CA Core+ is designed to reduce variation and allow jurisdictions to extend profiles as needed. Implementers should consult jurisdiction-specific IGs to determine if additional constraints or policies apply. When in doubt, prioritize compatibility with CA Core+ base definitions to support broader interoperability.

Extensibility and Additional Elements

A server may send “additional” elements beyond those flagged with Must Support in a CA Core+ profile. These additional elements are often required by other profiles the system conforms to, and they may carry local requirements or technical/workflow context.

For this reason, extensibility is generally encouraged and expected in CA Core+ profiles. Only in rare cases—where safety, policy, or compatibility requires it—are profiles designed to limit the inclusion of extra elements through tight cardinality or Must Support restrictions.

Specification authors should strive to enable greater interoperability and software reuse by not reducing element cardinality unless there's a well-justified reason.

Client systems:

• MAY ignore these “additional” elements, provided they are not unrecognized/unsupported values for modifier elements,
• MAY treat them as render-only,
• MAY use them if capable of understanding the content.

Use of Optional Elements

Profiles may leave many elements optional to support broad applicability across jurisdictions and use cases. CA Core+ adopts a flexible modeling approach:

• Elements with min=0 and no Must Support flag are considered optional.
• Implementers MAY populate these if the data is available and relevant.
• Downstream guides MAY elevate their importance by making them Must Support or tightening cardinality.

Consistency Across Jurisdictions

To promote reusability and alignment across Canada:

• Try to reuse extensions and value sets already present in CA Core+.
• If a local constraint is needed (e.g., a province-specific code), prefer narrowing a binding rather than replacing it entirely.
• Submit proposed extensions or changes via the Specification Feedback page.

Examples and Representations

Profiles in CA Core+ may include illustrative examples, but:

• Examples are informative only and do not imply conformance.
• Implementers are encouraged to test edge cases and realistic payloads, not just sample data.

Including Narrative in FHIR Resources

Systems often expose more data elements than those explicitly marked as Must Support (MS) or Obligations in a profile. When this happens, downstream systems may be unable to interpret or display some of the additional content.

To support broad interoperability and safe data exchange in these situations, systems MAY include a human-readable narrative in the resource’s text.div element. This narrative acts as a fallback representation for data that downstream systems cannot recognize or display, using FHIR’s standard mechanism for conveying such information.

Requirements for Generating Narratives

• Systems that generate a narrative SHALL include any information that is:

  • Required (1..)
  • Marked as MustSupport
  • Subject to obligations for the generating system

• The narrative SHOULD only include information that is represented in data elements within the instance of the FHIR resource.

Requirements for Receiving Narratives

• If a system receives a narrative and cannot process the FHIR resource in a structured manner, the receiving system SHOULD be able to present the narrative content to humans.

Implementation Considerations

• This implementation guide does not designate narrative as MustSupport because some downstream use cases (such as clinical decision support or analytics) may not need narratives, making them unnecessary overhead.
• Implementers MAY include narrative content when resources are exposed through standard RESTful APIs or in document bundles.
• Constraints on the text.div element MAY be strengthened in specific use case implementation guides.