CMS-0057-F turned Prior Authorization from a back-office workflow into a regulated API surface. Health plans that signed CMS-9115-F contracts in 2021 are discovering, often late in 2026, that the Prior Auth API requirement under 0057-F is not a small extension of what they already built. It is a new operational system with its own decision SLAs, public reporting metrics, and an entire FHIR-native stack underneath. This guide lays out what FHIR Prior Authorization actually means in 2026, what the four moving parts are, and what trade-offs health plans face when they pick an implementation path.
If your team is mapping the territory, this article sits at the top of the Prior Auth FHIR reference on this site, with deeper pieces linked throughout.
What FHIR Prior Authorization Actually Means Under CMS-0057-F
The Prior Authorization API requirement under CMS-0057-F is not a single endpoint. It is the Da Vinci ePA stack: Coverage Requirements Discovery (CRD), Documentation Templates and Rules (DTR), and the Prior Authorization Support (PAS) API. CRD lets the provider EHR ask the payer at order time whether a PA is required, what documentation is needed, and what the rules look like. DTR renders the payer-specific questionnaire inside the provider workflow, often as a SMART app. PAS submits the completed bundle, often round-trips through X12 278 / 275 inside the payer back office, and returns the decision.
The catch is that all three pieces have to interlock. CRD without DTR is a notification system. DTR without PAS is a form engine. PAS without the other two is a glorified web service that providers will not adopt because the upstream burden falls on them.
For a deeper walkthrough of the implementation choices, the Da Vinci PAS implementation guide covers the leading platforms in 2026.
The Decision SLAs That Drive the Operational Design
CMS-0057-F set Prior Auth decision SLAs at 72 hours expedited and 7 calendar days standard. Those SLAs are not aspirational. They became enforceable starting January 1, 2026, and they apply across the entire decision chain, including delegated entities. If your UM vendor takes three days to render a determination, the payer is still on the hook for the SLA breach in CMS reporting.
In practice, this changes the architecture. PA timing has to be logged at FHIR resource granularity, decision events have to flow back to the Patient Access API within one business day, and reporting metrics (approval rate, denial rate, average decision time) must be ready to ship to CMS each March 31. Vendors that ship the API but leave reporting as a customer-engineering line item are quietly handing health plans a permanent ongoing cost.
The Vendor Landscape Worth Knowing in 2026
The 2026 vendor landscape for FHIR Prior Authorization clusters into three buckets. The integration engines (Edifecs, MuleSoft Healthcare Accelerator, PilotFish, Rhapsody) come from the X12 world and bolt FHIR on top; they are strong on 278 / 275 round-trip but weaker on the SMART app and CDS Hooks pieces. The FHIR-native platforms (InterSystems IRIS, Smile Digital Health, 1upHealth) are stronger on the application layer but vary widely on X12 interoperability. A few smaller vendors and open-source efforts round out the field, with the Da Vinci reference implementations doing useful work but rarely production-grade out of the box.
If you want a side-by-side, the CRD DTR PAS platforms comparison covers how each vendor handles the three Da Vinci pillars.
How X12 Interop Still Shapes the Picture
For most US health plans, X12 278 / 275 is still the language of Prior Authorization inside the payer back office. CMS-0057-F did not retire X12; it added FHIR as a peer. Real implementations have a converter sitting between the FHIR PAS endpoint and the legacy UM system, translating 275 attachments into FHIR Bundles and back. Solutions that handle this round-trip cleanly save months of integration work and reduce risk during cutover.
If you want to dig into the X12 question specifically, the FHIR ePA solutions that handle X12 278 / 275 round-trip breaks down the leading options.
The Renewal Question
Most US health plans signed their first FHIR vendor contract under CMS-9115-F in 2021. Those contracts are up for renewal in 2026. The cmspriorauth.com RFP framework lists eight categories of capability to test before signing for another year, and CMS-0057-F changed the answer in every one of them. Renewal in 2026 is the natural decision point to ask whether the incumbent vendor can clear the full 0057-F bar, or whether the gap has grown too large to close in twelve months.