Written by Technical Team | Last updated 20.08.2026 | 25 minute read
The NHS Single Patient Record could become one of the most consequential changes to digital health infrastructure in England for decades. Its ambition sounds straightforward: bring together the important information held about a patient so that authorised professionals can access what they need, wherever that patient receives care, while giving patients much greater visibility of their own health information through the NHS App. The problem it is attempting to solve is equally familiar. Health information remains distributed across GP systems, electronic patient records, laboratory systems, diagnostic platforms, pharmacy systems, community services, mental health systems, social care platforms and numerous specialist applications. The information exists, but it does not always travel with the patient.
For digital health suppliers, however, the significance of the Single Patient Record extends far beyond creating another destination to which data must be sent. If the programme succeeds, it could change the assumptions on which healthcare software is designed, integrated and purchased. Products will increasingly be expected to participate in a national information ecosystem in which data must be discoverable, understandable, trustworthy and appropriately accessible outside the application in which it was originally created. Interoperability therefore moves from being a useful product capability to becoming part of the product itself.
It is also important not to get ahead of the programme. At the time of writing, the final technical architecture has not been fixed. NHS England has been exploring different technical approaches, working with existing shared care record suppliers and testing how established infrastructure could be extended. A hybrid, iterative approach has emerged rather than a single predetermined architecture. Early work has focused on real clinical scenarios including maternity and frailty, while legislation is being progressed to create the legal basis for the record and require relevant providers to share information. Patient access through the NHS App is intended to begin from 2028.
That uncertainty is not a reason for suppliers to wait. In many ways, it makes preparation more important. The details of individual APIs, procurement routes and technical components may evolve, but the direction of travel is much clearer: standardised data, interoperable systems, reliable patient identity, transparent provenance, stronger access controls, better data quality and digital services that work across organisational boundaries. Suppliers that begin adapting to those principles now will be in a much stronger position than those waiting for a final specification before thinking about interoperability.
The phrase “Single Patient Record” can create the impression that the NHS intends to replace its existing clinical systems with one enormous centralised application containing every piece of information about every patient. That is not a useful assumption for suppliers to make. The stated intention is to bring information from existing NHS and social care systems together while information continues to be held in the systems in which it was originally created. NHS England’s discovery work has explored several technical models, including connecting existing regional shared care records through a central interface, using a centrally managed data store connected to multiple settings, and using a virtual data layer capable of retrieving information from existing systems behind the scenes. These models are not necessarily mutually exclusive.
That matters because the fundamental problem being addressed is not simply storage. The NHS already stores enormous amounts of patient information. The harder problem is making the right information available to the right person at the right moment, with sufficient context for that information to be clinically meaningful and sufficiently strong controls for patients and professionals to trust the process. A laboratory result without provenance, a medication without its status, an allergy recorded differently in two systems or a diagnosis with no indication of when and where it was established can create more ambiguity rather than less. A successful Single Patient Record therefore depends on semantic interoperability and information quality as much as connectivity.
The programme also differs from existing Shared Care Records. Shared Care Records have already demonstrated that information can be joined across organisations and regions, but their coverage, content and capabilities vary. A clinician treating a patient outside their normal region cannot assume that the same information will be available in the same way. The ambition of the Single Patient Record is national. It is intended to allow relevant information to follow the patient across organisational and geographical boundaries, rather than depending on which local interoperability arrangements happen to exist around them.
This is why the Single Patient Record should be understood as an architectural shift rather than a single new piece of software. The significant question for a digital health supplier will increasingly become not “does your system contain this information?” but “can this information participate safely in the wider health and care ecosystem?” A product may still own a sophisticated workflow, user experience or specialist clinical capability, but the data produced by that workflow will increasingly need to be available elsewhere. Equally, the product may need to consume authoritative information created by other systems instead of creating yet another local copy.
The programme is therefore likely to expose an uncomfortable distinction between systems that are digitally mature internally and systems that are genuinely interoperable. A beautifully designed cloud application can still be a data silo. A modern API does not automatically make data clinically interoperable. And claiming to “support FHIR” is not the same as being capable of participating safely in a national longitudinal record. Suppliers need to think about the meaning, lifecycle, provenance and governance of information, not merely the mechanism by which JSON crosses an API.
For established EPR, primary care, diagnostic and clinical system suppliers, the Single Patient Record increases the strategic importance of openness. Historically, some of the value of a clinical system has come from being the principal place in which a particular dataset can be accessed. In a more interoperable NHS, that relationship changes. An EPR remains critical because it supports complex clinical workflows, documentation, prescribing, ordering, decision support and operational processes, but it becomes less acceptable for important patient information to be effectively trapped inside that EPR. The ability to expose structured information reliably may become as important as the ability to display it locally.
For specialist digital health suppliers, this potentially creates opportunity. A national information layer could reduce one of the biggest barriers to scaling healthcare technology: the need to recreate the same integrations every time a product enters another NHS organisation. Today, a company may prove a product successfully in one trust only to discover that deployment into the next requires different interfaces, different datasets, different authentication arrangements and extensive local mapping. If the Single Patient Record drives greater consistency in standards and access patterns, some of that repeated integration effort could eventually be reduced. A supplier could spend more of its engineering budget on the clinical value of its product and less on rebuilding local plumbing.
That does not mean integration becomes easy. In fact, the transition period may initially make the landscape more complicated. Suppliers will need to operate in an NHS containing modern FHIR APIs alongside older HL7 messages, proprietary EPR interfaces, shared care records, national services and local integration engines. Different organisations will modernise at different speeds. New national patterns will have to coexist with systems that cannot be replaced overnight. The successful supplier will therefore not simply support the newest standard; it will know how to operate safely across generations of NHS architecture while maintaining a clear migration path towards the future state.
The Single Patient Record could also change what NHS buyers regard as technical debt. A system that solves an immediate problem but creates another isolated patient dataset may become increasingly difficult to justify. Procurement teams and digital leaders are likely to place greater weight on whether information can be extracted in a standard form, whether interfaces are documented, whether data can move without punitive commercial restrictions and whether the system can integrate with national services. Interoperability is therefore likely to become a commercial differentiator before it becomes a completely standardised technical requirement.
There is another consequence. As access to common clinical information becomes easier, the competitive advantage of merely possessing data may decline. Digital health products will need to create value through what they do with information: improving workflow, reducing administrative effort, supporting decisions, coordinating pathways, identifying risk, improving communication or enabling patients to manage their health. A supplier whose proposition depends mainly on building another repository or dashboard should consider how that proposition changes when a longitudinal patient record and an increasingly capable NHS App become part of the national architecture.
The NHS App is particularly important here. The intention is for patients to access their Single Patient Record through the NHS App from 2028, while the App itself is becoming a much broader digital front door for the NHS. It is moving beyond prescriptions and appointment management towards planned-care journeys, communication, triage, prevention and access to approved digital health tools. Suppliers developing patient-facing products should therefore ask a strategic question: which interactions genuinely require a separate destination, and which should increasingly be delivered through, launched from or coordinated with national patient channels? A standalone patient app will still make sense in many specialist scenarios, but “we need our own app” should no longer be the default assumption.
This creates both opportunity and risk for healthtech companies. Products designed as composable services that can operate inside a wider ecosystem may gain distribution. Products designed around controlling the entire patient journey themselves may find national infrastructure occupying more of that journey. The strategic objective should therefore be to identify the piece of the pathway in which the product creates distinctive value and make that capability exceptionally easy for the NHS to integrate, deploy and scale.
FHIR will inevitably feature prominently in discussions about the Single Patient Record. NHS digital architecture is already moving towards HL7 FHIR R4 and UK Core profiles for new interoperability services, and suppliers should expect structured, standards-based exchange to become progressively more important. But the most significant technical mistake a supplier could make is to reduce Single Patient Record readiness to a checkbox labelled “FHIR API”.
FHIR defines a way of representing and exchanging healthcare information. It does not magically resolve disagreements about what a piece of information means, which system is authoritative, how records should be reconciled or what should happen when information changes. Two applications can produce technically valid FHIR resources and still create an unsafe integration if their interpretation of the underlying clinical information differs. Suppliers therefore need semantic interoperability as well as syntactic interoperability. That means recognised terminologies, controlled value sets, consistent units, explicit statuses and well-understood mappings between local and national information models.
Patient identity is another fundamental dependency. A national record can only be trusted if information is associated with the correct person. Suppliers should already treat the NHS number as a critical identifier while recognising that real-world identity management is more complicated than storing a ten-digit value. Records can contain missing identifiers, demographic discrepancies, duplicate registrations or historic errors. Products that create, match, update or exchange patient information need robust processes for identity verification, demographic synchronisation and handling exceptions. At national scale, a seemingly minor matching weakness becomes a patient-safety problem.
Provenance will become equally important. Imagine that a clinician sees three medication entries, two diagnoses and a recent test result gathered from several organisations. They need more than the values themselves. They need to understand where the information came from, when it was recorded, whether it remains current and, in some circumstances, which professional or organisation was responsible for it. If multiple systems can contribute information to a longitudinal view, the ability to establish provenance is essential for resolving conflicts. Digital health suppliers should therefore treat source, timestamp, author, status and version history as meaningful clinical metadata rather than optional technical decoration.
This leads directly to one of the hardest architectural questions: what happens when information changes? Reading data is relatively straightforward compared with managing updates safely. If an allergy is corrected in one organisation, should the correction propagate elsewhere? If a patient updates information through a digital service, which system becomes responsible for validating it? If two systems disagree about a medication, which entry should be presented? If a diagnosis is entered incorrectly and later amended, how should applications that previously consumed the original data respond? The Single Patient Record raises questions about the lifecycle of information, not simply its availability.
Suppliers should therefore assess their products across several capabilities:
The second set of questions is particularly important because interoperability failure does not always look like a broken interface. The dangerous failures are often subtler. An API can return HTTP 200 while the information displayed to a clinician is stale. A message can be delivered successfully while its code has been mapped incorrectly. Two records can be linked technically while referring to different people. A system can retrieve the correct information while presenting so much of it that clinically important information becomes harder to find. Integration testing must therefore assess clinical behaviour and human factors, not simply endpoint availability.
Security and access control will also have to become more granular. The ambition for the Single Patient Record includes role-based access and stronger auditability. In practical terms, “connected to the NHS” cannot mean every authenticated user can retrieve every available field. Different professionals require different information for different purposes. Emergency access may need to behave differently from routine access. Sensitive categories of information may require additional consideration. Suppliers should design authorisation around the principle that applications and users receive the information they need to perform a legitimate task, rather than treating access as an all-or-nothing decision.
Auditability should be designed with similar seriousness. In a more connected ecosystem, it must be possible to understand who accessed information, through which application, for what context and when. This becomes especially important when data is displayed through third-party applications rather than directly within the source system. Suppliers that maintain detailed, interoperable audit capabilities will be better positioned than products where logging was designed primarily for debugging.
Data quality is perhaps the least glamorous but most important issue of all. Connecting fragmented datasets does not automatically create one reliable truth. It can expose decades of inconsistencies. The same condition may be coded differently, repeated, entered as free text or recorded at different levels of specificity. Historic medication records may conflict with current prescribing information. Addresses and demographic details change. Legacy systems may contain information that was designed to make sense only in the workflow in which it was created.
For suppliers, this means data normalisation cannot simply be outsourced to the national programme. Every organisation contributing information has a role in improving the quality and structure of what it produces. Software design influences that quality. Interfaces that encourage structured capture, terminology services that help users select appropriate concepts, validation rules that catch impossible values and workflows that distinguish provisional from confirmed information all affect the usefulness of a national record. Better interoperability begins at the point of data creation.
There is also an important architectural principle hidden inside the NHS’s stated intention to avoid creating additional interfaces for frontline staff unless existing ones can be removed. The Single Patient Record should not become another portal that clinicians must remember to open. Suppliers need to think about contextual integration: bringing relevant longitudinal information into the workflow where the user is already working. A clinician reviewing a patient in an EPR should not necessarily need to leave that EPR, sign into another service and search for the patient again. The technical challenge is therefore not only data exchange but workflow integration, context transfer, identity and presentation.
That principle becomes even more important as AI enters clinical systems. Generative AI, ambient voice technologies, risk models and clinical decision-support tools can become substantially more useful when they have access to richer longitudinal context, but the risks increase at the same time. An AI application consuming Single Patient Record information must be able to distinguish source data, uncertainty, historical entries and current information. It must not turn conflicting records into a falsely confident summary. Suppliers building AI for healthcare should therefore view provenance and structured interoperability as prerequisites for trustworthy intelligence, not secondary integration tasks to address after the model has been built.
Single Patient Record readiness is about more than FHIR compliance. Digital health suppliers preparing for the NHS Single Patient Record should focus on semantic interoperability, UK Core and FHIR standards, NHS number and patient identity, clinical terminology, data provenance, access controls and data quality. A technically connected system is only useful if the patient information it exchanges remains accurate, clinically meaningful and trustworthy wherever it is used across the NHS.
The implications of the Single Patient Record are not exclusively technical. One of the barriers identified during the programme’s early work is structural: data can be difficult to share because of contractual arrangements, questions of responsibility and supplier restrictions as well as technical limitations. That means procurement and contracting will become part of the interoperability problem. A technically capable API is of limited value if customers face prohibitive charges, lengthy professional-services engagements or contractual restrictions every time they want to use it.
Suppliers should consequently expect NHS buyers to become more interested in the practical openness of products. Procurement questions may increasingly examine standards compliance, interface documentation, data portability, exit arrangements, information-governance responsibilities, clinical safety and the commercial model for integration. A platform whose architecture creates dependency on proprietary interfaces may carry a different long-term risk profile from one designed around documented, standards-based exchange. The NHS’s desire to avoid vendor lock-in and make digital services easier to adopt is likely to reinforce this direction.
The Single Patient Record will also operate in one of the most sensitive information environments in the country. Public support for joined-up records has been accompanied by clear expectations around privacy, transparency, accountability and control. Suppliers therefore need to recognise that public trust is part of system performance. A technically secure product can still damage confidence if patients cannot understand what happens to their information, if access appears unnecessarily broad or if responsibilities are unclear.
For companies hoping to participate in the emerging ecosystem, several areas deserve particular attention:
There are unanswered governance questions around the Single Patient Record itself, including the precise future arrangements for data controllership and the detailed implementation of patient choice. Suppliers should resist the temptation to invent certainty where none yet exists. Instead, products should be architected so that access policies, consent or objection rules, data-sharing controls and retention requirements can evolve without requiring wholesale redevelopment. Configurability is particularly valuable when legislation and national policy are still being translated into operational rules.
The same principle applies commercially. Nobody yet knows exactly where all the opportunities created by the Single Patient Record will sit. Some functionality may be provided nationally, some regionally and some through existing system suppliers. There may be opportunities around integration, terminology, identity, clinical workflow, record presentation, data-quality tooling, patient engagement, specialist applications and assurance. But suppliers should not build a speculative “SPR product” simply because the programme is prominent. The more durable opportunity is to ensure that an existing product solves an important healthcare problem in a way that is compatible with the emerging architecture.
The biggest mistake suppliers could make is to wait for a final Single Patient Record specification before taking action. There will undoubtedly be requirements that cannot be implemented until the programme publishes more detail, but most of the underlying work is valuable regardless of the final architecture. A supplier that improves data models, adopts appropriate interoperability standards, strengthens terminology, documents APIs, improves provenance, removes proprietary dependencies, designs better audit controls and clarifies its information-governance responsibilities is not betting on one particular version of the SPR. It is making its product better suited to the direction in which the NHS has been moving for years.
The starting point should be a genuine interoperability assessment rather than a compliance exercise. Map the clinically important information your product creates, consumes and modifies. Identify which information is structured and which still exists primarily in documents or free text. Determine where local or proprietary codes are used. Understand which system is authoritative for each important data item. Examine how corrections propagate, how duplicates are handled and whether provenance survives when information is exported. Review what happens if an upstream service is unavailable or returns unexpected data. That exercise often exposes architectural risks long before a national programme does.
Suppliers should then separate their core clinical or operational capability from the mechanisms used to integrate it. Products that tightly couple business logic to one EPR’s proprietary interface become expensive to deploy elsewhere. An integration layer that can translate between external standards and a stable internal domain model can make products considerably more portable. The objective should not be to create abstraction for its own sake, but to prevent the details of one customer environment from becoming embedded throughout the product.
It is also worth reviewing product strategy from a more fundamental perspective. Ask what becomes more valuable if a clinician can obtain a reliable longitudinal view of the patient without using your product. If the answer is “not much”, the Single Patient Record is a strategic threat. If your product becomes substantially better because richer information is available, it is an opportunity. The most defensible digital health products will use shared information to improve a distinctive workflow or outcome rather than relying on information scarcity.
Consider, for example, a remote-monitoring platform. Its future value is unlikely to come from being the only place where remote-monitoring observations can be viewed. Its value may come from intelligently identifying deterioration, coordinating intervention and integrating those observations into the wider clinical pathway. A diagnostic platform creates greater value when its results can reach the clinicians responsible for subsequent care. A digital therapeutic becomes more useful when it can participate in the broader patient journey instead of operating as an isolated intervention. A specialist clinical application becomes more scalable when it can obtain relevant patient context and return structured outcomes without bespoke integration at every site.
Suppliers also need to engage with national developments earlier. The SPR programme has already used market engagement to understand supplier perspectives, including responses from organisations across the healthcare technology ecosystem. That engagement is important because some of the hardest problems cannot be solved by national policy or vendors independently. Standards that are theoretically elegant but impossible to implement across deployed software will not deliver interoperability. Conversely, preserving every historic supplier-specific behaviour because change is inconvenient will perpetuate fragmentation. Effective national infrastructure requires both sides to participate.
Product roadmaps should therefore distinguish between capabilities that can be improved now and interfaces that depend on emerging national specifications. A sensible near-term roadmap might include stronger FHIR R4 capability, UK Core alignment where appropriate, SNOMED CT and other relevant terminology support, improved API documentation, better event handling, explicit provenance, robust NHS number handling, auditable role-based access, clearer data-export functionality, enhanced clinical-safety processes and automated interoperability testing. None of those investments depends entirely on one final SPR design.
Suppliers should also prepare their organisations, not just their software. Sales teams need to understand interoperability well enough not to make claims engineering cannot support. Product teams need clinical informatics expertise when defining information models. Developers need to understand that healthcare data cannot always be treated like ordinary application state. Information-governance specialists need to be involved before architecture has been fixed. Clinical safety officers need visibility of integration behaviours that could introduce hazards. Commercial teams need to understand when interface pricing or restrictive contract terms undermine the product’s strategic position.
Most importantly, suppliers should avoid treating the Single Patient Record as another mandatory integration project to place at the bottom of a backlog. Its real significance is what it says about the NHS that digital health companies will be selling into over the next decade. The direction is towards an NHS in which information needs to follow patients, national infrastructure provides more reusable capabilities, patients interact increasingly through the NHS App, systems are expected to support open standards and digital products must demonstrate how they fit into end-to-end clinical pathways.
For some suppliers, that will require relatively modest technical changes. For others, it will challenge long-standing business models and architectures. Products built around proprietary datasets, closed interfaces or repeated bespoke integration may have to change substantially. Companies that have already invested in standards, composable architecture and reusable integration will have an advantage, but even they will need to address difficult questions around data authority, reconciliation, provenance and workflow.
The opportunity is significant. A healthtech company that currently spends months integrating with every new provider could eventually benefit from more predictable routes to the information its product requires. Specialist applications could become easier to deploy across organisational boundaries. Clinicians could receive more complete information without leaving their normal workflows. Patient-facing tools could interact with a more coherent digital ecosystem. AI products could operate with richer context. New digital pathways could be assembled from interoperable components rather than built as isolated vertical systems.
But none of those benefits will be delivered merely by connecting more databases. The Single Patient Record will succeed only if information is trustworthy enough to act upon. That means accurate identity, clinically meaningful structure, consistent terminology, clear provenance, sensible access controls, reliable synchronisation and interfaces designed around actual care. Those are precisely the areas in which suppliers will have an increasingly important responsibility.
The name “Single Patient Record” may ultimately prove slightly misleading. The important change is not that the NHS will suddenly possess one record where previously it possessed many. It is that the boundaries between those records should matter less to the people delivering and receiving care. A clinician should not need to understand which organisation owns which server in order to find an allergy. A patient should not have to remember which portal contains a test result. A community team should not have to phone a hospital to discover information that already exists digitally. Technology should make organisational boundaries less visible in the experience of care.
For digital health suppliers, that is the real strategic message. The next generation of successful NHS technology will not be defined solely by what happens inside an application. It will be defined by how safely and effectively that application participates in a wider system.
The Single Patient Record is still evolving, and important architectural, regulatory and governance decisions remain to be made. Suppliers should follow those developments closely rather than making assumptions about the final implementation. But waiting for complete certainty would miss the larger point. The standards, capabilities and design principles needed to prepare for the SPR are also the capabilities needed to build better NHS software today.
The suppliers best prepared for the Single Patient Record will therefore not necessarily be those that react fastest when a final API specification appears. They will be those that have already designed their products around a more fundamental principle: patient information should be able to move safely to wherever it creates legitimate clinical value, without losing its meaning, its provenance or the trust of the person it describes.
Is the NHS Single Patient Record the same as the Federated Data Platform?
No. The NHS Federated Data Platform primarily supports operational uses such as managing waiting lists, discharges and hospital capacity. The NHS Single Patient Record is intended to provide patients and authorised health and care professionals with access to relevant longitudinal health information across care settings.
Will private healthcare providers and digital health suppliers have to connect to the NHS Single Patient Record?
Potentially. The government has stated that public and private health and social care providers, along with their IT suppliers, will be required to share relevant information with the Single Patient Record. The precise technical and contractual requirements are still being developed, making emerging NHS interoperability standards important for suppliers to monitor.
Could NHS Single Patient Record data be used for medical research?
Yes, potentially. The proposed legal framework allows Single Patient Record information to be used for approved research and planning under the same legal, ethical and governance protections that apply to other NHS health data. The NHS National Data Opt-out applies to certain secondary uses of confidential patient information rather than information used for an individual’s direct care.
Will wearable devices and genomic data be included in the NHS Single Patient Record?
The NHS has identified both as part of its longer-term direction. NHS England says the Single Patient Record could incorporate data from wearable devices and, in future, genomic records, supporting more personalised and preventative healthcare. This could create new interoperability opportunities for digital health, remote monitoring and connected medical-device suppliers.
How secure will the NHS Single Patient Record need to be?
The government expects the Single Patient Record to be assessed as critical national infrastructure, reflecting the sensitivity and national importance of NHS patient data. Suppliers interacting with the SPR should therefore expect cyber security, identity, access control, auditability and secure-by-design architecture to receive significant scrutiny as technical requirements mature.
Is your team looking for help with digital health strategy and consultation? Click the button below.
Get in touch