What it does, and why it's here
Provider Directory isn't a CMS-0057-F requirement. Medicare Advantage organizations and Medicaid/CHIP managed care plans have had to publish a public, machine-readable directory of their provider network, practitioners, locations, and network affiliations, since the 2020 Interoperability and Patient Access final rule (CMS-9115-F).
It's a query-only API by design: no authentication, and no consumer-identifying information required to search it. A member's app, a provider's system, or a plan-comparison tool can look up who's in a plan's network without being credentialed first.
CMS-0057-F doesn't touch this requirement directly, but it raises the stakes on the data behind it. The new Provider Access API has to verify that a provider calling in is actually in-network for the specific member they're asking about, and that check runs against the same underlying network and attribution data this directory exposes.
Who uses it
Any public consumer looking up network participation directly: member-facing apps, provider systems doing their own network checks, and plan-comparison or directory tools.
Internally, it's also the system of record the Provider Access API's own in-network attribution logic has to stay consistent with. If the directory is stale, that mismatch shows up as incorrectly granted or denied access on the newer API, not just a wrong phone number in a member's app.
Technical standards
| Standard | Version | Notes |
|---|---|---|
| HL7 FHIR | 4.0.1 | Base data format, shared with every other API on this site. |
| Da Vinci PDex Plan-Net | STU 1.1 | The implementation guide this API is built on: Practitioner, PractitionerRole, Organization, Location, and OrganizationAffiliation resources describing the network. |
| US Core | R4 | Base resource profiles Plan-Net's own profiles build on. |
The compliance risk moved, even though the mandate didn't
This requirement predates CMS-0057-F, but stale or incomplete provider directory data is now also a Provider Access API problem: attribution built on bad network data means either blocking a legitimate in-network provider or granting access to one who shouldn't have it.
Previous API
Provider Access API
A new FHIR endpoint that lets a member's in-network provider pull that member's payer-held data directly, instead of chasing it by fax.
Read it →Next API
Payer-to-Payer API
Moving a member's data from their old payer to their new one automatically, with consent, instead of it just disappearing when they switch coverage.
Read it →Ready to see where you stand?
Every requirement on this page is one line item in our free CMS-0057-F readiness survey.