Ask almost any physician practice or hospital utilization review team what eats the most staff time, and prior authorization is usually near the top of the list. Faxed forms, payer web portals with no shared standard, phone holds to confirm a decision that already exists somewhere in a computer system — the process has become a recurring symbol of administrative burden in American health care. In December 2022, the Centers for Medicare & Medicaid Services (CMS) put forward a detailed regulatory response: a proposed rule that would require many health plans to build standardized, FHIR-based application programming interfaces (APIs) for prior authorization and to meet firm decision deadlines. It has not been finalized, and its provisions are not yet in effect, but it represents the clearest sign yet of where federal policy on electronic prior authorization is headed.

This article summarizes what the December 2022 proposed rule contains, who it would apply to, the technical standards it references, and the burden-reduction goals CMS says are driving it. Because this is a proposed rule under active federal rulemaking, the details below should be treated as a snapshot of the proposal as published — not a description of a final, binding requirement. Readers who need to make compliance decisions should consult the primary source materials linked throughout and appropriate legal or regulatory counsel, since proposed rules can and do change materially before finalization.

A Second Attempt at Prior Authorization Reform

This is not CMS’s first pass at this topic. In December 2020, the agency issued an earlier prior authorization proposed rule that would have required similar payer APIs. That 2020 proposal was never finalized and was ultimately withdrawn amid stakeholder concerns and a change in administration. CMS carried many of the underlying goals forward, and on December 6, 2022, it announced a new proposed rule — “Advancing Interoperability and Improving Prior Authorization Processes” (identified in the rulemaking docket as CMS-0057-P) — that was published in the Federal Register on December 13, 2022, opening a public comment period that ran through March 13, 2023.

It is worth being precise about the rule’s status as of this writing: this is a proposed rule, not a final one. Proposed rules describe what an agency intends to require and invite public comment before anything becomes binding. CMS can and often does revise timelines, scope, and specific requirements between a proposed rule and the eventual final rule, and there is no guarantee every element described here will survive unchanged — or that the rule will be finalized on the schedule CMS initially outlined.

Who Would Be Affected

The proposed rule targets a broad slice of the payer landscape, though notably not commercial employer-sponsored insurance generally. As proposed, it would apply to:

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

CMS refers to this group collectively as “impacted payers” throughout the proposal. The rule would also touch clinicians and hospitals indirectly, through proposed new measures under the Merit-based Incentive Payment System (MIPS) Promoting Interoperability performance category and the Medicare Promoting Interoperability Program for eligible hospitals and critical access hospitals — intended to create an incentive on the provider side to actually adopt electronic prior authorization workflows once payers build the required APIs.

The Proposed FHIR-Based APIs

The technical core of the proposal is a set of HL7 Fast Healthcare Interoperability Resources (FHIR) APIs that impacted payers would be required to build, building on the Patient Access API framework CMS established in its earlier 2020 Interoperability and Patient Access final rule. As proposed, these would include:

  • An expanded Patient Access API, adding prior authorization status and decision information to the data patients (and their authorized apps) can already retrieve about their own claims and coverage.
  • A Provider Access API, giving in-network providers electronic access to a patient’s claims, encounter, and prior authorization data held by the payer — intended to give clinicians visibility into a patient’s history without manual record requests.
  • A Payer-to-Payer API, allowing patients to have their claims and prior authorization history follow them electronically when they switch health plans, reducing the “start from zero” problem when coverage changes.
  • A Prior Authorization API — sometimes referenced in CMS materials and industry commentary as the PARDD API (Prior Authorization Requirements, Documentation, and Decision) — that would let a provider’s system query a payer electronically to find out whether a given item or service requires prior authorization, what documentation is needed, and ultimately submit the request and receive a decision, largely without manual portal entry or faxing.

CMS’s proposal leans on implementation guides developed through HL7’s Da Vinci Project, an industry initiative focused on FHIR-based clinical and administrative data exchange. The most relevant guides are:

  • Coverage Requirements Discovery (CRD) — surfaces payer documentation and prior authorization requirements to a clinician inside their existing workflow, at the moment an order or referral is being placed.
  • Documentation Templates and Rules (DTR) — helps the provider’s system determine what specific clinical documentation a payer’s rule requires and assemble it in a structured, computable format.
  • Prior Authorization Support (PAS) — defines how a completed prior authorization request, along with its supporting documentation, is transmitted electronically to the payer and how the decision is returned.

Together, CRD, DTR, and PAS are meant to function as connected steps in a single electronic workflow: discover the requirement, gather the documentation, and submit the request — all without leaving the electronic health record (EHR).

Proposed Decision Timeframes and Denial Transparency

