Electronic Prior Authorization Under HIPAA Standards

Prior authorization is a structural bottleneck in health care, one that costs physicians time, delays patients' access to care, and, in a meaningful share of cases, ends in real harm. It is a structural bottleneck in health care, one that costs physicians time, delays patients' access to care, and, in a meaningful share of cases, ends in real harm. The regulatory response to that bottleneck now runs through a specific and fairly technical set of federal rules, built around FHIR-based APIs and layered on top of the older HIPAA transaction standard, X12 278. Understanding how that framework fits together (what's mandatory now, what's coming next, and where the two standards actually overlap) matters for anyone who touches the authorization process, on either side of the transaction.

The scale of the problem is why CMS moved. A 2025 RAND Corporation commentary found doctors handling an average of 43 prior authorizations apiece, consuming more than 16 hours of physician time per week, a number that assumes staff support and undercounts what happens in smaller practices. An AMA survey of 1,004 physicians found 34% reporting that prior authorization delays led to a serious adverse event for a patient in their care, including hospitalization, disability, or death. On the patient side, 58% of insured adults who needed specialized care ran into a delay or denial tied to prior authorization, 95% of physicians report care delays tied to the process, and 47% say prior authorization has led to an immediate care visit or an ER trip that could plausibly have been avoided. Those numbers are the reason regulators stopped treating prior authorization as an administrative detail and started treating it as a target for structural reform.

The traditional HIPAA transaction standard, X12 278, for prior authorization today

HIPAA's Administrative Simplification provisions designated the ANSI X12 EDI 278 transaction set as the standard format for sending and receiving authorization and referral requests. It's a batch-style transaction built on an older data-exchange standard, from an era when the fax machine was still the alternative worth beating. The 278 can run as a one-way request (provider asks, nothing structured comes back) or as a two-way inquiry-and-response, where the payer answers using the same transaction format, which is the version most people mean when they talk about "electronic" prior authorization today.

A 278 can cover services the requesting provider intends to perform directly, or it can cover a referral to a different provider entirely, so the same transaction set handles both authorization and referral certification. Version matters here in a way that trips people up: Version 5010 has been the HIPAA-mandated X12 standard for administrative transactions since 2012, and any system still running on an earlier version isn't just outdated, it's out of compliance. The 278 has done real work reducing fax and phone-based authorization, but it was never built for real-time, point-of-care decision support, and the newer rules are trying to close that gap.

The three-rule arc that built the current regulatory framework

None of this arrived as a single mandate. CMS built it in stages, each rule extending the one before it rather than replacing it.

The first stage, CMS-9115-F, laid the foundation: interoperability APIs across Medicare Advantage, Medicaid, CHIP, and Qualified Health Plan issuers on the Federally-facilitated Exchanges. It didn't touch prior authorization specifically. It just made sure the plumbing, the API infrastructure, existed.

The second stage, CMS-0057-F, is the rule most people mean when they talk about electronic prior authorization today. It mandates FHIR-based APIs and electronic prior authorization for non-drug items and services, and it applies to Medicare Advantage organizations, Medicaid and CHIP fee-for-service programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs, collectively referred to as "impacted payers." Providers aren't directly on the hook for compliance, but they'll feel every bit of the downstream change in how requests get submitted and answered. CMS projects $15 billion in savings over ten years from this rule alone, split between operational provisions that generally start January 1, 2026 and API requirements that generally start January 1, 2027.

The third stage, CMS-0062-P, released April 10, 2026, extends the same logic to prescription drugs. Its comment period closed June 15, 2026. It proposes requiring impacted payers to support electronic prior authorization for every drug that requires it, across both medical and pharmacy benefits, and it introduces NCPDP SCRIPT, Formulary & Benefit, and Real-Time Prescription Benefit standards for pharmacy-benefit drugs, running alongside FHIR for medical-benefit drugs. The proposed compliance date is October 1, 2027.

What CMS-0057-F requires: operational provisions in 2026 and API mandates in 2027

Two separate clocks are running here, and conflating them is probably the single most common mistake in how people talk about this rule.

The operational provisions kick in January 1, 2026. Impacted payers, other than QHP issuers on the FFEs, have to respond to expedited requests within 72 hours and standard requests within 7 calendar days. Denials now require an actual, specific reason, which replaces the old boilerplate ("not medically necessary" and nothing else) that gave providers no real foothold for an appeal. Payers also have to publicly post prior authorization metrics, approval rates, denial rates, response times, for the previous calendar year; the first posting, covering 2025 data, was due by March 31, 2026. On top of that, impacted payers take on additional reporting obligations to CMS tied to the new API requirements.

The API requirements kick in a year later, January 1, 2027. Several FHIR APIs become mandatory, including a Patient Access API expanded to include prior authorization status, a Provider Access API, a Payer-to-Payer API, and a Prior Authorization API. The Prior Authorization API has to publish which items and services actually require prior authorization, spell out documentation requirements, and support the full submission-and-adjudication cycle, including communicating approvals with end dates and conditions attached, denials with a specific reason, and requests for more information when the payer needs it. The Provider Access API lets in-network providers with an existing treatment relationship pull a patient's claims, encounter, clinical, and prior authorization data, with patients retaining rights over their own data access. The Payer-to-Payer API supports continuity of care when a patient switches plans, requiring payers to share data going back five years from the date of the request.

