GP Connect gives authorised systems a standardised way to read and, in defined cases, write to GP-held patient records in EMIS and SystmOne. For a clinician, that shows up as a record appearing on screen. For a development team, it is a different problem: an API surface built on FHIR, sitting behind NHS Spine routing and identity controls, with its own onboarding and clinical safety assurance process before anything goes live. Building against GP Connect correctly means treating all of that as one piece of work, not a technical integration with governance bolted on afterward.

What the API covers

GP Connect is not one API. It is six distinct capabilities, and each one solves a different problem for a consuming system.

Access Record HTML returns a read-only, human-readable view of a patient's GP record, rendered as a page rather than data. It is the fastest capability to build against and the right choice when a clinician simply needs to read the record, in urgent or out-of-hours settings most often.

Access Record Structured returns the same underlying information as coded, FHIR-formatted data that a consuming system can parse and act on. This is the capability that supports automated use, medication interaction checks or clinical decision support among them, because the system receiving the data can interpret it rather than a person reading it off a screen. Structured access currently covers medications and allergies most fully, with coverage of the wider clinical record expanding over time, so a consuming system should not assume every part of the record is available in structured form yet.

Access Document retrieves unstructured documents already held in the GP record, referral letters and discharge summaries most commonly, closing the gap left by Access Record HTML for anything that was never coded in the first place.

Appointment Management lets a consuming system book, amend, or cancel GP appointments across systems, supporting workflows that need to touch scheduling rather than just clinical history.

Send Document provides a standardised route for sending a document into a GP practice system, useful where another setting needs to push something back to the registered practice.

Update Record is the newest and most consequential capability. It allows an authorised system, in community pharmacy or urgent care most commonly, to send structured data into a patient's GP record rather than just read from it. Under the 2025/26 GP contract, practices are required to enable Update Record alongside Access Record HTML and Structured by 1 October 2025, which makes it the capability most likely to become a baseline expectation rather than an optional extra.

The architecture underneath the API

GP Connect is built on FHIR, using constrained profiles specific to NHS use cases rather than raw FHIR resources. That constraint is deliberate. It fixes mandatory fields, value sets, and cardinalities so that two different consuming systems interpret the same GP Connect response the same way, which is the point of the standard rather than a compliance detail sitting on top of it.

The APIs themselves are RESTful, secured over TLS, and routed through the NHS Spine, which directs each request to the correct GP system based on the patient's registration rather than requiring the consuming system to know which system holds the record. Authentication and authorisation rely on role-based access control and system-level identity, most commonly via smartcards or the equivalent CIS2 credentials, so access is tied to a specific authorised user in a specific context, not to the application in general.

None of this is unusual for a national integration layer. What makes it demanding in practice is that a consuming system has to get identity resolution right before any of it matters. Structured or HTML, the record GP Connect returns is only useful if the system requesting it has already confirmed which patient it is asking about, which is where Personal Demographics Service lookups and NHS number matching sit upstream of every GP Connect call.

Data models, coding, and what gets lost in translation

Structured data returned through GP Connect uses SNOMED CT for clinical concepts, dm+d for medications, and NHS-defined value sets elsewhere. A consuming system that displays this data directly to a clinician, or acts on it automatically through rules or alerts, has to interpret those codes correctly rather than treating them as opaque strings to pass through. Where a system's own internal coding differs, that mapping work sits entirely on the consuming side. GP Connect will return accurate, standardised data. It will not translate that data into whatever scheme a receiving system already uses internally.

The same discipline applies to context, not just codes. A medication's status, or a problem's episode of care, changes what the data means clinically. Treating a discontinued medication the same as an active one because the field was read but not interpreted is exactly the kind of error that a hazard log is supposed to catch before it reaches a patient.

What has to be in place before development starts

Four things sit ahead of any GP Connect build, and none of them are optional extras once a system is heading toward live use.

• Network access. Health and Social Care Network access is required for live environments, with separate arrangements available for development and test.
• PDS compliance. The ability to perform Personal Demographics Service lookups, either directly or through a third party, is what makes correct patient identification and NHS number resolution possible in the first place.
• Information governance sign-off. Confirms that access is for direct care, that the user requesting data has a legitimate relationship with the patient, and that every access is auditable, under the GP Connect Direct Care API Information Governance Model.
• Clinical safety oversight. A named Clinical Safety Officer, DCB0129 compliance for the manufacturer, and DCB0160 compliance for the deploying organisation, built into the design rather than assembled at the end as paperwork.

Testing, assurance, and going live

GP Connect onboarding runs through the Digital Onboarding Service across three gates, covering technical conformance, clinical safety evidence, and information governance compliance in turn. NHS England provides an API provider test suite, an interactive demonstrator for inspecting request and response payloads, and representative clinical test data, so a team can validate behaviour before touching real patient records. Functional conformance is the minimum bar. Performance, resilience, and user acceptance testing under realistic conditions are what determine whether a system is ready for live traffic, not just whether it passes the specification.

Where this connects to build work

The hardest part of a GP Connect integration is rarely the API call itself. It is trusting data that another system generated, resolving which patient it belongs to, and holding that agreement steady while the systems on both sides keep changing underneath it. We built exactly that 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 shape of the problem was the same one any GP Connect consumer faces: a national source of truth, a patient identity to resolve correctly, and an audit trail that has to survive a DCB0129 assessor asking to see it.