Your retrospective risk adjustment program reviews thousands of charts annually. Your coders identify HCCs. The codes get submitted. Everyone assumes the quality is good because you have a QA process.
Then a RADV audit reveals a 12% error rate. CMS questions dozens of HCCs that your QA process approved. You’re facing potential recoupment of millions.
How did codes that passed your QA end up failing a CMS audit? The problem is that most retrospective QA processes are broken in ways that aren’t obvious until audit time.
The Sample Size Problem
Most retrospective risk adjustment programs QA 5-10% of coded charts. That sounds reasonable. You can’t review everything, so you sample.
But 5-10% sampling only catches high-frequency errors. If one coder consistently makes a specific mistake, the sample will eventually catch it. If five different coders each make unique errors occasionally, your 5-10% sample misses most of them.
Do the math. If you code 10,000 charts annually and QA 10%, you’re reviewing 1,000 charts. If each of your ten coders makes errors on 3% of their charts in different ways, you’ve got 300 charts with errors but you’re only reviewing 1,000 total charts. You’ll catch some errors, but you’ll miss most.
The organizations that perform well in RADV audits QA 20-30% of charts. That’s expensive, but it’s cheaper than recoupment.
The Randomization Problem
Many retrospective programs don’t truly randomize their QA sample. They “randomly” select charts, but with unconscious bias toward charts that look straightforward. Complex charts that take longer to QA get skipped. Problem coders get more scrutiny while high-performers get less.
This creates systematic blind spots. Your QA is catching errors in the charts you’re reviewing but missing errors in the charts you’re not selecting.
True randomization requires discipline. Use actual random sampling tools. Don’t let QA reviewers cherry-pick charts based on convenience or gut feel.
The Timing Problem
Most retrospective QA happens in batches. Coders finish a month of chart reviews. QA reviews those charts a few weeks later. Errors are identified. Feedback goes to coders.
By the time coders get feedback, they’ve already coded hundreds more charts using the same flawed approach. Those errors are baked in.
Better approach: real-time QA. As coders complete charts, a portion goes immediately to QA. Coders get feedback within 48 hours while the work is still fresh in their mind. Errors get corrected before they become systematic patterns.
This requires more QA resources because you can’t batch the work efficiently. But it prevents error multiplication.
The Independence Problem
Some retrospective risk adjustment programs have coders QA each other’s work. Coder A reviews Coder B’s charts. Coder B reviews Coder A’s charts. This seems like good cross-training.
It’s terrible QA. Coders have relationships with each other. They don’t want to report their colleagues’ errors. They apply inconsistent standards based on who they’re reviewing. They often make the same coding mistakes, so they don’t catch each other’s errors.
Effective QA requires independence. QA reviewers should not be the same people doing production coding. They should have different incentives and different accountability.
The Feedback Loop Problem
When QA identifies errors in retrospective coding, what happens? In most programs, the error gets corrected and the coder gets informal feedback. Maybe there’s a note in their file. But there’s no systematic process to determine if the error was one-off or systematic.
If Coder A makes a MEAT criteria error on one CHF chart, is that a fluke or does Coder A consistently under-document CHF? Your QA process found one error. Are there fifty more like it that you didn’t catch?
Good QA programs trigger targeted re-review when errors are found. If Coder A made a CHF error, pull every CHF chart Coder A coded in the last 90 days and review them all. If it’s a pattern, you’ve caught it early. If it’s a one-off, you’ve confirmed that.
The Documentation Problem
When QA identifies an error, most programs fix it and move on. They don’t document the error in a way that’s useful for audit defense.
Three years later during a RADV audit, CMS questions an HCC. You need to show what QA process was in place when that chart was coded. You need to prove the code was properly reviewed.
You can’t. Your QA documentation is informal notes and email threads. You know QA happened, but you can’t produce audit-quality evidence of what your QA process found and how errors were addressed.
QA should generate formal audit trails. Every chart reviewed, every error found, every correction made, every feedback session conducted. That documentation protects you during audits.
The Consistency Problem
If you have multiple QA reviewers doing retrospective QA, are they applying consistent standards? Or is QA Reviewer A more lenient than QA Reviewer B?
Inconsistent QA is worse than no QA. It creates false confidence. You think your charts are being properly reviewed, but the quality depends on which QA reviewer happened to get that chart.
Regular QA calibration sessions are essential. All QA reviewers review the same set of charts independently. Compare results. Discuss discrepancies. Align on standards. Do this monthly.
What Actually Works
Effective retrospective risk adjustment QA requires several elements working together.
Higher sample rates than you want to pay for (20-30% minimum). True random sampling without cherry-picking. Real-time feedback instead of batched review. Independent QA reviewers, not peer review. Systematic error pattern detection. Formal audit trail documentation. Regular QA calibration.
This is expensive. It requires dedicated QA staff, not coders doing QA part-time. It slows down your production coding. It feels like overhead.
Until you get a RADV audit with a high error rate and face millions in recoupment. Then you wish you’d invested in proper QA.
Most retrospective programs underfund QA because the cost is visible and the benefit is invisible. You never see the RADV audit disaster you prevented. But that invisible benefit is worth more than you’re saving by cutting QA corners.
