A technical guide to the Provider Directory API under CMS-0057-F 

Of the five APIs required under CMS-0057-F, the Provider Directory API is the most straightforward to understand. The requirements are clear, the FHIR resources are well-defined, and most payers have some version of a provider directory already. In most of the implementations I work on, it’s the one teams assume is finished when it isn’t. 

But that doesn’t mean it’s easy to get right. The technical implementation is manageable. The operational challenge (keeping the data accurate, current, and accessible) is where most of the difficulty sits. 

This guide covers the new CMS-0057-F requirements for the Provider Directory API, the Plan-Net 1.2.0 migration, and the data freshness and governance questions that tend to cause problems in practice. 

It’s a longer read, but if you’re working through the migration or building the data pipeline, there’s enough detail here to be worth going through in full.

What CMS-0057-F requires 

The Provider Directory API must be publicly accessible, with no authentication required, and must return provider data conformant with the Da Vinci PDex Plan Net Implementation Guide.  

The requirements are: 

1. Conformance with Plan-Net 1.2.0 (up from Plan-Net 1.1.0 in the original CMS-9115 requirement) and US Core 6.1.0 

2. Data updated within 30 calendar days of a change: provider additions, removals, and attribute changes all need to be reflected within that window 

3. Public accessibility without requiring end-user authentication or app registration 

4. For Medicare Advantage and MA-PD plans: pharmacy data must be included, covering pharmacy locations, hours, types, and the drugs covered under the plan’s formulary 

The 30-day update requirement was already in place under CMS-9115. What CMS-0057-F adds is the IG version migration.

The IG migration: the changes that will break your implementation 

The migration from Plan-Net 1.1.0 to Plan-Net 1.2.0 was due earlier this year (January 1, 2026). If you haven’t done it yet, you may not be fully compliant. The changes go deeper than a version bump. 

Several of them will break a 1.1.0-conformant implementation in ways that won’t show up in manual testing. IG migrations tend to get pushed down the backlog until something breaks, but this one has enough new changes that it’s worth doing properly.

newpatients extension (PractitionerRole) 

The cardinality changed from a single instance to multiple. A provider can now indicate new patient acceptance by location and network separately. Populating it once still passes validation but may not represent the data correctly.

HealthcareService.category cardinality 

Changed from 1..1 to 1..*. A HealthcareService resource can now carry multiple category values. Any query logic or display code that assumes a single category value will need updating.

HealthcareServiceCategoryVS: ‘OTHER’ removed 

If your source data maps any services to ‘OTHER’ and you’re not handling that in your transformation logic, you’ll produce invalid resources.

Specialty value set updates 

Multiple specialty value sets were updated to reflect changes in the NUCC taxonomy. If your specialty codes were valid under 1.1.0 but aren’t in the updated value sets, your Practitioner and PractitionerRole resources will fail conformance validation. This one tends to catch people off guard. Everything looks fine until you run against the new test scripts.

Bulk export ($export) added 

The IG now explicitly defines how to retrieve inactive and terminated provider records through bulk FHIR API, including how to query for records that changed within a specific time window. If you’re supporting downstream payers or health tech platforms that consume your directory in bulk, this changes the contract.

The US Core 3.1.1 to 6.1.0 migration 

The US Core migration from 3.1.1 to 6.1.0 sits underneath all of this. The Practitioner, Organization, and Location profiles in Plan-Net are built on their US Core equivalents, and both have changed significantly across two major versions. 

Must-support elements have been added, terminology has shifted, and conformance expectations have tightened, all of which can catch existing implementations out. 

The 30-day update cadence: building a pipeline that meets the window 

Thirty days sounds generous until you actually map it out. The problem is rarely one system that’s obviously wrong. It’s that changes have to pass through multiple systems before they reach the FHIR layer, and each handoff adds time. 

A provider terminates their contract. The contracting system updates within a few days. That feeds into the credentialing system a week later. The nightly batch job runs two days after that. You’re already two weeks in and haven’t run FHIR validation yet. It always looks fine on paper until you map the actual systems. 