There's a financial lever attached to all of this, too. CMS added an "Electronic Prior Authorization" measure to the Health Information Exchange objective under the MIPS Promoting Interoperability category. MIPS-eligible clinicians report starting with the 2027 performance period, tied to the 2029 payment year, while eligible hospitals and critical access hospitals can report it as an optional bonus starting with the 2027 EHR reporting period, becoming mandatory in 2028. The FY 2027 IPPS Final Rule locked in that same timeline. That's a direct financial nudge pushing providers toward electronic prior authorization adoption, on top of whatever operational relief the rule itself provides.

The FHIR technical stack CMS mandates and the standards beneath it

CMS didn't just say "use FHIR" and leave it at that. The rule specifies a precise technical baseline. The core standard is HL7 FHIR Release 4.0.1, the exact version impacted payers have to implement, a specific technical baseline rather than a general reference to "FHIR" as a concept.

Five supporting pieces sit beneath that core standard, and each does a specific job. USCDI (the United States Core Data for Interoperability) defines the minimum data set that has to be exchangeable across systems. SMART App Launch supports EHR-embedded workflows, reducing the need for clinicians to leave their primary system to interact with payer portals. Bulk Data Access supports pulling data at scale across the required APIs. Standard identity and authorization protocols underpin API access, providing the security layer the system requires.

CMS strongly encourages, though doesn't mandate, a set of Da Vinci Implementation Guides that sit on top of the FHIR foundation and supply the actual clinical workflow logic. Coverage Requirements Discovery (CRD) shows whether a service needs prior authorization and what documentation it requires at the point of ordering, before anything gets submitted. Documentation Templates and Rules (DTR) pulls the required templates directly into the EHR workflow, so a clinician fills them out without leaving the system they're already working in. Prior Authorization Support (PAS) handles the actual electronic submission and carries the payer's response back into the EHR. Together, these three guides are what turn a bare FHIR API mandate into something that could plausibly feel, to a clinician, like a single continuous workflow rather than three disconnected systems talking past each other.

The coexistence of X12 278 and FHIR (and the enforcement discretion that changed the equation)

CMS-0057-F created a FHIR API mandate that runs parallel to the existing X12 278 requirement, not in place of it. HIPAA still designates X12 278 as the standard transaction for referral certification and authorization. CMS never repealed that requirement when it mandated the new APIs, which meant that, for a stretch after the 2024 rule, payers technically owed compliance to both standards at once, a real problem for any payer that wanted to build FHIR-only and skip maintaining the older EDI pipeline.

HHS resolved that tension with an enforcement discretion for HIPAA covered entities that implement and use a FHIR-based Prior Authorization API as described in CMS-0057-F. In practice, that means HIPAA Administrative Simplification enforcement won't come after covered entities that skip the X12 278 and run an all-FHIR Prior Authorization API instead. That's a genuinely significant moment in HIPAA's history, allowing FHIR to function as a standalone transaction path rather than sitting alongside EDI as a complement to it.

Real-world implementation, though, mostly isn't going all-FHIR overnight. Plenty of payer back-end systems are built on X12 EDI, and rebuilding that infrastructure from scratch isn't a weekend project. The practical architecture that's emerged has FHIR facing the provider and EHR side, handling the inbound request and outbound response, while internal translation converts that traffic to X12 278 for the older adjudication systems running in the background. That hybrid model fits within the framework the enforcement discretion was designed to accommodate. Providers interact through FHIR; payers route the data internally however their legacy systems require.

How the 2026 proposed rule extends ePA to prescription drugs

CMS-0062-P, released April 14, 2026, is still a proposed rule, pending finalization, so every provision below is exactly that: proposed, not locked in.

The gap it's meant to close is a deliberate one. CMS-0057-F excluded drugs entirely, and CMS-0062-P extends nearly all of the same electronic prior authorization requirements to prescription drugs, across both the medical benefit and the pharmacy benefit. The standard that applies depends on how the drug gets billed. Medical benefit drugs, things like infused or injected drugs billed on a medical claim, would run through the Prior Authorization FHIR API already required under CMS-0057-F, no new technical standard needed there. Pharmacy benefit drugs, the ones dispensed at a retail or mail-order pharmacy, would instead require support for NCPDP SCRIPT, a separate and already well-established electronic standard for pharmacy transactions.

That NCPDP SCRIPT alignment draws on an already well-established electronic standard for pharmacy transactions, extending consistent electronic prior authorization requirements across Medicaid, CHIP, and QHP issuers on the FFEs. The proposed capabilities for pharmacy-benefit drugs include a group-level formulary and benefit standard loaded directly into the provider's EHR, real-time prescription benefit information showing a specific patient's coverage and out-of-pocket cost, and electronic submission and response for the prior authorization itself. The proposed compliance date is October 1, 2027, and until the rule is finalized, that date and every provision attached to it remain proposals rather than settled law.