MA pbp section a

What it is

1. 1CMS Plan Benefit Package (PBP) Public Use File, Section A — the plan-level administrative and identity header for every Medicare Advantage and Part D plan that filed a benefit bid with CMS.
2. 2One row describes a single plan (contract+plan+segment) as of one PUF release: who runs it (org/marketing names, CEO/CFO), what kind of plan it is (HMO/PPO/PDP/SNP/PACE/MMP/Cost), member-service phone numbers and websites, special-needs/employer/VBID flags, and estimated enrollment.
3. 3It is the lookup/dimension spine that the other PBP sections (cost-sharing, drug, dental, etc.) hang off of via the contract/plan/segment key;
4. 4Section A itself carries almost no dollar amounts.

Grain

How to read it

1. 1Get the current roster of distinct Medicare plans for 2026 (one row per plan, latest snapshot): SELECT contract_id, plan_id, segment_id, pbp_a_plan_name, pbp_a_plan_type, pbp_a_org_marketing_name, pbp_a_special_need_flag, pbp_a_est_memb FROM medicare_silver.pbp_section_a WHERE report_year = 2026 AND quarter = (SELECT MAX(quarter) FROM medicare_silver.pbp_section_a WHERE report_year = 2026).
2. 2This answers 'which MA/PD plans exist this year, who operates them, what type are they, and roughly how big' — and gives the contract/plan/segment key to join into the cost-sharing and drug PBP sections for actual benefit/cost analysis.

Traps

1. 1GRAIN IS THE SNAPSHOT, NOT THE PLAN-YEAR. quarter = the CMS PUF RELEASE quarter, not a coverage quarter. For 2018+ a single plan-year appears up to 4 times (one row per quarterly re-release; ~45k plan-years have 2-4 snapshots). If you want one row per plan per year you MUST dedup to MAX(quarter) (optionally MAX(version)/MAX(cms_vintage_sequence)) within (contract_id, plan_id, segment_id, report_year) — otherwise you over-count plans ~1.4x in recent years.
2. 2bid_id LOOKS like the key but is NOT: it is NULL for all 9,994 pre-2007 rows and equals contract_id_plan_id_segment_id for only 229k of 244k rows; bid_id+year+quarter is NOT unique (234,041 < 244,035). Always key on the 5 columns contract_id, plan_id, segment_id, report_year, quarter (verified exactly unique = 244,035).
3. 3CODE COLUMNS ARE NOT ZERO-PADDED CONSISTENTLY across the history. plan_type has both '01' (98k) and '1' (3.4k) for HMO; orgtype has '01'/'1', '04'/'4', '08'/'8', etc. The early-year files use unpadded codes. Filtering e.g. plan_type='01' silently drops the '1' rows — normalize with LPAD or match both forms.
4. 4FLAG POLARITY IS INVERTED from intuition: pbp_a_special_need_flag = '1' means IS a SNP (31,002 rows) and '2' means NOT a SNP (207,959). Many Y/N flags here are coded '1'/'2', not 1/0 or Y/N.
5. 5NULLS CARRY MEANING (N/A, not zero/false). pbp_a_est_memb is null for ~70% of rows (= enrollment not reported, NOT zero members); all snp_* fields and special_need_plan_type are null for non-SNP plans; vbid_indicator/pbpver are null in years before the feature existed. Do not coalesce these to 0/false.
6. 6SECTION A IS A DIMENSION/HEADER, NOT A COST TABLE. It carries plan identity, type, contacts and flags but essentially no dollar cost-sharing — for premiums, copays, deductibles, and drug costs you must join to the other PBP sections (and the cost-sharing/MOOP tables) on the same contract_id/plan_id/segment_id key plus report_year/quarter.
7. 7Provenance is multi-vintage: asserted_at has 2 values and cms_vintage_sequence ranges 1-4 (the 2018-2024 quarterly snapshots were loaded 2026-05-20 on top of the 2026-05-16 historical load). sha256_content_hash is a per-FILE hash (40 distinct, one per release zip), not a per-row hash, so it cannot be used to detect row-level duplicates.

Columns (152)

Query it

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