A GP practice should start from NHS England's ambient scribing guidance: appoint a Clinical Safety Officer, complete the DCB0160 safety documents and a DPIA, pick from suppliers on the national registry that integrate with your clinical system, and run only a time-limited pilot of up to four months. The registry is self-certified, so it is a starting list, not an endorsement.
The common mistake is treating the registry as a shopping list with a quality stamp. It is not one. NHS England says it does not endorse any supplier on it and carries out only preliminary completion checks, and that procurement is done by individual NHS bodies under their own governance. What the registry gives you is a set of suppliers who have declared they meet certain standards, with evidence you can read. The work of deciding whether one is safe in your practice remains yours.
What the guidance says, in the order a practice manager needs it
NHS England's guidance, now in its second iteration, opens with a five-step implementation guide. The checklist below follows those steps and adds the questions a practice should put to a supplier at each one. It is written for a small to medium GP practice, though the same logic applies to a community service.
| Step | What the guidance asks for | What a practice does |
|---|---|---|
| 1 | Assign a Clinical Safety Officer and identify key risks | Name the person; list output errors, outages, integration failures and data loss |
| 2 | Complete DCB0160 documentation and a Data Protection Impact Assessment | Safety case, hazard log, monitoring framework, DPIA signed by the right people |
| 3 | Plan for appropriate integration | Confirm write-back to your principal clinical record system |
| 4 | Ensure appropriate controls | Supplier assurance (DTAC, MHRA where applicable), clinician review of every output, staff training |
| 5 | Implement your monitoring framework | Audit documentation, review incidents and performance over time |
Step 1: the Clinical Safety Officer and a usable hazard list
Someone in the organisation has to own clinical safety for this deployment. In a small practice this could be a GP partner who has completed clinical safety training, with support from the integrated care board (ICB) if the expertise is not in-house. The guidance says that if you lack the tools and capabilities to comply with the standards, you can ask your local ICB for help, so do that early rather than after you have chosen a supplier.
Start the hazard log with the risks the guidance names. Technical: output errors, system unavailability, integration failures, data loss. Clinical: missing critical information, incorrect information or context, delayed outputs. Add the one the guidance flags for generative tools: because the product is built on a large language model, it may introduce new functions unintentionally or through instructions a user types in, such as suggesting a diagnosis or listing what you "missed". Here is a worked hazard-log extract for a practice, written as an illustration.
| Hazard | Possible effect | Control | Owner |
|---|---|---|---|
| Summary omits an allergy mentioned in the consultation | Allergy absent from the record | Clinician reads and approves before filing; monthly audit of 20 notes against recordings | Clinical Safety Officer |
| Note written to the wrong patient's record | Wrong-record entry | Patient identifier check on the screen before approval; integration tested for matching | Practice manager and supplier |
| Scribe unavailable mid-clinic | Delay, unrecorded consultations | Fallback to usual typing; downtime procedure on the wall | Practice manager |
| Clinician prompts the tool to suggest diagnoses | Use beyond intended purpose | Written acceptable-use rule; supplier guardrails documented | Clinical Safety Officer |
The Complete Excel Course with AI Integration
From formulas and pivot tables to Power Query, DAX, VBA and AI with Copilot, ChatGPT and Claude — hands-on from the first lesson.
By Sagnik Bhattacharya and Virginia Thorn, Primetime Emmy Award winner
Buy nowStep 2: DCB0160, DCB0129 and the DPIA, who does which
The standards have a pair. DCB0129 is the supplier's clinical risk management standard; the guidance tells you to ensure the supplier has completed it. DCB0160 is the one you, as the deploying organisation, complete: it includes a safety case, a hazard log and a monitoring framework. Ask every supplier for their DCB0129 evidence early. If it is missing or out of date, that is the answer.
The DPIA is yours too. NHS England has published information governance guidance for ambient scribing that includes a template for completing one, and the main guidance says templates for risk assessments, including hazard logs and safety cases, were to follow in early 2026. Use what has been published and check the NHS England pages for those templates before you start.
A DPIA for a scribe should answer, in plain words: what personal data is captured (audio of the clinician and patient, a transcript, a draft note), where it is processed and stored, who the processors and sub-processors are, how long each item is kept, how a patient can object, and how a subject access request would be handled for transcripts as well as notes. The guidance asks that you and the supplier comply with UK GDPR, the Data Security and Protection Toolkit (DSPT) and Cyber Essentials certification, and that you are open with patients about how information is used and shared.
Step 3: integration and write-back decide the shortlist
The guidance says that in most general practice settings an ambient scribing product will need to integrate with the principal electronic patient record. This is not a nicety. It reduces clinical risk by preventing notes in the wrong place, removing manual copy-and-paste, and keeping the note in the right clinical record. The registry lists suppliers that offer integration, and the guidance mentions integration through IM1 for primary care.
So ask each shortlisted supplier, in writing, for the exact mechanism for your system. If you run EMIS Web (now supplied by Enlivio Health, formerly EMIS) or SystmOne, do not accept "integrates with major systems". Ask these five questions.
- Does the note write back into the patient's record automatically, or does the clinician copy it across?
- What exactly is written back: free text only, or coded entries and structured fields? Does it extract and link terms to clinical codes, which the guidance lists as a possible function, and who checks those codes?
- Is the integration live at practices like mine today, or planned? The guidance refers to "current or imminent" integrations, and the difference matters for a four-month pilot.
- What happens if write-back fails halfway: is there an alert, and is the note held safely?
- What does the supplier do for FHIR, HL7 or SNOMED CT standards, where the guidance mentions these for data exchange?
Step 4: DTAC, MHRA status and what "as applicable" means
The guidance says the registry sets expectations including a completed Digital Technology Assessment Criteria (DTAC) assessment and registration with the MHRA as applicable. Do not read that as "every scribe is a registered medical device". Whether a given product counts as a medical device depends on what it does, and the guidance is clear that it is not making that determination for you. Its appendix is about the reasoning.
What a practice can do: ask the supplier to state its medical device determination and show the evidence. Ask whether the product only transcribes and summarises, or also suggests diagnoses, codes or actions. The guidance warns about products that let users instruct them to suggest diagnoses or flag missing consultation components, especially where the product is not registered as a medical device. Also ask what happens when the supplier changes functionality: the guidance expects a process to review whether changes alter regulatory status.
Step 5: the pilot, with a start date, an end date and a pass mark
This is where the guidance gets specific. A pilot or proof of concept does not exempt a supplier from compliance. Pilots can continue only if they are time-limited, up to four months, and are not used to bypass compliance. You should also engage your ICB and regional teams for assurance before proceeding with a pilot or any commercial engagement, and not enter commercial agreements with suppliers who do not meet national and local requirements.
A practice pilot plan that fits those rules fits on one page.
PILOT PLAN: AI-enabled ambient scribe
Start: [date] Hard stop: [date, no later than four months after start]
Supplier: [name], registry entry checked on [date]
Safety: CSO [name]; DCB0160 safety case approved [date]; supplier DCB0129 evidence seen [date]
Data: DPIA approved [date]; DSPT and Cyber Essentials evidence seen [date]
Users: [two GPs, one nurse practitioner], all trained on [date]
Scope: face-to-face and telephone consultations; excluded: safeguarding, [other]
Patient information: notice in waiting room and on website, opt-out routine at start of consultation
Measures: edit time per note, errors found in monthly audit of [20] notes, incidents, patient objections, write-back failures
Decision at end: adopt via procurement route / extend via proper route / stop and delete dataIllustration of how the measures might look for a six-GP practice. Two GPs and one nurse pilot the tool for ten weeks. Each logs the minutes to review and approve a note, with a baseline from the prior fortnight. The Clinical Safety Officer audits 20 notes a month against the recording or consultation memory, counts omissions and wrong entries, and reports to a partner meeting. An incident, such as a note filed to the wrong record, stops the pilot until the cause is found. These figures are examples, not targets from the guidance.
Ten weeks, week by week
A pilot is easier to run when each week has one job. This is an illustrative plan for a practice that starts with the paperwork and keeps live use short. It assumes nothing goes live until the safety and data documents are approved, which is the order the guidance implies.
- Weeks 1 to 2: paperwork. Name the Clinical Safety Officer, shortlist two registry suppliers, request their DCB0129, DTAC and data-processing evidence, and start the DPIA from the published template.
- Week 3: ICB conversation. Tell the ICB what you plan, ask for assurance, and ask what help is available for DCB0160. Do not sign anything commercial yet.
- Week 4: integration test. With the supplier, test write-back in a non-live or test patient record. Fix any matching problems before a real patient is involved.
- Week 5: training and notices. Train the pilot users, put up the patient notice, and agree the fallback if the tool fails.
- Weeks 6 to 9: live use. Two or three clinicians, a limited consultation mix, weekly check-ins and a monthly audit.
- Week 10: decision. Report edit time, errors, incidents and patient objections, and make the adopt, extend or stop decision before the four-month ceiling.
Note that live use here covers only four of ten weeks. That is deliberate: most of the safety value is in the groundwork, and a pilot that spends half its allowance on paperwork is a good sign, not a slow one.
A write-back mistake and how the audit caught it
Illustration of a realistic failure. In week seven of a pilot, a nurse practitioner sees two patients with similar surnames back to back. The scribe produces both notes correctly, but the second is filed to the first patient's record because the integration matched on a surname and an appointment slot that overlapped. The nurse had approved the note without scanning the patient identifier on screen.
The weekly check-in catches it because the Clinical Safety Officer asked every user to report any wrong-record entry, however minor. The practice pauses the pilot for two days, logs the incident in the hazard log, asks the supplier to fix the matching rule to use the NHS number rather than name and time, adds an identifier check to the approval step, and restarts after a test. The result: a hazard that was on the log in advance, a control that existed on paper and now works in practice, and a written record of how the practice responded. This is what the monitoring framework is for.
An email to send each supplier before the demo
Send the same message to every supplier on your shortlist so you can compare replies line by line. Illustrative text:
Subject: Ambient scribe pilot, questions before a demo
Hello [first name],
We are a [size] GP practice planning a time-limited pilot (no more than four months) of an ambient scribing product under NHS England's guidance. Before a demo, please send:
1. Your AVT Supplier Registry entry and the evidence you supplied for it.
2. Your DCB0129 safety documentation and DTAC assessment.
3. Your medical device determination and MHRA registration status, if applicable.
4. How notes are written back to [EMIS Web / SystmOne], whether this is live at practices today, and what is written back (free text, codes).
5. Where audio, transcripts and notes are stored, for how long, and your sub-processors.
6. Whether any client data is used to train models.
7. Your price per clinician per month, any minimum term, and exit and deletion terms.
Kind regards,
[your name]Compare replies for speed and specificity as well as content. A supplier that sends a link to a generic security page has told you something about how a four-month pilot will go.
Procurement: why the pilot is not the purchase
The guidance says the registry is not a commercial framework. If you intend to buy, you follow appropriate local, regional and national commercial requirements, and you should only procure through frameworks operated by accredited framework hosts. Before that, develop a clear picture of what you want to buy and assess interoperability with your critical systems. A short specification written before the first demo saves months: the clinical record system, the consultation types, the number of users, the data you will not allow to leave a given region, and the contract exit terms.
Monitoring, bias and accents: what to check after go-live
The guidance asks you to monitor performance over time independently of the manufacturer: error reporting, service use, and comparison between reported and observed errors. It also warns that these products may perform differently with some accents or dialects, with participants who speak English as a second language, or with speech impairments. Check it against your own population, and watch whether any patient groups hesitate to seek care because they object to the tool.
- Accents and interpreters. Test with a consultation that includes an interpreter and with patients whose speech the tool is likelier to misread. Record the miss rate separately.
- Microphone placement. The guidance says proximity and positioning affect results. Decide where the device sits in each room and write it in your training sheet.
- Silent functions. Compare the supplier's release notes with your hazard log each quarter.
- Training. Teach clinicians how to dictate clearly, and reinforce that they remain responsible for reviewing and correcting every output.
Liability, contracts and the exit you need
The guidance notes that an NHS organisation may still be liable for claims arising from the use of AI products, especially where a non-delegable duty of care is involved. It says the exposure can be reduced by clear contracting that sets out each party's roles, responsibilities and liability. It also asks you to ensure data portability and to plan for maintenance: who stores data, who pays for subject access requests, who handles updates, and service level agreements for uptime, response times and support. Ask for these in the contract, not in an email from a salesperson.
Exit terms deserve their own line. If you leave the supplier at the end of the pilot, what is deleted, when, and what proof do you get? The related contract terms checklist for a voice agent shows the same pattern of minutes, data and exit terms in another setting.
Free tools and clinician-led trials: the shadow-use problem
The guidance says it is for settings implementing a specific product, not for individuals using tools outside their setting's supervision. It also lists as a risk that some users may use products outside supervision, circumventing policies and approvals. In practice, that is the free scribe a clinician downloads on their own phone. Address it head on: a short, kind policy that says which tools are approved, why, and what to do if someone is tempted. The tutorial on what GP scribes cost, including free tiers explains why a free tier can be a poor fit for a practice that has to meet these standards.
Telling patients, and handling objections
The guidance asks you to be transparent about how information is used and shared. In practice: a notice in the waiting room and on the website explaining that an AI-enabled note-taking tool may be used, what it records, who processes it, and how to say no. At the consultation, the clinician asks and notes the answer. Plan for the patient who says no: the clinician types as usual, and the practice does not treat that as a problem. For wording and trust, see how to roll out a scribe without losing patient trust.
The shortlist and decision rule in one page
Use this one-page scorecard to compare two suppliers. Mark each row pass, fail or unknown, and treat any fail or unknown in the first three rows as disqualifying until fixed.
| Row | Question | Supplier A | Supplier B |
|---|---|---|---|
| 1 | On the registry, evidence read, DCB0129 and DTAC evidence seen | Pass | Unknown |
| 2 | Write-back live for our clinical system, not planned | Pass | Fail |
| 3 | Medical device determination stated; guardrails stop diagnosis suggestions | Pass | Unknown |
| 4 | Data region, retention and sub-processors documented | Pass | Pass |
| 5 | Works for our accents and interpreters in test | Pass | Not tested |
| 6 | Contract: liability, SLA, exit and deletion in writing | Unknown | Unknown |
Supplier A advances to the pilot; Supplier B does not until rows 1, 2 and 3 are resolved. That is the whole decision rule: no pilot starts with an unknown in safety, integration or regulatory status. If the partners also run a private clinic on a different record system, picking a scribe by record system shows how the shortlist changes there.
Practice manager questions on NHS scribe pilots
Does being on the registry mean a scribe is NHS-approved?
No. The registry is a national self-certified list of suppliers with evidence for local buyers to examine. NHS England's guidance says it does not endorse any supplier and carries out only preliminary completion checks. Your practice still does its own safety, data protection and procurement work.
Can a GP just try a free scribe on their own?
NHS England's guidance is aimed at settings adopting a product under their own supervision, not individuals using unauthorised applications. A clinician trialling a free tool on patient consultations without the practice's assessments creates exactly the risk the guidance warns about. Route any trial through the practice.
How long can a pilot run?
The guidance allows pilots or proofs of concept to continue only if they are time-limited, up to four months, and are not used to bypass compliance. Treat four months as a ceiling, write the end date and the success measures down at the start, and decide before the end whether to adopt, extend through proper procurement, or stop.
Who signs off the clinical safety documents?
A Clinical Safety Officer for your organisation. They are responsible for the DCB0160 documentation, which includes the safety case, hazard log and monitoring plan. If the practice lacks that capability, the guidance says you can seek help from your local integrated care board.
Further reads
- Telling Patients You Use AI Note-Taking: Consent Wording That Works — Wording for telling patients about AI note-taking.
- AI Scribe Security: Audio, Retention and BAA Vendor Questions — Security questions to ask each supplier.
- What Is an AI Scribe and How Does It Work in a Consultation? — How a scribe works inside a consultation.
- What to Ask Before Buying Any AI Tool for a Medical Practice — General buying questions for a medical practice.
- Is an AI Scribe Worth It for a Small Private Clinic? — Whether the time saved justifies the cost.
- A Worked AI Implementation Plan for a Small Medical Practice — A wider implementation plan for a small practice.
- AI Receptionist for a GP Surgery: The 8am Rush and Hand-Offs — A practical overflow test and clinical hand-off plan for a surgery considering an AI phone receptionist.
- AI Policy for General Practice: A Template for UK Surgeries — A fill-in AI policy for a GP surgery: approved tools, patient data rules, DCB0160 and DPIA sign-off, incident handling and a review cycle.
- AI Scribe for Physiotherapists in the UK: A Consent and GDPR Checklist — A twelve-step checklist for a UK physio clinic adopting an AI scribe: consent, DPIA, vendor contract, data location, retention and HCPC standards.
- CQC and GP Practices: Build an Evidence Folder With AI — Organise a GP practice's CQC evidence by key question and quality statement, with an AI-built index, policy review log and mock-inspection summary.
- Free AI for Healthcare Providers: Six Free Tiers and Their Limits — Heidi, Carepatron, ChatGPT for Clinicians and three consumer free plans compared on limits, data terms and whether patient information belongs in them.
- GDPR in a Dental Practice: Which AI Tools Staff May Use — Which AI uses are fine for dental staff, which need a contract and a DPIA first, and which to ban, with an approved-tools list you can copy.
- What Policies Should a GP Practice Have? Checklist and AI Drafts — A GP practice policy checklist grouped by risk, with a review calendar and tested prompts for drafting each policy with AI before a partner signs it off.
- AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.
Sources: NHS England, Guidance on the use of AI-enabled ambient scribing products in health and care settings (second iteration, read November 2026).