Overview

Use cases have been developed to illustrate clinical and workflow scenarios, and are intended to provide examples of how eReferrals/eConsults can be managed using digital health systems and 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.

These use cases illustrate high-level interactions or “conversations” between participants (e.g., health care providers, patients, etc.) and their use of digital health systems/solutions (e.g., EMR/EHR solutions, Referral Management System, etc.) for managing eReferrals and/or eConsults. For detailed interactions, refer to: Messaging and Sequence Diagrams sections of this specification.

The use cases were developed in collaboration with the eReferral Interoperability Working Group, and jurisdictions involved in determining in-scope use cases for this Pan-Canadian eReferral-eConsult (CA:eReC) Implementation Guide. The Ontario eReferral – eConsult – HL7® FHIR® Implementation Guide was also referenced for examples of eReferral/eConsult use cases.

Each use case includes:

• clinical scenario (example),
• participants (i.e., people and systems),
• use case triggers, pre- and post- conditions,
• primary workflow, including detailed steps in the process and a workflow diagram to provide a visual representation of the interactions between participants,
• additional workflows (extra steps or processes that are added to the primary workflow to handle specific circumstances or requirements),
• alternate workflow (alternative processes or pathways that achieve a different outcome from the primary workflow based on specific circumstances or requirements).

Use Case Index

The list below includes the use case ID, name and description that are in-scope for Release 1.

Caveat

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

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

These use cases are applicable to the following implementation scenarios:

1. The sender(s) and receiver(s) have implemented specialized Referral Management Systems (RMS) to manage eReferrals/eConsults.
2. The sender(s) and receiver(s) have implemented point of service (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. The sender(s) and receiver(s) work within a shared platform/portal to manage eReferrals/eConsults.

UC-01: Referral directly to a Service Provider

UC-01: Description

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

UC-01: Scenario

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 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.

The medical office assistant at the neurosurgical specialist’s office is notified of the incoming referral request. After reviewing the request, the specialist decides to schedule an in-person appointment with Jane and his office assistant contacts Jane to schedule an appointment. Updates are electronically sent to Dr. Jones when the appointment is scheduled and completed to keep him informed about the referral status.

UC-01: Participants

Please refer to Participants for definitions.

UC-01: Triggers

Requester HCP needs to refer a patient for services with another provider (e.g., specialty care)

UC-01: Pre-conditions

• The Source System/Target System used by the healthcare provider is a) a point of Service (POS) system that includes RMS capability, or b) a Referral Management System (RMS) that is integrated with the POS system.
• The Source System 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.
• The Source System has the ability to submit referral requests in the prescribed format.
• The Target System has the ability to receive and respond to referral requests in the prescribed format
• Patient information in Source System is valid.

UC-01: Post-conditions

• Primary Flow: The Performer HCP completes the initial consultation appointment with the patient and completes the referral request;
• Alternate A: The Performer HCP declines the referral request;
• Alternate B: The Performer HCP converts the referral to a consultation; (See UC-02: Provider-to-Provider Consultation Request)
• Alternate C: The Performer HCP cancels the referral request after it was accepted;
• Alternate D: The Requester HCP revokes the referral request.

UC-01: Workflow diagram

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

Please see Sequence Diagrams for UC-01: Referral to a Service for a technical sequence diagram implementing this use case.

UC-01: Primary Flow

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

1. Requester HCP initiates a referral request.

2. Requester HCP searches for and selects the appropriate service and/or service provider (based on results from the Health Service Directory).

   For implementation guidance on interactions with a Service directory, please refer to the pan-Canadian Care Service Directory (CA:CSD)

3. Requester HCP is presented with and completes the referral requirements. Patient information and some of the referral requirements may be automatically populated based on information available in the POS system.

4. Requester HCP may provide a clinical narrative to support the reason for the referal and/or attach additional clinical notes/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 Requester (Source system) transmits the referral request to the Performer (Target system).

6. The Performer (Target system) receives the referral request. The Performer HCP receives a notification about the new referral request.

7. The Performer HCP reviews the request.

   Note:The request may be received and initially reviewed by administrative/support staff at the specialist’s office before being reviewed by the specialist.

8. The Performer HCP accepts the request, and an appointment is booked with the patient. The Performer HCP updates the referral status. The Performer (Target system) transmits an update to the Requester HCP (Source system).

   If the Performer HCP declines the request, see Alternate Flow A and B.

9. Performer HCP completes the initial consultation appointment with the patient. The Performer (Target system) transmits an update to the Requester (Source system).

UC-01: Additional Flows

The following are extra steps/processes that may be added to the primary workflow to handle specific circumstances or requirements.

i. The Performer HCP needs additional information (after step 5 and before step 8)

The Performer HCP requests more information from the Requester HCP before they can decide whether to accept the referral. The Performer HCP and Requester HCP systems have the ability to communicate and send questions/additional information.

ii. Updates to the referral request (after step 5 and before Step 9)

The Performer HCP and/or Requester HCP may update the referral request after it is submitted to/ received by the Performer. This may include sending communications, updating the referral request with new information, etc.

iii. Case Assigner assigns the request to a Performer HCP (after step 6 and before step 7)

