Healthcare and the NHS · Playbook 12

I've worked in this sector

Ambient clinical notes

The consultation is captured, the note and the letter are drafted before the patient leaves, and the clinician checks, edits and signs every word.

  • Speech and voice
  • Agents with tools
  • Human in the loop
  • Event-driven integration
  • NHS England AVT guidance
  • MHRA
  • DCB0129 / DCB0160
  • DSPT
  • UK GDPR

At a glance

The problem
Clinicians type notes between patients or after clinic, and letters wait days to be typed, checked and sent
Typical volume
Around 25,000 outpatient appointments a month across 30 specialties
Who's involved
Outpatient clinicians, the CCIO, clinical safety, IG and the DPO, the EPR team, medical secretaries, clinical coding, patient experience
Pilot
Up to 4 months in two or three specialties, after a 3–4 week discovery
Platforms
A product from the NHS supplier registry or a national framework, integrated on AWS, Azure, or a sovereign or on-prem stack

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 business problem

In a busy outpatient clinic, the clinician has two jobs at once: listening to the patient and writing it all down. Notes get typed with one eye on the screen, or saved up for the end of clinic. Letters are dictated, typed by a medical secretary, sent back for checking and signed days later. In a typical trust, the letter to the patient and the GP goes out a week or more after the appointment, and the GP practice acts on it later still.

Ambient voice technology (AVT) changes the order of work. With the patient's knowledge, it listens to the consultation, transcribes it, and drafts the clinical note, the clinic letter and suggested codes in the specialty's own format. The clinician reads, corrects and signs before the next patient comes in. NHS England is funding a national rollout that starts in outpatient settings.

The tools are easy to demo and hard to run well. A draft that reads fluently can still be wrong: a drug name misheard, a side mentioned in passing turned into a diagnosis, a plan said aloud that never reaches the EPR. Accents, interpreters, background noise and three people talking at once all test it. The real work is the design around the tool: consent, checking, integration with the EPR, clinical safety and evidence that it helps.

What AI changes

  • Patients are told before and at the start of the appointment that a scribe is in use, and can say no without any effect on their care.
  • The consultation is transcribed as it happens, and the note is drafted in the specialty's template within a minute of the end.
  • The clinic letter is drafted to the patient, copied to the GP, in plain English, ready to edit and sign the same day.
  • SNOMED CT codes for problems, findings and procedures are suggested with the words from the transcript that support them, for the clinician to accept or reject.
  • Actions said aloud, such as bloods in six weeks or a follow-up in three months, become a checklist for the clinician to confirm. Nothing is ordered or booked automatically.
  • The clinician stays the author. Nothing reaches the EPR, the patient or the GP until they have read and signed it.

How success is measured

Agree these, and measure the baseline, before anything is built. Example targets are typical, not promises.

Time on documentation

Clinician time spent writing notes and letters, per clinic, measured before and after.

ExampleDown by a third or more

Clinic to letter sent

Days from the appointment to the signed letter reaching the patient and the GP.

ExampleFrom 7–10 days to 1–2

Errors found in audit

Clinically significant errors in signed notes, from a weekly sample read against the audio or transcript.

ExampleNone unresolved, and falling

Draft edit rate

How much clinicians change the drafts. Very high means it isn't helping; near zero can mean drafts are being signed unread.

ExampleStable, and reviewed weekly

Patient opt-outs and concerns

How many patients say no, and why, split by age, language and specialty.

ExampleTracked, with no group avoiding care

Accuracy across voices

Transcription quality for different accents, interpreted consultations and noisy rooms.

ExampleNo group materially worse

UK regulation and controls

