healthcare AI platforms
CMS-0057-F.
A field guide for payer IT.
Most CMS-0057-F coverage explains the rule's intent. This is a field guide for the engineering team that has to build to it. What the four required FHIR APIs actually do, what the Da Vinci PA bundle (CRD, DTR, PAS) actually requires you to ship, what the public reporting deadline that already passed implies for your team, and where the implementation realities diverge from the regulation's plain text.
CMS-0057-F is more specific than the headlines.
The CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) requires impacted payers to implement four FHIR APIs by January 1, 2027 — Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization. The PA API is the new and substantial one; it relies on the Da Vinci PA bundle (CRD, DTR, PAS). Public reporting on PA performance metrics began March 31, 2026 — that deadline has already passed, and the metrics are now public for impacted payers.
Impacted payers: Medicare Advantage organizations, Medicaid managed care plans, CHIP managed care entities, and Qualified Health Plan issuers on Federally-Facilitated Exchanges. Traditional Medicare Fee-for-Service is not directly impacted by the rule.
What the rule actually requires you to ship.
CMS-0057-F mandates four FHIR-based APIs. Each has a distinct purpose, distinct data, and distinct technical lift. The Prior Authorization API is the one that gets the headlines, but the Provider Access and Payer-to-Payer APIs require comparable engineering investment.
| API | What it does | Implementation Guide |
|---|---|---|
| Patient Access API | Lets members access their claims, encounter, and clinical data. Now extended to include PA decisions and supporting documentation. | Da Vinci PDex |
| Provider Access API | Lets in-network providers access patient claims, encounter, and clinical data — and now PA decisions for their patients. | Da Vinci PDex |
| Payer-to-Payer API | Lets a member's new payer pull historical claims and clinical data from prior payers — including PA decisions. | Da Vinci PDex |
| Prior Authorization API | Electronic submission, status tracking, and determination of prior authorization requests over FHIR. | Da Vinci PA bundle: CRD + DTR + PAS |
CRD, DTR, PAS — what each one actually does.
The PA API is not a single FHIR resource — it is a workflow built from three sequential Implementation Guides. Each IG handles a distinct moment in the authorization workflow.
Coverage Requirements Discovery
The provider's EHR queries the payer to discover whether prior authorization is required for a specific service for a specific patient — before the order is placed. Returns a CDS Hooks card. Reduces unnecessary submissions and surfaces requirements upstream where they can be addressed.
Documentation Templates and Rules
Once PA is required, DTR retrieves the payer-specific documentation template (the questionnaire) for the service in question. The template can be auto-filled from the EHR's clinical data; the gaps are flagged for the provider to complete.
Prior Authorization Support
The actual PA submission. PAS exchanges X12 278 transactions over FHIR — the EHR submits, the payer responds with a determination (or pending status). PAS is the conformance surface the rule mandates; CRD and DTR are the upstream pieces that make PAS efficient.
The dates that matter.
CMS-0057-F's compliance dates are spread across multiple years. Some have already passed. The big one is January 1, 2027 — the FHIR API mandate for Provider Access, Payer-to-Payer, and Prior Authorization.
| Date | Requirement |
|---|---|
| January 2024 | PA decision time-frame requirements (72 hours expedited / 7 calendar days standard for urgent care) take effect. |
| January 2026 | Reasons for denial must be communicated to providers; PA performance metrics tracking begins. |
| March 31, 2026 | Already passed. First public reporting cycle on PA performance metrics: volume, approval rate, denial rate, average decision time, FHIR-API utilization. |
| January 1, 2027 | The big one. Provider Access API, Payer-to-Payer API, and Prior Authorization API (CRD + DTR + PAS) must all be live. |
Where the regulation diverges from the engineering reality.
A few things the regulation does not say explicitly that have surfaced in the first year of compliance.
Provider EHR adoption is the bottleneck.
The PA API only delivers value when providers actually use it from their EHR. Major EHR vendors (Epic, Cerner/Oracle, Athena, Allscripts/Veradigm) are all shipping CRD/DTR/PAS support — but rollout is uneven across customer instances. The implementation challenge is not getting your payer-side FHIR endpoint live; it is getting providers to actually call it.
Public reporting is going to embarrass laggards.
The March 2026 public reporting cycle made denial rates, average decision times, and FHIR-API utilization comparable across impacted payers. Plans whose PA performance is significantly worse than peer averages have started receiving scrutiny — from regulators, from large purchasers, and from the trade press. The reporting data has effectively become a public scorecard.
X12 278 is not going away.
PAS transmits X12 278 transactions over FHIR. The X12 278 transaction itself remains the substantive content of the request. Engineering teams that are weak on X12 278 are not going to be saved by FHIR — they have to get the underlying transaction right first.
The auto-deny line still applies.
CMS-0057-F is silent on whether a PA determination can be issued by an AI agent without human review. But the rule's denial-rationale requirement — payers must communicate the specific reason for any denial to the provider — is operationally incompatible with auto-deny. See The Auto-Deny Problem for the full argument.
FAQ.
What does CMS-0057-F require?
CMS-0057-F (the CMS Interoperability and Prior Authorization Final Rule) requires impacted payers to implement four FHIR APIs: Patient Access API, Provider Access API, Payer-to-Payer API, and Prior Authorization API. The PA API uses the Da Vinci PA bundle: CRD (Coverage Requirements Discovery), DTR (Documentation Templates and Rules), and PAS (Prior Authorization Support).
When does CMS-0057-F take effect?
The FHIR API mandate takes effect January 1, 2027. Public reporting of PA performance metrics began March 31, 2026 — that deadline has already passed. Some elements (like the Patient Access API) had earlier deadlines that have already kicked in.
Who is impacted by CMS-0057-F?
Medicare Advantage organizations, Medicaid managed care plans, CHIP managed care entities, and Qualified Health Plan issuers on Federally-Facilitated Exchanges. Traditional Medicare Fee-for-Service is not directly impacted by the rule — but is implicitly aligned through programs like the WISeR Model.
What is the Da Vinci PA bundle?
A set of HL7 FHIR Implementation Guides — CRD, DTR, and PAS — that together specify how electronic prior authorization works over FHIR. CRD discovers what coverage rules apply; DTR retrieves the required documentation templates; PAS submits the actual prior authorization request and receives the determination.
What public reporting is required?
Impacted payers must publicly post annual metrics on PA volume, approval rates, denial rates, average decision time, and the proportion of PA requests submitted via the FHIR API. The first reporting cycle began March 31, 2026.
Continue the cluster.
How PA Automation Actually Works
The seven steps of a PA workflow. Where automation works, where it does not, and the architectural pattern.
Read the note Note · PositionThe Auto-Deny Problem
Why every clinical non-affirmation routes through a human reviewer. Legal, regulatory, clinical, architectural.
Read the note Note · EngineeringPA Agent Architecture
The reference architecture for a domain-decomposed PA agent system. Agents, state, audit packets.
Read the note AudienceFor Payers
The buyer-side view for impacted payers. How HIP One supports the full Da Vinci PA bundle production-ready.
Read the payer view ProductHIP One
The platform with production CRD, DTR, and PAS support. Live in CMS Medicare today.
Explore HIP One Field guidePrior Authorization Automation
The buyer-side overview. Architecture, regulatory mandates, comparison table, ten-question FAQ.
Read the field guideA CMS-0057-F readiness conversation.
A 30-45 minute conversation with the team running production CRD/DTR/PAS in CMS Medicare. We bring the engineering checklist; you bring the gaps.