What the Prior Authorization API Does
The Prior Authorization API (originally proposed as the "PARDD API" — Prior Authorization Requirements, Documentation, and Decision API) enables three critical capabilities through a single standards-based interface:
- Determine if prior authorization is required — Providers query the payer to check whether a specific item or service requires PA for a given patient and plan
- Retrieve documentation requirements — The API returns what clinical documentation must be submitted, enabling automated compilation from the provider's EHR
- Submit PA requests and receive decisions — Requests flow electronically with structured data, and payers return decisions through the same channel
Prior Authorization Process Requirements
Separate from the API itself, CMS finalized process improvements that apply regardless of how a payer receives a PA request — whether through the API, fax, phone, or portal. These requirements take effect in 2026, one year before the API mandate:
Denial Reason Specificity
When denying a prior authorization request, impacted payers must provide a specific reason for the denial in the notice sent to providers. Generic denials are no longer acceptable under the rule. This requirement addresses one of the most persistent pain points cited by providers in the rulemaking comment process.
Public Metrics Reporting
All impacted payers must publicly report prior authorization metrics, creating unprecedented transparency. These metrics will include approval and denial rates, average response times, and other measures that allow stakeholders to compare payer performance. This reporting requirement takes effect in 2026.
Medicaid Notice & Fair Hearings
CMS finalized clarifications to existing Medicaid beneficiary notice and fair hearing regulations as they apply to prior authorization decisions. These are characterized as clarifications to existing requirements and took effect on the rule's effective date.
Scope: Items & Services Only
The Prior Authorization API and process requirements apply exclusively to items and services — not drugs. This means prescription drugs (whether self-administered, provider-administered, pharmacy-dispensed, or hospital-administered) are outside the scope of the PA provisions. Drug prior authorization involves different processes, standards, and regulatory frameworks that CMS chose not to address in this rule.
Recommended Implementation Guides
CMS strongly recommends the HL7 Da Vinci Implementation Guides as the technical foundation for the Prior Authorization API. These three IGs work together to cover the full PA workflow:
Coverage Requirements Discovery
Enables real-time queries from the EHR to the payer to determine if prior authorization is required for a given service, and what documentation rules apply — triggered during the clinical ordering workflow.
Documentation Templates & Rules
Provides FHIR Questionnaire resources that define the specific clinical data elements required for a PA request, enabling auto-population from the EHR and reducing manual documentation burden.
Prior Authorization Support
Handles the actual submission of PA requests and receipt of decisions through FHIR, replacing fax-based and portal-based workflows with structured electronic exchange.
For a step-by-step treatment of how these three implementation guides chain together and where the payer's responsibilities begin, see the dedicated guide: CRD, DTR and PAS explained.
The End-to-End Prior Authorization Workflow
CRD, DTR, and PAS are steps in one flow that starts in the provider's EHR and ends in the payer's authorization and core administration systems. The FHIR API is the boundary between the two worlds — it is not the decision engine.
Where X12 278 Fits
Prior authorization already has a long-standing HIPAA transaction — the X12 278 request and response. CMS-0057-F does not retire it. The Da Vinci PAS implementation guide is specifically designed to interoperate with X12 278: in many deployments the FHIR PAS request is transformed into a 278 for the payer's existing transaction infrastructure (or a clearinghouse), and the 278 response is mapped back into a FHIR ClaimResponse. This is why PAS is often described as a FHIR-to-X12 bridge. Expect X12 278 to remain part of the plumbing behind the FHIR boundary, especially where trading-partner agreements and clearinghouses are already built around it.
Payer Workflow Orchestration & Core Administration
When a PAS request arrives, the payer's interoperability layer must translate the FHIR Claim (use=preauthorization) into whatever the authorization workflow expects, invoke the utilization-management engine and medical-policy rules, and translate the outcome back into a FHIR ClaimResponse — including the specific denial reason the rule requires. In many payer environments the backend that records and adjudicates authorizations is an established core administration platform such as QNXT, Facets, or HealthEdge, or a custom system.
Compliance Dates
API Implementation (2027)
- MA organizations & state Medicaid/CHIP FFS programs: January 1, 2027
- Medicaid managed care plans & CHIP managed care entities: Rating period beginning on or after January 1, 2027
- QHP issuers on the FFEs: Plan years beginning on or after January 1, 2027
Process Requirements (2026)
- MA organizations & state Medicaid/CHIP FFS programs: January 1, 2026
- Managed care & CHIP managed care: Rating period beginning on or after January 1, 2026
- QHP issuers on the FFEs: Plan years beginning on or after January 1, 2026
Note: QHP issuers on the FFEs are required to implement the PA API and the public metrics reporting but are exempt from the mandated response timeframes (72-hour/7-day requirements).
Electronic Prior Authorization Measures (MIPS & Promoting Interoperability)
To drive provider-side adoption of the Prior Authorization API, CMS added new "Electronic Prior Authorization" measures under both the MIPS Promoting Interoperability performance category and the Medicare Promoting Interoperability Program. Starting with the CY 2027 performance period, eligible clinicians, hospitals, and CAHs must report a yes/no attestation (modified from the originally proposed numerator/denominator approach) regarding their use of the Prior Authorization API.