CMS-0057-F: The Four FHIR APIs Payers Must Ship by January 2027, and What App Developers Should Build

As of October 2026, Medicare Advantage organizations, state Medicaid and CHIP programs, Medicaid and CHIP managed care plans, and QHP issuers on the federal Exchanges must have four FHIR APIs live by 1 January 2027 (managed care by the rating period starting on or after that date): an expanded Patient Access API, plus new Provider Access, Payer-to-Payer and Prior Authorization APIs. The operational half of the rule is already in force: since 1 January 2026, most of these payers have had to decide standard prior authorization requests within 7 calendar days and expedited ones within 72 hours, give a specific reason for every denial, and publish prior authorization metrics by 31 March each year. This guide gives the deadlines with their regulation citations, separates the standards that are required from the implementation guides CMS only recommends, and covers what an app developer can usefully build around these APIs.

1. Which Payers CMS-0057-F Applies To

The CMS Interoperability and Prior Authorization final rule (CMS-0057-F, 89 FR 8758) was published on 8 February 2024 and took effect on 8 April 2024. It calls the payers it covers “impacted payers”:

• Medicare Advantage (MA) organizations
• State Medicaid and CHIP fee-for-service programs
• Medicaid managed care plans and CHIP managed care entities
• Qualified Health Plan (QHP) issuers on the Federally-facilitated Exchanges (FFEs)

The rule itself excludes issuers that offer only stand-alone dental plans and issuers that offer QHPs only on the Federally-facilitated SHOP Exchanges. It does not cover employer plans or commercial coverage sold outside the federal Exchanges, and it does not cover traditional Medicare fee-for-service.

The rule also has a provider side. It adds an “Electronic Prior Authorization” measure to the MIPS Promoting Interoperability category and the Medicare Promoting Interoperability Program, starting with the CY 2027 performance period (2029 MIPS payment year) for clinicians and the CY 2027 EHR reporting period for hospitals and CAHs. Clinicians and hospitals attest to it rather than reporting a percentage.

2. Deadlines at a Glance, With Sources

Every date below is taken from the current regulation text on eCFR (checked 12 October 2026), using the Medicare Advantage sections as the citation. Medicaid, CHIP and QHP equivalents sit in 42 CFR parts 431, 438, 440 and 457 and 45 CFR part 156.

3. The Four APIs, One by One

Patient Access API (expanded)

Payers have run a Patient Access API since 2021 under the earlier CMS-9115-F rule. It lets a member authorize a third-party app to pull their claims, encounter data and clinical data (USCDI). From 1 January 2027, it must also include prior authorization information for items and services: the status, the approval or denial date, the end date, the items and services approved, the specific denial reason, and related structured documentation from the provider. That data must appear within 1 business day of the payer receiving the request, be updated within 1 business day of any status change, and stay available for at least a year after the last change (422.119(b)(1)(iv)). Drugs are excluded.

Provider Access API (new)

In-network providers can retrieve the same data (minus remittances and member cost-sharing) for patients attributed to them, within 1 business day of a request, for dates of service from 1 January 2016. The payer must authenticate the provider, run an attribution process that links members to providers, and let members opt out (422.121(a)). The regulation requires conformance with FHIR Bulk Data Access, so expect population-level exports, not one-patient lookups only.

Payer-to-Payer API (new)

When a member changes plans, or has two plans at once, the new payer requests up to five years of data from the previous payer: claims and encounter data (minus remittances and cost-sharing), USCDI clinical data, and prior authorization information, excluding denied authorizations. This exchange is opt-in, the opposite of Provider Access. The new payer must offer the opt-in within one week of coverage starting, request the data within one week of having the old payer’s details, and the old payer must respond within 1 business day (422.121(b)). Concurrent payers exchange data at least quarterly.

Prior Authorization API (new)

This is the one most people mean when they talk about CMS-0057-F. By 1 January 2027, the payer’s API must (422.122(b)):

1. List the covered items and services that need prior authorization (drugs excluded).
2. Identify the documentation the payer requires for each.
3. Support a HIPAA-compliant prior authorization request and response, as described in 45 CFR part 162.
4. Return the decision — approved (with end date or circumstance), denied (with a specific reason) or more information needed.

In practice, those four steps map onto the three Da Vinci guides: Coverage Requirements Discovery (does this need prior auth?), Documentation Templates and Rules (what does the payer need, pre-filled from the EHR where possible) and Prior Authorization Support (submit and track). CMS has also said, through a February 2024 enforcement discretion from its National Standards Group, that it will not take HIPAA Administrative Simplification enforcement action against covered entities that run an all-FHIR prior authorization flow without the X12 278 transaction. That discretion is listed on CMS’s CMS-0057-F page.

