What CMS-0057-F Actually Requires from Hospitals (Not Just Payers)

Jalindar Karande

Jalindar Karande

Blog Date

02 September 2026

Blog read Time

12 min

Share:

What CMS-0057-F Actually Requires from Hospitals (Not Just Payers)

Summary

CMS-0057-F regulates payers directly, Medicare Advantage plans, Medicaid and CHIP programs, and marketplace QHP issuers. Hospitals get pulled in through EHR certification, daily API traffic, and a new Promoting Interoperability attestation. That attestation is optional for CY2027 and turns mandatory starting CY2028, per CMS’s FY2027 IPPS Final Rule, one year later than most compliance calendars still assume.

If you ask five professionals working at your hospital who CMS-0057-F applies to and you will probably get five different answers. Compliance says “not us, that is a payer rule.” IT says “sort of, through the EHR.” Finance just wants to know if it shows up in next year’s capital plan. All three are half right, which is exactly the problem. 

CMS-0057-F, the CMS Interoperability and Prior Authorization Final Rule, technically regulates health plans, not hospitals. But three separate mechanisms pull provider organizations into its compliance perimeter anyway, and one of them carries a real reporting obligation with a deadline that just moved. This piece untangles the payer-versus-provider confusion, walks through what your hospital actually has to do and by when, and flags where the real risk sits if you get it wrong. 

Does CMS-0057-F Apply to Hospitals, or Only to Payers? 

CMS-0057-F hospital requirements exist, but they are a side effect of a rule written for a different audience. The final rule regulates what CMS calls “impacted payers,” and that is a defined, closed list, not a general statement about the health system. 

Directly Regulated (“Impacted Payers”) Explicitly Outside the Rule 
Medicare Advantage (MA) organizations Traditional Medicare Fee-for-Service (Original Medicare) 
State Medicaid & CHIP fee-for-service programs Employer-sponsored / self-funded commercial plans 
Medicaid managed care plans (MCOs, PIHPs, PAHPs) Stand-alone dental plan (SADP) issuers 
CHIP managed care entities FF-SHOP-only issuers 
QHP issuers on the Federally Facilitated Exchanges State-Based Exchange (SBE) issuers 

 That second column answers two questions we hear constantly. Is traditional Medicare FFS subject to CMS-0057-F? No, though CMS has said it wants Original Medicare to be a “market leader” on data exchange voluntarily, which is an intention, not a mandate. Are commercial employer plans exempt? Yes, almost entirely, since the only commercial coverage the rule touches is QHPs sold on the federal exchange.  

The full CMS-0057-F Requirements for Payers run through four FHIR APIs, which we break down below.

The Three Side Doors That Pull Your Hospital In 

The Three Side Doors That Pull Your Hospital InIf your hospital is not a regulated payer, why is this rule on your CIO’s roadmap at all? Three mechanisms do it, and none of them require you to build anything CMS-0057-F itself mandates. 

  1. EHR certification inheritance. Your EHR vendor, Epic, Oracle Health, MEDITECH, whichever you run, has to certify against updated ONC standards to keep selling into the market impacted payers depend on. That certification cascade means your environment inherits new data requirements whether or not your compliance team ever reads the Federal Register notice. Confirm what your vendor has actually shipped against the ONC Certified Health IT Product List before it lands on a board slide marked “done.”

  2. A new Promoting Interoperability Prior Authorization measure. Covered in full in the next section, this is the one true reporting obligation CMS-0057-F creates for providers. It is the reason a “payer rule” now has a line on your MIPS and Promoting Interoperability scorecards.

  3. Daily provider-side API traffic. Once impacted payers stand up their Provider Access and Payer-to-Payer APIs, your staff will pull and push patient data through them constantly, whether or not your organization formally opted in. Does CMS-0057-F require hospitals to build their own FHIR API? No. The build obligation sits with payers. What you do need is a clean way to consume what they build at scale, and that is a real technical decision even without a mandate attached.  

Keen to know how the new regulation and a AI-ready hospital has in common? Read the comprehensive article here: CMS-0057-F and the AI-Ready Hospital: What CIOs Must Solve Before January 2027 

One practical step worth taking this quarter: pull your top payer contracts and mark which ones are actually impacted payers under this rule. A regional Medicaid MCO and a national Medicare Advantage plan both count. A self-funded employer plan administered by the same carrier does not. Knowing the difference changes your leverage in the next vendor conversation, since an impacted payer is working against a federal deadline you can point to and a non-impacted one is not. 

Budget impact follows the same logic. Payers carry the cost of building the APIs, but your hospital absorbs the downstream cost: EHR upgrade fees folded into your maintenance contract, integration tooling to consume payer endpoints at real volume, and the governance work required to prove your attestation is accurate on request. None of that shows up in CMS’s regulatory impact analysis. All of it shows up in your capital plan. 

