Use case for view patient-centric summary in Leeds Care Record

Brief description

LCR intends to deliver an integrated patient summary, presented to every user, when they first log into a patient. In order to do this, they will require structured data from GP systems EMIS Web and SystmOne. (Hospital, community, mental health and social care data already comes in structured form.)

Scenarios:

  • District nurse checking a patient’s record before visiting the patient at their home so they have an up to date understanding of their medical status and treatments.
  • Mental health professional reviewing a patient’s holistic situation as part of initial assessment – understanding the various encounters the patient is receiving across all care settings.
  • Hospital pharmacist assessing medications and allergies across all care settings as part of meds reconciliation process.

Use case justification

Structured GP data is an essential element for Leeds Care Record.

This is due to extensive feedback we have received that frontline users find the current layout too complex to navigate and they require a snapshot view of the patient across all care settings. This patient summary could be re-used in other locations once delivered.

Primary actors

  • Any clinician/care giver who views the Leeds Summary Record and are not a hospital user (hospital users will receive their own patient summary with a hospital-focused scope). Approximately, 2,100 users currently fit this category.

Triggers

  • Non-hospital user accesses patient’s Leeds Care Record view of their patient to gain a snapshot of who is involved with the patient, what alerts, allergies, medications and so on are currently available.

Preconditions

  • Patient must be registered at a Leeds Care Record GP practice.
  • Patient must have a valid NHS Number.
  • Patient must have data-sharing preferences in their GP practice clinical system set to allow the sharing of data.

Postconditions

  • On success
    • Patient data will be retrieved from the patient’s GP practice clinical system and incorporated into the summary screen displayed to the user.
  • Guaranteed
    • Either the patient’s data or an error message explaining why there is no data passed will be available to display in the patient summary screen.

Potential error messages

  • No data available
  • Patient not found
  • Sharing agreement is not set up
  • Patient does not consent
  • Response payload is invoked
  • Unable to invoke endpoint
  • Unable to resolve NACS
  • Unknown error details
  • Timeout
  • Message processing error
  • Request channel timeout
  • Underlying connection was closed
  • No endpoint listening

Basic flow with alternative and exception flows

Step Description
Step 1 LCR user attempts to access patient LCR record on PPM+ (either using a browser or a link within their local clinical system).
Step 2 LCR system identifies the patient’s GP practice end point using PDS/SDS lookup.
Step 2a Patient is not found at a GP practice. Standard hospital view (PPM+) is presented to user – error message advising why no GP data available.
Step 3 Spine Secure Proxy (SSP) checks organisation to organisation sharing agreement exists between requesting organisation (doctors) and the patient’s registered GP practice, and that the interaction (e.g. Get Medications) is part of the sharing agreement.
Step 3a Patient is not registered at an LCR practice. Therefore, there is no data sharing agreement. Standard hospital view (PPM+) is presented to user – error message advising why no GP data available.
Step 4 GP practice clinical system checks patient permissions and consent to share.
Step 4a Patient has not consented to share. Standard hospital view (PPM+) is presented to user – error message advising why no GP data available.
Step 5

System makes a series of calls to GP Connect:

  • Medications – medications within their prescribed periods (i.e. active). For example, GP prescribes for 8 weeks on 1st February – this medication would show as active until 29th March, 8 weeks later.

    • Acute

    • Repeat

    • Hospital (prescribed by hospital, recorded on GPSS)

    • Who and when prescribed it

  • Allergies

    • Allergy and severity (if available)

    • Who and when identified it

  • Conditions/Problems (outside scope of current release)

    • Severity

    • Who and when identified it

  • Immunisation (outside scope of current release)

    • Which version

    • Who and when gave vaccination

    • Date

    • Vaccine Code

    • Performer

  • Vital Signs (outside scope of current release)

  • Observations (outside scope of current release)

  • Procedures (outside scope of current release)

  • Encounter (outside scope of current release)

For all data retrieved include date recorded.
Step 6 System makes a series of calls to other 4 systems to which the patient has an open referral with (hospital, community, social care, mental health) requesting the summary dataset from each.
Step 7 The results of the calls made to each system are integrated into a series of melded views, displayed to the user as illustrated below.
Step 7a Any errors returned from any/all of the calls in previous steps will be displayed as part of the summary.

Supporting information

Current Standard 5 - tab view: Data is segmented by organisation

Patient summary showing melded views incorporating data retrieved from GP Connect

Example of a dedicated care journey which crosses care boundaries (diabetes)