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

Must Support Definition

In the context of the PS-CA, Must Support data elements are interpreted as follows:

For Implementers Creating Patient Summary Content (Senders):

• Senders SHALL demonstrate that the system can produce a value for the Must Support element.
• Senders SHALL ensure that the system can send/relay the data if available and appropriate (pertinent to the current clinical context or patient summary being generated).
• For elements not marked as Must Support: Senders MAY still populate these elements where applicable, although the Implementation Guide does not impose strict expectations. The decision to include non must support elements (or extensions) depends on jurisdictional requirements, providing flexibility for implementers to use these elements as needed without making them mandatory across all implementations.
  • Note: If an element is mandatory but not marked as Must Support, a fixed value can be sent without the expectation that the system must be capable of producing or populating that value.

For Implementers Receiving Patient Summary Content (Receivers):

• Receivers SHALL be capable of processing resource instances containing Must Support data elements without generating an error or causing the application to fail.
• Receivers SHOULD be capable of displaying Must Support data elements for human use, or processing (e.g. storing) them for other purposes.
• Receivers SHALL be able to process resource instances containing Must Support data elements asserting missing information.
• For elements not marked as Must Support: Receivers MAY accept and process these elements without generating an error, even if the system is not required to display or fully process them, ensuring robust handling of these elements in patient summaries.
  • Note: If an element is mandatory but not marked as Must Support, there is no expectation that the receiving system must process, display, or store that element.

Notes:

• Must support definition pertains to the base capabilities of systems that generate and/or consume patient summaries in Canada - with the expectation that business rules, regulations, policies, etc. within a jurisdiction and/or implementation determine how these elements are implemented, used, etc.

