Almost every patient portal project we scope arrives with the same assumption baked into the brief: that connecting to a GP clinical system is an integration task comparable to connecting to any other REST API. It isn't. EMIS Web and TPP SystmOne between them hold the primary care record for the overwhelming majority of patients in England, and neither supplier exposes that record through an open, self-service API that a third party can simply request access to and start building against. What blocks a patient portal project is rarely the software itself. It is the sequence of permissions, standards decisions and supplier assurance processes that have to be worked through before a single line of integration code has anything to talk to.
The two routes in, and why they are not interchangeable
There are, in practice, two distinct routes into a GP clinical system: GP Connect and IM1 pairing. GP Connect is a national, standardised set of FHIR-based capabilities — access record structured, appointment management, send document — built so that any accredited consumer can use them without a bespoke agreement with each individual practice or supplier. It is the right route whenever the capability a portal needs is one GP Connect already exposes, because it removes the need to negotiate separately with EMIS and TPP for every practice a portal wants to serve.
IM1 pairing is different. It is a direct interface agreement with a specific clinical system supplier, used when the data or the write-back permission a project needs falls outside what GP Connect currently covers. The two routes are not alternative paths to the same destination — they cover different, and only partially overlapping, sets of capability. A project brief that says "we'll use GP Connect" without first checking whether GP Connect actually exposes the specific read or write operation the portal needs is making an assumption that, if wrong, surfaces months into the build rather than during scoping.
We cover the general integration landscape — including where HL7 v2 sits alongside FHIR UK Core across a wider hospital estate — on our EHR and EPR integration page. For a portal specifically, the practical question during scoping is narrower: which of the specific data types and write-back scenarios this portal needs are covered by GP Connect today, and which require an IM1 negotiation with EMIS Web or SystmOne directly.
HL7 v2 does not disappear because FHIR exists
A second assumption we see regularly is that FHIR UK Core has effectively replaced HL7 v2 across the NHS estate, so a modern integration project can plan around FHIR alone. It hasn't, and it can't yet. FHIR UK Core is the standard for GP Connect and for a growing set of national and regional services, but a substantial amount of message traffic between hospital systems — admissions, discharge and transfer messages, orders and results moving between a PAS, a RIS-PACS pairing and a LIMS — still runs on HL7 v2, and will continue to for the foreseeable future because replacing that messaging layer is a separate, much larger modernisation project that most trusts have not undertaken.
For a patient portal, this matters most where the portal needs to surface hospital-originated data — an appointment outcome, a discharge summary, a result — rather than only GP-held data. If any part of the portal's data flow touches that hospital messaging layer, a FHIR-only integration design will simply not receive the messages it expects. The interface engine has to be built to handle both formats from the outset, converting HL7 v2 into a common internal model alongside FHIR UK Core resources, rather than treating HL7 v2 support as a later addition once the "modern" FHIR integration is working.
Patient matching is where projects quietly go wrong
Every one of these interfaces assumes the two systems on either side of it agree on which patient a message is about. That agreement cannot be assumed. NHS number is the correct primary identifier, verified where possible against the Personal Demographics Service, but a portal project has to design a documented fallback — matching on name, date of birth and address — for the records that arrive without a verified NHS number, and it has to log every automatic match and every match that fails, rather than resolving ambiguous cases silently. A portal that gets this wrong does not fail loudly; it fails by occasionally showing the wrong patient's data to the wrong patient, which is precisely the failure mode a clinical safety case exists to prevent.
Assurance timelines: the part that actually sets the schedule
The technical build for a well-scoped GP Connect or IM1 integration is rarely the longest item on a patient portal project plan. The assurance process is. Before a portal goes live against live patient data, it typically needs a clinical safety case addressing the hazards introduced by the integration — a mismatched patient record, a dropped message, an incorrect write-back — assessed under DCB0129 and DCB0160, alignment with the deploying organisation's Data Security and Protection Toolkit submission, and, separately, the specific supplier's own onboarding and technical assurance process for either GP Connect accreditation or IM1 pairing. None of these run in parallel by default, and none of them can be meaningfully shortened by adding developers to the project. A realistic project plan treats assurance as a critical path item from week one, not as a formality tackled after the build is functionally complete.
We set out indicative cost bands for this kind of programme, including how the assurance timeline typically maps onto delivery phases, in our patient portal development cost guide. The short version: a single, well-defined GP Connect interface is a materially smaller undertaking than an IM1-based integration covering several data types across both EMIS Web and SystmOne, and the assurance overhead scales with the number of organisations and suppliers involved, not with the size of the codebase.
What to build while you wait
Because assurance and supplier onboarding run on a timeline a project team cannot compress, the practical question is what to build in parallel so the wait is not dead time. Four things are usually genuinely independent of the final interface being live:
- The patient matching and PDS verification service, built and tested against representative — anonymised or synthetic — data, so it is ready to consume real messages the moment the interface goes live rather than being designed after the fact.
- The portal's own data model and consent framework, including how a patient's access to their own record is authenticated and how consent for any write-back scenario is captured and stored, none of which depends on the specific wire format the clinical system eventually returns.
- The clinical safety case documentation, drafted against the intended architecture so that DCB0129 and DCB0160 assessment can start reviewing a substantially complete document rather than starting from nothing once the technical build finishes.
- Everything that does not depend on the GP record at all — appointment booking against a scheduling system the practice already controls directly, secure messaging, and administrative self-service functions — sequenced first in the delivery plan so the portal has a usable version before the clinical data interface clears assurance.
This sequencing is exactly what a proper discovery and scoping sprint is for: identifying, before a contract is signed, which parts of the build are gated by external assurance and which are not, so the delivery plan reflects that reality rather than assuming every workstream can run at the same pace.
What this means for scoping the project honestly
A patient portal brief that names "EMIS Web and SystmOne integration" as a single line item is underspecified in a way that will surface as scope creep later. The honest version of that line item names which specific capabilities are needed — read-only access to a defined set of record types, or write-back into a specific field — checks which of those GP Connect already covers, and treats anything outside that as an IM1 negotiation with its own supplier-specific timeline. Our patient portal development work starts from that breakdown, because a project plan built on an assumed capability that turns out not to exist costs far more to fix mid-build than it does to identify during scoping.