Beyond the API architecture, the proposed rule would impose new speed and transparency requirements on prior authorization decisions themselves. For most impacted payers (QHP issuers on the FFEs are treated somewhat differently in the proposal), CMS proposed requiring:

  • A decision within 72 hours for expedited (urgent) prior authorization requests
  • A decision within 7 calendar days for standard (non-urgent) requests
  • A specific reason for any denial, regardless of the channel used to communicate it, so a provider can understand what went wrong and correct a resubmission if appropriate

These proposed timeframes are considerably faster than what many patients and providers report experiencing today under manual or fax-based processes, and CMS has framed them as a direct response to complaints — including from its own Office of Inspector General and physician groups — that prior authorization delays can postpone medically necessary care.

Proposed Public Reporting and Provider Incentives

CMS also proposed requiring impacted payers to publicly report certain prior authorization metrics, such as approval and denial rates and average decision times, broken out by item or service category. The stated intent is to give providers, patients, and regulators visibility into how individual payers are actually performing against the process, rather than relying on anecdotal complaints.

On the provider side, the proposal includes new measures under MIPS and the Medicare Promoting Interoperability Program that would give eligible clinicians and hospitals credit for using certified health IT to query payer requirements electronically (aligned with CRD) and to submit prior authorization requests electronically (aligned with PAS), rather than by phone, fax, or manual portal entry. The design intent is to align financial and workflow incentives on both sides of the transaction — payers build the pipes, and providers get a formal quality-program reason to use them.

The Burden-Reduction Rationale

CMS has been explicit that reducing administrative burden — for providers and, ultimately, for patients waiting on care decisions — is the central policy justification for this proposal. Prior authorization has repeatedly ranked among the most cited sources of physician administrative burden and burnout in surveys from provider associations, and manual, non-standardized processes have been linked to care delays. By requiring a common FHIR-based technical foundation across a large share of the payer market, CMS’s stated goal is to move prior authorization from a fragmented, largely manual process toward one where routine determinations can happen electronically and near-instantaneously, reserving human review for genuinely complex cases.

It is important to note, however, that the proposed rule as of late 2022 does not eliminate prior authorization as a utilization management tool, nor does it mandate which specific services require prior authorization — those decisions remain with individual payers. The rule is about how the process happens electronically and how fast it must move, not whether prior authorization itself continues to exist.

Timeline and What Comes Next

As proposed in December 2022, CMS outlined compliance dates tied to plan years and rating periods beginning on or after January 1, 2026, for the provisions requiring new or enhanced APIs, with the MIPS and Promoting Interoperability measures tied to subsequent program years. These dates are proposed only. Federal rulemaking on a proposal of this scope typically involves reviewing thousands of public comments, and CMS has revised timelines in comparable interoperability rules in the past. Readers tracking this topic should watch for a final rule, which — if and when issued — would specify the requirements and compliance dates that actually take legal effect, potentially with changes from what was proposed here.

For the authoritative and most current version of this rulemaking, see the CMS Advancing Interoperability and Improving Prior Authorization Proposed Rule (CMS-0057-P) fact sheet on CMS.gov.

Frequently Asked Questions

Is the CMS electronic prior authorization rule final as of late 2022?

No. As of this writing, it is a proposed rule (CMS-0057-P), published in the Federal Register on December 13, 2022, with a public comment period that closed March 13, 2023. CMS must review comments before issuing a final rule, and specific provisions — including timelines — may change before finalization.

What is the difference between this proposal and the 2020 prior authorization rule?

CMS issued an earlier prior authorization proposed rule in December 2020 covering similar ground, but it was never finalized and was ultimately withdrawn. The December 2022 proposal restarts the rulemaking process, incorporating feedback CMS says it received on the earlier effort while adding new elements like proposed decision timeframes and denial reason requirements.

Which health plans would the proposed rule apply to?

As proposed, it would cover Medicare Advantage organizations, state Medicaid and CHIP fee-for-service programs, Medicaid managed care plans, CHIP managed care entities, and Qualified Health Plan issuers on the Federally-Facilitated Exchanges. It does not generally extend to employer-sponsored commercial insurance outside the FFEs.

What FHIR standards does the proposed rule reference?

CMS points to HL7 Da Vinci implementation guides, including Coverage Requirements Discovery (CRD), Documentation Templates and Rules (DTR), and Prior Authorization Support (PAS), as the technical basis for the proposed Prior Authorization API and related electronic workflows.

Does the proposed rule eliminate prior authorization requirements?

No. The proposal addresses how prior authorization is processed electronically and how quickly payers must respond — proposed decision windows of 72 hours for expedited requests and 7 calendar days for standard requests — not whether payers can require prior authorization for specific services, which remains a payer-level decision.