Pan-Canadian Patient Summary (2.2.0-ti-ballot)

ti-ballot - For a full list of available versions, see the Directory of published versions

Relationship to Other Specifications

This project leverages the ongoing effort from the IPS project which has an established content and data model informed by FprEN 17269:2019 from CEN/TC 251 which uses both the HL7® CDA and HL7® FHIR® standards.

However, the PS-CA Use Cases and the implementation ecosystem are not identical to IPS. For example, the PS-CA specification has to account for jurisdictional differences in the following: system capabilities, established charting practices, and change management capacity. Notably, the PS-CA also has to account for creation of Canadian patient summaries through provider-generated summaries (as a result of an encounter to provide a snapshot of the patient's health care) and Patient generated summaries ( Patient requests access to their Patient Summary via a patient facing application and share with their health care provider via QR Code or Shared Health Link).

As a result, the PS-CA has applied a slightly different approach in implementing the data model from the original IPS project. While the elements within the IPS data model remain the same, the expectations for when and how the elements are implemented require a more nuanced approach.

Alignment with the International Patient Summary Global Specification (IPS-UV)

As one of the early national adopters of IPS using FHIR, PS-CA (and its jurisdictional implementations) have worked extensively with the International Patient Summary FHIR working group to ensure the newest release of the IPS-UV specification adequately reflects expectations that are consistent and feasible for early implementers. Part of this effort involved working with IPS-UV to provide more clarity in their mustSupport definitions as well as working with IPS-UV to be more regimented in where MS flags were applied. Over thirty Must Support flags were removed from IPS-UV as part of the efforts to refine it based on implementer feedback.

With these changes, only a handful of elements remain that are marked as Must Support in the IPS-UV that could not be marked as Must Support in PS-CA v2.2.0 TI-Ballot. These elements are described in the section below and will be considered for tightening of constraints in a future PS-CA release.

Differences between the IPS-UV and PS-CA

Differences between the IPS-UV and PS-CA are largely limited to areas where further localization was required as well as a handful of areas where the PS-CA needed to relax system conformance expectations in the first version to align to "current state" jurisdictional capabilities.

Must Support Differences

Elements that IPS-UV considers Must Support that are not Must Support in PS-CA v2.2.0 TI-Ballot:

CodeableConcept.coding (change expected in IPS)
Composition.meta.profile
Composition.attester
Composition.event[careProvisioningEvent]
Patient.telecom
Patient.generalPractitioner
AllergyIntolerance.type
AllergyIntolerance.reaction.severity
Condition.category
Condition.severity
Medication.ingredient (backbone)
Medication.ingredient.strength
MedicationStatement.dosage.timing
MedicationRequest.dosageInstruction.timing

Obligation Differences

For the PS-CA v2.2.0 TI-Ballot version, a consistent set of Obligations has been applied to Must Support elements depending on whether the element is mandatory or optional.

For mandatory elements:

Producer SHALL:populate
Consumer SHALL:no-error
Consumer SHALL:handle
Consumer SHOULD:display

For optional elements:

Producer SHALL:able-to-populate
Consumer SHALL:no-error
Consumer SHOULD:handle

IPS has tailored the obligations to each element depending on context, but, in general, the most common obligations used in IPS are:

Creator (Producer) SHALL:populate-if-known
Consumer SHALL:handle
Consumer SHOULD:display

For most mandatory elements, IPS has specified SHALL:populate Creator obligations.

As the community gains experience with the use of Obligations, future releases of PS-CA will review Obligation requirements and adjust expectations for specific elements.

Domain Prioritization Differences

In order to maintain compliance with the IPS-UV, the PS-CA Composition has maintained the required cardinality on Medication Summary, Allergies & Intolerances, and Problem List sections. However, it provides clear guidance to implementers for what should be included within the section.entry element if:

for a given patient, no information exists for that section, or
the implementing system can not produce the section (due to lack of capability, jurisdictional restrictions, etc.).

The following figure represents the:

data domains of interest by the participating Canadian jurisdictions (including Manitoba (MB), according to their Home Clinic Client Summary Service). Note that although a PT may have identified interest in a particular data domain, they may choose to prioritize which data domains to include according to their individual Patient Summary roadmaps.
data domains included in each PS-CA version.

IPSPSCA Overview

Note: NS has implemented an Encounter Section (not shown in Table)

Legend

Blue: Header domains
Red: Required domains
Orange: Recommended domains
Green: Optional domains
Grey: Domains of interest by jurisdiction
Check mark : Domains included in PS-CA specification
White: Domains not identified by jurisdictions as priority and/or not included in the recent version of PS-CA

Internationally, the exchange of IPS‑aligned patient summaries is supported by companion specifications such as the IHE Sharing of IPS (sIPS) profile, which defines document‑based sharing patterns for IPS content using IHE document sharing infrastructure.

PS‑CA does not depend on or require the use of sIPS; however, this profile provides options for how IPS‑aligned summaries are consumed. PS-CA references the sIPS consumer options as helpful guidance for implementers. The sIPS does not replace PS‑CA’s own pan‑Canadian approaches to exchange, which are defined through specifications such as CA:FeX, MHD, and CA:SHL.

CA Core+

The pan-Canadian Patient Summary (PS-CA) specification is currently being aligned with CA Core+, a foundational set of FHIR profiles, extensions, and terminology artifacts designed to support healthcare interoperability across Canada. CA Core+ enables standardized data exchange and harmonizes both pan-Canadian and jurisdictional specifications.

This alignment effort has surfaced key opportunities for harmonization, including:

Priority data elements for interoperability,
Terminology binding inconsistencies, and
Variations in cardinality and constraints such as Must Support flags and required vs. optional elements).

