GP Connect Appointment Management is the national interface that lets an authorised system search a GP practice's free appointment slots and create, amend, read, or cancel a booking directly inside that practice's clinical system. It is what allows an urgent care hub, NHS 111, a GP federation, or an extended access service to book into a practice diary they do not own, reliably and with the practice's own system recording the result. Built on FHIR over the NHS Spine, it is not a typical REST integration with a compliance layer added afterward. The specification, the security model, and the assurance process are all shaped around one fact: this is a direct care API booking a real clinical appointment, not a general-purpose calendar.

What the API covers, and what it does not

Appointment Management handles the business acts of finding capacity and managing a booking, search for free slots, create an appointment, read an appointment, amend an appointment, and cancel an appointment. It is intended for clinical and administrative use within direct care, and it is a distinct specification from any patient-facing booking interface, which has its own separate rules.

It does not stand alone. Appointment Management sits next to Foundations, the GP Connect capability that handles demographics and organisational data, Read Patient, Read Organisation, Read Location, and related lookups. Any robust booking integration resolves the patient, the organisation, and the location through Foundations first, then uses Appointment Management for the actual booking. Attempting a booking with minimal context is technically possible and a reliable source of validation errors, because the provider's rules expect resolvable references, not partial ones.

Security, governance, and what has to be in place before building

All Appointment Management traffic flows through the Spine Secure Proxy, which handles authentication, authorisation, auditing, and data-sharing agreement checks in one place rather than requiring every provider to implement its own trust model. Transport runs over mutual TLS, and every request carries a JSON Web Token identifying the user, their role, the consuming system, and the consuming organisation's ODS code. This is what lets a provider attribute a booking to a specific person in a specific organisation without a separate trust arrangement for every consumer that connects.

Most implementations reach the Spine Secure Proxy over the Health and Social Care Network, so network posture is worth confirming early, along with how certificates will be managed across development, test, and production environments. Onboarding runs as a structured sequence: a use case submission describing the business problem being solved, followed by consumer assurance, technical and clinical safety due diligence that demonstrates conformance to the specification and safety in context. Clinical safety documentation under DCB0129 and DCB0160, led by an accredited Clinical Safety Officer, is part of that evidence, not a separate track that can be left until the build is otherwise finished. Aligning development milestones with the assurance gates, rather than treating them as sequential, is what keeps a project from stalling at the point evidence is due.

The data model: slots, schedules, and appointments

Appointment Management is built on FHIR STU3 with GP Connect-specific profiles, a detail worth noting directly if a team's other FHIR experience is with R4, since search parameters and elements differ. A slot search returns a Bundle containing profiled Slot and Schedule resources, along with references to Practitioner, Location, and Organisation. The Slot describes when and for how long a bookable window exists. The Schedule provides the broader context of the diary it belongs to. Together with the referenced resources, they connect that capacity to a real practitioner and a real place, which is what lets a consuming system present a slot to a user with confidence rather than a bare time and date.

Creating a booking means posting a profiled Appointment resource that associates the chosen Slot with the Patient and other participants. Amending updates specific attributes, where a provider supports it. Cancelling changes the status to cancelled with a reason code, so the change is auditable and visible to practice staff. Where something goes wrong, an invalid reference, a conflict, a business rule violation, the provider returns an OperationOutcome explaining the failure in a form a system can act on rather than just display.

Each operation also has its own Spine interaction identifier, a URN the Spine Secure Proxy uses to route and authorise the request correctly. These belong in a client library as hard-coded, tested constants, not as something reconstructed per call, since a request with the wrong interaction ID fails for reasons that have nothing to do with the payload itself.

The booking workflow in practice

A defensible baseline flow identifies the patient through Foundations, usually via NHS number verified against the Personal Demographics Service, then reads the relevant Organisation, Location, and Practitioner references. It searches Slot resources within a date range, filtered by delivery channel and practitioner type where that matters to the user. It creates an Appointment referencing the selected Slot and Patient, then persists the appointment identifier and confirms to the user.

Booking within a single registered practice is comparatively simple, since the ODS code is already known. Booking across a federation, an extended access hub, or a nearby practice requires a way to determine the correct practice first. A locally configured pick list works well for a known set of federation partners. For NHS 111 or other urgent and emergency care consumers booking more broadly, the Directory of Services can identify appropriate practices by hours, distance, and service provision before the booking itself proceeds.

Slot availability deserves its own design discipline. Practices control which slots are exposed, to which organisation types, and categorise them by delivery channel and practitioner role. A client should filter for compatible slot types based on the booking context, warn where a slot's channel does not match what the user expects, and revalidate slot status immediately before posting the Appointment to avoid a race condition where two users attempt the same slot. Where a conflict does occur, surfacing the OperationOutcome cleanly and returning the user to an updated slot list is a better design than leaving them at a dead end.

Amend, cancel, and the parts that need product thinking, not just API calls

Not every field is amendable, and providers vary in what they allow to change after a booking exists. Many integrations implement rescheduling as cancel and rebook rather than relying on amend, which sidesteps that variability at the cost of a slightly less elegant user flow. Whichever approach is used, validating against the provider's current state immediately before the change, and confirming the result with a fresh read afterward, prevents overwriting an appointment that has since been altered locally at the practice. On cancellation, releasing the slot back into search results promptly keeps supply visible to other consumers rather than leaving it appearing unavailable.

Testing in the order the assurance tooling expects

The Automated Test Suite validates capabilities in a specific order, slot search first, then booking, then retrieval, amendment, cancellation, and read, because that order mirrors the real dependencies between them. Booking needs working Foundations lookups to validate the references inside a slot search response. Retrieval and amendment need a booking to already exist. Building and testing in that sequence, rather than in whatever order feels natural to the codebase, tends to surface integration problems earlier and avoids the false confidence of a booking flow that works in isolation but fails once it depends on data from an earlier step.

The most common source of fragile integrations is skipping Foundations lookups to save time early, which produces confusing validation errors much later. Treating the JWT as a first-class artefact rather than boilerplate, logging its identifiers against request identifiers for traceability through the proxy, and testing against more than one GP system supplier rather than assuming uniform behaviour, are the details that separate an integration that passes conformance from one that holds up once real practices and real diaries are involved.

Where this connects to build work

Every path through Appointment Management starts the same way: confirming who the patient actually is before anything else happens. We built that exact pattern for a primary care technology provider, replacing manual entry of patient demographics at registration with a certificate-secured lookup against the NHS Spine using QuickSilva's Spine Mini Service, including NHS number modulus checks and a full audit trail behind every match. The identity resolution problem sitting in front of that project is the same one sitting in front of every Appointment Management booking, confirm the patient against a national source of truth before anything downstream can be trusted.