MA pbp plan region area

What it is

1. 1A Medicare Part D / Medicare Advantage plan-geography 'footprint' table from the CMS PBP (Plan Benefit Package) Public Use Files: it lists which CMS regions each plan is offered in, per benefit year.
2. 2It is overwhelmingly standalone Part D drug plans (PDP) — 99% of rows are region_type='PD'.
3. 3It answers 'which plans serve which CMS region in which year', and is the regional-offering spine you join to richer PBP benefit/cost tables; it contains NO premiums, benefits, or dollar amounts itself.

Grain

How to read it

1. 1To list the regions a given standalone PDP serves in the latest 2026 view: SELECT region_type, ma_or_pdp_region_code, region FROM medicare_silver.pbp_plan_region_area WHERE contract_id='S5601' AND plan_id='001' AND contract_year='2026' AND quarter=1 ORDER BY ma_or_pdp_region_code.
2. 2This answers 'where is this Part D plan offered' (its geographic footprint) for that benefit year.
3. 3For a year-over-year footprint trend, always pin quarter (e.g. quarter=1) to avoid double-counting multi-quarter snapshots.

Traps

1. 1NO is_current flag and quarter is a true snapshot dimension: several years (2018, 2019, 2023, 2024) carry up to 4 quarterly re-publications of the SAME plans (each a distinct CMS file with its own sha256), so a naive COUNT/aggregate without filtering quarter over-counts plan-regions up to 4x. To get one current view per year, filter quarter = max(quarter) for that contract_year.
2. 2ma_or_pdp_region_code is meaningless without region_type: codes 01-39 are PDP regions when region_type='PD' but 01-26 are MA regions when region_type='MA', and the SAME numeric code maps to different geographies (e.g. '11' = Florida under PD, Michigan under MA). Always pair the code with region_type (and the region name).
3. 3This is NOT a benefit or cost table despite being PBP-sourced: it has zero premium/copay/dollar columns. ONE row = a plan-region offering (geographic footprint). For actual cost/benefit values you must join to the other pbp_* / PBP benefit tables on contract_id+plan_id+segment_id+year.
4. 4bid_id looks like a key but is broken: it is NULL for all of 2006 (7,536 rows) and matches contract_plan_segment in only ~37% of rows. segment_id is also format-unstable — '' vs '0' for the same logical value, flipping by quarter within a year (2019 Q1='' , Q2-Q4='0'). Reconstruct identity from contract_id/plan_id/segment_id, normalizing segment_id, rather than trusting bid_id.
5. 5Several columns are dead/constant and carry no signal: version (always 0.0), partial_flag (100% null), pbp_segment_id (100% null - not the real segment), pending_flag (always '0'). pbp_a_ben_cov is null for the entire PD slice (MA-only). asserted_at is a warehouse load date (only 2026-05-16 / 2026-05-20), not a real-world date - don't use it for plan timing.
6. 6The table is ~99% standalone Part D (region_type='PD', contract prefix 'S'); MA regional plans ('R', region_type='MA') are only 3,869 rows and the 'X'-prefixed orgtype=16 slice is a single CMS demo/test contract (1,598 rows). Also note eghp_flag: ~64% of PD rows are Employer Group Health Plans (eghp_flag='1') - filter on it to separate individual-market from employer/union-sponsored Part D.

Columns (27)

Query it

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