Ambient Clinical Documentation: How AI Scribes Work

Updated October 2026: a short answer to what ambient clinical documentation is, the 2025–2026 evidence on time saved (JAMA multisite study, UCLA randomized trial), Epic AI Charting, Texas AI-disclosure rules and a section on AI scribes for telehealth visits.

This is engineering guidance, not legal advice. Confirm specifics with qualified counsel.

Why this matters

If you run or build a telehealth product, the ambient scribe is the AI feature your clinical users will ask for first, because documentation is one of the biggest sources of clinician burnout and one of the few places where AI already has measured results. But it is also the feature most likely to put patient data somewhere it should not be: the audio of an entire consult is among the most sensitive data a health system holds, and the scribe by definition sends it to a model to be processed. A founder or product lead needs to understand three things before committing budget — how the technology actually works, exactly where the patient-data path leaves the protected boundary, and what the human-review step has to look like so the feature helps clinicians instead of exposing them to liability. Get those right and the scribe is one of the most useful AI features you can ship; get them wrong and it is the fastest way to a breach or a malpractice headache.

What is ambient clinical documentation? The short answer

Ambient clinical documentation is software that listens to a patient visit in the background and drafts the clinical note for the clinician to review and sign; the tool that does it is called an ambient AI scribe. It chains three models: speech recognition turns the audio into words, diarization works out who said what, and a large language model shapes the transcript into a structured note such as a SOAP note. The clinician does not dictate or type during the visit, and nothing reaches the medical record until they have checked and signed the draft. For a one-line definition, see the ambient clinical documentation glossary entry.

So every ambient scribe is an AI scribe, but not every AI scribe is ambient: “ambient” means the input is the natural conversation itself, captured without the clinician doing anything extra.

What an ambient scribe actually is

Start with the everyday picture. In a traditional in-person visit a busy clinic might hire a person — a medical scribe — to sit quietly in the corner and write up the visit while the doctor focuses on the patient. An ambient AI scribe is the software version of that person: it sits invisibly inside the video call, listens to the whole conversation, and produces a first draft of the clinical note by the time the call ends. "Ambient" means it works in the background from the natural conversation, without the clinician dictating to it or stopping to type.

The clinical note it drafts is a specific, structured document. Most visits are written up in a format clinicians call a SOAP note — four sections covering what the patient reports (Subjective), what the clinician observes or measures (Objective), what the clinician concludes (Assessment), and what happens next (Plan). The scribe's job is to listen to a free-flowing conversation and reorganize it into those sections, pulling out the symptoms, the history, the medications, and the follow-up plan, and leaving out the small talk.

One distinction matters before we go further, because it sets up everything about compliance. A scribe is a documentation tool: it records and organizes what was said. It is not a decision tool: it does not tell the clinician what is wrong with the patient or what to prescribe. That line — documentation versus decision — is the same line that decides whether the feature is an ordinary product or a regulated medical device, and we will return to it. For now, hold the simple version: the scribe writes down the visit; the clinician still makes every clinical call.

How it works: the three-step pipeline

Ambient clinical documentation works in three steps: speech recognition turns the visit audio into text, speaker separation labels each line as patient or clinician, and a language model rewrites the labeled transcript into the sections of a clinical note. The clinician then reviews, edits and signs the draft, and the note becomes part of the record only after that signature.

Under the friendly description is a chain of three machine-learning steps. Each one is a place where audio or text is handed to a model, and — keep this in mind — each one is a place where patient data moves.

Figure 1. The ambient-scribe pipeline. Audio enters on the left and a draft note leaves on the right; every stage sits inside the compliance boundary and every model vendor needs a BAA.

Step 1 — Speech recognition (turning audio into words). The first model is an automatic speech recognition system, usually shortened to ASR. It takes the audio of the consult and produces a running transcript of words. Clinical ASR is harder than the dictation on your phone, because it has to cope with drug names, anatomy, accents, cross-talk, and the background noise of a patient sitting in a kitchen. General speech models get the everyday words right and stumble on the medical vocabulary, which is why clinical scribes either use medically tuned models or add a medical-terminology correction layer. The internals of streaming speech recognition — which models, how they run live — are covered in the AI engineering section's streaming ASR article; this article stays on the clinical and compliance side.

