PFS Appointments

This guidance is under active development by NHS Digital and content may be added or updated on a regular basis.
Note: This is a draft version of the GP Connect PFS Appointments capability. The current version can be found using this link.

Design Overview

Purpose

To meet strategic objectives to improve access to GP care, the PFS Appointment Management API enables patients (via a consumer application) to book and manage GP practice appointments held in any of the four GP principal practice systems. The implementation of non-patient access is out of scope for this deployment, and is covered by the GP Connect Appointments 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 by PFS Appointments, ensuring that only slots available for direct patient booking are returned in response to a request.

The Appointment slots available via PFS Appointments 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 the Slot availability management page.

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 the Appointment Management capability:

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 Management consumer sessions illustrated.

Profiled FHIR resources

See the Appointment Management FHIR® resources page for details of the FHIR profiles used for the Appointment Management capability pack.

Spine interactions

The Appointment Management capability message set includes the following set of Spine interactions:

Operation InteractionID
Get organisation schedule urn:nhs:names:services:gpconnect:fhir:rest:search:slot-1
Read appointment urn:nhs:names:services:gpconnect:fhir:rest:read:appointment-1
Create appointment urn:nhs:names:services:gpconnect:fhir:rest:create:appointment-1
Cancel appointment urn:nhs:names:services:gpconnect:fhir:rest:cancel:appointment-1
Get patient appointments urn:nhs:names:services:gpconnect:fhir:rest:search:patient_appointments-1

Implementation and testing

Below is the suggested order in which the appointment 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.
back to top