Your provider directory is about to become a public exhibit. Here's how not to fail the audit.

Starting October 1, 2026, when a Medicare shopper looks up a plan on Medicare Plan Finder, they'll be able to see whether their doctor is in-network — before they enroll. That's a win for beneficiaries. For plans, it's a new obligation with a hard deadline, an executive signature, and a penalty that can make your entire network vanish from the shopping site during open enrollment.

CMS just released the updated Technical Implementation Guide for supplying MA provider directory data to Medicare Plan Finder (MPF), dated August 14, 2026. If you run individual MA plans, this is a build project, not a memo to file. Here's what it requires, what changed in this revision, and where plans are most likely to trip.

Reference: CMS, "Technical Implementation Guide for Supplying Medicare Advantage (MA) Provider Directory Data for Use in Medicare Plan Finder (MPF)," August 14, 2026. Rule basis: CMS-4208-F2, § 422.111(m).

The quick map: publish your in-network directory · pick 1 of 2 formats · host it publicly · CMS crawls it daily · production Oct 1, 2026 · attestation due Sept 1

What this actually is

CMS is putting provider directories inside Medicare Plan Finder — the tool people use on medicare.gov to compare plans. The goal is straightforward: let shoppers and their caregivers see whether specific providers and facilities are in-network while they're choosing a plan, not after.

The legal basis is the CY 2026 final rule (CMS-4208-F2), which added § 422.111(m). Under it, MA organizations must make their directory data available to CMS for online publication, submit it in CMS's format, update it within 30 days of learning about a change, and attest at least annually that it's accurate.

Who's on the hook: all individual (not employer-only) MA plans — Local CCPs (HMO, HMO-POS, Local PPO), Regional PPOs, network-based MSA plans, and network-based PFFS plans.

The three phases — so the timeline makes sense

CMS is rolling this out in stages. Knowing which phase you're in prevents a lot of confusion:

  • Phase 1 (CY 2026) — an interim stopgap. CMS partnered with a vendor (SunFire) to supply data, or plans simply pointed CMS to an existing directory URL. Temporary.

  • Phase 2 (CY 2027) — this is the one that's live now. Plans publish their own structured data files. Everything below is Phase 2.

  • Phase 3 (future) — a full National Provider Directory built on FHIR APIs, which CMS began developing in 2025. The long-term destination.

That Phase 3 detail matters for a decision you're about to make — keep it in mind.

The core requirement: publish, host, get crawled

For Phase 2, the mechanics are the same no matter which format you choose:

  1. You build your in-network directory as structured data files.

  2. You host them at a public URL — no login, no authentication.

  3. You record that URL in HPMS.

  4. CMS crawls it every day, validates it, and publishes the passing data to MPF.

One rule sits above all of this, in bold in the guide itself: only current, in-network providers and facilities may be included. This is a live network directory, not a historical roster.

The concept people miss: the index file

You don't hand CMS one giant file. You host an index file — a small JSON manifest — plus one or more data files containing the actual records.

The index file must contain a top-level provider_urls array listing the URLs of every data file. The URL you enter in HPMS points to the index, and CMS follows it to find everything else.

The critical constraint: you maintain one index per contract number + contract year combination, and that index must list only the files for that same contract/year. Cross-wiring contract years in a single index is a structural error.

Pick your format deliberately: machine-readable vs. FHIR

Plans choose one of two publishing formats. They are not equal, and the choice has a strategic dimension.

Option 1 — Machine-readable JSON. A simpler, custom CMS format modeled on the ACA Marketplace's directory files but adapted for MA. Easier to stand up. But the guide is explicit: this is a temporary option, and "all MA plans are expected to migrate fully to FHIR."

Option 2 — FHIR-based JSON. Built on the PDex Plan-Net Implementation Guide v1.2.0 (HL7 FHIR R4). More complex to implement, but it's the standard the National Provider Directory will run on. If you already built provider-directory FHIR APIs for the 2020 Interoperability and Patient Access rule (CMS-9115-F, required by July 1, 2021), you are closer to this than you think.

The honest read: machine-readable gets you to the October deadline faster; FHIR is where everything is heading. Choosing machine-readable now means doing this work twice. Choosing FHIR now is the harder lift but the last one. (One hard constraint if you go FHIR: XML-based FHIR is not supported — JSON only.)

Whichever you pick, one relationship is non-negotiable: every provider and facility must be explicitly linked to a unique MA plan, identified as [Contract]-[Plan]-[Segment] — for example, H9999-001-001, with 000 denoting a non-segmented plan. In FHIR, that link runs through the network field. Get this wrong and MPF can't tell which plan a provider belongs to.

The deadlines that actually matter

Here's the Phase 2 schedule, with the two dates that carry consequences in bold:

  • May 4 – mid-September 2026 — plan testing period (extended in this revision).

  • September 1, 2026 — CY 2027 attestation due in HPMS.

  • Early September 2026 — plan preview window.

  • September 18, 2026 — "target" deadline for production-ready CY 2027 data.

  • October 1, 2026 — production release of the CY 2027 MPF.

Notice the trap: the attestation is due September 1 — before the September 18 production-ready target. Your executives are signing off on the directory's accuracy before the data is even finalized for production. Build your internal review so the thing being attested on the 1st is genuinely done, not a placeholder you plan to fix by the 18th.

Two stakes worth escalating to leadership

This isn't purely a technical exercise. Two provisions belong in front of your executive team.

The attestation carries named-officer liability. It must be completed in HPMS by an authorized official — specifically the CEO, CFO, and/or COO — attesting the directory is "accurate, complete, and truthful at the time of the attestation to the best information, knowledge, and belief of the MA organization." That's a personal signature from a named executive, not an analyst ticking a box.

