Overview

Use cases are used to outline interactions or “conversations” between participants, which include users (e.g., health care providers patients etc.) and the systems (e.g., EMR solutions, Referral Management System, etc.).

The use cases presented below illustrate high-level interactions between health care providers and their health records system when managing eReferrals and/or eConsults. Please note that detailed interactions are defined in CA:eReC Messaging , CA:eReC Central Intake and CA:eReC Sequence Diagrams .

The use cases are derived from the Ontario eReferral – eConsult – HL7® FHIR® Implementation Guide, reflect input and feedback from the eReferral Interoperability Working Group, and jurisdictions involved in determining in-scope use cases for the Pan-Canadian eReferral-eConsult (CA:eReC) Implementation Guide.

Of note, these use cases and workflow scenarios are intended to provide examples of how eReferrals and eConsults can be managed across solutions. They are not meant to be inclusive of all possible implementation choices and do not reflect all potential workflows and implementation options within and across jurisdictions.

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.

Use Case Index

The list below includes the use cases' ID, name and description in-scope for Release 1.

Implementation Scenarios

The use cases presented provide examples and are not meant to be inclusive of or represent all possible implementation models, choices or requirements.

Depending on jurisdictional directives and approaches, healthcare providers may have implemented the same or a different solution to manage eReferrals/eConsults within and across jurisdictions.

In some cases, the point of service (POS) system used by a health care provider is able to directly manage eReferrals and eConsults, whereas other POS systems may be integrated with an external referral management solution (RMS).

These use cases are applicable to the following implementation scenarios:

1. Both the sender(s) and receiver(s) have implemented end-to-end specialized Referral Management Systems (RMS) to manage eReferrals/eConsults.
2. Both the sender(s) and receiver(s) have implemented end-to-end POS systems that directly manage eReferrals/eConsults.
3. Combination of the above (e.g. sender has implemented a RMS and receiver has implemented a POS system to manage eReferrals/eConsults, or vice versa)
4. Both the sender(s) and receiver(s) use a standalone platform/portal to manage eReferrals/eConsults.

Participants

People

• Requester HCP: A Health Care Provider or their delegate (e.g. medical office assistant), or other service provider that initiates and sends the referral request. For eReferrals/eConsults, this is typically the primary care provider.

• Performer HCP: A Health Care Provider or delegate, (e.g. medical office assistant), or other service provider that receives the referral request and performs the requested services. For eReferrals/eConsults, this is typically a specialist.

• Case Assigner: The individual responsible for assigning incoming referral/consult requests to a performer HCP. Performer HCPs may also self-assign incoming consult requests. In this case, the Performer HCP will also take on the role of Case Assigner. The Case Assigner may also be an algorithm (system) that automatically assigns requests to an available performer HCP based on established criteria (e.g., wait time, availability, location, etc.)

Systems

• Point of Service Systems (POS): Used by Requester/Performer HCPs to view and manage personal health information (PHI). These systems include hospital information systems (HIS), primary care electronic medical record systems (EMR), community and ambulatory health information systems, and provincial/regional EHR viewers.

  POS systems can include capability to directly manage eReferrals/eConsults. POS system functionality can exist at multiple points in the eReferral workflow, and a given system might provide this functionality in some workflows, and not in others. Where integration with other systems exist, a POS system is potentially a gateway to third-party managed health records and to services that facilitate eReferral processes.

• Requester POS systems: Initiate and potentially track and manage healthcare referral/consult requests.

• Performer POS systems: Receives the referral/consult request and is used to provide the requested healthcare services.

• eReC Source: Used by Requester HCP to initiate, monitor and communicate about the referral request. eReC Source functionality will vary between systems and may include some or all the following:

  • Search for available services or service providers (potentially through integration with a Healthcare Service Directory (HSD));
  • Access and complete electronic forms required by the service provider;
  • Attach supporting information (typically through integration with POS);
  • Submit a request;
  • Monitor referral status;
  • Receive information about appointments, updates and tasks planned and performed in response to the request;
  • Communicate with other service providers (e.g. secure messaging).

• eReC Target: Used by Performer HCP to receive, respond to, manage and communicate about the referral request and associated tasks. eReC Target functionality will vary between systems and may include some or all the following:

  • Receive, review, acknowledge, accept, reject and triage requests and supporting information;
  • Communicate with the requester (e.g. secure messaging);
  • Plan tasks to be performed in response to the request;
  • Appointment scheduling, and
  • Monitoring the status of planned tasks.

• Referral Management Systems (RMS) - Support the exchange of referral requests between Requester HCP and Performer HCP where one or both of their POS systems do not have the required capabilities to support the workflow (if an EMR/HIS does have the required capabilities to support the referral request workflow, they may perform one or both of the roles of eReC Source or eReC Target, while also playing the POS role). Capabilities can be implemented as API services and\or interactive applications and a single system may provide one or more capabilities to enable and or enhance eReferral workflows. They can also be considered helper apps.

  Note:

  • Depending on the use case, a RMS or a EMR/HIS with referral capability may perform the role of eReC Source, eReC Target, or both
  • A single system MAY act as the eReC Source and the eReC Target for a request or one or the other depending on the capabilities of the system, the role of the user for a specific request and the RMS systems used by requester and performer.
  • In practice, either or both of the systems exchanging referral information may be a specialized Referral Management Systems (RMS), a message broker, or any of a range of systems used at the Point of Service (POS) by people who request, triage, plan or perform services as part of an electronic referral or consultation process. The requirement is only that conformant systems SHALL provide the capabilities expected of the role they declare.
  • An eReC Source and eReC Target MAY support both eReferral and eConsult functionality, or only support one of eReferral and eConsult

