Business Context > Business Model

Context

Healthcare providers need to be able to access specialist advice and 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.

This Implementation Guide discusses how to implement two related types of service requests:

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

  • Electronic Consult (eConsult) enables primary care providers to request and receive advice from a specialist oftentimes eliminating the need for a patient referral.

This Ontario eReferral - eConsult 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 open 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 Information Architecture

A key goal of the CIA is to establish distributed/de-centralized referral networks that enable healthcare practitioners 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 are 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 and/or its delegate) 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 (and/or its deegate) 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.

Note: An EMR or HIS that provides all the required/preferred capabilities to support the referral workflow should be considered both a POS and RMS.

Both the sending and receiving HICs shall retain all communications and documentation within the eConsult/eReferral submission for a time period established by their policies and regulatory college(s) in order to comply with applicable laws. ​

Each HIC is expected to comply with their privacy requirements including Part V of PHIPA. ​

Please refer to the ‘Logging’ section on Consumer Responsibility section of the Implementation Guide.​

​Should a request to access that patient information be received while the information still resides in the referral system it can be provided to the requester. If the information is not available in the referral system because of its temporary nature, the associated information can be extracted from both the sender and receiver's systems.​

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

Provincial Digital Health Assets are systems hosted by the province of Ontario and use this implementation guide as a means to exchange information with RMS systems. Referral management, point of service, and health service directory systems may choose to integrate with Provincial Digital Health Assets but are not required to do so. The assets listed in the diagram are as follows:

  • ONE ID – Ontario’s digital identity and authentication system which allows healthcare professionals to securely access digital electronic healthcare services with a single username and password
  • Provincial HSD – provincial health services directory (future release)
  • CHRIS (RMS Target)1 – Client Health and Related Information System
  • OTNhub eConsult (RMS Source/Target)1 – enables primary care providers to consult with specialists across the province to get access to advice for patient care
  • Central Waitlist Management (Analytics)

1Note - CHRIS and OTNhub eConsult are Provincial Digital Health Assets and RMS systems

Referral & Consult 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 & eConsult Processes

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

  • a SMART 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.
  • a RESTful FHIR API that may be implemented to enable healthcare practitioners or service providers to search, view, and select recipeients of a referral request, and also search for existing referrals.

The creation of a patient context is out of the scope of this IG. Patient context is not created as a part of eReferral and eConsult workflow but is a transitory record. The Referral information is retained and is considered a transitory record as this information also resides within the sending and/or receiving systems.​

POS should request to access that patient information be received and while the information still resides in the referral system it can be provided to the requester. If the information is not available in the transitory system because of its temporary nature, the associated information can be extracted from PoC system.​

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 Specification: 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
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 Specification: 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). When not submitting a service request with a SMART on FHIR integration,Direct Messaging integration 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 Manage new and updated service requests The requester may create a new service requestand/or update an existing service request by updating the request. Requester sends an update to the ServiceRequest or the ServiceRequest's Status if information is changed or added When not submitting a service request with a SMART on FHIR integration, Direct Messaging integration maybe used to transmit the upates to the service request and supporting information to a receiver.
6. 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.
7. 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.
8. 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.