PolicyEngine / PolicyEngine/policyengine-us
Model Medicare Part B premiums in baseline SPM MOOP
- Dominant language
- Python
- Stars
- 162
- Forks
- 212
- Avg merge
- 3d 3h
- Merged PRs (30d)
- 96
Description
## 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
Contributor guide
Assessment
This issue has not been assessed yet.