GP Connect is the NHS service that allows authorised clinical staff to view, and in some settings update, GP-held patient information from within their own clinical system. It was introduced to address a long-standing structural problem in English healthcare: the same patient's record existing in isolated systems across GP practices, hospitals, community services, and ambulance trusts, with no standard way for one to query another.

GP Connect explained

GP Connect is the NHS service that lets authorised clinical staff view and, in some cases write to, GP-held patient information from inside their own clinical system, rather than the GP's. It does not move records. It does not create a new database of patient data sitting somewhere in the middle. It gives an already-assured system a secure route to ask a GP system a question and get a structured answer back.

Before it existed, that question was usually a phone call. A hospital team waiting on an answer from a GP practice, a paramedic with no way to check a medical history at all, an out-of-hours service working from whatever the patient could remember under pressure. GP Connect replaces the phone call with an API request that returns the same information in seconds, in a format the receiving system can use.

The programme was expanded quickly during the Covid-19 pandemic, when the Summary Care Record framework was extended under emergency powers and rapid information sharing stopped being optional. It has stayed part of the core NHS digital estate since, because the underlying problem it solves, a patient's record sitting in one system while the clinician treating them uses another, did not go away when the emergency did.

What a clinician can see

GP Connect covers several distinct capabilities, and they solve different problems.

A read-only HTML view lets a clinician in another setting see a patient's GP record as a formatted page, filtered by date range, without leaving their own system. This is the fast option: useful for context, not built for machine processing.

Structured record access returns the same information as coded, importable data rather than a page to read. This is the version that supports automated checks, for example flagging a medication interaction before it happens, because the receiving system can parse what it has been sent rather than a clinician reading it off a screen.

Document access lets a clinician search for and retrieve unstructured documents already held in the GP record, discharge summaries and letters most commonly, cutting the time spent chasing paperwork that already exists somewhere in the system.

Appointment management and document sending round out the set, letting services book and coordinate across systems and push updates such as consultation summaries back to the registered practice, so continuity does not depend on someone remembering to fax something over.

The data itself covers encounters, active problems and long-term conditions, allergies and adverse reactions, current and past medication with dosage history, referrals, observations such as blood pressure and pulse, and immunisation history. All of it comes through GP Connect's APIs in a standardised, nationally defined format, which is the detail that matters. Two systems returning the same condition coded two different ways is not interoperability, it is two systems that happen to be connected. Standardisation is what makes the data safe to act on rather than just visible.

Why the standardisation is the hard part

Access alone does not make data useful. A structured API returning coded, standard-format data is what lets a receiving system trust what it has just pulled in enough to act on it automatically, rather than asking a clinician to interpret a free-text field from a different organisation's system. That is the difference between GP Connect as a lookup tool and GP Connect as infrastructure other systems can build safety checks on top of.

It also means the compliance and consent work is not an afterthought bolted on top. Access is role-based and auditable, and organisations have to sign the National Data Sharing Arrangement and run an assured clinical system before they can use it at all. None of that is a separate governance exercise sitting next to the technical build. It is the technical build.

GP Connect in the room

In the West Midlands, GP Connect access has changed how out-of-hours clinicians handle cases that would otherwise default to hospital. NHS England describes one case in Herefordshire and Worcestershire in which a young patient with a long-term congenital condition contacted an out-of-hours service one evening. In the past, that call would have ended in advice to attend the emergency department. With the patient's GP record visible directly, including current medication and history, the clinician was able to advise specific home management instead, and the trip to hospital was avoided.

That is the pattern GP Connect is built to produce everywhere it is properly integrated: fewer phone calls, less duplicated testing, and a clinician working from the same picture regardless of which part of the system the patient walked into.

Where this connects to build work

GP Connect is one route into a wider problem that most of our NHS integration work sits inside: getting one system to trust and correctly interpret data it did not generate itself. We have built that pattern before in a different corner of primary care, replacing manual entry of patient demographics at registration with a certificate-secured lookup against the NHS Spine, with modulus checks on the NHS number and a full audit trail behind every match. The problem was the same shape: a clinician staring at a form, and a national source of truth they had no direct way to query.