Prospective vs. Retrospective Risk Adjustment: Why You Need Both on One Platform

Ask ten risk adjustment leaders whether they are "prospective" or "retrospective" and you will get a debate. It is the wrong question. The best-performing programs in 2026 are not choosing — they are running both, on one platform, with one shared source of truth. Here is how the two fit together and why splitting them across tools quietly costs you.

Two halves of one program

Prospective risk adjustment works before and during the visit. It prepares the provider: pre-visit summaries, suspected conditions, recapture candidates, and care gaps surfaced on-the-glass so they are addressed while the patient is in the room. Its strength is that documentation is created correctly the first time.

Retrospective risk adjustment works after the encounter. Coders review completed charts to catch what was missed, validate suspected HCCs against the evidence, and prepare clean, defensible submissions. Its strength is rigor and a second expert set of eyes.

Prospective catches conditions at their freshest and cheapest. Retrospective provides the validation and audit discipline. Run only one and you have a hole: prospective-only misses what the provider didn't address; retrospective-only is late, expensive, and dependent on chart chasing.

The hidden cost of two separate tools

Most organizations bolt together a prospective vendor and a retrospective vendor — and pay for it in seams:

• Duplicated suspects. The same condition gets surfaced twice, by two systems that don't talk, wasting provider and coder attention.
• Inconsistent evidence. The rationale a provider saw at the point of care doesn't match what the coder sees later — a problem when an auditor asks why a code was submitted.
• Fragmented analytics. You cannot see the full opportunity lifecycle — presented, addressed in the room, caught in coding, or missed entirely — because the data lives in two places.
• Double the integration and double the security review. Two contracts, two data feeds, two audit surfaces.

One engine, one evidence trail

When prospective and retrospective run on the same engine, the seams disappear. A suspect surfaced before the visit, the provider's action on it, and the coder's later validation are the same record — with the same source evidence attached throughout. That unified trail is what makes the whole program audit-defensible and what lets administrators finally see the complete picture.

On our platform, the on-the-glass sidecar (prospective) and the coder workspace (retrospective) are two surfaces of one system. Add quality and HEDIS on the same foundation and you have a genuinely unified program — not three tools stitched together.

The closed loop

The real prize is the feedback loop. When everything runs in one place, you can see which prospective suggestions providers consistently ignore, which conditions only ever get caught retrospectively, and where documentation education would move the needle. That insight makes next year's prospective program smarter. Two disconnected tools can never close that loop.

Stop framing it as a choice. Run both — on one platform — and let each make the other better.

*Running prospective and retrospective on separate tools? Schedule a live demo and we'll show you both on one platform, with one evidence trail._