What is Prior Authorization API? (Da Vinci PAS Edition)

Here’s a number that should keep every healthcare engineer up at night. 40. That’s how many prior authorization requests the average physician processes every single week, according to the AMA Prior Authorization Physician Survey. Their staff spends 13 hours managing those requests. And 95% of those physicians say prior auth directly contributes to their burnout.

Nearly one in four (26%) say the process has already caused a serious adverse event for a patient in their care, including hospitalization, permanent impairment, or death.

And the industry’s backbone for all of this? Fax machines. Phone calls. Payer-specific portals. Manual X12 278 transactions. It’s 2026. This is a system failure with a body count.

The good news: there’s a FHIR-native, federally mandated, standards-backed solution. It’s called the Prior Authorization API, built on the HL7 Da Vinci Prior Authorization Support (PAS) Implementation Guide, and under CMS-0057-F, it is no longer optional.

This is your complete technical guide to understanding it.

What Is a Prior Authorization API?

A Prior Authorization API is a standardized programmatic interface that allows healthcare providers, through their EHR systems, to electronically submit, check the status of, update, and cancel prior authorization requests directly with payers. In real time.

No fax. No portal re-keying. No phone tree.

Think of it as replacing a broken, manual, multi-day process with a structured, machine-readable, synchronous or asynchronous FHIR exchange.

Under CMS-0057-F (the Interoperability and Prior Authorization Final Rule, finalized January 17, 2024), implementing this API is now a federal compliance requirement for:

• Medicare Advantage organizations
• Medicaid managed care plans
• CHIP managed care entities
• Qualified Health Plan issuers on the Federally Facilitated Exchange
• State Medicaid and CHIP fee-for-service programs

The operational deadlines have already hit. Impacted payers were required to accelerate decision timeframes, 72 hours for expedited requests and 7 calendar days for standard requests, as of January 1, 2026. Full FHIR API implementation is mandated by January 1, 2027.

Translation? If your organization is affected by CMS-0057-F and you haven’t started building toward API compliance yet, you’re behind.

What Is the Da Vinci PAS Implementation Guide?

Here’s where the technical substance lives.

The Da Vinci Prior Authorization Support FHIR Implementation Guide is the HL7-published standard that defines exactly how the Prior Authorization API must be built.

Current production version: PAS IG v2.1.0 (STU 2.1), officially published at the HL7 Website. ONC has proposed adopting v2.2.1 (STU 2.2) as part of the CMS Interoperability and Prior Authorization for Drugs Proposed Rule.

Da Vinci itself is an HL7 International initiative, co-sponsored by major U.S. health plans, provider organizations, and EHR vendors, all working to advance FHIR-based data exchange for value-based care. PAS is one of the flagship outcomes of that collaboration.

The PAS IG is not a standalone specification. It’s one leg of a three-IG workflow tripod.

The Da Vinci Burden Reduction Stack: CRD → DTR → PAS

This is the most important architectural concept to understand before touching a single line of PAS code.

Da Vinci PAS was designed to work as the submission layer of a coordinated three-step prior authorization workflow. Each IG hands off to the next.

Here’s how this looks end-to-end in a clinical workflow:

This integrated workflow, when fully implemented, virtually eliminates the manual back-and-forth that causes those 13-hour-per-week administrative marathons.

But here’s what most implementations miss:

You don’t have to implement all three IGs at once. The PAS IG can be implemented independently. CRD and DTR can be added later. But the greatest reduction in manual effort and the strongest path to CMS-0057-F compliance comes from implementing all three together.

PAS Technical Architecture: What You’re Actually Building

The Core Operation: Claim/$submit

The backbone of PAS is the Claim/$submit FHIR operation.

HTTP method: POST Endpoint: [base-url]/Claim/$submit Input: A FHIR Bundle (type: collection) containing:

Output: A FHIR Bundle containing:

Or, on error: an Operation Outcome.

The Three Response States

Understanding the three possible Claim Response states is critical for your EHR integration logic:

Additional Operations

PAS defines two more key operations beyond $submit:

Claim/$inquire — Query the status of a previously submitted PA request

Claim/$cancel — Cancel a submitted PA request

These operations are essential for building a complete PA lifecycle management system, not just a fire-and-forget submission endpoint.

The X12 278 Bridge: How Regulatory Reality Shapes the Architecture

Here’s where it gets architecturally nuanced.

HIPAA’s Administrative Simplification provisions mandate that the X12 278 transaction be used for prior authorization request and response communications between covered entities. Most payer backend systems still speak X12, not FHIR.

