To All Articles

One Discharge. One Box. 2027.

Michael Nikitin

CTO & Co-founder AIDA, CEO Itirra

Published on September 28, 2026

Hospital CIOs have spent most of 2026 treating CMS-0057-F as someone else’s deadline. Payers have to stand up four FHIR APIs by January 1, 2027, and nearly every readiness conversation this year has been about them. But the same rule wrote a second, quieter requirement for hospitals and Critical Access Hospitals (CAHs) themselves: starting with the CY 2027 EHR reporting period, they must attest they requested at least one prior authorization electronically — or claim an exclusion (Source: CMS, CMS-0057-F Fact Sheet). This isn’t a payer problem. It’s a hospital-side box, on a hospital-side clock, with a hospital-side consequence.

Graphic stating the CMS-0057-F hospital attestation bar: one discharge or medical item/service requested electronically through a Prior Authorization API during the CY 2027 EHR reporting period.


What Exactly Do Hospitals Have to Attest?

Eligible hospitals and CAHs must attest “yes” to requesting a prior authorization electronically — via a Prior Authorization API, using data from certified EHR technology (CEHRT) — for at least one hospital discharge or one medical item or service, excluding drugs, ordered during the CY 2027 EHR reporting period. The alternative is to claim an applicable exclusion (Source: CMS, CMS-0057-F Fact Sheet). It’s a yes/no measure inside the Health Information Exchange (HIE) objective of the Medicare Promoting Interoperability Program — the same framework CMS already uses to score hospital EHR adoption and use. MIPS eligible clinicians get the equivalent measure starting the CY 2027 performance period, tied to the CY 2029 MIPS payment year (Source: CMS, CMS-0057-F Fact Sheet).

The bar itself is small on paper: one discharge, one request, one box checked yes. That’s precisely what makes it easy to underweight in a 2026 planning cycle dominated by the much bigger payer-side build.


Why Doesn’t This Wait for Payers to Be Ready?

Because the rule doesn’t explicitly condition the hospital attestation on the payer’s own API being live and functional first. Payers subject to CMS-0057-F must have their Prior Authorization API operational by January 1, 2027. The hospital measure asks something narrower and, in practice, harder to time: that the hospital requested at least one prior authorization electronically through such an API sometime during the CY 2027 reporting period. Nothing in the rule as written guarantees those two clocks line up cleanly for every hospital and every payer relationship — and payer readiness data through mid-2026 showed a meaningful share of payers still building toward their own January 2027 deadline.

Timeline comparing the payer-side Prior Authorization API go-live deadline of January 1, 2027 against the hospital-side CY 2027 EHR reporting period attestation window, showing the two are not explicitly linked in the CMS-0057-F rule.


What Does the Attestation Actually Require, Mechanically?

Element Detail
ProgramMedicare Promoting Interoperability Program (hospitals/CAHs); MIPS Promoting Interoperability performance category (eligible clinicians)
MeasureHealth Information Exchange (HIE) objective — requesting a prior authorization electronically
Reporting periodCY 2027 EHR reporting period (clinicians: CY 2027 performance period / CY 2029 payment year)
What gets attested“Yes” — at least one prior authorization requested electronically, via a Prior Authorization API, using CEHRT data, for one discharge or medical item/service (excluding drugs) — or an exclusion claim
Payer readiness required first?Not explicitly stated in the rule — payer APIs are due live Jan. 1, 2027, but the hospital attestation isn’t conditioned on confirming that go-live worked

Source: CMS, CMS-0057-F Fact Sheet.



What Happens If a Hospital Doesn’t Attest?

Falling short of the Promoting Interoperability Program’s required performance — which this new measure now factors into — subjects eligible hospitals and CAHs to a downward Medicare payment adjustment: a reduced annual payment update for hospitals under the Inpatient Prospective Payment System, and reduced Medicare reimbursement for CAHs below the standard 101% of reasonable costs (Source: HHS, Scoring, Payment Adjustment, and Hardship Information). CMS’s own guidance describes the mechanism without publishing a single universal percentage — the exact size of the adjustment depends on program year and an organization’s specific PI Program scoring, so a hospital finance team should confirm the current figure against CMS’s active-year guidance rather than treat any single number as fixed.

