Overview

The purpose is to describe the use cases and workflow scenarios for sharing a patient summary profile across solutions. Each jurisdiction may have implementation variances within the use cases. Therefore, these use cases provide examples and are not meant to be inclusive of all possible implementation choices and do not represent required implementation choices. The use cases provide high-level interactions between the Health Care Providers, their Health Records System and other Health Records Systems. Use cases provide the business description or "conversation" between the system(s) and its user(s), known as Participants. Participants can be people (e.g., health care providers, patients, etc.) or systems (e.g., EMR, EHR Repository, etc.).

Each use case will include:

• use case scenario,
• examples of use case triggers, pre and post conditions,
• who the participants are (i.e., people and systems),
• a use case diagram to provide a visual representation of the interactions between participants,
• use case steps corresponding to the diagram and potential alternate flows; and
• reference to the corresponding business requirements.

Use Case Index

The list below includes the use case's ID, name, description, and purpose. Participating Canadian jurisdictions have identified these use cases as applicable to their Patient Summary implementation for Release 1 or beyond.

UC-01:HCP Creates a PS-CA

Description

A Health Care Provider in any care setting creates a Patient Summary for use at point of care, which is made available to Patient Summary consumers.

Scenario

A patient schedules a visit with their regular health care provider, within their Medical Home, with symptoms including dizziness and an earache. The patient mentions that since they last visited, another clinic noted that they have high blood pressure (hypertension) which is being monitored at home for now. The patient also mentions a suspected penicillin allergy. The health care provider determines that the patient has an external ear infection (otitis externa) and prescribes antibiotics. The health care provider creates a clinical note in their EMR, which may trigger automatic updates, such as updates to the prescription information. The health care provider decides to create a new Patient Summary for this patient, or replace an existing Patient Summary if one had previously been created, and submit it to the jurisdictional EHR so that it is available for other health care providers who may be providing care for this patient.

Note that the implementation regarding what triggers the creation of a new Patient Summary or the replacement of an existing Patient Summary may be automated and/or vary between solutions. For example, updates to specific clinical information may trigger an update to an existing Patient Summary.

Triggers, Pre-conditions, Post-conditions

This section describes example triggers, pre-conditions & post-conditions related to the creation of the Patient Summary. It is not inclusive of all potential workflow scenarios which may be implemented within Canadian jurisdictions.

Triggers

• Health Care Provider provides care to a patient and updates the Patient's record.
• Health Care Provider receives additional information for a patient. For example, HCP receives test results for a Patient, updates the Patient's problem list, adds a clinical note, which triggers a new Patient Summary.

Pre-conditions

• Patient Summary shall uniquely identify the Patient so that it can be shared across jurisdictional systems (e.g., uniquely identified by a Client Registry ID)
• In jurisdictions where explicit consent is required to share the Patient Summary:
  • Patient provides, or has previously provided, consent to share their data to the EHR.

Post-conditions

• New Patient Summary recorded/registered in the PS-CA Solution that receives the PS-CA. Where applicable, the Patient Summary may replace an existing Patient Summary (e.g. according to jurisdictional rules such as same Patient, same Provider, same Location).
• Authorized health care providers have access to view the new patient summary or, may receive a notification that a new patient summary is available for their patient.

Use Case Participants & Diagram

The participants involved in this use case are:

• PS-CA Producer (Health Care Provider curating / producing a PS-CA via a Health Records System)
• PS-CA Solution (Health Records System receiving the PS-CA)

This use case diagram represents the participants and their role in the use case with a high-level view of the flow of information.

Use Case - Primary Flow

The following provides a textual description corresponding to the use case diagram.

1. Health Care Provider treats Patient and updates the Patient's health record in their Health Records System (e.g., EMR, HIS).

2. Health Care Provider determines that a new Patient Summary should be created and requests the Health Records System (e.g., EMR) to create the patient summary information.