So how does PAS work with payers that only understand X12?

Answer: Through an intermediary.

The PAS IG defines a translation layer where:

1. The EHR (PAS client) sends a FHIR Bundle to the intermediary
2. The intermediary converts FHIR → X12 278 and forwards it to the payer
3. The payer responds with X12 278
4. The intermediary converts X12 → FHIR Claim Response and returns to EHR

Important compliance note: CMS’s Office of Burden Reduction and Health Informatics (OBRHI) has announced an enforcement discretion that it will not enforce the X12 278 requirement if covered entities are using the FHIR-based Prior Authorization API as described in CMS-0057-F. This means organizations implementing full FHIR PAS exchanges can operate without X12 translation during this transition period.

Bottom line: you can build a pure FHIR PAS implementation today. X12 interoperability remains important for payers that haven’t yet migrated their backend systems, but it’s not a blocker for moving forward with FHIR.

What the PAS IG Actually Requires: Key Conformance Rules

The PAS IG distinguishes clearly between what systems SHALL and SHOULD do. Here are the most important:

For PAS Clients (EHR Systems):

• SHALL support the Claim/$submit operation
• SHALL support US Core R4 profiles for Condition, Observation, and Procedure
• SHALL support all PAS-specific profiles (PAS Claim, PAS ClaimResponse, etc.)
• SHOULD support Da Vinci CRD for identifying when PA is required
• SHOULD support $inquire and $cancel operations
• SHOULD allow clinicians to review and update PA details before submission

For PAS Servers (Payer Systems / Intermediaries):

• SHALL support the Claim/$submit operation
• SHALL return synchronous responses (approved/denied) or pended status immediately
• SHALL support $inquire for pended requests
• SHALL provide specific denial reasons per CMS-0057-F (effective January 1, 2026)
• SHOULD implement FHIR Subscriptions to notify clients of updates to pended requests

Profile Dependencies:

PAS is built on a dependency chain you need to manage:

Supporting multiple US Core versions simultaneously is intentional: the IG is designed to ease implementers through evolving USCDI regulatory requirements without forcing a complete rebuild.

Real Implementation Challenges (And How to Address Them)

The PAS IG is well-specified. But real-world implementation surfaces challenges that the IG doesn’t fully prepare you for.

Here’s what engineering teams actually encounter:

Challenge 1: X12-to-FHIR Mapping Complexity

The PAS IG references X12 278 field mappings but cannot publish them directly due to X12 intellectual property restrictions.

You must obtain X12 membership and access the PAS Implementation Guide separately to get the specific field mappings. Implementers regularly cite this as a source of friction and delay.

How to address it: Use an established intermediary partner (like Availity, or a platform like Smile CDR or Aidbox/Smartbox) that has already built the X12/FHIR translation layer and manages X12 licensing requirements. Don’t try to build a raw X12 conversion yourself unless it’s a core competency.

Challenge 2: Pended Request Handling Complexity

When a payer returns a pended status, the workflow becomes asynchronous. Your system must either:

• Poll via $inquire on a defined schedule, or
• Implement FHIR Subscriptions to receive push notifications when the pended request is resolved

The PAS Test Kit from ONC specifically notes that Subscription-based pended request handling is one of the areas not yet fully covered in the current test suite, meaning your implementation won’t have automated test coverage for this path.

How to address it: Build a Subscription-first implementation (R5 Backport pattern), with polling as a fallback. Define clear retry logic and timeout behavior in your system design before you write a line of code.

Challenge 3: Multi-Service Prior Authorization Bundles

A single PA request may cover multiple services (e.g., a surgical procedure plus associated anesthesia).

The PAS Claim resource uses item arrays to represent line-item requests, and the ClaimResponse returns per-item decisions.

The challenge: payers may partially approve a bundle, approving some items, denying others. Your EHR integration needs to handle partial approval states and surface per-item status to the clinician clearly.

How to address it: Map ClaimResponse item.reviewAction to your EHR’s order management system at the order-line level, not just at the encounter level.

Challenge 4: CMS-0057-F Denial Reason Requirements

As of January 1, 2026, CMS-0057-F requires payers to provide specific denial reasons for all adverse PA decisions. This is a payer obligation, but EHR systems need to surface these reasons intelligibly to clinical staff.

The PAS ClaimResponse carries denial reasons via reviewAction.reasonCode and optionally reviewAction.reasonReference. These codes are not always human-readable without a terminology lookup.

