Healthcare Risk Adjustment Tools from VBC Risk Analytics

Source: Dev.to

Introduction

Healthcare data engineering is hard. Healthcare risk adjustment data engineering is a category of hard that deserves its own word.
If you’ve ever worked in health IT, you know the stack: EHR extracts that arrive in many formats, ICD‑10 codes that map to HCC categories under rules that change every model year, RAF scores that determine how much a health plan gets paid for every enrolled member, and CMS audits that can claw back millions if the documentation doesn’t hold up.

At VBC Risk Analytics we’ve spent years building API‑first tools in this space. This post explains what risk adjustment actually is, why it’s technically interesting, and what we’re building — with the hope of connecting with developers, data engineers, and health‑IT professionals who work in this domain.

What is Risk Adjustment?

Risk adjustment is the process Medicare uses to ensure that health plans are paid fairly based on the health status of their enrolled members. Sicker members cost more to care for, so a plan that enrolls a predominantly sick population gets higher payments to offset those costs. A plan that enrolls predominantly healthy members gets lower payments.

The mechanism that drives this is the Hierarchical Condition Category (HCC) model — specifically, the CMS‑HCC model maintained by the Centers for Medicare and Medicaid Services (CMS). Every Medicare Advantage member gets a Risk Adjustment Factor (RAF) score that reflects their predicted cost relative to the average Medicare beneficiary.

• RAF = 1.0 → expected cost equals the average beneficiary.
• RAF = 1.5 → expected cost is 50 % higher than average.
• RAF = 0.7 → expected cost is 30 % lower than average.

The score is built by:

1. Taking the member’s demographic data (age, sex, Medicaid eligibility, etc.).
2. Mapping their ICD‑10 diagnosis codes to HCC categories.
3. Applying interaction factors for certain combinations of conditions.
4. Summing the coefficients from the CMS‑HCC model.

For a health plan with 100,000 Medicare Advantage members, even small errors in this calculation—missed diagnoses, mapping mistakes, documentation gaps—compound into significant over‑ or under‑payment.

Implementation Challenges

ICD‑10‑to‑HCC Mapping

• Approximately 70,000 ICD‑10‑CM codes map to 86 HCC categories in the CMS‑HCC V28 model.
• Not all codes map to HCCs; some map to multiple HCCs.
• The “hierarchical” part means that more severe conditions suppress less severe ones (e.g., HCC 18 — Diabetes with chronic complications — overrides HCC 19 — Diabetes without complication).

Model Versioning

• Model coefficients change with each version. CMS transitioned from V24 to V28 over 2024‑2026, blending the two models at different percentages each year.
• Code that was correct for V24 produces wrong answers for V28 if the coefficient tables aren’t updated.

Demographic Adjusters

• Adjusters depend on community‑dwelling vs. institutionalized status, Medicaid eligibility, and enrollment period. Errors affect every member.

RADV Audits

• The Risk Adjustment Data Validation (RADV) audit selects a sample of medical records and verifies that each HCC in the RAF score is supported by adequate documentation.
• Plans that fail RADV audits must repay the over‑payment plus potential extrapolation penalties.

VBC Risk Analytics Platform

Our platform at vbcriskanalytics.com addresses the risk adjustment workflow end‑to‑end. Key components include:

• RAF Score API – A REST endpoint that takes a member’s demographics and ICD‑10 codes and returns a fully calculated RAF score with HCC mapping details, model version, and coefficient breakdown. Handles V24, V28, and blended transition percentages.
• ICD‑10 Data Lookup API – Fast lookup for ICD‑10‑CM codes (descriptions, HCC mappings, validity flags, hierarchy relationships). Useful for coding workflow tools, eligibility systems, and CDI applications.
• RADV Audit Scrubber – Reviews documentation supporting each HCC against CMS audit criteria, flagging potential deficiencies before a RADV audit occurs.
• NPI Lookup API – Provider verification via the National Plan and Provider Enumeration System (NPPES), useful for linking clinical data to provider records.

Why an API‑First Approach?

• Most health plans and provider groups already have analytics infrastructure; they need specific capabilities, not a replacement system.
• Health‑IT developers building EHR integrations, population health tools, and care‑management platforms need programmatic access to risk‑adjustment data.
• APIs are testable, versionable, and composable in ways that dashboard‑only tools aren’t.

Getting Started

If you’re building something in the health‑IT space and need RAF scoring, ICD‑10 lookup, or provider verification, explore the healthcare APIs at VBC Risk Analytics. Documentation and sandbox access are available on the website.

Future Posts

In upcoming Dev.to posts I’ll dive deeper into:

• The ICD‑10‑to‑HCC mapping algorithm — how it works under the hood.
• CMS‑HCC V28 changes and what broke in existing implementations.
• RADV audit data modeling — structuring your documentation review pipeline.
• Building a risk‑stratification system from claims data.
• NPI verification edge cases and the mess that is provider data quality.

Contact

If you work in health IT or healthcare data engineering, I’d love to connect. Drop a comment below or reach out through vbcriskanalytics.com.