Use case for Clinical Triage Platform consumes GP-held patient data

Brief description

The CTP programme seeks to improve the triaging capability in urgent and emergency care settings by providing tools and services to support next-generation triaging capability better suited to addressing individual patient needs. Patients are currently triaged without a view of their medical history, leading to triage that is said to be too generic. To triage patients effectively and efficiently, the triage platform requires a Clinical Decision Support System (CDSS) that can support personalisation of the triage process by consuming and considering patient data from various sources.

The most viable source of patient data is the GP-held detailed patient record, which holds the most comprehensive collection of a patient’s medical history, current medications and at times may include a care plan for specific patient needs such as diagnosed chronic conditions.

In this use case we propose that the CTP CDSS will consume available patient information from the detailed patient record held in the patient’s GP system.

The data that the CTP CDSS access will be transient, as patient conditions change from day to day. Therefore, there would be no benefit in holding patient data on CTP as the patient’s condition can change quickly and the data will become out of date. This means that this use case is only concerned with real-time access of the patient record, at the point of triage by a clinician.

Use case justification

Current 111 service providers have raised the requirement to access patient data during triage. They have stated that clinicians and patients would benefit greatly from the former having access to the patient’s history to help them understand the needs of the individual within the collective patient population.

The Five Year Forward View states that the patient population in England is too diverse for a ‘one size fits all’ care model to apply everywhere, and that the NHS has to keep up with changes in patient healthcare needs and preferences. This can be achieved by personalising triage by using available information about the patient.

There are many aspects to patient care and, accordingly, there may be patients with many different types of records about their care. These would include hospital discharge records, pathology test results, and information regarding diagnosed chronic conditions and the related management or treatment plans. Due to the nature of urgent care especially in the 111 and Integrated Urgent Care Clinical Assessment Service (IUC CAS) space, clinicians fielding calls from an ever-changing base of patients will not be able to learn each patient’s full medical history within the brief time allotted to triage. It has been suggested that an intelligent, responsive triage system that can consume the patient data could address this shortcoming and improve the ability to provide personalisation of triage for each patient interaction.

By allowing the system to consume patient data in a meaningful way, the burden for clinicians to wade thought lengthy patient records could be alleviated. A system that can accept patient records as input, apply some logic to it and subsequently modify the clinical assessment of the patient is anticipated to have the following benefits:

  • A more appropriate disposition will be recommended.
  • Reduction in risk of under-triage and over-triage.
  • Optimise the sign-posting of patients to the most appropriate endpoint taking into consideration patient-specific healthcare history and current concerns.
  • Clinicians will potentially spend less time on triage, by utilising available system intelligence to better inform their triage decisions.

For this use case emphasis is on accessing the GP held patient data, although similar principles and considerations would apply to patient data sourced from any other systems.

Primary actors

  • Clinician

Secondary actors

  • Patient
  • GP system

Triggers

  • Clinician requests patient consent to access the GP-held detailed patient record.

Preconditions

  • Patient has gone through identification verification including retrieving their NHS Number.
  • A clinician is engaged in patient triage at that point in time, talking to a patient or their representative.
  • The healthcare professional has relevant access and permission to access the patient’s record.

Postconditions

  • On success:
    • Patient data is retrieved and consumed by the CDSS.
    • Access and use of the data is recorded for auditing purposes.
  • On failure:
    • Triage continues without consideration of the GP held patient data.
    • Declined or failed request for access to the patient data is recorded for auditing purposes.
  • Guaranteed
    • The patient is triaged through the use of the CTP CDSS tool.

Basic flow with alternative and exception flows

Basic Flow
Flow Identifier: Consent Given
Step User Action System Response (optional)
Trigger Clinician selects system option indicating that he/she wants to access GP held patient data.

  • Prompt clinician to record patient consent and reason for accessing data.
1 Clinician requests permission to access GP-held patient data from patient.
2 Patient gives consent
3 Clinician records consent in system.

  • Record that consent was obtained and the reason for accessing data.

  • Calls the integration API to

    • Retrieve and displays the GP held patient record.

    • Retrieve and apply structured data items to personalize the triage.

  • Updates triage based on patient data.

  • Generates applicable patient risk flags and alerts.
4 Perform Personalised Triage

  • Dynamically consume patient data in triage logic, in relation to responses provided by the patient during triage.

  • Raise flags and alerts as and when required.
5 Clinician completes triage.

  • Integration link is disconnected
End Use Case Ends
Alternative Flows
Flow Identifier: 2a Patient is unable or unwilling to consent but there is urgent justification for accessing the patient record.
Step User Action System Response
2a: Patient is unable to consent (e.g. Patient is cared for or has impaired speech, patient is delirious at that time).
2a1 Clinician determines that the patient is unable to consent, and opts to proceed without patient consent.

  • Prompt clinician for reason for proceeding without consent.
2a2 Clinician records a consent override in the system.

  • Record that consent was overridden.

  • System calls for patient data and displays the GP held patient record.
2a3 Perform personalised triage

  • Dynamically consume patient data in triage logic, in relation to responses provided by the patient during triage.

  • Raise flags and alerts as and when required.
2a4 Clinician completes personalised triage.

  • Integration link is disconnected
On Exit Use Case Ends
Alternative flows
Flow Identifier: 2b Patient is not willing to consent/refuses to give consent and there is not urgent justification for accessing the patient record.
Step User Action System Response
2b: Patient is not willing to consent/refuses to give consent.
2b1 Clinician records in the system that consent was declined.

  • Record that consent was declined.

  • Close the integration session.
2b2 Perform non-personalised triage.
2b3 Clinician completes non-personalised triage.
On Exit Use Case Ends
Exception Flows
Flow Identifier: Patient Record Not Accessible
Step User Action System Response
4a Patient record not found (new patients, incorrect patient registration, invalid NHS Number)

  • Records that record could not be found.

  • Alert clinician that the record is not found. Then close integration session.
5a Integration link is disrupted.

  • Integration link is disconnected.
On Exit Use Case Ends

Data items

Of the many data items that could be pulled from the GP records, the following have been identified as useful and relevant to triaging a patient in an urgent and emergency care (UEC) setting starting with the top 6 rated as the most important:

  • Top six:

    • Allergies/Adverse Reactions

    • Care Plans

    • Child Protection/Adult Safeguarding information

    • Conditions/Problems

    • DNACPR decisions/End of life Care Plan

    • Medications/Prescriptions

  • Other relevant patient information:

    • Admission Avoidance Notes

    • Appointments

    • Communication preferences

    • Reasonable Adjustments for Disability Needs

    • Electronic Frailty Index (eFI)

    • Encounters

    • Family history

    • Immunisations

    • Investigations, Diagnostics and Procedures

    • Referrals

    • Vital Signs

    • Point of Care Testing

    • Elected pharmacy

Original use case

This use case is a reformatted version of the Consume GP Held Patient Record use case developed by the NHS Digital CTP team.