CMS Advancing Interoperability and Improving Prior Authorization Processes Final Rule: A First Look for Payers and Providers

On January 17, 2024, The Centers for Medicare and Medicaid Services (CMS) released its Interoperability and Prior Authorization final rule (CMS-0057-F). This follows reviews of comments received from the public in 2023 on its preceding proposed rule released in 2022.

Impacted payers have not changed from the proposed rule and include:

• Medicare Advantage (MA) organizations
• State Medicaid agencies
• Medicaid Managed Care Plans
• Children’s Health Insurance Program (CHIP) Fee-for-Service (FFS) programs
• CHIP Managed Care entities
• Qualified Health Plan (QHP) issuers on the Federally Facilitated Exchanges (FFEs)

Also remaining consistent from the proposed rule into the final rule is the exclusion of drugs from the requirements of the rule. Drugs are defined as any drug covered by the impacted payer including drugs covered under medical benefits and any product that constitutes a Part D drug and is covered under the Medicare Part D benefit.

Compliance dates vary for some requirements in the CMS final rule. As the CMS final rule directly references requirements from the Office of the National Coordinator for Health IT (ONC) at 45 CFR 170, the U.S. Core Data for Interoperability (USCDI), beginning January 1, 2026, impacted payers will be required to use the expanded set of data in USCDI version 3. Impacted payers will also be required to report metrics on patient data requests made via the Patient Access API and improvements to prior authorization processes, both annually beginning January 1, 2026. API development and enhancement required in this CMS final rule are effective beginning January 1, 2027.  

API Requirements

Patient Access API

Payers will be required to continue to make available a Patient Access API while enhancing it to add information about a patient’s prior authorizations. Information to be added about prior authorization requests and decisions for items and services, excluding drugs, includes:

• Prior authorization status
• Date approved or denied
• Date or circumstance under which the prior authorization ends
• Items and services approved
• If denied, a specific reason why the request was denied
• Related structured administrative and clinical documentation submitted by a provider

These data are to be accessible via the Patient Access API no later than one business day after the payer receives the prior authorization request, updated no later than one business day after any status change, and remain accessible for at least one year after the last status change in the prior authorization. This enhancement to the Patient Access API is slated to be available from payers and app developers by January 1, 2027.

Provider Access API

A new Provider Access API will be required to include impacted payer claims and encounter data (without provider remittances and enrollee cost-sharing information), USCDI data, and prior authorization information (excluding that for drugs). The Provider Access API will be made available by impacted payers to in-network providers with whom the patient has a treatment relationship. Provisions of the Provider Access API also require impacted payers to maintain an attribution process to associate patients with in-network or enrolled providers with whom they have a treatment relationship. Before making information available via the Provider Access API, impacted payers are also required to have a process to allow patients to opt-out of having their data available to providers under these requirements. Impacted payers will also be required to provide plain language information to patients about the benefits of API data exchange with their providers and their rights to opt-out with instructions on how to do so as well as how to subsequently opt-in to this data exchange. Impacted payers are also required to provide on their website or through provider communications plain language information for providers requesting enrollee data via the Provider Access API, including how to use the payer’s attribution process to associate enrollees with their providers. The Provider Access API is to be made available to providers by January 1, 2027.

Payer-to-Payer Data Exchange API

In the Interoperability and Patient Access rule of 2020 (CMS-9115-F), CMS first required Payer-to-Payer Data Exchange to bring the benefits of a longitudinal patient record to patients supported by their payers. With payers at the center of this exchange, they can help the patient’s information go with them as they visit different providers and receive coverage from different payers over time.

In this final rule, CMS requires impacted payers to implement and maintain a FHIR^® API for Payer-to-Payer Data Exchange that makes available data with a date of service within five years of the exchange request. CMS is requiring the use of FHIR (release 4.0.1), the U.S. Core (version 3.1.1) FHIR implementation guide, and the FHIR Bulk Data Access (version 1.0.0) implementation guide while only recommending others (see table below). The data to be exchanged is consistent with the claims and encounter data, USCDI data, and prior authorization information exchanged in the Provider Access API. Impacted payers are also required to offer current enrollees the option to opt-in to Payer-to-Payer Data Exchange within one week of enrollment, a provision consistent with the proposed rule. Impacted payers must establish and maintain a process to identify the enrollee’s previous and concurrent payer(s) to facilitate the Payer-to-Payer API data exchange and fulfill requests for the exchange within one week of identifying the payers to supply data. For impacted payers of enrollees with concurrent payers, these payers will exchange data on at least a quarterly basis. Payers requesting to receive data in Payer-to-Payer Data Exchange must have their identity authenticated, attest that the patient is enrolled with the payer, and verify the patient has opted-in to the data exchange. Payers that are to supply data in the exchange must respond within one business day.  

Impacted payers will also be required to provide plain language educational resources in an easily accessible location on their public website about the benefits of Payer-to-Payer API data exchange and patients’ ability to opt-in or withdraw this permission with instructions on how to do so. The Payer-to-Payer Data Exchange API and its processes and resources are to be made available to patients by January 1, 2027.

Prior Authorization API

Leading significant new provisions in this final rule is the Prior Authorization API. Slightly changed from the proposed rule, this API is no longer called Prior Authorization Requirements, Documentation, and Decision or PARDD API. The Prior Authorizations API is required to contain the list of covered items and services requiring prior authorization, distinct from the requirement that impacted payers post a list publicly as specified elsewhere in this rule. Also, the Prior Authorization API identifies documentation requirements for prior authorization and supports prior authorization requests and responses. Responses to prior authorization requests are to communicate whether the prior authorization is approved (and the date or circumstance under which the authorization ends), denied (including a specific reason for the denial), or if additional information is required.

