The NHS Single Patient Record could be the most consequential change to England's digital health infrastructure in decades. It brings together the information held about a patient so the right professional can see it wherever that patient is being treated, and give patients the same view through the NHS App. A patient's information sits scattered across GP systems, hospital EPRs, labs, pharmacy, community and mental health services, social care platforms and specialist applications. It exists. It just does not travel with the patient.

If you take one thing from this, take this. The Single Patient Record is an interoperability programme, not a bigger database. Getting it right is less about building one more API and more about identity, provenance, data lifecycle and access control, with the code as the easy part underneath. Suppliers who treat those as first-class problems now will be in a stronger position than the ones waiting for a final specification.

It is an interoperability programme, not a bigger database

The name invites the wrong picture. It sounds like the NHS will replace every clinical system with one central application holding everything about everyone. That is not the plan. Information stays in the systems where it was created, whether that ends up being a central interface over existing shared care records, a centrally managed store, or a virtual layer that retrieves information behind the scenes.

The NHS already stores enormous amounts of patient information. The hard problem is getting the right information to the right person at the right moment, with enough context to mean something clinically and enough control for people to trust it. A lab result with no provenance or an allergy recorded differently in two systems creates more confusion, not less.

The ambition here is national, not regional, so the real question for a supplier is not 'does our system hold this information' but 'can this information safely take part in the wider health and care system.' A product can still own a brilliant workflow, but the data it produces increasingly needs to be usable elsewhere, and it may need to consume authoritative information created by other systems too.

What changes for suppliers

For established EPR and clinical system vendors, this raises the value of being open. An EPR stays critical because it runs the clinical workflow, but it becomes harder to justify important information staying trapped inside it. For specialist suppliers, this is closer to an opening. A national information layer could cut one of the biggest costs in scaling healthcare technology, rebuilding the same integration every time a product enters a new trust.

That does not mean integration gets easy. Suppliers will be operating across modern FHIR APIs, older HL7 messages and proprietary EPR interfaces all at once, because organisations modernise at different speeds. The ones who do well will not just support the newest standard, they will know how to work safely across several generations of NHS architecture while keeping a clear route to the future state.

The NHS App matters here too. Patients are expected to access their record through it from 2028, and the App is becoming a much broader front door into planned care, triage and approved digital tools. 'We need our own app' stops being the automatic default.

The technical work goes well beyond calling an API

FHIR will feature in every conversation about this programme, and NHS architecture is already moving toward HL7 FHIR R4 and UK Core profiles. But the biggest mistake a supplier can make is reducing readiness to a checkbox that says 'FHIR API done.' FHIR does not resolve disagreement about what a piece of information means or what happens when it changes. Two applications can produce technically valid FHIR resources and still create an unsafe integration if their interpretation of the underlying clinical fact differs.

Five things decide whether this works in practice. Patient identity, because real-world identity is messier than a ten-digit NHS number. Provenance, source, timestamp, author and status, so a clinician can resolve conflicts between what several systems are saying. Data lifecycle, because reading is the easy half and managing a correction safely is the hard part. Access control and audit, since 'connected to the NHS' cannot mean every field for every user. And data quality, because joining fragmented datasets together does not create one reliable truth by itself.

Security and access control need to get more detailed too, and auditability has to be designed with the same seriousness. It has to be possible to say who accessed what, through which application, and when, especially once data is shown through third-party applications rather than the source system itself.

Procurement and governance have to catch up too

None of this is purely technical. NHS England has already flagged a structural barrier, data can be hard to share because of contracts and supplier restrictions, not just technical limits. Expect buyers to ask harder questions about how open a product actually is, standards compliance, data portability, exit terms, the commercial model behind integration. A platform built around proprietary interfaces carries a different long-term risk than one built on documented, standards-based exchange.

Information governance, UK GDPR compliance, clinical safety processes including DCB0129 where relevant, and transparent data processing should be product capabilities built in from the start, not documents assembled before a procurement deadline. Some governance questions, like exactly how data controllership will work, are still open, so build products so access policies can change without a full rebuild.

What to do now

The biggest mistake a supplier can make is waiting for a final specification before doing anything. Most of the underlying work, better data models, documented APIs, stronger provenance, cleaner audit trails, is worth doing regardless of the final architecture. Start with an honest interoperability review rather than a compliance exercise. Map the clinically important information your product creates and consumes, and check what happens when an upstream service returns something unexpected.

A short checklist before you call it ready

• Identity. NHS number handling that's solid, not just present, with exception handling for deceased or superseded records.
• Provenance. Source, timestamp, author and status persisted alongside anything cached.
• Governance. DSPT complete, DCB0129 artefacts maintained as living documents.
• Engineering. One integration layer between external standards and a stable internal model, rate limits assumed by design.
• Commercial. Interface pricing and contract terms checked against whether they undermine the product's own position.

The name "Single Patient Record" might end up slightly misleading. The real change is not that the NHS suddenly has one record where it used to have many. It is that the boundaries between those records should matter less to the people delivering and receiving care.