This is the current version of the PS-CA Implementation Guide. Other releases of the PS-CA Implementation Guide may be found at Guides.

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 optional slices, 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 consistant and feasible for early implementers. Readers are encouraged to explore the following pages to learn more about the relationship between PS-CA and IPS and PS-CA and Jurisdicational Content.

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

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.

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 contain slices socializing SNOMED CT Canadian Edition (SNOMED CT-CA) value sets if they exist for a concept and are recommended for use by the PS-CA Terminology team.

  • 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.

Where slices aren’t mandatory in IPS-UV Specification

  • Don’t modify the slice; instead, introduce an additional slice that has a preferred standardized Canadian value set (when one is known and published in FHIR)

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)
  • Unless there is clear rationale for why a national standardized Canadian value set should supersede the preferred international value set, the bound value set should remain the same and slices should be used to socialize the national standardized value set
  • Develop a slice where appropriate (if slicing is open + criteria below are met)
    • If no standardized Canadian value set exists that is of equivalent scope and not subsumed by the original value set – keep the existing value set with set strength
    • If a standardized Canadian value set exists that is of equivalent scope and not subsumed by the original value set – make an optional slice

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

If multiple standardized Canadian value sets exist

  • Determine if there is a need to apply constraints for those value sets in the form of multiple new slices
    • Be careful not to force inheritance if jurisdictions are expecting to further constrain the content
  • Balance this approach with other ways to socialize the terminology (e.g., providing the code systems as examples in the StructureDefinition)

Slicing

  • Maintain IPS slices that are optional to encourage proliferation of international value sets even if they are not in use in Canada today
  • Introduce new slices for standardized Canadian terminology in accordance with the criteria above, while being careful not to proliferate too many slices for the purpose of socialization, which may cause inheritance issues with derivative content, and dilute the apparent strength of a preferred terminology

Where there is a required binding on a value set, for which an alternative standardized Canadian value set exists

  • If multiple codings are allowed, create a slice on coding show that an alternative coding can be sent alongside the required coding as long as they describe the same codeable concept

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 absent/unknown pattern in the clinical profile.
  • Systems that wholistically cannot produce content for the profiles in these sections at the time of Version 1.0 of this specification should use of the proposed new pattern outlined below:
    • Use a "contentNotSupported" profile to communicate that the producing system does not currently support the referenced required profile
    • This pattern is considered a temporary measure to allow for patient summaries to be exchanged in Canada (and internationally) while some systems work to meet the expectations for the full set of patient summary sections.
    • Note: Feedback is requested on the support of this pattern from the vendor/solution community to determine feasibility. This approach is likely to evolve as Canada and other national implementations work with the IPS-UV team to identify a pattern for national implementors to account for differing levels of domain prioritization early on in adoption.

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