AI Scribes in GP Practices: DCB0160 and MHRA Compliance Guide

Why This Article Exists

Deploying an AI ambient voice scribe in a GP practice usually triggers two regulatory regimes, not one. DCB0160 always applies, because the scribe is a Health IT System used during real-time direct care. MHRA medical-device regulation also applies if the scribe does anything beyond pure transcription, and almost all current products do, because they summarise, structure notes, suggest codes, draft letters, or populate the record. NHS England's published position (27 April 2025, last updated 24 April 2026) is that suppliers of generative AI scribes must hold at least MHRA Class I registration and that NHS organisations should procure only from the Ambient Voice Technology Self-Certified Supplier Registry. This article walks through what that means for your practice: the two-regime model, the questions to ask the vendor, the three main clinical-risk categories, the controls that work in a five-minute consultation, and a realistic eight-to-twelve-week deployment timeline.

This article assumes you understand the basics of DCB0160. If you do not, start here:

A Simple Guide to DCB0160: Understand the standard
What is a Clinical Safety Officer?: Learn about the CSO role
How to Conduct a DCB0160 Assessment: Understand the assessment process
What is a Digital Clinical Safety Management System?: Build the framework

DCB0160 and MHRA: Why Most AI Scribes Trigger Both

There are two overlapping regulatory regimes for digital products used in NHS care. Practice managers and clinical leads often hear about one but not the other, then deploy a scribe believing they have addressed compliance when they have only addressed half of it. The same two-regime model applies to clinical decision support, risk calculators and EPR modules; for the broader buyer's view of how DCB0160 and MHRA medical-device regulation interact across GP-practice software, see DCB0160 and MHRA Medical Devices: How the Two Regimes Apply to Software in GP Practices.

Regime 1: NHS clinical safety standards. DCB0129 covers the manufacturer; DCB0160 covers the deploying organisation (your practice). They apply to any "Health IT System" used "to influence, support, manage the real-time or near-real-time direct care of patients". An ambient scribe sitting in a consultation clearly meets this test. (NHS England Digital, applicability step-by-step, last updated 4 August 2022.)

Regime 2: MHRA medical-device regulation. Under the Medical Devices Regulations 2002 (S.I. 2002/618), regulation 2, software is a medical device if the manufacturer's intended purpose includes "diagnosis, prevention, monitoring, treatment or alleviation of disease" and similar clinical purposes. NHS England has published a specific position on AI ambient scribes that draws the line at what the scribe does with the audio.

NHS England's test (verbatim). Pure transcription products that "solely generate text transcriptions that are easily verified by qualified users" are unlikely to be medical devices. But "the use of Generative AI for further processing, such as summarisation, would be treated as high functionality and likely would qualify as a medical device". Functions that trigger device status include "providing 'call for action' prompts or feedback/suggestions on the consultation… functions that generate clinical codes, letters or health records that inform clinical decisions".

Source: NHS England, Guidance on the use of AI-enabled ambient scribing products in health and care settings, published 27 April 2025, last updated 24 April 2026.

Most current AI scribes are not pure transcribers. They produce structured SOAP notes, draft referral letters, suggest Read or SNOMED codes, or write directly into the EPR. Each of those features is "further processing". NHS England's stated expectation is that suppliers of these products hold "at least MHRA Class I Registration" and a UKCA certificate "for clinical use of medical devices in the NHS" (same source).

What this means for your practice. Deploying an ambient scribe is not a DCB0160 question alone. It is also a procurement question: is the supplier on the AVT registered list, do they hold MHRA Class I registration, and does the registration cover the version and modules you are actually deploying? Both regimes generate ongoing obligations on different parties through different mechanisms, and DCB0129/DCB0160 explicitly do not replace medical-device requirements (DCB0129 Specification v4.2, p.9, NHS England Digital).

Module-Level Thinking

The MHRA's stand-alone software flowchart is explicit that classification is module-by-module, not whole-product:

"In complex systems it may be appropriate to UKCA mark only those functions/modules that meet the definition of a device rather than UKCA marking the whole product."