How to address it: Implement terminology service lookups against the relevant code systems (X12 AAA, LOINC) and surface denial reasons in plain language in your clinical UX.

Testing Your PAS Implementation

ONC has published the Da Vinci PAS Test Kit, available through the Inferno Framework at inferno.healthit.gov.

The test kit validates:

• FHIR operations ($submit, $inquire) support
• Required PAS profile conformance
• Correct response structure for all ClaimResponse outcome states
• CapabilityStatement declarations

Known current limitations of the test kit:

• X12-specific value set expansions are not tested (IP restriction)
• Subscription-based pended notification flows are not fully covered
• Client-side clinician review workflows require manual validation

Use the test kit as your first validation gate, but treat it as a floor, not a ceiling.

For end-to-end workflow testing, the HL7 FHIR Connectathon (held multiple times annually) is the standard venue where PAS implementers test against live payer and intermediary systems in a structured environment.

CMS-0057-F Compliance Timeline: Where You Need to Be

Who is affected by the January 1, 2027, API deadline:

• Medicare Advantage organizations
• Medicaid managed care plans
• CHIP managed care entities
• QHP issuers on the FFE
• State Medicaid and CHIP FFS programs (some with extended deadlines, verify with CMS)

Why the Da Vinci PAS Ecosystem Matters

The Prior Authorization API isn’t just a compliance checkbox.

It’s the first real shot at fixing a system that, by the AMA’s count:

• Causes 95% of physicians to experience burnout
• Leads 79% of patients to abandon needed treatment
• Generates serious adverse events (hospitalization, permanent harm) in 26% of practices

When fully implemented, CRD identifying requirements at the point of care, DTR collecting the right documentation automatically, and PAS submitting and returning decisions in real time, the 13 hours of manual weekly PA work collapse dramatically.

That’s the architectural vision.

And with the January 1, 2027, deadline now within active development cycles for most health plan and EHR engineering teams, the implementation window is measured in months, not years.

What to Do Right Now

If you’re a FHIR developer or solutions architect building toward PAS compliance, here’s your starting point:

• Step 1: Read the PAS IG v2.1.0 start-to-finish, specifically the Use Cases and Formal Specification sections.
• Step 2: Download and run the ONC Da Vinci PAS Test Kit against your current FHIR server to establish your conformance baseline.
• Step 3: Evaluate whether you need a FHIR-to-X12 intermediary partner or whether your payer endpoints already support native FHIR. This single decision shapes your entire integration architecture.
• Step 4: Map your implementation plan against the three-IG workflow (CRD → DTR → PAS). Even if you’re starting with PAS only, understand where CRD and DTR will plug in later.
• Step 5: Join the Da Vinci PAS discussion forum at chat.fhir.org (#Da-Vinci-PAS stream) and participate in the next HL7 FHIR Connectathon. Real interoperability happens there.

Bottom Line

Prior authorization has been broken for decades.

The Da Vinci PAS Implementation Guide, backed by CMS-0057-F enforcement and the full weight of HL7, ONC, and CMS, is the most credible technical path toward fixing it.

The Claim/$submit operation is simple to describe. 

The orchestration around it, CRD, DTR, X12 bridging, Subscription handling, and denial reason surfacing, is where the real engineering work lives.

But the mandate is clear. The standard is published. The test tools are available.

The only question left is execution.

CapMinds: Your End-to-End CMS-0057-F Compliance Service Partner

Navigating CMS-0057-F alone is complex, costly, and time-sensitive. 

CapMinds delivers the complete digital health technology services your health plan needs to meet every deadline, from operational remediation to full FHIR API production readiness.

Our compliance-focused services include:

• FHIR R4 API Development Service: Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization APIs built to production-ready standards
• Prior Authorization Workflow Modernization Service: Electronic PA submission, denial notice redesign, and 72-hour/7-day decision routing
• USCDI v3 Data Migration Service: Seamless upgrade from legacy v1 content standards with full data integrity validation
• Da Vinci IG Implementation Service: CRD, DTR, PAS, and PDex implementation guide build-out for forward compliance
• Consent & Attribution Management Service: Opt-in/opt-out workflows, provider attribution logic, and auditable consent recordkeeping
• CMS Public Reporting & Metrics Service: PA performance dashboards, annual reporting infrastructure, and CMS submission support
• And More: EHR integration, ONC Inferno testing, provider enablement, and interoperability consulting

Don’t let compliance gaps become regulatory risk. Partner with CapMinds to modernize your health plan infrastructure with confidence, on time, every time.

Book a 1:1 Consultation Call with our Expert Team