Calibrate CHIP take-up before estimating premium collections

[daphnehanse11]

Follow-up from #8099.

Problem

#8099 tried to replace noisy Line 49 CHIP collection proxies with direct FY2024 M-CHIP premium collection values. A second pass through the official FY2024 CMS CHIP financial management workbook found that direct M-CHIP cost-sharing offset rows are zero for CT, DE, MA, MI, and NY, and M-CHIP 20% sheets do not expose premium offset rows. The large M-CHIP Gross Premiums Paid rows appear to be expenditure-side premium-category spending, not household receipts.

That means estimating budget-quality CHIP premium collections needs a different path: aggregate modeled household premiums over a CHIP-enrolled population, not child enrollment counts or CMS Line 49 proxies alone.

Current model/data state

• chip_premium is already tax-unit level and captures key family mechanics:
  • CT, MA, and NY use per-child premiums with family caps.
  • DE and MI use household/family flat premiums.
  • The federal 5 percent family income cost-sharing cap is applied centrally.
• chip_enrolled currently depends on is_chip_eligible and takes_up_chip_if_eligible.
• takes_up_chip_if_eligible defaults to True, so simulated CHIP enrollment is effectively eligibility-based unless an input overrides it.
• policyengine-us-data already maps CPS NOW_PCHIP to reported_has_chip_health_coverage_at_interview.
• That reported CHIP coverage signal does not appear to be wired into PolicyEngine-US CHIP take-up.
• Medicaid has the closer pattern: US-data anchors take-up to reported Medicaid coverage and state-specific rates, then calibrates against administrative Medicaid enrollment targets.
• The raw CMS Medicaid/CHIP enrollment file in US-data includes Total CHIP Enrollment by state, which can serve as a state-level target.

Proposed approach

1. Add a PolicyEngine-US input for reported CHIP coverage at interview, analogous to existing health coverage inputs such as has_medicaid_health_coverage_at_interview.
2. In policyengine-us-data, use CPS reported_has_chip_health_coverage_at_interview as a reported-first anchor for takes_up_chip_if_eligible.
3. Derive state-specific CHIP take-up rates or post-calibration adjustment from CMS Total CHIP Enrollment.
4. Add CHIP enrollment state targets to the calibration/loss matrix, analogous to Medicaid enrollment targets.
5. Once CHIP enrollment/take-up is calibrated, estimate aggregate CHIP premium collections by summing existing chip_premium by state.
6. Use those state aggregates to revisit Replace Line 49 proxy with direct M-CHIP sheet premium collections for CT, DE, MA, MI, NY #8099's CT, DE, MA, MI, and NY cost-sharing offset calibration.

Acceptance criteria

• PolicyEngine-US has an explicit reported CHIP coverage input that US-data can populate from CPS NOW_PCHIP.
• US-data persists a CHIP take-up input that prioritizes reported CHIP coverage among eligible people.
• CHIP take-up/enrollment is calibrated, or at least diagnosed, against CMS Total CHIP Enrollment by state.
• A report compares, for CT/DE/MA/MI/NY:
  • CMS Line 49 proxy values,
  • direct CMS M-CHIP cost-sharing offset rows,
  • modeled aggregate chip_premium after CHIP take-up calibration,
  • and Replace Line 49 proxy with direct M-CHIP sheet premium collections for CT, DE, MA, MI, NY #8099 expected ranges.
• The premium collection estimate uses tax-unit chip_premium, preserving household premiums and family caps instead of multiplying premium schedules by child counts.

Notes

This is cross-repo work:

• PolicyEngine-US likely needs the reported CHIP coverage input and possibly CHIP take-up behavior changes.
• policyengine-us-data likely needs the CPS NOW_PCHIP take-up anchor and CHIP enrollment calibration target wiring.

The goal is not to reinterpret CMS M-CHIP Gross Premiums Paid rows as household collections. Those rows should remain excluded from cost-sharing offset calibration unless an official source confirms otherwise.

[daphnehanse11]

Main tracker for the calibration/data work is now PolicyEngine/policyengine-us-data#1148. This US issue should be treated as the small companion/prerequisite for exposing any PolicyEngine-US input needed by the data pipeline, not as the owner of the take-up calibration work.