Source: MHRA, Medical device stand-alone software including apps (v1.10f), last updated 1 July 2023, p.9.

This matters for ambient scribes because most products are bundles. The transcription engine, the summarisation model, the coding suggestion module, and the letter-generation module may each sit in a different place. When you ask the vendor about MHRA status, ask which modules are covered, not just whether the company is registered.

The AVT Self-Certified Supplier Registry

NHS England Digital maintains the canonical list of AI scribe suppliers that have self-certified compliance with NHS England's ambient scribing guidance. The registry currently lists 23 suppliers (NHS England Digital, AVT Self-Certified Supplier Registry, last updated 17 April 2026).

Two things to understand about the registry:

Self-certification is not endorsement. Suppliers attest to meeting NHS England's expectations on data protection, clinical safety, MHRA registration, hosting, and information governance. NHS England Digital lists them; it does not vouch for them. Procurement assurance still sits with the deploying organisation, which is you.
Absence is a hard signal; presence is a soft signal. If a vendor is not on the registry, that is a meaningful concern: NHS England's stated expectation is that NHS organisations procure from registered suppliers. If a vendor is on the registry, you still have to do your own due diligence.

If a vendor tells you they are "MHRA registered" or "DCB0129 compliant", the registry is the place to verify it. If they are not on it, ask why.

Questions to Ask the Vendor Before You Sign

Use these questions in the first procurement conversation. The answers go directly into your DCB0160 hazard log and your supplier file. If a vendor cannot answer them in writing, treat that as a data point in itself. The vendor's answers on regulatory status are checkable in primary-source databases: the AVT registry and PARD buyer's verification workflow walks through both lookups end-to-end, including how to read a GMDN code and a reusable ten-step buyer's checklist.

Regulatory status

Are you listed on the AVT Self-Certified Supplier Registry? If not, why not, and is registration in progress?
What MHRA registration do you hold, and which modules of your product does it cover? Class I is the minimum NHS England expects. Ask for the registration reference and the date.
Do you hold a UKCA certificate? NHS England's guidance specifies "UK Conformity Assessed (UKCA) certificate for clinical use of medical devices in the NHS".
Is your product "pure transcription" or does it perform further processing (summarisation, coding, letter generation, EPR write-back)? Map their answer to NHS England's published test. If they claim pure transcription but the product clearly does more, that is a contradiction worth resolving.
What changed at your last MHRA registration update, and how do you handle re-registration when models or features change materially? AI scribes update frequently. The post-market surveillance obligation is on them, but you need to know how they manage it.

Clinical safety documentation

Can you share your DCB0129 Clinical Safety Case Report and Hazard Log? These are not optional. If they cannot share them, they have not done DCB0129.
Who is your Clinical Safety Officer, and what are their credentials? Per NHS England's clinical safety standards, the CSO must be a registered healthcare professional with appropriate training.
What AI-specific hazards are in your hazard log? Look for: hallucinated content, transcription errors on accents and clinical terms, drug-name confusion, omission of red flags, incorrect code suggestion, and misattribution of speakers.
How do you handle model updates, and what is your change-control process? Material changes to the model can change the safety profile. They need a process for re-running the hazard analysis and notifying you.

Data and information governance

Where is the audio processed and stored, and where is the resulting text stored? UK or EEA hosting matters for NHS data.
Do you train your models on consultation audio? If yes, what is the consent and de-identification model? Many practices and ICBs treat training-on-consult-audio as a hard no.
What is your data-retention policy for audio and transcripts? Default retention should be short. Audio retained "indefinitely for model improvement" is a red flag.
Will you sign a Data Processing Agreement that names your sub-processors? The whole chain matters under UK GDPR.
Do you have a current Data Protection Impact Assessment template you can share? Saves time, and shows the supplier has thought about it.

Operational fit

What is your incident-reporting process for clinical safety incidents that come to your attention via other practices? You want to be told about systemic issues even if your practice did not surface them.
What support model do you offer during the pilot phase? Daily-issue triage matters more than 24/7 phone support during week one.
What does deprecation look like, and how much notice do you give if you discontinue a feature or the product? Embedded clinical workflows are hard to unwind.

