The CMS Interoperability and Prior Authorization rule

The rule ties two goals together: making health data flow more freely among plans, providers, and patients, and reducing the friction that prior authorization adds to care. Identified in CMS documents as CMS-0057-F and finalized in early 2024, it builds on the agency's earlier 2020 Interoperability and Patient Access rule, which first required certain payers to expose patient data through standardized programming interfaces. The newer rule extends that foundation specifically to the authorization process, obligating covered plans to share requirements electronically, decide requests faster, and report on how they use prior authorization.

Importantly, the rule governs payer behavior rather than the clinical criteria behind any decision. It does not define which services need approval or what counts as medically necessary — those judgments remain with each payer and its policies. What the rule changes is the plumbing and the timeline around the request: how information moves, how quickly a determination must be returned, and what a plan must disclose when it declines a service.

The rule reaches the payers CMS directly oversees. That scope is central to understanding it, because a requirement that binds a Medicare Advantage organization may not apply to a neighboring employer-sponsored plan at all. The categories of impacted payers are:

• Medicare Advantage organizations
• State Medicaid and CHIP fee-for-service programs
• Medicaid and CHIP managed care plans
• Qualified Health Plan issuers on the Federally-Facilitated Exchanges

Most commercial and self-funded employer plans fall outside the rule's direct authority, though some adopt similar practices voluntarily or under separate state laws. Prescription drugs are also largely excluded from the rule's prior authorization provisions; medication approvals continue to run through pharmacy-benefit processes and other standards. Because the rule's reach varies by payer type and program — and because states may layer their own prior authorization laws on top — the requirements that actually apply should be confirmed against the specific plan and jurisdiction involved. The related articles on prior authorization under Medicare Advantage and under Medicaid describe how each program administers authorization within that framework.

A core mechanism of the rule is a set of application programming interfaces, or APIs, built on the HL7 FHIR standard — a common healthcare data format that lets different systems exchange structured information. Rather than prescribing one vendor's product, the rule requires covered payers to expose data through these standardized interfaces so that the provider and patient applications that connect to them can exchange information in a common format. Four interfaces are central to the rule.

Patient Access API

Lets patients retrieve their own claims, encounter, and — under the newer rule — prior authorization information through an application they choose.

Provider Access API

Shares a patient's data, including prior authorization details, with in-network providers to support care coordination.

Payer-to-Payer API

Moves a member's data, including active prior authorizations, from a former plan to a new one when the patient changes coverage.

Prior Authorization API

A FHIR-based interface intended to tell a provider's system whether a service needs authorization, what documentation is required, and the payer's decision — the technical backbone for electronic prior authorization.

Beyond data sharing, the rule imposes several operational duties on covered payers. Together they aim to make determinations faster and more transparent, and to give the field data on how often prior authorization is used and upheld.

• Faster decisions — shorter maximum timeframes for standard and expedited requests than some earlier standards required of the affected programs.
• Specific denial reasons — when a request is denied, the payer must communicate a specific reason, which supports a cleaner resubmission or appeal.
• Public reporting — covered payers must post certain aggregated prior authorization metrics, such as approval and denial figures, on their websites.

For revenue cycle teams working with affected plans, the rule is expected to shift more of the process onto electronic rails. As covered payers stand up their interfaces, a provider's system may be able to learn whether a service needs authorization and what documentation is required without a portal login or fax, and to receive decisions and a distinct authorization number through the same channel. Faster maximum decision windows and specific denial reasons can also compress the time spent chasing status and interpreting vague rejections, which supports tighter tracking of authorization status and deadlines.

The rule does not eliminate the underlying work, however. Teams still confirm whether a service requires review, assemble clinical documentation, and follow the payer's authorization workflow to a decision. Payers not covered by the rule may continue with existing processes, so front-end steps and per-payer verification remain essential regardless of how far electronic exchange advances. In short, the rule reshapes the mechanics and the timelines of prior authorization for a defined set of plans — it does not remove the clinical judgment, the documentation, or the need to match what was approved to what is ultimately billed.