Profiles & Operations > eReferral Workflow
INTRODUCTION
The purpose of this specification is to design an integration method between a Source Referral Management System (RMS Source) and a Target Referral Management System (RMS Target),that can serve the wide variety of referral workflows.
When comparing the referral workflow for sending to specialists vs. community based organizations vs. long term care vs. central intake etc..., many different business processes emerge. Some examples of differences include:
To facilitate different workflows, this specification includes the following related methods to submit an electronic referral.
For a summary of the key differences between these methods, refer to the Business Rules - Multiple Referral Submission Methods page. These eReferral submission methods are described in more detail throughout this page.
No matter the submission method, the workflow steps after the initial submission are the same.
REFERRAL WORKFLOW
The following table provides more description of these workflow steps.
| Workflow Step | Overview |
|---|---|
| 1. Select Target HealthcareService | (OUT OF SCOPE) The source system is responsible for selecting the referral destination. The selection process is usually driven by a directory or registry of services. The specification of a directory is out of the scope of this specification. The scope of this specification begins AFTER the referral destination has been selected. |
| 2. Submit Referral | Method 1: SMART on FHIR It is assumed that readers of this specification are familiar with the SMART on FHIR specification. This specification follows the ‘Clinician Access for EHR Launch’ model and the standalone model may be considered for future considerations. With SMART on FHIR, one potential challenge for implementers is that the RMS source system must have a SMART on FHIR enabled server, which may not be realistic in some cases, such as integrations to non-web applications or applications adapted on top of non-FHIR foundations (SharePoint, Microsoft Dynamics, Legacy Applications, etc.) RMS source system must expose a SMART on FHIR endpoint in order to receive and process SMART on FHIR requests. If the RMS source system were to consider other alternatives such as a ‘hosted’ SMART on FHIR server on its behalf , the integration between the RMS source system and the ‘hosted’ SMART on FHIR server must comply with applicable privacy, security and regulatory policies and rules to ensure the personal health information is securely protected. The user will submit the referral in eReferral app, according to the RMS Target's eReferral business logic. If the submission process in the app is abandoned or fails, the RMS Source will be notified. Method 2: Direct API Submission In the Direct API submission method, the RMS Source submits the referral payload directly to the RMS target via backend API mechanisms. The payload being sent matches that being sent in the SMART on FHIR method, except that it uses a different message event value. Unlike the SMART on FHIR submission methods, the RMS Target does not present any UI to the user. It is up to the RMS source to generate all of the UI components. |
| 3. Update Referral | Once submitted, the RMS Target is responsible for progressing the workflow of the referral, such as updating the referral status, modifying the referral and adding appointments. The RMS Target system sends notification messages back to the RMS Source (and any other interested systems) as the referral changes. Once submitted, RMS Source may not make further direct changes to the referral via the API (with the exception of revoking the referral), only the RMS target may make changes. The RMS source can communicate any desired changes via the Communication about Referral workflow. |
| 4. Communicate About Referral | (FUTURE PHASE) Both the RMS Source and RMS Target can send communication messages about the referral back and forth to each other. These can be a variety of communication types such as simple information messages, notifications, or requests for more information. Attachments can also be included in these communications. Any changes that the RMS Source wants to make to the referral after submission via the API must be made by submitting a Communication about Referral, not by modifying the referral resources directly. This ensures that the provider at the RMS Target maintains responsibility for progressing the referral through the workflow. |
| 5. Revoke Referral | If the patient requests at the RMS Source to revoke consent to the referral, the RMS Source may ask the RMS Target to revoke the referral via the API. The RMS Target must comply with this request. |
The following actors participate in the data flows related to this specification:
The resource cannot be rendered.
Actor: Referral Management System Source (i.e., RMS Source, Requester System)
Role: Responsible for initiating the service request to be processed by the RMS Target.
Actor: Referral Management System Target (i.e., RMS Target, Recipient System)
Role: Responsible for the reception, business process handling, and status of the submitted eReferral.
Actor: 3rd Party FHIR System (Optional)
Role: A system other than the RMS source that can interact with the Provider eReferral System. (e.g., EMR, data repository, patient portal, case management system, etc...)
Actor: Other System
Role: Any other system may interact with the RMS ecosystem.
Powered by SIMPLIFIER.NET