Search loading...

API Hub

Explore and Make use of Nationally Defined Messaging APIs

 

111/999 call handler

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

Pre-conditions:

  • 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 patents 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

Post conditions:

  • 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:

{The basic flow is the best case scenario (meaning the happy path) of what should happen in the use case if all the conditions are met. Describe other allowed variations of the basic flow. Are the any alternate routes that can be taken? Describe Error Conditions or what happens when a failure occurs in the flow}

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 end point using PDS/SDS lookup
Step 4 The call handling system requests to see any End of Life Problem/Conditions record for the patients 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 Patients 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 Patients 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 DNR problem/condition recorded
Step 7b The call handling system follows the standard workflow.

Use Case Diagram:

{Insert a Use Case Diagram that indicates the use case and all direct relationships with other use cases and associations with actors.}


All content is available under the Open Government Licence v3.0, except where otherwise stated