GP System Integration Mechanisms - A Guide for External Integrators
This was written by an LLM based on conversations I had with it over a period of time and research done via web and offline documents. Current as of March 2026. The developer.nhs.uk site was decommissioned on 2 March 2026; some GP Connect spec links now point to UK Gov Web Archive copies.
I thought it might be beneficial to post it here where others can read and learn from it. Sadly NHS England’s documentation is quite focused on each of the integration products individually, and doesn’t give a decent overview. Also the NHSE official information is spread across many many web pages, the information density is pretty low.
An honourable mention should go to this very helpful article by 6B, which does actually distil down some of the good info.
- GP System Integration Mechanisms - A Guide for External Integrators
The GP System Landscape
Before getting into mechanisms, it is worth noting who you are actually integrating with. The two dominant foundation system suppliers are Optum (EMISWeb) and TPP (SystmOne). A small but growing number of other suppliers (Cegedim Vision, Medicus) are working through the Digital Care Services (DCS) Framework onboarding. The mechanism you choose may behave differently - or not be available at all - depending on which of these systems you are targeting.
The Main Integration Mechanisms
1. GP Connect
GP Connect is the NHS England-designed, nationally standardised programme for GP system integration. It is FHIR-based and routes through the Spine Secure Proxy (SSP). It has several distinct sub-capabilities:
GP Connect: Access Record HTML
A FHIR API that sends a FHIR DSTU2 payload over a Spine Server proxy transport. It gives a rendered, read-only HTML view of the patient record from their registered practice - no structured data for machine processing. Designed primarily for clinicians in urgent care, out-of-hours, or cross-organisational settings who need to quickly see what a patient’s GP holds. Think: an A&E clinician pulling up a GP summary. Simple to consume but you cannot extract, process, or write back anything from the HTML view.
GP Connect: Access Record Structured
Retrieves structured information - patient data in a coded format that a consuming system can import and process - from a patient’s registered GP practice. The consuming system can import and process the patient data in whatever way it requires to best support patients and healthcare professionals treating them.
Supported clinical areas include medications, allergies, and most of the clinical record; some areas are still in development. The API is brokered through Spine, uses FHIR STU3, and is available via HSCN - though public internet access is planned.
This is the main route for building something that actually needs to consume and act on GP record data programmatically.
GP Connect: Access Document
Retrieves unstructured documents from a patient’s GP practice record - typically clinical documents received from various health and care settings and held by the registered GP practice. The example use case is a district nurse viewing a hospital discharge summary held at the GP practice.
GP Connect: Send Document
Sends a PDF consultation summary to a registered GP practice. Uses FHIR STU3 message payloads over MESH, defined by ITK3 v2.10.0. This is currently the only write-back capability in GP Connect, and it is document-level only - you are filing a PDF into the GP record, not writing structured coded data. Designed for point-of-care scenarios where the sender is a clinical system supporting a clinician, and the receiver is the patient’s registered GP system.
GP Connect: Appointment Management
A separate capability for reading and managing appointments in a GP system, used mainly for federated booking tools and extended hours services. Note: new supplier development on this capability has been paused; onboarding for existing suppliers on existing integrations continues.
GP Connect: Update Record
Currently restricted to community pharmacy use only. Allows structured data to be written back to the GP record - the only GP Connect capability that does this. Not available for general integrators.
GP Connect - Summary
- Nationally standardised, supplier-agnostic interface
- Read-heavy; structured write-back is not available for most integrators (document filing only via Send Document; Update Record is pharmacy-only)
- Requires HSCN access and Spine integration
- Onboarding via NHS England use-case submission (14-day response target)
- Clinical safety officer required (DCB0129/0160)
- Intended primarily for direct care by clinicians
2. IM1 (Interface Mechanism 1)
IM1 is the older, pre-GP Connect integration framework - but it is still very much live. There is no confirmed decommissioning timeline. The NHS England position as of early 2026 is that the long-term future is under consideration, but no plans or timescales exist.
IM1 is not a single API - it is an umbrella framework covering three distinct interface types:
IM1 Transaction API
Real-time, bidirectional integration with the GP system. Allows systems to search for patients, retrieve medical records, manage consultations, and file documentation, among other tasks. This is the workhorse interface for embedded third-party tools that operate within the GP clinical workflow - a document management system, a decision support tool, or a clinical triage product that needs to read and write back to the record in real time.
Note: some implementations require a software component installed on the local practice machine, as the integration works through the GP system client rather than a web API.
IM1 Bulk (Extraction) API
Provides access to bulk clinical data held within provider systems. GP practices must provide consent for each extract, and data sharing agreements are required. Consumers specify which data tables they require and receive a full extract initially, with daily deltas thereafter.
As the data can be up to 24 hours old, this is not recommended for direct patient care. This is the route for population health analytics, research, quality improvement dashboards, and similar uses where you need a large-scale view across a practice list or PCN.
IM1 Patient API
Provides end users (patients or their authorised representatives) with access to functionality as specified by the patient’s GP practice. To set up an account on a consuming system, the user or patient must obtain linkage details from the GP practice, which are input into the consuming system to link with their clinical record. This is the route for patient-facing apps: appointment booking, prescription requests, record access.
IM1 Governance Model
The IM1 onboarding process is NHS England-managed and covers technical conformance, clinical safety, and information governance. Consuming suppliers must pair with each foundation system supplier separately and execute a Model Interface Licence with each. Pairing with EMIS does not give you SystmOne access - they are separate processes.
Critically, IM1 interfaces are not built to a standard specification and core system suppliers are free to implement in whatever way they see fit. This is the key practical difference from GP Connect - the API surface, data model, and even the transport vary between suppliers. You effectively get a different API from EMIS and from TPP.
3. Supplier ‘Partner API’ Connections
Direct commercial relationships with individual GP system suppliers, outside the NHS England-managed framework.
EMIS Partner API
EMIS has made their Partner API available to consumers via an IM1 commercial model. It is similar to their Transaction API but the functionality available is different. It is only applicable with the EMISWeb GP module and to practices based within England.
In practice, the EMIS Partner Programme is a tiered commercial arrangement where EMIS certifies third-party software and makes it visible within the EMIS Web interface - for example, appearing in an embedded external viewer tab within the patient record. It gives deeper access to EMIS-specific data and workflows than GP Connect, but is EMIS-only and requires a direct commercial agreement with Optum/EMIS.
TPP SystmOne APIs
TPP has a number of interfaces that work across all care settings. For third-party integration with the SystmOne GP module, suppliers follow the Digital Care Services IM1 Pairing Integration Process. For GP Connect, TPP directs suppliers to NHS England. For other integration types, TPP has its own Integration Request Process.
TPP has historically been more restrictive about third-party integrations than EMIS, but has opened up more in recent years.
4. EMIS-TPP Direct Interoperability
An often-overlooked mechanism - a bilateral agreement between EMIS and TPP that enables cross-system record viewing without an external integrator involved. This provides the ability to view important patient details across clinical systems via an embedded HTML view within either EMIS Web or SystmOne.
This is not something an external integrator builds against - it is a configuration option for organisations that straddle both systems (e.g. a PCN where different practices use different systems). Useful to know about as it explains some of what clinicians can already see without any third-party integration.
5. Other Mechanisms Worth Knowing About
MESH (Message Exchange for Social Care and Health)
MESH is not a GP-specific API, but it underpins GP Connect Send Document and many other NHS messaging flows. If you need to deliver documents or structured messages to GP practices asynchronously, MESH is the transport layer. You can send FHIR, PDF, or HL7v2 payloads over MESH to a GP practice’s MESH mailbox without going through GP Connect’s SSP - though the receiving GP system still needs to be configured to accept and process those messages.
HL7v2 Messaging (legacy)
Older integrations - particularly lab results, discharge summaries, and pathology - still flow to GP systems as HL7v2 messages over MESH or HSCN. This is established territory for lab and secondary care systems. Not an active development target but you will encounter it in the wild.
NHS App / Patient API Layer
The NHS App uses GP Connect’s Patient API (which itself builds on IM1 Patient) to surface GP record data to patients. If you are building a patient-facing product and want to use NHS Login as the identity layer, there is an interplay between NHS App APIs, GP Connect, and IM1 Patient that you need to understand. It is not a separate integration mechanism as such, but the patient consent and authentication model is different from clinician-facing integrations.
Comparison Table
| GP Connect HTML | GP Connect Structured | GP Connect Send Doc | IM1 Transaction | IM1 Bulk | IM1 Patient | Partner API (EMIS) | |
|---|---|---|---|---|---|---|---|
| Intended use | Urgent/OOH care, cross-org viewing | Direct care data consumption | Post-encounter filing | Embedded clinical tools | Analytics / population health | Patient-facing apps | EMIS-specific deep integration |
| Read | HTML view only | Yes - structured FHIR | No | Yes | Yes (T+24h) | Yes | Yes |
| Write back | No | No | PDF only | Yes | No | Limited (bookings, Rx requests) | Yes |
| Structured data | No - rendered HTML | Yes - FHIR STU3 | Sends structured, lands as doc | Varies by supplier | Yes - raw tables | Limited | Yes |
| Bulk capable | No | No (per-patient) | No | No | Yes - core purpose | No | No |
| Real-time | Yes | Yes | Async (MESH) | Yes | No | Yes | Yes |
| Standardised spec | Yes (FHIR DSTU2) | Yes (FHIR STU3) | Yes (FHIR STU3 + ITK3) | No - supplier-specific | No - supplier-specific | No - supplier-specific | No - proprietary |
| GP system coverage | EMIS + TPP (partial others) | EMIS + TPP (partial others) | EMIS + TPP | EMIS + TPP separately | EMIS + TPP separately | EMIS + TPP separately | EMIS only |
| Network requirement | HSCN | HSCN | HSCN or internet (MESH) | Local / HSCN | Local / HSCN | Internet | Internet / HSCN |
| Onboarding body | NHS England | NHS England | NHS England | NHS England + supplier | NHS England + supplier | NHS England + supplier | EMIS/Optum directly |
| Clinical safety req | Yes (DCB0129/0160) | Yes | Yes | Yes | Yes | Yes | Yes |
How to Choose
For clinician-facing, cross-organisational record access - GP Connect Structured is the right long-term target. It is supplier-agnostic and nationally governed. If you only need to display the record (not process it), HTML is simpler but more limited.
For filing back to the GP record from a care encounter - GP Connect Send Document is the approved route, but accept that you are filing a PDF, not writing coded data. If you need to write coded clinical data (diagnoses, medications, SNOMED codes), IM1 Transaction is currently the only route and requires a separate pairing for each system supplier.
For analytics, population health, or research - IM1 Bulk is the right route. Expect data sharing agreements, practice-level consent, and daily rather than real-time data.
For patient-facing services - IM1 Patient or NHS App integration, depending on whether you want to integrate with the NHS identity stack.
For deeply embedded, EMIS-specific tools - the EMIS Partner Programme gives the richest access but ties you to one supplier and a commercial relationship with Optum.
For building something new that needs to work across both EMIS and TPP - GP Connect is significantly less work than maintaining two separate IM1 pairings, but its write-back capability is weaker. Many products end up needing both - GP Connect for reading, and a separate document-sending route or IM1 for writing.
Practical Realities
A few things the formal documentation will not tell you:
- IM1 pairing timelines are typically 6-18 months and require a clinical safety officer from day one
- The SCAL (Supplier Conformance Assessment List) is substantial - treat it as a serious governance undertaking, not a form-filling exercise
- EMIS and TPP have historically had different levels of openness - TPP has been notably more guarded about third-party access historically, though this has improved
- GP Connect supplier rollout is not uniform - some GP Connect capabilities are not yet available in all practices, and you cannot assume a given practice has enabled a given capability
- The developer.nhs.uk site was decommissioned in March 2026 - many GP Connect spec links now point to UK Gov Web Archive copies; check the NHS England API catalogue (digital.nhs.uk/developer) for current live links
- IM1 interfaces are not standardised across suppliers - building for both EMIS and TPP via IM1 effectively means building and maintaining two different integrations
- Free text and documents via IM1 are controlled - access to free text and documents is limited to specific, approved use cases; IM1 prioritises structured data
Key Resources
- NHS England IM1 Pairing Integration
- NHS England IM1 Interface Mechanisms Guidance
- NHS England GP Connect
- NHS England API Catalogue
- TPP Integration Request Process
- IM1 Confluence Spec (GP IT Futures)
Prepared March 2026. This landscape changes - always verify current status of individual GP Connect capabilities via the NHS England supplier progress pages before committing to an integration approach.