The situation
A US specialty practice wanted to use AI to clean up its medical billing before claims went out the door. The promise is obvious. Read the clinical notes, suggest the codes, catch the mistakes, get paid faster. The problem is what happens when the AI is confidently wrong.
In medical billing a wrong answer is not a typo. Say the system lets through a claim the payer will reject. That claim comes back denied. Someone has to rework it and resubmit. The practice waits weeks longer to get paid, on work it already did. And the opposite error is just as costly: block a claim that was actually fine, and you have slowed revenue for no reason.
On top of all of it, every one of these decisions touches protected health information, so the whole thing sits inside HIPAA whether you like it or not.
The real question was never “can AI code a claim.” It was “how do you let AI help without giving it the final say on anything that costs money or breaks a rule.”
The hard part
Payer rules are not one kind of thing, and most teams treat them as if they are.
Some rules are hard and precise:
- this payer requires pre-certification for that procedure
- these two codes cannot be billed together
- this diagnosis rules out that procedure
- this service is capped at three per year
And several hundred more like these, for every payer. None of them are judgment calls. They are lookups. If you answer them with a language model you will eventually get a confident, fluent, wrong answer, and a denied claim.
Other rules are genuinely prose. Something like “covered only when the patient’s records document a real clinical need for it” cannot be reduced to a table. Someone has to read the notes and judge. That needs reasoning.
The mistake we set out to avoid was using the probabilistic tool for the deterministic job. A model guessing at “does this need pre-cert” is a liability. The same model reading a paragraph of medical-necessity criteria is exactly the right tool. The whole trick is knowing which rule is which.
What we did
We split the problem down the middle.
Everything that could be made exact, we made exact. We built structured rule tables covering the mechanisms that actually cause denials: bundling edits, modifier rules, pre-certification, non-covered services, diagnosis exclusions, frequency caps, add-on dependencies, site-of-service. We populated them from the payers’ own published policies, not from an AI summary of those policies, because the summaries drifted. The same rule showed up as six weeks in one place and twelve in another. Ground truth had to be the source document.
That gave us a deterministic gate. The same claim, checked twice, produces the same verdict every time. No re-guessing between runs. If a combination is a known conflict, the gate catches it, and it can tell you exactly which rule fired and why.
The prose rules, the real judgment calls, went to a separate reasoning layer, clearly fenced off. The model reasons over policy text where reasoning is appropriate, and never gets to overrule a hard gate.
Two things mattered for the regulated context specifically. First, the validator is PHI-minimal. It reasons over codes, units, place of service and payer, and the audit logs never carry patient identifiers. The compliance posture is in the design, not bolted on.
Second, nothing is a black box. Every decision is explainable down to the specific rule and citation, which is exactly what you need when someone asks why a claim was held.
We built and validated this across four major national payers, several hundred real rule cases each, and proved the gate across the five denial mechanisms that cause the most rework.
We also made a deliberate safety choice: if a claim combination is not a known conflict, the system does not invent a reason to deny it. It passes it through. The gate encodes known problems; it does not manufacture new ones.
The outcome
The engine is built, loaded across four major payers, and proven across five distinct denial mechanisms. It runs inside the claim pipeline, merging its verdict into the practice’s existing workflow rather than replacing it. It is in final UAT now, approaching production for a live US practice.
What the practice gets is not “AI that does billing.” It is AI that helps where AI is safe, sitting on a deterministic gate that will not let a confident guess become a denied claim.
If you are facing the same thing
The pattern generalizes well beyond billing. Any time you put AI into a regulated workflow, the useful question is not “how good is the model.” It is “where in this process is a wrong answer expensive or non-compliant, and what deterministic check sits underneath the model to catch it.”
Getting that line in the right place, what the model decides versus what a hard gate decides, is most of the work, and it is the part generic AI tooling skips. We have now drawn that line inside a HIPAA billing system, a GxP quality system, and a financial-services assurance platform. It is the same discipline every time.
Putting AI into something where mistakes have consequences?
That is the conversation worth having. If you are building AI into a regulated or high-stakes workflow, we have done this before, and we can talk through where your deterministic floor needs to be.
Start a conversation →