Most health plans obsess over coding accuracy rates. We hit 96% accuracy! Our coders are certified! We use the latest coding guidelines!
That’s great. But here’s what nobody wants to hear: accuracy doesn’t matter if you can’t prove it when CMS comes knocking.
Defensible risk adjustment means you can show your work. Every HCC you submitted has a clear evidence trail linking it back to specific clinical documentation that meets CMS requirements. Not just that the code was correct, but that you can demonstrate why it was correct, using the exact documentation that supported it.
The difference becomes painfully obvious during a RADV audit. CMS doesn’t care about your internal accuracy metrics. They want to see the medical record. They want to find the MEAT criteria. They want documentation that explicitly supports every diagnosis code you submitted. If you can’t produce it, the HCC gets deleted. And if enough HCCs get deleted.
What Makes Risk Adjustment Defensible
Start with the evidence trail. When your coder reviews a chart and assigns an HCC, what happens to the supporting documentation? Does your system capture exactly which clinical evidence justified that code? Can you retrieve it three years later when the audit notice arrives?
Most organizations have a defensibility problem they don’t know about. Their coders are making good decisions based on the documentation they see. But the connection between the code and the evidence isn’t preserved. When audit time comes, they’re sending coders back into old charts hoping they can recreate the logic. That’s not defensible. That’s archaeology.
Good systems capture the evidence automatically. When a coder validates an HCC for diabetes, the platform should link that code to the specific A1C value, the medication adjustment, and the patient education documented in the note. That connection stays intact for as long as you need it.
The MEAT Criteria Documentation Standard
Here’s where defensibility lives or dies. CMS requires that every chronic condition be monitored, evaluated, assessed, or treated during the encounter. The documentation must explicitly show at least one of these elements. “Patient has diabetes” listed on the problem list doesn’t cut it.
Your defensibility depends on whether your coding process enforces this standard. Do your coders know what qualifies as MEAT evidence? Are they trained to reject codes when MEAT criteria is missing, even if they know the patient has the condition? Do you have a QA process that validates MEAT compliance before submission?
I’ve seen too many organizations where coders are pressured to “find” HCCs regardless of documentation quality. The revenue pressure is real. But coding conditions without adequate MEAT criteria isn’t capturing legitimate revenue. It’s building a portfolio of audit liabilities.
The Provider Query Gap
When documentation is unclear or incomplete, you have two choices: don’t code it, or query the provider for clarification. Most organizations don’t query enough. Queries slow things down, providers sometimes ignore them, and it’s easier to just make a judgment call and move on.
But skipping queries destroys defensibility. If a provider’s note mentions CHF without documenting symptoms, exam findings, or treatment changes, you can’t assume MEAT criteria was met. You need to ask. And if the provider can’t or won’t clarify, you can’t code it defensibly.
The organizations that survive RADV audits intact are the ones with robust query processes. They have clear triggers for when queries are required. They track query response rates. They escalate non-responsive providers. It’s not glamorous work, but it’s the foundation of defensibility.
Audit Simulation Before Submission
Here’s a practice that separates the prepared from the panicked: audit your own charts before CMS does. Take a random sample of your coded encounters and review them using CMS audit criteria. Pretend you’re the auditor. Can you find the MEAT criteria? Is the documentation legible, dated, and signed? Does the evidence actually support the HCC?
When you find problems (and you will), you’ve got two options. If the encounter hasn’t been submitted yet, fix it. Query the provider, get better documentation, or remove the unsupported HCC. If it’s already submitted, document the finding and use it to improve your process going forward.
Organizations that run regular internal audits understand their true defensibility before CMS shows up. They know which providers have documentation problems. They know which HCC categories are most vulnerable. They can make strategic decisions about whether to voluntarily correct issues or accept the audit risk.
The Cost of Indefensible Coding
Let’s talk numbers. A typical RADV audit samples 201 patient records. If CMS finds that 15% of your HCCs lack adequate support, they don’t just delete those codes from the sample. They extrapolate that error rate across your entire contract. That 15% error rate can turn into tens of millions in repayment.
And that assumes a 15% error rate. I’ve seen audits where organizations thought they were doing fine and ended up with 30-40% deletion rates because their documentation didn’t meet CMS standards. The financial impact can threaten the viability of the entire Medicare Advantage contract.
Defensible risk adjustment isn’t about being perfect. It’s about being honest. Code what the documentation supports. Build systems that preserve evidence trails. Query when documentation is unclear. Run your own audits to understand your vulnerabilities.
When CMS shows up, you should be confident that every HCC you submitted can withstand scrutiny. That’s what defensible means. Anything less is just hoping you don’t get caught.
