Advancing Interoperability and Improving the Prior Authorization Process Final Rule
On January 17, the Centers for Medicare & Medicaid Services (CMS) released a final rule that outlines policy changes to the prior authorization (PA) process for Medicare Advantage (MA) organizations, state Medicaid and Children鈥檚 Health Insurance Program (CHIP) Fee-for-Service (FFS) programs, Medicaid managed care plans, CHIP managed care entities, and Qualified Health Plan (QHP) insurers on the Federally Facilitated Exchanges (FFEs). Medicare FFS and commercial insurers are not covered by the policies finalized in this rule. The rule will alleviate the burden of prior authorization by streamlining the process for both patients and providers. Given the complexity of the changes and the required updates to the electronic processes outlined in the rule, the policies will not go into effect until January 1, 2026. The and provide additional information.
Exclusion of Drugs, pg. 25
As noted throughout the rule, none of the policies apply to the use of prior authorization for drugs, of any kind. However, CMS did request comment from stakeholders whether the agency should 鈥渃onsider policies to require impacted payers to include information about prior authorizations for drugs, when the payer covers drugs and on how future rulemaking to make information about prior authorizations for drugs available through these application programming interfaces (APIs) might interact with existing prior authorization requirements and standards.鈥 According to CMS, the agency received many comments on this issue, both for and against exclusion of drugs from the policies of this final rule; and given the overwhelming response to this issue, the agency noted that in the future, the agency will address making improvements to the PA process for drugs.
Patient Access to APIs, pg. 36
To provide improved coordinated care and to foster collaboration among patients, providers and payers, the rule finalized requirements for payers to include information about PA decisions and actions within the patient accessible API. Per the rule, an API is a 鈥渟et of commands, functions, protocols or tools published by one software developer that enables other software developers to create programs (applications/apps) that interact with each other without needing to know the internal workings of each other鈥檚 software while maintaining data security and patient privacy.鈥 Examples of non-healthcare APIs include Expedia and PayPal.
Previously finalized in 2020 rulemaking, payers are required to provide information in the patient access API that includes adjudicated claims, encounters with capitated providers, clinical data, including laboratory test results, no later than one business day after a claim has been adjudicated or clinical data received by the API. With the issuance of this final rule, PA requests and decision data have been added to the categories of required information for the Patient Access API. Per the rule, payers subject to these final rules will be required to make this data available for the duration of the authorization and at least one year after the last status change.
PA information shared via the Patient Access API must be made available no later than one business day after the payer receives a PA request and any status changes. The final rule provides examples of status changes that include: 鈥渁 payer receives a request, a payer approves or denies a pending prior authorization request, or a provider updates a denied prior authorization request with additional information for reconsideration.鈥 The rule notes that any meaningful change within the payer鈥檚 record of the PA request or the PA decision is considered a status change, and hence, will require an update to the information that should be made available to the patient.
Provider Access to API, pg.97
To improve care coordination and 鈥渟upport movement toward value-based payment models,鈥 payers subject to the regulations will be required to implement and maintain a Provider Access API. The Provider Access API allows for the sharing of patient data among in-network providers. The Provider Access API also allows the provider to initiate a request for access to patient data (immunizations, procedures, treatment plans, prior PA requests), before or during a patient encounter. The information must be available for sharing within one business day of the provider鈥檚 request. CMS also finalized that impacted payers will be required to provide education resources to beneficiaries about the Provider Access API, including information on opting out of the process and an explanation on how to do so.
Improving the PA Process, pg. 329
Requirement for Payers: Implement an API for PA, pg. 337
The PA process has been noted as a particular area of concern that contributes to physician burnout. As such, the final rule requires payers to facilitate the PA process through an application interface to submit PAs. The PA API must include:
鈥 A list of covered items and services (excluding drugs) that require PA and includes the documentation requirements when requesting PA for the listed services.
鈥 Functionality that allows the submission of the required PA documentation through the API.
鈥 Any response from the payer to the provider must include information that outlines the approval (if approved), how long the approval is valid, and if denied there must be a specific reason provided or a request for more information to support the PA.
Requirement for Payers to Provide Status of and Reason for Denial of PAs, pg. 371
The agency notes that improving timely and clear communication between payers and providers is key to streamlining PA and repeats throughout the rule the need for improved communication between providers and payers. One of the most oft stated reasons for frustration and increased administrative burden are PA denials. In attempt to fix the process, CMS has finalized the following provisions:
鈥 Payers will be required to provide the specific reason that a PA was denied, regardless of how the PA was requested.
鈥 PA decisions sent through the PA API that come from the payer to the provider must include if the payer approves the service and for how long, if the PA is denied and the reason, and if additional information is requested.
Note that the provisions listed above and others throughout the rule are not meant to supersede or replace existing federal or state requirements but are meant to reinforce said provisions.
Requirements for PA Decision Timeframes and Communications, pg. 392
To reduce wait times for decisions on PA submissions, the agency has finalized required timeframes for payers to send PA decisions to providers. The rule also defines the terms standard and expedited PAs as follows: standard is a non-expedited, non-urgent request and expedited is defined as an urgent request. The agency declined to further clarify the definitions in the final rule, even though commenters requested more precise definitions and were seeking clarity on this issue. The finalized timeframes for decisions regarding PA requests are:
鈥 Seven calendar days for a standard request.
鈥 Seventy-two hours for expedited request.
Public Reporting of PA Metrics, pg. 424
To increase transparency within the PA process, the agency has finalized the requirement that impacted payers must prepare reports on PA metrics and make those reports publicly available either on the payer鈥檚 website or other publicly available hyperlinks. The required data elements will be required in those reports:
鈥 A list of all items and services that require PA.
鈥 The percentage of standard PA requests that were approved, aggregated for all items and services.
鈥 The percentage of standard PA requests that were denied, aggregated for all items and services.
鈥 The percentage of standard PA requests that were approved after appeal, aggregated for all items and services.
鈥 The percentage of PA requests for which the timeframe for review was extended, and the request was approved, aggregated for all items and services.
鈥 The percentage of expedited PA requests that were approved, aggregated for all items and services.
鈥 The percentage of expedited PA requests that were denied, aggregated for all items and services.
鈥 The average and median time that elapsed between the submission of a request and a determination by the payer, plan, or issuer, for standard PAs, aggregated for all items and services.
鈥 The average and median time that elapsed between the submission of a request and a decision by the payer, plan, or issuer, for expedited PA, aggregated for all items and services.
Electronic PA for the Merit-based Incentive Payment System (MIPS) Promoting Interoperability Performance Category and the Medicare Promoting Interoperability Program, pg. 486
CMS finalized a new measure for MIPS eligible clinicians under the Promoting Interoperability performance category of MIPS, as well as for eligible hospitals and critical access hospitals (CAHs) under the Medicare Promoting Interoperability Program, related to electronic prior authorization. The new measure, titled 鈥淓lectronic Prior Authorization,鈥 will be included in the Health Information Exchange (HIE) objective for the MIPS Promoting Interoperability performance category and in the HIE objective for the Medicare Promoting Interoperability Program. The measure is a simple attestation measure (yes/no) instead of a numerator/denominator measure. Participants are required to report a yes response or claim an exclusion in order to satisfy the reporting requirements of the measure. The measure aims to address stakeholder concerns regarding low provider utilization of APIs established by payers for electronic PAs. CMS believes the new measure will enable the electronic exchange of health information to improve the quality of healthcare, such as promoting care coordination.
For the purposes of this new measure, CMS is finalizing that a PA request must be made electronically using the PA API with data from certified EHR technology to satisfy the measure. Additionally, MIPS eligible clinicians, eligible hospitals, and CAHs will be required to report the number of prior authorizations for medical items and services (excluding drugs) that are requested electronically from a PA API using data from CEHRT.
The new measures may be reported by MIPS eligible clinicians beginning with the CY 2027 performance period/CY 2029 MIPS payment year and for eligible hospitals and CAHs to report this measure beginning with the CY 2027 EHR reporting period.
Implementation Dates:
Policy/Process | Date of Implementation |
Patient Access API |
January 1, 2026 (payers must report API use metrics to CMS) January 1, 2027 (new data requirements become effective) |
Provider Access API | January 1, 2027. |
PA API | January 1, 2027. |
Improving the PA Process including: PA decision timeframes, provider notices including denial reason and public reporting of PA metrics. | January 1, 2026. |
MIPS Electronic PA Measure | CY 2027 performance year/CY 2029 payment year |
Advancing Interoperability and Improving the Prior Authorization Process Final Rule Comment Comparison Chart |
|
ASH Comment | CMS Final Rule Decision |
Supported CMS policy as proposed that would improve the prior authorization (PA) process including: 鈥 The prior authorization application program interface (API) must be populated with the list of covered items and services and includes documentation requirements when requesting PA. 鈥 Response from the payer must include information on the duration of the approval, and if denied, the specific reason for denial. |
The agency finalized the policies as proposed. |
Supported the use of public reporting of prior authorization metrics. | Impacted payers are required to report certain metrics about PA processes on its public website, on an annual basis. This includes the percent of PA requests approved, denied, and approved after appeal, and average time between submission and decision. |
Requested 72 hours response time for standard requests and 24 hours for expedited requested as opposed to CMS proposed 7 calendar days for a standard request and 72 hours for expedited requests. |
CMS finalized prior authorization timeframes as follows: 鈥 Standard request: 7 calendar days 鈥 Expedited request: 72 hours |
Supported the CMS proposal to require payers to include a specific reason for a prior authorization denial. | CMS finalized policy that will require payers to provide a specific, documented reason for the prior authorization denial. |
Urged CMS to not implement an electronic prior authorization MIPS measure under the Promoting Interoperability Performance Category. But if implemented that the measure be an attestation only measure. | CMS finalized the measure as attestation only. |
Urged the agency to apply the prior authorization policies and requirements to drugs administered by a physician. | The provisions of this rule only apply to medical items and services and do not apply to drugs. However, the agency may address drug-related issues in future rule making. |