Cross-sector rules are on the UK regulation map.

  • NHS EnglandGuidance on AI-enabled ambient scribing products (version 3, updated 29 July 2026)

    Organisations stay accountable for safe use. The guidance expects a DPIA, a clinical safety officer and DCB0160 documentation, integration with the EPR, clear contracts on liability and model updates, monitoring independent of the supplier, and staff trained to review every output. Pilots are time-limited to four months and must not bypass these steps.

  • MHRAAmbient voice technology-enabled products (29 July 2026)

    Products that only transcribe, summarise, draft correspondence or suggest codes for clinician review are generally not medical devices. Products intended to support diagnosis or treatment can be. Write the intended purpose down, keep the tool to documentation, and re-check its status whenever the supplier adds a feature.

  • NHS EnglandDCB0129 and DCB0160 clinical safety

    The supplier provides its DCB0129 safety case; the trust, as deployer, needs its own DCB0160 safety case, hazard log and monitoring. Hazards include misheard medicines, invented findings, missed actions and the wrong patient's record. Both standards are under review, so expect revised versions.

  • ICO and the National Data GuardianUK GDPR, the common law duty of confidentiality and the Caldicott principles

    Consultation audio is special category health data. Update privacy notices before go-live, tell patients what is recorded and how long it is kept, and give them a real chance to object. Keep audio only as long as needed to produce and check the note, under a retention period set in the DPIA.

  • NHS EnglandData Security and Protection Toolkit and Cyber Essentials

    The guidance expects both the trust and the supplier to meet the DSPT and hold Cyber Essentials. The new service, its supplier and its data flows go into the trust's CAF-aligned DSPT submission and information asset register.

  • GMC, NMC and HCPCProfessional standards for records

    The clinician who signs the note is responsible for it, whoever or whatever drafted it. Training and the sign-off step make that explicit, and the audit trail records who checked what.

The solution

Showing AWSAzuresovereign / on-prem services. Switch with the toggle; every diagram and table on this page follows it.

Ambient clinical notes: reference architecture
  1. 01Channels

    • Face-to-face clinic
    • Phone or video clinic
    • Patient told, and can say no
  2. 02Intake

    • API GatewayAPI ManagementKong, or your existing API gatewayCapture app API
    • Amazon TranscribeAzure Speech in Foundry ToolsOpen-weight speech model (e.g. Whisper)Speech to text (en-GB)
    • Amazon S3Blob StorageCeph, or IONOS S3 Object StorageShort-lived audio and transcript store
  3. 03Intelligence

    • Agent
      Bedrock AgentCoreFoundry Agent ServiceLangGraph on Kubernetes, with open-weight models via vLLMNote and letter drafter
    • Agent
      Bedrock AgentCoreFoundry Agent ServiceLangGraph on KubernetesDraft checker
    • NHS England Terminology Server (FHIR)NHS England Terminology Server (FHIR)NHS England Terminology Server, or a local FHIR terminology serverSNOMED CT look-up
  4. 04Orchestration

    • Step FunctionsLogic Apps / Durable FunctionsTemporalNote workflow
    • EventBridge + SQSEvent Grid + Service BusApache Kafka or RabbitMQEvents and queues
  5. 05Systems of record

    • EPR: notes, letters, codes
    • Outpatient clinic lists (PAS)
    • Letter route to patients and GPs
  6. 06People

    • Person
      Clinician: checks, edits, signs
    • Person
      Clinical coders and secretaries
    • Person
      Clinical safety and IG
  • Cloud or platform service (AWSAzuresovereign / on-prem)
  • AI agent
  • A person decides
  • Your existing systems
  • Outside your organisation

Components, side by side

