Business Requirements
This section outlines the requirements that support the pan-Canadian Patient Summary Interoperability Specifications. The requirements include:
- interoperability requirements which can be tested/validated through prototyping; and
- a broad set of requirements for consideration and to support and provide guidance to stakeholders in their PS-CA implementations. For example, supporting requirements may refer to local/jurisdictional policies and/or standards indicating that an implementer should validate specific requirement needs, if any, within a jurisdiction.
The requirements refer to a standardized expression of actors, entities, and user-system interactions, which will be further defined within the Technical context. Definitions of the terms used throughout the requirements may be found in the Glossary of Terms & Acronyms.
Additional requirements may emerge and will be included in subsequent releases of the PS-CA specifications.
Requirement Identification
The requirements in this specification follow a standardized naming convention to ensure clarity and organization. The structure is based on three primary categories, each assigned a unique prefix, followed by a three-digit numerical identifier. The prefixes and categories are as follows:
- BR1-001 = First requirement within the Business/Legal Requirements category
- BR2-001 = First requirement within the Information/Semantic Requirements category
- BR3-001 = First requirement within the Technical Requirement category
Conformance Language
The PS-CA specification utilizes conformance verbs such as SHALL, SHOULD, and MAY. They are described below for convenience:
- SHALL : This word defines an absolute requirement for all implementations.
- SHALL NOT : This phrase defines an absolute prohibition against inclusion for all implementations.
- SHOULD : This word defines a recommendation that is considered good practice to be included by an implementer. The full implications of ignoring it must be understood and carefully weighed before doing so.
- SHOULD NOT: This phrase defines a common bad practice to be omitted or ignored by an implementer. The full implications of implementing it must be understood and carefully weighed before doing so.
- MAY: This word defines truly optional items, which an implementer may choose to include or omit with no implications.
Business and Legal Requirements
These requirements enable independent organizations to execute a collaborative process or service.
| ID | Description | Status |
|---|---|---|
| BR1-01 | A Patient Summary-CA Solution SHOULD provide the ability to manage the versioning, storage, preservation, destruction, and archiving of Patient Summaries produced and consumed by authorized users of the system in accordance to jurisdictional policies. | Approved |
| BR1-02 | A Patient Summary-CA Solution SHOULD provide a healthcare provider with the option to review and sign-off the Patient Summary content before it is made available to PS-CA Consumers. Note: If the healthcare provider determines that changes are required to the Patient Summary prior to sign-off, the HCP will make the updates in the patient's chart. If the changes affect the Patient Summary content, a new Patient Summary will be created for review/sign-off by the HCP. |
Approved |
| BR1-03 | A Patient Summary-CA Solution SHOULD provide a healthcare provider with the ability to invalidate a Patient Summary if they determine it was entered in error or is invalid as required by jurisdictional policy. | Approved |
| BR1-04 | A Patient Summary-CA Solution SHOULD adhere to data retention policies set by local/jurisdictional policies and system requirements. | Approved |
| BR1-05 | A Patient Summary-CA Solution SHALL provide the ability for an authorized PS consumer (e.g. authorized health care provider) to ascertain the source of information (PS-CA author, producer, date and subject of care) of a current PS and, depending on the jurisdictional implementation, a historical PS. | Approved |
| BR1-06 | A Patient Summary-CA Solution MAY provide the ability to extract and save discrete data from a Patient Summary based on a request by an authorized system user. | Approved |
| BR1-07 | A PS-CA Author SHOULD reasonably ensure that the health information contained in a Patient Summary-CA is accurate, sufficiently complete and up to date to meet the specified clinical purpose. | Approved |
| BR1-08 | A Patient Summary-CA Solution SHOULD be able to comply with a legal hold from an authorized entity based on jurisdictional policies. Note: Legal hold policies prevent deletion of any electronically stored information on the PS-CA that may be imminent for a legal case. |
Approved |
| BR1-09 | A Patient Summary-CA Solution SHOULD be able to omit or mask data in a PS-CA in compliance with local/jurisdictional privacy policies. | Approved |
| BR1-10 | A Patient Summary-CA Solution SHOULD have the ability to produce a Patient Summary in compliance with a subject of care's consent directives in accordance to local/jurisdictional standards and/or policies. Note: For example, local/jurisdictional standards may include associating consent directives with PHI in the Patient Summary which cover concepts of maintaining association, processing consent directives, blocking transmission of PHI in Patient summary where consent directives are violated or no exception of a disclosure is outlined by law or by jurisdictional policy, and notifications to requesters when data is blocked due to consent directives. |
Approved |
| BR1-11 | A Patient Summary-CA Solution SHOULD limit the sharing of health information to what is clinically necessary and sufficient, in accordance with governing legislation and the Patient Summary-CA specification. * Note: For example, the clinician will have the ability to create the PS-CA with a subset of the data domains defined within the PS-CA Interoperability Specifications |
Approved |
| BR1-12 | A Patient Summary-CA Solution SHOULD have the ability to indicate or make the PS-CA Consumer (e.g. a healthcare provider) aware that information about the subject of care has been omitted or masked based on consent directives and jurisdictional policies. | Approved |
| BR1-13 | A Patient Summary-CA Solution SHOULD provide the Patient/Subject of Care a right of access to their Patient Summary based on jurisdictional policies and legislative provisions. | Approved |
| BR1-14 | A Patient Summary-CA Solution SHOULD limit access to only authorized PS-CA Producers and PS-CA Consumers, which may include both human actors (e.g., healthcare providers, patients) and systems (e.g., healthcare applications, digital platforms). | Approved |
Information and Semantic Requirements
These are requirements for syntax and semantics such that data exchanged between health record systems can be interpreted and the meaning of the data ascertained.
| ID | Description | Status |
|---|---|---|
| BR2-01 | A Patient Summary-CA Solution SHALL enable an authorized health care provider to create/produce a Patient Summary based on the pan-Canadian Patient Summary - FHIR Implementation Guide. | Approved |
| BR2-02 | A Patient Summary-CA Solution SHALL adhere to the syntactic, semantic/terminology and content standards for interoperability established in the pan-Canadian Patient Summary - FHIR Implementation Guide. Note: A jurisdiction may have additional requirements beyond those specified in the pan-Canadian Patient Summary - FHIR Implementation Guide. |
Approved |
Technical Requirements
This section defines the functional capabilities the system must or may offer to enhance user experience
| ID | Description | Status |
|---|---|---|
| BR3-01 | A Patient Summary-CA Solution SHALL provide the ability to capture and communicate the identity of the PS subject of care. | Approved |
| BR3-02 | A Patient Summary-CA Solution SHALL provide the ability to capture and communicate the PS-CA Author. | Approved |
| BR3-03 | Patient Summary-CA Solution SHALL provide the ability to send a Patient Summary by identifying a recipient health care provider (e.g., virtual submission to a clinic identified via registry lookup). | Draft |
| BR3-04 | Patient Summary-CA Solution SHOULD provide the ability to view the versions of Patient Summaries and render a previous version based on a request in accordance to jurisdictional policies. | Approved |
| BR3-05 | Patient Summary-CA Solution MAY be able to produce a PS-CA in a portable format (e.g., PDF) that is broadly accessible to patients/subjects of care. | Approved |
| BR3-06 | Patient Summary-CA Solution SHOULD adhere to minimum local/jurisdictional industry standards for authentication (e.g., multi-factor authentication) of authorized users. | Approved |
| BR3-07 | Patient Summary-CA solution SHOULD , where feasible, segregate duties and areas of responsibility to reduce opportunities for unauthorized modification or misuse of PHI based on jurisdictional standards. Note:For example, appropriate access-controls should be put in place to segregate duties for authorized actors who have access and/or can view hosted components of the Patient Summary in order to reduce opportunities for unauthorized modification or misuse of PHI and security-critical system data according to jurisdictional standards. |
Approved |
| BR3-08 | Patient Summary-CA Solution SHOULD protect health information in transit, adhering to jurisdictional standards for encryption. Note: For example, jurisdictional standards for encryption should cover concepts of cryptographic algorithms and protocols, management of encryption keys during the transmission of PHI to maintain the confidentiality and integrity of the Patient Summary. |
Approved |
| BR3-09 | Patient Summary-CA Solution SHOULD adhere to the minimum industry standards for role-based access control and security mechanisms for the Patient Summary, including defining the security level and authorization profile of all authorized actors and mapping each user to one or more roles and each role to one or more system functions, dictated by jurisdictional standards and system requirements. Note For example, jurisdictional standards for role-based access control should consider the following standards such as ISO 22600-1:2014, which describes the scenarios and the critical parameters in information exchange across policy domains. Another example of a standard is ISO 22600-2:2014, which describes and explains, in a more detailed manner, the architectures and underlying models for privilege management and access control which are necessary for secure information sharing including the formal representation of policies. |
Approved |
| BR3-10 | Patient Summary-CA Solution SHOULD adhere to jurisdictional standards for creation of secure audit logs that capture access to, modification or disclosure of Patient Summary-CA information. This includes the activities of PS-CA Producers, Consumers and Requesters. Note For example, jurisdictional standards for appropriate secure-audit records should log PHI-related events, such as Patient Summary access (including access to confidential data), Patient Summary creation, Patient Summary amendments and changes, traceability of consent, consent directive overrides and more for the Patient Summary. |
Approved |
| BR3-11 | The Patient Summary-CA Solution SHOULD have the ability to capture secure audit log content as dictated by jurisdictional standards and/or system requirements. Note : For example, jurisdictional standards and/or system requirements for secure audit logs should consider Patient Summary schema and log content such as the user ID of authorized actors, the role the user is exercising, the organization of the accessing user (at least in those cases where an individual accesses information on behalf of more than one organization), the patient ID of the data subject (patient/person), the function performed by the accessing user, a timestamp, in the case of access override to blocked or masked records or portions of records, a reason for the override, and in the case of changes to consent directives made by a substitute decision-maker, the identity of the decision-maker. |
Approved |
| BR3-12 | Patient Summary-CA Solution MAY provide the capability for a PS-CA to be de-identified, according to local/jurisdictional requirements. | Approved |
| BR3-13 | Patient Summary-CA Solution SHALL provide the ability to uniquely identify a Patient Summary-CA with a unique identifier. | Approved |
| BR3-14 | Patient Summary-CA Solution MAY retrieve data elements for the PS-CA from the PS-CA Author's local data source. | Approved |
| BR3-15 | Patient Summary-CA Solution MAY provide the ability to convert structured documents (e.g. FHIR-based) to unstructured documents (e.g PDF), and make transformations between structured document formats (e.g. CDA). | Approved |
| BR3-16 | Patient Summary-CA Solution SHOULD create the PS-CA in a structured format that aligns with the FHIR version identified in the PS-CA IG | Approved |
| BR3-17 | Patient Summary-CA Solution SHOULD protect health information at rest, adhering to jurisdictional standards for encryption. Note Note: For example, jurisdictional standards for encryption should cover concepts of cryptographic algorithms and protocols, and management of encryption keys to maintain the confidentiality and integrity of the Patient Summary. |
Approved |
| BR3-18 | PS-CA Solution SHALL have a default expiry date for the SHLink if not changed by the Patient (or designated caregiver). | Approved |
| BR3-19 | PS-CA Solution SHALL ensure that access to clinical data is short-lived (e.g., expire after a certain time period or after a specific number of uses) to minimize unauthorized consumption. | Approved |
| BR3-20 | PS-CA Solution SHALL provide safeguards (e.g., passcode) for the PS-CA Producer to prevent the SHLink from being accessed by the wrong party | Approved |