Step 2 — Speaker separation (working out who said what). A raw transcript is just words; a clinical note needs to know that "I've had the cough for three days" came from the patient and "let's start you on an inhaler" came from the clinician. The step that attributes each sentence to a speaker is called diarization. In a telemedicine call this is easier than in a crowded exam room, because each participant often arrives on a separate audio channel — the patient's microphone and the clinician's microphone are already distinct streams — which the system can use to label speakers reliably. Getting this wrong is not cosmetic: a note that attributes the patient's symptom to the doctor, or puts the doctor's instruction in the patient's mouth, is a clinical error.

Step 3 — Clinical summarization (shaping the note). The third model is a large language model — the kind of general text model behind modern chat assistants — given the speaker-labeled transcript and asked to produce the structured note. This is where the conversation becomes a SOAP note: symptoms sorted into the Subjective section, the plan into the Plan section, the chit-chat dropped. This step is also where the technology is most powerful and most dangerous, because a language model can write fluent text that was never said. We treat that risk in its own section below.

Three steps, three models, one through-line: audio in, structured note out. Everything else — the user interface, the EHR connection, the review screen — wraps around this core.

How much time does an ambient scribe save? The 2025–2026 evidence

The best evidence so far shows real but modest savings: about 16 minutes less documentation per 8 hours of scheduled patient care, roughly a 10% cut, in a JAMA study of 8,581 clinicians published in April 2026. Clinicians who used the scribe in at least half of their visits saved about 27 minutes of documentation per 8 hours. The scribe is still the AI feature clinicians ask for first, because documentation is the paperwork they finish at home after the kids are in bed — “pajama time” — but the business case should rest on measured numbers, not on vendor claims of an hour a day.

Two studies anchor the numbers in 2026:

• JAMA multisite study (April 1, 2026). Mass General Brigham, Emory, UCSF, Yale New Haven and UC Davis compared 1,809 clinicians who adopted Ambience, Nuance DAX Copilot or Abridge with 6,772 who did not, from June 2023 to August 2025. Adopters spent 13.4 fewer minutes in the EHR and 16 fewer minutes on documentation per 8 hours of scheduled care, and saw about 0.5 more patients a week. After-hours EHR work did not fall significantly overall.
• UCLA randomized trial (NEJM AI, published online November 26, 2025). 238 outpatient physicians across 14 specialties were randomized to Microsoft DAX, Nabla or usual care. Nabla cut time-in-note by 9.5% against control; DAX showed no significant change (−1.7%). Both groups reported lower task load and better burnout scores, and the trial recorded one mild adverse event.

Walk the arithmetic with those numbers. A clinician with 8 hours of scheduled telehealth visits a day, 4 days a week:

Average adopter (JAMA 2026):
   16 minutes saved per 8 scheduled hours × 4 days  = 64 minutes/week

Heavy user (scribe on 50%+ of visits):
   27 minutes saved per 8 scheduled hours × 4 days  = 108 minutes/week

Extra visits (JAMA 2026):            about 0.5 per week

That is an hour or two a week per clinician, not an hour a day, and the gain depends on how consistently the scribe is used. Primary care and advanced practice clinicians saved the most in the JAMA data; surgical specialties showed no significant change. That is why, of the six AI features in the map of where AI fits in a telemedicine product, the ambient scribe is still the AI feature clinical users ask for first: the time saving is measurable, burnout scores improve, and a more complete note helps the next clinician and the billing team. Plan adoption and training as part of the project, because the savings come from clinicians who use the scribe on most visits.

The compliance picture: where the patient data goes

Now the hard part. The audio of a medical visit is Protected Health Information — PHI for short, meaning any health data that can be tied to an identifiable person. A recording of a patient describing their symptoms is about as identifiable and as sensitive as health data gets. And the scribe, by its nature, sends that audio to a model to be processed. So the central compliance question from the AI map applies in full force: does PHI leave your protected boundary, and if so, who is on the receiving end and what have they signed?

Figure 2. The scribe's data path. The consult audio is PHI; it may go to a model only if that vendor is under a BAA and barred from training on it. The public-AI path is never allowed.