• Central Intake System (eReC Target + eReC Source): system can be used to receive eReferral/eConsult requests from Requester HCP and route the request to a downstream Performer HCP. The Central Intake System can act as both the eReC Target (for Case Assigner to receive consult requests) and eReC Source (for Case Assigner to assign a request to the Performer HCP)

• Health Service Directory (HSD): Used by HCP or service provider to discover services and service providers to address eReferral needs. RMS typically bundle in HSD functionality to better support referral/consult workflows. In other cases, the RMS, or POS system with referral capability could integrate with a HSD that is centrally managed (i.e. jurisdictional) or provided by a 3rd party. An HSD may provide one or more of multiple functions, including:

  • Health service discovery mechanisms
  • Health service definition hosting and data federation services
  • Integration with a forms repository to associate health services with forms used to support the referral process

Please refer to CA:eReC Actor Mappings for a mapping diagram that explains the relationship between use case actors, real-world systems and technical actors.

UC-01: Referral to a Service

Description

Requester Health Care Provider sends a referral request to a Performer Health Care Provider

Scenario

Note: In this example, Dr. Jones' electronic medical record (EMR) solution could be integrated with an external Referral Management System (RMS) or his EMR solution could have the capability to directly manage eReferrals.

Jane Doe is an active 72 year old who is managing type 2 diabetes, osteoarthritis (multiple joints), and chronic neck pain. Her neck pain had been well controlled with a combination of oral and topical medications, physiotherapy and massage therapy. However, in the last few months, Jane’s neck pain has worsened, exhibiting more concerning features.

Jane attends an appointment with her family doctor, Dr. Jones, who reviews past imaging results, including a fairly recent MRI. Dr. Jones determines that the underlying cause of the pain requires further assessment and refers Jane to a specialist.

Dr. Jones creates an eReferral from his EMR and selects a neurosurgical specialist that is located close to Jane’s home. After selecting the specialist, referral requirements are presented on his screen with some of the information already filled in (based on available data from his EMR). He completes the referral requirements and sends the referral request to the specialist. Jane also receives a notification that the referral has been sent.

The medical office assistant at the neurosurgical specialist’s office is notified of the incoming referral request and contacts Jane to schedule an appointment. Updates are sent to Dr. Jone's system when the appointment is scheduled and completed to keep him informed about the referral status.

Use Case Participants

People

• Requester HCP
• Performer HCP

Systems

• Requester POS system
• Performer POS system
• eReC Source
• eReC Target
• Health Service Directory (HSD)

Please refer to Participants for definitions.

Triggers

Requester Health Care Provider (HCP) needs to send a referral for a patient

Pre-conditions

• The POS system has the capability to directly manage the referral workflow or is integrated with an external eReC Source/eReC Target
• The POS system or eReC Source is integrated with a valid and up-to-date Health Services Directory
• Appropriate patient consent in accordance with jurisdictional requirements and legislation, whether implied or expressed, has been obtained to share their personal and health information during the referral process.
• Patients have indicated their communication preferences and provided consent to receive notifications and information about their eReferral status and appointment via their selected method(s).
• Patient information in Requester POS system is valid and up-to-date.

Post-conditions

• The Performer HCP completes the initial consultation appointment with the patient and closes the eReferral request. The Requester HCP is updated that the appointment is complete. Or,
• The Performer HCP converts the referral to a consultation and provides consultation advice to the Requester HCP instead of booking the patient in for an appointment (UC-2: Consultation Request). Or,
• The referral request was not fulfilled or was ended before completion because:
  • The Requester HCP cancels the referral request
  • The Performer HCP declines the referral request
  • The Patient declines the referral/request

Workflow diagram

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. Requester HCP initiates the creation of an eReferral request.

2. Requester HCP searches for and selects the appropriate service based on results from the Health Service Directory.

   The Health Service Directory could be i) centrally managed, or ii) locally integrated with the POS system, or iii) part of an eReC Source that is integrated with POS system.

3. Requester HCP is presented with and completes the referral requirements and, if necessary, provides a clinical narrative to support the reason for the referral. Patient information and some of the referral requirements may be automatically filled in based on information available in the POS system.

4. Requester HCP may attach additional clinical notes and supporting documentation from the POS system to support the referral request.

5. Requester HCP submits the referral request with the required information and clinical documentation. The eReC Source transmits the referral request to the Performer HCP and an electronic notification is sent to the Patient that the referral request has been sent.

   The eReC Source could be i) an EMR/HIS which has the capability to directly manage eReferrals (the system is both a POS system and eReC Source) or ii) an external Referral Management System (RMS) (the eReC Source is integrated with the Requester HCP POS System).

6. The eReC Target receives the referral request. The Performer HCP receives a notification about the new referral request and reviews the request.

   The eReC Target could be i) an EMR/HIS which has the capability to directly manage eReferrals (the system is both a POS system and eReC Target) or ii) an external Referral Management System (RMS) (the eReC Target is integrated with the Performer HCP POS System).

7. Performer HCP contacts the patient to arrange an appointment. After the appointment is scheduled, the eReC Target transmits an update to the eReC Source. The Requester HCP receives a notification that the appointment has been booked.

