Understanding the 2027 Interoperability API Requirements

January 1, 2027 is a little over nine weeks away. A number of summaries describe it as a deadline for practices. For the most part, it is a deadline for payers. What lands on practices is smaller and more specific, and it depends on your EHR and on which health plans you work with. This piece sets out who has to do what, what has already changed, and what a practice can usefully test between now and the new year.

The Rule in Brief

The rule is CMS-0057-F, the Interoperability and Prior Authorization final rule. It was released in January 2024. CMS generally gave impacted payers until January 1, 2027, to meet the API requirements. Exact compliance dates vary by payer type; for some managed care plans and Qualified Health Plan issuers, the deadline is tied to a rating period or plan year beginning on or after that date. Certain operational provisions began generally in 2026.

The rule applies to a defined list of 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 federally facilitated exchanges. Coverage outside that list is not subject to this rule’s API requirements, although a given payer may offer similar electronic tools anyway. That is a question for the payer.

What Has Already Changed

Some of the rule is already in effect, and it is worth knowing because it affects your day-to-day work now.

Since January 1, 2026, impacted payers other than QHP issuers on the federally facilitated exchanges have had to send decisions on standard prior authorization requests within seven calendar days and on expedited requests within 72 hours. These timeframes apply to covered medical items and services, not drugs.
For covered non-drug requests, impacted payers must give a specific reason when a prior authorization request is denied.
Impacted payers must also publicly report prior authorization metrics on their websites annually, with the first set due by March 31, 2026.

That last item is a practical resource. If you want to compare how your payers handle prior authorization, their published metrics are a place to start. The rule requires public reporting, but this article does not assess any individual payer’s report.

One more point on the current state of play: the API requirements do not prohibit other channels from continuing to be used. Payers may still handle requests and responses through portals, fax, email, mail, or phone where applicable. The January date concerns the payer’s obligation to implement APIs, not the disappearance of every other channel.

What the Payers Must Have by January 1

By the applicable compliance date, an impacted payer must maintain a Prior Authorization API. The API must hold the payer’s list of covered items and services, identify documentation requirements for approval, and support a prior authorization request and response. It must communicate whether a request is approved, denied with a specific reason, or needs more information. The API requirements use HL7 FHIR standards.

Three related API requirements also generally begin on January 1, 2027, subject to the payer-specific dates described above:

Patient Access API: The existing API must be expanded to include prior authorization information, excluding drugs.

Provider Access API: The API must let providers retrieve specified patient claims, encounter, clinical, and prior authorization data, subject to the rule’s requirements and patient protections.

Payer-to-Payer API: The API must support the exchange of specified patient data between payers when a patient changes plans or has multiple concurrent payers, subject to the rule’s permission and data-sharing requirements.

Two related points are worth making clear:

Drugs are excluded from the current CMS-0057-F prior authorization requirements. A separate proposal, CMS-0062-P, would extend similar requirements to drug prior authorization, but it remains a proposal rather than a finalized requirement under that rule.
Real-time decisions are not required. The rule does not require payers to make all prior authorization decisions in real time through the API. The API is intended to support electronic information exchange and request handling, while some decisions will still require clinical review.
Practices do not have to build an API. The API implementation obligations sit with the payers. Practices should work with their EHR vendors and payers to understand which electronic workflows will be available and how they will function.

What the Rule Asks of Providers

The provider-side requirement is a new measure in MIPS. CMS added an “Electronic Prior Authorization” measure to the Promoting Interoperability performance category. For MIPS-eligible clinicians, the measure begins with the CY 2027 performance period and the CY 2029 payment year. It is a yes/no attestation, with an applicable exclusion available where the clinician meets the official criteria.

To answer yes, a clinician must have requested prior authorization electronically through a Prior Authorization API, using data from certified EHR technology, for at least one medical item or service (excluding drugs) ordered during the performance period.

