Legacy Medicare ZIP → Payment Locality Crosswalk (superseded)

What it is

1. 1The CMS ZIP-code-to-Medicare-payment-locality crosswalk: it maps each U.S.
2. 25-digit ZIP code to the Medicare physician-fee-schedule "carrier locality" that governs how much Medicare Part B pays for a service rendered at that ZIP.
3. 3It is the geographic entry point that turns a provider/patient ZIP into a GPCI region (sibling medicare_gpci_locality) and thus into a locality-adjusted Medicare allowed amount — the cost benchmark used for commercial-to-Medicare ratio analysis.

Grain

How to read it

1. 1Map a provider ZIP to its locality-adjusted Medicare geography, then chain to GPCI for the cost adjustment.
2. 2Example: SELECT z.zip_code, z.locality_name, g.work_gpci, g.pe_gpci, g.mp_gpci FROM medicare_zip_to_locality z JOIN medicare_gpci_locality g ON z.state=g.state AND z.locality_number=g.locality_number AND g.calendar_year=2025 WHERE z.zip_code='10001'; → returns NY / 'MANHATTAN' with work=1.065, pe=1.166, mp=1.656, answering 'which Medicare payment locality and geographic price index applies to a service billed at ZIP 10001'.

Traps

1. 1locality_number is NOT a key by itself (only 15 distinct values, e.g. '99' means 'REST OF <STATE>' in 15 different states). The real Medicare locality identity is (state, locality_number) = exactly 64 distinct combos. Never group or join by locality_number alone.
2. 2is_statewide_locality is BROKEN: false for 100% of rows. Do not use it to detect statewide localities — use locality_number='00' (the actual whole-state code, present in 17 states) instead.
3. 3Four columns are 100% NULL/empty in this snapshot: cbsa_code, cbsa_name, rural_urban_code, and effective_date. The schema lists them but there is no data — do not build logic on them. (The dated, GPCI-bearing version of effective_date lives in sibling medicare_gpci_locality.)
4. 4Single-vintage snapshot: calendar_year is constant 2025 and there is no is_current / version column. created_at, asserted_at, source_file_id, mirror_source are all single constants (load/provenance metadata, not business dates). Treat the whole table as CY2025.
5. 5This table has NO prices or GPCI values — it is purely the ZIP→locality lookup. To get the actual Medicare cost adjustment you must join on (state, locality_number) to medicare_gpci_locality (work/pe/mp GPCI; join is 100% complete — 64/64 localities matched) and then to medicare_physician_fee_schedule. Don't confuse it with its sibling medicare_county_to_locality (county-keyed, used when you have county not ZIP).

Columns (17)

Query it

describe_data_source(source_fqn="medicare_silver.medicare_zip_to_locality")     # the card, live
query_substrate(sql="SELECT * FROM medicare_silver.medicare_zip_to_locality WHERE zip_code = '<value>' LIMIT 100")