8. Performer HCP completes the initial consultation appointment with the patient and closes the eReferral request. The eReC Target transmits an update to the eReC Source. The Requester HCP receives a notification that the appointment has been completed.

Use Case - Alternate Flows

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

1. Requester HCP may cancel/revoke the referral request. This status is noted in eReC Source and automatically forwarded to eReC Target. (Step 6 – 7)
2. Performer HCP may be unable to provide the service and decline the referral, this status is noted in their eReC Target and automatically forwarded to eReC Source. (Step 6 – 7)
3. Performer HCP and Requester HCP may update the referral request (e.g. send communications, update referral with new information, etc.). (Step 6 – 8)
4. Performer HCP may convert a referral to a consultation (providing advice to the Requester HCP instead of an appointment with the patient - See UC-02: Consultation Request). (Step 6)
5. Patient may decline the service and the status is notified in the eReC Source. (Step 6 – 8)
6. Patient may change the appointment date. (Step 7)

UC-02: Consultation Request

Description

Requester Health Care Provider (HCP) would like to seek advice/opinion from a specialist.

Scenario

Note: In this example, the family doctor’s EMR solution could be integrated with an external Referral Management System (RMS) or his EMR solution could have the capability to directly manage eConsults.

Jane Doe visits her family doctor complaining about pain occurring in her back and lower abdomen for the past two days. During the assessment, the family physician notes right-sided flank pain radiating from the back to the lower abdomen with fluctuating intensity that has not resulted in fever, nausea or vomiting. The patient has not had any recent trauma, numbness or weakness in extremities, and no saddle anesthesia. Suspecting renal colic, Jane's doctor sends her for an ultrasound. The ultrasound confirms a non-obstructing 5mm stone in the right ureter but also find an incidental complex renal cyst. Jane's family physician decides to consult a urologist to ask if the cyst can be managed with serial imaging, or whether a referral and consideration of a biopsy is necessary.

Option 1 - Request sent to a Specific Provider

The family physician would like to submit the consult request to a urologist they know. The family physician creates the eConsult request and submits the request directly to the selected urologist.

Option 2 - Request sent to a specialty organization (e.g., specialist clinic/hospital)

Jane's family physician knows which organization to submit the consult request to but will leave it to the case assigner at the organization to select the specialist. The family physician searches for an organization, creates the eConsult request, and submits the case to the organization. The case is received by the Case Assigner at the organization who assigns the case to a Urologist.

Option 3 - Request sent to Central Intake / Specialty Service Group (e.g., managed specialty)

The family physician creates an eConsult request for “Urology” and then submits the request to centralized intake/pool of specialists. The case is received and assigned to a specific specialist by the case assigner.

After Case Assignment

The urologist receives a notification for the assigned case, reviews the case details, and sends a response back to Jane's family physician. The specialist indicates that based on the size of the cyst and characteristics reported on the ultrasound, it can be safely monitored without the need for immediate intervention. A repeat ultrasound is recommended within 6 months.

Jane's family physician receives the consult response, reviews the notes left by the urologist. The family physician is satisfied with the response. Since no further clarification is required, the family physician closes the case.

Use Case Participants

People

• Requester HCP
• Performer HCP
• Case Assigner

Systems

• Requester POS system
• Performer POS system
• eReC Source
• eReC Target
• Central Intake (eReC Target + eReC Source)
• Health Service Directory (HSD)

Please refer to Participants for definitions.

Triggers

Patient visit with a Requester Health Care Provider (HCP) that results in a consultation request.

Pre-conditions

• The POS system has the capability to directly manage the referral workflow or is integrated with an external eReC Source/eReC Target
• The POS system or eReC Source is integrated with a valid and up-to-date Health Services Directory
• Appropriate patient consent in accordance with jurisdictional requirements and legislation, whether implied or expressed, has been obtained to share their personal and health information during the referral process.
• Patients have indicated their communication preferences and provided consent to receive notifications and information about their eReferral status and appointment via their selected method(s).
• Patient information in Requester POS system is valid and up-to-date.

Post-conditions

• The Requester HCP closes the consult request after receiving response from Performer HCP (e.g., Requester HCP has no further questions for the Performer HCP after reviewing the consultation notes and/or attachments from the Performer HCP). And/Or,
• The Requester HCP initiates an eReferral because the Performer HCP wishes to see the patient for an in-person consultation. Or,
• The Requester HCP cancels the consult request. Or,
• The Requester HCP redirects the consult request to another specialist (e.g., individual, organization, or specialty service group). Or,
• The Performer HCP declines the consult request.

Workflow Diagram - Specific Provider

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

Use Case - Primary Flow (Specific Provider)

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

1. Requester HCP initiates a consult request.

2. Requester HCP searches and selects a specific provider from the Service Directory.

   The Health Service Directory could be i) centrally managed, or ii) locally integrated with the POS system, or iii) part of an eReC Source that is integrated with POS system.

3. Requester HCP writes consultation question, attaches images and notes.

4. Requester HCP submits consult request. eReC Source transmits the request to the eReC Target.

   The eReC Source could be i) an EMR/HIS which has the capability to directly manage eConsults (the system is both a POS system and eReC Source) or ii) an external Referral Management System (RMS) (the eReC Source is integrated with the Requester HCP POS System).

