Every billing team will tell you they scrub everything before it goes out, and it is true as far as it goes. A scrubber is the automatic check a claim gets before it is sent, and a claim is the bill sent to the insurance company for a visit. The scrubber tests each claim against the rules the insurance companies have published.
There are two kinds of reason a claim gets denied, and a scrubber is built for the first kind. Practices buy protection against that one and believe they are covered for both. The second kind is local: one insurance company, one combination of codes, failing at your practice for reasons nobody wrote down anywhere.
Here is where this sits on the path from a visit to money in the bank. A visit becomes a charge, the visit written up as a billable line, and the charge becomes a claim.
The claim is checked and sent, and the insurance company answers with a payment or a denial, a refusal to pay with a reason code. This piece is about the moment just before the claim leaves, and it is one of the five checks that watch the money path.
What is checking medical claims against your own history?
Testing a claim against what has failed at your practice, not just the published rules. The evidence is your own payment reports, the insurance company’s explanation of what it paid and refused, because your own denials are the only place a local pattern exists.
At practices we have worked with, the same claim gets sent again and again, fixed each time to what the denial said, and nobody sees the repeats as a set. A scrubber catches what the rules say. This catches what your data says.
Why a scrubber cannot see the second kind
The scrubber is fine. The limit is in what a rule can be. A scrubber applies rules that somebody wrote down, and that is exactly what makes it work. A local failure has no rule to apply, because nobody published one.
The insurance company changed how it handles something and did not announce it, or the behavior applies to one plan or one contract term specific to you. So the only evidence that the pattern exists is in your own denials. Which means the only thing that can catch it is something reading your own denials.
Why the pattern stays invisible
Denials arrive one at a time into a work queue, and a queue gets worked one item at a time. The person working a denial sees one claim and fixes it. They are not looking across three months of denials for a combination that keeps appearing, because nothing presents it that way and there is no natural moment to ask.
The pattern is fully present in the data. It has simply never been looked at as a set. That is the difference between a biller who is good at appeals and a practice that has stopped manufacturing the same denial.
Building the list
Four steps, and the whole thing runs on data you already have. First, group your denials by what was on the claim: the insurance company, the code, the modifier, a code added to say how a service was done, the place of service, the provider. Group by those and not by the denial reason, because the reason is what the insurer said and the claim details are what you controlled.
Second, find the combinations that fail at a high rate. That is different from the ones that fail the most times in raw numbers, since those are usually just your highest volume. Third, set a confidence floor. Two failures is coincidence. Ten out of twelve is a pattern. Without a floor you will build a list of noise and stop trusting it within a month.
Fourth, check every new claim against the list before it is sent. A claim matching a known-fail combination stops and goes to a person, instead of going out to be denied on schedule. That last step is what makes this prevention. A list nobody checks against is a report.
Why the list has to be maintained
This decides whether the list stays useful or becomes a liability. Insurance company behavior changes. A combination that failed reliably in March may pay in September, because a rule was reversed or a contract was renegotiated.
A list built once and never refreshed becomes wrong in both directions. It misses new failure patterns, and it blocks claims that would now be paid, which is worse, because it holds up money for no reason and the practice never finds out.
So the list needs a refresh cycle and an expiration rule. A pattern that has not recurred in a defined period comes off, and new patterns come on as the evidence builds.
How this differs from working denials harder
The two get confused, and they are opposite activities. Working denials faster reduces the cost of each one, which is real value, and it does nothing to the count. The same claims fail next month at the same rate. Checking against your own history reduces the count, because the claim that produced the denial stops going out.
A practice can be excellent at appeals and still be manufacturing the same denials every week. Strong appeal numbers tend to hide the manufacturing. The same logic runs through every place a denial gets made before the claim leaves, and this is the one that catches what the published rules miss.
Real situations, and what the queue showed at the time
A common version: every claim to one insurance company goes to an electronic mailbox that insurer no longer reads. The scrubber passed every one, because every one was correctly built. The denials came back as “not on file,” and the pattern was visible in one afternoon of grouping by insurer.
At another, one denial reason showed up at four times its usual rate. Grouped by insurer and code, it was one company applying a new rule it had not announced. Once the combination was on the list, the next claims that matched it stopped at the desk instead of failing on schedule.
Where the same idea already works
Any operation that runs the same process over and over builds a record of how that process fails, and uses the record as well as the manual. A maintenance crew knows which part fails on which machine in a way no manufacturer’s specification captures, because they have watched it happen. A support desk knows which fix clears which symptom faster than any documentation says.
That local knowledge is more accurate than the general knowledge, and it only exists in the operation’s own history. Claims work the same way. The difference is that in most practices the local knowledge lives in one biller’s head instead of in a list, which means it leaves when they do.
What this means for you
Take twelve months of denials and group them by insurance company and code combination. Sort by failure rate instead of by count, and apply a minimum volume so single events do not appear. The top of that list is what your practice is manufacturing.
Most of it will be a handful of combinations recurring, and every one of them is being resubmitted right now by somebody who has no way of knowing it has failed nine times before. Put the top five on a list, and check tomorrow’s claims against it before they leave.
Grab 30 minutes with us. Prep nothing. You will see which combinations are failing at your practice and how often.
Questions people ask
What is checking claims against your own history?
Testing a claim against what has actually failed at your practice, instead of only against published rules. The evidence comes from your own payment reports and denials, which are the only place a local failure pattern exists. A claim that matches a known-fail combination stops before it is sent.
Why can a scrubber not catch these denials?
Because a scrubber applies rules somebody wrote down, and a local failure has no rule. The insurance company changed something without announcing it, or the behavior applies to one plan specific to you. Only your own denials show it, so only something reading your own denials can catch it.
How do I find failure patterns in my denials?
Group by what was on the claim, the insurance company, the code, and the modifier, instead of by the denial reason. Sort by failure rate instead of by count, and apply a minimum volume so coincidence does not appear as a pattern. Two failures is chance. Ten of twelve is a pattern.
How often should the pattern list be updated?
On a cycle, with an expiration rule. Insurance company behavior changes, so a list built once becomes wrong in both directions: it misses new patterns and it blocks claims that would now pay, which holds up money for no reason. Take a pattern off when it has not recurred in a set period.
Is this different from working denials faster?
It is the opposite activity. Working denials faster reduces the cost of each one and does nothing to the count. Checking against your own history reduces the count, because the claim that produced the denial stops going out. A practice needs both, and only the second one shrinks the pile.