The Audit Simulation Gap: Why Most HCC Coding Systems Catch Problems After It’s Too Late

Catching Problems After Submission Is Already Too Late

Most coding technology in the Medicare Advantage market works in one direction: forward. The system identifies potential HCC codes, the coder reviews them, and the codes get submitted to CMS. If the documentation behind a code is weak, that weakness doesn’t surface until an audit, sometimes years later, when the plan has to produce evidence it may not have or explain decisions nobody documented.

The gap isn’t in code identification. Systems are reliable at finding diagnosis mentions in clinical notes. The gap is in pre-submission defensibility testing. Before a code reaches CMS, somebody should be asking: if this specific diagnosis is sampled in a RADV audit, will the documentation hold up? If the answer is no, or if nobody is asking the question, the plan is submitting liabilities disguised as revenue.

CMS now audits all 550+ MA contracts annually. Sample sizes range from 35 to 200 enrollees per contract. The probability that any given code gets scrutinized has increased dramatically. The OIG’s March 2026 audits found error rates between 81% and 91% across three plans. Those errors were discoverable before submission. The technology just wasn’t designed to look.

What Audit Simulation Does

Audit simulation runs every chart through a mock RADV review before the code is finalized. The system evaluates each diagnosis against the same criteria CMS auditors apply: Is the condition documented in a face-to-face encounter note? Does the documentation show active management through MEAT criteria (Monitoring, Evaluation, Assessment, Treatment)? Is the diagnosis current, or is it a historical mention carried forward without recent clinical support?

Each diagnosis receives a defensibility score. Codes with strong evidence and clear MEAT documentation score high. Codes with thin evidence, ambiguous language, or missing management documentation score low. The coder and the quality team see these scores before submission and can make informed decisions: submit the strong codes, remediate the weak ones, and remove the indefensible ones.

The system also identifies patterns across the plan’s full submission set. Are certain diagnosis categories consistently scoring low? Are specific providers generating documentation that fails the defensibility test at higher rates? Are there HCC categories where the plan’s error rate would likely exceed audit thresholds? These population-level analytics turn individual chart reviews into strategic intelligence.

The Economics of Pre-Submission Detection

Fixing a documentation problem before submission costs virtually nothing. A provider query, a chart amendment, or a code removal is routine operational work. Fixing the same problem after a RADV finding costs orders of magnitude more: recoupment demands, appeals processes, legal fees, remediation programs, and reputational damage that affects future regulatory interactions.

The OIG’s BCBS Alabama audit estimated $7.06 million in overpayments from 271 sampled enrollee-years across just two payment years. Every one of those unsupported codes passed through a coding process that didn’t test defensibility before submission. An audit simulation layer running against those same charts would have flagged the majority of them for remediation. The cost of the simulation tool is a rounding error compared to the cost of the finding.

Plans running concurrent audits face this math on a continuous basis. Every quarter brings new audit exposure. Every submission cycle adds codes that either strengthen or weaken the plan’s defensibility position. Without pre-submission testing, the plan is accumulating risk with every chart it processes.

The Minimum Standard

Any HCC Coding Software deployed today should include pre-submission audit simulation as a core capability, not an optional module or a premium feature. Defensibility scoring, MEAT validation, population-level pattern analysis, and proactive identification of weak documentation should happen before the code reaches CMS. Systems that submit first and discover problems later were built for an enforcement environment where audits were rare. That environment is gone, and the technology needs to reflect the one that replaced it.