5. The eReC Target receives the request and automatically assigns the request to the Performer HCP.

   The eReC Target could be i) an EMR/HIS which has the capability to directly manage eConsults (the system is both a POS system and eReC Target) or ii) an external Referral Management System (RMS) (the eReC Target is integrated with the Performer HCP POS System).

6. Performer HCP receives a notification on the arrival of the new consult request.

7. Performer HCP reviews the consult request through their eReC Target and responds to the consult request by entering in notes and/or attachments.

8. Performer HCP sends the consultation notes back to the Requester HCP.

9. Requester HCP receives a notification indicating that a consult has been provided.

10. Requester HCP reviews the consultation response in eReC Source

11. Requester HCP is satisfied with the information, and closes the request.

Use Case - Alternate Flows (Specific Provider)

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

1. Clarification Requested (Step 10): After a consult has been provided, if further information is needed, the Requester HCP has the ability to request clarification from the Performer HCP.
2. Request for Information (Step 7): Performer HCP requests for more information from the Requester HCP and Requester HCP provides the information.
3. Case Cancelled (Step 5 - 7): The Requester HCP can decide to cancel the consult request if the consult is no longer needed.
4. Case Redirect by Requester (Step 5 - 7): The Requester can redirect the consult request to another another specialist, organization or central intake/specialty service group. This closes the original consult request and creates a new request for the recipient.
5. Return Case and convert to eReferral (Step 7): The Performer HCP provides the consult and indicates they wish to see the patient. The Requester HCP completes the consult and initiates an eReferral. (UC-01: Referral to a Service)
6. Case Rejected by Performer (Step 7): The Performer HCP rejects the consult because it is not appropriate or is missing information. This closes the consult request.
7. Performer HCP completes Performance KPI Survey (Step 7): Performer HCP may answer questions related to billing and time spent on case after providing the consult.
8. Requester HCP completes Performance KPI Survey (Step 11): Requester HCP may answer questions related to service utilization and feedback for Performer HCP.

Workflow Diagram - Specialty Organization

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

Use Case - Primary Flow (Specialty Organization)

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

1. Requester HCP initiates a consult request.

2. Requester HCP searches and selects an organization from the Service Directory

   The Health Service Directory could be i) centrally managed, or ii) locally integrated with the POS system, or iii) part of an eReC Source that is integrated with POS system.

3. Requester HCP writes consultation question, attaches images and notes.

4. Requester HCP submits consult request, and eReC Source sends the request.

   The eReC Source could be i) an EMR/HIS which has the capability to directly manage eConsults (the system is both a POS system and eReC Source) or ii) an external Referral Management System (RMS) (the eReC Source is integrated with the Requester HCP POS System).

5. Case Assigner at the specialty group receives the consult request through eReC Target and assigns to a Performer HCP.

   The eReC Target could be i) an EMR/HIS which has the capability to directly manage eConsults (the system is both a POS system and eReC Target) or ii) an external Referral Management System (RMS) (the eReC Target is integrated with the Performer HCP POS System).

6. Performer HCP receives a notification on the arrival of the new consult request.

7. Performer HCP accesses the consult request through their eReC Target and responds to the consult request by entering in notes and/or attachments.

8. Performer HCP sends the consultation notes back to the Requester HCP.

9. Requester HCP receives a notification indicating that a consult has been provided.

10. Requester HCP reviews the consultation response using their eReC Source.

11. Requester HCP is satisfied with the information, and closes the request.

Use Case - Alternate Flows (Specialty Organization)

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

1. Clarification Requested (Step 10): After a consult has been provided, if further information is needed, the Requester HCP has the ability to request clarification from the Performer HCP.
2. Request for Information (Step 7): Performer HCP requests for more information from the Requester HCP and Requester HCP provides the information.
3. Case Cancelled (Step 5 - 7): The Requester HCP can decide to cancel the consult request if the consult is no longer needed.
4. Case Redirect by Requester (Step 5 - 7): The Requester can redirect the consult request to another another specialist, organization or central intake/specialty service group. This closes the original consult request and creates a new request for the recipient.
5. Case Redirect by Assigner (Step 6): The Case Assigner at the specialty can redirect the consult request to another Performer HCP, which does not close the original consult request, but simply redirects it to another target.
6. Return Case (Step 6): The case is returned by the Performer HCP to the Case Assigner to be assigned to another specialist.
7. Return Case and convert to eReferral (Step 7): The Performer HCP provides the consult and indicates they wish to see the patient. The Requester HCP completes the consult and initiates an eReferral. (UC-01: Referral to a Service)
8. Case Rejected by Performer (Step 7): The Performer HCP rejects the consult because it is not appropriate or is missing information. This closes the consult request.
9. Case Self-assigned by Performer (Step 5): The Performer HCP may assign themselves to the case from a queue of incoming consult requests at the specialty group, essentially acting as the Case Assigner.
10. Performer HCP completes Performance KPI Survey (Step 7): Performer HCP may answer questions related to billing and time spent on case after providing the consult.
11. Requester HCP completes Performance KPI Survey (Step 11): Requester HCP may answer questions related to service utilization and feedback for Performer HCP.

Workflow Diagram - Specialty Service Group / Central Intake

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

Use Case - Primary Flow (Specialty Service Group / Central Intake)

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

1. Requester HCP indicates the need for a consult.

2. Requester HCP searches and selects a Specialty/sub-specialty from the Service Directory. A default selection is provided based on location which can be overridden by Requester HCP.

   The Health Service Directory could be i) centrally managed, or ii) locally integrated with the POS system, or iii) part of an eReC Source that is integrated with POS system.

