CRC Risk Adjustment Coding study materials
CRC Risk Adjustment Coding study resources

Sixty Charts, Twenty Findings: Sizing the Problem Before RADV Arrives

CRC Risk Adjustment Coding · Put your knowledge to work in context.

All case studies

Sixty Charts, Twenty Findings: Sizing the Problem Before RADV Arrives

A plan audits a 60-member random sample drawn from a Medicare Advantage contract's 2024 payment-year population of 4,800; the contract submits diagnoses from calendar year 2023 for that payment year. Auditors flag 20 charts. In 9, the submitted high-severity HCC has no supporting documentation anywhere in the record. In 5, the documentation supports a code in the same disease family at a lower severity than what was submitted. In 2, the only support is a sentence reading "rule out pulmonary fibrosis" with an HRCT still pending. In 4, the date of service falls in December 2022 or January 2024. The remaining 40 charts are fully supported. Contract leadership wants the exposure quantified, and one of the five susceptibility cases involves a submitted E11.65 where the note reads "type 2 diabetes, no complications, A1c 7.2%."

1. Calculate the chart-level error rate and classify the error types. Which findings are "unsupported diagnosis" versus "unsupported severity," and why does the distinction matter financially?

Read the worked answer

Calculation. 20 flagged charts ÷ 60 sampled = 33.3% chart error rate; 40 ÷ 60 = 66.7% clean.

Error types

  • 9 - unsupported diagnosis. No documentation at all. The HCC is deleted outright; the member's risk score loses that category entirely.
  • 5 - unsupported severity (code substitution). A diagnosis exists but a more severe category was submitted. The severity is corrected downward, not deleted.
  • 2 - unsupported (rule-out). "Rule out" is not a diagnosis in outpatient coding and cannot support risk adjustment. Deleted.
  • 4 - outside the data year. For a 2024 payment year the data year is CY2023, so December 2022 and January 2024 encounters belong to other payment years. Deleted for this year.

Why the distinction matters. Deletion and downgrade have different financial signatures. A deletion removes the whole category; a downgrade removes only the differential between the two categories in that hierarchy - which can be small or, in the diabetes family, can be the entire payment if the lower category is not modelled at all. Grouping all 20 as "unsupported" overstates the dollar impact and misdirects the corrective work. Auditors and actuaries need the split.

Population note. 33.3% is the sample rate. Applying it to 4,800 members is only defensible if the sample is truly random and representative; that estimate is not the same as a CMS RADV finding, which carries its own sampling and extrapolation methodology.

2. For the E11.65 chart - submitted with hyperglycemia, documented as uncomplicated diabetes with A1c 7.2% - state the correct action and explain the payment consequence, including what happens if the coder substitutes E11.9 instead.

Read the worked answer

E11.65 requires documented hyperglycemia. The note documents no complications, no hyperglycemia, and an A1c of 7.2% - which is not evidence of hyperglycemia. The submitted code is unsupported and must be removed.

The tempting replacement, E11.9, is the wrong instinct for three reasons:

  1. Accuracy. E11.9 is the correct code for the documentation, but it must be reached by coding the note, not by reaching for whatever code is nearest the one being deleted.
  2. Model mapping. Under the current V28 model, uncomplicated type 2 diabetes does not map to a payment HCC. Substituting E11.9 therefore yields no additional payment - it simply adds a diagnosis line that will be reviewed again next year.
  3. Audit optics. Deleting a code and immediately inserting a different diabetes code on the same chart, during an audit, looks like a save attempt. The change should be documented as a correction with the reason (unsupported hyperglycemia) and traceable to the reviewer.

Consequence. Removing E11.65 with no valid substitute means the diabetes hierarchy contributes nothing for this member-year. If the member has other qualifying conditions, they are unaffected. Note also that the A1c belongs in the record as data; it simply does not create a diagnosis.

Going forward, this is a provider-education issue: if the provider intends a hyperglycemia diagnosis, it must be stated and acted on in the note.

3. Recommend root-cause analysis and corrective actions, including practices that must be avoided.

Read the worked answer

Root cause - separate the mechanisms. The four error types will not share one cause. The 4 date-of-service errors suggest a data pipeline problem (retrospective chart pulls not filtered to the data year), not a coder problem. The 2 rule-out charts suggest coders coding from impression language. The 9 unsupported diagnoses suggest either suspect-condition coding or a problem-list-driven workflow. The 5 severity errors suggest coders defaulting to the highest documented historical severity rather than the current encounter.

Corrective actions

  • Fix the intake filter first: hard-stop any record with a date of service outside the payment year's data year.
  • Build a pre-submission prospective review for the highest-volume, highest-risk HCC families rather than auditing everything after the fact.
  • Replace "code from the problem list" with "code from the encounter assessment" in policy and in the EHR workflow; make retrieved source records the default remedy.
  • Provider education on rule-out language and on documenting severity and linkage when a complication is present.
  • Trend the error types quarterly by provider, specialty, and coder, and re-audit a fresh sample to confirm the fix.

Must be avoided

  • Retroactive addenda generated after the audit selection, or any alteration of the original note.
  • Deleting a code and substituting a similarly named one without documentation support.
  • Using the internal sample rate as a billing adjustment or as a stand-in for CMS extrapolation methodology.
  • Punitive messaging that drives coders to under-code legitimate conditions; measure both over- and under-capture.