VladaOmega
Sign inStart free
Medicare Advantage, Part D, Medicaid

MA pbp vbid overlay

medicare_silver.pbp_vbid_overlay·partial·silver·annual·Medicare Advantage Plan Benefit Packages (PBP)
Rows
N/A
Columns
16
History
2017 (report_year; benefit window 2017-01-01..2017-12-31) to 2026 (report_year; benefit window 2026-01-01..2026-12-31)
Card
yesgrain, traps, filters
Typed tools
0

What it is

  1. 1A marker/overlay table flagging which Medicare Advantage plan-segments offer Value-Based Insurance Design (VBID) flexibility and in which CMS PBP benefit sections, derived from the CMS Plan Benefit Package (PBP) Benefits Public Use File.
  2. 2It is the membership/JOIN spine for 'which MA plans participate in VBID (incl.
  3. 3SSBCI) and where' — it does not contain the benefit dollar values themselves.

Grain

KeyGrain
contract_idplan_idsegment_idparent_sectionvbid_variantreport_yearquarter
  1. 1One row per (contract_id, plan_id, segment_id, parent_section, vbid_variant, report_year, quarter) — i.e. one row per Medicare Advantage plan-segment x the specific PBP benefit section it flexes under VBID x the VBID variant, per benefit-year x per quarterly CMS PUF release.
  2. 2VERIFIED: those 7 columns produce exactly 172,041 distinct combinations = the full row_count, and dropping ANY single one of the 7 breaks uniqueness (none removable). cms_vintage_sequence and parse_revision are functionally determined by this key and add no distinctness.
  3. 3A single plan-segment typically spans 1-20 rows in one snapshot (one per VBID-flexed section).

How to read it

  1. 1Count distinct VBID-participating MA plan-segments per benefit year, de-duplicating the quarterly snapshots: WITH latest AS (SELECT report_year, max(quarter) mq FROM pbp_vbid_overlay GROUP BY report_year) SELECT o.report_year, count(DISTINCT (o.contract_id,o.plan_id,o.segment_id)) FROM pbp_vbid_overlay o JOIN latest l ON o.report_year=l.report_year AND o.quarter=l.mq WHERE o.parent_section <> 'unknown' GROUP BY o.report_year ORDER BY 1; — answers 'how many MA plans offered VBID benefits each year' and yields the real adoption curve (~57 in 2017 to ~7,400 in 2026) without the snapshot double-count or the unknown-sentinel noise.

Traps

  1. 1SNAPSHOT TABLE WITH NO is_current FLAG — the same benefit year is loaded from MULTIPLE quarterly CMS PUF releases, so the same plan-section repeats across quarters (2018/2019/2020/2022/2023/2024 are all multi-quarter; e.g. 2024 has q1,q3,q4 each ~17.7K rows). A naive COUNT(*) or COUNT(DISTINCT plan) across all rows DOUBLE/TRIPLE-counts. To get distinct VBID plans per year, dedup to one snapshot, e.g. JOIN to (SELECT report_year, max(quarter) FROM ... GROUP BY report_year). 'quarter' is a release/snapshot axis, NOT a within-year time period.
  2. 2parent_section='unknown' AND vbid_variant='unknown' are paired SENTINELS, not real values and not NULL — 76,436 rows (~44% of the table) where the parser could not classify the PBP section/variant. They co-occur perfectly (0 rows with only one 'unknown'), are heavily concentrated in 2022-2024, and inflate row counts. Filter them out (parent_section <> 'unknown') before any section-level analysis.
  3. 3asserted_at is an INGESTION timestamp (all rows 2026-05-16..2026-05-20), NOT a CMS publication/effective date — never use it to order CMS revisions or pick 'latest'; use report_year (benefit year) and quarter (release). Likewise observed_period / effective_period_start / effective_period_end are all DERIVED from report_year (Jan 1 and Dec 31 of that year) and carry no independent information.
  4. 4This is a MARKER / OVERLAY table — it carries only WHICH benefit sections a plan offers VBID flexibility in, NOT the benefit values. There are ZERO dollar/copay/limit columns. It tells you a plan participates in VBID and in which PBP sections; to get the actual benefit amounts you must JOIN on (contract_id, plan_id, segment_id, report_year) to the underlying PBP benefit tables. No nulls exist in any column (sentinels are used instead of NULL).
  5. 5cms_vintage_sequence (int 1-4) is NOT the grain and NOT a clean quarter mapping — it is a CMS release-sequence index that bleeds across quarters (vintage 4 = q1 AND q4). Use 'quarter' to identify the release. cms_vintage_sequence and parse_revision are provenance metadata that look key-ish but are functionally determined by the 7-column grain.
  6. 6Coverage is MA-only and grows steeply with VBID program adoption: contract_id is only H (MA/MAPD) and R (regional PPO) — no PDP. Distinct VBID plan-segments per year rose from 57 (2017) to ~7,400 (2026), so early years are thin. Do not treat low pre-2021 counts as data gaps; that is the actual size of the VBID program then.

Columns (16)