You will not get perfect answers to all seventeen. The goal is a written record of where the gaps are, so the CSO can decide whether the residual risks are acceptable.

The Three Main Clinical Risk Categories

Ambient scribes introduce three broad categories of clinical risk in a GP setting. Use these as the starting hazard list for your DCB0160 assessment, then add hazards specific to your workflows.

1. Medication Errors

The model mishears, misinterprets, or hallucinates medication names, doses, routes, durations, or allergy information.

"Zantac" recognised as "Xanax".
"20 milligrams once daily" written as "200 milligrams once daily".
An allergy mentioned in passing not captured, leading to a contraindicated prescription.
A medication discussed-but-not-prescribed appearing in the structured note as if it had been prescribed.

2. Wrong Follow-Up Actions

The model fails to capture, or misrecords, referrals, investigations, safety-netting advice, or onward care.

A two-week-wait referral discussed but not actioned in the note.
An investigation listed under the wrong urgency.
Safety-netting advice generic rather than condition-specific.
A follow-up appointment timing that conflicts with what was actually agreed.

3. Inaccurate Clinical History

The model misrecords history, examination findings, diagnostic certainty, or critical contextual status.

Red-flag symptoms downgraded to ordinary symptoms.
Examination findings invented or transposed.
A working diagnosis recorded as a confirmed diagnosis.
Pregnancy, safeguarding concerns, mental capacity issues, or end-of-life status not captured at all.

The common thread across the three is that AI-generated output can be plausible-sounding but wrong. Plausibility makes errors harder to catch than overt system failures. For a longer guide on identifying hazards methodically, see How to Conduct a DCB0160 Assessment.

Controls That Work in a Five-Minute Consultation

Generic controls (such as "clinician review" or "decision support") are not enough on a DCB0160 hazard log. Each control must answer the question: what does this look like in a real consultation, and what stops the clinician skipping it under time pressure? The controls below are written to that test.

Medication-Safety Controls

Mandatory in-EPR prescription review. The scribe drafts; the prescription is not issued until the GP opens the prescribing screen, sees the drug-allergy interaction check, and clicks Authorise. The scribe never writes directly into the prescribing record without that step.
Drug-name read-back during the consultation. Where a medication change is discussed, the GP confirms the name and dose verbally with the patient. The note then matches what was confirmed, not what the model heard first.
End-of-day medication-change audit during pilot. The CSO or a deputy reviews every medication change captured by the scribe against the consult, daily, for the first two weeks of pilot.
Allergy-mismatch alert. If the scribe captures a medication that conflicts with a recorded allergy, the EPR's existing alert must fire before the prescription can be issued. If the scribe write-back bypasses this alert, the integration is unsafe.

Follow-Up Action Controls

Structured action capture. Referrals and investigations come from EPR-native templates, not free text in the AI summary. The scribe drafts a suggestion; the GP selects the structured option.
End-of-consultation checklist. A short on-screen prompt at consult close: "Referrals issued?", "Investigations ordered?", "Safety-netting given?". Forces a yes/no answer before the consult is signed off.
Admin-team second check during pilot. For the first month, the admin team confirms that referrals visible in the consultation note have been actioned in the referral system. Mismatches go to the CSO.
Condition-specific safety-netting templates. Generic "come back if it gets worse" gets replaced with red-flag-specific templates for chest pain, headache, back pain, paediatric fever, and so on. The scribe is allowed to populate these but not to invent its own.

Clinical-History Controls

Structured red-flag capture. Common red-flag symptoms (chest pain, breathlessness, suicidal ideation, paediatric fever, postnatal mental health) are captured via structured prompts in the EPR, not via free text in the summary.
GP review of summary before signing the consult. The clinician reads, edits, and signs the AI-generated summary before it is committed to the record. The scribe must not auto-commit.
Examination-findings template. Structured examination templates reduce the model's freedom to invent findings. The scribe fills the template; the GP confirms or edits.
Critical-status flags. Explicit prompts for pregnancy, safeguarding, mental capacity, and end-of-life context. These are captured in coded fields, not free text, so they survive note review.

