Key Takeaways
- The CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) requires health plans to implement three new HL7 FHIR® APIs by January 1, 2027.
- January 2026 provisions, including 72-hour expedited and seven-day standard prior authorization decision timelines, are already active.
- API readiness involves data quality, attribution logic, and integration architecture.
- Partnering with integrated technology providers like HealthEdge® turns CMS-0057-F work into reusable data assets that support risk adjustment and value-based care.
- CMS-0062-P signals that the regulatory floor is rising — health plans that build to spec now will be positioned to absorb what comes next.
January 1, 2027, is closer than it seems for health plan compliance and technology teams.
The Centers for Medicare and Medicaid Services (CMS) Interoperability and Prior Authorization Final Rule (CMS-0057-F) requires health plans to implement three new Fast Healthcare Interoperability Resources APIs—developed by Health Level Seven® (HL7®) International and known as HL7 FHIR® — by January 1, 2027. HL7 FHIR APIs: Provider Access, Payer-to-Payer, and Prior Authorization. At the same time, health plans must expand the existing Patient Access API to include prior authorization data and update the Provider Directory API to meet new implementation guide standards.
The Prior Authorization API is particularly complex, as it’s a coordinated set of three HL7® Da Vinci implementation guides that drive in-workflow coverage checks, automated documentation gathering, and electronic submission that is central to making the API functional and not just technically compliant. CMS estimates the rule will save the healthcare system approximately $15 billion over 10 years by reducing prior authorization burdens.
For compliance executives and IT teams, the critical question is how to turn a compliance hurdle into a strategic foundation.
Jump to Section:
- The Five APIs and What They Entail
- What API Readiness Actually Looks Like for Health Plans
- API Compliance Best Practices: Sequencing and Testing
- What’s Coming Next: CMS-0062-P
- Building Infrastructure That Outlasts the API Deadline
The Five APIs and What They Entail
Patient Access API
Many health plans already operate the Patient Access API under the 2020 CMS rule. CMS-0057-F expands requirements to include prior authorization data by 2027. Plans must also report usage metrics annually to CMS.
Success here depends on clean, structured data feeding the endpoint. If data inconsistencies exist, the API exposes them. Many organizations use this opportunity to improve data quality broadly, which benefits member apps and portals.
Provider Directory API
The Provider Directory API delivers standardized provider information in HL7 FHIR format. The Provider Directory API originated under the 2020 CMS Interoperability and Patient Access rule and continues to be required under the broader interoperability framework. Accurate provider data is critical. Errors create member frustration and compliance risks. Provider Atlas Edge, formerly HealthEdge® Provider Data Management, helps health plans maintain a single source of truth for provider data, reducing operational friction, compliance risk, and administrative risk.
Provider Access API
The Provider Access API allows in-network providers to request bulk data for attributed members. Two challenges define this API:
- Attribution Accuracy: Plans need precise records of provider-member relationships.
- Opt-Out Management: Members can decline data sharing, and plans must track these preferences.
Solving these challenges doesn’t make bulk data export simple — but it does make it achievable. Health plans that get the underlying data quality, matching, and governance issues right are far better positioned to meet the bulk export requirements without the export process itself becoming another point of failure.
Payer-to-Payer API
The Payer-to-Payer API facilitates data sharing between health plans to enable member transitions. Plans must share up to five years of claims and prior authorization data when requested by a new payer.
Core compliance challenges for the Payer-to-Payer API are member matching, provider attribution, and consent management—each of which can be complex. Payers need to establish and continuously maintain which providers have an active treatment relationship with which members, a determination that is dynamic and must be verified and updated within tight timeframes.
Layered on top of that is consent: members must be able to opt out of data sharing, that choice has to be honored and tracked reliably, and the underlying business logic has to enforce consent and treatment-relationship rules correctly before any data is released. Getting this wrong doesn’t just create compliance risk—it’s the difference between a functioning API and one that over-shares or silently withholds data it should release.
Successful implementation requires building reliable identity, attribution, and consent management systems first, before addressing the bulk export mechanics themselves. Only then does the export become a contained technical problem rather than an open-ended one.
The Prior Authorization API
The Prior Authorization API aims to reduce the administrative burden for providers. It supports real-time queries, enabling health plans to respond instantly with approvals or specific denial reasons. The technical complexity is significant. It involves three implementation guides that are designed to work together:
- HL7 FHIR® Implementation Guide: Da Vinci Coverage Requirements Discovery (CRD), Version 2.2.1: Allows a provider system to query a health plan at the point of care to determine whether prior authorization is required for a specific service, which reduces unnecessary requests before they’re submitted.
- HL7 FHIR® Implementation Guide: Da Vinci Documentation Templates and Rules (DTR), Version 2.2.0: Enables health plans to communicate documentation requirements in a computable format, allowing clinical systems to automatically retrieve and populate relevant patient data.
- HL7 FHIR® Implementation Guide: Da Vinci Prior Authorization Support (PAS), Version 2.2.1: Supports direct submission of prior authorization requests from provider systems to health plan systems using HL7 FHIR, with structured responses that include status, denial reasons, and approval data.
Together, CRD identifies whether authorization is needed, DTR captures the documentation, and PAS submits the request and receives the decision. Implemented as a complete workflow, they reduce manual touchpoints and shorten turnaround times on both sides of the transaction.
Health plans with integrated care management solutions like Clinical Edge, formerly HealthEdge GuidingCare®, have a clear competitive advantage. Clinical Edge supports over 125 pre-built APIs and HL7 FHIR-compliant data exchange to enable the connectivity these workflows demand.
What API Readiness Actually Looks Like for Health Plans
True API readiness involves three layers that go beyond the technical build:
1. Data quality
Every API is only as good as the data feeding it. The Patient Access API exposes inconsistencies in claims and clinical data. The Provider Access API surfaces gaps in attribution records. The Payer-to-Payer API depends on reliable member matching. Plans that haven’t addressed underlying data quality issues will find that the APIs make those problems visible—to members, providers, and regulators.
2. Attribution and consent logic
The Provider Access API requires accurate records of provider-member relationships. The Payer-to-Payer API requires reliable consent workflows. These aren’t technical configurations—they’re governance frameworks that need to be designed, tested, and maintained. Plans that build these correctly create reusable infrastructure. Plans that approximate them will face ongoing maintenance and compliance exposure.
3. Integration architecture
Isolated endpoints that don’t connect to core administrative, care management, and provider data systems create manual workarounds and data lag. The plans that get the most from CMS-0057-F build APIs that are wired into their broader technology stack, — not bolted onto the side of it.
API Compliance Best Practices: Sequencing and Testing
Organizations that treat CMS-0057-F compliance as a phased engineering project see the best results.
Phase 1: Prior Authorization and Provider Directory API
Prior Authorization is the most technically complex, with three coordinated Da Vinci implementation guides (CRD, DTR, and PAS), X12-to-HL7 FHIR translation, and real-time response requirements. Addressing it early creates the runway needed to work through the business logic and stakeholder coordination it requires. Pair it with the Provider Directory API, a comparatively lighter lift that establishes a foundational data asset for the APIs that follow.
Phase 2: Patient Access and Provider Access APIs
Surface and address data quality issues here. Problems identified at this stage are cheaper to fix than problems discovered during Payer-to-Payer implementation. Build attribution frameworks for Provider Access alongside this work, as accurate provider-member relationship records and opt-out tracking are required before finalizing bulk data workflows.
Phase 3: Payer-to-Payer API
Leave this for last. Build opt-in consent frameworks before finalizing endpoints. These governance layers are the hard part, and the bulk data export and member data sharing become more straightforward once member matching, consent, and deduplication logic are in place. Plans that sequence correctly find the Payer-to-Payer API build is more manageable than expected.
Testing is critical at every stage. This includes conformance testing against Da Vinci implementation guides and stress testing under realistic query volumes. Don’t wait until an endpoint is fully built to test—surface integration gaps early, when remediation costs less and disruption is contained.
What’s Coming Next: CMS-0062-P
CMS-0057-F is not the end of the interoperability rule cycle. CMS-0062-P, the proposed 2026 Interoperability Standards and Prior Authorization for Drugs rule, builds directly on the foundation established under CMS-0057-F.
Key additions proposed under CMS-0062-P include:
- Mandated Da Vinci Conformance: CRD, DTR, and PAS would move from strongly recommended to explicitly required, with specific versions codified in regulation.
- Drug Prior Authorization: For the first time, HL7 FHIR-based prior authorization requirements would extend to medication workflows. CMS-0057-F did not cover drugs. CMS-0062-P does.
- Potential HIPAA Elevation: The proposal could add Da Vinci implementation guides to HIPAA requirements, significantly raising the enforcement weight behind conformance obligations.
CMS-0062-P is still a proposed rule, but the direction it signals is unambiguous: the regulatory floor is rising. Health plans that build to spec under CMS-0057-F will absorb these changes as incremental extensions. Plans that take a minimal approach will face another round of remediation.
Building Infrastructure That Outlasts the API Deadline
API compliance deadlines may be January 1, 2027, but the value of what gets built extends far beyond that.
The HL7 FHIR data layer created for CMS-0057-F compliance has lasting operational value across the health plan enterprise:
- Risk adjustment: Real-time data exchange surfaces clinical information that could support more accurate risk coding and submission.
- Medicare Star ratings: The Payer-to-Payer API brings in up to five years of historical claims and clinical data when new members join, giving plans immediate visibility into open care gaps and measure-relevant history — foundational inputs for HEDIS reporting, gap closure workflows, and the quality performance that drives Star ratings.
- Population health analytics: Longitudinal member data accessible through HL7 FHIR enables predictive interventions and more targeted care management.
- Value-based care: Tighter payer-provider data exchange supports the shared data requirements of value-based contracts and alternative payment models.
By treating compliance as an opportunity to build reusable systems, health plans create a lasting operational advantage. The plans that understand this will look fundamentally different in three years from those that don’t.
Learn more about how HealthEdge is supporting prior authorization efforts and CMS-0057-F compliance. Read the case study: From Bottleneck to Breakthrough—How Health Plans are Automating Prior Authorization.
HL7® and FHIR® are the registered trademarks of Health Level Seven International, and their use does not constitute an endorsement by HL7.
Frequently Asked Questions
1. Which health plans must comply with CMS-0057-F?
The rule applies to Medicare Advantage organizations, Medicaid and CHIP fee-for-service and managed care programs, and Qualified Health Plans (QHPs) on Federally Facilitated Exchanges.
2. Who is responsible for API compliance if a plan delegates prior authorization?
Responsibility remains with the health plan. The plan must ensure compliance by building the API over the vendor’s system or requiring the vendor to provide the functionality.
3. Are QHPs subject to prior authorization decision timelines?
No. The expedited and standard decision timelines apply to Medicare Advantage, Medicaid, and CHIP plans. QHPs must still implement all APIs and report public metrics.
4. Does the HL7 FHIR Prior Authorization API replace the X12 278 standard?
Not necessarily at this stage of the regulations. CMS allows flexibility. Plans can use HL7 FHIR-only, X12-only, or hybrid approaches.
5. What data must the Payer-to-Payer API share?
The API shares claims and encounter data (excluding provider remittances and enrollee cost-sharing), USCDI clinical data classes, and prior authorization records — excluding drug authorizations and denied requests. When a member joins a new plan, the incoming payer must request this data from the member’s previous or concurrent payer, covering up to five years prior to the request. This gives the new plan immediate access to member history rather than starting from a blank record.