Medicare Enrollment
Medicare Enrollment

Medicare Plan, Formulary, and Provider Data from Medicare.gov

Pull structured Medicare plan data for a ZIP code straight from the CMS Medicare Plan Finder on Medicare.gov: available MA, MA-PD, and PDP plans with premiums, deductibles, and star ratings, drug-by-drug formulary and cost detail, and provider-directory checks, returned as clean JSON. Read-only, no login, no credentials.

Go-live in as little as 30 minHybridPublic source

See it run on your systems.

We map your process, volume, and exception paths, then recommend a practical first scope.

Scope this workflowSee how it works ↓

Building internally? Read the docs →

Overview

What this workflow does

Medicare.gov’s Plan Finder is the authoritative public source for what plans exist in a county and what they cost, and this workflow turns it into a data feed. Give it a ZIP and it resolves the county, pulls the available plans filtered by type and year, and enriches the result with the details that actually drive plan conversations: the tier, yearly cost, and coverage status of each named drug, whether a named provider is in network and how far away, and formulary notes. Zero plans in a ZIP, an unmatched drug, or an unfound provider are reported as what they are, never papered over.

Technically it’s the catalogue’s hybrid: a browser agent that drives Medicare.gov’s own Plan Compare APIs from inside the site’s browser session rather than scraping the rendered pages. Same origin, same data the site itself displays, but structured at the source, which is both faster and more faithful than reading pixels.

How Asteroid runs this workflow

A ZIP code turned into a complete plan-comparison dataset

A ZIP, drug list, providers, and comparison assumptions arrive, Asteroid pulls the plans, formularies, and network checks from Medicare.gov's own Plan Finder, and the structured dataset comes back, with any enrichment that didn't resolve named in the output rather than papered over.

Medicare.gov Plan Finder

How it actually runs

  1. 01Resolve the ZIP to its county, since Medicare plan availability is a county-level fact.
  2. 02Pull the available plans for the county, year, and plan type requested, up to your requested limit, with contract ID, plan ID, organization, premiums, deductible, out-of-pocket maximum, and star rating per plan.
  3. 03Enrich with drug detail for each named drug: tier, estimated yearly cost, and covered-or-not, per plan.
  4. 04Check each named provider against plan directories: NPI, specialty, distance, address.
  5. 05Return the structured result with a total-plans count and a summary. If the plan list landed but an enrichment didn’t, the output says exactly which part is missing.

ZIP code, drugs, providers, pharmacies, and comparison assumptions are supplied

  6. A comparison dataset for your tools

    Structured plan, formulary, provider-network, pharmacy, premium, and cost data for the requested scenarios lands wherever your quoting or decision-support tools consume it.

Enrichment that doesn't resolve: An unmatched drug, an ambiguous provider, or stale source data is named in the output for a person to resolve once, and plan recommendations remain outside the automated pull entirely.

Closing the loop

What lands back in your system

Nobody on your team reads this JSON. Your system does. Each run delivers its record wherever the work already lives, and the loop closes on its own: requests in, records back, no one in the middle.

structured output · json
{
  "geography": {
    "zip": "30303",
    "county": "Fulton",
    "state": "GA",
    "fips": "13121"
  },
  "total_plans_available": 42,
  "plans": [
    {
      "contract_id": "H••••",
      "plan_id": "001",
      "plan_name": "Example Advantage (HMO)",
      "plan_type": "MA-PD",
      "partd_premium": "$0.00",
      "annual_deductible": "$545",
      "max_oopc": "$5,900",
      "star_rating": 4
    }
  ],
  "rx_costs": [
    {
      "drug_name": "atorvastatin 40mg",
      "tier": 1,
      "yearly_cost": "$42.00",
      "covered": true
    }
  ],
  "providers": [
    {
      "npi": "1•••••••93",
      "name": "SAMPLE, JANE MD",
      "specialty": "Family Medicine",
      "distance": "2.4 mi"
    }
  ]
}
Delivered toYour APIWebhooksGoogle SheetsSlackEmailAll integrations →

Partial success that says so beats complete-looking data that isn’t.

Data pipelines fail worst when they fail quietly: a plan list that silently dropped the drug costs looks identical to one that never had them. This workflow reports partial success as a first-class outcome, the plans arrived, this specific enrichment didn’t, by name. If you’re putting plan data in front of a beneficiary or an agent, knowing what you don’t have is as load-bearing as what you do.

At scale

The public-data end of the pipeline

This is the public-data end of the Medicare pipeline: it feeds quoting conversations and decision-support tools, pairs with logged-in multi-carrier quoting on your agency’s platform, and hands off to enrollment submission once a decision is made. Category view: the Medicare enrollment library.

Book a demo, watch a ZIP turn into plan data

Human in the loop

What escalates to a human

This workflow reads public government data and handles no member records; runs still execute on SOC 2 Type II infrastructure with per-execution audit trails, documented on the security page.

Nothing requiring credentials or consent.

There’s no login and no PHI requirement; ZIP, drug names, and a provider name are the whole input surface.

An enrichment that doesn’t resolve.

An unmatched drug or provider is named in the output rather than guessed at.

A Plan Finder change.

If CMS reshapes the underlying flow, the run fails with what it saw instead of returning stale-shaped data.

Questions

Frequently asked questions

The inputs and enrichments are yours to shape: plan year and plan type filters, a requested plan limit, the named drugs to price per plan, and the providers to check against plan directories. The output shape is stable JSON (geography with county and FIPS, plans with contract ID, plan ID, premiums, deductible, out-of-pocket maximum, and star rating, plus rx_costs and providers blocks), so your downstream tools parse one format. What never changes: it stays read-only, credential-free, and county-resolved, because plan availability is a county-level fact.

Every Medicare tool that shows plans is downstream of this data; the difference is whether a person fetched it. The Medicare enrollment library covers what happens after the lookup.

Book a demoMap this workflow

Disclaimer

Third-party names, including government agencies and registries, are used only to identify systems commonly involved in healthcare operations workflows. Asteroid is not affiliated with, endorsed by, sponsored by, or certified by those third parties unless expressly stated. Workflow availability depends on customer authorization, account permissions, configuration, and applicable system terms.