FHIR Plan-Net API

FHIR Plan-Net APICMS-0057-F, the morning the rule lands.

A DaVinci PDex Plan-Net (R4) implementation conformant to the seven required resources, with Bulk Data Export ($export), SMART Backend Services authentication, and a Sunfire-compatible feed for plans not yet on FHIR — so members keep finding care while the plan migrates.

FHIR R4 · Plan-NetIllustrative
// Illustrative — Plan-Net Practitioner search
GET /fhir/r4/Practitioner?name=Doe
{
"resourceType": "Bundle",
"type": "searchset",
"total": 12,
"entry": [{
"resource": {
"resourceType": "Practitioner",
"id": "sample-001",
"identifier": [{ "system": "http://hl7.org/fhir/sid/us-npi", "value": "0000000000" }],
"name": [{ "family": "Doe", "given": ["J."] }],
"qualification": [{ "code": { "coding": [{ "code": "MD" }] } }]
}
}]
}

01

Why this matters to your plan.

By January 2027, CMS requires every MA plan to publish its provider directory as a FHIR Plan-Net API — a standardized feed other systems can read automatically. It's not optional and it's not a phase-two item. Standing it up late shows up as a member-facing failure. We give you a conformant one now, under your own brand.

02

DaVinci PDex Plan-Net, conformant.

A FHIR R4 implementation of the DaVinci Payer Data Exchange Plan-Net guide. All seven required resources, every search parameter the spec mandates, and a CapabilityStatement that mirrors what's actually deployed — not what's advertised.

  • Practitioner, PractitionerRole, Organization, Location, HealthcareService, InsurancePlan, Endpoint
  • Search parameters per the IG: name, specialty, location, network, address, identifier, …
  • /.well-known/smart-configuration for SMART Backend Services discovery
  • /metadata returning a CapabilityStatement that reflects the live deployment

03

Bulk Data Export ($export), production-ready.

Async kick-off, polling endpoint, NDJSON streaming output, signed URLs with TTLs, request-ID propagation through the entire flow. The export pattern that auditors actually probe — not a placeholder route.

04

SMART Backend Services authentication.

JWT bearer auth for write paths and $export. Supports the .well-known/smart-configuration discovery flow. The public read endpoints are open per CMS-0057-F's no-authentication-required mandate; everything sensitive is behind SMART.

05

On the plan's own host.

We deploy the FHIR API as a Next.js rewrite under each plan's white-label host (e.g. providersearch.{your-plan}.com/fhir/r4). The plan owns its surface area; we own the conformance.

06

A Sunfire-compatible bridge for legacy plans.

Not every plan is on FHIR yet. For the ones that aren't, we expose a Sunfire-compatible feed that keeps members finding care while the plan migrates. FHIR cutover is staged behind a flag — same data, two surfaces.

Ready when you are

Bring this platform to your plan.

If your provider data is ready, a new white-labeled tenant goes live in about a week. Compliance certification runs alongside it, not as a later phase.