Grounding is the easy half of autonomous medical coding - an Arintra teardown

Every serious writeup of AI medical coding makes the same argument, and the argument is correct. Ask a language model for an ICD-10 code and it returns something shaped exactly like an ICD-10 code, whether or not one exists. So you stop letting it generate. You make it retrieve: the model proposes, a lookup against the real tables confirms, and anything that fails never reaches a claim.

That fight is worth having and it is mostly won. What I want to write about is the failure on the other side of it, because it is the one I hit, and it is the one I have not seen described anywhere. Call it the grounded wrong answer. The row exists. The lookup succeeded. Nothing hallucinated. The claim still denies.

Here is the shape of it, from the bundling table my own prototype reads. CPT 99213 is the established-patient office visit, one of the two highest-volume evaluation and management codes in American medicine. 99452 is the interprofessional referral service a treating physician reports for the work of arranging a specialist e-consult. The table says they are bundled with a modifier indicator of 0, meaning no modifier separates them: bill both, lose one. The row is real. It is also dead. It carries a deletion date of 31 December 2019.

column1  column2  effective_date  deletion_date  ccmi
99213    99451    20190101        20191231       0     <- returned
99213    99452    20190101        20191231       0     <- returned

Eighteen pairs carry that retired edit: nine office-visit codes, 99202 through 99205 and 99211 through 99215, each against both 99451 and 99452. All four codes in the block above are still live, carrying status A, separately payable, in the January 2026 fee schedule file I have loaded. A system that retrieves the newest matching row and stops has been hard-blocking that combination for more than six years, from a real database, with no hallucination anywhere in the pipeline.

What follows is how autonomous coding actually works, in the order the work happens: the code sets, the rules that govern them, the edit layer, and the places where I found this same temporal problem in my own system. Every number below comes from querying the tables, not from memory. I point at the working version once, at the end, and I am specific about what it is currently doing.

What the coder is actually being asked to produce

An encounter turns into a claim through three code sets doing three different jobs. ICD-10-CM carries the diagnoses, the why. CPT and HCPCS carry the services, the what. For risk-adjusted populations a fourth layer sits on top, mapping diagnoses to hierarchical condition categories that set a payment rate for the following year.

The procedure side matters more than it first appears, because two different bodies own it. The 2026 NCCI policy manual puts it plainly: CPT codes are defined in the AMA's CPT Professional codebook, "which is updated and published annually," while HCPCS Level II codes are defined by CMS and are "updated throughout the year as necessary."¹ So one claim line can carry a code from an annual release sitting next to one from a set that changes whenever CMS decides it should.

CPT 2026 alone carried 418 changes effective 1 January 2026: 288 new codes, 84 deletions and 46 revisions.⁴ Those are deltas, not a total. I am deliberately not quoting a total number of CPT codes, because the AMA does not publish one in that release and the commonly repeated figure does not trace to a primary source.

The diagnosis side has a trap that catches naive implementations immediately. The CMS ICD-10-CM order file holds 98,186 rows: 74,719 billable, 23,467 not. The non-billable rows are category headers. E11 (type 2 diabetes) and N18 (chronic kidney disease) are real entries in the real file and neither is a codeable answer. A coder that asks only "does this code exist?" passes all 23,467, 24% of the table. Existence is the wrong question. Billability is, and it lives in a separate column.

The rules that decide the answer are not in the note

This is why retrieval is necessary but nowhere near sufficient. The ICD-10-CM Official Guidelines are a separate rulebook governing how the tables may be used, and several of its rules are the opposite of what a careful, clinically literate model does by default.

Start with the one that surprises engineers most. Code assignment "is based on the provider's diagnostic statement that the condition exists ... Code assignment is not based on clinical criteria used by the provider to establish the diagnosis."² A model that reads the labs, notices they support sepsis, and codes sepsis the provider never documented is fabricating, no matter how clinically correct it is. The chart is not evidence of the condition. The provider's statement is.

