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.
01
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
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.
03
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
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
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
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
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.
