UKCore Hackathon Supporting Guide

This guidance is under active development by NHS England and content may be added or updated on a regular basis.

Workflow

Referral

Asking a provider to request a procedure or diagnostic or other service.

UK Core Profiles

Frameworks and Implementation Guides

Specifications


Referrals and Test Orders

In FHIR these are collectively known as ServiceRequest. It is the method where service is requested for a patient. This is typically between different health or social care sercices. When a ServiceRequest is performed this normally results in a Procedure or DiagnosticReport being returned to the requester. However it is common for a letter or document to be returned back. For example in NHS England systems, both electronic Referral Service (eRS) and Transfer Of Care (TOC) are often used together as one process:

  1. A referral is made together with supporting documentation and this is recorded on eRS
  2. eRS acts as a brokering service and helps get the referral actioned. The tasks are known as worklist items.
  3. An Outpatient or Discharge letter (TOC), is sent back to the requester.

This is different to HL7 v2 workflow where in pathology:

  1. The ServiceRequest or Test Order is sent using OML_O21 - Laboratory Order
  2. The DiagnosticReport is sent back using ORU_R01 - Unsolicited transmission of an observation message

The main difference betwween HL7 FHIR and v2 is:

  1. The request is ideally shared by the system creating the request and is not sent.
  2. The ask which is sent, is a fulfilment Task. This allows communication between the requester and the intended performer. This communication normally starts with a fulfilment Task being requested and the performer will respond with either a accepted response if they are going to perform the request or a rejected response with reasons why they are not performing the request.

In FHIR this is represented as:

Referral Resources

  1. The referral is represented as a ServiceRequest when shared from a EPR system.
  2. The Task resource is sent to the intended performer of the referral, this contains a link to the shared ServiceRequest. (This is quite different from the letter based approaches in previous standards.)
  3. The referral is actioned according to local procedures and when completed a Task indicating the referral is complete is sent back. Ideally the results of the referral would be shared as a DiagnosticReport but this may take other formats potentially PDF.

ServiceRequest is part of FHIR Workflow and is classed as a request resource. The returned response to the ServiceRequest is classed as an event resource.

Workflow Communication

The inclusion of the Task or communication process is optional and it's use is depends on the type of request. For example if the request is urgent, Task communication is not required. This leads us into workflow communication patterns.

Ad-Hoc and Emergency Care Patterns

The benefits and limitations of these patterns are described in Ad-Hoc Communication Patterns

These generally do not include the use of the Task resource and so are suitable for modernising existing referral systems. The main disadvantage of these patterns is the difficulty or added complications in arranging a request. This can make it difficult to support clinical process.

Current Solution FHIR Workflow Ad-Hoc Pattern
Emailing/Fax of Referral Letter The letter is shared via Document Sharing and the request metadata is sent as a FHIR ServiceRequest using Option B: Direct POST of request to fulfiller's system to the performer
HL7 v2 REF_I12 - Patient referral, OML_O21 - Laboratory Order or HL7 v3 Referral A like for like pattern is Option D: Messaging request from placer to filler & acknowledgment, in emergency settins where speed is essential this appropiate. In other settings this can be refactored into sharing the referral supporting information and then using Option B: Direct POST of request to fulfiller's system for sending the request

Example Implementations

Management Patterns

In the UK both the Welsh Clinical Communication Gateway (WCCG) and e-Referral Service - FHIR API (e-RS) allow management of referrals (like EPS) they follow Option H: POST of Task to a workflow broker. In both systems the ServiceRequest (or equivalent) is stored centrally and then referral is arranged via Task lists. The Task/Request completed is normally sent as a document via other systems.

All of these systems are referred to as workflow brokers.

It is not necessary to have a broker to implement management patterns, they all require the use of Task to facilitate clinical communication in arranging and performing the referrals. The use of these managment patterns is therefore highly recommended to match clinical and pathway requirements. This is also true a technical perspective, the use of the Ad-Hoc patterns can become very complicated to implement and will probably have scalability issues.

Payload/Interaction Considerations

A referral general consists of two parts:

  • ServiceRequest which consists of the type (e.g. laboratory, patient referral, etc), the specific service being requested (code), the patient who the service is for and the performer

  • supportingInfo documents and forms which support the referral. The will often include:

    • Referral letters
    • Assesment forms
    • Patient summaries

In FHIR Workflow and existing workflow brokers (e-RS and WCCG), these are treated seperatley. This allows the referral or request to be decoupled from the technical interactions and allows more natural clinical process (e.g. in E-RS, referral letters can be created before or after the referral is created. Additional documents can supplied if they are asked for during the workflow communication).

It is highly recommend support information is not coupled to the referral, except for emergency care.

Care and Activity Definitions

Example: Community Referrals

Referrals and Workflow (IoW) is an upcoming NWR.

This looks like a generic example of FHIR Workflow and would serve as an good introduction to the topic.


Example: NHS England Diabetes Prevention Programme

To illustrate this we will look how FHIR would be used in a NHS Diabetes Prevention Programme (NHS DPP)

This is a good end2end description of a clinical process which fits in with PRSB Diabetes. It is also known the requests for a technical solution did not find an answer and so resorted to email and pdf for both legs of the workflow.

This appears to have a criteria like Example: NHS England Digital weight management which is

Rough process

  1. Patient does diabetes risk assesment (include GP asking for form https://riskscore.diabetes.org.uk/start to be completed)
  2. Do a referral criteria check (FHIR ActivityDefinition)
  3. Create ServiceRequest
  4. Ask provider to fulfil (Task)
  5. Provider accepts
  6. Provider provides care
  7. Provider sends back a DiagnosticReport

Example: NHS England Digital weight management

NHS England Digital weight management this is describing a referral with a specific criteria and allows elaboration of ActivityDefinition. This is a pattern not seen with existing (digital) programmes and is more than likely present in actual workflows (probably in paper form). This may be a present in BARS https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir#api-Metadata-getMessageDefinition is suspiciously similar.

For example, weight management criteria states:

  • You must be 18 or over.
  • You must have a BMI greater than 30. The BMI threshold will be lowered to 27.5 for people from black, Asian, and ethnic minority backgrounds, as we know people from these ethnic backgrounds are at an increased risk of conditions such as Type 2 diabetes at a lower BMI.
  • You must have diabetes, high blood pressure, or both.
  • You must have a smartphone, tablet, or computer with internet access.

BARS has the following:

A receiver dictates what they need from a sender making a request and the MessageDefinition is the mechanism to support this.

Is a clear difference on target audience one is clinical and the other is technical (and unsure what clinical requirement this answers).


Example: At Home Patient Monitoring

Virtual Ward The NHS England is only considering the output from this workflow which is covered here https://github.com/nhsengland/virtual-wards-draft-standards


Example: DHCW Cross Border Referrals

Idea: Include DHCW England/Wales referrals to keep scope at UK level.

This will focus on WCCG and e-RS ideally being consistent with each other.


Example: Genomics

https://simplifier.net/guide/FHIR-Genomics-Implementation-Guide/Home?version=current should be linked from this.

The modelling and guide is mostly consistent with this technical framework. The workflow management pattern is Option D - Messaging request from placer to filler & acknowledgment but is done in a way which allows a move to other patterns.

back to top