Understanding the Prior Authorization API: Requirements, deadlines, benefits and trends

Updated February 27, 2026

Prior authorization is a critical tool for managing healthcare costs and care in the United States. In reality, it still too often runs on fax, phone calls, and manual document chasing. That creates administrative burden for providers and high operational costs for payers. And let’s not forget frustrated members waiting for necessary care. 

The Prior Authorization API, mandated in the US Centers for Medicare & Medicaid Services (CMS) Interoperability and Prior Authorization Final Rule (CMS-0057-F), aims to transform this process by automating requests, documentation, and decisions, reducing inefficiencies and delays. By adopting this API, payers can ease their administrative burden, improve member satisfaction, and enhance operational efficiency. 

Let’s dive into what this API entails, exploring its requirements, benefits, and how it’s set to transform one of the most complex processes in healthcare. 

What is the Prior Authorization API?

The Prior Authorization API—also known as the Prior Authorization Requirements, Documentation, and Decision API (PARDD API)—is a FHIR-based solution that enables seamless communication between providers and payers by automating key aspects of the prior authorization process. It supports three core capabilities:

• Requirements discovery: determine whether a given item/service requires PA and what rules apply.
• Documentation guidance: communicate what clinical/administrative documentation is needed to make a decision.
• Structured decisions: return approvals, denials (with specific reasons), or requests for additional information—so the provider can act without guessing.

It allows providers to check if prior authorization is needed for specific services or items and access clear documentation guidelines for approvals. Providers can submit requests directly through their EHR systems, track their status in real-time, and receive transparent decisions, including reasons for denials or requests for additional information. 

Who does this impact?

The Prior Authorization API is a requirement for “impacted players” (CMS-regulated payers), which includes: 

• Medicare Advantage (MA) organizations
• Medicaid managed care plans
• Children’s Health Insurance Program (CHIP) state agencies and managed care entities
• Qualified Health Plan (QHP) issuers on Federally-Facilitated Exchanges (FFE)

What are the technical requirements?

CMS requires a FHIR API-based approach. In the market, the most common path is to align with the HL7 Da Vinci implementation guides that support ePA workflows (for example, PAS along with CRD and DTR, depending on the workflow design). At a practical level, your implementation needs to: 

• Expose a payer’s covered items/services and PA rules in a way that a provider system can query.
• Expose PA documentation requirements (what data the payer needs to make a decision).
• Support electronic submission and status tracking for PA requests.
• Return structured outcomes: approval (including validity end date/conditions), denial (with specific reason), or request for more information..   

CMS-0057-F excludes prior authorizations for drugs from the mandatory scope of the Prior Authorization API. That said, many organizations are choosing to extend the same approach to pharmacy benefits over time to simplify operations. 

Timeline: what starts in 2026 vs what’s due in 2027 

It’s easy to miss this: CMS-0057-F has prior authorization process requirements that start earlier than the API build deadline.

Starting in 2026: prior authorization process requirements

• Decision timeframes: impacted payers must meet required turnaround times (for example, expedited/urgent requests within 72 hours and standard requests within 7 calendar days).
• Public reporting: impacted payers must publicly report certain PA metrics to increase transparency

Starting in 2027: Prior Authorization API (PARDD) compliance

• Impacted payers must implement the Prior Authorization API beginning January 1, 2027 (with some program-specific variations such as plan year/rating period alignment).

Tip: even if your API work streams are aimed at 2027, you’ll want to align them with 2026 operational commitments—especially turnaround times, metrics, and the internal control environment needed to defend those numbers.

4 benefits of the Prior Authorization API for payers

1. Lower administrative costs: By automating the submission, review, and decision-making processes, the API reduces reliance on manual workflows such as faxing and phone calls. Improved accuracy minimizes errors and rework, leading to significant cost savings. 
2. Stronger provider relationships: Providers get clear, real-time updates on electronic prior authorization requirements and decisions right in their EHR systems, cutting down on frustration and back-and-forth. Meanwhile, clear feedback on denials or requests for more information leads to greater trust and collaboration. 
3. Happier members: Faster approvals mean members can get the care they need without lengthy delays. When payers make decisions quickly and consistently, it strengthens trust and helps members feel more confident in their health plan. 
4. Increased operational efficiency: By standardizing processes and integrating with existing systems, payers can streamline workflows and boost productivity. With better data management, it’s easier to handle more requests without scaling costs. 

3 industry trends for payers in 2026

1. Increasing use of automation and AI: Advancements in AI and machine learning are revolutionizing prior authorization by automatically validating clinical data against payer rules to identify whether an authorization is required, and assisting in decision-making for complex cases by analyzing large datasets.
2. Adoption of FHIR Standards: Payers are moving toward fully FHIR-based systems, reducing reliance on legacy X12 standards and ensuring compatibility with other CMS-mandated APIs, creating a cohesive data exchange ecosystem. 
3. Expansion beyond core requirements: While the API doesn’t require drug-related authorizations, payers are increasingly exploring its use for broader applications—like prescription drugs and other pharmacy benefits—to create a more comprehensive solution for their providers and members. 

Take the next step

The Prior Authorization API represents a critical step forward in reducing administrative burden, accelerating care, and enhancing collaboration between payers and providers. By implementing this FHIR-based solution, payers can achieve compliance while transforming prior authorization into a seamless, efficient process that benefits all stakeholders. 

At Firely, we specialize in helping payers navigate FHIR implementation and API development. From aligning with CMS regulations to leveraging the Prior Authorization API for strategic advantage, we’re here to help.

If you’re ready to take the next step in implementing the Prior Authorization API, Firely Server offers the tools and support you need to get started. For more detailed instructions, visit our CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) documentation, or reach out to our team to explore how Firely can support your journey to interoperability.