The contract gate: a signed BAA, plus the no-train clause

Under the US health-privacy law known as HIPAA (the Health Insurance Portability and Accountability Act), any outside company that handles PHI on your behalf is a business associate, and you must have a signed Business Associate Agreement — a BAA — with them before they touch a single record. The BAA is the signed promise a contractor makes before they get a key to the building. The rule is explicit: a business associate is anyone who "creates, receives, maintains, or transmits" PHI for you (45 CFR §160.103), and the agreement is required (45 CFR §164.502(e), §164.504(e)).

For an ambient scribe this gate is non-negotiable, because the scribe vendor receives the most sensitive stream you have. The good news is that the serious clinical-scribe vendors offer a BAA as standard — it is table stakes in this market. The trap is the same one that catches every AI feature: a vendor offering a BAA and your use being covered by that BAA are two different facts. The free or consumer tier of a general AI tool has no BAA; pasting a transcript into it is a violation no matter how good the output.

One clause is specific to AI and easy to miss. A standard BAA stops the vendor from misusing your data, but it may not stop the vendor from using your patients' conversations to train its general model. For an AI vendor you usually have to add that prohibition in writing. A vendor can be fully HIPAA-covered and still, by default, learn from your patients unless your contract says no. Insist on the no-train clause, and read the full BAA article before you sign.

The minimum-necessary and consent gates

Two more rules shape the scribe specifically. First, HIPAA's minimum necessary standard (45 CFR §164.502(b)) says you should send only the data the task requires — a reason to question whether you need to retain the raw audio after the note is drafted, or whether the transcript can be discarded once the clinician signs. Second, recording a visit at all is governed by consent and retention rules that differ by state and by whether you keep the audio; the patient should know the visit is being captured for documentation, and you need a defensible answer to how long the recording lives and who can reach it. The mechanics of consent, recording, and retention have their own article: patient consent, recording, and data retention.

If you do keep audio or transcripts, they are PHI at rest and inherit every storage rule — encryption, access control, and the audit log that records who opened what (45 CFR §164.312(b) requires that logging). The cheapest scribe architecture, from a compliance standpoint, is often the one that keeps the least: draft the note, let the clinician sign, and delete the raw audio.

State AI-disclosure laws: tell the patient

Recording consent is now joined by AI-disclosure rules at state level. In Texas, HB 149 (the Texas Responsible Artificial Intelligence Governance Act) has required providers since January 1, 2026 to tell patients, in clear plain language and no later than the date of service, when AI is used in their care; SB 1188, in force since September 1, 2025, requires practitioners who use AI to review AI-generated records under Texas Medical Board standards. Build the disclosure into the visit flow — a plain-language notice at booking or at the start of the call, with a way to opt out — so every state rule you serve is a configuration, not a rebuild.

The FDA line: a scribe is documentation, not a device — until it isn't

The second line that decides whether an AI feature is safe to ship is the regulatory one. The US Food and Drug Administration (FDA) regulates software that diagnoses, treats, or drives clinical decisions — a category called Software as a Medical Device, or SaMD. It does not regulate software that merely records and organizes information.

A pure ambient scribe sits comfortably on the safe side of that line. It documents what happened; it does not decide anything. The FDA's Clinical Decision Support Software guidance, re-issued as a revised final version on January 6, 2026 (docket FDA-2017-D-6569), draws the boundary, and documentation assistance falls outside it. The January 2026 update generally loosened the agency's posture toward lower-risk software, which is good news for scribe builders — but it kept the hard cases hard.

The catch is that scribes do not stay pure. The moment a scribe starts suggesting — proposing billing codes, flagging a care gap ("this patient is due for a screening"), or recommending a diagnosis from the conversation — it edges from documentation toward decision support, and the FDA line comes back into view. The rule of thumb that keeps a feature safe is the one from the CDS guidance: it must offer a recommendation to a clinician who can independently review the basis for it, not push a conclusion the clinician has to trust blindly or that goes straight to the patient. A scribe that drafts a note for a clinician to sign is documentation. A scribe that auto-codes a claim with no human able to check the reasoning is something the FDA — and your billing-compliance team — will want to look at. Design the suggestion features so a human can always see and override the reasoning, and you keep the scribe on the non-device side. The broader treatment of this line lives in the compliance and safety layer for clinical AI.