The principle running through all of these is simple: the AI suggests, the clinician decides, and the workflow makes the decision step impossible to skip. Controls that rely on the clinician remembering to review under time pressure are weaker than controls baked into the EPR step that has to happen anyway.

The Assessment Process

Follow the standard DCB0160 assessment process, with the AI-specific additions called out below.

Verify regulatory status. Check the AVT Self-Certified Supplier Registry. Confirm MHRA registration. If the product performs further processing, the supplier should hold Class I as a minimum.
Request vendor DCB0129 documentation. Safety case, hazard log, evidence of CSO, change-control process. AI-specific hazards should be visible in the log.
Identify deployment-specific hazards. Use the three risk categories as the starting point. Add hazards from your workflows: how telephone consultations are handled, accent diversity, multi-speaker rooms (carer present), home-visit recording, paediatric consultations.
Score risk. Likelihood × severity for each hazard. Treat "AI plausibility" as a likelihood multiplier. Errors that look right are more likely to get through clinician review than obvious errors.
Design controls. Per category, per workflow. Each control must pass the five-minute-consultation test.
Pilot with close monitoring. One or two clinicians, two to four weeks, daily review of outputs.
Document the safety case. Hazards, controls, residual risks, CSO approval, monitoring plan, escalation route.
Roll out gradually. Phase by clinician group, with monitoring continuing.
Re-assess on material change. Vendor model update, EPR change, scope expansion to telephone consultations or home visits: each is a trigger to re-run the relevant parts of the hazard analysis. NHS England has flagged that DCB0129 and DCB0160 are themselves under review (focus groups completed by mid-2025; revisions to be consulted on), so date-stamp your safety case and re-check the standards annually (NHS England Digital, Review of digital clinical safety standards, last updated 22 July 2025).

Expect eight to twelve weeks from initial assessment to full deployment.

Time Required

Based on typical implementations, expect these time commitments. They assume good vendor DCB0129 documentation and a registered AVT supplier. Poor vendor support can double these times, and a supplier not on the registry can add weeks of due diligence.

CSO Time

Initial assessment and setup: 8–12 hours (spread over 2–3 weeks).
Pilot phase: 4–6 hours per month for 3 months.
Ongoing monitoring: 2–4 hours per month once stable.

Practice Manager / Admin Support

Setup and documentation: 4–6 hours.
Pilot-phase admin checks: 2–3 hours per week for the first month.
Ongoing: 1–2 hours per month.

What a Typical 12-Week Deployment Looks Like

This is a generalised pattern, drawn from the assessment steps above. It is not a specific practice. Treat it as a structure to plan against, not a case study.

Weeks 1–2: Procurement and regulatory verification. Practice manager and CSO confirm the supplier is on the AVT registry, request MHRA registration evidence, request DCB0129 documentation, and review the data-processing terms. Any gaps are logged as procurement actions before the contract is signed. CSO time: 3–4 hours. Admin time: 2–3 hours.

Weeks 3–4: Hazard identification and control design. CSO works through the three risk categories with one or two pilot clinicians, mapping each to specific controls in the practice's EPR and workflows. The hazard log is drafted, scored, and signed off by the CSO. Information governance lead reviews data flows and the DPA. CSO time: 4–6 hours. Clinician time: 1–2 hours each.

Weeks 5–8: Pilot. Two GPs use the scribe with the controls in place. Daily output review by the CSO or deputy for the first two weeks; weekly thereafter. Workflow issues are logged and fixed, or the deployment is paused. CSO time: 4–6 hours per month; pilot clinicians' own consultation time, plus around an hour a week of feedback.

Weeks 9–12: Phased rollout. If the pilot confirms controls work, the scribe rolls out to the next clinician cohort. Monitoring continues. Safety case is finalised, signed by the CSO, and stored with the practice's other clinical safety records. The PM updates the supplier file with the regulatory evidence collected.

Beyond week 12: Quarterly review by the CSO; spot-audit of consultations against scribe output monthly; re-run the relevant hazard analysis on any material vendor change. Re-check the AVT registry annually.

