Model Medicare Part B premiums in baseline SPM MOOP

[MaxGhenis]

Summary

Baseline SPM poverty currently uses medicare_part_b_premiums as a CPS input/uprated variable rather than a modeled Medicare Part B premium. This matters for baseline SPM resources and especially for future-year poverty projections.

We already have most of the Medicare Part B modeling machinery in policyengine-us, but it is not wired into the baseline SPM MOOP path.

Why this matters

For modeled SPM poverty, we want the baseline resource concept to use our model for the components we claim to model. Right now:

• medical_out_of_pocket_expenses feeds into SPM expenses
• health_insurance_premiums includes medicare_part_b_premiums
• but medicare_part_b_premiums is still an input/uprated variable

That means projected SPM poverty is partly inheriting CPS/Census-reported Part B premiums instead of a modeled premium schedule.

Current state

SPM expense path

• medical_out_of_pocket_expenses adds health_insurance_premiums and other_medical_expenses
• health_insurance_premiums adds health_insurance_premiums_without_medicare_part_b and medicare_part_b_premiums
• spm_unit_spm_expenses adds medical_out_of_pocket_expenses

Current gap

medicare_part_b_premiums is currently just an input variable with uprating, not a formula:

• policyengine_us/variables/household/expense/health/medicare_part_b_premiums.py

Meanwhile we already have Medicare Part B policy logic and parameters:

• policyengine_us/variables/gov/hhs/medicare/eligibility/part_b/base_part_b_premium.py
• policyengine_us/variables/gov/hhs/medicare/eligibility/part_b/income_adjusted_part_b_premium.py
• policyengine_us/variables/gov/hhs/medicare/costs/medicare_enrolled.py
• policyengine_us/parameters/gov/hhs/medicare/part_b/...

On the data side, CPS currently loads raw PEMCPREM into medicare_part_b_premiums.

Desired outcome

Decide and implement the correct baseline treatment for Medicare Part B premiums in SPM MOOP.

Preferred direction:

• baseline SPM should use modeled Medicare Part B premiums, not just the CPS input
• keep any Census-alignment audit as a separate validation path

Possible implementation choices:

1. Modeled baseline

   • derive Part B premiums from enrollment, filing status, prior-year MAGI/IRMAA, and any modeled offsets
   • use this directly in health_insurance_premiums

2. Census-style hybrid

   • use reported premiums where present
   • simulate otherwise
   • document clearly that this is a Census-alignment path, not a fully modeled baseline

Open modeling questions

• how to represent MSP/QMB/SLMB/QI offsets in the SPM MOOP context
• whether to treat CPS-reported PEMCPREM as a validation target, an input fallback, or neither
• whether baseline SPM projections should prioritize modeled consistency or Census-style hybrid reconstruction

Acceptance criteria

• explicit documented decision on modeled vs hybrid baseline treatment
• baseline medicare_part_b_premiums path implemented accordingly
• tests covering standard premium, IRMAA, and zero-premium / MSP-style cases
• validation note on how the modeled/hybrid series compares to CPS PEMCPREM and/or Census SPM MOOP

Related context

• policyengine-us#1357 is adjacent but narrower; it is about whether CPS health premiums withheld from Social Security are already captured
• this issue is broader: baseline SPM MOOP and poverty projections should not silently rely on raw CPS Part B premiums if we intend this component to be modeled