médical IA

When a clinical LLM fills in the wrong boxes: measuring, then repairing schema compliance for ICD-10, CPT and FHIR

Published on August 2, 2026 · 9 min read

Jianru Shen (University of Montana) tests three open-source large language models — Qwen2.5 7B, Llama 3.1 8B and Gemma2 9B — on 320 clinical scenarios across ten specialties, asking each to produce structured outputs that conform to the healthcare data standards ICD-10, CPT and HL7 FHIR. Without a safeguard, format compliance plateaus between 85.9% and 91.6% depending on the model; an automated validate-then-repair loop lifts it to 99.0% within two iterations, with about 1% of cases escalated to a human. But what the paper measures is structural compliance, not clinical accuracy: a perfectly well-formed code can still be medically wrong, and that is precisely the gap this work leaves open.

The context

A large language model (LLM: a neural network trained to predict text) can produce fluent clinical prose. The problem is that a hospital does not run on prose. A diagnosis must become an ICD-10 code (the International Classification of Diseases, tenth revision), a procedure must become a CPT code (the US procedure terminology that drives billing), and the whole thing must move between software systems in HL7 FHIR format (Fast Healthcare Interoperability Resources, the modern standard for exchanging health data). These formats are "schemas": strict templates that fix which fields exist, what type they are, and how they nest.

If a model's output violates the schema — a missing field, a mistyped code, invalid JSON structure — the electronic health record rejects it. This is the practical bottleneck blocking LLM integration in the clinic: a model can "reason" correctly and still produce an object that downstream systems cannot use. Prior approaches exist (constrained decoding, function calling, forced JSON templates), but they are often tied to a specific model vendor. The paper asks a systemic question: is the compliance gap specific to one model, or shared across a whole generation of LLMs? And can a generic correction layer close it?

The method

The core is a "closed" (cybernetic) validation-repair loop. The model first generates a structured output. A validator checks it against the target schema (ICD-10, CPT or FHIR): a deterministic, non-AI check that answers yes or no and points to the exact error. If the output is invalid, the error is fed back to the model with a correction instruction; it regenerates; the output is revalidated. This repeats until the output passes or an iteration limit is reached. A final safety net escalates to a human the cases the loop cannot fix.

The evaluation is paired: each scenario is run twice, once in a baseline condition (the model answers with no loop) and once with the validation-repair loop, which isolates the net contribution of the mechanism. The protocol comprises 320 clinical scenarios spanning ten medical specialties, giving 960 model-scenario pairs once crossed with the three models. All three LLMs are deployed locally — a choice that matters in healthcare, since it avoids sending data to a third-party cloud service. The metrics are simple and legible: the schema compliance rate (share of outputs the validator accepts), the number of iterations needed to converge, and the share of cases routed to human oversight. The paper adds a taxonomy of the errors encountered.

The results

At baseline, format compliance sits between 85.9% and 91.6% depending on the model. The most telling fact is not the level but the closeness of the three models: they fall within 5.7 percentage points of one another despite different architectures and training corpora. In other words, the compliance gap is not a quirk of one model — it is shared, which points to a common gap in how these LLMs learned healthcare formats. With the validation-repair loop, overall compliance rises to 99.0%, converging in practice within two iterations, with about 1% of cases sent to human review. The error analysis shows failures are predominantly "representation-level" violations — formatting problems (missing field, wrong type, malformed structure) rather than deep misunderstandings. That is consistent with a targeted repair, guided by the validator's message, being enough to fix them.

Translating into concrete terms helps. Out of 1,000 structured outputs, the baseline would leave roughly 85 to 140 non-compliant — objects an electronic health record would reject or ingest incorrectly. After the loop, about 10 would remain, escalated to a human. The operational gain is real: you move from a failure rate that forbids automation to a residue manageable by oversight. But this count says nothing about a different question the paper stays silent on: among the 990 now-"compliant" outputs, how many carry the right code?

What is good

A paired evaluation across three model families. Running Qwen, Llama and Gemma through the same protocol, at baseline and with repair, isolates the mechanism's effect and shows the compliance gap is systemic (under 5.7 points between vendors). That is stronger than a single-model demonstration.

A simple, deterministic, vendor-independent repair layer. Validation rests on the schema, not on an AI judgment: it is reproducible and verifiable. The loop converges in two iterations and works regardless of the underlying model, making it a deployable building block without vendor lock-in.

An error taxonomy that explains the result. Showing that failures are mostly format violations, not meaning errors, clarifies why validator-guided repair suffices. That is a useful contribution for anyone designing targeted safeguards rather than costly retraining.

What is less good

The metric misleads if read too fast. "Schema compliance" means syntactic correctness: the output has the right shape. It says nothing about clinical correctness: a well-formed ICD-10 code that names the wrong disease passes validation 100% of the time. The validator checks the template, not the medical truth. The headline 99.0% therefore measures form, and the paper does not measure — and does not claim to measure — how many codes are clinically right. This is the classic misleading-metric failure mode.

Constructed scenarios, no real records or live deployment. The 320 scenarios are a test bench, not patient records from a hospital, and there is no external multi-center validation nor integration tested in a real electronic health record. Generalization to the variety and noise of real data remains to be shown.

The 1% residue and the risk of over-trust. At the scale of a hospital system producing millions of documents, 1% is a considerable volume of cases to review. Above all, a "repaired" output is well-formed and therefore reassuring: it invites blind automation (automation bias) even though the repair does not touch the substance. Add that the tested models are small (7 to 9 billion parameters), the work is single-authored and published as a conference preprint (IEEE SMC 2026): all reasons to treat these figures as a starting point, not a verdict.

What it changes

For the research community, the paper offers a reproducible framework and a taxonomy for measuring the structural reliability of clinical LLMs — an angle distinct from medical-reasoning benchmarks. Above all it flags the next task: coupling format compliance with an evaluation of coding semantic accuracy, the only thing that truly matters for safety.

For clinicians and integration teams, the message is twofold. Yes, a validation-repair layer can make LLM insertion into an electronic health record more reliable without depending on a single vendor. No, "integrable" does not mean "correct": human review remains indispensable on substance, and the tidiness of the format must not lower one's guard.

For patients and the public, the stakes are invisible but concrete. ICD-10 and CPT codes feed the medical record, reimbursements and billing. A system that fixes the form of a code without guaranteeing its accuracy can produce perfectly compliant yet wrong documents — with consequences for the care pathway or out-of-pocket costs. Format reliability is necessary; it is not sufficient.