PFS Appointments

Note: This is a draft version of the GP Connect PFS Appointments capability. The current version can be found using this link.

Design Principals

Appointment API scope

The scope of pfs appointment management is to deliver:

SELECTED Functionality required for patients to create, cancel or view their own appointments at their GP.
Functionality to view or manage an entire diary/appointment book.
Functionality to create, amend, update diaries and/or schedules.

Access to available slots

When requesting the schedule of a particular diary, the level of detail returned should include:

All booked appointments and available slots.
Only slots that are available (all types).
SELECTED Only slots that are available, have been marked/flagged as externally bookable via PFS appointments and match the 'Embargo/Booking Window' rules.

Search parameters

The following search parameters will be initially included:

*** Need input from GARETH

All available common (across all four systems) slot defining criteria such as Gender, Slot Type, Slot Length, complex date/time ranges.
SELECTED 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.

Note: The Search Filter specification is flexible to allow for further search parameters to be defined. Value sets will be defined for these to be used by subsequent provider system slot access control.

Maximum time span of diaries returned

When searching for diaries, the results will be:

Unlimited based on any timespan provided as part of the search.
SELECTED Always be limited to a pre-defined maximum time period.

Note:A 2-week window was agreed with system suppliers as a reasonable trade-off between performance and usefulness initially, with the team seeking feedback from wider industry.

Do we need to use the 'AppointmentResponse' resource?

As per the suggested FHIR workflow in the FHIR Appointment should the booking of an appointment utilise the 'AppointmentResponse' FHIR resource or are HTTP response codes sufficient for GP Connect use cases?

AppointmentResponse resource will be provided in response to a booking request.
SELECTED HTTP codes will be used to convey success/failure of a booking request.

SELECTED This is NOT to be applied in the context of the Appointment Management capability.

Viewing booked appointments

This is only supported for future appointments, given the primacy of the administrative use case. Historic appointments should be considered part of the patient's medical record and therefore accessed via the Access Record HTML 'Encounters' view from the patient's registered GP practice. This assumes an update, according to usual business processes and external to GP Connect, by other GP practices hosting an appointment for the patient to their registered GP record. In the interest of simplicity and clarity in the specification, and taking into account the limited risks, the considered decision has been made that today's appointments will be classed as 'future'.

SELECTED This is supported for both past and future appointments. This is in-order to mirror current functionality in IM1.

Cancelling booked appointments

What provision will be made for making changes to existing future appointments?

Only cancellation will be allowed (must cancel and re-book).
SELECTED Cancellation of future Appointments are accommodated.
Cancel will be provisioned for (allowing appointments to move between slots/rescheduled).

Are appointment cancellations only able to be made by patients which booked them originally?

SELECTED Cancellations can be made by the patient.

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?

SELECTED 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 re-booked.

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.

Neither the Spine Secure Proxy, nor the GP Connect provider will expose such federation configuration or expose any aggregated view of appointments for a federation.

Please refer to the glossary for a definition of a federation in this context.

Branch surgeries

Please see Branch surgeries for more information GP Connect handling of branch surgeries, and implications for Appointment Management.