Written by Technical Team | Last updated 09.01.2026 | 15 minute read
Integrating a point-of-care system with the NHS National Care Records Service (NCRS) is deceptively simple on the surface: a clinician clicks a deep link, NCRS opens, and the correct patient record appears. Underneath that smooth click-through experience sits the most sensitive part of the whole journey: authentication and access control.
Authentication is not just a technical step in NCRS integration; it is the trust boundary that protects national clinical information. It determines whether the person in front of the screen is who they claim to be, whether they are entitled to view the record they are requesting, and whether their access can be audited later. When authentication is designed well, NCRS feels like a natural extension of the clinician’s workflow. When it is designed poorly, it can interrupt care, create workarounds, and undermine confidence in both the local system and NCRS.
NCRS integration is a user interface integration rather than a data API. That distinction changes everything about authentication responsibility. Your application is not negotiating tokens to fetch clinical data from NCRS. Instead, your application is handing the user off to NCRS, and NCRS authenticates the user through the Care Identity Service using smartcards or modern alternatives supported by CIS2. In other words, NCRS owns the session and the authorisation decisions, and your job is to launch NCRS in the right way, with the right patient context, while creating the conditions for a reliable sign-in experience.
This article explains how smartcard authentication and CIS2 authentication typically behave in NCRS integration, what practical flows look like end-to-end, and how to design a point-of-care product that supports both without fragility. The focus is on real-world integration outcomes: fewer clicks, fewer lockouts, fewer misdirected launches, and a clearer mental model for product teams, architects, and delivery leads.
NCRS integration is built around a deep link that launches NCRS and opens the patient record associated with the NHS number embedded in the link. Because it is a UI launch, NCRS itself controls the login process, the session, and the rules for what the user can view or do. That model is powerful because it avoids replicating national clinical data into multiple supplier systems and centralises clinical access governance in one place, but it also means that authentication behaviour is experienced directly by clinicians at the point of care.
From a workflow perspective, the deep link is a promise: “You are in the right patient context, and the national record is one click away.” Authentication is what keeps that promise from breaking. If the user lands on a login screen unexpectedly, is asked to re-authenticate too frequently, or is denied access after a long delay, the deep link starts to feel unreliable. In clinical settings, reliability is not a nice-to-have; it is the difference between NCRS being used routinely and being ignored.
The hidden complexity is that NCRS has to support a wide range of local environments: managed desktops on internal networks, laptops on Wi-Fi, shared workstations, mobile devices, and mixed authentication estates where some users still rely primarily on smartcards and others use CIS2 modern authenticators. NCRS can accept both approaches, but the experience depends heavily on local readiness: workstation setup, browser constraints, credential management components, and whether the user is already authenticated in another national application.
For integration partners, a key mindset shift helps: you are not “implementing NCRS authentication”; you are “making NCRS authentication succeed inside your workflow”. That means anticipating what the user sees after the click, deciding how you surface status messages when the handoff fails, designing your UI to discourage risky shortcuts, and supporting local IT teams with practical deployment guidance that reduces authentication friction.
Smartcard authentication remains widely used across health and care because it combines strong identity assurance with local possession of a physical token. In NCRS integration, the smartcard is not used by your application to sign into NCRS; it is used by the user when NCRS prompts for authentication through the Care Identity Service. The integration goal is to make that prompt predictable, quick, and compatible with the local workstation environment.
A typical smartcard-based NCRS journey begins with the clinician selecting a patient in the point-of-care system and clicking a link such as “Open in NCRS”. The system constructs a deep link that includes the patient’s NHS number and launches NCRS in a browser window. If the user is already authenticated in NCRS (or in a related national session that NCRS can recognise), they may be taken directly to the patient record. If not, NCRS will route them to the smartcard sign-in experience.
The phrase “smartcard sign-in” can refer to two practical modes that matter operationally. The older model is the CIS1 style workstation setup using a locally installed identity agent and smartcard middleware. The newer direction is smartcard access through CIS2-enabled components such as Smartcard Connect and modern credential management tooling. To a clinician, both are “insert card, enter passcode”, but to an IT team and supplier, they differ in prerequisites, support models, and failure modes.
Smartcard flows succeed when the local environment is prepared. That includes the physical reader, smartcard middleware, credential management components, and a supported browser configuration. It also includes the more human factors: the user’s card is unlocked, the passcode is known, and their role-based access is correctly assigned. Many apparent “integration issues” are actually workstation readiness issues that surface only when NCRS is launched from inside another application.
In practice, smartcard authentication for NCRS integration tends to follow a small number of patterns:
From a design standpoint, you cannot control how NCRS prompts the user, but you can control how your system prepares the user for what will happen. For example, a deep link labelled “View NCRS record (smartcard required)” sets expectations on shared workstations where a user may not have their card inserted. Likewise, surfacing an unobtrusive indicator that the NHS number is missing or unverified prevents a launch that inevitably fails or lands the user in the wrong place.
A subtle but important point is that smartcard authentication is not just “login”; it is part of a governance model. The user’s access rights are tied to their identity and role assignments, and the smartcard acts as a strong signal of possession. When NCRS is launched, it will apply those rights in its own interface. That means a user might successfully authenticate but still not be permitted to view certain datasets or perform certain actions, and your workflow should treat that outcome as expected rather than exceptional.
CIS2 authentication exists to provide secure, modern authentication options that are better suited to internet-based access and contemporary devices. Where smartcard authentication is anchored in a physical token and reader, CIS2 expands the set of authenticators and interaction modes while preserving high assurance and strong auditability. For NCRS integration, CIS2 matters because NCRS supports “smartcard or modern alternative” authentication routes, allowing organisations to reduce reliance on traditional smartcard-only workflows over time.
In an NCRS launch scenario, CIS2 does not mean that your system becomes responsible for authenticating the user into NCRS. NCRS still owns the authentication decision. However, CIS2 influences what the user experiences at the sign-in step and what local prerequisites are needed to make that experience smooth. It can also influence deployment choices: whether an organisation can support NCRS access on devices where smartcard readers are impractical, and whether authentication can be completed quickly with secure, user-friendly methods.
CIS2 commonly follows standards-based authentication patterns aligned with OpenID Connect. That matters for suppliers who also integrate their own applications with CIS2 directly, but for NCRS integration it matters mainly because it shapes session behaviour and the sign-in interface options the user sees. If a user is already authenticated with CIS2 in another context, NCRS may be able to reuse that session and reduce repeated prompts, depending on organisational configuration and session policies.
From the clinician’s viewpoint, the CIS2 experience is usually presented as a “choose your login method” screen, followed by an authentication step appropriate to the device and the organisation’s security posture. The exact choices available can vary, but the principle is consistent: strong authentication that works beyond the traditional smartcard estate.
Common CIS2 authentication elements that can appear during NCRS sign-in include:
This variability is a strength and a challenge. It is a strength because NCRS can remain usable across a wider set of settings, including mobility scenarios. It is a challenge because your support model must recognise that users in different organisations may see different sign-in paths even when they click the same deep link in your application.
A well-designed point-of-care application treats CIS2 sign-in as a normal, supported route rather than a special case. That means your help content, screenshots, and “what happens next” guidance should avoid assuming a single login method. It also means your error messaging should not say “smartcard problem” when the user may be attempting a non-smartcard CIS2 method.
CIS2 also introduces an important concept for user experience: step-up and assurance decisions. In practice, organisations may configure authentication policies that require stronger factors for certain contexts, or that time out sessions more aggressively on shared devices. For NCRS integration, this can manifest as a user being asked to authenticate again even if they recently accessed NCRS, especially if they are moving between devices or contexts. Rather than resisting that behaviour, your workflow should minimise the cost of it: preserve patient context in the deep link, avoid launching multiple NCRS windows unnecessarily, and ensure the user can easily return to your system without losing their place.
A successful NCRS integration is measured less by whether the deep link works in a happy-path demo and more by whether it keeps working across shifts, devices, network conditions, and mixed authentication estates. To achieve that, you need to design the integration as a product capability, not a one-off technical connection.
Start with patient context. The deep link includes the patient’s NHS number so NCRS knows which patient to display. That makes NHS number quality foundational. If your system allows unverified NHS numbers, duplicates, or partial demographics, you must decide what your NCRS launch button does in those cases. The safest approach is to require a verified NHS number before enabling the link, or to provide a clear, user-friendly route to verify it. The worst experience is a link that opens NCRS but fails silently or lands on a search-like screen that forces the user to re-enter details under time pressure.
Next, consider how you open NCRS. Launching in a new tab is often preferable because it avoids embedding a complex national UI inside a constrained frame and respects browser security policies. However, in managed environments, pop-up blockers and kiosk configurations can interfere. Your application should open NCRS in a way that is consistent with the organisation’s desktop standards and should provide guidance to local IT teams on browser settings that support the workflow without weakening security.
Session behaviour is another major factor. Users may already have an NCRS session, or they may not. They may have authenticated via smartcard earlier, or via a CIS2 method. A robust integration assumes nothing and simply launches the correct patient context, letting NCRS decide whether to prompt for authentication. Where you can add value is in avoiding redundant launches. If your UI encourages repeated clicks, you can end up with multiple NCRS tabs, each attempting authentication and competing for the user’s attention. A small piece of product design, such as disabling the NCRS launch button for a few seconds after click and showing a “Launching NCRS…” indicator, reduces this dramatically.
Error handling deserves special attention because authentication failures rarely present as clean, actionable errors. Users may see a generic “can’t sign in” message, a blank page, a redirect loop, or a smartcard middleware prompt that never completes. Your system cannot intercept NCRS errors, but you can build a support-friendly pattern around them. Provide a “Having trouble opening NCRS?” link near the launch control that opens a short, role-appropriate checklist, ideally tailored by device type. Keep the language neutral: focus on prerequisites (“Is your smartcard inserted?”, “Are you connected to the right network?”, “Is your authentication method available?”) rather than diagnosing from afar.
Audit and clinical safety should be embedded in the workflow. NCRS will audit access on its side, but your local system should also record that a user attempted to launch NCRS for a patient at a specific time. This is not about duplicating national audit; it is about operational insight. When a user reports “NCRS didn’t open”, your support team needs to know which patient context was used, whether the NHS number was present, and whether the launch action was performed successfully at the browser level. Even lightweight logging can reduce resolution time and prevent misattribution of issues.
There is also a user education element that product teams sometimes overlook: the difference between “launch” and “access”. Users may assume that clicking the link grants access to the record. In reality, access depends on identity, role permissions, and sometimes policy-based conditions. Your UI copy should set the right expectation without adding friction. A short tooltip or helper text that explains “NCRS opens in a separate window and may ask you to sign in” can prevent confusion, especially for staff who use NCRS less frequently.
Finally, design for mixed estates. During transitions from CIS1 smartcard-heavy environments to CIS2 modern authentication, organisations can have different rules on different sites, or even different departments. Your integration should be indifferent to that diversity. Avoid hard-coding assumptions like “smartcard always required”. Avoid embedding documentation that becomes obsolete when an organisation rolls out CIS2 authentication alternatives. Make your support content modular and easy to update, and keep the launch mechanism consistent so that training is transferable.
Authentication in NCRS integration is inseparable from governance. Because NCRS provides access to national clinical information, onboarding is controlled, and products complete an assurance journey before they are recognised as integrated. For suppliers, this means planning early for the non-technical work: information governance alignment, security posture, and readiness to support healthcare organisations in deploying the authentication components required for their chosen login routes.
Smartcards have a long operational history, which is both a benefit and a burden. The benefit is maturity: many organisations have established processes for issuing cards, managing passcodes, and assigning role-based access. The burden is environmental dependency: readers, middleware, workstation configuration, and support processes that can vary between sites. As a supplier, you can reduce that burden by packaging a clear “smartcard readiness” guide for NCRS launch scenarios, written in operational language for local IT teams, not just developers.
CIS2 authentication introduces a different set of governance conversations. Organisations need confidence that modern authenticators meet assurance requirements, that recovery processes are safe, and that shared device risks are managed. Session timeouts, re-authentication triggers, and device trust models can all change user experience. Rather than treating those as externalities, suppliers should design integration guidance that anticipates them. For example, if an organisation uses shared workstations in urgent care, it may prefer shorter sessions and more frequent prompts. In contrast, a community setting with single-user devices may prefer fewer prompts and stronger device binding. Your product should support both realities without forcing the organisation into one pattern.
A future-proof NCRS integration also recognises that authentication technology evolves while the deep-link concept remains stable. Your launch mechanism should not depend on fragile browser hacks or deprecated components. Keep the integration minimal: generate the correct deep link, launch NCRS predictably, and let NCRS manage authentication. Then focus your innovation where it matters: patient context quality, workflow design, and operational support.
There is also an opportunity to think about how NCRS fits into the wider clinical desktop. Many organisations are trying to reduce “window sprawl”, where clinicians juggle multiple separate systems. NCRS integration can either add to that sprawl or reduce it, depending on how you design the handoff and return journey. A good pattern is to make “return to patient” effortless: ensure your application retains the patient context when the user comes back, avoid resetting the patient list, and make it easy to continue the task that led them to NCRS in the first place.
Ultimately, smartcards and CIS2 are not competing goals; they are complementary routes in a national identity service that needs to serve diverse care settings. The best NCRS-integrated point-of-care products treat authentication as a first-class part of the user experience. They build the deep link reliably, they avoid assumptions about how the user will sign in, they help organisations deploy the necessary components, and they support clinicians through the moments when authentication friction is unavoidable for safety reasons.
When you get that right, NCRS stops feeling like “another system” and starts feeling like what it is meant to be: a secure, quickly accessible national view that supports direct care at the moment it matters.
Is your team looking for help with NHS National Care Records Service (NCRS) integration? Click the button below.
Get in touch