Accuracy, hallucination, and who is liable

A language model's gift and its curse are the same thing: it writes fluent, confident prose. In a clinical note, confident prose that was never said is a patient-safety risk. Three failure modes matter, and a product has to be designed against all three.

The first is hallucination — the model inventing something. The dangerous version in a scribe is a fabricated finding: a note that records a physical-exam step that never happened, or a symptom the patient never mentioned, simply because such things commonly appear in notes like this one. The second is omission — the model leaving out something that was said and mattered, like an allergy or a dose change. The third is the speaker mix-up from a diarization error, putting one person's words in another's mouth. Published reviews from 2025 put hallucination rates in the low single digits of notes, and the 2025 UCLA randomized trial rated clinically significant inaccuracies as occurring “occasionally” for both scribes it tested. That sounds small until you multiply it by the millions of visits a health system runs, and remember that a single fabricated allergy can harm a patient.

This is why the human-review step is not a nicety; it is the core of the design. No scribe output becomes part of the medical record until a qualified clinician has read it, corrected it, and signed it. The clinician is legally responsible for the note they sign, AI-drafted or not, so the product's job is to make review genuinely possible: surface the draft quickly, make edits easy, and never auto-file.

Figure 3. The review gate. The scribe produces a draft only; a clinician must review, edit, and sign before the note enters the record. No path skips the human.

Two design details have emerged from early deployments and malpractice discussion in 2025–2026, and both belong in a product spec. One is the idea of a reasonable review window: if the workflow leaves a clinician only a few seconds before the next patient, "review" becomes a rubber stamp, and a note signed without real review is hard to defend. Build the schedule and the interface so review has time to be real. The other is the discipline of keeping a draft state that is visibly unsigned and excluded from the legal record until the clinician acts — so an unreviewed draft can never be mistaken for a finished note. How the signed note then becomes a permanent, structured record is the EHR-integration question we turn to next.

EHR write-back: getting the note into the chart

A note that lives only in the scribe tool is half a feature. The value lands when the signed note flows into the patient's chart in the electronic health record (EHR) — the system of record clinics actually work in. This is the write-back step.

In 2026 the cleanest path uses the healthcare data standard called FHIR (Fast Healthcare Interoperability Resources), which models a clinical note as a DocumentReference resource that can be posted into the chart through the EHR's API. The important design rule mirrors the review gate: the integration writes the note as unsigned — in FHIR R4 that is DocumentReference.docStatus = preliminary, or the EHR vendor's own pending-signature queue — and the clinician's signature, in your app or in the EHR, is what finalizes it, so the human action — not the AI — is the thing that commits the record. The full mechanics of FHIR, HL7, and the realities of connecting to a specific EHR are covered in HL7, FHIR, and the EHR integration reality.

There is a strategic wrinkle worth flagging for product planners. On February 4, 2026 Epic — the EHR most large US health systems run on — released AI Charting, part of its Art tools for clinicians, which listens during the visit, drafts the note and queues orders from the conversation. Epic said in February 2026 that 85% of its customers were live with its generative-AI features (Fierce Healthcare), and specialist scribe vendors (Abridge, Ambience, Suki, Nabla, DeepScribe, Heidi and others) now compete with a tool built into the chart. For a telehealth product that means the write-back target is a moving one: build the integration so the note lands correctly whether the clinician finishes it in your app or in Epic, and assume the EHR vendors themselves are now competitors and partners at the same time.

Build vs buy: the vendor landscape and the build path

Almost every team faces the same fork: integrate an existing scribe vendor, or build the pipeline in-house. The honest answer for most telehealth products in 2026 is buy the model, own the workflow — use a mature scribe or ASR vendor under a BAA for the hard machine-learning, and build the parts that are specific to your product (the review screen, the EHR write-back, the consent flow). The table below lays out the buy options; every row includes the column that matters most in healthcare.

Figure 4. Four ways to add an ambient scribe, compared. The BAA column is the one that decides whether an option is even on the table for PHI.