3. Requester HCP writes consultation question, attaches images and notes.

4. Requester HCP submits consult request, which is transmitted by eReC Source.

   The eReC Source could be i) an EMR/HIS which has the capability to directly manage eConsults (the system is both a POS system and eReC Source) or ii) an external Referral Management System (RMS) (the eReC Source is integrated with the Requester HCP POS System).

5. Case Assigner at the Specialty Service Group receives the consult request through Central Intake (eReC Target + eReC Source) system and assigns to an available Performer HCP.

   The Central Intake System receives consult request from Requester HCP and routes it to a downstream Performer HCP. It can act as both the eReC Target (for Case Assigner to receive consult requests) and an eReC Source (for Case Assigner to assign a request to the Performer HCP)

6. Central Intake (eReC Target + eReC Source) routes the consult request which is received by eReC Target (Performer)

   The eReC Target could be i) an EMR/HIS which has the capability to directly manage eConsults (the system is both a POS system and eReC Target) or ii) an external Referral Management System (RMS) (the eReC Target is integrated with the Performer HCP POS System).

7. Performer HCP receives a notification on the arrival of the new consult request.

8. Performer HCP accesses the consult request through their eReC Target, and responds to the consult request by entering in notes and/or attachments.

9. Performer HCP sends the consultation notes back to the Requester HCP via Central Intake (eReC Target + eReC Source).

10. Requester HCP receives a notification indicating that a consult has been provided.

11. Requester HCP reviews the consultation response using their eReC Source.

12. Requester HCP is satisfied with the information, and closes the request.

Use Case - Alternate Flows (Specialty Service Group / Central Intake)

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

1. Clarification Requested (Step 11): After a consult has been provided, if further information is needed, the Requester HCP has the ability to request clarification from the Performer HCP.
2. Request for Information (Step 8): Performer HCP requests for more information from the Requester HCP and Requester HCP provides the information.
3. Case Cancelled (Step 5 - 8): The Requester HCP can decide to cancel the consult request if the consult is no longer needed.
4. Case Redirect by Requester (Step 5 - 8): The Requester can redirect the consult request to another another specialist, organization or central intake/specialty service group. This closes the original consult request and creates a new request for the recipient.
5. Case Redirect by Assigner (Step 7): The Case Assigner at the specialty can redirect the consult request to another Performer HCP, which does not close the original consult request, but simply redirects it to another target.
6. Return Case (Step 7): The case is returned by the Performer HCP to the Case Assigner to be assigned to another specialist.
7. Return Case and convert to eReferral (Step 8): The Performer HCP provides the consult and indicates they wish to see the patient. The Requester HCP completes the consult and initiates an eReferral. (UC-01: Referral to a Service)
8. Case Rejected by Performer (Step 8): The Performer HCP rejects the consult because it is not appropriate or is missing information. This closes the consult request.
9. Case Self-assigned by Performer (Step 5): The Performer HCP may assign themselves to the case from a queue of incoming consult requests at the specialty group, essentially acting as the Case Assigner.
10. Performer HCP completes Performance KPI Survey (Step 8): Performer HCP may answer questions related to billing and time spent on case after providing the consult.
11. Requester HCP completes Performance KPI Survey (Step 12): Requester HCP may answer questions related to service utilization and feedback for Performer HCP.

UC-03: Referral to a Central Intake

Description

Requester Health Care Provider sends a referral request to a Central Intake, which forwards to most appropriate downstream Performer Health Care Provider

Scenario

Note: In this example, Dr. Jones' electronic medical record (EMR) solution could be integrated with an external Referral Management System (RMS) or his EMR solution could have the capability to directly manage eReferrals.

Mary Jane has a ski accident. Her primary care practitioner, Dr. Jones, strongly suspects that Mary Jane has torn her anterior cruciate ligament (ACL) in the right knee and would like to refer Mary Jane for further assessment.

Dr. Jones initiates an eReferral for “Orthopedics” and selects the appropriate service. The referral requirements are presented on his screen, with some information already completed based on information available in the EMR. Dr. Jones completes the rest of the information required for the referral.

Option 1 - Routing requests (Central Intake forwards request)

Note: In this scenario, the referral is received by Central Intake. A case assigner at Central Intake assigns the request to a specialist.

Dr. Jones submits the referral request to Central Intake. A notification is sent to Mary Jane to confirm that the referral has been requested.

The central intake system notifies the triage nurse about the incoming request. The triage nurse forwards the request to Dr. Treat, an orthopedic surgeon who is located a close distance to Mary Jane's home and has the shortest wait time. The referral request is forwarded to Dr. Treat. Dr. Jones also receives an update about the triage decision.

Dr. Treat’s office receives a notification about the referral request. The office staff contact Mary jane and schedule an appointment with her.

Updates are sent to Dr. Jones when the appointment is scheduled, any changes to the referral request, and when the appointment is complete.

Option 2 - Chaining requests

Note: In this scenario, the referral is received by Central Intake and an assessment is completed at a Rapid Access Clinic/ Rapid Assessment Centre. If the assessment outcome results in further services required, a new referral (that is linked to the initial referral) is created for the additional services.

Dr. Jones submits the referral request to Central Intake. A notification is sent to Mary Jane to confirm that the referral has been requested.

