Business Context > Business Model

Context

Healthcare providers need to be able to refer patients to the care they need, anywhere in the province in a fair and consistent manner. Current paper based referrals and disconnected electronic systems are a significant barrier to this.

Electronic Referral (eReferral) simplifies the referral process by enhancing communication between primary care providers, specialists and other healthcare service providers enabling quick and secure referrals to be sent, received and managed through an electronic platform.

This Ontario eReferral FHIR implementation guide (IG) is intended to enable the provincial integration solution outlined in the Provincial eReferral Strategy – Conceptual and Information Architecture Report (CIA) (sections 4 & 5) by providing standard, non-proprietary ways for systems that participate in eReferrals to interoperate with one another.

As a starting point, this IG supports only a subset of the functionality, pathways, and provincial integration envisioned in the CIA Report.

Conceptual Architecture

A key goal of the CIA is to establish distributed/de-centralized referral networks that enable healthcare pactitioners and service providers to use their systems to refer patients to a broad range of different specialists and service providers locally and across the province.

As illustrated in the following diagram, key goals for this IG are to provide standards based methods to:

  • connect the systems that healthcare practitioners and service providers use in their practices with the different software applications currently used to support electronic referrals within their local area, and
  • connect the systems used by different referral networks to one another.

CIA

Systems

Different types of systems will play a role in achieving this goal:

Point of Service Systems (POS) are software applications used by healthcare practitioners or service providers for viewing or managing personal health information (PHI). Common POS systems include, but is not limited to, hospital information systems (HIS), primary care electronic medical record systems (EMR), community and ambulatory health information systems, and provincial/regional EHR viewers.

In an eReferral context:

  • a Referral Requester POS System is the POS System that a healthcare practitioner or service provider uses to initiate and potentially track and manage Healthcare Service Requests.
  • a Referral Recipient (Performer) POS system is a POS system used by a healthcare practitioner or service provider who will provide the requested healthcare services, and to which the request will be routed.

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

Referral Management Systems (RMS) are systems that help facilitate the exchange of referral requests between Requesters and Performers in situations where one or both POS Systems do not have all the required/preferred capabilities to support the workflow. 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 Service Request Workflows. They can also be considered helper apps.

In an integration supported by this IG, an RMS may perform one or both of the following roles:

  • An RMS Source is used by a healthcare service provider to initiate, monitor and/or communicate about a request. An RMS Source will typically enable providers to:

    • 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 status;
    • receive information about appointments and tasks planned and performed in response to the request;
    • communicate with other service providers using messaging.

  • An RMS Target is used by a healthcare service provider to receive, respond to, manage and/or communicate about a request. RMS Target functionality will vary between systems used by service providers to respond to different request types but may include some or all the following:

    • receive, review, acknowledge, accept, reject and requests and supporting information;
    • communicate with the requester using messaging;
    • plan tasks to be performed in response to the request;
    • appointment scheduling, and
    • monitoring the status of planned tasks.

  • An RMS used by an organization for central intake or case planning may provide a combination of the features above to support forwarding of requests and/or creation of child requests

Health Services Directory Services (HSD) are systems that enable a healthcare practitioner or service provider to efficiently identify appropriate services and service providers to address patient needs.

An HSD may provide one or more of multiple functions, including:

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

Note: It is common for a single system to bundle the functions of an RMS and HSD, to provide a well integrated, user friendly workflow.

Referral Processes in Ontario

Business processes for referring patients to specialists, community based organizations, long term care, central intake (etc.) vary significantly within the province of Ontario.

Areas of variation include:

  • referral forms
  • requirements for supporting information including signed documents
  • requirements for appointment booking
  • inclusion of a patient assessment
  • routing rules based on wait times or matching algorithms
  • splitting, chaining, and forwarding of referrals
  • patient self-referral
  • consultations in care

To support this variation, this IG provides foundational building blocks to support diverse workflow patterns and it is anticipated that it will continue to evolve as new patterns and requirements are surfaced.

Supporting eReferral Processes

To facilitate different referral processes and the different capabilities of software applications used at the point of care, this implementation guide (IG) provides specifications for:

  • a SMART, user interface level, integration that may be implemented to connect the software applications that healthcare practitioners or service providers use to manage patients in their practice to an referral management system (and associated referral network) to create referral requests, and
  • a Direct Messaging integration that may be implemented to enable a bi-directional exchange of information about referral requests, appointments, referral related tasks and communications between the systems used by different networks of providers.

The following table provides an overview of the business workflow to create and manage electronic referral (eReferral) with supporting functionality:

# Step Description Supporting Functionality
1. Select target Healthcare Service A healthcare practitioner or service provider (requester) browses a directory (or map) of services and/or service provider and makes a selection. A SMART Integration may be used to launch an appropriate support app where the application used at the point of service (POS) lacks the ability to directly access and browse directory services. A SMART app may use FHIR services presented by the POS to gather information (e.g. patient address) to support the search
(FUTURE) Direct Messaging may be used to syncronize health service directories between systems
(FUTURE) RESTful FHIR endpoints may be available to provide a POS with access to shared directory services.
2. Provide supporting information After selecting a service, the requester completes the service request by completing any required forms and/or attaching supporting documentation required by the selected service / provider. A SMART Integration may be used to launch an appropriate support app where the POS lacks necessary forms and functionality to complete the referral request. A SMART app may use FHIR services presented by the POS to collect supporting information including discreet data to populate forms or attachments.
3. Submit request After completing the request, the requester submits the request to the selected service / provider (receiver). Direct Messaging may be used to transmit the service request and supporting information to a receiver who uses a different software application to support their work.
4. Manage and process the request After a request has been submitted, the receiver is responsible for progressing the workflow of the referral which will pass through different states as the receiver reviews and accepts the request and creates, assigns and completes tasks corresponding to the requested services. As states are updated in the receiver system, updates are sent to the requester. Direct Messaging shall be used to transmit information back to requesters when service requests are received using Direct Messaging.
5. Create an appointment The receiver may create an appointment to meet with the patient to perform the requested service. Direct Messaging may be used to transmit appointment information back to a requester's software application when service requests are exchanged using Direct Messaging.
6. Communicate about the request When a requester or receiver has questions, additional information or results related to a request the information may be sent electronically to the other party. Direct Messaging may be used to exchange communications between the requester and receiver.
7. Revoke a referral A requester may revoke a referral at the request of the patient or due to other reasons (i.e. due to human error in the selecting the appropriate Patient file). Direct Messaging shall be used to transmit a request to revoke when a service requests was presented using Direct Messaging.