Ambient clinical notes: components on AWS, Azure and a sovereign or on-prem stack
LayerAWSAzureSovereign / on-prem
Build or buyMost trusts will buy. The registry is self-certified, not an endorsement, so test the evidence like any other supplier's. The architecture below applies either way: it's what you integrate, assure and monitor.A product from NHS England's self-certified AVT supplier registry or a national framework, or your own build on AWSA product from the registry or a national framework, or your own build on AzureA product that can be hosted privately, or your own build on open-weight models
Capture: app, audio, filesCapture on trust-managed devices only. Audio is encrypted in transit and at rest, and deleted on a short, agreed schedule.API Gateway, S3API Management, Blob StorageKong or your existing API gateway; Ceph or IONOS S3 Object Storage
Speech to textAdd drug names, local place names and specialty terms. Test on your own patients' accents, interpreted consultations, children's clinics and noisy rooms, not a supplier's benchmark.Amazon Transcribe (en-GB) with a custom vocabularyAzure Speech in Foundry Tools, with custom speechOpen-weight speech models (e.g. Whisper) on your own GPUs
Drafting and reasoningBoth clouds offer a choice of models, including Claude. Templates per specialty, agreed with clinicians.Amazon BedrockMicrosoft FoundryOpen-weight models served with vLLM on your own GPUs, or IONOS AI Model Hub
Agent runtimeThe original Bedrock Agents closed to new customers on 30 July 2026; new builds use AgentCore.Amazon Bedrock AgentCoreFoundry Agent ServiceAn open-source agent framework (e.g. LangGraph) on Kubernetes
Clinical codesSuggested codes are validated against the current SNOMED CT release, and OPCS-4 where the trust codes outpatient procedures. The clinician or coder confirms each one.NHS England Terminology Server via FHIRNHS England Terminology Server via FHIRNHS England Terminology Server, or a local FHIR terminology server
WorkflowAWS Step FunctionsLogic Apps or Durable FunctionsTemporal, or n8n
Middleware and eventsAmazon EventBridge, SQSEvent Grid, Service BusApache Kafka or RabbitMQ
Link to the EPRThis decides the design. Agree in discovery whether drafts land in the EPR for signing, or sit beside it to copy from. In general practice, the route is IM1.Through your EPR supplier's published interfaces (FHIR, HL7 or their API)Through your EPR supplier's published interfaces (FHIR, HL7 or their API)Through your EPR supplier's published interfaces (FHIR, HL7 or their API)
GuardrailsBlocks the draft from adding diagnoses, medicines or doses that aren't in the transcript.Bedrock GuardrailsFoundry guardrails (Azure AI Content Safety)Open-source guardrails (e.g. NeMo Guardrails, Llama Guard)
Identity, keys, data protectionClinicians sign in with the identity they already use. Smartcard access stays with the EPR.IAM Identity Center, KMS, MacieEntra ID, Key Vault, PurviewKeycloak or your existing Active Directory; OpenBao or HashiCorp Vault; an HSM
Monitoring and auditLog every draft, every edit and every sign-off, with the model and template version. Keep your own measures, independent of the supplier.CloudWatch, CloudTrailAzure Monitor, Log AnalyticsPrometheus, Grafana, OpenTelemetry
UK data residencyIONOS AI Model Hub runs in German data centres: EU, not UK, residency. Many trusts' IG policies will require UK processing for consultation audio.eu-west-2 (London)UK South / UK WestYour 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 →

Hybrid and on-prem

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 PAS and the letter route to patients and GPs stay where they are, with your EPR supplier. The signed note lives in the EPR, never in the AI service, and smartcard access is unchanged.

Uses cloud AI

Transcription, drafting and the draft check run in a UK cloud region, inside the chosen product, or on the trust's own GPUs for the sovereign option. Audio and transcripts are kept only until the note is signed and checked, then deleted on the agreed schedule.

How they connect

Capture devices reach the service over the trust network or HSCN. Drafts go back through the EPR supplier's interfaces and an API gateway, over a private link such as AWS Direct Connect or Azure ExpressRoute, or inside the trust's data centre.

If the link drops

The clinic carries on. The clinician types the note or dictates the letter exactly as before the AI, and the capture app tells them clearly that nothing is being recorded. No consultation depends on the scribe working.

The agents

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.

Note and letter drafter

May do

  • Read the transcript of a consultation the patient agreed to
  • Read the clinic context: patient details, referral reason, last letter
  • Draft the note in the specialty's template
  • Draft the letter to the patient, copied to the GP
  • Suggest SNOMED CT codes with the supporting words
  • List actions said aloud for the clinician to confirm

May not do

  • Sign, file or send a note or letter
  • Order a test, book a follow-up or make a referral
  • Add a diagnosis, medicine or dose nobody said
  • Suggest a diagnosis or treatment
  • Keep audio beyond the agreed retention period

Where a person signs offThe clinician reads, edits and signs every note and letter. Drafts stay marked as drafts until they do. The agent's permissions are enforced by the platform's identity and policy controls, not by instructions in a prompt.

Draft checker

May do

  • Check each statement in the draft against the transcript
  • Flag medicines, doses and numbers that don't match what was said
  • Flag words the transcription wasn't confident about
  • Flag missing template sections

May not do

  • Change the draft
  • Mark a draft as checked or approved
  • Hide a flag from the clinician

Where a person signs offFlags are shown to the clinician at the point of signing. A weekly audit sample is read by clinicians against the source, independent of the supplier's own figures.

Middleware and integration

The EPR stays the record. Drafts reach it only through the EPR supplier's published interfaces and the API layer, never by screen-scraping or direct database writes. If the supplier only allows a side panel, the clinician copies from it, and the design accepts that until a better route exists.

Events keep the AI decoupled. An ended consultation becomes a message on a queue, and the draft is written back when ready. If the service is slow, the clinician isn't blocked: they can sign later or write the note themselves. Every message carries the appointment ID, so a retry never files a duplicate.

The signed letter leaves through the trust's existing route to patients and GP practices, with its usual checks. The AI never sends anything directly, and coded data goes into the EPR the same way as codes entered by hand.

