CMS Prior Authorization Rule 2026: What Health Systems and Payers Actually Need to Build by October 2027

Key Takeaways

• The 2026 CMS Prior Authorization (CMS-0062-P) rule extends electronic prior authorization requirements to drugs for the first time, closing a major gap left by the 2024 rule.
• The hard compliance deadline is October 1, 2027 - by that date, systems must be live, not in development or testing.
• Compliance requires three major technical workstreams: building five interoperability APIs, implementing FHIR R4 and Da Vinci implementation guides, and modernizing or replacing legacy systems that cannot support modern API-based data exchange.
• HIPAA-covered entities have 24 months from the final rule's effective date to adopt FHIR for prior authorization transactions; small health plans get 36 months.
• Public reporting of drug prior authorization metrics begins in 2028, covering 2027 data.
• Organizations that haven't started yet should have a development partner contracted by mid-2026 at the latest - 18 months is a tight but realistic build window.

The prior authorization process has been a persistent source of friction in US healthcare for decades because of time and effort needed to approve a single prescription. In most cases, approval requires an excessive number of manual tasks—filling out forms or sending faxes (yes, actual faxes)—while patients wait days or even weeks, sometimes until their condition becomes critical.

The 2026 CMS Interoperability Standards and Prior Authorization for Drugs proposed rule  (officially designated CMS-0062-P) is the most significant federal push yet to fix this. It sets hard technical requirements, firm deadlines, and for the first time, extends electronic prior authorization mandates to drugs — not just procedures and services.

If your organization is a health system, payer, digital health vendor, or clearinghouse operating within CMS programs, this rule affects you directly. October 2027 is closer than it looks once you factor in procurement, development, testing, and validation cycles.

This article explains what the rule actually requires, who it applies to, what needs to be built, and what your team should be doing right now before engaging a development partner.

What Is the 2026 CMS Prior Authorization Rule and Who Does It Affect?

The Difference Between the 2024 Rule and the 2026 Rule: What Changed

The 2026 CMS Interoperability Standards and Prior Authorization for Drugs rule (CMS-0062-P) is a proposed federal regulation that requires health insurers and payers operating within CMS programs to modernize how they handle prior authorization (particularly for drugs) through standardized electronic systems, faster decision timelines, and greater transparency.

To understand the 2026 rule, you need to know what came before it. The 2024 CMS rule was already a big deal - it required payers to implement electronic prior authorization and set strict decision timeframes for non-drug items and services: surgeries, imaging, specialist referrals, and medical equipment. It was, and remains, real progress given the outdated, manual processes that had driven prior authorization for years.

Drugs, however, were left out despite being one of the highest-volume and highest-stakes categories in healthcare. The 2026 rule fixes that:

• It extends electronic prior authorization to drugs covered under both medical and pharmacy benefits
• Sets faster decision timeframes for drug requests
• Requires payers to give specific reasons when denying a drug authorization
• Expands public reporting to include drug metrics alongside everything else.

It also updates HIPAA's underlying data exchange standards to align with modern FHIR requirements - more on that in the FHIR section below.

Who Exactly Has to Comply

The rule uses the term "impacted payers" to describe the organizations subject to its requirements. That group includes:

• Medicare Advantage (MA) organizations
• State Medicaid fee-for-service programs
• 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 (FFEs)

The 2026 rule also pulls in a new group not previously covered - insurance plans offered to small business employees through federal marketplaces, known as FF-SHOP plans. If you offer coverage through FF-SHOP, you're now subject to the same interoperability requirements as everyone else.

On the provider side, health systems and hospitals are directly affected because they must connect to payer APIs to submit electronic prior authorization requests. Digital health vendors building EHR-adjacent tools, clinical decision support software, or prior authorization workflow platforms are also affected, because their systems must support the required technical standards. Health data clearinghouses – organizations that process electronic health transactions between providers and payers are affected through the HIPAA track of the rule.

In short: if your organization touches prior authorization in any meaningful way within a CMS program context, assume this rule applies to you and verify accordingly.

The Compliance Timeline