For most hospitals that isn’t a connectivity problem. Legacy HL7v2 feeds and free-text notes have to become clean FHIR resources before any API call means anything, and that’s exactly where generative AI data mapping for healthcare interoperability earns its keep, turning months of manual field-mapping into a supervised, auditable process. 

The Promoting Interoperability Attestation, Explained 

This is the part most compliance briefings skip past, and it is the one with an actual reporting requirement attached to your organization’s name. 

CMS-0057-F added a new measure called Electronic Prior Authorization to two separate reporting tracks: the Promoting Interoperability performance category of MIPS, for MIPS eligible clinician prior authorization attestation, and the Medicare Promoting Interoperability Program 2027, for eligible hospitals and critical access hospitals. 

Both tracks work the same way. It is an CMS-0057-F yes/no attestation requirement, not a numerator-over-denominator calculation. You, or your CAH, report a simple yes or claim an applicable exclusion, confirming that you requested at least one prior authorization electronically through a payer’s FHIR-based Prior Authorization API, using certified EHR technology, during the reporting period. 

Reporting Track Who It Covers Status 
MIPS Promoting Interoperability category MIPS eligible clinicians CY2027 performance period / CY2029 payment year, as originally finalized 
Medicare Promoting Interoperability Program Eligible hospitals & Critical Access Hospitals Optional bonus for CY2027, mandatory from CY2028 (FY2027 IPPS Final Rule) 

 Are Critical Access Hospitals affected by CMS-0057-F?  

Yes, explicitly. CAHs sit in the same reporting bucket as eligible hospitals under the Medicare Promoting Interoperability Program, not a separate, lighter-touch category. 

This single line is also how CMS-0057-F interacts with your existing Promoting Interoperability scoring. Electronic Prior Authorization sits inside the Health Information Exchange objective, next to measures you already report. It does not replace your current PI obligations. It adds one more, worth bonus points now and a required line item later. 

If your data foundation is not ready for one clean attestation, it is not ready for AI at scale either. They are the same gap, wearing two different deadlines. Leaders need to align with the regulation objectives by transforming the data foundation for building an AI-Ready infrastructure for hospitals & ambulatory organizations.  

2027 vs. 2028: The Deadline Most CIOs Still Have Wrong 

A lot of hospital compliance calendars are quietly out of date on this exact point. 

When CMS-0057-F was finalized in January 2024, the Electronic Prior Authorization measure was written as effective for eligible hospitals and CAHs starting the CY2027 EHR reporting period, full stop. That is still the number sitting in a lot of 2025-era compliance decks. 

It changed.  

In the CMS FY2027 IPPS rule hospital prior authorization update, CMS finalized a one-year softening specifically for hospitals and CAHs: the measure is now an optional bonus measure for CY2027, attest yes and earn 10 bonus points toward your PI score, no exclusion needed because it is voluntary, becoming a CMS-0057-F provider compliance 2027 non-issue this year and a mandatory measure starting CY2028. 

That is genuinely good news, one more year of runway on this specific line item. It is not, however, a reason to sit still. Here is why. The hard part was never the attestation checkbox. It is the underlying capability: a working connection to a payer’s live Prior Authorization API, patient and encounter data clean enough to generate a real submission, and a workflow that gets a clinician or utilization management team to actually use it. That build takes months. Checking a box takes ten minutes. Treat CY2027 as a free pass and you simply move the scramble to late 2027, competing with every other hospital in your market for the same integration vendors at the same time. That’s the kind of gap an outside AI healthcare consulting engagement tends to catch faster than an internal audit, because it’s looking specifically for the space between what’s on the roadmap and what’s actually in production. 

CMS-0057-F 2028 hospital extension, in short: real, confirmed, and not an excuse to wait.

Contact UsCMS-0057-F vs. CMS-9115-F: What Actually Changed 

CMS-0057-F did not start from a blank page. It builds directly on CMS-9115-F, the 2020 CMS Interoperability and Patient Access Final Rule, which first required impacted payers to stand up a Patient Access API and a Provider Directory API. 

CMS-0057-F keeps that foundation and adds three new FHIR APIs, plus operational teeth the earlier rule never had. 

FHIR API What It Does New or Expanded? 
Patient Access API Lets patients pull claims, clinical, and now prior authorization data into apps of their choice Expanded (originated in CMS-9115-F; PA data added by CMS-0057-F) 
Provider Access API Shares claims, clinical, and PA data with in-network providers for patients they treat New in CMS-0057-F 
Payer-to-Payer API Moves up to five years of claims and clinical history when a patient switches plans New in CMS-0057-F 
Prior Authorization API Automates PA request submission, decision tracking, and specific denial reasons New in CMS-0057-F 

 The practical difference for a hospital: CMS-9115-F never created a provider-side reporting obligation. CMS-0057-F does, through the Promoting Interoperability attestation covered above. That is the line separating “a payer compliance rule we read about once” from “a measure with our organization’s name attached to it.” 

What Happens If You Don’t Attest, or Get It Wrong 

