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 flags 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.
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-preBallot, 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 & Child Elements
Occasionally, Must Support flags are applied to elements that fall under a backbone element that is not considered Must Support. This profiling is intended to communicate conditional expectations IF the implementation uses/supports the backbone element.
One example where this practice occurs frequently is in the Composition profile, where an individual sections is not considered Must Support, but there are elements inside of the section that are considered Must Support if the implementer supports the section.
It is not intended to incur the expectation that systems have to support the backbone element and the child elements noted underneath if they would have otherwise not included them in their profile. This modeling will continue to be evaluated for impacts for derived profiles.