Pan-Canadian Patient Summary (PS-CA) CI Build

General Principles & Design

Releases of the PS-CA Implementation Guide may be found on a table on the Home Page of this Project.

General Principles and Design

Intent

Develop PS-CA as a nationally localized version of the International Patient Summary (IPS) that supports the cross-border exchange use cases outlined in the International Patient Summary, while also customizing it to include additional pan-Canadian concepts where appropriate so that it might serve as a base for Canadian jurisdictions to begin implementing patient summaries.

High Level Design Principles for the Pan-Canadian Patient Summary (PS-CA)

The following principles were developed and approved by the Pan-Canadian Interoperability Coordinating Table to guide the development of the PS-CA Specification:

Be based on a consensus driven, co-design approach with jurisdictions, providers and other key stakeholders
Be patient- and provider-centered, with considerations for clinician and patient needs and expectations, and with consideration for the impacts to clinician workflow and clinical processes
Promote efficiency for vendors with respect to solution investment and testing, and incorporate vendor community needs
Be inclusive and mindful of the change management considerations of the Patient Summary
Be based on one data model for national use, that allows for jurisdictional implementation guides which clarify provincial use (e.g., support jurisdictional code/value sets)
Consider the four use case scenarios associated with the IPS (scheduled and unscheduled local care; scheduled and unscheduled cross-border care)
Be based on iteration to occur over time, in a series of versions
Consider the design of extensions (including those planned by jurisdictions) in a manner that enables adoption at the pan-Canadian level

Releases of the PS-CA Implementation Guide may be found on a table on the Home Page of this Project.

Profiling Conventions and Approach

Adapting the International Patient Summary (IPS)

The pan-Canadian Patient Summary Interoperability Specification (that this guide belongs to) is an implementable, testable specification, based on the IHE International Patient Summary (IPS) specification and the HL7 IPS Implementation Guide. Both international specifications are considered Trial Implementation and continue to evolve through feedback from implementers.

The PS-CA FHIR profile set will be as closely aligned to the HL7 IPS-UV specification as possible in order to allow vendors in Canada to implement patient summaries aligned with local needs. This means that every effort will be made to adopt the international specification and analyze its constraints with practical implementations in mind.

The PS-CA specification attempts to profile in a way that allows the patient summaries (instances) to be conformant to the IPS-UV specification without having to formally derive from the profiles.

This means that instances should be able to conform to the IPS-UV specification even if the generating implementation does not fully meet the IPS-UV expectations for being able to generate all additionalBindings, demonstrate support of all Must Support elements, etc.

In places where profiling of the PS-CA uncovers challenges with the IPS-UV (e.g., IPS-UV incorrectly applies slicing or applies Must Support flags to elements not utilized in Canadian workflows) these challenges are noted and brought forth to the IPS FHIR team through formal change request mechanisms.

As one of the early national adopters of IPS using FHIR, PS-CA (and its jurisdictional implementation - PS-ON) 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. Readers are encouraged to explore the following pages to learn more about the relationship between PS-CA and IPS, PS-CA and Jurisdictional Alignment. As well as PS-CA and Jurisdictional Context.

Derived vs. Aligned Profiles

While this specification is intended to align with the International Patient Summary specification in a way that allows instances to be conformant to PS-CA, IPS-UV, and the CA Baseline, a decision has been made to delay formally deriving from the IPS-UV until issues regarding Must Support (MS) flag inheritance have been resolved and a roadmap exists regarding system conformance expectations.

Must Support (MS) Constraint Approach - Alignment with IPS

See Must Support definition.

Some elements marked as Must Support in the IPS-UV are elements that some (or all) of our jurisdictional systems do not have discrete fields for today (based on analysis data dictionaries provided).

PS-CA and PS-ON teams have worked extensively with the International Patient Summary FHIR working group to ensure the newest release of the IPS-UV specification adequately reflects mustSupport expectations that are feasible for early implementers to demonstrate.

Must Support Expectations

Since Must Support expectations are inherited into any derivative guides, the PS-CA definition of Must Support differentiates between instance and system conformance and the negotiation of currently-not-supported elements is fundamental to arriving at a PS-CA that any jurisdiction could reasonably inherit from.

In the context of the PS-CA, Must Support on any data element SHALL be interpreted as follows:

Implementers conforming to the PS-CA Implementation Guide, when creating patient summary content

To be considered a conformant vendor you SHALL show that your system is capable of producing a value for that element
To produce a conformant instance you SHALL show that your system can send/relay the data if available and appropriate

Implementers conforming to the PS-CA Implementation Guide, when receiving patient summary content