While PS-CA does not currently reference CA Core+ profiles directly, future versions will formally derive from CA Core+, inheriting its core profiles and applying Patient Summary specific constraints. This strategy will strengthen interoperability, support the reuse of national profiles, and promote consistent implementation across jurisdictions.

Health Application Lightweight Protocol (HALO)

HALO is a pan-Canadian framework that enables SMART on FHIR applications to access clinical data. The PS-CA Implementation Guide is independent of HALO and does not require its use. However, PS-CA resources MAY be accessed and used within HALO-enabled applications to support real-time retrieval of a Patient Summary. See the HALO specification for details.

Use of CA Baseline Profiles

Recent work has removed all Baseline profiles from PS-CA, deriving from CA Core+ when appropriate, while keeping aligned. That is, constraints, must support and cardinality are still aligned with Baseline and past decisions.

Alignment Work Underway with Jurisdictions

Jurisdictional content is expected to meet the minimum expectations outlined in the PS-CA specification, this ensures that all implementors across the country are building from the same foundational data model (leading to economies of scale with vendors). With this approach, customizations and differences across jurisdictions are minimized to only implementation specific details (e.g., tighter constraints on elements that support specific integration requirements from jurisdictional health assets).

In the cases where jurisdictions have begun profiling work, the PS-CA specification development team has worked collaboratively with the jurisdiction to compare the specifications, align where appropriate, and identify any areas that need to be relaxed in the national profile, or resolved further through the international specification. Jurisdictional content developed after the initial draft of the PS-CA is published is expected to align to the minimum expectations outlined in the PS-CA specification and ideally directly derive from the profiles in the PS-CA FHIR® package.

Differences between the PS-CA and Jurisdictional Content

Jurisdictional content should never weaken or contradict the expectations defined in this specification. It is not expected to introduce looser constraints than those established by the PS-CA. Any additional constraints defined through jurisdictional content are expected to result from tightening PS-CA expectations. For example, a jurisdiction may apply a Must Support flag to an element that is identified for tightening in a future PS-CA release but is not yet required at the pan-Canadian level due to varying levels of support across participating jurisdictions.

In addition, some jurisdictions may introduce constraints on elements that are required to support integration with existing digital health assets. Examples include additional provider identity requirements needed to leverage established jurisdictional systems.

Understanding the scope of jurisdictional content is critical to interpreting the differences between these two types of content. To date, jurisdictional constraints reflect expectations only for systems that generate, store, and transmit patient summaries produced within that jurisdiction. These constraints are not intended to apply to summaries received from other jurisdictions and should not be interpreted as such.

Additional guidance on interpreting jurisdictional constraints will be provided in future releases as jurisdictions move to support inter-jurisdictional and international exchange of patient summaries.

Jurisdictional Patient Summary Content

Implementers are encouraged to review jurisdiction-specific implementation guides (IGs) and related project resources for additional constraints, localizations, and implementation details defined by each jurisdiction.

IG/Project Space	Link
PS-AB	Alberta Patient Summary FHIR Implementation Guide
PS-ON	Ontario Patient Summary FHIR Implementation Guide
PS-CA:NB	MyHealthNB Patient Summary Overview
PS-CA:BC	British Columbia Patient Summary FHIR Implementation Guide
NS	YourHealthNS Patient Summary Overview

This guide will continue to be updated as additional jurisdictions adopt the content present in this guide.