For mental health providers, the work continues after the session ends. Documentation can add 30+ minutes per visit, spilling into evenings and weekends. So we built Scribe, optional AI documentation tools inside Headway’s EHR, so providers can stay fully present with patients instead of administrative work.
One of the ways providers can use Scribe is generating a draft progress note from a session transcript. Shipping that meant answering a harder question first: how do we make it produce a reliably good note, every time? The answer is nuanced, as a single therapy session can be written up several valid ways, and the distance between an accurate summary and an unsupported clinical assumption can come down to a single clause.
Our eval system exists to turn that judgment into something we can measure; Sentence-level checks, statistical gates, precision and recall on the grader itself, and a clinical team that wrote the rubric and makes the calls no automated check can.
In practice, we treat note quality the way we treat code. Scribe writes the first draft. An automated reviewer reads every sentence and fails any that break a rule, the way CI fails a build. Human reviewers confirm or overturn those calls, and the corrections feed back into the writer and the checker, so every release is stricter than the last.
We invest this much in measurement because a clinical note lives on the patient chart for years and shapes care long after the session ends. Getting it right on average isn’t acceptable. We needed a way to check every sentence of every note, and a way to know when that check itself was wrong.
Defining note quality before grading anything
Grading a note is more like reviewing a pull request than running a unit test. A unit test has one right answer. Code review is full of judgment calls, where two good engineers read the same diff and reach different conclusions. AI documentation is the judgment-call kind.
To narrow that ambiguity, we built a 14-category documentation risk rubric with our Clinical team. It sorts every generated sentence into one of two buckets: a permissible transformation, or an impermissible violation.
A rubric is only useful if you decide what “good enough” looks like before you start grading. We set a tolerance for each severity tier ahead of time, scaled to how directly and seriously an error threatens clinical accuracy:
- Tier 1, high severity: the tightest tolerance, for errors that put affirmatively wrong or invented clinical content into the note
- Tier 2, moderate or low severity: a looser tolerance for errors of interpretation, completeness, or tone
We also set how many reviewed notes we’d need before believing a passing rate was real and not noise.
How we evaluate the note
The check does three things for every AI-generated sentence: extracts the sentence, aligns it against the source material (the transcript, appointment context, the previous note, and the submitted note), and classifies it against the rubric.
Based on how many High, Moderate, and Low violations appear in each note, we mark the final note PASSED or FAILED:
- At least 1 High or Moderate violation → the note fails
- At least 3 Low violations → the note fails
A high-severity flag catches a sentence that states a clinical detail the transcript doesn’t support. A moderate flag catches smaller leaps past what the transcript actually says. A low flag catches product quality problems that don’t touch care but still make the note worse to work with.
Why we keep a human in the loop (HITL)
Even with an LLM-as-judge, we continuously route a subset of evaluations to human reviewers, for two reasons: the judge is non-deterministic, and the rubric is always evolving as we gather more AI-generated datapoints. Human review lets us catch any details the LLM-as-a-judge may have misinterpreted. Importantly, that subset isn’t only the judge’s failures—it combines three streams:
- a random sample of all traces,
- every provider-flagged note (where the provider rated the draft dissatisfied), and
- every note the LLM evaluation failed
The random sample matters most for trust: reviewing notes the judge passed is the only way to catch the calls it missed.
On each reviewed note, auditors record two things:
- Whether the LLM-as-judge flagged failures correctly (its precision)
- Whether the LLM-as-judge missed failures it should have caught (its recall)
How a team of licensed clinicians and trained auditors make the writer and the check better
Human review does more than catch a bad note at the moment. Every disagreement our team of auditors log feeds our prompt iteration flywheel, which is a loop that turns reviewed traces into measurable improvements to two prompts. The check (our LLM-as-judge) grades the writer (our generation prompt), and the human-corrected labels (HITL) grades the check. This flywheel, and the AI-driven prompt research inside it, is where our process goes beyond a standard LLM-as-judge setup.
Here’s the loop:
- Collect traces: Every evaluation trace (transcript, appointment context, prior note, generated note, submitted note, and the judge’s verdict) is routed to a tracing project, with the problematic ones queued for review.
- Subject-matter experts review failures: Our clinical team verifies the failures and adds the rationale the model missed, both for generation failures (why a sentence really is a violation) and evaluation failures (why the judge called it wrong).
- Build a training dataset: Those reviewed traces become a labeled dataset where each sentence carries both the judge’s call and the human’s call, side by side.
- Improve the check: We baseline the current judge against the human labels using precision and recall. An AI research loop then studies the disagreements, proposes candidate updates to the evaluation prompt, and tests each one against the labeled dataset.
- Improve the writer: With the sharper judge in place, we baseline the generation prompt, then use the same AI-driven research process – with the human-annotated violations as context – to draft and test candidate updates. We promote the one that drives the failure rate down, again with HITL review.
- Release and repeat: The updated prompts ship, and the loop restarts once enough new feedback has accumulated to act on.
Increasingly, this runs hands-off. We use AI to do the prompt research itself: labeled human feedback flows into an automated process that analyzes failure patterns, proposes prompt updates, runs experiments against our gating metrics, and keeps iterating until it either hits the target or exhausts the iteration’s goal — with humans reviewing before anything ships. Most eval writeups stop at “LLM grades, human audits.” Closing the loop with AI that improves both prompts is what lets a small team hold a strict quality bar at scale.
Real work, real stakes
Documentation is a major driver of provider burnout in mental health care. Every hour we return to a provider is an hour they can spend with a patient. We built Scribe for that reason, and the eval system is what lets us put it in front of providers with confidence. We’ve since run the same process on every AI note product we build, and each one gets through it faster than the last.
This is how we approach building everything at Headway. We clear the administrative path so providers and patients can spend their attention on care.
We’re hiring engineers who want their work measured, want to be surrounded by people operating at that level, and want the thing they build to matter after they ship it. If that’s the environment you’re looking for, come build with us.
