Articles

AI medical bill review: why we gave the model less to do

Every accuracy problem we hit building an automated medical bill review engine was fixed the same way: by taking work away from the AI. Four times we found a failure, and four times the fix was to hand that job to deterministic code or to a paid service and leave the model with less. The engine got more accurate as the model got smaller.

01Reading the PDFmoved to a paid cloud OCR service
02Extracting the rowsmoved to deterministic code, the model keeps the remainder
03Computing the moneymoved to formulas, permanently
04Deleting duplicatesremoved entirely: nothing is deleted, both rows are kept

That is not the story an AI company is supposed to tell. It is what happened, and it is the reason the output is defensible.

The failure that set the pattern

The model invented numbers that were not on the bill.

Not often, and not randomly. It happened when the model was pushed into a corner: the figure it was asked for was illegible, or cut off, or simply absent from the page it had been given. Rather than return nothing, it returned something plausible. A dollar amount that looked exactly like the other dollar amounts on that bill, and that no provider had ever charged.

This is the specific failure that makes a language model unsuitable for the last mile of this work. It has no signal for its own unreliability, so a fabricated amount arrives with the same confidence as a correct one. The reasoning behind that behaviour, and why it is a property of the technology rather than a bug in one model, is the subject of why we are called System 2.

In litigation, that number ends up in a damages figure an expert signs. There is no version of this where that is an acceptable failure rate, so the response was not to prompt around it. It was to stop asking the model for numbers.

Round one: the model could not read the page

The first attempt was the obvious one. Hand the PDF to the model and ask it to read the bills. It did not work.

Scanned medical bills are hostile input. They are faxed, photocopied, rotated, stamped, and stacked on top of each other in one file. Columns do not line up. A paid amount and a billed amount sit inches apart in a grid the scan has partly destroyed. Reading that reliably is not a reasoning problem, it is an optical one, and a model asked to do both at once does neither well.

So the reading moved to a dedicated cloud OCR service, which returns the text along with the position of every word on the page. The model no longer sees the image. It sees a clean spatial grid with blank cells preserved, which is what stops a paid amount from sliding into an empty neighbouring column.

What does better OCR cost?

About what the model calls cost, and sometimes more. On a large case the OCR line is comparable to the entire AI spend, which is not what most people expect when they price out a document pipeline.

We pay it because OCR is the input to everything downstream. A cheaper read that garbles one digit in a CPT code does not save money, it moves the cost to a person checking a row, or to an expert defending a number that was never on the bill. The cheapest possible OCR is the most expensive part of a bill review pipeline, and that is the tradeoff worth stating plainly rather than optimising quietly.

Round two: extraction moved to deterministic code

With clean text available, the next question was who turns it into rows. Originally the model did. Now most of that work is done by deterministic code, and the model handles the small remainder.

The split is by confidence, not by preference. Where the structure of the document is recognisable, code reads it, and code reading a known structure is reproducible: it returns the same answer every time, and when it is wrong it is wrong in a way you can find once and fix forever. Where the document does not fit a known shape, the model reads it, and the result carries a confidence signal. Below the bar, the value does not become an answer. It becomes something the reviewer is asked to confirm.

The distinction that matters is not which one is smarter. A deterministic error is a bug and a model error is a coin flip. You can eliminate the first. You can only ever reduce the second.

Round three: no dollar figure is ever produced by a model

Every amount in the output is computed by a formula. Not checked by one. Produced by one.

The fee schedule lookups, the bilateral uplift, the multiple procedure reduction, the daily caps, the totals: all of it is arithmetic over values that came from a source page, run in code. The model is never asked what a number should be, because the model can be wrong and has no way to tell you it is.

Plenty of people in this field would call that overcautious, and in a lower-stakes domain they would be right. Here the output is an exhibit. Someone signs it, an opposing expert reads it looking for exactly one thing to break, and a single invented figure discredits the rest of a correct analysis. The asymmetry is not close, so the rule is absolute rather than a matter of judgment.

Round four: nothing gets deleted

The hardest problem in this work is that the same service is billed more than once. A provider’s HCFA, the insurer’s EOB, a ledger and a lien can all describe one office visit, and adding them up triple-counts the damages.

An early instinct is to have the model decide which lines are duplicates and remove them. We do not do that, and the reason is the same principle that governs the assembly step: a deleted charge is invisible, and an extra one is not.

So the engine merges what it can prove and keeps everything else. More than nine times in ten a duplicate is resolved correctly and collapses to one charge. The remainder stays in the workbook as two rows, highlighted, so the reviewer can see at a glance which lines are possible duplicates and remove one in a few seconds. That is a few seconds of work in exchange for never silently erasing a real charge.

What the engine asserts, and what it asks

This is the design idea underneath all four rounds, and it is the one worth stealing.

The output has two tiers. There is what the engine asserts, which is everything it can produce deterministically or verify, and there is what the engine asks, which lives on a checklist tab in the same workbook. Anything uncertain goes in the second tier. It never gets promoted into an answer to make the output look cleaner.

That is why the assertions can be trusted. Not because the system is incapable of being unsure, but because being unsure has somewhere else to go. A pipeline with only one tier has to resolve every ambiguity into a confident value, and a confident wrong value is the failure that costs an expert her credibility.

What this costs you, and where a model still earns its place

The buyer’s side of this is not zero. Somebody reviews the flagged rows and the checklist, and on a large case that is real minutes, not a rubber stamp. If you were hoping for a system that hands back a finished number nobody has to look at, this is not that, and we would rather say so before you start than after.

The model still does the part it is genuinely better at than any rule we could write: reading messy language. Deciding that a page is a bill rather than a treatment note. Recognising that two differently spelled provider names are the same practice. Proposing that two lines from different documents describe one service. Those are judgments about meaning, and code is bad at them.

What the model does not do is decide what anything costs. It reads. The arithmetic belongs to code, and the signature belongs to a person.

Questions004

Frequently asked questions

01

Can AI extract medical billing data accurately?

AI reads messy documents well and should not be trusted to produce the numbers. In our engine a language model classifies pages, resolves provider names and proposes duplicate groups, while every dollar figure is computed by deterministic code from values traced to a source page. The reason is that a model has no reliable signal for its own uncertainty, so a fabricated amount arrives looking exactly like a correct one.

02

Why not just send the PDF to an AI model?

Scanned medical bills are faxed, rotated, stamped and stacked, and reading them is an optical problem before it is a reasoning problem. Asking one model to do both at once produces worse results than separating them. A dedicated OCR service returns text plus the position of every word, and the model then works on a clean spatial grid rather than a damaged image.

03

How do you stop an AI from hallucinating a number on a medical bill?

Do not ask it for numbers. Every amount in our output is produced by a formula over values extracted from a source page, and the model is never in the arithmetic path. Where a value cannot be read with confidence, it is not filled in with a guess. It goes on a checklist for the reviewer to confirm.

04

What happens to duplicate charges the system is not sure about?

Uncertain duplicates are kept, not removed. Both lines stay in the workbook and are highlighted so the reviewer can see the possible duplicate and delete one in seconds. Deleting a real charge is invisible and unrecoverable, while an extra row costs a few seconds, so the system is built to make the second mistake rather than the first.

Burak Tamac spent eight years as a senior paralegal doing medical bill review by hand for a New Jersey personal-injury firm, and now builds document-processing systems for law firms and expert practices at S2Reason. He holds a Ph.D. in political science and is an adjunct professor at Montclair State University. The engine described here is the Expert Report Engine.

Try it on your own cases firstYou see it work before you pay for it.