3. Health Records System (e.g., EMR, HIS) pulls the available Patient Summary information from within the local system (e.g. EMR creates Patient Summary with data solely from the EMR Patient Chart).

4. Health Care Provider, optionally, reviews and validates the Patient Summary prior to sharing/publishing the Patient Summary.

5. Health Care Provider sends / publishes the Patient Summary to the receiving Health Records System (e.g., EHR).

6. Receiving Health Records System (or data processing layer i.e. jurisdictional hub) applies business rules (e.g. data standardization, privacy, policy, etc.). For example:

   a.) Validation of Patient Summary data (e.g. Provider identified and eligible to submit a Patient Summary, Patient identified, etc.)

   b.) Checks for existing Patient Summary for same patient/same provider - apply replacement / archiving rules

7. Receiving Health Records System records/saves the Patient Summary.

8. Patient Summary available for access by authorized Health Care Providers. (Refer to UC-02 HCP Views/Consumes a PS-CA)

Use Case - Alternate Flow

The following list provides possible alternate flows that may occur within this use case.

• Step 4: Health Care Provider has the option to bypass an additional review of the Patient Summary, allowing the Health Records System to automatically share/publish the Patient Summary to the receiving Health Records System.
• Step 4: Health Care Provider, upon review of the Patient Summary, chooses to make changes to the Patient's medical information within the Patient's health record prior to publishing the Patient Summary. If the changes affect the content of the Patient Summary, a new Patient Summary will be created.
• Step 4: Health Care Provider, upon review of the Patient Summary, chooses to withhold some or all of the information within the Patient Summary from being shared/published to another Health Records System.
• Step 5: Health Care Provider, after submitting the Patient Summary, identifies that there is incorrect or missing information on the patient summary. The HCP will have the option to create and publish a new Patient Summary to replace the previously submitted Patient Summary.
• Step 5: Health Care Provider, after submitting the Patient Summary, identifies that there is incorrect information or the Patient Summary is for the wrong patient. The HCP will have the option to retract / delete the most recent Patient Summary that they submitted with the same Patient, Provider and Location identified.
  • Note: Business rules for how a document management system manages documents it has received (e.g., when is it appropriate to delete a document, how long should it be archived, when should the system alert users of new information, etc.) is outside of the scope of the current PS-CA specifications. Additional use cases and business rules will be tackled in forthcoming releases of the PS-CA specifications. This release is intended to be a technical building block that new use cases can build off of.

UC-02:HCP Views/Consumes a PS-CA

Description

A Health Care Provider, in any care setting , views and, optionally uses, a Patient Summary at the point of care.

Scenario

A patient schedules a visit with a health care provider, outside of their Medical Home, with symptoms including dizziness and an earache. The patient mentions that they have a regular health care provider, within their Medical Home, and experience high blood pressure (hypertension) which is being monitored at home for now. The health care provider collects information from the patient and searches their Patient Summary-CA Solution for an existing Patient Summary (e.g., searches the network to determine if a Patient Summary was created and shared by another Health Care Provider). Upon finding a Patient Summary for their patient, the health care provider views and uses the information in the Patient Summary in support of providing care for this patient.

Triggers, Pre-conditions, Post-conditions

This section describes example triggers, pre-conditions & post-conditions related to the creation of the Patient Summary. It is not inclusive of all potential workflow scenarios which may be implemented within Canadian jurisdictions.

Triggers

• Health Care Provider gathers all available information about their patient to provide care.
• Where applicable, HCP received a notification that new Patient Summary information is available for a Patient to which they have subscribed to receive notifications.

Pre-conditions

• In jurisdictions where explicit consent is required to create and share the Patient Summary: Patient provides, or has previously provided, consent to share their data.

Post-conditions

• Health Care Provider views and uses the Patient Summary in support of Patient care.

Use Case Participants & Diagram

The participants involved in this use case are:

• PS-CA Consumer (Health Care Provider requesting access to a PS-CA)
• PS-CA Solution (Health Records System enabling access to the PS-CA)

