Releases of the PS-CA Implementation Guide may be found on a table on the Home Page of this Project.
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, package/structuredefinition-profile-quantity-ca-ps.json. If the Quality element is not Must Support but included in a resource, the children system and code must be processed and handled correctly.