MA pbp section b19 model test

What it is

1. 1CMS Medicare Advantage Plan Benefit Package (PBP) Section B-19 — the supplemental-benefit summary section covering VBID (Value-Based Insurance Design), MA Uniformity Flexibility, SSBCI (Special Supplemental Benefits for the Chronically Ill), VBID Hospice, Health Equity (HEP), Wellness/Health-Planning (WHP), and Part-C Rewards-and-Incentives.
2. 2One wide row per MA plan-segment per benefit year, carrying the top-level yes/no flags, package counts, and the (sparse) reduced cost-share dollar amounts each plan filed in its bid.
3. 3It is the source for 'which MA plans offer VBID/SSBCI/UF supplemental benefits, of what type, in which years.'

Grain

How to read it

1. 1"SELECT report_year, COUNT(*) AS plans, SUM(CASE WHEN pbp_b19a_ssbci_yn='1' THEN 1 ELSE 0 END) AS ssbci_yes, SUM(CASE WHEN pbp_b19a_uf_yn='1' THEN 1 ELSE 0 END) AS uf_yes, SUM(CASE WHEN pbp_b19a_vbd_yn='1' THEN 1 ELSE 0 END) AS vbd_yes FROM medicare_silver.pbp_section_b19_model_test GROUP BY report_year ORDER BY report_year;" answers 'how many MA plan-segments offer SSBCI / MA Uniformity Flexibility / VBID supplemental benefits each year, and how did adoption shift (e.g.
2. 2VBID going to zero in 2026)?'.
3. 3Join to pbp_section_a (or pbp_vbid_overlay) on (contract_id, plan_id, segment_id, report_year) to attach plan name/enrollment/region.
4. 4Always GROUP BY or filter report_year first because field availability is year-dependent."

Traps

1. 1NAME TRAP — '_model_test' is NOT a dev/sample/partial table. It is the literal CMS PBP source section name ('B-19 Model Test', the VBID/MA-Uniformity-Flexibility 'model test' supplemental-benefit section). It carries ~88-95% of all MA contracts for its years (e.g. 2024: 953 of 1,034 contracts vs full pbp_section_a). It IS real production data, just only for plans that file Section B-19.
2. 2GRAIN TRAP — the profiler reports an 11-column SUPERSET key. The true minimal grain is just (contract_id, plan_id, segment_id, report_year) = 40,737 distinct = row_count, zero dupes. bid_id, quarter, observed_period, effective_period_start are all redundant (bid_id = contract_'_'_plan_'_'_segment exactly; quarter is always 1; observed_period/eff_start = Jan-1 of report_year). The extra columns the profiler added (pbp_a_plan_type, max_plan_ben_amt, whp_provid_incent...) are NOT keys — they just happen not to break uniqueness.
3. 3YEAR GAPS — only 2017, 2021, 2022, 2024, 2025, 2026 exist; 2018/2019/2020/2023 are MISSING from silver. Never assume a continuous yearly series. For a continuous VBID index across 2017-2026 use the sibling pbp_vbid_overlay (16 cols, index-only, no benefit fields). Also quarter=1 always, but the source files are mixed quarters per year (see source_url) — don't read quarter as the true release.
4. 4NULL-MEANS-NOT-COLLECTED, varying by year — this is the single biggest analysis trap. 2017 has EVERY B19a/HEP/WHP/B19b field 100% NULL (the section had a totally different shape then; only legacy base cols). HEP fields are populated ONLY in 2024. WHP and VBID fields are populated 2021/2022/2024 and NULL in 2025/2026 (VBID demonstration sunset; CMS restructured ~40 fields CY2024->CY2025). So NULL on vbd_yn/hep_action/whp_* usually means 'field absent that year', NOT 'plan answered No'. Always filter by report_year before interpreting a flag, and read 1/2/NULL as Yes/No/not-applicable.
5. 5ONLY ~90 of 1,181 source columns are extracted (92% of the per-sub-benefit cost-share matrix is NOT in silver). The detailed reduced-cost-share dollar amounts a cost analyst wants (pbp_b19a_coins_16a_min, copay/deductible per sub-benefit) DO NOT EXIST here — only top-level yes/no flags + package counts + a handful of sparse aggregate dollars survive. Whole column families are placeholder-empty in every year: all pbp_b19_c_* Part-C cash-rebate/R&I fields (the live reward data is in pbp_b19_whp_* instead), pbp_b19a_reduct_cost_add_yn, and most pbp_b19c_* hospice cost-share cells (≤10 rows ever). See docs/research/26_pbp_b19_column_ledger.md for the per-column inhabitance-by-year ledger.
6. 6SINGLE SNAPSHOT, no is_current / no dedup needed — there is no is_current column. asserted_at (2026-05-16), cms_vintage_sequence (=1), and parse_revision (=1) are CONSTANT across all rows: the bi-temporal columns are scaffolding for future re-releases but currently carry exactly one vintage. Do NOT write supersession/dedup logic; one row per (bid, year) already. Provenance columns (source_url, sha256_content_hash, parser_artifact_hash) have 6 distinct values = one per report_year.

Columns (114)

Query it

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