On January 17, 2024, the Centers for Medicare & Medicaid Services (CMS) released the Advancing Interoperability and Improving Prior Authorization Processes for Medicare Advantage Organizations, Medicaid Managed Care Plans, State Medicaid Agencies final rule, which finalizes policies to streamline prior authorization processes for medical items and services and improve healthcare data electronic exchange standards and adds a new Medicare Promoting Interoperability Program measure for eligible hospitals and critical access hospitals (CAHs) and for Merit-based Incentive Payment System (MIPS) eligible clinicians. See the press release here. CMS has also provided a rule overview fact sheet.

This rule finalizes the following:

• Streamlined policies to make the prior authorization process more efficient,
• A requirement for payers to include prior authorization information in the patient access application programming interface (API),
• A requirement for payers to implement a provider access API,
• A new electronic prior authorization measure for MIPS-eligible clinicians under the Promoting Interoperability performance category of MIPS, as well as for eligible hospitals and CAHs under the Medicare Promoting Interoperability Program,
• A requirement for payers to exchange, with patient consent, certain patient data, prior authorization requests and decisions when a patient changes health plans, and
• Recommended but not required Implementation Guides (IGs) for implementing the APIs.

These finalized proposals do not address policies or standards for any drugs, including outpatient drugs covered under Medicare Part B, Part D or Medicaid. This final rule has not yet been published in the Federal Register.

BACKGROUND

The release of this final rule comes several years after CMS issued the May 2020 Interoperability and Patient Access final rule (Interoperability and Patient Access Final Rule).[1] The Interoperability and Patient Access Final Rule implemented the first phase of interoperability rulemaking by the Agency. Following on the heels of this rule, in December 2020, CMS issued the Interoperability and Prior Authorization proposed rule (2020 Proposed Rule),[2] which proposed requirements for state Medicaid fee-for-service (FFS) programs, state Children’s Health Insurance Program (CHIP) programs, Medicaid managed care plans, CHIP managed care entities, and qualified health plans (QHPs) relating to healthcare data exchange and prior authorization processes. While commenters generally supported those proposals, concerns were raised that, among other things, MA organizations were not covered by the 2020 Proposed Rule. Stakeholders also indicated that the comment period was too short to provide substantive analysis and feedback.

In consideration of these comments, CMS issued the December 2022 Interoperability and Prior Authorization proposed rule (2023 Proposed Rule).[3] In the final rule, CMS formally withdraws the 2020 Proposed Rule.

Provisions of this final rule will take effect in either 2026 or 2027. The Patient Access API and prior authorization decision timeframes and denial reason requirements will take effect in 2026, while the Provider Access API and Payer-to-Payer API requirements must be implemented by January 1, 2027. CMS believes these time frames to be appropriate to ensure sufficient time to train staff and build and update APIs and operational procedures. This rule also finalizes certain exemptions or extensions of proposed implementation deadlines for state Medicaid and CHIP programs.

CMS TAKES STEPS TO IMPROVE THE PRIOR AUTHORIZATION PROCESS

CMS finalizes policies to make the prior authorization process more efficient and transparent in order to improve the patient experience and reduce burden for providers. The prior authorization process requires that healthcare providers request approval from payers to provide certain items or services before they are rendered. This ensures that covered items and services are medically necessary and covered by the payer, however, the process has become burdensome for patients, providers, and payers.

Impacted payers will be required to build and maintain a Prior Authorization API (renamed from “Prior Authorization Requirements, Documentation and Decision API” in the proposed rule) to automate the process for providers to determine whether a prior authorization is required, addressing one of the major challenges providers currently face when trying to determine prior authorization requirements. The API will identify the payer’s documentation requirements to make them available within the provider’s workflow and support an automated compilation of information from the provider’s system. The API will also support automated compiling of necessary data elements to populate the HIPAA-compliant prior authorization transactions and allow payers to compile specific responses regarding the status of a prior authorization request, such as the reason for a denial. These changes will facilitate the exchange of prior authorization requests and decisions from provider’s electronic health records (EHRs) or practice management systems in compliance with adopted HIPAA standards.

CMS also finalizes its proposals requiring impacted payers to:

• Include a specific reason when they deny a prior authorization request regardless of the mechanism used to submit the request,
• Send prior authorization decisions within 72 hours for expedited (urgent) requests and seven calendar days for standard (non-urgent) requests,[4] and
• Publicly report certain prior authorization metrics by posting them on their website or through publicly accessible hyperlinks annually.

These requirements will take effect in 2026, with the first set of metrics required to be publicly reported by March 31, 2026.

CMS WILL ADD PRIOR AUTHORIZATION INFORMATION TO PATIENT ACCESS API

