Written by Technical Team | Last updated 30.09.2025 | 12 minute read
NHS App web integration allows a patient-facing web service to appear inside the NHS App as if it were part of the native experience. Rather than building a fully native module, your team hosts a secure, responsive website that is opened within the NHS App’s embedded browser (“webview”). Done well, the transition feels seamless: the patient taps a tile or link in the NHS App and lands directly in your service already recognised, already authenticated, and without jarring differences in design or behaviour. This pattern makes integration faster to deliver and easier to evolve because you continue to ship and deploy your own web application, while the NHS App provides the entry point and a small JavaScript interface for essential interactions.
For commissioners and suppliers, the value is twofold. First, you gain national reach with a familiar entry point and a large, growing user base that already trusts the NHS App. Second, you avoid duplicating identity, accessibility, and distribution efforts across two platforms. Patients benefit from a coherent digital front door: one app on the home screen, one login, one place to find messages, appointments and local services. For your product team, the web integration route concentrates your effort where you create the most value—your own service—while conforming to the safety, accessibility and information governance expectations that come with being part of the NHS ecosystem.
Before you write a single line of code, confirm that your service is a fit for the integration pathway. The NHS App surfaces national and locally commissioned services that are free at the point of use and demonstrably benefit patients in England. If you are a supplier, ensure you have a commissioning route—such as a trust, integrated care board (ICB) or national programme—so there is a clear basis for onboarding and continued operation. If you are a provider organisation seeking to integrate a local service, check that your contracts, clinical governance and data protection arrangements cover the scope of what you plan to expose to patients via the app.
Identity is the bedrock. You will need NHS login (OpenID Connect/OAuth 2.0) to identify users reliably and to give them single sign-on from the NHS App into your web application. This is more than a technical checkbox; it drives your account model, consent flows, and error handling. Many teams underestimate the time needed to align their service with NHS login’s assurance levels, claims and recovery pathways. Plan early for how you will map identity to patient records, what you will display before the patient has fully proven their identity, and how you will deal with edge cases such as unverified accounts, expired sessions, or mismatches between account details and clinical systems.
Compliance is not negotiable. Your service must meet accessibility standards (for example, WCAG 2.2 AA), follow clinical risk management processes, and demonstrate robust information governance. In practice, that means you will show evidence of a clinical safety case with identified hazards and mitigations, complete an information governance self-assessment (commonly via the Data Security and Protection Toolkit), and maintain a security posture appropriate to handling personal and health data. Even if your application does not directly read from NHS clinical systems, consider the broader ecosystem: data minimisation, consent and transparency still apply, and patients should be able to understand what is shared, with whom, and why.
You will also encounter onboarding artefacts and agreements that formalise your responsibilities. Expect to complete a supplier conformance pack (often referred to as a SCAL or equivalent), take part in assurance reviews, and sign a connection agreement that sets expectations for incident handling, service availability, change management and reporting. These are not bureaucratic niceties; they are the guardrails that let the NHS App host a diverse range of services safely and predictably. Teams that engage early with governance usually progress faster because they plan their documentation and testing alongside their build.
To judge how ready you are, it helps to inspect your current product through the lens of the NHS App. Ask whether your journeys will still make sense in a mobile webview with the NHS App’s own header and navigation framing your content. Look closely at anything that triggers native capabilities such as file downloads, camera access or deep linking out to another app, because those behaviours can differ inside a webview. If your service relies heavily on browser-specific features, confirm that they work reliably within a mobile app’s embedded browser on both iOS and Android.
A quick readiness snapshot:
Finally, keep in mind that integration is a relationship, not a one-off delivery. The NHS App continues to evolve. Webviews are periodically updated by Apple and Google. Accessibility guidance tightens. National priorities shift. What you sign up to is a commitment to keep pace, monitor your service in production, and work with the NHS App team to make improvements without destabilising the patient experience.
A reliable integration follows a repeatable blueprint, even though details will vary by use case and commissioning context. Start by expressing your interest and establishing fit. This typically involves a discovery conversation where you explain your service, your commissioning route, and how the integration will improve patient outcomes or reduce administrative burden. Treat this as your opportunity to align on the problem you are solving, the metrics that matter, and any constraints that could shape scope or timeline.
Once the intent is confirmed, you will assemble a solution design with the NHS App team. This is a working document that maps the end-to-end flow: where and how the patient launches your service from the NHS App; what identity claims you need and how you validate them; the states your UI must handle; and the error and recovery paths. The most useful designs are concrete: they include screenshots or wireframes; document the “jump-off” URL pattern and query parameters; describe cache, cookie and session strategies; and specify the content security policy. While you’re here, decide the hosting regions and failover approach, how you will tag events for analytics, and the monitoring you will use to detect and triage incidents.
The build phase is where you will adapt your web application to run well inside a mobile webview. At minimum, you will adopt a mobile-first layout, remove or hide any competing header and footer chrome, and ensure back navigation behaves predictably with the NHS App’s own controls. Many teams add a small environment-detection layer—checking a custom user agent or calling a “is this the NHS App?” JavaScript snippet—to toggle UI and feature flags. You will probably introduce a new authentication entry point that accepts the hand-off from the NHS App, validates the tokens or assertions you receive, and creates a session in your service without asking the patient to sign in again. Do not forget state that persists across screens: cookie settings, SameSite behaviour and secure flags matter in a webview.
Formal testing and assurance run in parallel with development. Expect to use a sandbox or “sandpit” environment for early end-to-end checks, then a controlled assurance environment that mirrors production more closely. You will demonstrate happy-path journeys, error and timeout handling, and accessibility. A common exercise is an incident rehearsal: walking through how you would detect, communicate and resolve a realistic failure—say, your identity provider is unavailable or your content delivery network throttles requests. At each stage, keep your documentation in lockstep: clinical safety hazards updated, mitigations verified, and operational runbooks refined.
Go-live is staged because safety and trust trump speed. The first release is usually a limited rollout to a small population or a defined geography, with analytics and error rates watched closely. You will fix what you learn, then scale. After full release, the relationship continues through monthly or quarterly reporting, periodic assurance reviews, and a change management process that surfaces the impact of even seemingly small UI tweaks. Bake that cadence into your product development rhythm; forward-plan major changes so that you have time to align on user impact and testing.
Key milestones and artefacts worth planning from day one:
If you treat the blueprint as iterative rather than linear, you will spot risks earlier. For example, build a thin vertical slice that exercises the hand-off from the NHS App through to your own data backend, then harden each segment. Involve product, design, clinical safety and operations in every review so that no single domain becomes a late-stage blocker. Keep decisions lightweight but well-recorded: why a particular claim is needed, why a timeout is set the way it is, why a piece of UI was simplified. Those notes will save you time in assurance and future audits.
At the heart of the integration is the identity bridge. The NHS App launches your service at a dedicated entry endpoint (“jump-off URL”), typically passing context that lets you identify the patient and establish a session without additional prompts. Your backend must treat this entry carefully: validate signatures, confirm intended audiences, check expiry and issuer, and then translate upstream identity into your own application session. Resist the temptation to mirror all upstream tokens wholesale into the browser. Instead, create a short-lived, least-privilege session that your app can refresh silently when the NHS App remains open, and which you revoke quickly if the patient signs out or the app is backgrounded for a long period.
Silent re-authentication matters because mobile usage is bursty. People switch apps, answer calls, lock screens, move between networks. Your strategy should anticipate that the webview may be suspended and resumed, and that cookies can be treated slightly differently inside an embedded browser. Test SameSite and Secure attributes, partitioned cookies on newer platforms, and the impact of private browsing or tracking prevention settings. Design your session lifetime with these realities in mind: long enough to avoid constant prompts, short enough to minimise risk. Where you need to extend the session, do it via back-channel checks rather than front-channel redirects that can break in a webview.
User experience depends on predictable navigation. Inside the NHS App, the native container owns the top-level navigation and back behaviour. Your app should avoid duplicating top bars or adding elements that look like platform controls. If you need to send the patient “home” to the NHS App, or open a document using the host’s download manager, rely on the lightweight JavaScript interface provided for web integrations. Treat that interface as a contract that can evolve: load it from its canonical location, avoid bundling it into your main JavaScript bundle, and guard your code if the interface is not present (so your site still works in a normal browser for testing and support).
Security controls deserve special attention. Enforce HTTPS everywhere, deploy modern TLS, and set a tight content security policy that whitelists only the origins you truly need. Review how you handle personally identifiable information in logs and analytics. In mobile contexts, device identifiers are sensitive; capture the minimal telemetry required to operate safely. If you render documents or images containing clinical information, ensure they are not cached unnecessarily by the browser, and consider time-limited URLs. For downloads, avoid assumptions about the presence of a traditional “save” dialogue; use the host-provided pathways when available so patients can access files reliably.
Finally, design for resilience and observability. Webviews can fail in ways that are hard to reproduce on desktop. Add health checks and feature flags so you can degrade gracefully—perhaps hiding an advanced feature for a subset of devices until a fix is deployed. Instrument your application with dashboards that expose launch success rates, session establishment times, error distributions, and performance budgets. Tie those metrics to your incident triggers and on-call rotas. When you can see issues quickly and react predictably, you maintain trust with the NHS App team and, more importantly, with patients who expect the service to work the first time they need it.
Testing for a web integration is not a tick-box exercise; it is how you prove the experience is safe, accessible and reliable for a diverse audience. Build a device matrix that spans current iOS and Android versions and a few older ones, varying screen sizes and network conditions. Pair automated checks with hands-on sessions where product, designers, clinical safety and support staff walk through scenarios as real patients would. Accessibility needs the same seriousness: use tooling to catch regressions, but also schedule manual testing with screen readers and voice control. Each defect you prevent before release saves hours of support and a dent to patient confidence.
Assurance formalises what you have tested and what you will do when things go wrong. Document your hazards and mitigations in your clinical safety case; articulate your data flows and minimisation decisions; show how you meet accessibility criteria and where you have an improvement backlog. When you rehearse an incident, include comms as part of the drill: who talks to whom, what you tell patients in the UI, what the NHS App team needs to know, and when you declare recovery. The confidence you build here is what unlocks staged rollout and, ultimately, full availability.
Once live, treat your integration as a product within a product. Watch key metrics—launch success, error rates, task completion, time to first meaningful paint—and actively look for friction. The best teams create a quarterly rhythm: they gather insights from analytics and service desk logs, prioritise improvements, and co-ordinate changes with the NHS App team so that journeys remain coherent. When you plan a new feature, flag it early; when you change a critical page, run an accessibility regression as part of your definition of done; when the mobile platforms update, re-test the edge cases you know are fragile. This discipline is how you stay reliable at scale while continuing to innovate.
Is your team looking for help with NHS App integration? Click the button below.
Get in touch