EHR usability and AI scribes: designing the clinician's review step

An AI scribe does not remove documentation work. It changes the work from writing a note to checking one, and people check badly when the draft looks finished. The review step should therefore do five things: show the clinician what matters first, show where each statement came from, mark what the model was unsure of, make a correction take seconds, and never let a signature claim a check that did not happen. The rest of this page explains why, and how to build each part.

Why EHR usability still matters

EHR usability is how well the record supports the clinician's real work: finding information, entering it and acting safely on it. The burden is measured, not anecdotal. A time-motion study of 57 physicians in four specialties found that during the office day they spent 49.2% of their time on EHR and desk work and 27.0% on direct clinical face time (Sinsky et al., Annals of Internal Medicine, 2016). An event-log study of primary care physicians put EHR time at about 5.9 hours of an 11.4-hour workday, 1.4 of those hours after clinic, with clerical and administrative tasks making up 44.2% of it (Arndt et al., Annals of Family Medicine, 2017).

Ambient AI scribes are the most direct attempt to lift that load. Early evidence is promising and uneven. At one large group, 3,442 physicians used a scribe in as many as 303,266 encounters in the first ten weeks, and the authors link use to less documentation and EHR time (Tierney et al., NEJM Catalyst, 2024). In a survey study of pilots at two academic centres, the share of clinicians meeting burnout criteria at one site fell from 52.6% to 30.7% at 84 days, though the design was uncontrolled and response rates were low, so the findings may reflect enthusiastic users (You et al., JAMA Network Open, 2025).

The same literature names the weak point. A scoping review of 14 studies on usability barriers to AI scribes found frequent errors, overly long notes, limited formatting options and weak EHR integration, and found that time savings can disappear when clinicians must make substantial corrections (Atiku et al., Journal of Evaluation in Clinical Practice, 2026). Usability here means the review.

From typing to verifying

When a clinician writes a note, every sentence passes through their attention on the way out. When a scribe drafts it, nothing does unless the interface forces it. The risk has a name, automation bias: the tendency to over-rely on automation. A systematic review of 74 studies by Goddard, Roudsari and Wyatt (JAMIA, 2012) found that workload and time pressure make it worse, and that the mitigators include stressing user accountability and several display choices: where advice sits on screen, showing updated confidence levels, and giving information rather than a direct recommendation. That is a design brief for the review step.

The notes are not reliably clean. One comparison of 97 outpatient encounters found hallucinations in 31% of ambient notes against 20% of physician-written ones, and the ambient notes were less succinct. It is a single study, and the authors' disclosure ties all of them to the vendor whose product was evaluated, so read it as a signal about review effort, not a benchmark (Palm et al., Frontiers in Artificial Intelligence, 2025).

There is also a trust problem outside the room. A thematic analysis of 484 clinician comments on public forums, whose authors say their aim was not statistical representativeness, argues that the idea that a signature plus patient access to the note guarantees accountability is a "fragile fiction". Clinicians described proofreading as hard to sustain under productivity pressure, and noted that notes can read as generic or verbose to the two audiences that now read them: colleagues and patients (Atiku and Olakotan, Journal of Evaluation in Clinical Practice, 2026).

The anatomy of a review step

Think of the step as six stages. What follows is design judgement drawn from the research above, not a finding from any one study.

1. Draft. Lead with what a clinician would act on: the assessment, plan, medication changes and orders, not the history in encounter order. Keep the note short. Length is a cost the reviewer pays, and the scoping review lists overly long notes as a barrier.
2. Provenance. Link each statement to the part of the conversation it came from, with the audio or transcript span one tap away. A clinician who can verify a sentence in seconds will verify more of them. Mark statements the model inferred rather than heard, because those are the ones with no span to check.
3. Uncertainty. Mark what the model was unsure of, and mark it where the reader's eye is, inline, rather than in a score at the top. Goddard and colleagues list confidence information among the mitigators, but a number nobody acts on does not help; we cover that in why confidence scores do not fix trust when the review step never changes. Reserve the marking for the high-consequence fields (doses, laterality, negations, allergies) so that it keeps its meaning.
4. Edit. Make a correction cheaper than ignoring the error. Edit in place, accept or reject by statement, and support voice and keyboard. Show what changed against the draft so the clinician sees their own corrections accumulate.
5. Attest. A signature should reflect a review that happened. Gate sign-off on the high-consequence items being seen or resolved, not on scrolling. Do not add a confirmation dialogue that people click through; it teaches them to sign without reading.
6. Record. Keep the machine draft, the clinician's edits, the attestation and the source spans together, so an auditor can reconstruct what the model proposed and what the human changed. Decide early what the legal record is and what is working material, and let the client's clinical, legal and regulatory owners make that call.

The patient is a second reader. With patient access to notes (OpenNotes), a draft that reads fine to a clinician may mislead a patient. Plan for how an uncertain or sensitive statement appears in the patient view, and for how a patient can flag an error.

This is the general review, approve and override pattern from human-in-the-loop UX patterns, applied to one clinical workflow. We apply the same discipline in our human-in-the-loop workflow design. For the wider regulatory view of clinical software design, see healthcare UX design for clinicians, patients and regulators.

Failure modes and design counters

The specialty row has support: the scoping review found usability ratings more favourable for routine or protocol-driven visits, and the pilot survey study recorded concerns about fit for visit types such as psychiatry and paediatric physical exams.

What to test with clinicians before release

• Seeded errors. Plant known errors (a wrong dose, a flipped negation, a missed allergy) in realistic drafts and measure how many reviewers catch them, with and without your uncertainty and provenance marks.
• Time to correct. Time a typical edit from noticing the error to finishing the fix.
• Signature behaviour. Compare time on note and number of interactions with the draft before signing, across busy and quiet sessions.
• Provenance use. Check whether clinicians open the source span, and whether they trust it when they do.
• Flag response. Count how often uncertainty marks are acted on, and whether they are ignored by day three.
• The second reader. Show the patient view to patients and ask what they would query.
• Hard visits. Include complex, multi-problem and psychiatric encounters, not only routine ones.

We would run these with the clinicians' real specialties and real EHR, since a prototype tested in isolation misses the integration problems the scoping review reports.

Standards, and what we could not confirm

In the United States, ONC's certification criterion on safety-enhanced design, 45 CFR 170.315(g)(3), requires user-centred design and summative usability testing for named capabilities, with at least ten participants per capability, with a report that must contain the NISTIR 7742 information. NIST's NISTIR 7804 (Lowry et al., 2012) is a technical evaluation and validation protocol for EHR usability, which ONC recommends rather than requires. The criterion's future is unsettled: ONC's HTI-5 proposal lists it for removal, and ONC has since announced a final HTI-5 rule. We could not confirm from the rule text what the final version does with this criterion, so check it before you rely on either position. Whatever the rule says, the evidence above is the better reason to test the review step with clinicians.

A related note from another sector: in construction we designed an expert review of AI output, covered in the BuildTwin case study. It is not health work, and we make no healthcare claim from it. It shows the same idea, that the person checking the AI needs to see the evidence behind each output. For how we approach clinical products, see our healthcare product design work.

The studies here are early, mostly single-system and frequently self-reported. The decisions on clinical content, legal status of the record and regulation belong to your clinical, legal and regulatory owners, not to a design page.

Talk to us about your review step

If your team is building or fixing how clinicians review AI-drafted notes, we are happy to talk through the design with you.