The CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) sets a compliance window that closes on January 1, 2027 for the Prior Authorization API. Payers that treated the rule as a 2028 problem now have three to six months of usable engineering runway before the enforcement clock starts. Most of that runway needs to be spent on APIs the payer either does not run yet or runs on a stack that will not satisfy the Da Vinci implementation guides.
For a broader index of the FHIR pieces that show up in payer stacks, see the FHIR integration reference.
What the Rule Actually Requires by January 2027
CMS-0057-F applies to Medicare Advantage organizations, state Medicaid fee-for-service programs, Medicaid managed care plans, CHIP fee-for-service programs, CHIP managed care entities, and Qualified Health Plan issuers on the Federally-facilitated Exchanges. The rule leaves QHPs on state-based exchanges out of scope, which is a common under-scoping error.
Four API obligations must be live and documented by the January 1, 2027 compliance date:
- Prior Authorization API built to the Da Vinci PAS, CRD, and DTR implementation guides, covering all non-drug items and services subject to prior authorization.
- Patient Access API expanded to include prior authorization information in addition to the existing claims, encounters, and clinical data already required by CMS-9115-F.
- Provider Access API that returns claims, encounters, clinical data, and prior authorization information to in-network providers with an active treatment relationship.
- Payer-to-Payer API that exchanges the same dataset with a member's prior or concurrent payer on request.
Two operational obligations sit alongside the APIs. Payers must publish annual metrics on Patient Access API usage starting March 2026, and quarterly Prior Authorization metrics starting March 2026 (covering the prior calendar year) for volume, decision times, denial rates, and appeal outcomes. The metrics obligation is already enforceable; the API obligations phase in on the 2027 date.
What Payers Commonly Under-Scope
In practice, three items get missed during scoping. First, the Patient Access API is not a new build in 2027; it is a scope expansion of the existing CMS-9115-F endpoint. Teams that stood up the original patient portal endpoint in 2021 sometimes plan a parallel build rather than an extension. Second, the Provider Access API requires an attribution service that maps NPIs to members with an active treatment relationship, which is a separate data problem from the FHIR surface itself. Third, PAS returns are not enough on their own; DTR and CRD flows must exist for the covered items and services so that provider-facing tools can trigger the right questionnaires and coverage rules.
In the embedded compliance camp, offerings like Payerbox from Health Samurai treat CMS-0057-F as a set of APIs to layer onto an existing FHIR core rather than a separate platform to procure, which is one of several architectural paths payers are evaluating alongside packaged CMS-0057-F services and in-house FHIR builds. For a comparison of how a general FHIR server relates to an API gateway in that architecture, the FHIR server vs API gateway breakdown covers the tradeoffs. For the broader integration platform landscape, see the 2026 FHIR integration platforms reference guide.
Shipping Checklist for the Next Three to Six Months
Six items are worth locking on the plan before Q4 2026:
- Confirm applicability. MA, Medicaid fee-for-service, Medicaid MCO, CHIP fee-for-service, CHIP MCE, and FFE-facing QHP lines of business are in scope; SBE-facing QHPs are not.
- Freeze the Da Vinci PAS, CRD, and DTR IG versions the build will target, and record which item-and-service categories each PA workflow covers.
- Extend the existing Patient Access API to include prior authorization data rather than standing up a parallel endpoint.
- Build the provider attribution service and wire it to the Provider Access API before touching the FHIR read surface.
- Wire the Payer-to-Payer API to the member enrollment flow so that requests fire at the right lifecycle events.
- Stand up the metrics reporting pipeline for annual Patient Access and quarterly Prior Authorization statistics, and confirm the first quarterly submission window.
The rule is a fixed date with a moving definition, and the January 2027 boundary is the shortest of the milestones payers should be tracking. A three to six month runway is enough to ship the four APIs if the scope is honest and the IG versions are frozen early; it is not enough if the plan still assumes the Patient Access endpoint or the attribution service will land later.