PolicyEngine / PolicyEngine/policyengine-us

Model Medicare Part B premiums in baseline SPM MOOP

Open
#7,967 1 comment 0 reactions 0 assignees View on GitHub
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.