• While coding is not currently considered must support in version 2.0.0-DFT-Ballot, 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 (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.

Must Support Expectations: Backbone/Parent & Child Elements

In FHIR profiles, Must Support (MS) flags may be applied differently to parent and child elements, leading to different implementation expectations. It is essential to understand these different Must Support scenarios to implement FHIR profiles appropriately:

Scenario 1: When the Backbone/Parent Element is Marked as Must Support but the Child Element is Not

If the parent element is marked as Must Support, systems are expected to support the parent structure. However, the child elements under that structure do not need to be supported unless specifically required by the profile or the implementation. In this scenario, systems should apply a "reasonable approach" — meaning that supporting only the parent element without addressing essential child elements would not be considered a reasonable or compliant implementation. For example, supporting only an address type in an address structure while ignoring the actual address content would not meet expectations for a complete and useful implementation.

Furthermore, handling child elements in structures like CodeableConcept can vary based on the use case. In some cases, supporting only the text field of CodeableConcept may be acceptable, but it depends on the specific clinical context and the importance of the child elements within that context.

To avoid ambiguity in Must Support requirements, it's often helpful to define tighter expectations within the profile by clearly marking Must Support down to the child elements, especially when these child elements are critical for clinical purposes. Profiles may consider defining data type profiles that explicitly define Must Support and then referencing them in relevant sections, ensuring clarity for implementers about which exact child elements must be supported.

Scenario 2: When the Child Element is Marked as Must Support but the Parent is Not

This scenario reflects a conditional Must Support requirement. Even though the parent element is not Must Support, if the child element is marked as Must Support, systems are required to support the child element if the parent element is used. This ensures that when the parent element is included, all Must Support child elements must be processed and handled correctly.

See for example Quality, which has child elements marked as Must Support, Data Type: Quantity (PS-CA). If the Quality element is not Must Support but included in a resource, the children system and code must be processed and handled correctly.

Known Issues & Future Development

During development, several issues were detected that could not be resolved in time prior to publication; issues with multiple—but no "best"—solutions possible; and issues with conflicting guidance. Some of those issues are listed below. Open issues are those for which no decision has been made, are pending feedback, or, for which there is an outstanding action. Issues are marked as close when a decision has been made, or the issue resolved.

Feedback is requested on both open and closed issues.

Known Issues

1. Validation Tooling - Expanding Value Sets / Intersectional Value Sets

   There are two tooling issues leading to IPS value sets not being expanded and validated against by current FHIR tools:

   1. The is a current limitation in Simplifier validation tooling to perform expansion and filter capabilities that are necessary for the validator to determine if a slice is met on loaded examples.
   2. More broadly, there is a known issue with the FHIR Validator Tooling/FHIR terminology server that the validator uses (tx.fhir.org) not supporting value sets that combine multiple value sets and/or apply filters as part of the sequence for defining the value set (an approach IPS uses for many of its value sets).
      • After this fix is applied, Implementers will be able to validate the examples including IPS value sets against the FHIR Validator GUI - IG Package is loaded and can be validated against by selecting "Options" and then choosing "https://packages.simplifier.net/ca.infoway.io.psca" from the dropdown of Implementation Guides.

2. Referenced ValueSets and CodeSystems are not resolvable.

   Some referenced ValueSets are not available at their canonical URL; some (particularly Canada-specific) ValueSets are not on the terminology servers used in IG publication (i.e. tx.fhir.org). Some referenced ValueSets are not currently available as FHIR R4 and may require conversion before use. Primarily, these issues impact validation against Canada Health Infoway-hosted ValueSets during development of derived Implementation Guides. (This doesn't affect deployed systems, since, in that environment, instances will be validated against locally present value sets.) For several of these ValueSets, "stub" resources have been created to stand-in within this Implementation Guide for the unresolvable ValueSets.

   Current guidance is to manually download the referenced value sets from, for example, the Terminology Gateway. Investigation is needed to determine if the problem ValueSets can be made "resolvable" through Infoway, or if they can be added to the standard terminology servers.

3. Must Support Relaxation

   Several elements flagged as Must Support in IPS-UV are not flagged in PS-CA due to feedback received about jurisdictional support. These elements are called out on relevant profile pages in this implementation guide. Feedback is requested about:

   • Whether it was appropriate to relax the Must Support requirement for these specific elements
   • Whether Must Support should be relaxed or added on additional elements

4. IPS 2.0.0-Ballot Terminology Realignment

   As part of the IPS 2.0.0-Ballot release, in consultation with SNOMED International, there are several changes in terminology bindings (see https://jira.hl7.org/browse/FHIR-46365 for additional details).

   • SNOMED has codes for absent/unknown, so there is no longer a need for separate IPS absent/unknown codes
   • SNOMED IPS FreeSet is no longer identified as a separate/additional binding, as they are part of the full SNOMED CT.
     These changes have been applied to PS-CA, and need to continue to be assessed within the Canadian implementors landscape, in conjunction with ongoing efforts to transition to the Canadian Terminology Server. Additional details will follow in the next PS-CA release.

5. Packaged Profiles do not include Snapshots

   Current tooling is unable to generate FHIR profile snapshots when creating packages for this project. If you wish to retrieve the snapshots for a particular profile, you can select the "Download snapshot as XML/JSON" option from the respective profile page within the Simplifier project (top-right corner of the project profile page, not the IG page)

6. Examples files may have validation errors

   • Some validation tooling are indicating errors with the fullURL values currently in the examples. We are investigating this, and will provide updated examples in an updated release if necessary.

7. Canonical URL mismatches identified as errors using IGPublisher

   • When using IGPublisher with the PS-CA FHIR profiles and valuesets, IGPublisher will identify errors with Canonical URLs not matching the resource URLs. This applies to includes extensions from PrescribeIT and from TerminologyGateway Stub ValueSets. IGPublisher expects all input conformance assets (profiles, valuesets, codesystems, extensions) to share the same base URL fhir.infoway-inforoute.ca/io/psca/.

Closed Issues

1. AdditionalBinding Rendering

   This version introduces the AdditionalBinding Extension which has been utilized by IPS since the IPS 1.1.0 release to convey additional terminology that is relevant under certain contexts (e.g., proposed for use with countries that do not have SNOMED CT licensing, utilized heavily in legacy data, etc.). See

   Command 'pagelink' could not render: Page not found.
   .
   • This extension is applied to the binding element and renders in IGPublisher now renders in Simplifier.

2. individual-RecordedSexOrGender Cross-Version Extension

   This version socializes the RecordedSexOrGender Extension. Previously, tooling required for it to be "re-published" in this guide to pre-adopt an extension published in R5. The HL7 Extensions Pack now includes both the R5 and R4 versions of this extension and dependencies have been updated accordingly.

Note: To view previously closed issues please review prior versions of the PS-CA. You may find the previous versions of the guide here.

Tooling & Validation

Companion to many interoperability specifications is conformance demonstrations and testing. Conformance can be tested at several points and at several layers; for example, validation of document content or messaging behaviour. Such activities help ensure interoperability between implementations, easing deployment and reducing post-deployment issues.

Canada Health Infoway envisions a range of proof-of-conformance activities to go alongside the PS-CA Specification as part of a larger interoperability program, including:

• FHIR resource validation
• IHE Connectathon-style peer-to-peer testing
• On-line demonstrations

The conformance plan will allow flexibility to accommodate for anticipated jurisdictional tailoring of PS-CA. As of the publication of this implementation guide, the exact nature of these activities is still to be determined.

To complement a Canada Health Infoway conformance plan, implementers are directed to the Conformance and Validating Resources in the FHIR specification.

Validation Tools

Open source, publicly accessible, and commercially available validation applications and websites may be useful to implementors who desire to check their products. Some of these include:

• the official Java FHIR validator (documentation),
• an online version of the official validator,
• the US ONC's Inferno Validator, and
• other validators.

Generally, the application or website is given:

• a resource or bundle of resources,
• an implementation guide package (in this case, the PS-CA release package, available on this site)
• and a profile to validate the resource against.

Using tooling to test and validate against the PS-CA Package

The HL7 FHIR Validator GUI is one of the most straightforward ways of validating example resources to determine if they meet constraints in this guide. The constraints in this guide have been pre-loaded in the form of a package to the registry so that it can be easily selected in the HL7 FHIR Validator interface.

To validate an example:

1. navigate to https://validator.fhir.org/
2. click the "options" button on the top left corner of the site header
3. scroll down to "select an IG" to validate against
4. select the "ca.infoway.io.psca" IG from the dropdown menu
5. select the "IG version" that you would like to validate against
6. click "Add+" to add the IG version to the list of IGuides that the example will be validated against (you can validate against multiple IGs at once)
7. scroll back up to the "Validate" button in the top left corner of the site header
8. load the example for validation by either copy/pasting it into the "Enter Resource" window, or upload the example(s) through the "Upload Resources" window
9. click the "Validate" button on the bottom of the page
10. the results (errors, warnings, information messages, etc.) of the validation will be displayed at the bottom of the page

Notes:

1. Unless a validator can be loaded with the PS-CA-referenced terminology or can be directed at a terminology server that supports PS-CA terminology, an otherwise complaint PS-CA resource instance may receive validation warnings & information messages due to terminology not being able to be checked. None of the listed online validators are currently aware of all PS-CA code systems or value sets.

2. The above list of applications and websites is not exhaustive. Inclusion in the above list is not a recommendation by Infoway. Several of these tools are under active development; features or availability may change without notice.

3. After confirming the example is conformant to the constraints in the PS-CA, consider adding it as a file to the IPS Sample Registry.

Patient Summary Viewers

To view a rendering of an example patient summary. Rendering example summaries is a recommended final step when performing testing & validation.

Note: These tools are for test data only and should never be used to submit or view PHI.

To view a rendering in the PS-CA Renderer:

1. navigate to https://ps-ca-renderer.apibox.ca/
2. copy/paste (or load from a file) the example bundle of patient summary resources in JSON or XML format
3. click the "View PS-CA" button to render the contents

An IPS viewer tool has also been created for viewing patient summary bundles. Support for optional sections may be more limited, however the IPS viewer also includes examples from other national implementers that readers are encouraged to explore.

To view a rendering in the IPS Viewer:

1. navigate to https://www.ipsviewer.com/
2. copy/paste (or load from a file) the example bundle of patient summary resources in JSON or XML format
3. click the "View IPS" button to render the content