Then the rule that cuts the other way. Under the "with" convention, "the classification presumes a causal relationship between the two conditions linked by these terms," and such conditions "should be coded as related even in the absence of provider documentation explicitly linking them," unless the record says they are unrelated or a guideline demands an explicit link.² A cautious model refuses to connect a diabetic's kidney disease to the diabetes without an explicit statement. The classification requires it to.

And then the one I would use to test any autonomous coding vendor, because it cannot be answered from the note at all. Both the Section II and Section III guidelines say that if a diagnosis documented at discharge is qualified as "probable," "suspected," "likely," "questionable," "possible," or "still to be ruled out," you "code the condition as if it existed or was established," each carrying the same note restricting it to inpatient admissions. Section IV then states that these guidelines "were developed for inpatient reporting and do not apply to outpatients."²

Excludes notes work the same way. A type 1 excludes note "is a pure excludes note. It means 'NOT CODED HERE!'" and the excluded code "should never be used at the same time as the code above the Excludes1 note."² That constraint lives in the tabular list, not in the code record. A system that retrieves descriptions without the notes above them violates it while passing every existence check.

The published evidence points the same way, with a caveat worth stating rather than burying. A two-stage retrieve-then-rank system scored 100% on ICD-10-CM assignment where a bare GPT-3.5-turbo baseline scored 6%,¹⁴ mechanistically this argument exactly. But the evaluation set was 100 single-term conditions, which the author flags as needing validation on realistic cases. It tells you retrieval is the right architecture. It tells you nothing about a four-page discharge summary.

Then the edit layer runs, and it is not one rulebook

Correct codes still fail. Three independent CMS edit systems sit between a set of codes and a paid claim: procedure-to-procedure edits, medically unlikely edits, and add-on code edits.¹ The first two do most of the damage, and they answer different questions.

NCCI procedure-to-procedure edits

A PTP edit is a pair. "If a provider/supplier reports the 2 codes of an edit pair, the Column One code is eligible for payment and the Column Two code is denied. However, if it is clinically appropriate to use an NCCI PTP-associated modifier, both the Column One and Column Two codes are eligible for payment."¹

Whether a modifier can rescue the pair is carried by one digit, the Correct Coding Modifier Indicator. A CCMI of 0 means "modifiers cannot be used to bypass the edit"; a CCMI of 1 means they "may be used to bypass an edit under appropriate circumstances"; a CCMI of 9 means their use "is not specified," and is used "for all code pairs that have a deletion date that is the same as the effective date."¹ That last clause is a tell. The file format itself assumes pairs born and retired on the same day, so the data model is temporal from the start.

Medically Unlikely Edits

An MUE is "the maximum UOS reported for a HCPCS/CPT code on the vast majority of appropriately reported claims by the same provider/supplier for the same beneficiary on the same date of service."¹ Units, not pairs. Some values come from anatomy, pleasingly obvious once stated: "The MUE value for an appendectomy is '1' since there is only 1 appendix."¹

The operationally important field is not the limit. It is the MUE Adjudication Indicator, which decides what a coder can do about a denial. "An MAI of '1' indicates that the edit is a claim line MUE. An MAI of '2' or '3' indicates that the edit is a DOS MUE."¹ Under MAI 1, units can be split across claim lines with a modifier, each line adjudicated separately. MAI 2 edits are absolute, "per day edits based on policy," where override "would be contrary to CMS policy." MAI 3 edits are "per day edits based on clinical benchmarks," and a contractor "may bypass the MUE ... during claim processing, reopening, or redetermination" if records show the units were provided, correctly coded and medically necessary.¹

Those are three different instructions to a human: split the line, do not bother appealing, appeal with the chart attached. A system returning a limit without the indicator cannot answer the only question the biller has. Nor can you assume your table is complete: "Most MUE values are published on the CMS MUE webpage. However, some MUE values are not published and are confidential."¹

Risk adjustment, where the version is the answer

For Medicare Advantage populations, diagnoses map to hierarchical condition categories that drive payment. The critical fact for 2026 is that the model changed and the transition is finished: CMS "is completing the three-year phase-in of the 2024 CMS-HCC risk adjustment model" and "is calculating 100% of the risk scores using only the 2024 CMS-HCC model."⁵

