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
Appointment API scope
The scope of (Patient Facing) Appointment Management is to deliver:
- functionality required for patients to create, cancel or view their own appointments at their GP
Access to available slots
When requesting the schedule of a particular diary, the level of detail returned should include:
- only slots that are available, have been marked/flagged as externally bookable via this APIs and match the 'Embargo/Booking Window' rules
Search parameters
The following search parameters will be initially included:
- Date Range, Booking Organisation Type, Booking Organisation ODS Code, Urgent Care (UC) Disposition Code and Service ID are accommodated to reflect more targeted provider system slot availability and return. Consumers can then apply further filtering and/or sorting at the client side. The last 2 are required to support the use of GP Connect APIs by UC Services.
Maximum time span of diaries returned
When searching for diaries, the results will be:
- always be limited to a predefined maximum time period
Do we need to use the 'AppointmentResponse' resource?
As per the suggested FHIR workflow in the All Assets should the booking of an appointment utilise the 'AppointmentResponse' FHIR resource or are HTTP response codes sufficient for GP Connect use cases?
- HTTP codes will be used to convey success/failure of a booking request
Patient dissent to share
This is NOT to be applied in the context of the (Patient Facing) Appointment Management FHIR API.
Viewing booked appointments
- for patient-facing services - supported for both past and future appointments to mirror current functionality in IM1
Cancelling booked appointments
What provision will be made for making changes to existing future appointments?
- cancellation of future appointments are accommodated
Tentative appointment booking
Is it possible to 'hold' an appointment slot obtained via GP Connect, and then confirm the booking at the end of a consultation/triage process?
This functional requirement is not supported due to the additional technical complexity it would demand. End users will need to book the appointment, then cancel if necessary, and good practice will need to be locally specified in business rules and policies agreed by participating organisations. For example, the practice of reserving numerous slots at the start of a '111' Urgent Care Call triage by using the 'Book Appointment' API, and then cancelling, would be considered bad practice and could contravene such agreements.
Can appointments be rescheduled?
The API will not make provision for rescheduling of appointments in a single interaction. The must be cancelled and rebooked.
Therefore, a consumer wishing to reschedule an appointment can do this through 2 API calls - firstly to cancel the existing appointment, then secondly to create a new appointment at the new date/time.
Responsibilities in a federated booking context
Where there is a requirement for an implementation to provide an appointment management capability in a federated context, the GP Connect consumer implementation has the responsibility for defining the set of organisations which make up the federation. This consumer configuration will enable the consumer to make API calls to the relevant organisation set of endpoints in order to gain a federated view of appointments.
The GP Connect provider will not expose such federation configuration or expose any aggregated view of appointments for a federation.
See the glossary for a definition of a federation in this context.
Branch surgeries
GP practices with multiple surgeries
A GP practice may operate from a single surgery (location) or from multiple surgeries (multiple locations).
In GP Connect, a GP practice is represented by an Organization resource, and the surgeries are represented by Location resources. The surgery Location is linked to the GP practice Organization via the Location.managingOrganisation element.
A GP practice operating multiple surgeries usually designates one of the surgeries as a main surgery and the rest as branch surgeries. The designation of surgeries as main and branch doesn't have significant impact on GP Connect other than the main surgery normally having the same name and address as the GP practice, and the branch surgeries having different names and addresses.
When a patient registers at a GP practice with multiple surgeries, they are assigned a 'preferred' surgery, even though the patient is formally registered to the GP practice (organisation) as a whole, and can usually attend appointments at any of the surgeries (locations).
ODS codes
In GP Connect, an ODS code identifies a GP practice as a whole, and is populated in the Organization.identifier element.
APIM
APIM is used by GP Connect consuming systems to verify a patient's identity, and to retrieve the ODS code of a patient's registered GP practice.
The ODS code stored in a patient's PDS record represents the GP practice as a whole, and does not identify the patient's preferred surgery.
GP Connect routing
GP Connect uses ODS codes in order to route requests to a GP practice by including the practice's ODS code in the URL (see General API Guidance).
Therefore, when a GP Connect request is sent, it is sent to a practice as a whole, and not to a specific surgery.
The following query to read a Patient resource is being sent to the patient's GP practice identified by the ODS code D82809:
https://provider.nhs.uk/D82809/STU3/1/gpconnect/Patient/1
Implications for Access Record HTML and Access Record Structured
There are no implications for Access Record HTML and Access Record Structured because the patient's record is requested from the GP practice as a whole and not from an individual surgery.
Implications for Appointment Management
Because a GP practice's appointment book can hold appointments across multiple surgeries (locations), it is important to distinguish which surgery an appointment is held at, to allow the patient to decide where they wish to attend.
In order to do this, every Schedule resource has an associated Location resource which represents the surgery that the appointment will take place at, including the surgery's name, address and contact details.
To retrieve the patient's preferred surgery (assigned when they registered with the practice), a reference to the surgery Location is held in Patient.registrationDetails.preferredBranchSurgery. This can be used to identify appointment slots at the patient's preferred surgery by comparing its logical id with that of the Location resource referenced from the Schedule.actor element.