SHALL be capable of processing resource instances containing Must Support data elements without generating an error or causing the application to fail.
SHOULD be capable of displaying Must Support data elements for human use, or processing (e.g., storing) them for other purposes
SHALL be able to process resource instances containing Must Support data elements asserting missing information

Note: While coding is not currently considered must support in Version 1.0, implementers that support codings should still send the codings for codeable concepts if they are available and receivers should not produce failures or rejections if codings are included in the patient summary in the version (a base tenet of FHIR®).

Additionally, vendors should expect that some jurisdictions may further constrain support of coded elements within the context of their own jurisdictional content.

Missing Data Expectations

Optional Data Elements

If the system generating the data does not have data to be included in the patient summary, the data element is omitted.

Required Data Elements

Reason for absence of data needs to be speficied. It may be indicated in the two following ways:

Non-coded Data Elements

Example: While the birthDate element requires a value, if the exact date of birth is unknown, only the known portion of the date (e.g., the year) should be provided without estimating or inferring unknown parts of the date. Use of the Data Absent Reason is appropriate when the date of birth of an individual cannot be determined.

Coded Data Elements
- For preferred, example, or extensible binding strengths:
  - If the source system has no coded data, only the text element is used
  - if there is neither text or codes representing actual (i.e non-exceptional) concepts:
    - use the appropriate exceptional concept code from the value set if available
    - use the appropriate concept code from the Data Absent Reason Code System if the valueSet does not have it.
- For required binding strength:
  - use the appropriate exceptional concept code from the value set

Masked Data Handling

General Guidance

The emptyReason element can be used to indicate that an entire section of the patient summary (e.g., Procedures) is withheld due to privacy or consent restrictions. This allows the system to convey that data exists but cannot be shared, ensuring transparency.

Section-Level Masking: Use section.emptyReason when a full section of data is unavailable for privacy reasons, applying codes such as "withheld" to explain why the section is absent.

Jurisdictional Policy Alignment

Each jurisdiction may have different regulations and requirements regarding data withholding based on privacy preferences or legal obligations. Implementers must ensure that the masking of data using section.emptyReason is in compliance with local laws and regulations.

Query Response When the Data Is Masked:

When the patient summary is masked (fully or partially) due to privacy or consent reasons, there are two ways the response can be returned:

Return an OperationOutcome (Preferred for Fully Masked Data): When the entire patient summary is masked and no data can be shared, an OperationOutcome should be returned, with issue.code set to "suppressed", to explicitly indicate that the patient summary is withheld due to privacy restrictions. This approach minimizes complexity and avoids the need for generating a fully masked Document Bundle.
Return a Masked Patient Summary (Bundle Response for Partial Masking): If some sections can be shared while others are masked, return a Bundle containing the mandatory Composition and Patient along with other applicable entries. Masked sections should use section.emptyReason to explain why the data is withheld, maintaining the structure of the summary.

Jurisdiction-Specific Handling for Masked Data Responses

Jurisdictional policies may dictate the appropriate method for handling both fully masked patient summaries and masked sections. Some policies may allow informing the requester that the summary or section exists but is blocked (e.g., using OperationOutcome with issue.code set to "suppressed"), while others may require returning a "not found" response to avoid residual disclosure of sensitive information.

Profiling Approach

Profiles from the STU1 (Standard for Trial Use 1) Release of IPS-UV were initially reviewed as the starting point for the PS-CA profiles.

Gap Analysis

Using data dictionaries provided by the participating jurisdictions, gaps were identified where any participating jurisdiction did not currently support an element that had an IPS constraint on it (e.g., marked as Must Support or as having minimum cardinality).

Where a gap was believed to be an over-constraint in IPS-UV STU1 (e.g., profiling decision that went against their stated principles and intent), more recent releases of IPS-UV (e.g., CI Build and Connectathon branches) were reviewed to determine if the gap was resolved by the IPS-UV since the initial balloted specification. Where the over-constraint was not corrected, it was surfaced as in imperfection to the IPS-UV team.

Any gaps that were due to limitations of current systems were noted, sized, and brought forth to the Coordinating Table with recommendations and rationale for which gaps should be addressed in more immediate versions versus which may be closed in later versions.

Must Support Flags

Avoid relaxing must support flags where the gap analysis indicates that the gap may be reasonably filled (more than 50% of jurisdictional data dictionaries support the concept). Identify these through the gap analysis and surface to the participating standards teams and ultimately to the Coordinating Table.

