Prepay vs. postpay FWA detection: where each rule belongs

This guide gives a practical way to decide, rule by rule.

What makes a review "prepay" or "postpay"

CMS draws the line by when the determination is made, not by which tool makes it. The Medicare Program Integrity Manual says: "Prepayment review occurs when a reviewer makes a claim determination before claim payment has been made. Prepayment review always results in an 'initial determination'." Postpayment review "results in either no change to the initial determination or a 'revised determination' indicating that an overpayment or underpayment has occurred" (CMS Medicare Program Integrity Manual, ch. 3, §3.2).

The same chapter describes medical review edits as system logic that "either automatically pays all or part of a claim, automatically denies all or part of a claim, or suspends all or part of a claim" so a trained clinician or claims analyst can review it. It also sets a principle worth adopting even if you are not a Medicare contractor: reviewers "shall not deny a payment for a service simply because the claim fails a single screening tool criterion. Instead, the reviewer shall make an individual determination on each claim."

That gives you a working model. Before payment, a rule can pay, deny, or suspend for review. After payment, a rule can only open a question that may end in a revised determination and an overpayment. In both stages, a screen is a reason to look, not a decision.

What each stage is good at

Prepay is good at rules that are deterministic and need only data available at adjudication. Typical examples:

• Code-pair and unit limits. CMS's NCCI procedure-to-procedure edits "prevent improper payment when incorrect code combinations are reported," and Medically Unlikely Edits "prevent improper payments when services are reported with incorrect units of service" (CMS NCCI).
• Exact and near-exact duplicates against claims already in history.
• Missing or inconsistent modifiers, such as an E&M billed with a procedure but without modifier 25 or 57.
• Targeted review of specific providers already known to have a high error rate.

Postpay is good at rules that need paid amounts, a time window, or comparison with peers. Typical examples:

• Utilization patterns over months: frequency outliers, visit counts per member, units trending up after a fee schedule change.
• Peer comparison by specialty and region, where one claim tells you nothing and the provider's distribution tells you a lot.
• Network behavior: shared members across providers, referral concentration, coordinated billing between provider pairs.
• Audits that need medical records, a sample, and extrapolation to the provider's claim universe.

The pattern is simple. If the evidence is inside the claim and the history you already hold, prepay can act on it. If the evidence only shows up in aggregate, over time, or across providers, it is a postpay signal, at least until it has identified a specific provider you can target.

Five questions that decide where a rule belongs

Run each candidate rule through these five questions. You can score them in a spreadsheet; the discussion matters more than the score.

1. Are all inputs present before payment?

If the rule needs the allowed amount, the paid date, or claims that haven't arrived yet, it can't run prepay as written. Sometimes a simpler proxy can, for example a units threshold instead of a units trend.

2. How precise is it?

A prepay rule with a low hit rate costs you twice: reviewer time on clean claims and provider abrasion. Before moving a rule upstream, measure its precision on historical claims. That means the share of flags that reviewers actually upheld, not the share that looked suspicious.

3. What does delay cost?

Pending a claim has a cost: prompt-pay obligations, provider relations, and member access when the provider is a pharmacy or DME supplier. High-volume, low-dollar services with low error rates rarely justify a pend. High-dollar, high-error categories often do.

4. What happens if the rule is wrong?

A wrong postpay flag costs an analyst's time and maybe a records request. A wrong prepay denial leads to an appeal, rework, and possibly a complaint. The less certain the rule, the more it should recommend review than deny.

5. Is it about a claim, or about a provider?

Claim-level logic (code pairs, units, duplicates) travels well to prepay. Provider-level suspicion usually starts postpay and moves upstream as targeted prepay review of that provider once the evidence supports it. CMS takes the same line with its contractors: MACs "shall initiate a targeted provider-specific prepayment review only when there is the likelihood of sustained or high level of payment error" (PIM ch. 3, §3.2.1).

Moving rules between stages

