Appointment API Scope
The scope of appointment management is to deliver:
- SELECTED Functionality required to manage appointments in the context of a patient.
- Functionality to view or manage an entire diary/appointment book.
- Functionality to create, amend, update diaries and/or schedules.
New/unknown patients booking
The ability to create appointments for Patients not known to the GP practice/diary owner:
- If a patient is not known to the local system the appointment booking will be rejected by booking system. It will not be possible to register the patient.
- SELECTED If a patient is not known to the local system the appointment booking will be rejected by booking system. It will be possible to register the patient via a separate patient registration end point.
- If a patient is not known to the local system the appointment booking will be accepted and a patient record will be created with basic details about the patient (identifier).
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 and have been marked/flagged as externally bookable via GP Connect.
The following search parameters will be initially included:
- All available common (across all four systems) slot defining criteria such as Gender, Slot Type, Slot Length, complex date/time ranges.
- SELECTED Date Range, Urgent Care (UC) Disposition Code & Service ID, and Requesting Organisation Type are accommodated to support potential available appointment slot filtering (consumers can then apply further filtering, sorting at client side). The last 3 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:
- Unlimited based on any time span provided as part of the search.
- SELECTED Always be limited to a pre-defined maximum time period.
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.
Patient Dissent To Share
SELECTED This is NOT to be applied in the context of the Appointment Management Capability
Viewing and Amending Booked Appointments
SELECTED 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’.
Cancelling and Amending booked appointments
What provision will be made for making changes to existing appointments?
- Only cancellation will be allowed (must cancel and re-book).
- SELECTED Cancellation and Amendments to the Appointment Reason, Description and Comment are accommodated.
- Cancel and comprehensive amendments will be provisioned for (allowing appointments to move between slots/rescheduled).
Can appointments be re-scheduled?
The API will not make provision for re-scheduling of appointments in a single interaction as a result of the limitation on which data elements of an appointment can be amended.
Therefore, a consumer wishing to re-schedule an appointment can do this through two 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 relevent organisation set of endpoints in order to gain a federated view of appointments.
Neither Spine Security 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.