Understanding the timeline is critical because the rule has two distinct compliance tracks running in parallel, each with different deadlines and different affected populations.

Full Compliance Deadline: October 1, 2027

This is the hard deadline. By October 1, 2027, your optimized and compliant systems must be live and operational - not in testing, not in development, but actually running. Here's what that means in practice:

• Electronic prior authorization for drugs under the medical benefit, built on FHIR R4 and Da Vinci implementation guides
• Electronic prior authorization for drugs under the pharmacy benefit, using NCPDP SCRIPT, Formulary & Benefit, and Real-Time Prescription Benefit standards
• Faster decision timeframes for drug prior authorization requests: 24 hours for most Medicaid and CHIP programs, and no longer than 72 hours for standard requests (24 hours for expedited) for QHP issuers on federal exchanges
• Specific denial reasons communicated for every rejected drug authorization
• Drug prior authorization data flowing through the Patient Access, Provider Access, and Payer-to-Payer APIs

There's also a separate HIPAA compliance track running alongside this. Providers, payers, and clearinghouses have 24 months from the final rule's effective date to adopt FHIR as the standard for prior authorization transactions. Small health plans get 36 months. The clock starts when the rule is finalized (no fixed calendar date yet), so watch the Federal Register for the finalization announcement.

One honest note on timing: October 2027 looks comfortable on a calendar, but in reality it isn't. Factor in vendor selection, contracting, system discovery, development, testing, and validation - and 18 months goes fast. If you haven't started yet, your internal deadline for contracting a development partner should be mid-2026.

What You Report After: Starting in 2028

Once your systems are live and running through 2027, the reporting obligations kick in the following year. Think of it as the report card for your first year of compliance.

Starting in 2028, covering 2027 data, impacted payers must publicly report drug prior authorization metrics on their websites: approval rates, denial rates, and decision timeframes. This sits alongside the non-drug metrics reporting already required under the 2024 rule.

On the API side, payers must also report Provider Access, Payer-to-Payer, and Prior Authorization API usage metrics annually to CMS. Deadlines vary by payer type: MA organizations and Medicaid/CHIP FFS programs report by March 31, while Medicaid managed care plans and CHIP managed care entities have 90 days after the end of each rating period.

One additional reporting requirement kicks in sooner: once the final rule is published, existing payers have 60 days to submit their API endpoint information to CMS for a centralized public directory. New payers must do so 60 days before they start covering patients. After that, any changes must be submitted within one week and verified annually.

What You Actually Need to Build

The Five APIs

The rule requires impacted payers to implement and maintain five interoperability APIs, each serving a distinct function in the broader data exchange ecosystem. Together, they enable secure, seamless connection with hospital systems and the transfer of prior-authorization data.

The Patient Access API gives patients direct access to their own health data - including prior authorization status, approved drugs with dosage information, denial reasons, and related clinical documentation - through third-party applications of their choice. For drugs, this must include the status of the prior authorization, the dates of approval or denial, the circumstances under which the authorization ends, and any specific denial reason.

The Provider Directory API maintains a standardized, always-current directory of in-network providers that any system can query automatically, replacing the outdated static directories that list retired doctors and wrong phone numbers.

The Provider Access API lets providers pull a patient's prior authorization history, coverage details, and clinical documentation directly from the payer's system - with the patient's consent. Before writing a prescription, a doctor can see exactly what's already been approved, what's been tried, and what the plan will cover.

The Payer-to-Payer API ensures a patient's prior authorization history travels with them when they switch insurance plans. Approval dates, authorized drugs, dosages, supporting documentation – all of it transfers to the new payer automatically, so nothing has to start from scratch. The Prior Authorization API is the centerpiece of the rule. It replaces the fax-and-phone prior authorization process with a real-time electronic workflow. The request goes from the provider's EHR system to the payer's system automatically, and the decision comes back the same way.

Each of these APIs must conform to specific implementation guides (IGs) mandated by CMS. The Da Vinci suite of IGs is central to this: Coverage Requirements Discovery (CRD), Documentation Templates and Rules (DTR), Prior Authorization Support (PAS), and Payer Data Exchange (PDex) are all required. Organizations must implement specific versions of these IGs, and older versions have proposed expiration dates of January 1, 2028.