4. Required Standards vs Recommended IGs

This is where most summaries go wrong. CMS-0057-F requires conformance with a short list of base standards in 45 CFR 170.215. The Da Vinci and CARIN implementation guides are, under the final rule as it stands today, recommended, not required. CMS’s own API standards page (last updated 31 August 2026) says “CMS recommends payers use the IGs to support implementation.”

Two version details matter for anyone building today:

• US Core and SMART versions. The payer regulations cross-reference US Core 3.1.1 and SMART App Launch 1.0.0, and ONC’s adoption of both expired on 1 January 2026. The payer rules let payers use updated versions that ONC has approved (422.119(c)(4)), and CMS lists US Core 6.1.0 and SMART 2.0.0 alongside the older ones. Build against US Core 6.1.0 and SMART 2.0.0.
• The 2.2 versions. The FY 2027 IPPS final rule (91 FR 49570, 4 August 2026) updated 45 CFR 170.215 so that it now lists Da Vinci CRD 2.2.1, DTR 2.2.0, PAS 2.2.1, CARIN Blue Button 2.2.0, PDex 2.1.0, PDex US Drug Formulary 2.1.0 and CDex 2.1.0 as adopted HHS standards. That adoption does not, by itself, make the IGs mandatory for payers under CMS-0057-F. See the next section.

5. What Has Applied Since January 2026

The parts of CMS-0057-F that are not about APIs have been live for nine months:

• Decision timeframes. MA organizations, Medicaid and CHIP fee-for-service programs and Medicaid and CHIP managed care must decide standard requests within 7 calendar days (down from 14), with a possible extension of up to 14 days, and expedited requests within 72 hours. FFE QHP issuers are not bound by these timeframes under CMS-0057-F.
• Denial reasons. Every denial of an item or service must include a specific reason, however it is communicated.
• Public metrics. By 31 March each year, payers post the previous year’s figures on their websites: the list of services needing prior authorization, approval and denial percentages for standard and expedited requests, approvals after appeal, extensions, and average and median decision times (422.122(c)). The first set, covering 2025, was due on 31 March 2026, and it is a public dataset on which services and payers cause the most friction.
• Patient Access usage reporting. Payers report to CMS how many unique members had data sent to an app, and how many more than once.

6. What Changed in 2026: CMS-0062-P and the IPPS Rule

On 14 April 2026, CMS published a follow-up proposed rule, CMS-0062-P (91 FR 19890), with comments due 15 June 2026. According to the proposed rule and CMS’s fact sheet, it would:

• Make the IGs required. Payer APIs would have to conform to CARIN Blue Button, Da Vinci PDex, PDex US Drug Formulary, PDex Plan Net, CRD, DTR and PAS from 1 October 2027.
• Bring drugs in. Prior authorization for drugs would be added to the APIs and to the denial-reason and timeframe rules, also from 1 October 2027 in the proposal.
• Add FFE QHP timeframes. Standard non-drug requests in 7 calendar days and expedited ones in 72 hours.
• Require endpoint reporting. Payers would report their API endpoints to CMS.
• Extend the rules to SHOP. Small-group QHP issuers on the FF-SHOPs would become impacted payers.
• Adopt FHIR as a HIPAA standard for prior authorization and related eligibility transactions, with compliance 24 months after the final rule (36 for small health plans).

As of 12 October 2026, only part of that has been finalized. The FY 2027 IPPS final rule finalized ONC’s updated standard versions in 45 CFR 170.215 (section 4 above). The payer-side proposals have not been: the eCFR text of 42 CFR 422.119 and 422.122 still excludes drugs and does not require the Da Vinci IGs. Treat 1 October 2027 as a proposed date until a final rule appears in the Federal Register.

Either way, CRD, DTR and PAS are the interfaces app developers should expect to call.

7. What App Developers Should Build

CMS-0057-F is a payer mandate, but the APIs it creates are open doors for apps. Four realistic opportunities:

1. Patient apps on the Patient Access API

From January 2027, a member-authorized app can show prior authorization status and denial reasons alongside claims and clinical data. That makes “where is my authorization?” something a patient app can answer from its own data. Build SMART App Launch 2.0 standalone patient access, and support every impacted payer’s endpoint, not just one. Note that once a patient directs data to your app, HIPAA usually stops applying to you if you are not a covered entity or business associate, and FTC rules (including the Health Breach Notification Rule) may apply instead. Payers must tell members about this (422.119(g)).

