As of January 2026, CMS's Interoperability and Prior Authorization Final Rule is in effect. Medicare Advantage plans, Medicaid managed care plans, CHIP managed care entities, and Qualified Health Plan issuers on the federal exchange are now required to implement FHIR-based APIs for prior authorization and patient access.
This isn't a future requirement anymore. It's live. And the ripple effects are hitting every healthtech company that touches payer data, prior authorization workflows, or patient-facing applications.
What the Rule Actually Requires
The rule mandates three categories of FHIR-based APIs:
Patient Access API. Payers must make claims, encounter data, and clinical information available to patients through FHIR R4 APIs. This has been in effect since earlier iterations, but enforcement is tightening.
Provider Access API. Payers must share patient data with in-network providers through FHIR APIs, enabling care coordination and reducing information gaps when patients move between providers.
Prior Authorization API — the big one. Payers must implement a FHIR-based prior authorization workflow that allows providers to submit, check status, and receive decisions through standardized APIs. This replaces (or supplements) the phone/fax-based workflows that add days or weeks to care delivery.
The rule also requires payers to report prior authorization metrics publicly — approval rates, denial rates, and processing times. This transparency component creates additional pressure to modernize.
Translation: if your product touches prior authorization, your FHIR implementation needs to be real and functional — not a roadmap item.
Who's Directly Affected
Payers and health plans have the primary compliance obligation. If you're a healthtech company serving payers, your clients are now under mandate.
Healthtech companies building prior authorization tools need to support the FHIR-based PA API. If your product is built around X12 278 transactions or proprietary payer portals, this likely means significant integration work.
EHR vendors and health information exchanges face pressure from both sides: providers expecting their EHR to support the new PA APIs, and payers requiring FHIR-compliant data exchange.
Provider organizations benefit from the rule but also need to ensure their systems can consume the new APIs. Many smaller provider groups rely on their EHR vendor for this capability — and not all vendors are ready.
What This Means for Your Product Roadmap
If you're a healthtech company in the payer or provider space, here's the practical impact:
Your FHIR implementation needs to be real, not theoretical. Many companies added "FHIR-ready" to their marketing over the past few years without building robust FHIR R4 API integrations. The mandate requires actual, functional FHIR APIs — not a slide deck.
X12-only integrations aren't enough anymore. If your prior authorization workflow is built entirely on X12 278/275 transactions, you need a parallel FHIR pathway. The mandate doesn't eliminate X12, but it creates a FHIR-first expectation.
Data mapping becomes critical. The rule specifies use of HL7 Da Vinci Implementation Guides for prior authorization. If your data model doesn't map cleanly to Da Vinci profiles (PAS, PDex, CRD), you have mapping work ahead. This isn't a trivial exercise — Da Vinci profiles are specific and exacting.
Testing against real payer endpoints is essential. Sandbox testing isn't sufficient for compliance. You need to validate your FHIR integrations against actual payer API endpoints, which means establishing connectivity and testing arrangements with each payer.
Translation: "FHIR-ready" on your marketing site no longer counts. You need working FHIR APIs tested against real payer endpoints.
The TEFCA Connection
Running in parallel, the Trusted Exchange Framework and Common Agreement (TEFCA) is establishing national-level standards for health information exchange. TEFCA's Qualified Health Information Networks (QHINs) create a framework for cross-organization data exchange that complements the CMS mandate.
Companies that build their interoperability stack with TEFCA alignment in mind — using standard FHIR profiles, supporting USCDI data classes, and designing for cross-network exchange — will be better positioned as the regulatory landscape continues to evolve.
This isn't just about compliance today. It's about building infrastructure that won't need to be rebuilt when the next set of requirements drops. And in healthcare, the next set of requirements always drops.
A Practical Checklist
If you're assessing your readiness right now, here's where to start:
Immediate (this quarter):
Audit your current FHIR R4 API implementation against the Da Vinci Implementation Guides — specifically PAS, PDex, CRD, and DTR. Identify gaps between your current data model and the required FHIR profiles. Establish or verify connectivity with your target payers' FHIR API endpoints. Review your authentication and authorization implementation (SMART on FHIR).
Translation: if you haven't pulled up the Da Vinci IG specs and mapped your data model against them, that's your first action item this week.
Near-term (next 90 days):
Build or update FHIR-based prior authorization submission and status check workflows. Implement proper error handling for FHIR API responses — payer implementations vary widely, and graceful degradation matters. Set up monitoring and alerting for API connectivity, response times, and error rates. Document your compliance posture for customer-facing conversations.
Ongoing:
Track CMS enforcement actions and guidance updates. Monitor Da Vinci IG updates (these evolve). Build toward TEFCA/QHIN compatibility if you're in the HIE space. Plan for the Provider Directory API requirement, which is also part of the rule.
The Opportunity
Regulation creates urgency, and urgency creates opportunity. Every payer and healthtech company that hasn't solved FHIR-based interoperability is now under deadline pressure. The companies that can help them move fast — whether through products, services, or advisory support — are in a strong position.
The broader trend is clear: healthcare data exchange is moving toward FHIR-based, API-first, and standards-driven interoperability. The CMS mandate is just the most immediate forcing function. Companies that build this capability now aren't just solving a compliance problem — they're building infrastructure that will define how healthcare data flows for the next decade.