DRAFT - The specification is currently in development and subject to significant change. It is not ready for limited roll-out or production level use.
eReferral and eConsult Business Models
Context
eReferrals and eConsults are created, submitted, tracked and managed electronically. When provider workflow considerations are addressed, eReferrals/eConsults have the potential to streamline and improve the patient referral and provider-to-provider consultation process compared to traditional paper-based or fax-based methods.
This specification defines messaging patterns to support models of eReferral and eConsult where system integrations are needed to enable clinical workflow and information sharing.
eReferral vs eConsult
An eReferral refers to patient referrals that are created, securely transmitted, tracked and managed electronically.
A patient referral is the process by which a healthcare professional directs a patient to a different healthcare professional or organization for care or services. A common example is from a primary care provider to a specialist but can also include requests for other services, such as diagnostic testing, home and community care or long-term care.
An eConsult refers to a consultation between health professionals conducted electronically.
A consultation occurs when a health professional seeks the expertise of another regarding a patient’s care, and can support consultations between health professionals from a range of major medical and behavioral health disciplines, including primary care professionals, specialists and allied health professionals.
Through eConsults, the requesting professional can send relevant patient information and specific questions to another health care professional and receive timely recommendations and/or guidance on the patient’s care, typically through asynchronous electronic communication channels.
These are distinct concepts with similar technical workflows that typically result in different outcomes:
- an eReferral typically results in the booking of an appointment but, where supported, may result in the provision of advice only
- an eConsult typically results in the provision of advice only (potentially advice to refer the patient)
Service Record
Within this specification, Service Record refers to a definitive set of information that is collected, maintained and managed throughout the referral or consultation process. The Service Record includes information about the:
- Patient who is the subject of the service request
- Referring Practitioner who sent the service request
- Service Request with a clinical Reason
- Supporting information to support triage and processing of the request
- Service Provider who has been assigned to perform the service with a location
- Status of the request with a status reason
- Appointment information (for referrals only)
- Outcome (optional)
Key elements of the Service Record with relationships are illustrated below:
The messaging defined in the specification allows different parties using different information systems to contribute content to the Service Record and access it according to their roles.
Participants in eReferral eConsult Information Exchange
During the service lifecycle, information is contributed to the Service Record by different parties participating in the process. By different People, Organizations and Systems.
People / Organizations
| Party | Description |
|---|---|
| Requester HCP | A Health Care Provider (HCP) or their delegate (e.g. medical office assistant), or other service provider that initiates and sends the service request. For eReferrals/eConsults, this is typically the primary care provider. |
| Case Assigner | An individual, organization, or automated process responsible for associating a request with a Performer HCP. Depending on the model employed, this could be a distinct role with additional responsibilities or performed by either the Requester HCP or Performer HCP. |
| Performer HCP | A Health Care Provider (HCP) or delegate, (e.g. medical office assistant), or other service provider that receives the service request and performs the requested services. |
Systems
The following systems commonly support end user workflows that support the service lifecycle and contribute to a patient's Service Record in one or more System Roles.
| System | Description |
|---|---|
| Referral Management System (RMS) | A specialized system that provides users with the functionality to collect, maintain, manage and disseminate information between participants in eReferral or eConsult workflows throughout the service lifecycle. A key function of an RMS is to generate and store a Service Record to support record keeping and communication throughout the service lifecycle. |
| Point of Service System (POS) | A system used in clinical settings to view and/or manage patient health information and health records. POS systems are an important source of supporting clinical information for an eReferral or eConsult. POS Systems participating in eReferral and eConsult include but are not limited to hospital information systems (HIS), electronic medical/health record (EMR/EHR) systems and provincial/regional EHR viewers. POS systems participating in eReferral / eConsult may provide the ability to initiate a request, receive updates as the request progresses and/or to receive a copy of the Service Record to support clinician workflow or recordkeeping requirements without providing other referral management functionality of a specialized RMS. |
Roles of Systems
| System | Description |
|---|---|
| Source System | A POS or RMS that is used by a Requester HCP to initiate a service request and to receive and access information about the request's status with related information and appointments. |
| Target System | A POS or RMS that is used by a Performer HCP to receive and process service requests. |
| Central System | A system (typically an RMS) that is used by a Case Assigner to receive, triage and assign service requests to Performer HCPs to be completed. Some business and deployment models (e.g.: Central Access and Triage) treat the Central System as the definitive source of the Service Record throughout the service lifecycle to support the use of Source System and/or Target System with limited RMS functionality. |
| Connected System | A system that receives event based notifications containing Service Record information from an RMS without contributing content to or progressing the state of the record. |
Information Contributed to the Service Record
| System | Primary Users | Content Provided |
|---|---|---|
| Source System | Requester HCP | - Patient Demographic and Identifying Info - Referring Practitioner Identifying Info - Requested Service - Referral Reason - Supporting Documentation |
| Central System | Case Assigner | - Service Provider Identifying Info |
| Target System | Performer HCP | - Referral Status - Appointment Info - Outcome(s) |
Information contributed to the record by the parties participating in eReferral/eConsult information exchange may originate in other systems integrated with some or all of the participating systems. This information exchange is beyond the scope of this guide, but where shared reference systems exist, references in messages may be used to look up information from the definitive source.
| System | Description | Relevant Content |
|---|---|---|
| Jurisdictional Registries | Registry systems within a jurisdiction may provide a definitive source for information about people, organizations or services referenced in a referral request or record. Relevant registries include: Client/Patient (CR), Provider (PR), Healthcare Service Directory (HSD) | CR: Patient Demographic and Identifying Info PR: Requester HCP Identifying Info & Performer HCP Identifying Info HSD: Requested Service & Service Provider Identifying Info For implementation guidance on interactions with a Service directory, please refer to the pan-Canadian Care Service Directory (CA:CSD) |
| Jurisdictional EHR | A jurisdiction's EHR may provide users of a POS or RMS with access to patient health information from other care settings that may be referenced in a referral. | - Supporting Documentation in referral |
Approaches to implementing eReferral Exchange
This section identifies a few different eReferral eConsult related business models that are supported by this specification.
Single RMS Model
In the Single RMS Model, a single referral management system supports the exchange of Service requests, Appointments and Secure Communications between Requester HCPs and Performer HCPs. This could be a multi-tenant cloud environment supporting multiple independent subscribers or a shared enterprise or jurisdictional system.
Example workflow:
- A Requester HCP (also performing the role of Case Assigner) initiates the referral in an RMS, selects a Performer HCP to provide the service, completes the required paperwork and sends the referral
- The Performer HCP receives the referral, triages the request for completeness & appropriateness, accepts and completes the referral in the same, shared RMS as the Requester HCP
- The RMS enable transmission of the referral to the Performer HCP as well as transmission of status updates, appointments, etc. to the Requester HCP
- A shared Service Record is created and maintained within the RMS as a result of information entered by the Requester HCP and Performer HCP
Connecting POS Systems
Within a Single RMS Model, system integrations with local point of service systems (POS) may be used to improve workflow, to support creation and management of referral record and/or to retain a copy of a referral Service Record in the patient's chart.
Referral record copied to POS
Where a POS system does not have built in support for referral management, HCPs may create and/or manage referrals in an RMS and then receive a copy of the Service Record in their POS system through a system integration.
Referral initiated and/or managed in POS
In other cases, a POS system may provide HCPs with the ability to:
- Initiate a referral in the POS system and then send a request to the RMS to create the Service Record through a system integration, and/or
- Receive and manage referral information in the POS system and then communicate updates to the referral's status (e.g.: acceptance, completion), and appointment information to the RMS's copy of the Service Record through a system integration
Point to Point Model
RMS solutions are not all the same and may be optimized to support the workflow of requesters, high volume receivers, specific health care providers / pathways, etc. In these situations, system integrations allow the unique features of two different RMS solutions to be connected into a single, integrated end to end solution.
In the Point to Point Referral Model, Health Care Providers (HCP)s who participate in referral workflows work within different Referral Management Systems (RMS) that each retain and manage separate instances of the Service Record that must be kept in sync.
For example:
- A Requester HCP may initiate the request in one RMS (Source System) and send it on to a recipient who uses another RMS (Target System)
- The Performer HCP receives the request, triages it for completeness & appropriateness, accepts and completes the request in the Target System
- An integration between Source System and Target System enables transmission of the service request to the Performer HCP as well as transmission of status updates, appointments, etc. to the Requester HCP
A simple illustration of the Point to Point Model is provided below.
In the Point to Point Model, system integrations with local point of service systes (POS) may be used to assist with creation of the service request, to notify users of updates, or to store a copy of the Service Record in the POS with the patient's chart.
Service Record "ownership" in the Point to Point Model
The Point to Point Model workflow requires the Service Record be maintained within and synhcronized between two distinct systems performing the roles of Source and Target where:
- Each system retains a full copy of the Service Record which is updated as local users perform actions and as information is received from the other system via the integration
- The Source System sends messages that focus on information that users acting in the role of Requester HCP and Case Assigner contribute to the Service Record (the Source System is considered the source of truth for the service request and supporting documentation)
- The Target System sends messages that focus on information that users acting in the role of Performer HCP contributes to the Service Record (the Target System is considered the source of truth for status and appointment information)
Single Entry Models
Single Entry Models aim to provide more equitable access to services and enable load balancing between service providers (etc.) by having a centralized entity perform services in support of the Requester HCP and/or Performer HCP within a service area and/or referral pathway.
Services performed by this centralized entity may include:
- Providing a single point for Requester HCPs to send service requests to for a defined geographic area or pathway with the centralized entity performing the Case Assigner role
- Providing a quality assurance step by reviewing / triaging requests for completion and appropriateness before the Case Assigner assigns the request to a Performer HCP, and/or
- Providing load balancing and potentially reducing wait times as Case Assigners delegate requests to the next available or most appropriate provider for the requested service.
Single Entry Models may be implemented using the Single RMS or Model or within a network of RMS solutions integrated using the Point to Point Model.
Service Record "ownership" in the Single Entry Models
In Single Entry Model workflows the roles of Requester HCP and Case Assigner are performed by different people or organizations. In these cases, there will be two (or more) separate "requests" that need to be appropriately managed by the Case Assigner and Central System (RMS).
In the case of a routed referral, the two requests would be:
- A service request from the Requester HCP to the Case Assigner (e.g.: to accept the service request, assign it appropriately, keep the Requester HCP updated as the service is performed), and
- A service request from the Case Assigner to the Performer HCP (e.g.: to accept the service request, perform it, keep the Case Assigner updated as the service is performed).
To support this, an integrated "Central System (RMS)" used by the Case Assigner will employ separate messaging approaches to:
- Enable the Case Assigner to receive the service request from the Requester HCP / Source System, communicate acceptance (etc.)
- Enable the Case Assigner to transmit the service request to the Performer HCP / Target System and receive, acceptance, (etc.)
- Enable the Case Assigner to notify the Requester HCP / Source System of its interactions with the Performer HCP as the service request is assigned, accepted, completed (etc.)
Examples:
A couple examples are provided below.
Example: Central Access and Triage (CAT) Model
Alberta's Central Access and Triage (CAT) referral model provides an enterprise solution to Single Entry by appointing a single entity within a service area to be accountable for:
- providing a single, centralized point of access for service requests throughout the service area
- Ensuring that requests are complete and appropriate before assigning to a Performer HCP
- Assigning the service request to the next available, appropriate Performer HCP
- Ensuring that requests assigned are accepted by and completed by the appropriate Performer HCP
- Managing and storing the shared Service Record on behalf of all participants in the referral process
In the CAT model, a shared enterprise RMS is used to manage a shared Service Record that the Requester HCP, CAT team (Case Assigner with additional responsibilities) and Performer HCP all contribute to.
Integrations with POS systems allow:
- A Requester HCP to initiate the referral process from their POS (Source System) by requesting a Service Record be created and assigned to a Performer HCP by the CAT team and receive acknowledgment, status updates (etc.)
- The CAT team (in the role of Case Assigner) to transmit the Service Record to the assigned Performer HCP and receive acknowledgement, status updates (etc.)
- The CAT team (in the role of Case Assigner) to notify the Requester HCP that the Service Record has been created and of its interactions with the Performer HCP as the request is assigned, accepted, completed (etc.)
Example: Central Intake in Point to Point
In Ontario, Central Intake services have been introduced to provide single points of access to high demand services within specific geographical areas within the province.
Organizations operating Central Intake services have a choice of RMS solutions to support their requirements and these have been introduced to an existing network of Point to Point integrations with existing Source Systems and Target Systems.
In this model the RMS used by Central Intake is a Target for requests from Requester HCPs and can be seen as a Source of Referrals to Performer HCPs.
To support this, an integrated RMS used by Central Intake (in role of Case Assigner) will employ separate messaging approaches to:
- Enable the Case Assigner to receive the service request from the Requester HCP / Source System, communicate acceptance (etc.)
- Enable the Case Assigner to transmit the service request to the Performer HCP / Target System and receive, acceptance, (etc.)
- Enable the Case Assigner to notify the Requester HCP / Source System of its interactions with the Performer HCP as the service request is assigned, accepted, completed (etc.)