Written by Technical Team | Last updated 30.09.2025 | 10 minute read
If you’re planning to surface a patient-facing experience inside the NHS App, the first thing to understand is that this is not a simple “add a link and go live” exercise. NHS England curates and prioritises integrations in quarterly cycles and expects candidate services to meet a specific set of eligibility criteria before an Integration Manager is even assigned. At a minimum, your service must be commissioned in England (for example by an ICB, NHS England or a GP surgery), be free at the point of use to patients, and deliver a personalised, patient-specific journey rather than general health information. You’ll submit an Expression of Interest, demonstrate your product, and—if aligned to the NHS App roadmap and procurement frameworks—move into a structured assessment and delivery process.
There are three principal integration pathways to consider. The first is a web integration: you present a responsive web application inside the NHS App’s native webview, and the NHS App supplies the shell (navigation, header, and context) so your UI needs to adapt accordingly. The second is an NHS App Notifications & Messaging integration, which allows you to send in-app messages and (where supported) capture keyword or free-text replies from patients. The third involves the Patient Care Aggregator (PCA/“Wayfinder”), which is aimed at secondary care and unifies outpatient booking and referral journeys. The pathway you choose determines your onboarding artefacts, APIs, and assurance steps.
A successful web integration follows a well-defined sequence: after eligibility and prioritisation, you complete a solution design with technical requirements, implement and demonstrate your integration in the NHS App Sandpit environment, repeat assurance steps in the Assurance of Suppliers (AOS) environment, complete your Supplier Conformance Assessment List (SCAL), and sign the Connection Agreement that binds you to operational standards post-go-live. Go-live is normally phased—limited release to a cohort, then full release—followed by ongoing assurance and monthly performance data submissions to the NHS App team.
If your use case involves messaging at national scale or in primary care, onboarding may route via NHS Notify or the NHS App API depending on setting and feature. Messaging carries additional responsibilities: choosing use cases carefully (especially for time-critical content), managing citizen preferences, and implementing fallback channels if an in-app message isn’t delivered or read quickly enough. For secondary care messaging specifically, engagement with the Patient Care Aggregator is also expected so that appointment messaging lines up with booking journeys surfaced to patients.
For secondary care booking and referral experiences, the PCA offers patients a single view of outpatient appointments drawn from connected secondary-care booking systems and the national e-Referral Service. Your product typically exposes a patient portal with deep links from the NHS App list view, enabling patients to view details and (where supported) amend or cancel. The PCA roadmap has progressively added documents, questionnaires and paperless preferences; suppliers add these via additional onboarding cycles, each with its own feature-specific criteria and trust-side sign-offs.
Integration with NHS login is non-negotiable. NHS login uses OpenID Connect with Vectors of Trust (VoT) to express both identity verification and authentication strength. Most patient-facing features in the NHS App require at least P5 (medium proofing) with strong authentication (for example, password plus registered device), whereas access to more sensitive data or transactions can require P9 (high proofing) with strong authentication, sometimes with “step-up” journeys from P5 to P9 within your flow. You signal acceptable vectors via the vtr claim during the OIDC flow and must handle cases where the user’s current session does not meet your requested vector. Getting this right is fundamental to reducing friction and ensuring lawful, proportionate access to patient data.
Alongside identity, you must meet the NHS App standards for integration, which bring together accessibility, service design, clinical safety and data privacy requirements. The accessibility baseline is WCAG 2.2 AA for your embedded product, and you’ll be asked to provide evidence (for example, an accessibility audit and remediation plan). On service design, you’re expected to meet all 17 points of the NHS Service Standard, which includes understanding users and their context, measuring performance, designing for inclusivity, and operating a reliable service. For clinical safety, DCB0129 (for manufacturers) and DCB0160 (for deployers) apply; you’ll certify conformance in your SCAL and name a Clinical Safety Officer to lead and sign the safety case and hazard log. For data privacy, UK GDPR and PECR apply as standard, with particular attention to lawful bases and special category data handling.
Because you will process special category data (health), you must identify both an Article 6 lawful basis and an Article 9 condition—health and social care provisioning under Article 9(2)(h) is often relevant for direct care, though you must determine the right ground for your service and document it in a DPIA and privacy notice. If you rely on substantial public interest or research conditions, additional Schedule 1 safeguards may be necessary. Treat this as a first-class requirement: incorrect or ambiguous legal bases are common blockers during assurance.
Security and resilience expectations are similarly stringent. The Data Security and Protection Toolkit (DSPT) remains a baseline for NHS-connected services, and suppliers frequently align with Cyber Essentials Plus and ISO/IEC 27001 to demonstrate broader controls over identity management, logging, vulnerability management, incident response and supplier assurance. When building the embedded web experience, assume a hardened Content Security Policy, strict cookie governance, and a “no unnecessary third parties” mindset. If you send messages via the NHS App, you’ll also need reliable monitoring, retry logic and fallback mechanisms to avoid compromising care pathways when a message is delayed or missed.
To help teams plan, here’s a concise view of the prerequisites you should have on or near day one of your integration project:
User experience inside the NHS App is subtly different from a standalone web app. The native iOS and Android apps host your product in a tailored webview with their own navigation and context, so your site must hide its own headers and footers and defer to the NHS App’s chrome. The App also exposes a JavaScript API for limited interactions and detection, allowing your service to confirm that it’s running within the NHS App context and to behave accordingly (for instance, handling back navigation and focus states appropriately). This is where performance and resilience matter: sluggish pages, uncontrolled modals or inaccessible dynamic components feel worse in a mobile webview than they do in desktop browsers.
Accessibility must be built in from the start. WCAG 2.2 AA compliance is the floor, not the ceiling, and you’ll be expected to test with real users who have access needs, adopt the NHS design system patterns and content style, and produce an accessibility statement that reflects the embedded context (including any reliance on the NHS App container for features like text sizing). Don’t forget that language support is English-only inside the NHS App for interface elements, and ensure that linked content and downstream forms meet the same accessibility bar as your in-app pages.
Digital health services succeed when they’re stitched into NHS infrastructure using mainstream interoperability standards. Across England, that starts with NHS numbers as the durable patient identifier and standard message structures via HL7® FHIR®. If your service reads or writes GP data, plan around GP Connect; for secondary care referrals and bookings, understand how the NHS App consumes summary lists via the Patient Care Aggregator and deep links into your portal for detail. Booking and referral flows are evolving toward the Booking and Referral Standard (BaRS), so design your architecture to adapt as those capabilities become available.
For messaging, the NHS App API lets you send in-app messages and, where enabled, capture replies. Authoring is Markdown-based with a defined subset, so you’ll need to craft content that’s readable and accessible, and avoid embedding personal data in URLs. Critically, because the messaging channel assumes P9 (high-assurance) recipients, you may include personal and special category data in messages—provided you have the legal basis and you follow the formatting rules. Time-critical messaging is discouraged unless you implement robust fallback channels; you’re accountable for the risk if a patient does not read or receive a message in time.
When you integrate with PCA/Wayfinder, think of it as an aggregator of aggregators. The NHS App asks the PCA for each patient’s list of referral and booking summaries from connected secondary-care booking systems and renders them for the patient. Each entry includes a deep link to your patient portal for action; documents and questionnaires are increasingly surfaced as additional features. From a supplier perspective, this means aligning your portal’s authentication with NHS login, implementing deep links with context‐appropriate state, and ensuring your portal supports amend/cancel safely with clear error handling. You will also need to add features in separate onboarding cycles and provide evidence that trusts have updated their DPIAs, safety cases and equality/inequalities assessments for each.
Before committing your backlog, map the interfaces you’ll need to support and the artefacts each one will require:
Observability and MI: event logging with patient-safe identifiers; monthly KPIs for the NHS App team; dashboards for message delivery, read receipts and fallback utilisation.
Assurance isn’t a paper chase; it’s a joint rehearsal for safe, reliable operations at national scale. In the Sandpit you’ll demonstrate core flows, identity handling, error states and accessibility. In AOS you repeat the exercise against the more formal assurance checklist while progressively completing your SCAL—evidence for accessibility, service design, clinical safety, privacy, security and operational support. Before go-live you’ll sign the Connection Agreement that binds you to service obligations, and you’ll walk through an incident rehearsal with NHS service management so both teams know how to respond to clinical, security or outage scenarios.
Release is deliberately phased. Start with a limited cohort (for example, a subset of practices or one acute trust) to validate performance at live scale, iron out operational issues, and tune your fallback channels. Move to full release once metrics meet your jointly agreed thresholds. After launch, you’ll be asked for monthly performance data and to participate in annual assurance reviews (combined with NHS login where applicable). Changes to your in-app journey—anything from tile copy to substantial new features—must be planned with your Integration Manager, with minor edits taking weeks and larger feature shifts scheduled in quarterly planning.
Finally, keep governance lightweight but real. Treat your safety case and hazard log as living artefacts; review DPIAs and privacy notices when you expand scope; measure inclusivity and accessibility in production, not just in labs; and monitor user sentiment on message volume and relevance. The teams that thrive inside the NHS App are the ones that combine evidence-based delivery with respect for patient time, patient safety and patient trust—meeting the letter of the standards while continuously improving the experience.
Is your team looking for help with NHS App integration? Click the button below.
Get in touch