Elements originally marked Must Support that showed larger gaps in support should be noted through comments and surfaced to the participating standards teams to validate whether or not the data dictionary reflected current capability of systems to support the element. Confirmed sizeable gaps should be put forth for relaxation according to the process agreed on by the executive committee and the Coordinating Table.

See Approach to Composition Section, below, for details on how Must Support flags on composition sections were handled when the section had mixed support in Version 1.0.

Cardinality

Avoid relaxing cardinality and terminology constraints where it is possible to take an alternative approach

Implementing Canadian Terminology Where Appropriate

PS-CA encourages global interoperability where possible (for the focus around international exchange) while also promoting and socializing standardized Canadian terminology in use today for the purpose of greater harmonization and transparency between creators and receivers, particularly at a cross-jurisdictional level.

Work has begun to identify the standardized terminology used nationally, as well as jurisdictionally. The approach to the work to identify and recommend national and jurisdictional terminology can be found on the Terminology Approach page.

Initial work in Version 1.0 will focus on socializing (that is, raising awareness of, and encouraging use of) standard terminology available in the current landscape, but this work will the basis to understand the gap between current state terminology/value set implementation and yet-to-be-defined desired future state to support implementation planning.

Caution has been applied to avoid relaxing terminology constraints where it is possible to take an alternative approach.

Socialization of SNOMED CT Canadian Edition

As a general rule, the profiles will indicate through the main binding which terminology is recommended. Where SNOMED CT Canadian Edition (SNOMED CT-CA) value sets if they exist for a concept they are typically indicated as preferred.
Where a recommended SNOMED CT-CA value set does not exist on the Infoway Terminology Gateway, an interim approach has been applied. A "stub" value set resource is created that the profiles can point to. These encourage the use of SNOMED CT-CA codes and communicate minimal information to readers about existing hierarchies in SNOMED CT-CA without needing to identify the full list of codes.
One downside of these stub value sets is that they do not have the full benefits of a value set that is hosted on a terminology server with validation operations which allow implementers to check instance conformance against.

Socialization of Other Structured Terminologies

In prior releases, both IPS and PS-CA leveraged the use of slicing to model additional terminology that might be used or expected to be used in certain contexts.

Since then, a more appropriate mechanism in FHIR has been developed to communicate this: additionalBinding Extension. Both IPS and PS-CA have replaced the use of slices with the additionalBinding Extension.

Where a value set is required in IPS-UV/Base FHIR Specification

If the values can be reasonably fixed, or are determined to have appropriate semantic mappings to standardized national or jurisdictional codes (e.g., absentOrUnknownAllergyIntollerance), maintain that value set and provide guidance and support in mapping

Where a value set is preferred in IPS-UV/Base FHIR Specification

Follow binding strength rules (i.e., not permitted to relax a preferred value set to example)
If a standardized Canadian value set exists that is of equivalent scope and not subsumed by the IPS value set – modify the primary binding value set to the standardized Canadian value set (with preferred strength)
- Identify the IPS value set as an additionalBinding (if not fully subsumed by the standardized Canadian value set)

Where a value set is an example in the IPS-UV/Base FHIR Specification

If the binding strength of the value set is example and there is a standardized Canadian value set – the value set can be replaced with the preferred standardized Canadian value set without need for an additionalBinding for the optional value set

If multiple standardized Canadian value sets exist

Determine if there is a need to apply constraints for those value sets related to the context of their use - use additionalBinding if necessary to convey any expectations
Balance this approach with other ways to socialize the terminology (e.g., providing the code systems as examples in the StructureDefinition)

Extensions

Introduce standardized Canadian extensions that are critical for care in Canadian Context when they are known.

New extensions will not likely be produced in the first version
The jurisdictional minimum data set comparison and the CA Baseline can be used as starting points for what extensions may already be in use in the Canadian landscape
- socialization of these extensions is predicated by their relationship to the use cases in PS-CA version 1.0 (e.g., if an extension exists for aboriginal identity group but exchange of this information is not a requirement for the use cases, the extension is not included in the PS-CA)
- Jurisdictions are encouraged to review standardized extensions in use in Canada and use them where they deem appropriate
Jurisdictions that would like to enforce the use of certain extensions for their own purposes should do so in their jurisdictional content
Any implementation specific extensions (e.g., PrescribeIT extensions) likely go beyond the use case scope for minimum critical

Approach to Composition

The composition profile should allow for jurisdictions to prioritize what domains their patient summaries must support and mandate in their initial implementation.

Some jurisdictions will consider a section optional, while others may not support the creation of that section at all
Further discussion to clarify whether jurisdictions which do not support the creation of a certain section would still abide by the receiving rules to not generate an error/cause an application failure if they receive summaries that include those sections

