CCLF is not eligibility: where dual status gets lost in Medicare ACO data

If you work with Medicare Shared Savings Program (MSSP) data, you get two families of files from CMS: CCLF (claims and beneficiary demographics, monthly) and ALR (Assignment List Reports, quarterly). The usual advice is correct: CCLF does not tell you who is assigned to your ACO. The ALR does.

What I didn’t see written anywhere is the next question: the ALR tells you who is in. Which source tells you what attributes they have?

This post walks through one attribute, dual eligibility status, in the open-source Tuva Project connectors. It shows how a reasonable-looking coalesce plus a “latest month” rule can turn full-dual beneficiaries into non-duals in the risk model, without any test or flag going off.

Why dual status matters

In the CMS-HCC model, the community segment a beneficiary falls into depends on dual status (full, partial, or non-dual) together with age and disability. Different segment, different coefficients, different RAF. Classifying a full dual as non-dual changes the risk score of that member.

In Tuva’s cms_hcc package, the mapping looks like this:

case
    when dual_status_code in ('02', '04', '08') then 'Full'
    when dual_status_code in ('01', '03', '05', '06') then 'Partial'
    else 'Non'
end as dual_status

That’s a lookup on a categorical code. Keep that in mind.

Two sources, two different fields

Both have “dual” in the name. Only one is a code.

Tuva’s own docs agree on where dual status comes from: the Medicare CCLF Connector page lists dual eligibility status as one of the attributes in beneficiary_demographics. The ALR connector README describes bene_psnyrs_dual as a person-years fraction, keeps it at numeric(38,10) and pins that precision with a unit test.

Issue 1: coalescing a fraction with a code

With cms_alr_connector: true, the CCLF connector builds dual_status_code like this (eligibility.sql#L215):

cast(coalesce(
    latest_span_record.bene_psnyrs_dual,   -- ALR, numeric fraction
    latest_span_record.bene_dual_stus_cd   -- CCLF8, categorical code
) as string) as dual_status_code

Synthetic example:

m1 was dual for the whole year and has a full-dual code in CCLF8. It ends up non-dual.

Without the ALR connector, the other branch of the same model uses bene_dual_stus_cd directly, so the mapping is correct there. The issue is specific to the ALR + CCLF combination, which is the setup the docs recommend for MSSP.

Issue 2: latest month of the span

Eligibility spans are built by grouping consecutive months with the same eligibility_flag and data_sharing_flag. For each span, the connector keeps one row: the latest coverage_month.

The span gets the March row, so dual_status_code is null, and cms_hcc maps it to Non. Two months of valid information discarded.

Why nothing catches it

cms_hcc has a flag for this situation, medicaid_dual_status_default. It is set only when dual_status_code is null:

• Issue 2 (null) → flagged. At least you can see it.
• Issue 1 (1.0000000000) → not null, not a valid code, not flagged. The member is classified as non-dual, and nothing indicates that a default was applied.

The Input Layer contract does define the valid values (00–10) and says a missing value defaults to non-dual in CMS-HCC. There is also a terminology seed, terminology__medicare_dual_eligibility. But I didn’t find any test that checks dual_status_code against it.

Eligibility authority ≠ attribute authority

The maintainers’ position, paraphrased: CCLF8 is not eligibility. The ALR is the source of truth for whether a member is eligible, and since ALRs are quarterly and delayed, the connector carries the latest ALR status forward. CCLF8 elements could be integrated where available.

That’s correct for eligibility, and the connector implements it carefully: inferred_eligibility_flag extends the latest ALR using CCLF8’s bene_entlmt_buyin_ind only for members active in the latest ALR month.

But “the ALR decides who is eligible” doesn’t imply “every attribute should come from the ALR”. Eligibility has an authoritative source. Dual status has another one. And a person-years fraction isn’t a status code, whatever file it comes from.

Options

None of these are mine to decide. They’re the alternatives I’d put on the table:

1. Use a categorical source for dual_status_code. Either CCLF8 bene_dual_stus_cd, or ALR table 9 BENE_DUAL_STATUS if CMS defines it with a compatible value set (to verify against the ALR data dictionary). Keep bene_psnyrs_dual as an extension column.
2. Latest non-null within the span instead of the latest row.
3. Test the value set: an accepted_values or relationships test against terminology__medicare_dual_eligibility.
4. Widen the default flag: set medicaid_dual_status_default when the code is null or not in the valid set.

What Tuva said

Takeaway

The Tuva blog post Understanding Medicare ACO Assignment explains why CCLF alone can’t define your population. This is the next layer of the same problem: once the ALR has decided who is in, every attribute still needs its own answer to “which source is the truth, and what does this field actually mean?”

Technical lineage says dual_status_code comes from latest_span_record. Semantic lineage asks whether that value is still a dual status code by the time cms_hcc reads it.

References

Tuva Project — docs

• MSSP ACOs Data Tools Overview: https://thetuvaproject.com/mssp-acos/overview
• Medicare CCLF Connector: https://thetuvaproject.com/mssp-acos/medicare-cclf-connector
• CMS ALR Connector: https://thetuvaproject.com/mssp-acos/cms-alr-connector
• Input Layer: https://thetuvaproject.com/input-layer
• CMS HCCs data mart: https://thetuvaproject.com/data-marts/cms-hccs

Tuva Project — code (pinned commits)

• medicare_cclf_connector · eligibility.sql (coalesce, L215): https://github.com/tuva-health/medicare_cclf_connector/blob/4728d7a65eed512e2c9d2c3ad2dd82f24e1f81cf/models/final/eligibility.sql#L215
• medicare_cclf_connector · int_eligibility_member_months_combined.sql: https://github.com/tuva-health/medicare_cclf_connector/blob/4728d7a65eed512e2c9d2c3ad2dd82f24e1f81cf/models/intermediate/int_eligibility_member_months_combined.sql
• medicare_cclf_connector · packages.yml (Core pin): https://github.com/tuva-health/medicare_cclf_connector/blob/603a258e3c649d6a4eb7d0835e8efc7d79371204/packages.yml
• cms_alr_connector · README (bene_psnyrs_dual definition): https://github.com/tuva-health/cms_alr_connector/blob/51e148339dae0a6d72dda45f70a02f7a6720d064/README.md
• cms_hcc · cms_hcc__int_members.sql (dual mapping and default flag): https://github.com/tuva-health/cms_hcc/blob/b3cd83033157eaec79f17c3943207adc0b5c3d97/models/cms_hcc/intermediate/cms_hcc__int_members.sql#L351-L409

Tuva Project — blog

• Understanding Medicare ACO Assignment (2026-02-19): https://github.com/tuva-health/tuva_blog

CMS

• CCLF Information Packet (BENE_DUAL_STUS_CD)
• Medicare Shared Savings Program — ALR data dictionary (BENE_PSNYRS_DUAL, table 9 BENE_DUAL_STATUS)
• CMS-HCC Rate Announcement (community segments by dual status)