2027 Medicare Advantage Risk Adjustment: Final Policy Checklist

The first task in preparing for 2027 risk adjustment is to distinguish the final CMS policy from the earlier proposal. An implementation plan based on the Advance Notice alone can target a model that CMS did not finalize.

This article summarizes selected final-policy points and offers an operational checklist for data and coding teams. It does not provide patient-specific coding advice, a complete HCC crosswalk, or a revenue forecast. Use the full CMS announcement and appropriate professional review for implementation decisions.

What the final announcement says

CMS's April 6, 2026 Rate Announcement retains the 2024 Medicare Advantage risk-adjustment model for CY 2027. That model was fully implemented in CY 2026; the proposed replacement calibrated with newer data was not finalized for Part C. Do not describe 2027 as the first year of full implementation of the 2024 model. CMS final 2027 fact sheet.

CMS also finalized exclusion of diagnosis information from unlinked chart review records from risk-score calculation beginning in CY 2027, with an exception for beneficiaries switching between MA organizations. Part D has its own finalized model changes. These distinctions require separate review rather than a single rule applied to every risk-adjustment workflow. CMS announcement summary.

The agency's projected average payment change is not an estimate of your organization's revenue. Local results depend on the actual population, contracts, submitted data, applicable policies, and other payment factors.

Inventory your risk-adjustment workflows

List the payment program, payment year, model version, population, source systems, and responsible business owner for each workflow. Keep Part C, Part D, and other programs separate. Similar diagnosis terminology does not make their models or submission requirements interchangeable.

Record the versions used by analytics, coding support, submission, and reconciliation systems. A dashboard can appear reasonable while using a different mapping or year from the production submission process. Make that mismatch detectable before it reaches a financial decision.

For each version, store the official source location and the date your team retrieved it. Note whether the file is final, preliminary, corrected, or intended only for testing. Preserve historical versions needed to reproduce prior results.

Trace diagnoses to their source

Review how diagnosis information is connected to the relevant encounter and source documentation. Determine which records are ordinary encounter submissions, which are chart-review records, and how linkage is represented. Do not infer a valid link merely because the same beneficiary appears in two systems.

An internal lineage checklist should identify:

• The source document and version used by the reviewer.
• The encounter record and applicable dates.
• The submitting organization and submission path.
• Any correction, deletion, or replacement applied later.
• The reason a record is included or excluded from a particular calculation.
• The owner responsible for resolving missing or conflicting information.

These are proposed control fields, not a replacement for CMS technical submission specifications. Your implementation team must reconcile them with the actual program requirements and authoritative files.

Test the exception instead of assuming it applies

The finalized exception for beneficiaries switching MA organizations should be implemented from the full policy and technical guidance. Avoid a blanket rule that accepts all unlinked records, or one that discards every such record without reviewing the exception.

Develop approved test cases covering records that qualify, records that do not, and records with insufficient information to decide. Record the expected result and its source rationale. Unresolved cases should go to a named reviewer rather than inherit a favorable default.

Do not create or alter encounter history to make an unsupported record appear eligible. If the evidence is absent, retain that limitation and resolve it through the appropriate operational process.

Keep clinical accuracy separate from payment incentives

The purpose of coding review is to represent the documented encounter accurately under the applicable rules. A condition's effect on a risk model is not a reason to invent it, change its severity, or omit clinically relevant documentation.

Have qualified reviewers resolve documentation and coding questions. An AI suggestion should remain distinguishable from the clinician's documentation and the final reviewed coding decision. Record accepted changes and rejected suggestions so a later reviewer can understand the sequence.

Avoid treating a higher modeled score as proof of improved accuracy. Validate the underlying supported diagnoses and data handling first. Payment reconciliation is a separate step with separate evidence.

Run a controlled comparison

Use an approved, appropriately protected dataset to compare the current implementation with the intended 2027 configuration. Keep the input population fixed when isolating configuration effects. If population or utilization also changes, present those effects separately.

Report record counts at each stage: received, linked, excluded, unresolved, and included in the calculation. Make duplicate handling and correction logic explicit. A top-line score difference without record-level reconciliation is difficult to investigate and should not be the sole acceptance criterion.

Document the limitations of any scenario. Do not convert an estimated score change directly into a guaranteed contract payment or imply that a national projection applies uniformly to every plan.

Prepare a release and monitoring packet

Before approving the change, collect the applicable policy sources, version inventory, mapping decisions, test cases, exception queue, and rollback procedure. Assign coding, operations, compliance, and engineering responsibilities explicitly.

After release, sample accepted and excluded records, review unexplained changes, and monitor unresolved exceptions. Recheck when CMS issues clarifications or implementation files change. A one-time review does not establish permanent accuracy.

For related preparation, use the 2027 code-release readiness checklist and the AI coding evidence guide. They address code versions and evaluation methods, not a substitute risk-adjustment model.

Public-reference check: September 6, 2026. This is a bounded summary and original operational checklist, not complete program guidance, a payment guarantee, or a credentialed clinical/legal review.