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. MHRA medical-device regulation also applies if the manufacturer intends the product for a medical purpose — and on 29 July 2026 the MHRA published dedicated guidance on where that line falls for ambient voice technology. It is not where most people assume. 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.

Where the MHRA draws the line. The test is the manufacturer's intended purpose, not the technology. MHRA's worked examples of AVT products that are not medical devices include transcription; summarisation of the consultation for the clinician to review and correct; structuring information into problem or medication lists for the clinician to confirm; suggesting clinical codes for terms explicitly mentioned in the conversation; and drafting a discharge summary or letter for the clinician to review and edit. Its examples of products that are devices turn on intent: a summary offering "generated insights" that suggest diagnoses or treatments; a scribe marketed as guiding "diagnosis and treatment planning"; an agent that determines and orders follow-up tests without clinician confirmation; and a product that analyses record data to recommend diagnoses.

Source: MHRA, Ambient voice technology-enabled products, published 29 July 2026.

This is a change from where the debate sat a year ago, and it is worth being explicit about. An earlier reading — including in an earlier version of NHS England's own ambient-scribing guidance — treated generative summarisation as the trigger in itself. That is no longer the published position. NHS England revised its guidance on 29 July 2026 to align with the MHRA, and it now says the guidance "is not intended to provide a specific determination of which ambient scribing products meet the definition of a medical device", asking adopters instead to "ensure that the ambient scribing product has been correctly considered under medical device regulation" and to comply with that regulation "where applicable" (NHS England, Guidance on the use of AI-enabled ambient scribing products in health and care settings, version 3, published 27 April 2025, last updated 29 July 2026).

What this means for your practice. The DCB0160 question does not move: the scribe is a Health IT System used in real-time direct care, so the assessment is yours to do whatever the MHRA answer turns out to be. The medical-device question is narrower than the market believes, and it is answered by what the manufacturer says the product is for — in the Instructions for Use, the labelling and the sales material. So read the vendor's marketing as carefully as the specification. A product sold on administrative time-saving and a product sold as improving diagnosis are in different regulatory positions even if the code is identical. 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 lists 27 suppliers (NHS England Digital, AVT Self-Certified Supplier Registry, last edited 21 August 2026). NHS England is explicit that listing is not endorsement and that this is not a commercial framework — procurement and assurance stay with you.

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 is the product's stated intended purpose, and have you assessed it against the MHRA's ambient voice technology guidance? Ask for the answer in writing, with the reasoning. "We are not a medical device" is a conclusion, not evidence.
If it is a device, what MHRA registration do you hold and which functions does it cover? Ask for the registration reference, the class and the date. If it is not a device, ask them to confirm that no function suggests diagnoses, recommends treatment or acts without clinician review.
Does any of your marketing claim clinical benefit? Under the MHRA's guidance, claims about guiding diagnosis, treatment planning or patient outcomes can make an otherwise administrative product a medical device. A mismatch between the specification and the sales deck is a genuine finding.
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? DCB0129 makes both mandatory artefacts. 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. Get the vendor's written intended-purpose assessment against the MHRA's ambient voice technology guidance, and where the product is a device, the registration reference and class. Record whichever answer you get and the reasoning behind it.
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. DCB0129 and DCB0160 are themselves under review, and the public consultation on revised versions closes on 11 September 2026, so date-stamp your safety case and re-check the standards (NHS England Digital, Review of digital clinical safety standards, last edited 30 June 2026).

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.
Ambient voice technology-enabled products (MHRA). Published 29 July 2026.
Guidance on the use of AI-enabled ambient scribing products in health and care settings (NHS England). Version 3, published 27 April 2025, last updated 29 July 2026.
Ambient Voice Technology Self-Certified Supplier Registry (NHS England Digital). Last edited 21 August 2026.
Review of digital clinical safety standards DCB0129 and DCB0160 (NHS England Digital). Last edited 30 June 2026.

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?

Often not. The MHRA's ambient voice technology guidance (29 July 2026) puts the test on the manufacturer's intended purpose, and gives transcription, summarisation for review, structured-data capture, code suggestion and letter drafting as examples of products that are not medical devices. A scribe becomes a device when it is intended to do something clinical: suggest diagnoses or treatments, get marketed as guiding diagnosis or improving outcomes, or act on its own output without clinician review. Note that a common earlier reading treated generative summarisation itself as the trigger; that is not the current published position. Either way, the DCB0160 assessment is still yours to do.

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 lists 27 suppliers (page last edited 21 August 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 — but NHS England states plainly that it does not endorse the suppliers on it, so the assurance work is still yours.

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, and the public consultation on revised versions closes on 11 September 2026 (NHS England Digital, last edited 30 June 2026). Note that a revised standard would be published under the amended section 250, so it would carry a "must comply" duty rather than today's "have regard to". 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.