2. Provider-side prior authorization tools (CRD, DTR, PAS clients)

Providers need to call payers’ Prior Authorization APIs, and from 2027 they need to attest to doing so for the Electronic Prior Authorization measure. A CDS Hooks service that fires at order time (CRD), a SMART app that renders the payer’s questionnaire and pre-fills it from the chart (DTR), and a submission and status tracker (PAS) are all buildable today against the public Da Vinci reference implementations. The hard part is EHR integration, which our FHIR integration guide and EHR app builder guide cover.

3. Care-coordination apps on Provider Access

Value-based practices, care managers and specialty groups can pull claims and clinical history for attributed patients in bulk. An app that ingests Bulk Data exports, reconciles them with the practice’s own records and surfaces gaps in care is a natural fit. This is PHI at scale, so it needs a BAA with the practice, encryption at rest and in transit, and audit logging of every read.

4. Payer-side components

Member opt-in and opt-out flows, attribution management and metrics dashboards for the 31 March posting are scoped products that smaller plans often buy rather than build.

Whichever you build, a few things apply to all of them:

• Register properly. Payers must publish API documentation and app registration requirements publicly (422.119(d)) and may cut off apps that pose an unacceptable security risk, using objective criteria (422.119(e)). Read each payer’s developer portal before you promise coverage.
• Respect consent direction. Provider Access is opt-out, Payer-to-Payer is opt-in. Your data model needs to know which applies.
• Watch for Part 2 data. Payers’ APIs must protect data covered by other laws, including 42 CFR Part 2 (422.119(c)(2)). Our Part 2 guide explains what that means for SUD records.

VertiComply generates full-stack healthcare apps (web plus native iOS and Android) with HL7/FHIR building blocks, and with HIPAA safeguards such as encryption, audit logging, role-based access and session timeouts on every plan. That covers the app side of a Patient Access or provider-facing tool; you still register with each payer and handle their specific requirements. We sign a BAA on request on all paid plans (pricing). Our HIPAA checklist for app developers lists the rest.

This article summarizes federal regulations for general information and is not legal advice.

Frequently Asked Questions

What is the CMS-0057-F deadline for the Prior Authorization API?

1 January 2027 for Medicare Advantage organizations and state Medicaid and CHIP fee-for-service programs, the rating period beginning on or after 1 January 2027 for Medicaid and CHIP managed care, and plan years beginning on or after 1 January 2027 for QHP issuers on the federal Exchanges. State programs and QHP issuers can apply for extensions or exceptions; MA organizations cannot.

Are the Da Vinci CRD, DTR and PAS implementation guides required?

Not under CMS-0057-F as finalized. The rule requires FHIR R4, US Core and SMART App Launch, and CMS recommends CRD, DTR and PAS. The April 2026 proposed rule, CMS-0062-P, would make them required from 1 October 2027, but as of October 2026 that payer requirement has not been finalized.

What prior authorization timeframes apply in 2026?

Since 1 January 2026, Medicare Advantage, Medicaid and CHIP fee-for-service programs, and Medicaid and CHIP managed care must decide standard prior authorization requests within 7 calendar days and expedited requests within 72 hours, with limited extensions. Every denial must include a specific reason. Drugs are excluded, and QHP issuers on the federal Exchanges are not covered by these timeframes.

Does CMS-0057-F apply to commercial health plans?

No. It covers Medicare Advantage, Medicaid, CHIP and QHP issuers on the Federally-facilitated Exchanges. Employer plans and commercial plans sold outside the federal Exchanges are not impacted payers, although some have chosen to build the same APIs.

Can a third-party app use the Provider Access or Payer-to-Payer API?

Not directly. Provider Access is for in-network providers with an attributed relationship, and Payer-to-Payer is for payers. A third-party app can use the Patient Access API with the member’s authorization, or work on behalf of a provider or payer under a business associate agreement.

When do payers publish prior authorization metrics?

By 31 March each year, for the previous calendar year, on the payer’s public website. The first reports, covering 2025, were due by 31 March 2026.

Last reviewed 12 October 2026. Dates are taken from the eCFR text current to 8 October 2026 and from CMS’s implementation pages; CMS-0062-P may change the IG and drug requirements if it is finalized. Nothing here is legal advice.