The Provider Directory API is the simplest of the four CMS-0057-F APIs on paper and one of the trickiest in production. The PDex Plan Net IG v1.1.0 requires a no-auth public endpoint that exposes the payer's network providers as FHIR Practitioner, PractitionerRole, Organization, Location, and HealthcareService resources. The complexity comes from the upstream data quality, not the API surface. Provider directories are notoriously dirty inside payers, and CMS-0057-F makes the dirt publicly auditable. Here are the implementations that handle this gracefully in 2026. For broader context, the ePA stack reference covers the parallel API layers on this site.
What PDex Plan Net Actually Requires
PDex Plan Net IG v1.1.0 mandates specific resource profiles, search parameters, and conformance behaviors. The endpoint must be no-auth and publicly accessible. The data must reflect the payer's current network with reasonable freshness (CMS does not mandate real-time, but does require an articulated update cadence). The search parameters must support the operations members and providers actually use (find by specialty, location, accepting new patients, network status).
The catch is that most payer provider directories internally have inconsistent specialty codes, stale addresses, and ambiguous network designations. A conformant API exposes these issues to the public.
1. Smile Digital Health (Plan Net Module)
Smile CDR ships a Plan Net implementation that handles the full IG profile set with FHIR-native storage. The strength is the unified data tier; provider data lives alongside claims, eligibility, and attribution data, which simplifies cross-API queries. The trade-off is that the payer still needs to feed Smile clean provider data; the platform does not fix upstream data quality on its own.
2. InterSystems IRIS for Health
InterSystems IRIS handles PDex Plan Net through the broader IRIS data platform. For payers with provider data already in IRIS for other purposes (HIE, population health, claims), the PDex layer extends without a separate data integration. The trade-off is enterprise pricing and longer integration runway typical of IRIS deployments.
3. 1upHealth Provider Directory
1upHealth implements PDex Plan Net with first-class search support and developer-friendly tooling. The platform fits payers whose Provider Directory is consumed primarily by third-party member-facing apps rather than internal systems. The search performance is competitive and the API documentation makes integration for downstream consumers straightforward.
4. Optum Provider Directory (FHIR API)
Optum runs one of the largest commercial provider directories in the US healthcare market and exposes a FHIR-conformant API on top of it. For payers that already source provider data from Optum, the PDex Plan Net layer is a thin extension. For payers without that relationship, the commercial model is a heavier lift but the data quality is competitive.
5. Availity Provider Directory
Availity runs a provider directory network with FHIR Plan Net support. The model is a shared network rather than per-payer hosting, which simplifies the operational pattern for payers with overlapping provider relationships. The trade-off is the network dependency and commercial terms with Availity.
The Data-Quality Problem That CMS Made Public
Provider directories were always messy inside payers; CMS-0057-F made the mess publicly visible. The PDex Plan Net API exposes every stale address, every contradictory specialty code, every provider listed as accepting new patients who actually is not. Members, providers, and regulators can all query the API.
Implementations that handle this well include some data-quality tooling: validation against external sources, change-tracking for stale entries, and feedback loops from API consumers. Implementations that simply pipe internal data to FHIR resources expose every upstream issue without remediation paths.
How to Evaluate Directory Implementations Honestly
A useful pattern during vendor evaluation is to query the candidate implementation for a known-bad subset of the payer's directory (specialists with stale addresses, providers who dropped from network last quarter). The vendor responses reveal whether the platform has data-quality awareness or is a thin pass-through.
For the Provider Access side of payer-provider data flow, the Best Provider Access API solutions with Bulk Data export covers a related but distinct API. For the member identity question that ties into Payer-to-Payer, the Top 5 FHIR Member Match engines covers patient-side matching.