In the Interoperability and Patient Access Final Rule,[5] CMS finalized a requirement that impacted payers must implement a Health Level 7® (HL7®) Fast Healthcare Interoperability Resources (FHIR) ® Patient Access API.[6] Impacted payers include MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the Federally Facilitated Exchanges (FFEs).

These APIs were intended to enable enrollees to use health applications (health app) to access certain healthcare data. Specifically, at a minimum, the Interoperability and Patient Access Final Rule specified that these APIs must make available adjudicated claims (both provider remittances and enrollee cost-sharing), capitated provider encounters, and clinical data (including laboratory results with a date of service beginning January 1, 2016, or thereafter). CMS also required these payers to make data available via the Patient Access API within one business day after a claim is adjudicated or encounter or clinical data are received.

 CMS notes that the primary goal of the Patient Access API is to provide health information access to patients. However, the lack of a coordinated exchange of health information makes it challenging for patients to effectively access their health information, and prior authorization request and decision information is an important component of this dataset.

Therefore, CMS finalizes its proposal to require impacted payers to include prior authorization information in the data that must be made available to patients through the Patient Access API. This information includes:

• Prior authorization status,
• Date of the prior authorization approval or denial,
• Date or circumstance under which the authorization ends, and
• Items and services approved.

This information also includes “any materials that the provider sends to the payer to support a decision” [7]. However, in response to comments highlighting the administrative burden of requiring providers to submit unstructured documentation, such as scanned documents or PDFs, CMS modified its proposal to only require structured administrative and clinical documentation related to a prior authorization request. CMS also removed the requirement for payers to share the quantity of items or services used under a prior authorization. This removal was in response to comments pointing out that the “quantity used to date” information would come from payer claims data, which is unreliable until the claims have been processed, which can take months.

In cases of a prior authorization denial, impacted payers must provide specific rationale for this determination. Consistent with other provisions of the rule, this requirement would not apply to drugs.

In addition, CMS will require impacted payers to retain prior authorization information in the Patient Access API for as long as the authorization is active and for at least one year following the last status change. However, the Agency will not require payers to share a patient’s full prior authorization history in consideration of the fact that much of this information would lack clinical relevance.

These requirements will take effect in 2027, giving covered entities an additional year for implementation in comparison to the proposed rule. The compliance date will be January 1, 2027 for MA organizations and state Medicaid and CHIP FFS programs. Medicaid managed care plans and CHIP managed care entities must comply by the rating period beginning on or after January 1, 2027, and QHP issuers on the FFEs must comply for all plan years on or after this date.

CMS finalized its proposal to require impacted payers to provide this information within one business day after the receipt of a prior authorization request or another prior authorization status change. The Agency cited the one-year delay of implementation timelines from the proposed rule, and the removal of the requirement to include unstructured documentation, as reasons why this one-day timeframe would be reasonable.

These finalized policies do not directly relate to Medicare FFS, but CMS plans to implement these provisions for Medicare FFS in order to provide the same benefits for these beneficiaries and solicited feedback on how to achieve this in the proposed rule.

HIPAA Right of Access and Privacy Considerations

Under the Health Insurance Portability and Accountability Act (HIPAA) Privacy Rule, individuals generally have a right to inspect and obtain copies of their protected health information (PHI) for as long as the information is maintained by a covered entity in a designated record set.[8] Individuals also have the right to request access to this information in the form and manner requested. CMS aims to complement this right by making PHI available through a standards-based and interoperable Patent Access API. Upon an individual’s request, a covered entity must provide access to electronically maintained PHI in the form and manner requested, if readily producible in the requested form and format. If not readily producible, then CMS expects the covered entity to provide alternative, readable electronic access as agreed upon by the individual.

CMS notes the Agency has no direct regulatory authority over health apps. CMS reiterates that disagreement about the health app’s worthiness or concerns about what the application may do with requested PHI is not an acceptable reason to deny an individual’s request. The Interoperability and Patient Access Final Rule specified that impacted payers may only deny or discontinue a health app’s connection to their APIs if a determination is made, based on an objective and verifiable criteria-based process, that the application would pose a danger to the payer’s systems, such as increasing the risk of a cyber-attack.[9] CMS notes that other federal laws may apply to a health app, such as the Federal trade Commission Act,[10] even where HIPAA does not apply.

Patient Access API Metric Changes

CMS finalized its proposal to require impacted payers to report aggregated, de-identified annual information to CMS about Patient Access API use by patients. This information must include:[11]

• The total number of unique patients whose data are transferred via the Patient Access API to a health app designated by the patient, and
• The total number of unique patients whose data is transferred more than once via the Patient Access API to a health app designated by the patient.

CMS believes these requirements will help the Agency evaluate whether the Patient Access API is achieving its desired policy goals. CMS also finalized its proposal for data reporting level requirements. Specifically, CMS will require:[12]

