Most risk-bearing groups end up running two different motions under one banner. One is forward-looking: surface a suspected condition before a visit so a clinician can confirm it. The other is backward-looking: pull the chart after submission, check that the documentation holds, and find what was missed. Both are legitimate. The trouble starts when each one lives in its own tool, with its own copy of the member, its own model version, and no idea what the other did.
This post defines both, compares them on the dimensions that actually decide what you buy, and explains why a single canonical record beats two stitched-together point solutions. It assumes you already know the V28 mechanics and the RADV-defensible capture patterns; we link rather than repeat them.
What prospective risk adjustment is
Prospective risk adjustment works before or at the encounter. The system reads the available record, claims, prior diagnoses, lab values, pharmacy fills, unstructured notes, and surfaces conditions that are likely present but not yet documented this year. The clinician sees a suspected condition with its supporting evidence and can confirm, document, and code it during the visit.
The point is timing. A chronic condition like CKD or diabetes with complications has to be re-documented each calendar year to count. If you flag it before the visit, recapture happens in the exam room with the patient present. Navina, for example, surfaces newly suspected conditions from claims, health information exchange data, and unstructured EHR content at the point of care, linked back to the clinical evidence (navina.ai). That is the prospective shape: get the diagnosis in front of the right person before the window matters.
Prospective work also reduces downstream volume. Conditions confirmed at the visit do not need to be chased later. The chart review queue shrinks, and the documentation is contemporaneous, which is exactly what an auditor wants to see.
What retrospective risk adjustment is
Retrospective risk adjustment works after the encounter, usually after submission. Coders and abstractors review charts to confirm that submitted diagnoses are supported, find conditions that were documented but never coded, and prepare evidence for a possible RADV audit. This is the high-volume, validation-heavy side of the program.
Reveleer is a clear example here. Its Evidence Validation Engine guides abstractors to member insights mapped to the clinical source documentation, supports CMS and RADV-IVA submissions, and is built to catch unsupported conditions before CMS does (reveleer.com). The strength of retrospective work is completeness and defensibility: it is the safety net that catches what the point of care missed and assembles the paper trail.
The cost of retrospective-only programs is timing and rework. By the time a chart review finds a gap, the visit is over. Recapturing the condition often means another member touch, another appointment, or a deficiency letter to a provider who has already moved on.
Prospective vs. retrospective, side by side
The two approaches differ on five dimensions that matter when you decide what to buy:
| Dimension | Prospective | Retrospective |
|---|---|---|
| Timing | Before or during the encounter, while the patient is reachable. | After the encounter, typically after claim submission. |
| Primary data source | Pre-visit record: prior claims, labs, pharmacy, HIE, unstructured notes. | The completed chart and submitted encounter data. |
| Primary strength | Contemporaneous documentation; recapture at the visit; fewer downstream chases. | Completeness and audit defense; finds documented-but-uncoded conditions; RADV readiness. |
| Primary risk | Suspecting noise; clinician alert fatigue if prompts are generic. | Rework and extra member touches; documentation found too late to fix cleanly. |
| Example vendors | Navina (clinician-first, point-of-care suspecting). | Reveleer (high-volume chart review, Evidence Validation Engine, RADV prep). |
Why splitting these across vendors creates blind spots
The seductive setup is to buy a prospective tool for the clinics and a retrospective tool for the coding shop. On paper they cover the full year. In practice, two problems appear immediately.
Duplicate member touches. The prospective tool flags a member for a suspect HCC and schedules a visit. The retrospective tool, working off an older snapshot, flags the same member for a chart chase. The member now gets two contacts for one condition, and two teams burn time on work that should have happened once.
Model and trumping mismatches. If the prospective vendor prompts on a condition that no longer maps under V28, or the retrospective vendor surfaces a code that is trumped inside a constrained group, the diagnosis gets submitted and then rejected. The two systems disagree about what counts, and the rejection shows up weeks later in an MAO-004 report that neither vendor owns end to end.
No shared evidence trail. When the prospective suspect and the retrospective validation live in different systems, the chain of custody is fragmented. The note that supported the suspect, the coder's review, and the submission status sit in three places. Reassembling that during an audit is manual archaeology.
"Two vendors do not give you two views of one problem. They give you two problems that disagree about the same member."
How one canonical record handles both
The fix is not to pick a side. It is to run prospective suspecting and retrospective validation against the same member record, with one V28-aware trumping engine deciding what actually counts.
Pelica is built this way. One canonical record per member is stitched from claims, EHR, pharmacy, lab, ADT, payer SFTP drops, and call recordings. The Risk Adjustment Copilot suspects conditions and flags them pre-claim at the point of care, and it validates submitted diagnoses against the same record after the fact. Trumping inside constrained groups is applied once, in real time, so the prospective prompt and the retrospective review never disagree about whether a code counts. When a recapture needs a member touch, the action layer makes the call and books the visit rather than handing the task to a separate outreach team.
A physician-led IPA in New York running risk on more than 175,000 patients consolidated its prospective and retrospective work on Pelica. Across Pelica deployments, customers have lifted RAF by roughly +0.4 in two quarters with no new headcount. The lever was not a better suspecting model or a faster coder. It was removing the seam between the two motions.
The submission lifecycle ties both halves together
Whichever way a diagnosis enters, prospective at the visit or retrospective from chart review, it has to survive the same submission pipeline. A single system should track every diagnosis through it:
- 277CA. Claim-level acknowledgment: was the encounter accepted, rejected, or pended after front-end processing.
- MAO-002. Encounter-level acceptance from the Encounter Data Processing System.
- MAO-004. The risk-adjustment filtering result: which diagnoses are allowed or disallowed for payment. A disallowed diagnosis here is an early signal that documentation will not survive RADV.
- MMR. The Monthly Membership Report, where payment effects of accepted encounter data show up.
- MOR. The Model Output Report, listing the HCCs CMS actually recognized for each member.
If prospective and retrospective live in separate vendors, no one owns this lifecycle end to end. A diagnosis suspected at the visit can be disallowed at MAO-004, and the prospective team never learns why. On one record, the rejection routes straight back to the suspect that generated it, and the next encounter prompt is corrected. CMS documents these reports and the encounter data process in its risk adjustment and Encounter Data System guidance (cms.gov).
So what belongs in your stack
Both motions belong. The question to ask a vendor is not "do you do prospective or retrospective." It is: do prospective suspecting and retrospective validation run on the same member record, with one trumping engine, and can you trace a single diagnosis from suspect to MOR in one place. If the answer is no, you are buying two tools that will eventually disagree about the same patient.
Sources and further reading
- CMS-HCC Risk Adjustment: model software, technical documentation, and Encounter Data System reports (277CA, MAO-002, MAO-004, MOR)
- CMS: 2024 Medicare Advantage and Part D Rate Announcement (V28 model, projected -3.12% risk score impact)
- Navina: AI-powered risk adjustment, prospective point-of-care suspecting
- Reveleer: retrospective risk adjustment and the Evidence Validation Engine