This use case diagram represents the participants and their role in the use case with a high-level view of the flow of information.

Use Case - Primary Flow

The following provides a textual description corresponding to the use case diagram.

1. Health Care Provider, providing care for their Patient gathers information from the Patient and other information that may be available in the PS-CA Solution (e.g., Health Records System such as an EHR). 1.Health Care Provider requests access to view an existing Patient Summary for their Patient from the PS-CA Solution.
2. PS-CA Solution applies applicable business/privacy/policy rules (e.g., consent rules applied according to jurisdictional privacy legislation).
3. PS-CA Solution renders the Patient Summary into a format that is consumable by the requesting system (e.g., PDF document).
4. Health Care Provider obtains access to the Patient Summary and, optionally, consumes the information into their Health Records System.
5. Health Care Provider views/uses the most current Patient Summary information available in support of caring for the Patient.

Use Case - Alternate Flow

The following list provides possible alternate flows that may occur within this use case.

• Step 3.b. Provider is not authorized to view the Patient Summary. Process abandoned and HCP does not obtain access to Patient Summary. HCP, alternatively, collects additional input from the Patient.

UC-03: Patient Views/Consumes a PS-CA

Description

A Patient accesses/obtains a copy of their own Patient Summary.

Scenario

A patient, or their designated caregiver, would like to access their patient summary information to stay up to date with their medical health information, contained within the Patient Summary, empowering them to play an active role in their own care.

Note that a jurisdictional implementation may choose to present a different version of the Patient Summary to patients than providers. For example, the patient version of the Patient Summary may use more patient friendly language, certain information that might lead to patient harm may be redacted (for example, in the case of patients undergoing behavioral health treatment).

Triggers, Pre-conditions, Post-conditions

This section describes example triggers, pre-conditions & post-conditions related to the creation of the Patient Summary. It is not inclusive of all potential workflow scenarios which may be implemented within Canadian jurisdictions.

Triggers

• Patient, or their designated caregiver, chooses to view the patient summary to stay informed of their medical information.
• Patient wants to obtain a copy of their patient summary to have on their person while travelling.
• Patient wants to obtain a copy of their patient summary to share with another care provider.

Pre-conditions

• A jurisdictional clinical system with patient access is available.
• A patient summary has been created for the patient. (Refer to UC-01) Note that the patient summary assembled for a patient may contain a different / modified set of data than is assembled in the patient summary for a health care provider.
• Patient has setup up a personal account, with username/password, in the jurisdictional clinical system (e.g., patient portal).
• If applicable, patient has designated and authorized a designated caregiver to access their personal health record on their behalf.
• Patient, or designated caregiver, has logged into the jurisdictional clinical system (e.g., patient portal).

Post-conditions

• Patient, or their designated caregiver, accessed and viewed their own patient summary.
• Optionally, the patient, or their designated caregiver, has obtained a copy (e.g. download or printed report) of their patient summary.
• Patient, or their designated caregiver, presents the patient summary to another health care provider to support continuity of care. (Refer to UC-05 where the Patient presents their Patient Summary to a Health Care Provider in another jurisdiction.)

Use Case Participants & Diagram

The participants involved in this use case are:

• Patient / Subject of Care via Patient Portal
• PS-CA Solution (e.g., PHR)

This use case diagram represents the participants and their role in the use case with a high-level view of the flow of information.

Use Case - Primary Flow

The following provides a textual description corresponding to the use case diagram.

