The CY 2027 Rate Announcement is final. Here is the operational translation most coverage has skipped.
Nearly 58% of MA contracts submitted unlinked CRRs in 2022. For many of those plans, chart-only diagnosis capture was not a workaround — it was the architecture. The CY 2027 Rate Announcement, finalized April 6, 2026, removes that architecture from the risk score calculation entirely. Diagnoses from unlinked Chart Review Records will not count toward risk scores starting in CY 2027.
The coverage has focused almost entirely on the financial impact: $7.12 billion in projected MA payment reductions, stock movements, industry comment letters. What has not been addressed with equal precision is the operational question underneath all of that — specifically, which workflows inside a retrospective program break under this rule, which ones do not, and what the distinction means for how plans should actually respond. Those are different problems. Conflating them is how plans end up rebuilding the wrong thing.
The rule is final. The window to redesign is now.
The Mechanism, Without the Regulatory Wrapper
CMS defines an unlinked CRR as a chart review record that introduces a diagnosis into the encounter data system without reference to a specific beneficiary encounter — no internal control number, no underlying EDR, no service record to anchor it. The diagnosis appears in CMS’s data. The clinical event that generated the documentation does not.
Plans may still submit unlinked CRRs. CMS was explicit about that. But those submissions will not factor into risk score calculation. The sole exception covers members switching from one MA organization to another.
What this means at the workflow level: every diagnosis a retrospective review surfaces must be traceable to an encounter data record already in the system. The chart can confirm a condition. The encounter has to establish it. That is the operational line CMS drew, and it is a meaningful structural constraint for programs where the chart was the primary evidence source rather than a validation layer on top of encounter data.
Where the Retrospective Capture Value Still Lives
Run this diagnostic against your current program. Of the diagnoses your retrospective review produced in the last submission cycle, how many were submitted as unlinked CRRs with no corresponding EDR in the system? In 2023, plans submitted 88.8 million unlinked chart review diagnoses, and 85% could not be matched to encounters. For programs with significant chart-only capture, that percentage describes the direct revenue exposure under the 2027 rule.
The defensible retrospective capture that survives sits in two specific places.
- Encounter-present, code-absent findings. The encounter is in the system. The condition was documented at that encounter. The code was never submitted. Retrospective review identifies it, links the CRR to the existing EDR, and submits it as a linked record. This is encounter-anchored and fully valid.
- Coding accuracy corrections on submitted encounters. The encounter was coded, but the code is wrong, incomplete, or at an insufficiently specific HCC. Retrospective review identifies the correct code from the chart, links the correction to the original EDR, and submits the update. This is linked and valid.
Both of these survive the 2027 rule. The capture they produce is real, defensible, and directly linkable to an EDR. What does not survive is the retrospective program as a mechanism for introducing diagnoses that exist only because a coder found them in a chart months after the service year closed.
The Verification Layer No One Is Talking About
Here is where programs built by people who have run retrospective operations for years will immediately recognize the problem.
When a coder identifies a diagnosis through chart review, the program now needs to answer one question before that code goes anywhere near a submission file: is there an EDR in the system that this diagnosis can be linked to?
That sounds simple. It is not.
In most retrospective programs, coding operations and encounter data management do not sit in the same environment. Coders work against chase lists and chart images. Encounter data lives in a separate system, often managed by a different team, submitted through a different workflow. The verification step — cross-referencing a coded diagnosis against the EDR universe for that member and that date of service — requires a data join that is manual in most programs and error-prone in all of them when done at scale.
What breaks in practice:
A coder identifies a legitimate, documentarily supported diagnosis. The coder accepts it. The QA auditor confirms it. The code goes into the submission file. Nobody checked whether an EDR exists for that encounter because the check was never built into the workflow. The submission goes out as an unlinked CRR. It generates no payment.
And it creates a record in CMS’s data showing that the plan identified a condition through chart review with no corresponding clinical service.
That last point is the one experienced RA operators will not sleep through. An unlinked CRR submission is not neutral in an audit context. It does not simply fail to generate revenue — it documents, in CMS’s own system, that the plan identified a condition through a chart review that could not be tied to a clinical encounter. In a RADV audit, that is not a footnote. That is a question.
Submitting an unlinked CRR does not just fail to generate payment. It creates a record that CMS and OIG can use to ask why the condition appeared in a chart review but not in any clinical encounter.
The ambiguous linkage cases are where the real risk lives. Scenarios where linkage may fail include encounters filed under a different NPI than the rendering provider named on the chart, date-of-service discrepancies between the claim and the record, EDRs submitted after coding was already completed, and telehealth visits where the billing entity differs from the rendering provider. In each of these scenarios, automated matching may not catch the gap, and an unlinked submission can result.
These cases require an analyst who understands both the coding decision and the encounter data infrastructure well enough to resolve the linkage question before submission. OIG audit findings have consistently surfaced diagnosis patterns with no underlying encounter as a primary driver of RADV repayment liability. The pre-submission verification layer is not a back-office quality step. It is the mechanism that determines whether a plan’s retrospective program is defensible or not under the 2027 standard.
An AI-flagged unlinked diagnosis that routes to automated acceptance without analyst review of the encounter linkage is audit exposure wearing the appearance of a submission-ready code.
What Changes Now, and What Does Not
The structure of a well-run retrospective program does not change. Chart retrieval quality still determines what coders see. Coding accuracy still determines what goes to QA. Pre-submission QA still determines what gets submitted. The sequence is unchanged.
What changes is a new validation gate between coding output and submission file generation: every retrospective diagnosis requires a confirmed encounter anchor, reviewed by someone who can resolve the ambiguous linkage cases that automated matching may not catch, before it enters the EDS.
Plans that build that gate correctly will preserve the retrospective capture their programs can still legitimately deliver while eliminating the submission exposure the 2027 rule creates. Plans that retrofit it with automated matching alone will clear the easy cases and submit the problematic ones — which are exactly the ones that surface in audits.
The 2027 rule ended one version of retrospective review. The version where the chart was a standalone evidence source, and the retrospective CRR was how a condition entered CMS’s data for the first time, is gone.
The version where retrospective review finds what was documented but not coded, at encounters that already exist in the system, verifies the linkage before submission, and produces a defensible, encounter-anchored code — that version is still the job.
If you are evaluating how this rule affects your retrospective program, Annova works with MA plans on medical record retrieval and risk adjustment coding designed around encounter-anchored workflows. Learn more about our approach.