• MA organizations to report data to CMS at the contract level,
• State Medicaid and CHIP FFS programs to report at the state level,
• Medicaid managed care plans to report at the state level,
• CHIP managed care entities to report at the state level, and
• QHP issuers on the FFEs to report at the issuer level.

While the proposed rule would have MA organizations reporting at the organization level, CMS agreed with commentors that contract level reporting would minimize payer burden, and accordingly, updated this requirement in the final rule.

Reporting requirements will go into effect on March 31, 2026. Going forward, all impacted payers must “report the previous calendar year’s metrics to CMS by March 31 following any year that they offered that type of plan.” [13]

CMS does not plan to publicly report these metrics at the issuer, plan, or state level. However, the Agency may reference or publish de-identified and aggregated data without the names of state agencies, plans, or issuers.

CMS WILL REQUIRE PAYERS TO IMPLEMENT PROVIDER ACCESS API

To improve care outcomes and facilitate a continued movement towards value-based care, CMS believes it is important for providers to have access to the same patient data that patients have through the Patient Access API, except for provider remittances and enrollee cost-sharing. CMS notes that the Patient Access API is a good first step, but more can be done to make patient data directly available to providers via a FHIR API. In the Interoperability and Patient Access Final Rule, CMS solicited feedback on the value and feasibility of establishing a FHIR API data exchange between payers and providers.

In this final rule, CMS finalizes its proposals to require impacted payers to implement and maintain a Provider Access API to facilitate this exchange of data for current patients when requested by a provider or facility. Generally, CMS finalizes data requirements and technical specifications consistent with Patient Access API policies as finalized in the Interoperability and Patient Access Final Rule and proposed in this rule[14]. Consistent with the Patient Access API, CMS will require impacted payers to provide requested data to the provider within one business day after the request is made. The most significant difference between the Patient Access API and Provider Access API is in how providers access patient data – not through a health app but through the provider’s electronic health record or practice management system. Also, unlike the Patient Access API, CMS will exclude provider remittances and enrollee cost-sharing information from the proposed Provider Access API.

Further, CMS finalizes its proposal to require impacted payers to maintain a process to verify patient-provider treatment relationship for the purposes of data sharing. CMS terms this method patient attribution.

Provider Access API provisions must be implemented by January 1, 2027, one year later than initially proposed, for MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans other than Non-Emergency Medical Transportation (NEMT) prepaid ambulatory health plans (PAHPs), CHIP managed care entities, and QHP issuers on the FFEs. Provisions do not apply to Medicare fee-for-service, but CMS is considering how proposals could apply to it.  These requirements will not apply to patients who are no longer enrolled with a payer. CMS acknowledges that there may be some instances in which a provider shares data with providers who are not enrolled or have a provider agreement with the payer for treatment purposes, but this is not required.

Patient Opt-Out of Data Sharing Considerations

CMS finalizes its proposal to require impacted payers to include a mechanism for patients to opt out of data sharing for all providers in the payer’s network through the Provider Access API. CMS does not outline specific methods for this opt out mechanism but expects payers to make the process available by smart phone device, website, other applications, and notes that for some patients, mail, fax, or telephonic methods may also be necessary.

Provider Access API Educational Resources

CMS finalizes its proposal to require payers to implement Provider Access API resources for both providers and patients. For patients, this information should include the benefits of Provider Access API requirements, opt out rights, and instructions for opting in and out of data exchange. Payers must provide this information in a non-technical, simple, and easy-to-understand manner, no later than one week after the start of coverage and annually thereafter. CMS will also require payers to post this information at all times on the payers’ public websites. However, CMS does not describe specific content or a format for these notices.

For providers, CMS will require payers to develop resources in “plain language” as opposed to in a “non-technical and easy-to-understand” format as proposed. Resources must explain how patient data can be requested from the Provider Access API, and how to use the payer’s attribution process to associate patents with the provider.

CMS FINALIZES ELECTRONIC PRIOR AUTHORIZATION MEASURE WITH STREAMLINED REPORTING REQUIREMENTS

In this final rule, CMS introduces a new measure, “Electronic Prior Authorization,” under the Health Information Exchange (HIE) objective for both the MIPS Promoting Interoperability performance category and the Medicare Promoting Interoperability Program. MIPS eligible clinicians are required to report this measure starting with the Calendar Year (CY) 2027 performance period/CY 2029 MIPS payment year, while eligible hospitals and Critical Access Hospitals (CAHs) will begin reporting during the CY 2027 EHR reporting period.

The Electronic Prior Authorization measure is structured as an attestation, where MIPS eligible clinicians, eligible hospitals, and CAHs report a yes/no response or claim an applicable exclusion, departing from the initially proposed numerator/denominator format.

To report the Electronic Prior Authorization measure:

