Design principles
Clinical Safety Principles
Clinical safety is about promoting, and helping embed, clinically safer working practice methods and proactive risk management for patient safety enabled by IT, with consistent application across the NHS.
GP Connect FoT Clinical Safety Principles
The following principles and underlying detailed requirements are currently undergoing review by the NHS Digital Clinical Safety team, so may be subject to change.
Information Standards for Clinical Risk Management
The GP Connect API is underpinned by the information standards for clinical risk management, which describes a framework for national healthcare initiatives that has been created by the Department of Health, NHS England, the Care Quality Commission and other national health organisations. The information standards for clinical risk management also describe a mechanism for introducing requirements to which the NHS, those with whom it commissions services, and its IT system suppliers, must conform.
Commissioning Organisation
Commissioning organisations for GP Connect: must have a clinical safety framework compliant with Information Standard: (SCCI0160: Clinical Risk Management: its Application in the Deployment and Use of Health IT Systems). are responsible for assuring that deployment and implementation of consumer applications using the GP Connect APIs comply with this framework.
Consumer & Provider Systems
Consumer and provider systems using the GP Connect API must comply with the requirements of the SCCI0129 standard, promoting and ensuring the effective application of clinical risk management by suppliers developing and maintaining health IT systems: (SCCI0129: Clinical Risk Management: its Application in the Manufacture of Health IT Systems) Additionally, the GP Foundation System providers must also carry through the clinical safety requirements of the GPSoC framework into any GP Connect functionality.
Assurance & Deployment
Confirmation of compliance with the clinical safety standards as above will be specified as part of the GP Connect (SCAL) against which the consumer supplier will need to assure. The SCAL is managed and administered by the NHS Live Services Team.
Commissioning clinical safety approval of the consumer system forms part of the NHS Digital requirements for deployment into live operation.
Provider systems must also demonstrate standards compliance as part of the NHS Digital assurance processes.
Assurance Principles
- Assurance will use a risk-based approach
- Testing should be automated where possible to establish technical conformance
- All artefacts related to assurance and testing should be made available as part of the ecosystem (public domain) prior to engaging in a formal NHS Digital assurance process
Information Governance Principles
Your organisation must complete the Data Security and Protection Toolkit (DSPT) for each NHS England Service being integrated and obtain at least a 'Minimum Standards Met' rating.
Each time a new NHS England Service is integrated, a check is made that the connecting organisation is registered and active with DSPT.
All organisations that have access to NHS patient data and systems must use this Toolkit to provide assurance that they are practising good data security and that personal information is handled correctly.
API scope
The scope of the API is to enable the ability for patients using patient facing applications (e.g the NHS App) to:
order a repeat prescription
view all medication including acute and repeat medcations, both current and historic
cancel an unactioned order for a repeat prescription
check the status of a prescription order
view active prescription requests
order an electronic repeat prescription as a one off to a pharmacy other than the patient's nominated pharmacy
Order a repeat prescription
This API will only allow orders for repeat prescriptions. Acute prescriptions should be handled via other methods until this functionality is supported.
A patient can add supporting evidence or additional information to a reqest which ensures that the practitioner will have all relevant information upon reviewing a medication order. For example a patient can include additional details such as where they are going on holiday or if they are reaching the end of their previous prescription.
The details of the request are bundled together into MedicationRequest:
- Status (requested, approved, rejected)
- Intent (order)
- Medication (name of medication)
- Authored On (DD/MM/YY)
- Note (free text supporting information provided by the user)
- Status Reason (to be used when request is rejected)
- Requester (patient)
- Dosage Instructions
- Previous Prescription (ID linking to the previous prescription issued)
- Prescription Type (repeat)
As part of the ordering process the patient can check the pharmacy the prescription will be sent to (once approved by a practitioner) for electronic prescriptions. This is where they can choose to send their prescription to an alternative pharmacy as a one-off nomination. This functionality is only available for electronic prescriptions which are processed via EPS.
When a patient chooses a one off nomination the MedicationRequest bundle will also include location details which can then be sent on for EPS to process should the practitioner approve the request:
- ODS Site Code
- Name
- Type
- Hours of Operation
For paper prescriptions the patient will be informed to collect their prescription from their practitioner.
View medication
Retrieves a full list of all medications related to the patient, including current and historic medication for both repeat and acute prescriptions.
Cancel prescription order
Patients can only cancel a prescription order if it has not been processed by a practitioner, while the status is 'Requested'.
Each medication item is requested individually and then bundled together into a single message. This means that each item will have its own status and can be cancelled on an individual basis instead of the entire request.
Prescription status
Prescription tracking will follow the status model shown below. This requires the practitioner to be EPS enabled. Statuses within the green area are in scope for the Prescriptions Management API.
For paper prescriptions tracking will end once the prescription has been printed.
Requested
Repeat prescription order has been created and submitted to practitioner systems but processing has not been started.
Approved
Repeat prescription order has been reviewed by a practitioner and passed through the system to EPS for processing/ printed ready for collection by the patient.
Rejected
Repeat prescription order has been reviewed by a practitioner and will not be processed further. When this selection is made by a practitioner they should be required to provide a rejection reason so the patient has context for this decision. This note is included within the 'status reason' free text field to ensure the full context of the response from the practitioner can be included in any response.