First-pass claims review: patterns, anti-patterns, and pitfalls
Claims review is the workflow with the highest ratio of pain-per-FTE to organizational appetite for change. Reviewers are expensive. Backlogs are visible. The audit posture is real. And yet the failure mode for AI in this space is depressingly consistent: a sandbox demo at 88% accuracy that never makes it past legal review.
Here are the patterns we use to ship, the anti-patterns to avoid, and the pitfalls we have hit ourselves.
Patterns that work
Cite the policy on every decision. The agent should not just emit a recommendation. It should emit the recommendation plus the specific policy clauses that supported it. Reviewers trust an agent that shows its work. Auditors require it.
Make denials a human decision. Even at high confidence, the agent should not auto-deny. Approve at threshold, route every denial to a reviewer with the full evidence pack pre-built. The PR risk of an "AI-denied claim" is not worth the throughput gain.
Track per-segment accuracy. Claims accuracy at the aggregate level can be 92% while the accuracy on a specific procedure code is 68%. Per-segment dashboards catch this; aggregate dashboards do not.
Replay every model swap. Before any model change ships, replay the last 1000 claims through the candidate and diff against what the supervisor approved. The two-hour replay run catches regressions a four-week shadow mode would miss.
Anti-patterns to avoid
Free-text reasoning as the audit trail. "The agent thought it was reasonable" is not auditable. Structured citations are auditable. If your platform's audit log is mostly model output strings, you are going to have a bad time at year-end.
One global confidence threshold. A 92% threshold on auto-pay is appropriate for a routine outpatient claim. It is dangerously high for a complex inpatient claim with multiple modifiers. Per-procedure thresholds, per-dollar thresholds, per-provider thresholds. All three.
Treating reviewer corrections as noise. They are training signal. If your platform throws them away, or stores them but does not feed them back into evaluation, you have built a one-way curve.
Pitfalls we have hit
We shipped a claims pilot last fall where the agent's accuracy on a specific MCO's claims dropped 6 points in a week. The cause turned out to be a routing change on the MCO's side that altered which claim type came through which channel. The agent was fine. The data distribution had shifted.
The fix was the eval harness. Per-payer dashboards caught the drop within three days. Without per-segment metrics, we would have been chasing a "model regression" that did not exist.
The lesson, restated: the model is rarely the bottleneck in claims. The data plumbing, the per-segment metrics, and the per-decision audit trail are. Get those three right and the model improvements just compound on top.