UK Government Pushes Single Patient Record Amid Data‑Chaos Concerns

The King’s Speech on 13 May 2026 announced that the upcoming NHS Modernisation Bill will embed a Single Patient Record (SPR) into law. In theory the SPR will aggregate a patient’s primary‑care notes, hospital episodes, social‑care plans and even historic paper records into a single, searchable repository that can be accessed via the NHS App.

---

What the SPR is supposed to do

Goal	Expected Benefit
Unified view	Clinicians can see the full care trajectory without juggling disparate systems.
Patient access	Individuals can read, download and share their own record from the NHS App, improving self‑management.
Automated triage	Structured data feeds AI‑driven decision support, potentially lowering variation in referrals.
Cross‑sector sharing	Paramedics, community pharmacists and social workers gain read‑only access, reducing duplication.

The impact statement released in January estimates £10 bn of public funding for development, integration and ongoing governance. The rollout schedule targets maternity and frailty pathways by 2028, with a staged expansion to all specialties thereafter.

---

Architecture options on the table

Two competing technical approaches have emerged from the NHS Digital procurement brief:

1. Centralised data lake – a monolithic repository that ingests raw HL7/FHIR feeds from every NHS Trust, GP practice and social‑care provider. The lake would be hosted on a public‑cloud vendor (currently unspecified) and accessed through a bespoke UI.
2. Federated Data Platform (FDP) – an API‑gateway layer that leaves source systems in‑place but normalises requests via a Palantir‑run orchestration engine. The FDP would expose a single‑call summary endpoint that aggregates data on demand, avoiding a full data copy.

Both designs must meet the same core requirements:

• FHIR‑compliant data model – to guarantee interoperability with existing EPRs such as Cerner, Epic, and the NHS’s own Lorenzo.
• Role‑based access control (RBAC) – clinicians get read‑only views; administrators can audit every query.
• End‑to‑end encryption – TLS 1.3 for transport, AES‑256 at rest, with hardware security modules (HSMs) for key management.
• Audit‑trail visibility – every access must be logged and exposed to the patient via the NHS App.

---

Power consumption and cost implications

A rough capacity model for a national‑scale SPR (≈ 70 million citizens, 5 TB average per patient) yields 350 EB of raw storage. Assuming a 30 % compression factor using columnar Parquet files, the effective footprint drops to ≈ 120 EB.

Component	Approx. Power (MW)	Annual Energy (MWh)	Rough Cost (£/yr)
Centralised storage cluster (10 k servers)	12	105 600	9 M
FDP API‑gateway layer (2 k VMs)	3	26 400	2 M
Network fabric (core routers, 100 GbE)	4	35 200	3 M
Total	19	167 200	≈ £14 M

These figures are ball‑park; they exclude cooling overhead and the cost of additional compute needed for AI‑driven triage models (estimated at another 5 MW). The centralised lake option consumes roughly 40 % more power than the federated approach because of constant data replication and indexing.

---

Compatibility and integration challenges

Challenge	Why it matters	Mitigation strategy
Legacy EHR heterogeneity	Over 200 different systems still use proprietary schemas.	Deploy a FHIR‑conversion micro‑service per vendor; use open‑source tooling like HAPI FHIR to minimise custom code.
Terminology mapping	Clinical codes (SNOMED‑CT, Read v2, ICD‑10) need translation to patient‑friendly language.	Build a terminology service that leverages the NHS Digital SNOMED‑CT API and a natural‑language generation layer for plain English summaries.
Data‑controller ambiguity	Current law makes GPs the controller; SPR would shift that role to NHS England.	Draft a statutory amendment that designates NHS England as custodian while preserving GP‑level consent flags.
Vendor lock‑in risk	Palantir’s FDP could become the de‑facto platform, limiting future migration.	Insist on open API contracts (OpenAPI 3.0) and data export rights every 12 months, as stipulated in the procurement clause.

---

What clinicians are flagging

• Audit‑trail transparency – Doctors want the NHS App to show who accessed a record, when and for what purpose. Without this, patient trust erodes.
• Performance latency – Real‑time access in emergency departments must stay under 200 ms for a full‑record fetch; any higher and it becomes a safety risk.
• Clinical workflow integration – The SPR UI must embed into existing PACS, RIS and pharmacy systems via SMART on FHIR launchers, otherwise clinicians will revert to legacy portals.

---

Building a homelab‑style testbed

For IT teams that want to experiment before the national rollout, the following stack reproduces the core SPR functions on a modest budget:

1. Kubernetes cluster (4‑node, 8 CPU/32 GB RAM each) – orchestrates micro‑services.
2. PostgreSQL + TimescaleDB – stores structured FHIR resources and time‑series vitals.
3. HAPI FHIR Server – provides a standards‑compliant REST API.
4. Open Policy Agent (OPA) – enforces RBAC policies per user role.
5. Prometheus + Grafana – monitors latency; set alerts for > 200 ms response times.
6. Keycloak – handles OAuth2 authentication, mirroring the NHS App flow.
7. Palantir Foundry sandbox (if available) – can be swapped in for the FDP layer to test API‑gateway behaviour.

Deploy the stack with Helm charts, seed synthetic patient data (≈ 10 k records) using the FHIR Bulk Data Generator, and run a k6 load test simulating 1 000 concurrent clinicians. Expect ~150 ms median latency on a well‑tuned query, demonstrating feasibility before scaling to the national level.

---

Outlook

The SPR promises a single source of truth for patient care, but the path forward is littered with technical and governance hurdles. If the government can lock down transparent audit logs, enforce open‑API contracts and avoid a single‑vendor dependency, the SPR could finally deliver the integrated care that has eluded NHS digital projects for two decades.

Until those safeguards are codified, clinicians like Dr Emma Runswick and Dr Katie Bramall will remain sceptical, and patients may continue to opt‑out of secondary data uses. The next parliamentary session will likely host the first substantive debate on who controls the data and how the system will be policed – the outcomes of which will determine whether the SPR becomes a functional reality or another costly footnote in NHS IT history.