eReferral Implementation Guide - Local Development build (v0.1.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Overview

The primary purpose of the LK eReferral (Electronic Referral) Implementation Guide is to specify the interfaces used to step through the eReferral workflows.

Referral Actors

There are three actors: Requester, Performer and Intermediary.

The Requester initiates the referral request, may book an appointment, is notified of changes and receives notification when the referral activities are completed.

The Performer reviews the request and accepts (or rejects), may book an appointment, fulfills the request and triggers the completed event marking the end of the workflow.

The Intermediary orchestrates the workflows and also interacts with the FHIR repository.

These actors work together to step through referral workflows. The FHIR repository is the central data store that keeps all versions of the Resource instances as they change through the workflow.

Consideration 🔎 The Intermediary functions may be allocated to the Requester and Performer. For example the Requester may create a referral and submit to the FHIR repository, and then send a notification message directly to the Performer. This architecture requires each Requester system be capable of sending messages to every Performer system. This is not desirable as it will be time consuming and troublesome to maintain. Using an Intermediary requires only that the Intermediary system be able to connect and send messages to other Requester or Performer systems.

FHIR Resource Model

FHIR Events and Messages

The referral process can be considered a series of Events which trigger complementary FHIR Messages. Events to submit a referral, events to accept a referral and so on, complete, cancel, etc.

• The ServiceRequest Resource is considered the referral.
• The Task resource Resource records the status of the referral i.e. accepted, rejected, completed.
• The Appointment Resource represents appointments.
• The Communication Resource is central to the Requester or Performer seeking or adding additional information.
• The DocumentReference Resource represents documents that are attached to the referral, populated by the Requester or the Performer.
• The EndPoint Resource specifies the message URL used for connections.

For the Sri Lanka eReferral system Communication (and CommunicationRequest) and EndPoints are out of scope at this time.

FHIR Resource Structure

The referral process data model will be represented by FHIR Resources as follows and shown in the diagram below.

• When a referral is created it will reference the Performer, which may be an Organization, HealthcareService or PractitionerRole. This is represented in the diagram below as associations between ServiceRequest (the referral) and Organization, HealthcareService or PractitionerRole. One may request a referral to
  1. a Doctor (PractitionerRole that works at a Facility; Facility being combination of Organization, HealthcareService and Location),
  2. an Organization,
  3. or a Service.
• The status of the referral (the ServiceRequest) is managed by the ServiceRequest and Task Resources. A Task instance SHALL be created by the Orchestration component if not included in the initial request.
• The Appointment for the referral may be linked to the ServiceRequest.
• A Communication Resource may be added that provides information after the ServiceRequest has been accepted. This is out of scope.
• A DocumentReference may be included such that additional information can be included in the referral request.

This diagram also matches the Facility FHIR Resource structure — the relationships between HealthcareService, Organization and Location remain the same.

Message Bundle and Profiles

FHIR Messages are composed of a Bundle of type message with the first entry being a MessageHeader. All the standard rules for [FHIR Messages}(https://hl7.org/fhir/R4/messaging.html) apply.

Three Bundle profiles are used: one to create or update the referral request LKReferralCreateOrUpdate, another to send notifications LKReferralNotify and lastly one for simple acknowlegment of messages recieved LKReferralAck echoing back resources as they are stored.

The LKReferralAck profile is not constrained beyon a header and OperationOutcome. Actor systems SHOULD populate the acknowledgment Bundle if any referral Resources have changed, this includes changes such as assigning an id to a newly created Resource.

Notifications (LKReferralNotify) SHALL always contain the most recent versions of the referral Resources.

Event	Impact	Bundle Profile (Message Definition)	Response Event	Response Bundle Profile	Comments	Message Header Focus
create-referral	consequence	LKReferralCreateOrUpdate (CreateReferralDefinition)	acknowledge	LKReferralAck	This message requests the Performer to accept the referral and begin processes to complete. This may include an Appointment. The Task can be submitted by the Requester or created by the Intermediary.	ServiceRequest
accept-referral	notification	LKReferralNotify (AcceptReferralDefinition)	acknowledge	LKReferralAck	This message informs the Requester that the request has been accepted by the Performer.	Task and may be Appointment
update-referral	consequence	LKReferralCreateOrUpdate (UpdateReferralDefinition)	acknowledge	LKReferralAck	This message informs the Performer or Requester that updates have been made to the request.	ServiceRequest or Appointment or Task
reject-referral	notification	LKReferralNotify (RejectReferralDefinition)	acknowledge	LKReferralAck	This message is sent back to the Requester if the Performer refuses the initial referral request.	Task
complete-referral	notification	LKReferralNotify (CompleteReferralDefinition)	acknowledge	LKReferralAck	This message is sent when the Performer has completed and should contain information (i.e. FHIR Resources) regarding the outcomes of the appointment.	Task and ServiceRequest
cancel-referral	consequence	LKReferralNotify (CancelReferralDefinition)	acknowledge	LKReferralAck	This message is sent when the Requester or Performer is canceling the request.	Task and ServiceRequest

Future Functionality and Improvements

This section discusses some future enhancements to Electronic Referrals that have not be specified, but should be considered.

Requester Registration and EndPoints

The Requester may be represented by a PractitionerRole or an Organziation. The referral workflows described in this guide require that the Requester be able to recieve FHIR Messages. A ServiceRequest will identify the requester as a Reference to a PractitionerRole or Organization. To automate end point discovery the PractitionerRole and Organization should have the endpoint element populated as part of the Requester registration process.

Performer Registration and EndPoints

Each Performer must have an end point that receives FHIR Messages and acts to respond in some manner, depending on the state of the referral.

A self-service Performer Registration process is ideal and is closely related to the Facility Registry interaction to create a Facility. This process does not have to be self service, an initial implementation may only include registration via other means where the Intermediary administrators configure the eReferral Resources.

An example workflow follows:

//Step 1// A Performer submits information regarding the types of Services it offers, where they are offered and who fulfills the Services. This step closely matches the step to create a Facility and Providers in their respective Registries. E.g. The HealthcareService, the Location, the Organization and PractitionerRoles are created (or existing Resources found) and associations made. These FHIR Resources should be created or updated in the Facility or Provider Registry. Security, governance and roles are not discussed here, but should follow workflows to create Providers and Facilities.

//Step 2// Create EndPoint FHIR Resource that contains information regarding where and how to send all referral Messages. Then reference the EndPoint from at least one of HealthcareService, PractitionerRole or Location.

Now the Facility and Provider Registries have Services, Locations and PractitionerRoles that define where to send referral requests. The Intermediary only has to query the Registries for the Resource and retrieve the EndPoint.

FHIR Subscriptions

FHIR defines a Subscription framework that is able to notify an actor when events occur. This is ideally a self registration as the actor subscribes to a topic and receives notifications that the event has occurred. The notifications may contain all the Resources associated with the referral (pushed to the actor) or just FHIR References (the actor must pull the Resource instance from the Repository). As the FHIR Message model described in this guide offers equivalent functionality to notify and deliver FHIR Resources, the Subscription option has not be pursued. The Subscription framework is ideal for self registration and management of notifications which alleviates some administrative burden on the Intermediary, which is a distinct advantage over FHIR Messages.

Referral Performer Directory

A Electronic Referral System would benefit from a directory of referral Services, that is, the ability to search for referral Performers by Service. This is equivalent to searching the Facility Registry for Facilities that offer a particular Service and is currently accepting referrals.