So an HCC category number on its own is not an answer. It is an answer plus a model version, and an implicit version makes the number ambiguous. My mapping table holds 11,351 rows: 8,019 codes carry a V28 category across exactly 115 distinct categories, 9,822 carry a V22 category across 79, and 2,236 have a V22 mapping and no V28 mapping. Report one of those as risk-adjusting in 2026 and you are describing a model CMS no longer runs.

The temporal bug, measured

Here is the lookup my engine used to answer "can these two codes be billed together." It is the obvious implementation, and I wrote it.

const { data } = await db
  .from('ncci_ptp_practitioner')
  .select('column1_code, column2_code, modifier, rationale')
  .or(`and(column1_code.eq.${code1},column2_code.eq.${code2}),` +
      `and(column1_code.eq.${code2},column2_code.eq.${code1})`)
  .order('effective_date', { ascending: false })
  .limit(1);

The table it queries is not a list of current edits. It is an append-only log of every practitioner PTP edit CMS has issued, spanning 1 January 1996 to 1 April 2026 across 119 distinct effective dates. Retirement lives in a second column: CMS writes an asterisk for an edit still in force and a date for one withdrawn. So I measured what ignoring that column costs.

total rows                                   2,630,927
distinct code pairs                          2,323,399
pairs whose newest row is still active       1,726,993
pairs whose newest row is a RETIRED edit       596,406   (25.7%)

596,406 pairs. A quarter of the table. For every one the lookup succeeds, returns a genuine CMS row, and the validation layer raises a critical NCCI_VIOLATION reading "These codes cannot be billed together on the same encounter. Select the higher-value code." That is a revenue-suppressing instruction and a route-to-human trigger, issued with total confidence from data that was correct at some point since 1996.

That number needs one honest deduction, and making it is the same discipline this piece is arguing for. Many edits were retired because one of the two codes was itself deleted, and a code that no longer exists cannot reach a claim. Filter to pairs where both codes still appear in the January 2026 fee schedule file I have loaded, and 596,406 becomes 44,823. That smaller number is the one I would defend: it is the subset that can still fire on a claim submitted today. Quoting the larger one without the deduction would be a grounded wrong answer about grounded wrong answers.

The gap between the two figures has a worked example sitting in it. CPT 99213 carries a second retired bundle, against 94662, three generations deep at 2000, 2016 and 2020, the newest of them retired on 31 December 2025. The lookup returns that one as a live hard block too. But 94662 was deleted from the CPT code set effective 1 January 2026,¹² and it appears nowhere in my loaded fee schedule or MUE tables, while its sibling 94660 is in both. The retrieval is just as wrong. The claim it would have blocked cannot be submitted. Both failures are real, only one of them costs anybody money, and a system that cannot tell them apart will report the wrong size for its own problem.

The fix is one predicate. The lesson is not, because the bug is invisible from every angle you would normally look from. The model behaved. The row was real. The join was correct. Nothing logged an error, and a test against any pair CMS never retired passes, so the suite stays green. The only way to see it is to know the reference data has a time dimension and go looking.

The same shape, three more times

Once I knew what to look for, I found the same class of error in three other places in my own code. None is exotic. All are the kind of thing that survives review because each line is individually defensible.

1. Two halves of one function disagreeing about the payment year

The HCC lookup filters to rows where the V28 category is present, then its reducer falls back to the V22 category when V28 is missing. Those two lines express opposite intentions, six lines apart in one function. The filter says "2026 only." The fallback says "use the old model if the new one has nothing."

I checked which wins, because guessing would have been exactly the failure this piece is about. Those 2,236 V22-only codes hold a true SQL null in the V28 column, not an empty string, so the filter excludes them and the fallback is unreachable dead code. The behaviour is right in 2026 by accident of how the loader wrote nulls. If a future load writes empty strings, the dead branch wakes and the system reports V22 categories in a year calculated entirely on V28. A latent bug triggered by a data-loading detail is worse than a live one, because nothing tells you the day it arms.

2. The column that decides the appeal, empty in every row

