Insights › Health systems
Health systems
Rule, model, or neither: deciding where AI belongs in revenue cycle
One question settles most of it. What is left is knowing why chained steps fail in production, and which number actually tells you a deployment is working.
By The CercaLabs team · Published June 2, 2026 · 5 minute read
I sat through a vendor demo where an agent read a denial letter, pulled the supporting documentation, drafted an appeal, and queued it for signature. Eight steps, start to finish, and every one of them worked.
It was genuinely impressive. I also would not have bought it, and it took me a minute to articulate why.
The demo showed each step working once. What it did not show is what happens to the chain when each step works ninety five percent of the time, which is roughly where good models land on real documents.
Multiply that across eight steps and the whole thing is right about two thirds of the time. Not because any step got worse. Because reliability multiplies instead of averaging.
That arithmetic is behind most agent pilots that demo beautifully in October and get quietly switched off by February.
One question decides most of it
Before any of the reliability math matters, there is a simpler question that settles where a model belongs at all.
Does the work have a defined right answer given the inputs?
If yes, use a rule. A rule is cheaper, it is auditable by construction, and it fails loudly rather than quietly. If the input is unstructured or the judgment is genuinely interpretive, a model earns its place.
Choosing wrong is the most expensive mistake in this category and it happens in both directions. A model in front of deterministic work wastes money and adds a failure mode you did not have. Rules written for genuinely variable documents break within a quarter.
The most common version is the first row. An eligibility transaction returns a defined answer. Routing it through a model adds cost, latency, and something new to debug.
Why the failure feels so strange when it arrives
The compounding problem has a particular signature, and it confuses good teams.
Every component tests fine. Somebody reviews each step, finds nothing broken, and reports back that the system is working. Meanwhile the output is wrong often enough that people have quietly stopped trusting it.
The problem exists only at the level of the chain, and the chain is usually the one thing nobody built a test for.
The response is not a better model. It is shorter chains, with a human checkpoint placed where the cost of being wrong rises rather than at the end.
Most teams put review at the end by default. That catches the error after you have already paid for all eight steps, which is the most expensive possible place to find it.
The number nobody asks for
Most organizations evaluate a deployment on accuracy. That is the vendor's metric, and it is measured against a test set somebody curated.
The number worth instrumenting is how often your own reviewers override the output. That one is measured against reality, by the people who have to live with the result.
If your specialists are correcting a third of the queue, the accuracy score is not describing your world. And the fix is rarely a better prompt. It usually means the model was pointed at a decision it should not have been making.
Instrument disagreement from day one and treat a rising override rate as a design problem rather than a training problem. A team that cannot tell you its override rate cannot tell you whether the thing works.
Three places we will not put a model
We would rather say this before a contract than after.
Anything submitted to a payer without review. A confidently wrong authorization request is worse than a slow one. It burns the appeal window and can create a record you have to explain later. Human approval before submission is not a phase one precaution we remove once everyone relaxes.
Interpreting coverage policy as authoritative. A model will summarize a coverage determination fluently and be wrong about the clause that decides the case. Use it to surface the relevant passage to a person, not to conclude that a service is covered.
Compensating for a broken upstream process. If registration captures bad demographics, a model that cleans them downstream hides the defect and makes it permanent. Fix the intake.
Where none of this applies to you
If you have a narrow, well-bounded document problem and a human reviewing every output, most of this caution is overhead you do not need. Short chains with review built in are exactly the case where a model is straightforwardly good, and I do not want to talk anyone out of that.
The honest limit on our own position is that it makes for a smaller engagement than most people expect when they start the conversation. The incentive in this market runs toward putting a model in front of everything, because that is what gets funded.
We think that produces expensive, fragile systems that get switched off after the first incident, and we have watched the pattern run through two technology cycles now. Our bias is the opposite, and it costs us work sometimes.
I will also say plainly that our named engagements are automation and document processing. Our current generation AI work is most visible in products we build ourselves rather than in a large reference deployment, and you should weigh that accordingly.
*Bring one workflow to a teardown and we will tell you which side of the line it sits on, including when the answer is that you do not need us.*