1. Patient / Subject of Care navigates to their personal health information via a Patient Portal.
2. Patient / Subject of Care or Substitute Decision Maker requests access to view their Patient Summary / Summaries.
3. PS-CA Solution (e.g., PHR) applies applicable business/policy rules (e.g. validates the patient's credentials).
4. PS-CA Solution (e.g., PHR) retrieves the PS-CA (from local storage or from an external PS-CA Registry). If applicable, the PS-CA Solution may apply data transformation, such as formatting the information into a PDF.
5. Patient / Subject of Care obtains access to their Patient Summary/Summaries and optionally, prints/saves the document in a portable format.

Use Case - Alternate Flow

The following list provides possible alternate flows that may occur within this use case.

• A substitute decision maker, with the designated permissions, accesses/obtains the Patient Summary.

UC-04: HCP Requests PS-CA On-Demand

Description

A Health Care Provider (HCP) in any care setting requests a patient summary to be created at the time of the request (i.e., on-demand), consisting of the patient's most recent health information from an available data source(s) to be used at the point of care or as part of a clinical workflow.

Scenario

Emergency Room providers request a Patient Summary On-Demand

Mr. Sam Khan is a 79 year old male patient, an ex-smoker who lives with multiple chronic medical issues, including Rheumatoid Arthritis, Valvular Heart Disease, Osteoporosis, Prostate Cancer, and significant Anxiety. Over the past few years, his level of frailty has increased, and he relies more on his family for assistance.

He visits four specialist physicians for appointments during the year, and also regularly sees his family physician, Dr. Anderson, who synthesizes a lot of the specialist advice and treatment planning, and tries to keep her EMR records up to date.

About a week after a visit to one of his specialists, while visiting his son in a nearby town, he feels acutely short of breath and a little dizzy, accompanied by coughing. His son takes him to the ER, where he is quickly assessed by the triage team. It is challenging for him to convey his full medical history when he arrives. While his son is very supportive, he isn’t aware of all the details of recent specialist and family physician consultations.

Unfortunately, they didn’t have a chance to collect all of Sam’s medications before heading to the ER. Sam’s son is not aware that Dr. Anderson had recently started Sam on a couple of inhalers for suspected COPD. These are new medications, and Sam has been having challenges with the delivery mechanism due to his arthritis.

Through her Hospital Information System interface, the triage nurse requests a Patient Summary, which pulls records from available data source(s) i.e., Central Data Repository, presenting a concise summary of Sam’s medical history. The Patient Summary helps to fill in critical information gaps during the initial nursing assessment. The Patient Summary also helps the attending physician make her initial differential diagnosis more confidently, complementing the more detailed but incomplete records available through the HIS and provincial EHR.

She and the nursing team realize that Sam had not been taking his new inhalers regularly and is likely experiencing an acute exacerbation of COPD. They start appropriate treatment, and Sam’s condition improves and stabilizes.

Triggers, Pre-conditions, Post-conditions

This section describes example triggers, pre-conditions & post-conditions related to the creation of the Patient Summary. It is not inclusive of all potential workflow scenarios which may be implemented within Canadian jurisdictions.

Triggers

• Health Care Provider collects health information in support of treating a patient.

Pre-conditions

• In jurisdictions where explicit consent is required to create and share the Patient Summary: Patient provides, or has previously provided, consent to share their data
• Patient has existing health record in the Clinical Data Repository (one data source) or Patient has existing health care data in multiple data sources (EHR repositories, EMR, HIS, CIS,PHR).

Post-conditions

• Healthcare care Provider obtains/views newly created (on-demand) Patient Summary from the (clinical data repository or directly EHR repositories , EMR, CIS) with options to view and import the Patient Summary into their clinical solution.

Use Case Participants & Diagram

The participants involved in this use case are:

• PS-CA Consumer (Health Care Provider requesting an on-demand PS-CA via a Health Information System).
• Clinical Data Repository (Data source for PS).

This use case diagram represents the participants and their role in the use case with a high-level view of the flow of information.

Use Case - Primary Flow

The following provides a textual description corresponding to the use case diagram.

1. Health Care Provider (HCP), while treating a Patient, determines that additional information is required for making clinical decisions.
2. HCP, using their clinical system, requests the Patient Summary to be created on-demand from Clinical Data Repository.
3. Clinical Data Repository (CDR) receives request and retrieves relevant patient data from various sources within it’s repository.
4. CDR assembles the Patient Summary with information retrieved from the corresponding patient data sources in the Clinical Data Repository.
5. CDR applies business rules (e.g., policy, privacy, etc.) to the information that has been collected from the Clinical Data Repository.
6. CDR renders the Patient Summary into a format that is consumable by the requesting system (e.g., PDF document).
7. HCP receives and views the Patient Summary.
8. Optionally, the HCP may choose to consume the Patient Summary into their clinical system.
9. HCP has access to the most recent and available Patient Summary.

Use Case - Alternate Flow

The following list provides possible alternate flows that may occur within this use case:

• Step 8: Health Care Provider receives response from the CDR that the Patient Summary is masked. Health Care Provider completes the applicable jurisdictional consent documentation (e.g., override reason code) and re-submits the request or abandons the request.

UC-05: Patient Mediated Access and Exchange of their Patient Summary

Introduction

This use case describes the process of accessing and sharing a patient summary using a Shareable Health Link (SHL) and QR code. It is split into two distinct yet interconnected parts (i.e., Part A: Patient Requests Access to Their Shareable Patient Summary and Part B: Patient presents their QR code or SHL to HCP for access to their Patient Summary), offering a complete overview of the workflow from the creation of the shareable patient summary to its use by Health Care Providers (HCP).

Description

A patient, via a patient-facing application, requests access to a shareable copy of their patient summary. Subsequently, the patient provides access to their encrypted patient summary via the QR code on their mobile device or by sharing a secure SHL, (e.g., via email) at the point of care (e.g., walk-in clinic, emergency department). The HCP scans the QR code or accesses the SHL shared by the patient, addressing any security prompts, such as entering a passcode if required, and then may proceed to view/utilize and consume the patient summary.

Part A: Patient Requests Access to Their Shareable Patient Summary

Ms. SJ, a 37-year-old non-smoker and non-drinker, recently experienced a high-risk pregnancy involving early hospitalization and pre-term delivery due to pre-eclampsia and gestational diabetes. She is currently taking metformin and an anti-hypertensive. Ms. SJ, recently moved within her province, and she found a new primary care clinic that is taking on new patients.

Ms. SJ signs up for a patient-facing provincial application to access her personal health information and creates a shareable patient summary, which will be useful for her upcoming appointment. On the application, she is presented with privacy and security measures, such as a consent notice, passcode, and QR code timeout. After providing her consent and completing the security instructions for her shareable patient summary, the application assembles her patient summary using available data and creates a SHL and QR code, which is displayed on Ms. SJ’s mobile phone, and she is happy to see that she has the option to print a copy. Ms. SJ is ready for her appointment.

Triggers, Pre-conditions, Post-conditions

This section describes example triggers, pre-conditions & post-conditions related to the creation of the Patient Summary. It is not inclusive of all potential workflow scenarios which may be implemented within Canadian jurisdictions.

Triggers

• Patient, or their designated caregiver, choose to share their patient summary with a healthcare provider.

Pre-conditions

• Patient has access to a patient-facing application which supports access to their patient summary and creation of a QR code with a SHL for sharing with an HCP.

Post-conditions

• A QR code, with a SHL, is created and displayed to the patient for accessing and sharing their patient summary.

Use Case Participants & Diagram

The participants involved in this use case are:

• Patient or designated caregiver requesting access to their shareable patient summary via patient-facing application.
• PS-CA Producer (e.g., Clinical Data Repository).

Use Case - Primary Flow

The following provides a textual description corresponding to the use case diagram.

1. Patient or their designated caregiver accesses Personal Health Information via a patient facing application (e.g., Jurisdictional Patient Portal).

2. Patient or their designated caregiver requests access to a shareable patient summary, on option available within their patient facing application.

3. Patient or their designated caregiver is presented with applicable privacy and/or security forms such as a consent statement, requirements for a PIN, passcode, validity time frame etc., according to jurisdictional policies.

4. Patient or their designated caregiver reviews the information presented and determines if they would like to proceed. If yes, proceed to step 4a. Otherwise, proceed to step 4b.

   a.) Patient or their designated caregiver completes the privacy and security forms. Proceed to step 5.

   b.) Patient or their designated caregiver decide not to complete the privacy and security forms. The request for their shareable patient summary is terminated. Process complete. (Refer to alternate flow for step 4b)