The MUE checker compares a count against mue_value and never reads the adjudication indicator. I assumed that was a code problem until I queried the table: mue_adjudication_indicator is an empty string in all 15,264 rows. The column exists and the load never populated it. So the engine cannot tell a claim-line edit from a date-of-service edit, or MAI 2 from MAI 3, which is the difference between "do not appeal" and "appeal with the chart." The most decision-relevant field in the file is absent, and because the column is present and empty rather than missing, nothing errors.

A blunter limitation sits underneath it. The checker counts how often a code appears in a list; real MUE adjudication sums units of service, per line or per date of service. Not the same operation, and saying so is worth more than papering over it.

3. Two lookups for the same code that disagree

The CPT/RVU table is not a list of CPT codes. It is a list of priced line items, and a code appears several times with different modifiers, because the professional and technical components of one service are priced separately. My loaded file holds 19,226 rows covering 16,978 distinct codes, including 1,132 rows with modifier 26 and 1,113 with TC. So a radiology coder that emits 71046 has not finished the job: global, professional and technical are three different answers depending on who owns the equipment and who read the film.

Two functions read that table differently. The detail lookup filters to the bare-modifier row; the existence check does not filter at all. So a code whose only row carries a modifier passes validation, then returns null from every downstream check depending on the detail read: billability, E/M level, global period, MUE limit. I expected a large class. I queried it, and it is exactly one code, 86153 with modifier 26. One is not a crisis, but it is the difference between a bug I can describe precisely and a scare number I would have had to retract.

What the architecture looks like when it is right

None of this argues against the pattern. It argues for being specific about which layer is load-bearing. The shape I would defend is five stages, and the decisions that matter are in the last two.

1. Extraction. Pull clinical entities out of the note.
2. Clinical reasoning. Decide, per finding, whether it is codeable at all.
3. Code assignment. The LLM proposes codes with a self-reported confidence. The only stage where the model decides anything.
4. Validation. Deterministic. In my case nine checks: exists, billable, NCCI pair, MUE units, specificity, missing secondary, modifier alert, HCC gap, upcoding risk.
5. Routing. Deterministic. Decides whether the claim posts without a human.

The routing gate is not a model, and that is the most important sentence in the design. Any critical error routes to review. Any high-severity error routes to review. Auto-post requires mean confidence of at least 92 and zero critical errors. The model proposes; ordinary code decides what reaches a claim. Once that holds, a confident model stops being dangerous, because confidence is an input to a threshold rather than a licence.

The second decision is subtler and I got it wrong first. An early version deleted codes that failed the grounding lookup, the intuitive anti-hallucination behaviour. So when the tables became unreachable, every code failed, every code was deleted, and the pipeline cheerfully shipped a result with zero codes on it. Silent deletion is far worse than flagged uncertainty, because it looks like an answer. The current version tries a description match, then retains the code marked ungrounded with confidence capped at 75.

The third is one I would look for in anyone else's system: severity has to be a function of how complete your reference data is. When the full tables are live, a code that is not found really does not exist, and that is critical. On a declared subset the same miss only means "could not be verified here," and it is raised as a medium warning naming the subset size. Treating those identically is how you either bury coders in false criticals or wave through codes you never checked.

How accuracy should be measured, and how it currently is

Everything published about accuracy here is self-reported. Arintra's Series A announcement, $21 million led by Peak XV Partners in August 2025, reports Mercyhealth results of "5.1% increase in revenue and 43% reduction in denials on claims automated," a 50% cut in work queue aging and 32% lower coding costs, naming Epic and Athena as integrations.¹⁵ I have no reason to doubt those figures and no way to check them, which is the problem. I looked for an independent, peer-reviewed evaluation of any commercial autonomous coding product and found none. That absence is the most useful fact about the category's evidence base.

Note what "on claims automated" is doing there. It is the right way to report it, and it scopes the headline number to the subset the system chose to handle. Automation rate and accuracy-on-automated trade directly against each other: any system reaches very high accuracy by routing almost everything to a human. A vendor claim without both numbers is not a claim about performance.

