Illustration of CMS Interoperability rule
Health Interoperability
9 Min Read

CMS-0057-F has landed. But what does it mean for your FHIR roadmap?

Photo of Rich Almeida
Rich Almeida

Subscribe to our newsletter


On 17 January, after months of industry speculation, CMS released the much-anticipated Interoperability and Prior Authorization Final Rule (CMS-0057-F), a comprehensive initiative aimed at reshaping data exchange in the healthcare ecosystem.

The rule is a significant milestone in the journey toward better access to interoperable patient data for patients, providers, and payers. The reduced burden on payers, providers, and patients could bring ten-year cost savings running into billions, and will free up valuable time for care providers to spend on delivering high-quality care.

Compliance requires – among other things – extensive implementation of FHIR via a set of APIs that improve access to health information or focus on automating the prior authorization process. As of today, our Firely Server has already completed many of these components. So read on for the full story, and check out how we can support your FHIR compliance roadmap.

The scale of the task

CMS-0057-F is a pivotal regulatory proposal that advances interoperability and patient access to health information, fostering seamless data exchange throughout the healthcare ecosystem.

Now that we have the details, the serious work can begin. And there is likely to be a lot of it: the rule document alone extends to 728 pages.

Under the new rule, prior authorization decisions must be communicated within seven days for standard requests or three days for urgent issues. Denials must come with a reason, along with clear instructions for resubmissions and appeals. Payers are also required to report patient access and prior authorization metrics, providing a valuable feedback loop for improving these processes in future rulemaking.

While the primary emphasis is on payers, providers must also make adjustments to facilitate data exchange and streamline their processes and costs. This is especially important regarding FHIR API prior authorization obligations.

Some operational provisions take effect as soon as January 2026, while API software will need to be developed and deployed by 1 January 2027.

Getting down to the details

The key to implementing the rule is having the mandated FHIR APIs in place. Some of these were included in the previous rule, but others are brand new: together they form a solid infrastructure for exchanging information between payers, providers, and patients.

Prior Authorization API

The Prior Authorization API is right at the heart of things: a transformative shift in automating prior authorization processes.

Impacted payers must maintain a Prior Authorization API that includes covered items and services, documentation requirements, and supports prior authorization requests and responses. The API must communicate approval, denial (with specific reasons), and requests for more information.

Given the existing complexity of prior authorization processes, automating them in FHIR will always be a challenge. This API has three substantial IGs recommended by the rule and a fourth recommended by Da Vinci to support documentation exchange.

There is no shortage of new FHIR technologies in this API, including CQL, CDS hooks, and questionnaires. Details of these can be found in the recommended IGs and you can find an overview in Firely’s updated ‘Ultimate Guide to FHIR in US Regulations’.

Patient Access API

The previous rule already mandated an API that allows patients to access their data and share it with third parties. The new rule brings all the data elements for prior authorization into scope.

Impacted payers must enhance their existing FHIR Patient Access API by incorporating information regarding prior authorizations (excluding drug-related ones). This requirement must be fulfilled by January 1, 2027, and from 1 January 2026 payers must report annual Patient Access API usage metrics to CMS.

Provider Access API

This is a new requirement that allows providers to access health plan data for their patients. Instead of individuals making requests (as in the Patient Access API), the provider can request data in bulk.

The data to be shared includes claims, encounter data, and specified prior authorization information. Payers must provide clear information to patients about the benefits of API data exchange and their opt-out rights. 

The concept of this API looks simple enough, but its implementation in FHIR involves several intricate tasks, including establishing a member-to-provider attribution process (aka member-matching), verifying patient consent and authorization based on valid treatment relationships with providers, incorporating complex business logic to enforce consent and authorization rules, and enabling the receipt of data in bulk format. These features add layers of complexity to the API’s development and functionality within the FHIR framework.

Payer-to-Payer API

This API ensures payers exchange information to ensure continuity of care for patients transitioning between health plans.

Impacted payers must maintain a Payer-to-Payer API to share claims, encounter data, and certain prior authorization information, while excluding provider remittances and enrolee cost-sharing details. The data shared must align with the USCDI standards and include patient data within five years of the data request. A finalized opt-in process empowers patients to consent to data sharing, and impacted payers must clearly explain the benefits and opt-in procedure.

CMS announced enforcement discretion on specific payer-to-payer data exchange provisions of the May 2020 Interoperability and Patient Access final rule, pending resolution of implementation challenges. With these issues addressed in the recent ruling, CMS mandates payers to exchange data using FHIR technology. If payers haven’t already adopted FHIR for this purpose, they must incorporate various technologies, and ensure patient data within five years of the exchange request is available on their FHIR servers. This also includes prior authorization data, with some nuances to status and timing.

Compliance is simplified by substantial overlap with the consent functionality and implementation guides required for the Provider Access API.

Provider directory API

This API was required by the previous rule and has not significantly changed. Publicly-accessible provider directory information enables third-party applications that help patients and clinicians find providers. The Provider directory API also improves the quality, accuracy, and timeliness of provider directory information.


For the first time, the rule also includes metric collection and measures for payers to report real world use of FHIR APIs, providing an essential feedback loop to improve these processes in future rule making.

CMS will use this information to enforce implementation and to improve these APIs in future rulemaking. Impacted payers must also publicly report certain prior authorization metrics annually, with compliance starting on 1 January 2026, and initial reports lodged by 31 March 2026.

A major step forward for interoperability

Firely sees these steps as significant progress towards a more efficient healthcare infrastructure. CMS-0057-F is not just about the implementation of rules and technical code: it involves fully embracing the concept and infrastructure of data sharing, reducing the burden on providers, and freeing up more time for quality healthcare. And its scope is much broader than the previous rule and, importantly, it not only prescribes what needs to be implemented, but also stimulates actual usage by specifying metrics to report.

CMS-0057-F also goes a long way towards reducing arbitrary critical care denials and unnecessary treatment delays – although more may need to be done, with the ultimate aim of real-time prior authorization. 

Even if – like most payers – you already have a FHIR solution to meet the requirements of the previous CMS rule, it may not be scalable or fit the new use cases. And if you have built your own solution, you may not want to devote the resources needed for revisiting the process.

How Firely can help

Keeping on top of every development is time-intensive and complicated, even for experts. The APIs taken together implement more than 10 IGs (including dependencies), some of which are still subject to development and testing at HL7 FHIR Connectathons in order to improve real world capabilities and workflow scenarios.

With the first deadline less than two years away, it’s time to start thinking seriously about how to implement the requirements and whether to rely on internal resources or call in the experts, with a future-proof FHIR solution as the optimum outcome. The industry also needs to be ready for refinements and changes driven by the metrics and feedback.

Fortunately, you can leave the heavy FHIR-lifting to Firely. As a 100% FHIR-dedicated company we have the solutions to help you achieve compliance and the experts you need to implement a future-proof FHIR roadmap. And with Firely Server there’s no need to divert resources to building your own solution: it’s a fully-compliant server right out of the box. Our FHIR experts will guide you through the right architecture and integration decisions, and support your team to learn all the ins and outs of FHIR and your FHIR set-up. Reach out to them now or test Firely Server yourself with our one-week free trial.  

Want to read more first? Our guide to FHIR-related regulations in the US will give you a full overview of the key Implementation Guides you need for CMS-0057-F.

Recommendations for you

Explore more topics

Post a comment

Your email address will not be published. Required fields are marked *