health-data aca technical-guide

Understanding ACA Rating Areas: A Developer's Guide

Mark at Opelyx ·

If you look at two health insurance plans with identical benefits from the same insurer, the premiums can differ by 40% or more depending on where you live. That’s not a mistake. It’s rating areas — the geographic pricing units that the ACA established to give insurers some flexibility without allowing them to price individuals based on health status.

As a developer working with health plan data, rating areas are one of the first things you need to understand. Get this wrong and you’ll silently return incorrect premiums. A user in Tampa and a user in Miami will both be in Florida, but they’re in different rating areas with meaningfully different prices.

What Rating Areas Actually Are

Under the ACA, insurers must file separate rate schedules for each rating area they operate in. The law allows states to define up to a certain number of rating areas, and states took very different approaches.

The simplest approach is one rating area per county. Florida uses numbered rating areas that closely follow county lines, though some group multiple counties together. In practice the mapping is nearly 1:1, which makes the ZIP-to-rating-area lookup relatively straightforward: find the county for a ZIP, look up the rating area for that county.

California went the other direction. Covered California defined 19 rating areas that group multiple counties together into regional pricing zones. The LA Basin (Los Angeles, Orange, and parts of surrounding counties) is one rating area. The San Joaquin Valley is another. This creates a more complex many-to-many relationship between ZIPs and rating areas, because county boundaries and rating area boundaries don’t always align cleanly.

A few states defined rating areas by groups of ZIP codes, which is the messiest situation from a data processing standpoint — no clean geographic hierarchy to follow.

The Critical Gotcha: IDs Are Not Unique

This took me an embarrassingly long time to run into during development, but it’s important: rating area IDs are not unique across states.

Every state has a “Rating Area 1.” Most states have a “Rating Area 2” through at least “Rating Area 15.” Florida’s “Rating Area 1” is Escambia County (Pensacola). Georgia’s “Rating Area 1” is different geography entirely. If you store rating areas with just the ID and look them up without filtering by state, you’ll get nonsense.

In our database, rating area lookups always filter on both state_code and rating_area_id. The primary key in our zip_rating_area table is composite — you cannot query it on rating area ID alone. This is the kind of constraint that saves you from subtle bugs.

FFM vs SBM: The Data Source Difference

The 30 FFM (Federally Facilitated Marketplace) states get their rating area definitions from CMS’s Service Area PUF files. These are clean, well-structured CSVs that map ZIP codes to rating areas with explicit state codes.

The 21 SBM (State-Based Marketplace) states are another story. These states run their own exchanges and publish their own data. Some provide clean rating area crosswalks. Others don’t publish them in a machine-readable format at all — you end up reverse-engineering the rating areas from their rate filings.

California publishes their rating area definitions through Covered California. Colorado uses a different structure through Connect for Health Colorado. New York’s definitions are embedded in SERFF rate filings. Each state required custom handling.

ZIP Code Complexity

ZIP codes are a postal service routing construct, not a geographic boundary. They cross county lines. They cross state lines in rare cases. They change when the USPS restructures mail routes. A small number of ZIP codes span two different rating areas.

For the common case — one ZIP, one rating area — the lookup is simple. The edge cases require a decision: pick the dominant county for that ZIP, or return multiple possible rating areas and let the caller decide.

We use census crosswalk data as a reference, combined with our own ZIP-to-county-to-rating-area table in D1. When a ZIP spans counties, we assign it to the county that covers the largest residential population percentage. This gets the right answer for probably 99.5% of real users — someone living in a ZIP that crosses a county line is almost certainly on the dominant-county side of it.

How the API Handles This

The /v1/health/zips/:zip endpoint does the full resolution. It returns a HAL-format response with hypermedia links and a locations array that accounts for ZIPs spanning multiple rating areas:

{
  "_links": {
    "self": {
      "href": "https://api.opelyx.com/v1/health/zips/33101?year=2026",
      "type": "application/json"
    },
    "search": {
      "href": "https://api.opelyx.com/v1/health/plans{?zip,age,year}",
      "templated": true,
      "type": "application/json",
      "title": "Search plans for this ZIP"
    }
  },
  "zip": "33101",
  "locations": [
    {
      "state": "FL",
      "county_fips": "12086",
      "county_name": "Miami-Dade County",
      "rating_area_id": "Rating Area 11"
    }
  ]
}

Note that rating_area_id carries the full string (e.g. "Rating Area 11"), not just the numeric suffix. The locations array is usually a single entry but can contain multiple entries for the small number of ZIPs that genuinely span county or rating area boundaries. A legacy singular URL (/v1/health/zip/:zip) redirects with a 301 to the plural form.

When you call the plan search endpoint with a ZIP, we resolve the rating area internally and use it to filter plans and fetch the correct rate records. You never have to think about rating areas unless you want to.

The data flow is:

  1. ZIP -> state + county (from our D1 crosswalk table, with CMS Marketplace API as fallback for any ZIP not yet in our database)
  2. State + county -> rating area ID (from our zip_rating_area table)
  3. Rating area ID + state + metal tier + plan type -> matching plans with correct rates

Step 2 is where most implementations go wrong. Either they drop the state filter (returns wrong results silently) or they skip the entire lookup and try to match plans directly to ZIPs (which only works for states with one rating area per ZIP, and breaks everywhere else).

An Example: Colorado

Colorado is instructive because it’s a mid-complexity SBM state. Connect for Health Colorado defines 9 rating areas covering the state’s 64 counties. The Front Range (Denver, Boulder, Fort Collins, Colorado Springs) is split into multiple rating areas despite all being adjacent metro areas. Rural eastern Colorado is its own region.

I pulled the rating area definitions from Colorado DOI SERFF filings, cross-referenced against the Covered Colorado plan data, and ended up with a manually-validated crosswalk. The CMS PUF doesn’t include Colorado at all — it’s SBM-only, so if you’re relying purely on federal data you have zero Colorado coverage.

That’s the broader point: building a genuine 51-jurisdiction health plan API isn’t just about processing CMS files. It requires state-by-state research into where each state publishes its data, in what format, and how complete it is. We’ve done that work so you don’t have to.

Back to all posts