Written by Technical Team | Last updated 15.06.2026 | 24 minute read
Interoperability in primary care is often described as a technical problem: connect to an application programming interface, exchange a message and move data between two systems. For digital health innovators working with GP practices in England, however, that description is dangerously incomplete. The real challenge is to build software that can participate safely and reliably in a complex clinical, operational and regulatory environment while working across the dominant GP record systems, particularly EMIS Web and TPP SystmOne.
A product may have an elegant interface, a persuasive business case and enthusiastic clinical advocates, yet still fail because it cannot fit into the everyday machinery of general practice. It may require staff to re-enter information, interrupt established workflows, reconcile inconsistent records or switch repeatedly between applications. It may retrieve data successfully but lose the clinical context needed to interpret it. It may work in one practice and become impractical when deployed across a Primary Care Network whose member practices use different systems, templates, coding conventions and local processes.
Successful interoperability therefore involves much more than connectivity. It requires technical compatibility, semantic consistency, dependable identity matching, appropriate access control, safe workflow integration and a credible operating model. It must also accommodate the fact that a PCN is not a single organisation with a single database. It is a network of independent practices collaborating across shared services, staff and population-health objectives, often alongside community providers, pharmacies, acute trusts, local authorities and voluntary-sector partners.
The most valuable interoperable products do not simply make more data available. They reduce the effort required to turn information into safe, coordinated action. That distinction should shape every architectural, product and commercial decision made by innovators entering the English primary care market.
The first question for an interoperability project should not be, “Which EMIS or SystmOne API can we use?” It should be, “What clinical or administrative outcome are we trying to improve, and what information must move in order to achieve it?” Beginning with an available interface can encourage teams to build around the data they can obtain rather than the service problem they need to solve.
Consider a PCN developing a proactive care service for people with frailty. A superficial integration requirement might be to retrieve a list of patients with a frailty code. The real workflow is more complicated. The service may need to identify eligible patients across several practices, distinguish clinically meaningful frailty from historic or provisional coding, exclude people who have moved or died, display recent consultations and medicines, record the outcome of a multidisciplinary review, assign follow-up actions and make the relevant information visible to each patient’s registered practice. Different parts of this journey may require different technical routes, permissions and safety controls.
The same principle applies to online consultation, care navigation, long-term-condition management, social prescribing, medicines optimisation and enhanced-access services. A care-navigation platform does not merely need appointment availability. It needs enough information to offer an appropriate pathway, handle urgency, respect practice-specific rules, protect confidentiality and ensure that the resulting action is visible to the right team. A clinical decision-support tool does not merely need coded observations. It must establish whether values are current, comparable, complete and associated with the correct patient and clinical episode.
Mapping the workflow should expose the moments at which information is created, read, interpreted, changed or handed over. It should identify who is accountable at each point, what happens when a system is unavailable and which application remains the authoritative record. Innovators should document not only the intended “happy path” but also the exceptions that frequently occur in real practices: temporary residents, patients without a verified NHS number, duplicate records, proxy users, sensitive information, incomplete registrations, staff working across multiple organisations and records containing conflicting data.
This exercise often reveals that a product requires several different types of interoperability. Transactional integration supports activities such as reading a patient record during a consultation, booking an appointment or writing information back. Bulk extraction may support population-health management, service planning or cohort identification. Messaging may be appropriate for sending a document or structured clinical communication. Contextual integration may allow a user to launch a product from within the principal clinical system with the correct patient already selected. Authentication integration may be needed to establish the user’s identity, organisation, role and legitimate relationship with the patient.
It is equally important to decide which data should not be copied. Replicating large sections of a GP record into a separate platform creates synchronisation, provenance, security and clinical-safety obligations. A copied record can become misleading as soon as the source changes. In many use cases, viewing current information at the point of need is safer than maintaining a secondary clinical repository. Where data must be persisted, the product should retain its source, retrieval time, coding system, author, status and relevant version information.
A useful design discipline is to write a one-sentence interoperability purpose for every exchange. For example: “Retrieve the patient’s current medication and allergy information so that an authorised pharmacist can conduct a structured review,” or “Write the outcome of a PCN respiratory review into the registered practice record so that it forms part of ongoing care.” This forces the team to define the care purpose, data scope, user and destination. It also makes subsequent discussions about legal basis, permissions, assurance and testing far more concrete.
The best architecture may therefore be a composition of interfaces rather than a single integration. A product could use a national service to verify demographics, GP Connect to retrieve selected record information, a supplier-specific interface to perform a workflow that national APIs do not yet support, and a messaging mechanism to communicate an outcome. The architecture should be shaped by the clinical journey, not by a desire to force every requirement through one technical channel.
Key takeaway: Successful primary care interoperability is not simply about connecting an API. Digital health software for Primary Care Networks must combine NHS GP system integration, including EMIS Web and TPP SystmOne, with reliable patient matching, consistent clinical coding, secure access controls and safe workflow integration. Start with the care pathway, then select the GP Connect, IM1, national or supplier-specific interfaces needed to support it.
EMIS Web and TPP SystmOne are central to the reality of building for English general practice. Although national standards are creating more consistent routes to information, many practical primary care workflows continue to depend on supplier-specific capabilities. A product intended for PCN-wide deployment must therefore acknowledge both systems early, rather than completing an EMIS integration and treating SystmOne as a later adaptation, or vice versa.
The objective should be one coherent product with a carefully isolated integration layer. Business rules, clinical logic, user experience and workflow orchestration should not be distributed throughout supplier-specific code. Instead, the product should define an internal contract describing the capabilities it needs: find a patient, retrieve active medications, obtain allergies, read coded observations, search appointments, create a task, add a consultation entry or attach a document. Separate adapters can then translate those intentions into the mechanisms supported by EMIS, TPP or national services.
This capability-oriented approach prevents the underlying GP system from becoming the product’s domain model. Without it, teams are tempted to expose EMIS concepts directly in their application, then reproduce the same screens and rules for SystmOne. The result is duplicated development, inconsistent behaviour and a growing volume of conditional logic. A well-designed integration boundary accepts that the two systems may represent or permit an activity differently while protecting the rest of the product from those differences.
Developers must also avoid assuming that similarly named functions have identical clinical meaning. An “active medication”, “consultation”, “task”, “appointment slot” or “problem” may have different fields, states, histories and user expectations across systems. Even where both suppliers support a function, the available granularity, update behaviour, coding options or audit information may differ. The product’s internal model should preserve meaningful distinctions rather than flattening them into the lowest common denominator.
A lowest-common-denominator strategy initially appears efficient, but it can make the product too limited to deliver value. The better pattern is a common core with explicitly managed capability variation. Every practice connection should have a machine-readable capability profile describing which operations are supported, which versions are enabled, what configuration is required and what limitations apply. The user interface can then adapt safely. It might allow structured write-back where this is assured, offer document-based communication where it is not, or disable a feature rather than failing after a clinician has completed the work.
IM1 pairing remains an important route for integrating third-party systems with the principal GP systems. It encompasses interface mechanisms that can support reading patient information, entering information and extracting data in bulk. The process involves more than obtaining technical documentation: suppliers must satisfy prerequisites, work through the applicable assurance and commercial arrangements, integrate with the relevant provider interfaces and establish pairing with participating practices. Because EMIS and TPP expose their own interfaces, “supporting IM1” does not mean writing one implementation that works identically with both.
EMIS integration may involve capabilities such as its Partner API or other approved interface arrangements, depending on the use case and commercial model. TPP SystmOne integration similarly requires implementation against the mechanisms available for SystmOne. Innovators should obtain authoritative, current documentation and commercial terms directly through the applicable onboarding routes. Designing from historic integration guides, unverified examples or assumptions formed from one customer deployment is a common source of delay.
The integration abstraction should nevertheless remain practical rather than theoretical. Excessive abstraction can hide clinically important supplier behaviour. Engineers need observability at the adapter level so that support teams can determine whether a problem arose in the product, the supplier interface, the practice’s configuration, user permissions or the source record itself. Logs should record correlation identifiers, operation types, response categories, timing and relevant technical metadata without unnecessarily exposing patient information.
A robust internal architecture could separate five concerns:
This pattern is particularly valuable for PCNs because deployment conditions vary by practice. One member practice may use EMIS Web and another SystmOne. Two practices using the same supplier may have different modules, organisational settings, role configurations or local templates. A PCN service may also be hosted by one practice while treating patients registered elsewhere. The product must understand the distinction between the user’s employing organisation, current working context, host service, patient’s registered practice and organisation responsible for the authoritative record.
Write-back deserves special caution. Reading data is not automatically low risk, but writing creates additional consequences because the product can alter the record on which future care depends. Supplier-specific APIs may differ in how they create coded entries, free text, documents, tasks or consultations. An integration must preserve author, date, clinical context and provenance while avoiding duplicate entries when a request is retried. Idempotency controls are essential: if a network interruption occurs after the receiving system has accepted an update, the product must not create the same clinical entry again simply because it did not receive a confirmation.
The system should distinguish between information that is proposed, reviewed, authorised and committed. For example, an automated tool might identify a possible code or draft a consultation summary, but a clinician may need to confirm it before it becomes part of the record. The product should make that boundary visible. Quietly converting suggestions into definitive record entries risks contaminating the clinical record and reducing trust.
Testing must cover each supplier independently and then test PCN workflows across mixed environments. A successful demonstration against one development instance is insufficient. Teams should test realistic record sizes, historic codes, inactive medicines, unusual demographic data, concurrent updates, revoked permissions, session expiry, system downtime and partial failure. They should also verify what users see in EMIS or SystmOne after a write, not merely whether an API returned a success response.
Supplier integration is important, but it should not be the only foundation. National services and standards provide a route towards more portable, scalable products. GP Connect is especially significant because it gives authorised systems a more consistent way to access information held in the patient’s registered GP record. Depending on the approved use case and available capability, this can include rendered views of the record or structured, coded information that a consuming system can process.
GP Connect Access Record: HTML is useful when a professional needs to view record information in a human-readable form. It can reduce the need to reproduce complex clinical presentation logic, but the content remains primarily for viewing rather than computation. Access Record: Structured is more suitable where the product must interpret selected coded information, such as medications, allergies, investigations or other supported clinical sections. Innovators should check the current production status, permitted care settings and supported datasets rather than assuming the entire GP record is available through a universal FHIR interface.
GP Connect should also not be treated as a generic mechanism for unrestricted write-back. Update Record currently supports defined workflows and message types rather than arbitrary alteration of a GP record by any application. A product whose core proposition depends on creating structured entries, tasks or appointments must establish whether the required operation is supported nationally or requires a supplier-specific route. Roadmaps are valuable context, but products should be commercially and clinically viable using capabilities that are actually available and approved for their use case.
The Personal Demographics Service is another important component. Accurate patient matching cannot depend on a user typing a name and date of birth and selecting the first plausible result. The NHS number should be the principal identifier where available and verified, supported by appropriate demographic checks and traceable matching logic. Systems must still handle legitimate exceptions, but uncertainty should be exposed rather than concealed. A false positive can disclose information about the wrong person or add clinical content to the wrong record; a false negative can fragment care.
Authentication and authorisation must be designed as separate concerns. Authentication establishes who the user is. Authorisation determines what that user may do in a particular organisation, role and context. NHS Care Identity Service 2 can provide secure authentication for health and care professionals and supports modern authentication options alongside established smartcard-based arrangements. Integration with an identity service does not, by itself, prove that every authenticated user should access every patient or function. The application must enforce role-based permissions, organisational scope, purpose of use and other relevant policy.
The application should also maintain a complete, intelligible audit trail. It should answer who accessed which patient, from which organisation, for what function, when, and what information was created or changed. Audit records should be useful to clinical safety officers, information-governance teams and operational support staff, not merely produced as opaque technical logs. Where the product makes an automated recommendation, the audit should include the input data and relevant rule or model version so that the decision can later be understood.
Semantic interoperability is as important as technical transport. A FHIR resource that carries an ambiguous local code is syntactically interoperable but clinically unreliable. SNOMED CT provides the standard clinical terminology used in electronic health records across the NHS in England, while the dictionary of medicines and devices provides the standard identifiers and descriptions used when exchanging medicines information. Products should consume supported terminology releases, preserve concept identifiers and manage inactive or replaced concepts rather than storing only display text.
Units and reference ranges also require rigorous handling. A blood result or physiological measurement is not safely interpretable without its unit, date, status and, in many cases, reference information. Systems should not silently assume that values retrieved from different sources use the same unit. Nor should they transform values without retaining the original representation and documenting the conversion. Similar caution applies to dates, laterality, negation, certainty and the distinction between a suspected, historic and active condition.
Developers should define a canonical data model that is clinically meaningful but does not pretend that every source maps perfectly. Mappings should have explicit confidence and loss characteristics. When a supplier-specific field has no exact equivalent, preserve it as an extension or source attribute rather than forcing it into an inaccurate category. When the same clinical concept is represented by several historic codes, terminology services and carefully governed value sets can support consistent cohorting without rewriting the underlying record.
A dependable national-services strategy should normally address:
Standards must nevertheless serve the workflow rather than become an end in themselves. FHIR improves consistency, but implementing FHIR does not guarantee a usable product. Teams still need to interpret profiles, cardinalities, extensions, value sets, search constraints, authentication patterns and error responses. They must version their integrations deliberately and test compatibility when an API, terminology release or supplier implementation changes.
Clinical safety should begin during discovery, not shortly before procurement. DCB0129 applies to organisations that manufacture health IT systems, while deploying healthcare organisations have responsibilities under DCB0160. For the supplier, compliance involves a structured clinical-safety process led by an appropriately qualified Clinical Safety Officer, supported by a hazard log, safety case and clinical-safety documentation proportionate to the product and its intended use.
The hazard analysis should examine the complete sociotechnical system. A technically correct API call can still contribute to harm if users misunderstand the result, important information is omitted, alerts are excessive, a task goes to an unmonitored queue or staff assume that write-back succeeded when it did not. Hazards should be linked to concrete controls, test evidence and post-deployment monitoring. “User training” should not become the default mitigation for avoidable design weaknesses.
Interoperability creates characteristic hazards that deserve explicit treatment. These include displaying stale information without its retrieval time; losing provenance during transformation; associating information with the wrong patient; omitting qualifiers from a clinical code; duplicating a record entry after a retry; creating an action in the wrong practice; failing to communicate that only part of the record was available; and presenting a supplier outage as an empty clinical history. An empty result, a failed query and a genuine absence of information are three different clinical states and must look different to the user.
Information governance should likewise be embedded in product architecture. Teams need a clear account of the organisations acting as controllers, joint controllers or processors for each workflow. They should establish the lawful basis for processing, the role of direct care, any secondary-use requirements, retention periods, data-sharing arrangements, sub-processors and international transfers. PCN working arrangements can make these questions more complicated because staff, services and systems may span several legal entities.
Data minimisation should be visible in both the user experience and the technical design. A receptionist conducting care navigation may need contact details and limited contextual information but not unrestricted access to the full clinical record. A population-health analyst may need pseudonymised cohort data rather than identifiable records. A clinician carrying out a medication review may need richer information but only for the patient being treated. The product should retrieve and display the minimum data needed for each role and task rather than regarding broad record access as a convenience.
The Digital Technology Assessment Criteria provide an important framework across clinical safety, data protection, technical security, interoperability, usability and accessibility. Meeting DTAC expectations is not equivalent to obtaining a permanent certificate that removes the need for local assurance. Evidence must remain current, accurate and aligned with the deployed product. A material change to hosting, functionality, artificial-intelligence components, data flows or integrations may require documents and risk assessments to be revisited.
Security controls should be proportionate to the sensitivity and operational importance of the service. Encryption in transit and at rest, secure software-development practices, vulnerability management, penetration testing, secrets management, strong administrative access, monitoring, backup and incident response are baseline considerations. Multi-tenant products must enforce robust isolation between organisations. Support tools should not permit unrestricted access to patient data, and privileged activity should be controlled and audited.
Resilience is a clinical property as well as an engineering concern. A PCN may come to depend on a digital triage or care-coordination platform during core hours. The product therefore needs clearly stated service objectives, health monitoring, capacity planning, graceful degradation and tested recovery procedures. It should define what users can still do when EMIS, SystmOne, a national API or the product itself is unavailable. Queueing a transaction may be appropriate in one workflow and unsafe in another, particularly when information could change before the delayed update is committed.
Error messages should tell users what happened and what action is safe. “Integration failed” is rarely sufficient. A clinician may need to know whether the record was not found, access was denied, data was unavailable, an update was rejected or the outcome is uncertain. Where the result is uncertain, the product should prevent casual resubmission until it has checked whether the original transaction completed. Support teams should have diagnostic detail without exposing sensitive data in screenshots or general-purpose logs.
Operational responsibility must be agreed across the supplier, practice, PCN, ICB support arrangements and GP system provider. When an integration fails, frontline staff should not be left to discover which organisation owns the problem. A support model needs clear escalation paths, severity definitions, contact arrangements and ownership for configuration, access permissions, supplier pairing and incident communication.
Configuration management is especially important at PCN scale. Practice codes, organisation identifiers, appointment books, user roles, clinical templates, task recipients and service locations can change. Configuration should be validated, versioned and auditable. High-risk changes may require dual approval or testing before activation. Products should avoid embedding practice-specific assumptions in code or relying on a single knowledgeable staff member to maintain an undocumented set-up.
Deployment should be gradual enough to detect workflow and safety problems but structured enough to produce meaningful evidence. A pilot with one unusually enthusiastic practice may not reveal the challenges of a mixed-system PCN. A stronger approach tests representative practices, including both EMIS and SystmOne sites, different list sizes, varying digital maturity and realistic shared-staff arrangements. Measures should include not only usage but also time saved, duplicate work, failed transactions, unresolved tasks, patient experience, safety events and the effect on continuity of care.
Interoperability has commercial consequences. Every practice-specific workaround increases onboarding cost and weakens the economics of scaling. Innovators should therefore treat implementation effort as a product metric. Time to first safe transaction, number of local configuration steps, support contacts per deployment and proportion of onboarding that requires engineering intervention are as important as conventional software-performance measures.
The buying environment is also distributed. A PCN may champion the product, but practices often retain responsibilities for their records and local systems. An ICB may provide funding, assurance or technical support. A federation may employ shared staff or operate the service. The principal clinical-system supplier controls relevant interfaces, while NHS England controls access to national services. A credible go-to-market plan must identify the decision-maker, budget holder, data-controller relationships, deployment authority and people responsible for everyday operation.
Innovators should resist the temptation to describe interoperability as “seamless” before they understand the implementation model. Integration may require practice pairing, supplier approvals, user-role changes, local data-sharing decisions, clinical-safety review and testing. Customers are more likely to trust a supplier that provides a precise readiness checklist than one that implies connection will be instantaneous.
A practical onboarding pack could include:
The product should produce evidence of value at network level without obscuring variation between practices. A PCN dashboard might show access, demand, pathway outcomes or care-gap closure across the network, but it should also reveal where data quality, configuration or adoption differ. Aggregating everything into one headline figure can hide a practice whose integration is failing or a patient group that is being excluded.
Data-quality variation should be treated as an expected operating condition. Practices may record equivalent concepts using different SNOMED CT codes, templates or historical conventions. Some records will contain free text where structured data would be preferable. Cohort definitions should be transparent, versioned and clinically governed. Users should be able to understand why a patient was included or excluded, and the product should quantify uncertainty rather than presenting every query result as definitive.
This is particularly important for population-health management. A technically correct search can still produce a clinically misleading cohort when codes are incomplete, medication data are historic or measurements are missing. The product should combine coded logic with sensible temporal rules, exclusion criteria and validation. It should also create a feedback loop: when care teams identify missing or incorrect information, there should be an appropriate process to improve the source record rather than silently correcting only the secondary system.
Patient-facing interoperability requires further thought. Patients increasingly expect to use the NHS App and other digital services to view information, request care, manage prescriptions and interact with practices. A new product should avoid creating an unnecessary standalone account or duplicating a pathway that already has a national entry point. Where a separate experience is justified, identity, proxy access, accessibility, language, assisted-digital support and continuity between online and offline routes must be designed deliberately.
Digital inclusion is not achieved by retaining a telephone number as an afterthought. Interoperable workflows should allow staff to act on behalf of patients through legitimate assisted channels without creating parallel, lower-quality records. A patient who cannot use an app should still benefit from coordinated information and should not have to repeat their story because the digital pathway and practice workflow are disconnected.
Artificial intelligence adds another layer to the problem. An AI tool integrated with the GP record may summarise consultations, suggest coding, prioritise demand or identify risk. Its safety depends heavily on the quality, completeness and provenance of the information supplied to it. The system must distinguish generated text from verified clinical fact, communicate uncertainty and preserve human accountability. Model outputs should not become part of the authoritative record without an appropriate review step and clear attribution.
AI also makes observability more important. Suppliers should be able to trace which data informed an output, which model and prompt configuration were used, what the user saw and what action was taken. Changes to a model can alter clinical behaviour even when the surrounding interface remains unchanged. Model updates therefore need controlled release, evaluation and clinical-safety consideration rather than being treated as an invisible infrastructure upgrade.
The long-term goal should be to make the product progressively less dependent on supplier-specific behaviour without waiting for a perfectly standardised future. National APIs and standards should be preferred where they meet the need, while adapters should contain the supplier-specific capabilities still required today. This creates an architecture that can evolve as GP Connect and other national services expand, or as additional foundation-system suppliers enter the market.
Procurement and partnership conversations should examine exit as well as entry. Practices and PCNs need to know how data can be exported, how retained copies will be deleted, what happens to queued transactions and how the service can be withdrawn without losing clinically relevant information. Interoperability includes the ability to stop using a product safely. A system that can receive data but cannot return or dispose of it responsibly creates a new form of lock-in.
The strongest digital health companies will regard EMIS and SystmOne integration as necessary infrastructure rather than their unique value. APIs can be replicated; deep understanding of primary care is harder to copy. Defensible value comes from fitting into clinical work, reducing cognitive and administrative burden, handling exceptions safely, supporting mixed-system networks and producing evidence of improved care.
Building interoperable software for Primary Care Networks is therefore an exercise in disciplined translation. Innovators must translate between technical standards and clinical meaning, between national strategy and local practice, between two dominant GP systems and one coherent product, and between access to data and responsibility for what happens next.
The measure of success is not the number of integrations listed on a sales page. It is whether a professional can care for a patient across organisational boundaries with less duplication, fewer gaps and greater confidence. Software that achieves that will not feel like an additional digital layer imposed on general practice. It will become part of the dependable infrastructure through which modern primary care is delivered.
Is your team looking for help with bespoke software development? Click the button below.
Get in touch