CMS-0057-F is a deadline, not a project
Prior authorization is the most hated workflow in healthcare — and by January 1, 2027 impacted payers must run it over a FHIR PARDD API. The Prior-Auth Agent automates the whole loop: check requirements, gather documentation, submit, and handle the decision, bridging X12 278 ↔ FHIR so nothing in your stack breaks.
- CMS-0057-F PARDD API + Da Vinci PAS / CRD / DTR
- X12 278 ↔ FHIR R4, bidirectional
- Auto-assembled documentation, tracked decision clocks
The PARDD loop
- 1CRD
Is prior auth required?
- 2DTR
Gather the documentation
- 3PAS
Submit over PARDD
- 4Decision
Approve · pend · deny + reason
In short
Four steps, fully automated
The Da Vinci prior-authorization loop — CRD → DTR → PAS → decision — run end to end by the agent, with a human confirming only what the payer rules genuinely require.
- 1
1 · Is PA required? (CRD)
At the point of order, Da Vinci Coverage Requirements Discovery queries the payer and returns whether prior authorization is required — and the rules behind the answer — before the clinician moves on.
- 2
2 · Gather documentation (DTR)
Documentation Templates & Rules pulls the payer's questionnaire, auto-answers it from the EHR/FHIR record (CQL), and flags only the gaps a human must fill — no re-keying.
- 3
3 · Submit (PAS)
The Prior Authorization Support transaction submits the request over the PARDD API, bridging X12 278 ↔ FHIR so both the payer's EDI stack and modern FHIR clients stay in sync.
- 4
4 · Decision & follow-up
Approvals, pended status and denials return with structured reasons. The agent tracks the CMS decision clock, parses denial reasons, and drafts the appeal or resubmission automatically.
What the Prior-Auth Agent handles
Everything from coverage discovery to appeal drafting — on standards, with a full audit trail.
CMS-0057-F PARDD API
Native support for the Prior Authorization API (PARDD) that impacted payers must operate under the CMS Interoperability and Prior Authorization final rule.
Da Vinci PAS / CRD / DTR
The full FHIR prior-auth stack — Coverage Requirements Discovery, Documentation Templates & Rules, and Prior Authorization Support — wired together end to end.
X12 278 ↔ FHIR bridging
Translate bidirectionally between the legacy X12 278 request/response and FHIR R4, so payers can modernize without abandoning their EDI backbone.
Automated documentation assembly
Auto-answer DTR questionnaires from the clinical record with CQL, attach supporting documents, and surface only the fields a human actually needs to complete.
Decision-clock tracking
Monitor the CMS-mandated timeframes — 72 hours for expedited requests, 7 calendar days for standard — and alert before a payer misses them.
Denial handling & appeals
Parse structured denial reasons, explain them in plain English, and draft the appeal or corrected resubmission automatically.
The 2027 clock is already running
CMS-0057-F requires four FHIR APIs — Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization (PARDD) — with operational provisions in 2026 and the APIs due January 1, 2027. Yet roughly 43% of payers and 47% of providers had not started as of October 2025. Read the full breakdown of what the rule requires and how to sequence it.
Security & Compliance
Enterprise-grade trust, stated honestly
Protecting PHI is non-negotiable. Here's exactly where our certifications stand — no overclaiming.
Compliant · BAAs available
Audit in progress
On roadmap
Native, by design
AWS HIPAA-eligible infrastructure · Business Associate Agreements (BAAs) · Encryption in transit & at rest · See our security details →
Frequently asked questions
Ready for the CMS-0057-F prior-auth deadline?
See the PARDD loop run on a real prior-authorization scenario, with X12 278 ↔ FHIR bridging on your own transactions.