Routine questions answered straight away, by phone or web chat, from content the trust has approved. Anything clinical or urgent goes to a person, with clear signposting to NHS 111 and 999.
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.
A large trust's phone lines carry thousands of calls a day. Many are the same questions: where is the clinic, where can I park, can I eat before my colonoscopy, what are the visiting times on the ward, can I move my appointment to next week. The answers are on letters, leaflets and web pages, but patients can't find them, or want to be sure.
Each of those calls waits in the same queue as a patient whose symptoms have got worse, or a carer who needs to speak to the ward. Call abandonment rises, missed appointments follow, and staff spend the day reading the same answers aloud. The cost lands on patients who most need a person: older people, people with disabilities and people who don't speak English well.
An assistant can take the routine load, but only if it is designed to know its limits. It answers only from content the trust has approved. It never gives clinical advice. It recognises when a question is clinical or urgent and hands it to a person straight away, with NHS 111 and 999 always signposted. And it must make the service easier for everyone, not just for people who like chatbots.
Agree these, and measure the baseline, before anything is built. Example targets are typical, not promises.
Share of calls answered within a minute, and the abandonment rate.
ExampleAbandonment roughly halved
Routine enquiries fully answered or rebooked without a person, checked by audit, not just by the call ending.
Example30–40% of routine enquiries
Clinical or urgent cues that reached a person and were signposted correctly, from a weekly audit sample.
ExampleEvery case in the sample
Answers that were wrong or out of date, found by the weekly sample review.
ExampleFalling, and each one fixed at the source
Appointments moved by the assistant that matched the access policy.
ExampleEvery one
Satisfaction and complaints, split by age, disability, language and channel.
ExampleNo group worse off
Cross-sector rules are on the UK regulation map.
Design from user research with patients, including people who don't use digital services. Point 5 means everyone can use it, point 16 means it is clinically safe, and point 3 means a joined-up experience across phone, web and the NHS App. A person is always one step away.
If you buy, the supplier completes DTAC; if you build, use it as your own checklist. It covers clinical safety, data protection, technical security, interoperability, and usability and accessibility. The previous form was retired by April 2026.
Even an assistant that never gives clinical advice can cause harm: a missed urgent symptom, wrong fasting instructions, an appointment moved that shouldn't have been. That needs a clinical safety officer, a hazard log and a safety case before go-live. Both standards are under review, so expect revised versions.
Software that only handles administration, such as booking appointments, is unlikely to be a medical device. A symptom checker that matches symptoms to conditions is likely to be one. Keep the intended purpose to approved, non-clinical information and booking, written down, and hand any symptom to a person.
The web chat meets WCAG 2.2 AA and is covered by the trust's accessibility statement. The phone assistant speaks plainly, allows extra time, and offers a person at any point. Recorded communication needs, such as a BSL interpreter, large print or an advocate, route the patient to a person who can meet them.
Use the minimum personal information needed: none at all for directions or parking, and only appointment details after identity is checked. Principle 8 means telling patients clearly that they are talking to an automated assistant and how their information is used.
Conversations can contain health data. That means a DPIA before the pilot, UK processing, a short retention period for transcripts and recordings, and a contract that stops providers training their models on your data. The assistant never refuses anything on its own: anything outside the rules goes to a person. The service goes into the trust's 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 |
|---|---|---|---|
| TelephonyKeep your current numbers and menus. The assistant is one option in the menu at first, not the only route in. | Amazon Connect, or your existing telephony through a SIP link | Azure Communication Services, or your existing telephony through a SIP link | Your existing SIP telephony (e.g. Asterisk) |
| SpeechTest with your own callers: accents, older voices, speech differences, poor lines and background noise. | Amazon Transcribe and Amazon Polly (en-GB) | Azure Speech in Foundry Tools | Open-weight speech models (e.g. Whisper) and open-source text to speech on your own GPUs |
| Reasoning and answersBoth clouds offer a choice of models, including Claude. Short, plain answers, read aloud well. | Amazon Bedrock | Microsoft Foundry | Open-weight models served with vLLM on your own GPUs, or IONOS AI Model Hub |
| Approved content (retrieval)Only approved, dated content with a named owner. If the content doesn't answer the question, the assistant says so and offers a person. | 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 |
| Urgency and topic screenRuns on every turn. Any symptom, distress or clinical question stops the answer and hands over. Urgency rules are written and signed off by clinicians. | Bedrock Guardrails, plus your own urgency rules | Foundry guardrails (Azure AI Content Safety), plus your own urgency rules | Open-source guardrails (e.g. NeMo Guardrails, Llama Guard), plus your own urgency rules |
| BookingThe rules live in the booking service, not in a prompt: which clinics, how far ahead, which pathways are excluded. | Through your PAS or EPR supplier's booking interface | Through your PAS or EPR supplier's booking interface | Through your PAS or EPR supplier's booking interface |
| Patient identityNo personal information is shared before identity is checked. Proxy access for carers follows the trust's existing rules. | NHS login for web; agreed checks plus a one-time code for phone | NHS login for web; agreed checks plus a one-time code for phone | NHS login for web; agreed checks plus a one-time code for phone |
| Workflow and events | AWS Step Functions, EventBridge, SQS | Logic Apps or Durable Functions, Event Grid, Service Bus | Temporal or n8n; Apache Kafka or RabbitMQ |
| Identity, keys, data protection | 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 answer with its source, every handoff with its reason, and every rebooking. | CloudWatch, CloudTrail | Azure Monitor, Log Analytics | Prometheus, Grafana, OpenTelemetry |
| UK data residencyIONOS AI Model Hub runs in German data centres: EU, not UK, residency. Most trusts will want UK processing for patient conversations. | 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, the EPR, the telephony platform and the contact centre queues stay where they are. The assistant reads appointment details only through the booking interface, and never holds a copy of the record.
Uses cloud AI
Speech, retrieval over approved content and the assistant run in a UK cloud region, or on the trust's own GPUs for the sovereign option. General questions such as parking and directions need no personal data at all.
How they connect
Telephony hands calls to the assistant over a SIP link. Booking goes through the PAS or EPR supplier's interface and an API gateway, over a private link such as AWS Direct Connect or Azure ExpressRoute, using a service account that can only do what the rules allow.
If the link drops
Calls fall straight back to the existing phone menu and queues, and the web chat shows phone numbers and the main information pages. Nothing is lost: patients reach people exactly as they did before the assistant.
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.
Enquiry assistant
Where a person signs offThere's no adverse decision for the assistant to make. Anything outside the rules goes to a person. Its permissions are enforced by the platform's identity controls and the booking service, not by instructions in a prompt.
Content gap finder
Where a person signs offContent owners, and clinicians for anything about preparing for a procedure, approve every answer before the assistant can use it.
The PAS or EPR stays the record of every appointment. The assistant books only through the supplier's booking interface, with the same rules the patient access team uses. If the interface is down, the assistant says so and offers a person, and never queues a change to make later without telling the patient.
Handoffs use the contact centre's existing queues. The person who picks up sees a short summary and the transcript, so the patient doesn't start again. Urgent handoffs go to the front of the queue.
Confirmations go out through the trust's existing letter, text and NHS App messaging routes, so patients get them in the usual place and the record of what was sent stays in one system.
Analyse a month of calls and enquiries, research with patients including those who avoid digital services, audit the content, and agree what the booking interface allows.
Gate · must be true to passBaseline agreed, content owners named, clinical safety officer named, DPIA and hazard log started, intended purpose written down.
Web chat first, for general information only: directions, parking, visiting and preparing for procedures. Then the phone, as one option in the menu.
Gate · must be true to passWrong-answer rate within limits, every urgent cue handed over in testing and in the audit sample, accessibility audit passed, clinical safety sign-off.
Add identity checks and rebooking for a few clinics, with monitoring, support and a rollback plan.
Gate · must be true to passRebooking audited against the rules, contact centre trained, monitoring and rollback in place.
More clinics, more languages from translated approved content, and other trusts in the ICB on the same platform.
Gate · must be true to passEach new clinic or language passes the same 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 & DPO | SecurityI can fill this |
|---|---|---|---|---|---|---|---|---|
| Business case and benefits | Accountable | Responsible | Consulted | Consulted | Informed | Consulted | Informed | Informed |
| Target architecture and booking integration | Informed | Consulted | Accountable and Responsible | Consulted | Consulted | Consulted | Consulted | Consulted |
| Clinical safety case and urgency rules | Consulted | Consulted | Consulted | Informed | Consulted | Accountable and Responsible | Informed | Consulted |
| DPIA, accessibility and DTAC evidence | Consulted | Responsible | Consulted | Consulted | Consulted | Consulted | Accountable | Consulted |
| Build and integration | Informed | Consulted | Accountable | Responsible | Responsible | Consulted | Informed | Consulted |
| Testing with patients and staff | Informed | Accountable | Consulted | Responsible | Responsible | Responsible | Informed | Informed |
| 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: telephony and web chat, the approved content, the booking integration, identity checks and the gates, working closely with your clinical safety officer and patient access team. I'd report to your programme board.
Option B
If your partner, your contact centre supplier or your own team already has an architect, I'd take on the booking integration, the handoff design and the safety and audit controls under their lead, and give them a second senior opinion on security, accessibility and the clinical safety evidence.
Goes wrong
The assistant answers from general knowledge and gives fasting instructions that don't match the trust's.
How the design avoids it
Retrieval from approved, dated content only, the source named in every answer, and 'I don't know, let me get a person' when the content is silent.
Goes wrong
A patient mentions chest pain in the middle of a parking question, and the assistant answers the parking question.
How the design avoids it
An urgency screen on every turn, rules written by clinicians, and testing with real call transcripts before go-live.
Goes wrong
Rebooking rules sit in the prompt, so an urgent appointment gets moved.
How the design avoids it
The rules live in the booking service and the assistant's account can only do what they allow.
Goes wrong
The phone menu is replaced, and people who can't use the assistant are stuck.
How the design avoids it
The assistant is one option, a person is always one step away, and experience is measured by age, disability and language.
Goes wrong
Content goes stale and nobody notices.
How the design avoids it
Named owners, review dates, and a content gap finder that flags out-of-date answers.
Changes already announced or under way that affect this design. More in the UK horizon scan.
Keep your assistant to non-clinical enquiries and point patients to the NHS App and NHS 111 for symptoms, so the two don't overlap.
Send confirmations through the NHS App where your trust can, and use the same booking rules for the app and the assistant so they never disagree.
Keep the hazard log and safety case structured and current, so moving to the new versions is an update, not a rewrite.
Keep conversation logs, handoff reasons and rebooking records in a form you could show the ICO.
Build on national standards and the booking interface rather than one-off integrations, so the assistant can use a fuller record if the trust later decides it should.
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.
