Written by Technical Team | Last updated 30.01.2026 | 13 minute read
Building a patient-facing health app in the UK is no longer just about a polished user journey and a secure backend. If your product needs to read from, write to, or transact against a person’s GP record, you are stepping into one of the most valuable—and most carefully governed—data environments in healthcare. Primary care electronic health record (EHR) systems sit at the centre of prescribing, problem lists, allergies, referrals, test results, and day-to-day clinical decision-making. For patients, they are also a source of truth: “What’s on my record?”, “What medication am I on?”, “Can I book an appointment?”, “Can I request a repeat prescription?”, “Why was I coded as having this condition?”
That demand is exactly why “primary care EHR integration” has become a defining capability for digital health vendors. But the reality is that integration is rarely a single API call or a one-off technical project. It’s an end-to-end discipline that blends interoperability standards, identity and access management, consent and permissions, information governance, clinical safety, operational support, and careful user experience design. Patient-facing apps amplify the challenge, because you are exposing clinical data directly to the public and must handle edge cases safely—unexpected results, sensitive record items, proxy access, safeguarding concerns, and local practice configuration differences.
This article explores how patient-facing apps can integrate with NHS primary care records responsibly and effectively, with a focus on authentication, consent, and record access. It also explains the practical difference between national access routes and supplier-specific routes, why “IM1” matters, and how to design an integration that is robust in the real world—not just in a test environment.
When people say “integrate with GP systems”, they often imagine a single national system. In practice, UK primary care is served by a handful of leading EHR platforms, each with its own product ecosystem, configuration options, and operational realities. EMIS Web and TPP SystmOne are widely deployed, while systems such as Cegedim Vision and newer cloud-native platforms such as Medicus have their own interface capabilities and partner models. From a patient-facing perspective, your goal is typically consistency: one app, one experience, and a predictable set of data and features—regardless of which GP system a practice uses.
The main architectural decision is whether your app will integrate through national interoperability routes, such as GP Connect and IM1 mechanisms, or through vendor-specific APIs and partner programmes (or a blend of both). National routes aim to provide a standardised approach, commonly using FHIR-based resources and nationally defined profiles. Vendor-specific routes may offer deeper capability in certain areas, but can create long-term complexity: different authentication patterns, different data models, different operational processes, and sometimes different commercial terms.
For patient-facing apps, integration commonly clusters around three capability areas:
Each of these introduces its own risk and governance considerations. Record access feels passive, but it can still lead to harm if sensitive information is displayed unexpectedly or misinterpreted. Transactional services can disrupt practice operations if requests flood in or booking rules aren’t respected. Messaging can introduce clinical safety and medico-legal complexities if expectations are unclear.
An additional reality in UK primary care is local variability. Even when a national standard exists, each GP practice can configure access and workflows differently. Some patients may have limited record access, some may have full access, and some may have none—often for legitimate reasons. Your app must be designed to handle “permission denied” not as an error state, but as a meaningful, explainable outcome that maintains patient trust.
Authentication is the doorway into patient-facing primary care integrations. It is also a common place where otherwise strong products stumble: confusing login journeys, mismatched expectations about identity proofing, and unclear boundaries between “who the user is” and “what they are allowed to do”.
For patient-facing apps, the dominant model is citizen identity: you need to know that the person using the app is the patient (or an authorised proxy), and you need that identity to be recognised by national NHS services. In most cases, that means integrating with a citizen identity provider and then obtaining access tokens that can be presented to downstream APIs.
In technical terms, many patient-facing integrations use OAuth 2.0 patterns. What matters practically is not the buzzwords, but the outcome: your app must acquire the right token for the right user, for the right scope, at the right time, and must protect that token like any other sensitive credential. It also needs to support token refresh, session handling, secure logout, and revocation scenarios.
It’s important to distinguish this from workforce identity, which is where NHS Smartcards and CIS2 come into play. CIS2 is designed primarily for health and care professionals accessing national clinical systems and patient information. If your product has a clinician-facing component (for example, a staff portal that supports onboarding a patient, managing consent, or assisting with record access), CIS2 may be relevant for that workforce workflow. But for a purely patient-facing app, CIS2 is usually not the main authentication mechanism.
The best patient-facing integrations treat authentication as part of product design, not just security plumbing. Your login journey should explain why identity verification is required, what the patient can expect to access after signing in, and what happens if the GP practice has restricted access. Done well, authentication becomes a trust-building moment rather than a barrier.
A robust authentication design for patient-facing GP access also needs to handle:
Finally, don’t underestimate the operational side of authentication. If token acquisition depends on specific configuration, onboarding steps, or environment constraints, you’ll want clear runbooks and monitoring. Many integration failures in live settings are not code bugs—they are certificate issues, misconfigured redirect URIs, missing firewall rules, or a misunderstood scope.
Consent in patient-facing apps is often misunderstood as a single checkbox: “I consent to share my data.” In primary care EHR integration, consent is more nuanced because access is shaped by patient choice, practice policy, national rules, and safeguarding considerations. Your app needs to communicate this clearly without overwhelming users, and your integration needs to respect the underlying permission model instead of trying to route around it.
A practical way to think about consent and permissions is to separate three questions:
Identity assurance answers this. If the user is the patient, great. If the user is a proxy (such as a parent, carer, or someone with legal authority), you must handle proxy access properly, including different rights and visibility rules.
Viewing medications is different from viewing consultation notes. Booking an appointment is different from requesting a repeat prescription. Your app should treat permissions as feature controls, enabling or disabling functionality based on what the downstream EHR and national services allow for that patient at that practice.
GP practices can restrict record visibility for legitimate reasons. They may also restrict certain services, and these restrictions can change over time. Your app must be resilient to changes and should not “cache” an assumption that a user will always have the same access.
Two integration design principles make a significant difference here. First, treat permissions as a dynamic state, not a one-time check. Second, design your UI so that restricted access is communicated calmly and helpfully, with clear next steps.
In patient-facing record access, sensitive content is a key safety challenge. Patients may see coded information that is clinically accurate but emotionally difficult or confusing. They may see references to suspected diagnoses, safeguarding notes, or third-party information. Even where a national API returns data in a controlled way, your app still has responsibility for presentation. A patient-friendly experience includes context, definitions, and safe signposting—without turning the app into a substitute for clinical advice.
Here are common consent and permissions scenarios your app should be ready to handle:
A strong integration does not treat these as edge cases. It treats them as standard pathways, each with a clear user journey and a traceable audit trail.
Practical consent and permission design checklist for patient-facing apps:
Once authentication and permissions are in place, the next question is what record data your app can access and how reliably it can do so across GP systems. Patient-facing record access commonly relies on standardised interfaces that return structured clinical information in FHIR format. In principle, this gives you a consistent data model for key parts of the GP record. In practice, “consistent” still requires careful engineering and thoughtful product decisions.
From a patient-facing perspective, record access usually needs to support a meaningful subset of the longitudinal record, such as:
In integration terms, you must define your minimum viable record scope early. Many products fail by trying to access “the whole record” without a clear plan for presentation, safety, and performance. Start with user value: what does a patient actually need to do or understand? Then map that to the available data resources and their constraints.
IM1 is often discussed as a route that helps suppliers integrate with GP clinical systems through a standard mechanism. For patient-facing apps, it’s best understood as part of a broader national integration landscape: a way of achieving consistent integration across principal GP systems, with standards that guide how APIs should behave. GP Connect is frequently central in this picture, especially for patient-facing record access and related services. In real deployments, the constraints matter as much as the capability. Patient-facing record access must be engineered for:
GP record queries can be heavy, especially if you request large time ranges or broad sets of resources. You’ll need to design your data retrieval strategy carefully: incremental fetches, caching where appropriate, pagination, and clear UI states while data loads.
Even with a standard interface, clinical data is shaped by years of coding practices. Patients may have duplicate items, old codes, or inconsistent descriptions. Your app needs sensible grouping, deduplication strategies, and careful wording.
Not everything that exists in the record should necessarily be displayed in the same way. Some items require sensitive handling; some may need additional context; and some may be restricted. Your integration must respect the upstream rules and ensure your downstream presentation doesn’t amplify risk.
Many patient-facing apps focus on read access first. If you plan to write data back—such as submitting structured questionnaires, updating demographics, or sending clinical messages—you must be even more rigorous about validation, auditability, and error handling. A write operation that silently fails or writes incorrect data can create direct clinical risk.
A useful approach is to treat record access as a product capability with a well-defined contract. Define exactly which resources you consume, how you transform them, and how you present them. Build a clear mapping layer that can evolve as standards and supplier behaviours change. And invest in monitoring early: you want to know when an API starts returning unexpected payloads before your users report it.
The strongest patient-facing apps use record access to build trust, not just features. They present information clearly, allow users to drill down when needed, and make it easy to spot what’s current versus historical. They also provide appropriate signposting: “If you have concerns about this information, contact your GP practice,” and “If this is urgent, call 111 or 999,” aligned to the product’s clinical safety approach.
Primary care EHR integration is never “done” at go-live. For patient-facing apps, the operational phase is where trust is won or lost: patients expect reliable access, practices expect predictable behaviour, and governance stakeholders expect ongoing compliance.
Compliance in NHS integration is not a single hurdle; it’s an ecosystem. Your integration needs to align with information governance expectations, security controls, clinical safety requirements, and interoperability standards. Even when you are using standard APIs, your product remains responsible for how it stores, processes, and displays data.
A practical implementation approach combines technical build with governance-by-design. That means involving the right stakeholders early—clinical safety officers, information governance leads, technical architects, and operational support—and ensuring decisions are documented in a way that can stand up to scrutiny during procurement and assurance.
Security and hosting are also integral. Patient-facing apps are typically internet-facing, which makes them more exposed than systems running solely on internal networks. You’ll need robust controls such as web application firewalls, strict IP and certificate management where relevant, secure secrets handling, and regular penetration testing. Integration endpoints should be treated as high-value targets because they represent access to clinical data.
From an operations perspective, long-term success depends on the “unsexy” elements: monitoring, alerting, incident response, and change management. National services and supplier systems evolve. Certificates expire. API versions change. Practices alter configuration. Your app must be resilient and your support team must be prepared.
Finally, build your integration roadmap with realism. Many teams start with record access, then expand into appointments and prescriptions, then explore messaging and write-back capabilities. Each step increases complexity and risk. If you treat each capability as a separate, well-governed product increment—rather than a sprawling “integrate everything” programme—you will move faster and with fewer surprises.
Patient-facing apps can genuinely improve access, understanding, and continuity of care. But in primary care, success is earned through careful integration, respectful handling of consent and permissions, and authentication journeys that protect users without creating friction. When these foundations are done well, interoperability stops being a technical feature and becomes a service quality: patients feel empowered, practices feel supported, and your product becomes a trusted part of the NHS digital landscape.
Is your team looking for help with primary care EHR integration? Click the button below.
Get in touch