5. PS-CA Producer retrieves relevant patient data from available data sources ( e.g., CDR, EHR ,EMR).

6. PS-CA Producer assembles patient summary from discrete data sources. An existing patient summary can be retrieved or a new patient summary may be generated depending on the implementer.

7. PS-CA producer applies business rules (e.g., Privacy, Policy, Data Standardization).

8. PS-CA producer applies data encryption and transformation (i.e., data formatted according to the type of request).

9. PS-CA Producer creates shareable health link which is encoded into a QR code.

10. Patient or their designated caregiver is presented with a QR code, and optionally the SHL. Additionally, the Patient may view the shareable patient summary on their device.

11. Patient has access to the shareable copy of their patient summary with a QR code and SHL for sharing their patient summary with a health care provider.

Use Case - Alternate Flow

The following list provides possible alternate flows that may occur within this use case:

• Step 4b. Patient/designated care giver is not authorized to access a shareable patient summary and the process is abandoned. (For example, a jurisdictional rule identifies that a patient summary request may only occur once within a specific time period.)

Part B: Patient presents their QR code or SHL to HCP for access to their Patient Summary.

Ms. SJ attends her first in-person visit with her new family physician, Dr. Pereira. During the consultation, she displays her patient summary QR code on her mobile phone and shares the passcode. Ms. SJ explains to Dr. Pereira that, if she was not able to scan the QR code, Ms. SJ could share the SHL via email to the clinic. Dr. Pereira, having access to QR code scan technology, scans the QR code and enters the required security prompts. Dr. Pereira views Ms. SJ’s patient summary and is happy to see that there is an option to import the patient summary into her local clinical solution.

