A waiting list that matches reality: data errors found every night, patients asked whether they still need care, and a person confirming every change. Clinical validation stays with clinicians.
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.
An acute trust's referral-to-treatment (RTT) waiting list is a live list of open pathways, often tens of thousands of them, held in the PAS or EPR. Over time it drifts from reality. There are duplicate pathways from re-referrals, clocks left running after the first treatment, planned and follow-up patients sitting on RTT pathways, patients treated by another provider or privately, patients who have moved away or died, and patients whose symptoms have gone and who no longer want treatment.
Validation keeps the list true. NHS England's guidance describes three stages: technical validation to find data errors, administrative validation that contacts the patient or carer, and clinical validation where a clinician reviews the record. Contact can be by text, e-form or online conversation, with a letter or phone call where the patient needs one. 2025/26 planning guidance asked trusts to validate RTT patients after 12 weeks on the list and every 12 weeks after that. Done by hand, this means validators working through PTL extracts line by line, chasing replies and passing cases to clinicians, with the evidence often kept in spreadsheets.
The stakes have risen. NHS England's planning framework asks for 70% of patients to be treated within 18 weeks by March 2027 and 92% by March 2029. A clean list helps patients and planning, but only if every removal is right, and can be shown to be right.
Agree these, and measure the baseline, before anything is built. Example targets are typical, not promises.
Share of pathways open more than 12 weeks that have been validated in the past 12 weeks.
ExampleAbove 90%
Removals later reversed, or patients re-referred for the same condition within six months, found by audit.
ExampleFalling, reviewed monthly
Time to confirm or reject a proposed correction, compared with checking by hand.
ExampleDown by half
Response and removal rates by age, deprivation, language and digital access. A low response must never mean fewer patients treated.
ExampleNo group worse off
Replies saying symptoms are worse, reviewed by a clinician within the agreed time.
ExampleEvery one, within one working day
New duplicates and clock errors found each week, by cause. Should fall as the causes are fixed.
ExampleFalling month on month
Cross-sector rules are on the UK regulation map.
Clocks start, stop and are removed only for the reasons in the national rules and the trust's access policy. The rules and policy are held as versioned knowledge, and every proposed correction names the rule it relies on. Monthly returns no longer allow clock pauses, so the AI never proposes one. Every removal keeps an evidence trail for audit: the finding or the patient's reply, the clinician's decision where needed, and who confirmed it.
The design follows the three stages: technical, administrative and clinical. Patient contact uses text, e-form or the NHS App, with letters and calls where needed. The date of last validation is recorded in the PAS, so it flows into the waiting list minimum data set.
Taking someone off a waiting list is a significant decision based on health data, which is special category data. Under the amended UK GDPR, solely automated significant decisions are still strictly limited where special category data is involved. Here a person confirms every removal, and every discharge letter tells the patient and their GP how to get back on the list if they need to.
Contacting a patient about their own place on the list is part of their care, so the national data opt-out doesn't apply to that. Using the list for anything beyond care, such as training or evaluating models for other purposes, needs its own legal basis and may need opt-outs applied. Get the Caldicott Guardian's view, and a DPIA, in discovery.
Removing a patient who still needs care is a clinical hazard. The trust deploys the tool under DCB0160, and under DCB0129 too if it builds it, with a clinical safety officer and a hazard log. The standards are under review. The system is covered in the trust's 2026-27 DSPT submission.
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 |
|---|---|---|---|
| Waiting list feedA nightly copy of open pathways and recent activity from the PAS. The AI works on the copy and never edits the PAS directly. | AWS Glue, Amazon RDS for PostgreSQL | Azure Data Factory, Azure Database for PostgreSQL | Apache Airflow or your existing ETL; PostgreSQL |
| Rules and matchingMost checks are plain, tested rules. Machine learning is used for fuzzy matching of duplicate pathways and for ranking findings, never for deciding who needs care. | Amazon SageMaker AI | Azure Machine Learning | MLflow and Kubeflow on Kubernetes |
| Reading repliesFree-text replies are sorted into a small, fixed set of outcomes. Anything unclear goes to a person. | Amazon Bedrock; Amazon Textract for scanned paper replies | Microsoft Foundry; Azure Content Understanding for scanned paper replies | Open-weight models served with vLLM on your own GPUs; Docling plus an open-weight vision model for scans |
| RTT rules and access policy (retrieval)The national rules suite, the recording and reporting guidance and the trust's access policy, versioned. Every finding cites the rule. | 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 |
| WorkflowRuns each campaign: who is due, which channel, reminders, follow-up by another route, and escalation. | AWS Step Functions | Logic Apps or Durable Functions | Temporal, or n8n |
| Middleware and events | Amazon EventBridge, SQS | Event Grid, Service Bus | Apache Kafka or RabbitMQ |
| Patient messagingNHS App message first where the patient uses the App, then text, then letter. Wording approved by the trust, with easy-read and translated versions. | NHS Notify, or the trust's existing patient messaging route | NHS Notify, or the trust's existing patient messaging route | NHS Notify, or the trust's existing patient messaging route |
| Link to the PAS / EPRConfirmed changes are made by the validator in the PAS, or through an interface your EPR supplier supports, under the validator's own identity. | Your existing integration engine | Your existing integration engine | Your existing integration engine |
| Human reviewValidators and clinicians review where they already work, not in a new screen. | In the validation team's existing PTL tool or EPR worklist | In the validation team's existing PTL tool or EPR worklist | In the validation team's existing PTL tool or EPR worklist |
| GuardrailsMessages to patients use approved templates only. The AI never writes free text to a patient. | Bedrock Guardrails | Foundry guardrails (Azure AI Content Safety) | Open-source guardrails (e.g. NeMo Guardrails, Llama Guard) |
| Identity, keys, data protectionThe agents have read access to the copy of the list, and no write access to the PAS. | IAM Identity Center, KMS, Macie | Entra ID, Key Vault, Purview | Keycloak or your existing Active Directory; OpenBao or HashiCorp Vault; an HSM |
| Monitoring and auditLog every finding, every message sent, every reply, and who confirmed each change, with the rule version. | CloudWatch, CloudTrail | Azure Monitor, Log Analytics | Prometheus, Grafana, OpenTelemetry |
| UK data residencyThis is NHS patient data. The trust's IG policy may require UK residency, so an EU-hosted option such as IONOS AI Model Hub (Germany) may not fit. | eu-west-2 (London) | UK South / UK West | Your own UK data centre, or a UK or EU provider |
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 PAS or EPR stays the waiting list of record, and every change is made there by a person. The integration engine and the trust's reporting stay where they are.
Uses cloud AI
The nightly checks, duplicate matching, reply reading and the agents run in a UK cloud region, or on the trust's own servers for the sovereign option. Only the fields needed for validation are copied, and the copy is refreshed, not kept.
How they connect
A nightly feed and the trust's integration engine, over HSCN or a private link such as AWS Direct Connect or Azure ExpressRoute. Findings come back to the validators' worklist as events.
If the link drops
Nothing on the waiting list changes, because only people change it. Validators carry on by hand as they did before, campaigns pause, and the nightly checks catch up when the link returns.
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.
Validation agent
Where a person signs offA validator confirms every correction, and a clinician makes every clinical validation decision. The agent has no write access to the PAS, enforced by the platform's identity and policy controls, not by instructions in a prompt.
Reply reader
Where a person signs offA person confirms every removal, including those the patient asked for, and the patient and GP get a letter saying how to come back onto the list.
The PAS or EPR stays the waiting list of record. The AI reads a nightly copy and proposes changes; people make them. If the trust already uses the NHS Federated Data Platform's RTT and patient-led validation products, use those for the list and the campaigns, and add only what they don't already do.
Patient contact goes through one messaging route with fallback, NHS App first, then text, then letter. Moving to the NHS App inbox for hospital letters, as it rolls out, is then a configuration change rather than a rebuild.
Events decouple the AI from the PAS. Each finding and each reply is a message on a queue with its own ID, so a retry never sends a patient two letters or creates two tasks. If the AI is paused, validation carries on by hand, exactly as before.
Map today's validation process, measure the baseline, agree the rules with the access team, confirm the messaging route, and get the Caldicott Guardian's view.
Gate · must be true to passBaseline agreed, rules signed off, DPIA and hazard log started, message templates approved.
Technical validation in shadow mode on two specialties, compared with validators' own findings, then one patient contact campaign.
Gate · must be true to passFinding accuracy within agreed limits, no wrongful removals in the audit, response rates checked by patient group, clinical safety case signed off.
Nightly checks and campaigns go live in the pilot specialties, with monitoring, support and a rollback plan.
Gate · must be true to passMonitoring, support model, rollback plan and validator training in place.
Add specialties in waves, then non-RTT follow-up lists and diagnostic waiting lists.
Gate · must be true to passEach new list passes the same pilot gate.
| Activity | Chief operating officer | Product owner | Solutions architectI can fill this | Technical PMI can fill this | EngineersI can fill this | Clinical safety officer | IG & Caldicott | SecurityI can fill this |
|---|---|---|---|---|---|---|---|---|
| Business case and benefits | Accountable | Responsible | Consulted | Consulted | Informed | Consulted | Informed | Informed |
| Target architecture and integration | Informed | Consulted | Accountable and Responsible | Consulted | Consulted | Consulted | Consulted | Consulted |
| Validation rules and access policy | Accountable | Responsible | Consulted | Informed | Consulted | Consulted | Informed | Informed |
| Clinical safety case and hazard log | Accountable | Consulted | Consulted | Informed | Consulted | Responsible | Informed | Informed |
| DPIA, Caldicott review and DSPT | Consulted | Consulted | Consulted | Informed | Informed | Consulted | Accountable and Responsible | Consulted |
| Build 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 design end to end: the waiting list feed, the rules and matching, the patient contact flow and the gates, working closely with your access team, your clinical safety officer and your Caldicott Guardian. I'd report to your programme board.
Option B
If your partner, your EPR supplier or your own team already has an architect, I'd take on the data pipeline, the rules engine and the agents under their lead, and give them a second senior opinion on integration with the PAS, the messaging route and the audit trail.
Goes wrong
No reply is treated as 'no longer needed', and the patients least able to reply drop off the list.
How the design avoids it
Nobody is removed for not replying. Follow up by another route, and monitor response and removal rates by patient group.
Goes wrong
Pathways are removed in bulk because the rule looked obvious.
How the design avoids it
A person confirms every change, batches stay small and grouped by rule, and a sample of each batch is re-checked.
Goes wrong
A reply saying 'it's got worse' waits in the same queue as the rest.
How the design avoids it
Worsening symptoms go to a clinician the same day, and that route is tested before the first campaign.
Goes wrong
The list is cleaned, but the same errors come back every month.
How the design avoids it
Report findings by cause, and fix them where they start: booking, coding and PAS configuration.
Goes wrong
The numbers improve, but nobody can show why each patient left the list.
How the design avoids it
An evidence trail for every removal: the rule or the reply, who confirmed it, and the letters sent to the patient and GP.
Changes already announced or under way that affect this design. More in the UK horizon scan.
Make validation continuous, not a sprint, so the list is accurate every month the target is measured.
Build the audit trail and the patient-group monitoring now. Scrutiny of how lists are reduced will grow as the target gets closer.
Use one messaging route with letter fallback, so the App inbox can be switched on without changing the campaigns.
Keep the confirmation log, the reasons and the patient letters in a form you could show the ICO.
Design so findings and replies can feed the trust's FDP products if it uses them, rather than running a second list.
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.
