ScrubCheck: An NCCI Claim Scrubber Running before Submission

Launch Live Demo

Billing staff often identify denials only after submitting a claim and waiting weeks for the rejection to appear on an EOB. ScrubCheck moves that review to the front of the process. Paste a claim’s procedure codes into ScrubCheck, and it runs the same two checks a payer uses before processing payment. It then returns a verdict for each line, along with an explanation for every flag.

ScrubCheck is the companion to SourceFetch. SourceFetch explains what a policy says. ScrubCheck applies that policy to a specific claim.

The code is available on GitHub. The design is described below.

System Design

ScrubCheck runs two deterministic checks against the CMS edit tables. PTP (procedure-to-procedure) edits identify code pairs that are bundled, such as a comprehensive metabolic panel billed alongside the basic panel it already includes. MUE (medically unlikely edits) identify cases where a single code is billed above its daily unit cap. For each finding, ScrubCheck reports the rule behind the decision: the modifier indicator for a bundle or the MAI value for a unit cap overage, which determines whether the overage can be appealed.

Deterministic Logic and Model Phrasing

ScrubCheck was built around one deliberate split. The checks themselves are pure table look-ups with no model involved because whether two codes bundle has a single correct answer. A model that is 98 percent accurate is still wrong on the claims where accuracy matters most. The optional explanation layer is the only part that calls a model. When a key is configured, it rewrites the facts already computed by the engine into a sentence a biller can act on. The prompt prohibits it from adding any code or rule that was not passed in. The model never decides whether two codes bundle. It only explains what the deterministic core has already found.

Modifier Indicators

The most instructive part of this domain is that a bundle is not always a hard stop. A modifier indicator of 0 means the pair can never be unbundled. A modifier indicator of 1 means the pair can be unbundled if the second service was distinct and the appropriate modifier is appended. Encoding that distinction and checking whether the claim already includes a bypass modifier turns a flag into actionable guidance rather than an alert with no context.

Deployment and Hosting

The deterministic core is safe to expose because it relies only on table look-ups. The explanation layer, however, makes paid API calls, which creates an opportunity for abuse. For this reason, ScrubCheck runs locally, and the demo above serves as a substitute for a live deployment. The source code is available on GitHub, and the video shows the application running.