Typically, when multiple providers work at the organization (e.g., specialist clinic, hospital), a Case Assigner will assign incoming requests to an individual Performer HCP associated with the organization. If a preferred Performer HCP is not listed on the referral request or is unable to accept the request (e.g., does not have capacity to accept new patients), the request may be assigned to an alternate provider at the organization.

iv. The appointment scheduled with the Provider HCP is changed (after step 8 and before step 9)

When the original appointment is rescheduled, the Performer HCP updates information in the Target system and an update is sent to the Source system. The appointment may be rescheduled due to patient preference and at the discretion of the Performer HCP.

UC-01: Alternate Flows

The following are processes/pathways that achieve a different outcome from the primary workflow based on specific circumstances or requirements.

A. Request declined by Performer HCP (step 8)

The Performer HCP decides to decline the referral request after reviewing it. The Performer HCP updates the referral status and includes a reason for declining the request (e.g., unable to provide the service) in the Target system. An update is automatically transmitted to the Source system.

B. Referral request changed to a Consult request by Performer HCP (step 8)

The Performer HCP decides to decline the referral request (e.g., does not schedule patient for an in-person appointment) but provides advice to the Requester HCP. If the Target System includes this functionality, the Performer HCP can convert the referral request to an eConsult. Alternatively, the Performer HCP may decline the referral request and ask the Requester HCP to create and send an eConsult request.

C. Referral request cancelled by Performer HCP (after Step 8 and before Step 9)

The Performer HCP cancels the referral request after accepting the patient. This can occur when the Performer HCP or patient decides to cancel the request after it has been initiated but before the referral/consult process is completed. Reasons can vary and may include patient preference, changes in medical status or administrative reasons. The Performer HCP updates the referral status in the Target system and an update is transmitted to the Source system.

D. Referral request revoked by the Requester HCP (after step 5 and before step 9)

The Requester HCP may revoke the referral request after it is submitted to the Performer HCP and before the appointment with the patient is completed. Reasons can vary and may include patient preference, reassessment of patient needs, changes in medical status and/or clinical judgment/diagnosis, transfer of care to another provider or facility, or administrative reasons. The Requester HCP updates the referral status is the Source system and an update is transmitted to the Target system.

UC-03: Referral to Central Intake

UC-03: Description

Requester Health Care Provider (HCP) sends a referral request to Central Intake. Central Intake assigns the referral request to an appropriate and available Performer HCP.

Notes:

• A Central Intake model to manage eReferrals may be implemented (provincially, regionally, or locally at organization level) for specific health care specialties/services.

• When a central intake model is used for eReferrals, Central Intake serves as a centralized mechanism or intermediary to manage eReferral requests, ensuring incoming requests are assigned to an appropriate specialist/service provider. The Case Assigner at Central Intake may be a healthcare professional (e.g., nurse) trained to assess the urgency and appropriateness of referrals.

• Typically, Central Intake focuses on administrative aspects of handling eReferral requests). However, responsibilities of Central Intake can vary across jurisdictions/regions and may include ensuring completeness of referral requests, scheduling appointments, tracking and monitoring referral statuses, and supporting follow-up processes. In some cases, Central Intake may also include triaging/prioritizing request (based on urgency, clinical criteria, established protocols/clinical pathways), facilitating communications and information exchange between the referring provider and specialist/healthcare professional

UC-03: Scenario

Mary Jane had a ski accident. Her primary care provider, a family physician, strongly suspects that Mary Jane has torn her anterior cruciate ligament (ACL) in the right knee and would like to refer her for further assessment. The primary care provider creates an eReferral for Mary Jane, selecting the appropriate specialty (Orthopedics), service and reason for referral. The referral requirements are displayed on his screen, with some information already populated from Mary Jane’s electronic medical record (EMR). The family physician completes the remaining information needed for the referral. The referral request is submitted and received by Central Intake. Central intake assigns the request to a Performer HCP based on one of the following scenarios:

Option 1 (UC-03a): Central Intake forwards request to Performer HCP (Routing Request)

“Routing requests” refers to the process of directing or forwarding eReferrals to an appropriate healthcare provider or specialist. In this scenario, Central Intake receives the eReferral request and assigns it to a specialist based on availability and other relevant criteria, ensuring the referral is directed to the most suitable provider who can address the patient's condition or concerns effectively.

Central Intake receives a notification of the new eReferral request. The Case Assigner reviews the details and forwards the request to an orthopedic surgeon located a close distance to Mary Jane's home with the shortest wait time. The family physician receives a referral status update that the request has been sent to the specialist.

The specialist’s office receives a notification about the incoming referral request. After reviewing the request, the orthopaedist accepts the patient for treatment and the office staff book an appointment for Mary Jane. The family physician receives a referral status update that an appointment has been scheduled.

After the specialist has conducted the initial consultation appointment with Mary Jane, the family physician receives a status update that the appointment has been completed.

Option 2 (UC-03b): Subsequent referral linked to initial referral request (Chaining requests)

"Chaining requests" refers to a sequential referral process where subsequent referrals are connected or chained to an initial referral request.

In this scenario, Central Intake directs the referral to a Rapid Access Clinic/ Rapid Assessment Centre (RAC). If the assessment outcome indicates further services are needed, a subsequent referral (that is linked to the initial referral) is created by Central Intake for the additional services.