Process and people

  • A consent script, patient information before the appointment, and a recorded note in the EPR that AVT was used and the patient was told.
  • Clear rules on when not to record, such as safeguarding disclosures, some sexual health and mental health consultations, and whenever the patient or clinician prefers not.
  • A clinical safety officer owns the hazard log, and every model, template or product update is re-tested before it goes live.
  • A weekly audit of signed notes against the source, by clinicians, with results reported by specialty.
  • Medical secretaries' work redesigned with them, not around them: checking, routing and patient contact rather than typing.
  • Clinicians trained before go-live, including how the tool fails: mishearing, inventing and leaving things out.

Delivery plan

  1. 3–4 weeks

    Discovery

    Map today's note and letter process, measure the baseline, agree the EPR integration route, shortlist products from the registry or a framework, and engage the ICB and regional team.

  2. Gate · must be true to passBaseline agreed, EPR route confirmed, clinical safety officer named, DPIA and hazard log started, intended purpose written down.

  3. Up to 4 months

    Pilot

    Two or three specialties with willing clinicians. Drafts are generated, clinicians sign as usual, and quality is audited against the source every week.

  4. Gate · must be true to passError rate and edit rate within agreed limits, no group of patients worse off, DCB0160 safety case and CCIO sign-off.

  5. 6–8 weeks

    Production

    Go live in the pilot specialties with monitoring, support, contract terms for model updates, and a rollback plan.

  6. Gate · must be true to passMonitoring, support model, rollback plan, training and patient information in place.

  7. Ongoing

    Scale

    Add specialties in waves, then emergency and inpatient settings, then community services.

  8. Gate · must be true to passEach new specialty passes the same pilot gate, with its own template and accent and noise testing.

Roles and RACI

Who is responsible, accountable, consulted and informed, by activity
ActivityCCIOProduct ownerSolutions architectI can fill thisTechnical PMI can fill thisEngineersI can fill thisClinical safety officerIG & DPOSecurityI can fill this
Business case and benefitsAccountableResponsibleConsultedConsultedInformedConsultedInformedInformed
Product selection and EPR integration designConsultedConsultedAccountable and ResponsibleConsultedConsultedConsultedConsultedConsulted
Clinical safety case and hazard logAccountableConsultedConsultedInformedConsultedResponsibleInformedConsulted
DPIA, patient information and DSPTConsultedConsultedConsultedInformedInformedConsultedAccountable and ResponsibleConsulted
Build and integrationInformedConsultedAccountableResponsibleResponsibleConsultedInformedConsulted
Pilot audit against the sourceAccountableResponsibleConsultedResponsibleConsultedResponsibleInformedInformed
Go-live decisionAccountableResponsibleConsultedResponsibleInformedConsultedConsultedConsulted
Run, monitor and improveAccountableResponsibleConsultedConsultedResponsibleConsultedConsultedConsulted

Business case and benefits

CCIO
A · Accountable
Product owner
R · Responsible
Solutions architect
C · Consulted
Technical PM
C · Consulted
Engineers
I · Informed
Clinical safety officer
C · Consulted
IG & DPO
I · Informed
Security
I · Informed

Product selection and EPR integration design

CCIO
C · Consulted
Product owner
C · Consulted
Solutions architect
A/R · Accountable and Responsible
Technical PM
C · Consulted
Engineers
C · Consulted
Clinical safety officer
C · Consulted
IG & DPO
C · Consulted
Security
C · Consulted

Clinical safety case and hazard log

CCIO
A · Accountable
Product owner
C · Consulted
Solutions architect
C · Consulted
Technical PM
I · Informed
Engineers
C · Consulted
Clinical safety officer
R · Responsible
IG & DPO
I · Informed
Security
C · Consulted

DPIA, patient information and DSPT

CCIO
C · Consulted
Product owner
C · Consulted
Solutions architect
C · Consulted
Technical PM
I · Informed
Engineers
I · Informed
Clinical safety officer
C · Consulted
IG & DPO
A/R · Accountable and Responsible
Security
C · Consulted

Build and integration

CCIO
I · Informed
Product owner
C · Consulted
Solutions architect
A · Accountable
Technical PM
R · Responsible
Engineers
R · Responsible
Clinical safety officer
C · Consulted
IG & DPO
I · Informed
Security
C · Consulted

Pilot audit against the source