ColumnTypeMeaning
contract_idstringCMS Medicare Advantage contract ID (the plan's parent contract). VERIFIED 1,188 distinct; all begin H (1,160 contracts, standard MA/MAPD) or R (28 contracts, regional PPO). No S/E prefixes — VBID is an MA-side flexibility, so PDP-only contracts never appear. Part of the grain key.
plan_idstring3-char plan benefit package ID within the contract (e.g. '001','053','805'), zero-padded string. 656 distinct, NOT unique on its own (reused across contracts). (contract_id, plan_id) identifies a plan; add segment_id for a plan-segment. Part of the grain key.
segment_idstringPlan segment number as string, range '0'-'25'. '0' = unsegmented plan and dominates (154,554 of 172,041 rows, ~90%); non-zero values are CMS geographic/benefit segments of a segmented plan. Part of the grain key — a contract can offer different VBID section sets per segment (e.g. H0028/053 has segments 1,3,4 with different section sets).
parent_sectionstringThe CMS PBP benefit-section code under which the plan offers a VBID-flexed benefit: e.g. b10 (DME/prosthetics), b13 (Part B Rx/other), b13i (SSBCI), b14c, b16 (dental), b17 (vision), b18 (hearing), b19a/b19b, plus b1a/b1b/b2/b3/b4/b7/b9. CRITICAL: 'unknown' is a SENTINEL (76,436 rows) meaning the parser could not classify the section — it is NOT a real PBP section. Part of the grain key; one plan-segment has 1-20 such rows per snapshot.
vbid_variantstringThe VBID flexibility flavor for that section. Observed: b19b_uf and b19a_uf (UF = Uniform Flexibility / standard supplemental), b19b_ssbci (Special Supplemental Benefits for the Chronically Ill — always paired with parent_section b13i), b19a_plain/b19b_plain/plain (non-VBID/standard marker). CRITICAL: 'unknown' (76,436 rows) is a sentinel co-occurring EXACTLY with parent_section='unknown' (0 either-only). Part of the grain key.
report_yearintThe Medicare benefit/plan year the row describes (int). VERIFIED 2017-2026, 10 years. Primary temporal axis (= the year the VBID offering is effective), distinct from when CMS published or Vlada parsed it. Part of the grain key.
quarterintWhich quarterly CMS PBP PUF RELEASE (1-4) this row was extracted from. The same benefit year is republished in multiple quarters (e.g. 2023 has q2,q3,q4 each ~16.5K rows). REQUIRED in the grain key because the same plan-section repeats across a year's quarterly releases — this is the SNAPSHOT axis, NOT a within-year time period. There is no is_current flag.
observed_perioddateDate = always January 1 of report_year (derived, not independent). Marks the start of the observation/benefit year. One distinct value per report_year; carries no information beyond report_year.
asserted_atdateDate Vlada parsed/loaded the row — all values fall 2026-05-16 to 2026-05-20 regardless of benefit year. This is an INGESTION/bitemporal timestamp, NOT a CMS publication date. Do NOT use it to order CMS revisions or pick the latest snapshot; use report_year/quarter for that.
effective_period_startdateDate = January 1 of report_year. Start of the annual coverage window the VBID offering applies to. Derived from report_year; the profiler picked this as the time column but it is fully determined by report_year (annual).
effective_period_enddateDate = December 31 of report_year. End of the annual coverage window. Always a full calendar year [Jan 1, Dec 31] of report_year. Derived from report_year.
cms_vintage_sequenceintInt 1-4, a CMS release-sequence index that roughly tracks the quarter ordinal within a year but is NOT a clean 1:1 (vintage 2 spans q1&q2, vintage 4 spans q1&q4). Functionally determined by the grain — adding it does NOT increase row distinctness. Use quarter, not this, to identify the release.
parse_revisionintInt parser-version that produced the row: 1 (49,817 rows) or 2 (122,224 rows). Provenance/lineage of the extraction, not a business attribute. Functionally determined by the grain (no per-grain accumulation of multiple parse revisions).
parser_artifact_hashstringSHA-256 of the parser artifact/code that produced the row (provenance). Lets you tie a row to the exact extractor build. Not a business key.
source_urlstringThe CMS PBP Benefits PUF download URL this row came from, e.g. https://www.cms.gov/.../pbp-pufs/pbp-benefits-2019-q3.zip. Exactly one URL per (report_year, quarter) — confirms the underlying source is the CMS Plan Benefit Package (PBP) Benefits Public Use File.
sha256_content_hashstringSHA-256 content hash of the source file (the .zip), for integrity/provenance and dedup of identical source content. Not a business key.

Query it

describe_data_source(source_fqn="medicare_silver.pbp_vbid_overlay")     # the card, live
query_substrate(sql="SELECT * FROM medicare_silver.pbp_vbid_overlay WHERE contract_id = '<value>' AND plan_id = '<value>' AND segment_id = '<value>' AND parent_section = '<value>' AND vbid_variant = '<value>' AND report_year = '<value>' AND quarter = '<value>' LIMIT 100")
ItemValue
Typed tools that read itnone; raw SQL
Identity keycontract_id
Joinhow_to_join(source_fqn="medicare_silver.pbp_vbid_overlay")
Raw doorAthena (read-only via query_substrate): medicare_silver.pbp_vbid_overlay
NoteGrain-governed; live in Glue / query_substrate. Source family pbp_benefits.

This page as markdown: /docs-md/data/medicare_silver_pbp_vbid_overlay.md · every page in one file: /llms-full.txt