Notes:

• This example assumes referrals to RAC is sent through central intake. Depending on policies and processes established by the jurisdiction, region, and/or organization, requests to RACs may alternatively follow a direct referral pathway (i.e., request is sent directly to RAC and bypass Central Intake). If a direct referral pathway is used, see UC-01: Referral directly to a Service Provider.
• If Central Intake assigns the referral to a RAC, it is typically assigned at the facility level rather than at the individual level, and the RAC team (administrative and clinical staff) manage the intake process and subsequent assessment and treatment planning. The patient is assessed by a health professional with the required training and qualifications, who may be a nurse practitioner, a specialty provider (e.g physiotherapist), or other advanced practice provider.
• If results of the RAC assessment indicate the patient requires additional services from another provider (surgical or non-surgical), a new referral that is linked to the original request is created by Central Intake. Alternatively, depending on policies and processes established by the jurisdiction, region, and/or organization the RAC could create the new referral linked to the original request, and send it i) directly to a service provider, or ii) to Central Intake to assign a service provider.

Central Intake receives a notification of the new eReferral request. The Case Assigner at central intake forwards the referral to a Rapid Access Clinic/Rapid Assessment Centre (RAC) that serves the geographic area where Mary Jane resides.

The RAC staff triage and assign the referral to an appropriate and available healthcare provider (e.g., advanced practice provider within the RAC who will conduct the assessment. Administrative staff at the RAC schedule Mary Jane for an appointment.

Based on results of the assessment, Mary Jane is a potential candidate for surgery. The RAC sends an update to Central Intake that the assessment has been completed. The Central Intake creates a new referral, linked to the original request, and sends it to an orthopedic surgeon. An update is sent to the family physician that the original eReferral has been completed and a new referral has been created for Mary Jane.

Note: If a Central Access and Triage (CAT) model is used, the original request is deemed completed and an update is sent to CAT. A new referral, linked to the original request, is created by CAT and sent to an orthopedic surgeon. See UC-04: Referral to Central Access and Triage (CAT)

Option 3 (UC-03c): A single referral divided into multiple referrals (Splitting requests)

“Splitting requests” refers to the process where a single referral is divided or split into multiple referrals, each directed to a different providers or services.

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 site.

When completing requirements for the referral request, the family physician sees that diagnostic imaging results need to be included. The family physician creates a single eReferral for an MRI and an ultrasound and sends the request to Central Intake.

Central Intake receives a notification of the new eReferral request. The Case Assigner at central intake “splits” the request into separate referrals (MRI and ultrasound) and the requests are sent to two different diagnostic imaging sites.

At the respective diagnostic imaging facilities, the administrative staff receive a notification about the incoming request and schedule an appointment with Mary Jane. Updates for each referral are sent to Central Intake and the family physician when appointments are scheduled as well as when each appointment is completed.

UC-03: Participants

Please refer to Participants for definitions.

UC-03: Triggers

Requester HCP needs to refer a patient for services with another provider (e.g., specialty care).

UC-03: Pre-conditions

• The Source system/Target system used by the healthcare provider is a) the point of Service (POS) system that includes RMS capability, or b) a standalone Referral Management System (RMS) that is integrated with the POS system.
• The Source system 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.
• The Requester Source system has the ability to submit eConsults in the prescribed format.
• The Performer Target system has the ability to receive and respond to eConsults in the prescribed format.
• Patient information in Source system is valid.
• The Performer HCP has registered as a service provider for centrally managed referrals.

UC-03: Post-conditions

• Primary Flow: The Performer HCP completes the service and the eReferral request is closed.
  • UC-03a (Routing): Performer HCP completes the initial consultation appointment with the patient.
  • UC-03b (Chaining): The rapid assessment centre/ rapid access clinic (RAC) completes the assessment appointment with the patient. If the patient requires additional services, a new referral that is linked to the initial request is created.
  • UC-03c (Splitting): All the requested services on the initial referral have been completed.
• Alternate A: Central Intake declines the referral request; or
• Alternate B: The Performer HCP declines the referral request;
• Alternate C: The Performer HCP converts the referral to a consultation;
• Alternate D: The Requester HCP revokes the referral request;
• Alternate E: The Performer HCP cancels the referral request;
• Alternate F: Based on outcomes of the RAC assessment, the patient does not require additional services (only applicable to UC-03b)

UC-03a/c: CENTRAL INTAKE – ROUTING/SPLITTING REQUESTS

• Routing: The referral request is forwarded to a Performer HCP (downstream service).
• Splitting: The referral request contains request for multiple services and is split into different referrals at Central Intake. Each referral corresponds to the original request and is directed to different Performer HCPs (downstream services).

UC-03a/c (Routing/Splitting Requests): Workflow Diagram

This 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. Additional downstream services may be required beyond the initial workflow depicted in the diagram below. A routed or split referral may be followed by successive chaining, routing, or splitting operations at each subsequent downstream service, as necessary, to fulfill the original referral.

Please see Sequence Diagrams for UC-03: Referral to a Central Intake for a technical sequence diagram implementing this use case.

UC-03a/c (Routing/Splitting Requests) - Primary Flow

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

1. The Requester HCP initiates a referral request.

