DRAFT - The specification is currently in development and subject to significant change. It is not ready for limited roll-out or production level use.


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.