Overview
Purpose
To meet strategic objectives to improve access to GP care, this API enables patients (via a consumer application) to book and manage GP practice appointments. The implementation of non-patient access is out of scope for this deployment, and is covered by the previous iteration: GP Connect Appointment Management API. Some API specification items may be uplifted in the future to reflect the requirements identified by related Appointment Management initiatives within the GP IT and Interoperability domains.
Example scenarios
- a patient can book, view or cancel appointments
GP practice appointment slot availability
GP practices need to control access by external organisations to their appointment book. Provider systems will enable practice users to designate their schedules/slots as bookable, ensuring that only slots available for direct patient booking are returned in response to a request.
The appointment slots available will also be categorised by the end user according to standardised values representing the role of the practitioner delivering the appointment and the channel by which the appointment is to be delivered - for example, 'telephone', 'in-person'. This provides more information to the patient booking the appointment, thereby reducing the risk of inappropriate appointment booking. The requirements are described in more detail in Slot availability management.
First of Type (FoT) care setting deployments
The following FoT deployments are being progressed:
Care Setting 1: Within GP federations
Enabling a patient to book, view or cancel in-hours or extended hours appointments at the patient’s registered GP practice or another GP practice within the same federation.
API definition
The following individual API calls are used by consumers to implement this API:
- How to retrieve a patient's appointments
- How to search for free slots
- How to read an appointment
- How to book an appointment
- How to cancel an appointment
Examples of consumer Appointment Management sessions
The use of the individual API calls listed above by consumers to fulfil business processes is illustrated with focus on the booking of an appointment. See - Appointment consumer sessions.
Profiled FHIR resources
See - All Assets for details of the FHIR profiles used for this API.
Service discovery
Determining which GP practice to book into
Patient's registered practice
The 'default' Appointment Management flow is shown in the diagram below. It utilizes APIM (all steps in the blue container below are within the APIM system) to handle the discovery of the patient's GP in the 'Identify Routing' step of the diagram below. The patient's NHS number is provided via NHS App login. Both the NHS number and ODS code are then sent to the API producer.
This flow is suitable for Appointment Management consumers that wish to book into the patient's registered practice, which is the only scenario supported in this release of Appointment Management.
Booking into other practices
Booking into other practices is not supported within this API. This may become available in future releases.
Consumer system configuration
Appointment consumer systems that are predominantly used to book into GP practices within the local area (such as within a local federation) may use local system configuration to determine the ODS organisation code of the practice to book into.
For example, a pre-configured pick list of organisations on the booking screen of the consumer screen allowing a user to choose which practice to book into. The pick list may be configured by the consumer organisation or by the consumer system supplier in conjunction with the consumer organisation.
Spine interactions
The message set for this API includes the following set of interactions:
| Operation | InteractionID |
|---|---|
| How to search for free slots | urn:nhs:names:services:gpconnect:fhir:rest:search:slot-1 |
| How to read an appointment | urn:nhs:names:services:gpconnect:fhir:rest:read:appointment-1 |
| How to book an appointment | urn:nhs:names:services:gpconnect:fhir:rest:create:appointment-1 |
| How to cancel an appointment | urn:nhs:names:services:gpconnect:fhir:rest:cancel:appointment-1 |
| How to retrieve a patient's appointments | urn:nhs:names:services:gpconnect:fhir:rest:search:patient_appointments-1 |
Implementation and testing
Below is the suggested order in which the Appointment Management capabilities should be implemented as a provider supplier. The specified order has been recommended around the functionality of the GP Connect Automated Test Suite and any internal dependencies between the test scenarios for the different Appointment Management endpoints. The Appointment Management capability test scenarios are dependent on the foundation capabilities and therefore the foundation endpoints should be developed and tested before implementing the Appointment Management capabilities.
It’s recommended that you develop against the Automated Test Suite as this will help with creating a GP Connect compliant product. By implementing the endpoints in the order below, the Automated Test Suite set of tests for that endpoint can be run during development without you seeing errors due to pre-test API calls or post-test validation API calls relevant to the test being run and failing as they have not been developed yet.
| Order | API endpoint | Test suite endpoint dependencies | Reason for dependency |
|---|---|---|---|
| #1 | Search for free slots | Read an organization / Read a practitioner / Read a location | The Search for free slots test scenarios require some of the foundation endpoints to validate references within returned resources contained within the response bundle. |
| #2 | Book an appointment | Register a patient / Find a patient / Search for free slots / Read an organization / Read a location / Read a practitioner / Read a patient | The Book an appointment endpoint finds a slot which it then uses to book an appointment for a known patient. To find the logical IDs of the elements required to book an appointment it requires the Find a patient and Search for free slots endpoints to have been implemented and working. Some of the tests also require the Register a patient endpoint to have been implemented as it tests booking an appointment against a GP Connect temporary patient. |
| #3 | Retrieve a patient’s appointments | Search for free slots / Find a patient / Book an appointment / Register a patient / Read an organization / Read a location / Read a practitioner / Read a patient | The test suite builds the appointments for a patient before testing the Find a patient’s appointments capability to make sure appointments exist to find. This requires the endpoints to find free slots, find a patient’s logical identifier, book an appointment and, in some tests, create a temporary patient against which to book the appointment. |
| #4 | Cancel an appointment | Search for free slots / Find a patient / Book an appointment / Register a patient / Read an organization / Read a location / Read a practitioner / Read a patient | The test scenarios for the Cancel an appointment capability require most of the foundation endpoints and the other Appointment Management endpoints to be implemented in order to find and create the appointments required for the test scenarios and validation of the returned response. |
| #5 | Read an appointment | Search for free slots / Find a patient / Book an appointment / Cancel an appointment / Register a patient / Read an organization / Read a location / Read a practitioner / Read a patient | The test scenarios for Read an appointment require different foundation endpoints and all the other appointment endpoints to be implemented as the tests need to create appointments with different statuses if they are not available. The test must find the local identifiers for both the appointment it is trying to read and any steps it may need to do to create or validate the appointment. |