Eligible hospitals and critical access hospitals have a related measure, but its status differs: it is an optional bonus measure for the 2027 EHR reporting period and becomes mandatory beginning with the 2028 EHR reporting period.

A few cautions:

The measure specifications define the applicable exclusions. Check the current 2027 QPP specification for the criteria that apply to your clinician or reporting group.
Check whether your clinicians are required to report the Promoting Interoperability category at all.
The measure was finalized as an attestation, not as the numerator-and-denominator measure originally proposed. That makes the reporting simpler, but it does not make the underlying workflow work by itself.

Attesting to one request sounds like a low bar. The difficulty is the chain behind it: an EHR that supports electronic prior authorization against payers that expose the relevant API, and clinicians or staff who can use that workflow rather than reverting automatically to a portal.

How Ready Is Everyone

WEDI’s February 2026 survey, published in March, provides a dated snapshot of readiness. Forty-seven percent of provider respondents said they were somewhat or very likely to meet the January 1, 2027, deadline, down from 69% in the earlier survey. Separately, 33% had not started implementation and testing, while 67% were unsure about implementation progress. Thirty-three percent said they were somewhat or very likely to implement the Provider Access API, down from 44% in the previous survey. Among payer respondents, 16% estimated that they would be 75% to 100% complete with the Patient Access API by January 1.

These were survey results from February 2026, not a measurement of readiness today. WEDI opened a follow-up survey in September that closed on October 9; check for publication of those results before using the February figures as the latest industry snapshot.

A reasonable reading for a practice manager is limited to this: readiness was uneven in the published survey, so assumptions about what will work on January 2 are worth testing.

What to Test Between Now and the New Year

The following are practical suggestions. They are not requirements of the rule.

1. Pick a sample. Choose a handful of medical-benefit services that account for most of your prior authorization work. Include at least one from each impacted payer you deal with most.

2. Trace one request end to end. Follow an order from entry in the EHR through submission and the payer’s response to where the decision appears in your system. If your vendor has a test environment, use it.

3. Check the response side. Where do approvals, denials, and requests for more documentation appear? Who sees them? Check that denial reasons are captured somewhere your team can act on them.

4. List your payers by category. Identify which payers fall under the rule. For those that do, find out whether they have published API documentation and confirm the applicable compliance date.

5. Decide the fallback. If the API path fails for a request, what is the manual route, and who owns it? Other channels remain available during the transition, so a documented fallback helps keep work moving.

6. Name an owner. Someone in the practice should be responsible for the attestation and for tracking whether at least one qualifying request was submitted in 2027.

Questions for Your EHR Vendor

Does the current version support prior authorization through payers’ FHIR APIs, either directly or through a clearinghouse? If not, when is the release planned?
Is the capability included in your license or priced separately?
How does it handle documentation requirements and attachments?
Can it produce the information you need to support the attestation?
Does it support retrieval through the Provider Access API?
What testing support is available before January?

Questions for Payers

Which of your plans are subject to the rule, and what is the applicable compliance date for each?
Which FHIR implementation approach and implementation guides will your platform support, and how will the API interact with our existing electronic prior authorization workflows?
What happens to requests submitted outside the API after the applicable compliance date?
How will denial reasons be delivered?
Where can we find your published prior authorization metrics?
Short answers to common questions
Do we have to build an API? No. The API implementation obligations sit with payers.
Does this cover drug prior authorizations? Not under the current CMS-0057-F requirements. CMS proposed additional drug-related requirements in CMS-0062-P, but that proposal is not itself a finalized requirement.
Will payers decide faster after January? The decision-time limits of 72 hours for expedited requests and seven calendar days for standard requests are already in effect for impacted payers other than QHP issuers on the federally facilitated exchanges, and they apply to covered non-drug items and services. The January date concerns API implementation.
What if a payer is not ready? The rule does not provide a single operational answer for every practice-payer situation. Ask each payer how it will handle requests during implementation and keep a documented manual fallback.

Sources