The central intake system notifies the triage nurse about the incoming referral request. The triage nurse assigns the referral to an available advanced practice provider at a Rapid Access Clinic / Rapid Assessment Centre / (RAC) that serves the geographic area where Mary Jane resides.

The administrative team at the RAC contacts Mary Jane and schedules an appointment. After completing the assessment, the advanced practice provider determines that Mary Jane is a candidate for surgery. The assessment outcome is sent to Central Intake and an update is also sent to Dr. Jones.

The triage nurse at Central Intake creates a new referral and sends the request to Dr. Treat, an orthopedic surgeon who is located a close distance to Mary Jane's home and has the shortest wait time. Dr. Jones also receives an update about the triage decision.

Dr. Treat’s office receives a notification about the referral request. The office staff contact Mary jane and schedule an appointment with her.

Updates are sent to Dr. Jones when the appointment is scheduled, any changes to the referral request, and when the appointment is complete.

Option 3 - Splitting requests

Note: In this scenario, the referral is received by Central Intake. Since more than one service is requested, the case assigner at Central Intake “splits” the request and assigns each service to a different service provider.

When completing the referral requirements, Dr. Jones sees that diagnostic imaging results need to be included with the eReferral request. Dr. Jones creates a request for an MRI and an ultrasound on the same eReferral request and sends the request to Central Intake.

The central intake system notifies the triage nurse about the incoming request. The triage nurse “splits” the request and sends the request for the services (MRI and ultrasound) to two different diagnostic imaging sites.

At the respective diagnostic imaging sites, the administrative staff are notified about the incoming request, contact Mary Jane and schedule an appointment with her.Updates are sent to Central Intake and Dr. Jones when the appointments are scheduled, as well as when the appointments have been completed.

Use Case Participants

People

• Requester HCP
• Performer HCP
  • Downstream Service - Performer HCP (B)
  • Rapid Assessment Centre - Performer HCP A
• Case Assigner

Systems

• Requester POS system
• Performer POS system
  • Downstream Service
  • Rapid Assessment Centre
• eReC Source
• eReC Target
  • Downstream Service
  • Rapid Assessment Centre
• Central Intake (eReC Target + eReC Source)
• Health Service Directory (HSD)

Please refer to Participants for definitions.

Triggers

Requester Health Care Provider (HCP) needs to send a referral request for a patient.

Pre-conditions

• The POS system has the capability to directly manage the referral workflow or is integrated with an external eReC Source/eReC Target
• The POS system or eReC Source is integrated with a valid and up-to-date Health Services Directory
• Appropriate patient consent in accordance with jurisdictional requirements and legislation, whether implied or expressed, has been obtained to share their personal and health information during the referral process.
• Patients have indicated their communication preferences and provided consent to receive notifications and information about their eReferral status and appointment via their selected method(s).
• Patient information in Requester POS system is valid and up-to-date.

Post-conditions

• Performer HCP completes the service and closes the eReferral request. The Requester HCP and Central Intake are updated about outcome of service. This includes when:
  • Performer HCP completes the initial consultation appointment with the patient.
  • When a rapid assessment centre is used, Performer HCP A at the Rapid Assessment Centre completes assessment appointment with the patient and patient does not require further services. Or,
• Performer HCP converts the eReferral to an eConsult and provides advice to the Requester HCP instead of assessing the patient at an in-person appointment (UC-2: Consultation Request), Or,
• The service request was not fulfilled or was ended before completion because:
  • The Requester HCP cancels the referral request. Or,
  • The Case Assigner at Central Intake declines the referral request. Or,
  • The Performer HCP A at Rapid Assessment Centre declines the referral request. Or,
  • The Performer HCP (B) at Downstream Service declines the referral request. Or,
  • The Patient declines the service.

Workflow Diagram - Routing/Splitting Requests

• Routing: The same referral request is forwarded to a new downstream service from Central Intake.
• Splitting: The referral request gets split into multiple parts/services that logically make up the original request at Central Intake, to be fulfilled by different downstream services. There could be further successive downstream services beyond the first downstream service shown in diagram below. A routed/split referral may be followed by successive chaining, routing or splitting operations at each successive downstream service in any combination needed to fulfil the original referral.

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

Use Case - Primary Flow - Routing/Splitting Requests

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

1. Requester HCP initiates a referral request.

2. Requester HCP searches and selects an appropriate central intake service from a Service Directory.

   The Health Service Directory could be i) centrally managed, or ii) locally integrated with the POS system, or iii) part of an eReC Source that is integrated with POS system.

3. Requester HCP is presented with, and completes the referral requirements, and/or provides a clinical narrative to support the reason for the referral. Patient information and some of the referral requirements may be automatically filled in based on information available in the POS system.

4. Requester HCP may optionally attach additional clinical notes and supporting documentation from the POS system to support the referral request.

5. Requester HCP submits the referral request (clinical documentation and/or completed referral requirements). eReC Source transmits the referral request to Central Intake (eReC Target + eReC Source) and an electronic notification is sent to the Patient that the referral request has been sent.

   The eReC Source could be i) an EMR/HIS which has the capability to directly manage eReferrals (the system is both a POS system and eReC Source) or ii) an external Referral Management System (RMS) (the eReC Source is integrated with the Requester HCP POS System).

6. Central Intake (eReC Target + eReC Source) receives the referral request and notifies Case Assigner.

