You're not comparing two clinical philosophies — you're comparing two coefficient/crosswalk artifacts that must both run during the blend. Here's the diff that matters in code.
| Concern | V24 | V28 |
|---|---|---|
| HCC IDs | one numbering | renumbered/reorganized — not 1:1 with V24 |
| Payable categories | one set | revised; some V24-payable conditions drop |
| Coefficients | V24 table | re-estimated |
| Status during transition | weighted with V28 | weighted with V24 (blend) |
Implementation implications
- No shared HCC enum. Tag every HCC value with its model version or you will eventually compare V24 #18 to V28 #18 and they are not the same thing.
- Two crosswalks + two coefficient tables, both keyed by payment year. Treat them as versioned data, not config constants.
-
Blend at the RAF layer, not the HCC layer:
blended = w24*RAF_v24 + w28*RAF_v28, weights from the payment-year Rate Announcement. - Golden tests per version. A fixed member set with expected RAF under each model; run on every coefficient-table update.
A side-by-side of the category remap, plus a calculator that outputs the same member under both models, is here: HCC V28 — useful as the reference for those golden tests.
The non-code part
All of this serves one goal: the accurate RAF for the documented patient under the correct payment-year blend. Engineering correctness here isn't pedantry — a silently wrong model version mis-funds real patients at scale. Cross-check your output against the V28 model before trusting it downstream.
Not coding, billing, or clinical advice. Confirm coefficients/weights against the current CMS Rate Announcement.
Written by Chin Ramamoorthi — CEO, VBC Risk Analytics. He has 20+ years across provider- and payer-side healthcare IT, including leading V24-to-V28 transition work on both the payer and provider side.
Reviewed by the VBC Risk Analytics Risk Adjustment & Coding Team.
Last updated: August 2026
Top comments (0)