Skip to content

GP Connect Architecture Patterns

This page tracks NHS GP Connect architectural patterns.

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.

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.