Written by Technical Team | Last updated 30.09.2025 | 19 minute read
NHS login sits at the heart of many digital health experiences in England, quietly doing the heavy lifting of identity, security and consent so citizens can access services safely. Whether you are building a new digital product or improving an established one, understanding how the user journeys unfold—and how the different verification levels gate features—will make the difference between a smooth, trustworthy experience and a confusing one. This article unpacks the moving parts in plain English, clarifies what P0, P5 and P9 actually mean in practice, and offers practical guidance for designing journeys that work for real people.
At its simplest, NHS login provides a standard way for people to prove who they are and sign in to multiple NHS and partner services. Under the bonnet there are graded levels of assurance, each unlocking progressively more sensitive capabilities. Crucially, you can’t just “turn everything on”; your service requests only the claims and scopes it legitimately needs, and the user journey adapts accordingly. The result is a layered approach: light-touch for low-risk features, and rigorous checks when clinical or personal information is involved.
NHS login follows a well-understood pattern in modern identity systems: one account, used across many services, with strength of verification matched to risk. Users discover NHS login when they tap a “Continue with NHS login” button on a website or in an app. From there, they are taken through a consistent set of steps managed by NHS login itself. Those steps differ depending on what the relying service has asked for (the scopes and claims) and the verification level the user has already achieved. Although the underlying technology relies on standards, the most important part is human: the sequence of screens, prompts and checks that lead someone from intention (“I want to see my prescription history”) to outcome (“I can safely view it”).
This is where user journeys matter. The flows are designed to be predictable across services, which helps users build mental models—useful in healthcare, where clarity and trust are essential. If a person has only completed basic account creation, they can still sign in, but they will be nudged to strengthen their identity before accessing anything sensitive. If they are fully verified, the journey is shorter and more powerful, allowing access to GP records, repeat prescriptions and other clinical features. Designing with those pathways in mind is key to reducing friction while meeting regulatory and safety expectations.
The P0 (sometimes called “low-level”) journey is the least demanding in terms of proof. It typically involves creating an account with an email address, setting a password, and confirming a phone number for security codes. That combination is enough to recognise a returning user and protect against casual misuse, but it doesn’t establish a strong link to a real NHS identity. Think of P0 as a lightweight pass: it opens the door to general experiences that don’t need access to a person’s NHS record and where the risk of harm is low.
In product terms, P0 is useful because it lets you get people started quickly. You can personalise around someone’s preferences and contact details without risking exposure of clinical data. You can also build trust while making it clear that stronger verification will be required before certain features appear. Presenting those boundaries transparently (“To view your GP record, we’ll need to verify your identity”) helps set expectations and can reduce frustration later.
Where teams sometimes stumble is by treating P0 as a one-size-fits-all answer to sign-in. It isn’t. If you attempt to deliver clinically sensitive features to P0 users—by, for example, inferring identity from self-entered details—you risk both safety and compliance issues. P0 does not prove that John Smith is the same John Smith in the Personal Demographics Service (PDS), nor does it guarantee that the phone number belongs to the right person. It is, by design, a minimal assurance level.
Productively, P0 can still underpin genuinely valuable health journeys when you avoid clinical entanglements and respect data minimisation. The secret is to design features that are useful on their own—nudges, information, self-tracking that stays outside the clinical record—while giving clear, inviting pathways to higher verification when people want more.
Suitable use cases at P0 include:
P5 moves the experience from “we know this account” to “we can match this person to an NHS identity”. In practical terms, P5 involves collecting key demographics—name, date of birth, and often NHS number—and matching them to the Personal Demographics Service. That match creates a stronger assertion that the account belongs to the right, real individual within the NHS spine. You still do not have carte blanche to surface medical records, but you are on firmer ground to deliver features that rely on accurate demographic context.
For many services, P5 is the sweet spot: enough assurance to anchor transactions to the right person, without the full rigour and friction of P9. It enables capabilities like directing the user to their registered GP practice, initiating non-sensitive administrative requests, or pre-populating forms with validated demographic details. It can also reduce errors where name or date-of-birth mismatches would otherwise trigger manual checks or create duplicate entries.
The choreography of the P5 journey matters. Done well, it feels like a natural extension of sign-in, with clear, plain-English explanations about why details are needed and how they will be checked. People may not know their NHS number, so journeys should accommodate this gracefully, using alternative match routes and explaining what happens next. Responsiveness to edge cases—such as recently updated names, adoptions, or overseas registrations—prevents dead ends. The goal is respectful rigour: ask for only what is necessary, provide reasons, and give constructive next steps if the match fails.
From a product and engineering perspective, P5 is also where “claims and scopes” thinking becomes concrete. Your service should only request the attributes it genuinely needs. If you require the ODS (organisation) code for a GP practice to route messages or configure integrations, request exactly that—not an expansive bundle of unrelated claims. Keeping scopes tight supports the principle of least privilege and will keep governance conversations straightforward.
P9 is the top tier. It links the authenticated account to the right person and adds a robust proof of identity sufficient for accessing clinical information and performing sensitive actions. Users reach P9 through defined routes that might include document checks, liveness and facial matching, or linkage to existing GP online services where appropriate. The important point for product teams is what P9 enables: it is the key that unlocks reading the GP record, ordering repeat prescriptions, and managing appointments—capabilities that carry higher risk and therefore demand higher assurance.
The user experience at P9 requires careful design because the checks are more involved. People may need to photograph documents, complete real-time liveness prompts, or follow a set of steps that take longer than a typical sign-in. Successful products make this predictable and humane. They explain why the checks are necessary (“we’re protecting your private health information”), provide progress feedback, and offer alternative routes if technology or circumstances get in the way. Accessibility considerations are central: lighting, camera quality, motor impairments and language all affect whether someone can complete the process.
Once completed, P9 removes a great deal of friction from subsequent sessions. Users can return to supported services and access sensitive features with a short, predictable sign-in—often a password plus a one-time code, or a biometric second factor on a device. That combination respects both security and convenience while ensuring that the right data is shown to the right person.
From an integration standpoint, P9 also sharpens the conversation about data boundaries and consent. Just because your service is technically able to request certain claims does not mean it should. Clearly communicate which pieces of information your application will use and why, and present consent screens that are unambiguous. If you are surfacing clinical record content, make provenance clear (e.g., which practice provided the record), provide timestamps, and help users interpret entries safely.
Typical P9-enabled capabilities include:
When you plan a digital health service, it’s tempting to chase P9 immediately because it unlocks the richest features. In reality, the best experiences grow in layers. Start by articulating your service’s risk profile. What could go wrong if you misidentify a person? What harm could arise if a stranger viewed the data you plan to display? How might an incorrect action (like ordering a medication) affect someone’s care? Map those risks to verification levels: P0 for low or negligible risk, P5 for medium-risk identity binding, and P9 for clinical data and sensitive actions.
That mapping then flows into your feature strategy. For example, a symptom checker or educational tool can provide immediate value at P0, capturing user intent and building trust. As people lean into the service and see value, you can present a thoughtful prompt to strengthen their account to P5, unlocking personalised routing to their GP or pre-filled administrative forms. Only when they choose to view or act upon the clinical record do you step up to P9, with clear explanations and supportive guidance. This layered approach reduces early friction while ensuring the right safeguards are in place when they matter most.
Another practical consideration is failure handling. Not everyone will complete a PDS match smoothly at P5, and some people will struggle with document or liveness checks at P9. Plan these realities into your product. Offer alternative routes and human support where appropriate. Provide straightforward next steps when a check can’t be completed—for instance, explaining how to update demographic information with a GP practice, or offering appointment-based identity checks for those without suitable documents or devices. Treat these pathways as first-class parts of the user journey rather than afterthoughts.
You should also design your information architecture to reflect capability boundaries. Do not tease features that a user cannot access at their current level without context; instead, gently disclose them with a lock badge or a short, empathetic explainer (“Available after identity verification”). When people opt to proceed, hold their place and return them to the same screen after verification so effort is never wasted. Micro-copy, progressive disclosure and sensible defaults do more to reduce drop-off than any single technical decision.
Finally, bring your governance and privacy teams into the conversation early. Verification level is only one part of the safety story. You’ll also need clear data processing justifications, short and plain privacy notices, and an audit trail for consent. Aligning these elements from the outset prevents rework later and reassures users that their data is being handled with care.
A well-designed journey is as much about what you leave out as what you include. Keep prompts clear, use everyday language, and avoid jargon. If you need a date of birth, say why. If you need to check details against NHS records, explain what will happen and how long it typically takes. Provide examples of acceptable documents with simple tips for success (clean lenses, good lighting, remove cases that cover parts of the ID). Build generosity into your error messages: tell people what went wrong and how to fix it.
Device diversity is a practical challenge. Many users will start on a desktop but need a mobile device to complete document capture or liveness. Offer graceful hand-offs—QR codes or secure links that allow someone to continue on their phone without starting over. Conversely, allow people on mobile to park progress and finish later on a larger screen if needed. Consider connectivity constraints and ensure that critical steps save state if a session drops.
Security should never be an afterthought, but it also shouldn’t feel like a punishment. Where possible, embrace authentication methods people already understand—one-time passcodes via SMS or authenticator apps, device biometrics for step-up approval—and back them with controls such as rate limiting, risk-based prompts, and alerting for unusual sign-ins. If you support multi-device access, make device management simple: list active sessions, allow users to revoke old devices, and confirm changes via email or SMS.
Accessibility must run throughout. Ensure that forms and verification flows work with screen readers, that time-outs are generous or adjustable, and that instructions are available in plain English with alternative formats. If your P9 route uses video or motion, supply an equivalent for users who cannot perform liveness in the standard way, and make human support easy to reach. Inclusive design is not just a regulatory requirement; it is fundamental to successful completion in a health context.
From a technical perspective, your service integrates with NHS login by requesting specific claims (attributes about the user) and scopes (permissions to access them). The principle of least privilege applies: request only what you need for the user story in front of you. This is not simply a governance box-tick. Lean requests lower the cognitive burden on users at consent screens and reduce perceived risk. When a person sees that you’re asking for a small, clearly justified set of data, they are more likely to proceed.
Think in terms of bundles aligned to journeys. For a P0 experience, you might only need an identifier and a confirmed email to deliver notifications. For P5, adding date of birth and a link to the registered GP practice could underpin routing and pre-population. For P9, you request the clinical scopes necessary to surface the features you genuinely provide—medications, appointments, documents—no more, no less. As your product grows, revisit these bundles periodically to prune legacy requests that no longer add value.
Transparency matters here. Make the consent moment specific and comprehensible. Replace generic “We need access to your data” with “We’ll use your date of birth and GP practice to find your record and route your requests correctly.” Avoid yawning, multi-page terms at the precise second someone wants to complete a task; give them succinct, contextual explanations and the option to read more. After authorisation, consider a “What we can now do” confirmation that reiterates the value unlocked—and what you still cannot see or do.
Auditing and traceability are part of the same story. Keep clear logs of what was requested, what was granted, and when. If a claim is revoked or a scope changes, handle the downgrade gracefully in your UI and communicate the impact: “Because you removed access to X, feature Y is now hidden.” This builds trust and prevents surprising errors later.
One frequent misstep is collapsing the verification journey into a single monolithic gate before anything useful happens. This approach often leads to high drop-off because users are asked to do a lot before they understand the value. Instead, stage the experience. Offer immediate, meaningful functionality at P0. Then, when the moment is right—typically when a person tries to access a locked feature—invite them to strengthen their verification with a concise explanation of the benefit.
Another pitfall is under-investing in failure pathways. Matching against demographic records can fail for legitimate reasons: recent changes of name or address, people with multiple similar records, or system timing issues. Document checks can fail due to lighting, glare or camera quality. If the only outcome is “Try again”, users will give up. Provide varied help: tips for better photos, alternate documents, the ability to pause and resume, and clear contact routes for support.
A third trap is assuming that P9 is static. People change phones, emails and names. Build account management that respects identity assurance without making common maintenance tasks painful. When a user updates their phone number, guide them through any required checks with empathy and clarity, and confirm changes through a second channel to protect against account takeovers. Make the security model visible in small, reassuring ways—messages like “We’ve sent a confirmation to your email” or “You’ll need to verify your identity again to see your record on this device.”
Finally, beware of scope creep in both senses. Technically, avoid requesting expansive claims because “we might need them later.” Product-wise, resist designing features that implicitly assume clinical access for everyone. Keep the experience robust at every level, and you’ll naturally support a wider range of users, including those who cannot or do not wish to complete P9.
Verification journeys are not fire-and-forget; they benefit from continuous improvement grounded in evidence. Instrument your flows to understand completion rates, time to verify, the most common failure points, and how often people return to finish later. Segment by device type and route to see whether, for example, desktop-to-mobile hand-offs outperform pure mobile flows, or whether a particular document type correlates with failures.
Balance quantitative data with qualitative insights. Watch user research sessions to observe where explanations land and where they don’t. Listen for emotional cues—confusion, worry, relief—and fine-tune micro-copy and sequencing accordingly. Test alternative prompts for strengthening verification and measure whether they produce better conversion without increasing support contacts or complaints.
Crucially, set ethical guardrails for iteration. Do not “dark pattern” people into granting wider access than they intended. Avoid nudges that imply care will be compromised if someone does not upgrade to P9 when it isn’t necessary. Frame choices accurately and respect both consent and refusal. In health, the long-term cost of eroding trust far outweighs any short-term uptick in conversion.
To make this concrete, imagine a staged rollout for a new health app. In phase one, you support P0: people can create an account, set communication preferences, and receive tailored guidance based on self-reported goals. You keep the claims request minimal and build a polished experience around core tasks that don’t depend on clinical data. Early signals show strong engagement and low support burden.
In phase two, you introduce P5 where it adds clear value. Users can confirm their demographics and, once matched, see administrative features: a view of their registered GP practice, the ability to submit non-sensitive requests, and smarter routing for queries. You craft contextual prompts when someone enters a flow that benefits from P5, explaining the benefit and time required. Completion rates are high because people now see a clear “why”.
Phase three expands to P9 for users who want clinical features. You design the document and liveness steps with care, provide alternatives, and ensure accessibility. After successful verification, the app unlocks record views, repeat prescriptions and appointment management. Importantly, these features are visible—but gently gated—at lower levels, so the upgrade path is always obvious and inviting.
Across all phases you keep scopes tight, consent screens clear, and failure handling humane. You measure carefully, improve iteratively, and maintain a stable core experience for those who cannot or do not wish to move beyond P0. In doing so, you preserve trust while delivering meaningful value at every level of assurance.
Even with a strong conceptual grasp, the day-to-day of building can be messy. A simple, shared checklist helps keep teams aligned and focused on outcomes. Use it to guide discovery, design and delivery, and to ensure that your service makes the most of NHS login without stumbling over common issues.
NHS login’s layered verification model is not a bureaucratic obstacle; it is a framework for building trust at the right pace. P0 lets you welcome people in and deliver immediate value. P5 connects accounts to real NHS identities for confident, non-sensitive tasks. P9 opens the door to the most powerful features, where assurance must be strongest. If you design your service to be genuinely useful at each of those layers—and to help people move between them with clarity and dignity—you will earn the right to deliver more over time.
In the end, successful digital health experiences respect three things: the user’s time, the user’s autonomy, and the user’s privacy. When you align your user journeys, claims and scopes, and verification pathways to those principles, NHS login becomes a force multiplier rather than just a sign-in button. It sets the stage for safe, human-centred care in a world where more and more of our health lives are lived online.
Is your team looking for help with NHS Login integration? Click the button below.
Get in touch