CMS says prior-auth APIs do not require real-time decisions

An API is a governed exchange, not an instant adjudicator

CMS's updated FAQ directly addresses a common implementation shortcut: the CMS Interoperability and Prior Authorization Final Rule does not require impacted payers to make prior-authorization decisions in real time through the API. CMS explains that a prior-authorization request may still need evaluation by a clinical reviewer. The API can improve discovery, submission, status, and response exchange without collapsing clinical policy and accountable review into an automated transaction.

That distinction should shape product claims. A system may return an immediate acknowledgement, validate required fields, identify a missing attachment, or route a request to the correct queue. None of those events is the coverage decision. Buyers should require separate timestamps and statuses for receipt, validation, additional-information requests, clinical review, determination, communication, and any subsequent appeal. A single 'completed' status can hide the very delay the workflow is meant to expose.

The response needs decision context

CMS describes API responses that communicate whether a request was approved, denied, or requires more information. Approval information should include relevant duration or circumstance; a denial should include a specific reason; and a request for more information should identify what is needed. These response states are operational data, not merely messages. Provider teams need to connect them to the submitted request, supporting evidence, payer policy, responsible reviewer, and next action.

A credible demonstration should use all three outcomes. For an approval, the system should preserve the covered scope and any expiration. For a denial, it should retain the specific reason and the policy or evidence context available to the recipient. For an incomplete request, it should show the missing information, the clock state, and the party expected to respond. Buyers should also test a corrected resubmission so the history does not disappear behind the latest payload.

Timing controls remain visible

The final rule includes decision time frames for impacted payers other than qualified health plan issuers on federally facilitated exchanges: 72 hours for expedited requests and seven calendar days for standard requests. Technology cannot establish that every case meets those time frames, but it can make receipt, classification, pause conditions, determination, and communication auditable. Teams should verify how the system handles weekends, incomplete submissions, corrected data, and a changed urgency classification.

The API provisions generally begin January 1, 2027, while specified operational provisions took effect in 2026. A readiness plan therefore needs more than an endpoint delivery date. Payers and providers need data definitions, workflow ownership, clinical-review capacity, response content, exception handling, metrics, and testing across organizational boundaries. The FAQ also confirms that the CMS-0057-F prior-authorization policies exclude drugs of any type, so product scope should not silently blend medical-service and pharmacy workflows.

What buyers should ask to see

The strongest evaluation follows one request from requirement discovery through a final response. Buyers can ask which implementation guide and version is supported, how payer rules are represented, what validates attachments, how status changes are generated, where clinical reviewers work, and how denial reasons reach the requesting team. The test should include an unavailable service, a duplicate request, an incomplete response, and a human override, with evidence preserved at each transition.

The CMS FAQ clarifies federal implementation expectations; it does not certify an API, determine medical necessity, or prove interoperability in a buyer's environment. Vendor documentation can establish a documented interface or workflow. Conformance testing, observed transactions, and operating metrics provide different and stronger forms of evidence. Prior Auth Monitor keeps those claims separate so an available API is not mistaken for an automated clinical decision or a measured improvement in access.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Prior Auth Monitor will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.