Autonomous medical coding, built as a working prototype
Every clinical encounter in US healthcare has to be turned into codes before anyone is paid for it. A person reads the note, works out which diagnoses and procedures it supports, and assigns ICD-10-CM, CPT and HCPCS codes to them. The work is slow, it is expensive, and the error modes are unforgiving in both directions: code too conservatively and the provider is paid less than the care was worth, code beyond what the note documents and the claim is a compliance problem. Claims that fail on a coding technicality come back as denials, and reworking a denial costs more staff time than coding the encounter did in the first place. Autonomous medical coding is the category of software that tries to do this first pass without a human in the middle of it.
This page is a working prototype of what that software has to do. You can paste a note, pick a specialty, and watch five agents take it apart: extract the clinical entities, decide which of them are codeable, assign codes, validate the resulting claim, and route it to billing or to a human. The point of building it rather than diagramming it is that the hard parts only show up when the thing runs. A note that says a symptom was denied must not become a code. A model that confidently returns a code that does not exist has to be caught by something other than the model. Two codes that are each defensible alone can be indefensible billed together. None of that is visible in a slide.
So the engine is built the way a real one has to be built: the model proposes, and code outside the model decides. Every code the model returns is checked against a reference set before it is allowed anywhere near a claim, and a code that fails that check is flagged for a human rather than deleted, because silently dropping a code is its own kind of error. Validation runs across the whole claim, not code by code. Routing is a policy, not a vibe: a confidence threshold you can move, with the review queue visibly growing or shrinking as you move it. When the model path fails outright, a deterministic rule layer answers instead, so the interface never presents an empty result as a successful run. Every run writes an audit trail that states which grounding tier it used, and the interface labels which parts of any screen are live engine output, public-sourced fact, or synthetic sample.
Arintra is a real company working in autonomous medical coding. This is an independent concept study of the problem space by Kaushal Khodifad, with no affiliation with, endorsement by, or access to that company, and it does not represent their product. The outcome figures shown in the interface above are illustrative scenario inputs, not measurements of this prototype or of anyone else's.
The five agents
- NLP extraction. Reads the free-text note and pulls out clinical entities, tagging each one as present, absent or historical. The distinction is the whole job: a note that says a symptom was denied, or that a condition is in the patient's history, must not produce a code for it.
- Clinical reasoning. Decides which of those findings should actually be coded and which should be skipped, and records a rationale for each decision rather than just a verdict.
- Code assignment. Maps the findings that survived to ICD-10-CM, CPT and HCPCS codes. Every proposed code is then looked up in the loaded reference set. A code that cannot be verified is kept and flagged for a human, never silently dropped and never silently invented.
- Validation. Runs the nine checks listed below across the whole claim, not code by code, because most coding errors are relationships between codes rather than a single bad code.
- Routing. Sends the claim to auto-billing or to the human review queue based on confidence and on what validation found. The confidence threshold is a control on the page, so you can watch the automation rate and the review queue trade against each other.
The nine checks before a claim may bill
- Code not found.
- The code is not in the reference set that is actually loaded. On the demonstration subset that means unverified here rather than nonexistent, so it is flagged at medium severity instead of killing the claim.
- NCCI violation.
- Two procedures billed together that CMS procedure-to-procedure edits say may not be, checked against the committed NCCI pairs including whether a modifier is permitted to override the edit.
- MUE violation.
- A code billed more times than its medically unlikely edit limit allows. On the committed subset the limit that can fire is the implicit one-per-encounter cap on evaluation and management codes; per-procedure MUE values come from the optional database tier.
- Low specificity.
- An unspecified code used where the documentation supports a more specific one, with the more specific alternatives surfaced.
- Missing secondary.
- A condition affirmed in the note with no matching diagnosis code assigned to it.
- Upcoding risk.
- A level 5 evaluation and management code on a note too thin to support it.
- Modifier alert.
- An evaluation and management code billed alongside a procedure, which needs a modifier review before submission.
- Not billable.
- An ICD-10 category header submitted as though it were a billable code.
- HCC gap.
- A code with no risk-adjustment mapping where a sibling code does carry one, which is the difference between documenting a condition and being paid for its complexity.
How this demo is grounded
The anti-hallucination check is only as good as the reference set behind it, so the reference set is stated exactly rather than described vaguely. This deployment runs the repo-seed tier: the code sets are committed in the repository, which makes the engine reproducible from the repository alone with no remote database. The numbers below are read from those files at render time, not typed here.
- 99 ICD-10-CM codes, a demonstration subset of commonly billed codes from CMS ICD-10-CM FY2026. The full CMS set runs to roughly 74,000 codes and is not loaded anywhere in this project.
- 48 CPT codes with work RVUs, a demonstration subset of AMA CPT 2026. The full set requires an AMA licence, so only the subset is committed.
- 27 NCCI procedure-to-procedure pairs from the CMS Q1 2026 practitioner file, plus 17 codes carrying a medically-unlikely-edit limit and 56 diagnosis codes carrying a risk-adjustment mapping.
- Sixteen specialty configurations, each with its own expected code library, documentation pattern and validation behaviour.
Because the reference set is a declared subset rather than the complete code sets, a lookup miss is treated as unverified here rather than as proof the code does not exist. The engine says so in the audit trail of every run, and the same wording appears on the validation error itself. If the full datasets are loaded into the optional database tier, the severity of that same check rises accordingly.
What is inside the workspace
- Executive Overview.
- The framing, the seven design layers of the product, and a provenance legend that tells you which parts of any screen are live engine output, public-sourced fact, or synthetic sample.
- ROI and Financials.
- A calculator you drive: set provider count, annual encounters and net patient revenue, and it decomposes the result into labor savings, denial reduction, under-coding capture and accounts-receivable acceleration, so you can see which assumption is carrying the number.
- RCM Walkthrough.
- One encounter stepped through seven phases: documentation improvement, autonomous coding, charge and scrub, 837P submission, payer adjudication, payment or denial, and financial analytics. Two of those steps hit real endpoints and the integration trace marks every step as simulated or real.
- Coding Engine.
- Pick a synthetic encounter or paste your own note, choose one of sixteen configured specialties, and run the five agents against it end to end.
- Denial Center.
- Denial prevention, root-cause grouping and appeal drafting. The appeal skeletons here are rule-based and labelled as such; the live model-written appeal sits in the walkthrough's denial phase.
- AI Architecture.
- The pipeline with its lid off: per-agent output, timings, the grounding tier the run used, and the audit trail line by line.
- Compliance.
- Audit logging, plus an explicit split between what is verifiable in this deployment's code and what a production system would additionally require.
Data posture, stated honestly
True of this deployment, verifiable in the code
- Grounding lookups are read-only queries against public CMS reference tables. They are reference data, never patient data, and the server-side database key never reaches the browser.
- Agent system prompts stay server-side. The browser sends only note text and a specialty.
- Analytics is a single anonymous page-view ping, with no IP capture, no geolocation and no user-agent parsing.
- Every sample encounter shipped with the demo is synthetic.
Not implemented here, and required before any real deployment
- A business associate agreement and zero-data-retention terms with the model provider, or an in-tenant deployment inside the covered entity's own cloud.
- PHI redaction or pseudonymization before any prompt leaves the tenant boundary.
- Tenant isolation with row-level security on every table touching encounter data, plus role-based access for coder, auditor and admin.
- Immutable audit-log retention, access logging, and a breach-notification runbook.
- Independent attestation of the deployed stack.
This prototype has never processed real patient data and is not a medical device, a billing system, or clinical advice.