LLMs in clinical documentation and coding: separating real capability from demo-ware

Every payer, provider, and healthcare investor we work with has now sat through some version of the same demo: a clinical note goes in, and a tidy set of ICD-10-CM and CPT codes comes out, sometimes with a confidence score and a highlighted rationale. It is genuinely impressive to watch. It is also, in most cases, the least informative thing you will ever learn about the product. The demo answers the question “can a language model produce plausible codes from clean text?” The question that determines whether the product survives contact with a production revenue cycle is different: how often is it exactly right, on messy real-world documentation, at the level of specificity a claim requires, at a cost of error the organization can tolerate?

The distance between those two questions is where demo-ware lives. And in clinical documentation and coding, that distance is unusually measurable, because the academic literature has spent the last two years quantifying it.

What the numbers actually say

Start with the hardest version of the task: fully autonomous code assignment. When GPT-4 was evaluated on assigning ICD-10-CM codes from diagnosis descriptions, it achieved roughly 34% exact-match accuracy. Not 34% of notes with some usable output, but 34% of codes matching the correct code exactly. ICD-10-CM is a vocabulary of about 74,000 codes where laterality, encounter type, and seventh-character extensions all matter for payment and audit. “Close” is not a billing status.

Now compare a structurally different task: validating codes that human coders have already assigned. A 2025 study that ran an LLM-based system across more than 13,000 ICD-10-CM codes from real inpatient records found the system validated codes with roughly 94% accuracy and 95% sensitivity. Same underlying model class, radically different result, because verification against a specific code and a specific note is a constrained problem, while open-ended assignment across the entire vocabulary is not.

The same study surfaced a third number that should reframe how buyers think about this entire category: the human-assigned codes being validated had an overall positive predictive value of about 85%, roughly 94% for principal diagnoses but only about 84% for secondary diagnoses. In other words, the “gold standard” the industry benchmarks against is itself wrong more than one time in seven.

Three implications fall out of Exhibit 1. First, task framing dominates model choice: the gap between 34% and 94% is not a bigger model, it is a smaller problem. Second, any vendor quoting a single “accuracy” number without specifying exact-match versus partial-match, code-set breadth, and note type is quoting a marketing number. Third, and this is the one buyers consistently miss, because human coding itself runs at roughly 85% PPV on secondary diagnoses, a model can disagree with the gold standard and be right. That cuts both ways: it makes naive benchmarks unreliable, and it makes audit one of the highest-value near-term applications, because there is a real, quantifiable error pool to find.

Why demos flatter and production punishes

Demo conditions differ from production conditions in ways that all point the same direction. Demo notes are legible, complete, and usually chosen because they code cleanly; production documentation is fragmented across encounter notes, contains copy-forward artifacts, and frequently omits the detail that determines code specificity. Demos are scored by impression; production is scored by denial rates, DRG shifts, RADV exposure, and coder minutes. Demos show the modal case; revenue and compliance risk live in the tail: the rare codes, the combination rules, the payer-specific edits that a foundation model has seen a handful of times, if at all.

The gap between 34% and 94% is not a bigger model. It is a smaller problem.

Documentation drafting, the ambient scribe category, sits in a different spot on this landscape, and it’s worth being precise about why. Ambient tools have achieved real clinical adoption faster than almost any technology in recent memory, but their success is architectural: a clinician reviews and signs every note. The product is designed so the model never needs to be exactly right, only useful. That is not a criticism; it is the design pattern that separates deployable LLM products from demo-ware across this entire category. The failure mode we see in diligence is vendors borrowing the credibility of ambient documentation’s adoption curve to sell autonomous coding, a task with a fundamentally different error tolerance and no clinician sign-off backstop.

A map for buyers and diligence teams

We evaluate documentation and coding AI on two axes: how much autonomy the workflow actually grants the model, and how verifiable its output is at the point of use. Products in the review-backed, easily-verified region are deployable today and their ROI can be measured in coder minutes and denial deltas. Products claiming high autonomy on hard-to-verify output are, with rare exceptions, demos wearing production clothing.

Note what the upper-left quadrant has in common: in every deployable use case, the model’s output is a draft or a flag, and the economic claim is measurable, whether notes per clinician-hour, codes audited per coder-day, or secondary-diagnosis error yield. In the lower-right, the output is a claim submitted to a payer, the error surfaces weeks later as a denial or years later as an audit finding, and the vendor’s accuracy statistic was computed against a gold standard we now know is about 85% clean.

Five questions that collapse the demo

1. “What is your exact-match rate, and on what code-set breadth?” Accept nothing scored on partial matches, category-level matches, or a curated top-50 code list unless your case mix is genuinely that narrow.
2. “Show me performance on our documentation, stratified by note type.” A vendor confident in production performance will run a blinded retrospective on your notes. One who won’t is telling you where the product really is.
3. “How was your ground truth adjudicated?” If the benchmark is unaudited historical coding, the reported accuracy inherits that roughly 15% error rate, in an unknown direction.
4. “What happens to the 6 to 66% the model gets wrong?” Map the human-review workflow, its staffing cost, and its rubber-stamp rate. Autonomy that quietly depends on review isn’t autonomy; it’s coder-assist with worse ergonomics.
5. “What moved in production: denials, DRG mix, coder minutes, query rates?” Demand pre/post operational metrics from a reference client, not accuracy in a lab.

Where this lands

None of this is a case for sitting out the category. The validation result, a model auditing thirteen thousand real codes at roughly 94% accuracy against a human baseline of 85%, is one of the most commercially interesting numbers in healthcare AI right now, because it points at recoverable revenue and reducible audit risk that exists today, in claims already flowing. Coder-assist tools with honest top-5 suggestion designs measurably compress coding time. Ambient documentation has already changed clinical workflows at scale by respecting, rather than fighting, the need for human sign-off.

The discipline is in matching the tool to the task’s error tolerance. Autonomous coding will get there for progressively larger slices of the case mix, starting with high-volume, low-ambiguity encounter types and expanding as models earn trust through audited production performance. Buyers who insist on that evidence trail will capture the value. Buyers who purchase the demo will discover the gap between 34% and the pitch deck one denial at a time.

Gript Technologies advises payers, operators, and investors on claims analytics, clinical informatics, and healthcare AI. We run vendor diligence, retrospective performance studies on client documentation, and claims-based validation of AI ROI claims. If you’re evaluating a documentation or coding AI vendor, we can run the five questions above against real data, yours, not theirs.