What is Retrospective Risk Adjustment? Definition, Formula, and Benchmark

Retrospective risk adjustment is the process of reviewing already-completed clinical documentation — closed encounters, discharge summaries, operative reports, consultation notes — to identify diagnoses that were clinically present but not coded on the original claim. Coders flag conditions that meet MEAT, producing addenda or coder-to-provider queries to support claim corrections or late submissions before the CMS risk-adjustment data submission deadline.

Retrospective review is the longest-established risk-adjustment workflow and remains widely used because it can be applied to any completed encounter regardless of whether the provider performed pre-visit planning. It is especially valuable for capturing conditions documented in specialty consultations or hospital encounters that did not flow back into the primary-care coding process, and for closing coding gaps left by providers unfamiliar with HCC-relevant specificity.

The classic workflow involves a CRC-credentialed coder reviewing patient charts in batches, applying the current year's CMS-HCC or HHS-HCC crosswalk, identifying documented conditions not reflected on claims, and either (a) submitting a corrected claim if within timely-filing windows or (b) submitting the diagnosis directly to the EDPS or EDGE server via an encounter-data submission if the claim timely-filing window has closed. Direct EDPS submission requires careful documentation governance because CMS evaluates these submissions for pattern risk.

Compliance risk is the central governance consideration. Retrospective programs that rely on aggressive coder interpretation of ambiguous documentation, or that pressure providers to sign addenda for conditions the provider did not independently evaluate, have been the subject of multiple DOJ and OIG actions. The UnitedHealth, Kaiser, and various smaller-plan settlements include retrospective chart review allegations among the challenged practices. Well-governed programs enforce strict MEAT criteria, do not code from query-generated addenda unless the query used objective language, and maintain audit trails for every coder decision.

Even when run compliantly, retrospective review produces higher RADV error rates than prospective review. The documentation is not contemporaneous; auditors scrutinize retroactive coding patterns more closely; and conditions flagged by retrospective review are more likely to have marginal MEAT support than conditions captured by a provider at time of service. Industry has therefore shifted toward prospective-primary, retrospective-backup models in which retrospective review focuses on encounters outside the prospective program's reach (hospital discharges, specialty consultations, emergency visits).

Vendor landscape is mature. Most large retrospective programs use a combination of rules-based engines and NLP to flag charts with likely-unreported HCCs, CRC-credentialed coders for validation, and automated query generation to request provider clarification when MEAT is borderline. Internal programs at large ACOs and payers follow the same architecture.