HCC suspecting explained from a data engineering perspective

HCC suspecting is one of those terms that sounds like a clinical concept but is primarily a data problem. Understanding what it is from a data engineering perspective — what the inputs are, what the output tables look like, and why it matters financially — is more useful than the clinical framing.

What HCC suspecting is

Hierarchical Condition Categories (HCCs) are a risk adjustment model used by CMS for Medicare Advantage plans and ACOs. Each HCC represents a clinical condition category. Patients with more or more severe conditions get higher Risk Adjustment Factor (RAF) scores, which drives the capitation payment the plan receives for that patient.

HCC suspecting identifies patients who probably have a condition but haven’t had it documented in a claim this year yet. “Suspecting” means: based on prior year claims, this condition likely still persists — go find documentation of it this year or risk losing the RAF credit.

From a data perspective:

Input: claim lines with ICD-10 diagnosis codes, minimum two years of history
Processing: map ICD-10 codes to HCC categories via the CMS crosswalk, compare prior year HCC set to current year HCC set
Output: one row per patient per HCC gap, flagged with whether the condition appeared in prior year, current year, or both

The Tuva HCC suspecting mart

Tuva produces three relevant tables:

hcc_suspecting__summary — one row per patient:

patient_id
suspecting_gaps — count of HCCs documented in prior year that haven’t appeared in current year claims yet
HCC category counts by severity tier

hcc_suspecting__list — one row per patient per suspected HCC:

patient_id
hcc_code
hcc_description
prior_year_claim_count
current_year_claim_count
suspected_flag

hcc_recapture__int_gap_status — intermediate model computing gap status per patient per HCC. This is one of the two models that fails on DuckDB 1.10 due to a window function column binding bug in complex CTEs.

The ICD-10 to HCC mapping

The crosswalk from ICD-10 codes to HCC categories comes from CMS. Tuva includes these as seeds. The current CMS HCC model v28 (in use since 2024) maps roughly 10,000 ICD-10 codes to 115 HCC categories.

The mapping is not one-to-one. Multiple ICD-10 codes can map to the same HCC, and the “hierarchical” part means more specific conditions trump less specific ones. If a patient has both HCC18 (diabetes without complications) and HCC17 (diabetes with acute complications), only HCC17 gets counted — it subsumes HCC18.

In SQL terms, this is implemented as a ranked window function over HCC hierarchy groups, keeping only the highest-severity HCC within each group:

SELECT *
FROM (
    SELECT
        patient_id,
        hcc_code,
        hcc_description,
        ROW_NUMBER() OVER (
            PARTITION BY patient_id, hcc_hierarchy_group
            ORDER BY hcc_severity DESC
        ) AS hierarchy_rank
    FROM hcc_raw_mappings
)
WHERE hierarchy_rank = 1

Why suspecting_gaps matters for RAF

A Medicare Advantage plan or ACO wants every HCC present last year documented again this year. If a patient had type 2 diabetes with complications last year but no diabetes diagnosis has appeared in current-year claims yet, there’s a suspecting gap.

Closing that gap — getting documentation from a provider visit — recaptures the RAF credit. The financial value per HCC varies. HCC 85 (congestive heart failure) carries a coefficient of ~0.32, meaning it adds roughly 32% to the base capitation payment. HCC 138 (kidney transplant status) is even higher. A single unclosed gap on a high-RAF condition can represent thousands of dollars annually for one patient.

What you actually do with the mart

The most common use case is a worklist: patients ranked by suspecting_gaps, filtered to those who’ve had a recent visit but still have open gaps. The gap list becomes an outreach queue — care coordinators or clinical coders review it and initiate outreach.

In the analytics app built on top of this pipeline, hcc_suspecting__summary feeds a risk prediction model that flags high-gap patients early, before a full RAF reconciliation run. The four features used are patient_age, patient_sex, total_paid_amount, and condition_count — all derivable from the summary table alone.