2. The Requester HCP searches for and selects the appropriate service (based on results from the Health Service Directory). There may be the option to select a preferred service provider (e.g., organization, specialist).

3. The Requester HCP is presented with and completes the referral requirements. Patient information and referral requirements may be automatically populated based on information available in the POS system.

4. The Requester HCP may provide a clinical narrative to support the reason for the referral and/or attach additional clinical notes/supporting documentation from the POS system to support the referral request.

5. The Requester HCP submits the referral request with the required information and clinical documentation to Central Intake. The Source system transmits the referral request to the Central System.

6. Central System receives the referral request. The Case Assigner at Central Intake is notified of the new referral request.

7. The Case Assigner at Central Intake processes the referral request. This may include reviewing the referral details, triaging/prioritizing the request (based on urgency, clinical criteria, established protocols/clinical pathways, etc.) and determining the most appropriate healthcare provider for the request (based on wait times, location, patient preference, etc.).

8. The Case Assigner at Central Intake determines if the referral request needs to be split.

   1. If the eReferral request is to be completed by the same service provider (individual or organization), it is routed to the appropriate Performer HCP (UC-03a).
   2. If the eReferral request needs to be completed by multiple service providers, the Case Assigner may split the request into separate referral requests, one for each service. (UC-03c).

   Note: If the original eReferral was split into multiple requests, steps 9 to 12 are completed for each referral request.

9. The Case Assigner at Central Intake forwards the request to the appropriate Performer HCP. The Central System transmits the request to the Performer Target system and sends an update to the Requester HCP.

   Note: If the eReferral request, is forwarded to a Rapid Assessment Centre/ Rapid Access Clinic (RAC), the RAC is the Performer HCP (see primary workflow for UC-03b below).

10. The Performer Target system receives the referral request. The Performer HCP receives a notification about the new referral request and reviews it.

11. The Performer HCP accepts the request, and an appointment is booked with the patient. After the appointment is scheduled, the Performer Target system transmits an update to the Central System, which then forwards the update to the Requester Source system. The Requester HCP receives an update that the appointment has been booked.

    If the Performer HCP declines the request, see Alternate Flow B.

12. Performer HCP completes the appointment with the patient and closes the eReferral request. The Performer Target system transmits an update to the Central Intake, which then forwards the update to the Requester Source system. The Requester HCP receives an update that the appointment/service has been completed.

UC-03b: CENTRAL INTAKE – CHAINING REQUESTS

Chaining: After a referral request is completed and the patient needs further services, a subsequent referral (based on the original eReferral) is created and sent to the additional Performer HCP.

UC-03b (Chaining Requests): Workflow Diagram

This 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. Additional downstream services may be required beyond the initial workflow depicted in the diagram below. A routed or split referral may be followed by successive chaining, routing, or splitting operations at each subsequent downstream service, as necessary, to fulfill the original referral.

Please see Sequence Diagrams for UC-03: Referral to a Central Intake for a technical sequence diagram implementing this use case.

UC-03b (Chaining Requests): Primary Flow

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

Complete Steps 1 to 8 in UC-03a/c Primary Flow (see above)

9. If the eReferral request, based on established protocols and pathways, requires an assessment to be completed by a Rapid Assessment Centre/ Rapid Access Clinic (RAC), Central Intake forwards the request to the appropriate RAC (UC-03b)

   In this scenario, the RAC is the Performer HCP

10. The RAC (Target system) receives the referral request. The Performer HCP at the RAC receives a notification about the new referral request and reviews it.

11. The Performer HCP accepts the request and assigns it to a health care professional (such as an advanced practice practitioner) at the RAC who will conduct the patient assessment. The RAC books an appointment with the patient. After the appointment is scheduled, the RAC (Target system) transmits an update to the Central System, which forwards to the Requester Source system. The Requester HCP receives an update that the appointment has been booked.

    If the RAC declines the request, see Alternate Flow B.

12. The RAC completes the assessment appointment with the patient and indicates whether additional services (surgical or non-surgical) is needed. The RAC (Performer Target system) transmits an update to the Central System, which forwards to the Requester (Source system). The Requester HCP receives an update that the appointment has been completed.

13. If the patient requires additional services, the Central Intake creates a new referral (linked to the original request) for the subsequent service directly to the service provider (see UC-01: Referral directly to a Service Provider). Updates about the new referral are sent to the Requester HCP.

    If no additional services are required, see Alternate Flow F.

    Note: Depending on established protocols and pathways and the capabilities of the RAC Target System, the new linked referral may be created at the RAC.

UC-03: Additional Flows

The following are extra steps/processes that may be added to the primary workflow to handle specific circumstances or requirements.

i. Central Intake needs additional information (after step 6 and before step 9)

The Case Assigner at Central Intake requests more information from the Requester HCP (sent from the Central System to the Requester HCP). The Requester HCP updates the eReferral with the requested information. The update is sent to the Central System and accessed by the Case Assigner.

ii. The Performer HCP needs additional information (after step 10 and before step 11)

The Performer HCP requests more information from the Requester HCP before they can decide whether to accept the referral. The Performer HCP and Requester HCP systems have the ability to communicate and send questions/additional information. The request for information is sent to Central Intake. Central Intake forwards the request to the Requester HCP. When Central Intake receives an update/response from the Requester HCP, the new information is forwarded by Central Intake to the Performer HCP.

