Use case for 111/999 call handler

Brief description

A patient calls 111/999 and the call handling system is able to interrogate the GP system to search for information that the patient is end of life.

The flow of information will be from the GP system to the call handling system.

Data needs to be supplied using SNOMED CT codes.

This use case will take place every time a call takes place. The expected volume of this happening is to be determined.

Similar use cases could be developed to flag other key conditions that would impact how a call is handled such as the patient being diagnosed with Learning Difficulties, Diabetic, etc.

Use case justification

If a call handler is aware that the caller is an end of life patient they will amend their response to the call ensuring that the patient gets the most appropriate outcome.

Currently, without this information, they have to go through the pathways modules and follow the dispositions which are produced.

Primary actors

• 111/999 call handler
• call handling system

Secondary actors

• patient

Triggers

• the information is searched for automatically once the patient’s ID has been established

Preconditions

• the patient’s NHS Number is available to the call handling system
• the call handler has the relevant permissions to access the information
• the call handling system is able to interact automatically with the GP system (or proxy)
• the information is presented to the call handler early in the call
• the patient has consented to share their data
• end of life is recorded as one of a set of possible clinical codes in the patient’s medical record on the GP system
• there is an agreed workflow for patients with an end of life status which the call handler is able to follow

Postconditions

• On success:

  • the patient receives advice/treatment which is timely and the most appropriate for their needs

• Guaranteed:

  • the patient receives advice/treatment which is safe
  • access is recorded for auditing purposes
  • information on which decisions are made is available for critical incident review/medico-legal investigation

Basic flow with alternative and exception flows

Step	Description
Step 1	Call handler searches for and finds the patient on their call handling system.
Step 2	Once the patient is identified the call handling system automatically starts the process to check for an end of life condition.
Step 3	The call handling system identifies the patient's GP practice endpoint using PDS/SDS lookup.
Step 4	The call handling system requests to see any End of Life Problem/Conditions record for the patient from their registered GP practice. The API call includes a list of SNOMED CT codes to be looked for.
Step 5	Spine Security Proxy (SSP) checks organisation to organisation sharing agreement exists between requesting organisation (call centre) and the patient's register GP practice, and that the interaction (for example, Get Problem/Condition) is part of the sharing agreement.
Step 6	GP practice clinical system checks patient permissions and consent to share.
Step 7	The call handling system receives the End of Life clinical codes that are found. The following information is returned with the following information: That there is an EOL clinical code that is active on this date.
Step 8	The call handling system will present the EOL information to the call hander and moves to the EOL workflow.
Step 9	The EOL information and the switch to the EOL workflow is recorded on the call handling system for use in critical incident review/medico-legal investigation.
Step 3a	GP practice is not found on SDS.
Step 3b	The call handling system follows the standard workflow. Note - the call handler is not presented with any error message as this would distract them from the task in hand.
Step 5a	SSP sharing agreement between 'to' organisation and 'from' organisation doesn't exist.
Step 5b	The call handling system follows the standard workflow.
Step 6.1a	The patient is not found on the GP practice clinical system.
Step 6.1b	The call handling system follows the standard workflow.
Step 6.2a	The patient has not consented to the sharing of medical data from the GP practice.
Step 6.2b	The call handling system follows the standard workflow.
Step 7a	There is no Do Not Resuscitate (DNR) problem/condition recorded.
Step 7b	The call handling system follows the standard workflow.