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

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:

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

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

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