Most conversations about coding confidence start with a workflow question: how many passes does a chart get before it's submitted? Vendor read, internal coder, second vendor, pre-submission check- usually four- and most leaders have to call someone to confirm the exact number.
The fix is what the model is required to produce, and that's an architecture decision, not a modeling one.
Every additional pass in a chart review pipeline is really an admission: the previous system's output wasn't something a person could verify on its own, so another system had to re-derive it independently. That's expensive in a specific way. Two independent reads of the same chart aren't redundancy; they're two separate probability estimates with no shared evidence, and reconciling them requires a human to build the case a third time, from the original record.
The deadline pressure makes this worse than it looks on paper. The service period for the 2027 initial run closed in June, and the submission deadline is September 4. A sequential pipeline means pass two can't start until pass one closes out, so latency compounds. A chart that's clinically fine can still miss the run and wait until March, not because the diagnosis was wrong, but because the pipeline was slow.
The Real Constraint: Recall and Precision Aren't the Same Failure
This is the part that gets flattened in most vendor conversations. A model tuned for recall (finding every plausible diagnosis) and a model tuned for precision (only surfacing what's actually supported) fail in opposite directions, and in risk adjustment, both failure modes are expensive. Miss a supported diagnosis, and you've undercaptured. Surface an unsupported one, and you've created audit exposure.
We handle that by separating the two jobs instead of asking one model to do both. A language layer reads the unstructured note and proposes candidates, optimized for recall, so nothing plausible gets skipped. A separate deterministic layer, built on a structured clinical knowledge graph, checks each candidate against actual coding rules and clinical criteria before it's allowed to reach a coder, optimized for precision. Neither layer alone is sufficient: a recall-only system produces a longer list of guesses, and a precision-only system, applied to unstructured text, misses most of what's actually written. The output a reviewer sees has already passed both filters. That's a different guarantee than "the model was 92% accurate on a validation set," and it's the guarantee that actually matters when someone has to defend the code later.
What has to be true downstream of that architecture: evidence attached at the point of output, not retrievable after the fact. The diagnosis linked to the specific encounter it came from, not inferred later. And the ability to remove a code, not just add one, since a system that can only propose diagnoses has no mechanism to flag one that no longer holds up.
Human review changes shape under this architecture too. A reviewer answering "does this hold up" against an artifact is doing bounded verification. A reviewer reconstructing a finding from a raw note is doing the original analysis over again, at close to the original cost. Same person, same chart, different economics, and the difference isn't effort; it's what the system handed her to start from.
If you're evaluating a vendor on this, the workflow questions still matter (what does a reviewer see on first open, can the system remove a code, what does a second vendor actually catch that the first one didn't), but ask one architecture question too: is recall and precision being optimized by the same model, or by two systems checking each other? The answer tells you more than any accuracy number will.