FHIR Compliance

FHIR (Fast Healthcare Interoperability Resources) is the modern data exchange standard that underpins all five APIs on the medical benefit side. Think of it as a universal language that lets different healthcare software systems talk to each other—something that, until recently, was remarkably hard to do in healthcare IT. But implementing FHIR R4 is not a single checkbox. It's a substantial technical undertaking that touches your:

• Authentication infrastructure: FHIR APIs must use SMART on FHIR for secure access control, meaning your systems need to support OAuth 2.0 flows that let providers and patients to authenticate and access only the data they're permitted to see
• Data architecture: your patient and clinical data must be mapped to FHIR resource types (like MedicationRequest, Coverage, or ClaimResponse) and structured to conform to the specific Da Vinci implementation guide profiles CMS requires, not just generic FHIR
• Integration layer with EHR systems: prior authorization workflows live inside EHR systems, so your FHIR APIs need to connect directly to your EHR's data model, which varies significantly depending on whether you're running Epic, Oracle Health, Meditech, or something else

The HIPAA track adds another layer. HHS is proposing to formally adopt FHIR as the required standard for prior authorization transactions across all covered entities, meaning providers, payers, and clearinghouses, not just insurers. This matters because HIPAA compliance isn't optional. Non-compliance carries significant financial penalties, and the clock starts as soon as the rule is finalized.

One important distinction: not all drugs fall under the same technical standard, and which one applies depends on how the drug is covered by the insurance plan.

Medical benefit drugs are typically administered in a clinical setting – think infusions, injections, or chemotherapy given at a hospital or clinic. These fall under FHIR R4 and Da Vinci implementation guides.

Pharmacy benefit drugs are the ones a patient picks up at a pharmacy with a prescription. These fall under three separate NCPDP standards instead:

• SCRIPT: handles electronic prior authorization requests and decisions
• Formulary & Benefit: lets providers query what a plan actually covers
• Real-Time Prescription Benefit: provides real-time coverage and cost information at the point of prescribing

If your organization handles both types (as many health systems and payers do) you're looking at two parallel technical tracks with different tooling, expertise, and testing requirements.

Legacy System Redesign or Replacement

Most health systems and payers operate on EHR and claims processing infrastructure that was not designed with FHIR interoperability in mind. Legacy systems - some running on architectures from the 1990s and early 2000s - may have no FHIR support at all, partial FHIR support that does not extend to the Da Vinci IGs, or vendor roadmaps that do not align with the October 2027 deadline. In practice, this means many of these systems simply cannot communicate with the modern FHIR-based APIs the rule requires: not without significant upgrades, middleware integration layers, or in some cases full replacement.

Epic, which runs in a large share of US health systems, has made significant investments in FHIR R4 support and has Da Vinci IG implementations in various stages of development. However, Epic's FHIR capabilities vary by module and version, and integration with Epic's APIs requires navigating their specific authentication requirements, data models, and certification processes. Other major EHR vendors – Oracle Health, Meditech, or Allscripts –  have varying levels of FHIR R4 readiness that must be assessed at the implementation level, not just the marketing level.

For many organizations, the realistic options are: upgrade existing systems where the vendor supports FHIR R4 and Da Vinci IGs on an acceptable timeline; replace systems where it doesn't; or build middleware integration layers that translate between legacy system outputs and FHIR-compliant API interfaces. Each path has different cost, risk, and timeline profiles that must be evaluated against your specific technical landscape.

Checklist: Things to Do Now

The following steps are what your organization should complete internally before engaging a development partner. Arriving at a vendor conversation with this groundwork done will compress the discovery phase significantly and produce better project scoping.

Identify which CMS programs you participate in

This is the foundational step as it determines which APIs you are actually required to build and which compliance timelines apply to your organization specifically. Not every organization needs all five APIs, and the applicable standards differ based on program participation. A Medicaid managed care plan has different obligations from a Medicare Advantage organization or a QHP issuer. Document precisely what your compliance footprint looks like before you start scoping technical work.

