General Principles & Design

Core and Core+

The CA Core+ Project is intended to cover the intepretation of pan-Canadian Health Data Content Framework (pCHDCF) constraints into pan-Canadian FHIR Profiles. This is expected to cover the constraints, raised in the pCHDCF, that are common and expected across all domains. This project also covers the efforts to ensure that the use case/context specific constraints, raised in the pCHDCF, are harmonized into pan-Canadian profiles.

The use of "Core" vs Core+" when referring to the profiles developed under this project is still evolving.

Early insights into profile patterning have been provided below. Reviewers are encouraged to provide feedback on the clarity and impact of this structure to help inform the approach moving forward.

  1. Common Data Exchange Profiles (referred to as CA Core profiles and housed in this guide) are intended to act as a base of constraints that are expected to be shared and demonstrated across Canadian FHIR implementations.
  2. Domain-Specific Data Exchange profiles (not currently included in the version of this guide) are intended to identify constraints that are applicable and expected under certain contexts* (e.g., Patient Summary). These profiles will likely continue to be housed in their respective guides, but will undergo harmonization efforts to incorporate changes from the pCHDCF.

*There is a possibility that patterns in constraints may arise that would allow for profiles to convey requirements that are only applicable to certain contexts/actors but are not necessarily domain-specific. Examples of this include additional requirements for practitioner license registration details to be supported by provider registry systems and/or organization details that are required for administrative services but are not required for the clinical coordination of care.

Two approaches that could be applied to these particular examples are: 1) the creation of CA Core Registry or Administrative profiles, or 2) the application of actor specific obligations on the CA Core profiles. Reviewers are encouraged to provide feedback on the impact of these two structural options on their own implementations. Reviewers are asked to weigh in on whether the use of the imposeProfile extension (or other mechanisms) resolves the concern of inheriting actor specific obligations that may not apply to the downstream guide.

Principles for Common Data Exchange (CA Core) Profiles

  • The intent of the profiles in this guide, is to form a set of constraints that are expected to be demonstrated across domains
    • Like other National Core profiles, these constraints are extended to extend beyond the constraints in the base FHIR specification or a National Base Specification (e.g., CA FHIR Baseline)
  • The purpose of conveying these constraints in the form of CA Core FHIR profiles is to build foundational capabilities in FHIR Servers and Apps to prepare them to meet foundational constraints that are shared across prioritized Pan-Canadian use cases (e.g., eReferral)
    • It will adhere to the general principle for base and core profiles to convey expectations for interoperability at the point of data being exchanged and not expectations of clinical or administrative user workflow or how health data is used.
  • To accomplish this, the profiles will need to be testable and modular – so that a vendor can combine the CA Core constraints + the use case constraints to arrive at the full set of requirements
    • For this reason, this specification will prioritize profiling mechanisms that support validation/testing (i.e., Test Driven Design)
  • The CA Core profiles must avoid duplication of constraints where they create confusion and burdens in users - and rely on the intended compilation features in FHIR
    • To this end, the profiles should attempt to leverage the CA FHIR Baseline as an artifact in that compilation - in ways that insulate against breaking changes (e.g., imposeProfile with version dependency)
  • The CA Core profiles will require a process to balance expectations, so they are reachable/testable while trying to be prescriptive enough to increase capabilities to meet the expectations of the pCHDCF