Read the table by its last column first. Every serious option can be put under a BAA — but for the startups you must confirm the BAA covers the tier you are on, and for a self-build you need a BAA from each vendor in your chain (the ASR provider and the language-model provider both receive PHI). The self-build path is viable and gives you the most control: a clinical-grade speech API for steps 1 and 2, a language model on a BAA-covered tier for step 3, and your own review-and-write-back layer around them. It costs more engineering and more compliance work; you take it when the scribe is core to your product rather than a feature bolted on. The model-engineering details of that build live in the AI section's telemedicine AI-scribe engineering playbook and the intake-and-scribe system design; this article covers the clinical wiring and compliance around them. For a cost-and-architecture view of the same decision, read our ambient scribe build vs buy guide.

The specialist market is moving fast in 2026. Suki raised a $90 million Series E on October 12, 2026 and is extending its assistant from notes to referrals and prior authorizations, and it licenses its scribe to other health-tech products through a partner SDK and API. If you need an AI scribe API rather than a finished app, that partner route is the fastest way in; check that the vendor's BAA covers API use, not only its own app.

AI scribes for telehealth visits: what changes

An AI scribe for telehealth works best when it takes the audio from the video platform itself: each participant arrives on a separate track, so speaker separation is much easier, and the consent notice can be shown when the patient joins the call. The scribe can join as a server-side bot client that subscribes to the patient and clinician tracks from the media server (an SFU) and stops recording the moment the call ends. Diarization is still needed inside a track — a caregiver or an interpreter often shares the patient’s microphone — and a server-side bot is not possible if the call is end-to-end encrypted; then the scribe runs on the clinician’s device.

Three telehealth-specific design choices matter:

• Where the audio is captured. Capturing on the server from separate tracks gives clean per-speaker audio and a single place to enforce the BAA path. Capturing on the clinician’s device also works if the app taps the local microphone and the remote track separately before they are mixed; record a mixed stream and diarization has to do more work.
• Consent at join. Show the recording and AI notice in the waiting room or join screen, store the patient’s answer with the visit, and keep the scribe out of the call if they decline.
• On-device or self-hosted speech recognition. If you want the audio never to leave your boundary, run speech recognition on the clinician’s device or on your own HIPAA-covered servers, and send only the transcript to a language model under a BAA — or self-host that model too. This reduces the number of vendors that touch PHI, but you take on accuracy tuning for medical vocabulary yourself, and on-device models are smaller and usually weaker on drug names than cloud medical ASR.

A common, expensive mistake

The most frequent failure is not technical. It is a clinician, or a developer testing the feature, pasting a real consult transcript into a free, public AI chatbot to "clean up the note." That single paste sends PHI to a vendor with no BAA, and on a consumer tier the data may feed model training. It is a HIPAA violation whether or not anything bad ever happens, because the patient data crossed to an uncontracted vendor.

The fix is boring and absolute. Every tool that can touch a transcript is on an approved list, runs under a BAA on the exact covered tier, and the public consumer tiers are blocked at the network. Make the compliant path the easy path inside your product — a one-click "draft my note" that routes to the approved model — or the convenient shortcut wins and someone reaches for the public chatbot. The second-most-common mistake is the inverse of the review gate: letting a draft note auto-file or letting the clinician sign a stack of them without real review. Both are design failures, and both are preventable in the product.

Frequently asked questions

What is the difference between an AI scribe and ambient AI?

An AI scribe is any AI tool that drafts clinical notes, whether from dictation, a recording or typed input. Ambient AI is the subset that listens to the natural patient–clinician conversation in the background, so the clinician does nothing extra during the visit.

How does ambient clinical documentation work?

Speech recognition transcribes the visit, diarization labels who said what, and a language model turns the transcript into a structured note. The clinician reviews, edits and signs the draft, and only that signature makes the note final in the EHR.

Is ambient clinical documentation the same as speech recognition?

No. Speech recognition only turns speech into text, as in classic medical dictation. Ambient documentation uses speech recognition as its first step, then adds speaker separation and summarization to produce a finished draft note.

Is an AI medical scribe HIPAA compliant?

Only if every vendor that receives the audio or transcript has signed a BAA covering the exact tier you use, ideally with a clause that bars training on your data. Free consumer AI tools have no BAA and must never receive visit audio or transcripts.