7. Case Assigner processes the referral request (Processing includes analysis of referral request needs, urgency, downstream service wait times, location and may include consideration for patient preference for location, waiting period and health care provider.).

   1. If referral request contains multiple distinct services, it is split into its constituent parts to be forwarded to appropriate downstream services to fulfill different parts of the request.
   2. If referral request is just for a single service, it is routed to the appropriate downstream service as the same request.

8. Central Intake (eReC Target + eReC Source) transmits the referral request to the downstream service, and a notification to Requester eReC Source, which informs Requester HCP about the routed/split referral.

9. eReC Target (Downstream Service) receives the referral request and notifies Performer HCP.

   The eReC Target could be i) an EMR/HIS which has the capability to directly manage eReferrals (the system is both a POS system and eReC Target) or ii) an external Referral Management System (RMS) (the eReC Target is integrated with the Performer HCP POS System).

10. Performer HCP contacts the patient to arrange an appointment. After the appointment is scheduled, the eReC Target (Downstream Service) transmits an update to Central Intake (eReC Target + eReC Souce), which forwards to the Requester eReC Source. The Requester HCP receives a notification that the appointment has been booked.

11. Performer HCP completes the initial consultation appointment with the patient and closes the eReferral request. The eReC Target (Downstream Service) transmits an update to Central Intake (eReC Target + eReC Source) which forwards it to the Requester eReC Source. The Requester HCP receives a notification that the appointment has been completed.

Workflow Diagram - Chaining Requests

• Chaining: A new, distinct referral is created to a downstream service based on the original referral after a service is performed. There could be further successive downstream services beyond the first downstream service shown in diagram below. A chained referral may be followed by successive chaining, routing or splitting operation at each successive downstream service in any combination needed to fulfil the referral.

Use Case - Primary Flow - Chaining Requests

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

1. Requester HCP initiates a referral request.

2. Requester HCP searches and selects an appropriate central intake service from a Service Directory.

   The Health Service Directory could be i) centrally managed, or ii) locally integrated with the POS system, or iii) part of an eReC Source that is integrated with POS system.

3. Requester HCP is presented with, and completes the referral requirements, and/or provides a clinical narrative to support the reason for the referral. Patient information and some of the referral requirements may be automatically filled in based on information available in the POS system.

4. Requester HCP may optionally attach additional clinical notes and supporting documentation from the POS system to support the referral request.

5. Requester HCP submits the referral request (clinical documentation and/or completed referral requirements). eReC Source transmits the referral to Central Intake (eReC Target + eReC Source) and an electronic notification is sent to the Patient that the referral request has been sent.

   The eReC Source could be i) an EMR/HIS which has the capability to directly manage eReferrals (the system is both a POS system and eReC Source) or ii) an external Referral Management System (RMS) (the eReC Source is integrated with the Requester HCP POS System).

6. Central Intake (eReC Target + eReC Source) receives the referral request and notifies Case Assigner.

7. Case Assigner processes the referral and routes to an assessment centre (i.e. a Rapid Assessment Centre). (Processing includes analysis of referral request needs, urgency, downstream service wait times, location and may include consideration for patient preference for location, waiting period and health care provider.).

8. Central Intake (eReC Target + eReC Source) transmits the referral request to the assessment centre, and a notification to Requester eReC Source, which informs Requester HCP about the routed referral for assessment.

9. eReC Target (Rapid Assessment Centre) receives the routed request and notifies Performer HCP A.

   The eReC Target could be i) an EMR/HIS which has the capability to directly manage eReferrals (the system is both a POS system and eReC Target) or ii) an external Referral Management System (RMS) (the eReC Target is integrated with the Performer HCP POS System).

10. Performer HCP A confirms referral request acceptance and contacts patient for assessment.

11. eReC Target (Rapid Assessment Centre) transmits the acceptance message along with any optional note to the Central Intake (eReC Target + eReC Source) which forwards it to Requester eReC Source, so that Requester HCP has access to the update that the patient is accepted for assessment.

12. Performer HCP A assesses patient is eligible for downstream service.

13. eReC Target (Rapid Assessment Centre) sends the assessment outcome to Central Intake (eReC Target + eReC Source) which forwards it to Requester eReC Source, so that Requester HCP has access to the assessment outcome.

14. Case Assigner processes the updated referral and creates a new distinct referral request to a downstream service, eReC Target (Downstream Service).

15. Central Intake (eReC Target + eReC Source) transmits the referral request to the downstream service, and a notification to Requester eReC Source, so that Requester HCP has access to the update about the new downstream referral.

16. eReC Target (Downstream Service) receives the referral request and notifies Performer HCP B.

    The eReC Target could be i) an EMR/HIS which has the capability to directly manage eReferrals (the system is both a POS system and eReC Target) or ii) an external Referral Management System (RMS) (the eReC Target is integrated with the Performer HCP POS System).

17. Performer HCP B contacts the patient to arrange an appointment. After the appointment is scheduled, the eReC Target (Downstream Service) transmits an update to Central Intake (eReC Target + eReC Souce), which forwards to the Requester eReC Source. The Requester HCP receives a notification that the appointment has been booked.

18. Performer HCP B completes the initial consultation appointment with the patient and closes the eReferral request. The eReC Target (Downstream Service) transmits an update to Central Intake (eReC Target + eReC Source) which forwards it to the Requester eReC Source. The Requester HCP receives a notification that the appointment has been completed.

Use Case - Alternate Flows - Routing/Splitting/Chaining Requests

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