The following process is used to determine where Must Support flags were placed in the first version of the PS-CA Composition Profile:

When all jurisdictions have marked a section as mandatory

The section can have minimum cardinality of 1 and Must Support constraints applied

When some jurisdictions have marked a section as mandatory, and the others consider it optional

The Must Support constraint and minimum cardinality can be maintained
Systems that support the clinical profiles referenced in these sections, and that have content for a given patient, should produce the section.
Systems that support the clinical profiles referenced in these sections, but that do not have content for a given patient, should use the Composition.section.emptyReason.
- Some systems may still be utilizing the Pseudo resource pattern that uses an "empty" resource to conveys either a) that information is unknown, as well as B) asserting there is no known medications, allergies, or problems for the patient. Receiving systems SHALL not reject patient summaries that use this convention for unknown information while implementers work on transitioning to the preferred modeling.

When some jurisdictions consider a section mandatory or optional, but others have decided not to include it in their implementation of PS-CA Version 1.0

A note is included on the section identifying expectations around receiving patient summaries, and that vendors should expect some jurisdictions may further constrain support of the section within the context of their own jurisdictional content
Must Support flags on items within a section (e.g., title, code, entry) are maintained even if a section is not marked Must Support, this ensures that vendors who do claim support for certain sections still have expectations for what those sections will entail

Releases of the PS-CA Implementation Guide may be found on a table on the Home Page of this Project.

Terminology Approach

The PS-CA specification promotes two simultaneous goals for terminology. It promotes standardized Canadian terminologies in use today for the purpose of facilitating semantic interoperability within and across jurisdictions through the exchange of patient summaries. These are referred to as the Proposed Pan-Canadian Value Sets.

The PS-CA specification also encourages global interoperability where possible for international exchange. Value sets that have been defined by the HL7® FHIR® Base Standard or by the IPS Specification for the purposes of interoperable international exchange are referred to as the Global Value Sets. The SNOMED CT IPS Free Set (IPS Free Set) Value Sets are included in this category.

Note: The IPS free set value sets, while helpful for exchange of summaries with countries that do not have SNOMED CT licenses, are not intended to reflect the breadth and complexity of other SNOMED CT value sets used in clinical care today. Readers are encouraged to further review the IPS Guidance on use of the IPS Free Set.

Work towards developing PS-CA version 1.0 focuses on standard terminologies available in the current landscape. When a jurisdiction uses an alternative terminology that is different from the proposed Pan-Canadian Value Sets (local terms that are from an alternative standard, or non-standardized, value set), these are identified as Local Value Sets.

The work to identify all three types of terminology provides the basis to understand the gap between "current state" terminology/value set implementation and desired future state alignment to nationally and internationally recommended terminologies and value sets.

Given these goals, this guide employs a number of profiling mechanisms to socialize terminologies in use locally and facilitate the implementation of standardized terminologies in use nationally and globally.

Terminology Mechanisms

Terminology Binding at Element Level

Profile elements with coded datatypes (e.g., code, Coding, CodeableConcept) often have bindings to FHIR ValueSets noted in their StructureDefinitions. The strength of these bindings (required, extensible, preferred, or example) help implementers determine conformance expectations for what values should be used for the element.

Currently, this specification applies a preferred binding on the Proposed Pan-Canadian Value Sets, when feasible. While earlier versions of the specification inherited a preferred binding to the global value sets from IPS-UV, early feedback from the implementer community outlined the need to prioritize domestic jurisdictional—rather than international—exchange in Version 1.0.

Socialization of Other Structured Terminologies

In prior releases, both IPS and PS-CA leveraged the use of Slicing to model additional terminology that might be used or expected to be used in certain contexts.

In a handful of areas where the Base FHIR specification has a required binding on a CodeableConcept (and there is evidence of substantial use of legacy code systems like v3), slicing has been maintained. This has been done to demonstrate that the required coding must be sent, but the legacy coding that is a semantic match can still be sent as an additional coding.

Multiple Codings to Represent a CodeableConcept

The ability to supply multiple codings for a given CodeableConcept is highlighted in this guide to ensure implementers have a way of supplying the original term that was captured.

This is particularly useful for elements that have a value set mandated by the FHIR R4 standard, but are anticipated to be captured in Canadian systems using an alternative terminology. One example of this is the AllergyIntolerance.clinicalStatus element. FHIR R4 standard requires the use of the AllergyIntolerance Clinical Status Codes value set which includes three concepts: active, inactive, resolved. Canadian systems implementing V3 ActStatus concepts for allergy capture (e.g., Newfoundland) will map to those three concepts but will likely also want to supply the original coding which may provide additional detail. An example of how this would be modelled in a patient summary can be found below.

