Update and manage referrals and bookings as a referrer

This page describes the functionality available via our FHIR API for referrer organisations to update an appointment booking or referral.

This use case guide covers:

1. Retrieve referral information.
2. Retrieve healthcare service information.
3. Update appointment.
4. Update referral.

The process diagram shows how the various endpoints can be used to create an integrated solution. Endpoints in red denote those which can be accessed via the application-restricted, unattended access route.

This use case covers the functionality to retrieve details of referrals, as a referrer organisation. This includes specific information such as referral state and healthcare service information.

Up-to-date referral information should be retrieved in cases where the referral requires an action, or are in-flight referrals which need to be managed by a referrer.

1.1 Identify referrals

Endpoint: Retrieve referral worklist (A008)

The referral process starts by identifying in-flight referrals from a referrers worklist.

Worklists provide lists of referrals that meet certain criteria, typically where a user needs to be aware of something important, or to undertake an action, in order to avoid delays to patient care.

The referrer worklists currently supported include:

Letters outstanding

This worklist contains referrals which been initiated but require a referral letter to be added.

Rejected / triage response

This worklist contains referrals which have had an appointment rejected or have been returned to the referrer with a response as part of a triage outcome.

Assessment returned / cancelled / DNA

This worklist contains referrals which:

• have a clinical assessment outcome of 'advise referrer' recorded
• have been cancelled by someone other than the initial referring organisation
• have been marked as 'did not attend' (DNA) and the provider has returned the referral back to the referrer for action

Awaiting booking

This worklist contains referrals which do not currently have an appointment booking. This includes referrals which are:

• awaiting triage
• deferred to provider, or 
• have had their appointment booking cancelled

1.2 Retrieve referral information

Endpoint: Retrieve referral request (A005)

Once a referral has been identified, or is already known from a previous encounter, then the details of a referral can be retrieved, including:

Referral state 

During the lifecycle of a referral, the state may change multiple times. The referral state provides an 'at a glance' summary of the referral. 

Related reasons or comments 

Some referral states may also have a reason and some reasons may also have a comment. For example, a referral in a REJECTED state will have a rejection reason with comments explaining why it was rejected and actions to resolve them.

1.3 Check you can perform an update action

Endpoint: Available actions for user list (A029)

At this stage, it is advisable to check if the update action is permitted. This endpoint performs a search for all currently supported actions.

Referrals must be in a correct state for an update action, like an appointment cancellation, to occur.

Referral information can be further enhanced through this use case to elaborate details of a healthcare service.

A healthcare service is a place where a referrer can send a patient for triage, treatment or obtain clinical advice. A service is usually provided by an organisation at a specific location. Some services could be virtual, as with telemedicine services.

2.1 Retrieve healthcare service information

Endpoints: Retrieve healthcare service (A033), Search for healthcare services (A035), Retrieve healthcare service version (A037)

Attributes about associated healthcare services can be retrieved via the healthcare service endpoints. The information can be used to understand a services functionality, terms of use, and contact information. A patient may have up to twenty services associated with a single referral.

This use case covers the functionality to retrieve appointment details of existing referrals, and update the appointment booking.

3.1 Retrieve appointment

Endpoint: Retrieve appointment (A038)

This endpoint can be used to retrieve the current version of an appointment.

An appointment is made to a service so a patient can be seen.

A referral may, or may not, have an appointment and an appointment will always relate to a specific referral. It is possible to have more than one appointment during the life of the referral, but never concurrent appointments.

3.2 Update appointment

Endpoints: Retrieve referral request (A005), Retrieve appointment (A038), Retrieve reference data (A004), Update appointment (A034)

Currently, the only update appointment action available via the API allows the cancellation of an appointment booked to a directly bookable service.

You will need appropriate appointment cancellation reasons for this step.

This use case covers the functionality to update a referral:

• changing a shortlist
• cancelling a referral

4.1 Change shortlist

Endpoint: Change shortlist (A031)

This endpoint can be used to amend the shortlist of a referral.

A referral may have up to twenty services shortlisted. A shortlist can include one or more:

• directly bookable service (DBS)
• indirectly bookable service (IBS)
• referral assessment service (RAS)

It may be appropriate to generate a patient letter, after changing services on a shortlist. In which case, the Generate patient letter (A019) endpoint can be used.

4.2 Cancel referral

Endpoints: Cancel referral (A036), Retrieve reference data (A004)

This endpoint can be used to cancel a referral.

Cancelling a referral is a one-way process and results in an end-state. No further progression of care can occur once this action has been performed.

e-RS does not allow a referral to be cancelled, without also cancelling the current appointment. Therefore, if there is a current appointment associated with the referral, that will also be cancelled.

Retrieve reference data (A004) must be used to retrieve a list of reference data, which detail the reason the cancellation is being performed. The correct dataset must be used depending on the cancellation scenario, as detailed in the technical specification.