iii. Updates to the referral request (after step 5 and before Step 12)

The Performer HCP, Requester HCP and/or Central Intake may update the referral request after it is submitted to Central Intake and before the Performer HCP completes the service. This may include sending communications, updating the referral request with new information, etc.

iv. The appointment scheduled with the Provider HCP is changed (after step 11 and before step 12)

The appointment may be rescheduled due to patient preference or at the discretion of the provider HCP. When the original appointment is rescheduled, the Performer HCP updates information in the Target system. The Performer (Target system) transmits an update to the Central Intake (Central System) which forwards to the Requester (Source system). The Requester HCP receives an update that the appointment has been completed.

UC-03: Alternate Flows

The following are processes/pathways that achieve a different outcome from the primary workflow based on specific circumstances or requirements.

A. Request declined by Central Intake (after step 7 and before step 8)

The Case Assigner at Central Intake declines the referral request after reviewing it. The Case Assigner updates the referral status and includes a reason for declining the request (e.g., unable to provide the service) in the Central System. An update is transmitted to the Requester HCP (Source system).

B. Request declined by Performer HCP (step 11)

The Performer HCP declines the referral request after reviewing it. The Performer HCP updates the referral status and includes a reason for declining the request (e.g., unable to provide the service) in the Performer Target system. An update is sent to the Central System.

Central Intake reviews the reason the request was declined. Central Intake may reassign the request to a different Performer HCP or cancel the request. The Central System sends the update to the Requester HCP (Source system).

C. Referral request changed to a Consult request by Performer HCP (step 11)

The Performer HCP decides to decline the referral request (e.g., does not schedule patient for an in-person appointment) but provides advice to the Requester HCP. If the Target System includes this functionality, the Performer HCP can convert the referral request to an eConsult.

Alternatively, the Performer HCP may decline the referral request and indicate an eConsult should be requested. Depending on established protocols, the Requester HCP or Central Intake may create the eConsult request.

D. Referral request cancelled/revoked by the Requester HCP (after step 5 and before step 12)

The Requester HCP may cancel/revoke the referral request after it is submitted to Central Intake and before the Performer HCP completes the appointment. Reasons can vary and may include patient preference, reassessment of patient needs, changes in medical status and/or clinical judgment/diagnosis, transfer of care to another provider or facility, or administrative reasons.

The Requester HCP updates the referral status is the Source system and an update is transmitted to Central Intake and the Target system. The Performer HCP receives an update that the eReferral has been cancelled

E. Referral request cancelled by Performer HCP (after Step 11 and before Step 12)

The Performer HCP cancels the referral request after accepting the patient. This can occur when the Performer HCP or patient decides to cancel the request after it has been initiated but before the referral/consult process is completed. Reasons can vary and may include patient preference, changes in medical status or administrative reasons.

The Performer (Target system) transmits an update to the Central System and the Requester (Source system). The Requester HCP receives an update that the eReferral has been cancelled.

If request was sent to RAC (UC-03b)

F. Patient does not require additional services (step 13).

Based on the results of the assessment, the patient does not need additional services. The RAC closes the eReferral. The RAC (Target system) transmits an update to the Central System and the Requester (Source system). The Requester HCP receives an update that the eReferral has been completed.

UC-04: Referral to Central Access and Triage (CAT)

UC-04: Description

Requester Health Care Provider sends a referral request to Central Access and Triage, which manages the referral process

Notes:

• A Central Access & Triage (CAT) model to manage eReferrals may be implemented (provincially, regionally, or locally at organization level) and/or for specific health care specialties/services.
• While a Central intake model may primarily focus on administrative processing/scheduling, the CAT model incorporates more comprehensive clinical triage and care coordination processes. Protocols and clinical pathways, developed with input from the health care providers, guide the referral processes.
• When a CAT model is used, all referral status events flow back to Central Access & Triage (CAT) as the owner/manager of the entire referral journey. CAT manages the status of the central (provincial) record and communicates information back to the referring provider as workflow progresses through a central RMS system.
• This use case assumes that all participants are integrated for electronic message flows; however the workflow requirement allows for both integrated and non-integrated communications (e.g. referral record could be sent via e-fax or other channel).

UC-04: Scenario

Jayanti is a retired professional athlete. During her career, she experienced a number of injuries which has led to chronic pain challenges. Despite efforts with physiotherapy and medication, the pain in her right shoulder has worsened. Recent imaging (x-ray, ultrasound, and MRI within the past 12 months) has confirmed a deterioration in her condition. Several years ago, Jayanti found relief through joint injections administered by an orthopedic surgeon in another city (where she was previously living).

Based on established clinical pathways, Jayanti ’s family physician refers her to an orthopedic specialist for a reassessment and to explore appropriate options for alleviating her on-going discomfort, which may include potential joint injections.

The eReferral is submitted to the Central Access & Triage (CAT) centre. Upon receiving the eReferral, the CAT team reviews the request, prioritizes it based on clinical guidelines, creates a central referral record and assigns the request to an appropriate and available orthopedic specialist.