• MIPS eligible clinicians must attest “yes” to requesting a prior authorization electronically via a Prior Authorization API, utilizing data from certified electronic health record technology (CEHRT) for at least one medical item or service (excluding drugs) ordered during the CY 2027 performance period, or report an exclusion if applicable.
• Eligible hospitals and CAHs must attest “yes” to requesting a prior authorization 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 report an exclusion if applicable.

These modifications aim to streamline the reporting process and reduce the burden on MIPS eligible clinicians, eligible hospitals, and CAHs, aligning with the broader goal of improving the electronic prior authorization workflow. For the CY 2027 performance period, the measure will not be assigned points, but is crucial for meeting minimum reporting requirements. Failure to report will result in not being considered a meaningful EHR user and failing the Medicare Promoting Interoperability Program or the MIPS Promoting Interoperability performance category. The importance of reporting a “Yes” during the specified performance or EHR reporting period is highlighted, as a “No” response would lead to significant consequences, including zero scores and payment adjustments. Eligible hospitals and CAHs failing to meet program requirements may face a downward payment adjustment unless granted a hardship exception.

CMS FINALIZES PAYER-TO-PAYER DATA EXCHANGE REQUIREMENTS WITH MODIFICATIONS

In the Interoperability and Patient Access Final Rule, CMS finalized that at a patient’s request, certain impacted payers must exchange and maintain a health record containing certain patient health information, beginning on January 1, 2022. CMS encouraged but did not require that payers use a FHIR API for this data exchange. Since the rule was finalized in May 2020, CMS has received feedback that the lack of technical specifications for the payer-to-payer data exchange requirements has created challenges for implementation including incompatible systems across the industry, poor data quality, operational challenges, and administrative burdens. As a result, CMS announced in December 2021 that it would not enforce the payer-to-payer data exchange requirements until further rules were finalized.^[15] This final rule rescinds the previous payer to payer data exchange requirements and seeks to address the challenges that resulted from previous rulemaking.

CMS finalizes its proposal to require that payers build a Payer-to-Payer API to facilitate the exchange of patient data including claims and encounter data (excluding cost information), and prior authorization requests and decisions.[16] Impacted payers will be required to request data from a patient’s previous payer no later than one week from the start of coverage or upon the patient’s request, with the patient’s permission. Payers will be required to exchange five years of patient data, not the entire patient health record as proposed. CMS will only be requiring this data exchange if the patient opts into data sharing. CMS also finalizes the proposal that if an enrollee has concurrent coverage with two or more payers, these payers must make the patient’s data available to the concurrent payers at least quarterly. These new API requirements will also apply to Medicaid and CHIP FFS programs in addition to Medicare Advantage plans.

Payers (excluding Medicaid managed care plans and CHIP managed care entities) will be required to provide information about the Payer-to-Payer API to patients in plain language, with information on the benefits of the data exchange, opt out rights, and instructions for opting in and out of data exchange. Information must also be posted in an easily accessible location on payers’ websites at all times on the payers’ public websites.

Provisions are effective January 2027, rather than 2026 as proposed.

CMS ENCOURAGES THE USE OF IMPLEMENTATION GUIDES

CMS strongly encourages the use of specific IGs when stakeholders are implementing the Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization APIs and the already-existing Provider Directory API. CMS states this will increase interoperability and reduce burden. The specific IGs CMS recommends for each API are included in Table H3 of the final rule.[17]

********

This Applied Policy® Summary was prepared by  April Gutmann with support from the Applied Policy team of health policy experts. If you have any questions or need more information, please contact her at AGutmann@appliedpolicy.com or at (202) 558-5272.

[1] Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Interoperability and Patient Access for MA Organization and Medicaid Managed Care Plans, State Medicaid Agencies, CHIP Agencies and CHIP Managed Care Entities, Issuers of Qualified Health Plans on the Federally-Facilitated Exchanges, and Health Care Providers, 85 FR 25510.

[2] 85 FR 82586.

[3] 87 FR 76238.

[4] This would not apply to Qualified Health Plan (QHP) issuers on the Federally Facilitated Exchanges.

[5] 85 FR 25510.

[6] An API includes a set of commands, functions, tools, or protocols published by a software developer to permit other developers to create applications that can interact with other software, while maintaining data security and patient privacy.

[7] See page 57 of the final rule.

[8] Health Insurance Portability and Accountability Act of 1996, Pub. L. 104–19.

[9] See 45 CFR § 164.524.

[10] See 15 U.S.C. 45(a).

[11] 87 FR 76249.

[12] Ibid.

[13] See page 97 of the Final Rule.

[14] Table H3 on pages 672-673 of the unpublished final rule outlines the list of standards and implementation specifications for each API.

[15] 86 FR 70412.

[16] Table H3 on pages 672-673 of the unpublished final rule outlines the list of standards and implementation specifications for each API.

[17] Page 672 of the unpublished rule.