Suppression is the real penalty. CMS will suppress your provider directory on MPF if you fail to attest, if validation produces fatal errors, or if data-quality issues exceed a published threshold. In plain terms: during the exact window when beneficiaries are shopping, your network can disappear from the comparison tool. For a plan competing for enrollment, that's not a technical footnote — it's a commercial event. (CMS generally lifts a suppression the day after you resolve the issue.)

For the technical team: how to build it and not fail validation

Everything above is what leadership needs. What follows is for whoever's building the pipeline.

Hosting and HTTP behavior

  • Public, unauthenticated URLs. The Interoperability rule bars any authentication on provider-directory data — CMS's crawler must reach it with no credentials.

  • Plain, uncompressed JSON only. This revision makes it explicit: the crawler rejects NDJSON and any compressed files. If your server auto-gzips responses, that's a silent failure — turn it off for these paths.

  • Serve proper headers: Content-Type: application/json, Content-Length, Last-Modified, and ETag. CMS uses ETag/Last-Modified (weak validators are fine, e.g. W/"abc123") to skip re-downloading unchanged files. Support HEAD and conditional requests (If-None-Match, If-Modified-Since) so unchanged files return 304 Not Modified. (Full detail in Appendix D.)

Run the self-validation checklist first

This revision adds a Self-Validation Steps section — treat it as your pre-flight. Before you rely on CMS's crawl:

  1. Paste the index URL into a browser; confirm it returns raw JSON with a provider_urls array.

  2. Validate the JSON syntax of the index and every constituent file.

  3. Confirm every URL in provider_urls is publicly reachable from an outside network, no auth.

  4. Confirm responses include Content-Type: application/json, Content-Length, Last-Modified, and ETag.

  5. Confirm the server is not compressing files.

  6. Confirm every record reflects the current contract year — year (machine-readable) or InsurancePlan.period (FHIR).

The format specifics

Machine-readable (Appendix A). A JSON array of provider/facility entries. Required top-level fields: npi, type (Individual/Facility), plans, lastUpdatedOn (ISO YYYY-MM-DD). One entry per NPI — if a provider has multiple NPIs, split them. The plans sub-type carries maPlanId (the H9999-001-001 format), year (array, but supply only one contract year for MPF), addresses, and specialty (NUCC codes). This revision refined the accepting field definition and the network field name.

FHIR-based (Appendix B). Package data as FHIR resource bundles. CMS consumes seven resource types: InsurancePlan, Location, Organization (Network), Organization (Facility), OrganizationAffiliation, Practitioner, and PractitionerRole. The provider-to-plan link runs through the network field, tied back to InsurancePlan. This revision clarified that InsurancePlan.period.start should be the first day of the contract year — e.g., 2027-01-01 for CY 2027 — and added a facility phone number path. (Appendix C's UML was updated to match; the sample bundle CMS ships includes one of each resource type.)

Appendix E is your real test plan

The most valuable addition in this revision is Appendix E — the Validation Inventory, the full catalog of error codes CMS's crawler emits. It defines three severity levels, and the hierarchy tells you exactly where to spend effort:

  • Level 1 — Fatal. A structural failure that stops CMS from reading the file: unreachable URL (C4001), bad TLS cert (C4002), invalid JSON syntax (C4004/N3015), zero providers found (P1017), a missing index URL (C4011), a malformed index (C4013). The entire dataset is rejected — nothing from that file shows on MPF.

  • Level 2 — Record-Level. One record is broken while the rest process: missing/invalid NPI (P1001/P1002), invalid plan-ID format (N3002), a broken FHIR reference (F5005–F5008), multiple NPIs on one resource (F5009). That record is dropped from MPF; the rest publish.

  • Level 3 — Informational Warning. A soft flag that still publishes: missing sex (P1010), missing language (P1011), a stale record older than 30 days (C4010). The record shows on MPF, but you should remediate.

The practical rule: drive Level-1 errors to zero first — a single fatal error can take your whole directory off Plan Finder. Level-2 costs you individual providers. Level-3 is cleanup. CMS regenerates the error report (a .csv per contract) after each daily crawl, retrievable in HPMS or via API, usually by mid-morning Eastern.

One boundary worth stating plainly: validation checks structure and completeness, not truth. CMS will confirm your file parses and your NPIs exist — it will not confirm the provider is actually in your network. Data accuracy remains the plan's responsibility, and that's exactly what your CEO/CFO/COO is signing.

Where to send questions

CMS split support by type:

  • HPMS (URLs, validation reports, attestation, previews) → HPMS Help Desk, 1-800-220-2028, hpms@cms.hhs.gov

  • The JSON files & validation results → support@cms-mapnet.zendesk.com

  • The validation API → hpmstechsupport@triafed.com

  • General MPF questions → MPF@cms.hhs.gov

The bottom line

This is the most demanding CMS release in a while — a genuine engineering and governance lift, not a reminder. Three things determine whether you sail through or scramble:

  1. Choose your format with your eyes open. Machine-readable is faster to the October 1 line but temporary; FHIR is harder but future-proof, and it's where the National Provider Directory is going. If you built FHIR for the 2021 Interoperability rule, lean on it.

  2. Treat Appendix E as the spec. The error catalog is your test plan. Build against it, run the self-validation checklist, and get to zero fatal errors well before October 1.

  3. Get the attestation on your executives' calendars now. It's due September 1, it needs a C-suite signature, and failing it — or failing validation — suppresses your network from Plan Finder during shopping season.

The data has to be public, current, correctly linked to each plan, and clean enough to survive a daily crawl. Get those right, and your providers show up for every shopper comparing plans. Get them wrong, and you're invisible in the one place it counts most.

Submission & reportingHealth Data MaxComment