CMS, the Centers for Medicare & Medicaid Services, is the federal agency that runs Medicare, Medicaid and CHIP and oversees plans on the federal health insurance exchanges. Its rules now shape how payer data moves, and the rule most software teams are working on is CMS-0057-F, the Interoperability and Prior Authorization Final Rule.
This guide covers which payers the rule applies to, what is already in force, what arrives in 2027, how the four FHIR APIs fit together, how electronic prior authorization works end to end, and where these programs tend to slip.
What does CMS require under CMS-0057-F?
Planning payer FHIR APIs?
Agnotic builds FHIR APIs, prior authorization workflows and the data pipelines behind them for payers, providers and health tech vendors.
CMS-0057-F requires impacted payers to decide prior authorization requests within set timeframes, publish prior authorization metrics, and run four FHIR APIs: Patient Access, Provider Access, Payer-to-Payer and Prior Authorization. CMS finalized the rule in January 2024 to cut prior authorization delays and move claims and clinical data between payers, providers and patients.
The rule has two halves. One is operational: how fast payers decide and how openly they report. The other is technical: the APIs that let other systems read data and submit requests without phone calls or fax.
Both halves land on the same data. A payer that cannot find its own prior authorization decisions quickly will struggle with the metrics in 2026 and with the APIs in 2027.
Which payers does the rule cover?
The rule covers impacted payers: Medicare Advantage organizations, state Medicaid and CHIP fee-for-service programs, Medicaid managed care plans, CHIP managed care entities and issuers of qualified health plans on the federal exchanges. Commercial group plans outside those programs are not directly covered.
Providers are not regulated by the API requirements, but they decide whether the APIs get used. A Prior Authorization API that no EHR calls changes little, so provider organizations and their EHR vendors are part of every serious program.
Health tech vendors sit in between. Payers often buy FHIR servers, prior authorization rules engines or member apps, and those vendors carry part of the build even though the legal duty stays with the payer.
What applies now, and what arrives in 2027?
The operational requirements started on 1 January 2026, and the API requirements apply from 1 January 2027. The first date is already behind most payers, so the 2026 work is about running the new rules well, while the 2027 work is still a build.
- From 1 January 2026: Impacted payers must decide expedited prior authorization requests within 72 hours and standard requests within 7 calendar days, give a specific reason when they deny a request, and publish prior authorization metrics on their websites.
- From 1 January 2027: Impacted payers must offer a Provider Access API, a Payer-to-Payer API and a Prior Authorization API, and add prior authorization information to the Patient Access API that the 2020 interoperability rule first required.
The metrics are public, which makes decision speed visible to members, providers and regulators. Build the reporting from the same tables the APIs will read, so the numbers on the website and the data in the API never disagree.
Running the 2026 requirements
The decision timeframes are a workflow problem first. A payer can only meet them if every request, whatever channel it arrives through, starts a clock the moment it is received.
- Single intake log: Fax, portal, phone and electronic requests all land in one queue with a received time, a priority flag and the member and service requested.
- Clock tracking: Each request shows the time left before its deadline, and reviewers see expedited requests first.
- Pending information: When a request lacks documentation, the outreach to the provider and the provider's reply are logged against the same record.
- Structured denial reasons: Reviewers choose from a maintained list of reasons tied to the policy that applied, with free text only as an addition.
- Reporting extract: The metrics pull reads from the intake log and decision records directly, with no spreadsheet step in between.
The same intake log becomes the backbone of the Prior Authorization API in 2027. Requests that arrive through the API simply become another channel feeding the queue.
How the four APIs connect payer, provider and patient
Each of the four APIs serves a different reader. Patient Access goes to the member's app, Provider Access to in-network providers, Payer-to-Payer to the member's new plan, and Prior Authorization runs between the provider's EHR and the payer.
- Patient Access API: The member's chosen app reads claims, encounter and clinical data, and from 2027 prior authorization information. It uses FHIR R4 with SMART on FHIR authorization.
- Provider Access API: In-network providers with a treatment relationship read a member's claims, clinical and prior authorization data, often for a whole panel at once. Members can opt out.
- Payer-to-Payer API: When a member changes plans, the new plan requests the member's history from the old one, if the member opts in.
- Prior Authorization API: The provider's system learns whether authorization is needed, sees what documentation is required, submits the request and receives the decision.
Three of the four APIs share most of their data, and two depend on member consent choices. That is why one shared design beats four separate projects.
How does electronic prior authorization work end to end?
Electronic prior authorization runs in three stages: discover the requirement, gather the documentation, then submit and track the request. CMS recommends, but does not require, the HL7 Da Vinci Coverage Requirements Discovery (CRD), Documentation Templates and Rules (DTR) and Prior Authorization Support (PAS) implementation guides for these stages.
- 1. Discover: When the clinician orders a service, the EHR calls the payer's coverage requirements service and learns whether authorization is needed for this member and service.
- 2. Gather: If it is, the EHR loads the payer's documentation questionnaire, fills what it can from the chart and asks the clinician only for the rest.
- 3. Submit: The EHR sends the request with the completed documentation to the payer's Prior Authorization API.
- 4. Decide: The payer's rules engine and reviewers make the decision within the required timeframe and record the reason.
- 5. Return and track: The decision goes back to the EHR, and the authorization number and status are stored where the scheduler and biller can see them.
The hard part sits in step 4 and behind step 2. Payers have to turn coverage policies held in documents into structured rules and questionnaires, and that is policy work as much as software.
On the provider side, the EHR vendor usually owns steps 1 to 3. A provider with a custom system or a specialty product needs its own client for those calls.
That client has to read the payer's coverage response, render the questionnaire for the clinician, attach chart data with the right FHIR profiles and store the returned authorization against the order. Testing it against each major payer in your market is a project of its own.
One data layer, four APIs
The cleanest way to meet the rule is a single FHIR data layer that all four APIs read from. Each part below is built once and reused.
- Source feeds: Claims, encounters, clinical data from providers and prior authorization records flow into one store, with clear rules for which system is the source of truth.
- FHIR mapping: Data is mapped to US Core and the Da Vinci payer data profiles once, not separately for each API.
- Member and provider identity: One service resolves members across plan years and links providers to members through attribution.
- Consent registry: Opt-outs for Provider Access and opt-ins for Payer-to-Payer live in one place that every API checks before it returns data.
- Authorization and audit: SMART on FHIR for apps, system-level credentials for providers and payers, and one audit log across all four APIs.
- Metrics: Prior authorization reporting reads the same tables the API reads, so public numbers and API data match.
Whether you build, buy or combine the two, judge each option against this list. A product that covers one API but brings its own copy of member data will cost more to run than it saves.
Where payer API programs slip
Most slippage comes from data and policy, not from the API code. These are the failure points to watch.
- Four projects, four data copies: Separate teams build each API against their own extracts, and the APIs return different answers for the same member.
- Policies left in PDFs: The Prior Authorization API cannot say what documentation is needed if coverage rules are not structured.
- Late provider testing: The payer finishes its endpoints, then learns that the main EHRs in its network call them differently.
- Consent handled per API: Opt-outs recorded in one system are missed by another, which exposes data the member asked to withhold.
- Unreadable denial reasons: Codes that mean something internally reach the provider as text nobody can act on.
- Metrics built last: Public reporting assembled by hand from several systems each year, instead of from the live data.
Each item has the same fix: decide shared data, consent and identity first, then build the APIs on top.
How Agnotic can help
Work on this rule is mostly data engineering with a thin API layer on top. Agnotic Technologies builds that data layer for payers and the vendors that serve them: FHIR mapping, member identity and consent services, prior authorization rules and questionnaires, and the four APIs.
For providers and specialty product teams, Agnotic builds the EHR-side client that calls a payer's Prior Authorization API. Your compliance team owns the reading of the rule; Agnotic builds to the requirement list you agree.
Plan payer API work with Agnotic
Explore interoperability services and the build versus buy comparison for these APIs, or browse more articles in the Interoperability hub.
Related reading on Agnotic
Continue with the TEFCA guide, interoperability in healthcare, US Core implementation and value-based care.
