The Centers for Medicare & Medicaid Services finalized a rule in January 2024 that requires certain health plans to build four FHIR-based APIs and to speed up prior authorization decisions. CMS later pushed the API compliance date from January 1, 2026 to January 1, 2027, but that date is not far off, and it covers work that takes months to design, test, and connect to real claims and clinical data. This article explains who the rule covers, what each API has to do, which deadlines already passed and which are still ahead, and what a software team should be building right now if a client falls under this rule.
This is not legal advice. Confirm current requirements against the CMS rule text and your organization's counsel before making compliance decisions.
Who the rule applies to
The CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) applies to a specific set of payers, often called "impacted payers" in the rule text:
- Medicare Advantage organizations
- State Medicaid fee-for-service programs
- State Children's Health Insurance Program (CHIP) fee-for-service programs
- Medicaid managed care plans
- CHIP managed care entities
- Qualified Health Plan (QHP) issuers on the Federally-Facilitated Exchanges
Commercial payers outside these programs are not directly bound by this rule, though many are adopting similar FHIR APIs voluntarily or under state-level interoperability requirements. QHP issuers are also excluded from the prior authorization decision timeframes described below, even though they must still build the API. Prior authorization for prescription drugs is excluded from the rule entirely; it only covers items and services that go through a payer's medical prior authorization process.
The four APIs the rule requires
CMS-0057-F builds on an earlier interoperability rule that already required a Patient Access API. The new rule expands that API and adds three more, all built on HL7 FHIR standards rather than the older X12 EDI transaction formats most payer systems still run internally.
Patient Access API (expanded)
The existing Patient Access API, which already exposes claims, encounter, and clinical data to patients through third-party apps, must be expanded to include prior authorization information: what was requested, the decision, and the reason for a denial. For a team that already built the original Patient Access API, this is a scope addition to an existing FHIR resource set rather than a new system.
Provider Access API
This API lets a provider's system query a payer directly for a specific patient's claims, encounter, clinical, and prior authorization data, with the patient's authorization. It is the piece most likely to require new infrastructure for payers that have never exposed structured clinical data to external provider systems, since it means standing up FHIR endpoints, consent handling, and provider identity verification against something like NPPES or a state provider directory.
Payer-to-Payer API
When a patient changes plans, or has concurrent coverage, this API requires payers to exchange most of the same data categories with each other, again with patient permission. In practice this is the hardest piece to test early, because it depends on another organization's endpoint being live and spec-compliant, not just your own.
Prior Authorization API
This is the centerpiece of the rule for most provider-facing software. It must support three FHIR-based operations: letting a provider's EHR query whether a given prior authorization is required for a specific item or service, letting the provider submit the request with the necessary documentation attached, and returning a decision. Denials must include a specific reason, not a generic code.
Deadlines: what already applies and what is still ahead
CMS split this rule into operational requirements and API requirements, and they land on different schedules:
- Faster decisions (already in effect in 2026): Impacted payers must send prior authorization decisions within 72 hours for expedited requests and seven calendar days for standard requests, for most items and services covered by the rule.
- Specific denial reasons (already in effect in 2026): Every prior authorization denial must state a specific reason, not a boilerplate code.
- Public metrics reporting (already in effect in 2026): Impacted payers must publicly post prior authorization metrics, such as approval and denial rates and average decision times, on their websites.
- The four FHIR APIs (compliance date January 1, 2027, delayed from January 1, 2026): This is the deadline most software teams are building toward right now. CMS moved it back a year after public comment on implementation burden, but has not signaled a further delay.
- MIPS Electronic Prior Authorization measure: Eligible clinicians, eligible hospitals, and critical access hospitals get a new measure under the Promoting Interoperability category for using a payer's Prior Authorization API, tied to the same general timeline.
The gap between "operational rules already live" and "APIs due in 14 months" is exactly where a lot of organizations get caught out: they assume the whole rule is a 2027 problem because that's the date everyone talks about, then discover the faster-decision and metrics-reporting requirements were already enforceable.
What building this actually involves
If you are a payer, a health system integrating with payer APIs, or a vendor serving either, the technical work breaks down into a few concrete pieces.
FHIR server and resource mapping
Each API exposes specific FHIR resources: Claim, ExplanationOfBenefit, Coverage, DocumentReference, and for prior authorization specifically, resources built around the PAS (Prior Authorization Support) and DTR (Documentation Templates and Rules) implementation guides from the HL7 Da Vinci project. Most payer core systems do not store data natively as FHIR resources, so the real engineering effort is usually a mapping and transformation layer between legacy claims adjudication systems and a FHIR-compliant API surface, not the API layer itself.
Consent and identity
Provider Access and Payer-to-Payer both depend on verifying who is asking and what they are authorized to see. That means OAuth 2.0-based authorization flows, provider directory lookups, and patient consent tracking that can be audited later. Teams that already built patient portal authentication and access controls have a head start on the identity patterns here, even though the APIs serve systems rather than people directly.
DTR integration for prior authorization
The Documentation Templates and Rules piece is what lets a provider's EHR ask, in real time, "does this procedure need prior authorization, and if so, what documentation do you need," and get back a structured questionnaire rather than a PDF form. Implementing DTR well is what actually reduces provider friction; implementing only the bare minimum query-and-submit endpoints technically satisfies the rule but leaves the experience close to what providers already dislike about prior authorization today.
Testing against a moving ecosystem
Because Payer-to-Payer and Provider Access depend on other organizations' endpoints, plan for a testing phase that uses HL7's published test servers and reference implementations before assuming your integration will work against a live partner system. Several EHR vendors and health information networks are publishing their own conformance testing environments as the deadline approaches; checking whether a specific trading partner has one available is worth doing early rather than during the final compliance push.
Where this intersects with HIPAA
CMS-0057-F is an interoperability rule, not a HIPAA rule, but it changes how protected health information moves between systems, which puts it squarely inside HIPAA's security and transaction-standard requirements. One detail worth knowing: HHS is using enforcement discretion for the X12 278 transaction standard, meaning covered entities that implement an all-FHIR Prior Authorization API will not be enforced against for not also supporting the older X12 278 format. That does not remove the underlying HIPAA Security Rule obligations around access controls, audit controls, and transmission security for whatever system carries this data; it only addresses the transaction-format requirement. Whether a given implementation meets HIPAA's requirements still depends on the specific technical safeguards, business associate agreements, and risk analysis behind it, not on following this rule alone.
Practical starting point for a software team
For a health plan, health system, or vendor that has not started this work, a reasonable sequence looks like this:
- Confirm which of the six payer categories above actually applies to the organization, since the rule's scope is narrower than "all payers."
- Inventory which operational requirements (decision timeframes, denial reasons, metrics reporting) are already live and whether current processes meet them.
- Pick a FHIR server strategy: a vendor platform designed around the Da Vinci implementation guides, or a custom mapping layer in front of existing claims systems. This decision affects timeline more than almost anything else.
- Scope the Prior Authorization API and DTR integration first, since it has the most direct effect on provider experience and the most regulatory attention.
- Build Provider Access and Payer-to-Payer with realistic assumptions about partner readiness, and budget time for integration testing that depends on someone else's system.
Frequently asked questions
Does this rule apply to commercial health insurance that isn't Medicare Advantage or an exchange plan?
Not directly. The rule's "impacted payer" definition covers Medicare Advantage, Medicaid and CHIP fee-for-service and managed care, and QHP issuers on the federal exchanges. Fully commercial, employer-sponsored plans outside those categories are not bound by this specific rule, though the broader direction of federal policy has been toward more FHIR-based data exchange.
Is prior authorization for medications covered by this rule?
No. CMS-0057-F excludes prior authorization decisions for prescription drugs. It applies to items and services that go through a payer's medical prior authorization process.
What happens if a payer misses the January 1, 2027 API deadline?
The rule carries standard CMS enforcement mechanisms for the programs involved, which can include corrective action requirements and, in Medicare Advantage, contract-level consequences. Specific enforcement posture can change, so current CMS guidance and legal counsel are the right source for what happens in a given program at a given time.
Do we need to support both FHIR and the older X12 278 standard?
HHS has indicated it will not enforce X12 278 support against covered entities that implement an all-FHIR Prior Authorization API, but organizations should confirm current enforcement guidance rather than assume this is permanent, and should check whether specific trading partners still expect X12 transactions in practice.
How is this different from the FHIR basics used in general EHR integration?
The underlying standard is the same HL7 FHIR framework used in most modern EHR integration work, but this rule layers specific implementation guides (PAS and DTR from the Da Vinci project) and specific regulatory deadlines on top of it. A team experienced in general FHIR integration still has real new work to do to meet the prior-authorization-specific resources and workflows this rule requires.
Getting the architecture right before the deadline
Fourteen months sounds like time to spare until the mapping layer between a legacy claims system and FHIR resources turns out to be the slow part, or until a Payer-to-Payer integration test reveals that a trading partner's endpoint isn't ready either. Organizations that start with a clear API and consent architecture, rather than treating this as a checklist of four endpoints to stand up quickly, tend to end up with systems that hold up under provider and patient use, not just under a conformance test.
Sabyrix Technologies builds FHIR-based EHR and claims integrations and broader healthcare software for organizations navigating rules like this one. If your team is scoping Prior Authorization API, Provider Access, or Payer-to-Payer work against the 2027 deadline, a strategy call is a useful way to work through the architecture decisions before committing engineering time to one approach.