PBP dental (cleaned view)

What it is

1. 1A semantic view over CMS Medicare Advantage Plan Benefit Package (PBP) Section B16 — the DENTAL benefit.
2. 2One row describes how a specific MA plan covers a dental benefit component (overall dental, or the Medicare-covered / diagnostic-preventive / comprehensive sub-benefits): its cost share (copay or coinsurance), frequency/limit, auth & referral rules, and the CMS Mandatory/Optional supplemental-benefit classification.
3. 3It is the dental slice of the broader PBP semantic layer (sibling views like vw_pbp_* exist per benefit), used to answer 'what does plan X charge for dental and how often is it covered'.

Grain

How to read it

1. 1To get each MA plan's overall dental cost share for the 2026 benefit year: SELECT contract_id, plan_id, segment_id, cost_share_string, copay_amount, coinsurance_pct, limit_quantity_per_year, limit_period_label FROM medicare_semantic.vw_pbp_dental WHERE report_year=2026 AND source_pbp_section='B16'.
2. 2This returns one row per plan-segment with the filed dental member cost share and frequency limit.
3. 3For the 2025+ sub-benefit breakdown (Medicare-covered vs diagnostic/preventive vs comprehensive), drop the section filter and read B16A/B16B/B16C rows instead.

Traps

1. 1NOT one row per plan. A 2024-or-earlier plan has 1 dental row (B16); a 2025/2026 plan has 4 (B16 overall + B16A/B/C sub-benefits). You MUST include source_pbp_section in the grain key, and filter to source_pbp_section='B16' (or dental_sub_benefit IS NULL) if you want exactly one overall-dental row per plan. Aggregating cost_share across all sections double-counts.
2. 2version looks like a snapshot/history axis but is NOT — there is exactly one version per (contract,plan,segment,report_year,quarter), already deduped. The real time axis is report_year + quarter. There is no is_current column; dedup to a single bid version has already been done upstream.
3. 3The entire benefit_amount dollar family (benefit_amount, _kind, _period_code, _period_label, _annualized, _pmpm) AND max_oop_applies are 100% NULL in this view — confirmed by numeric_amount_observability='offered_without_numeric_amounts'. Do NOT read a dental dollar allowance/cap from this table; it only carries copay/coinsurance and frequency limits.
4. 4Benefit-type columns are split into TWO families by era: the *_cy2025 columns (comprehensive_cy2025, diagnostic_cy2025) populate ONLY for report_year 2025-2026; the non-suffixed columns (oral_exam, comprehensive_diagnostic, diagnostic, preventive_care) populate ONLY for report_year <=2024 — same Mandatory/Optional concept, different CMS layout. Coalesce across the pair (or filter by year) or you will see spurious nulls.
5. 5Several columns are single-valued constants and carry no filtering power: benefit_category='dental', network_type='in_network', offered_status='offered', source_silver_table, aggregation_policy='separate_components', numeric_amount_observability, annualization_policy, combined_limit_policy, consumer_document_reconciliation_status='not_checked', confidence_tier='source_faithful', and lmi_authorities='' (empty).
6. 6Redundant columns to avoid mistaking for independent dimensions: dental_sub_benefit maps 1:1 to source_pbp_section (adds no grain), and dental_limit_periodicity_label is an exact duplicate of limit_period_label. consumer_document_reconciliation_status='not_checked' everywhere means these are raw bid filings, NOT reconciled against consumer Summary-of-Benefits documents.

Columns (107)

Query it

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