This pattern is intended as a planning skeleton. The actual time and effort for a given practice depends on how good the vendor documentation is, how comfortable the clinical team is with the controls, and how much existing clinical safety governance is already in place.

Common Pitfalls

Pitfall 1: Treating DCB0160 as Paperwork

Clinical safety is not a compliance exercise. It exists to prevent patient harm. Involve frontline clinicians in hazard identification. Controls designed without them tend to fail under time pressure.

Pitfall 2: Assuming the AVT Registry Is the Whole Story

The registry confirms the supplier has self-certified. Procurement assurance, your DCB0160 assessment, and the contractual data-protection terms still sit with you. The registry is a necessary check, not a sufficient one.

Pitfall 3: Confusing DCB0129 With MHRA Registration

DCB0129 covers clinical risk management in the manufacture of a Health IT System. MHRA registration covers placing a medical device on the market. They are different obligations on the supplier. A supplier can do DCB0129 and not be MHRA-registered, or be MHRA-registered without proper DCB0129. NHS England's guidance asks for both.

Pitfall 4: No CSO Time Allocated

If the CSO has no protected time, the assessment will not happen properly. Block diary time and name a deputy to cover leave.

Pitfall 5: Missing Vendor Documentation

Make DCB0129 documentation, AVT registry status, and MHRA evidence contractual requirements before you sign. If the vendor has not done their work, you will be doing it for them.

Pitfall 6: Assuming the Vendor Has Addressed All Risks

Vendors assess product safety in general. You assess deployment safety in your specific context: your workflows, your accents, your patient population, your room set-ups, your EPR.

Pitfall 7: Quietly Expanding Scope

A scribe that was assessed for face-to-face GP consultations in the surgery is not automatically safe for telephone triage, video consultations, home visits, paediatric clinics, or shared-room set-ups. Each new scope is a re-assessment trigger.

Pitfall 8: No Monitoring After Deployment

Controls only work if they are followed. Monitor continuously to ensure controls are effective and to identify emerging risks, particularly after a vendor model update.

Action Checklist

Resources to Bookmark

How to Conduct a DCB0160 Assessment: Step-by-step process
What is a Clinical Safety Officer?: The role leading your assessment
How to Build a Clinical Safety Management System: Set up the framework

Primary Sources Cited in This Article

DCB0160 publication record (NHS England Digital). Last updated 15 June 2023.
Applicability of DCB0129 and DCB0160, step-by-step (NHS England Digital). Last updated 4 August 2022.
DCB0129 specification v4.2 (NHS England Digital). Version dated 02.05.2018.
Medical Devices Regulations 2002, regulation 2 (legislation.gov.uk). Current in-force version (revision incorporating amendments to 17 June 2025).
Medical device stand-alone software including apps, v1.10f (MHRA). Last updated 1 July 2023.
Guidance on the use of AI-enabled ambient scribing products in health and care settings (NHS England). Published 27 April 2025, last updated 24 April 2026.
Ambient Voice Technology Self-Certified Supplier Registry (NHS England Digital). Last updated 17 April 2026.
Review of digital clinical safety standards DCB0129 and DCB0160 (NHS England Digital). Last updated 22 July 2025.

Frequently Asked Questions

Do AI scribes require a DCB0160 assessment?

Yes. Ambient voice scribes are Health IT Systems used during real-time direct care, which is the test set out in the NHS England Digital applicability guidance. The deploying organisation (your practice) is responsible for the DCB0160 assessment. The vendor's DCB0129 work covers the product as designed; your DCB0160 covers it as deployed in your workflows. Both are needed.

Are AI scribes medical devices under MHRA regulation?

It depends on what the scribe does. NHS England's 27 April 2025 guidance on AI ambient scribing draws the line at "further processing". Pure transcription that is easily verified by a qualified user is unlikely to be a medical device. Generative summarisation, structured-note generation, code suggestion, letter drafting, and EPR write-back are "further processing" and are likely to make the product a Class I medical device or higher. NHS England's stated expectation is that suppliers of these products hold "at least MHRA Class I Registration".

