Medicare Part B Drug Spending (by HCPCS × year)

What it is

1. 1A clean (silver-tier) Medicare Part B Drug Spending dashboard: CMS's annual public-use file (PUF) of total Medicare Part B spending and utilization, one row per HCPCS-coded drug/biological per calendar year (2019-2023), as published in CMS Release Year 2025 (data through 2023).
2. 2It is a Medicare reference/benchmark dataset for what Medicare paid for physician-administered (Part B) drugs by drug, used to benchmark drug cost, utilization, and price trends.

Grain

How to read it

1. 1Benchmark a Part B drug's Medicare cost and trend.
2. 2Example: SELECT data_year, total_spending_usd, total_beneficiaries, avg_spending_per_dosage_unit_usd FROM drug_silver.fact_drug_spending_part_b WHERE hcpcs_code='90670' ORDER BY data_year; answers 'how did Medicare spending and per-unit price for Prevnar 13 move 2019->2023?' (spending collapses $389M->$14M as Prevnar 20 displaces it, while per-unit price rises).
3. 3For a code's headline 2023 ASP price and long-run growth, read avg_dy23_asp_price_usd and cagr_avg_spending_per_dsg_unt_19_23_pct from any single row of that code (they're constant).
4. 4To rank top Part B drug spend: SELECT hcpcs_code, hcpcs_description, total_spending_usd FROM ...
5. 5WHERE data_year=2023 ORDER BY total_spending_usd DESC.

Traps

1. 1avg_dy23_asp_price_usd, chg_avg_spending_per_dsg_unt_22_23_usd, and cagr_avg_spending_per_dsg_unt_19_23_pct are NOT per-year values — they are single full-period / 2023-snapshot trend figures stamped IDENTICALLY onto all 5 year-rows of a code (verified on Prevnar 13: total_spending falls 389M->14M across years while these three stay 257.99 / 0.0026 / 0.041). For a per-year price use avg_spending_per_dosage_unit_usd; only read the three trend columns once per code (e.g. WHERE data_year=2023).
2. 2The grain is (hcpcs_code, data_year) = 3,164 rows. Do NOT add hcpcs_description/brand_name/generic_name or any provenance column to a join/dedup key — descriptions/names are constant per code and every provenance column (source_id, source_url, sha256, bronze_object_key, s3_version_id, cms_vintage_sequence, parse_revision, asserted_at, vintage_tag) has exactly ONE value across the whole table. The profiler's 9-column 'verified grain' is a padded superset.
3. 3CMS privacy suppression: rows with <11 claims/beneficiaries are dropped by CMS, so total_claims and total_beneficiaries floor at 11 and low-volume drugs are MISSING entirely (absence != zero spending). Also each year has a different drug roster (559 codes in 2019 -> 734 in 2023), so a code missing in an early year may simply not have existed/met threshold then.
4. 4Nulls carry meaning: generic_name null (~8%) = vaccine/biologic/blood product with no listed generic; chg_22_23 null = no 2022 baseline; cagr_19_23 null = no 2019 baseline (i.e. newer drug). Do not coalesce these to 0.
5. 5This is a single CMS Release-Year-2025 vintage (asserted_at=2025-04-30, data through 2023), loaded once: is_current is true for all rows and cms_vintage_sequence=1, so the bitemporal columns are present but inert. Don't assume multiple vintages exist. data_year/observed_period/effective_period_start/effective_period_end are 1:1 redundant — pick one (data_year) for filtering.
6. 6Percent columns are FRACTIONS not percentages despite '_pct'/'_usd' suffixes: cagr 0.041 = 4.1%, chg_22_23 -0.045 = -4.5% (the chg column name says _usd but the values are ratios). This is Medicare-paid (allowed) amount data, NOT commercial or list/AWP price — pair with the commercial substrate to compute commercial-to-Medicare drug ratios.

Columns (31)

Query it

describe_data_source(source_fqn="drug_silver.fact_drug_spending_part_b")     # the card, live
query_substrate(sql="SELECT * FROM drug_silver.fact_drug_spending_part_b WHERE hcpcs_code = '<value>' AND data_year = '<value>' LIMIT 100")