What are the legal implications of using an AI medical scribe?

The clinician who signs the note is responsible for it, AI-drafted or not, so a real review step is required. Some states also require telling patients about AI use: Texas has required it since January 1, 2026.

Do AI scribes work for telehealth visits?

Yes, and often better than in person, because the video platform delivers each speaker on a separate audio track. The scribe can join the call as a server-side bot client (unless the call is end-to-end encrypted), and the consent notice can be shown when the patient joins.

Is there an API for ambient documentation?

Yes. Several scribe vendors, including Suki, license their scribe through a partner SDK and API, and you can also assemble one from a medical speech-to-text API and a language model under BAAs. Check that the BAA covers API use.

Where Fora Soft fits in

We build the telemedicine and real-time-video platforms that an ambient scribe attaches to, and we build them compliance-first: the patient-data path before the feature. When a client wants an ambient scribe, our work is to route the consult audio so the model vendor sits under a BAA with a no-train clause or never receives identifiable data, to keep the feature on the documentation side of the FDA line, to build the review-edit-sign gate into the product rather than bolt it on, and to wire the signed note into the EHR as a draft the clinician finalizes. The machine learning is increasingly a commodity you can buy; placing it correctly relative to the PHI boundary, the device line, and the clinician's signature is the engineering that keeps a launch — and the clinicians using it — out of trouble. Our telemedicine software development team builds the consult itself, our AI telehealth platform development team builds that scribe path into it, and our custom speech-to-text engineers tune the medical transcription it depends on.

The handbook

Fora Soft Video Engineering Handbook

We wrote the seven volumes that cover the whole video stack, pixel to production: compression, delivery, sound and AI, across 9,000+ pages. A scribe is assembled from parts the series takes apart one at a time. Start with the AI volume on models and speech, where recognition, diarization and summarization are worked through end to end; then the real-time AI volume for serving, cost per hour of audio and the compliance ground a clinical feature stands on; then the delivery volume for the WebRTC consult the scribe listens to. Written by Nikolay Sapunov, CEO at Fora Soft.

Browse the handbook on Amazon →7 volumes · Kindle & paperback

See our case studies

References