Card showing the consequence of not attesting under CMS-0057-F: a reduced annual Medicare payment update for hospitals, and CAH reimbursement cut below 101 percent of reasonable costs.


Where’s the Real Gap Between Attesting Yes and Being Ready?

Attesting “yes” and actually being able to attest it truthfully are two different projects. The first is a checkbox. The second requires an EHR-side workflow that can genuinely call a payer’s Prior Authorization API and complete a real request.

Four-row comparison table: what CMS asks hospitals to attest under CMS-0057-F versus what it actually takes to attest truthfully, covering the API call, payer readiness, CEHRT configuration, and exclusion claims.
Hospitals that haven’t identified which payer relationship they’ll use for that one transaction, this far into the year, are behind a deadline they may not have been tracking as their own.


How Does This Fit With CMS-0057-F’s Payer-Side Deadlines?

It’s the third piece of the same picture. We’ve covered what payers have to build, and why hospital-side integration work — not just waiting for payers — was always the real project. We’ve also covered how far behind that payer-side build actually was, using WEDI’s own readiness data. This piece is the closing argument: even a hospital that’s done everything right on its own EHR-side integration still needs a live payer counterpart to complete one real transaction and attest honestly.



What This Means for a Hospital or CAH IT Team

Identify, now, which payer relationship is most likely to have a working Prior Authorization API earliest in CY 2027, and plan to run — and document — a real test transaction through it well before the reporting period closes. Don’t wait for a payer’s own confirmation that its API is “ready”; test directly. And decide deliberately, in writing, whether an exclusion genuinely applies to your organization rather than falling into one by default.

None of this is off-the-shelf. A payer’s Prior Authorization API, your CEHRT vendor’s prior-auth module, and your own EHR workflow all have to talk to each other in a way no vendor ships pre-configured — which is exactly the kind of integration work that gets built once, specifically, for the systems you actually run.



Frequently Asked Questions

What exactly do hospitals have to attest under CMS-0057-F starting in 2027?

Eligible hospitals and CAHs must attest “yes” to having requested at least one prior authorization electronically, via a Prior Authorization API using CEHRT data, for one hospital discharge or medical item/service (excluding drugs) during the CY 2027 EHR reporting period — or claim an applicable exclusion (Source: CMS, CMS-0057-F Fact Sheet).

Does the hospital attestation depend on the payer’s API being ready first?

Not explicitly. Payers subject to the rule must have their Prior Authorization API live by January 1, 2027, but the hospital measure only requires that the hospital requested at least one prior authorization electronically sometime during the CY 2027 reporting period — the rule doesn’t guarantee those two timelines align for every hospital-payer pair.

What happens if a hospital or CAH doesn’t attest, or attests “no”?

It factors into the hospital’s or CAH’s Medicare Promoting Interoperability Program score, and falling below the required threshold can trigger a downward Medicare payment adjustment — a reduced annual payment update for hospitals, and reduced reimbursement below 101% of reasonable costs for CAHs (Source: HHS, Scoring, Payment Adjustment, and Hardship Information).

Is this the same requirement as the payer API build deadlines covered in CMS-0057-F?

It’s related but separate. The payer build deadlines (Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization APIs, live by January 1, 2027) are what payers must build. The attestation measure is what hospitals and CAHs must independently demonstrate they used.

Can a hospital just claim an exclusion instead of attesting “yes”?

The rule allows claiming an applicable exclusion, but that should reflect an organization’s actual circumstances — not stand in for integration work that wasn’t completed in time.

Ready to talk?

Attesting to CMS-0057-F from the hospital side in 2027?

The deadline sits with the payer. The readiness sits with you.

Talk to Itirra →

Sources

  1. “CMS Interoperability and Prior Authorization Final Rule CMS-0057-F” — CMS, Fact Sheet
  2. Fact Sheet PDF — CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) — CMS/HHS
  3. “Scoring, Payment Adjustment, and Hardship Information” — HHS, Medicare Promoting Interoperability Program
  4. Payment Adjustment and Hardship Information Tip Sheet — CMS
  5. “CMS-0057-F Isn’t a Payer Deadline. It’s Your Integration Test.” — Itirra
  6. “The Prior Authorization API Is Still ‘Coming Soon.’ The Compliance Deadline Isn’t.” — Itirra