Profiling Conventions and Approach

This version of the PS-CA Implementation Guide has been superseded by a newer version. Other releases of the PS-CA Implementation Guide may be found on a table on the Home Page of this Project.

Must Support (MS) Constraint Approach

While this specification is intended to align to 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.

IPS-UV intends its must support definition to enforce the expectation that conformant vendors be able to show that their systems support those values regardless of the cardinality expectations. Some elements marked as MS in the IPS-UV are elements that some/all of our jurisdictional systems do not have discrete fields for today (based on analysis data dictionaries provided).

  • IPS-UV employs must support expectations on patient summary creators that challenges their approach towards open slicing to allow use of alternative code systems. This is an issue that IPS-UV is resolving in the Connectathon and CI Branches
    • PS-CA will follow the same approach in removing MS flags from optional open slices that force support of certain terminologies. This allows jurisdictional implementations to participate without having to modify their systems to be able to produce SNOMED CT Global terminology simply to show conformance to the specification.
    • Any elements that participating jurisdictions don’t support will be noted and validated through stakeholder review.

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, mustSupport 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 mustSupport data elements without generating an error or causing the application to fail.
  • SHOULD be capable of displaying mustSupport data elements for human use, or processing (e.g., storing) them for other purposes.
  • SHALL be able to process resource instances containing mustSupport 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 this element within the context of their own jurisdictional content.

Profiling Approach

Profiles from the STU1 Release of IPS-UV were initially reviewed as the starting point for the PS-CA profiles.

Gap Analysis

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

Where a gap was believed to be an over-constraint of the IPS-UV (e.g., profiling decision that went against their stated principles and intent), the most recent releases of IPS-UV (e.g., CI Build and Connectathon branch) 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 what gaps are tackled in the first draft versus which may need to be closed in later versions.

MS 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 MS 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 gap 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 MS 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/receivers particularly at a cross-jurisdictional level.

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

Initial work in Version 1.0 will focus on socializing 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 desired future state (e.g., as defined in coming months) to support implementation planning.

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

Socialization of SNOMEDCT-CA

  • As a general rule, the profiles will contain slices socializing SNOMEDCT-CA value sets if they exist for a concept and are recommended for use by the PS-CA Terminology team.

  • Where a recommended SNOMEDCT-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 SNOMEDCT-CA codes and communicate minimal information to readers about existing hierarchies in SNOMEDCT-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, 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 hardcoded 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 (e.g., can’t relax down 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 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 multiple new slices
    • Being 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 structureDefintion)

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 CA terminology in accordance with the criteria above, while being careful not to proliferate too many slices for the purpose of socialization that causes inheritance issues with derivative content

Where there is a required binding on a value set & a standardized Canadian code system exists that is not that value set

  • 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 minimum data set analysis + 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 in the PS-CA is determined on their relationship to the use cases in 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 needs to occur to confirm that even jurisdictions who do not support the creation of a certain section can still abide by the receiving rules to not generate an error/cause an application failure if they receive summaries that include sections

The following process is used to determine where MS 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 MS constraints applied

When only some jurisdictions have marked a section as mandatory and the rest consider it optional

  • The MS constraint and minimum cardinality can be maintained:
  • Systems that can support the clinical profiles referenced in these section that do not have content for a given patient should use the absent/unknown pattern in the clinical profile. systems that support the profile
  • Systems that wholistically cannot produce content for the profiles in these sections at the time of Version 1 of this specification should explore the use of the proposed new pattern outlined below:
    • This new pattern involves the use of the "contentNotSupported" profile to communicate if the producing system does not support the referenced required profile at the time of initial implementation
    • 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: This guide is specifically seeking feedback on the support of this pattern from the vendor/solution community to determine its feasibility before the V1 Trial Implementation. 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 initial implementations of Version 1.0

  • A note is included on the section noting expectations around receiving + that vendors should expect that some jurisdictions may further constrain support of this section within the context of their own jurisdictional content

  • MS flags on items within a section (e.g., title, code, entry) are maintained even if a section is not marked MS, this ensures that vendors who do claim support for certain sections still have expectations for what those sections will entail