1. HHS, HIPAA Privacy Rule — business-associate definition and contract requirement, 45 CFR §160.103, §164.502(e), §164.504(e). Why any AI scribe vendor that receives consult audio or transcripts needs a signed BAA. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-160/subpart-A/section-160.103 — tier 1.
2. HHS, HIPAA Privacy Rule — minimum necessary standard, 45 CFR §164.502(b) and §164.514(d). The basis for limiting retained audio/transcripts to what the documentation task requires. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.502 — tier 1.
3. HHS, HIPAA Security Rule — audit controls, 45 CFR §164.312(b), and technical safeguards, §164.312(a)(1),(e)(1). Logging and access control for stored PHI (audio, transcripts, notes). https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.312 — tier 1.
4. FDA, Clinical Decision Support Software — Guidance for Industry and FDA Staff (revised final, January 6, 2026; docket FDA-2017-D-6569). The documentation-versus-decision line; documentation assistance falls outside device regulation. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/clinical-decision-support-software — tier 1.
5. 21st Century Cures Act §3060(a) (2016), amending §520 of the Federal Food, Drug, and Cosmetic Act to exclude certain decision-support software from the device definition. The statutory basis the FDA CDS guidance interprets. tier 1.
6. HHS, Guidance Regarding Methods for De-identification of PHI under 45 CFR §164.514(b) — Safe Harbor and Expert Determination. Relevant if transcripts are reused for analytics or model evaluation. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.514 — tier 1.
7. HHS, HIPAA Security Rule NPRM (RIN 0945-AA22; Federal Register, Jan 6, 2025) — proposed strengthening of technical safeguards (MFA, encryption). Still proposed, not final, as of October 2026: the HHS regulatory agenda moved the final-rule target from May 2026 to July 2027 (Alston & Bird, HHS Delays HIPAA Security Rule to 2027, July 10, 2026, https://www.alston.com/en/insights/publications/2026/07/hhs-delays-hipaa-security-rule-2027); cited as proposed. tier 1.
8. HL7 FHIR R4 (2019) — DocumentReference resource and SMART on FHIR app-launch; the standard mechanism for writing a signed note back into an EHR. https://hl7.org/fhir/R4/documentreference.html — tier 1.
9. Beyond human ears: navigating the uncharted risks of AI scribes in clinical practice, npj Digital Medicine (2025). Peer-reviewed account of hallucination, omission, and speaker-attribution failure modes in clinical scribes. https://www.nature.com/articles/s41746-025-01895-6 — tier 5.
10. Transforming clinical documentation with ambient AI scribes: a narrative review of technology, impact, and implementation, PMC (2025–2026). The ASR + diarization + summarization pipeline and reported time-savings. https://pmc.ncbi.nlm.nih.gov/articles/PMC12973079/ — tier 5.
11. Texas Medical Liability Trust, Using AI Medical Scribes: Risk Management Considerations (2026). Practitioner guidance on the clinician's review-and-attestation duty and the reasonable-review-window idea. https://www.tmlt.org/resource/using-ai-medical-scribes-risk-management-considerations — tier 5.
12. Fierce Healthcare, How Epic's latest EHR features could shift the AI scribe market (2026). Market orientation on Epic AI Charting (Feb 2026) and the Epic ambient-vendor toolbox. https://www.fiercehealthcare.com/ai-and-machine-learning/how-epics-ai-moves-could-shake-health-tech-market — tier 6, orientation only.
13. Changes in Clinician Time Expenditure and Visit Quantity With Adoption of Artificial Intelligence–Powered Scribes: A Multisite Study, JAMA (April 1, 2026; doi 10.1001/jama.2026.2253). 8,581 ambulatory clinicians at five academic health systems; 16 fewer documentation minutes and 13.4 fewer EHR minutes per 8 hours of scheduled care. https://jamanetwork.com/journals/jama/article-abstract/2847319 — tier 5.
14. Lukac PJ, Mafi JN et al., A Pragmatic Randomized Controlled Trial of Ambient Artificial Intelligence to Improve Health Practitioner Well-Being, NEJM AI (online November 26, 2025). 238 UCLA physicians randomized to DAX, Nabla or usual care; Nabla −9.5% time-in-note. https://ai.nejm.org/doi/abs/10.1056/AIoa2500945 — tier 5.
15. STAT, Epic launches AI Charting, potentially scrambling the ambient scribe market (February 4, 2026), and Fierce Healthcare, Epic rolls out AI Charting (February 5, 2026). https://www.statnews.com/2026/02/04/epic-ai-charting-ambient-scribe-abridge-microsoft/; https://www.fiercehealthcare.com/ai-and-machine-learning/epic-rolls-out-ai-charting-and-more-built-automation-clinicians-and — tier 6, orientation only.
16. Texas HB 149, Texas Responsible Artificial Intelligence Governance Act (89th Legislature; patient AI-disclosure duty effective January 1, 2026); Texas SB 1188 (2025; practitioner review of AI-generated records, effective September 1, 2025); and Texas Medical Liability Trust, Texas physicians must disclose use of AI under new state rules (2026). https://capitol.texas.gov/tlodocs/89R/billtext/html/HB00149F.htm; https://www.tmlt.org/resource/texas-physicians-must-disclose-use-of-ai-under-new-state-rules — tier 1 / tier 5.
17. Tech Times, Suki Raises $90M to Automate Referrals and Prior Auths, Not Just Clinical Notes (October 14, 2026). https://www.techtimes.com/articles/328988/20261014/suki-raises-90m-automate-referrals-prior-auths-not-just-clinical-notes.htm — tier 6, orientation only.

Where sources disagreed, the article follows the controlling rule. Vendor and market pieces (refs 11–12, 15, 17) describe practice; the BAA requirement, the minimum-necessary standard, the audit-control obligation, and the documentation-versus-device line are stated from HHS and FDA primary sources (refs 1–7), which override any looser vendor framing. The FDA CDS guidance is cited at its January 2026 final version. Time-saving figures (refs 13–14) and hallucination-rate figures (refs 9–10) are peer-reviewed observations, not regulatory thresholds, and are presented as the studies reported them.