The denial data is where this stops being an engineering argument and becomes a business one. KFF's analysis of CMS transparency filings found HealthCare.gov issuers denied 19% of in-network claims in 2024, ranging from 3% to 36% across insurers. Of those denials, 36% were recorded as "other," 25% administrative, 13% excluded service, 9% lacking prior authorization or referral, and only 5% for medical necessity. Of roughly 85 million denied in-network claims, consumers appealed at least 262,982, well under 1%, and insurers upheld the original denial in 66% of those internal appeals.¹³

On the risk adjustment side the enforcement environment tightened sharply and then got complicated. In May 2025 CMS announced it would expand audits "from ~60 MA plans a year to all eligible MA plans each year," approximately 550, grow its coder workforce "from 40 to approximately 2,000 by September 1, 2025," move from 35 records per plan to between 35 and 200, and "deploy advanced systems to efficiently review medical records and flag unsupported diagnoses," citing a MedPAC estimate that MA overpayments could run "as high as $43 billion per year."⁶

Anyone writing from memory would stop there and state extrapolated RADV recovery as settled law. It is not. On 25 September 2025 the Northern District of Texas vacated CMS's 2023 RADV final rule in Humana v. Becerra on Administrative Procedure Act grounds, finding the removal of the fee-for-service adjuster was not a logical outgrowth of the 2018 proposed rule.⁷ CMS noticed its appeal on 21 November 2025,¹⁰⁹ and the appeal is now Fifth Circuit No. 25-11293, captioned against Secretary Kennedy, in which the government filed its opening brief in March 2026.⁸ As of September 2026 the Fifth Circuit has not ruled.⁹ So the audit expansion stands, while the extrapolation methodology that made those audits existential is vacated and unresolved. A compliance narrative that depends on which of the two you mention is marketing.

The reference data moves on five independent clocks

Pull the cadences together and the temporal bug looks structural rather than careless. Nothing under an autonomous coder updates on the same schedule as anything else.

• ICD-10-CM: twice a year. CMS scopes the FY2026 files to encounters from 1 October 2025 through 31 March 2026, with a separate 1 April 2026 release.³
• CPT: annually on 1 January, with an Editorial Panel that "meets 3 times per year."¹
• HCPCS Level II: "updated throughout the year as necessary."¹
• NCCI PTP and MUE: quarterly. MUEs "are added on a quarterly basis," and add-on code edits post as quarterly complete files.¹
• MPFS RVU: quarterly. CMS posts four lettered files a year, RVU26A through RVU26D for 2026.¹¹ My own load is pinned to the January file and it is September.

That last admission is the honest summary of the whole piece. An autonomous coding engine is a data pipeline with a model attached, and the pipeline has a much shorter half-life than the model. Almost all the attention goes to the component that changes slowly. The failure I measured came entirely from the components that change quarterly, and it was invisible to any evaluation testing the model rather than the freshness of what it stood on.

So the diligence question is not "what is your accuracy." It is: which file version are you on for each of those five clocks, how do you learn a new one exists, what happens to a claim adjudicated against last quarter's edits, and can you show me the retirement filter in the query. The last one takes ten seconds to answer.

The working version, and what it is honestly doing

All of this comes out of a prototype I built, which is the only reason I can quote measured counts rather than round numbers. It runs the five-stage pipeline above against the public CMS corpus loaded into Postgres, with a deterministic routing gate and a status endpoint that probes the live tables rather than asserting what it thinks it has. It holds public reference data only: no PHI, no encounter data, no write path. A production system persisting encounters would be a different database with tenant isolation, a BAA with the model provider and redaction before prompts leave the tenant, and I would rather say that than imply this demo solved it.

One thing you can check rather than take on trust. The status endpoint counts the five tables on every request instead of asserting a connected state, so it reports the tier the deployment is actually on. At the time of writing it returns the supabase tier, complete, with the five counts used throughout this piece: 98,186, 19,226, 2,630,927, 15,264 and 11,351. It does not always return that. When the deployment cannot reach the database, the code falls back to a committed repo-seed subset of 99 ICD-10 codes and 48 CPT rows and says so, which is a state this deployment has been in as recently as this week. That is the point of building the probe rather than a badge: after everything above, an engine that quietly overstated its own grounding would be a poor advertisement for the argument. Check the endpoint before you believe the number.