The instinct when RAF falls is to hire. More coders, more reviewers, more vendors. It rarely works, because the bottleneck is not the number of people. It is how those people spend their day. A coder who spends three hours chasing a diagnosis across a suspect list, an EHR, a reject report, and a payer portal is not producing more RAF than one who spends thirty minutes on the same diagnosis with the data already assembled. The difference is the rote work, and rote work is the thing you can remove without hiring.

This post is about the levers that actually move RAF under V28. It assumes the V28 mechanics are familiar; if they are not, start with the V28 readiness playbook and come back.

Brief V28 context

V28, the 2024 CMS-HCC model, finishes its three-year phase-in in payment year 2026. It expanded the model from 86 condition categories to 115, shrank the ICD-10-to-HCC crosswalk from roughly 9,797 codes to about 7,770, and reduced coefficients on common categories like diabetes without complications and vascular disease. CMS's Office of the Actuary projected an average MA risk score impact of roughly -3.12% from the model change in the 2024 Rate Announcement (cms.gov). The full mechanics are in the readiness guide; the point here is that the model compressed RAF for most plans, and recovering it is an operations problem.

The levers that move RAF without headcount

Six levers do the work. None of them require a larger team. All of them require taking rote tasks off your coders' plates.

1. Accurate suspecting and chronic-condition recapture

Chronic conditions have to be re-documented every calendar year to count toward RAF. A member with documented CKD Stage 3 in 2024 contributes nothing in 2026 unless the condition is confirmed and coded again this year. Accurate suspecting reads the full record, prior claims, labs, pharmacy fills, unstructured notes, and produces a specific, evidence-backed list of conditions to recapture per member. The accuracy matters: a noisy suspect list trains clinicians to ignore it.

2. Pre-claim flagging at the point of care

The highest-yield moment is when the patient is in the room. Surfacing the specific condition that needs documentation, with the clinical criteria required, before or during the encounter means recapture happens contemporaneously. Generic prompts ("review chronic conditions") do not move RAF. Specific prompts ("Confirm CKD staging today, documented Stage 3a in 2024") do. This is the same point-of-care motion covered in the prospective vs. retrospective comparison, and it is the single biggest lever.

3. Correct constrained-group trumping

This is where teams waste effort. V28 places several related conditions into constrained groups that share one coefficient, so only the highest-weighted condition in a group counts. Documenting more conditions inside the same constrained group does not raise RAF. A coder who captures three codes in one constrained group has produced the same RAF as one who captured the single top code, at three times the effort. Correct trumping, applied automatically, redirects that effort toward conditions that add a distinct, payable HCC.

4. Documentation that survives RADV

A captured HCC that cannot be defended is a future clawback, not RAF. Each captured condition needs a retrievable evidence packet: the source note, supporting labs or imaging, and the coder review. Building this as a system requirement rather than a manual scramble keeps captured RAF from evaporating in audit. The full pattern is in the RADV-defensible HCC guide.

5. Prioritize by days-to-submission-window, not RAF size alone

The common mistake is to sort the worklist by RAF value and work the biggest conditions first. But a high-RAF condition with six months of runway is less urgent than a moderate one whose submission window closes in two weeks. Prioritizing by days-to-window protects RAF that would otherwise be lost to a missed deadline. A "days remaining" view per member, per diagnosis, beats a "biggest first" sort every time.

6. Close the loop with providers

Suspecting and flagging are useless if the provider never acts. Closing the loop means the deficiency goes back to the right provider with the right context, and someone confirms whether the documentation landed. When this is manual, it slips. When the system books the visit, routes the gap, and tracks the response, recapture rates hold.

What this looks like in numbers

These are the outcomes Pelica's single canonical record has produced when the rote work comes off the team.

+0.4 RAF
Lifted in two quarters across Pelica deployments, with no new headcount
~10 hrs
Saved per user per week by removing cross-portal chasing
3x
Outreach capacity per coordinator after automating the loop-closing

The roughly +0.4 RAF lift came without hiring. The coordinator's time moved from chasing tabs to judgment work, and the same team produced more confirmed, defensible captures.

Why hiring is the false economy

Consider the math of adding a coder. A new hire spends weeks ramping, then settles into the same workflow as everyone else: pull the suspect list from one system, cross-check the reject report in a second, verify trumping in a third, find the supporting lab in the EHR, and log the submission in the payer portal. Most of that day is assembly, not coding. You have added capacity to do the rote work faster, not to produce more RAF per dollar.

The problem compounds under V28. With a tighter crosswalk and more constrained groups, the assembly step is harder than it was under V24. A diagnosis that mapped cleanly two years ago may now sit inside a constrained group, or no longer map at all. A coder working by hand has to check each of these conditions one at a time. Hiring scales that manual checking; it does not eliminate it. Every new coder inherits the same fragmented stack and the same hours lost to stitching data together.

There is also a quality cost. When the team is buried in assembly, the judgment work, deciding whether a note actually supports a diagnosis, gets rushed. Rushed judgment is what produces the captures that fail RADV. So the hire that was supposed to protect RAF can quietly increase audit exposure. The way out is not more hands on the same broken workflow. It is a workflow that does the assembly for you.

Questions to ask your tooling

If the goal is to move RAF without growing the team, the tooling has to do the assembly. As you evaluate, the questions that separate a real RAF lever from a dashboard are:

If the honest answer to most of these is "no, but it shows me a report," the tool is adding to the assembly burden, not removing it. The team will still be doing the rote work by hand, and RAF will keep tracking headcount instead of judgment.

The thesis: stop doing rote work

Strip the six levers down and they share one idea. A coordinator's time should go to judgment, not to assembly. Judgment is deciding whether a clinical note supports a diagnosis, whether a member needs a call, whether documentation will hold in audit. Assembly is everything else: pulling the suspect list, cross-referencing the reject report, checking the trumping, finding the supporting lab, logging the submission status. Assembly is what eats the day, and assembly is exactly what software should do.

"Adding coders scales the assembly work along with the judgment work. Removing the assembly work scales the judgment alone. Only one of those moves RAF per dollar."

This is why the answer to "how do I improve RAF under V28" is rarely "hire." A team running off a dozen portals can double its judgment output without adding a single person, simply by not spending its hours stitching data together by hand. That is the work Pelica's Risk Adjustment Copilot removes: it suspects, flags pre-claim at the point of care, applies V28 trumping in real time, builds the evidence packet, and tracks every diagnosis through submission, so the coders you have spend their time where it counts.

Sources and further reading