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:
   
   1. Validation of Patient Summary data (e.g. Provider identified and eligible to submit a Patient Summary, Patient identified, etc.)
   2. 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.