1. Request for Information from Central Intake:
   1. Case Assigner requests more information from Requester HCP and sends a request for information from Central Intake (eReC Target + eReC Source).
   2. Requester HCP views the Request for Information and updates the referral with the requested information.
   3. Case Assigner receives the referral update in Central Intake (eReC Target + eReC Source) and processes the referral using the remaining steps in the flow
2. Request for Information from Assessment Centre:
   1. Performer HCP A at Rapid Assessment Centre requests more information from Requester HCP and sends a request for information to Central Intake (eReC Target + eReC Source) from their eReC Target (Rapid Assessment Centre).
   2. The request for information is forwarded from Central Intake (eReC Target + eReC Source) to Requester eReC Source.
   3. Requester HCP views the Request for Information and updates the referral with the requested information. Referral update is received in Central Intake (eReC Target + eReC Source) and forwarded by Central Intake (eReC Target + eReC Source) to eReC Target (Rapid Assessment Centre)
   4. Performer HCP A receives the referral update in eReC Target (Rapid Assessment Centre) and processes the referral using the remaining steps in the flow
3. Request for Information from Downstream Service:
   1. Performer HCP (B) at Downstream Service requests more information from Requester HCP and sends a request for information to Central Intake (eReC Target + eReC Source) from their eReC Target (Downstream Service).
   2. The request for information is forwarded from Central Intake (eReC Target + eReC Source) to Requester eReC Source.
   3. Requester HCP views the Request for Information and updates the referral with the requested information.
   4. Referral update is received in Central Intake (eReC Target + eReC Source) and forwarded by Central Intake (eReC Target + eReC Source) to eReC Target (Downstream Service)
   5. Performer HCP (B) receives the referral update in eReC Target (Downstream Service) and processes the referral using the remaining steps in the flow
4. Decline from Central Intake:
   1. Case Assigner at Central Intake declines the referral request, the decline notification is sent to Requester from Central Intake (eReC Target + eReC Source).
   2. Requester HCP receives the decline status in their eReC Source.
5. Decline from Assessment Centre:
   1. Performer HCP A at Rapid Assessment Centre declines the referral request, the decline notification is sent to Central Intake (eReC Target + eReC Source) from their eReC Target (Rapid Assessment Centre).
   2. Case Assigner at Central Intake receives the decline, sends a referral request to another Rapid Assessment Centre, and an update to Requester HCP about the new referral to another Rapid Assessment Centre
   3. Requester HCP receives the update in their eReC Source.
6. Decline from Downstream Service:
   1. Performer HCP (B) at Downstream Service declines the referral request, the decline notification is sent to Central Intake (eReC Target + eReC Source) from their eReC Target (Downstream Service).
   2. Case Assigner at Central Intake receives the decline, sends a referral request to another Downstream Service, and an update to Requester HCP about the new referral to another Downstream Service
   3. Requester HCP receives the update in their eReC Source.
7. Decline from Patient
   1. Patient declines the referral at the Requester, Central Intake, Rapid Assessment Centre and Downstream Service settings.
   2. Notifications about the referral decline are sent upstream to Central Intake/Requester or downstream to Rapid Assessment Centre / Downstream Service depending on in which setting the patient declined the referral, and if a referral is already sent to the Rapid Assessment Centre or Downstream Service.
   3. Requester HCP / Case Assigner at Central Intake / Performer HCP A at Rapid Assessment Centre / Performer HCP (B) at Downstream Service receives the update in their POS/eReC Source or integrated eReC Source.
8. Patient not Eligible for Downstream Service
   1. Performer HCP A assesses patient at Central Intake and determines that a referral to downstream service is not needed
   2. Central Intake (eReC Target + eReC Source) sends the referral outcome to Requester HCP.
   3. Requester HCP receives the update in their eReC Source.
9. Cancellation:
   1. Requester HCP cancels the service request in their eReC Source, which sends the cancellation message to the Central Intake (eReC Target + eReC Source) and notifies Patient by their communication preference that the initial referral has been cancelled.
   2. Case Assigner receives the referral cancellation notification in the Central Intake (eReC Target + eReC Source). If a referral request has been sent/forwarded to a Rapid Assessment Centre or Downstream Service, Central Intake (eReC Target + eReC Source) sends the cancellation message to the eReC Target (Rapid Assessment Centre) / eReC Target (Downstream Service).
   3. eReC Target (Rapid Assessment Centre) / eReC Target (Downstream Service) receives the cancellation notifications and any appointments/tasks created in response to the referral request are cancelled.
10. Referral Updates
    1. Requester HCP updates the initial referral to add additional service(s) and commits the update in their eReC Source.
    2. Case Assigner receives the updated service request including the new service from the Central Intake (eReC Target + eReC Source) and processes the modified referral to completion using the remaining steps in the basic flow.
11. Appointment Date Changed by Patient
    1. Patient changes the appointment date with Rapid Assessment Centre or Downstream Service
    2. Performer HCP A at Rapid Assessment Centre / Performer HCP (B) at Downstream Service updates the referral with the new appointment date and the update notification is sent upstream to Requester HCP
    3. Requester HCP receives the update in their eReC Source.
12. Convert Referral to a Consultation
    1. Performer HCP A at Rapid Assessment Centre / Performer HCP (B) at Downstream Service may convert a referral to a consultation (providing advice to the Requester HCP instead of an appointment with the patient - See UC-02: Consultation Request).
    2. Requester HCP receives the consultation notes in their eReC Source.