The best rule libraries treat stage as a property of a rule, not as the system the rule lives in. That makes three moves routine.

Promote a postpay alert to prepay. A postpay rule has run for a few cycles, reviewers uphold most of what it finds, and its inputs exist before payment. Promote it to prepay as a "review" recommendation first, not "deny." Watch the uphold rate and pend time before tightening.

Put a provider on targeted prepay review. A postpay investigation confirms a pattern for one provider. Instead of waiting for the next audit, target that provider's new claims for prepay review, with written entry criteria, a review period, and exit criteria. Record why the provider was targeted. You will be asked.

Demote a noisy prepay edit. If a prepay edit flags many claims that reviewers release, move it to postpay monitoring, where it can still feed trend analysis without pending clean claims.

Each move should go through a dry run on recent history, so you can see what would have been flagged before it affects live claims.

Measuring each stage

Track the two stages separately. They fail in different ways.

The most important number is the one connecting the stages: how many postpay alerts each quarter come from patterns a prepay rule could have caught. If that number rises, your prepay library is behind.

The regulatory hooks

Both Medicare Advantage and Medicaid managed care rules expect plans to prevent problems, not only find them.

• Medicare Advantage. The compliance program must include "measures that prevent, detect, and correct fraud, waste, and abuse," routine monitoring and auditing, and, when potential misconduct is found, a timely, reasonable inquiry and corrective action that can include repaying overpayments (42 CFR 422.503(b)(4)(vi)).
• Medicaid managed care. MCOs, PIHPs, and PAHPs must have FWA arrangements, verify by sampling or other methods that billed services were received, report all overpayments identified or recovered to the state within 30 calendar days, promptly refer potential fraud, and suspend payments to a network provider when the state determines there is a credible allegation of fraud under §455.23 (42 CFR 438.608).
• Medicaid NCCI. States must apply Medicaid NCCI to fee-for-service claims. CMS calls applying it to fee-for-service claims processed by MCOs or limited benefit plans "desirable but optional," and Medicaid NCCI differs from Medicare's, including DME edits and MUEs applied per claim line (CMS NCCI for Medicaid). If you run both lines of business, don't assume one edit set serves both.

Prepay screens are the "prevent." Postpay detection, review, and recovery are the "detect and correct." Auditors want to see both, and the trail between them.

When a postpay audit has to project an overpayment, the methodology matters as much as the findings. CMS's Program Integrity Manual chapter 8 covers statistical sampling for overpayment estimation (PIM ch. 8), and HHS-OIG offers its RAT-STATS software for free (OIG RAT-STATS).

How AEGIS Detect handles both stages

We built AEGIS Detect around the idea above: one governed rule library, where each rule's payment stage is set to prepay, postpay, or both.

• Prepay: rules evaluate pending claims against the member's claim history and current reference data, and recommend deny, suspend, review, or flag. A claim that can't be fully checked is suspended rather than passed. Reviewers release, suspend, or deny with a required reason; Detect does not deny claims automatically, and finalized decisions are exported for handoff to your claims system.
• Targeting: put specific providers, members, or models on prepay review, with changes to the flag list audited and versioned.
• Postpay: runs score paid and adjusted claims 0 to 100. A dry run shows what would be flagged before alerts go live, and an alert becomes a Case Management lead in one step.
• Library: 100+ base rules across DRG, utilization, high dollar, unbundling, duplicates, coding abuse, and upcoding, on CMS NCCI, MUE, and MS-DRG reference data. Rules Studio adds test scenarios, synthetic history, and replays before promotion.
• Downstream: Medical Review for clinical and coding decisions, SVRS for reproducible sampling and extrapolation, and Insights for the metrics above.

See it on your rules

Bring three of your current edits: one prepay rule you trust, one you suspect is noisy, and one postpay pattern you wish you caught earlier. We'll walk them through Detect in a demo.

Request a demo or email sales@aegisisd.com.

Related: Payment integrity for health plans · AEGIS Detect · All resources