Use case for events

Brief description

A professional user of the Local Care Record (‘Care professional’) needs to review a patient’s GP practice information relating to events:

• details of Encounters
• details of Referrals
• details of Admissions

A patient is admitted to hospital and the clinician responsible for the care of that patient in the hospital needs to review their care history, recorded encounters, referrals and admissions from the GP practice clinical system, to assist in determining the appropriate care provision and support. They have access to the Local Care Record (LCR), which shares clinical information relevant to the direct care of their patient from a variety of local hospital, community and GP organisations.

Use case justification

Currently, when a patient’s record is viewed in the LCR, their encounters, referrals and admissions from the GP practice clinical system are presented as a static HTML view from a third-party supplier, which is rigid and not in keeping with the needs of professionals, the design of the system’s UI, nor is it the preferred strategy for sharing of patient information within the LCR landscape. Electronically consuming the FHIR-compliant profiles for a patient’s encounters, referrals and admissions from their GP practice clinical system will allow the LCR to:

• share this data in a manner which is congruent and consistent with all other care partners
• present the data in a manner which is appropriate for the care setting
• share more relevant data, pertinent to the role of the professional involved and improve care delivery
• present the data in a uniform and streamlined interface
• provider a higher quality user experience
• provide a higher fidelity audit record

Primary actors

• care professionals
• clinicians
• LCR subsystem

Secondary actors

• patient

Triggers

• at the point of direct care, during a consultation or care delivery setting, the professional/clinician is discussing the medical history with their patient

Preconditions

• patient has been admitted onto the Hospital’s Patient Administration System (PAS) and has gone through identification including retrieving their NHS Number
• the clinician has been advised by the local hospital’s system that their patient has information available within the LCR
• the clinician is logged into, and has a valid session with, the LCR
• the clinician has relevant access and permission to view the patient’s details in the LCR
• the patient has been registered within the GP practice clinical system and has data available for sharing with other clinical systems. Note: if no such data is available, it will not be possible to initiate the basic flow.
• the GP practice clinical system exists within the Spine Security Proxy (SSP)

Postconditions

• On success:

  • the patient’s recorded encounters, referrals and admissions are taken from the GP practice clinical system and presented in the LCR

• Guaranteed:

  • access and data returned is recorded for auditing purposes

Basic flow with alternative and exception flows

Step	Description
Step 1	Clinician requests the 'Encounters, Referrals and Admissions' for the patient using the LCR interface.
Step 2	The LCR identifies the patient's GP practice endpoint using PDS/SDS lookup.
Step 3	The LCR requests the patient's 'Encounters Referrals and Admissions' from their registered GP practice.
Step 4	Spine Security Proxy (SSP) checks organisation to organisation sharing agreement exists between requesting organisation (LCR) and the patient's registered GP practice, and that the interaction (for example, Get Encounters Referrals and Admissions) is part of the sharing agreement.
Step 5	GP practice clinical system checks patient permissions and consent to share.
Step 6	The LCR receives the 'Encounters, Referrals and Admissions' via the GP Connect service and presents the results to the clinician within the LCR user interface (UI). The following information is returned and presented in the LCR UI, as a minimum, for all Encounters and Admissions: Brief Summary of the Encounter/Admission Status of the Encounter/Admission (for example, planned/in-progress/finished) Type of Encounter/Admission (for example, inpatient/outpatient/ambulatory) Urgency of the Encounter/Admission Related Referral information, if available Clinician(s) involved Start and end time Reason for the Encounter/Admission Related Diagnosis information, if available Any related hospital information, if available. The following information is returned and presented in the LCR UI, as a minimum, for all Referrals: Summary of the Referral Status of the Referral (for example, active/suspended/cancelled) Type of Referral Urgency of the Referral Originating Encounter/Admission (if available) Service requested Proposed date and time for service Requestor of the service The clinical speciality that the Referral is requested for Reason for Referral Additional supporting information Comments and notes relating to the Referral
Step 7	The clinician then reviews the information presented and determines the best course of action in response to the information. This may involve requesting additional data sets from GP Connect to supplement the data already presented within this list.
Exceptions
Step 4a	SSP sharing agreement between 'to' organisation and 'from' organisation doesn't exist.
Step 4b	Exception is reported in LCR user interface; user is directed to contact local service desk for resolution.
Step 5a	The patient has not consented to the sharing of medical data from the GP practice.
Step 5b	Exception is reported in the LCR user interface.
Step 6a	A logic or integration exception occurs in the retrieval of data.
Step 6b	Exception is reported in the LCR user interface and is logged within the LCR's exception tracing database; user is directed to contact local service desk for resolution.