Claims scrubbing: catching the error before the payer does.
A claim rejected by a scrubber costs a few seconds to fix. The same claim denied by a payer costs weeks of float, staff time to rework, and sometimes the money entirely. Scrubbing is simply moving the error detection from after submission to before it, and the economics of that shift are not close.
Key takeaways
- Rejections and denials are different. A rejection never entered adjudication and can be fixed freely; a denial is a decision that must be appealed.
- Generic edits are the floor, not the ceiling. The value comes from payer-specific rules built from your own denial history.
- Every recurring denial should become an edit. Otherwise the scrubber never improves and the same claims keep failing.
- A clean claim rate near 100% may mean weak edits. If nothing is being caught, the scrubber probably is not checking much.
What scrubbing checks, in order
Scrubbing runs layered checks. The first layer is structural: required fields present, identifiers formatted correctly, dates valid and internally consistent. The second is code-level: valid current codes, correct modifiers, code-pair edits, unit limits, diagnosis supporting procedure. The third, and the layer that separates a good scrubber from a generic one, is payer-specific: rules encoding what your particular payers reject, drawn from your own remittance history rather than a shared national ruleset.
That third layer is where most of the value sits and where most practices stop short. Every payer applies local policies and idiosyncratic field requirements that no off-the-shelf edit library covers. A denial that recurs three times and is reworked three times, without an edit being written, will recur a fourth.
| Layer | Catches | If missing |
|---|---|---|
| Structural | Missing NPI, malformed member ID, invalid or inconsistent dates | Clearinghouse rejection; fast to fix but delays the whole batch |
| Code validity | Deleted or superseded codes, wrong code for date of service | Denial after adjudication, requiring a corrected claim |
| Code pairs and modifiers | Bundled procedures, missing or invalid modifiers, laterality | Bundling denials and, where modifiers are misused, audit exposure |
| Medical necessity | Diagnosis not supporting the procedure under coverage policy | CO-50 denial requiring clinical appeal |
| Units and frequency | Units above payer maximums, services inside frequency intervals | Partial payment or denial that is easy to prevent |
| Payer-specific | Local field requirements, plan quirks, prior-auth flags | Recurring denials unique to your payer mix that no generic edit catches |
The feedback loop is the whole point
A scrubber is only as good as the rules in it, and the rules should grow from your own remittance data. The discipline is straightforward: every denial that recurs gets analysed for whether a pre-submission check could have caught it, and where the answer is yes, an edit is written. Over time the scrubber comes to encode the accumulated knowledge of what your specific payers reject.
Without that loop, scrubbing becomes a static gate that catches typing errors and nothing else, while the denials that actually cost money pass straight through. This is why clean claim rate alone is a poor measure of scrubber quality: a permissive scrubber produces a beautiful first-pass number and a disappointing collection rate.
Review your top ten denial reasons quarterly and ask one question of each: could a pre-submission edit have caught this? Where the answer is yes, write the rule. This single habit turns a static scrubber into one that improves continuously, and it is the difference between a clean claim rate that looks good and one that means something.
Do and don't
- Build payer-specific edits from your own remittance history.
- Convert every recurring denial into a pre-submission rule.
- Review the top denial reasons quarterly and act on them.
- Measure clean claim rate alongside first-pass payment rate.
- Keep code sets current so validity edits reflect the correct year.
- Don't rely solely on generic edit libraries.
- Don't treat a high clean claim rate as proof the scrubber is working.
- Don't let staff override edits routinely without recording why.
- Don't rework the same denial repeatedly without writing a rule.
- Don't leave prior year code sets active after the annual update.
Frequently asked questions
What is the difference between a rejection and a denial?
A rejection happens before adjudication: the clearinghouse or payer refused the claim on structural grounds, so it never entered the system. It can be corrected and resubmitted freely, and it does not count against timely filing in the same way. A denial is an adjudication decision, which means it must be appealed or corrected within a defined window. Rejections are cheap; denials are expensive. Scrubbing converts what would have been denials into rejections you fix yourself.
Is a 99% clean claim rate good?
Only if paired with a strong first-pass payment rate. A permissive scrubber that checks little will report an excellent clean claim rate while claims deny after adjudication, because the metric only measures claims accepted for processing. Look at both numbers together: claims accepted, and claims paid correctly on first submission. The second is what actually reflects revenue cycle quality.
How do we build payer-specific edits?
From your own remittance data. Group denials by payer and reason, identify those that a pre-submission check could have prevented, and write a rule for each. Start with the highest-volume causes, since a handful of rules usually covers a large share of preventable denials. The rules encode what your payers actually reject rather than what a generic library assumes, which is why they outperform off-the-shelf edits.
Should staff be able to override edits?
Yes, but with a recorded reason and periodic review. Legitimate exceptions exist and a scrubber that cannot be overridden will block valid claims. What matters is visibility: if one edit is overridden constantly, either the rule is wrong and should be refined, or staff are bypassing a genuine problem. Reviewing override patterns quarterly usually reveals which of those it is.
Do you configure scrubbing in our existing system?
Yes. We work with whatever clearinghouse and practice management system you already run, analyse your remittance history to identify preventable denial patterns, and build payer-specific edits into your existing scrubber rather than introducing new software. The quarterly review that converts new denial patterns into rules is part of the ongoing engagement.