Prior Authorization API
The Prior Authorization API is a CMS-mandated FHIR-based interface that modernizes the prior authorization process. It replaces manual (phone, fax) and EDI-based (278) prior auth with standardized, real-time FHIR interactions.
The Problem with Current Prior Auth
The current prior authorization process is one of the most burdensome administrative tasks in healthcare:
| Issue | Impact |
|---|---|
| Manual processes (phone, fax, portal) | Delays care by days or weeks |
| Inconsistent requirements | Providers must learn each payer's unique rules |
| Opaque decision-making | Denials often lack specific, actionable reasons |
| No standardized reporting | Limited visibility into approval rates and turnaround times |
| Provider burden | Average of 13 hours/week spent on PA by physician practices |
CMS Requirements (CMS-0057-F)
FHIR-Based Submission
- Payers must accept prior auth requests via Da Vinci PAS (FHIR $submit operation)
- Supports the CRD/DTR/PAS workflow for integrated EHR experience
Response Time Mandates
| Request Type | Maximum Response Time |
|---|---|
| Urgent | 72 hours |
| Standard | 7 calendar days |
These are maximum times — payers are encouraged to respond faster, and many urgent requests should receive near-real-time responses.
Denial Reason Specificity
- Payers must provide specific, actionable reasons for denials
- Generic denial codes (e.g., "not medically necessary") are insufficient
- Reasons must help the provider understand what clinical criteria were not met
Decision Transparency
- PA decisions must be accessible through the Patient Access API (member-facing)
- Members can see: what was requested, the decision, and the reason
Public Metrics Reporting
Starting March 2026, payers must publicly report:
| Metric | Details |
|---|---|
| Approval rate | % of PA requests approved |
| Denial rate | % denied |
| Appeal overturn rate | % approved after appeal |
| Average decision time | By urgency level and service category |
| Volume | Total PA requests received |
Electronic PA for All Applicable Services
- If a payer requires PA for a service, they must support electronic PA for that service
- Applies to all items and services, not just a subset
Technical Implementation
Da Vinci PAS Workflow
- Provider's EHR constructs a FHIR Claim resource (use = "preauthorization") with supporting clinical data
- Bundle is submitted via $submit to the payer's PAS endpoint
- Payer processes and returns a ClaimResponse with the decision
- If pended, the payer may request additional documentation via DTR questionnaires
- Provider can query the status of pended requests
Supporting IGs
- Da Vinci CRD — Real-time coverage requirements check at point of care
- Da Vinci DTR — Automated clinical data collection using SMART on FHIR questionnaires
- Da Vinci PAS — The submission and response mechanism
Compliance Timeline
| Milestone | Date |
|---|---|
| PA reason specificity requirement | January 1, 2026 |
| PA metrics public reporting | March 2026 |
| FHIR-based PA API (full) | January 1, 2027 |
