Referral Assessment Services - interpreting data in the NHS e-Referral Service

Although Referral Assessment Service (RAS) functionality has been available in e-RS for several years, the Covid19 pandemic saw a dramatic increase in their use – there are now almost twice as many in use as there were in February 2020.

This guidance outlines how commissioning organisations can identify the number of RAS requests raised and the outcome of each request from the e-RS data extracts. Information on differences for provider organisations are at the end of this article.

Data extracts are made available within e-RS on a monthly or daily basis. The key extracts are:

EBSX02 - Monthly UBRN Action

A record of every recorded action taken for all UBRNs with which the organisation had a legitimate relationship in the given month.

EBSX02D - Daily UBRN action extract

A daily version of the above extract.

EBSX03 – Codified Fields

The main table used to decode the information contained within EBSX02 and EBSX05 (field names ending _CD).

EBSX04 – Organisation

An Organisation Data Service (ODS) code lookup table.

EBSX05 – Service

Information about all the services on all live e-RS (whether published or unpublished) at the end of each month, plus any removed services that had e-RS activity against them in that month.

The EBSX02 data extracts can be accessed by users with the e-RS information analyst role on their smartcard (B1130) and downloaded as zipped .csv files. The EBSX03, 04 and 05 extracts are also available from the e-RS website.

Actions relating to a RAS request can span several months. For the sake of simplicity, this guide assumes that organisations want to look at information relating to the last two months; to report over longer periods the number of EBSX02 and EBSX05 files incorporated needs to increase accordingly.

To report on the latest two months information, analysts will need to download the:

1. EBSX02 extracts for the current and previous month, combined into a single table.
2. EBSX05 extracts for the current and previous month. These should be into one data table starting with the earliest EBSX05 and then only appending any new rows from the subsequent month’s data.
3. latest EBSX03 and EBSX04 to decode key fields.

It can be helpful to translate the information held within EBSX02 and EBSX05 into language that front end system users would understand. The key fields for this analysis, and how they link to other extracts to be made useful for non-analysts are:

EBSX02

E_REFERRAL_PATHWAY_START:

This field identifies the Referral to Treatment (RTT) pathway start date (for actions that have occurred in e-RS). For the purposes of the pathways covered by this analysis, it will be calculated once a triage request has been initiated and referral information has been attached. It should be noted that this field is a text field in the format YYYYMMDDHHMMSS and will need to be converted to a usable format to enable analysis.

REFERRING_ORG_ID:

This lists the ODS code of the referring practice. It can be decoded with the EBSX04 ORG_NAME field. The PARENT_ORG_ID can also be pulled from EBSX04 to identify the practice’s local commissioning organisation.

ACTION_ID:

A sequential reference for all actions recorded in e-RS. Used to establish the order in which actions occurred.

ACTION_DT_TM:

The date and time that the action occurred. It should be noted that this field is a text field in the format YYYYMMDDHHMMSS and will need to be converted to a usable format to enable analysis.

ACTION_CD:

Lists the actions recorded against each UBRN. Decoded using the EBSX03 DISPLAY field.

ORG_ID:

Identifies the organisation of the user carrying out the action. It can be decoded with the EBSX04 ORG_NAME field.

ACTION_REASON_CD:

Lists the drop-down reason selected in e-RS to give context to actions such as Referral Triage. Decoded using the EBSX03 DISPLAY field. Not every action will have an action reason.

SERVICE_ID:

Identifies the Service with which the referral was associated (if any) when the action was performed in e-RS. Links to the EBSX05 to bring in key information to support the analysis. Recommended fields to link from the EBSX05 are: PROVIDER_ORG_ID, LOCATION_ORG_ID and SPECIALTY_CD. Not every action will be associated with a Service ID.

UBRN:

The Unique Booking Reference Number for the referral/triage/advice request. This will enable the identification of unique referrals

TEST_PATIENT_IND:

Identifies test patients for exclusion from the dataset

EBSX05

PROVIDER_ORG_ID:

Lists the ODS code of the organisation providing the e-RS service. It can be decoded with the EBSX04 ORG_NAME field.

LOCATION_ORG_ID:

Lists the ODS code of the site from which the service is provided. It can be decoded with the EBSX04 ORG_NAME field.

SPECIALTY_CD:

Identifies the specialty of the e-RS service. Decoded using the EBSX03 DISPLAY field. The specialties used by e-RS are not the same as the national Treatment Function code list and a separate lookup table will be needed if reporting on a national treatment function basis is needed.

RAS referrals are identified in the EBSX02 by the ACTION_CD 1608 (Request Triage). 