What Happens If You Don't Attest, or Get It WrongTwo separate risk tracks live under this rule, and hospitals routinely conflate them. 

  • Track one: missing the Electronic Prior Authorization measure itself. For CY2027, there is no penalty for skipping it. It is optional, and no exclusion process exists because none is needed, you simply forgo the 10 bonus points. Starting CY2028, that changes. Once it becomes a required measure, failing to attest without a qualifying exclusion counts against your Promoting Interoperability score the same way missing any other required PI measure would, which can affect your standing as a meaningful EHR user and, downstream, your Medicare payment update. 
  • Track two: information blocking. This is the sharper edge, and it does not run through CMS-0057-F directly. It sits under the separate 21st Century Cures Act framework. If your hospital cannot produce a documented, defensible reason for withholding electronic health information from a legitimate Provider Access or Payer-to-Payer request, and OIG investigates and refers a finding to CMS, the consequences are concrete. An eligible hospital loses meaningful EHR user status for that reporting period and forfeits three-quarters of its annual market basket payment increase.  

A CAH gets paid 100% of reasonable costs instead of 101%. HHS’s own estimate put the median financial hit at roughly $394,000, ranging from about $30,000 to $2.4 million depending on the hospital. 

The realistic risk exposure for a hospital that treats CMS-0057-F as someone else’s problem: low on the attestation itself through 2027, real and growing from 2028 forward, and already live today on the information blocking side, which has applied to Medicare-enrolled providers since July 2024.

Should You Voluntarily Attest in 2027 for the Bonus Points? 

Given the compliance risk is genuinely light this year, the more useful question is not a compliance question at all. It is a strategic one.  

Yes, and here is the actual reasoning. The technical build, connecting to a payer’s Prior Authorization API and generating one real submission, is the same work whether you do it as an optional pilot in 2027 or a mandatory rollout in 2028. Doing it now, while the stakes are low and there is no exclusion pressure, means your first real submission happens as a controlled test, instead of scrambling and competing for the same Prior Authorization API bonus points promoting interoperability and the same integration vendors. 

Treat CY2027 as your evidence-generating year. Pick one payer relationship, most likely your highest-volume Medicare Advantage plan, run one clean electronic prior authorization through it, and use that single transaction to validate your workflow, your data quality, and your governance sign-off process before any of it is mandatory. That is a defensible pilot with a real regulatory deadline behind it, which happens to be exactly the kind of proof point a board actually trusts over a vendor demo. 

Frame this correctly and CMS-0057-F stops being a compliance line item. It becomes the budget justification that finally gets digital transformation in healthcare funded as infrastructure.

What Your CIO Should Tell the Board 

Boards do not need the FHIR API taxonomy. They need three things, stated plainly. 

  • This is a data-readiness deadline wearing a compliance disguise. The clean patient identities, governed data lineage, and FHIR-based connectivity CMS-0057-F assumes are the same foundation any serious AI initiative needs. Fund it once, not twice. 
  • The hospital-side deadline moved; the underlying work did not shrink. CY2027 optional, CY2028 mandatory buys a year of runway, not a year of inaction. 
  • Real financial exposure sits in information blocking, not the attestation checkbox. That risk is live now, not in 2028. 

Talk to Our Strategy ConsultantsFrequently Asked Questions 

It directly regulates payers, Medicare Advantage, Medicaid and CHIP programs, and marketplace QHP issuers. Hospitals get pulled in through EHR certification, daily API use, and a new Promoting Interoperability attestation.

A new attestation measure requiring eligible hospitals and CAHs to report yes or no on whether they requested at least one prior authorization electronically through a payer’s FHIR Prior Authorization API. 

CMS-9115-F (2020) created the original Patient Access API. CMS-0057-F (2024) expands it and adds three new APIs, Provider Access, Payer-to-Payer, and Prior Authorization, plus the hospital-side attestation. 

Both, technically. CY2027 is an optional bonus measure worth 10 points. It becomes mandatory starting CY2028, per CMS’s FY2027 IPPS Final Rule. 

Yes. CAHs report under the same Medicare Promoting Interoperability Program track as eligible hospitals, with no separate carve-out.

No. Original Medicare FFS sits outside the rule’s direct requirements, though CMS has said it wants FFS to align voluntarily. 

Nothing in CY2027, since it is optional. From CY2028, missing it without an exclusion counts against your Promoting Interoperability score like any other required measure. 

It is the API impacted payers must build so in-network providers can pull a patient’s claims, clinical, and prior authorization data. Hospitals do not build it, but staff will use it daily once payers deploy it. 

About the author

Jalindar Karande

Jalindar Karande

Author

LinkedIn

Jalindar Karande is Director – Solutions at Inferenz, with 20+ years of experience delivering turnkey enterprise solutions across AI and Data. He specializes in identifying complex business challenges and translating them into scalable technology solutions. With expertise in GenAI, Snowflake, Databricks, BigQuery, cloud platforms, and orchestration tools, he helps organizations accelerate data-driven transformation and achieve measurable business outcomes.