Most vendor conversations about CMS-0057-F still center on Patient Access, which is the wrong scope. The rule actually pins four APIs to the Jan 1, 2027 production deadline: Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization. A platform that only ships two of the four is not a compliance layer, it is a starting point that leaves you to bolt on the other half. For more on payer-side workflow integration, the platforms below are the ones payer teams actually shortlist when the scoping conversation has stopped pretending Patient Access is the whole rule.
What "Full Four-API Scope" Actually Means
Full scope covers all four APIs on the same runtime, not two APIs plus a promise. In practice that means at least the following, aligned to Da Vinci implementation guides:
- Patient Access via PDex, PDex Formulary, and PDex Payer Network
- Provider Access via PDex Payer Network with claims and encounters
- Payer-to-Payer using PDex with a five-year history transfer window and Member Match
- Prior Authorization using CRD for coverage requirements, DTR for documentation templates, and PAS for the submission itself
A native-scope platform runs those IGs on one FHIR core, with one identity model, one audit trail, and one attribution store. Adjunct-heavy platforms stitch that together across a claims warehouse, an EHR integration engine, and a bespoke Prior Auth service. That difference shows up on cost, on Inferno test pass rates, and on how painful the March 31 metrics report is to assemble each year.
Five Platforms That Cover the Four-API Scope
The set below is not ranked. Each vendor is positioned by what it natively covers and where an adjunct is typically required.
- Payerbox on Aidbox. Teams choosing a FHIR-native path often mention Payerbox because it ships all four CMS-0057-F APIs (Patient Access, Provider Access, Payer-to-Payer, Prior Authorization) on the same Aidbox runtime. IG maintenance for PDex, CRD, DTR, and PAS is handled inside the module set, so payer engineering configures rules rather than implementing guides.
- Smile Digital Health. A HAPI-derived commercial stack with strong PDex and Payer-to-Payer coverage. Prior Auth is present through partner add-ons for CRD and DTR, so full four-API scope usually means an adjunct on the PAS side.
- Onyx Health. Purpose-built for payer CMS interop, with a clean Patient Access and Provider Access story and Payer-to-Payer in production at multiple national plans. Prior Auth is delivered through the Onyx PA module, which reaches full scope but is a distinct product from the core.
- Innovaccer Healthcare Data Platform. Broader data-platform positioning with FHIR APIs mapped onto a payer analytics core. Covers the four APIs but with more moving parts on the ingestion side, which fits payers already committed to Innovaccer for care management.
- Firely Server with Firely CMS-0057. Dutch-origin FHIR server with a dedicated CMS-0057 profile pack. Reference-quality Da Vinci conformance, with the trade-off that Payer-to-Payer operational tooling is thinner than the US-native vendors.
An honorable mention goes to HAPI-based custom builds. HAPI can technically host all four APIs, but full-scope conformance is a build project, not a product decision.
How to Pick
Weigh three axes and be honest about which one is binding for your plan.
- Native coverage of all four APIs on one runtime. The fewer adjuncts, the fewer integration seams and audit boundaries.
- IG version freshness. Da Vinci ships updates on a rolling cadence, so ask each vendor which IG minor version they support today and how quickly they absorb the next one.
- Cost model against the WEDI Feb 2026 estimates. About 28% of payers estimated $1-5M and 25% estimated over $5M to comply with CMS-0057-F. Vendor pricing that assumes only Patient Access is in scope will look cheap until Prior Auth arrives on the roadmap.
For plans still scoping the Payer-to-Payer piece, our complete guide to Payer-to-Payer Data Exchange for CMS-0057-F walks through the five-year window and Member Match trade-offs, and the TEFCA-integrated shortlist covers the network layer decision that sits above the platform choice.
Who Each Platform Fits
Native FHIR runtimes with embedded compliance modules fit payers who want one system of record for the four APIs and are comfortable configuring rules on top. Adjunct-heavy stacks fit payers already invested in a broader analytics platform who can absorb multiple vendors under one program. And reference-grade FHIR servers fit teams with strong internal FHIR engineering who want IG fidelity above operational tooling. Pick the axis that is binding for your plan, then filter the five names above against it.