Summary

Starting with Contract Year (CY) 2027, CMS requires every Medicare Advantage organization to make its provider directory available to Medicare Plan Finder (MPF), the tool CMS runs for beneficiaries to shop and compare Medicare plans. The goal is to better enable Medicare beneficiaries and their caregivers to find the right plan that supports their needs. starting Contract Year (CY) 2027. RevSpring offers this feature to any client who subscribes to their Provider Directory offering, by building the data files CMS needs and keeping them continuously available for CMS to retrieve.

In one sentence:  CMS pulls provider directory data into Medicare Plan Finder by crawling a MPF Provider Directory URL(s) each health plan enters into HPMS; RevSpring builds, hosts, and maintains these URL(s) and the necessary FHIR-base JSON file(s) on the client's behalf.

1. The CMS Program

The Centers for Medicare & Medicaid Services (CMS) finalized a rule — CMS-4208-F2 — requiring Medicare Advantage organizations to submit provider directory data to CMS for publication on Medicare Plan Finder. The goal is straightforward: give beneficiaries and their caregivers accurate, current, in-network provider information directly inside the same tool they use to shop and compare Medicare plans.

Who Must Participate

The requirement applies to all individual (not employer-only) MA plans:

• Local Coordinated Care Plans (CCP) — HMO, HMO-POS, and Local PPO
• Regional PPO plans
• Medical Savings Account (MSA) network-based plans
• Private Fee-for-Service (PFFS) network-based plans

What Health Plans Must Provide

Each MA organization must make its complete, current provider and facility directory available to CMS, in one of two accepted formats:

• Machine-Readable JSON files, or
• FHIR-based JSON files (built to the HL7 Da Vinci PDex Plan-Net Implementation Guide, version 1.2.0)

Plans are responsible for the accuracy of this data and must formally attest to it annually, through an authorized officer (CEO, CFO, and/or COO), in HPMS.

2. How Data Actually Gets to Medicare Plan Finder

CMS does not accept files directly or query health plan FHIR APIs in real time. Instead, each health plan is responsible to publish plan directory data at a dedicated, publicly accessible URL, and CMS retrieves it on a recurring schedule.  These URLs are defined on a per CMS Contract Number/Contract year basis and entered into a plans HPMS system:

• The published, MPF Provider Directory URL(s), points to an index files, a manifest listing every constituent JSON file that makes up the complete directory for a given CMS Contract Number/Contract Year.
• CMS crawls each plan's MPF Provider Directory URL(s) daily, generally overnight Eastern Time, with validation results available in HPMS by mid-to-late morning.
• The Directory data must be refreshed at least every 30 days; CMS does not support incremental updates and each crawl reflects the complete, current state of the directory.
• CMS validates technical and structural compliance only (is the URL reachable, is the file well-formed, are all required fields present) — not the underlying accuracy of the data itself. That responsibility stays with the health plan.

Note: This model was not CMS's original design. CMS initially planned to query each health plan's live systems directly and in real time; in February 2026, CMS moved to this static, file-based, index-URL approach instead, citing the operational cost of querying 700+ contracts on demand every day.

3. How RevSpring Supports This Program

RevSpring acts as the data and technical partner between a health plan's provider data and CMS's Medicare Plan Finder requirements. For each client, RevSpring:

• Builds FHIR-based JSON files from the client's provider directory data, structured to CMS's technical specifications
• Generates and hosts the index file(s) and MPF Provider Directory URL(s) for every contract number / contract year combination the client offers
• Ensures that URL is continuously public, reachable, and current for CMS's nightly crawl
• Refreshes the underlying data on a daily basis, well ahead of CMS's 30-day minimum
• With CMS validation reports provided by clients, provide guidance on how to resolve issues
• Provides the client with the MPF Provider Directory URL(s) to enter into their own HPMS system

What This Requires From the Client

RevSpring can only build accurate directory files from accurate source data. In exchange, each client is responsible for:

• Supplying a Network Crosswalk File that maps their provider network information to their CMS contract, plan, and segment IDs
• Entering the MPF Provider Directory URL(s) RevSpring provides into their own HPMS system by navigating toe the MPF Provider Directory Module and opening the “Manage MPF Provider Directory URLs” page
• Sharing any CMS validation feedback with RevSpring so that they can be reviewed and act on any necessary corrections
• Completing the annual CMS attestation confirming the data's accuracy

4. Program Timeline

Looking Ahead: Phase III and the National Provider Directory

MPF Phase II is CMS's near-term solution for getting provider directory data into Medicare Plan Finder. It is explicitly a bridge, not the end state. CMS has announced plans to build a National Provider Directory (NPDir) — a public, all-payer directory that sits at the center of how provider data flows across the healthcare system, not just for Medicare Plan Finder.

• NPDir will be powered by FHIR-based APIs, aligned with the same HL7 Da Vinci PDex Plan-Net standard that underlies today's Phase II data.
• Rather than CMS crawling static index files per contract, Phase III envisions NPDir directly ingesting each health plan's FHIR API and redistributing that data — including feeding Medicare Plan Finder itself.
• CMS has indicated an initial beta of NPDir, with iterative rollout to follow; specific validation criteria and onboarding timelines have not yet been finalized.

Because RevSpring's Phase II approach is already built on FHIR-based JSON and the same underlying Plan-Net data model, the work being done today positions clients well for that eventual transition — the data structure carries forward, even as the delivery mechanism moves from a crawled index file to a live, standard-based FHIR exchange.