CMS-0057-F Rule: FHIR APIs & Cures Act Exceptions

CMS-0057-F—formally titled the CMS Interoperability and Prior Authorization Final Rule (89 FR 8758, published February 8, 2024)—is a federal regulation issued by the Centers for Medicare & Medicaid Services (CMS) that mandates standardized HL7 FHIR application programming interfaces (APIs) and strict decision turnaround timelines for health plans and healthcare providers. Operating alongside the 21st Century Cures Act Information Blocking regulations (45 CFR Part 171) and the Trusted Exchange Framework and Common Agreement (TEFCA), CMS-0057-F replaces manual fax-and-portal prior authorization workflows with automated EHR-to-payer clinical data exchange.

What Is the CMS-0057-F Interoperability and Prior Authorization Final Rule?

CMS-0057-F applies to a defined group of regulated health plans referred to by CMS as impacted payers:

Medicare Advantage (MA) organizations
State Medicaid and Children’s Health Insurance Program (CHIP) Fee-for-Service (FFS) agencies
Medicaid managed care plans and CHIP managed care entities
Qualified Health Plan (QHP) issuers on the Federally Facilitated Exchanges (FFEs)

The final rule addresses two major bottlenecks in US clinical care delivery and health informatics: (1) longitudinal clinical and claims data fragmentation when patients move between providers or health plans, and (2) administrative delays in utilization management and prior authorization for medical items and services (excluding prescription drugs, which are governed under separate Part D electronic prior authorization standards).

The Four HL7 FHIR APIs Mandated by CMS-0057-F and Compliance Dates

CMS-0057-F establishes a two-stage compliance timeline across 2026 (operational decision turnaround times and public reporting) and January 1, 2027 (production deployment of four HL7 FHIR R4 APIs built on US Core, the SMART App Launch Framework, and HL7 Da Vinci Implementation Guides):

Mandated API / Provision	Compliance Deadline	Recommended Technical Standards & IGs	Required Data Payload & Workflow Scope
1. Patient Access API (Expanded)	January 1, 2027	HL7 FHIR R4, US Core IG, CARIN Blue Button IG, SMART App Launch (OAuth 2.0 / OpenID Connect)	Adds non-drug prior authorization requests, approval/denial status, effective dates, and structured denial reasons to existing claims, encounter, and USCDI clinical data
2. Provider Access API	January 1, 2027	HL7 FHIR Bulk Data Access IG, PDex (Payer Data Exchange) IG, US Core IG	Requires impacted payers to share adjudicated claims (excluding cost/price data), encounter data, all USCDI data classes, and prior authorization records with in-network providers subject to a patient opt-out process
3. Payer-to-Payer API	January 1, 2027	HL7 FHIR PDex IG, Bulk Data Access IG, US Core IG	Exchanges a 5-year lookback of claims, encounters, USCDI clinical data, and active/recent prior authorizations when a beneficiary switches payers or holds concurrent coverage, subject to patient opt-in permission
4. Prior Authorization API	January 1, 2027	HL7 Da Vinci CRD (Coverage Requirements Discovery), DTR (Documentation Templates & Rules), and PAS (Prior Authorization Support)	Allows clinicians to query inside the EHR whether an item/service requires prior authorization, auto-populate required clinical documentation templates via FHIR Questionnaire/CQL, and submit/receive electronic prior authorization determinations
Operational Decision Timelines & Public Metrics	January 1, 2026 (Metrics: March 31, 2026)	CMS-0057-F Administrative Rules	Impacted payers (except QHP issuers on FFEs) must issue expedited prior authorization decisions within 72 hours and standard decisions within 7 calendar days, state specific denial reasons, and publicly report annual prior authorization metrics

In addition to payer mandates, CMS-0057-F adds an Electronic Prior Authorization attestation measure to the Merit-based Incentive Payment System (MIPS) Promoting Interoperability performance category for Merit-eligible clinicians and the Medicare Promoting Interoperability Program for eligible hospitals and Critical Access Hospitals (CAHs) beginning in calendar year 2027.

What Are the 8 Exceptions to the 21st Century Cures Act Information Blocking Rule?