CCIO
A · Accountable
Product owner
R · Responsible
Solutions architect
C · Consulted
Technical PM
R · Responsible
Engineers
C · Consulted
Clinical safety officer
R · Responsible
IG & DPO
I · Informed
Security
I · Informed

Go-live decision

CCIO
A · Accountable
Product owner
R · Responsible
Solutions architect
C · Consulted
Technical PM
R · Responsible
Engineers
I · Informed
Clinical safety officer
C · Consulted
IG & DPO
C · Consulted
Security
C · Consulted

Run, monitor and improve

CCIO
A · Accountable
Product owner
R · Responsible
Solutions architect
C · Consulted
Technical PM
C · Consulted
Engineers
R · Responsible
Clinical safety officer
C · Consulted
IG & DPO
C · Consulted
Security
C · Consulted

R ResponsibleA AccountableC ConsultedI Informed· not involved

Where I'd fit

Option A

Lead the architecture

If there's no architect on the programme, I'd own the design end to end: product selection against your EPR, the integration route, audio retention, security, monitoring and the gates, working closely with your clinical safety officer and CCIO. I'd report to your programme board.

Option B

Support your architect

If your partner, your EPR supplier or your own team already has an architect, I'd take on the EPR integration, the event flow and the independent monitoring under their lead, and give them a second senior opinion on security, supplier evidence and the clinical safety case.

Where this goes wrong

  1. Goes wrong

    The demo was one clear voice in a quiet room. Real clinics have accents, interpreters, children and corridor noise.

    How the design avoids it

    Test on your own clinics, every specialty and voice, and report accuracy by group, not as one average.

  2. Goes wrong

    Clinicians sign fluent drafts without reading them, and an invented finding enters the record.

    How the design avoids it

    A draft checker that flags unsupported statements, short drafts, an edit-rate measure and a weekly audit against the source.

  3. Goes wrong

    Drafts sit beside the EPR, so clinicians copy and paste and the time saved disappears.

    How the design avoids it

    Agree the EPR integration route in discovery, before choosing a product.

  4. Goes wrong

    A supplier update adds a 'suggested diagnosis' feature, and the tool becomes a medical device without anyone deciding it should.

    How the design avoids it

    A written intended purpose, contract terms on change notice, and a re-check of device status and the hazard log at every update.

  5. Goes wrong

    Patients aren't told properly, and trust is lost after one complaint.

    How the design avoids it

    Information before the appointment, a consent script, an easy no, and opt-outs tracked and listened to.

On the horizon

Changes already announced or under way that affect this design. More in the UK horizon scan.

  1. Under way
    NHS England's national AVT rollout, funded through its Frontline Productivity programme and starting in outpatients, with a national centre of excellence and a benefits framework planned.

    Talk to your regional digital transformation team early, and collect baseline measures now so you can show benefits in the national format.

  2. To 30 September 2027
    A national NHS procurement framework for dictation, speech recognition and AVT runs from October 2025 to September 2027.

    If you buy through it, plan contract length and exit terms around its end date, and keep your integration independent of one product.

  3. Late 2026 and 2027
    The review of DCB0129 and DCB0160 (consultation closed 11 September 2026) is expected to bring revised clinical safety standards.

    Keep the hazard log and safety case structured and current, so moving to the new versions is an update, not a rewrite.

  4. 2027
    After the national commission on regulating AI in healthcare, the MHRA plans a 2027 consultation on how AI devices are qualified and classified, and a full roadmap in spring 2027.

    Keep the intended purpose written down and narrow, and review it against the new rules as they land.

  5. By December 2028
    The Single Patient Record in the NHS App, with the Health Bill (going through Parliament) as its legal basis.

    Make sure signed notes and codes go into the EPR as structured, coded data, so they can flow into the shared record when it arrives.

Questions to ask your partner or vendor

Good answers are specific. Vague answers to any of these are worth following up.

Copy them into your next supplier meeting

  1. What exactly is the intended purpose, and how will we know if an update changes it?
  2. How does the draft reach our EPR: written into the record, or copied from a side panel?
  3. What is the accuracy on our own clinics, for our patients' accents and our interpreters?
  4. Where is the audio processed and stored, for how long, and is it used to train anyone's model?
  5. How will we measure quality independently of the supplier, and who reads the audit?
  6. What does it cost per clinician per month at our scale, and what happens to our data if we leave?

Planning something like this?

Whether you need someone to lead the design or to support the architect you already have, let's talk it through.

Sam Naseem
Sam NaseemBirmingham, UK · UK & Europe
Available now