Brief description
A patient calls the OOH GP complaining of pain and asking for painkillers.
The OOH GP wants to check:
- What medications the patient is already taking.
- What they were prescribed for.
- When they were last issued, and how many.
- What allergies the patient may have.
The GP has access to an electronic patient record (EPR). The flow of information is from the GP practice clinical system to the OOH EPR. Data needs to be supplied using SNOMED CT codes. This use case will take place every time an OOH GP appointment takes place. The expected volume of this happening is to be determined.
Use case justification
Without this information the OOH GP will have to make a judgement on whether it is safe to prescribe the medication the patient is asking for.
Primary actors
- OOH GP
- OOH EPR
Secondary actors
- Patient
Triggers
- Clinical consultation
Preconditions
- The patient is registered on the OOH EPR; NHS Number is available.
- The OOH EPR can access the GP information.
- The OOH GP has the relevant permissions to access the information.
- The patient has consented to share the information.
- The information is real-time.
Postconditions
- On success:
- The GP is able to prescribe the most appropriate medication.
- Guaranteed:
- The GP will make a clinical decision based on the information they have.
- 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 | OOH GP accesses patient information on their EPR. |
Step 2 | The EPR identifies the patient’s GP practice endpoint using PDS/SDS lookup. |
Step 3 | The EPR requests to see the patient’s medications and allergies from their registered GP practice. The requirement is for the full history of the patient’s medications. It will be the responsibility of the EPR to present them in a clear way to the OOH GP. |
Step 4 | Spine Secure Proxy (SSP) checks organisation to organisation sharing agreement exists between requesting organisation (OOH GP) and the patient’s registered GP practice, and that the interaction (e.g. Get Problem/Condition) is part of the sharing agreement. |
Step 5 | GP practice clinical system checks patient permissions and consent to share. |
Step 6 | The EPR receives the Do Not Resuscitate Problem/Condition. The following information is returned with the following information:
*Taken from 'Standards for structure and content of medications and medical device records: technical annex 2013' (pdf attached below). |
Step 7 | The EPR will record the information locally. |
Step 8 | The information will be presented to the OOH GP. Note: This use case deliberately uses the supplied data for presentation to the OOH GP only. Future use cases may look at using the data supplied for decision support. However, those will only be progressed once the system is bedded and has a proven record of retrieving the information without introducing errors. |
Step 9 | The information is recorded on the EPR for use in critical incident review/medico-legal investigation. |
Exceptions | |
Step 2a | GP practice is not found on Spine Directory Service (SDS). |
Step 2b | The EPR advises the OOH GP that it cannot access the patient's GP practice record as the GP practice cannot be found. |
Step 4a | SSP sharing agreement between ‘to’ organisation and ‘from’ organisation doesn’t exist. |
Step 4b | The EPR advises the OOH GP that it cannot access the patient’s GP practice record as it does not have permission to access the data. |
Step 5.1a | The patient is not found on the GP practice clinical system. |
Step 5.1b | The EPR advises the OOH GP that it cannot access the patient’s GP practice record as the patient is not registered at the GP practice. |
Step 5.2a | The patient has not consented to the sharing of medical data from the GP practice. |
Step 5.2b | The EPR advises the OOH GP that it cannot access the patient’s GP practice record as the patient has refused permission. |