Records that are clean, matched and published to national standards before the Single Patient Record arrives. AI finds the problems; people fix them, and nothing merges itself.
At a glance
An illustrative scenario. The numbers are typical examples, not a client case study. The cloud services and UK rules were checked on 9 November 2026.
The Single Patient Record is coming, and the legal basis is going through Parliament now. The Health Bill (in Lords committee as of 9 November 2026) gives the Secretary of State power to make regulations that set up a system making patient information readily available to patients and to the people caring for them. The regulations can require providers to share information, can say that sharing under them doesn't breach a duty of confidence, and can allow financial penalties. The government's fact sheet says data will, where possible, stay in the systems where it was created, with the Single Patient Record connecting to existing patient records and shared care records rather than replacing them.
For a trust, that means its records will be read by clinicians who have never seen its systems. Today they live in an EPR, a community system, a maternity system and a pharmacy system, each with its own local codes. Some patients have two hospital numbers. Some emergency and unknown patients never had their NHS number traced. Allergies are recorded as free text in one system and coded in another. Inside the trust, staff know these quirks and work around them. Once the record is shared, a duplicate, a wrong allergy or a medicine with a local name follows the patient across England.
The timetable is tight and the detail isn't settled. The government's target is the Single Patient Record in the NHS App by December 2028, starting with maternity and frailty, and NHS England is still testing technical approaches. Trusts can't wait for the regulations to start on data quality, matching and standards, because that work takes years. They also can't build to an architecture nobody has chosen. The answer is to fix what is certain to matter: verified NHS numbers, national codes, standard FHIR resources and clean audit trails.
Agree these, and measure the baseline, before anything is built. Example targets are typical, not promises.
Share of active patient records with an NHS number traced and verified against the Personal Demographics Service.
ExampleAbove 99.5%
Possible duplicate records waiting for review, and how long they wait.
ExampleFalling month on month, none older than 30 days
Share of allergies, diagnoses and medicines recorded with SNOMED CT or dm+d codes, not local codes or free text.
ExampleAbove 95% for the pilot pathway
Share of published resources that pass validation against the UK Core profiles first time.
ExampleAbove 98%
How often the coding team accepts a suggested mapping. Very high can mean people have stopped checking.
ExampleStable, and reviewed monthly
Share of retrieval queries made by a user with a recorded care relationship to the patient, checked by sampling.
ExampleEvery query logged; exceptions investigated
Cross-sector rules are on the UK regulation map.
Going through Parliament. Regulations will say who must share what, and can override the duty of confidence for that sharing and allow financial penalties, with a notice, a chance to respond and an appeal to the First-tier Tribunal. The Secretary of State must consult before making them. Build the publishing pipeline so what is shared is configuration, ready for whatever the regulations require.
Data stays at source where possible, connecting existing records and shared care records. Access is tiered and role-based with audit trails. GPs and hospitals stay responsible for the data they hold, and future responsibility arrangements are still being worked out. Keep your own system as the master, publish from it, and keep an audit trail you can hand over.
Sharing for direct care sits on public task and health care conditions (Articles 6(1)(e) and 9(2)(h)). Until the regulations are made, the existing rules apply in full. A DPIA covers the data quality work, the matching and the retrieval assistant, and nothing is processed outside UK regions.
The eight Caldicott principles (December 2020) apply: use the minimum necessary, on a need-to-know basis, and tell patients. The national data opt-out doesn't apply to direct care. The fact sheet says the Bill creates no new route for planning or research uses: those still need an existing legal basis, where the opt-out can apply. So the retrieval assistant serves direct care only.
In force since 5 February 2026, the information standards for health and adult social care now reach IT providers, not just care providers. Conform to FHIR UK Core, SNOMED CT, dm+d and the NHS number standard, and ask your EPR supplier for evidence of conformance. The Health Bill moves NHS England's information functions to the Secretary of State.
The new integration and AI services are covered in the trust's annual Data Security and Protection Toolkit submission. Matching, mapping and publishing errors are clinical hazards, so they go in a hazard log and safety case owned by a clinical safety officer. The clinical safety standards are under review (consultation closed 11 September 2026).
Showing AWSAzuresovereign / on-prem services. Switch with the toggle; every diagram and table on this page follows it.
01Channels
02Intake
03Intelligence
04Orchestration
05Systems of record
06People
| Layer | AWS | Azure | Sovereign / on-prem |
|---|---|---|---|
| Events from clinical systemsUse the integration engine you already run. It already knows your systems' messages; the new work is publishing them as FHIR. | API Gateway, EventBridge | API Management, Event Grid | Kong or your existing API gateway; Apache Kafka |
| FHIR store and facadeProfile everything against FHIR UK Core. Azure API for FHIR retired on 30 September 2026; new builds use the FHIR service in Azure Health Data Services. | AWS HealthLake | Azure Health Data Services FHIR service | An open-source FHIR server (e.g. HAPI FHIR) on Kubernetes |
| Record matchingDeterministic rules on a verified NHS number and agreed demographics. No machine-learning auto-merge: uncertain cases go to a person. | AWS Entity Resolution (rule-based matching only), plus PDS lookups | Rules in Azure Functions, plus PDS lookups | Rules in your integration engine or a small matching service, plus PDS lookups |
| TerminologyMappings are suggested with evidence and approved by clinical coding. Keep the approved map versioned. | The NHS England terminology server, called from the workflow | The NHS England terminology server, called from the workflow | The NHS England terminology server, or a local copy of SNOMED CT and dm+d releases |
| Reasoning and summariesExplains data quality findings and drafts mapping evidence. Both clouds offer a choice of models, including Claude. | Amazon Bedrock | Microsoft Foundry | Open-weight models served with vLLM on your own GPUs, or IONOS AI Model Hub |
| Retrieval over the recordRead-only, filtered by the user's role and care relationship at query time, and every answer links to its source entries. | Bedrock Knowledge Bases | Foundry IQ, built on Azure AI Search | OpenSearch, or PostgreSQL with pgvector |
| Agent runtimeThe original Bedrock Agents closed to new customers on 30 July 2026; new builds use AgentCore. | Amazon Bedrock AgentCore | Foundry Agent Service | An open-source agent framework (e.g. LangGraph) on Kubernetes |
| WorkflowPublishing is deterministic and doesn't depend on the AI. If the agents are switched off, records still flow. | AWS Step Functions | Logic Apps or Durable Functions | Temporal |
| Middleware and events | Amazon EventBridge, SQS | Event Grid, Service Bus | Apache Kafka or RabbitMQ |
| GuardrailsThe retrieval assistant refuses to answer without a source and never gives treatment advice. | Bedrock Guardrails | Foundry guardrails (Azure AI Content Safety) | Open-source guardrails (e.g. NeMo Guardrails, Llama Guard) |
| Identity, keys, data protectionAccess decisions use the user's role and care relationship from the EPR, enforced by the platform, not by the prompt. | IAM Identity Center, KMS, Macie, Amazon Verified Permissions | Entra ID, Key Vault, Purview | Keycloak or your existing Active Directory; OpenBao or HashiCorp Vault; an HSM |
| Monitoring and auditLog every query, every finding, every suggested and approved mapping, every match decision and who made it. | CloudWatch, CloudTrail | Azure Monitor, Log Analytics | Prometheus, Grafana, OpenTelemetry |
| UK data residencyThis is NHS patient data. Expect UK residency to be required, so an EU-hosted option may not fit. | eu-west-2 (London) | UK South / UK West | Your own UK data centre, or a UK or EU provider (IONOS AI Model Hub runs in Germany) |
On a phone, the table shows the platform you pick. Sovereign / on-prem means open, portable components you can run in your own data centre or with a UK or European provider; IONOS is shown as one example, and others exist. What sovereign cloud means →
Many organisations keep core systems and sensitive data on their own servers. This is how the same design works across both.
Stays on-prem
The EPR, the community, maternity and pharmacy systems, and the integration engine stay where they are. Many trusts also keep the FHIR facade on-prem, close to the EPR. Merges, unmerges and clinical changes are only ever made in the source systems, by people.
Uses cloud AI
Data quality analysis, mapping suggestions and the retrieval assistant can run in a UK cloud region, or on the trust's own GPUs for the sovereign option. They work on extracts and the FHIR store, never with write access to a clinical system.
How they connect
Through the integration engine and an API gateway, over a private link such as AWS Direct Connect or Azure ExpressRoute, or the HSCN where national services require it. Findings and suggestions come back as tasks in the teams' existing work queues.
If the link drops
Publishing to the shared care record carries on, because it runs through the integration engine and doesn't depend on the AI. Data quality checks and mapping suggestions pause and catch up later. Clinicians use the record viewers they already have.
What each agent may do through its tools, what it may not, and where a person signs off. The limits are enforced by the platform, not the prompt.
Data quality and matching agent
Where a person signs offA trained member of the data quality team decides every uncertain match and makes every merge in the source system. The agent's permissions are enforced by the platform's identity and policy controls, not by instructions in a prompt.
Code mapping assistant
Where a person signs offThe clinical coding team approves every mapping, and a clinician reviews any that affect allergies, medicines or safety alerts.
Record retrieval assistant (read-only)
Where a person signs offThe clinician reads the sources and makes every decision. The Caldicott Guardian's team samples the access log every month.
The integration engine stays the hub. It already receives admissions, results, medicines and discharge messages from each system. The new layer turns those into FHIR UK Core resources, validates them, and publishes them as events: to the shared care record now, and to the Single Patient Record when its interfaces are published. Every event carries an ID, so a retry never creates a duplicate entry.
Matching runs before publishing. A record goes out only with an NHS number traced against the Personal Demographics Service. Records that fail wait in a queue for the data quality team, and the integration engine keeps working for everything else.
Consuming works the same way in reverse. Data from the shared record is read through its published interfaces, cached only as the data sharing agreement allows, and shown in the EPR with its source. The retrieval assistant indexes only what the user could already see, and checks permissions again at query time.
Profile data quality across every system, measure NHS number coverage and duplicates, map today's integration flows, and agree the first pathway with the shared care record partnership.
Gate · must be true to passBaseline agreed, Caldicott Guardian and IG support, clinical safety officer named, DPIA and hazard log started.
One pathway, such as maternity or frailty: data quality checks, matching and mapping suggestions in shadow mode, and FHIR publishing to a test endpoint.
Gate · must be true to passValidation pass rate and matching accuracy within agreed limits, no unreviewed uncertain matches, coding team sign-off.
Live publishing for the pilot pathway to the shared care record, with data quality queues running and the retrieval assistant for a small clinical group.
Gate · must be true to passMonitoring, support model, rollback plan, access audit and clinician training in place.
Add pathways, then connect to the Single Patient Record as its interfaces and regulations are published.
Gate · must be true to passEach new pathway passes the same pilot gate.
| Activity | Chief clinical information officer | Product owner | Solutions architectI can fill this | Technical PMI can fill this | EngineersI can fill this | Clinical safety officer | Caldicott Guardian & IG | SecurityI can fill this |
|---|---|---|---|---|---|---|---|---|
| Readiness plan and benefits | Accountable | Responsible | Consulted | Consulted | Informed | Consulted | Consulted | Informed |
| Target architecture and integration | Consulted | Consulted | Accountable and Responsible | Consulted | Consulted | Consulted | Consulted | Consulted |
| Matching rules and merge process | Accountable | Responsible | Consulted | Informed | Consulted | Consulted | Consulted | Informed |
| DPIA, data sharing and access audit | Consulted | Consulted | Consulted | Informed | Informed | Consulted | Accountable and Responsible | Consulted |
| Clinical safety case and hazard log | Accountable | Consulted | Consulted | Informed | Consulted | Responsible | Informed | Consulted |
| Build, FHIR profiling and integration | Informed | Consulted | Accountable | Responsible | Responsible | Consulted | Informed | Consulted |
| Go-live decision | Accountable | Responsible | Consulted | Responsible | Informed | Consulted | Consulted | Consulted |
| Run, monitor and improve | Accountable | Responsible | Consulted | Consulted | Responsible | Consulted | Consulted | Consulted |
R ResponsibleA AccountableC ConsultedI Informed· not involved
Option A
If there's no architect on the programme, I'd own the readiness design end to end: the integration engine's FHIR layer, the matching and data quality workflow, the retrieval assistant and the gates, working closely with your Caldicott Guardian and clinical safety officer. I'd report to your programme board and your chief clinical information officer.
Option B
If your partner, your EPR supplier or your own team already has an architect, I'd take on the event publishing, the matching workflow and the data quality agents under their lead, and give them a second senior opinion on FHIR profiling, security and the clinical safety evidence.
Goes wrong
Two patients with similar names are merged automatically, and one inherits the other's allergies.
How the design avoids it
Deterministic rules on a verified NHS number, a person for every uncertain match, and merges only in the source system.
Goes wrong
A local allergy code is mapped to the wrong SNOMED CT concept, and the error spreads to every system reading the record.
How the design avoids it
Suggestions with evidence, approval by clinical coding with a clinician for safety-critical codes, and a versioned map.
Goes wrong
The trust builds to a guess about the national architecture, and has to rebuild when it is chosen.
How the design avoids it
Invest in what any approach needs: verified NHS numbers, national codes, UK Core resources and events. Keep the connection to the national service thin.
Goes wrong
The retrieval assistant becomes a way to browse records without a care relationship.
How the design avoids it
Permissions checked at query time by the platform, no bulk queries, and a monthly access audit.
Goes wrong
Data quality is treated as a one-off clean-up before go-live.
How the design avoids it
Checks run on every change, with owners and queues, so new errors are caught as they are made.
Changes already announced or under way that affect this design. More in the UK horizon scan.
Respond to the consultation through your partnership, and keep what you publish as configuration so the regulations become a change, not a rebuild.
Publish your pilot pathway to your shared care record now. It is the route the Single Patient Record plans to connect to.
Check that onboarding agreements, data sharing agreements and contracts name the right body, and track interface changes.
Get the maternity and frailty data clean and coded first, since patients will see it too.
Plan the data quality and mapping work pathway by pathway, reusing the same pipeline.
Good answers are specific. Vague answers to any of these are worth following up.
Whether you need someone to lead the design or to support the architect you already have, let's talk it through.
