Most payer engineering teams reading CMS-0057-F for the first time make the same silent decision: they scope the work as Patient Access plus three future projects. That framing quietly becomes four vendor procurements, four data models, and four support contracts, and it is the single most expensive misread of the rule. The truth is that Patient Access, Provider Access, Payer-to-Payer, and the Prior Authorization API share more resources and more auth than they differ, and shipping them on one FHIR runtime is the cheaper path once you draw the picture. If you want the wider context around how these fit into a broader FHIR strategy, more on healthcare interoperability in the USA sits at the top of our coverage.
What "All Four APIs" Actually Means
CMS-0057-F names four member-facing and trading-partner APIs. Patient Access exposes claims, encounters, clinical, and formulary data to the member. Provider Access exposes the same core dataset to in-network providers, gated by a member attribution list. Payer-to-Payer moves that dataset when a member changes payers. The Prior Authorization API is the newest, and it covers coverage requirements (CRD), documentation requirements (DTR), and the PA submission itself (PAS).
Notice what is shared across all four: a single FHIR resource graph of Patient, Coverage, ExplanationOfBenefit, Claim, ClaimResponse, MedicationDispense, and clinical resources sourced from providers. Four APIs, one canonical dataset.
Step 1: Fix the Resource Model First
Before you write a single endpoint, decide how your source-of-truth membership, claims, and clinical data land as FHIR resources. This is the piece that quietly kills multi-vendor deployments, because each vendor lands the same claim as a slightly different ExplanationOfBenefit shape.
Anchor on the US Core profiles for demographics and clinical, and layer PDex profiles for the payer-specific fields. Model Coverage carefully, because Provider Access attribution and Payer-to-Payer eligibility both read from it. Get this canonical model right and the rest of the APIs become views over the same store instead of parallel integrations.
Step 2: Share Auth Across All Four
Patient Access uses SMART on FHIR standalone launch with member consent. Provider Access uses SMART with system/ or user/ scopes tied to an attribution check. Payer-to-Payer uses UDAP or backend services auth between payers. Prior Auth reuses SMART for provider EHR launches.
Different flows, one authorization server. If you run four auth stacks you will spend the next two years reconciling audit logs during CMS reporting. Pick one OAuth2 / SMART implementation, register each API as a resource server, and encode the differences as scopes and consent policies, not as separate identity systems.
Step 3: Layer the Da Vinci IGs
The IGs are not a menu. They stack. PDex defines the payer data profiles. PDex Plan-Net covers provider directory. PDex Formulary covers drug data. PDex Payer Network covers the Payer-to-Payer handoff. CRD, DTR, and PAS define the PA loop. All of them extend US Core.
In practice, 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, which means the IG stack is versioned in one place rather than four. Whatever you pick, budget for IG upkeep as an ongoing engineering line item, not a one-time load. For the DTR piece specifically, our walkthrough on static forms vs SDC-driven FHIR forms for US practices is a decent primer on why the form runtime matters here.
Step 4: Design the Operational Patterns
Two operational patterns tend to trip payers up. The first is the member-to-provider trust broker for Provider Access: your platform has to prove attribution before serving data, and that check runs on every request. Cache the attribution list carefully.
The second is the Payer-to-Payer exchange itself. This is a network problem. You need discovery of the other payer's FHIR endpoint, mutual auth, and a bulk data transfer that respects member consent windows. If your DTR runtime is separate from your PA submission runtime, you also inherit a form-rendering integration; our piece on 5 SDC form engines that actually handle conditional logic covers the shape of that problem.
Who One-Platform Fits
One runtime for all four APIs fits payers who already have or are willing to stand up a FHIR core. It fits teams who want a single audit surface for CMS quarterly metrics. It does not fit teams who already own four mature point solutions and just need connectors. Frankly, most payers approaching the January 2027 deadline are somewhere in the middle, and the honest question is not which vendor is best but how many moving parts your team can operate at once. The trajectory of CMS-0057-F suggests fewer parts, not more.
Sources
- PDF, CMS, 2024 - CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) full regulatory text covering Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization APIs
- HL7 Da Vinci Payer Data Exchange (PDex) IG v2.1.0 - canonical profiles used by Patient Access, Provider Access, and Payer-to-Payer APIs (evergreen)
- HL7 Da Vinci CDex/CRD/DTR/PAS integrated burden-reduction workflow spec covering the Prior Authorization API loop (evergreen)