Real-Time Error Detection
and Correction

To protect patient and clinician privacy, in all our blog posts we use representative synthetic examples.

So far in this series we have discussed some of the ways we approach “offline” pre-deployment evaluations and “online” continual monitoring of our GenAI systems. In this post we discuss “in-line” evaluations, which run within the clinical note generation pipeline to directly identify and correct note quality issues.

These detection and correction systems, which we call “Editors”, are an integral part of our quality assurance process: Specialized systems and workflows that revise the original “draft” of AI-generated documentation to correct detected issues before clinicians ever see the system output.

One of our most important Editors detects and corrects confabulations (The Science of Confabulation Elimination: Toward Hallucination-Free AI-Generated Clinical Notes) to ensure that every claim in a draft of clinical documentation is substantiated by the conversation or other clinical context available to the documentation generation system.

In this post, we will describe at a high level how these systems work, and use the example of our confabulation Editor as a case study in how we evaluate and improve our systems based on feedback from real-world deployment. Crucially, our evaluation practices extend to the evaluation of the Editors themselves, in order to ensure that they are validated against expert review.

An Editor is a specialized system designed to detect and correct issues with AI-generated notes before they are shown to the user, with each Editor focused around a different aspect of quality. Alongside the confabulation Editor (described below) other Editors focus on the removal and correction of other unwanted behavior, such as stigmatizing language.

To give an illustrative example, consider a conversation in which a patient initially reports taking one medication (“I’ve been on…Prozac I think”) but later on corrects themselves, to clarify that they are actually on a different medication (“Actually no, not Prozac, it’s Lexapro, sorry”). In this illustrative example, the original draft may anchor on the first statement made by the patient, writing “Patient has been taking Prozac”, while the Editor detects the error and corrects the statement (replacing “Prozac” with “Lexapro” in the draft) to reflect the corrections made mid-conversation. The confabulation Editor is designed to catch issues like these, as well as other subtle accuracy and attribution issues that can arise in real-world use of our system.

The confabulation Editor described above consists of two components: A Detector and a Corrector. Both components require validation, and in this section we focus on how we validate the Detector. In academic research, to validate similar systems it is common to construct datasets by artificially injecting confabulations into examples. This practice ensures that there is something to detect, with a known ground truth. For instance, to validate how well LLM judges perform at detecting inaccuracies in AI-generated clinical summaries, Croxford et al. 2025 use a dataset explicitly constructed to include errors by prompting LLMs to generate clinical summaries with ungrounded assertions.

The challenge is that these datasets may not reflect real-world failure modes—realistic errors are often more subtle than outright hallucinations, such as failures to recognize that a statement has been corrected in the conversation.

These examples represent challenging edge cases for our current Detector, and are therefore useful for benchmarking improvements. We use these internal datasets to validate improvements that we make to our Detector, measuring performance using two metrics: precision and recall. Precision is the fraction of claims flagged by the system that are genuine errors, and Recall is the fraction of all genuine errors that are caught by the system.

We have continually improved upon earlier versions of our confabulation Detector. With our most recent version, we achieved major gains along both metrics, with a 1.6x-2.4x improvement in F1 score (a combination of precision and recall) across internal challenge datasets.

In addition to validating on our internal datasets, we engage with partners who conduct their own independent evaluations of our clinical documentation system. For instance, one major academic medical center conducts regular in-depth expert review of a subsample of our AI-generated notes, looking for potential accuracy issues. These reviews use a variety of references for each encounter, including the AI-drafted note, transcript, audio recording of the conversation, and the edits made by clinicians to the original note. Beyond identifying errors, these references are used to perform root-cause analysis, distinguishing between e.g., errors that are attributable to failures in transcription versus errors that are attributable to the downstream note generation system.

These partner evaluations allow us to validate improvements in our core systems. In this case, for instance, we curated a challenge dataset consisting of notes where this partner’s expert review identified accuracy issues. On this dataset, we found that our updated Detector would have caught over 50% of the issues that the earlier version failed to detect.

Robust automated evaluations can be used to directly improve the output of AI systems, by integrating into similar detect-and-correct workflows like the one described above. However, measuring the quality of these workflows requires careful curation of validation datasets that reflect real-world failure modes and expert judgement.