The medical office assistant at the orthopedic surgeon’s office is notified of the incoming referral request. After reviewing the request, the specialist decides to schedule an in-person appointment with Jayanti and his office assistant contacts Jayanti to schedule an appointment. Updates on the status of Jayanti’s referral is sent to the CAT. Jayanti’s family physician receives updates from the CAT when the appointment is scheduled and completed, to keep her informed about the referral status.

UC-04: Participants

Please refer to Participants for definitions.

UC-04: Pre-conditions

• The Source System is integrated with a valid and up-to-date Health Services Directory. The Health Service Directory can be provided by the Jurisdiction/ region (e.g., CAT services catalogue in Alberta) and define specialty/subspecialty and/or reason for referral.
• 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.
• Patient information in Requester POS system is valid
• The Requester Source system has the ability to submit eReferrals in the prescribed format.
• The Performer Target system has the ability to receive and respond to eReferrals in the prescribed format.
• The Performer HCP has registered as a service provider for centrally managed referrals.

UC-04: Post-conditions

• Primary Flow: The Performer HCP completes the requested service and CAT closes the referral;
• Alternate A: The Performer HCP declines the referral request and CAT closes the referral.
• Alternate B: CAT cancels the referral without assigning it to a Performer HCP;
• Alternate C: The Performer HCP cancels the referral request after it was accepted, and CAT closes the referral
• Alternate D: The Requester HCP revokes the referral request and CAT closes the referral.

UC-04: Workflow diagram

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

Please see Sequence Diagrams for UC-04: Central Access and Triage (CAT) for a technical sequence diagram implementing this use case.

UC-04: Primary Flow

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

1. The Requester HCP initiates a referral request.
2. The Requester HCP searches for and selects the appropriate service (based on results from the Health Service Directory). Available options may be based on reason for referral. The Requester HCP may have the option to designate a preferred service provider.
3. The Requester HCP completes the information needed for the requested service.
4. The Requester HCP submits the referral request to CAT. The Requester (Source System) transmits the eReferral to the CAT (Central System).
5. CAT receives the request and creates the central referral record in the Central System. CAT communicates the shared referral identifier with the Requester HCP.
6. CAT reviews the request for adherence to business rules for referral contents.

• If CAT needs additional information, see Additional Flow i

7. CAT assigns the request to an appropriate Performer HCP and the Central System sends the referral record to the Performer HCP

8. CAT notifies the Requester HCP that the referral record is now updated with the Performer assignment.

9. The Performer HCP acknowledges receipt of the newly assigned referral request. Performer Target System initiates the corresponding Performer workflow.

10. The Performer HCP reviews the referral request.

• If Performer HCP requests information from the Requester HCP, see Additional Flow ii

11. Performer HCP agrees to perform the requested service.

• If the Performer HCP declines the request, see Alternate Flow A.

12. CAT receives the accepted status from the Performer HCP, and updates the state of the central referral record as applicable.
13. CAT notifies the Requester HCP that the referral record is now updated with a status indicating acceptance by the Performer HCP.
14. The Performer HCP schedules the appointment for the patient consultation, and the Target System sends the appointment details to the CAT Central System.
15. CAT receives the appointment details from the Performer HCP, and updates the state of the central referral record as applicable.
16. CAT informs the Requester HCP of the scheduled appointment.
17. The Performer HCP fulfils the requested service through the patient consultation appointment, and notifies CAT that the performer workflow is complete.
18. CAT receives the completed status from the Performer HCP, and updates the state of the central referral record as applicable.
19. CAT notifies the Requester HCP that the referral record is now updated with a status indicating completion of the requested service.

UC-04: Additional Flows

The following are extra steps/processes that may be added to the primary workflow to handle specific circumstances or requirements.

i. CAT requests additional information from Requester HCP (after step 6 and before step 7)

• The CAT needs more information from the Requester HCP before they can assign the request to the Performer HCP.

1. CAT documents the additional information needed, and sends the information request to the Requester HCP.
2. Requester HCP receives the request and gathers the information needed.
3. Requester HCP updates the service request with the additional information (e.g. attached supporting info) and/or separately documents a communication containing their response; then sends the assembled response to CAT.
4. Use case flow returns to step 7 of the primary flow, for assignment of the Performer HCP.
   

ii. Performer HCP requests additional information from Requester HCP (step 10)

• The Performer HCP needs more information from the Requester HCP.

1. Performer HCP documents the additional information needed and sends the information request to CAT to manage as part of the central referral record.
2. CAT receives the information request from the Performer HCP, and updates the state of the central referral record as applicable.
3. CAT incorporates any centrally managed information to the Performer HCP information request as needed, and sends to the Requester HCP for response.
4. Requester HCP updates the service request with the additional information (e.g. attached supporting info) and/or separately documents a communication containing their response; then sends the assembled response to CAT.
5. CAT receives the information response from the Requester HCP, and updates the state of the central referral record as applicable.
6. CAT sends the response information to the Performer HCP.
7. Use case flow returns to step 10 for the performer to review and resume related workflow.
   

iii. CAT redirects referral request to a new Performer HCP (see Alternate Flow B)

• CAT may redirect the case to a different Performer HCP. Reasons for this can vary and may include case declined by Performer HCP. This does not close the referral request but rather redirects it to a new Performer HCP.