Dr. Pereira is very happy to note that this saves her time and requires less administrative effort to gather Ms. SJ’s medical history. The consultation proceeds smoothly.

Triggers, Pre-conditions, Post-conditions

Triggers

• Patient presents a health care provider (HCP) with access to their patient summary using a QR code or SHL.

Pre-conditions

• Patient has a QR code or SHL with access to a patient summary.
• HCP has the necessary tools to scan the QR code or access the SHL (e.g., a QR code scanner, Health Information System).

Post-conditions

• HCP has access to Patient Summary.

Use Case Participants & Diagram

The participants involved in this use case are:

• Patient or designated caregiver
• PS-CA Consumer (Health care provider/Clinical system)
• PS-CA Solution (Health record system enabling access to the PS-CA)

Use Case - Primary Flow

The following provides a textual description corresponding to the use case diagram.

1. Patient has a medical encounter with a health care provider (HCP) virtually or in-person to obtain health care services.

2. Patient displays their patient summary QR code on their mobile device or shares a shareable health link (e.g., via email) with the HCP and provides them with the passcode/PIN that they created (in Part A of this use case) to access the patient summary.

3. HCP scans the QR code or accesses the SHL in a browser to retrieve the patient summary.

4. HCP is presented with applicable privacy and/or security form and they enter required security prompts (e.g., passcode, expiration time frame etc.,) according to jurisdictional policies.

5. PS-CA Solution verifies the information submitted by the HCP in response to the security prompts (e.g., passcode/PIN).

   a.) If the security prompts are correct, proceed to step 6.

   b.) If the security prompts are incorrect, PS-CA Solution denies access and prompts the user to re-submit the security prompts. If multiple failed attempts occur or the HCP abandons the process, the request for the patient summary is terminated. Process complete.

6. PS-CA Solution retrieves the patient summary. Note: This process typically involves two steps: initially, a manifest file is provided containing the link to the patient summary. The patient summary is then retrieved in a subsequent step.

7. HCP views and optionally saves/imports the patient summary in their clinical system.