Inventory all your current software systems

Document every system involved in prior authorization workflows: EHR, pharmacy management, claims processing, billing, imaging, and any middleware or integration platforms. Note which vendor runs each system and which version is deployed. This inventory becomes the foundation for everything that follows - you cannot assess your FHIR readiness, identify integration gaps, or scope a realistic implementation plan without first knowing exactly what you're working with.

Check FHIR R4 readiness with each vendor

Contact your EHR vendor and any other relevant software vendors and ask directly: does your current version support FHIR R4? Do you support the Da Vinci CRD, DTR, PAS, and PDex implementation guides? What is your roadmap for the IGs required under the 2026 CMS rule, and does that roadmap align with October 2027? Get answers in writing.

Identify whether your drugs fall under medical benefit, pharmacy benefit, or both

This determines your technical track. Medical benefit drugs require FHIR R4 and Da Vinci IGs. Pharmacy benefit drugs require NCPDP SCRIPT, Formulary & Benefit, and Real-Time Prescription Benefit standards. Many organizations will need both, which doubles the scope of technical implementation.

Assess your data quality

FHIR APIs are only as good as the data flowing through them. Inconsistent patient record formats, duplicate records, missing fields, and non-standardized terminology will cause implementation failures no matter how well the API layer is built. Conduct a data quality assessment before development begins.

Document your current prior authorization workflow in detail

Map who does what today: which staff roles are involved, what forms are used, how requests are submitted, how decisions are communicated back to providers, and how denials are currently handled. This workflow documentation will be essential input for any development partner scoping the implementation.

You’ll also need to identify an internal project owner. This person should be able to speak fluently to both clinical workflows and IT systems. If no such person exists in your organization, identify two people who together cover that ground, and establish a clear decision-making structure before vendor conversations begin.

Set an internal vendor selection deadline

Given the October 2027 compliance deadline and realistic development and testing timelines, your organization should have a development partner contracted by mid-2026. Working backward from October 2027 with 12-18 months of realistic build time, that window is already tight for organizations that are starting their assessment now.

Next Steps: Building a Realistic Roadmap to October 2027

Once the internal groundwork above is complete, a realistic implementation roadmap for most organizations follows this sequence:

• Technical discovery and gap assessment
• Architecture and API design
• Phased development starting with the highest-priority APIs
• Integration with EHR and payer systems
• Conformance testing against Da Vinci IG specifications
• Final validation and go-live.

The sequencing of which APIs to build first matters. Organizations that have not yet implemented any of the five APIs should generally prioritize the Prior Authorization API: it carries the most direct patient impact and the most immediate operational urgency — followed by the Patient Access API, which has the broadest data surface area and typically takes longer to get right.

The NCPDP pharmacy benefit track, if applicable, should run as a parallel workstream rather than sequentially. It requires different expertise and different tooling from the FHIR track, and waiting until the FHIR work is complete before starting NCPDP work is a common planning mistake that compresses timelines unnecessarily.

Testing is the phase that consistently takes longer than organizations expect. Conformance testing against Da Vinci implementation guides is not a rubber stamp — it requires iterative validation against specification requirements, coordination with trading partners, and in many cases formal certification processes. Building adequate testing time into your roadmap from the start is essential.

If your organization needs a development partner with FHIR R4 fluency, Epic integration experience, and deep healthcare domain knowledge to help navigate this implementation, Kanda Software works with health systems and digital health organizations on exactly this kind of engagement. The right time to start that conversation is before your internal deadline, not after.

Conclusion

The CMS interoperability rule 2027 is not a distant regulatory abstraction. It is a concrete technical mandate with a firm deadline, specific standards requirements, and enforcement mechanisms built into existing HIPAA law. The organizations that will meet October 2027 comfortably are the ones starting their internal assessment now, completing their vendor landscape analysis in the coming months, and contracting development partners well before the end of 2026.

The organizations that will struggle are the ones treating this as a future problem. In healthcare IT, there is no such thing as a fast procurement cycle, a trivial legacy system migration, or a quick Da Vinci IG implementation. The complexity is real, the timeline is tight, and the window to act is open now.