"clinicalStatus" : {
    "coding" : [
      {
        "system" : "http://terminology.hl7.org/CodeSystem/allergyintolerance-clinical",
        "code" : "resolved"
      },
      {
        "system" : "http://terminology.hl7.org/CodeSystem/v3-ActStatus",
        "code" : "completed"
      }
    ]
},

Must Support Flags

Must Support flags are used in combination with slices to identify which standard terminologies vendors are expected to demonstrate they can support for a given release and/or use case. In this release, Must Support flags are only applied to the Data Absent Reason slices as this is a fundamental concept that every implementer is expected to be able to support.

As the specification evolves, implementers should anticipate that additional Must Support flags may be added to other slices to support future use cases that may have additional terminology requirements (e.g., global exchange with a country without a SNOMED CT license).

Stub ValueSets for Exposing Terminology

Stub value sets are another mechanism used in this guide to create a resource with pointers to referenced ValueSets that are not available at their canonical URL or on the terminology servers used in IG publication (i.e., tx.fhir.org).

While these stub value sets cannot be used in conformance testing (see Known Issues & Future Development ), these stand-ins allow for additional details to be provided, such as the website pages where implementers can find and download the value sets in their entirety (e.g., Terminology Gateway, National Vaccine Catalogue).

Terminology Selection and Approach to Value Sets

The scope of PS-CA value sets is confined to HL7 IPS FHIR profiles that have existing terminology bindings defined for data elements. The following principles were used to guide the development and definition of the value sets required for the PS-CA profiles.

The PS-CA value sets have to:

Support semantic interoperability and implementation in Canada over the short- and long-term.
Align and support national terminology policy such as SNOMED CT Canadian Edition, Canadian Clinical Drug Data Set (CCDD), and pan-Canadian LOINC Observation Code Database (pCLOCD) (see below).
Accommodate the requirements of jurisdictions where feasible.
Take into consideration the guidance from the Global Digital Health Partnership (GDHP), which recommends the use of SNOMED CT in specific clinical domains.
Take into consideration the terminology binding strength of existing required value sets to ensure there is no disruption in interoperability.
Take into consideration that FHIR is a data interoperability standard and value sets developed are suited for data exchange and may be broader than value sets used at the point of care.
Include clinical review and stakeholder input and quality assurance processes.
Include formal documentation of the approach, decisions, characteristics of these value sets, and maintenance processes.
Identify opportunities for multi-use value sets, where a single value set is relevant for multiple data elements (create once, use many times).

Terminologies and Classifications - Current and Future State

Current state health system clinical terminologies and classifications identified as national standards and in use across jurisdictions include:

SNOMED CT Canadian Edition (SNOMED CT-CA)
International Statistical Classification of Diseases and Related Health Problems, Tenth Revision, Canada (ICD-10-CA)
International Classification of Diseases, Ninth Revision, Clinical Modification (ICD-9-CM)
Canadian Classification of Health Interventions (CCI)
Logical Observation Identifiers Names and Codes (LOINC)
pan-Canadian LOINC Observation Code Database (pCLOCD)
Canadian Clinical Drug Data Set (CCDD)
Licensed natural Health Products Database (LNHPD)
HL7 Vocabulary

In addition, across jurisdictions there is extensive use of free-text and locally defined term sets used for health information data capture.

In the future, it is expected these major terminologies and classifications will continue to exist and that there will be an increase in the use of SNOMED CT-CA in place of free-text or locally defined term sets for health information exchange and data capture.

Terminology Management

Terminology owners often update their code systems and value sets over time: retiring concepts, adding new ones, modifying relationships, etc. Consistent with common FHIR practice, and general best practice, terminologies used in this Implementation Guide should be "current at time of application," except when specific versions of CodeSystems or ValueSets have been identified within PS-CA. Implementers should be cautious of recognizing only the terminology in effect at the time of publication of the PS-CA Implementation Guide, or only the terminology in effect at time of system implementation. PS-CA Patient Summary documents should use current-at-time-of-creation terminology. However, since Patient Summary documents may have an extended life, recipient systems should be designed to accommodate out-of-date codes.

This release of the PS-CA Implementation Guide does not specify conformance expectations around terminology versioning (support of specific terminology versions, handling of obsolete concepts, etc.); however, future updates to the guide, or conformance programs, may define specific requirements.