Care Evolution

What the Rule Actually Requires (And Why It’s Not Just About APIs)

CMS-0057-F isn’t just another set of interoperability mandates, it’s a significant operational shift in how payers manage and exchange data, particularly around prior authorizations. The rule introduces four FHIR APIs with highly specific expectations for what data must be shared, how quickly, and with whom.

Patient Access API: Expanded to include prior auth

Payers must enhance their Patient Access APIs to include prior authorization data (excluding drugs). This isn’t just a binary status – it includes the approval or denial date, the items/services approved, and the specific reason for any denial. Active prior authorizations must be included, as well as any prior auths that had a status change in the past year. Importantly, this applies regardless of how the request was originally submitted – phone, fax, portal, or API. Updates must be reflected in the API within 1 business day.

In addition, payers must begin reporting on Patient Access API usage. Starting in 2026, annual usage metrics must be submitted to CMS by March 31 each year, covering the prior calendar year. The first report, due March 31, 2026, must cover usage in calendar year 2025 and include counts of unique users and repeat users of the API.

Provider Access API: Structured, permissioned data sharing

This API requires payers to share patient data – including claims, encounter data, USCDI clinical elements, and prior auth details – with in-network providers who have an active treatment relationship. Unlike the Patient Access API, no patient app is involved. Instead, the burden is on the payer to: 1) verify the treatment relationship, 2) manage patient opt-outs, and 3) educate both patients and providers. This includes establishing a provider attribution process and delivering updates within 1 business day of a request or status change.

Payer-to-Payer API: A departure from patient-mediated exchange

This expands previous guidance and now mandates bulk FHIR-based exchange between payers. When a member switches health plans, the new plan must request up to 5 years of historical data (excluding denied prior auths and cost-sharing info), and the previous plan must respond within 1 week. For concurrent coverage, data sharing must occur quarterly. Payers must also implement a process to identify prior payers, collect member opt-in, and include an attestation with every request.

Prior Authorization API: Not just electronic, but accountable

This API must support full prior auth workflows: discovery (what requires prior auth), submission, tracking, and final determination. It must expose documentation requirements and deliver decisions within 72 hours for expedited requests and 7 calendar days for standard ones. Updates must be reflected in the API within 1 business day and records retained for at least 1 year after the last status change.

Separate from the API requirements, new operational rules take effect January 1, 2026, requiring payers to consistently meet these turnaround times, and provide clear, specific reasons for any denial – regardless of submission method. In addition, payers must publicly report prior authorization metrics beginning March 31, 2026, covering calendar year 2025. Required metrics include approval/denial rates, appeals outcomes, extended reviews, and average decision times.

Implementation Timeline

Why Payers Choose CareEvolution

• Flexible integration with existing UM, claims, and provider network systems
• FHIR-native architecture supporting one-off queries and bulk exchange
• 1-day update readiness to meet regulatory SLAs
• Real-world security and access management with OAuth2, scopes, and registration
• Modular deployment – start with Patient Access, expand as needed