CMS Prior Authorization API Rule

The CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F, published January 2024) requires Medicare Advantage organizations, state Medicaid and CHIP fee-for-service programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers in FFEs to implement FHIR R4-based APIs for prior authorization by January 1, 2026. Required APIs include: a Provider Access API (enabling providers to access their patients' data with patient consent); a Payer-to-Payer API (enabling data exchange when patients switch plans); and a Prior Authorization API (implementing the HL7 Da Vinci Prior Authorization Support (PAS) implementation guide and Coverage Requirements Discovery (CRD) API). The rule also requires payers to include prior authorization decisions in Claims and Encounter data, and mandates that payers report prior authorization metrics publicly — approval rates, denial rates, and average decision timeframes — beginning in 2026.

The engineering complexity of the CMS-0057-F rule is substantial. The Prior Authorization Support (PAS) API requires payers to implement a FHIR Claim resource-based prior authorization exchange using the Da Vinci PAS IG, which involves X12 278 transaction translation — the existing EDI standard for prior authorization — into FHIR representations. Most payer utilization management systems are built around X12 278/278i workflows and rules engines (InterQual, MCG) that do not natively expose FHIR interfaces, requiring middleware translation layers. The Coverage Requirements Discovery (CRD) API uses CDS Hooks, a FHIR-based clinical decision support standard, to push prior authorization requirements to providers at the point of care within EHR workflows — requiring CDS Hooks server implementation that calls into payer UM rules engines in real time, with sub-second response time requirements. The Da Vinci Documentation Templates and Rules (DTR) API completes the workflow by enabling electronic collection of clinical documentation within the EHR context.

The rule's payer-to-payer data exchange requirement creates a new category of engineering obligation: when a patient transitions between plans, the new plan must request and the old plan must respond to FHIR bulk data requests covering five years of claims, encounters, and prior authorization history within one business day of patient request. This requires both outbound FHIR Bulk Data server capability and inbound bulk data ingestion pipelines — at scale, as every member transition triggers an exchange. The Provider Access API intersects with the existing ONC § 170.315(g)(10) patient access requirement, but extends it to provider-directed access with attribution-based patient panel determination. Attribution logic — determining which patients are in a provider's panel — is a notoriously imprecise process with significant engineering implications for data access scope.

We implement CMS-0057-F compliant prior authorization APIs using Da Vinci PAS and CRD implementation guides as the technical specification, with X12-to-FHIR translation middleware that integrates with existing payer UM system APIs. Our CDS Hooks server implementations are designed for sub-200ms response times with UM rules engine caching and asynchronous enrichment patterns. We build payer-to-payer exchange infrastructure with FHIR Bulk Data server and client capabilities, attribution-based patient panel APIs, and bulk transfer orchestration that handles member transition workflows at plan scale.

Compliance-Native Architecture Guide

Design principles and a structured checklist for building software that is compliant by default — not compliant by retrofit. Covers data architecture, access controls, audit trails, and vendor due diligence.