As providers and health plans exchange Electronic Health Information (EHI) through FHIR APIs, Health Information Exchanges (HIEs), and TEFCA, their practices are governed by the 21st Century Cures Act Information Blocking Rule (42 U.S.C. § 300jj-52; implemented by ASTP/ONC in 45 CFR Part 171). Under Part 171 Subparts B and C, ONC established eight core regulatory exceptions (divided into two categories, later supplemented in Subpart D by the TEFCA Manner Exception for Qualified Health Information Network participants). When an actor’s practice satisfies all conditions of an applicable exception, the practice is legally deemed not to constitute information blocking:

Category 1: Exceptions That Involve Not Fulfilling Requests to Access, Exchange, or Use EHI (45 CFR Subpart B)

Preventing Harm Exception (45 CFR § 171.201): Permits an actor to engage in a practice that is reasonable and necessary to prevent physical harm to a patient or another person, provided the risk is determined on an individualized basis by a licensed healthcare professional (or stems from corrupt/misidentified data).
Privacy Exception (45 CFR § 171.202): Permits an actor not to fulfill a request to protect an individual’s privacy when one of four sub-exceptions is met: (a) an unsatisfied precondition under state or federal privacy law (such as missing HIPAA authorization), (b) a HIPAA Privacy Rule restriction for Substance Use Disorder or mental health records, (c) a denial of an individual’s access request permitted under 45 CFR § 164.524, or (d) honoring an individual’s uncoerced request not to share their EHI.
Security Exception (45 CFR § 171.203): Permits justifiable security restrictions directly related to safeguarding the confidentiality, integrity, and availability of EHI.
Infeasibility Exception (45 CFR § 171.204): Applies when fulfilling a request is genuinely infeasible due to uncontrollable events (such as natural disasters or public health emergencies), inability to unambiguously segment the requested EHI from withheld EHI, or documented technical infeasibility under the circumstances (for which the actor must provide a written explanation within 10 business days).
Health IT Performance Exception (45 CFR § 171.205): Allows reasonable, temporary downtime or throttling necessary to maintain or improve health IT performance, provided maintenance is planned and non-discriminatory (or responds to an unplanned outage).

Category 2: Exceptions That Involve Procedures for Fulfilling Requests (45 CFR Subpart C)

Content and Manner Exception (45 CFR § 171.301): Allows an actor to fulfill an EHI request in an alternative technological manner (such as standard FHIR APIs, USCDI/EHI export formats, or machine-readable formats) when the actor cannot reach agreeable terms with the requestor or cannot technically support the exact manner requested.
Fees Exception (45 CFR § 171.302): Permits an actor to charge reasonable, cost-based fees for accessing, exchanging, or using EHI—provided the fees are based on objective criteria, exclude opportunistic profit or competitor exclusion, and never charge patients for electronic access to their own EHI.
Licensing Exception (45 CFR § 171.303): Permits an actor to license interoperability elements on reasonable and non-discriminatory (RAND) terms upon receiving a request, beginning negotiations within 10 business days and concluding within 30 business days.

When Does the Information Blocking Security Exception (45 CFR § 171.203) Apply?

Health systems and payers frequently ask whether blocking an unverified third-party SMART on FHIR app or throttling suspicious API traffic violates information blocking rules. Under 45 CFR § 171.203, the Security Exception protects an actor’s security practice only when it satisfies three overarching threshold requirements plus one of two operational pathways:

Three Mandatory Threshold Conditions (§ 171.203(a)–(c)):
1. The practice must be directly related to safeguarding the confidentiality, integrity, and availability of EHI.
2. The practice must be tailored to the specific security risks being addressed.
3. The practice must be implemented in a consistent and non-discriminatory manner (i.e., an EHR vendor or health system cannot impose onerous security vetting on third-party research or care-coordination apps that it waives for its own affiliated applications).
Pathway A — Organizational Security Policy (§ 171.203(d)): If the practice implements an organizational security policy, that policy must be in writing, have been prepared on the basis of individualized risk analysis, align with consensus security standards (such as NIST Cybersecurity Framework or ISO/IEC 27001), and be implemented PRIOR to the dispute.
Pathway B — Specific Security Determination (§ 171.203(e)): If the practice does not follow a pre-existing written policy (for example, blocking an active zero-day exploit or a compromised OAuth client token), the actor must make an individualized determination based on observable facts that the practice is necessary to mitigate a specific security risk, and there must be no reasonable and appropriate alternative practice that would pose less interference with EHI access, exchange, or use.