The Centers for Medicare & Medicaid Services (CMS) recently published the CMS Advancing Interoperability and Improving Prior Authorization Processes Final Rule (“PA Final Rule”) in the Federal Register.
Effective April 8, 2024, with rolling implementation dates of certain provisions, the PA Final Rule imposes requirements on payers that will have wide-reaching impacts across other health care stakeholders—particularly providers and patients.
Through the PA Final Rule, CMS promotes policies (1) to streamline timing and transparency in the prior authorization process and (2) to use technology to update the way the requests and responses can be accessed and transmitted among stakeholders through the use of application programming interfaces (APIs).[1] The PA Final Rule imposes requirements on payers, including Medicare Advantage organizations, state Medicaid and Children’s Health Insurance Program (CHIP) agencies and CHIP managed care entities, Medicaid managed care plans, and Qualified Health Plan (QHP) issuers on the Federally-Facilitated Exchanges (FFEs) (collectively, “impacted payers” or “payers”). It is important to note that while these payers aren’t required under the PA Final Rule to include prior authorizations for drugs, they also aren’t restricted from including drug prior authorizations in these policies. To give stakeholders adequate time to comply, CMS has delayed compliance for the technical API updates and implementation requirements until January 1, 2027. However, the operational or process-related prior authorization policies are being finalized with compliance dates starting January 1, 2026.
Prior Authorization: Improving the Process
Through the policies that update prior authorization processes, CMS intends to shorten the length of time it can take to get prior authorization, provide more information to providers and patients, and make payers more accountable by requiring them to provide a specific reason when denying a prior authorization request. As of January 1, 2026, impacted payers will be required to provide a decision to standard prior authorization requests within seven calendar days, and expedited prior authorization decisions must be sent within 72 hours.[2] In addition, if a request for prior authorization is denied, impacted payers must provide the requesting provider with a specific reason for the denial. These requirements are intended to increase efficiency and facilitate transparent communication among payers, providers, and patients. The additional information that payers will be required to include in prior authorization denials will better enable providers to resubmit prior authorization requests in a more timely and efficient manner, if necessary. Since the requirements to implement or update the APIs to support these communications will not go into effect until 2027, impacted payers will still be allowed to send requests and responses in this initial phase of compliance in any manner—such as via portal, fax, email, mail, or phone—until the API requirements become effective.
The PA Final Rule will also require impacted payers to report certain metrics about their prior authorization program to CMS. Among other data, the reportable information includes the percent of prior authorization requests approved, denied, and approved after appeal; the average time between submission of a prior authorization request; and when a decision is communicated. CMS will make this information publicly available on CMS’s website.
Advancing Interoperability: The Technical Policy Changes
The PA Final Rule’s requirements for payers to use APIs are technical in nature and build off of another relatively recent rulemaking by CMS to provide an alternative standardized and streamlined way for payers and providers to send and receive electronic transactions.
In May 2020, CMS finalized the Interoperability and Patient Right of Access Rule (“2020 Rule”) to promote the access, use, and exchange of electronic health information by requiring—among other things—impacted payers to implement and maintain a Patient Access API, Provider Access API, and Payer-to-Payer API. Through those APIs, patients, providers, and payers could obtain access to the claims, patient encounters, and clinical information in a(n) enrollee’s/beneficiary’s record. The PA Final Rule represents CMS’s next steps to move the interoperability ball further down the court by adding certain information about prior authorization requests, responses, and decisions into those existing APIs. In addition, the PA Final Rule adds another API for impacted payers to design—the Prior Authorization API. In fact, to encourage the use and adoption of the International Fast Healthcare Interoperability Resources (FHIR®)-based APIs, CMS also announced in the PA Final Rule that it will exercise enforcement discretion if both the payer and provider are using the required APIs. If so, the National Standards Group that is responsible for Administrative Simplification enforcement will not enforce the Health Insurance Portability and Accountability Act of 1996 (HIPAA) requirements to translate electronic authorization transactions into the X12 278 standard transaction set.
API: What It Is and How It Works
As noted, an API is a set of rules or protocols that lets two or more software applications or systems exchange data and communicate with each other. APIs give an application owner a simple, secure way to make the data that the application collects and maintains available to the users of other systems within the same organizations or with third parties. APIs can be designed to provide end users “access only” to information and can also support the bi-directional exchange of information.
The everyday use of cell phones can provide an example of how APIs work. When an individual purchases a product on an e-commerce site, a third-party app may pop up for payment. APIs enable these functions behind the scenes to allow individuals to get the product and the e-commerce site to receive payment. While the information transferred through the API may be different depending on the type of payment method selected, the requests and responses all happen behind the scenes in the API. Once the transactions are complete, APIs enable the amount owed to be posted to the selected payment method and the individual to get their order confirmation.
APIs in health care work in much the same way: say you go to your doctor, and you need a prescription filled. Using a certified electronic health records technology (CEHRT), your doctor asks you where you want to pick up your medication. The doctor selects the data needed to submit a valid prescription and chooses the pharmacy. An API sends the request from the doctor’s CEHRT to the web server, and the API calls the receiving pharmacy. The web server sends a response to the API that the prescription was received, and you can pick up the prescription shortly thereafter.
FHIR APIs
FHIR APIs are specifically designed to transport health information. FHIR APIs hold promise for revolutionizing how we move data, and they were introduced by the Office of the National Coordinator for Health Information Technology to improve access and enable the sharing of electronic health information. When data and transactions are standardized, the data can be separated from the systems and applications where they reside and can be transmitted to another system, even though the systems are different (like in our e-commerce example). However, FHIR APIs will not solve all data-sharing issues. They do not address how health care data should persist, as patient data today is embedded In a myriad of systems and applications scattered across the health care ecosystem. People need their medical history accessible for life and even beyond.
Patient Access API
As the name implies, the Patient Access API only allows a patient to obtain access to certain information. As background, starting July 2021, the 2020 Rule required impacted payers to offer an API that could be used by third-party developers to design applications that would enable a plan enrollee to request access to their electronic protected health information maintained by their health plan. In the original requirements for the Patient Access API, impacted payers would publish the API’s rules and protocols on its public-facing website, which health information technology developers could use to create and offer an app for enrollees to download. After the enrollee provided the app with certain information and accepted the terms and privacy policy, the app would be activated to request the impacted payer to make available, through the Patient Access API, the individual’s claims, encounters, and clinical information they maintain with a date of service on or after January 1, 2016, to and/or through the app.
In addition to the claims, encounters, and clinical data originally required to be accessible in the United States Core Data for Interoperability (USCDI) format, the PA Final Rule expands and adds new data requirements beginning January 1, 2027, for impacted payers to include in prior authorization requests and decisions. The new data content that must be made available through the Patient Access API includes the status of the prior authorization request; whether the request was approved or denied; the date or circumstances the prior authorization ends; the items and services that are approved or denied; and, if the prior authorization request is denied, the specific reason for the denial.
Although some commenters urged CMS to require payers to disclose the specific coverage or clinical criteria upon which the payer based a prior authorization denial, CMS did not go that far. Instead, since payers consider the criteria used for making prior authorization decisions to be proprietary and the criteria involves complicated medical decision-making that may not be understood by patients, CMS did not require payers to disclose that information as part of the new data required to be disclosed in the Patient Access API. The information provided through the Patient Access API will not replace the notices that are required for Medicare Advantage, Medicaid, and CHIP managed care plans and QHPs under their respective utilization management rules.
The PA Final Rule requires impacted payers to report annual metrics about Patient Access API usage starting January 1, 2026, and to add information about prior authorizations to the data available through the Patient Access API by January 1, 2027.
Provider Access API
The Provider Access API is also an “access only” API that impacted payers must implement to share certain patient prior authorization information with certain in-network providers by January 1, 2027. Notably, the Provider Access API that impacted payers will be obligated to implement will only have to be available to share patient data with in-network providers with whom the patient has a treatment relationship. Payers will be required to develop an attribution process to associate patients with their providers to ensure that a payer only sends data to providers for patients with whom they have a treatment relationship. The data requirements for the Provider Access API are somewhat different from the data that is shared with patients through the Patient Access API, as impacted payers must make the enrollee’s/beneficiary’s claims and encounter data and specified prior authorization information available to providers. However, provider remittances and enrollee cost-sharing information are excluded from the Provider Access API. CMS will also require impacted payers to offer patients the opportunity to opt out of having their health information available and shared under the Provider Access API.
Payer-to-Payer API
Under the PA Final Rule, impacted payers must implement a Payer-to-Payer API that makes certain information, such as claims and encounter data, data classes, data elements in the USCDI, and information about certain prior authorizations, available by January 1, 2027. The Payer-to-Payer API was originally meant to allow enrollees/beneficiaries to bring their past plan data with them when they switch plans so the new plan and the enrollee/beneficiary can retain the information as they move from one payer to another payer. No later than one week after the start of coverage, a new payer must identify any previous payer or concurrent coverage and give the enrollee/beneficiary the opportunity to opt in to having the new payer request data from any previous or concurrent payer. If the patient opts in to this type of past plan data sharing, a previous payer will provide the data it maintains with dates of service within five years of the date of the request, and it must provide this data within one day of receiving the request. The new payer must incorporate the enrollee’s/beneficiary’s data into its record for that individual.
Where a patient has concurrent coverage with two or more payers, impacted payers are required to exchange patient data within one week of the start of coverage and at least quarterly thereafter. For concurrent payers, this information will continue to be necessary and ongoing. As required under the 2020 Rule, the Payer-to-Payer API must make available claims and encounter data, excluding provider remittances and enrollee cost-sharing information; all data classes and data elements must be in the USCDI format. The new data elements required by the PA Final Rule include information about prior authorizations, excluding requests for prior authorization for drugs and prior authorization requests that were denied.
Impacted payers will have to reach out to enrollees to raise awareness of the value of having access to health information and of allowing the historical health information that their health plan maintains to follow them to a new health plan if they move or have to change health plans. Impacted payers must provide enrollees information about the opportunity to opt in to this type of information sharing and how enrollees would make that choice.
Prior Authorization API: Bi-Directional API
Effective January 1, 2027, impacted payers that are not eligible for and do not apply for an extension, exemption, or exception[3] will be required to design and implement this new bi-directional (two-way exchange) API to facilitate the administrative prior authorization process. Both sending and receiving entities must have implemented a FHIR-standard API. The APIs must be built and maintained to be able to facilitate the following three steps: (1) identify when prior authorization is required, (2) identify payer-specific requirements that may apply, and (3) submit the prior authorization request and receive a response.
Impacted payers must implement and maintain a Prior Authorization API populated with a list of items and services that require prior authorization. The API must also identify the payer’s documentation requirements for all items and services that require a prior authorization request. While the API must support the creation and exchange of prior authorization requests from providers and responses from payers, the documentation does not have to be transmitted through the API.
Under the HIPAA Administrative Simplification Rules, the Secretary of the U.S. Department of Health and Human Services (HHS) was required to identify and adopt standards for the prior authorization transaction. The adopted transaction is HL7 X12-278.[4] When a covered entity sends an electronic transaction to another covered entity, it is required to use the adopted HIPAA standards. However, HHS will exercise enforcement discretion if the prior authorization transaction is sent via FHIR on both ends. The request does not need to be translated into the HL7 X12-278 transaction. This will help move to an only FHIR-based approach for exchanging administrative and financial information.
Other API-Related Obligations
The requirements in the PA Final Rule do not end there. Impacted payers must also provide plain language resources to enrollees/beneficiaries and to providers. Payers must raise awareness of the benefits of API data exchange with their providers and their ability to opt out of this data sharing, if they so choose. The provider education that payers are responsible for is about the process for requesting patient data and the payer’s attribution process. When implementing the Payer-to-Payer API, impacted payers must provide “plain language” materials to enrollees/beneficiaries about the benefits of Payer-to-Payer API data exchange and their ability to opt in or withdraw a previous opt-in decision.
A Silver Lining for Providers?
A new Merit-based Incentive Payment System (MIPS) measure will be available for eligible providers to report their implementation and use of the Prior Authorization API. The new MIPS measure will be called “Electronic Prior Authorization,” and it will be added to the Health Information Exchange objective for the MIPS Promoting Interoperability performance category and the Medicare Promoting Interoperability Program. MIPS-eligible clinicians will be able to report the Electronic Prior Authorization measure beginning with the calendar year (CY) 2027 performance period / CY 2029 MIPS payment year, with eligible hospitals and critical access hospitals (CAHs) beginning with the CY 2027 EHR reporting period. This will be an attestation measure for which the MIPS-eligible clinician, eligible hospital, or CAH report a “yes”/“no” response or claim an applicable exclusion.
To successfully report the Electronic Prior Authorization measure, MIPS-eligible clinicians must attest “yes” to requesting a prior authorization electronically via a Prior Authorization API using data from CEHRT for at least one medical item or service (excluding drugs) ordered during the CY 2027 performance period or (if applicable) report an exclusion. Eligible hospitals and CAHs must attest “yes” to requesting a prior authorization request electronically via a Prior Authorization API using data from CEHRT for at least one hospital discharge and medical item or service (excluding drugs) ordered during the 2027 EHR reporting period or (if applicable) report an exclusion.
ENDNOTES
[1] An API is a set of rules or protocols that let software applications communicate with each other to exchange data, features and functionality.
[2] This policy change for standard decisions does not include QHPs on the FFEs.
[3] For the Provider Access, Payer-to-Payer, and Prior Authorization APIs, Medicaid FFS programs can request a one-year extension or an exception when more than 90 percent of Medicaid/CHIP-eligible individuals are enrolled in managed care plans—the Patient Access API and the other policy provisions are not subject to the same extension or exceptions.
[4] See X12 and CAQH CORE Webinar Series: Introduction to the 278 Transaction, Standard & Operating Rules, a webinar describing the 278 transaction and operating rules. The 278 Healthcare Service Review transaction protocol was intended to eliminate the inefficiencies that plagued the prior authorization process by enabling providers to send electronic authorization requests to payers and by alerting providers when authorizations were approved or pending. However, the static fields in the 278 transaction aren’t flexible enough to account for the variation in payers’ prior authorization requirements. The current 278 transaction only allows providers to convey basic financial and demographic information and some limited clinical data, including diagnoses and requested services, but the 278 transaction cannot deliver the level of clinical detail that insurers require to make prior authorization determinations. With each payer having its own ever-changing list of items and services that require prior authorization, each payer uses different criteria to make its determination, and different clinical information is required to support requests. For that reason, the standard has gone virtually unused since it was incorporated into most practice management systems and EHRs beginning in the early 2000s, when it was adopted.
[View source.]