Create a subset of the EBSX02 data, using the key fields listed in the 'Relationships between the extracts and key fields to support analysis' section, identifying the RAS referrals that were created within the month where the TEST_PATIENT_IND = 0.

Because referral pathways can see referrals move through several RASs it is important to identify the initial Request Triage action. This can be achieved in a couple of stages:

1. Remove all Request Triage actions where the E_REFERRAL_PATHWAY_START date is earlier than the date element of the ACTION_DT_TM. This leaves all Request Triage actions where the referral information was either added the same day or before the request was finalised (E_REFERRAL_PATHWAY_START is populated) or the referral information was added later (E_REFERRAL_PATHWAY_START is null).
2. There are some triage requests where the referring organisation changes the ‘referred to’ service before or on the day that the referral information is added. To de-duplicate reporting in these instances, it is necessary to further refine the dataset by only retaining the row of data for each UBRN with the lowest ACTION_ID value.

By linking the SERVICE_ID associated with the action to the EBSX05 it is possible to pull back the SPECIALTY_CD for the referred to service. Do not use the SPECIALTY_CD field present in the EBSX02 as this will be null if the referrer did not search by specialty (i.e. used a clinical term or named clinician search).

Receiving providers are only able carry out triage of RAS requests once referral information has been added to the request – this is identified using ACTION_CD 1440 (Add Referral Letter)

The date that the referral is available for triage is therefore:

• Where the E_REFERRAL_PATHWAY_START for ACTION_CD 1608 is not null: ACTION_DT_TM for the 1608 action
• Where the E_REFERRAL_PATHWAY_START for ACTION_CD 1608 is null: ACTION_DT_TM for the 1440 action with the lowest ACTION_ID associated with the same UBRN/UBRN_ID

This will leave a small number of requests where the E_REFERRAL_PATHWAY_START is null and there is no associated 1440 ACTION_CD. In these instances, the pathway start date should be taken as:

• The ACTION_DT_TM for the 1608 action

Providers will not be able to triage these referrals, and they will remain open unless cancelled or modified by the referring organisation.

Triage Outcomes are identified in the EBSX02 by the ACTION_CD 1770 (Record Triage Outcome) and there are three possible outcomes, viewable in the ACTION_REASON_CD field:

1. 10000021 (Refer/Book Now).
2. 10000022 (Return to Referrer with Advice).
3. 10000023 (Accept and Refer/Book Later).

It is necessary to create an additional subset of the EBSX02 data, using the key fields listed above, identifying the Triage Outcomes that were recorded within the month where the TEST_PATIENT_IND = 0

Again, because a referral can go through several RASs, it is necessary to de-duplicate the data to identify the final triage outcome. In this case that is achieved by only retaining the row of data for each UBRN with the highest ACTION_ID value.

By linking the SERVICE_ID associated with the action to the EBSX05 it is possible to pull back the SPECIALTY_CD for the referred to service. Do not use the SPECIALTY_CD field present in the EBSX02 as this will be null if the referrer did not search by specialty (i.e. used a clinical term or named clinician search).

Where there is no corresponding Triage Outcome for a request, it is possible that it has been amended before a provider was able to carry out triage

There are 2 relevant ACTION_CDs that apply in this scenario:

• 1421 (Cancel Request)
• 1423 (Modify Request)

Therefore, it is necessary to create a further subset of the EBSX02 data, using the key fields listed above, identifying all instances of these two ACTION_CDs where the TEST_PATIENT_IND = 0.

Because a request could be cancelled after being triaged, or modified but remain a Triage Request, it is important to only match this dataset to Triage Requests where no corresponding Triage Outcome has been identified.

The ACTION_ID of the ‘closing’ action must be greater than the ACTION_ID of the initial Triage Request to be relevant for this analysis. Where more than one 1423 Modify Request action exists use the lowest ACTION_ID that is greater than that of the initial Triage Request action.

By creating and comparing the three datasets defined above an organisation will be able to identify ll unique RAS requests. Of these:

• those RAS requests closed with a triage outcome
• those RAS requests closed or amended by the referrer
• by omission of one of the above, those RAS requests remaining open for provider action

This information should support both operational management and performance reporting of RAS requests.

RAS referrals can move through other services and providers, or be routed through Referral Management Centres, before reaching a particular provider and appearing in their dataset. In this case, RAS referrals can be identified by all Request Triage actions (ACTION_CD 1608) within the EBSX02 where the associated SERVICE_ID is for a service run by that provider. There is no need to exclude on the basis of the E_REFERRAL_PATHWAY_START.

Because RAS referrals can pass through multiple services and organisations it is recommended that any aggregated reporting at commissioner or ICS level is carried out using the commissioner EBSX02 datasets and not aggregated from provider data - as this may inflate the number of RAS requests and outcomes.