How do I check whether an AI scribe vendor is registered?

Use the Ambient Voice Technology Self-Certified Supplier Registry, maintained by NHS England Digital. The registry currently lists 23 suppliers (page last updated 17 April 2026). It is the canonical list for "is this scribe registered?". If a supplier tells you they meet NHS England's expectations on AI scribes, the registry is where that should be visible.

What are the biggest clinical safety risks with AI scribes?

Three categories. Medication errors: the model mishears or misinterprets drug names, doses, or routes, or misses an allergy. Wrong follow-up actions: referrals, investigations, or safety-netting are missed or misrecorded. Inaccurate clinical history: symptoms downgraded, examination findings transposed, diagnostic certainty wrong, critical status (pregnancy, safeguarding) not captured. The shared property is plausibility: AI-generated text reads correctly even when it is wrong, which makes it harder for a clinician to spot than overt errors.

Should clinicians review every AI-generated note?

Yes. The fundamental safety principle is that the AI suggests and the clinician decides. Every AI-generated consultation note, prescription, and follow-up action must be reviewed and approved by the clinician before it becomes part of the record. This is your primary control across all three risk categories. Removing it would make the deployment unsafe.

How long does it take to deploy an AI scribe safely?

Eight to twelve weeks from initial assessment to full deployment is typical: two weeks of procurement and regulatory verification, two weeks of hazard identification and control design, four weeks of close-monitored pilot with one or two clinicians, four weeks of phased rollout. CSO time is around 8–12 hours of initial assessment then 4–6 hours per month during the pilot phase.

What should I ask the AI scribe vendor before deployment?

The minimum: AVT registry status, MHRA registration evidence (and which modules it covers), UKCA certificate, DCB0129 safety case and hazard log, named CSO and credentials, change-control process for model updates, data hosting and retention, model-training-on-consult-audio policy, DPA with named sub-processors, and an incident-reporting process. The fuller seventeen-question list is above. If the vendor cannot answer in writing, log the gap and let the CSO decide whether the residual risk is acceptable.

What happens if the vendor changes the model after we have deployed?

Material model changes can change the safety profile. Your DCB0160 safety case should specify a re-assessment trigger on vendor model updates. The vendor's DCB0129 process should generate a notification when they make material changes. Practically, the CSO re-runs the parts of the hazard analysis that the change touches, confirms controls still work, and updates the safety case. Post-market surveillance under MHRA is a manufacturer obligation, not yours, but DCB0160 keeps the deployer obligation alive.

Does DCB0129 cover MHRA medical-device requirements?

No. The DCB0129 specification itself states that the standard "applies to all Health IT Systems including those that are also controlled by medical device regulations". That is, the two regimes run in parallel, and neither replaces the other. A vendor that produces DCB0129 documentation has not, by virtue of doing so, met any MHRA obligation. The reverse is also true: an MHRA-registered medical device used as a Health IT System still needs DCB0129 from the manufacturer and DCB0160 from the deployer.

Are the standards changing?

DCB0129 and DCB0160 are under live review by NHS England, with focus groups completed by mid-2025 and a public consultation on revisions to follow (NHS England Digital, last updated 22 July 2025). The MHRA medical-device framework is also being reformed incrementally. Post-market surveillance amendments came in during 2025, and a further statutory instrument introducing new pre-market requirements is expected in 2026 (GOV.UK, Implementation of the future regulations, last updated 12 March 2026). Date-stamp your safety case and re-check the standards annually.

Key Takeaways

Deploying an AI ambient voice scribe safely in a GP practice is a two-regime exercise. DCB0160 always applies because the scribe is a Health IT System used in real-time direct care. MHRA medical-device regulation also applies if the product does anything beyond pure transcription, and almost all current products do.

Use the AVT Self-Certified Supplier Registry as your canonical procurement check, ask the vendor questions in writing, and design controls that survive a five-minute consultation. The principle running through every control is the same: the AI suggests, the clinician decides, and the workflow makes the decision step impossible to skip.

Treat this deployment as the starting point for clinical safety governance across all your digital systems. Start with the scribe, then work through your other systems systematically.