CMS released updated technical guidance (look at the three files with ‘provider directory’ in their file name in the zip file) on May 1, 2026 for the Medicare Advantage provider directory data submission requirement under CMS-4208-F2. There’s a significant technical change described in the memo and artifacts that payers and their vendors need to act on immediately to ensure Medicare Plan Finder can ingest their data.
No More FHIR API Option
As a refresher, CMS wants to ingest up-to-date MA directory data from payers to populate in Medicare Plan Finder (MPF) so that Medicare beneficiaries can search for MA plans with their preferred providers in-network. Previously (in their February 2026 technical guidance), CMS gave MA organizations two paths to submit their provider directory data: 1) A machine-readable JSON file or 2) A FHIR API (PDex Plan-Net compliant)
CMS has revised the ways payers can comply. Payers can no longer rely on the FHIR APIs to comply. The machine-readable JSON option remains as an option. In place of the FHIR API, CMS says that payers can also publish a FHIR-based JSON file: a bulk publish approach, not a dynamic query approach.
Why Did CMS Drop the FHIR API?
They did this for two reasons: to reduce the cost and complexity for payers to publish the data, and to make it easier for CMS to get the data. CMS showed their math in the memo, the FAQ, and the technical guide. To support daily data refreshes via dynamic FHIR queries, CMS would need to hit APIs across 700+ contracts, covering 5,500+ unique MA plans, every single day. That’s an enormous number of requests, and many payers, especially those using third-party API vendors, pushed back on the cost and infrastructure burden.
CMS’s solution: preserve the FHIR resource structure and Plan-Net IG logical relationships, but swap the one-query-at-a-time approach for FHIR Bulk Publish. Under this model, payers export their full provider directory data ahead of time, post the files to a publicly accessible URL, and CMS crawls and downloads them daily. The publisher controls when the extraction runs, what the payload looks like, and how the files are hosted.
This is the same pattern Defacto has been working (alongside Zocdoc, b.well, Optum, and others) to advance for SMART Scheduling Links. It makes a lot of sense for provider directory data at this scale, especially as the mandated query frequency increases (from CMS) as well as demand and interest from others.
FHIR Bulk JSON vs. Machine-Readable JSON: What’s the Difference?
Both formats are JSON. Both are machine-readable. The difference is the schema.
The machine-readable JSON format is based on the schema CMS originally developed for ACA Qualified Health Plans on the Federally Facilitated Marketplace (healthcare.gov). It treats providers and plans as first-class entities, with individuals and facilities as subtypes of providers, but addresses are attributes of providers rather than independent objects. That means you can represent most of the key relationships, but not all of the logical connections that the FHIR model supports. For example, in FHIR, Location is a first-class resource that both practitioners and facilities reference independently, so you can explicitly understand which providers share a location; in the machine-readable format, address is just an attribute of a provider, so that layer of relationship is lost. It was designed for simplicity and marketplace compliance, not FHIR interoperability.
The FHIR-based JSON format uses the PDex Plan-Net IG resource model: Practitioner, PractitionerRole, Organization, OrganizationAffiliation, InsurancePlan, Location, and Network. Resources are linked by logical reference, and the schema carries the full semantic richness of FHIR posted as static files to a publicly accessible URL. CMS and others will crawl the index file, download the constituent resource bundles, and reassemble the relationships during ingestion.
The FHIR bulk files can be segmented across multiple files (recommended max 300MB each, plain JSON — no compression allowed), with an index file listing all constituent URLs. This design borrows from the Transparency in Coverage where a payer publishes an index file that links to all in-network rates files.
What Payers Need to Do Right Now
If you were planning to publish the machine-readable JSON, you’re in good shape. No changes needed.
If you were planning to rely on your existing FHIR API, your work isn’t wasted. Much of the heavy lifting was figuring out where the source data lives and mapping it into FHIR resources, and that work is still necessary to produce the bulk FHIR data. What changes is the delivery mechanism. Talk to your API vendor now: can they produce a static bulk export of the full PDex dataset instead of serving it dynamically? If not, go to your PDM vendor or provider directory vendor and ask whether they can transform the data into either the bulk FHIR format or the legacy machine-readable JSON format. Getting the data into a bulk file is the important step.
On timelines: Nothing has changed. Testing runs May (right now) through August 2026. CMS is hosting a FHIR Connectathon July 14–16, 2026 that will include a track to test PDex Plan-Net bulk publish implementations. Bring your JSON files. Or, at least encourage your API vendor to attend. Folks will be ready to test.
On your FHIR API obligations: this change does NOT get you off the hook for CMS-9115-F. CMS put this in red, bold in the ‘How to Prepare Your Machine-Readable JSON Submission’ document for a reason. The Interoperability and Patient Access rule still requires you to have a publicly accessible Provider Directory FHIR API. If you haven’t implemented that, you still need to. In fact, while you are working on publishing the FHIR JSON file, you should use this as an opportunity to ensure that the API and JSON file align. CMS could theoretically compare the results of your FHIR API with your JSON file and raise questions about deltas.
On access controls: CMS is explicit that these files must be publicly accessible. That means no authentication, no required credentials, no gating. The URL you register in HPMS should be an index file pointing to your FHIR bulk JSON files. Wherever you’re publishing your FHIR API base URLs and your Transparency in Coverage file URLs, add your MPF index file URL there too.
Payer Considerations for the Long-Run
CMS is paying close attention to your data. The channel has changed, but CMS is still going to be pulling your network data daily and using it in a consumer-facing tool. Third parties will be watching too. Your machine-readable files, your FHIR API, and your web-based directory all need to be telling a consistent story.
Get your field mapping right. CMS is prescriptive about what it needs: NPI, name, specialty, address, phone, languages, accepting status, and the specific MA plan identifier (contract number–plan ID–segment ID). If your data doesn’t map cleanly to those fields, your plans won’t show up in Medicare Plan Finder. Not seeing MA products on Medicare Plan Finder may have a tangible impact on member enrollment.
Attestation stakes are real. Your CEO, CFO, or COO has to sign off on the accuracy of this data annually in HPMS. The REAL Health Providers Act requirements are coming right behind Plan Finder requirements. What’s different now is that CMS has the infrastructure for programmatic monitoring and enforcement at scale. Since the files will be more feasible for CMS to crawl daily, they can run programmatic checks on the data daily. This means data quality problems that might have gone unnoticed before are now surfaceable systematically. As you stand up these files, make sure you have a process to assess data accuracy, understand where you stand relative to your market, and be ready to publish CMS-style audit results when that day comes.
Daily updates may be coming. Right now, you’re only required to update your files every 30 days per MA regulations. CMS will crawl daily but use HTTP headers (ETag, Last-Modified) to skip downloads when nothing has changed. But CMS is watching which payers can maintain daily refresh cycles — particularly those doing business in California, where update requirements are already more aggressive. Payers who demonstrate daily update feasibility now are the ones who won’t be caught off guard when CMS mandates it.
This may not stop with Medicare Advantage. Medicaid MCOs are already subject to the same PDex Plan-Net FHIR API requirements under CMS-9115-F. And on April 23, 2026, CMS sent a letter to every State Medicaid Director demanding a comprehensive two-year provider revalidation strategy. This explicitly includes oversight of managed care plan provider directories as a required element. The letter frames accurate, up-to-date provider enrollment data as a foundational program integrity obligation. If CMS’s National Provider Directory ambitions extend across program types, the bulk FHIR publish pattern being established here for MA is likely the template Medicaid MCOs will be building to next (as State Medicaid agencies may seek programmatic monitoring and enforcement methods similar to those being established for Medicare Advantage). The revalidation cycle creates exactly the kind of upstream data trigger that makes a bulk FHIR export tractable: known events, structured data, regulatory obligation to keep it current. Medicaid plans should be watching this closely.