Risk Adjustment
Reading your own charts like an auditor
Mike Garrett, CPC, CRC · September 2, 2026
There are two occasions on which an organization finds out how well its documentation supports its coding. One is a Risk Adjustment Data Validation audit, where CMS selects the sample, sets the timeline, and extrapolates the findings. The other is a self-audit, where you choose all three.
They examine the same thing. Only one of them lets you fix what you find.
What an auditor actually does with a chart
The mechanics are unglamorous. For each sampled diagnosis, the reviewer asks a short series of questions, in order, and stops at the first “no”:
- Is there a face-to-face encounter in the payment year, with an acceptable provider type, behind this diagnosis?
- Does the encounter documentation support the condition — is it monitored, evaluated, assessed, or treated in the note, not merely listed?
- Does the documentation support this specific code — the stated complication, the stated stage, the causal linkage the code asserts?
- Is the record itself valid — signed, credentialed, attributable to the right patient and date?
Notice what’s absent: any interest in whether the condition is plausible, whether the patient “clearly has it,” or whether it appeared in prior years. The chart in front of the reviewer either supports the code or it doesn’t.
Running the same play on yourself
A useful self-audit imitates that indifference. The temptation, when reviewing your own charts, is to read charitably — to fill gaps from context, to know things the note doesn’t say. An auditor won’t, so the review shouldn’t.
In practice that means an independent reviewer — internal audit staff outside the coding chain, or an outside firm — applying the same pass/fail questions to a defined sample. Not a huge one. A few hundred charts, sampled sensibly across providers and condition categories, will surface the patterns: which providers’ notes consistently show their work and which lean on the problem list, which condition categories keep failing on specificity, where “history of” language is quietly contradicting the codes submitted.
Patterns are the real product. A single unsupported code is a correction; the same failure across one provider’s charts is an education plan; the same failure across the organization is a process problem — and each has a different fix.
What you do with the findings
This is where self-audits earn their keep, and where they demand some nerve. Codes the documentation doesn’t support should be corrected through the appropriate channels — and yes, that includes deleting submitted diagnoses that can’t stand. An organization that only acts on findings in one direction doesn’t have an audit program; it has a liability generator, and regulators read them exactly that way.
Done honestly, the payoff compounds. Providers get feedback while the pattern is still small. Coders get clarity on where the documentation standard actually sits. And the organization gets the thing no vendor can sell it directly: a record that holds up because it was tested before anyone else tested it.
The best time to read your charts like an auditor is before an auditor does. There is no second-best time — just shorter notice.