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.
Overview
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.
Step by step
Structured output
Every run ends as a record like this in your system, not a portal screenshot someone transcribes. This is the part your team stops doing by hand.
{ "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" } ]}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
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.
Human in the loop
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
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.
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.