Written by Technical Team | Last updated 09.01.2026 | 18 minute read
General practice software has quietly become some of the most mission-critical infrastructure in the UK. Every day, GP teams rely on their clinical system to hold the definitive patient record, coordinate appointments, issue prescriptions, code consultations, and communicate with community services. Yet most modern care pathways extend beyond the four walls of a practice. Patients move between urgent care, community pharmacy, elective services, social care, remote monitoring, and digital-first channels. If the GP record cannot be accessed safely and consistently where it is needed, clinicians waste time re-entering data, patients repeat their story, and risk accumulates in the gaps.
That is why integrations with EMIS and SystmOne matter, and why GP Connect and FHIR have become central to building them. Done well, a GP Connect integration can enable read-only access to record content for legitimate care settings, improve booking journeys, and support structured data exchange with a shared language and predictable interface. Done poorly, it can add friction to practice workflows, create brittle dependencies, and introduce information governance headaches that slow down deployments.
This article takes a practical, engineering-led view of how to build high-quality integrations for GP practices using GP Connect and FHIR—especially when your product needs to work across EMIS Web and TPP SystmOne estates. It covers the architecture you are plugging into, the patterns that reduce delivery risk, and the choices that turn “an integration” into a reliable capability clinicians can trust.
Most GP-facing digital products start with a deceptively simple goal: “get the data” or “write the outcome back.” In reality, the value of an integration is rarely the raw payload. It is the clinical and operational outcome it enables—often measured in minutes saved, errors avoided, and continuity preserved.
For GP practices, time is the scarcest resource. An integration that reduces call handling, shortens appointment workflows, or eliminates duplicative documentation can have a compounding effect across reception, clinicians, and administrative teams. For patients, the benefit is usually felt as fewer handoffs, faster resolution, and less repetition. For ICBs and service providers, the prize is a more coherent pathway: information follows the patient, not the organisation.
EMIS Web and SystmOne dominate large portions of the GP clinical systems landscape. If your product can integrate with both, you move from “a local pilot” to something that can scale across regions with far less bespoke work. But cross-system scaling only works when you design for variation: differences in configuration, local governance, practice-level preferences, and the realities of network connectivity and identity tooling in NHS environments.
This is where NHS GP Connect is strategically important. Rather than creating bespoke point-to-point interfaces for each principal supplier, GP Connect provides a standardised way to access GP system capabilities via the Spine. That standardisation does not eliminate complexity—you still have to deal with assurance, security, conformance, and the nuances of clinical content—but it does give you a more consistent contract and a clearer route to supporting multiple suppliers.
Finally, it is worth acknowledging that integrations are not purely technical assets. They are trust assets. GP teams are rightly cautious: if a third-party tool surfaces incomplete information, times out during a consultation, or clutters the record with ambiguous updates, confidence evaporates quickly. The strongest integrations feel “boringly dependable.” They behave the same way every time, align with workflow, and make it obvious what is happening and why.
Key takeaway: A successful GP Connect integration isn’t just “connecting to EMIS Web or TPP SystmOne” — it’s building safe NHS interoperability clinicians can trust. Prioritise read-only clarity, FHIR validation, robust audit logging, and clear “as of” timestamps so teams don’t rely on stale or incomplete GP record data. When primary care EHR integration reduces re-keying and protects workflow, it scales faster across practices and avoids information governance delays.
Before you write a line of code, you need a clear map of the terrain—because the NHS has multiple integration routes, and the “right” route depends on your use case, your users, and what you are permitted to do.
At the centre of this landscape are the principal GP clinical systems, including EMIS Web and TPP SystmOne. They are not just databases; they are workflow engines with complex configuration, role-based access, clinical coding behaviours, and local templates. Integrating into them means respecting both the data model and the lived workflow of practice teams.
GP Connect sits on top of these principal systems to expose specific capabilities through a standard interface. As a consumer (your application), you do not connect directly to each practice system over the open internet. You connect through Spine-facing services and controlled proxying, with strong authentication, auditing, and authorisation. This matters because it changes how you design your integration: you are building within a governed ecosystem, not simply consuming an API.
In parallel, you may also encounter IM1 pairing. This is best thought of as an assurance and compatibility pathway to integrate with principal clinical systems through defined interface mechanisms. For many suppliers, IM1 pairing is part of the reality of becoming “allowed” to interoperate in certain ways and environments. In practice, it influences your delivery plan: timelines, evidence, test environments, and how you demonstrate safe behaviour.
It is also important to separate capability from product experience. GP Connect might allow you to retrieve structured record sections, but you still need to decide how that content appears in your UI, how you cache it (if at all), and how you ensure clinicians do not mistake it for a live, writable view. GP Connect might allow appointment interactions, but you still need to manage slot selection, concurrency, and what happens when a slot disappears mid-flow.
Two practical decisions will shape everything that follows:
First, decide whether your product is primarily a clinical companion (used by clinicians or care services to view GP record content) or a workflow actor (creating or updating items, booking appointments, writing back outcomes). The governance posture, testing burden, and risk profile rises sharply as soon as you can create or update clinical content.
Second, decide whether you are building for single-practice deployments (deep configuration, tight feedback loops, more bespoke support) or multi-practice rollouts (standardised onboarding, repeatable assurance artefacts, and tooling for variability). Cross-EMIS and cross-SystmOne scale is rarely achieved by “more code”; it is achieved by better onboarding design, clearer operational controls, and disciplined handling of exceptions.
HL7 FHIR standard is often described as “a standard,” but the real engineering value is that it provides a consistent way to represent healthcare concepts (patients, medications, allergies, encounters, observations) and a consistent way to exchange them. GP Connect uses FHIR-based APIs to expose defined capabilities from GP systems, brokered through Spine services. The net result is that your system can ask for information in a predictable structure rather than screen-scraping, relying on proprietary formats, or building a one-off integration for each supplier.
When developing for GP practices, it helps to think in layers:
A robust GP Connect integration treats all three layers as first-class concerns. If you focus only on the interoperability layer, you can end up with technically correct payloads that are clinically misleading or operationally fragile.
From an implementation viewpoint, you will commonly design around a handful of GP Connect-aligned capability patterns:
Even within “record access,” you will face a design fork: structured data versus rendered views. Structured FHIR payloads are powerful because your system can process them: you can reconcile medication lists, run rules, or populate downstream forms. Rendered views are powerful because they preserve clinical presentation and reduce misinterpretation risk—especially when the consuming context is “read-only decision support” rather than “data ingestion.”
This is where many integrations either shine or stumble. Structured data is not automatically safer. If you ingest structured items without a careful clinical interpretation layer, you can surface incomplete lists, double-count entries, or mis-handle historic versus current items. Conversely, relying solely on rendered views can limit what your product can do and can create awkward UX in modern applications. The best approach is often hybrid: use rendered views for fast clinical context and structured pulls for specific workflows where you can guarantee correct interpretation.
From a software architecture standpoint, scalable GP Connect integrations usually converge on a few proven patterns:
A dedicated integration service that encapsulates Spine-facing connectivity, token acquisition, request signing, audit logging, and error translation. This service becomes the single place where GP Connect complexity lives, and it prevents the rest of your product from being contaminated by integration-specific quirks.
A strict contract boundary between “FHIR as transported” and “clinical concepts as used.” In other words, you treat raw FHIR resources as external inputs, validate them, and only then transform them into your internal domain model. This makes it easier to evolve your system when profiles change, and it reduces the risk of UI and business logic accidentally depending on optional fields.
Deterministic reconciliation logic for common clinical lists. Medications, allergies, and problems often require careful handling of statuses, dates, and “entered in error” patterns. Build this as a tested library with fixtures, rather than scattering it across UI components.
A clear strategy for freshness and caching. In clinical settings, stale data is a safety risk. If you cache, you need explicit TTLs, user-visible “as of” timestamps, and defensive behaviour when data cannot be refreshed. In many workflows, the safest default is short-lived caching for performance, not long-lived storage.
The final piece is error handling. NHS connectivity paths can fail in ways commercial API consumers do not always expect: proxy constraints, certificate issues, directory mismatches, and practice-level configuration differences. Your application needs to distinguish between “no data,” “not authorised,” “endpoint not found,” “temporarily unavailable,” and “misconfigured.” If every failure becomes “Something went wrong,” your support burden will balloon and users will lose confidence.
When planning an integration with EMIS Web or TPP SystmOne, one of the earliest architectural decisions is whether to rely on GP Connect’s standardised interfaces or to pursue more direct, system-specific integration routes. While both approaches can enable access to GP data, they differ significantly in scalability, governance, and long-term maintenance burden.
The table below summarises the practical differences that tend to matter most in real-world NHS deployments, particularly for products aiming to operate across multiple practices, regions, or integrated care systems.
| Dimension | GP Connect–based integration | Direct EMIS / SystmOne integration |
|---|---|---|
| Scalability across practices | Designed for multi-practice and multi-region use through a standardised Spine-mediated interface | Often limited to specific deployments, requiring repeat work for each estate or configuration |
| Supplier variation handling | Abstracts many differences between EMIS Web and SystmOne behind common capability definitions | Requires supplier-specific logic and ongoing adaptation to system changes |
| Information governance posture | Built around nationally defined access controls, auditing, and assurance expectations | Heavily dependent on local agreements and custom governance evidence |
| Clinical safety risk profile | Primarily read-focused capabilities reduce risk when used for decision support and context | Write-back or deep access increases safety assurance, testing, and operational risk |
| Long-term maintenance effort | Changes managed through published API updates and conformance processes | Higher ongoing cost due to bespoke interfaces, version drift, and supplier changes |
Engineering teams sometimes underestimate how much of this work is about being a safe citizen in a regulated environment. A GP Connect integration is not simply a technical connection; it is a controlled interaction with sensitive health data. Your build plan should explicitly include assurance, governance, and operational readiness as deliverables—not afterthoughts.
Start with identity and routing. Your system needs to locate the right GP Connect endpoint for the right practice context, and it needs to prove it is allowed to access what it is requesting. In practice, this means building around the Spine-facing prerequisites and handling the reality that practices can be configured differently. Treat endpoint discovery and practice mapping as core product capabilities, not configuration trivia.
Security design needs to be visible in your architecture, not implied. That means clear separation of duties, locked-down secrets management, strong audit logging, and principled access control. A good rule of thumb is that you should be able to answer, quickly and precisely: who accessed which patient record, for what purpose, from which organisation context, and what was returned? If you cannot answer that without digging through ad hoc logs, you are not ready for real-world scrutiny.
Conformance is also a product discipline. The APIs may be standardised, but your implementation has to behave correctly under both normal and abnormal conditions. That includes rate limiting, retry behaviour, idempotency where relevant, timeouts that fail safely, and validation of payloads. It also includes user experience decisions: how you present partial data, how you label views, and how you avoid encouraging unsafe copy/paste behaviour.
Testing needs to be layered. Unit tests catch your transformation and reconciliation rules. Contract tests catch profile drift and optionality assumptions. Integration tests validate authentication, endpoint discovery, and request/response handling. Operational tests validate that your alerting, dashboards, and runbooks can actually support a live rollout when something breaks at 10:30 on a Monday surgery.
The most effective teams build a repeatable delivery checklist that prevents avoidable mistakes across practices and suppliers. A practical checklist often includes:
When you are supporting both EMIS Web and SystmOne footprints, you also need to design for variability without fragmenting your codebase. The trick is to keep the integration mechanics consistent while allowing the operational parameters to vary. Configuration should control practice identity, endpoint routing, capability availability, and UX affordances—not fork your entire logic tree. Feature flags can help, but only if you use them to manage rollout risk rather than to paper over inconsistent behaviour.
Finally, do not ignore performance. Clinicians notice latency instantly. If your embedded record view takes several seconds to load, it will be abandoned. Optimise the path that matters: parallelise safe calls where possible, keep payload processing efficient, and use short-lived caching for repeat views within a session. But always keep safety first: performance wins that risk stale or ambiguous information are rarely worth it in primary care.
Once the integration works technically, the real work begins: making it behave well in the messy reality of GP operations. This is where many promising projects stall, because the last mile is dominated by onboarding friction, local governance concerns, and workflow mismatches rather than code defects.
Information governance needs to be built into the product experience. Users should be able to understand what they are viewing, where it came from, and how current it is. If your product displays GP record content, you should make context explicit: whether the view is read-only, which organisation is the data source, and what the “as of” time is. When users cannot tell, they fill in the blanks—and in healthcare, assumptions create risk.
Workflow design is equally critical. A GP practice does not want “more software”; it wants fewer steps. If your integration forces users to break their flow, re-search for patients, or switch contexts repeatedly, adoption will stall even if the underlying data is valuable. The best integrations feel like they belong in the care pathway: they launch in the right context, pre-populate what they can, and return users to their task without friction.
There are also important human factors when integrating across EMIS and SystmOne estates. Different areas develop different habits around coding, summarising, medication management, and document handling. If your product assumes a single “ideal” record structure, it will perform unevenly. Instead, design your clinical interpretation layer to tolerate variation and present uncertainty honestly. For example, if a list is incomplete because of a filtering rule, tell the user rather than pretending it is authoritative.
Operational readiness should be treated as a continuous discipline, not a go-live checkbox. Over time you will encounter certificate renewals, endpoint changes, practice mergers, ODS code updates, network policy changes, and periods of degraded Spine connectivity. The integrations that survive are those with strong observability, clear runbooks, and a calm approach to incident response.
A sustainable optimisation programme usually focuses on a few high-leverage areas:
If you are aiming for long-term success in GP practice environments, treat every deployment as the beginning of a relationship. Practices need stability, predictable change management, and responsive support. Your release cadence, incident communications, and training materials become part of the “product” just as much as the API calls.
The prize, though, is worth it. High-quality GP Connect and FHIR integrations can unlock safer, more joined-up care: the right information in the right place at the right time, without forcing clinicians into brittle workarounds. For software teams, the most strategic mindset is to view interoperability as a platform capability—one that improves with every rollout, every edge case you tame, and every workflow you streamline.
When you build EMIS and SystmOne integrations with that platform mindset, GP Connect and FHIR stop being abstract standards and become practical tools: they help you deliver dependable clinical experiences that scale across the NHS, respect governance, and genuinely reduce workload in general practice.
What are the most common reasons GP Connect integrations fail during NHS onboarding?
Many GP Connect integrations fail not because of API logic, but due to gaps in operational readiness. Common causes include incorrect ODS code mappings, incomplete endpoint discovery for practices using EMIS Web or TPP SystmOne, and missing evidence around audit logging or data minimisation. Early alignment with assurance requirements and testing against real practice configurations significantly reduces delays.
How long does it typically take to deploy a GP Connect integration across multiple GP practices?
For products designed with scale in mind, technical integration can often be completed in weeks, but real-world rollout across practices usually takes longer. Timelines are influenced by local governance approvals, IM1 pairing status, practice onboarding capacity, and variations in system configuration. Teams that invest in repeatable onboarding processes and clear deployment documentation tend to scale much faster across regions.
Can GP Connect be used for near real-time clinical decision support?
GP Connect is suitable for contextual decision support, but it is not a real-time data feed. Data should be treated as a point-in-time snapshot retrieved at the moment of access. Safe implementations make this explicit to users, avoid background polling, and clearly label timestamps so clinicians understand when the GP record was last accessed via the NHS Spine.
What governance evidence is usually required for GP Connect record access?
Suppliers are typically expected to demonstrate purpose limitation, role-based access controls, detailed audit trails, and clear user-facing labelling of read-only data. Clinical safety documentation and data protection impact assessments are also commonly reviewed. Preparing this evidence early helps prevent late-stage blockers during NHS assurance or local approval.
Is GP Connect sufficient on its own for full primary care EHR integration?
GP Connect covers a defined set of standardised capabilities, but it does not replace all forms of integration. Some advanced workflows may still require complementary approaches, such as supplier-specific interfaces or messaging standards. Most successful products treat GP Connect as a core interoperability layer and design additional functionality around it only where there is a clear, justified need.
Is your team looking for help with GP Connect integration? Click the button below.
Get in touch