1. CAT receives the declined information from the Performer HCP that indicates they cannot fulfill the request as assigned.
2. CAT identifies an alternate service provider for the referral request, and replaces the assigned Performer HCP.
3. Use case flow returns to step 7 of the primary flow, where workflow re-starts under the new performer.

UC-04: Alternate Flows

The following are processes/pathways that achieve a different outcome from the primary workflow based on specific circumstances or requirements.

A. Request declined by Performer HCP (step 8)

• The Performer HCP decides to decline the referral request after reviewing it. The Performer HCP updates the referral status and includes a reason for declining the request (e.g., unable to provide the service) in the Target System. An update is sent to CAT.

1. Performer HCP determines either that the service cannot or should not be fulfilled as requested, or that the referral request is appropriate but cannot be fulfilled as assigned; then notifies CAT of the declined request along with details of the reason for declining.
2. CAT receives the declined information from the Performer HCP, and updates the state of the central referral record. If the request is redirected to a new performer, see Additional Flow iii
3. CAT notifies the Requester HCP that the referral record for the referral request has now been updated to indicate a declined service, including the decline reason.

UC-02: Provider-to-Provider Consultation Request

UC-02: Description

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

UC-02: Scenario

Note: In this example, the family doctor manages the eConsult directly in his POS system. The electronic medical record (EMR) solution (POS system) could be integrated with an external Referral Management System (RMS) or the 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 finds an incidental complex renal cyst. Jane's family physician decides to consult a urologist to determine if the cyst can be managed with serial imaging, or whether a referral and consideration of a biopsy is necessary.

The consultation request is created and submitted to the specialist as follows:

Option 1 (UC-02a): Directly to a specific specialist

The eConsult request is sent directly to a designated specialist (individual).

The family physician creates the eConsult request and selects the desired urologist (e.g., one whom they have an existing professional relationship). The request is submitted directly to the selected urologist.

Option 2 (UC-02b) Directly to a specific organization

The eConsult request is sent to a designated organization (e.g., specialist clinic, hospital, etc.) that offers the required service. These organizations are staffed by multiple healthcare professionals (e.g., specialists) that offer the specialized care and/or services. Typically, a Case Assigner at the organization is responsible for assigning the request to an individual specialist within the organization.

The family physician creates the eConsult request and submits the request to the selected organization (e.g., specialist clinic or hospital). The request is received by the Case Assigner who assigns the case to an available urologist at the organization.

Option 3 (UC-02c) To Central Intake/Specialist Pool

When a central intake model/specialist pool is used for eConsults, Central Intake/Specialist Pool serves as a centralized mechanism to manage and distribute eConsult requests and facilities the response process. Upon receiving an eConsult request, Central Intake/Specialist Pool may triage the request based on urgency, clinical criteria, or specific protocols (e.g., jurisdictional/ regional clinical pathways and processes, designed with clinical experts). A Case Assigner at Central Intake/Specialist Pool may assign the request to an appropriate and available specialist within their network, or a specialist may self-assign requests.

The family physician creates an eConsult request and submits the request to Central Intake/ specialist pool (e.g., specialty service group, managed specialty). The Case Assigner at Central Intake assigns and forwards the request to an available urologist.

After Case Assignment

The urologist receives a notification of the assigned case, reviews the details, and sends a response back to Jane's family physician. Based on the size and characteristics of the cyst reported on the ultrasound, the specialist indicates that 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 urologist’s response, reviews the notes and is satisfied with the response. Since no further clarification is required, the family physician closes the case.

UC-02: Participants

Please refer to Participants for definitions.

UC-02: Triggers

Requester Health Care Provider (HCP) seeks advice/opinion from a specialist on a patient case.

UC-02: Pre-conditions

• The Source system/Target system used by the healthcare provider is a) the point of Service (POS) system that includes RMS capability, or b) a standalone Referral Management System (RMS) that is integrated with the POS system.
• The Source system 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.
• The Requester Source system has the ability to submit eConsults in the prescribed format.
• The Performer Target system has the ability to receive and respond to eConsults in the prescribed format.
• Patient information in Source system is valid.
• UC-02c only: The Performer HCP has registered as a service provider for centrally managed referrals.

UC-02: Post-conditions

• Primary Flow: The Requester HCP closes the consult request after receiving response from the Performer HCP (i.e., Requester HCP has no further questions);
• Alternate A: The Requester HCP revokes the consult request;
• Alternate B: The Requester HCP revokes the consult request and redirects the request to different specialist, organization or specialist pool;
• Alternate C: The Requester HCP creates an eReferral based on eConsult response;
• Alternate D: The Performer HCP declines the consult request;
• Alternate E: Alternate E: The Performer HCP returns the consult request to the Case Assigner (only applicable to UC-02b and UC-02c)
• Alternate F: The Case Assigner declined the consult request (only applicable to UC-02b and UC-02c)

UC-02: Workflow Diagram

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.

Please see Sequence Diagrams for UC-02: Consultation Request for a technical sequence diagram implementing this use case.

UC-02: Primary Flow

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

1. The Requester HCP initiates a consult request for the patient case.

