Medical Coding & Claims Agents

The label arrives on its own, and it is not the label you want.

The claim lifecycle hands you a supervision signal for free. An 837 goes out, a 999 acknowledges the interchange syntactically, a 277CA accepts or rejects at claim level, and eventually an 835 remittance returns with the money and, where money was withheld, a Claim Adjustment Reason Code and usually a Remittance Advice Remark Code. HIPAA still mandates version 005010 for these transactions, so the format has been stable for over a decade and the parsing is a solved problem.

What you must not do is mistake that signal for correctness. The 835 tells you what a payer decided to pay under its own adjudication rules. It does not tell you what the documentation supported. The two diverge in both directions:

• A paid claim can be wrong. Payers do not audit every line at adjudication; upcoding frequently pays first and is recovered later, with interest and penalties attached.
• A denied claim can be right. Roughly 70% of denials that providers appeal are overturned and paid, on Premier's data — a majority verdict against the payer's first answer.
• Undercoding is invisible to it entirely. There is no transaction in the standard that says "you could have billed more". The signal is silent in exactly the direction your optimiser will drift.

Make the objective two-sided, or the agent will undercode its way to a clean scorecard.

A single-sided objective — minimise denials, maximise first-pass rate — is degenerate. The safest code is always the least specific one, the lowest-level evaluation and management code, the one with no modifier. It gets paid, it never gets appealed, and it costs the organisation money on every encounter forever. Nothing in the feedback loop will surface it.

The fix is a scorecard with two opposing terms, both measured on the same matured cohort:

• Denial and rework rate — the side the payer supervises. Compare against the organisation's own historical baseline, not an industry figure; the denominators differ too much between specialties to make external comparison meaningful.
• Coded-level distribution against an audited baseline — the side nobody supervises. Take a random sample of the agent's encounters, have certified coders code them blind, and compare the distributions. A drift toward lower-specificity codes is the failure this catches, and it is the only thing that catches it.

Distribution drift is also how the regulator finds you, from the other direction. CMS flags outliers on high-level codes, and an agent that drifts up lands you where UCHealth did — see step 4. Track the distribution, not just the mean, and alarm on movement in either direction.

CO-16 is a pointer, not a reason — and your denial taxonomy lives or dies on that.

The largest denial bucket in most books is CARC 16: "Claim/service lacks information or has submission/billing error(s) which is needed for adjudication." Read literally, it is almost content-free. That is by design — X12 requires at least one RARC to accompany it, and the RARC carries the actual diagnostic detail. An agent that routes on the CARC alone collapses its biggest, most-addressable bucket into one undifferentiated class and learns nothing from it.

Build the taxonomy on the CARC/RARC pair, and separate the codes that are genuinely different problems:

• CARC 16 + RARC — a data or documentation defect. Routable, usually fixable by the agent, and the RARC says how.
• CARC 197 — "Precertification/authorization/notification/pre-treatment absent." This is not a coding failure at all; it is a workflow failure upstream of coding, and feeding it back into the coding model is training on someone else's mistake.
• CARC 50 — services not deemed a medical necessity by the payer. A documentation and clinical-support problem, appealable, and the one most worth a human.
• CARC 97 — bundled into another already-adjudicated service. A genuine coding-logic signal, and the one that should reach the model.
• Group codes matter too. CO is a contractual obligation the provider writes off; PR is patient responsibility. A contractual write-off is not a defect and should never enter the agent's error signal.

This is about to get better rather than worse. HHS finalised the first HIPAA claims-attachment standards in March 2026, adopting X12N 275 and 277 transactions with a compliance date roughly two years out — which turns "send documentation" from a fax into a structured, machine-addressable exchange. Design the documentation path as a transaction now, because it is becoming one.

The liability is per claim and multiplicative, which inverts the usual risk model.

Most agent deployments worry about an occasional bad output. Here the shape is reversed: a systematic coding error is replicated across every encounter that matches it, and False Claims Act exposure is assessed per claim — treble damages plus a civil penalty currently running from $14,308 to $28,618 per claim, unchanged for 2026 because the inflation adjustment could not be computed. A rule that is wrong on a common encounter type does not cost you one claim's value. It multiplies.