A significant development regarding prior authorizations is that the final rule requires the use of FHIR APIs for prior authorization transactions. HHS will use enforcement discretion for the Health Insurance Portability and Accountability Act of 1996 (HIPAA) required use of the X12 278 standard for prior authorization transactions. The implementation of FHIR alone for prior authorization submissions to comply with this new rule and not using X12 278 transactions will not be enforced against HIPAA Administrative Simplification. Impacted payers are required to use FHIR APIs for compliance and may optionally use X12 278 transactions with FHIR APIs. The use of enforcement discretion allows the new CMS requirements for FHIR APIs for prior authorization to become the new compliance requirement and for providers and payers to leverage newer technology (where X12 278 transactions may not be used) while allowing those organizations currently using X12 278 transactions a glidepath to implement FHIR API capabilities.

Standards and Recommended Implementation Guides

To accomplish the advances in interoperability and improvements to prior authorization, CMS has required some standards and recommended implementation guides.

To meet requirements for the API provisions, CMS recommends — and does not require — new versions of HL7 FHIR implementation guides for SMART App Launch, burden reduction (CRD, DTR, and PAS), CARIN for Blue Button^®, HL7 Payer Data Exchange (PDex), and U.S. Drug Formulary.

Measurements to Advance Interoperability and Improve Prior Authorization Processes

In addition to expanding the Patient Access APIs to include prior authorization information for patients, CMS is adding requirements to measure the uptake of the Patient Access API. Beginning in 2026, impacted payers must report aggregated, deidentified data at the contract level for the previous calendar year for the usage of the Patient Access API. Payers must report the total number of unique enrollees whose data are transferred via the Patient Access API to an app designated by the enrollee and the total number of unique enrollees whose data are transferred in this way more than once.

CMS is also introducing several requirements to improve prior authorizations. Impacted payers — excluding QHP issuers on the FFEs — will be required to send prior authorization decisions for items and services (excluding drugs) within 72 hours for expedited requests and seven calendar days for standard requests. This improvement aims to have impacted payers reduce their decision timeframes to half of current requirements.

Impacted payers, beginning January 1, 2026, must provide a specific reason for decisions denying prior authorizations, regardless of the method used to send the prior authorization request. These decisions may be communicated via portal, fax, email, mail, or phone. Again, as with all other policies in this rule, this provision does not apply to prior authorization decisions for drugs. Some existing requirements mandate that payers provide information about prior authorization denials to providers, patients, or both through notices, often in writing, and nothing in this final rule changes these existing requirements.

Impacted payers are also required to publicly report annually certain prior authorization metrics for the previous calendar year by posting them publicly on their website. These include:

• A list of all items and services (excluding drugs) that require prior authorization, in addition to listing of items and services (excluding drugs) in the Prior Authorization API
• Percentage of standard prior authorization requests that were approved, aggregated for all items and services
• Percentage of standard prior authorization requests that were denied, aggregated for all items and services
• Percentage of standard prior authorization requests that were approved after appeal, aggregated for all items and services
• Percentage of standard prior authorization requests for which the timeframe for review was extended and the request approved, aggregated for all items and services
• Percentage of expedited prior authorization requests that were approved, aggregated for all items and services
• Percentage of expedited prior authorization requests that were denied, aggregated for all items and services
• Average and median time elapsed between submission of a prior authorization request and a determination by the payer, for standard prior authorization, aggregated for all items and services
• Average and median time elapsed between submission of a prior authorization request and a determination by the payer, for expedited prior authorization, aggregated for all items and services

The compliance date for reporting on these metrics starts January 1, 2026, with the initial set of metrics to be reported by March 31, 2026.

To foster adoption of improvements to prior authorization, CMS has provider measures to complement payer metrics reporting. The provider measures described in the proposed rule are included in the final rule with slight modifications as “Electronic Prior Authorization” measures in the Health Information Exchange (HIE) objective for the MIPS Promoting Interoperability Program. Both measures require an attestation and, if not, claim an applicable exclusion. There are two provider measures, one for clinicians and another for hospitals.

Overall, the policies in the CMS Interoperability and Prior Authorization final rule are estimated to save $15 billion over 10 years.

The Latest in Interoperability

The CMS Interoperability and Prior Authorization rule is the latest in requirements at the federal level to foster a patient-centric health IT ecosystem where secure information sharing among patients, payers, providers, and health IT developers becomes the norm. This new rule complements the Contract Year 2024 Medicare Advantage and Part D final rule, which added continuity of care requirements and to reduce disruptions for patients. In December 2023, the ONC finalized the Health Data, Technology, and Interoperability (HTI-1) rule which advanced standards and incorporated protections and transparency for automation, artificial intelligence, and health equity. The new CMS rule builds upon the HTI-1 rule and previous CMS and ONC rules from 2020 that established Interoperability and Patient Access requirements for payers under CMS authority and Information Sharing and Health IT Certification under ONC authority.

The CMS Interoperability and Prior Authorization rule and other policies set the foundation for improving health information sharing that will support better health outcomes and enhance collaboration among providers and payers on behalf of patients. The description of the provisions here are for impacted payers to meet minimum requirements to comply with the regulation. Payers may opt to implement addiitional features than required, for example, to implement APIs for plans not covered by this rule (e.g., commercial plans) or offer features to similar stakeholders (e.g., offer provider access API to qualified providers that may not be in-network providers). ZeOmega is uniquely positioned to realize the benefits of interoperability in support of whole-person care with its HealthUnity suite of products, including Smart Authorization Gateway. Contact us for more information.

‍