A GP Connect FHIR call does not start with GP Connect. Before a consumer system can ask a provider for a patient's record or a free appointment slot, it has to know which patient it means, which practice holds their record, and which technical endpoint on the Spine that practice exposes. That work happens across the Personal Demographics Service and the Spine Directory Service, in a fixed order, before the Spine Secure Proxy ever sees a GP Connect request. Most integration delays trace back to a step in that sequence being skipped or assumed rather than executed, not to the GP Connect API itself.

Step one: verifying identity through PDS

The Personal Demographics Service is the authoritative source of NHS numbers in England, and a PDS trace confirms that a given NHS number is genuine, current, and correctly linked to the patient a consumer system believes it is dealing with. This is not an optional check that can be skipped when a system already holds an NHS number locally. A number that looks correct but has not been verified in real time carries a real risk of a request being made against the wrong patient's record, which is a clinical safety issue, not a data quality one.

The PDS response also returns organisational information, including the ODS code of the patient's registered GP practice, and that ODS code is what determines which GP Connect endpoint the rest of the sequence targets. Caching demographics or relying on a locally stored lookup rather than a live query introduces exactly the kind of staleness this step exists to prevent, since patients move between practices, temporary addresses, and care settings more often than a cached record accounts for.

Step two: discovering the endpoint through SDS

With the ODS code confirmed, the next step queries the Spine Directory Service, the accredited directory of every system on the Spine, holding Accredited System IDs, party keys, and FHIR service root URLs. Without this lookup, a consumer system has a correct patient and a correct practice, but no way to reach that practice's system programmatically.

This runs as two related calls. Retrieving the Endpoint resource, using the ODS code and the relevant GP Connect interaction ID, returns the message handling system party key and the base FHIR service root URL the practice exposes. Querying the Device resource then returns the practice's ASID, the identifier the Spine Secure Proxy uses to authorise and route messages correctly. Together, these two calls give a consumer system everything it needs to address future GP Connect requests to the right place.

It is worth building with the expectation that SDS behaves differently across environments. A sandbox environment may return only mock data, while integration and live environments supply fully populated identifiers. An integration that assumes sandbox-level responses everywhere will misbehave the moment it reaches a live environment, not because anything is broken, but because the assumption was wrong from the start.

Step three: confirming capabilities through the Spine Secure Proxy

With an ASID and a service root URL in hand, the consumer system can retrieve the provider's CapabilityStatement through the Spine Secure Proxy, which brokers and enforces governance on all traffic between consumer and provider. The CapabilityStatement describes which FHIR interactions and profiles that specific provider supports, Access Record Structured, Appointment Management, or others, and not every provider exposes the same set.

Caching this response for the duration of a session reduces unnecessary repeated calls, but a consuming system should still be built to handle a provider's capabilities changing between sessions, reacting to what is actually advertised rather than hard-coding an assumption about what every provider offers.

Step four: making the GP Connect request itself

Only once identity, endpoint, and capability have been established does the consumer system issue a live GP Connect FHIR request through the Spine Secure Proxy. Every request needs a specific set of headers, Ssp-From carrying the consumer's ASID, Ssp-To carrying the provider's, and an authorisation header containing a valid JWT bearer token, so that only accredited, authorised systems can call through and every request is logged with clear provenance.

An Access Record Structured request, for example, is built as a FHIR Parameters resource specifying which elements of the record are needed, medications, allergies, or conditions among them, and posted to the provider's endpoint, returning a FHIR Bundle on success. Appointment management interactions follow the same pattern of headers and tokens. Where something fails, a provider returns a FHIR OperationOutcome describing the problem, and a well-built consumer application surfaces that in a way a clinician or administrator can act on, rather than a generic failure message that hides which step went wrong.

Where the sequence actually breaks in practice

Most delays sit at the handoff points between these stages rather than inside the GP Connect API itself.

A failed PDS trace, or a registered practice that does not match expectations, usually means the NHS number has not been verified in real time, or the returned practice details are stale. An SDS lookup that routes to the wrong destination or cannot reach the provider usually traces back to an ODS code, interaction, or service root URL that was not used exactly as returned. A GP Connect read or search that fails despite a valid NHS number is often a patient resolution issue, since GP Connect requests should not assume the NHS number is the same as the provider's internal resource identifier. A request rejected before the provider even processes it points to a missing or malformed SSP header, most commonly Ssp-From, Ssp-To, or the interaction ID, or a JWT that is not valid for the specific operation being called. An attempt to call an operation the provider does not support means the CapabilityStatement was not checked or was checked and ignored. And an integration that works in one environment but fails in another almost always means the documentation, endpoints, or identifiers for that specific environment were not confirmed before deployment.

Treating this as a checklist during troubleshooting and assurance, rather than assuming the fault sits in the clinical API, resolves most integration issues faster than debugging the FHIR payload itself.

Governance, security, and audit

Both consumer and provider systems have to be correctly registered in SDS with matching ASIDs and accredited interactions, and a formal data sharing agreement has to authorise the flow of patient information between the two organisations before any of this is legitimate rather than merely technically possible. Every SSP request carries a JWT with claims for the issuing system, the user identity, and the intended audience, with the scope claim determining exactly which resources and operations are authorised. The proxy verifies these claims and logs them for audit before a request proceeds.

Clinical safety obligations run alongside all of this, not after it. Hazard logs, risk assessments, and safety sign-off under DCB0129 and DCB0160 need to reflect how the integration actually behaves, including the failure points above, since a hazard log that only covers the happy path misses most of where real risk sits. Audit logging should capture consumer and provider ASIDs, timestamps, request identifiers, the FHIR resource types accessed, and the user identity behind each request, since that is what turns a support incident into something that can actually be investigated rather than guessed at.

Real-world friction worth planning for

A patient record that cannot be found at the provider despite a confirmed PDS trace often means the patient has recently registered at a new practice and the provider's systems have not yet caught up, which calls for a clear, specific message rather than a generic error. Multiple ASIDs existing for a single ODS code, common where an organisation hosts more than one GP system, means a consumer has to select the ASID tied to the correct interaction rather than defaulting to whichever one it finds first. Sandbox environments returning incomplete SDS payloads can look like a broken integration when it is simply a test environment behaving as designed. And capability mismatches between providers mean a consuming application should adapt to what a provider's CapabilityStatement advertises, rather than assuming every practice supports the same set of operations.

Where this connects to build work

This entire sequence, verify the patient, resolve the organisation, confirm the endpoint, then make the request, is the same shape of problem we solved 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. Getting that identity resolution correct, and provable, was the actual engineering work, in the same way it sits underneath every PDS to SDS to GP Connect integration described above.