Prior Authorization After the CMS Interoperability Rule: What Payers Actually Shipped

The Centers for Medicare and Medicaid Services finalized the Interoperability and Prior Authorization rule in January 2024, with compliance dates staggered through 2026 and 2027. Enough of those dates have now passed, and enough affected plans have shipped, that the conversation inside health systems has moved from what the rule requires to what it has actually changed in the operating flow. The picture is more granular than either the initial payer press releases or the provider trade association reaction suggested.

The headline requirements are known: impacted payers, which include Medicare Advantage organizations, Medicaid managed care plans, CHIP managed care entities, and Qualified Health Plan issuers on the Federally-facilitated Exchanges, must implement a Prior Authorization API using the HL7 FHIR standard, must decide urgent requests within 72 hours and standard requests within seven calendar days, and must publish specific denial and turnaround metrics. The less obvious operating truth is that the API standard and the decision-timeline standard are two different implementation problems, and the payers that have shipped one have not necessarily shipped the other.

On the API side, the specific plans that have gone furthest have generally done so by treating the FHIR endpoint as a wrapper around an existing utilization-management system rather than as an opportunity to rebuild that system. The result is technically compliant and, in the majority of cases, provides real interoperability with the electronic health record systems most large health systems run. It also, in most cases, has not changed the substantive decision logic underneath. A prior-authorization request that a payer would previously have delayed or denied is being delayed or denied through a faster, more machine-readable interface.

On the timeline side, the seven-day and 72-hour requirements have produced the operational change that health-system revenue-cycle leaders actually notice. Denial patterns are shifting toward more specific, more clinically grounded denials, because the payer no longer has the option of running out the clock on an underspecified request. That is, in the aggregate, a real improvement for provider cash conversion. It is also producing a workload shift inside utilization-management teams on the payer side that is not fully absorbed, and a corresponding workload shift on the provider side toward more upfront clinical documentation.

The pattern that has emerged in the specific health systems handling this well is a re-centralization of prior-authorization operations that had been distributed across service lines during the last decade. Systems that had a prior-authorization coordinator embedded in each department are consolidating into a central utilization-management function that owns the API integration, the appeals workflow, and the payer-scorecard analytics. The reason is that the API and the timeline requirements together create enough new signal that the central function pays for itself in denial-rate reduction within the first year.

For a health-system CFO, the working question is whether the current revenue-cycle plan distinguishes between the cash-flow improvement from faster decisions, which is durable and pricable, and the assumption of lower denial rates, which is not automatic and depends on the health system actually rebuilding its own upstream documentation workflow to meet the payer at the higher standard the API now enables. Systems that model the second as automatic are, in our experience, disappointed at the first-year read.

For a payer CFO, the parallel question is whether the API investment has been paired with genuine rebuild of the utilization-management logic underneath, or whether the plan is running a compliant interface against a decision engine that will lose the next round of state-level and CMS scrutiny on the substantive fairness of denials. The regulatory posture on both is tightening, and the plans that have treated the API as the finish line are the ones most exposed.