GP Connect Architecture Patterns

This page tracks NHS GP Connect architectural patterns.

Onboarding check (8 September 2026): new developers can no longer onboard through GP Connect for Send Document, Update Record or Appointment Management; existing consumer suppliers can still onboard end users. Apply the current service boundary before treating a capability or DSIC standard as an available integration route.

Consumer and Provider Model

NHS England Digital describes GP Connect as an intermediary service connecting multiple consumers to multiple GP-system providers. Providers are GP practice IT systems that hold patient records, documents, appointments, prescriptions, and related information. Consumers are point-of-care or patient-facing applications that retrieve or update information.

Access Record and Access Document

For Access Record and Access Document, the consumer uses the patient's NHS number to identify the registered GP through PDS, uses the registered GP ODS code to find the GP system endpoint, calls Spine Secure Proxy with patient and endpoint details, and receives the response back through SSP.

Access Record: HTML supports read-only viewing of the existing registered practice's record without moving that registration. The PDS step identifies the registered GP; it is not a registration transfer.

The GP2GP Requesting Adapter serves a different workflow: the receiving GP system first completes the new permanent registration/PDS update, then uses the migration interface to obtain, integrate and acknowledge the transferred record. Reuse of GP Connect migration operations does not make that adapter a registration-preserving viewing route.

This distinction has a sender-side technical check: S94 Step 10 requires a PDS lookup and NACK 19 when the requesting practice does not match the current registered GP. An adapter accepting a request is therefore not evidence that a different practice can retrieve the record without the PDS registration prerequisite.

Send Document and Update Record

For Send Document and Update Record, the consumer sends a structured GP Connect FHIR message to MESH. MESH uses workflow and patient details to route the message to the relevant GP provider mailbox, where the provider system retrieves and processes it.

Patient Facing APIs

For Patient Facing APIs, the consumer calls GP Connect APIs hosted on the NHS API platform, which then routes to the registered GP provider system using the patient NHS number and registered GP lookup.

Evidence Status

Confidence is high for the architecture patterns because the source is NHS England Digital. These patterns do not establish whether a specific InterSystems product is assured, deployed, or configured for a given capability.

Follow-up Evidence

InterSystems product documentation that maps Health Connect or HealthShare components to SSP, MESH, or NHS API Platform routes.
Customer-side architecture documents for named deployments.