MA pbp section d

What it is

1. 1CMS Plan Benefit Package (PBP) Section D for Medicare Advantage / Part C plans: the plan-level deductibles and Maximum-Enrollee out-of-pocket (MOOP) limits each MA plan files with CMS each year.
2. 2Despite the 'D' it is NOT Medicare Part D prescription-drug data — drug formulary/tier/gap data lives in the sibling pbp_mrx* tables;
3. 3Section D = the deductible & out-of-pocket-maximum section of the benefit package.
4. 4It is the cost-exposure ceiling (deductible + MOOP) reference for every MA plan, usable to benchmark how much financial protection a plan offers.

Grain

How to read it

1. 1Benchmark MA plan out-of-pocket maximums for 2026: SELECT pbp_a_plan_type, round(avg(pbp_d_comb_max_enr_amt),0) avg_moop, max(pbp_d_comb_max_enr_amt) max_moop, count(*) plans FROM medicare_silver.pbp_section_d WHERE report_year=2026 AND quarter=1 AND pbp_d_comb_max_enr_amt_yn='1' GROUP BY pbp_a_plan_type ORDER BY plans DESC.
2. 2Answers: what combined in+out-of-network MOOP do 2026 MA plans set, by plan type? (Local PPO ~$10,900; observed plan-level max $13,900.) Always pin quarter (use =1, or MAX(quarter) per year for the latest in-year revision) and join to pbp_section_a / the contract-plan dimension for plan names.
3. 3For the medical deductible use pbp_d_ann_deduct_amt (gated by pbp_d_ann_deduct_yn='1'); do NOT use the bare pbp_d_deduct column, which is entirely NULL.

Traps

1. 1NOT Part D drugs. The 'D' is PBP Section D = plan deductibles + Maximum-Enrollee out-of-pocket (MOOP), for Medicare ADVANTAGE plans. Prescription-drug formulary/tier/coverage-gap data is in the SIBLING tables pbp_mrx, pbp_mrx_tier, pbp_mrx_gap_coverage (and Part B drugs in pbp_section_b15). Querying this table for drug costs returns nothing useful.
2. 2quarter is a MANDATORY grain dimension and silently inflates counts. Most years store only quarter=1, but 2018/2019/2023 store all 4 quarterly PBP re-releases (so each plan appears ~4x) and 2020/2022/2024 store partial sets. Without a quarter filter, a multi-year COUNT or AVG over-counts those years 3-4x. Use WHERE quarter=1 (or MAX(quarter) per plan-year) to get one row per plan.
3. 3No is_current / snapshot-active flag exists. Every retained quarterly release is its own row; you must do the 'pick one quarter' dedup yourself. effective_period_start, effective_period_end, observed_period and report_year are all just encodings of the plan YEAR (start=year-01-01, end=year-12-31), verified identical for all 201,597 rows — none of them is a publication/load timestamp.
4. 4bid_id looks like the natural key but is NULL for 8,425 legacy rows (years 2001-2006, before CMS assigned bid IDs) and is therefore unusable as a full-history key; for years >=2007 it equals contract_id+'_'+plan_id+'_'+segment_id. segment_id is an EMPTY STRING '' (not NULL) in those same legacy years.
5. 5Pervasive NULL-means-not-applicable, plus dead columns. _yn fields use 1=Yes / 2=No / NULL=not-applicable (commonly because the plan type doesn't use that field — e.g. HMO plans leave combined-MOOP pbp_d_comb_max_enr_amt NULL because their MOOP is in Section C). Many dollar columns are populated only when their gating _yn='1'. The bare pbp_d_deduct column is 100% NULL (a defined-but-unused legacy slot) — use pbp_d_ann_deduct_amt instead. The table is 627 columns wide mostly because of hundreds of near-empty per-benefit-line pbp_d_diff_deduct_* and 1-5 repeated pbp_d_combo_* cells.

Columns (656)

Query it

describe_data_source(source_fqn="medicare_silver.pbp_section_d")     # the card, live
query_substrate(sql="SELECT * FROM medicare_silver.pbp_section_d WHERE contract_id = '<value>' AND plan_id = '<value>' AND segment_id = '<value>' AND effective_period_start = '<value>' AND quarter = '<value>' LIMIT 100")