The precedent worth reading is UCHealth: the Department of Justice intervened in 2024 and the matter settled for $23 million over automated coding rules that departed from the relevant coding standards and inflated emergency-department evaluation-and-management levels. No model was involved and no intent was alleged — deterministic automation, applied consistently, produced the exposure. FCA scienter reaches reckless disregard, which is precisely where an unaudited autonomous pipeline sits.

Three design consequences follow, and none of them is a model change:

• Version and freeze the logic. You must be able to say which rule set and which model version produced a given claim, months later. This is audit trails as a hard requirement, not a nice-to-have.
• Make the reviewed/unreviewed distinction a stored fact. Not an inference from timestamps. The question you will be asked is what review actually happened on this claim.
• Alarm on population shifts, not per-claim scores. The harm is a distribution moving. Per-claim confidence will not show it; step 2's distribution comparison will.

Whether you may run autonomously is now a routing question, not an architecture one.

No federal rule appears to require a human to review an AI-generated code before submission — but the certification attached to every claim makes the submitting entity responsible for it regardless of what produced it, so "the vendor's model did it" is not a defence. State law is now filling the gap, and it is doing so unevenly, which is the operationally important part.

Indiana's HB 1271, effective 1 July 2026, is as far as we can tell the first US law to restrict provider-side automation directly: it prohibits providers from using AI to submit a health benefits claim without review by the provider or another person involved in developing the claim. Its payer-side half bars insurers from using AI as the sole basis to downcode on medical necessity without a human first reviewing the record. Most of the other state activity — California's SB 1120, Maryland, Utah, and others — regulates the payer side, but the direction is consistent, and OIG's February 2026 Medicare Advantage compliance guidance explicitly names AI-generated EMR prompts that add risk-adjusting diagnoses as a compliance risk.

So the autonomy decision belongs in the routing table, keyed on facts you already have:

• Jurisdiction of the rendering provider — because a claim submitted in Indiana carries a review obligation a claim submitted elsewhere does not.
• Payer and line of business — Medicare Advantage risk adjustment now carries named regulatory attention that commercial fee-for-service does not.
• Code family — evaluation-and-management levels and risk-adjusting diagnoses are the two families where errors are both systematic and enforced against. Route them to review even where the law does not force you to.

Build this as configuration with an effective date, not as a condition in code. The rules change on legislative calendars, and you will be editing it several times a year.

Retrieve the code, do not recall it — and re-validate every October.

Asking a model to emit a code from its weights is the architecture that does not work, and there is a clean measurement of it: the NEJM AI benchmark published in 2024 tested frontier models against tens of thousands of real ICD-10-CM and procedure codes and found the best performer reaching 33.9% exact match, with every model under 50%. The models have improved since; the structural problem has not. Code sets are large, hierarchical, updated on a fixed calendar, and full of near-identical siblings distinguished by a laterality or an encounter type — which is a retrieval and verification problem wearing a generation problem's clothes.

• Ground every code in the current code set as data. Retrieve candidates, then have the model justify the selection against the documentation, and validate the emitted code exists and is billable in the active set before it reaches the claim. This is grounding applied to a closed vocabulary, and a deleted code caught at validation is a denial you never had.
• Treat the annual updates as scheduled model drift. ICD-10-CM turns over every 1 October — FY2027 brings 190 new codes and 30 deletions — and CPT turns over every 1 January, with the 2026 set carrying 418 editorial changes. HCPCS moves quarterly. Your eval set ages out on those dates whether or not you re-run it.
• Re-baseline after every turnover. A held-out set coded before the update measures the old vocabulary. Re-cut it, and expect a genuine accuracy dip in the affected families for a cycle.
• Discount vendor accuracy claims. The published autonomous-coding figures — 95%-plus accuracy, high direct-to-bill rates — are self-reported and, as far as we can find, none is independently audited. Your own blind-coded sample is the only number about your own encounter mix.

Related: healthcare agents for the clinical-safety frame, insurance claims agents for the same problem viewed from the payer's side, model risk management for the validation programme this needs, and human-in-the-loop for designing the review step so it stays a control rather than a rubber stamp.