The CMS Prior Authorization API: FHIR, Da Vinci CRD, DTR, PAS, and X12 278

What the Prior Authorization API does

The Prior Authorization API, called the PARDD API in the proposed rule, is the core of CMS-0057-F’s technology requirements. An impacted payer must populate it with its list of covered items and services, and it must (CMS FAQ):

• Show whether an item or service requires prior authorization
• Identify the documentation the payer requires for it
• Support sending a prior authorization request and receiving the payer’s response
• Return a decision that approves the request with the date or circumstance when the authorization ends, denies it with a specific reason, or asks for more information

It does not cover drugs. It is due January 1, 2027 for Medicare Advantage organizations and Medicaid and CHIP fee-for-service programs, and by the rating period or plan year beginning on or after that date for Medicaid managed care plans and QHP issuers on the federal exchanges. See compliance deadlines.

Required standards and recommended implementation guides

CMS lists the required standards and strongly encourages payers to use the recommended Da Vinci guides (CMS fact sheet; CMS implementation guides).

FHIR and the X12 278

HIPAA names the X12 278 as the standard transaction for prior authorization. In February 2024, HHS announced it will not take HIPAA enforcement action against covered entities that use an all-FHIR prior authorization API instead of the X12 278. No end date was given (CMS; CMS FAQ). See the X12 278 guide for how the 278 works today.

Alongside CMS-0062-P in 2026, HHS proposed adopting FHIR-based standards, including US Core, SMART, CRD, DTR, and PAS, as the HIPAA standard for prior authorization in place of the X12 278, with compliance 24 months after a final rule takes effect. The proposal was not final as of November 4, 2026 (CMS; Federal Register).

The other three APIs

• Provider Access API: lets in-network providers with a treatment relationship retrieve a patient’s claims, clinical data, and prior authorization information. Patients can opt out (CMS fact sheet).
• Payer-to-Payer API: moves a patient’s claims, clinical, and non-drug prior authorization data to a new payer when the patient opts in, for dates of service within five years of the request (CMS fact sheet).
• Patient Access API (expanded): adds non-drug prior authorization information to the data patients can access through apps (CMS fact sheet).

Proposed: version 2.2 and drugs (CMS-0062-P)

CMS’s April 2026 proposed rule would require version 2.2 of the CRD, DTR, and PAS implementation guides and extend the Prior Authorization API to drugs covered under the medical benefit, with NCPDP standards for pharmacy-benefit drugs. Most proposed compliance dates are October 1, 2027. Comments closed June 15, 2026 (CMS).

Questions to ask your EHR and prior authorization vendors

• Will you connect to payers’ Prior Authorization APIs, and for which payers first?
• Do you support the Da Vinci CRD, DTR, and PAS implementation guides, and which versions?
• Will coverage requirements and documentation templates appear inside our ordering workflow, or in a separate tool?
• How will prior authorization decisions, end dates, and denial reasons be written back to the chart?
• Will you support attesting to the Electronic Prior Authorization measure for MIPS or the hospital Promoting Interoperability Program?
• What happens for payers that are not covered by CMS-0057-F or haven’t launched an API?

What it means for providers

Payers must offer these APIs, but providers only benefit when their EHR or prior authorization vendor connects to them. Until then, and for every payer not covered by the rule, prior authorizations still go through payer portals, fax, and phone.

Saga works through payer portals today, assembling documentation from the chart, submitting requests, and tracking each one to a decision inside your EHR. See prior authorization automation and how Saga compares with other approaches.