2. The Requester HCP searches for and selects the desired service and service provider from the Health Service Directory.

   1. If the request is sent directly to a specific specialist, the service (specialty/ subspecialty) and desired specialist (individual) are selected.
   2. If the request is sent directly to a specific organization, the service (specialty/ subspecialty) and the desired organization (e.g., specialist clinic, hospital) are selected.
   3. If the request is sent to central intake/specialist pool, the service (specialty/ subspecialty) is selected. The system may automatically assign a specialist pool (e.g., based on geographic boundaries) and/or the Requester HCP may select a specialist pool (e.g., based on patient preferences).

3. The Requester HCP writes the consultation questions and attaches images/notes to support the consult request.

4. The Requester HCP submits the consult request to the selected Provider HCP. The Source system transmits the request to the Target system.

5. The Target system receives the request.

   1. If the request is sent directly to a specific specialist, the Target system automatically assigns the case to the Performer HCP (designated specialist).

   2. If the request is sent directly to a specific organization, the Case Assigner at the organization reviews the consult request and assigns the case to the Performer HCP (specific specialist within the organization). Note: The Performer HCP may also self-assign incoming consult requests.

   3. If the request is sent directly to Central Intake/Specialist Pool, the Case Assigner at Central Intake receives the consult request through the Central Intake system and assigns the case to an appropriate and available Performer HCP. The Central Intake System transmits (routes) the consult request to the Performer HCP system (Target system). Note: The Performer HCP may also self-assign incoming consult requests.

6. The Performer HCP receives a notification of the new consult request and reviews the details.

7. The Performer HCP accepts the request and provides their response by entering notes and/or attachments in the Target system.

8. The Performer HCP sends the consultation response back to the Requester HCP.

9. The Requester HCP receives a notification in the Source system that a response to the consult request has been provided and reviews the specialist’s response.

10. The Requester HCP is satisfied with the advice/opinion and the request is completed.

UC-02: Additional Flows

The following are extra steps/processes that may be added to the primary workflow to handle specific circumstances or requirements.

i. The Performer HCP needs additional information (after step 5 and before step 7) The Performer HCP requests more information from the Requester HCP before they provide a consult response. The Performer HCP and Requester HCP systems have the ability to communicate and send questions/additional information.

ii. The Requester HCP needs clarification after receiving response (after Step 9 and before step 10) The Requester HCP would like clarification (e.g., additional information) after the initial consult response has been received from the Performer HCP. Both the Requester HCP system and Provider HCP system have the capability to send/respond communications (e.g., follow-up questions).

iii. The Performer HCP completes Performance KPI Survey (after step 10) The Performer HCP may answer questions related to billing and time spent on case after providing the consult. This may be a requirement in some jurisdictions.

iv. The Requester HCP completes Performance KPI Survey (after step 10) The Requester HCP may answer questions related to service utilization and feedback on the Performer HCP. This may be a requirement in some jurisdictions.

If a Case Assigner is involved (UC-02b and UC-02c)

v. The Case Assigner needs additional information (steps 5b/5c) The Case Assigner requests more information from the Requester HCP before they can assign the consult request. The Case Assigner and Requester HCP systems have the ability to communicate and send questions/additional information.

vi. The request is reassigned by the Case Assigner (after steps 5b/5c and before step 7) The Case Assigner may redirect the case to a different Performer HCP. Reasons for this can vary and may include case declined by Performer HCP, case revoked by the Case Assigner because the designated Performer HCP is unavailable or unable to provide a timely response. This does not close the consult request but rather redirects it to a new Performer HCP.

UC-02: Alternate Flows

The following are processes/pathways that achieve a different outcome from the primary workflow based on specific circumstances or requirements.

A. Request cancelled by Requester HCP (after step 5 and before step 8) The Requester HCP decides to cancel the consult request before receiving a response from the Performer HCP. Reasons may vary and can include changes in patient’s medical status or administrative reasons that result in the consult no longer being required.

B. Request revoked by Requester HCP (after step 5 and before step 8) The Requester HCP revokes the consult request before receiving a response from the Perfomer HCP and redirects the request to a different specialist, organization or specialty group. The original consult request is closed, and a new request is created for the new Performer HCP.

C. Request results in an eReferral request (Step 7) The Performer HCP responds to the consult request and recommends the patient be evaluated by a specialist. The eConsult is completed and the Requester HCP initiates an eReferral. (see UC-01: Referral to a Service and UC-03 Referral to Central Intake). If the POS system/RMS includes this functionality, the Performer HCP or Requester HCP can convert the consult request to an eReferral.

D. Request declined by Performer HCP (Step 7) The Performer HCP declines/rejects the case because they are not able to provide advice/opinion. Reasons can vary and may include the specialist's capacity constraints/lack of availability, clinical appropriateness, missing information, or other constraints. This closes the consult request.

If a Case Assigner is involved (UC-02b and UC-02c)

E. Request returned to Case Assigner by Performer HCP (Step 7) The case is returned to the Case Assigner by the Performer HCP. Depending on the reason provided by the Performer HCP, the Case Assigner may then request additional information from the Requester HCP (additional flow v.), reassign the case to another Performer HCP (additional flow vi), or decline the request (alternate flow F.)

F. Request declined by Case Assigner (Step 5b/5c) The Case Assigner declines/rejects the consult because they are not able to assign the case to a Performer HCP. Reasons can vary and may include lack of specialist availability, clinical appropriateness, missing information, or other constraints.