A pipeline that reliably meets the 30-day window has a few important characteristics:

Event-driven triggers 

Nightly batches are too slow for changes that happen late in the day, and may miss updates entirely if a job fails silently, and cannot guarantee that a patient or user has accurate information when they need it most to make a care decision. The contracting or credentialing system should trigger an update when a provider record changes, which then kicks off the FHIR update pipeline directly.

A single source of truth per attribute 

If both the credentialing system and the contracting system can update a provider’s practice location and they disagree, your FHIR resource will reflect whichever one ran last. You should be clear on which system owns which attribute before you build the pipeline.

Record-level timestamps 

Every FHIR resource should carry a timestamp for when it was last updated from source, separate from meta.lastUpdated. meta.lastUpdated reflects when the FHIR server last touched the resource, not when the underlying provider data changed. You need both.

Independent monitoring 

A monitoring layer that runs independently of the pipeline itself, querying for resources whose source-update timestamp is approaching the 30-day window without a confirmed update. You want to know before the deadline passes, not after.

Non-contract change events 

Location updates, phone number corrections, and changes to whether a provider is accepting new patients often come through provider relations teams or self-service portals rather than formal contract events. These need to feed into the same pipeline with the same SLA, not sit in a manual update queue that nobody’s tracking against a 30-day window.

The _since parameter and downstream consumers 

Plan-Net 1.2.0 also formally added support for querying changed resources using the _since parameter in $export. If downstream systems rely on this to keep their own copies of your directory current, your pipeline needs to be accurate enough that a _since query returns a complete set of changes, not just the records that made it through the main pipeline on time.

Public accessibility: what it means in practice 

The Provider Directory API must be accessible without end-user authentication: no OAuth token, API key, or app registration. This occasionally trips teams up if the API was originally built behind an auth layer that needs to be stripped back. 

Also confirm that your bulk data export endpoint ($export) is accessible and returns data in NDJSON format. Bulk access is how most downstream systems will consume your directory, and it’s frequently tested less thoroughly than the individual resource endpoints.

Pharmacy data for MA-PD plans 

If you’re a Medicare Advantage Prescription Drug plan, CMS-0057-F requires pharmacy data to be included in your Provider Directory API. This covers pharmacy locations and contact information, pharmacy types, hours of operation, and formulary drug coverage. 

The areas that tend to create problems: 

1. Formulary data modeled correctly in FHIR: the Da Vinci PDex Formulary IG defines how drug coverage should be represented, and it’s easy to produce something that looks right but fails conformance validation 

2. Pharmacy hours and type data that’s accurate and current: this often lives in systems that don’t have a natural update trigger when a pharmacy changes its hours or closes 

3. Linkage between the InsurancePlan resource and the associated HealthcareService and Location resources: the links between these resources are often missing or broken 

Testing and validation 

Testing a Provider Directory implementation has two layers: conformance validation and operational accuracy. Touchstone covers the first: use the Plan-Net 1.2.0 test scripts, and make sure you’re testing against real data, not just synthetic examples. 

For operational accuracy, a few things worth including: 

• Test bulk export with a realistic data volume: performance issues with $export often only show up at scale 

• Validate that terminated providers are removed or marked inactive within the 30-day window, not just whether new providers are appearing correctly 

• For MA-PD plans, validate formulary data against at least a sample of your actual formulary to confirm the FHIR representation is accurate, not just technically conformant 

• Test the unauthenticated access path explicitly, from outside your internal network: it’s the first thing I check when reviewing a Provider Directory implementation, and it’s surprising how often that step gets skipped 

If working through all of this sounds like a lot – it is. Firely Server handles the FHIR layer out of the box, including Plan-Net 1.2.0 conformance, bulk export, and public accessibility. 

If you’re working through where your current implementation stands, the CMS-0057-F Readiness Checklist covers the Provider Directory requirements alongside the other four APIs. And if you want to talk through your situation, get in touch.