Putting a large language model into a clinical workflow is mostly not a machine learning problem. It's a problem of deciding what the model is allowed to be wrong about, and building everything else around that decision.
We took LLM-assisted ICD-10 coding and clinical documentation from benchmarking to production over the past year. Here's what the path actually looked like, including the parts that had nothing to do with models.
Start With the Failure, Not the Capability
The first question people ask is "how accurate is it?" The better first question is "what happens when it's wrong?"
For ICD-10 coding, a wrong code is not a cosmetic error. It can mean a denied claim, a resubmission cycle, a delayed payment to a provider, or — at the far end — a compliance problem. The cost of a mistake is asymmetric and lands on someone who isn't in the room.
That framing settled the architecture before we evaluated a single model: the model suggests, a human decides. Not because the model is bad, but because the failure cost is high and the review cost is low. A coder confirming a correct suggestion takes seconds. A wrong code discovered three weeks later takes considerably longer than that.
Getting this decided early was worth more than any model choice. It meant every subsequent argument had a fixed point to refer back to.
Benchmarking Needs Your Data
Public benchmarks were close to useless for us. Not wrong — just measuring something other than our problem.
Real clinical documentation is messy in specific ways: abbreviations that vary by institution, mixed-language notes, dictation artefacts, templated boilerplate wrapped around two sentences of actual content. A model that performs well on clean text may or may not survive that.
So we built an internal evaluation set from real, de-identified documentation, coded by people who code for a living, covering the distribution we actually see — including the unusual cases, deliberately over-represented, because that's where models fail and where errors cost most.
Three things that made the evaluation useful:
Measure at the decision, not the token. Nobody cares about perplexity. We measured whether the suggested code was accepted by a human coder, because that is the actual production question.
Report by segment. Aggregate accuracy hides everything interesting. Accuracy by specialty, by document type, by note length told us where to deploy first — and where not to.
Keep a holdout you never tune against. Obvious, routinely violated under deadline pressure.
Guardrails Are the Product
The model is maybe a quarter of the system. The rest is the machinery that makes its output safe to act on.
- Confidence-aware presentation. A low-confidence suggestion is shown differently from a high-confidence one. Presenting every output with identical visual authority trains people to stop reading.
- Validation against the code set. The model's suggestion is checked against the actual ICD-10 hierarchy. A plausible-looking code that doesn't exist, or doesn't apply in context, never reaches a human.
- Provenance. Every suggestion links to the text that drove it. Coders need to verify, not trust — and a suggestion you can't trace is a suggestion you have to re-derive from scratch, which is slower than no suggestion.
- Full audit trail. What was suggested, what was accepted, what was overridden, by whom, when. This is a regulatory requirement, and it's also your best source of evaluation data.
- Deterministic fallback. When the model is unavailable, slow, or unsure, the workflow degrades to the existing manual path. It never blocks.
That last one is the difference between a feature and a dependency.
GPU Capacity Planning, Honestly
This was the part I underestimated most, and the part with the least useful material written about it.
Serving an LLM is a fundamentally different capacity problem from serving a web application. Requests are long-running and variable, memory is dominated by model weights plus KV cache, and the thing you're actually optimizing is batching efficiency. Utilization graphs that look fine can sit alongside terrible latency.
What I'd tell someone sizing this on Oracle Cloud or anywhere else:
Measure concurrency, not requests per second. Your capacity ceiling is how many sequences you can hold in memory simultaneously, and that depends on context length. Long clinical documents change the arithmetic considerably.
Decide your latency target before you size anything. Interactive coding assistance and overnight batch processing have completely different profiles. We have both, and they should not share a serving path.
Know your peak shape. Clinical workflows are not uniform across the day. Provisioning for peak wastes money; provisioning for mean produces a queue exactly when people are working.
Cost per accepted suggestion is the real metric. Not cost per token, not cost per GPU-hour. A cheaper model that gets rejected more often can easily be more expensive overall, once you count the human time.
What Surprised Me
Adoption was a design problem, not a trust problem. I expected resistance to AI. What we actually got was indifference to a badly placed UI. Coders adopted it where it reduced keystrokes in their existing flow and ignored it where it added a step. The model quality was identical in both places.
The audit trail became the evaluation pipeline. Override data is labelled data, generated continuously by experts, for free. We built the audit log for compliance and it turned out to be the most valuable feedback loop in the system.
The boring parts dominated the timeline. Evaluation infrastructure, guardrails, observability, failure handling, capacity work. Model selection was weeks. Everything else was the year.
Where We Are
In production, human-in-the-loop, with measured acceptance rates and a review path for everything it touches. Coders are faster. Nothing is auto-submitted on the model's word alone, and I don't expect that to change soon — not because the technology can't get there, but because in this domain the cost of being confidently wrong stays higher than the cost of a human glance.
Which is, I think, the actual lesson. The interesting question was never how good the model is. It was how you build a system that's useful when the model is good and safe when it isn't.
