Two and a half years ago I wrote my first blog at Redox. My debut focused on how the CMS proposed Interoperability and Prior Authorization rule would dramatically improve prior authorization processes with electronic processing via APIs.
ICYMI: It didn’t. That rule was never finalized.
But: There is still hope. CMS just finalized the CMS Interoperability and Prior Authorization Final Rule CMS-0057-F, or what many have called the “Interop 3” rule.
I provided an overview of the proposed Interop 3 rule last February. Today I will focus on some of the major changes and clarifications associated with the final rule.
CMS says no to drugs
The final rule covers prior authorization for medical treatment and services only. There was a call for prescription drug prior authorization to be included in this rule, but for now, CMS has not included it. They have indicated they will explore it in the future.
More time to comply with API requirements
The finalized rule requires that both payers and providers update or implement a variety of HL7® Fast Healthcare Interoperability Resources (FHIR®) APIs. Payers must update patient APIs and implement: Provider, Payer-to-Payer, and Prior Authorization APIs. While most of the rule focuses on payer requirements, it also requires that Merit-Based Incentive Payment System (MIPS) “Promoting Interoperability Program” eligible providers report on their use of Prior Authorization APIs in a new “Electronic Prior Authorization” measure. This ensures providers also implement and adopt and use Prior Authorization APIs, which is critical for the rule to make a true impact. The deadlines for these updates and implementations have moved until “at least” January 1, 2027.
The compliance date remains January 1, 2026, for other portions of the rule, including prior authorization decision timeframes, reasons for denial, and metrics reporting.
Payer-to-payer data limits
Requiring payers to send (and receive) all data, for all time was less than appetizing to an industry already overwhelmed with data. Accordingly, the final rule limits payer-to-payer data sharing requirements to information related to claims, encounters, United States Core Data for Interoperability (USCDI) elements, and prior authorizations over the last five years.
Prior auth compliance will come a little easier
The original Interop 3 rule did not propose the modification of existing HIPAA rules in any way, which would have required payers to implement Prior Authorization APIs capable of sending and receiving both HL7® FHIR® and X12® standards. Not surprisingly, commenters were not fans of the complexity of this proposal. The final rule states that HHS will not enforce the use of the X12 standard for HIPAA compliance with electronic prior authorization if a FHIR API is used. In other words, Prior Authorization APIs will be compliant if they use FHIR and X12, or purely FHIR. Of interest, this would apply to any HIPAA-covered entity conducting prior authorization—so payers that are not implicated in this rule (e.g., commercial plans, worker’s compensation, etc.) can also opt to use a FHIR-only exchange for prior authorization going forward.
During a WEDI webinar last week, Alex Mugge, CMS Chief Health Informatics Officer, shared a table that covers the Interoperability standards that are required by each of the APIs.
She also shared the Da Vinci Project Implementation Guides that are recommended for each API. She made a point to emphasize that while these are not required, they are strongly encouraged— sending very strong vibes that future rule-making will require them.
No final rule on attachments
In our last blog, we discussed the “Attachments” proposed rule, which accompanied the Interop 3 proposal. At this time, it does not appear the rule is being finalized. During the WEDI webinar, Mugge stated that “CMS and HHS have not formally declared an attachment standard, so there is still a lot to unpack….Until further information on requirements for attachments [is available], it will be up to the implementer to decide which [standard] they want to use.”
Navigating a sea of APIs
With hundreds of payers and thousands of providers, there are reasons to be concerned about how they will find each other’s APIs to be compliant and get value from the new requirements. CMS issued an RFI in 2022, and based on Mugge’s WEDI update, they are still pursuing it—exploring how CMS can support providers and payers in connecting to the necessary digital endpoints.
The Redox take
After years of limbo, it is a relief that a rule requiring electronic prior authorization has finally made it to the finish line. Prior authorization APIs alongside existing patient and new provider and payer-to-payer APIs will go a long way to ensure patients, providers, and payers can be on the same page. It is imperfect, will take a long time, and a lot still needs to be refined in the future, but it is a substantial step forward.
We are ready to support payers and providers to be compliant with this law now and in the future. Although Da Vinci guides can push us toward interoperability, the reality is that there is still no guarantee that two implementers will be capable of interoperating out of the box. Redox’s flexible integration platform can smooth the inevitable differences no matter how large (e.g. X12 to FHIR) or small (e.g. moving properties around). We have in-depth experience utilizing Da Vinci implementation guides for prior authorization and beyond.
Additionally, while prior authorization APIs have received the most attention, we are particularly jazzed about the new Provider API requirements as these APIs will unlock more timely information and transparency at the point of care to further reduce clinician burden and improve care.
Check out our Prior Authorization Case Study to learn more about our work and capabilities. If you’d like to learn more about our solutions. Let’s chat.