Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Advancing Interoperability and Improving Prior Authorization Processes for Medicare Advantage Organizations, Medicaid Managed Care Plans, State Medicaid Agencies, Children's Health Insurance Program (CHIP) Agencies and CHIP Managed Care Entities, Issuers of Qualified Health Plans on the Federally-Facilitated Exchanges, Merit-Based Incentive Payment System (MIPS) Eligible Clinicians, and Eligible Hospitals and Critical Access Hospitals in the Medicare Promoting Interoperability Program

AGENCY:

Centers for Medicare & Medicaid Services (CMS), Department of Health and Human Services (HHS).

ACTION:

Final rule.

SUMMARY:

This final rule will improve the electronic exchange of health care data and streamline processes related to prior authorization through new requirements for Medicare Advantage (MA) organizations, state Medicaid fee-for-service (FFS) programs, state Children's Health Insurance Program (CHIP) FFS programs, Medicaid managed care plans, CHIP managed care entities, and Qualified Health Plan (QHP) issuers on the Federally-facilitated Exchanges (FFEs). This final rule will also add new measures for eligible hospitals and critical access hospitals (CAHs) to report under the Medicare Promoting Interoperability Program and for MIPS eligible clinicians to report under the Promoting Interoperability performance category of the Merit-based Incentive Payment System (MIPS). These policies, taken together, will reduce overall payer and provider burden and improve patient access to health information while continuing CMS's drive toward interoperability in the health care market.

DATES:

These regulations are effective on April 8, 2024.

FOR FURTHER INFORMATION CONTACT:

Alexandra Mugge, (410) 786–4457, for general questions related to any of the policies in this final rule, or questions related to CMS interoperability initiatives.

Lorraine Doo, (443) 615–1309, for issues related to the prior authorization process policies, or the Prior Authorization Application Programming Interface (API).

Shanna Hartman, (410) 786–0092, for issues related to the Payer-to-Payer API, the Electronic Prior Authorization measures for the MIPS Promoting Interoperability performance category and Medicare Promoting Interoperability Program, or any of the API standards and implementation guides (IGs) included in this final rule.

David Koppel, (303) 844–2883, for issues related to the data exchange policies generally, Patient Access API policies, or patient privacy.

Scott Weinberg, (410) 786–6017, for issues related to the Provider Access API policies.

Amy Gentile, (410) 786–3499, for issues related to Medicaid managed care.

Kirsten Jensen, (410) 786–8146, for issues related to Medicaid FFS.

Joshua Bougie, (410) 786–8117, for issues related to CHIP.

Natalie Albright, (410) 786–1671, for issues related to MA organizations.

Carolyn Kraemer, (301) 492–4197, for issues related to QHPs.

Elizabeth Holland, (410) 786–1309, for issues related to MIPS and the Medicare Promoting Interoperability Program.

Russell Hendel, (410) 786–0329, for issues related to the Collection of Information and Regulatory Impact Analysis.

SUPPLEMENTARY INFORMATION:

Table of Contents

I. Background and Summary of Provisions

A. Purpose and Background

B. Summary of Major Provisions

C. Specific Terms Used in This Final Rule

D. Global Comments

II. Provisions of the Proposed Rule

A. Patient Access API

B. Provider Access API

C. Payer-to-Payer API

D. Prior Authorization API and Improving Prior Authorization Processes

E. Extensions, Exemptions, and Exceptions; Federal Matching Funds for Medicaid and CHIP

F. Electronic Prior Authorization Measures for the Merit-Based Incentive Payment System (MIPS) Promoting Interoperability Performance Category and the Medicare Promoting Interoperability Program

G. Interoperability Standards for APIs

III. Collection of Information Requirements

IV. Regulatory Impact Analysis

I. Background, Summary of Provisions, and Terms

A. Purpose and Background

In the December 13, 2022 Federal Register (87 FR 76238), we issued the “Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Advancing Interoperability and Improving Prior Authorization Processes for Medicare Advantage Organizations, Medicaid Managed Care Plans, State Medicaid Agencies, Children's Health Insurance Program (CHIP) Agencies and CHIP Managed Care Entities, Issuers of Qualified Health Plans on the Federally-Facilitated Exchanges, Merit-Based Incentive Payment System (MIPS) Eligible Clinicians, and Eligible Hospitals and Critical Access Hospitals in the Medicare Promoting Interoperability Program” proposed rule (CMS Interoperability and Prior Authorization proposed rule), in which we proposed new requirements for MA, state Medicaid FFS programs, state CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs (collectively “impacted payers”) to improve the electronic exchange of health care information and streamline prior authorization for medical items and services. The proposed rule also included proposals for new electronic prior authorization measures for MIPS eligible clinicians (as defined at 42 CFR 414.1305) under the Promoting Interoperability performance category of the MIPS, as well as for eligible hospitals and CAHs under the Medicare Promoting Interoperability Program.

This rule also builds upon the policies established in the “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” final rule (85 FR 25510, May 1, 2020) (hereinafter referred to as the “CMS Interoperability and Patient Access final rule”).

We received nearly 900 timely pieces of correspondence containing comments on the CMS Interoperability and Prior Authorization proposed rule. Some public comments were outside of the scope of the proposed rule and those out-of-scope comments are not addressed in this final rule. Summaries of the public comments that are within the scope of the proposed rule and our responses to those public comments are addressed in the various sections of this final rule under the appropriate heading. However, in this section we address certain comments that pertain across policies or to the rule overall.

In this final rule, we are finalizing our proposals with modifications in response to commenter feedback. Taken together, these final policies will help to increase health information data exchange, streamline prior authorization process policies, and help to address a significant source of provider burden and burnout to ultimately improve patients' access to timely care.

B. Summary of Major Provisions

In the CMS Interoperability and Patient Access final rule, we required impacted payers (MA organizations, state Medicaid FFS programs, state CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs) to implement and maintain a standards-based Patient Access API. The Patient Access API must allow patients, through the health apps of their choice, to easily access their claims and encounter information as well as clinical data, including laboratory results, provider remittances, and patient cost-sharing pertaining to such claims, if maintained by the impacted payer (85 FR 25558). In this final rule, we are finalizing our proposal to require that impacted payers include information about certain prior authorizations in the data that are available through the Patient Access API. For those changes to the Patient Access API, we are finalizing compliance dates in 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs). In addition, starting January 1, 2026, we are requiring impacted payers to annually report to CMS certain metrics about patient data requests made via the Patient Access API. We are also finalizing our proposal to directly reference the content standard at 45 CFR 170.213, so that the data content requirement is automatically updated as HHS's Office of the National Coordinator for Health Information Technology (ONC) adopts new versions. As of this final rule's publication, the content standards adopted at 45 CFR 170.213 are USCDI v1, which will expire on January 1, 2026, and USCDI v3.

To improve coordination of care across the care continuum and movement toward value-based care, we are finalizing our proposal to require impacted payers to implement and maintain a Provider Access API that is consistent with the technical standards finalized in the CMS Interoperability and Patient Access final rule (85 FR 25558), including the Health Level Seven (HL7®) International Fast Healthcare Interoperability Resources (FHIR®) Release 4.0.1 standard. Providers can use that API to access current patient data from payers, including adjudicated claims and encounter data (excluding provider remittances and patient cost-sharing information), all data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI), and prior authorization information. For the Provider Access API policy, we are finalizing compliance dates in 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027 for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027 for QHP issuers on the FFEs).

We are finalizing, with modifications, our proposal to require impacted payers to implement and maintain a Payer-to-Payer API to exchange patient data when a patient moves between payers to ensure continued access to their health data and support continuity of care between payers. Specifically, the payer to payer data exchange will include adjudicated claims and encounter data (excluding provider remittances and patient cost-sharing information), all data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI), and certain information about the patient's prior authorizations. Impacted payers will be required to request data from a patient's previous payer, with the patient's permission, no later than 1 week from the start of coverage or at the patient's request. Impacted payers will then be required to integrate any data they receive in response to that request into the patient's record, which could facilitate care continuity as patients move between payers. We are finalizing a policy that payers will be required to exchange five years of patient data, as opposed to the entire patient health record. Five years of data are sufficient to support care continuity and continuation of prior authorizations as necessary, as well as maintaining patient access to their most recent data without significant burden to payers. In addition, if a patient has two or more concurrent impacted payers, the impacted payers will be required to exchange the patient's data at least quarterly, to ensure that all impacted payers have a more complete patient record. For the Payer-to-Payer API policy, we are finalizing compliance dates in 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs).

To improve the patient experience and access to care, we are also finalizing several new requirements for prior authorization processes that will reduce burden on patients, providers, and payers. To streamline the prior authorization process, we are requiring impacted payers to implement and maintain a Prior Authorization API. In the proposed rule, we used the term “Prior Authorization Requirements, Documentation, and Decision API (PARDD API).” For simplicity, we are finalizing the name of that API as simply the “Prior Authorization API.” This name change alone does not indicate any changes to the requirements or standards that we proposed.

Providers can use the Prior Authorization API to determine whether a specific payer requires prior authorization for a certain item or service, thereby easing one of the major points of administrative burden in the existing prior authorization process. The Prior Authorization API will also allow providers to query the payer's prior authorization documentation requirements directly from the provider's system, which could facilitate the automated compilation of necessary information to submit a prior authorization request. For the Prior Authorization API policy, we are finalizing compliance dates in 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs).

We are also finalizing our proposals to establish certain requirements for the prior authorization process, regardless of whether the payer receives the prior authorization request through the Prior Authorization API. We are requiring that impacted payers send notices to providers when they make a prior authorization decision, including a specific reason for denial when they deny a prior authorization request. We are also finalizing our proposal to require impacted payers, except for QHP issuers on the FFEs, to respond to prior authorization requests within certain timeframes. Finally, we are requiring all impacted payers to publicly report certain metrics about their prior authorization processes, which will enhance transparency. For these prior authorization process policies, we are finalizing compliance dates in 2026 (by January 1, 2026, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2026, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2026, for QHP issuers on the FFEs).

We are finalizing, with modifications, our proposal for new electronic prior authorization measures for MIPS eligible clinicians under the MIPS Promoting Interoperability performance category and for eligible hospitals and CAHs under the Medicare Promoting Interoperability Program. To promote Prior Authorization API adoption, implementation, and use among MIPS eligible clinicians, eligible hospitals, and CAHs, we are adding new measures titled “Electronic Prior Authorization” under the Health Information Exchange (HIE) objective in the MIPS Promoting Interoperability performance category and the Medicare Promoting Interoperability Program, beginning with the calendar year (CY) 2027 performance period/2029 MIPS payment year and CY 2027 electronic health record (EHR) reporting period, respectively. As detailed in section II.F. of this final rule, we are finalizing a modification to our proposal for the Electronic Prior Authorization measure that will require a MIPS eligible clinician, eligible hospital, or CAH to report a yes/no attestation or (if applicable) an exclusion, rather than a numerator and denominator.

We are additionally finalizing our proposals, with modifications, for more specificity as to which of the required standards at 45 CFR 170.215 are applicable to each API. Impacted payers will only be required to use the specifications that CMS has identified as necessary for the Patient Access, Provider Access, Provider Directory, Payer-to-Payer, and Prior Authorization APIs. Since the publication of the CMS Interoperability and Prior Authorization proposed rule, ONC has published the Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing (HTI–1) final rule (January 9, 2024; 89 FR 1192) (hereinafter referred to as the HTI–1 final rule), which reorganized the structure of 45 CFR 170.215 to delineate the purpose and scope more clearly for each type of standard or implementation specification. The standards we are finalizing in this rule, including updated citations are as follows:

• Health Level Seven (HL7®) Fast Healthcare Interoperability Resources (FHIR®) Release 4.0.1 at 45 CFR 170.215(a)(1) (HL7 FHIR).
• HL7® FHIR® US Core Implementation Guide (IG) Standard for Trial Use (STU) 3.1.1, which expires on January 1, 2026, at 45 CFR 170.215(b)(1)(i) (US Core IG).
• HL7® SMART Application Launch Framework IG Release 1.0.0 which expires on January 1, 2026, at 45 CFR 170.215(c)(1) (SMART App Launch IG).
• FHIR® Bulk Data Access (Flat FHIR) IG v1.0.0: STU 1 at 45 CFR 170.215(d)(1) (Bulk Data Access IG).
• OpenID Connect Core 1.0, incorporating errata set 1 at 45 CFR 170.215(e)(1) (OpenID Connect Core).

We refer readers to the HTI–1 final rule for further information (89 FR 1192). More detail about the required standards can be found in section II.G. and Table H3. We are also strongly recommending that payers use specific IGs to supplement the required standards at 45 CFR 170.215. Additionally, we are finalizing our proposal to allow payers to voluntarily use updated versions of the standards, specifications, or IGs for each of these APIs prior to the adoption of updated versions in regulation, subject to certain conditions and provided the updated standard does not disrupt an end user's ability to access the data available through the API. We are also finalizing terminology changes related to the Patient Access API (in section II.A.2.d. of this final rule). These policies will take effect on the effective date of the final rule.

We are finalizing, as proposed, some clarifications to existing Medicaid beneficiary notice and fair hearing regulations that apply to Medicaid prior authorization decisions. Because these are clarifications and improvements to existing regulations, as we proposed, Medicaid agencies will have to comply with these policies upon the effective date of a final rule.

In our proposed rule, we proposed compliance dates in 2026 (by January 1, 2026, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2026, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2026, for QHP issuers on the FFEs), for all policies that require API development and enhancement. Based on commenter feedback and as noted previously, we are delaying the compliance dates in this final rule for the provisions that require API development and enhancement in 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs). Throughout this rule, we generally refer to these compliance dates as “in 2027” for the various payers.

We believe this approximately 3-year timeline to recruit and train staff, update, or build the APIs, and update operational procedures will be sufficient to implement these policies, based on comments and public information from some payers and providers regarding similar initiatives already in progress. In addition to the 3-year implementation timeframe, we are finalizing our proposal to give state Medicaid and CHIP FFS programs an opportunity to seek an extension to the compliance dates, or an exemption from meeting certain requirements, in certain circumstances. Additionally, we are finalizing our proposal to provide an exceptions process for QHP issuers on the FFEs. We believe the approximately 3-year timeframe for implementation in the final rule will offer sufficient time for state Medicaid and CHIP FFS programs and QHP issuers on the FFEs to determine whether they can timely satisfy the API development and enhancement requirements in this final rule and to prepare the necessary documentation to request an extension, exemption, or exception, as applicable.

Executive Order 13985 of January 20, 2021, entitled “Advancing Racial Equity and Support for Underserved Communities Through the Federal Government,” set administration policy that the “Federal Government should pursue a comprehensive approach to advancing equity for all.” CMS is committed to pursuing a comprehensive approach to advancing health equity for all, and the policies in this final rule are aligned with that Executive order because they represent efforts to mitigate existing inefficiencies in policies, processes, and technology that affect many patient populations. Some patient populations are more negatively affected by existing processes than others and should realize greater benefits through the improvements these policies will provide. One of the main components of this final rule is our continued support for the individual's ability to select an app of their choice when accessing their health information. We want to ensure that members of all communities can access their health information and benefit from this technology. However, we are interested in the best ways to ensure that apps are available and accessible for individuals with disabilities, individuals with limited English proficiency, individuals with low literacy or low health literacy, and individuals with geographic, economic, or other social risk factors that may create barriers to accessing or using technology and apps.

Our goal is to ensure that these proposed policies do not exacerbate current disparities or create unintended inequities that leave some communities or populations unable to benefit from this information sharing. Further, we seek to ensure that patient privacy considerations are built into the implementation of these proposed policies by using secure technologies, such as Open Authorization/Open ID (OAuth) 2.0 and OpenID Connect Core for authentication, as previously discussed in the CMS Interoperability and Patient Access final rule (85 FR 25520). While we proposed policies that we believed would address some health care inequities, we solicited comments about how to ensure that individuals from all communities and populations can actively benefit from our health care interoperability proposals.

C. Specific Terms Used in This Final Rule

Our policies emphasize improving health information exchange and facilitating appropriate and necessary patient, provider, and payer access to information in health records. We also include several policies intended to reduce payer, provider, and patient burden by improving prior authorization processes and helping patients remain at the center of their care. Prior authorization refers to the process through which a health care provider, such as an individual clinician, acute care hospital, ambulatory surgical center, or clinic, obtains approval from a payer before providing care. Payers establish prior authorization requirements to help control costs and ensure payment accuracy by verifying that an item or service is medically necessary, meets coverage criteria, and, for some payers, is consistent with standards of care before the item or service is provided. A prior authorization is made up of two parts—a request from a provider and a decision by a payer. We refer to the provider's workflow and associated information and documentation as the “prior authorization request” and the payer's processes and associated information and documentation as the “prior authorization decision.”

For purposes of this final rule, references to QHP issuers on the FFEs exclude issuers offering only stand-alone dental plans (SADPs). Likewise, we are also excluding QHP issuers offering only QHPs in the Federally-facilitated Small Business Health Options Program Exchanges (FF–SHOPs) from the provisions of this final rule, as we believe that the standards could be overly burdensome for both SADP and Small Business Health Options Program (SHOP) issuers. We are finalizing an exceptions process for QHP issuers on the FFEs from the API requirements; the grant of an exception is conditioned upon our annual approval of a narrative justification, as further detailed in section II.E. of this final rule. For the purposes of this final rule, FFEs include FFEs in states that perform plan management functions. State-based Exchanges on the Federal Platform (SBE–FPs) are not FFEs, even though patients in those states enroll in coverage through HealthCare.gov. Hence, QHP issuers in SBE–FPs will not be subject to the requirements in this final rule. We encourage SBE–FPs and State-based Exchanges operating their own platforms (SBEs) to consider adopting similar requirements for QHPs on their Exchanges.

Throughout this final rule, we use terms such as “patient,” “consumer,” “beneficiary,” “enrollee,” and “individual.” Every reader of this final rule is a patient who has received or will receive, medical care at some point in their life. In this final rule, we use the term “patient” as an inclusive term. We understand that, historically, we have referred in our regulations to “patients” using the other terms previously noted. However, for the policies herein, we will use additional, specific terms applicable to individuals covered under the health care programs that we administer and regulate. We also note that when we discuss patients, the term includes, where applicable, a patient's personal representative. For example, a patient or their personal representative may opt into or out of certain types of information exchange under the policies in this final rule. But when we refer to a patient's medical needs or health records, we do not include the medical needs or health records of the patient's personal representative. Per the Standards for Privacy of Individually Identifiable Health Information (Health Insurance Portability and Accountability Act (HIPAA) Privacy Rule) issued under HIPAA (Pub. L. 104–191, enacted on August 21, 1996), as modified, at 45 CFR 164.502(g), and related guidance, a “personal representative” is a person authorized under state or other applicable law to act on behalf of an individual in making health care-related decisions (such as a parent, guardian, or person with a medical power of attorney). Under the HIPAA Privacy Rule (45 CFR part 164, subpart E), the individual's personal representative generally may exercise the right to access the individual's protected health information (PHI). For many processes described in this final rule, a patient's personal representative could act on a patient's behalf, as permitted by the HIPAA Privacy Rule and other applicable laws.

We also use terms such as “payer,” “plan,” and “issuer” in this final rule. Certain portions of this final rule are applicable to MA organizations, state Medicaid FFS programs, state CHIP FFS programs, Medicaid managed care plans (managed care organizations (MCOs), prepaid inpatient health plans (PIHPs), and prepaid ambulatory health plans (PAHPs)), CHIP managed care entities (MCOs, PIHPs, and PAHPs), and QHP issuers on the FFEs. Where certain provisions may not apply to specific plan or provider types, we have identified them separately from the aforementioned categories. We use the term “payer” in the preamble of this final rule as an inclusive term for all these entities and programs and, in the case of plans, plan types, but we also use specific terms as applicable in various sections of this final rule.

We use the term “policies that require API enhancement or development” to describe the requirements that involve technical development work to either establish a new API, such as the Provider Access or Payer-to-Payer APIs, or to enhance the functionality of an existing API, such as the addition of prior authorization data to the Patient Access API. We are finalizing these policies with compliance dates in 2027. As discussed throughout this rule, we are finalizing a modification to our proposal for certain requirements by establishing compliance dates in 2027, rather than in 2026, as we proposed. Specifically, those policies include adding prior authorization information to the Patient Access API, implementing the Provider Access API (including a process for patients to opt out and disseminating educational resources to patients and providers), implementing the Payer-to-Payer API (including processes for gathering previous/concurrent payer information and for patients to opt in, and disseminating educational resources to patients), and implementing the Prior Authorization API. We are not including in the group of “policies that require API enhancement or development” terminology changes for the Patient Access API, reporting Patient Access API metrics, changes to prior authorization processes, reporting prior authorization metrics, Medicaid notice and fair hearings changes, the MIPS and Medicare Promoting Interoperability measures, and updated standards. An explanation of why we are establishing these deadlines for each policy is found in section I.D.2. of this final rule and throughout this rule.

We use the term “items and services” when discussing prior authorization in this final rule. Unless otherwise stated, the policies for prior authorization APIs and processes do not apply to drugs of any type, meaning any drugs that could be covered by the impacted payers in this final rule (for example, prescription drugs that may be self-administered, administered by a provider, or that may be dispensed or administered in a pharmacy or hospital), because the processes and standards for prior authorization of drugs differ from the other “items and services” included in our final policies. In the CMS Interoperability and Patient Access final rule, we finalized policies that require payers to send claims data related to prescription and other drug claims via a Patient Access API, and we are finalizing certain provisions related to claims data in this final rule. For example, Medicare Advantage Prescription Drug (MA–PD) plans that cover Part A, Part B, and Part D benefits, as well as supplemental benefits, are required to provide access to information about all those covered benefits through the Patient Access API at 42 CFR 422.119(b). Prescription and other drug information is part of a patient's record and giving patients, providers, and payers access to claims data for prescription and other drugs can offer valuable insights into a patient's health care, provide benefits for care coordination, and help avoid potentially harmful drug interactions. We acknowledge that there are existing laws and regulations that may apply to prior authorization of drugs for the impacted payers in this final rule. Thus, while the claims data included in this final rule and existing policies do include prescription and other drug claims, our policies in this final rule related to prior authorization do not include standards or policies for any drugs (as previously described), including covered outpatient drugs under Medicaid, and Medicare Part B or Part D drugs covered by an MA (including an MA–PD) plan.

Additionally, we use the terms “provider” and “supplier” as inclusive terms composed of individuals, organizations, and institutions that provide or furnish health services, such as clinicians (that is, physicians and other practitioners), hospitals, skilled nursing facilities (SNF), home health agencies, hospice settings, laboratories, suppliers of durable medical equipment, prosthetics, orthotics, and supplies (DMEPOS), community-based organizations, as appropriate in the context used. When specifically discussing policies related to the Medicare Promoting Interoperability Program and the Promoting Interoperability performance category of MIPS, we refer to MIPS eligible clinicians, eligible hospitals, and CAHs.

Throughout this final rule, we finalize API provisions in which we refer to the API functionality as a single API, though we acknowledge that payers may implement this functionality by using one or multiple APIs. For example, while we refer to the Patient Access API (discussed in section II.A. of this final rule) as a single API to describe the functionality, payers may achieve the same functionality with one or multiple APIs, depending on the implementation approach.

An API is a set of commands, functions, protocols, or tools published by one software developer (“A”) that enables other software developers to create programs (applications or “apps”) that can interact with A's software without needing to know the internal workings of A's software while maintaining data security and patient privacy (if properly implemented). This is how API technology enables the seamless user experiences, which are familiar in other aspects of patients' daily lives, such as travel and personal finance smartphone apps, which can function without being integrated into the smartphone's operating system. Standardized, secure, transparent, and pro-competitive API technology can provide similar benefits for patients of health care services.

Health Level 7 (HL7®) is the standards development organization (SDO) that develops the Fast Healthcare for Interoperability Resources (FHIR®) standard and IGs referenced throughout this final rule. HL7 requires the registered trademark with the first use of its name in a document, for which policies are available on its website at www.HL7.org.

Finally, throughout this final rule we discuss the APIs in relation to the programmatic requirements to share data between payers, providers, and patients under specific rules. However, payers could use these APIs to exchange data for myriad purposes, beyond those in this final rule. For instance, a patient could request data outside the scope of this final rule, or program integrity entities could request data from payers (such as under the Inspector General Act of 1978). Nothing in this final rule prevents payers from sharing the requested data via these APIs, if technologically feasible, for appropriate purposes permitted by law. We encourage using these standards-based APIs for purposes beyond our requirements to improve the interoperability of health data, regardless of the use case.

D. Global Comments

CMS received nearly 900 timely pieces of correspondence in response to the CMS Interoperability and Prior Authorization proposed rule. We summarize comments that are globally applicable to the final rule here. In this section, we address comments related to Medicare FFS implementation, the National Directory of Healthcare (NDH), final policy compliance dates, exclusion of drugs from the prior authorization policies in this final rule, the payers impacted by this final rule, the withdrawal of the “Medicaid Program; Patient Protection and Affordable Care Act; Reducing Provider and Patient Burden by Improving Prior Authorization Processes, and Promoting Patients' Electronic Access to Health Information for Medicaid Managed Care Plans, State Medicaid Agencies, CHIP Agencies and CHIP Managed Care Entities, and Issuers of Qualified Health Plans on the Federally-Facilitated Exchanges; Health Information Technology Standards and Implementation Specifications” proposed rule (December 2020 CMS Interoperability proposed rule) (87 FR 76239), and compliance and enforcement.

1. Medicare Fee-for-Service Implementation of Final Policies

Although these requirements do not directly pertain to Medicare FFS, we want to ensure that people with Medicare can benefit from the policies in this final rule, regardless of their coverage or delivery system. We intend for the Medicare FFS program to be a market leader on data exchange, including through the Provider Access, Payer-to-Payer, and Prior Authorization APIs, and therefore we solicited comments on how these proposals could apply to Medicare FFS. We also encouraged other payers not directly impacted by this final rule to consider the policies in this final rule for voluntary adoption to reduce burden and support greater interoperability.

A significant number of commenters expressed support for our intention to ensure that Medicare FFS will comply with the requirements of this final rule by the compliance dates we are establishing. We did not make any policy proposals regarding this effort, but we are considering comments as we plan our roadmap for implementation.

2. Compliance Dates and Enforcement

For our proposals that require API enhancement or development, we proposed compliance dates in 2026 (by January 1, 2026, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2026, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2026, for QHP issuers on the FFEs) (87 FR 76289) and indicated that we thought that a 3-year timeline to recruit and train staff, update or build the APIs, and update operational procedures would be sufficient. In the proposed rule we used the term “implementation dates” rather than “compliance dates” as we are using in this final rule. Because payers may implement APIs before the compliance dates, we want to be clear when we are discussing the regulatory deadlines in this final rule. This terminology does not indicate any changes to the substance of any proposals or finalized requirements.

Comment: Many commenters expressed support for the proposed compliance dates in 2026. A commenter stated that the proposed compliance dates give impacted payers, health information technology (IT) developers, and providers sufficient time to prepare for widespread adoption and utilization. A commenter stated that the feasibility of implementation in 2026 will depend on the complexities of the implementation and the date the final rule is published. Another commenter suggested that CMS provide an implementation timeline with steps to ensure all parties are ready for implementation in 2026. Another commenter wrote that CMS should conduct pilots before the proposed 2026 compliance dates.

Multiple commenters recommended that CMS establish a shorter timeframe for the revisions to the Patient Access API and the implementation of the new APIs. Commenters stated that the benefits of our prior authorization proposals are especially necessary and encouraged us to finalize compliance dates as early as possible. A commenter recommended that CMS require MA organizations to implement the requirements within 90 days of publication of this final rule. Another commenter stated that they believe that MA organizations have the revenue and resources to implement the provisions in CY 2024.

Payers have indicated that they are already collecting information about how patients are using their Patient Access API, and many submitted comments based on the patient uptake they are witnessing. We did not receive comments that indicated that collecting and reporting these metrics would be a burden on payers.

Multiple commenters expressed concern regarding the proposed 2026 compliance dates, for most of the requirements in the rule. Other commenters emphasized that payers would have to begin work on implementation immediately following publication of this final rule to meet all requirements by the 2026 compliance dates. Multiple commenters recommended that CMS delay the compliance dates to 2027 or 2028, citing the feasibility of technology implementation and operational changes.

Commenters indicated that state Medicaid and CHIP FFS programs may need more time to implement because they need to secure funding and engage in the state's procurement process. A commenter recommended compliance dates no earlier than January 1, 2027, with state Medicaid and CHIP agencies having the ability to request up to two 1-year extensions following that date. The commenter noted that due to unique funding cycles and procurement requirements, states could require more time than other payers to implement the proposed requirements.

Multiple commenters weighed in on the amount of time that payers will need to implement the provisions in the proposed rule. Multiple commenters noted that the proposed requirements for payers to implement four APIs within less than 3 years from publication of the final rule would create a significant burden on payers. A commenter stated that developers will need 12–18 months from the publication of a final rule to design, develop, test, and release updated software. The commenter stated that payers will also need time to implement the updated functionality and train staff to assist patients and other API end users. Another commenter stated that developers would need 18 months per API. A commenter recommended that CMS finalize any policies with at least 24 months of lead time. Another commenter suggested that CMS provide at least 24 to 36 months after the publication of the final rule for payers to comply. Other commenters suggested 3 years between publishing a final rule and the compliance dates. Several commenters recommended that CMS consider a staggered implementation approach for the API requirements.

Commenters indicated that, of our proposals, the technical development and enhancement of the required APIs would necessitate a longer implementation period than the prior authorization process improvements.

Response: Having taken into consideration comments about the implementation timeline generally and about each of the policies specifically, we are finalizing our policies that require API development or enhancement with compliance dates in 2027. Specifically, MA organizations and state Medicaid and CHIP FFS programs must comply with those policies by January 1, 2027; Medicaid managed care plans and CHIP managed care entities must comply beginning with the first rating period that begins on or after January 1, 2027; and QHPs in FFEs must comply by the first plan year beginning on or after January 1, 2027. For simplicity, throughout this rule we generally refer to these compliance dates as “in 2027” for the various payers. However, we are finalizing some of our other policies with the proposed 2026 compliance dates, as noted in the Summary of Major Provisions.

Specifically, we are finalizing 2026 compliance dates for the requirements that impacted payers report Patient Access API metrics to CMS, make standard and expedited prior authorization decisions within specific timeframes, send notices to providers, including a specific denial reason for denied prior authorizations, and publicly report prior authorization metrics on their websites. While these policies require a certain level of development and implementation effort, they are not as technically challenging as implementing the APIs. Thus, we believe a nearly 2-year implementation timeframe is sufficient and will allow payers to prioritize them for an earlier deadline.

Because impacted payers should already have Patient Access APIs implemented based on requirements finalized in the CMS Interoperability and Patient Access final rule, reporting on usage of that API should not be a significant burden to payers. We proposed to gather those data to understand how the Patient Access API is being adopted across the industry. We do not believe there is any benefit to delaying this reporting requirement, as we need these data to help inform future policies.

Importantly, the prior authorization policies we are finalizing with 2026 compliance dates should reduce the burden of prior authorization processes, even before the 2027 compliance dates for the API development and enhancement policies. Requiring impacted payers to send provider notices, including a specific denial reason, respond within specific timeframes, and report prior authorization metrics will apply regardless of how the payer received the prior authorization request, and are not dependent on the API. Therefore, we do not believe there is a reason to tie those requirements to the API compliance dates. Delaying the changes to prior authorization timeframes and procedures would only delay the benefits of those new policies.

However, we are sensitive to the implementation burdens on payers, particularly for the final policies that require API development or enhancement. We understand that payers need time to design, develop, test, and implement major system changes to implement the new Provider Access, Payer-to-Payer, and Prior Authorization APIs. We considered finalizing staggered API compliance dates between 2026 and 2027, as some commenters suggested, but concluded that we are not in the best position to prioritize and understand what work can feasibly be completed by 2026 and what scope is better in a second phase for 2027. Instead, we are delaying the compliance dates for the three new APIs and modifications to the Patient Access API by 1 year from the proposed compliance dates to allow payers time to sufficiently plan, develop, test, and implement this technology. After considering the comments we received, we agree with the volume of commenters that indicated that more than 2 years is necessary from the publication of the final rule for payers to meet the new API requirements. In consideration of the schedule for this final rule's publication, we are finalizing compliance dates in 2027, for the new Provider Access, Payer-to-Payer, and Prior Authorization API requirements in this final rule. Throughout the final rule, we specify the exact regulatory citations that are being modified from our proposed rule to reflect the finalized compliance dates for each payer.

We are addressing concerns specific to state Medicaid and CHIP programs with the availability of an extension for Medicaid and CHIP agencies, under which states could seek to delay implementation until 2028, as discussed in section II.E. of this final rule. In that section, we also discuss the possibility of states receiving enhanced Federal Financial Participation (FFP) for expenditures related to implementing these requirements.

Comment: Many commenters expressed concern regarding the lack of discussion in the proposed rule for mechanisms to ensure compliance with the provisions of the rule once finalized. Multiple commenters recommended that CMS clearly outline how it will conduct oversight and enforcement of the requirements in the rule and commenters recommended that CMS outline a process for formal oversight, audit, and enforcement, including financial penalties and other consequences to promote accountability. A commenter questioned the enforcement and oversight activities for the CMS Interoperability and Patient Access final rule (CMS–9115–F). Another commenter highlighted the lack of penalties for non-compliance with the Provider Directory API. Other commenters recommended that CMS develop a structured process for the public to report non-compliance. Multiple commenters recommended that CMS closely monitor payer compliance and impose civil monetary penalties on payers that are non-compliant.

Response: As explained in the proposed rule and the CMS Interoperability and Patient Access final rule, each CMS program oversees compliance under existing program authorities and responsibilities for the different types of payers impacted by these API requirements (for example, MA organizations, Medicaid programs, etc.). Oversight and compliance procedures and processes vary among these CMS programs and CMS may choose from an array of possible enforcement actions, based on a payer's status in the program, previous compliance actions, and corrective action plans. Therefore, we do not address specific potential compliance and enforcement actions across impacted payers in this final rule, although we do discuss categories of enforcement actions that CMS could consider for various payers in the discussion later in this section. Patients and providers may submit an inquiry or complaint to the appropriate authority, depending on their coverage.

For MA organizations, because these are program requirements, depending on the extent of the violation, CMS may take compliance actions from warning letters or requiring a corrective action plan, to enforcement actions including sanctions, civil money penalties and other measures specified at 42 CFR part 422, subpart O. If an MA enrollee believes a plan is not fulfilling its responsibilities with respect to the API requirements, they have a right to file a grievance with a plan under the procedures at 42 CFR 422.564. Individuals may also submit complaints about their MA plans to 1–800–MEDICARE and the online complaint system at https://www.medicare.gov/my/medicare-complaint. The State Health Insurance Assistance Programs (SHIP) are available to help Medicare beneficiaries, including with filing complaints.

When states use enhanced funding for expenditures related to system modifications or enhancements, CMS's enforcement is based upon 45 CFR 95.612 (Disallowance of FFP) and the methodology described in the Centers for Medicaid and CHIP Services (CMCS) Informational Bulletin (CIB), “Medicaid Enterprise Systems Compliance and Reapproval Process for State Systems with Operational Costs Claimed at the 75 Percent Federal Match Rate,” published May 24, 2023. If a state is not compliant with the requirements included in this final rule, the appropriate program policy team will address compliance enforcement.

States are obligated by 42 CFR 438.66(b) and (c) to have a monitoring system for all of their managed care programs, including the performance of each managed care plan, to ensure that all managed care plans are fulfilling their contractual obligations. States report the results of their monitoring activities in an annual Managed Care Program Annual Report, in accordance with 42 CFR 438.66(e). Further, per 42 CFR 438.3(a), CMS must review and approve all managed care plan contracts. Should information in a state's Managed Care Program Annual Report or contract indicate a need for improvement or correction, CMS would work with the state to ensure that the issue is remedied. Patients or providers with concerns regarding Medicaid or CHIP FFS should contact their state Medicaid or CHIP agency. Patients and providers can contact Medicaid.gov@cms.hhs.gov if the state agency is not responsive.

For any concerns related to compliance by Medicaid managed care plans and CHIP managed care entities, enrollees and providers should first contact their managed care plan or managed care entity. Enrollees or providers can contact the state Medicaid or CHIP agency to report issues that they cannot resolve by working with the managed care plan or entity directly.

Consistent with the authority under 45 CFR 156.715, the Center for Consumer Information and Insurance Oversight (CCIIO) performs compliance reviews of issuers in the FFEs. In addition, 45 CFR 156.800 through 156.815 provides for additional enforcement remedies including Civil Money Penalties (CMPs) and Notices of Non-Compliance (NONCs) as well as paths to QHP issuer Suppression and Decertification. If enrollees in a QHP on the FFEs or their providers have concerns about an issuer's interoperability implementation, they should first contact their health plan with questions. For issues that they cannot resolve by working directly with the plan, enrollees and providers can contact the Marketplace Call Center at 1–800–318–2596 (TTY: 1–855–889–4325).

CMS manages compliance with the HIPAA administrative transaction standards under the authority of the administrative simplification rules. Complaints about non-compliance can be submitted to CMS at https://asett.cms.gov/ASETT_HomePage.

3. Exclusion of Drugs

In the CMS Interoperability and Prior Authorization proposed rule, we stated that we were excluding drugs from the Prior Authorization API and proposed process requirements for prior authorizations because the standards and processes for issuing prior authorizations for drugs differ from those that apply to medical items and services.

Under state Medicaid programs and the MA program, there are similar timing requirements for prior authorizations for coverage of drugs. MA plans are required to respond to expedited requests for Part B drugs within 24 hours (42 CFR 422.572) and to non-expedited requests as expeditiously as the enrollee's health condition requires, but no later than 72 hours after receipt of the request (42 CFR 422.568). Further, MA–PD plans that cover Part A, B, and D benefits must comply with similar timelines in responding to prior authorization requests for Part D prescription drugs (42 CFR 423.568, 423.572). Similarly, under Medicaid (both FFS and managed care), if a state requires prior authorizations for covered outpatient drugs, a response must be provided within 24 hours of the request for prior authorization (see section 1927(d)(5) of the Social Security Act (the Act) and 42 CFR 438.3(s)(6)). We acknowledge that other drugs do not meet the definition of “covered outpatient drugs,” including cancer drugs, special treatments, and other important medications, and thus are not subject to these prior authorization timeline requirements.

Comment: A plethora of commenters provided input and requested that CMS reconsider the proposal to exclude drugs and instead include drugs in the prior authorization policies for all or some impacted payers.

Some commenters expressed support for CMS's exclusion of drugs from the proposed requirements and CMS's decision to defer Prior Authorization API requirements for drugs to future rulemaking. Multiple commenters recommended that CMS make clear the exclusion of drugs from all the requirements in a final rule.

Response: We believe it is clear throughout this final rule that none of the prior authorization policies apply to any drugs covered by any impacted payer. However, based on the overwhelming number of comments in support of our reconsideration of the policy, and additional conversations with SDOs and stakeholders, we will consider options for future rulemaking to address improvements to the prior authorization processes for drugs.

Comment: Multiple commenters expressed disappointment that CMS excluded outpatient prescription drugs from the prior authorization process and Prior Authorization API policies in the proposed rule, explaining that drug prior authorizations constitute the majority of all prior authorizations. Multiple commenters recommended that CMS reconsider the exclusion of drugs from the proposed rule and suggested that CMS expand a final rule to include outpatient prescription drugs covered under a medical benefit.

A few commenters specifically requested that CMS include drugs covered under a medical benefit in the prior authorization process and Prior Authorization API policies in the final rule and explained that the exclusion was troubling because health plans may cover physician-administered drugs and specialty drugs through a patient's medical benefits, including specialty drugs. A commenter urged CMS to include administered drugs, which are inextricably related to other provider services. Some commenters stated that by failing to include administered drugs throughout the proposed rule, CMS is failing to address the biggest culprit of delay to timely care and administrative burden for cancer patients. Commenters described barriers to access for prescriptions for specialty drugs, cancer drugs, and certain drugs for chronic conditions that require ongoing re-authorizations. The commenters believed that including prescription drugs in our prior authorization policies would improve the effectiveness of this final rule and would support CMS's goals of reducing barriers and burdens in health care.

Response: While we acknowledge the request for reconsideration, when making the decision to exclude prescription drugs from the proposed rule, we believed there would be operational complexities in applying the requirements of this rule to prior authorization for prescription drugs under current conditions and did not anticipate the overwhelming response to that exclusion under current conditions. Based on the scope and breadth of the comments, it is essential for us to conduct a thorough evaluation of both existing policies and standards, and the impact any mandatory changes will have on impacted payers, providers, and patients, as well as on other policies before making a proposal for public consideration. We are committed to ensuring transparency of the process, and the development of the right policy to support all entities who might benefit. We anticipate engaging with the public on this topic in the near future and encourage the public to provide additional feedback.

Comment: Many commenters questioned whether impacted payers are permitted to include the functionality necessary to conduct prior authorization for drugs via the Prior Authorization API. A commenter also requested that CMS require all payers to include drug-related prior authorization requirements in the Prior Authorization API to ensure prescribers have ready access to uniform policies, and patients have timely access to their medications. Another commenter recommended that CMS explain that even if prescription drugs are excluded from the requirements, the rule does not prohibit the sharing of drug prior authorization data via the Patient Access, Provider Access, and Payer-to-Payer APIs.

Response: While we did not propose a requirement for prior authorization policies for drugs to be included in the Prior Authorization API, payers may add such coverage rules and requirements to their APIs; nothing in this final rule prohibits broader use of the required Prior Authorization API by impacted payers and we encourage them to do so to the extent permitted by law. The scope of the IGs for the Prior Authorization API includes prior authorization for medications covered under a medical benefit. We describe the IGs and the Prior Authorization API in further detail in section II.D.2. of this final rule. However, we note that a FHIR API cannot be used with a National Council for Prescription Drug Programs (NCPDP) SCRIPT standard because the data elements have not yet been mapped. Also, the HL7® FHIR® Da Vinci Prior Authorization Support (PAS) IG states it “SHOULD NOT be used for any medication that is covered under a prescription drug program benefit where Prior Authorization is provided by another electronic exchange process (for example, NCPCP SCRIPT).”

We confirm that nothing would prohibit an impacted payer from sharing the same information about prior authorizations for drugs that they are required to share for items and services via the Patient Access, Provider Access, and Payer-to-Payer APIs, if they choose.

Comment: A commenter sought clarification on whether the prior authorization requirements would apply to supplies dispensed at a pharmacy, such as diabetic test strips. This commenter stated that an API would likely not provide any additional benefit or improve the timeliness of a decision and might increase handling timeframes while the API is in the early stages of use. This commenter recommended that pharmacy dispensable supplies maintain their current timeframes for coverage decisions. Another commenter recommended that CMS require impacted payers to include durable medical equipment (DME) administered under the DME benefit in the Prior Authorization API. Another commenter sought clarification on whether therapeutic devices are excluded from the Prior Authorization API requirements.

Response: Supplies, including those dispensed at a pharmacy and DME, that are considered medical benefits and are not prescription drugs, are subject to the prior authorization requirements of this final rule. Payers will be required to include these supplies in their APIs, to the extent they are covered as a medical benefit and require prior authorization. DME, for example, includes continuous glucose monitors, test strips, lancets, orthotics, wheelchairs, and other devices. All prior authorizations covered as a medical benefit, including those for DME, supplies dispensed at a pharmacy, or therapeutic devices, must still meet the timeframe requirements established in this final rule, regardless of whether the request is made through an API or other means, as described in section II.D.4. However, for MA–PDs, this final rule excludes the entire scope of “Part D drugs,” as defined at 42 CFR 423.100, from the scope of the prior authorization requirements; therefore, certain supplies that are included in the definition of Part D drugs at 42 CFR 423.100 are not subject to the prior authorization requirements adopted here.

4. Impacted Payers

As stated previously, certain portions of this final rule apply to MA organizations, state Medicaid FFS programs, state CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs. We received numerous comments regarding applicability to the payers impacted by the rule and summarize these comments and responses.

Comment: Many commenters supported CMS's proposed categories of impacted payers for this rule. Specifically, commenters supported the inclusion of Medicaid and CHIP FFS, which were excluded from the payer to payer data exchange requirements in the CMS Interoperability and Patient Access final rule, and MA plans, which were excluded in the December 2020 CMS Interoperability proposed rule. Commenters noted that the benefits of interoperable data exchange will only accrue if there is widespread adoption by payers across the health care system.

Response: We appreciate the support for the proposed types of impacted payers and agree that the more payers that implement the requirements of this final rule, the greater the beneficial impact will be on patients.

Comment: A commenter requested clarification as to whether dental plans that provide coverage to MA enrollees or Medicaid beneficiaries are impacted payers and encouraged CMS to exclude those plans, akin to the exclusion of QHP issuers on the FFEs offering only SADPs. Another commenter specifically encouraged CMS not to exclude SADPs and to include dental plans for MA and Medicaid or CHIP managed care.

Response: We did not propose new interoperability or prior authorization standards on SADPs on the FFEs because they have relatively lower enrollment and premium intake compared to individual market medical QHPs. Requiring those plans to comply with the requirements in this final rule could result in those issuers no longer participating in the FFEs, which would not be in the best interest of enrollees. These plans are therefore outside the scope of this final rule. We appreciate input from commenters who view prior authorization and interoperability as important for SADP enrollees and will continue to monitor this issue and work with stakeholders to understand how to best meet patient needs while considering the potential burden on payers.

For Medicare beneficiaries enrolled in MA plans, when dental coverage is a supplemental benefit covered by the MA plans, it is offered by the MA organization, directly or through contract arrangements the MA organization uses to provide the MA supplemental benefit. Regardless of the mechanism, the dental coverage is part of the MA plan itself and offered under the MA organization's contract and bid with CMS, not a separate plan. MA organizations can project expenditures to comply with the policies in this final rule to incorporate into their overall operational costs when setting premiums.

An organization that has a risk-based contract directly with a state to provide dental benefits only to Medicaid and CHIP beneficiaries is usually a PAHP. We proposed, at 42 CFR 438.210 and 438.242 for Medicaid (applicable to separate CHIP through existing cross-references at 42 CFR 457.1230(d) and 457.1233(d)), that all PAHPs other than Non-Emergency Medical Transportation (NEMT) PAHPs, including those that cover dental benefits, would be subject to the requirements of this rule. Per 42 CFR 438.4, capitation rates, which are required for all risk-based MCOs, PIHPs, and PAHPs, must be projected to provide for all reasonable, appropriate, and attainable costs that are required under the terms of the contract and for the operation of the managed care plan for the time period, as well as the population covered under the terms of the contract, in addition to meeting specific additional requirements at 42 CFR 438.4 through 438.7. Similarly, for separate CHIP, per 42 CFR 457.1201(c) and 457.1203(a), capitation rates are based on public or private payment rates for comparable services for comparable populations and must represent a payment amount that is adequate to allow the MCO, PIHP, or PAHP to efficiently deliver covered services to beneficiaries in a manner compliant with contractual requirements. Therefore, the concerns of upward pressure on premiums that impact participation that are applicable to SADPs offered on the FFEs are not present for Medicaid and CHIP risk-based managed care plans.

Comment: A commenter suggested that CMS define the term “payer” to encompass health insurance issuers and group health plans subject to the Public Health Service Act. Multiple commenters expressed their concern that private payers, commercial plans, and employer-sponsored plans would not be subject to the rule requirements. A commenter expressed concern regarding the 150 million Americans who are in employer-sponsored coverage, who may not have access to the benefits of the proposed rule.

Another commenter suggested that CMS could use its authority over the public sector Consolidated Omnibus Budget Reconciliation Act (COBRA) group health plans to extend interoperability requirements to those payers.

Response: We appreciate commenters supporting implementation of the policies by private payers, commercial plans, and employer-sponsored plans. However, we proposed to impose these requirements under our authority to regulate issuers in the Exchanges that CMS operates, which does not apply to health insurance issuers and group health plans outside the FFEs. There is nothing prohibiting those payers from implementing the provisions in this final rule voluntarily, as long as there are no conflicts with other Federal or state laws, and we do encourage those plans to voluntarily meet the requirements of this final rule to allow patients they cover to have the same interoperable access to their data as impacted payers are required to provide.

Title XXII of the Public Health Service (PHS) Act applies COBRA requirements to group health plans that are sponsored by state or local government employers. They are sometimes referred to as “public sector” COBRA to distinguish them from the Employee Retirement Income Security Act of 1974 (ERISA) and Internal Revenue Code requirements that apply to private employers. We did not make any proposals regarding public sector COBRA plans, so they are not included as impacted payers in this final rule, but we will consider whether we can and should propose similar interoperability requirements on such plans in future rulemaking.

Comment: A commenter sought clarification regarding why CMS exempted SHOP issuers from the proposed rule.

Response: As discussed in the proposed rule, we proposed to exclude QHP issuers offering only QHPs in the FF–SHOPs. We believe that the proposed standards would be overly burdensome for both SADP and SHOP issuers. Requiring issuers offering only SADPs and issuers offering only QHPs in the FF–SHOPs, which have relatively lower enrollment and premium intake compared to individual market medical QHPs, to comply with our proposals, could result in those issuers no longer participating in the FFEs, which would not be in the best interest of the enrollees.

Comment: Multiple commenters recommended that CMS work with ONC and other Federal agencies, such as the Veterans Administration (VA), the U.S. Department of Defense (DoD), and other government payers, to bring additional data into the interoperability universe.

Response: We continue to work with ONC and agencies across the Federal Government to move toward a fully interoperable health care system. We are committed to sharing any insights and best practices from our experience working with impacted payers with other agencies that provide health care coverage to inform their own interoperability goals. These are independent agencies over which HHS has no authority.

5. Withdrawal of Proposed Rule

In the CMS Interoperability and Prior Authorization proposed rule, we explained that we were withdrawing the December 2020 CMS Interoperability proposed rule (87 FR 76239). We received multiple comments in support of this decision.

Comment: Commenters supported our withdrawal of the December 2020 CMS Interoperability proposed rule. Several commenters expressed that the burden of prior authorization has grown since that proposed rule was published and voiced their support for finalizing our proposals.

Response: We appreciate the support and believe that the proposals that we are now finalizing reflect the feedback we received from the health care industry.

6. National Directory of Healthcare

On October 22, 2022, we released a Request for Information (RFI) (87 FR 61018) to solicit public comments on establishing an NDH that could serve as a “centralized data hub” for health care provider, facility, and entity directory information nationwide. We also received many comments to this proposed rule that discussed the possibility of an NDH, particularly to discover payers' digital endpoints (in this case, a FHIR server's URL or IP address) to facilitate our Payer-to-Payer API policy.

Comment: Many commenters stated that the lack of a national directory makes it difficult to identify digital endpoints to facilitate payer to payer data exchange. Multiple commenters also expressed how important an NDH would be to the success of a Provider Access API, because as information on provider digital endpoints remains limited, widespread access to such a directory could advance efforts to connect payers to providers. Commenters urged CMS to establish an NDH before the API compliance dates and explained that not doing so could result in an industry-wide scramble and search for verified plan endpoints necessary for implementation. A commenter recommended that CMS establish and maintain a national payer directory that includes verified information on payers, including their API endpoints, contact information for their API project managers, and their readiness for participation in payer to payer data exchange. Another commenter stated they are currently trying to set up their own Payer-to-Payer API and encountered problems without a centralized location of payer endpoints. This led to issues identifying a new member's previous payer and making secure connections to exchange information. A commenter cautioned that a draft version of the National Directory IG developed by the FHIR at Scale Taskforce (FAST) originally published in September 2022 describes a payer to payer data exchange but is based on the projected existence of a national directory of payer endpoints and governance framework. A commenter noted scalability issues that could arise without a national directory of endpoints to connect in a unified and meaningful manner.

Response: We understand that a directory of payer and provider digital endpoints would be highly beneficial to facilitate our Payer-to-Payer, Provider Access, and Prior Authorization API requirements. Without such a directory, payers would need to discover other payers' endpoints one by one, and each payer would have to maintain a list of payers that they have previously connected with for data exchange. The Trusted Exchange Framework and Common Agreement (TEFCA) provides a directory of digital endpoints that can be used by TEFCA Participants.

Additionally, CMS is committed to exploring an NDH that contains payers' and providers' digital endpoints to facilitate more interoperable data exchange in healthcare for a variety of use cases, including support for the Payer-to-Payer, Provider Access, and Prior Authorization APIs.

II. Provisions of the Proposed Rule and the Analysis of and Responses to Public Comments

A. Patient Access API

1. Background

In the CMS Interoperability and Patient Access final rule (85 FR 25558), in order to give patients access to their own health information in a way most meaningful and useful to them, we required impacted payers to share, via FHIR APIs, certain information including patient claims, encounter data, and a set of clinical data that patients can access via health apps. Claims and encounter data, used in conjunction with clinical data, can offer a broad picture of an individual's health care experience. Patients tend to receive care from multiple providers, leading to fragmented patient health records where various pieces of an individual's record are locked in disparate, siloed data systems. With patient data scattered across these disconnected systems, it can be challenging for providers to get a clear picture of the patient's care history, and patients may forget or be unable to provide critical information to their provider. This lack of comprehensive patient data can impede care coordination efforts and access to appropriate care.

2. Enhancing the Patient Access API

In the CMS Interoperability and Patient Access final rule (85 FR 25558–25559), we adopted regulations that require certain payers, specifically MA organizations (at 42 CFR 422.119), state Medicaid and CHIP FFS programs (at 42 CFR 431.60 and 457.730), Medicaid managed care plans (at 42 CFR 438.242(b)(5)), CHIP managed care entities (at 42 CFR 457.1233(d)), and QHP issuers on the FFEs (at 45 CFR 156.221), to implement and maintain APIs that permit patients to use health apps to access specified data. The Patient Access API must make available, at a minimum, adjudicated claims (including provider remittances and patient cost-sharing); encounters with capitated providers; and clinical data, including laboratory results, with a date of service on or after January 1, 2016, as maintained by the payer. Payers must make those data available via the Patient Access API no later than 1 business day after a claim is adjudicated or encounter or clinical data are received. In the CMS Interoperability and Prior Authorization proposed rule, we proposed various changes to enhance the Patient Access API that are discussed further elsewhere. We also received comments about the Patient Access API more generally, which we summarize and respond to in this section.

To support the ongoing maintenance of the Patient Access API, we are requiring certain specifications and recommending certain IGs, as further discussed in this section and in section II.G. With the publication of the HTI–1 final rule, our cross references to 45 CFR 170.215 have been updated to reflect the updated citations as needed. Changes to the structure of 45 CFR 170.215 and versions of the API standards codified there are discussed further in section II.G. and reflected throughout this final rule. For the Patient Access API, impacted payers must use the following standards: HL7 FHIR Release 4.0.1 at 45 CFR 170.215(a)(1), US Core IG STU 3.1.1 at 45 CFR 170.215(b)(1)(i), SMART App Launch IG Release 1.0.0 at 45 CFR 170.215(c)(1) and OpenID Connect Core 1.0 at 45 CFR 170.215(e)(1). Impacted payers are permitted to voluntarily use updated standards, specifications, or IGs that are not yet adopted in regulation for the APIs discussed in this final rule, should certain conditions be met. For the standards at 45 CFR 170.215 required for the Patient Access API, updated versions available for use under our policy include, but are not limited to, US Core IG STU 6.1.0 and SMART App Launch IG Release 2.0.0, which have been approved for use in the ONC Health IT Certification Program. We refer readers to policies finalized for the Patient Access API in the Interoperability and Patient Access final rule, as well as section II.G.2.c. of this final rule for a full discussion on using updated standards. We are also recommending payers use the HL7® FHIR® CARIN Consumer Directed Payer Data Exchange IG (CARIN IG for Blue Button) STU 2.0.0, HL7® FHIR® Da Vinci Payer Data Exchange (PDex) IG STU 2.0.0, and HL7® FHIR® Da Vinci PDex US Drug Formulary IG STU 2.0.1. We also direct readers to section II.G. of this final rule for a discussion of the standards for the Patient Access API, and Table H3 for a full list of the required standards and recommended IGs to support API implementation.

Comment: Multiple commenters expressed general support for the Patient Access API, as it would promote transparency and improve patient access to health data. Many commenters agreed that the proposed modifications to the Patient Access API would improve patient engagement, shared decision making, and be an opportunity for patients to improve health literacy. Commenters stated that it is critical to ensure that data are shared interoperability to prevent unnecessarily restrictive or expensive proprietary systems from inhibiting patient and provider access. A commenter noted that the API places the patient at the center of care, which could lead to improvements in quality care and a seamless patient experience. Other commenters noted that it will help improve predictability for patients and help them identify potential violations in mental health parity law and facilitate better communication between patients and providers. Another commenter noted that the most convenient way for patients to access their health information is via apps.

Multiple commenters expressed support for the standardization of the Patient Access API across different payer types and coverage programs. A commenter stated that establishing standardized processes for the Patient Access API would benefit patients and enable them to have efficient and secure access to their records while maintaining their privacy.

Response: We thank the commenters for their feedback and will continue to look for ways to drive adoption and use of the Patient Access API to benefit patients. We agree that requiring a standard API will unlock potential for developers to create patient-friendly apps.

Comment: Other commenters stated that they do not believe the Patient Access API will be a dominant means for accessing health care data because patients may get similar or better information elsewhere. Commenters stated that they have not seen significant uptake of health apps since the implementation of the Patient Access API. Commenters relayed that while they believe in the potential for the Patient Access API to improve the utility and portability of patient medical information, they have not seen robust utilization of these tools, possibly because many payers have their own portals. Some commenters believe that their members prefer to speak with a customer service representative, for instance, to discuss the status of their claims. Some payers noted that although they currently have a low rate of members using apps, they anticipated higher utilization as younger cohorts, who are more familiar with how smartphone apps can benefit their care, reach the age of Medicare eligibility.

A commenter flagged that the Patient Access API could result in administrative costs being spread over a smaller than expected user base due to its low utilization. They recommended that CMS continue to monitor the utilization of the proposed APIs as it considers new functionalities and requirements.

Multiple commenters expressed concerns that certain patients may not be able to access the Patient Access API due to a variety of factors (for example, limited access to technology/internet, software, or apps or low digital literacy), and they encouraged CMS to consider how it can help patients with limited digital or broadband access to have equitable access to necessary coverage information. Stating that some patients may not have access to the appropriate software or app, multiple commenters recommended that CMS require states and other entities to continue to provide written notices instead of relying on electronic communication via the Patient Access API. Commenters also recommended that CMS continue to monitor the Patient Access API usage and closely track any potential disparities in access due to social determinants of health (SDOH) or differences in digital literacy.

Response: We understand that some patients cannot or may not want to access their health information electronically or through a health app. Nothing in this rule will require patients to use the Patient Access API to access their health information. Nor will the rule change any applicable obligation for payers to make information available in non-electronic formats, should such a requirement exist. For example, 42 CFR 435.918(a) requires Medicaid agencies to give individuals the choice whether to receive notices electronically or by mail. Similar requirements for MA organizations can be found at 42 CFR 422.2267(d)(2). Furthermore, under the HIPAA Privacy Rule, covered entities generally must provide individuals access to their PHI in the form and format requested by the individual, if it is readily producible in such form and format; or, if not, in a readable hard copy form or such other form and format as agreed to by the covered entity and the individual.

However, making available digital tools, such as standardized APIs and health apps that can access them, aligns with how many people interact with other industries today, such as banking and e-commerce. Making health information similarly available and interoperable broadens patients' options for accessing their records. While many patients may be satisfied using their payer's portal, and we do not wish to take that option away from them, using proprietary systems and data formats has led to a health care system where patient data are fragmented and often difficult to exchange between parties. Entities such as HIEs, health apps, and TEFCA Participants and Subparticipants may be able to gather data from payers, providers, and other sources to create a more comprehensive patient record than could be maintained by the payer alone. Advances in nationwide data sharing, such as payers' Patient Access APIs, connections across HIEs, and exchange enabled by TEFCA, can facilitate secure and reliable access to these data sources. That is the reason that CMS and HHS are invested in establishing open standards and requirements for payers and providers to use standardized technology. While many patients are most familiar with their payer's portal, until the Patient Access API provisions went into effect on January 1, 2021, their options may have been limited. We also anticipate that adoption will take time as patients learn about their options and choose methods for accessing their health information that work best for them.

Comment: Multiple commenters recommended that CMS ensure that the Patient Access API allow caregivers and dependents to have access where patients have provided consent. A commenter urged CMS to explain how an individual can ensure caregivers have access to their health information via the Patient Access API. Another commenter recommended that CMS explain that representatives should be included in all relevant communication and considered as payers develop the API.

Response: Per the HIPAA Privacy Rule at 45 CFR 164.502(g), a personal representative is a person authorized under state or other applicable law to act on behalf of the individual in making health care related decisions (such as a parent, guardian, or person with a medical power of attorney). With limited exceptions, a personal representative is treated as the individual for purposes of the HIPAA Privacy Rule. Similarly, our existing Patient Access API policies (at 42 CFR 422.119(a) and (b)(1), 431.60(a) and (b), and 457.730(a) and (b) and 45 CFR 156.221(a) and (b)) explicitly apply to patients' personal representatives.

Payers likely have different processes and policies for designating someone as a personal representative under the HIPAA Privacy Rule and also may be subject to similar state laws. Nothing in this rule will require a change to those processes. Therefore, patients and personal representatives should contact their payer for the steps to ensure appropriate access to information via the Patient Access API. We do not explicitly require impacted payers to send to their patients' personal representatives the required educational resources. However, payers are required to post those resources on their public websites and to convey them via other appropriate mechanisms through which they ordinarily communicate with current patients. If payers send other resources to personal representatives on a patient's behalf, then educational resources should be sent to them as well. In addition, there may be program- or state-specific requirements to transmit such resources to a patient's personal representative.

Comment: A few commenters recommended that CMS require payers to update patient information that they are told is incorrect by a patient or provider.

Response: Under the HIPAA Privacy Rule, at 45 CFR 164.526, individuals have the right to have a covered entity amend PHI or a record about the individual in a designated record set for as long as the PHI is maintained in the designated record set, with certain exceptions. The Patient Access API does not require the impacted payer to include the capability to send information from a patient to a payer. Therefore, while patients have the right under the HIPAA Privacy Rule to request that a HIPAA-covered entity (such as a provider or payer) amend their record, that functionality is out of scope for the Patient Access API.

a. Prior Authorization Information

To enhance our policy finalized in the CMS Interoperability and Patient Access final rule, we proposed in the CMS Interoperability and Prior Authorization proposed rule to add information about prior authorizations to the categories of data required to be made available to patients through the Patient Access API. We stated that this proposal would apply to all prior authorization requests and decisions for items and services (excluding drugs) for which a payer has data in the patient's record, as discussed further in this section. We also proposed that the Patient Access API must include certain information about prior authorizations within 1 business day of receipt of, or change of status to, the prior authorization. The primary goal of the Patient Access API is to give patients access to their health information, and by expanding patient access to prior authorization information, we aim to help patients be more informed decision makers and true partners in their health care.

As discussed in section I.D. of this final rule, our prior authorization proposals did not apply to drugs of any type that could be covered by an impacted payer, including, for example, outpatient drugs, drugs that may be prescribed, drugs that may be administered by a provider, drugs that may be dispensed or administered in a pharmacy or hospital, or over-the-counter (OTC) drugs.

In section II.D. of this final rule, we finalize several proposals focused on making the prior authorization process less burdensome for providers and payers, which we anticipate will reduce delays in medically necessary access to covered items and services and improve patient outcomes. Giving patients access to information about prior authorization requests and decisions will enable them to take a more active role in their own health care.

We are finalizing our proposal to require impacted payers to provide patients, through the Patient Access API, with access to information about prior authorization requests and decisions made for their care and coverage. However, we are finalizing a modification to our proposal and not requiring payers to share the quantity of items or services used under a prior authorization or unstructured documentation related to a prior authorization, as discussed elsewhere in this final rule. We are finalizing these changes with compliance dates in 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs), which is a year after the proposed 2026 compliance dates.

Comment: A significant majority of commenters expressed support for CMS's proposal to include prior authorization information in the Patient Access API. Commenters listed multiple benefits to making prior authorization information available via the Patient Access API, including empowering patients in their care, reducing the burden of repeated inquiries to payers, and facilitating faster decisions by allowing patients to help providers submit the necessary documentation. Multiple commenters highlighted current challenges for patients to access their prior authorization information.

Response: We appreciate commenters' feedback confirming the significant burden that prior authorizations processes place on patients. We received comments from across the industry that indicated that those processes could be improved by interoperable data exchange. Those comments have informed the policies we are finalizing to require impacted payers to make available via the Patient Access API certain information about prior authorizations.

Comment: Multiple commenters expressed concerns that because many patients do not have an overall understanding of the prior authorization process, giving patients access to prior authorization information would add to existing confusion, and that this information may be overwhelming. Some commenters stated that they do not believe that additional requirements and burden on impacted payers around the Patient Access API are warranted based on current app adoption by patients. The commenters stated that there should be greater Patient Access API use before adding more requirements to the Patient Access API.

Commenters cautioned against creating any expectations for patient involvement in a prior authorization process that they may not understand and over which they may have little control. Other commenters recommended that CMS explore strategies to promote access to timely prior authorization-related information for patients who cannot or do not want to use health apps.

Response: We understand that not all patients will want to access their prior authorization data, and some may not be able to fully understand the information that is presented to them. However, we do not believe that this is a sufficient justification for not making those data available to patients who want that access and insight into their care. We strongly encourage payers to make data transparent and explain the processes involved in a patient's coverage in an easily understandable manner.

We do not intend to create expectations for patient involvement in the prior authorization process but want to make that opportunity available where it can be beneficial to expedite prior authorization decisions. To the extent that program-specific requirements do not already require such disclosures to enrolled patients, we urge payers to make prior authorization information available to patients regardless of what method they use to inquire about their coverage or care—whether that is an online patient portal, a phone call to customer service agents, or an email inquiry. However, our proposals in this section only addressed information available to patients via the Patient Access API.

Comment: Some commenters stated that, because prior authorization requests today are commonly submitted via multiple modalities, CMS should modify its proposal to require prior authorization information be included in the Patient Access API only if it came from requests submitted via a Prior Authorization API. Commenters flagged that prior authorization data received in non-standard formats, such as fax, would require significant resources for many payers to translate into a standard format to be shared via the Patient Access API. Commenters stated that adoption of electronic prior authorization by providers would be gradual, and it would be administratively complex and burdensome to require payers to convert prior authorizations submitted via phone or fax to electronic format. The commenters recommended that CMS make sharing prior authorizations received via phone or fax optional for payers.

Response: We understand that data submitted for prior authorization requests via non-electronic or non-standardized modalities could require an additional step to make available through the Patient Access API. However, we also note that the burden of ingesting data from non-standard and non-electronic requests into a payer's prior authorization systems exists regardless of the requirement to share data with the patient. While sharing requests submitted via a Prior Authorization API might be simpler, as they are already in a FHIR format, we do not believe that the burden of converting data from the format payers currently use in their prior authorization systems outweighs the benefit of making prior authorization information available to patients. We also note that the same prior authorization data are largely required to be shared via the Provider Access and Payer-to-Payer APIs, thus creating an economy of scale by spreading the benefit to all parties while the burden of data translation would only have to happen once. We believe that all patients should have access to their prior authorization information, regardless of the process between their provider and payer.

In section II.D. of this rule, we are finalizing a requirement for impacted payers to implement and maintain a Prior Authorization API and in section II.F. of this rule, we are finalizing a measure within MIPS to incentivize providers to use that Prior Authorization API. We are finalizing those policies to promote the adoption of electronic prior authorization and, therefore, expect that as electronic prior authorization increases over time, the overall burden of making available prior authorization information submitted and received through other modalities will decrease. We believe that payers will also encourage their providers to use electronic prior authorization to decrease that burden, which will lead to greater interoperability and data availability for patients.

Also, if we required only prior authorization data submitted via a Prior Authorization API to be available via the Patient Access API, we would be excluding patients whose providers may not be able to implement electronic prior authorization for technological or other reasons. Therefore, we are finalizing a Patient Access API policy that covers data from all prior authorizations, regardless of the medium through which the payer receives the request.

Comment: A commenter noted challenges that state Medicaid agencies would face to include prior authorization data in the Patient Access API. The commenter stated that there are differences between how states process prior authorizations today, with some state Medicaid agencies relying on manual processes.

Response: State expenditures on designing, developing, installing, enhancing, or operating state Medicaid systems that can conduct electronic prior authorization may be eligible for enhanced Federal financial participation. Implementation of the Prior Authorization API should facilitate a faster and more automated workflow to make prior authorization data available. We encourage states to take this opportunity to determine whether modernizing prior authorization systems beyond the implementation of a Prior Authorization API can improve their prior authorization processes. We describe the enhanced Medicaid Federal matching percentages in fuller detail in section II.E. of this final rule.

Comment: A commenter requested that CMS explain that the information it is requiring to be available does not need to be “pushed” to a patient app, but should be available for query, if a patient chooses to use their app to retrieve their information.

Response: We confirm that the Patient Access API works on a query mechanism and not a “push.” Our final policy requires that the data be available for a patient's app to query and receive from an impacted payer.

Comment: Some commenters suggested that patients should be able to provide supporting documentation directly to their payer via the Patient Access API. The commenters stated that patients should have the choice to submit prior authorization requests themselves, or to have a provider or third party do it, and should also have the option to initiate, monitor, and appeal prior authorization decisions. Another commenter believed that patients should be able to challenge decisions and report delays.

Response: We did not propose to require impacted payers to accept a prior authorization request or supporting documentation directly from patients. We fear that this would create confusion about the prior authorization process and whether the provider or patient is ultimately responsible for the submission of prior authorization requests and documentation. Providers are in the best position to understand the clinical requirements to obtain prior authorization and are responsible for using their clinical judgment to decide on the best course of treatment. As discussed, it is valuable for patients to have transparency into that process and be able to assist providers to submit necessary information. However, without a clinical understanding, patients may submit extraneous or irrelevant information. Furthermore, patients likely do not have systems that would be able to communicate and submit information via the Prior Authorization API. That would require the availability of an alternative system and negate some of the efficiencies the Prior Authorization API will bring to the prior authorization process. Taken together, such a requirement would add burden to payers and may end up delaying the prior authorization decision process. Nothing in this rule will prohibit a payer from accepting information directly from patients if that would benefit the payer's processes or patient care. Furthermore, payers are already required to have a process in place for patients or providers to appeal prior authorization decisions and to file a complaint with the appropriate Federal or state oversight agency.

i. Compliance Dates

For the requirement to include prior authorization information in the data available via the Patient Access API, we proposed compliance dates in 2026 (by January 1, 2026, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2026, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2026, for QHP issuers on the FFEs).

Comment: Some commenters supported the proposed compliance dates. However, several commenters recommended that the compliance dates for adding prior authorization information to the Patient Access API be accelerated—with recommendations for July 1, 2024, January 1, 2025, or 12 months after the finalization of this rule. Multiple commenters recommended earlier compliance dates due to the significant impact that this information could have on patient empowerment and information transparency.

Conversely, multiple commenters recommended that CMS delay the proposed compliance date until the Prior Authorization API, discussed in section II.D. of this final rule, is widely adopted. Commenters stated that while the technical data standards may be mature, CMS should also consider the status of payers' data infrastructure, which may not have prior authorization information in a structured format to be shared via the Patient Access API. As discussed previously, some commenters recommended limiting the requirement to make prior authorization data available through the Patient Access API only to data contained in standardized HIPAA-compliant electronic prior authorization transactions, such as those facilitated by the Prior Authorization API. These commenters recommended that CMS work with payers, providers, health IT developers, and consumer advocacy groups to first advance electronic prior authorization uptake before determining appropriate compliance dates. A commenter suggested CMS consider additional flexibilities and exceptions for impacted entities unable to comply with the proposed 2026 compliance dates.

Another commenter recommended delaying the compliance dates by another 2–3 years to allow for simultaneous implementation with the “Administrative Simplification: Adoption of Standards for Health Care Attachments Transactions and Electronic Signatures, and Modification to Referral Certification and Authorization Transaction Standard” proposed rule (hereinafter referred to as the HIPAA Standards for Health Care Attachments proposed rule) (87 FR 78438).

Response: After reviewing public comments, we have elected to finalize the provision with a 1 year delay to the compliance dates, to 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs). While making data related to prior authorization available to patients is necessary and urgent, we also understand that it will take time for payers to implement the policies we are finalizing. We believe that the additional year will allow payers to ensure a smooth rollout of this additional functionality. However, we encourage payers to meet the requirements of this rule as soon as possible to benefit their patients.

We decline to delay the compliance date for including prior authorization information in the Patient Access API until after the Prior Authorization API compliance dates and are finalizing the same compliance dates for both this policy and the Prior Authorization API. The purpose of the Prior Authorization API is to facilitate the exchange of structured prior authorization data, and we agree that receiving requests electronically may expedite payers' ability to make that information available to patients. However, even after the Prior Authorization API compliance dates, we expect that a number of prior authorizations are going to be submitted through other channels (hopefully in declining number). As discussed previously, payers will need to have the ability to share prior authorization information that is submitted via channels other than the Prior Authorization API, regardless of the compliance dates. By finalizing 2027 compliance dates, we are providing payers with an additional year beyond what we proposed to implement the needed functionality within their internal systems.

Comment: A commenter suggested that prior authorization decisions issued before the compliance dates should not be required to be available via the Patient Access API.

Response: We proposed, and are finalizing, that impacted payers must give patients access to existing prior authorization information maintained by the payer beginning on the compliance dates. In the CMS Interoperability and Patient Access final rule, we required payers to make available the specified data they maintained with a date of service on or after January 1, 2016, which meant that patients had access to their historical data beginning on the January 1, 2021, compliance date. That date range also applies to the prior authorization data that must be included. However, unlike the other categories of data, there is a period of time after which prior authorization data no longer needs to be available. As discussed elsewhere in this final rule, prior authorization information must be shared while the prior authorization is active and for 1 year after the last status change. As of the compliance dates, payers must make all required data available via the Patient Access API. However, it is unlikely that a significant number of patients will have data from many years before the compliance dates. On January 1, 2027 (or the actual compliance date), payers will be required to make available data about all active prior authorizations, regardless of how long they have been active, and any requests that have had a status update within the previous 1 year period (that is, since January 1, 2026, if a payer implements on these changes on that day).

ii. Data Content

We proposed that the information required to be available through the API would include the prior authorization request and related administrative and clinical documentation, including all of the following:

(1) The prior authorization status.

(2) The date the prior authorization was approved or denied.

(3) The date or circumstance under which the authorization ends.

(4) The items and services approved.

(5) The quantity used to date under the authorization.

(6) If denied, the specific reason why the request was denied.

In section II.D.3. of this final rule, we are finalizing that in the case of a prior authorization denial, the payer must give the provider a specific reason for the denial that is separate from the content requirements for the APIs finalized in this rulemaking. Including the reason in the Patient Access API can help patients understand why a payer denied a prior authorization request. The administrative and clinical documentation related to a prior authorization request that we proposed must be shared through the Patient Access API would include any materials that the provider sends to the payer to support a decision, for example, structured or unstructured clinical data including laboratory results, scores or assessments, past medications or procedures, progress notes, or diagnostic reports. For the reasons discussed, we are finalizing modifications to our proposals to not require impacted payers to include “the quantity used to date” or unstructured documentation in the data available via the Patient Access API.

As further discussed in sections II.B. and II.C. of this final rule, we are requiring impacted payers to make available generally the same information about prior authorization requests and decisions via the Provider Access and Payer-to-Payer APIs. In this way, these prior authorization data can be available to all relevant parties. We note that the requirement to share information about prior authorizations via the Patient Access and Provider Access APIs is in addition to any notice requirements that apply to prior authorization requests and decisions, such as the requirement to notify providers of a decision within certain timeframes discussed in section II.D.5.b. of this final rule.

Comment: Some commenters recommended that CMS require payers to make data more actionable and descriptive by including detailed reasons why a prior authorization request is pending. Many commenters recommended a status for when certain services do not require prior authorization. Conversely, to make status updates simpler via the Patient Access API, multiple commenters suggested only having a pending, active, denied, or expired status update. A commenter requested clarification on whether, in our proposal, the listed “another status” was a status unto itself or used as a catch-all description of any statuses other than those listed.

Response: While we consider five basic statuses (pending, active, denied, expired, authorization not required) to cover the general scope of a prior authorization request and decision, we are neither defining the term “status” as used in this rule, nor these five basic statuses or the conditions under which they must be used by impacted payers. We understand that payers use a variety of processes and do not intend to prescribe exactly when a particular status must be used. Rather, we are indicating that impacted payers must make clear to patients (via the Patient Access API) and providers (via the Provider Access API discussed in section II.B. of this final rule), the status of a prior authorization decision, such as when it is pending, approved, denied, or expired or a request has been submitted for an item or service that does not require prior authorization. We expect payers will generally use those statuses, but they are also welcome to use other statuses that provide additional information or are more specific to the particular payer's process. Such statuses should be clear and understandable to patients and providers. For example, a payer could use statuses such as “under appeal” or “expired—approved quantity used.” However, in some cases, the status information available beyond “pending” could be meaningless to patients if it refers only to the payer's internal processes.

We also agree that patients could benefit from payers making it clear through the Patient Access API when an item or service submitted for prior authorization does not require prior authorization for coverage. However, we emphasize that a mere query as to whether prior authorization is required would not create a record that needs to be shared via the Patient Access API (or the Provider Access API). For instance, a provider may use the HL7® FHIR® Da Vinci Coverage Requirements Discovery (CRD) IG, which is the part of the Prior Authorization API that allows a provider to query whether a payer requires prior authorization before they will cover a specific item or service for a specific patient. Similar queries made through other channels, or submissions that are rejected for being unnecessary, need not be made available through the Patient Access API unless the request creates a record in the patient's data maintained by the payer. Though not required, impacted payers would be welcome to make that information available.

Comment: Multiple commenters supported our proposal that the Patient Access API enhance transparency by including a specific reason for denial. Commenters stated that including a reason for denial would help beneficiaries dispute decisions in a more effective manner. A few commenters urged CMS to require impacted payers to disclose via the Patient Access API the specific coverage or clinical criteria upon which the impacted payer relied to issue a denial.

Response: While we encourage payers to provide coverage or clinical criteria that they used to make a prior authorization decision if that information would help the patient or provider understand the prior authorization decision, many payers consider that specific information to be proprietary. In addition to potentially being proprietary, those clinical criteria may be significantly more complicated than the information we are requiring, and not easily understood by patients. Therefore, we did not propose to require that detailed clinical criteria for a prior authorization decision be shared with patients through the Patient Access API. Instead, we proposed and are finalizing that when a payer denies a prior authorization request, they must provide a specific reason for that denial through the Patient Access API. That reason may indicate which clinical criteria the patient did not meet to be approved for the items or services. We reiterate that the requirement that the specific reason for a denial be included in the Patient Access API is in addition to any other applicable requirements regarding notice of decisions, such as the requirement at 42 CFR 422.568(e) that MA organizations issue a notice containing specific content when denying a prior authorization request and similar requirements for Medicaid managed care plans at 42 CFR 438.210(c) and for health insurance issuers offering individual health insurance coverage (which includes QHP issuers on the FFEs) at 45 CFR 147.136(b)(3)(ii)(E).

Comment: A few commenters questioned whether CMS would provide standardized denial codes and how much flexibility payers will have to define denial reasons.

Response: In this final rule, we are requiring impacted payers to provide a specific reason for a denial. We did not propose standardized denial codes or a specific set of denial reasons for payers to use. However, there is a list of standardized codes that must be used when a prior authorization decision is sent to a provider via the adopted HIPAA standard, which is maintained by the SDO X12. While using those codes is not required for the Patient Access API, we strongly encourage payers and providers to evaluate the code set and make recommendations to X12 for updated or new denial codes, as appropriate. If those X12 denial codes meet the requirement for specificity, they could be used in both the HIPAA transaction and the Patient Access API.

Comment: A few commenters urged CMS to require payers to include plain language information about appealing a prior authorization decision, including processes to request internal review and external appeal of a decision and information about consumer programs to assist with appeals.

Response: We did not propose to make that information available via the Patient Access API. Our educational requirements, discussed in the CMS Interoperability and Patient Access final rule (85 FR 25550–52), only cover using the Patient Access API and not the prior authorization process writ large. However, impacted payers are already required to include that information with a notice of denial. For requirements to make information about the appeals process available to patients via other modalities, see further discussion in section II.D. of this final rule. Depending on the specific requirements of their program, impacted payers may be able to meet that requirement by providing notice about the appeals process via the Patient Access API.

Comment: Multiple commenters recommended that CMS not require the prior authorization information included in the Patient Access API to include the “quantity used to date” requirement, because that information would come from payer claims data. Commenters explained that those data are not a reliable source for patients and providers to track the number of authorized services used to date because of the lag time for processing claims. As such, payers would not be able to update that information until claims have been submitted and processed for the items or services covered by the prior authorization, which could result in inaccurate information being given to a patient for weeks or months until claims are processed.

Response: We understand that payers may not always have accurate or current information about the quantity of approved items or services that a patient has used as of a specific date under a prior authorization. Payers must rely on claims data for that information, which are often not current because there is typically a time lag between when an item or service is rendered and when the claim is submitted and/or processed. If a patient knows that they have used some quantity of the approved items and services, but is not sure of the specific quantity, receiving inaccurate information from their payer about the quantity used to date would lead to confusion and possibly unnecessary inquiries that take patients, providers, and payers time to resolve. Therefore, we are not finalizing our proposal to include “quantity of approved items or services used to date” in the prior authorization information available via the Patient Access API. However, we are finalizing our proposal to require a total number of items or services approved under the prior authorization decision.

Comment: Some commenters recommended that administrative and clinical documentation sent by the provider for prior authorization requests be included in the Patient Access API. However, multiple other commenters recommended that CMS not finalize its proposal to include supporting documentation for prior authorization requests. Some commenters specifically recommended that CMS not require payers to include data or forms that were not sent in a standardized electronic manner, such as via the Prior Authorization API. The commenters expressed concern about the feasibility for impacted payers to provide information that they received in a non-electronic or unstructured format (such as scanned documents or PDFs) and whether third-party patient apps can access or display such documentation. Instead, commenters recommended that CMS focus on requiring that discrete data elements and structured data related to prior authorizations be available to patients. While some commenters expressed that structured data may be duplicative or unnecessary, a majority of commenters indicated that including such data would not be overly burdensome for payers.

Other commenters requested clarification regarding what types of provider-generated documentation would be required and some recommended that CMS assess the prior authorization information requirements against information already available in the APIs to mitigate redundant or duplicative information.

Response: After reviewing the comments, we agree that the burden of requiring impacted payers to make unstructured documentation available via the Patient Access API outweighs the benefits such documentation would provide, so we are finalizing a requirement that the Patient Access API must include structured administrative and clinical documentation submitted by a provider related to the prior authorization request.

Structured documentation includes any data received from a provider and stored in the payer's system in a standardized format with defined data attributes, such as USCDI or FHIR. Examples of structured documentation include data sent by the provider via a transaction standard for prior authorization(s), which utilizes standard code sets, data sent via a Prior Authorization API in a format other than as an attachment, or structured questionnaires that a payer requires providers to fill out when making the prior authorization request. Unstructured data include any attachments submitted by providers, such as radiological scans, large PDFs of clinical data, or, generally, another file that a provider sends to the payer as an attachment to the prior authorization request.

We note that documentation received in an unstructured format does not need to be parsed and converted to structured data to be included in the Patient Access API. However, if a payer does parse the unstructured documentation to store the contained data in a structured format, those structured data would then be “maintained” by the payer, as defined in the CMS Interoperability and Patient Access final rule (85 FR 25538), and the payer would be required to make it available via the Patient Access API.

At this time, the standards for transmitting documentation and attachments via the FHIR APIs are still under development and in testing, and thus not yet in widespread use across the industry. The developing standard for exchanging attachments via FHIR APIs is the HL7® FHIR® Da Vinci Clinical Data Exchange (CDex) IG. Version 2 of the IG completed the HL7 consensus-based process in 2023 and was published as an STU, indicating that it is being prepared for additional testing by implementers before being proposed for adoption. Without the FHIR standard, payers might implement unstructured documentation attachments within the Patient Access API in a variety of ways, which would lead to confusion and lack of interoperability. At this time, attachments exchanged via CDex are considered unstructured documentation and would not need to be made available via the Patient Access API as part of the prior authorization information. If the CDex becomes a mature standard, we may reconsider in future rulemaking whether it would be beneficial to share unstructured documentation as attachments via the Patient Access API.

We recognize that unstructured administrative and clinical documentation from a provider could be important to help patients understand the prior authorization process, so we encourage payers to make that information available when possible. Furthermore, the policy we are finalizing will require impacted payers to make available any documentation that a provider sends to the payer to support a prior authorization request that is received in a structured format. Since we are finalizing that only structured data be made available, and structured data are formatted in a way that makes them easily transmissible between systems, our final policy should place significantly less burden on payers than our proposal, while still giving patients access to information about their prior authorization processes.

We note that some of that information may already be available via the Patient Access API as clinical data. However, we believe that there is value to patients being able to ensure that the clinical information reviewed by the payer is accurate and up to date. Therefore, it is important for payers to make available the specific clinical data that they are looking at to decide on the prior authorization request, even if that information may be elsewhere in the patient's record.

Comment: Multiple commenters suggested that the Patient Access API should include information regarding whether the requesting provider is in-network or out-of-network, by requiring payers to fully implement the X12 270/271 transaction standards for health plan eligibility benefit inquiry and responses. Another commenter recommended that CMS require payers to make available via the Patient Access API the names and contact information for the in-network provider who can furnish the appropriate service within the time and distance standards required by law. Multiple commenters believed that patients should be able to access prior authorization information via the Patient Access API regardless of their provider. A commenter noted consideration for varying network adequacy standards and that a patient may need to seek care from an out-of-network provider. A commenter noted that Medicaid managed care plans have wide discretion for measuring provider network adequacy and that a patient's provider should be able to offer the same services for prior authorization despite their network status with the patient.

Response: This rule makes no distinction between in-network and out-of-network providers with regard to making prior authorization information available through the Patient Access API. Regardless of the requesting provider's network status, the required information must be shared with patients. We understand that it is important for patients to know whether the provider they are seeing is in their payer's network, but we do not believe that the appropriate place for that information is with prior authorization information. Furthermore, the FHIR API technical specifications and IGs for the Patient Access API are not built to include information on a provider's network participation. We note that in the CMS Interoperability and Patient Access final rule (85 FR 25563), we required MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities to build and maintain a Provider Directory API. We encourage developers to integrate within their apps network information from payers' Provider Directory APIs for easy patient access.

To the extent that a provider's network status may increase a patient's out of pocket costs, we encourage payers to inform patients before they receive items or services from an out-of-network provider to the extent that applicable programmatic requirements do not already require the payer to do so.

Comment: A commenter recommended that a log of all instances that a patient's data was transferred via the Provider Access and Payer-to-Payer APIs should also be documented and accessible under the Patient Access API.

Response: We did not propose that payers must make that information available via the Patient Access API but encourage payers to do so for transparency with respect to when and with whom a patient's data are being shared. We will consider proposing to require this in future rulemaking.

iii. Timeline for Data Sharing

We proposed to require impacted payers to make available, via the Patient Access API, information about prior authorization requests and decisions for items and services (excluding drugs) to patients no later than 1 business day after the payer receives the prior authorization request or there is another status change for the prior authorization. Examples of status changes include: a 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. We expect that impacted payers use a variety of terminology, but, generally, any meaningful change to the payer's record of the prior authorization request or decision will require an update to the information available to the patient.

We proposed 1 business day as the appropriate timeframe because patients need timely access to the information to understand prior authorization processes and their available care options. As discussed further in section II.D. of this final rule, we proposed to require payers to make much of the same information about prior authorization requests and decisions available via the Prior Authorization API during the decision-making process. In addition, we stated that because impacted payers would be required to have the ability to exchange prior authorization information electronically, it would be reasonable for them to share prior authorization information with patients within 1 business day of any update to the prior authorization request or decision.

Comment: Many commenters expressed that the prior authorization process is opaque and burdensome to patients. Commenters stated that patients often wait for approval for critical items and services without status updates from their payer. Those commenters voiced support for the proposed requirement that payers make prior authorization information, including decision status and documentation information, available through the Patient Access API within 1 business day after the payer receives the request. Multiple commenters noted that this will provide greater transparency with respect to the prior authorization process.

Response: We appreciate commenters confirming that our proposed policies would ease the burden of prior authorization processes and benefit patients and providers. We agree that timely access to information about their prior authorizations is important to increase transparency and ensure that patients understand their care and coverage.

Comment: Multiple commenters, specifically payers, noted that the proposed 1 business day window may not be operationally feasible for payers. A commenter noted that, to implement this requirement, payers would need to develop an interface to move prior authorization data between multiple internal systems, which will be especially difficult for requests submitted in a non-electronic format. Other commenters noted business process and operational challenges that would make 1 business day difficult and burdensome, such as the time to manually assess whether they can legally make the information available via the Patient Access API under applicable state law. A commenter stated that 1 business day would not be feasible for Medicaid agencies due to the necessary updates to the Medicaid Management Information System (MMIS) systems.

Many commenters recommended that CMS instead consider requiring a 2 business day response requirement. A commenter recommended extending the proposed requirement to 2 business days until electronic Prior Authorization APIs are widely adopted and proven, and only then consider a 1 business day requirement. Another commenter recommended that CMS extend the timeframe window to 7 calendar days. Some commenters noted that although the prior authorization process would be automated by the implementation of the Prior Authorization API, they recommend extending the 1 business day timeframe for the Patient Access API to match the period a payer has to make a determination on the prior authorization.

Response: We appreciate commenters' perspectives regarding the feasibility of a 1 business day timeframe. Per the comments we received, the most significant barrier to the 1 business day timeframe we proposed was the proposed requirement to include unstructured documentation with prior authorization information. As discussed previously, we are not finalizing a requirement to make available unstructured prior authorization documentation via the Patient Access API. That exclusion from the data required to be made available will reduce the amount of data translation and transformation required to have data available via the Patient Access API. In addition, as discussed in section I.D., we are delaying the compliance dates by 1 year from our proposed 2026 to 2027 in order to give impacted payers additional time to make system changes necessary to meet the requirements of this final rule. We acknowledge that this may be particularly challenging for Medicaid and CHIP agencies based on existing MMIS systems. As discussed in section II.E. of this final rule, expenditures for required changes to states' MMIS or other state systems may be eligible for enhanced Federal financial participation. That funding may be available, not just for systems and processes that directly contribute to data available via the Patient Access API, but for other systems, such as those that track prior authorization requests and decisions. We also note that the Prior Authorization API discussed in section II.D. will greatly facilitate the movement of structured prior authorization data. Payers, including Medicaid and CHIP, should consider levers for promoting its usage by their providers.

After reviewing comments, we believe that between the changes to the data that must be shared and the additional implementation time, payers will be able to make necessary changes to meet these requirements by the finalized compliance dates. Therefore, we are finalizing the timeframe as proposed and are requiring payers to make prior authorization information available via the Patient Access API within 1 business day of receiving a request. Impacted payers must update prior authorization information made available via the Patient Access API within 1 business day of any status change.

Comment: Multiple commenters recommended that CMS retain the proposed 1 business day timeframe for prior authorization requests received via the Prior Authorization API but extend the timeframe for prior authorizations received through other channels (for example, by proprietary portal, fax, or phone). A commenter noted that, in the dental field, not all prior authorizations are submitted electronically. An additional commenter noted this timeframe does not provide impacted issuers adequate time to transfer information received by alternate methods (phone, fax) to interoperable, electronic formats. A commenter stated that the turnaround is not operationally feasible if the information is not received in a standardized format.

Response: As discussed in the previous section, we are finalizing our proposal with a modification to require that only structured documentation related to prior authorizations be made available via the Patient Access API. We believe this modification will, in large part, address this issue. Payers will not be required to convert documentation from non-electronic or non-standardized prior authorization requests into standardized data that can be available via the Patient Access API. However, by requiring only the structured data elements, including documentation, and not unstructured documents or images, we believe that this will streamline that conversion process and make the 1 business day timeline feasible for payers.

Comment: A commenter recommended that CMS create flexibility for delays between a provider sending the request and the payer's receipt. Another commenter recommended that CMS finalize a policy that the 1 business day timeline for making prior authorization data available via the Patient Access API begins only once the payer has information adequate to adjudicate the prior authorization request, as defined by payers' prior authorization policies. The commenter noted that some payers may require additional time to gather the information and perform any necessary data transformation to the FHIR standards. Similarly, another commenter recommended that the 1 business day requirement only applies after a request is received via the X12 278 transaction standard or Prior Authorization API electronic transaction that passes validation. Another commenter recommended that CMS require information about prior authorization be made available no later than 1 business day after a payer makes a decision.

Response: Our proposal was for the 1 business day timeframe to begin when the payer receives the prior authorization request. We are not requiring payers to share information that they do not possess. However, we disagree with the commenters' suggestions that the 1 business day timeline should begin when the payer has sufficient information to adjudicate a prior authorization request, or an adjudication has been made. A payer could not know whether there is sufficient information in the request to make a decision before the request is reviewed. As other commenters noted, it is critical that patients know that a payer has received the prior authorization request made on their behalf, even if it has not yet been reviewed or adjudicated. In section II.D., we are finalizing a policy that requires certain payers to make a decision within 7 calendar days for standard requests and 72 hours for expedited requests. It may take a payer several days to review a prior authorization request, and not having any status updates during that time would leave patients and providers in limbo.

We did not propose and are not finalizing a requirement that the timeline for making data available only applies to prior authorization requests received via an electronic HIPAA-compliant X12 278 transaction and/or FHIR transaction. We know that payers currently support a variety of modalities for providers to submit prior authorization requests, including online portals, phone, and fax. We believe that patients should have access to their prior authorization data within the same timeframe, regardless of how the prior authorization request was submitted. Because we are not finalizing the requirement to include unstructured documentation, receiving documentation in an unstructured format as part of a request will not hamper or delay a payer's ability to make the required prior authorization data available through the Patient Access API. A HIPAA-compliant X12 278 transaction is, by definition, composed of structured data, which must be made available through the Patient Access API, though attachments to such a transaction are likely unstructured documentation. Finally, we note that if the payer receives a request that does not pass validation or cannot be processed for some other reason, this could be an acceptable status to provide. If a payer's system fails to receive such a request, we cannot expect the data to be made available via the Patient Access API.

Comment: A commenter recommended that CMS require providers to respond to payers' requests for information within a certain timeframe and include information on provider response timeliness in the Patient Access API.

Response: We did not propose a timeline for providers to respond to payers' requests for additional information. However, it is entirely appropriate for a prior authorization status to be “waiting for additional information from provider” or similar. That would indicate to the patient that the provider must take some action to receive approval of the prior authorization, which would allow them to follow up with the provider to ensure that is done in a timely manner.

Comment: A couple of commenters requested clarification about the relationship between our Patient Access API requirements and ONC's information blocking regulations at 45 CFR part 171. Specifically, commenters questioned the implications of the information blocking regulations if payers also meet the definition of a health information network (HIN) or HIE at 45 CFR 171.102. They questioned whether our timeline requirement is compatible with the “21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program” final rule (85 FR 25642) (ONC Cures Act final rule), which the commenter explained requires information to be made available to the patient “without delay.”

Response: Any impacted payer should consider reviewing the ONC Cures Act final rule to determine whether they are an actor (as defined at 45 CFR 171.102) and to ensure they are complying with any applicable information sharing policies. The information blocking regulations (45 CFR part 171) are based on separate statutory provisions (see 42 U.S.C. 300jj–52), unrelated to our authority to issue this rule. We encourage commenters to address questions or complaints regarding information blocking to ONC.

We work closely with ONC and our other Federal partners to ensure that our regulations do not place conflicting requirements or unnecessary burdens on entities that are regulated by more than one Federal agency. However, comments specific to the information blocking regulations or other regulations issued by ONC are outside the scope of this rule. Additional information is available from the Information Blocking page of ONC's website: https://www.healthit.gov/topic/information-blocking.

iv. Length of Prior Authorization Data Availability

We proposed to require that information about prior authorizations be available via the Patient Access API for as long as the authorization is active and at least 1 year after the last status change. We note that, under the proposal, information on denied and expired prior authorizations would be available for at least 1 year after expiring or being denied. We did not propose to require payers to share a patient's full prior authorization history because that could comprise a significant amount of information that may no longer be clinically relevant. Claims, encounter, and clinical data can provide valuable information about a patient's health history. With those data available through the Patient Access API, we believe that process-related information about long-expired or denied prior authorizations will be irrelevant. Also, as payers' prior authorization policies may change over time, that information has a limited lifespan of usefulness to a patient's current care. At the same time, the API should include information about all active authorizations for as long as they are active, and, therefore, may include information related to ongoing care.

Comment: A majority of commenters supported CMS's proposal to require prior authorization information to be available via the Patient Access API for as long as the authorization is active and for 1 year after the last status change. Commenters opined that this timeframe balanced the benefits of data availability and the burden of maintaining data.

Some commenters suggested that CMS require payers to make prior authorization information available through the Patient Access API for longer than 1 year after the last status change. For example, some commenters suggested 3 years and others 5 years as the appropriate period to make information available after the last status change. Other commenters recommended that CMS require payers to make all prior authorization information available via the Patient Access API until 1 year after the patient is no longer covered by that payer. Those commenters stated that historical prior authorization information may yet be relevant to a patient's care or could create a record for patients to demonstrate that they face repeated barriers in accessing care or receiving coverage. Finally, another commenter suggested that those data may be important for long-term treatment that exceeds 1 year.

Response: We continue to believe that 1 year after the last status change is the appropriate amount of time to require payers to make historical prior authorization information available to patients through the Patient Access API. There may be other requirements outside the scope of this rulemaking that require certain payers to make health care records available to individuals over a longer time period. Further, this rulemaking does not address the record maintenance requirements that apply to impacted payers. We only address the timeframe during which certain data must be made available through specific APIs. While background information may impact and improve patient care, we believe that the availability of claims and clinical data are more important to patients and providers than information about prior authorizations that have expired or been denied. In fact, a patient's claims or encounter data are likely to include any items or services that were subject to a past prior authorization. As finalized in the CMS Interoperability and Patient Access final rule, and as modified by this final rule, payers are also required to make available through the Patient Access API any claims and encounter data, and all data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI), which includes clinical data, maintained by the impacted payer with a date of service on or after January 1, 2016.

As discussed previously, some commenters stated that including prior authorization information in the Patient Access API could lead to information overload and confusion for patients. While we do not believe that to be the case for active and recent prior authorizations, it may be so if patients were presented with a large amount of historical prior authorization data that may no longer be relevant. Therefore, we believe that 1 year is the appropriate timeframe for requiring prior authorization data to be available via the Patient Access API. We emphasize that for ongoing long-term care, any active prior authorizations must be included, even if they have been in that status for more than 1 year. Furthermore, we encourage payers to make these prior authorization data available for longer than 1 year if they believe it adds value to patients, providers, or themselves and their own processes.

b. Interaction With HIPAA Right of Access Provisions

Previous CMS interoperability proposals have elicited numerous comments regarding the interaction between the Patient Access API and HIPAA Privacy Rule individual right of access. Per 45 CFR 164.524, an individual patient generally has a right of access to inspect and obtain a copy of PHI about themselves in a designated record set for as long as the PHI is maintained in the designated record set by a covered entity. This includes the right to inspect or obtain a copy, or both, of the PHI. Our Patient Access API policies complement that right by requiring payers to make available—through a standards-based and interoperable FHIR API (that is, the Patient Access API)—PHI that patients already have a right to access. It is critical that individuals have access to their own health information and the ability to share it with others who are involved in their care, particularly when it could involve care coordination between providers or prior authorization.

Consistent with the HIPAA Privacy Rule, we believe that it behooves us to require all impacted payers to have the capability to provide individuals' PHI via an industry standard FHIR API, so that patients can access their data through apps of their choice. We believe that, in addition to the other benefits described in this final rule, ensuring that patients can receive their PHI in a standard, interoperable format that they can use with the latest technologies will reduce instances of an individual requesting PHI in an electronic format that is not readily producible, which could reduce costs and burden for patients and payers.

In the CMS Interoperability and Patient Access final rule, we established that the only reason payers could deny API access to a patient's preferred health app is if it would present an unacceptable level of risk to the security of PHI on the payer's system. These risks include, for example, insufficient authentication or authorization controls, poor encryption, or reverse engineering. The payer must make that determination using objective, verifiable criteria that are applied fairly and consistently across all apps and developers.

As we discussed in the CMS Interoperability and Patient Access final rule (85 FR 25518), disagreement with the patient about the worthiness of a health app as a recipient of patient data, or even concerns about what the app might do with the requested data, are not acceptable reasons to deny an individual's request. Impacted payers may offer advice to patients on the potential risks of permitting an app or entity access to the patient data required to be made available via the Patient Access API. However, such efforts generally must stop at education and awareness or advice related to a specific app. Payers can inform the patient that the patient may not want to allow an app to access their data without a clear understanding of how that app may use their data, including how the patient's personal data would be used or sold (a possibility for apps that are not covered entities or business associates under the HIPAA Privacy Rule and the Security Standards for the Protection of Electronic Protected Health Information [the Security Rule]). For instance, if a payer learns that a particular app has publicly known privacy or security vulnerabilities, they could inform patients who use that app to access their data of those known vulnerabilities. Per our policies finalized in the CMS Interoperability and Patient Access final rule, if a patient still wants to use the app, or does not respond to the payer's warning, the impacted payer is required to share their data via the API, absent an unacceptable security risk to the payer's own system. For more information on this ability to inform patients, see the CMS Interoperability and Patient Access final rule at 85 FR 25550. Again, the finalized policies in this rule do not affect or alter any obligations under the HIPAA Privacy and Security Rules.

While FHIR itself does not define security-related functions, when used in combination with appropriate security controls (such as authentication and access control), a FHIR API can and should be implemented and maintained to comply with the HIPAA Security Rule, at 45 CFR parts 160 and 164, subparts A and C, for secure data exchange. Furthermore, a covered entity is not liable for what happens to the PHI once the designated third party receives the information as directed by the individual.

Our policies in this section address how an impacted payer must make patients' data available to them. However, we do not have the authority to regulate health apps that individuals may wish to use, or what those apps do with patient data. Regardless of whether the HIPAA Privacy and Security Rules apply to a health app, and even where they do not apply, other Federal laws such as the Federal Trade Commission (FTC) Act may apply. Under section 5 of the FTC Act (15 U.S.C. 45(a)), the FTC has authority to challenge unfair or deceptive trade practices, including those related to the privacy and security of personal health information that apps collect, use, maintain, or share. For example, if an app discloses an individual's health information in a manner inconsistent with the app's privacy policy, terms of use, or an individual's reasonable expectations, or fails to take reasonable measures to assess and address privacy or data security risks, the developer of that app may be violating the FTC Act. The FTC has applied its section 5 authority to a wide variety of entities, including health apps. For more information about what laws may apply to health apps, see https://www.ftc.gov/business-guidance/resources/mobile-health-apps-interactive-tool.

The FTC also enforces the FTC Health Breach Notification Rule (16 CFR part 318), which applies to most health apps and similar technologies that are not covered entities or business associates under HIPAA and, therefore, are not subject to the HIPAA Breach Notification Rule (45 CFR 164.400 through 164.414). The FTC's Health Breach Notification Rule sets forth steps that entities covered by that rule must follow when there has been a breach of unsecured personal health information. Any violation of the FTC's Health Breach Notification Rule is treated as an unfair or deceptive act or practice under section 18 of the FTC Act and is subject to civil penalties of up to $50,120 per violation per day. In 2023, the Commission brought its first enforcement actions under the Health Breach Notification Rule.

c. Patient Access API Metrics

We proposed to require impacted payers to report metrics to CMS on an annual basis about how patients use the Patient Access API, in the form of aggregated, de-identified data. We stated that those reports would help CMS better understand whether the Patient Access API requirement is efficiently and effectively ensuring that patients have access to their health information and whether payers are providing that required information in a transparent and timely way. Additionally, we stated that aggregated usage data from every impacted payer would help us evaluate whether the Patient Access API policies are achieving the desired goals. We also stated that gathering this information would help us to provide targeted support or guidance to impacted payers, if needed, to help ensure that patients have access to their data and can use their data consistently across the impacted payer types.

Specifically, we proposed that impacted payers annually report—

• 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 are transferred more than once via the Patient Access API to a health app designated by the patient.

Tracking multiple data transfers would indicate repeat access, showing that patients are either using multiple apps or allowing apps to update their information over the course of the year. While data transfers may not indicate to what extent patients are using apps to manage their health care, it would be a preliminary indicator of interest in the technology.

Comment: A majority of commenters supported CMS's proposal to require impacted payers to report aggregated, de-identified data metrics on how patients use the Patient Access API to CMS annually.

Response: We thank commenters for their feedback.

Comment: Commenters recommended that these metrics only be used to evaluate the effectiveness of CMS's policies and to assess whether patients are using the Patient Access API in a volume sufficient to justify the administrative burden of existing and future requirements. A commenter stated that these metrics would not reflect factors within a payer's control and recommended that CMS work with FTC to have third-party app developers directly report these metrics. Another commenter warned that these metrics may not account for patient preferences for portals or other resources aside from apps. A commenter recommended that neither CMS nor state Medicaid agencies attempt to regulate or oversee the usage of third-party apps by their users. Another commenter supported the annual public reporting of Patient Access API metrics provided that this information is not made publicly available in a manner that identifies specific payers or apps.

Response: We acknowledge that patient app usage is generally outside the control of payers, though education can help patients make informed decisions. We emphasize that we proposed and will be collecting these metrics, not to evaluate or compare payers, but to help us understand how patients are using apps, the effectiveness of our Patient Access API policies, and to assess potential future rulemaking.

Making data available via a FHIR API gives patients a wider range of options to access their data. Ultimately, patients must decide what method of accessing their health information is most useful to them. If patients prefer to use online portals, rather than apps, that could inform future rulemaking. However, to understand how patients are accessing data made available through the API using a heath app designated by the patient, we must have access to the relevant data. We do not intend to interfere with how a patient uses a third-party app (and neither should impacted payers, including state Medicaid agencies), but to provide them options to access their data in the way that best suits them. As discussed previously, the only permissible reason to deny or discontinue an app's access to an API is if the payer reasonably determines that the app presents an unacceptable level of risk to the security of PHI on the payer's systems.

We do not have the authority to require app developers to report usage metrics, and even if we did collect data from them, it would not provide the information that we are seeking, as developers would not know a patient's health coverage status. For instance, a developer could tell us that an individual connected to a specific payer organization but would not be able to report whether the patient is covered under by an MA plan or QHP. Finally, as noted in the proposed rule, we do not intend to publicly publish these Patient Access metrics in a way that identifies specific payers or apps.

Comment: A few commenters suggested that CMS establish an easy-to-use standardized format for reporting Patient Access API metrics.

Response: We appreciate the request from commenters and are finalizing a modification to our proposed regulatory text to require reporting in a specified form and manner to ensure consistency between impacted payers. We will issue specific format and process guidance for submitting Patient Access API metrics before reporting is required.

Comment: Most commenters supported CMS's proposed metrics, as they could provide valuable information regarding Patient Access API adoption and use.

Commenters voiced widespread support for the first metric to measure usage of the Patient Access API. Support for the second metric was mixed, with multiple commenters questioning its value to the API's policy evaluation. Commenters warned that this metric would be affected by many external factors, including the user experience of the app, as opposed to acts of the payer. Another commenter stated that the second measure would not provide meaningful insight into patient use patterns, and instead suggested that CMS should solicit information about usage patterns from app developers.

Response: We understand that the metric on repeat usage may not provide a high level of statistical validity, which is why we are not requiring these metrics to be reported publicly. However, it is important for CMS to understand how many patients are using the Patient Access API and whether they have simply tried it once or are invested in using health apps to manage their data. These findings will help us monitor our interoperability policies and plan for the future. We did not receive any comments that indicated that submitting either of these metrics would be a significant burden for impacted payers.

We acknowledge that these metrics could be affected by a plethora of external factors outside of payers' control. As noted previously, we are collecting these metrics to better enable us to evaluate our policies in this area. As we do not have regulatory authority over app developers, we did not propose to impose reporting requirements on them.

Comment: A commenter requested that CMS explain what constitutes a “unique patient” so that payers can identify unique patients in the same manner, so the results are not varied.

Response: We define a unique patient by the record of the individual covered by the payer's benefits, not by the individual accessing the data. Therefore, if both a patient and their personal representative access their data, that will only be counted as usage by a single patient for the purpose of these metrics.

i. Reporting Level

We proposed to require MA organizations to report these data to CMS at the organization level, state Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities to report at the state level, and QHP issuers on the FFEs to report at the issuer level. We solicited comment on whether we should require payers that administer multiple plans under a single contract to report these data to CMS at the contract level. We also solicited comment on an alternative final policy that would permit MA organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to report aggregate data at higher levels (such as the parent organization level or all plans of the same type in a program).

Comment: We received comments espousing a range of opinions on the appropriate level of reporting for impacted payers.

Specifically for MA organizations, multiple commenters recommended a more granular metric reporting level, noting that reporting Patient Access API metrics at the plan level would better drive plan-specific improvement efforts and be more consistent with current industry practice. Conversely, a commenter stated that organization level would simplify report preparation since some MA organizations have ten or more separate plan contracts with CMS. A commenter recommended that CMS not require reporting at the more granular contract level as any metrics based on small populations could lead to skewed data.

Many commenters supported our proposed reporting levels for Patient Access API use metrics for state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs.

On the other hand, a commenter recommended that payers be required to report metrics at the county level, rather than the state level. Another commenter warned that too much aggregation can make data meaningless and stated that payers should prioritize data metrics that can be acted upon effectively. Conversely, a commenter recommended that CMS allow consolidation of Patient Access API use metrics at the holding or parent company level, which would aggregate that company's MA plans, Medicaid managed care plans, CHIP managed care entities, QHPs, and commercial plans. Another commenter suggested that CMS begin collecting metrics at a more aggregated level and wait to implement more refined data segmentation as a clear use case arises.

Response: Upon further consideration, we determined that contract level is the more appropriate reporting level for MA organizations. Contract-level data are aggregated data that are collected from the plan benefit packages (PBPs) offered under an individual contract; it is specific to the contract to which it corresponds. CMS already requires MA organizations to annually report some contract-level data about their organization determinations to the agency. A consistent approach of contract-level reporting in the MA program will give us useful information while limiting payer burden. By requiring contract-level reporting for these metrics, we ensure that the format of these reported data remain consistent with other data that MA organizations are required to report. There could be value to requiring MA organizations to report on a plan level in the future to get more discrete data. However, at this time, we believe that the burden of requiring MA organizations to report at the plan level, and the small sample sizes that some plans would have, outweigh the benefits of that information.

We agree that requiring Medicaid managed care plans and CHIP managed care entities to report at the state level and QHP issuers on the FFEs to report at the issuer level balances the reporting burden and the meaningfulness of the data. Aggregating by holding company would provide data that are not particularly useful. Many commenters recommended that we use this information to monitor disparities in data access, which would be hindered without disaggregation between MA, Medicaid, CHIP, and QHPs. Similarly, we do not believe that additionally segmenting data into smaller geographic areas would provide useful information now, though in the future we may consider whether it would be beneficial.

We note that CMS programs may assess whether to collect more detailed metrics than we are finalizing here. For instance, we may consider requiring in future rulemaking that MA plans report at a more discrete level. Similarly, should a state Medicaid or CHIP agency believe it would be beneficial, they may require additional metrics in their managed care contracts.

Comment: A few commenters requested that we explain whether integrated care plans for dually eligible individuals, such as fully integrated dual eligible special needs plans (FIDE SNPs), should report consistent with MA organizations, at the contract level, or with Medicaid managed care plans, at the plan level.

Response: An integrated care plan generally combines a dual eligible special needs plan (D–SNP), which includes FIDE SNPs and highly integrated dual eligible special needs plans (HIDE SNPs)—both as defined at 42 CFR 422.2, and a Medicaid managed care plan offered by the same parent organization. D–SNPs are a type of MA plan designed to meet the needs of individuals who are dually eligible for Medicare and Medicaid, also known as dually eligible individuals. Therefore, an MA organization will report information about Patient Access API usage by its D–SNP enrollees to CMS at the MA organization's contract level. The affiliated Medicaid managed care plan will report information about Patient Access API usage by its enrollees to CMS at the plan level.

We understand that this means an organization that offers an integrated product for dually eligible individuals (for example, a FIDE SNP), may report twice and in different ways for the same population. We do not believe this duplication outweighs the benefits of capturing the data as we proposed, but we may consider future rulemaking to separate reporting for integrated D–SNPs from the overall MA organization.

ii. Annual Reporting

We proposed that payers must report metrics from the previous calendar year to CMS by March 31st of each year. Under our proposal, in the first year the requirement would be applicable, payers would report CY 2025 data by March 31, 2026. A new MA organization, Medicaid managed care plan, CHIP managed care entity, or QHP issuer on the FFEs would naturally have no data to report in its first year of existence and would be required to report data following its first full calendar year subject to the Patient Access API requirement.

Comment: Multiple commenters expressed support for CMS's proposal to require payers to share patient use metrics annually starting with CY 2025 to be reported to CMS by March 31, 2026. Some commenters recommended that we delay the first year of the reporting requirement to CY 2026, which would be reported no later than March 31, 2027. Another commenter suggested that we delay the reporting deadline because a technical solution would need to be in place by the end of late 2024 to have metrics for CY 2025 to report in March 2026.

Response: We note that per the CMS Interoperability and Patient Access final rule, impacted payers were required to implement the Patient Access API no later than January 1, 2021. The metrics that we proposed were not tied to the implementation of any other proposals in the CMS Interoperability and Prior Authorization proposed rule, including adding prior authorization information to the data available via the Patient Access API. Based on this rule's publication schedule, payers should have sufficient time to implement any necessary changes to report these metrics.

Comment: A majority of commenters supported the proposed annual reporting requirement, though multiple commenters recommended that CMS consider requiring payers to report Patient Access API metrics quarterly. A commenter recommended that as the popularity for Patient Access API grows, use metrics should be reported on a quarterly basis.

Commenters agreed that requiring payers to report data on API usage from the previous calendar year to CMS by March 31 provides an appropriate amount of time for payers to validate the data before submitting it to CMS.

Response: After reviewing the comments, we agree that annual reporting is the appropriate frequency for these metrics. Given that we are looking to understand the overall usage of third-party apps and any patterns between payers, we do not believe that the burden of requiring payers to report these metrics quarterly would improve our understanding of whether patients are accessing the Patient Access API. We may in the future consider proposing more frequent reporting or additional metrics, but for the two metrics we are finalizing now, we do not expect that it would be beneficial to require payers to report more often than annually.

iii. Public Reporting

In the preamble to our proposed rule, we stated that we do not plan to publicly report these metrics at the state, plan, or issuer level, but may reference or publish aggregated and de-identified data that do not include names of specific state agencies, plans, or issuers.

Comment: Some commenters recommended that CMS require payers to publicly report Patient Access API metrics, as they believe that health IT companies and developers would benefit from the information. Commenters stated that by making these metrics public, CMS can help patients and stakeholders better understand the impact of access APIs and help inform future innovations that promote patient access and future decision making. A commenter recommended that CMS consider publicly reporting plan-reported information at the state, plan, or issuer level.

Other commenters did not support CMS publicly reporting Patient Access API use metrics. Multiple commenters stated that this could provide inaccurate information and potentially reveal identifying information. A commenter cautioned that publicizing reports, particularly of the second proposed metric (the total number of patients whose data are transferred more than once to a specific third-party app), may give consumers an inaccurate portrayal of API success.

Response: There may be value to publicly reporting aggregated and de-identified data to give the public a sense of Patient Access API adoption across the industry. But we agree with commenters that, absent the proper context, those data could be perceived inaccurately or misleadingly. As discussed, some commenters expressed that there is currently low health app adoption among patients regardless of the type of payer. We also understand that low patient adoption does not necessarily indicate a lack of payer readiness or compliance. Therefore, until we are confident that these data can be presented in an easy-to-understand and meaningful way, we may publicly report aggregated and de-identified data, but will not include names of specific state agencies, plans, or issuers unless and until proposed through future rulemaking.

iv. Other Metrics

We requested comment on what other Patient Access API metrics we should consider requiring payers to report to CMS and/or make available to the public in future rulemaking. For instance, we solicited comments on whether payers could report aggregated demographic information, such as sex, race, age, ethnicity, and geographic data and whether that could help identify underserved populations or disparities in patient access to health data and, if so, policies that should be considered to promote equity. We also solicited comments on the potential benefits and burdens of requiring payers to report the names of all apps that patients have used to access the payers' API each year. We considered collecting this information, or requiring payers to make it public, not for the purpose of recommending or endorsing specific apps, but to review for best practices and evaluate patient ease of use.

Comment: Commenters provided many recommendations for additional Patient Access API metrics.

Response: We greatly appreciate the wide range of metric suggestions, such as indicators on demographic information, utilization, query management, successful requests, and barriers to accessing records. We will continue to research additional ways to evaluate the effectiveness of the API for consideration in future rulemaking.

d. Patient Access API Amendments

We proposed two minor terminology changes to the requirements finalized in the CMS Interoperability and Patient Access final rule (85 FR 25558). Unlike most of our proposals, we proposed that these amendments would take effect on the effective date of the final rule. We proposed these changes to explain terms but did not expect them to substantively change any current regulatory obligation.

First, we proposed to revise the description of the clinical data impacted payers must make available via the Patient Access API. These provisions, finalized in the CMS Interoperability and Patient Access final rule, currently require payers to make available “clinical data, including laboratory results” (85 FR 25536–40). We proposed to revise these paragraphs to specify that the data that payers must make available are “all data classes and data elements included in a content standard at 45 CFR 170.213.” That citation is to a content standard maintained by ONC of clinical data classes and data elements for interoperable health information exchange. Referring explicitly in the rule text to a data set in a standard at 45 CFR 170.213 will help avoid unnecessary confusion, as this reference will more clearly identify exactly what data must be available through the Patient Access API. Furthermore, this change brings us into greater alignment with the standards promulgated by ONC and used by certified health IT developers.

As versions of the USCDI evolve, there may simultaneously be multiple versions of the standard referenced at 45 CFR 170.213 (as both v1 and v3 are listed at the time of publication of this final rule). In the HTI–1 final rule, ONC finalized the adoption of USCDI v3 in 170.213 and finalized a January 1, 2026, expiration date for USCDI v1 (89 FR 1192). For the ONC Health IT Certification Program, this allows for a transition period between standards, and, during that time, health IT developers could incorporate updated standards versions within their systems and complete required certification. During such a period, when 45 CFR 170.213 includes more than one version of the USCDI standard, payers would be allowed to use any of the then-referenced content standards to meet the requirement to make clinical data available through the Patient Access API. If a standard has a listed expiration date (as USCDI v1 is currently listed to expire on January 1, 2026), payers would not be able to be use it after expiration.

Second, we proposed to revise the language previously finalized for denial or discontinuation of a health app's access to the API. Currently, the rules require impacted payers to make a determination to deny or discontinue access to the Patient Access API using objective, verifiable criteria that are applied fairly and consistently across all apps and developers through which “enrollees” or “beneficiaries” seek to access patient data. We proposed to change the terms “enrollees” and “beneficiaries” to “parties” for consistency with our proposal to apply this provision to the Provider Access, Payer-to-Payer, and Prior Authorization APIs. We stated that because parties other than patients, such as providers and payers, would be accessing these APIs, it would be more accurate to use the term “parties” rather than “enrollees” or “beneficiaries.” Those APIs are discussed further in sections II.B., II.C., and II.D. of this final rule.

Comment: All comments we received on these technical language proposals supported our effort to keep the Patient Access API required data aligned with ONC's standards. However, we did receive a variety of comments on the USCDI standard currently referenced at 45 CFR 170.213. Those comments are discussed in section II.G. of this final rule.

A commenter requested clarification on whether payers would be required to request information from providers to fill any data classes and data elements of the standard at 45 CFR 170.213 that are missing within their records. Similarly, another commenter requested that CMS explain that the requirement to provide claims and encounter data within 1 business day applies only to information available at the time of the request.

Response: In the CMS Interoperability and Patient Access final rule, we defined “maintain” to mean the payer has access to the data, control over the data, and authority to make the data available through the API (85 FR 25538). Under that existing regulation, payers are required to share data that they maintain as part of their normal operations. Nothing in this final rule will change that existing policy; payers are not required to reach out to providers or other entities to gather data that the payer does not already maintain, if it is not part of their normal operations, to share via the Patient Access API. We thank commenters for their feedback and are finalizing this proposal without modification.

We note that we are not modifying the Patient Access API applicability date for MA at 42 CFR 422.119(h), for Medicaid FFS at 42 CFR 431.60(h), for CHIP FFS at 42 CFR 457.730(h), and for QHP issuers on the FFEs at 45 CFR 156.221(i) because these amendments do not substantively change any existing requirements finalized in the CMS Interoperability and Patient Access final rule.

e. Medicaid Expansion CHIP Programs

In the CMS Interoperability and Prior Authorization proposed rule, we discussed implementation for states with Medicaid Expansion CHIP programs (86 FR 76279). See section II.E. of this final rule for that complete discussion, including a summary of public comments received and our final action statement.

f. Specific CHIP-Related Regulatory Framework

For CHIP, we proposed amendments to 42 CFR 457.1233(d) that would align separate CHIP managed care API requirements with the Medicaid managed care plan API requirements, rather than with the CHIP FFS API requirements. In the CMS Interoperability and Patient Access final rule (85 FR 25559), we finalized requirements for separate CHIP managed care entities at 42 CFR 457.1233(d). API requirements for CHIP managed care entities were codified at 42 CFR 457.1233(d)(2) and (3) through cross-references to CHIP FFS program requirements at 42 CFR 457.730 and 457.760, respectively. On November 13, 2020, we published a final rule titled “Medicaid Program; Medicaid and Children's Health Insurance Program (CHIP) Managed Care” (85 FR 72754). In that rule, we removed 42 CFR 457.1233(d)(1) through (3), and, at 42 CFR 457.1233(d), cross-referenced to Medicaid managed care regulatory requirements at 42 CFR 438.242. Therefore, the policies in the CMS Interoperability and Patient Access final rule (85 FR 25559) are applicable to separate CHIP managed care entities per 42 CFR 457.1233(d) through a cross reference to Medicaid managed care at 42 CFR 438.242. We apply the API requirements in this final rule to separate CHIP managed care entities through the existing cross reference at 42 CFR 457.1233(d) to Medicaid managed care at 42 CFR 438.242.

3. Other Requests for Comment

We requested comment on a variety of topics on which we did not make specific proposals but are reviewing for future consideration. We appreciate commenters' submissions regarding the following:

• How we could and should apply these requirements to Medicare FFS and its existing prior authorization requirements and standards.
• What policy levers we might have to create norms or best practices for privacy policies by health app developers.
• How we could leverage ONC's TEFCA or other HHS HIE initiatives to facilitate secure interoperable data exchange with health apps.
• The availability of apps that are accessible to individuals with disabilities, availability of apps in a multitude of languages to ensure that individuals with limited English proficiency can understand the information provided, and availability of apps at appropriate literacy levels and in plain language.

4. Final Action

After considering the comments received, and for the reasons discussed in the CMS Interoperability and Prior Authorization proposed rule and our response to those comments (as summarized previously), we are finalizing our proposals with the following modifications:

• Impacted payers must make information about prior authorization requests and decisions available via the Patient Access API beginning 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs), rather than in 2026.
• Impacted payers are not required to share the quantity of items or services used under a prior authorization via the Patient Access API.
• Impacted payers are not required to share unstructured documentation related to prior authorizations via the Patient Access API.
• MA organizations must report Patient Access API metrics at the contract level rather than at the proposed organizational level.

See further discussion for exact details of the final requirements for impacted payers.

Specifically, we are finalizing a requirement that, beginning 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs), impacted payers must make the all of following information available about prior authorization requests and decisions (excluding for drugs) available via the Patient Access API:

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

We are finalizing the requirement that impacted payers make this information about prior authorizations available no later than 1 business day after the payer receives a prior authorization request and must update that information no later than 1 business day after any status change. This information must be available for the duration that the authorization is active and at least 1 year after the prior authorization's last status change.

We are finalizing a requirement that, beginning 2026, impacted payers must annually report Patient Access API metrics to CMS in the form of aggregated, de-identified data. Specifically, by March 31, MA organizations at the contract level, state Medicaid and CHIP FFS programs, Medicaid managed care plans and CHIP managed care entities at the state level, and QHP issuers on the FFEs at the issuer level must report the following metrics: (1) the total number of unique patients whose data are transferred via the Patient Access API to a health app designated by the patient; and (2) the total number of unique patients whose data are transferred more than once via the Patient Access API to a health app designated by the patient. 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.

We are finalizing, as of the effective date of this final rule, the replacement of “clinical data, including laboratory results” with “all data classes and data elements included in a content standard at 45 CFR 170.213” in the required content for the Patient Access API. We are also finalizing, as of the effective date of this final rule, to change the terms “enrollees” and “beneficiaries” to “parties” at 42 CFR 422.119, 431.60, and 438.62 and 45 CFR 156.221.

These final policies apply to MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs at the CFR sections listed in Table B1.

5. Statutory Authorities for the Patient Access API Policies

We note that we received no public comments on the statutory authorities for our Patient Access API policies.

a. MA Organizations

For MA organizations, we proposed these new requirements and the revisions to current requirements under our authority at sections 1856(b)(1) of the Act (to promulgate regulations implementing MA organization standards, including the requirements in section 1852(h) of the Act), and 1857(e)(1) of the Act (to add contract terms determined by the Secretary to be “necessary and appropriate”). Section 1856(b)(1) of the Act requires the Secretary to establish regulatory standards for MA organizations that are consistent with and carry out Part C of the Medicare statute, Title XVIII of the Act. Section 1852(h) of the Act requires that MA organizations have procedures in place to maintain accurate and timely medical records and health information regarding MA enrollees and to assure enrollees have timely access to such records and information. Our policy for the Patient Access API is to require access for enrollees to specified medical records and health information through a specific mechanism from the MA organization. The Secretary is authorized under section 1857(e)(1) of the Act to add new contract terms, including additional standards and requirements, for MA organizations that the Secretary finds necessary and appropriate and that are not inconsistent with Part C of the Medicare statute. The policies here meet this standard by addressing and facilitating access to enrollees' medical records and health information for the reasons identified in our discussions for each policy.

The policy in section II.A.2.a. of this final rule that will require MA organizations to make an enrollee's prior authorization requests and related clinical documentation available through the Patient Access API will allow these enrollees to have access to that information in a convenient, timely, secure, and portable way, which is in enrollees' best interests. This requirement is consistent with section 1852(h) of the Act, which requires MA organizations to assure enrollees timely access to their records and data that is maintained by MA organizations. To ensure that MA organizations meet modern-day patient expectations of transparency, efficiency, and timeliness when providing prior authorization data to enrollees, it is essential for CMS to ensure that each MA organization has a standardized system in place that offers enrollees access to their own data, including data that pertain to their prior authorizations, using existing and emerging technologies of their choice, specifically in this case, health apps. Therefore, making these data available through the Patient Access API is consistent with our programmatic authority to establish standards to implement section 1852(h) of the Act and could help patients be more informed about and active in their own care, which could potentially lead to better health outcomes.

Making this information available via the Patient Access API could help patients support the prior authorization process as well. Patients could see what information is needed and what information has been provided on their behalf to facilitate a prior authorization request. Patients could provide missing information needed by the payer to reach a decision. This could allow MA organizations to address prior authorization requests more promptly, streamlining this process, and thus simplifying prior authorization for the MA organizations. This could also improve an enrollee's experience with the process, by facilitating more timely and potentially more successful initial prior authorization requests. This, again, supports efficient operation and timely provision of information and services.

In addition, to ensure the requirements finalized in the CMS Interoperability and Patient Access final rule (85 FR 25558 through 25559) would be most effective, CMS finalized in this rule that MA organizations report specific metrics to CMS on patient use of the Patient Access API. Section 1857(e)(1) of the Act explicitly authorizes the adoption of additional reporting to CMS by MA organizations where necessary and appropriate. Here, these metrics would facilitate CMS's oversight, evaluation, and administration of patient health data access in the Part C program and, therefore, this data collection is necessary and appropriate to adopt.

In alignment with HHS's priorities and goals, CMS is focused on putting patients at the center of their own health care and ensuring that patients have secure access to their health information. We believe these policies are critical and appropriate to ensure that MA organizations stay abreast of industry standards and continue to offer enrollees not only quality coverage but also a quality customer experience.

b. Medicaid and CHIP

Our finalized requirements in this section for Medicaid managed care plans and Medicaid state agencies fall generally under our authority in sections 1902(a)(4), 1902(a)(7), 1902(a)(8), and 1902(a)(19) of the Act. Section 1902(a)(4) of the Act requires that a state Medicaid plan provide such methods of administration as are found by the Secretary to be necessary for the proper and efficient operation of the state Medicaid plan. Section 1902(a)(8) of the Act requires states to ensure that Medicaid services are furnished with reasonable promptness to all eligible individuals. Section 1902(a)(19) of the Act requires states to ensure that care and services under a Medicaid state plan are provided in a manner consistent with simplicity of administration and the best interests of the recipients.

In addition, section 1902(a)(7) of the Act requires that states must provide safeguards that restrict the use or disclosure of information concerning Medicaid applicants and beneficiaries to purposes that are directly connected with the administration of the Medicaid state plan. The implementing regulations at 42 CFR part 431, subpart F, for section 1902(a)(7) of the Act list purposes that CMS has determined are directly connected with administration of Medicaid state plans (42 CFR 431.302) and require states to provide safeguards meeting certain requirements to restrict uses and disclosures of Medicaid beneficiary data, including requirements about releasing applicant and beneficiary information at 42 CFR 431.306.

Our policy to require that the prior authorization data described in this section be shared via the Patient Access API would be consistent with the requirement at section 1902(a)(7) of the Act, providing that states may share these data only for purposes directly connected with the administration of the Medicaid state plan. The data sharing policy for the Patient Access API would be related to providing services for Medicaid beneficiaries, a purpose listed at 42 CFR 431.302(c). As mentioned previously, giving a patient access to their own health information can make them a more active participant in ensuring they receive timely and appropriate care (for example, allowing them to monitor medications or access treatment history).

The finalized requirement to make information about prior authorization requests and associated documentation available through the Patient Access API is expected to allow beneficiaries to more easily obtain information about the status of prior authorization requests submitted on their behalf. Beneficiaries could potentially use that information to make more informed decisions about their health care, improve the efficiency of accessing and scheduling services, and, if needed, provide missing information that the state (or Medicaid managed care plan, if applicable) needs to reach a decision. Receiving missing information more quickly could enable more prompt responses from state Medicaid FFS programs and Medicaid managed care plans to prior authorization requests, thus facilitating more timely and successful prior authorizations. This would help states fulfill their obligations to provide care and services in a manner consistent with simplicity of administration and the best interests of the recipients and to furnish services with reasonable promptness to all eligible individuals. Improving the prior authorization process could also help improve the efficient operation of the state plan by potentially improving the speed and consistency of prior authorizations, which could, in turn, facilitate faster access to care for beneficiaries. In these ways, these policies are authorized under section 1902(a)(4), (8), and (19) of the Act.

Additionally, states must apply the safeguards described at 42 CFR 431.306 when sharing beneficiary data via the Patient Access API. We remind states that to meet the requirements of that regulation, states must have consistent criteria for release and use of information (which should comply with the finalized Patient Access API requirements), in accordance with 42 CFR 431.306(a). Access to information concerning beneficiaries must be restricted to persons who are subject to standards of confidentiality that are comparable to that of the state Medicaid agency, in accordance with 42 CFR 431.306(b). The permission requirement at 42 CFR 431.306(d), which requires that the state agency obtain permission from a family or individual, whenever possible, before responding to a request for information from an outside source, is not relevant to this policy, because any request for beneficiary information would be from Medicaid beneficiaries themselves and the apps that they are authorizing to receive their information. Beneficiaries are not “outside sources,” and, while apps might be outside sources, information is shared with an app through this API only if the beneficiary has verified their identity (through authentication protocols) and authorized the app to receive information. We do not believe that any of the other requirements at 42 CFR 431.306 are relevant because they cover data release and use in contexts outside of our policies in this section of the final rule. We note that while the beneficiary's permission is not required under 42 CFR 431.306(d) for the Patient Access API we discuss here, state or other laws may require such permission.

With respect to Medicaid managed care, and in addition to the general authorities cited previously mentioned regarding Medicaid programs, this policy will also help implement section 1932(b)(4) of the Act, which provides that each Medicaid MCO must establish an internal grievance procedure under which a beneficiary who is eligible for medical assistance may challenge the denial of coverage or payment for such assistance. CMS has traditionally extended requirements applicable to Medicaid MCOs to other Medicaid managed care plan types as efficient and proper methods of administration under section 1902(a)(4) of the Act to ensure that Medicaid beneficiaries have the same protections, benefits, and responsibilities regardless of the type of managed care plan in which they are enrolled. Allowing beneficiaries to access the status of their denied prior authorizations within 1 business day could enable beneficiaries to file appeals timelier and receive faster resolution. Enabling beneficiaries to monitor the status of prior authorization requests submitted on their behalf is also consistent with how section 1932(c) of the Act indicates that timely access to care should be assured for beneficiaries. Knowing within 1 business day that a prior authorization has been approved could enable a beneficiary to more promptly schedule or obtain care.

We also proposed to require state Medicaid agencies and Medicaid managed care plans to report Patient Access API metrics to CMS annually. These metrics will support CMS's oversight, evaluation, and administration of the Medicaid program, as it will allow us to evaluate beneficiary access to the Patient Access API. API usage could indicate that the policy is supporting program efficiencies and ensuring access to information in a timely and efficient way and in the best interest of beneficiaries, as intended, and as is consistent with section 1902(a)(4) and (19) of the Act. Additionally, section 1902(a)(6) of the Act requires Medicaid state plans to provide that the state Medicaid agency will make such reports, in such form and containing such information, as the Secretary may from time to time require. These metrics will serve as a report to evaluate the implementation and execution of the Patient Access API.

For CHIP, we finalized these requirements under the authority in section 2101(a) of the Act, which states that the purpose of Title XXI of the Act is to provide funds to states to provide child health assistance to uninsured, low-income children in an effective and efficient manner that is coordinated with other sources of health benefits coverage. This provision provides us with authority to adopt these requirements for CHIP because the finalized requirements increase patient access to their health information, which can improve the efficacy of CHIP programs, allow for more efficient communication and administration of services, and promote coordination across various sources of health benefits coverage.

We believe that requiring CHIP agencies, as well CHIP managed care entities, to make CHIP beneficiaries' prior authorization data and other standardized data available through standards-based APIs will lead to these beneficiaries accessing that information in a convenient, timely, and portable way. This improved access will help to ensure that services are effectively and efficiently administered in the best interests of beneficiaries, consistent with the requirements in section 2101(a) of the Act. We believe making patient data available in this format will result in better health outcomes and patient satisfaction and improve the cost effectiveness of the entire health care system, including CHIP.

These policies align with section 2101(a) of the Act in that they also will improve the efficiency of CHIP programs. For example, adding information about prior authorization requests to the Patient Access API will allow beneficiaries to easily obtain the status of prior authorization requests made on their behalf. This will in turn allow patients to make scheduling decisions and provide any missing information needed by a payer to reach a decision, which makes the prior authorization process more efficient, streamlining the prior authorization process.

Additionally, the safeguards for applicant and beneficiary information at 42 CFR part 431, subpart F, are also applicable to CHIP through a cross-reference at 42 CFR 457.1110(b). As discussed previously for Medicaid, giving CHIP beneficiaries access to their prior authorization statuses through the Patient Access API would be related to providing services to beneficiaries, which is described at 42 CFR 431.302(c) as a purpose directly related to state plan administration. Allowing beneficiary access to prior authorization statuses also conforms with provisions for beneficiary access to their records at 42 CFR 457.1110(e). We remind states that when they share beneficiary information through the Patient Access API, they must comply with the privacy protections at 42 CFR 457.1110 and the release of information provisions at 42 CFR 431.306.

Finally, by finalizing the requirement for state CHIP agencies and CHIP managed care entities to report Patient Access API metrics to CMS annually will help states and CMS understand how this API can be used to continuously improve the effectiveness and efficiency of state CHIP operations by providing information about its use, which is an indication of the API's uptake among patients, including how many only use it for a one-time setup consistent with 2107(b)(1) of the Act. The more we understand about the Patient Access API's usage, the better we can assess that the API is leading to improved operational efficiencies and providing information to beneficiaries in a way that supports their best interests.

c. Qualified Health Plan Issuers on the Federally-Facilitated Exchanges

For QHP issuers on the FFEs, we finalized these new requirements under our authority at section 1311(e)(1)(B) of the Patient Protection and Affordable Care Act, as amended by the Health Care and Education Reconciliation Act of 2010 (Pub. L. 111–148, enacted March 23, 2010, and Pub. L. 111–152, enacted March 30, 2010, respectively) (collectively referred to as the Affordable Care Act) which affords the Exchanges the discretion to certify QHPs if the Exchange determines that making available such health plans through the Exchange is in the interests of qualified individuals in the state in which the Exchange operates.

We believe generally that certifying only health plans that take steps to make enrollees' prior authorization requests and related clinical documentation available through interoperable technology would ultimately lead to these enrollees having access to that information in a convenient, timely, and portable way, which is in enrollees' best interests. Adding information about prior authorization requests to the Patient Access API would allow enrollees to easily obtain the status of prior authorization requests submitted on their behalf and use that information effectively to make more informed decisions about their health care, improve the efficiency of accessing and scheduling services, and, if needed, provide missing information needed by the issuer to reach a decision. This could allow QHP issuers on the FFEs to more promptly address prior authorization requests and would also facilitate more timely and potentially more successful initial prior authorization requests. We encourage SBEs (including SBE–FPs) to consider whether a similar requirement should be applicable to QHP issuers on SBEs.

Finally, requiring QHP issuers on the FFEs to report Patient Access API metrics to CMS annually will help CMS assess the effect this API is having on enrollees and will inform how CMS could either enhance the policy or improve access or use through activities such as additional patient education. These data could help CMS understand how best to leverage this API, and patient access to it, and to ensure this requirement is being met efficiently and adding value to CMS operations, including leading to the intended efficiencies.

B. Provider Access API

1. Background

In the CMS Interoperability and Patient Access final rule, we required impacted payers to implement a Patient Access API (85 FR 25558) that allows patients to access their health information through a third-party app. Patients who do so could then share their information with their provider during an appointment. For example, during a visit with a provider, a patient could share specific diagnoses, procedures, and tests accessed through the Patient Access API, to inform the discussion with their provider.

In the CMS Interoperability and Patient Access proposed rule (84 FR 7610), we had sought comment on the feasibility of implementing and maintaining a FHIR API for data exchange between payers and providers and received comments strongly supporting our concept to require data availability through a Provider Access API. Some commenters stated that allowing providers to receive data, including prior authorization information, directly from payers, would make FHIR-based data exchange significantly more valuable for patients, providers, and payers. More data could be available to help providers manage a patient's care and providers could reduce or eliminate duplicate tests. Payers might also see fewer duplicate requests for services, fewer appeals and, possibly, lower costs. In the final rule, we specifically agreed with commenters that making available information about prior authorization decisions via an API would reduce burden on providers and their staff (85 FR 25541). We also discussed the potential benefits of payers sharing patient health information directly with providers (85 FR 25555) and encouraged payers to consider an API solution that would enable direct provider access to appropriate health information to support the delivery of care.

While the Patient Access API was a significant first step toward sharing individual patient health information with providers, we believe it would benefit patients if payers were required to make patient data directly available to providers via a FHIR API. In the normal course of business, many providers already maintain EHRs and share data for a variety of purposes authorized by the patient and/or existing law. Therefore, in the CMS Interoperability and Prior Authorization proposed rule, we proposed to require impacted payers to implement and maintain a FHIR API that makes patient data available to providers who have a contractual relationship with the payer and a treatment relationship with the patient. The Provider Access API has the potential to allow payers to build upon their existing systems and processes to enhance access to patient data, while continuing to protect patient privacy and data security.

We also proposed a patient opt out (rather than an opt in) policy that would require payers to allow patients to opt out of the Provider Access API. Finally, we proposed Provider Access API compliance dates in 2026 (by January 1, 2026, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2026, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2026, for QHP issuers on the FFEs).

As mentioned in section I.A. of this final rule, these policies do not pertain to Medicare FFS. In the proposed rule, we solicited comment on whether our Provider Access API proposal could be implemented in the Medicare FFS program. We expect that a Medicare FFS implementation would generally conform to the same requirements that apply to the impacted payers under this final rule, so Medicare FFS providers and beneficiaries enrolled in Medicare FFS could also benefit from this type of data sharing. We solicited comment on whether these requirements could be implemented as proposed, how we could apply each of these proposals, and if there would be any differences implementing the Provider Access API for the Medicare FFS program as a Federal payer. CMS's Data at the Point of Care (DPC) project is currently piloting an API that makes Medicare FFS claims and Part D data available to certain providers. However, some differences exist for Medicare FFS. For instance, provider remittances and patient cost-sharing information are not proprietary, so those data are shared in the DPC pilot; however, we proposed that impacted payers would not be required to share that information under our policies. Because the DPC API currently enables provider access to patient data and involves processes like authenticating the provider and verifying a patient treatment relationship with an attribution process, the information gained from the DPC pilot will be useful to impacted payers as we finalize proposals in this rule.

2. Requirements for Payers: Provider Access API for Individual Patient Information

In the CMS Interoperability and Patient Access final rule (85 FR 25558), we required impacted payers to make certain health information available through a Patient Access API when requested by a patient. We stated that it would be valuable for providers to have access to the same patient data, except for provider remittances and patient cost-sharing information, through a FHIR API that allows a provider to request data for an individual patient, as needed, thereby providing them with further insight into the patient's health care. Research shows that patients achieve better outcomes when their record is more complete, and more data are available to the health care provider at the point of care. Making more comprehensive information available to providers could thus improve the care experience for patients. Ensuring that providers have access to relevant patient data at the point of care could also reduce the burden on patients to recall and relay information during an appointment and/or provide confirmation that the patient's recollection of prior care is accurate.

Therefore, we proposed to require impacted payers to implement and maintain a Provider Access API to make current patients' information available to in-network or enrolled (as applicable) providers, at the provider's request. Under our proposal, an in-network provider is any provider or health care facility that is part of a specific health plan's network of providers with which it has a contract to furnish covered items or services. In the case of state Medicaid and CHIP FFS programs, that means any providers or health care facilities that are enrolled with the state as Medicaid or CHIP providers. We noted that this requirement would only apply to current patients. Once a patient is no longer enrolled with a payer, the payer would not need to share data with providers under our proposed policy.

We explained that the Provider Access API would allow a provider to initiate a request when the provider needs access to a patient's data, such as prior to or during a patient visit. Both the Provider Access and Patient Access APIs would facilitate the FHIR-based exchange of claims and encounter data, all data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI), and certain information about prior authorizations maintained by the payer.

We also stated that we believed that sharing claims and encounter data (without provider remittances and patient cost-sharing information) would complement the data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI) by providing more information to support treatment and care coordination. Claims and encounter data, used in conjunction with clinical and other available data, can offer a broader, more complete picture of an individual's interactions with all their providers in the health care system. With that proposal, we intended to help providers gain efficient access to more comprehensive data on their patients. Specifically, we proposed to require impacted payers to make available any of the applicable patient data with a date of service on or after January 1, 2016, that they maintain. This timeframe for data to be included is consistent with the requirements of the Patient Access API, as finalized in the CMS Interoperability and Patient Access final rule (85 FR 25567), so payers should already be maintaining and making available the same set of data from this timeframe via a FHIR API.

Finally, we explained that, unlike the Patient Access API, the Provider Access API would not include provider remittances and patient cost-sharing information. Many payers consider cost-sharing information proprietary and, while we do not necessarily agree with such a characterization, we believed that information would have limited benefit for treatment or care coordination and thus excluded it from the scope of data required to be accessible through the Provider Access API.

We proposed that payers would be required to make available via the Patient Access and Provider Access APIs information related to prior authorization requests and decisions for items and services (excluding drugs). This information would include, as applicable:

• The prior authorization status.
• The date the prior authorization was approved or denied.
• The date or circumstance under which the prior authorization ends.
• The items and services approved;
• If denied, a specific reason why the request was denied.
• Related structured administrative and clinical documentation submitted by a provider.

We proposed that information about prior authorizations be available via the Patient Access API for as long as the authorization is active, and for at least 1 year after the last status change, and that this would apply to the Provider Access API, as well. We noted in the proposed rule that this provision would be particularly relevant to denied and expired prior authorizations, to ensure that they would be available for at least a year after expiring or being denied. We did not propose to require payers to share a patient's full prior authorization history, because that could comprise a significant amount of information that may no longer be clinically relevant.

In general, our proposal for the data that payers would have to make available through the Provider Access API, as well as the technical specifications, aligned with the requirements for the Patient Access API finalized in the CMS Interoperability and Patient Access final rule (85 FR 25558) and those that were proposed for the Patient Access API in the CMS Interoperability and Prior Authorization proposed rule (87 FR 76238).

However, we further explained that there are a few notable differences between the requirements for a Patient Access API and those for a Provider Access API. The biggest difference is how and why the end user will access the data. For the Patient Access API, the patient is requesting access to their own data through a health app for their own reference and use, and potentially to share the data with a provider. For the Provider Access API, we expect that a provider will request and receive access to the patient's information through their EHR, practice management system, or other technology for treatment purposes. Providers will securely access their patients' data through a FHIR API using at least one of these systems. Providers will not access patient data through their own health app; rather, the data will flow from the payer to the provider's EHR or practice management system, which will allow them to incorporate the patient data into their records, should they choose to do so. For example, a provider who is preparing for an upcoming appointment may need more information about the patient than is contained in the patient's record in their own systems. Under this proposal, the provider would be able to request the additional data from the patient's payer. The payer would then be required to share the requested data no later than 1 business day after receiving a request from a provider who meets all other requirements to access the data.

In the CMS Interoperability and Patient Access final rule we required standards for the Patient Access API by cross reference to 45 CFR 170.215 (85 FR 25558). We proposed to require certain standards at 45 CFR 170.215 that are applicable to the Provider Access API. We are finalizing our proposals for the Provider Access API with modifications, requiring impacted payers to use the following standards: HL7 FHIR Release 4.0.1 at 45 CFR 170.215(a)(1), US Core IG STU 3.1.1 at 45 CFR 170.215(b)(1)(i), SMART App Launch IG Release 1.0.0 at 45 CFR 170.215(c)(1), and Bulk Data Access IG v1.0.0: STU 1 at 45 CFR 170.215(d)(1). We are also recommending payers use the CARIN IG for Blue Button STU 2.0.0, PDex IG STU 2.0.0, and SMART App Launch IG Release 2.0.0 to support Backend Services Authorization. We proposed but are not finalizing to require impacted payers to use OpenID Connect Core for reasons discussed later in this section. We refer readers to Table H3 for a full list of the required standards and recommended IGs to support API implementation. We refer readers to section II.G. of this final rule for further discussion of the required and recommended technical standards for the Provider Access API.

For Medicaid and CHIP managed care, we proposed that NEMT PAHPs, as defined at 42 CFR 438.9(a) and 457.1206(a) respectively, would not be subject to the requirement to establish a Provider Access API. As proposed at 42 CFR 438.242(b)(7) and by cross-reference at 42 CFR 457.1233(d), all other Medicaid managed care plans and CHIP managed care entities (that is, MCOs, PIHPs, and non-NEMT PAHPs) would be subject to this final rule. We stated our belief that the unique nature and limited scope of the services provided by NEMT PAHPs, which only cover transportation and not medical care itself, justified their exclusion from the requirements of the Provider Access API. Specifically, we did not believe that providers have routine need for NEMT data; therefore, requiring NEMT PAHPs to implement and maintain a Provider Access API (and a Payer-to-Payer API, as discussed in section II.C.3. of this final rule) would be an undue burden. However, we did propose that NEMT PAHPs be subject to the requirements for the Patient Access API, Prior Authorization API, and prior authorization processes.

We acknowledged that it could be helpful for all providers to have access to their patients' data regardless of contractual or enrollment relationships with a patient's payer. However, we proposed to only require impacted payers to share data with in-network or enrolled providers. We recognized that this could make it more difficult for an out-of-network provider to create or access a more comprehensive care record for a patient. We considered requiring payers to make the data available to all providers, regardless of whether the provider is under contract or enrolled with the payer. We will continue to consider a requirement to share patient data with out-of-network providers for future rulemaking. To this end, we requested comment in the proposed rule on existing processes for sharing data with out-of-network providers. Though we did not propose to require it, we encouraged payers to share information via API with out-of-network or unenrolled providers to the extent permitted by law if they can verify a treatment relationship. For state Medicaid and CHIP FFS programs specifically, data sharing with out-of-network and unenrolled providers would need to comply with Medicaid confidentiality rules as required by section 1902(a)(7) of the Act and implemented in our regulations at 42 CFR part 431, subpart F.

We are finalizing our proposal to require impacted payers to make available to providers, via the Provider Access API, claims and encounter data (without provider remittances and patient cost-sharing information), all data classes and data elements included in a content standard at 45 CFR 170.213, and certain information about prior authorizations (excluding those for drugs). However, as with the Patient Access API policies, we are finalizing a modification to our proposal and not requiring payers to share the quantity of items or services used under a prior authorization or unstructured documentation related to a prior authorization. We are finalizing these changes to the Provider Access API policy with compliance dates in 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs), which is a year after the proposed 2026 compliance dates. Throughout this rule, we generally refer to these compliance dates as “in 2027” for the various payers.

To support the Provider Access API implementation and maintenance, we are requiring certain standards and recommending certain IGs, as further discussed later and in section II.G. of this final rule. With the publication of the HTI–1 final rule, our cross references to 45 CFR 170.215 have been updated to reflect the updated citations as needed. Changes to the structure of 45 CFR 170.215 and versions of the API standards codified there, are discussed further in section II.G. and reflected throughout this final rule. For the Provider Access API, impacted payers must use the following standards: HL7 FHIR Release 4.0.1 at 45 CFR 170.215(a)(1), US Core IG STU 3.1.1 at 45 CFR 170.215(b)(1)(i), SMART App Launch IG Release 1.0.0 at 45 CFR 170.215(c)(1), and Bulk Data Access IG v1.0.0: STU 1 at 45 CFR 170.215(d)(1). Impacted payers are permitted to use updated standards, specifications, or IGs that are not yet adopted in regulation for the APIs required in this final rule, should certain conditions be met. For the standards at 45 CFR 170.215, updated versions available for use under our policy include, but are not limited to, US Core IG STU 6.1.0, the SMART App Launch IG Release 2.0.0, and the Bulk Data Access IG v2.0.0: STU 2, which have been approved for the ONC Health IT Certification Program. We refer readers to section II.G.2.c. of this final rule for a full discussion on using updated standards. We also recommend payers use the CARIN IG for Blue Button STU 2.0.0, PDex IG STU 2.0.0, and SMART App Launch IG Release 2.0.0 to support Backend Services Authorization. We refer readers to Table H3 for a full list of the required standards and recommended IGs to support API implementation.

a. General Comments

Comment: Multiple commenters supported CMS's proposal to require impacted payers to develop and maintain a Provider Access API and recommended that CMS finalize the proposal. Multiple commenters also noted that the API would give health care providers invaluable insights into patient care, which could lead to better quality care, reduce duplicate services, and streamline provider workflows. A commenter recommended that CMS focus its efforts on the secure exchange of data from patients to providers via the Patient Access API, which could allow the patient to be an intermediary who can choose which payer data to share with the provider.

Response: We agree with commenter sentiments about the various benefits to both providers and patients of providers having improved and direct access to patient data. As explained throughout this final rule, the requirements and standards for the Provider Access API will largely align with those currently in place and that we are finalizing for the Patient Access API. We anticipate that this alignment will provide consistency and help payers build on the work done to comply with the requirements for the Patient Access API. Enabling improved data sharing directly with providers, who have the clinical expertise to effectively use the data to improve patient care, is a logical next step for our API implementation requirements.

b. Compliance Dates

Comment: Multiple commenters supported the proposed 2026 compliance dates for the Provider Access API, as the appropriate time when the IGs will be sufficiently mature. Other commenters supported earlier compliance dates for the Provider Access API, including dates in calendar years 2024 and 2025.

By contrast, multiple other commenters requested that CMS delay the implementation of the Provider Access API. Many recommended the compliance dates for the Provider Access API be at least 3 years after the issuance of the final rule to allow for provider and payer collaboration. Commenters stated this would allow payers and providers to stagger the separate implementation of the HIPAA Standards for Health Care Attachment proposed rule (87 FR 78438). A commenter stated that delaying the implementation of the Provider Access API requirement would enable the industry to develop consistent attribution methodologies and establish opt out policies. A commenter suggested that if CMS finalizes its proposal to require payers to implement Provider Access APIs and require a response within 1 business day, it should delay the compliance dates until 2027.

Multiple commenters flagged that CMS does not have to require implementation on any particular calendar date, since it would not affect an enrollee's plan benefits or premiums. A commenter specifically stated that the implementation does not need to be synchronized to the beginning of the plan benefit year for MA organizations and QHP issuers on the FFEs.

A commenter sought clarification on the compliance dates as it relates to onboarding new providers to a payer's network, in order to ensure these new providers are following all applicable regulations, laws, and testing requirements by the proposed compliance dates in 2026. Multiple commenters recommended that CMS develop the Prior Authorization API before fully implementing the Provider Access API. A commenter further recommended that CMS phase in implementation of the Provider Access API. They believe CMS should allow additional time for development of the Provider Access API to maximize its utility and provided suggestions for additional capabilities to do this.

Response: After consideration of public comments, we are finalizing a 1 year delay in the compliance dates, to 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs). As discussed in section I.D. of this final rule, we are delaying the compliance dates for each of our policies that require API development and enhancement (though other policies on new reporting metrics and prior authorization processes are being finalized with different compliance dates). While making data related to prior authorizations available to providers is necessary and urgent, we also understand that the policies we are finalizing will take time for payers to implement. An additional year will give payers time for a smooth rollout of this new API, as well as to onboard their providers. Payers may communicate these policies to any new providers through the same channels they currently use to communicate participation rules, coverage guidelines, and other important plan information with new providers joining their network. Because we are delaying the compliance dates, we do not believe a phased implementation is necessary, even if the additional time is used to implement functionalities for the API that we are not requiring in this final rule. We emphasize that the compliance dates are merely a deadline, and we encourage payers to meet the requirements of this rule as soon as possible to benefit their patients and providers. The additional year will also give impacted payers the requested time to establish the required attribution and opt out processes (discussed in sections II.B.3.a. and II.B.3.b. of this final rule, respectively).

Finally, we decline to delay the compliance dates for this policy until after the Prior Authorization API is implemented and are finalizing the same compliance dates for all three new APIs. We agree that the purpose of the Prior Authorization API is to facilitate the exchange of structured (as defined in section II.A.2.a.ii. of this final rule) prior authorization data, and therefore receiving requests electronically may expedite payers' ability to make that information available to providers. However, even after the Prior Authorization API compliance dates, we expect that a number of prior authorizations are going to be submitted through other channels (hopefully in declining number). A provider's access to this information should not depend on the method and process that a payer sets for providers to submit a prior authorization request. Rather, the purpose of our Provider Access API policies is that providers have access to their patients' data (if patients do not opt out). That means that payers will need to be able to share through the required APIs any prior authorization information that is submitted in ways other than the Prior Authorization API, regardless of the compliance dates. By finalizing 2027 compliance dates, we are providing payers an additional year beyond our proposal to implement the needed functionality within their internal systems. While we acknowledge that the compliance dates may not need to be at the start of a calendar, contract, or rating year, finalizing our proposal with specific compliance dates will ultimately reduce confusion for all parties.

Comment: A commenter cautioned that without information that will be contained in an anticipated ONC proposed rule, it is difficult to provide realistic timelines for making prior authorization data available. They recommended that CMS offer an additional public comment period after the publication of this separate, anticipated ONC rule to allow the industry appropriate time to review the proposed changes that would be incorporated into the provider's workflow.

Response: Regarding ONC regulations, we recognize that commenters are interested in future ONC policies which may relate to the policies in this rule. ONC issued both the HTI–1 proposed and final rules since the publication of our proposed rule. As discussed, cross references in this final rule have thus been updated accordingly. We will continue to work with ONC to explore the adoption of standards and health IT certification criteria where appropriate to streamline data exchange, support interoperability, and increase efficiencies associated with the policies in this final rule. We further note that the Unified Agenda, at the time of publication of this final rule, has been updated to include an entry for a proposed rule from ONC entitled “Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability” (RIN 0955–AA06). The description indicates that the proposed rule aims to advance interoperability, including proposals to expand certified APIs for electronic prior authorization. However, the policies in this rule can be finalized independently of future rulemaking by ONC and we are not providing an additional period for comment.

c. Identifying Providers and Networks

Comment: Multiple commenters requested clarification on the definition of “providers” that are eligible to use the Provider Access API. A commenter recommended that CMS permit providers who use a Type 2 National Provider Identifier (NPI) number to use the Provider Access API. Multiple commenters also believed that providers other than physicians should have access to patient data via the Provider Access API. A commenter recommended that the final rule explain whether the Provider Access API can be used by clinical laboratories. Another commenter believed that a Tax Identification Number (TIN) should be used for patient attribution purposes, rather than an NPI because it would give an opportunity for multiple providers in the same practice to access a patient's information.

Response: Providers who should have access to a patient's data are those, whether they are an individual, a facility, or a group of providers who have come together as an Accountable Care Organization (ACO), who are appropriately licensed, provide items or services eligible for coverage by the payer, and are enrolled with the payer or in the payer's provider network. Should a clinical laboratory, or other entity such as an ACO, meet these criteria, it would indeed be a provider who could use the Provider Access API to access patient data, assuming all other criteria outlined in this final rule are met. Multiple providers in the same practice may also be able to access a patient's data if the practice is enrolled with a plan under a Type 2 NPI (that is, an organization's NPI), or if those providers are part of an ACO that is requesting data on a provider's behalf, because all the providers in such organizations would be part of the payer's network. Furthermore, an ACO typically has business associate agreements with the providers that comprise the ACO, that should allow them to request data on the provider's behalf. Impacted payers may even elect to use patient rosters from such multi-provider practices or ACOs, as well as a practice's TIN, as part of its attribution process (see section II.B.3.a. of this final rule) since the patients on these rosters could be attributed to all the providers in these organizations.

Comment: Multiple commenters sought clarification on how CMS defines a payer's network. A commenter inquired whether CMS's intention was to only include contracted providers who have both a contractual relationship with the payer and a treatment relationship with the patient, and as to which facilities are considered contracted or out-of-network. Another commenter asked for CMS to further define “treatment relationship with the patient.” A different commenter sought clarification on the definition of in-network providers for a plan that operates in multiple territories and has some providers that may be in-network for one location and out-of-network for another.

A commenter further recommended that CMS consider how to allow for effective patient data transfers in more complex provider-facility relationships, meaning contracted individual and institutional providers. A commenter also recommended that CMS consider the nuances of cancer therapy networks when developing its final policies, as some payers utilize a cancer therapy network and cover services furnished by certain providers who may be considered out-of-network generally, but in-network for certain cancer treatments.

Other commenters suggested that CMS explain whether impacted payers with leased networks would be subject to the in-network requirement and recommended that leased network providers not be considered in-network for purposes of the Provider Access API. One of these commenters raised the concern that requiring QHP issuers on the FFEs to share patient information with leased network providers would impose a burden on QHPs, noting that the in- and out-of-network status of these providers could depend on a plan's benefit package. These commenters noted that these networks are often rented or leased from other payers, and that the QHP issuer that is renting the network may not have control over provider contract standards.

Response: We are finalizing that impacted payers will be required to make the specified patient data available to in-network or enrolled providers with whom the patient has a verified treatment relationship (determined via an attribution process, as discussed in section II.B.3.a. of this final rule), assuming the data access conforms to all other applicable laws and regulations, such as state privacy laws. As discussed elsewhere, a payer can establish a treatment relationship by determining whether the patient's claims history, proof of an upcoming appointment, or other information (for example, hospital admission letter) demonstrates a treatment relationship with the provider. Nothing in this final rule would require the information used to verify the provider's relationship to the patient to be shared or exchanged via the Provider Access API itself. We also remind readers that, though we are not requiring payers to share patient data with out-of-network or unenrolled providers, we encourage them to do so to the extent permitted by law if they can verify a treatment relationship.

Impacted payers that operate in multiple service areas, and therefore have some providers that are in-network in a particular area but out-of-network in other areas, should treat the providers based on network status on a case-by-case basis, depending on the payer's service area applicable to each enrollee. For example, if Providers A and B are both in-network for the plan, but Enrollee C resides in a service area where only Provider A is in-network, then the plan can treat Provider A as in-network and Provider B as out-of-network for making Enrollee C's data available via the Provider Access API. However, we remind readers that while not required, it would still be permissible to grant access to the Provider Access API to Provider B. The fact that Provider B already has a contract with the payer would even help to mitigate the potential privacy, security, and program integrity concerns we discussed in the proposed rule. The presence of this contractual relationship is also why we agree with the commenter regarding providers who are part of a cancer therapy network. If providers are in-network for some services for a patient, then they are an in-network provider. Our goal with our Provider Access API policies is to maximize the number of providers who can use it.

We acknowledge that there may be health care settings and facilities where only some of the providers are enrolled with or have a provider agreement with the impacted payer (as applicable). Under the HIPAA Privacy Rule, covered health care providers generally may disclose certain PHI to other health care providers for treatment purposes. Thus, there may be cases where a provider may share relevant patient data obtained via the Provider Access API with another provider who may not be in-network or enrolled with the impacted payer. However, under our requirements, payers would only be required to share data through the Provider Access API in response to requests from in-network or enrolled providers (as applicable).

Providers in a leased network are in-network for purposes of the Provider Access API requirement because the lease effectively creates a contract with the providers in that network. By way of example, QHP issuers on the FFEs include leased network providers in the Network Adequacy template they submit as part of the annual QHP Certification application process, to the extent that a network's providers are available to enrollees in that QHP and are treated by the issuer as providing in-network benefits. In addition, per 45 CFR 156.340, QHP issuers on the FFEs are responsible for their own compliance and the compliance of any delegated or downstream entities with all applicable Federal standards related to Exchanges.

d. Provider Adoption and Use

Comment: Multiple commenters agreed with the scope of the Provider Access API, but expressed concern about potential penalties for providers who are unable to adopt technology that supports data exchange via this API.

Response: We did not propose any requirements for providers to use the Provider Access API, nor did we propose penalties for providers who do not use the API. However, accessing patient data through the Provider Access API will improve providers' ability to furnish quality care to patients. We expect that providers too will see the benefit of this technology and having patient data available directly from payers.

Comment: Multiple commenters flagged that providers should have access to a patient's health information without technological or financial barriers, and that CMS should consider the costs to health centers, safety net providers, long-term and post-acute care (LTPAC) settings, and hospitals with low resources, as well as their unique needs with regard to implementing use of the Provider Access API. They believed that considering these provider types would ensure more widespread use of the API. A commenter stated that some small businesses do not have the staff or funding to set up a complex data exchange and they believed there is a need to engage them in discussions about the benefits of the health information exchange. Another commenter stated that the proposed rule did not offer any indication of available resources to help providers implement the API. A commenter recommended CMS consider investments that health centers make to ensure appropriate interoperability and access.

A commenter urged CMS to track and counteract any equity issues that may manifest from operationalizing the Provider Access API. Multiple other commenters flagged that the true impact of APIs on everyday practices will not be understood until they are implemented and being used by providers, with another commenter recommending that CMS focus targeted efforts to engage provider specialties and groups who have traditionally lagged in uptake of interoperable technology.

Response: We agree that technology should not be a barrier to accessing appropriate patient information and our policies are intended to make such access easier for providers. We recognize that there are care settings that lag in adoption of EHR and other health IT, and/or lack the staff or resources to make use of the Provider Access API, which could result in these care settings missing out on the benefits of data exchange. Nevertheless, making data available via a FHIR API, which ensures these data are available to any authorized system seeking to access it, will benefit settings that may not have sophisticated technological solutions. Furthermore, making these data available is a vital antecedent to increased data sharing and interoperability across the health care system. We will be closely monitoring implementation and use of the Provider Access API to assess its real-world impact on care delivery, such as the possible equity concerns described by the commenters, as well as continue to work with providers to encourage and enable them to use the API, should they wish to do so.

Comment: Multiple commenters recommended that CMS seek to understand the current state of health IT and the needs of end users before mandating Provider Access API implementation. A commenter stated that the health IT infrastructure across the industry is not ready to support the APIs. Another commenter representing payers, providers, and clearinghouses in both the public and private sector noted that when they surveyed their payer members on the Provider Access API implementation, 64.3 percent of payers responded it would be “very difficult or difficult” to implement.

Response: We disagree with the commenters' assessment that existing health IT infrastructure is not ready to support the Provider Access API. Payers are currently required to maintain a Patient Access API that enables the exchange of the same data as we are requiring to be available via the Provider Access API, with the caveat that this rule establishes new requirements to include information related to prior authorizations. The Patient Access API establishes the foundation to ensure that existing payer health IT infrastructure is indeed capable of also supporting the Provider Access API. For providers, as of October 2018, eligible professionals and hospitals collectively received over $38 billion in incentives to adopt, implement, upgrade (AIU), and demonstrate meaningful use of certified EHR technology (CEHRT) through the Medicare and Medicaid Promoting Interoperability Programs (formerly the Medicare and Medicaid EHR Incentive Programs). As of 2021, 78 percent of office-based physicians and 96 percent of non-Federal acute care hospitals had adopted CEHRT. CEHRT now incorporates functionality for standards-based FHIR APIs. We thus believe health IT developers can build on these standards-based APIs to further develop functionality in provider systems that supports access to Provider Access APIs.

Comment: Multiple commenters underscored the need to establish incentives for providers to adopt the Provider Access API to offset any provider burden. Commenters cited quality measure reporting through the MIPS and CEHRT programs as possible avenues for incentives. Another commenter recommended that CMS and ONC work together to create incentives for vendors to improve EHR functionality and for providers to utilize the API, as well as provider educational resources to encourage adoption.

Response: For reasons explained previously, we believe that providers will see the benefit of using the Provider Access API, but we intend to closely monitor providers' experience, as well as consider ways to encourage use of the API in future rulemaking, if need be. We remind readers that nothing in this final rule would prohibit impacted payers themselves from incentivizing and/or requiring use of the Provider Access API. However, should they choose to implement such a policy, we remind impacted payers to carefully weigh the expected benefits against any potential new burden on providers.

Comment: Multiple commenters stated that the Provider Access API may be duplicative of existing resources (for example, HIEs or HINs, multi-payer portals, or other existing mechanisms for accessing claims data). Many other commenters supported creating the ability to integrate information from the Provider Access API into the provider's EHR system. These commenters recommended that CMS work closely with both providers and EHR vendors to ensure that integrating data from the Provider Access API is user-friendly and incorporated into the clinical workflow. They stated that that would make patient data from the Provider Access API organized and navigable. Another commenter stated that because patients often receive care from multiple health providers, they often have fragmented patient health records, which can make it difficult for providers to get a clear picture of a patient's health history.

Multiple commenters, however, expressed concerns regarding the feasibility of the Provider Access API. A commenter stated that the biggest challenge to the implementation of Provider Access API is that providers generally interact with many payers and it is not feasible for provider organizations to support many one-to-one connections with payers. The commenter stated that while it would be costly and risky, the urgency to implement a National Data Warehouse Exchange Hub/Clearinghouse has never been greater.

Response: We understand commenters' concern about the potential for duplication of the Provider Access API functionalities that existing resources may provide. However, not all providers currently use or have access to other resources that can access patient data. Further, the data we are requiring payers to make available under this final rule may not be available from other sources. Thus, the Provider Access API can be a valuable tool for providers, even if they currently have access to data via an HIE/HIN or other source. We anticipate that providers will find benefits to patient care from having patient data available from multiple sources.

We emphasize that the responsibility for implementing and maintaining the Provider Access API falls on impacted payers, not on providers or provider organizations. Further, in this final rule, we prioritize sharing structured data elements through standardized APIs (see section II.A.2.a.ii. of this final rule). Thus, even though this final rule does not obligate providers to use the Provider Access API, we anticipate that health IT vendors will integrate data from this API for providers in a manner that is organized, navigable, and useful to providers. We encourage vendors to work with their clients so that information accessed via the Provider Access API is useful for filling in gaps in the patient record, rather than creating duplicative data, and providers can take full advantage of their benefits.

Comment: Multiple commenters suggested that CMS should take steps to ensure that costs borne by EHR vendors are not passed onto providers, and that implementation is done in a manner that minimizes burden for providers. Multiple commenters also recommended that CMS explicitly require payers to allow providers to use the Provider Access API at no charge and that CMS should monitor and enforce such a requirement against payers who attempt to charge providers a user fee to access the APIs.

Response: Our goal is to improve care and reduce burden on patients, health care providers, and payers. We also recognize that EHR vendors, providers, and payers have costs of doing business. We strongly encourage EHR vendors to only charge reasonable fees for any initial or periodic system configurations required to access payers' API endpoints. Furthermore, EHR vendors and payers should ensure that any fees charged per API call are necessary and reasonable based on any actual maintenance costs for that entity. We also strongly encourage payers to permit providers to use their Provider Access API at no cost to maximize usage and benefits to patient care, which would ultimately benefit the payer as well. We will continue to work with interested parties to ensure that health care providers are not unnecessarily burdened and to ensure that our regulations do not place conflicting or unnecessary burdens on entities that may be regulated by more than one Federal agency.

Furthermore, EHR vendors and some impacted payers may be information blocking actors (as defined at 45 CFR 171.102) that must abide by ONC's regulatory requirements. Specific details of the information blocking regulations and other regulations issued by ONC are outside the scope of this final rule. Additional information about ONC information blocking regulations is available from the Information Blocking page of ONC's website: https://www.healthit.gov/topic/information-blocking. Questions may be sent to ONC's Health IT Feedback and Inquiry Portal at https://inquiry.healthit.gov/. Payers who are information blocking actors (as defined at 45 CFR 171.102) and have committed information blocking (as defined at 45 CFR 171.103) may be subject to civil money penalties by the HHS Office of the Inspector General (OIG). Interested parties should address questions regarding when particular practices might be considered information blocking to ONC.

Finally, we did not propose to implement a prohibition against payers charging providers a user fee to access their APIs. We will closely monitor implementation of the Provider Access API and whether user fees present a significant impediment to interoperable data exchange. We will also be monitoring the frequency and type of feedback we receive from providers, patients, and payers related to burden and cost, to determine whether other policies might be ripe for consideration in future rulemaking. See section I.D.2. of this final rule for more information about CMS's enforcement and compliance policies.

Comment: A commenter wanted to ensure that payers cannot require providers and clinical staff to use multiple different tools that might leverage the Provider Access API to treat patients. The commenter stated that providers should have autonomy to deliver care without having to add new technology that payers may require them to implement. Another commenter similarly recommended that CMS ensure payers do not increase burden on providers, stating that a significant burden would be placed on providers if their network participation gets conditioned on payer requirements to use the Provider Access API. Another commenter urged CMS to prohibit payers from placing additional contractual demands on providers, such as unrealistic turnaround times for physicians to retrieve patient information. The commenter expressed concerned that if providers cannot comply with payers' potential new requirements, they may be forced out of network.

Response: This rule does not require payers to impose requirements to use the Provider Access API on their in-network or enrolled providers. However, both providers and patients can benefit from the improved interoperability facilitated by FHIR APIs, with providers in particular seeing the benefits of having more patient data available to them. Contractual requirements set by payers for their in-network or enrolled providers are out of the scope of this rule. Nonetheless, if payers do choose to require providers to use the Provider Access API in some capacity, or even if they develop and require their own apps, we expect that they would do so to improve coordination with the provider and patient care, and also in a way that does not add provider burden.

Comment: A commenter noted that clinical data managed by payers are often derived from claims submitted by providers, which often results in them being in a different level of detail and format than clinical data exchanged between providers. The commenter stated that when the data are made available to providers, clear communication of those differences and accurate interpretation by the receiving provider's system is essential for enabling the provider to use the data to address care gaps and make treatment decisions. The commenter added that because the data are derived from claims, which would have been submitted by many of the same providers requesting it from the payer, deduplication of the data can become more complex. They further recommended that standards for representing the provenance of data when transmitted from payers to providers be enhanced to avoid adding a reconciliation burden on providers who receive the patient data. Another commenter said that EHR vendors would need to develop a “curation function” that could allow providers (and patients) to select the specific data to incorporate into the patient's record, warning that without this capability, there will be a significant amount of duplicate and junk data that will render the Provider Access API unusable.

Response: We thank the commenter for the comments, and we appreciate the concerns regarding the level of detail, format, and potential duplication of data received by providers' systems. One of the IGs we recommend for the Provider Access API is the PDex IG (see Table H3 in section II.G. of this final rule) is a set of guidelines that describes how to exchange data between payers and providers. A key PDex IG feature is the capability to include provenance records, if they exist, when exchanging data. Provenance records describe where the data came from and how they were processed. The PDex IG strongly recommends that payers create provenance records when they are not included in a data set. We also strongly recommend provenance records in cases, like those cited by the commenter, when clinical data are derived from claims. The provenance profile contains contextual information about the data, including the data's original author(s), transmitters, and formats (including whether they are derived from a claim-related transaction). Thus, using the PDex IG can help mitigate the problem of duplicating data by including provenance information. We also strongly recommend that the data source be included at the point of record creation, so that users can appropriately understand the source and context of the data. While we acknowledge the potential complexity of deduplicating data, creating contextual provenance information could help providers' systems identify data that already exist in the system, which can make the data actionable, rather than duplicative. In this way, payers can help providers unlock the benefits of accessing patient information through the Provider Access API. Finally, nothing in this final rule obligates providers to incorporate data they access via the Provider Access API into their patient's record, if they do not believe there is a benefit.

Comment: A commenter suggested that CMS permit payers to include audit rights and penalties in their provider contracts to ensure that payers are able to monitor and regulate information access requests, as the structure of the proposed rule effectively asked payers to trust that providers who request access to patient information have a valid need to access that information.

Response: Nothing in this final rule prohibits impacted payers from including additional requirements in their provider contracts and/or terms of service for requesting patient data. However, we emphasize that our requirement to provide access is limited to in-network providers who have a treatment relationship with the patient. We understand that payers need to ensure that provider requests are appropriate, so it follows that those entities would want to define roles and responsibilities through provider contracts, as these are established vehicles which delineate other payer requirements. If payers choose to implement such requirements, or a separate terms of service agreement, we strongly encourage them to balance the benefits to patients against any additional burden this would place on providers. Further, our requirements on the impacted payer will ensure that patients are informed of their data sharing options and will have the opportunity to opt out of data sharing under this policy if they do not wish for their providers to have access to their data. Any requirements that payers implement to use the Provider Access API must not conflict with the HIPAA Rules, or any other applicable law. See sections II.B.2.j. and II.B.3.b.ii. for discussions on the interaction of this final rule with the HIPAA Rules.

Comment: Multiple commenters cautioned that this rule puts a large burden on payers with little burden on providers and that given the number of resources needed to implement the API, provider uptake is critical. A commenter further stated that this rule requires payers to build a new API and share information with providers without asking providers to contribute or share information with payers, which they believe will lead to a breakdown in communication between providers and payers.

Response: As discussed previously, the technical requirements for the Provider Access API align almost identically with those already established for the Patient Access API (85 FR 25510) that impacted payers are currently required to maintain. We also emphasize that our recommended IGs will provide further clarity for payers on how to implement the APIs, thus reducing some of the implementation burden. As we discuss in section II.B.3., we are not being prescriptive as to how impacted payers implement their attribution and opt out processes, so that they can design processes that work best for them. We believe that all parties will see the benefit of improved data exchange facilitated by the Provider Access API. Because this final rule does not prohibit it, impacted payers may also decide to require providers to share certain data with them as part of their network/enrollment requirements. In fact, we understand that such requirements already exist in some situations. However, should payers implement such polices, we expect that they would do so only to the extent that it would benefit patient care and not add provider burden. We strongly encourage payers to carefully weigh any expected benefits against this potential burden. Finally, the Health IT Certification Program has already established requirements for FHIR APIs in EHR systems, which creates the capability for providers to make data available to payers via FHIR APIs. Using those APIs would allow payers to implement any requirements in a way that imposes minimal burden on providers.

Comment: A commenter recommended that CMS explain whether only providers, not EHR vendors, can trigger a request for patient records.

Response: We are only requiring impacted payers to make patient data available to in-network or enrolled providers. Vendors are not permitted to request data for themselves, as they are not providers and thus cannot meet the criteria for making such a request. However, an EHR vendor may request the patient data via the provider's system at the behest of a provider who is eligible to request the data, with appropriate authentication and if consistent with other applicable law.

e. Data Content

Comment: Multiple commenters recommended that CMS streamline the proposed required data to limit duplicative information and potentially overwhelming providers. A commenter recommended that CMS initially focus the Provider Access API on sharing claims data before introducing other types of data. Another commenter recommended that CMS consider the burden that this proposal may place on providers if they must maintain multiple versions of USCDI and whether it would even be feasible for their EHR to support this.

Multiple commenters, however, suggested additional data that should be made available via the Provider Access API. Some commenters suggested that to facilitate a simpler prior authorization request process, CMS consider requiring payers to make patients' insurance coverage information readily available to providers through the Provider Access API. A commenter recommended that patient data collected by payer-owned providers and health service companies also be included in the Provider Access API.

Response: We understand the concern over duplicative information, and it is not our intention to increase provider burden. Under this final rule, we are only requiring the exchange of data that are already structured, meaning they can be received by the provider's system in a standardized format with defined data attributes—this includes data classes and data elements in the USCDI and FHIR resources (see more discussion of how we define structured documentation in section II.A.2.a.ii. of this final rule). Most EHR systems use standardized clinical data in their systems today and, if certified under the ONC Health IT Certification Program, are also required to use the data classes and data elements in the content standard at 45 CFR 170.213 (USCDI). There are IT solutions available for providers' EHRs or practice management systems, such as Substitutable Medical Applications, Reusable Technologies (SMART) on FHIR apps, that can make the data received via the Provider Access API actionable and avoid duplicative information. Further, for administrative ease and consistency, we are keeping the required types of data consistent (excluding provider remittances and patient cost-sharing information, as explained elsewhere in this final rule) with those required under the Patient Access API. We did not propose to include patients' insurance coverage information, to which providers should already have access through existing channels with payers or from patients themselves. However, a Health Insurance Information data class has been added to USCDI v3, and includes the data elements Coverage Status, Coverage Type, Relationship to Subscriber, Member Identifier, Subscriber Identifier, Group Identifier, and Payer Identifier. As payers adopt USCDI v3 (as required after January 1, 2026, under the regulations at 45 CFR 170.213), this information would be required to be available.

We remind impacted payers that if there is additional information beyond that which we are requiring that they do or can share with providers, they can use the Provider Access API as a mechanism for sharing that information, as permitted by applicable law. To the extent that impacted payers maintain patient data (per the CMS Interoperability and Patient Access final rule [85 FR 25536]) collected by payer-owned providers and health service companies, only the data elements specified in this final rule are included in the Provider Access API requirements.

Comment: A commenter recommended that CMS support the development of content and technical standards for prior authorization decisions that can be incorporated into IGs for testing before requiring inclusion of prior authorization information in the Provider Access API.

Response: Our recommended IGs (listed in Table H3) are currently in production and several versions of the IGs have been updated since publication of the proposed rule. Additionally, the recently published PDex IG STU 2.0.0 specification includes a prior authorization profile that enables payers to communicate prior authorization decisions and changes to the status of a prior authorization requests. The process for IG development is open and we encourage industry engagement in their further development via opportunities such a HL7 FHIR Connectathons.

Comment: A commenter recommended that CMS require USCDI v3, since the proposed Provider Access API would not be implemented until 2026. The commenter stated that the USCDI v1 does not have digital data standards for social determinant of health (SDOH), sexual orientation and gender identity (SOGI), nor other data standards important for public health capabilities, and this could be a missed opportunity to drive national digital data standardization in this area. The commenter suggested this requirement would create a business case and drive adoption of standards and a move by industry to align.

Response: At the time the proposed rule was published, USCDI v1 was the only standard included at 45 CFR 170.213. The HTI–1 final rule, however, finalized that USCDI v1 expire on January 1, 2026, and also adopted USCDI v3 at 45 CFR 170.213 (89 FR 1210). Both versions will be available USCDI versions at 45 CFR 170.213 until January 1, 2026. Until this date, payers may meet the Provider Access API requirements by sharing all data classes and data elements in either USCDI v1 or v3. After January 1, 2026, payers must make available all data classes and data elements in USCDI v3. ONC accepts submissions from the public for new USCDI data classes and data elements through the USCDI ONC New Data Element and Class (ONDEC) Submission System and regularly publishes updated versions of the USCDI. Any change in a content standard at 45 CFR 170.213 will go through notice-and-comment rulemaking. Impacted payers are permitted to voluntarily use updated standards, specifications, or IGs that are not yet adopted in regulation for the APIs discussed in this final rule, should certain conditions be met. We specifically encourage impacted payers to make all data classes and data elements available from more advanced versions of the USCDI prior to the expiration date. We refer readers to section II.G.2.c. of this final rule for a full discussion on using updated standards.

Comment: A commenter noted that while there is a FHIR resource for a scheduled appointment, it is not included in USCDI v1, which means a provider cannot send an appointment even when they have implemented the latest version of USCDI. The commenter stated that adding that element would require additional EHR vendor development.

Response: All data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI) for dates of service after January 1, 2016, maintained by the payer are required to be made available to the provider who requests them (assuming all other applicable requirements specified in this final rule are met). Whether or not a scheduled appointment data element is included in USCDI has no bearing on how API developers use the Scheduling and Appointment FHIR Resources for other purposes.

Comment: Multiple commenters disagreed with the proposal to require payers to include clinical documentation and forms related to a prior authorization, with one noting that this information will be duplicative of the clinical information in a person's medical record. Another commenter stated that clinical documentation is often submitted to payers in the form of lengthy PDF documents, and sometimes by fax, making manually translating these data into FHIR challenging and infeasible to do within the proposed 1 business day timeframe. A commenter recommended that CMS explain whether payers have to convert clinical documentation submitted by providers by fax or in PDF or JPEG file formats into FHIR. A commenter recommended that CMS require the same discrete data element standards that the agency applied to the original Patient Access API to the Provider Access API, since distributing patient clinical attachments to all requesting clinicians raises concerns under the HIPAA minimum necessary standard. The commenter stated that an alternative is that providers could share clinical attachments as needed through clinician data sharing consultation and collaboration. However, a commenter recommended that CMS should include the administrative and clinical documentation requirements and require specific information for prior authorization data.

Response: After reviewing the comments, we agree that the burden of requiring payers to make unstructured documentation (as explained in section II.A.2.a.ii. of this final rule) available via the Provider Access API outweighs the benefits such documentation would provide. Thus, like for the Patient Access API, we are finalizing a requirement that the Provider Access API include only structured administrative and clinical documentation related to the prior authorization requests.

As with the Patient Access API, documentation received in an unstructured format does not need to be parsed and converted to structured data for the purposes of inclusion in the Provider Access API. However, if a payer does parse the unstructured documentation to store the contained data in a structured format, that structured data would then be “maintained” by the payer, as defined in the CMS Interoperability and Patient Access final rule (85 FR 25538). For example, a payer may receive and maintain an unstructured PDF that contains lab results. If a payer maintains those lab results in a structured format, they would be required to share them under this final rule. If they are maintained in an unstructured format, they would not.

We recognize that unstructured administrative and clinical documentation could be important to help providers understand certain prior authorization requirements, so we encourage payers to make that information available when possible. Furthermore, the policy we are finalizing would require payers to make available any documentation or materials that the provider sends to the payer to support a decision that are received in a structured format. Since we are finalizing that only structured documentation be made available, and structured documentation are formatted in a way that makes them easily transmissible between systems, our final policy should place significantly less burden on payers than our proposal, while still giving providers access to information about their prior authorization processes.

It is important for payers to make available the specific clinical data at which they are looking to make a determination on the prior authorization request, even if that information may be elsewhere in the patient's record. As to the commenter concerned about clinical attachments and the HIPAA Privacy Rule's minimum necessary standard, we refer them and all readers to section II.B.3.b.ii. of this rule for more discussion about the HIPAA Rules.

Comment: A commenter sought clarification on whether the data sharing requirement applies to only claims and encounter data that are available at the time of the request, reasoning that if so, it could avoid any inappropriate pressure on providers to submit claims immediately after the provision of an item or service.

Response: Per the CMS Interoperability and Patient Access final rule (85 FR 25536), payers are only required to share data that they maintain as part of their normal operations. Nothing in this final rule would change that existing policy that payers are not required to reach out to providers or other entities to gather data that they do not maintain, if it is not part of their normal operations, in order to share via the Provider Access API.

f. Provider Remittances and Cost-Sharing Information

Comment: Multiple commenters agreed with CMS's proposal to not require payers to make available provider remittances and patient cost-sharing information, as it would likely only have a limited beneficial impact on care. A commenter stated the cost-related data currently available via from the Patient Access API are not very clear, which could lead to different implementations and increased ambiguity when implementing the Provider Access API. A commenter warned that implementers are inconsistent, with some sending Explanation of Benefits (EOB) scrubbed of the item level detail, whereas others exclude EOBs altogether and only provide clinical data.

Response: Regardless of whether provider remittance information or cost-sharing information are truly confidential or proprietary information protected from disclosure under Federal law (which we do not address here), excluding such data from the Provider Access API is appropriate. Thus, if commenters believe that cost-sharing information would largely not be helpful information for providers to have access to, then we emphasize that sharing this information is not a requirement for the Provider Access API. We further agree with commenters that including this information in the Provider Access API will have limited benefit for treatment or care coordination. This rule does not prohibit payers from sending that information. Therefore, if a payer believes that implementing their Provider Access API in such a way that includes provider remittances and patient cost-sharing information would provide benefit or reduce burden, they are not prohibited from doing so under this rule, and may do so consistent with other applicable laws.

Comment: Multiple commenters urged CMS to reconsider excluding cost-sharing information from the Provider Access API because providers with access to this information can make more informed decisions regarding patient care by incorporating cost into treatment plans, and in turn, maintain a good provider-patient relationship. A commenter encouraged CMS to examine standards-based, patient-facing, and real-time benefit check capabilities that can be facilitated by patient cost-sharing information. A commenter also cautioned that excluding provider remittances and cost information conflicts with the cost-sharing information needed to enable Good Faith Estimates (GFE) under the No Surprises Act (NSA), which was enacted as part of the Consolidated Appropriations Act, 2021 (CAA). They suggested that the rule be revised to allow necessary cost-sharing information required under the NSA. Another commenter highlighted that providers must be able to calculate sustainable total cost of care for patients attributed to them as part of value-based payment models.

Multiple commenters proposed potential solutions to facilitate the sharing of cost-sharing information. A commenter suggested that CMS consider a bi-directional exchange mandate (as opposed to one-way provider access to payer data) to cover payment and operations, in addition to treatment. A commenter suggested that it does not make sense to restrict patient cost-sharing information since it is available in the X12 270/271 transaction standard. The commenter stated the Provider Access API can potentially replace the need for a separate 270/271 transaction and instead incorporate the information in 270/271 transactions. Another commenter expressed that modifications could be made to the CARIN IG for Blue Button to align with the proposed requirement to remove remittances and cost-sharing data from the FHIR transaction.

Response: While we appreciate the various suggestions we received; we did not propose any related policies because the primary purpose of our Provider Access API policies is to improve the exchange of data for health care treatment. We acknowledge that some providers may find cost information helpful for gaining a clearer picture of a patient's financial situation. However, there is nothing prohibiting a provider from discussing the costs of various items or services and comparing the costs when furnished in-network and out-of-network to help a patient understand how to limit their out-of-pocket costs. Further, in-network or enrolled providers should be generally aware of the costs of various treatments, as their contracts would address payment amounts and conditions of payment for services furnished by that provider to a covered individual. We finally note that the GFE provision of the NSA relates to prospective costs, rather than cost information from past claims; that provision is beyond the scope of this final rule.

Comment: A commenter stated that the CARIN IG for Blue Button will require updates to support CMS's proposal to remove remittances and cost-sharing data from the FHIR transaction for the Provider Access API.

Response: Further development is currently underway on the CARIN IG for Blue Button, which is one IG that we are recommending to support the Patient Access, Provider Access, and Payer-to-Payer APIs (see Table H3 in section II.G.4. of this final rule). These developments will support exchanging information without provider remittances and patient cost-sharing information.

Comment: A commenter supported CMS's effort to establish the infrastructure needed to support payment reform and value-based care initiatives via the Provider Access API, stating that these initiatives are critical to reducing the costs of health care delivery while maximizing quality for Medicare enrollees. Multiple commenters stated, however, that the Provider Access API does not facilitate sharing the complete set of information needed by providers for participation in value-based care programs and recommended that CMS prioritize additional information, such as financial targets, spending, coordination of care payments, payer-generated attributed beneficiaries, and cost performance reporting. They believe these would allow a better exchange of value-based care payment models' summary-level data. A commenter recommended that ONC and CMS encourage industry to prioritize APIs to exchange information that would reduce administrative burden and lead to value-based care scalability.

Response: We did not propose to include cost information for value-based care, as the primary goal of the Provider Access API is to give providers both immediate and direct access to patient data in order to improve patient care. However, we remind impacted payers that they can use the API to exchange additional data, should they so choose. We agree that FHIR APIs have the potential to support participation in value-based care programs, as these initiatives are critical to reducing the costs of health care delivery while maximizing quality for patients. We will continue to explore ways to leverage FHIR APIs to achieve CMS and broader HHS priorities. The requirements in this final rule are a critical foundation for this future work.

g. Prior Authorization Data

Comment: Multiple commenters supported including prior authorization information in the data made available through the Provider Access API, noting that it would help future providers understand the patient's current health status more quickly and better meet their care needs, increase transparency, and reduce burden on patients and providers. A commenter stated that adding prior authorization information to the Provider Access API will enhance functionality and incentivize use of the API.

Response: We thank commenters for their support and agree that giving providers access to the same prior authorization data as patients will have a positive impact on patient care.

Comment: Multiple commenters recommended not including “the quantity of services used” due to delays in claims processing. A commenter recommended that CMS include just the approved number of units.

Response: In response to commenter feedback to both the Provider and Patient Access API proposals, we are finalizing our proposal with the modification that “quantity of approved items or services used to date” will not be a required field. We refer readers to section II.A.2.a.ii. of this final rule for a full discussion of our reasoning.

Comment: A commenter recommended including a standardized comment code(s) and comment description(s) for each status update sent to the provider to help with future data analysis of prior authorization improvements and tracking quality metrics.

Response: While we consider five basic statuses (pending, active, denied, expired, authorization not required) to cover the general scope of a prior authorization requests and decisions, we do not intend to prescribe or delineate the exact statuses that payers must use. The requirement for the Provider Access API (and the other APIs in this rule) to include the status of the prior authorization is intended to provide information to the provider, patient, or other payer that is using the API to access this information. Therefore, compliance with the requirement is not based on using specific terms, but on providing clear information. We refer readers to section II.A.2.a.ii. of this final rule for a full discussion on prior authorization status definitions.

Comment: A commenter recommended that CMS crosswalk the required types of data for the Provider Access API with the other proposed APIs to avoid duplication, such as having to include supporting documentation through the Provider Access API, even if it is available via the Prior Authorization API.

Response: If the commenter is recommending that the Provider Access API make available a mutually exclusive set of data from the Prior Authorization API to avoid confusion, then we note that Prior Authorization API will not have prior authorization data from other providers. We refer readers to section II.D. of this final rule for our full discussion of the Prior Authorization API requirements. We further intend to provide educational resources related to all the APIs in this final rule. We are not finalizing our proposal that related unstructured administrative and clinical documentation be included in the prior authorization data that impacted payers would have to make available to providers via the Provider Access API.

Comment: A commenter recommended including the following additional data elements related to prior authorization: timestamps of any change in the status of the prior authorization; date/time received, reviewed, denied/approved; how the decision was made; software tools/artificial intelligence (AI) tools used; and persons involved in making the prior authorization decision. Another commenter stated that prior authorization metrics should be available via the Provider Access API to give providers an aggregated view of their attributed patients' prior authorizations. A commenter also recommended that CMS should require payers to make available through the Provider Access API contact information for the entity responsible for managing the payer's prior authorization program.

Response: While these specific additional data and functionalities may provide value to some providers at this time, we do not believe that the value outweighs the additional effort impacted payers would need to expend to add these data and functionalities to the Provider Access API. The PDex IG STU 2.0.0, which has been published since the publication of the CMS Interoperability and Prior Authorization proposed rule, states that payers using this IG shall make available pending and active prior authorization decisions and related clinical documentation and forms for items and services (not including prescription drugs), including the date the prior authorization was approved, the date the authorization ends, as well as the units and services approved and those used to date. It also requires a creation date, issued date, and specific codes relevant to the approval status. However, as discussed in section II.G., we are not yet ready to require this IG. We are thus prioritizing the data that are most important and useful at this time for clinical decision-making in proximity to a patient visit. To use one commenter's example, requiring payers to provide contact information for the entity responsible for managing the payer's prior authorization program would be duplicative, as providers who have a contractual relationship with the payer should already be aware of whom to contact regarding their prior authorization submissions. Providers can also use the Prior Authorization API to obtain this information. We remind impacted payers, however, that they may choose to include additional information if they believe it adds value to patients, providers, or themselves and their own processes. FHIR inherently provides flexibility to include additional information without reducing interoperability and the associated IGs are designed to both require and constrain specific elements identified as core to the IG's use case. We encourage the public to engage in the HL7 balloting process to provide feedback on data elements they believe would be most widely useful and applicable.

Comment: A commenter recommended that sharing prior authorization information through the Provider Access API be required, even if the patient opts out.

Response: We certainly agree with the benefits of providers having access to prior authorization information via an API and note that providers will have access to the Prior Authorization API. Providers will thus have access to these data for prior authorization requests that they make, regardless of whether the patient has opted out of the Provider Access API. We refer readers to section II.D.2.c. of this final rule for our discussion on patient opt out and the Prior Authorization API.

Comment: A commenter urged CMS to require impacted payers to provide a statement through the Provider Access API when they are not requiring a prior authorization for an item or service. The commenter stated that this will ensure a level of transparency and paper trail between payer and provider.

Response: This information will be available through the Prior Authorization API, so does not need to be included in the Provider Access API. We refer readers to section II.D. of this final rule for our full discussion of the Prior Authorization API requirements and section II.A.2.a.ii. for that of prior authorization statuses.

Comment: A commenter encouraged CMS to work with impacted payers to ensure the supporting data fields of laboratory test results, clinical data, and a specific reason for a denial are standardized to ensure information is consistent across sources. They urged CMS to work with payers, providers, and patients to determine the balance of data included in the requirements and provide the needed clarification and guidance to all parties.

Response: As explained in section II.B.2.e. of this final rule and in more detail in section II.A.2.a.ii. of this final rule, we are finalizing a requirement for payers to share only data that are already structured, which include laboratory test results, clinical data, and a specific reason for a prior authorization denial. We also remind readers that payers are not obligated under this rule to parse or convert documentation received in an unstructured format for the purposes of inclusion in the Provider Access API. However, they may choose to do so. We will continue to work with interested parties to ensure that all parties benefit from the data sharing requirements we are finalizing and explore possible enhancements to our policies that require API development or enhancement in future rulemaking.

h. Data Availability

Comment: A commenter stated that prior authorization information should be available from the entire duration of the patient's history and not just for 1 year after the last status change because it would improve transparency in decision-making for providers.

Response: Like with the Patient Access API, we believe that 1 year after the last status change is the appropriate amount of time to require payers to make historical prior authorization information available to providers. While historical information can certainly affect and be useful in improving patient care, we believe that historical claims and clinical data are more important to providers than information about prior authorizations that have expired or been denied more than a year in the past. Furthermore, our policy allows payers to make these prior authorization data available for longer than 1 year, if they believe it adds value to patients, providers, or themselves and their own processes. To inform ongoing long-term care, any active prior authorizations must be included, even if they have been in that status for more than a year.

Comment: A commenter supported the payer maintaining patient health data and making available any data to the provider with a date of service on or after January 1, 2016. A commenter recommended that CMS explain whether all data included in this rule will be subject first to corporate data retention standards, then retained from January 1, 2016, to present. Another commenter sought clarification as to whether CMS's intention is to include all data since 2016 and not only the last 5 years.

Response: We remind impacted payers that the policy we are finalizing aligns with the similar one finalized in the CMS Interoperability and Patient Access final rule: the data available through the Provider Access API are data with a date of service on or after January 1, 2016 maintained by the payer. By “maintained,” we mean data that are maintained as part of normal operations, as is currently the policy for the Patient Access API under the CMS Interoperability and Patient Access final rule.

We did not propose a policy for impacted payers to make data available only from the previous 5 years in either the proposed rule or the CMS Interoperability and Patient Access final rule, nor did we receive comments specifically in favor of shortening the timeframe to 5 years. However, we also recognize that the data a payer maintains dating back to January 1, 2016, could be a substantial amount and, depending on the capabilities of the provider's EHR or practice management system, potentially more than some providers will need. We remind providers that this final rule does not obligate them to incorporate data they access via the Provider Access API into their patient's record. While we are finalizing our proposal to require impacted payers to make available via Provider Access API any of the applicable patient data with a date of service on or after January 1, 2016, that the payer maintains, we will closely monitor whether this timeframe is appropriate, to inform possible future rulemaking.

i. Response Timeframe for Requested Data

Comment: Multiple commenters expressed their support for the proposal to require payers to share the requested patient data no later than 1 business day after the payer receives the request. A commenter stated this will enable the provision of historical health care data and may affect current care recommendations. Multiple other commenters sought clarification on whether the proposed 1 business day turnaround time for a payer to respond to a provider's request for patient data included time for payers to complete an authentication of the provider's identity and the provider-patient treatment relationship.

Multiple commenters recommended that CMS increase the amount of time payers have to respond to providers' data requests. Recommendations included suggestions to establish a two-day response time to balance timely access to information and reduce the operational burden and cost of the requirement. Commenters also noted that not all provider systems are FHIR-enabled and that could lead to longer data exchange times. A commenter stated that because of CMS's technical standards, specifications, and IG requirements, payers will likely need more time than one day to comply with CMS's proposed requirements. They believe that payers may need additional time to establish technical connections and contractual terms for a first-time request from a provider.

However, other commenters believed the time for payers to respond to the data request should be decreased from 1 day and that the response should come as soon as possible, to be real-time or near real-time. A commenter sought clarification from CMS as to why 1 business day is allowed for the payer to respond to a request, particularly if the initial request is being transmitted during a patient visit. The commenter continued that real-time responses should be expected from new technology. Another commenter stated having real-time data would help providers see a more complete view of a patient's complete care history. A commenter warned that, often, providers and patients review data during a visit and that delayed access to the data could undermine efforts to promote care coordination and provider-patient engagement. A commenter also recommended that CMS consider requiring that the requested data be provided within 1 calendar day to accommodate facilities that have 24/7 operations, like SNFs.

Response: We foresee providers needing access to the specified data in order to review them in proximity to a patient visit. Thus, we do not believe that the turnaround time should be greater than 1 business day. We specify in the regulation that a payer must make the data available through the Provider Access API no later than 1 business day after receiving a request from the provider, if all the following conditions are met:

• The payer authenticates the identity of the provider that requests access and attributes the patient to the provider under the required attribution process;
• The patient does not opt out of the Provider Access API; and
• Disclosure of the data is not prohibited by law.

Authenticating the identity of the provider will include confirming that the requesting provider is in-network or enrolled with the payer and the attribution process will include confirming that a verified treatment relationship exists. The technical standards at 45 CFR 170.215 set requirements for identity proofing and authentication processes that must be met in order for a provider's EHR or practice management system to connect to the Provider Access API and access a patient's data (see section II.B.2.k. for more discussion on authorization and authentication). Those standards allow authentication to be completed within 1 business day, if not immediately, when the provider accesses their system via login. Impacted payers can also verify the patient-provider treatment relationship before the provider request. In fact, payers are permitted and highly encouraged to design their attribution processes to verify treatment relationships prospectively. We believe that the patient relationship can be verified for the vast majority of providers who will be requesting data via the Provider Access API either ahead of time or relatively quickly. However, we recognize that this may be difficult, if not impossible, for a new patient's first visit because there will be no claims history between that patient and the provider. Thus, there might be instances where the conditions previously mention may take longer to be met for some data requests. We strongly encourage impacted payers to ensure completion of these steps in a reasonable amount of time, so the provider can make use of the data they are requesting.

While we appreciate the commenters who pointed out that some providers might need the patient information as soon as possible or in real time, we also believe that requiring that standard would cause undue burden on impacted payers. We nonetheless encourage payers to make data available to requesting providers as soon as they are able.

We are therefore finalizing our proposal that impacted payers respond to a provider's request for patient data no later than 1 business day after the payer receives the request if all conditions are met. This timeframe adequately balances a provider's need for timely data with impacted payers' capability to make data available. Further, as discussed in detail in section II.A.2.a.ii. of this final rule, we are not finalizing our proposal for impacted payers to share unstructured documentation related to prior authorizations, as sharing such documentation would currently be difficult to accomplish in 1 business day.

Comment: A commenter stated that the required response time for the Provider Access API could be administratively time consuming because the process to determine whether a disclosure is permitted under applicable law is a manual process that involves research, review, and analysis to determine which laws are applicable to the requester of the information, the type of data requested, and the intended recipient. Another commenter recommended that CMS consider the extent to which payers will be burdened by connecting and testing EHRs to facilitate the Provider Access API implementation.

Response: We are only requiring impacted payers to share data elements that are already structured, and are requiring certain mature IGs and standards (see Table H3 in section II.G. of this final rule) that will enable the Provider Access API to connect to third-party apps and/or providers' EHRs or practice management systems. Because of this foundation, along with the 2027 compliance dates that we are finalizing, payers should have sufficient time to not only test their API connections, but also to develop internal processes and train staff to make the necessary determinations of which of the known and structured data are permitted to be shared via the Provider Access API. For instance, impacted payers may use this time to develop processes that flag certain data elements—as the payer receives them—as those that may require special permissions or are prohibited to disclose under other law. Such processes can ease any manual review and decision-making that might be necessary when a provider requests patient data.

Comment: A commenter recommended that CMS make it clear that the provider must request access to patient data and attest to their treatment relationship with the patient at the time of connection.

Response: While payers might utilize a process for providers to attest to a treatment relationship at the time of the data request, we did not propose, nor are we finalizing such a requirement. This is not the only way to attribute patients, but impacted payers are certainly permitted to utilize a provider attestation as part of their attribution process (discussed in section II.B.3.a. of this final rule). Our regulations do not prohibit using an attestation where another law that permits disclosure requires an attestation.

Comment: Multiple commenters sought clarification on whether CMS's 1 business day proposed requirement complies with the 21st Century Cures Act (Pub. L. 114–255, Dec. 13, 2016) (Cures Act) around information sharing “without delay.”

Response: We refer readers to section II.A.2.a.iii. of this final rule for a discussion of how our timeline requirements relate to ONC information blocking regulations.

Comment: A commenter recommended that CMS require payers to notify providers once they have received a request and the specific date a provider should expect to receive information in response.

Response: While we did not propose such a requirement, it would be good practice for the payer to verify that they have received the request for patient data from the provider. We expect payers to have a process for providers to track their requests. Additionally, it would benefit providers for them to receive a notification if the patient cannot be attributed to them. In the DPC pilot, participating providers have the ability to request data for a patient with whom they have no prior treatment relationship, however they will receive a response with no data if they do so.

j. Interaction With HIPAA Privacy, Security, and Administrative Transaction Rules

Under our policies, all data shared and received via the Provider Access API must be handled in a way that is consistent with all applicable laws and regulations. Payers and health care providers that are covered entities under the HIPAA Rules are subject to the HIPAA Privacy and Security Rules. Adherence to both the HIPAA Privacy and Security Rules helps to ensure that the covered entity disclosing patient data through the Provider Access API has appropriate security protocols in place. These include, but are not limited to, administrative and technical safeguards, such as security management processes; access controls; and audit controls. Regardless of whether a provider meets the definition of a covered entity under the HIPAA Rules at 45 CFR 160.103, there may be state laws that require certain privacy and security protections for an HIE. Additionally, other laws, such as the regulations that focus on confidentiality of substance use disorder patient records at 42 CFR part 2 or state privacy laws, may require the payer to obtain the enrolled individual's permission to disclose certain health information. We requested comment on any other considerations regarding state privacy or other laws that may be implicated by our proposals.

Commenters provided many thoughts and recommendations related to the Provider Access API's intersection with existing privacy laws, including the HIPAA Privacy Rule. We thank the commenters for their perspectives and will use the feedback to inform future guidance, educational resources, and/or rulemaking. We remain committed to safeguarding patient information across the health care industry. Our policies provide an opportunity to engage patients in their data sharing and privacy rights while offering them the opportunity to more meaningfully engage with their care.

Our policies will not alter any obligation for providers or payers to comply with applicable law, including obligations for HIPAA covered entities to follow the HIPAA Rules. Such other applicable law includes, but is not limited to, standards regarding the use and disclosure of PHI, administrative, physical, and technical safeguards and other security provisions, and breach notification. The minimum required security framework of the Provider Access API is specified in the technical standards at 45 CFR 170.215 and will allow payers to verify the requesting provider's identity by using the required authorization and authentication protocols. Authorization refers to the process by which the payer gives the provider permission to access data. The authentication protocols are those that allow the payer to verify the identity of the requesting provider. In addition to using these required protocols, the payer will be required to share the specified data only if it can also attribute the patient to the provider using an attribution process, as discussed in section II.B.3.a. of this final rule. While FHIR itself does not define security-related functions, used in combination with appropriate security controls (such as authentication and access control), a FHIR API can and should be implemented in compliance with the HIPAA Security Rule for secure data exchange.

Under section 1173(a) of HIPAA, the Secretary is required to adopt standards for specific financial and administrative transactions and may adopt standards for other financial and administrative transactions. Although our policies will facilitate sharing claims data from payers to providers for the purpose of helping to improve patient care, the FHIR API data transmission will not be subject to HIPAA transaction standards because the purpose of the exchange would not be to request or issue a payment. We also did not propose a mechanism to report health care encounters in connection with a reimbursement contract that is based on a mechanism other than charges or reimbursement rates for specific services. The Secretary has not adopted a HIPAA transaction standard applicable to transmitting claims or encounter information for a purpose other than requesting or issuing payment, thus HIPAA administrative simplification standards do not apply to the Provider Access API.

k. Technical and Standards Considerations

Comment: Multiple commenters recommended that CMS detail the requirements for the Provider Access API, with many offering that the rule should describe the workflow, authorization, provider authentication, and attribution processes in more detail. They cautioned that without a standardized governance framework and legal terms, it will be unreasonable to expect payers and providers to establish connections and respond to requests within a set timeframe since they will need to negotiate bespoke agreements.

Multiple commenters stated that CMS's proposed standards and recommended IGs are insufficient for the Provider Access API. One payer cautioned that this would result in payers struggling to comply with the requirements and limited improvements to information exchange. Another commenter warned that the lack of endpoint standardization between payer and provider systems will likely create technical difficulties. A commenter stated that without requiring an IG for the Provider Access API, the data will not be standardized and might not be able to be directly incorporated into a provider's EHR or practice management system. A commenter also noted that the IGs that CMS recommends do not include direction for how sensitive data such as behavioral health data will be shared and with what privacy guidelines. A commenter was additionally concerned that the recommended IGs are not enough to support the attribution process.

Response: We refer readers to section II.G. of this final rule for further discussion regarding the required technical standards for the Provider Access API and IG maturity. Further, the IGs we are recommending, listed in Table H3, are primarily meant to help implement the APIs themselves, not to facilitate related payer processes, like segmenting sensitive data or the attribution process. We recommend that industry look to existing trust community agreements for guidance on a standardized governance framework and legal terms. These agreements include, but are not limited to TEFCA or others used by state and regional HIEs. We anticipate that affected entities will need to adopt new practices and methods to enable data sharing with new trading partners, including payers supporting new types of interoperability with providers. This final rule affords flexibility to define those approaches. We will continue to evaluate and consider specifications that are well-adapted to meet the legal and regulatory needs for possible future guidance or rulemaking.

Comment: A commenter recommended that CMS exercise caution when selecting authentication mechanism requirements for the Provider Access API and stated that allowing simpler authentication mechanisms may make it easier to incorporate into workflows. Another commenter stated that it is unclear the extent to which payers would be expected to support trust and authentication processes for individual clinicians via the OpenID Connect Core standard, versus SMART integration that could rely on organization-level authentication. They noted that without specificity on workflows for exchange and authentication, authorization, and consent processes, payers and developers will need to support the numerous permutations that could be adopted by providers to address those needs, increasing complexity and burden. The commenter acknowledged the specifications developed by the HL7® Da Vinci Project and others have begun to address technical aspects of those needs, however, they are not yet mature and, because they are technical standards, do not address needed governance agreements.

Another commenter stated that while the FHIR resources in the current Patient Access APIs are mostly reusable, the mechanism for providers to access information is entirely different. The commenter discussed system authentication and access protocols (OAuth and OpenID Connect Core) that are used to enable members to use portal credentials to pull data into a third-party app. The commenter mentions that while OAuth can and should be used for server-to-server connections to enable access to a wider set of data while maintaining security practices, current APIs do not have this capability. Therefore, they believe that this modification to enable a health care provider to access data on multiple patients is a significant change and will require rebuilding the FHIR APIs available for provider access.

Response: Impacted payers are required to use authorization and authentication protocols to verify the requesting provider's identity. However, there is no single security protocol approach that will address all use cases. Additionally, within a single API, implementers may need to utilize more than one protocol to address specific population and trading partner needs. We are finalizing a modification to our proposal to not require the OpenID Connect Core for the Provider Access API. However, we are requiring impacted payers to use the SMART App Launch IG, which includes the capability to perform authentication via OAuth. However, we recognize that other methods such as Backend Services Authorization (which is included in both the SMART App Launch IG Release 2.0.0 and the Bulk Data Access IG v1.0.0), Mutual Transport Layer Security (mTLS), Unified Data Access Profiles (UDAP), or other trust community specified means may be appropriate depending on the needs.

The PDex IG, which we are recommending payers use to support the Patient Access, Provider Access, and Payer-to-Payer APIs (see Table H3 in section II.G.4. of this final rule), includes using mTLS for the purposes of authentication. We are also supporting efforts to further refine the specifications for security (that is, authentication) at scale through UDAP via the FAST Security IG and will consider recommending this specification in the future. We recognize the importance of scalable technologies needed to support secure, protected, and authorized connectivity and communication across a wide range of interested parties throughout the industry. There are several approaches available, including the ones cited by commenters, and others implemented by various trust networks operating throughout the United States today.

Comment: Multiple commenters supported CMS's proposed requirement to leverage the Bulk Data Access IG for the Provider Access API, so that if a provider has a panel of patients associated with a single payer, the payer can share those data asynchronously in one transaction.

Response: We thank commenters for their support of our policies. As discussed in section II.G. of this final rule, we are finalizing our proposal for impacted payers to use the Bulk Data Access IG at 45 CFR 170.215(d)(1) to support implementation of the Provider Access API.

Comment: Multiple commenters recommended that CMS limit the API to only individual data requests and that CMS not require the FHIR Bulk Data Access specification at this time, but instead consider it at a later date after it has been more thoroughly tested by HL7. Multiple commenters also stated that more work is needed on the Bulk Data Access IG before it is mandated, as it has not been adequately implemented; this makes it difficult to assess if it will be able to meet the proposed need and timelines.

Multiple commenters also highlighted concerns with the technical functions of the Bulk Data Access IG and noted that large bulk downloads could pull time away from more urgent requests. The commenters recommended that payers be able to put reasonable limits on bulk data requests or that CMS should remove the bulk data transfer from the initial requirements. A commenter stated that CMS should only require impacted payers to respond to requests for certain patient's data quarterly. The commenter stated this would ensure that vendors do not set a default of daily retrievals of data that risk sharing more patient information than necessary.

Multiple commenters additionally flagged that payers, especially smaller health plans, could struggle to respond to bulk requests within the 1 business day response period and that they could be faced with significant costs to implement this requirement correctly. A commenter stated concern about bulk patient attribution and requested CMS clarification and/or limitations on bulk data sharing requirements.

Response: Bulk data exchange can allow payers to prioritize more urgent requests and defer bulk data requests until a later time when sufficient system resources can be allocated to create bulk data export. However, we remind payers that they are still required to comply with the 1 business day timeframe discussed in section II.B.2.i. of this final rule. We emphasize that although we are requiring impacted payers to support FHIR Bulk Data Access at 45 CFR 170.215(d)(1) under this final rule, this requirement does not obligate them to use it for every data exchange if it is not feasible. However, we agree with commenters that impacted payers have leeway to place reasonable limits on bulk data requests. At the same time, we also believe that the benefits of access to these data outweigh any potential concern that vendors will set daily retrievals of data. This is because a provider would first need to request the data for individual patients, as well as the fact that the Provider Access API is better suited to enable discrete provider use when seeing a patient, rather than ongoing patient monitoring.

Comment: A commenter stated that the PDex IG could support the opt out process by adding a flag to indicate an attributed member has opted out of provider data sharing.

Response: We appreciate the commenter's suggestion and urge impacted payers to explore ways to leverage FHIR IGs for the other processes that we are requiring in this rule.

l. Interaction With ONC Policies

Comment: Multiple commenters made recommendations regarding how CMS can work with ONC. They recommended that CMS work with ONC to implement additional requirements as part of the ONC Health IT Certification Program for developers to implement API interfaces into CEHRT in such a way that fits with provider workflow.

Multiple commenters also recommended that CMS partner with ONC to create guidance regarding implementation of the Provider Access API and the technical capabilities of payers, EHR vendors, and providers. A commenter further suggested that CMS work with ONC to ensure that both payers and CEHRT vendors are aligned in the technical capabilities to implement Provider Access APIs in a way that does not hamper provider workflow and negate efforts to reduce prior authorization burdens.

Multiple commenters strongly encouraged CMS to work with ONC to consider how the Provider Access API could be expanded in future rulemaking to support bi-directional, real-time data exchange between payers and providers to support patient care and to automate prior authorization requests, rather than a one-way data exchange from payer to provider. A commenter stated that including such criteria could ensure compliance with the ONC Cures Act final rule information blocking policies.

Response: We appreciate commenters' support for leveraging of the ONC Health IT Certification Program to ensure APIs are implemented in a standardized fashion. We will continue to work with ONC to explore the adoption of standards and health IT certification criteria where appropriate to streamline data exchange, support interoperability, and increase efficiencies associated with the policies in this final rule, as well as to align and mutually reinforce all of our respective policies.

m. Interaction With Trusted Exchange Framework and Common Agreement

Comment: Multiple commenters suggested that promoting payer to provider information exchange through the TEFCA may be a better path to achieve improved data exchange, including that of large-scale data sets, between payers and providers, rather than a requirement to implement FHIR APIs. A commenter recommended that CMS should collaborate with ONC and the Recognized Coordinating Entity (RCE) to determine an approach for payers to fulfill the payer to provider exchange requirement by joining the TEFCA network once responses are required for requests made as payment and operations exchange purposes, as described in the Qualified Health Information Network (QHIN)) Technical Framework (QTF).

Response: We will continue to work closely with our ONC colleagues on our policies as they relate to TEFCA, including how it can support the exchange of large-scale datasets. As we wrote in the proposed rule (87 FR 76328), we agree that connections between QHINs can support exchange of patient information between payers and providers and could eventually provide the similar functionality to the Provider Access API. As requirements for using FHIR are incorporated into the QTF in the future, Participants and Subparticipants will be positioned to not only exchange the same data using the same standards that we are requiring in this final rule, but to do so under the TEFCA framework. Participants under TEFCA may include those, such as payers, who have entered into a contract to participate in a QHIN. As we expect payer participation in TEFCA to become more widespread in the future, we will continue to explore how we can align policies that require API development or enhancement for payers with TEFCA to ensure Participants and Subparticipants can utilize this network infrastructure to meet these API requirements.

We remind commenters that though we are finalizing our proposals for APIs to use and comply with certain standards and technical specifications, this would not preclude payers from also leveraging QHIN-to-QHIN exchange or HIEs/HINs to exchange patient data.

Comment: A commenter recommended that CMS establish a consistent set of technical standards between TEFCA and the proposed APIs that are required so that the industry does not have to implement different standards depending upon the exchange partner or mechanism for exchange.

Response: ONC and CMS will continue to work closely together to identify ways that TEFCA can support the payer API requirements. We further agree that use of TEFCA could help to reduce burden associated with implementation variation that may arise in developing direct connections with exchange partners. ONC and the RCE are implementing the FHIR Roadmap for TEFCA Exchange to align and accelerate adoption of FHIR across the industry.

n. Federal Matching Funds for State Medicaid and CHIP FFS Expenditures on Implementation of the Provider Access API

In section II.E. of this final rule, we discuss Federal matching funds for certain state Medicaid and CHIP FFS programs' expenditures related to implementation of the Provider Access API (this was also addressed in the proposed rule at 87 FR 76264).

o. Medicaid Expansion CHIP

In section II.E. of this final rule, we discuss implementation for states with Medicaid Expansion CHIP programs (this was also addressed in the proposed rule at 87 FR 76264).

3. Additional Requirements for the Provider Access API

Additional requirements for the Provider Access API regarding attribution, patient opt out process, patient resources, and provider resources are discussed in the sections that follow.

a. Attribution

Patient attribution is a method of identifying a patient-provider treatment relationship. Attribution is a critical component to ensure that patient health data are shared only with appropriate providers. For purposes of our policies, we use the term “attribution” as shorthand for the determination that a treatment relationship exists between the patient and provider. For the Provider Access API, we proposed to require impacted payers to maintain an attribution process to associate patients with their in-network or enrolled (as applicable) providers to ensure that a payer only sends a patient's data to providers who have a treatment relationship with that patient.

We are aware that the process of attribution can relate to many payer functions, including managing contracts, payments, financial reconciliation, reporting, and continuity of care. We thus encourage payers to use processes that they already have in place to attribute patients to their providers for these other purposes.

We expect that many payers will rely primarily on claims data to establish a treatment relationship between a patient and a provider. Other payers might use existing patient rosters for individual providers or organizations, such as ACOs. For new patients, we explained that payers could accept proof of an upcoming appointment to verify the provider-patient treatment relationship. We know that many providers already verify coverage with a payer before a new patient's first appointment. A payer could establish a process that aligns with that query, using some evidence of a scheduled appointment. Once confirmed, the provider would be able to request the patient's data in preparation for the visit. Payers may have other existing processes that they prefer to use. We did not propose a prescriptive attribution process in order to provide payers the flexibility to use systems and processes they already have in place, where appropriate, or to develop new policies and procedures to ensure that access to a patient's data through the Provider Access API is limited to providers who have a treatment relationship with the patient.

CMS has implemented an attribution process in the DPC pilot for Medicare beneficiaries (the Medicare FFS version of the Provider Access API), which can serve as an example for impacted payers. The pilot requires HIPAA covered entities or their business associates to agree to certain terms of service before data can be sent to them. The current Medicare FFS terms of service require each organization to maintain a list of patients that represents the patient population currently being treated at their facilities. CMS requires providers to attest that they have a treatment-related purpose to add a patient to their group. This is accomplished by submitting an attestation with every request to add a patient to their roster. This pilot will continue to test methods to accurately attribute patients to their providers. The information gained from this pilot may assist the industry to develop procedures to identify providers under this requirement.

In addition, HL7 has developed a HL7 Da Vinci Risk-Based Contracts Member Attribution (ATR) List IG. The ATR List IG does not specify how the payer and provider identify these patients, but defines the protocols, data structure, and value sets to be used for exchanging a Member Attribution List. The Member Attribution List typically contains: (1) plan/contract information which is the basis for the Member Attribution List, (2) patient information, (3) attributed individual provider information, (4) attributed organization information, and (5) member and subscriber coverage information. The DPC pilot program has been working with the Da Vinci Member Attribution List workgroup towards compatibility with that IG. The ATR List IG is also informing updates to the PDex IG. We encourage payers to review the information from the workgroup. We further note that the HL7 Argonaut Project, a private sector initiative that advances using FHIR, has developed an IG specifying how to use the Scheduling and Appointment FHIR Resources to communicate this information.

We solicited comments on our proposal to require payers to maintain an attribution process to associate patients with their enrolled or in-network (as applicable) providers to ensure that a payer only sends a patient's data to providers who have a treatment relationship with that patient. We requested comments on other examples of how patients can be attributed to the enrolled or in-network providers from whom they are receiving care, especially for a new patient-provider treatment relationship. We also requested comments on whether and how payers could attribute the patient to the provider at the time a provider makes a request for patient data through the Patient Access API.

As discussed in more detail elsewhere, we are finalizing our proposal without changes.

i. General Comments on Attribution

Comment: Multiple commenters expressed their support for CMS's proposed requirement that impacted payers maintain a process to verify a provider-patient relationship. Multiple commenters also underscored the importance of developing a patient attribution system to ensure those data are shared appropriately. A commenter further stated that payers should only develop an attribution process for in-network providers.

Response: We thank commenters for their support for this proposal. We emphasize that the requirement we are finalizing—that impacted payers be required to make the specified patient data available to providers—only applies to those that are in-network or enrolled with the payer. However, we encourage payers to consider making the Provider Access API available to out-of-network providers. This rule requires that impacted payers maintain an attribution process to associate patients with their providers. Thus, if payers choose to make the API available to out-of-network providers, they would still need to establish an attribution process to ensure that a treatment relationship exists before making patient data available.

Comment: A commenter recommended that CMS align patient attribution requirements and processes across payer types and leverage the CMS Innovation Center to identify where the process can be streamlined. A commenter also recommended that CMS permit payers to set reasonable requirements for providers to demonstrate that the provider is treating an individual, which could reduce the risk of providers making unauthorized inquiries in the system.

Response: We recognize that there are multiple ways for impacted payers to verify a treatment relationship. Payers may already have a process that they want to use, so requiring a different process that deviates from an established and effective workflow may add burden. We encourage payers to work together to establish industry-wide principles and standards for patient attribution. As previously stated, payers are permitted to set requirements for providers as part of their processes, such as requiring an attestation of a treatment relationship and/or a need for the data. We agree with the commenter that such requirements should be reasonable and not overly burden providers.

Comment: A commenter stated that some specialties are referred patients at a higher rate and requested that CMS take into account the additional burdens of the attribution process for providers who may only see a patient once. Another commenter suggested that the final rule should ensure that any attribution process will not negatively impact those patients who have a high number of providers. A commenter further noted the significant technological challenges of attribution and expressed concern that patients that most need their data to follow them through clinicians, systems, and payers are those that are most likely to have data discontinuity due to clinicians receiving erroneous patient data.

Response: We emphasize that payers should consider all types of patients and providers when designing their attribution processes to prevent creating disparities. Making the specified data available via API may be particularly beneficial for patients experiencing data fragmentation. Establishing and maintaining an attribution process will benefit patients who may see multiple providers, so that all such a patient's providers (assuming they are in-network or enrolled) can have access to necessary information. We remind readers that we are not being prescriptive on when attribution needs to take place, as long as it occurs before patient data are made available through the Provider Access API. We encourage payers to perform the attribution prior to the first visit and/or in a reasonable amount of time to determine whether there are legal restrictions on the data that may be shared and so that providers can have the opportunity to review any relevant data in proximity to the patient encounter.

Comment: A commenter expressed concern regarding the attribution process for Medicaid patients, noting that developing a proactive process for providers who will see a patient would be challenging for Medicaid agencies. Another commenter stated that there should be special consideration for patients with mental health and substance use disorder issues. For example, proof of upcoming appointments can be an inadequate test of a patient-provider relationship due to high “no-show” or cancellation rates. A commenter also stated that verifying a provider-patient relationship will be difficult to accomplish in a single business day.

Response: We understand the concerns of Medicaid agencies, including challenges in attributing new patients, and believe that proof of an upcoming appointment could sufficiently indicate the patient-provider relationship. However, impacted payers have latitude to determine when proof of an upcoming appointment can be used. For example, payers may implement a policy where providers can only successfully receive requested data if they have an upcoming appointment with the given patient within a specific number of days. Such a process can also mitigate potential “no show” or cancellation situations which one commenter cited. Many providers confirm appointments in the days prior to their appointment. A patient who confirms their appointment in proximity to the visit is less likely to cancel or not show. As stated previously, impacted payers must send the requested data no later than 1 business day after the payer receives a request and the following conditions are met: (1) the payer authenticates the identity of the provider and attributes the patient to that provider; (2) the patient has not opted out; and (3) disclosure of the requested information is not prohibited by law. Nothing in the rule requires payers to establish that these conditions are met in one business day; rather, data must be made available through the Provider Access API no later than one business day after these conditions are met. We encourage payers to verify these conditions are met in advance as often as possible. If this is difficult or not possible, such as in the case of new patient visits, we strongly encourage payers to complete the attribution process in a reasonable amount of time with minimal involvement from the provider, so as not to increase burden.

ii. Providers' Role in Attribution

Comment: A commenter sought clarification from CMS regarding whether the provider or the payer must maintain records of the attribution. They also asked how to account for ACO or value-based care coverage models that permit patients to choose a provider. Another commenter agreed, pointing out that most attribution processes in these coverage models are currently geared toward identifying a singular accountable primary care physician within value-based arrangements and that often, a patient's identification of “their doctor” may not match results generated through automated attribution approaches.

Response: This final rule imposes on impacted payers the requirement to maintain a process to attribute a patient to in-network or enrolled providers. Payers are responsible for maintaining attribution records and ensuring that only in-network or enrolled providers who have a treatment relationship with the patient (or should they choose, out-of-network or unenrolled providers to whom the impacted payer has attributed a patient) have access to patient data. However, the process of attribution inherently requires provider participation in some instances. For example, when a patient has their first visit with a particular provider, we cannot expect the payer to have that information without some provider input. In other instances, payers may involve patients in their attribution processes, especially if they wish to account for providers who might not be identified via existing automated approaches. Should they do so, any such involvement should not be onerous for the patient.

Comment: A commenter stated that CMS should allow payers and providers to adopt an approach that assures payers that any provider request for patient data meets the requirements of this rule, while also allowing providers to delegate the ability to request information to support staff. Another commenter sought clarification on whether physicians and their staff would be expected to operate outside of their normal workflows to demonstrate a care relationship with a patient. A commenter sought clarification on whether multiple providers could be attributed to the same patient at a time. A commenter further sought clarification on whether the rendering provider is the provider who has a treatment relationship with the patient, or if the billing provider could also be attributed to the patient to request data using the Provider Access API. A commenter stated that CMS should require payers to make an attribution prior to the first visit.

Response: While we are not being prescriptive in how payers should design their attribution processes; we caution that payers should not set overly onerous criteria for providers to prove their treatment relationship with a patient. Both patients and providers will benefit from the provider having access to the specified information; the attribution process should not impede this benefit. Furthermore, it is appropriate for providers to be able to delegate administrative tasks to their staff. Similar to other processes, such as submitting claims, payers should set reasonable requirements that allow staff to provide information or perform tasks on a provider's behalf.

We do not intend to overburden providers or their staff with the attribution process. As stated, we believe that payers can attribute most patients to providers via claims, which should not require providers to operate significantly outside their normal workflows to demonstrate a care relationship with a patient. Furthermore, we acknowledge that patients can (and in many cases should) be attributed to multiple providers who would be able to request access to the patient's data. This may apply, for example, to a multi-provider practice or an ACO.

Comment: Multiple commenters recommended that CMS reevaluate the attribution process as outlined in the proposed rule. Multiple commenters also stated that payers have significantly different attribution processes, and this adds burden to hospitals and SNFs. A commenter agreed that varying attribution processes across payers would increase administrative burden for providers and clinics under the proposed rule. A commenter recommended that CMS permit providers not only to attribute patients through individual requests, but also to be able to submit information in a bulk format by submitting a list of all a payers' enrollees currently in their care. Another commenter cautioned CMS to not adopt any standard for attribution more rigorous than the HIPAA Privacy Rule and avoid imposing burdensome requirements.

Response: We emphasize that the requirement to implement an attribution process applies to impacted payers, not providers. As discussed, a payer may verify the patient treatment relationship in a variety of ways. While verification may necessitate some action by the providers, we strongly encourage payers to implement a process that is least burdensome to providers as possible. When information from providers is required, payers should allow bulk submission in order to impose the least possible burden on providers. Finally, because we did not propose to adopt any attribution standard or method at all, we are not adopting one that is more rigorous than what is required under the HIPAA Privacy Rule.

iii. Attribution Process Design and Suggestions

Comment: A commenter recommended that CMS establish minimum attribution criteria and a uniform claims attribution process. Multiple commenters suggested that CMS create guidance on best practices and specific ways that payers can accurately attribute patients to specific providers and when a payer can determine that a treatment relationship between a patient and provider has ended to allow flexibility in the attribution process rather. Multiple commenters also stated that payers should be able to “un-attribute” a patient from a provider when a treatment relationship is inactive to protect patient data. A commenter stated that it is crucial for CMS to define the timeline for which the patient attribution roster on both the payer and provider side must be updated to ensure that it is never shorter than the 30 days mandated by some states. A commenter also stated that the attribution process will be difficult because it will require two separate processes, one for new and one for established patients. A commenter further stated that payers will need to prioritize implementation of the Provider Access API, which will make developing an attribution process difficult.

Response: In order to permit impacted payers the flexibility to leverage their existing processes or utilize another method that may be the least burdensome for them, we did not propose, and are not finalizing, a standardized attribution method. In the DPC pilot, for a provider to establish a treatment-related purpose for viewing patient data, they must have an existing “treatment relationship,” defined as a processed claim with the provider's NPI number for that patient within the past 18 months. The DPC pilot currently does not have the ability for providers to access data for patients before their first claim. As noted in the proposed rule and previously mentioned, with each roster addition or renewal, a provider must also attest that there is an active treatment relationship. We have had significant interest in our DPC pilot from providers and provider organizations that participate in the Medicare program and continue to gather information from interested parties. However, we do not have information beyond what is currently publicly available to share at this time.

This DPC process is just one attribution method and we encourage payers to leverage their existing processes and develop methods that work best for them and that place the least amount of burden on providers. Nothing in this final rule would require a specific timeframe after which a treatment relationship expires. Payers are permitted to establish a period after which the treatment relationship is considered inactive and a patient could be un-attributed from a provider. However, many patients may only see a particular provider annually, which would clearly signify a continuing treatment relationship. We did not propose a requirement for providers to maintain a patient roster, though it may be required under other Federal or state regulations or under the provider's contract with the payer.

Finally, we understand that some payers may have challenges implementing an attribution process. One of the reasons we are finalizing a 2027 compliance dates rather than the proposed 2026 dates (see section I.D. of this final rule) is to give impacted payers additional time to prepare and test any new or modified process. We intend to provide more information and education on potential authentication processes prior to the compliance dates.

Comment: Multiple commenters expressed concern with how difficult it is to verify the patient-provider relationship. A commenter sought clarification on the intended level of attribution for access to a member's data. Another commenter stated their belief that the proposed attribution requirement, specifically how a “treatment relationship” is defined, requires further development and feedback from consumers before implementation so that they can feel in control of their data. They noted that it is not uncommon to have dozens of providers involved in a single patient's care, nor is it uncommon to have a single interaction with a specialty provider, or to have a provider consult another provider on a course of care without the patient's knowledge.

Response: Payers should be able to meet the requirement to have an attribution process by verifying the patient-provider treatment relationship in a variety of ways, as discussed in this section. Payers should consider Federal and state law, internal risk policies, and their own processes to determine what level of assurance they require to attribute a patient to a provider for the Provider Access API. Establishing specific requirements or procedures would add burden to payers who may establish different, but equally acceptable and effective, processes.

We do not believe it is necessary to define a “treatment relationship” only for the purposes of this rule. Payers may have different definitions that may be based on Federal or state law, internal policies, or provider contracts. Therefore, an additional definition would be unnecessary, duplicative, and possibly confusing. We do note that if there is doubt about whether a patient and provider are in a treatment relationship, information from the patient could be one method of making that determination. However, we emphasize that placing burden on a patient should only be used a last resort, and only if the benefits of making data available outweigh that burden.

In some cases, verifying a treatment relationship could result in providers having access to data about patients they have treated only once and whom they may not treat again. However, we believe that these providers would have little reason to request this information because they would be creating unnecessary work for themselves without benefitting patient care. Further, data from the Provider Access API is only required to be made available to in-network or enrolled providers. Such providers have already been vetted to participate in the impacted payer's network, so it is unlikely these participating providers would seek out patient data they do not need for patient care. Finally, some impacted payers might utilize an attestation process, as suggested by some commenters, where providers must attest that they have a clinical need for any data they request. A provider requesting data that they do not need could endanger their payer network or contract status if they fraudulently attest that they are only requesting data for patient care, should the impacted payer implement such a policy. We thus believe that the benefits of the Provider Access API outweigh concerns that already-attributed providers will inappropriately request patient data. We look forward to working with interested parties to develop best practices for attribution processes.

Comment: A commenter stated that a claims-based approach to verifying a treatment relationship is the most reliable. Conversely, another commenter stated that it was not necessary to verify a treatment relationship through claims data. They recommended using processes that show the onset or evidence of treatment like Admission, Discharge, Transfer (ADT) or Scheduling Information Unsolicited (SIU) transaction. Another commenter stated that a hospital admission letter should be enough for payers to grant the provider access to the Provider Access API for the specified patient. A commenter also encouraged payers to consider whether a provider's signed order for treatment (on behalf of a patient) is enough to establish this relationship. A commenter highlighted that the CMS companion guide on the HIPAA-mandated eligibility transaction supporting Medicare Beneficiary Matching could serve as a model for data elements that could facilitate attribution. These data and the associated eligibility and benefit request essentially serve as proof of a scheduled appointment. A commenter also recommended leveraging TEFCA for the attribution process.

Response: Because different approaches and standards for an attribution process continue to evolve, we did not propose to specify how payers should identify whether a specific patient can be attributed to the requesting provider. Instead, we encouraged the community to continue to collaborate on viable approaches. We agree that a claims-based approach is both reliable and puts little, if any, burden on providers. We expect that payers will also find this to be the simplest way to verify the treatment relationship because they will have a record of a treatment relationship as of the most recent date of service on a claim. We also agree that the other methods suggested could be leveraged by payers to attribute patients to providers for the Provider Access API.

Comment: Multiple commenters highlighted existing resources or models that CMS could leverage to establish an attribution process. Another commenter recommended that payers be allowed to use the existing processes to verify treatment relationships, including the ATR List IG. Multiple commenters also stated that this IG could be updated to provide the necessary tools to support implementation of the attribution process and some recommended that CMS adopt that standard when it is mature enough for large scale implementation.

Multiple commenters expressed support for HIEs and HINs as unique entities that have the capability to create and manage patient-provider attribution for the Provider Access API. The commenters provided an example from the Active Care Relationship Service (ACRS), which enables organizations to send data files that record the relationships between their providers and patients. Another commenter stated that CMS should work with HIEs to expand capabilities and create IGs and processes for patient matching, attribution, and opt out to support the Provider Access API.

Response: We thank readers for their comments and will consider them for future guidance or rulemaking. As we did not propose a specific attribution method, we encourage impacted payers to consider these existing resources and models. As members of the HL7® Da Vinci Project, we will continue to monitor development of the ATR List IG.

Impacted payers may already have multiple arrangements in place with providers to support data exchange, and may even participate in community, local, state, or private HIEs. These HIEs may already have a process to attribute patients to providers. To the extent it would benefit payers, we encourage them to work with HIEs and HINs to facilitate the Provider Access API. Nothing in our policies prohibits a payer from using an intermediary to aid with patient matching, data exchange, or data hygiene. Once again, our goal is to allow payers to develop the least burdensome approach to attribution, and we encourage collaboration on potential solutions.

Comment: Multiple commenters requested that CMS consider implementing a national, digital patient identification standard. A commenter recommended that CMS implement a standardized patient identification framework to ensure that patient data are not inadvertently co-mingled and does not pose a threat to patient privacy and safety within the Provider Access API. Another commenter stated that an electronic standard should be developed to verify a patient relationship and appointment status.

Multiple commenters stated the importance of making sure the CEHRT programs require that record requests can only be made when a treatment relationship is present. A commenter recommended that CMS and ONC work together to establish standards for ONC's Health IT Certification Program.

Response: A standard unique health identifier for each individual, which is in accord with numerous commenters' recommendations, would be associated with a HIPAA standard arising at section 1173(b)(1) of the Act. We will continue to work with our Federal partners as we consider future guidance or additional rulemaking within the ambit of our authority.

Comment: A commenter recommended that CMS establish a workgroup or advisory committee to establish an appropriate attribution process. Another commenter recommended that CMS monitor the state of evolving technology and maintain flexibility in its requirements as technology continues to develop.

A commenter recommended CMS utilize public feedback to establish minimum criteria as proof of an authentic patient-provider relationship, because a lack of clear guidance in this area may cause disputes between payers and providers regarding the appropriate criteria for establishing proof of a relationship.

Response: We intend to continue our work with industry as they develop attribution processes that do not overly burden payers, providers, or patients. Additionally, based on feedback from the public, we believe that the public would benefit from further educational resources, and we will explore avenues by which we may offer those in the future.

Comment: A commenter asked whether payers can integrate an attestation of a treatment relationship with a FHIR transaction.

Response: While we are not prohibiting use of a FHIR transaction as part of the attribution process, the IGs we are recommending are primarily meant to help implement the APIs themselves, not to facilitate related payer processes, like the attribution process.

b. Opt Out

We proposed that all impacted payers would be required to establish and maintain a process to allow patients or their personal representatives to opt out of (or if they have already opted out, to opt back in to) having the patients' data available for providers via the Provider Access API. We noted that this differed from our Payer-to-Payer API, which was structured as an opt in process. Similar to the attribution process, as previously discussed, we did not intend to be prescriptive regarding how this opt out process should be implemented, but payers would be required to give all patients or their personal representatives the opportunity to opt out, including those currently enrolled on the compliance dates, before making patient information available via the Provider Access API, and at any time while the patient is enrolled with the payer.

We did not propose to require specific methods for patients to opt out, but anticipated that payers would make that process available by mobile app or on their website. We also anticipated that mail, fax, or telephonic methods may be necessary alternatives for some patients, which payers would have to accommodate. We invited comments on whether we should establish more explicit requirements regarding the patient opt out processes.

Our proposal would require impacted payers to allow patients to opt out of the Provider Access API data exchange for all providers in that payer's network. However, we also encouraged payers to implement processes that allow more granular controls over the opt out process, so patients can opt out of making data available to individual providers or groups of providers. We did not propose to require those more granular controls, as we were concerned about the potential administrative and technical burden this would place on some payers. However, we requested comments about the technical feasibility of implementing an opt out process that would allow patients to make provider-specific opt out decisions, and whether we should consider proposing such a requirement in future rulemaking.

We appreciate commenters' feedback to our requests, and understand concerns about the potential for administrative burden associated with providing patients with more granular controls over data sharing, as well as which specific providers can receive their data. We used the term “granular” broadly because we wanted to know which data elements commenters thought were most important to be able to segment out. We are committed to minimizing the burden on patients and providers as much as possible and continue to weigh the benefits of providing patients with more control over their data against the potential administrative burden on impacted payers. We appreciate the suggestions we received for how to implement a more granular opt out approach and will consider these suggestions for future rulemaking.

We proposed an opt out approach because, as we discussed in the proposed rule, opt in models of data sharing have been shown to inhibit the utilization and usefulness of data sharing efforts between patients and health care providers. We acknowledged that there are positives and negatives to both opt in and opt out policies, and that some patients may prefer to control or direct their health information via an opt in process, which requires affirmative permission from a patient before their data can be shared. However, patients who are less technologically savvy or have lower health literacy may be less likely to use the Patient Access API, so having an opt out policy for the Provider Access API would facilitate sharing data directly with the provider, without requiring action by the patient. We stated our belief that opt out would promote the positive impacts of data sharing between and among payers, providers, and patients to support care coordination and improved health outcomes, which could lead to greater health equity. In formulating our proposal, we carefully weighed the issues related to both opt in and opt out policies, especially as they relate to making data available to providers. We wrote that a policy defaulting to sharing data with providers, unless a patient opts out, appropriately balances the benefits of data sharing with the right of patients to control their health information. As we also detailed in the proposed rule, payers would be responsible for providing patient resources to ensure that patients understand the implications of opting out. We noted that, should patients not opt out of data sharing, then the data that would be made available via the Provider Access API would be available to in-network providers whose identity has been authenticated and to whom the patients have been attributed, meaning that the payer has verified a treatment relationship between the provider and the patient. However, we stated that our proposals, taken together, gave patients ample opportunities to change their data sharing permission as they see fit.

As we explained in detail in our proposed rule (87 FR 76260), opt in models can create greater administrative burden for smaller health care organizations, depending on where the responsibility for obtaining and updating the patient's data sharing permission is held. We also pointed to the fact that a larger health care organization that employed an opt in model, the Veterans Health Administration within the VA, saw the vast majority of provider requests for patient information rejected for lack of patient permission.

We additionally stated our belief that an opt out model could address equity issues by ensuring that patients from lower socioeconomic and minority groups, who are more likely to have limited health literacy, can benefit from the improved care that the Provider Access API can facilitate. We believe that data sharing as the default option for all patients enhances both personal and organizational health literacy, as these terms are defined by the Healthy People 2030 report, while protecting patients' choice to limit data sharing.

The ability for patients to opt out was specific to the data we proposed requiring payers to share via the Provider Access API. As discussed previously, nothing in the proposed rule would alter any other requirements under applicable privacy and security laws and regulations. If there is other authority to share patient information with respect to which a patient may not opt out, such as disclosures required by law, nothing in this proposal would change the payer's obligation to disclose that information. However, we encouraged payers and providers to use the proposed Provider Access API as a technical solution to transmit data between payers and providers beyond the scope of these policies, provided such disclosure is consistent with all other applicable requirements, such as the requirements set out in the HIPAA Privacy Rule and the HIPAA Security Rule.

We value the importance of safeguarding the quality and integrity of patient health information. We acknowledged that there may be potential program integrity risks associated with sharing patient data under both an opt in and opt out models. We expect that if payers identify any vulnerabilities, they will work to make changes to their operations to address risks that could lead to potential fraud and to limit the impact on patient information.

We requested comments on our proposal for a patient opt out framework for the Provider Access API. As discussed in more detail elsewhere, we are finalizing this proposal without changes.

i. General Comments on Opt Out

Comment: Multiple commenters expressed support for the proposed policy to require an opt out framework for the Provider Access API. Commenters provided various rationales for their support, including that the opt out framework would enable patients to protect and control their health information while still making patient data available to providers, encourage increased data transmission, and allow patients to terminate a provider's access to their data when the patient no longer has a treatment relationship with the provider.

Multiple commenters specifically expressed their support for an opt out approach instead of an opt in approach. These commenters noted that it is less burdensome for payers and that an opt in approach would require patients to have a higher level of education or better technology and health literacy to utilize than an opt out process, which may result in fewer patients having their data exchanged via the Provider Access API under an opt in approach.

Response: We appreciate the comments we received in support of our proposal to allow patients or their personal representatives to opt out of the Provider Access API if they do not wish for their data to be made available via the API requirement. We agree with the commenters that an opt out approach will enable patients or their personal representatives to better protect and control their health information while still making patient data available to providers. We remind commenters that the opt out would not necessarily allow patients or their personal representatives to terminate a provider's access to their data when the patient no longer has a treatment relationship with the provider, because we did not propose to require a granular opt out policy (though some payers might choose to implement such a policy). However, we did note in section II.B.3.a. of this final rule that payers have latitude to determine when a patient-provider treatment relationship ends via their attribution process. Thus, regardless of the opt out granularity, payers should also use their attribution process to determine whether and when an individual provider should have access to a patient's data via the Provider Access API.

Comment: Other commenters voiced their concerns with an opt out approach but did not specifically recommend that CMS take a different approach. Multiple commenters noted that offering patients an opportunity to opt out would limit information sharing and that information sharing is important to facilitate the prior authorization process. Multiple commenters also stated their belief that an opt out approach would reduce, or even remove patient control over their health information. Those commenters stated that because CMS expects most patients not to opt out, the confidentiality of this patient data will effectively not be the default.

Response: For reasons we discussed in both the proposed rule and previously, the opt out approach appropriately balances the benefits of data sharing with the ability of patients to control their health information. All patients will be given the opportunity to opt out of our Provider Access API policy. We agree that this information sharing is important to improve the efficiency of the prior authorization process and to ensure that patients have timely access to the care they need. While patients may opt out of data flowing from their payer to their provider via the Provider Access API, they cannot opt out of the prior authorization process established by their payer or the communications between their provider and payer that enable that process.

Comment: Multiple commenters recommended that CMS adopt an opt in approach instead of an opt out approach for the Provider Access API. Commenters provided various rationales for recommending an opt in approach, including that an opt in would give patients more control over their data and is more understandable than an opt out process. A commenter explained that while they support an opt in approach, they do not agree that it would benefit disadvantaged people (such as people with low health literacy or limited English proficiency) because patients may not understand what it means to give permission for data sharing. Multiple commenters also supported an opt in approach due to patient privacy concerns with opt out. Specifically, a commenter with concerns about sharing patients' mental health and substance use information recommended that CMS adopt an opt in process, including a requirement for patients to provide written authorization before such information is accessible through the Provider Access API. The commenter explained that there are laws in place requiring a written authorization from a patient to disclose mental health and substance use information. Another commenter also recommended that CMS align requirements for the Provider Access API opt out approach with consent requirements under 42 CFR part 2. A commenter further stated their belief that most patients would choose to opt into the Provider Access API if they are adequately informed of their rights and the potential for API data exchange.

Response: We refer readers to our proposed rule for a full discussion of why we proposed an opt out patient permission framework (87 FR 76259). As discussed elsewhere, we are finalizing a requirement that impacted payers must provide patients with plain language information about the Provider Access API, including how to opt out of data sharing, in order to help maximize patient control. This requirement should ensure that patients, including those with low health literacy or limited English proficiency, are aware of their rights and have the opportunity to make an informed decision about whether or not to allow payers to share their data with their providers through the Provider Access API. We further remind readers that all data sent and received via the Provider Access API must still be handled consistent with all other applicable laws and regulations regarding disclosure of these data. For instance, rules of confidentiality for patient records associated with mental health or substance use disorder, such as 42 CFR part 2, which may require patient consent to share with providers, will still apply.

ii. Interaction With HIPAA

Comment: Multiple commenters stated that a process requiring patient permission for data sharing via the Provider Access API is not necessary because the HIPAA Privacy Rule permits PHI disclosure without patient permission under certain circumstances. Specifically, they reasoned that patient permission is not necessary if the PHI disclosed via the Provider Access API falls within the scope of HIPAA treatment, payment, and operations (TPO) disclosures, and recommended that CMS limit the data shared via the Provider Access API to the scope of permitted TPO disclosures. In support of their recommendation, these commenters noted that requiring an opt out process could be confusing and cumbersome to patients, negatively affect patient care, and would conflict with Federal and state laws (including the HIPAA statute). In a similar vein, commenters stated that CMS should rely on the HIPAA Privacy Rule requirements instead of requiring an opt out process, and a commenter suggested that CMS require impacted payers to include the Provider Access API exchange in their HIPAA Notices of Privacy Practices (NPP). Another commenter recommended that CMS make it clear that payers may still share certain patient health information with providers if it falls under the scope of a TPO disclosure, even when a patient elects to opt out of data sharing. Multiple commenters recommended that CMS provide additional guidance as to whether the Provider Access API is to be used for purposes beyond treatment, and indicated that providers should be able to access payer data for other purposes permitted under the HIPAA Privacy Rule, such as payment.

Response: We understand that there are those who believe that an opt out patient permission process is not necessary, given existing HIPAA Privacy Rule provisions that permit PHI disclosure without an individual's authorization under certain circumstances. However, we emphasize that by virtue of this final rule, impacted payers would be required to disclose any PHI specified within the content standards for the Provider Access API, if the applicable requirements of this rule were met. That disclosure would be permitted under the HIPAA Privacy Rule as “uses or disclosures that are required by law,” rather than as a permitted TPO disclosure. Required by law disclosures are limited to the relevant requirements of such law, not to the HIPAA minimum necessary standard, thereby ensuring that all content required by our Provider Access API policy may be disclosed. Because our policies would potentially give providers access to more than what would have been considered to be the minimum necessary PHI under the HIPAA Privacy Rule for certain purposes (for example, administrative data in the USCDI that would not be used for treatment purposes), we are requiring impacted payers to give patients or their personal representatives an opportunity to opt out so that they have some control over whether or not to share this additional data with their provider(s). We believe that patients should control their own data to the extent possible and with an opt out approach to data sharing, we are giving patients this opportunity. Where the requirements of this rule change how covered entities or their business associates may use or disclose PHI, covered entities should consider their obligations under the HIPAA Privacy Rule.

We emphasize that the opt out process described here only applies to the Provider Access API policies in this final rule. That is, the requirement for impacted payers to share individual claims and encounter data, all data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI), and certain information about prior authorizations maintained by the payer with a date of service on or after January 1, 2016, with in-network providers who have a treatment relationship with the patient. If a patient or their personal representative opts out under our policy, then the impacted payer should not share these data with a provider who requests it under this policy. However, there may be other permissible bases for payers and providers to share data, such as under the HIPAA Privacy Rule's permitted uses and disclosures to carry out TPO. Patients or their personal representatives do not have the ability to opt out of a payer or provider using the API itself as a mechanism for sharing data under such bases for disclosure.

We also note that the data that may be shared under other permissible bases, such as the TPO exception, may overlap with the data required to be shared by our Provider Access API policy. For instance, a payer may be permitted to disclose clinical data included in a content standard at 45 CFR 170.213 with a health care provider for treatment purposes under 45 CFR 164.506(c)(2). If that disclosure is permissible, a patient opting out of the Provider Access API policy in this final rule would not prohibit a payer from using the Provider Access API to make that disclosure. In addition, there may be permissible bases for sharing data outside the scope of our Provider Access API policy. As an example, payers may be permitted to disclose clinical data that is not included in a content standard at 45 CFR 170.213, such as information related to SDOH, under the TPO exception. Similarly, a patient or personal representative opting out of the Provider Access API policy in this final rule would not prohibit a payer from using the Provider Access API as the mechanism to make that permissible disclosure.

Per 45 CFR 164.506(b), covered entities may create a process to obtain consent from an individual to use or disclose PHI to carry out TPO. Per 45 CFR 164.522(a), individuals also have the right to request restrictions on how a covered entity will use and disclose PHI about them for TPO. Except in limited circumstances, a covered entity is not required to agree to an individual's request for a restriction. Where a covered entity agrees to a restriction, it is bound to it unless the restriction is subsequently terminated. We emphasize that the opt out process described in this final rule is specific to the Provider Access API policy and therefore is not, on its own, a consent mechanism per 45 CFR 164.506(b) or an agreed-upon restriction per 45 CFR 164.522(a).

Payers should make these nuances clear to patients in their required educational resources, so that patients understand that their PHI may still be shared in some instances, even if they or their personal representative opts out of the Provider Access API policy.

iii. Interaction With Health Information Exchanges

Comment: Multiple commenters noted that HIEs would be great partners for payers when implementing the Provider Access API, with one noting that they could be used to reduce the number of endpoints providers would need to query for patient information. Commenters suggested that because many providers already have connections to HIEs set up within their EHRs, HIEs could act as a conduit for the information impacted payers are required to make available. Furthermore, commenters stated that HIEs could make available patient clinical data beyond what is maintained by the payer.

Response: We agree that HIEs could be helpful partners for payers when implementing the Provider Access API and nothing in this rule would prohibit an impacted payer from partnering with an HIE to meet its requirements. As a commenter noted, HIEs have extensive experience and expertise with patient matching and attribution, as well as with various consent models. We additionally agree that provider participation in an HIE can reduce the number of endpoints they would need to query for care coordination and treatment. We further encourage payers to look to HIEs or HINs as models for implementing a legal framework for data exchange.

Comment: Multiple other commenters recommended that CMS both explain and reexamine its interpretation of 42 CFR 431.306(d) and 457.1110(b) to prohibit Medicaid and CHIP programs from releasing beneficiary information to outside sources without first obtaining permission from the beneficiary or their personal representative. The commenters stated that CMS's current interpretation would effectively prohibit Medicaid agencies from participating in HIEs for Provider Access API and TPO purposes. The commenters stated that CMS should consider expanding this to include out-of-network providers.

Response: We do not agree that 42 CFR 431.306(d) and 457.1110(b) prohibit Medicaid or CHIP agencies from contracting with an entity that offers the technology to allow for digital access and transfer of a patient's medical records, often referred to as an HIE. Section 1902(a)(7) of the Act, which our regulations at 42 CFR part 431, subpart F, implement, requires that a state's Medicaid plan provide safeguards which restrict the use or disclosure of information concerning Medicaid applicants and beneficiaries to purposes directly connected with administration of the state plan. Our regulations at 42 CFR part 431, subpart F, set forth requirements for states to safeguard Medicaid applicants' and beneficiaries' information in accordance with section 1902(a)(7) of the Act, including requirements for safeguarding the information, what types of information must be safeguarded, and when and how to release otherwise safeguarded information. The same requirements also apply to separate CHIP programs through a cross reference at 42 CFR 457.1110(b). The disclosures of beneficiary data to an HIE contracted to develop and maintain the required Provider Access API would be directly related to the administration of the state plan, because sharing beneficiary data through the Provider Access API supports the provision of services for beneficiaries, as described at 42 CFR 431.302(c). Access to beneficiary data could help a provider better manage a beneficiary's total care because the data would provide a more in-depth medical history, enable more informed decision making, and potentially prevent orders for, or the provision of, duplicative services. Further, under section 1902(a)(4) of the Act, Medicaid agencies may contract with organizations to enhance the agency's capability for effective administration of the program.

The regulation at 42 CFR 431.306(d) generally requires states to obtain permission from an individual Medicaid or CHIP applicant or beneficiary, or their personal representative, before responding to a request for information from an outside source, or disclosing that applicant's or beneficiary's data safeguarded under 42 CFR 431.305. There is no requirement for a state Medicaid or CHIP agency to obtain permission from an individual or family member prior to providing information about a Medicaid or CHIP beneficiary to an enrolled Medicaid or CHIP provider because enrolled providers are not outside sources as described at 42 CFR 431.306(d). Enrolled Medicaid and CHIP providers are part of a state's Medicaid and/or CHIP FFS programs because they are contracted to support the agency's administration of its Medicaid or CHIP state plan. Specifically, an enrolled Medicaid or CHIP provider has a provider agreement with the Medicaid or CHIP agency to provide Medicaid or CHIP benefits and services under the state plan. Thus, the state Medicaid agency could share Medicaid or CHIP beneficiary information with enrolled providers for purposes directly connected to administration of the state plan, without prior permission from the Medicaid or CHIP beneficiary required by 42 CFR 431.306(d) and 457.1110(b) respectively.

Similarly, state Medicaid and CHIP agencies may share Medicaid and CHIP beneficiary information with entities with which the state Medicaid or CHIP agency has contracted to support the agency's administration of its Medicaid or CHIP state plan. Such contractors would not be considered “outside sources” because they are contracted to carry out functions directly related to administration of the state Medicaid or CHIP plan, such as case management and long-term services and supports for Medicaid or CHIP beneficiaries. Thus, if a state Medicaid or CHIP agency contracts with an HIE to carry out administrative functions of the state's Medicaid or CHIP program, such as developing and maintaining the required Provider Access API, the HIE would not be considered an “outside source” and the state Medicaid or CHIP agency could share Medicaid or CHIP beneficiary information with the HIE for the purposes directly connected to administration of the state plan, without prior permission from the Medicaid or CHIP beneficiary required by 42 CFR 431.306(d) and 457.1110(b) respectively.

In addition, to receive beneficiaries' information from the Medicaid or CHIP agency, Medicaid or CHIP providers, plans, or contractors must be subject to standards of confidentiality comparable to those of the state Medicaid or CHIP agency in accordance with 42 CFR 431.306(b) and 457.1110(b) respectively. Furthermore, the Medicaid regulation at 42 CFR 434.6(a)(8) requires that each of the state Medicaid agency's contracts must provide that the contractor safeguards information about beneficiaries as required by 42 CFR part 431, subpart F. Under these requirements, if a state Medicaid or CHIP agency contracted with an HIE or other entity, the contractor would be required to meet the same standards of confidentiality as the state Medicaid or CHIP agency (as set forth in section 1902(a)(7) of the Act and our implementing regulations at 42 CFR part 431, subpart F), including but not limited to—

• Providing safeguards that restrict the use or disclosure of information concerning applicants and beneficiaries to purposes directly connected with the administration of the plan in accordance with section 1902(a)(7) of the Act and 42 CFR 431.300 and 431.302; and
• Not disclosing data to an outside source, such as providers that are not enrolled with the state Medicaid or CHIP agency, and that might be participating in an HIE, without prior permission from the individual in accordance with 42 CFR 431.306(d).

iv. Opt Out Process Design

Comment: Commenters provided thoughts about the implementation of the proposed opt out requirement. Multiple commenters suggested that CMS require a standardized opt out process to improve the patient and provider experience. A commenter expressed concern that the proposed implementation flexibility could be difficult for patients to navigate, while another commenter requested clarification on what opting out and opting back in means.

Response: We agree that it is important to make it easy for patients or their personal representatives to opt out of data sharing. However, it is also important to give payers flexibility in how they implement the opt out process required by this rule. We recognize that payers' approaches may vary depending on their systems, capabilities, and specific enrollee population. Requiring a specific process could impose unnecessary burden on payers. We remind readers that regardless of what process payers choose, a patient or their personal representative must have the ability to change their data sharing permission at any time. For example, if a patient or their personal representative previously opted out of having their data shared under the Provider Access API policy, they should be able to reverse this decision, effectively choosing to opt back into having their data shared under the Provider Access API policy. We additionally note that each of our policies in this final rule is targeted toward individual patients, not any family members that may be covered through the same benefits. In some cases, applicable law may allow one individual (such as a parent or guardian) to act as a personal representative for another individual covered under the same benefits (such as a minor) and could therefore opt out of data sharing under the Provider Access API for that person. No data should be shared about any patient that has opted out (or whose personal representative has opted out), regardless of whether another patient covered under the same benefits has chosen to not opt out. We will continue to monitor implementation of the Provider Access API opt out requirement to ensure payers' opt out processes for the Provider Access API are easy and intuitive for patients or their personal representatives to use.

Comment: Commenters recommended that CMS include several additional, explicit requirements related to the Provider Access API opt out process. Multiple commenters also recommended requiring or permitting payers to incorporate the opt out process into their existing platforms and communications, including patient portals, payers' websites, and within payers' regular communications with patients. A commenter encouraged CMS to collaborate with interested parties to develop a single platform for patients to give permission for data sharing.

Response: While we are not requiring impacted payers to incorporate their opt out processes into their existing platforms and communications, we generally expect that that would result in the least amount of burden on payers and patients. There are solutions available that could be leveraged to manage permissions across payers, such as HIEs. We encourage impacted payers to investigate a variety of options to determine the solution that is best for them and their patients.

Comment: Multiple commenters made recommendations related to the accessibility of the opt out process. They recommended that CMS require impacted payers to provide options to patients for opting out of data sharing that are accessible to patients with varied technological literacy (that is, via mail, fax, and phone). A commenter recommended that opt out information be available for the Provider Access API in multiple languages to reduce disparities and barriers to patients' understanding of the opt out process. Another commenter recommended that CMS establish clear expectations for how payers should accommodate patients who may have difficulty accessing the opt out process or that CMS should track the extent to which patients encounter difficulties with opting out of data sharing. A commenter further recommended that payers collect patients' opt out elections at the point of treatment, so that it is clear which provider(s) have access to the patient's data via the Provider Access API policy.

Response: We agree with commenters that payers should make efforts to ensure their patients or their personal representatives have the opportunity to opt out of data sharing under the Provider Access API policy and should be accommodated accordingly. These accommodations certainly include accounting for varied technology literacy and language barriers (see section II.B.3.c.ii. of this final rule for a discussion on plain language and existing requirements to make information accessible in other languages or formats). However, we do not want to be overly prescriptive to payers, as we believe they would know best how to accommodate their particular patient population. We disagree that payers should collect patient opt out elections at the point of treatment because we intend for these data to be available to the provider before patient appointments, and such practices are also outside the scope of a provider's role. We therefore intend to monitor patient experience and payer compliance with the opt out process and will consider our observations through this monitoring for future rulemaking.

Comment: Multiple commenters recommended implementing processes for payers to notify providers of patients' election to opt out of the Provider Access API data exchange. A commenter identified some potential implementation challenges for providers, including that tracking patient permission would be challenging and that the opt out approach could create segmented data captures and multiple workflows. Another commenter flagged that CMS should not rely on physicians to educate patients on the intricacies of APIs, instead encouraging CMS to provide standardized language and guidelines to payers around how the process to opt out will be communicated to patients and the process for collecting and communicating opt outs to physicians.

Response: While we are not requiring impacted payers to notify providers of their patients' election to opt out of the Provider Access API data exchange, we agree that notification can increase the utility of the Provider Access API for providers. We remind readers that we are not requiring providers to track patient data sharing permission, educate patients about their data sharing options, or utilize the Provider Access API at all. However, we believe that giving providers access to more patient data will benefit the care that they provide, and we encourage them to adjust their workflows and work with their EHR developers to take advantage of the data availability through this new mechanism.

Comment: A commenter noted that it will take time for payers to process opt out requests from patients or their personal representatives who choose to opt out of having their data shared after enrollment. Another commenter suggested that patients should be able to record their permission through multiple channels (for example, OAuth 2.0, portal access, and the FHIR consent profile). A commenter also stated that payers may have to design related processes to allow patients to opt in to sharing of sensitive information that adhere to state or local privacy laws. A commenter further sought guidance on whether specific consent language would be required for patients or their personal representatives to opt in and whether an opt in election may be included in the HIPAA authorization form or other enrollment materials.

Response: Payers will have flexibility in how they process patient data sharing permission and the channels that patients may use to make their election. We caution, however, that any such opt out channels should be both optimally accessible to patients or their personal representatives and not onerous for them to navigate. Part of managing an opt out process will include cognizance of other laws that may restrict data sharing, such as state privacy laws. In fact, if other applicable law requires an opt in permission for data sharing, payers may integrate both the Provider Access API opt out and other permission gathering processes to simplify patients' ability to control their data, to the extent permitted by law. Finally, regarding the commenter seeking specific consent language for opt in and clarification related to leveraging the HIPAA authorization form for this purpose, we emphasize that this final rule finalizes an opt out framework for the Provider Access API, not an opt in. We further note that compound HIPAA authorizations are generally prohibited, per 45 CFR 164.508(b)(3).

v. Opt Out Timeframes

Comment: Multiple commenters stated that patients or their personal representatives should be allowed to opt out at any time. Other commenters supported payers providing an option to opt out at a certain time, such as at the time of enrollment. A commenter recommended that CMS allow payers 30 days to process a patient's request to opt out and stop sharing the patient's data via the Provider Access API.

Response: We agree that patients or their personal representatives should be able to opt out of data sharing under the Provider Access API policy at any time and we are requiring impacted payers to give their patients the opportunity to do so. As discussed in section II.B.3.c. of this final rule, no later than one week after the start of coverage and annually, patients will need to be given information about their opt out rights and instructions both for opting out. We remind readers that “start of coverage” is defined differently, as applicable, for each type of impacted payer. We refer readers to section II.C.3.c.i. of this final rule for discussion of these differences. We do not agree that the opt out option should be time-limited, as that reduces patient control over their health data.

c. Patient Educational Resources Regarding the Provider Access API

To help patients understand the implications of the opt out provision for the Provider Access API, we proposed to require impacted payers to disseminate certain educational resources to their patients. We proposed that those resources would include information about the benefits to the patient of API data exchange, their opt out rights, and instructions both for opting out of the data exchange and for opting in after previously opting out. We proposed that payers would have to provide this information, in non-technical, simple, and easy-to-understand language, before the first date on which the payer makes patient information available through the Provider Access API, at the time of enrollment and annually thereafter. We also proposed that payers would be required to make this information available at all times, in an easily accessible location on payers' public websites. We did not propose to require this information to also be distributed to patients' personal representatives. However, we highly encourage impacted payers to do so, especially if distributing other materials to personal representatives is typical. We also did not propose specific text or format for this information, but requested suggestions and comments on whether required content or format would be beneficial or burdensome. In particular, we sought comments on language explaining how patient data that is shared through the Provider Access API could be used. We anticipated that payers would want to include this information in their regular communications, such as annual enrollment information, privacy notices, member handbooks, or newsletters. However, we requested comment on the most appropriate and effective communication channel(s) for conveying this information to patients. We also requested comment on whether a requirement to provide this information at the time of enrollment and annually is appropriate, or whether we should require payers to share this information more frequently.

We believe it is important to honor patient privacy preferences. Offering patients educational resources about their right to opt out of the Provider Access API data sharing is thus fundamental to empowering patients with respect to their data.

As discussed in more detail, we are finalizing a modification to these proposals, that impacted payers must provide this information to patients no later than one week after the start of coverage. “Start of coverage” is defined differently, as applicable, for each type of impacted payer and we refer readers to section II.C.3.c.i. of this final rule for discussion of these differences.

i. Dissemination

Comment: Multiple commenters supported the proposed requirement for payers to disseminate patient educational resources and made recommendations for communicating with, or sending information to patients. These recommendations include disseminating educational resources through existing patient portals, letters, text messages, and information posted on websites, in handbooks, and by mail.

Conversely, a commenter recommended that CMS not require physical materials be sent annually to patients. The commenter recommended that payers should only send hard copies to patients who have opted out of data sharing. However, another commenter stated that separate patient resources for the Provider Access API are not necessary at all. A commenter additionally stated that many plan renewals do not actually generate patient-visible paperwork, forms, or formal documents of any sort and provided examples for how frequently sharing patient resources currently occurs. A commenter further stated that payers should have the flexibility to communicate with their members in a manner consistent with a set format and content for consistency and clarity.

Response: We emphasize that impacted payers can indeed use their existing processes for producing patient-facing resources and will be permitted to send their patient education resources through the communication channels they think are most effective for reaching their patients, including emails, messages through a payer portal, or physical mail. It is not our intention to overburden payers, and thus we do want to be overly prescriptive in a way that that will unduly disrupt how they currently communicate with their patients. We disagree that only patients who have opted out of data sharing should receive these resources. Under our policies, patients may choose to change their data sharing permission at any time and we thus believe that they should remain maximally informed of their choices.

We are also finalizing a modification to the proposed rule regarding payer deadlines, to give payers more clarity and an appropriate amount of time to meet these requirements, as well as to align with policies we are finalizing for the Payer-to-Payer API (see section II.C.3.c.i. of this final rule). Specifically, payers will be required to provide patients, no later than one week after the start of coverage, information about the benefits of API data exchange with their providers, their opt out rights, and instructions for both for opting out of data exchange and for opting in after previously opting out. This timeframe is intended to provide a reasonable amount of time after a payer receives confirmation that a patient will be enrolled in coverage with them. As further discussed in section II.C.3.c.i., to ensure feasible timeframes, we are finalizing deadlines to account for situations when coverage starts prospectively or retroactively for MA plans and QHPs issuers on the FFEs and retroactively for Medicaid and CHIP.

Comment: Multiple commenters supported our proposal to require impacted payers to provide patient education resources at enrollment and annually thereafter. A commenter stated that educational resources could also come from providers at patient interactions. Other commenters expressed that CMS's requirements should not add burden to providers or interfere with their clinical workflow. A commenter recommended that CMS not require Medicaid agencies to provide information on the Provider Access API opt out policy more frequently than at member enrollment and annually. The commenter stated that it would be resource intensive and would require new workstreams and member outreach processes.

Response: We thank commenters for their support of our proposal to require impacted payers to provide patient education resources at enrollment and annually thereafter (though we are finalizing a modification to this proposal, as explained above). We did not propose to require any role for providers, as we agree this would increase their administrative burden. We also agree with commenters that providing these resources more frequently would indeed increase burden, which is why we did not propose for impacted payers to do so.

ii. Content

Comment: Multiple commenters suggested that CMS require payers to use clear and plain language and ensure the opt out policy is prominent.

Response: We agree with commenters' sentiments and thus proposed that patients should be able to easily understand the patient education resources. In response to both these comments and comments on our opt out proposals, as well as for consistency with other policies, we are finalizing this rule slightly differently from how it was proposed. We had proposed that impacted payers provide patient education resources in “non-technical, simple, and in easy-to-understand language,” but our finalized requirement is that they use “plain language.” This change is not intended to alter that the educational information be non-technical, simple, and easy-to-use, but to make clear that we encourage impacted payers to follow the Federal Government's plain language guidelines. Those guidelines were informed by the Plain Writing Act of 2010, which requires Federal agencies to use clear government communication that the public can understand and use. That statute only applies to Federal Government agencies, but the plain writing guidance that has been developed for the Federal Government will be useful for impacted payers when developing educational resources for patients. We note that providing these patient educational resources is a separate requirement from the requirement to create an NPP under the HIPAA Privacy Rule.

Comment: A commenter expressed concern about language access, while another recommended CMS set inclusivity requirements, based on a payer's patient population, for translating into languages other than English. Multiple commenters recommended that notices about the Provider Access API be focus group tested, written in accurate but positive language (so as not to unduly discourage participation), and translated into the required threshold languages for the coverage area.

Response: Impacted payers may already be required to provide plain language resources in languages other than English, per 45 CFR part 92, which requires impacted payers (as health programs or activities under that section) to provide meaningful access to individuals with limited English proficiency and accessibility requirements for individuals with disabilities. The requirements of that part apply to impacted payers, as described at 45 CFR 92.3.

Additionally, this rule does not affect standards already in place for specific payers on state or Federal levels. For example, 45 CFR 156.250 requires QHP issuers on the FFEs to provide information in accordance with the accessibility standards for individuals with disabilities and individuals with limited English language proficiency at 45 CFR 155.205(c). Other impacted payers might have their own standards for accessible patient-facing resources, as well, that would not be affected by this final rule.

Comment: Multiple commenters recommended, for ease of readability, that resources or notices be written at a certain grade level. Multiple commenters recommended that CMS amend the patient resources proposal to require impacted payers to write resources at a fourth-to-sixth grade reading level.

Response: While we agree that these resources need to be understandable, we do not believe that it is prudent to establish a specific “grade level” requirement. A grade level score is based on the average length of the words and sentences. Readability formulae vary and the grade level scores for the same text can differ depending on how it is used. Furthermore, edits that are made to make text score at a lower grade level can produce choppy text that lacks cohesion.

Comment: A commenter did not support the development of patient education resources that may be duplicative or confusing to patients, while another did not support the proposal for separate patient outreach and education if the data sharing under the Provider Access API is permitted under the HIPAA Privacy Rule's TPO exception.

Response: We refer readers to section II.B.3.b.ii. of this final rule for a full discussion of the HIPAA Privacy Rule's applicability and why we are requiring an opt out policy for the Provider Access API. We believe that plain language educational resources will inform rather than confuse patients. We encourage payers to explain to patients that not opting out of data sharing would not limit or negatively affect their rights under the HIPAA Privacy Rule. Rather, it is an opportunity for them to control where their data are shared under the policies of this final rule. Where the requirements of this rule change how covered entities or their business associates may use or disclose PHI, covered entities should also consider their obligations under the HIPAA Privacy Rule.

Comment: Commenters recommended that CMS require additional details from payers about their opt out process for the Provider Access API. A commenter stated patients should receive detailed communications that include the potential benefits and harms of sharing versus not sharing this information, including the potential impact on quality and timeliness of care. Commenters further recommended that resources include information on privacy and security, moving data to a third-party app, and guidelines for patient-provider dialogue on consent.

Response: As explained, we did not want to be overly prescriptive for the specific language used for the patient resources, but we did propose that they include patient instructions for opting out of data sharing and controlling their permission. We specifically proposed that the patient education resources include information about the benefits of API data exchange. In addition, impacted payers may, if they choose, include reasonable and objective information about any risks to data sharing. However, the purpose of the information in the educational resources, regardless of the particular content, should be to inform patients. We believe that patients educated with accurate information will realize the benefits of data sharing via the Provider Access API and most will not opt out.

We agree that plain language resources should include information about privacy and security, in order to give patients an informed view of how the Provider Access API works. It is also reasonable and acceptable for payers to bundle or combine the educational resources about the Provider Access API with the educational resources about the Patient Access and Payer-to-Payer APIs, discussed in sections II.A. and II.C. of this final rule, to give patients a holistic view of how our interoperability policies work together to improve data exchange.

Comment: Commenters recommended that CMS partner with ONC to develop templates and content for these educational resources, which impacted payers could use to meet this requirement. Many commenters recommended that CMS work with the health care community and patient advocates to develop language on the benefits and risks of data exchange. Commenters also recommended that CMS work with industry to develop and disseminate educational resources by creating a web page dedicated to interested party-specific newsletter inserts, holding CMS open door virtual forums, and using other methods to communicate regulatory and implementation updates.

Response: We intend to continue working with Federal and industry partners to increase patient engagement in a way that both protects their autonomy and enables the sharing of the data to improve their health care. Based on feedback, we intend to develop additional outlines or templates for patient education resources.

d. Provider Resources Regarding the Provider Access API

We proposed to require impacted payers to develop non-technical and easy-to-understand resources for providers about the Provider Access API. We proposed that those resources would have to include information about the process for requesting patient data from payers via the Provider Access API and how to use the payer's attribution process to associate patients with the provider. We proposed that impacted payers provide these resources to providers through the payer's website and other appropriate provider communications, such as annual contract updates or handbooks. Non-technical resources will help providers understand how they can use the API to access patient data, thus realizing the expected benefit of the proposed API. We requested comment on this proposal, including whether CMS should develop guidance regarding, or address in future rulemaking, the specific content of these educational resources about the Provider Access API.

As discussed in more detail, we are finalizing this proposal, with a modification that provider resources be in plain language.

i. Dissemination

Comment: Multiple commenters expressed support for requiring impacted payers to make these resources easily available on a payers' website, in contracts, and in provider handbooks. However, other commenters sought clarification on what “other appropriate provider communications” are and whether existing provider communication channels can be used to provide these resources. A commenter stated that it is unreasonable to expect providers and their staff to access each payers' website to obtain the payers' specific resources and they do not believe this will happen in a reliable manner. Other commenters stated that the resources should be incorporated into a clinical workflow or EHRs.

Response: While the provider resources must be available on the payer's website, we are also requiring impacted payers to send those resources directly to providers through other appropriate channels. We encourage payers to use existing methods of communication by which providers expect to receive information from payers. We use the term “other appropriate provider communications” to provide payers with flexibility, but that term includes existing communication channels. For example, 42 CFR 422.202 requires MA organizations to provide to participating physicians written notice of rules of participation, including terms of payment, credentialing, and other rules directly related to participation decisions. The Provider Access API resources can be disseminated along with such resources. While payers are welcome to use the Provider Access API to make those resources available, they would have to develop an operable solution. Furthermore, if a provider needs guidance to access the Provider Access API, requiring a connection and query would not be useful.

ii. Content

Comment: Multiple commenters supported the proposal for impacted payers to disseminate provider-facing resources, particularly with instructions for attributing patients to a provider.

Response: We appreciate commenters support for this requirement. As finalized, payers will be required to include information about the payer's process to attribute patients to a particular provider. We also highly recommend that payers include contact information for provider assistance. To be consistent with our revision to the patient education resources policy, but also being clear that we have not altered the intent, we are finalizing regulatory text slightly different than what we had proposed, to require provider education resources in “plain language,” as opposed to our proposed “non-technical, simple, and in easy-to-understand language.”

Comment: Multiple commenters recommended more technical education resources than we proposed because of the technical nature of API data exchange. A commenter suggested that the resources include information about the IGs, links to the payer's technical documentation and contact information for assistance with the Provider Access API. Another commenter warned that the educational resources need to be better defined, because they believe that the information we describe will be more appropriate for EHR vendors than providers. In fact, another commenter stated that it may be more appropriate for EHR and practice management system vendors to provide education resources that offer greater specificity about how data are integrated into provider data systems and workflows.

Response: While payers will have to include instructions for accessing patient data, we disagree with the recommendation that payers include more technical documentation. We do not believe that most providers will be interested in the specific implementation details of the API, but will rely on their technology vendor. We remind payers that, per the final requirements in the CMS Interoperability and Patient Access final rule, they are required to make technical information about their Patient Access APIs available by posting directly on their website. We are finalizing this requirement by reference for the Provider Access, Payer-to-Payer, and Prior Authorization APIs, as well. References or links to that material would be entirely appropriate to include in the required provider resources. EHR and practice management vendors also have a role to play in educating providers about the functionality of their particular system. However, only payers will be able to offer provider specific details about their Provider Access API and the process for attributing patients.

Comment: Commenters suggested that CMS require using language regarding limitations related to disclosures of sensitive conditions that are subject to 42 CFR part 2 and disclosures to minors.

Response: Though we are not requiring it to be included in the provider resources, payers should adequately inform providers of what data are and are not available through the Provider Access API. Providers should be aware of what they can expect to receive in response to a request, whether that is because of the data content requirements, payer maintenance policies, or privacy limitations.

Comment: Multiple commenters requested that CMS develop educational resources that impacted payers could disseminate to their providers to ensure consistency and that providers are aware of any reporting protocols for payer non-compliance. A commenter added that these requirements and related guidance should be posted on CMS provider web pages and print publications. Multiple commenters recommended that CMS consult with Federal partners at ONC, the Health Resources and Services Administration (HRSA) and the Agency for Healthcare Research and Quality (AHRQ), and the provider community in order to understand their educational needs and how best to promote the resources. A commenter recommended that CMS provide additional guidance on the education and training efforts to provider specialties who are lagging the industry in interoperable technology adoption.

Response: Based on comments we received, we intend to provide general guidelines to impacted payers about what this final rule requires to be disseminated to providers, which may include information on potential best practices. However, unlike the patient-facing educational resources described previously, we expect that provider resources could vary significantly between payers. Payers will have different processes to allow providers to request data via the Provider Access API and policies for patient attribution to explain to their providers. Therefore, there is less benefit to standardized templates or content for these resources. We provided links to resources for APIs to support payers implementing provisions of the CMS Interoperability and Patient Access final rule (85 FR 25510) and we intend to identify similar resources for health care providers for this final rule. We will continue to work with our partners to ensure providers can access patient data, regardless of the technology they use. Requiring an API that can be accessed with systems other than CEHRT is a step toward that goal, and payer-developed resources should address all the ways providers could interact with the Provider Access API.

4. Extensions, Exemptions, and Exceptions

See section II.E. of this final rule for a discussion of extensions and exemptions and the final policies for the Provider Access API for state Medicaid and CHIP FFS programs and exceptions for the Provider Access API for QHP issuers on the FFEs (this was also addressed in the proposed rule at 86 FR 76279).

5. Final Action

After considering the comments received, and for the reasons discussed in the CMS Interoperability and Prior Authorization proposed rule and our response to those comments (as summarized previously), we are finalizing our proposal with the following modifications:

• Impacted payers must implement and maintain a Provider Access API beginning 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs) rather than in 2026.
• Impacted payers are not required to use OpenID Connect Core at 45 CFR 170.215(e)(1) for the Provider Access API.
• Impacted payers are not required to share the quantity of items or services used under a prior authorization via the Provider Access API.
• Impacted payers are not required to share unstructured documentation related to prior authorizations via the Provider Access API.
• Impacted payers are required to provide educational resources to patients no later than one week after the start of coverage, as that term is defined for each type of impacted payer, rather than at enrollment.
• The educational resources that impacted payers are required to provide to patients and providers are described as “plain language” rather than in “non-technical, simple, and in easy-to-understand language.”

See further discussion later for exact details of the final requirements for impacted payers.

We are finalizing that beginning 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS Programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs), impacted payers must implement and maintain a Provider Access API that is conformant with certain technical standards, documentation requirements, and denial or discontinuation policies. Specifically, those technical standards are HL7 FHIR at 45 CFR 170.215(a)(1), US Core IG at 45 CFR 170.215(b)(1)(i), SMART App Launch IG at 45 CFR 170.215(c)(1), and Bulk Data Access IG at 45 CFR 170.215(d)(1).

We are finalizing that, by the deadlines, impacted payers must make available upon request from an in-network provider, via the Provider Access API, claims and encounter data (excluding provider remittances and patient cost-sharing information), all data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI), and certain information about prior authorizations (excluding those for drugs) that the payer maintains no later than 1 business day after receiving a request from such a provider, if all the following conditions are met:

• The payer authenticates the identity of the provider that requests access and attributes the patient to the provider under the required attribution process;
• The patient does not opt out of the Provider Access API; and
• Disclosure of the data is not prohibited by law.

The required prior authorization information is:

• The prior authorization status;
• The date the prior authorization was approved or denied;
• The date or circumstance under which the prior authorization ends;
• The items and services approved;
• If denied, a specific reason why the request was denied; and
• Related structured administrative and clinical documentation submitted by a provider.

We are finalizing that impacted payers are required to make this information about prior authorizations available no later than 1 business day after the payer receives a prior authorization request and must update that information no later than 1 business day after any status change. This information must be available for the duration that the authorization is active and at least 1 year after the prior authorization's last status change.

We are finalizing that impacted payers must establish and maintain an attribution process to associate patients with their in-network or enrolled providers to enable payer to provider data exchange via the Provider Access API.

We are finalizing that, by the deadlines, impacted payers must establish and maintain a process for patients to opt out of data exchange via the Provider Access API and to change their permission at any time. We are finalizing that this process must be made available before the first date on which the payer makes patient information available via the Provider Access API, and at any time while the patient is enrolled with the payer.

We are finalizing that, by the deadlines, impacted payers provide educational resources in plain language to their patients about the Provider Access API. Those resources must include information about the benefits of API data exchange with providers, patients' opt out rights, and instructions for both opting out of data exchange and for subsequently opting in. Impacted payers must make this information available to patients before the first date on which the payer makes their information available via the Provider Access API, no later than one week after the start of coverage, and at least annually. These resources must also be available in an easily accessible location on payers' public websites. We remind readers that “start of coverage” is defined differently, as applicable, for each type of impacted payer. We refer readers to section II.C.3.c.i. for discussion of these differences.

We are finalizing that, by the deadlines, impacted payers must provide on their website and through other appropriate provider communications, information in plain language explaining the process for requesting patient data using the Provider Access API. The resources must include information about how to use the payers' attribution process to associate patients with their providers.

These policies apply to MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans and CHIP managed care entities (excluding NEMT PAHPs), and QHP issuers on the FFEs at the CFR sections listed in Table C1.

6. Statutory Authorities for Provider Access API

We received no public comments on the statutory authorities for our Provider Access API policies.

a. Medicare Advantage Organizations

For MA organizations, we are finalizing these Provider Access API requirements under our authority at sections 1856(b)(1) of the Act to promulgate regulations that adopt standards to implement provisions in Part C of Title XVIII of the Act (such as section 1852(d)(1)(A)) of the Act to adopt new terms and conditions for MA organizations that the Secretary finds “necessary and appropriate.” Section 1852(d)(1)(A) of the Act requires MA organizations to, as a condition of using a network of providers, make covered benefits available and accessible to enrollees in a manner that assures continuity in the provision of benefits. As noted in this section of this final rule, these regulations implement this requirement by requiring implementation of an API that will make available data to improve the provision of benefits. The Secretary also has authority under section 1857(e)(1) of the Act to add new contract terms, including additional standards and requirements, for MA organizations the Secretary finds necessary and appropriate and that are not inconsistent with Part C of the Medicare statute.

In implementing section 1852(d)(1)(A) of the Act, we previously adopted a regulation, at 42 CFR 422.112(b), that requires MA organizations to ensure the continuity of care and integration of services through arrangements with providers that include procedures to ensure that the MA organization and the contracted providers have access to the information necessary for effective and continuous patient care. Our policy for MA organizations to implement and maintain a Provider Access API will facilitate exchanges of information about enrollees that are necessary for effective and continuous patient care, which is consistent with the requirement at section 1852(d)(1)(A) of the Act for continuing the provision of benefits. The Provider Access API policy, which will support sharing claims, all data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI), as well as certain information about prior authorizations (sections II.B.2. and II.B.3. of this final rule) and a requirement for MA organizations to offer provider educational resources (section II.B.3.d. of this final rule), will give providers tools to support continuity of care and care coordination for enrollees. Were a provider able, through a Provider Access API established by an MA organization, to gather information for their patient, the provider potentially could make more informed decisions and coordinate care more effectively. In addition, if a patient moves from one provider to another, the new provider will be able to ensure continuity of care if they are able to access relevant health information for the patient from the MA organization in an efficient and timely way. A Provider Access API could support this; thus, the policy will carry out and be consistent with the Part C statute.

This policy will complement and align with MA organization obligations at 42 CFR 422.112(b)(4) by providing a means, through a Provider Access API, for the exchange of information that supports effective and continuous patient care. A Provider Access API may increase the efficiency and simplicity of administration. It will give providers access to a significant amount of their patients' information with limited effort, and it could reduce the amount of time needed during provider visits to establish a patient's prior history, which could introduce efficiencies and improve care. These policies are also expected to allow for better access to other providers' prior authorization decisions, which could give a provider a more holistic view of a patient's care and reduce the likelihood of ordering duplicate or misaligned services. Ultimately, we anticipate that sharing patient information will ensure that providers receive patient information in a timely manner and could lead to more appropriate service utilization and higher patient satisfaction. In addition, the policy that MA organizations make available educational resources and information will increase access to and understanding of this Provider Access API, leading to more efficient use and integration of the API as a means for providers to access patient information. Thus, the Provider Access API will be necessary and appropriate for the MA program and consistent with existing requirements.

b. Medicaid and CHIP

Our finalized requirements in this section for Medicaid FFS and Medicaid managed care plans fall generally under the authority in the following provisions of the statute:

• Section 1902(a)(4) of the Act, which requires that a state Medicaid plan provide such methods of administration as are found by the Secretary to be necessary for the proper and efficient operation of the state Medicaid plan;
• Section 1902(a)(8) of the Act, which requires states to ensure that Medicaid services are furnished with reasonable promptness to all eligible individuals; and
• Section 1902(a)(19) of the Act, which requires states to ensure that care and services are provided in a manner consistent with simplicity of administration and the best interests of the recipients.

The final Provider Access API policies are authorized under these provisions of the Act because they will ensure that states are able to ensure that Medicaid providers can access data that could improve their ability to render Medicaid services effectively, efficiently, and appropriately. The policies are expected to help states fulfill their obligations to operate their state plans efficiently and to ensure that Medicaid services are furnished with reasonable promptness and in a manner consistent with the best interest of the recipients.

In addition, section 1902(a)(7) of the Act requires that states must provide safeguards that restrict the use or disclosure of information concerning Medicaid applicants and beneficiaries to purposes that are directly connected with the administration of the Medicaid state plan. The implementing regulations at 42 CFR part 431, subpart F, for section 1902(a)(7) of the Act list purposes that CMS has determined are directly connected with administration of Medicaid state plans (42 CFR 431.302) and require states to provide safeguards meeting certain requirements to restrict uses and disclosures of Medicaid beneficiary data, including requirements for sharing applicant and beneficiary data at 42 CFR 431.306.

Our finalized policy, that the data described in this section of the final rule be shared via the Provider Access API, is consistent with the requirement at section 1902(a)(7) of the Act, providing that states may share these data only for purposes directly connected with the administration of the Medicaid state plan. The Provider Access API data sharing policy is related to providing services for Medicaid beneficiaries, a purpose listed at 42 CFR 431.302(c). As mentioned previously, a provider can better manage a patient's total care when they have access to more of that patient's data because the data will provide a more in-depth medical history, enable more informed decision making, and potentially prevent the provision or ordering of duplicative services. More details about how the policies will be implemented in a manner consistent with state Medicaid requirements under 42 CFR part 431, subpart F, are discussed in section II.B.2. of this final rule.

Requiring states to implement a Provider Access API to share data with enrolled Medicaid providers about certain claims, encounter, and clinical data, including data about prior authorization decisions, for a specific individual beneficiary, may improve states' ability to ensure that care and services are provided in a manner consistent with simplicity of administration, and to cover services more efficiently. We remind states that “enrolled Medicaid providers” includes managed care plan providers, per 42 CFR 438.602(b). This Provider Access API will enable Medicaid providers to access beneficiary utilization and authorization information from the state or managed care plan(s) prior to an appointment or at the time of care, and that, in turn, should enable the provider to spend more time on direct care. The policy will support efficient and prompt delivery of care as well, which will be in beneficiaries' best interests. These policies are also expected to give providers better access to prior authorization decisions for care provided by other enrolled Medicaid providers, which will give a provider a more holistic view of a patient's care and reduce the likelihood of ordering duplicate or misaligned services. This may also facilitate easier and more informed decision-making by the provider and should therefore support efficient coverage decisions in the best interest of patients. The Provider Access API is expected to make available a more complete picture of the patient to the provider at the point of care, which could improve the quality and efficiency of a patient visit. These outcome and process efficiencies may help states fulfill their obligations to ensure prompt access to services in a manner consistent with the best interest of beneficiaries, consistent with sections 1902(a)(8) and (19) of the Act, and the efficiencies created for providers might help the state administer its Medicaid program more efficiently, consistent with section 1902(a)(4) of the Act. These analyses apply similarly to FFS and managed care programs and delivery systems, so we are exercising our authority to adopt virtually identical regulatory requirements for a Provider Access API for both Medicaid FFS programs and Medicaid managed care plans.

For CHIP, we finalized these requirements under the authority in section 2101(a) of the Act, which states that the purpose of Title XXI of the Act is to provide funds to states to provide child health assistance to uninsured, low-income children in an effective and efficient manner that is coordinated with other sources of health benefits coverage. We believe this policy will strengthen states' abilities to fulfill these statutory obligations in a way that will recognize and accommodate using electronic information exchange in the health care industry today and will facilitate a significant improvement in the delivery of quality health care to CHIP beneficiaries.

When providers have access to patient utilization and authorization information from payers or other health IT systems, they may be able to provide higher quality care. Improving the quality of care aligns with section 2101(a) of the Act, which requires states to provide CHIP services in an effective and efficient manner. The more information a provider has to make informed decisions about a patient's care, the more likely it is that patients will receive care that best meets their needs. Additionally, providers can be more effective and efficient in their delivery of CHIP services by having direct access to patient utilization and authorization information. If a provider has information about a patient prior to or at the point of care, the provider will be able to spend more time focused on the patient, rather than on their need to collect information. In addition, the information providers do collect will not be based solely on patient recall. This will save time, improve the quality of care, and increase the total amount of direct care provided to CHIP beneficiaries. When data are standardized, and able to be incorporated directly into the provider's EHR or practice management system, they can be leveraged as needed at the point of care by the provider and also can be used to support coordination across providers and payers. This is inherently more efficient, and, ultimately, more cost-effective, as the information does not have to be regularly repackaged and reformatted to be shared or used in a valuable way. As such, the Provider Access API policies also align with section 2101(a) of the Act in that these proposals will improve coordination between CHIP and other health coverage. For these reasons, we believe this policy is in the best interest of the beneficiaries and within our long-established statutory authorities.

Finally, the safeguards for applicant and beneficiary information at 42 CFR part 431, subpart F, are also applicable to CHIP through a cross-reference at 42 CFR 457.1110(b). More details about how the policies could be implemented in a manner consistent with these CHIP agencies' requirements are also discussed in section II.B.2. of this final rule. As discussed previously for Medicaid, giving CHIP providers access to attributed beneficiary data through the Provider Access API is related to providing services to beneficiaries, which is described at 42 CFR 431.302(c) as a purpose directly related to state plan administration. We remind states that when they share beneficiary information through the Provider Access API, they must comply with the privacy protections at 42 CFR 457.1110 and the release of information provisions at 42 CFR 431.306.

c. Qualified Health Plan Issuers on the Federally-Facilitated Exchanges

For QHP issuers on the FFEs, we are finalizing these new requirements under our authority in section 1311(e)(1)(B) of the Affordable Care Act, which affords the Exchanges the discretion to certify QHPs if an Exchange determines that making available such health plans through that Exchange is in the interests of qualified individuals in the state in which the Exchange operates. We believe the benefits will outweigh any additional burdens this might impose on issuers. By using the finalized technologies, patients could experience improved health, payers could see reduced costs of care, and providers could see better compliance with care regimens. We also do not believe that premiums will significantly increase because some of the infrastructure necessary to implement the technology has been completed to comply with the CMS Interoperability and Patient Access final rule. Furthermore, QHP issuers on the FFEs might combine investments and staff resources from other programs for implementation efforts, avoiding the need to increase premiums.

We believe that certifying only health plans that make enrollees' health information available to their providers via the Provider Access API is generally in the interests of enrollees. Giving providers access to their patients' information supplied by QHP issuers on the FFEs will ensure that providers are better positioned to provide enrollees with seamless and coordinated care and ensure that QHP enrollees on the FFEs are not subject to duplicate testing and procedures, and delays in care and diagnosis. Access to the patient's more complete medical information could also maximize the efficiency of an enrollee's office visits. We encourage SBEs, including SBE–FPs, to consider whether a similar requirement should be applicable to QHP issuers participating in their Exchanges.

C. Payer-to-Payer API

1. Background

Having a patient's data follow them when they change payers can have a multitude of benefits for patient care. A payer receiving data when a new patient enrolls can better coordinate care and make more informed decisions. For instance, a payer can use the patient's data to determine whether they have a chronic condition or is undergoing current care that needs to be maintained. If necessary, patient data can give payers the information they need to assign a case manager or help the patient find providers in their new network. Maintaining a corpus of data ensures that the patient and their providers do not lose access to recent information that may be relevant to ongoing or future care.

Furthermore, because payers usually maintain a relationship with individual patients over time, they are uniquely positioned to collect and aggregate a patient's record. Whereas patients may have several providers who manage their care, they generally maintain a relationship with only one or two concurrent payers for a full year or multiple years. However, when a patient moves from one payer to another, both parties may lose access to that valuable data. Data exchange among payers, specifically, sending patient data from a patient's previous payer to their new one, is a powerful way to ensure that data follow patients through the health care system and improve care continuity. Electronic data exchange between payers will support payer operations and a patient's coverage transition to a new payer efficiently and accurately. Sharing health care data between payers also helps care coordination, care continuity, and allows patients to maintain access to their record over time.

In the CMS Interoperability and Patient Access final rule (85 FR 25565), we highlighted numerous benefits of payers maintaining a longitudinal (meaning, long-term) record of their current patients' health information. If payers are at the center of the exchange, they can make information available to patients and their providers and can help a patient's information follow them as they move from provider to provider and payer to payer.

In the CMS Interoperability and Prior Authorization proposed rule, we proposed and, in this rule are now finalizing regulations that require impacted payers (MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs) to implement and maintain a FHIR API to facilitate payer to payer data exchange. We are finalizing that proposal to require impacted payers to build a Payer-to-Payer API, with certain standards (as further described in section II.F.), that will facilitate patient data exchange at the start of coverage and with concurrent payers. We proposed, and are finalizing, a patient opt in policy for this data exchange. We proposed compliance dates in 2026 for the Payer-to-Payer API (by January 1, 2026, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2026, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2026, for QHP issuers on the FFEs). However, in response to comments we are finalizing a modification to that proposal for the Payer-to-Payer API to establish compliance dates in 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs). Throughout this rule, we generally refer to these compliance dates as “in 2027” for the various payers. In addition, and also in response to comments, we are finalizing a modification to our proposal to only require impacted payers to exchange data with a date of service within 5 years of the exchange request.

To support the implementation and maintenance of the Payer-to-Payer API, we are requiring certain standards and recommending certain IGs, as further discussed and in section II.G. With the publication of the HTI–1 final rule, our cross references to 45 CFR 170.215 have been updated to reflect the updated citations as needed. Changes to the structure of 45 CFR 170.215 and versions of the API standards codified there are discussed further in section II.G. and reflected throughout this final rule. For the Payer-to-Payer API, impacted payers must use the following standards: HL7 FHIR Release 4.0.1 at 45 CFR 170.215(a)(1), US Core IG STU 3.1.1 at 45 CFR 170.215(b)(1)(i), and Bulk Data Access IG v1.0.0: STU 1 at 45 CFR 170.215(d)(1). Impacted payers are permitted to use updated standards, specifications, or IGs that are not yet adopted in regulation for the APIs required in this final rule, should certain conditions be met. For the standards at 45 CFR 170.215, updated versions available for use under our policy include, but are not limited to, US Core IG STU 6.1.0 and the Bulk Data Access IG v2.0.0: STU 2, which have been approved for the ONC Health IT Certification Program. We refer readers to policies finalized for the Patient Access API in the Interoperability and Patient Access final rule, as well as section II.G.2.c. of this final rule for a full discussion on using updated standards. We also recommend payers use the CARIN IG for Blue Button STU 2.0.0, PDex IG STU 2.0.0, and SMART App Launch IG Release 2.0.0 to support Backend Services Authorization. We refer readers to Table H3 for a full list of the required standards and recommended IGs to support API implementation.

In this section, we talk about data exchange between payers. When we refer to a patient's new payer, we mean the payer that a patient is newly enrolled with and the party responsible for requesting and receiving the patient's data. When we refer to the patient's concurrent payers, we signify the parties (two or more) that are providing coverage at the same time and are responsible for exchanging data with each other as discussed further in section II.C.3.c. When we refer to the patient's previous payer, we denote the payer that a patient has previously had coverage with and thus the payer responsible for sending the data to the new payer.

Our payer to payer data exchange requirements discussed in this section involve transactions and cooperation between payers, which may include payers that are not subject to the requirements in this rule. We emphasize that each impacted payer is responsible only for its own side of the transaction. For instance, when an impacted payer is required to request patient data from another payer, it will have to do so regardless of whether the other payer is an impacted payer (a status that may or may not be evident to the requesting payer). Similarly, if an impacted payer receives a request for patient data that meets all the requirements, the impacted payer must share those data, regardless of whether the requesting payer is an impacted payer (which, again, may or may not be evident to the payer sharing the data). In this way, payers not subject to this regulation that implement a Payer-to-Payer API (or other IT functionality to request or receive information through the impacted payer's API) and their patients can also benefit from the data exchange.

We are exploring steps for Medicare FFS to participate in payer to payer data exchange and we encourage other payers that are not subject to these requirements to do the same. We intend to implement the Payer-to-Payer API capabilities for Medicare FFS in conformance with the requirements for impacted payers, as feasible. In the proposed rule, we sought comment on whether our proposals could be implemented as proposed for the Medicare FFS program, how we could apply each of the proposals, and whether there would be any differences for implementing the Payer-to-Payer API in the Medicare FFS program as a Federal payer. We summarize the comments received and our responses in section I.D. of this final rule. We strongly encourage all payers that are not subject to the requirements of this rule to consider the value of implementing a Payer-to-Payer API, so that all patients, providers, and payers in the U.S. health care system may experience the benefits of such data exchange.

Comment: Many commenters supported our proposal to require data exchange via a Payer-to-Payer API. Commenters stressed the benefits to patients of maintaining an ongoing record when they change payers, which could result in better patient outcomes, especially for patients with chronic conditions. Commenters agreed that this API would improve interoperability, data exchange, and reduce administrative burden. Multiple commenters stated that the Payer-to-Payer API would be especially helpful to patients with concurrent coverage. A commenter stated that the assignment of primary care physicians could also be facilitated by the Payer-to-Payer API and that this could reduce care disruptions when changing payers. Another commenter acknowledged that investments made in payer to payer data exchange would benefit broader multi-payer alignment efforts, which are a key priority for improving quality, access, and value in health care. Another commenter stated that exchanging patient data from previous and concurrent payers would eliminate duplicative medical record requests from payers requiring providers to reapprove medical necessity, retry step therapy requirements, and reauthorize treatments.

Response: We appreciate commenters validating our statements in the proposed rule regarding the benefits of payer to payer data exchange. We agree that the benefits of payer to payer data exchange include both ensuring care continuity and that patients, providers, and future payers do not lose access to important health information. We are finalizing, with modification, the Payer-to-Payer API proposals as discussed in this section.

Comment: Multiple commenters opposed finalizing our Payer-to-Payer API proposals. They disagreed with our justification that payers should be the maintainers of a patient's longitudinal data. Another commenter cautioned that, as proposed, the Payer-to-Payer API would require payers to share a large amount of unnecessary data, which would make it difficult to effectively coordinate care. Instead, they suggested that by leveraging the Patient Access API, patients should have the responsibility to maintain their patient data using an app, or other solution of their choice. A commenter recommended that CMS separate the goal of creating longitudinal consumer health records from the goal of supporting consumer transitions between payers.

Response: After reviewing comments, we agree that patients are in the best position to manage their health information, especially with the growing ecosystem of health apps and the availability of standardized Patient Access APIs. Some HIEs and health apps (which may also be TEFCA Participants and Subparticipants) may be able to gather data from payers, providers, and other sources to create a more comprehensive patient record than could be maintained by a payer. However, payers are uniquely positioned to collect and aggregate patient data, especially during coverage transitions. As we noted, patients may have several providers who manage their care, but they generally maintain a relationship with only one or two concurrent payers for a full year or multiple years. A payer to payer data exchange can facilitate care continuity by providing access to information about past treatments when a patient is moving from one payer to another. For example, that information could show payers that a patient has already demonstrated medical necessity or engaged in step therapy, which could ease the approval of a prior authorization request. Ensuring that payers have timely access to newly enrolled patients' data upon a patient transitioning payers can have a multitude of benefits for patient care leading to better-coordinated care, more informed decision-making, and minimize disruption in ongoing care. Therefore, to mitigate potential burden on impacted payers, while still establishing the Payer-to-Payer API as a means to support the creation and availability of a longitudinal record, as discussed, we are finalizing a modification to our proposal to only require payers to exchange data with a date of service within 5 years of the request. That modification means that payers will not be responsible for exchanging and maintaining a patient's entire health history dating to January 1, 2016.

Comment: Multiple commenters did not support the proposed Payer-to-Payer API and suggested alternatives to gain the intended benefits. A commenter noted that there are many industry solutions already being developed to facilitate the coordination of benefits between payers and recommended CMS continue to monitor and enable technical innovation in this area. Another commenter cautioned CMS to not view FHIR as the sole solution to interoperability and patient data exchange challenges. The commenter noted that as proposed, payers would experience challenges if FHIR failed to reach widespread adoption and maturity. Another commenter stated that requiring the FHIR standard eliminates choice and leads to bias and further stated that other options may be better suited for a payer.

Response: We thank the commenters for their suggestions, but FHIR APIs are the standard that the industry indicated has the greatest maturity and hence has been adopted by ONC. A variety of solutions will not lead to interoperability across the healthcare system. While payers already have processes in place for coordinating benefits, that coordination does not extend to transitions of care between payers, such as maintaining prior authorizations. Data exchange between payers can ensure that valuable patient information is not lost, such as prior authorization requests and approvals, which could make that transition more seamless. Requiring FHIR will get the healthcare industry to a more interoperable state, as that standard supports health data exchange in a standard, structured, but flexible format that can continue to advance and mature. Impacted payers are already required to use the FHIR standard for the Patient Access and Provider Directory APIs, and this final rule is meant to build on this existing policy. Also, we are extending the compliance dates for the Payer-to-Payer API to 2027. This delay to the compliance dates versus our proposal allows for additional time for implementation and IGs to be refined and matured to support the policies in this final rule.

Comment: Multiple commenters expressed concern regarding payer access to patient data. They worried that this could lead to patient risk profiling, increased prior authorization requirements, increased premiums and limits on coverage and access to care. They recommended that CMS prohibit impacted payers from using information sent from a previous payer to discriminate against a patient. A commenter stated that CMS should implement safeguards to ensure that the payer to payer data exchange does not encourage payers to make care decisions based on the patient's record. The commenter recommended that CMS explain that the provider is the director of medical care, and payers support the patient's care through payment and coverage of services. They suggested that large-scale consumer data exchange should be consumer-mediated and result in meaningful access to comprehensive data for care coordination among payers.

Response: We agree with the commenters that patient information should not be used in an inappropriate manner. We remind payers that section 1852(b) of the Act states that an MA plan may not deny, limit, or condition the coverage or provision of benefits based on any health status-related factor described in section 2702(a)(1) of the Public Health Service Act. Section 2705(a)(1) of the Public Health Service Act, which applies to QHP issuers on the FFEs, prohibits discrimination against individuals based on their health status-related factors. Similarly, section 2102(b)(1)(B)(ii) of the Act prohibits CHIP programs from denying eligibility for children with preexisting conditions. Finally, the overarching regulations at 45 CFR part 92 implementing section 1557 of the Affordable Care Act prohibit discrimination under any health program or activity receiving Federal financial assistance on the basis of race, color, national origin, sex, age, or disability.

Comment: Multiple commenters suggested that implementation of a Payer-to-Payer API may increase provider burden with unintended downstream effects. A commenter discussed how the Payer-to-Payer API could lead to a negative impact on providers who may be required to ingest large amounts of data if payers maintain a longitudinal record back to January 1, 2016, that is also shared via the Provider Access API.

Response: Our modification to require impacted payers to exchange only 5 years of data via the Payer-to-Payer API will mitigate this possible issue for providers. By circumscribing the data to be exchanged by payers to only more recent data, providers are less likely to receive distant and irrelevant historical data via the Provider Access API. We acknowledge that not all of a patient's health information is going to be equally relevant to a particular provider. Therefore, providers should look for clinically relevant information and work with their EHR vendors on solutions to easily display the information most relevant to their practice. We discuss this issue is greater depth in section II.B.2.c.

Comment: A commenter questioned the utility of the Payer-to-Payer API if payers other than impacted payers do not voluntarily adopt the technology and processes to share data.

Response: We appreciate commenters supporting Payer to Payer adoption by payers other than impacted payers. We strongly encourage all payers not subject to these provisions to consider the value of implementing a Payer-to-Payer API, so that all patients, providers, and payers in the U.S. health care system may ultimately experience the benefits of such data exchange. Even though not every payer may participate in it, our Payer-to-Payer API policy can benefit the millions of Americans covered by impacted payers. We specifically encourage impacted payers that have other lines of business to adopt the policies in this final rule for their commercial plans that are not subject to the requirements of this rule.

Comment: A commenter recommended that CMS work with ONC and industry stakeholders to develop a longer-term FHIR roadmap, including patient-centric data homes that efficiently and effectively collect, storage, and integrate information from across the health system on behalf of a patient. Another commenter recommended that CMS work with the DoD and the VA to implement Payer-to-Payer APIs.

Response: We appreciate the support for our Payer-to-Payer API policies and will continue to work with other Federal agencies to improve interoperability across the health care system.

Comment: Many commenters recommended delaying the Payer-to-Payer API compliance dates to give payers more time to design, develop, test and implement their systems. Some commenters recommended a January 1, 2027, compliance date, and another commenter recommended 4 years after the publication of the final rule, to give industry time to align on a standardized implementation approach. A few commenters suggested CMS delay compliance dates until IGs are mature enough to adopt as required standards, or to allow payers to adopt Payer-to-Payer API on a voluntary or pilot basis. Some commenters suggested CMS set rolling compliance dates and the Payer-to-Payer API should be prioritized after the Prior Authorization API. Several commenters specifically recommended that CMS to delay the compliance dates for state Medicaid agencies to implement a consistent solution at enrollment. A commenter requested that CMS accelerate the compliance dates to 2024. Another commenter urged CMS to consider the added cost and burden for payers to meet the proposed compliance dates.

Response: Because we understand that the payer implementation process is significant, after reviewing the comments, we are finalizing a modification to our proposal for the Payer-to-Payer API, to establish compliance dates in 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs). However, as discussed in section I.D.2., we decline to delay beyond that because of the importance of payer to payer data exchange. Establishing regulatory compliance dates will provide greater urgency to test and mature the evolving technical standards and IGs. When we proposed to require the relevant IGs in our December 2020 CMS Interoperability proposed rule, we received many comments that those standards were not mature enough to feasibly implement at that time. In response, we proposed in this rulemaking to only recommend (rather than require) the IGs for standardized implementation. After consideration of the comments we received in response to the CMS Interoperability and Prior Authorization proposed rule, we are finalizing those IGs as recommendations because it is prudent to move forward to attain the policy goals of the Payer-to-Payer API, even while those standards are being developed to achieve true interoperability. Moving to a 2027 compliance dates will give the industry an extra year to refine those IGs and for payers to implement their technical solutions.

With regard to the requests for additional time for Medicaid programs specifically, we refer readers to section II.E.2.a. of this final rule where we finalize our proposals to create a process for Medicaid and CHIP FFS programs to request and be granted an extension to the compliance dates for the Payer-to-Payer API.

2. Proposal To Rescind the CMS Interoperability and Patient Access Final Rule Payer to Payer Data Exchange Policy

We strongly believe that data exchange among payers is a powerful way to improve information sharing that would allow patients and providers to have more complete access to health information, which can help to promote better patient care. Patients may wish for their health information to follow with them when they change payers, in part so that they can track the services they have received, and to ensure that a new payer has information to better assist with continuity of that care. However, given the concerns raised by stakeholders regarding the lack of technical specification in our previously finalized policy, we proposed to rescind the payer to payer data exchange policy finalized in the CMS Interoperability and Patient Access rule (85 FR 25568) at 42 CFR 422.119(f)(1) and 438.62(b)(1)(vi) and (vii) and 45 CFR 156.221(f)(1). We did so to prevent industry from developing multiple systems, and to help payers avoid the costs of developing non-standardized, non-API systems, and the challenges associated with those systems. We proposed a new policy that would, instead, require impacted payers to implement and maintain a Payer-to-Payer API using the FHIR standard. We stated that using FHIR APIs would ensure greater uniformity and ultimately lead to payers having more complete information available to share with patients and providers.

Comment: Commenters supported CMS's proposal to rescind and replace the Payer-to-Payer API requirements finalized in the CMS Interoperability and Patient Access rule (85 FR 25568). They agreed that the proposals would help standardize data exchange and avoid developing duplicative systems. Multiple commenters strongly supported the newly proposed FHIR API approach and noted that this API would leverage the same standards as the Patient Access and Provider Access APIs. A commenter highlighted how CMS's proposal to replace the payer to payer data exchange addressed a key concern held by the industry about the lack of specificity in the previous policy. Another commenter stated that they welcomed the elimination of provider remittances and cost-sharing information from the required data content.

Response: We appreciate commenters support and are finalizing our rescission of the previous policy.

We note that we are correcting a technical error in this final rule for the Payer-to-Payer API requirements in Medicaid managed care. When we proposed to remove the requirement at 42 CFR 438.62(b)(1)(vi) and (vii) and instead use a cross reference to 42 CFR 431.61(b)(1) at § 438.242(b)(7), we inadvertently neglected to properly revise 42 CFR 438.9 to continue excluding NEMT PAHPs from the Payer-to-Payer API requirements. When the payer to payer data exchange requirements were finalized in the CMS Interoperability and Patient Access rule (85 FR 25568) at § 438.62(b)(1)(vi) and (vii), NEMT PAHPs were automatically excluded as 42 CFR 438.62 is not applicable to NEMT PAHPs. However, by moving the Payer-to-Payer API requirements to § 438.242(b)(7), the requirements would apply to NEMT PAHPs (at 42 CFR 438.9(b)(7)). As we explained when we proposed to exclude NEMT PAHPs from the Provider Access API (87 FR 76258), we believed that the unique nature and limited scope of the services provided by NEMT PAHPs, in that they only cover transportation and not medical care itself, justified their exclusion from the requirements of the Provider Access API. Similarly, we do not believe that other payers have a routine need for NEMT data; therefore, requiring NEMT PAHPs to implement and maintain a Payer-to-Payer API would be an undue burden on them. It would also be a burden on other Medicaid payers concurrently covering a patient to receive NEMT data quarterly as required at 42 CFR 431.61(b)(5). To correct this oversight, we are finalizing 42 CFR 438.9(b)(7) to exclude the requirement at § 438.242(b)(7), which is to comply with § 431.61(a) and (b).

Comment: A commenter supported our proposal to rescind the previous requirements but urged us not to finalize our new Payer-to-Payer API proposals, because many of the technical standards are still undergoing development and refinement and operational processes have not been established by payers. The commenter suggested that CMS should consider establishing a voluntary payer to payer data exchange policy.

Response: We acknowledge that any new requirement is going to have operational challenges that need to be resolved. Technical standards have substantially developed over the past 3 years since we issued the December 2020 CMS Interoperability proposed rule (85 FR 82586). We refer readers to sections II.G.3.a. and II.G.3.b. of this rule for additional discussion on enhancements to both the required and recommended IGs published since the publication of the CMS Interoperability and Prior Authorization proposed rule. For example, the recently published PDex IG STU 2.0.0 specification now includes a Prior Authorization profile that enables payers to communicate prior authorization requests and decisions. We are extending our compliance dates for the Payer-to-Payer API from our proposed 2026 to 2027 in order to provide additional time for stakeholders, and specifically payers, to address those barriers to implementation.

3. Payer to Payer Data Exchange on FHIR

a. Payer-to-Payer API Technical Standards

In the CMS Interoperability and Patient Access final rule we finalized a requirement that impacted payers must implement, maintain, and use a Patient Access API conformant with 45 CFR 170.215. However, we did not require payers to use an API or specific standards for payer to payer data exchange in that final rule.

In the CMS Interoperability and Prior Authorization proposed rule, we proposed an API-based payer to payer data exchange utilizing standards and technology similar to that of the Patient Access API. The degree of overlap between the requirements for the Patient Access API (discussed in section II.A.2. of the proposed rule) and the Provider Access API (discussed in section II.B.2. of the proposed rule) should ease the development and implementation of the Payer-to-Payer API for payers.

The Patient Access API will provide the foundation to share adjudicated claims and encounter data, all data classes and data elements included in a standard adopted at 45 CFR 170.213 (USCDI), as well as certain information about prior authorizations. Because, as of January 1, 2021, the same adjudicated claims and encounter data, and all data classes and data elements included in the standard at 45 CFR 170.213 are already required for the Patient Access API, payers should have already formatted these categories of data and prepared their systems to share these standardized data via a FHIR API. As a result, payers have already devoted the development resources to stand up a FHIR API infrastructure when they implemented the Patient Access API, which could be adapted for additional interoperability use cases.

We proposed that, beginning January 1, 2026 (for Medicaid managed care plans and CHIP managed care entities, by the rating period beginning on or after January 1, 2026, and for QHP issuers on the FFEs, for plan years beginning on or after January 1, 2026), impacted payers must implement and maintain a Payer-to-Payer API that is conformant with the same technical standards, documentation requirements, and denial or discontinuation policies as the Patient Access API.

We proposed to require certain standards adopted under 45 CFR 170.215 that are applicable to the Payer-to-Payer API. We are finalizing our proposals for the Payer-to-Payer API with modifications, requiring impacted payers to use the following standards: HL7 FHIR Release 4.0.1 at 45 CFR 170.215(a)(1), US Core IG at 45 CFR 170.215(b)(1)(i), and Bulk Data Access IG at 45 CFR 170.215(d)(1). We also recommend payers use the CARIN IG for Blue Button STU 2.0.0, PDex IG STU 2.0.0, and SMART App Launch IG Release 2.0.0 to support Backend Services Authorization. We proposed but are not finalizing to require impacted payers to use SMART App Launch IG and OpenID Connect Core for reasons discussed later in this section. We refer readers to Table H3 for a full list of the required standards and recommended IGs to support API implementation. We refer readers to section II.G. of this final rule for further discussion of the required and recommended technical standards for the Payer-to-Payer API.

One operational difference between the Patient Access and Payer-to-Payer APIs is that payers may find it more efficient to share data for multiple patients at a time. It is likely that impacted payers with a fixed enrollment period will have many patients' data to share at one time, especially if other payers share that enrollment period (such as QHPs offered on an FFE). In such a situation, it could require significant time and resources for payers to send each patient's data individually through an API. The Bulk Data Access IG for exchanging multiple patients' data at once has been adopted by ONC at 45 CFR 170.215(d)(1), which is discussed further in section II.F. of this final rule and is a standard we proposed to require for the Payer-to-Payer API.

We requested comments on these proposals. We received multiple comments regarding technical implementation challenges and the maturity of the recommended IGs, which are addressed in section II.G. of this final rule. Here we respond to the comments specific to the standards and IGs for implementing the Payer-to-Payer API.

Comment: Multiple commenters stated their support for the proposed FHIR standard and recommended IGs for the Payer-to-Payer API. Multiple commenters stated that the FHIR standard will ultimately prevent issues with data sharing across payers and allow information to be shared accurately and timely. Many commenters gave their support for our proposal that the Payer-to-Payer API must be conformant with the standards at 45 CFR 170.215, including support for the Bulk Data Access IG and OpenID Connect Core. Some commenters agreed with not requiring payers to use the CARIN IG for Blue Button or HL7 Da Vinci IGs. Additionally, other commenters explained that universally implementing FHIR would define how health care information is shared, but will have no impact on how data are collected or stored. Multiple commenters stated their support for requiring Payer-to-Payer APIs to use the same standards as the other interoperability APIs. A commenter stated that leveraging the same standards and IGs will support efficient implementation. Another commenter stated that the lack of standards has been one of the barriers to achieving data fluidity between payers.

Response: We thank commenters for their support of the proposed standards and recommended IGs for the Payer-to-Payer API and agree that the using standards will support more efficient data sharing. Requiring impacted payers to use the same standards and IGs will support consistent implementation and improve interoperability across health care. We note that for the Payer-to-Payer API, we are finalizing a modification to our proposal by not requiring the SMART App Launch IG at 45 CFR 170.215(c) and OpenID Connect Core at 45 CFR 170.215(e)(1), as discussed further in section II.C.3.d.iii. of this final rule. Protocols requiring user level credentials managed by the payer, such as those used with OpenID Connect Core, are generally not appropriate for business-to-business data exchanges like the Payer-to-Payer API where a particular individual may not be directly initiating the exchange.

Comment: Some commenters who supported the proposal that the Payer-to-Payer API must be conformant with FHIR at 45 CFR 170.215(a)(1) identified concerns with implementation. Multiple commenters agreed with the approach to require the FHIR standard for Payer-to-Payer APIs, but some commenters noted that the standard has not been widely demonstrated in production by industry stakeholders. A commenter stated that payers will need to create workflows to process exchanges, incorporate received data into local records, and troubleshoot any issues. A commenter recommended that CMS allow 1 to 2 years to implement new standards depending on complexity. The commenter encouraged data transfer standards be backward compatible.

Response: We agree that implementing new standards takes time and appreciate the commenter recommending we allow 1 to 2 years. However, technology and standards are ever evolving and will never remain static for the period it would take the entire industry to implement. To address comments about the time necessary for implementation, we are delaying the compliance dates for the Payer-to-Payer API to 2027, which will give implementers approximately 3 years from the publication of this final rule. Public comment has broadly indicated that the proposed standards will be sufficiently mature for implementation by that deadline. We will continue working with HL7, the FHIR accelerators, and industry stakeholders to define, to participate in and convene testing events, and to develop and maintain the specifications, which moves them towards greater maturity. Specifically, the PDex IG has been tested, implemented, and based on industry standard consensus, is ready for use. We acknowledge that the standards discussed in this rule will continue to mature to enhance functionality and meet additional use cases. We expect that future rulemaking by CMS and ONC will be necessary to keep pace with the latest technical innovations. While the technology may never be “done,” commenters indicated that the standards available today are sufficiently mature to facilitate 2027 compliance dates for the policies in this final rule that require API development or enhancement.

We acknowledge that, as with any standard, potential compatibility issues could arise through the further development of those specifications. We discuss IG maturity further in section II.G.3.b. of this final rule. These standards are subject to a standards development process where changes are reviewed and compatibility is an important consideration, increasingly so with the level of adoption and use. As the IGs mature, the number of potential compatibility issues between versions is expected to decrease.

Comment: Multiple commenters recommended that CMS name specific IG versions and standards as a baseline for the Payer-to-Payer API and create a formal standard version advancement process similar to the ONC Standards Version Advancement Process (SVAP). A commenter noted that an established SVAP would give the industry and HL7 the opportunity to continue refining and testing standards and IGs to ensure consistent implementation. A commenter recommended that CMS ensure that the applicable Payer-to-Payer API technical standards remain current as new versions become available. Multiple commenters specifically stated their concern for endpoint compatibility and recommended that CMS create required standards so that payers do not need to make one-off modifications to accommodate slightly different APIs.

Response: In the proposed rule, we stated that we believed the approach of recommending, but not requiring, specific versions of the IGs would provide directional guidance without locking implementers into the versions of the recommended IGs available at the time of the proposed rule. To not recommend any specific IGs would have meant a more diverse set of proprietary solutions with little to no interoperability. Our recommendations have allowed the IG authors and community to receive feedback from real-world use and to further mature and refine the IGs. Certification and testing of these APIs could help avoid implementation variation and will consider ways for CMS to support such testing in the future. In addition, by using the recommended IGs, implementers can ensure that their APIs are compatible and conformant to the requirements. As the standards continue to mature, we will consider whether to propose requiring additional IGs through rulemaking.

Comment: A commenter stated that the proposed IGs are dependent on an outdated network authentication protocol and recommended using the HL7® FHIR® Da Vinci Health Record Exchange (HRex) IG, which leverages UDAP for authentication. Another commenter simply recommended utilizing UDAP for authentication. Another commenter recommended CMS modify the standards and IGs to adequately capture the Payer-to-Payer API requirements. The commenter stated that CMS should support the development of content and technical standards for prior authorization decisions that can be incorporated into the appropriate IGs for testing.

Response: We acknowledge that there is no single security protocol approach that will address all use cases. Additionally, within a single API, implementers may need to utilize more than one protocol to address specific population and trading partner needs. As discussed in section II.C.3.d.iii. of this final rule, we are finalizing a modification to our proposal to not require the OpenID Connect Core and SMART App Launch IG standards for the Payer-to-Payer API. We recognize that methods such as SMART Backend Services (which is included in the SMART App Launch IG v2), mTLS, UDAP, or other trust community specified means may be appropriate depending on the needs. We refer readers to Table H3 in this final rule for an updated finalized list of all required and recommended IGs for the Payer-to-Payer API. We will continue to work with ONC to advance the versions of the standards that ONC adopts at 45 CFR 170.215. We will continue to monitor the development UDAP and other trust community specified solutions that could support the Payer-to-Payer API authentication process. We also note that ONC has adopted SMART Release 2.0.0 at 45 CFR 170.215(c)(2) and while we are not requiring the SMART App Launch IG for the Payer-to-Payer API, we do recommend using SMART Backend Services.

Comment: A commenter expressed support for maturing the PDex IG and noted that the IG still needs more testing for specific use cases. Another commenter suggested that CMS not finalize the Payer-to-Payer API until it works with HL7 to diminish the costs with the PDex IG. The commenter noted that in the PDex IG, the patient would be responsible for manually executing the data exchange using a third-party app and then transmitting that information to a new payer. Another commenter stated that the IGs identified for the payer to payer data exchange include the capability for two methods (member-mediated and member-directed), which would cause confusion and redundancy. The commenter stated that the member-directed solution would potentially give the new payer access to financial information meant to be available only to the patient.

Response: The PDex IG provides multiple data exchange methods. One method allows a member to directly authorize data being sent to a third party. While this method could be utilized for payer to payer interactions, it is not the primary method defined by the PDex IG for that use case. For the Payer-to-Payer API use case, the PDex IG provides guidance for supporting exchanges that do not require direct member engagement. The PDex IG STU 2.0.0, which is being recommended for the Payer-to-Payer API in this rule, can facilitate on the payer to payer exchange by defining a means for the requesting payer to send a record of the patient's opt in to retrieve data from the other payer. This method does not require patient action through OAuth and is the method we recommend for payer to payer data exchanges. While we recognize that the PDex IG utilizes mTLS for payer authentication, we are not requiring that protocol and recognize that other methods, such as SMART Backend Services, UDAP, or other trust community specified means, may be appropriate and easier to implement at scale. Payers will be able to choose the protocols or combination of protocols they deem appropriate as long as they meet the applicable security and privacy requirements.

Comment: Multiple commenters had concerns regarding FHIR due to the lack of mature HL7 FHIR IGs and recommended that CMS instead advance payer to payer data exchange by leveraging the TEFCA QHINs. A few commenters recommended that CMS address the need for a legal governance framework for payer to payer data exchange. A commenter recommended that CMS work with ONC and the TEFCA RCE to incorporate the payer to payer data exchange use case into TEFCA's planned support for payment and operations exchange. The commenter also recommended that CMS allow payers to comply with the Payer-to-Payer API requirements by participating in TEFCA.

Response: We agree with the commenter that TEFCA can provide an efficient vehicle to query, send, and receive standardized electronic health information (EHI) from a broad array of participants enabling payer to payer data exchange. While standards and IGs for using FHIR within a network like TEFCA are still maturing, the FHIR Roadmap for TEFCA Exchange outlines the path for implementation. In addition, ONC and the RCE are currently developing the requirements in Common Agreement Version 2.0 for FHIR-based exchange under TEFCA across Exchange Purposes, including for Payment and Operations. ONC is aiming to publish Common Agreement Version 2.0 in the first quarter of 2024. To the extent that the requirements of this rule can be met through TEFCA exchange by the compliance dates, payers are permitted to do so. However, as there are methods for exchanging data under TEFCA that do not comply with the standards requirements we are finalizing (such as exchanging information using a method other than a FHIR API), participation in TEFCA, including exchanging the required data, does not necessarily mean that the payer is meeting the requirements of this rule.

We note that payer to payer data exchange is legally required under this final rule and as such, legal agreements are not required. However, we understand that some payers may still request legal agreements. CMS is also working closely with ONC to explore how TEFCA could potentially be leveraged to support scalable governance for payer to payer exchange.

Comment: Multiple commenters expressed support for CMS requiring the Bulk Data Access IG. A commenter stated that this IG was designed to exchange population level data to allow payers and providers to analyze care using the tools of “big data” analytics and for bulk information exchange between payers and providers for populations covered under value-based arrangements. A commenter stated it is critical to pace mandates with the development and adoption of standards and that the Bulk Data Access IG is not finalized or adopted by HHS. Another commenter stated that while the Bulk Data Access IG is the correct specification for transferring large amounts of data between two payers, the IG is still evolving. A commenter highlighted that the Bulk Data Access IG will require additional development efforts for their organizations since it is new. Another commenter stated that the Bulk Data Access IG does not include aspects that are relevant to the Payer-to-Payer API.

Response: In the ONC Cures Act final rule HHS adopted the Bulk Data Access IG at 45 CFR 170.215(d)(1). In the CMS Interoperability and Patient Access final rule (85 FR 25510), we finalized a requirement to implement, maintain, and use API technology conformant with the standards at 45 CFR 170.215, which includes the Bulk Data Access IG. In this final rule, we are finalizing standards applicable for each API. Bulk data exchanges are usually used for system-to-system use cases and allow large volumes of information on a group of individuals to be shared in one exchange, which could be useful for sharing data between payers. Therefore, we feel that the Bulk Data Access IG is relevant for the Payer-to-Payer API and is being finalized as proposed.

Comment: Multiple commenters recommended blockchain based technologies be used for the payer to payer data exchange. A commenter recommended that CMS support and evaluate blockchain-based technologies for the payer to payer data exchange and recommended that there needs to be confidence in the ability of blockchain-based technologies to leverage APIs for associated data movement. Another commenter recommended that CMS retain regulatory flexibility to enable future data exchange opportunities, including the potential for permissioned on-chain PHI access rather than an API call and response model.

Response: We acknowledge that there are a range of technologies that may facilitate interoperability. In conjunction with ONC, we are working to establish standards that result from the work of SDOs and have been generally agreed upon by the industry through consensus-based processes. Blockchain technologies do not meet those criteria at this time, but we will continue to monitor evolving technologies and their possible benefits for interoperability. In the meantime, we are not prohibiting payers from using blockchain technology if they are doing so in a way that meets their legal requirements.

Comment: Some commenters stated that payers, especially state Medicaid and CHIP agencies, would need technical assistance with implementing the Payer-to-Payer API. Multiple commenters stated that payers could use HIEs to implement the Payer-to-Payer API requirements, including the opt in process, which would reduce the burden on payers.

Response: CMS has hosted, and intends to host in the future, CMS and HL7 FHIR Connectathons, which are free for stakeholders to attend, as well as provide educational webinars providing overviews of the technical requirements set forth in the interoperability rules. Additional public resources also exist through HL7, such as HL7 FHIR Connectathons, HL7 website resources and HL7 FHIR workgroup meetings. We understand that some payers may have implementation challenges and one of the reasons we are finalizing 2027 compliance dates is to give impacted payers additional time to prepare and test any new processes they may need to implement.

To the extent that it reduces burden, we encourage payers to partner with HIEs or HINs, especially those operating under TEFCA, to facilitate payer to payer data exchange, subject any other applicable laws governing privacy and disclosure of these data. Some HIEs may already have the technical framework to manage patient consent or engage in standardized data exchange via FHIR APIs in ways that existing payer systems do not. Nothing in this rule would prohibit an impacted payer from partnering with an HIE to meet its requirements. For instance, as HIEs may have access to clinical data from providers that payers do not, some impacted payers may want to contract with an HIE to host their required API, either as their repository for clinical data, or as an intermediary with the payer's own systems. The HIE could then augment payer data with other clinical data they have access to in order to enhance the data available to via the Patient Access, Provider Access, and Payer-to-Payer APIs, subject to other applicable law.

Comment: A commenter cautioned that CMS's proposals could result in each payer building their own API, and each payer pulling data from every other payer within a state. A commenter stated that it is not feasible for every clearinghouse to maintain so many non-standard connections, and to do so would be costly and risky. The commenter stressed the urgency to implement a National Data Warehouse Exchange Hub/Clearinghouse.

Response: Impacted payers will not have to maintain non-standard connections for this payer to payer data exchange, as we are requiring impacted payers to use a FHIR API to support interoperable implementations. We are requiring impacted payers to use the same standards specifically so that connections between payers do not need to be “hard coded” but can rely on the same technical standards to connect to any other payer's endpoint. There is no requirement to use a clearinghouse, but to the extent it could benefit payers, we encourage them to leverage HIEs or HINs.

Comment: A commenter recommended that CMS resolve the technological infrastructure dependencies by further investing in the HL7 FAST Accelerator and ONC's work to facilitate patient matching and support implementation of the HL7 FAST Accelerator solutions to enable scaled exchange through FHIR APIs. Another commenter recommended that CMS collaborate with ONC to encourage industry adoption of the solutions outlined by the HL7 FAST Accelerator, at minimum, identity resolution, security, and directory for the Payer-to-Payer API.

Response: We will continue to work closely with ONC on the FAST Accelerator and will seek to leverage any appropriate solutions being developed as part of this work. We are also committed to continuing to work with HL7, the Accelerators, and interested parties within the industry in defining, participating in, and convening testing events, as well as developing and maintaining the specifications, thereby moving them toward greater maturity and will adopt solutions as appropriate to our use cases as they mature.

b. Payer-to-Payer API Data Content Requirements

i. Data Content

We proposed to require impacted payers to implement and maintain a Payer-to-Payer API to exchange claims and encounter data (excluding provider remittances and patient cost-sharing information), all data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI), and certain information about prior authorizations that the payer maintains with a date of service on or after January 1, 2016. As stated in the proposed rule (87 FR 76255), this set of data is consistent with requirements for the Patient Access API finalized in the CMS Interoperability and Patient Access final rule (85 FR 2555) and our proposals for the Patient Access and Provider Access APIs. Using the same data content standards across the APIs in this final rule adds efficiencies for payers and maximizes the value of the work that has already been done, reducing the overall burden for impacted payers.

In response to comments, we are finalizing our proposal, with modifications. We are modifying the data content by excluding data related to denied prior authorizations. In addition, we are also finalizing a modification by only requiring impacted payers to exchange data with a date of service within 5 years of the request.

Comment: Many commenters expressed that using the same January 1, 2016, start date for the set of data that must be exchanged via the Payer-to-Payer API would include significant historical data that are unlikely to be relevant to a patient's current health status and ongoing care. Those commenters urged us to establish a rolling period of time to the date of the exchange for the data content that must be shared. Some commenters pointed out that the technical and operational level of effort to integrate a patient's full history would impose significant data storage and archival costs on payers. Some commenters disagreed with CMS's justification for the proposal that payers were the appropriate maintainer of a patient's complete health history and suggested that while payers had a role to play, patient apps could be a more efficient, effective and reliable method to meet that objective.

Response: While we continue to support and emphasize the benefits of payer to payer data exchange, we also recognize the burden of exchanging and storing large amounts of complex patient data. There are two main benefits for Payer-to-Payer API data exchange: to facilitate care continuity when a patient changes payers and to maintain the patient's record so that relevant information is not lost. After consideration of the comments, we agree that requiring impacted payers to exchange a patient's entire history back to the proposed January 1, 2016, date would impose a significant burden on payers to integrate and maintain those data. In effort to balance the benefits we described in the proposed rule, which were supported by commenters, and the burden that some commenters raised, we are finalizing a modification to our proposal to limit the payer to payer data exchange to only the previous 5 years of data.

As described previously, solutions are emerging in the marketplace for Personal Health Records (PHR) that are better suited to keeping patient records for an indefinite period than payers, which might themselves maintain limited clinical data. ONC defines a PHR as an electronic application through which patients can maintain and manage their health information (and that of others for whom they are authorized) in a private, secure, and confidential environment. For instance, health apps can create a longitudinal record by gathering data both from payers via the Patient Access API, and providers' CEHRT. Even so, it is still important for patient care and continuity for a patient's new payer to receive and maintain some recent historical record of the patient's care. When a patient changes payers, only the information that the current payer maintains would be available via the Patient Access, Provider Access and Payer-to-Payer APIs.

As payers and providers will have a more robust infrastructure for data exchange (including via the FHIR APIs required in this final rule), they are better suited to enable data exchange to providers and between payers than a patient would be with their PHR. A patient could supplement information that their payer maintains with information from their PHR, but should not have the primary responsibility for ensuring the technical capability to send their records.

For continuity of ongoing care, we expect that the more recent data are, the more relevant they generally would be. Therefore, it is important to establish a period of time that is reasonably likely to include information relevant to foreseeable care after a patient changes payers. While many commenters suggested shortening the timeframe for data to be exchanged, we did not receive comments suggesting a specific period. Five years balances the needs to manage care continuity and establish a patient record with their new payer while not being overly burdensome on payers to exchange and maintain a large amount of data that may not be relevant. Being able to keep the most recent 5 years of data when transitioning between payers will cover the vast majority of a patient's ongoing and future healthcare needs. Even for patients with chronic conditions, data older than 5 years are unlikely to have significant relevance or value when more recent information is available. This amount of data sharing strikes the right balance of limiting the burden to payers, while still reaping the benefits of care coordination and continuity and allowing patients to maintain a significant amount of data with their current payer.

However, we disagree with commenters who suggested limiting the data exchange to a shorter period to focus only on current health conditions and ongoing care. We do not want to narrow the scope of data to be exchanged to focus simply on care continuity. Health information that is not relevant at the time a patient changes payers may later be important for the patient or their providers to have access to. Beyond the care continuity justification for payer to payer data exchange, making a reasonable amount of patient data available, even if it is not the patient's full record, is still an important goal of this policy. For these reasons, and to better balance the burden on payers and benefit to patients, we are finalizing a modification to our proposal to only require the most recent 5 years of data be exchanged between impacted payers. We will monitor the Payer-to-Payer API implementation and usage to determine whether to extend this timeframe in the future.

For some patients, those 5 years of data may still comprise a significant quantity. However, the data content requirements for the Payer-to-Payer API are built on structured data standards, such as the data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI), which should be easily ingested using the recommended IGs. The exception to that structured data is administrative and clinical documentation submitted by providers related to prior authorization requests and decisions, as discussed later in this section of this final rule. We encourage impacted payers to review the PDex IG for guidance on ingesting patient data in a structured manner that creates a useable patient record. We also note that CMS will continue to work closely with ONC and other Federal agencies to improve data interoperability through initiatives such as the USCDI+.

Comment: Multiple commenters recommended narrowing the scope of data that would be exchanged via the Payer-to-Payer API. Some commenters suggested that CMS narrow the scope of information required to be exchanged to specific data that would facilitate a change in coverage. Other commenters recommended that CMS only require a minimum set of information necessary to facilitate a patient's transition and improve care coordination. Some commenters recommended that CMS work with industry stakeholders to determine a subset of key coverage, clinical, demographic, claims, and encounter information to share via the payer to payer data exchange to support coverage transitions. Another commenter expressed that the data exchange should be limited to claims data and prior authorization decisions.

Response: We disagree with the view that the information sent via a Payer-to-Payer API should be limited to a minimum set of data that would facilitate transition between payers and continuity of ongoing care. While care continuity is one purpose of the Payer-to-Payer API, there are use cases that benefit from additional information being sent. Specifically, we proposed to include claims, encounter data and clinical data to maintain the availability of those data for the Patient Access and Provider Access APIs after a patient changes payers. We acknowledge that a patient's historical data may not be directly relevant to a patient's care at the time of transition. However, that does not mean that a patient or provider would never have a reason to access those data. While the payer to payer data exchange has its use cases, the Patient Access and Provider Access APIs have additional use cases. Therefore, it is important to consider not just how a payer would use data received from a previous payer, but how patients and providers may use it as well. A patient should not lose access to their recent claims, encounter, or clinical data from their payer because they are not strictly necessary to facilitate the transition to a new payer. As discussed, we are finalizing a modification to our proposal to limit the data to be sent to that with a date of service within 5 years of the request.

Comment: Multiple commenters provided recommendations regarding clinical data to be exchanged. Some commenters stated that clinical information is not stored in a sharable format for the Payer-to-Payer API. Specifically, a commenter discussed how current technology cannot adequately parse through large, non-standardized files. The commenter noted that clinical information sent by providers to payers is not received, structured, or stored in a way to be shared, as the X12 275 transaction standard for healthcare claims attachments has not been finalized (though a standard has been proposed in the HIPAA Standards for Healthcare Attachments proposed rule (87 FR 78438)). In addition, a commenter recommended that CMS work with ONC to implement a requirement that providers share comprehensive clinical data in a FHIR enabled format with patients and payers. Another commenter recommended that CMS remove the requirement that impacted payers share all clinical information in USCDI and focus on the clinical information that has been received in standard, electronic structured format related to prior authorization. A commenter asked CMS to explain whether impacted payers only need to make available via the API the USCDI data classes and data elements that they currently maintain.

Response: We acknowledge that not all information that we are requiring to be made available through the Payer-to-Payer API will be stored and maintained in a structured data format within the payers' systems. However, the benefits of ensuring that a patient's data follow them to a subsequent payer outweigh the burden of exchanging that information. In many circumstances, clinical information can be significantly more informative than claims or encounter information. For example, claims for laboratory tests will not provide the actual results of those laboratory tests, which is more important than simply knowing that laboratory tests were done without knowing what the results were. However, we know that many payers do not maintain clinical data, or only maintain specific sets of clinical data and therefore claims and encounter information can fill gaps that would otherwise be missing.

Our data content requirements for the Payer-to-Payer API are built on the existing requirements for the Patient Access API. The set of clinical information that we have required to be available via the Patient Access API since January 1, 2021, is defined by the USCDI standard at 45 CFR 170.213. As discussed in section II.A.2.d. of this final rule, for clarity we are changing the regulatory text to point directly to the USCDI standard at 45 CFR 170.213 for the Patient Access API, as well as the new Provider Access and Payer-to-Payer APIs. Therefore, to the extent a payer maintains those data, the data classes and data elements in USCDI should already be in payers' systems in a form that makes them available via a FHIR API. Because payers should already have experience making that set of information available, there should not be a significant burden to make the same underlying data available through multiple APIs. Henceforth, with our revisions to directly reference the content standard at 45 CFR 170.213, the Patient Access, Provider Access, and Payer-to-Payer APIs will all be required to include all data classes and data elements within that content standard that are maintained by the payer.

We are not adding any requirements in this final rule that would require payers to parse and convert unstructured files into structured data, either for their own records or to share via the APIs. We also expect that as standards are adopted across the industry, an increasing percentage of clinical data will be stored and transmitted in structured formats, which is a result we encourage. We note, however, that unstructured administrative and clinical documentation submitted by a provider to support a prior authorization request (excluding those for drugs and those that were denied) are required to be sent through the Payer-to-Payer API.

Comment: A commenter recommended that the patient's choice whether to opt into the Payer-to-Payer API be part of the data exchanged.

Response: That piece of information is required as part of the attestation of patient opt in and is discussed in more detail in section II.C.3.d.iv. of this final rule. If a patient does not opt in, there would be no payer to payer data exchange under these requirements.

Comment: A commenter recommended that CMS reduce the quantity of data that needs to be exchanged by not requiring that denied claims be exchanged between payers.

Response: While some denied claims may be extraneous (such as a claim denied because it is a duplicate), they may contain important information about a patient that would be beneficial to their record. A claim, even if it is denied, can indicate that a patient received items or services, even if the claim was not paid. Denied claims are also included in the information that is currently required to be available via the Patient Access API (85 FR 25532). We did not propose, nor are we finalizing, to exclude denied claims from the Payer-to-Payer API (or the Provider Access API). However, as discussed in section II.C.3.b.iii., we are excluding denied prior authorization requests from the set of information that must be exchanged between payers. Unlike claims, a denied prior authorization request does not indicate that the patient actually received items or services and therefore an exclusion is justified, as discussed.

Comment: Multiple commenters stated that payers have already formatted the necessary data elements and prepared their systems to share the standardized data through other FHIR APIs. A commenter noted that this infrastructure can be adapted for expanded interoperability use cases, such as the Payer-to-Payer API. However, another commenter believed that barriers to implementing FHIR APIs exist in the way of process siloes in payer organizations.

Response: We appreciate the confirmation that payers have already formatted the necessary data elements to be shared through other FHIR APIs, particularly the Patient Access API. We agree that infrastructure can be adapted for this Payer-to-Payer API and are requiring the same data classes and data elements already required for the Patient Access API. Payers have already formatted these data elements and prepared their systems to share these standardized data via a FHIR API. We note that the Payer-to-Payer API data content requirement also includes both structured and unstructured administrative and clinical documentation submitted by providers related to prior authorizations, of which the unstructured documentation is not required to be shared through the Patient Access and Provider Access APIs. We also agree that payers have already devoted the development resources to standing up a FHIR API infrastructure when they implemented the Patient Access API, which could be adapted for expanded interoperability use cases. Using the recommended IGs will reduce implementation barriers and we encourage payers to get involved in the HL7 FHIR workgroups and to collaborate with other payer organizations on these API implementations. In addition, we are delaying the compliance dates to 2027 rather than the proposed 2026 not just to give payers time to implement the technical requirements, but also to address any internal business process changes that may be necessary.

ii. Provider Remittances and Patient Cost-Sharing

We proposed to exclude provider remittances and patient cost-sharing information from the Payer-to-Payer API because that information is often considered proprietary by payers. While there could be value to patients having provider remittances and patient cost-sharing information available via the Patient Access API, exchanging those data between payers would have only a limited beneficial impact on care. We believed that information about provider remittances and patient cost-sharing under another payer would have no impact on a payer's ability to ensure care continuity when a patient changes payers. Furthermore, there are existing processes for coordinating payment when a patient has concurrent payers that we did not wish to affect. Sharing claims and encounter information, even without these cost details, would complement the data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI), by providing more information about the patient's care history to support care coordination and efficient operation.

Comment: Multiple commenters supported the exclusion of provider remittances and patient cost-sharing information from the data shared through the payer to payer data exchange. However, a few commenters noted that this policy could create additional development work if payers need to segment data elements to make provider remittances and patient cost-sharing information available via the Patient Access API, but not the Payer-to-Payer API (or Provider Access API).

Response: We acknowledge that segmenting data could create additional burden for payers. However, as discussed in the proposed rule, we proposed to not require provider remittances and patient cost-sharing information be included in the data shared via the Payer-to-Payer API because payers may consider that information proprietary. We agree that cost information would have limited benefits to care continuity when a patient changes payers. However, as our policy to exclude that information is intended to protect the payer's proprietary information, we are not prohibiting payers from sending it. Therefore, if a payer believes that implementing their Payer-to-Payer API in such a way that includes provider remittances and patient cost-sharing information would reduce burden, they are not prohibited from doing so.

iii. Prior Authorization Data

We refer readers to section II.A.2.a. of this final rule where we discuss in more detail how prior authorization data must be available through the Patient Access API—and therefore through the other APIs as well. Our proposals to include prior authorization data in the Payer-to-Payer API mirrored our proposals to include prior authorization data in the Patient Access and Provider Access APIs. We stated that it would be valuable for payers to make certain information about prior authorizations available via the Payer-to-Payer API, particularly when a patient enrolls with a new payer. Prior authorization data can inform a payer about ongoing treatments. Payers can use that information to determine whether a new patient needs a new prior authorization, and, if so, whether the information from the previous payer is sufficient for them to issue a decision without additional work by the patient or provider. Prior authorization is a significant focus of this final rule as a whole, and information about these requests and decisions could be beneficial to patients, providers, and payers. As discussed in more detail in section I.D., this final rule does not apply to any prior authorization processes or standards related to any drugs.

We discuss prior authorization and prior authorization processes in more depth in section II.D. of this final rule. We proposed to add certain information about prior authorizations to the set of data that impacted payers must make available via the Payer-to-Payer API upon request from another payer. We proposed that the information must include:

• The status of the prior authorization;
• The date the prior authorization was approved;
• The date or circumstance under which the authorization ends;
• The items and services approved;
• The quantity used to date; and
• Related administrative and clinical documentation.

Comment: Many commenters generally supported including prior authorization information in the Payer-to-Payer API and stated that this would increase transparency, improve care coordination, and reduce burden on providers, patients, and payers. Commenters stated that including prior authorization data in the Payer-to-Payer API would protect beneficiaries' access to necessary items and services since information on prior authorization is not always transferred when beneficiaries switch coverage today. A commenter stated that prior authorization information would enable the new payer to provide continuous coverage for existing treatments and highlighted that this is especially important for patients receiving cancer treatment and specific medications after progressing through step therapies. Multiple commenters expressed support for sharing historical data to increase payer knowledge of previous patient prior authorization decisions and health care data, and to encourage continuity of care.

Response: We appreciate commenters concurring on the importance of previous payers sharing authorization data. The prior authorization process is a priority area for us to reduce patient and provider burden.

Comment: Multiple commenters recommended that some types of prior authorization data should be excluded from the Payer-to-Payer API. A few commenters suggested that CMS not require impacted payers to include information about prior authorizations without fully understanding how payers could use that information. Commenters specifically recommended that CMS exclude information about previously denied prior authorizations. A commenter noted that this might be used to limit care for patients, even if they meet the new payer's criteria for the same service. Conversely, another commenter noted that there is some benefit to patients and providers having a basic history of denied prior authorization requests.

Response: After considering the comments we received, we are removing the requirement to include denied prior authorization decisions in the Payer-to-Payer API. However, we note that supporting clinical information associated with such decision may be available under the requirement to share all data classes and data elements included in the data content standard at 45 CFR 170.213 (USCDI) that are maintained by the payer. As discussed previously, we are focusing on the aspects of payer to payer data exchange that relate to care continuity when a patient changes payers. Because a previously denied prior authorization decision generally would not reflect ongoing treatment, and thus the information may not support care continuity, the value of including such information would likely be outweighed by the drawbacks of doing so. A denied prior authorization decision does not provide information about the patient's ongoing care because it does not show that patients received any items or services. If a patient did receive those items or services despite the denial of coverage, that information would have to be gathered from elsewhere (such as clinical data), regardless of whether the payer receives information about the denied prior authorization decision. However, we emphasize that denied prior authorization decisions are required to be shared via the Patient Access and Provider Access APIs because the benefits to those parties of accessing that information can be significant, especially for resubmitting requests or appealing decisions.

However, this information could be used in ways that would negatively impact a patient's care or coverage. For example, information about a denied prior authorization decision could potentially create bias in future prior authorization decisions with the new payer, and patients could experience challenges to obtain coverage for a given service. Even if a previously denied prior authorization does not in fact create bias with the new payer, some patients may fear that result, which could lead to fewer patients opting in to payer to payer data exchange.

Comment: Several commenters recommended not including the quantity of services used to date due to the concern that health plan claims data updates are often delayed and, therefore, may not be a reliable source to track the number of authorized services used to date. A commenter recommended that CMS require only the authorized units of items and services for a specific prior authorization, rather than the items and services used under the authorization.

Response: Upon reviewing comments, we agree with the many commenters who pointed out that the authorized services used to date under a prior authorization may be more confusing than useful for patients and providers. We heard that the quantity used to date would only be available based on claims that have been submitted and adjudicated for those items or services. Because there can be a significant lag between the items or services being provided and the claim being adjudicated, the information available through the APIs could be out-of-date and inaccurate. Therefore, we are finalizing a modification to our proposal that will not require payers to share the number of items or services used under the authorization. We are also finalizing a modification to our proposals that this information does not need to be included in the Patient Access API (discussed in section II.A.2.a.ii. of this final rule) or the Provider Access API (discussed in section II.B.2.g. of this final rule).

Comment: Several commenters encouraged CMS to include unstructured documentation and forms that were submitted as part of a prior authorization request. Some payers commented that making that documentation available via the Payer-to-Payer API will facilitate their ability to make prior authorization decisions for a new patients without requesting duplicative information be submitted. Commenters stated that unlike in the Patient Access and Provider Access APIs, sharing supporting documentation through the Payer-to-Payer API could allow the new payer to use that information to make decisions about subsequent prior authorizations, if required. A few commenters held the opposing view that CMS should not finalize requirements to include clinical documentation and forms with prior authorization information via the Payer-to-Payer API.

Response: We are finalizing a modification to our proposal for the Patient Access and Provider Access APIs to remove the proposed requirement to make available unstructured administrative and clinical documentation. We have concluded that for these APIs, the burden outweighs the benefit. However, that is not the case for the Payer-to-Payer API. One of the goals of this regulation and the Payer-to-Payer API requirement is to promote greater continuity of care when patients change payers, especially regarding prior authorization. In order for payers to ease that transition, they need as much relevant data related to recent and ongoing care as possible. For instance, current data can allow a payer to authorize coverage for ongoing treatment, without requiring repeat testing or needing a provider to resubmit clinical information that the provider has already submitted to a previous payer.

In addition, the concerns regarding payers' ability to quickly make the unstructured administrative and clinical documentation available, via the Patient Access and Provider Access APIs, do not apply to the Payer-to-Payer API. Under our Patient Access and Provider Access API policies, payers have 1 business day from the time they receive the prior authorization request or there is another status update to make prior authorization information available. For the Payer-to-Payer API, absent a specific patient request, typically payers only have to exchange data at the time a patient changes payers, or quarterly for concurrent payers. Therefore, unless a prior authorization request is submitted within the last days of coverage, payers will have a longer timeframe to ensure that unstructured documentation is included in the patient's record and can be transferred to another payer when the need or requirement to transfer data through the Payer-to-Payer API arises. Furthermore, the concern about a patient app or provider's EHR not being able to read and display unstructured documentation does not apply to payers, which regularly receive unstructured administrative and clinical documentation with prior authorization requests.

Comment: A commenter suggested that given the complexity and variation across prior authorizations, any pertinent data from peer-to-peer reviews should be included in Payer-to-Payer API exchange.

Response: Based on comments and conversations with payers, we understand that many payers consider the specific criteria they use to make prior authorization decisions to be proprietary information. In addition, because payers have different criteria, information about internal peer reviews of prior authorization requests from another payer has only limited usefulness. Therefore, we are not requiring payers to exchange any documentation that the payer itself generates regarding a peer-to-peer review of a prior authorization request. But we are requiring impacted payers exchange structured and unstructured administrative and clinical documentation submitted by providers related to prior authorizations to assist care continuity and allow payers to make their own decisions based on the patient's specific needs without requiring duplicative submissions from a provider.

iv. Duration of Prior Authorization Data to be Exchanged

We proposed that impacted payers would be required to make certain information about prior authorizations available via the Payer-to-Payer API for the duration that the authorization is active and for at least 1 year after the prior authorization's last status change. We proposed to require the availability of prior authorization information for at least 1 year after any status change across the Patient Access, Provider Access and Payer-to-Payer APIs, so that information from denied and expired prior authorizations would not be lost when they were not approved or no longer active.

Comment: Many commenters supported CMS's proposal that certain information about prior authorizations be available for the duration of an active authorization and for at least 1 year after the last status change. Some commenters were in favor of retaining a patient's historical prior authorization data indefinitely. Another commenter requested clarification on how the proposal to make prior authorization data available for at least 1 year would align with the requirement that impacted payers make available patient data with a date of service on or after January 1, 2016.

Response: As discussed previously, we are finalizing a modification to our proposal that will not require denied prior authorization requests to be shared via the Payer-to-Payer API at all. Such information must be shared through the Patient Access and Provider Access APIs beginning in 2027 (see sections II.A.2.ii. and II.B.2.g. of this final rule for more information). We note that the requirement to share patient data with a data of service on or after January 1, 2016, comes from the CMS Interoperability and Patient Access final rule, which required claims, encounter information and certain clinical data to be made available via the Patient Access API. Prior authorization information was not included in that rule, and therefore, we do not have reason to believe that payers are generally maintaining prior authorization data back to that date. In addition, the obligation to share encounter, claims, or other information from within 5 years of the request is contingent on the payer maintaining those data; for payers that are not required to maintain records past a certain point or that do not have internal policies for retaining records past a certain time period, the data may not be available to be shared through the Patient Access API. As discussed in the proposed rule, the availability of claims and clinical data are more important to patient care than information about prior authorizations that have expired. Claims and encounter data indicate items and services that the patient actually received in the course of their care. Information from a prior authorization indicates whether certain items and services were approved for coverage, and often the basis for that decision. While active or recent prior authorization information is important because it can indicate current or recent medical necessity, such information cannot be inferred from prior authorizations that have been expired for more than 1 year as they would not indicate any sort of ongoing care. Claims and clinical data maintained by the previous payer that are related to the treatment that occurred under an expired prior authorization would replace the need for the expired prior authorization decision itself. While claims and clinical data associated with an expired prior authorization can indicate the type of care received, as discussed earlier in this section, the value to a new payer of prior authorizations that were not acted upon, meaning they do not have a claim or any clinical data associated with them and are not associated with any past treatment or active care for the patient, is outweighed by the potential drawbacks of including such information. We also considered comments summarized previously and also discussed in sections II.A. and II.B. of this final rule regarding the inclusion of these data in the Patient Access and Provider Access APIs. While some API content differences may be beneficial or practical (such as the exclusion of provider remittances and patient cost-sharing information), we are keeping the API requirements as similar as possible to reduce burden by standardizing data content. We emphasize that for ongoing long-term care, any active prior authorizations must be included, even if they have been in that status for more than 1 year. Furthermore, our policy allows payers to make these prior authorization data available for longer than 1 year, if they believe it adds value to patients, providers, themselves or future payers.

v. Considering Prior Authorizations From Another Payer

While we did not propose to require payers to review, consider, or honor the active prior authorization decision of a patient's former payer, payers may gain efficiencies by doing so. We sought comment on the benefits, burdens and considerations of imposing such a requirement. However, we did not make any proposals and therefore are not finalizing any policies in this area. We do note that since we published the proposed rule, the Medicare Program; Contract Year 2024 Policy and Technical Changes to the Medicare Advantage Program, Medicare Prescription Drug Benefit Program, Medicare Cost Plan Program, and Programs of All-Inclusive Care for the Elderly final rule (CY 2024 MA and Part D final rule) was issued, which requires MA coordinated care plans to provide a minimum 90-day transition period when an enrollee switches to a new MA organization, during which the new MA organization may not require prior authorization for an active course of treatment.

Comment: A commenter requested clarification about the relationship between this final rule and the provision for MA plans at 42 CFR 422.112(b)(8)(i)(B) added by the CY 2024 MA and Part D final rule. That rule requires MA coordinated care plans to provide a minimum 90-day transition period when an enrollee switches to a new MA organization during which the new MA organization may not require prior authorization for an active course of treatment.

Response: The requirements at 42 CFR 422.112(b)(8) adopted in that recent final rule apply to Part A and B benefits covered by an MA plan. An “active course of treatment” is defined at 42 CFR 422.112(b)(8)(ii) as a course of treatment in which a patient is actively seeing a provider and following a “course of treatment,” which is defined as a prescribed order or ordered course of treatment for a specific individual with a specific condition, outlined and decided upon ahead of time with the patient and provider. A patient can have an active course of treatment to which 42 CFR 422.112(b)(8) will apply that did not require prior authorization by their previous payer.

Per 42 CFR 422.112(b)(8)(i)(B), MA organizations offering coordinated care plans must have, as part of their arrangements with contracted providers, policies for using prior authorization that provide for a minimum 90-day transition period for any active course(s) of treatment when an enrollee has enrolled in an MA coordinated care plan, even if the course of treatment was for a service that commenced with an out-of-network provider. Further, the MA plan cannot deny coverage of such active courses of treatment on the basis that the active course of treatment did not receive prior authorization (or was furnished by an out-of-network provider) but may review the services furnished against the MA plan's coverage criteria when determining payment. This includes enrollees who are new to an MA plan, an enrollee switching from Traditional Medicare to MA, or enrollees new to Medicare and enrolling in an MA plan for the first time.

In that final rule, we explained how we expect any active course of treatment to be documented in the enrollee's medical records so that the enrollee, provider, and MA plan can track an active course of treatment to avoid disputes over the scope of the new requirement. Therefore, an active course of treatment should be included in the data exchanged between impacted payers, regardless of whether a previous payer required a prior authorization. Under this final rule, the data content that must be shared via the Payer-to-Payer API includes the claims and encounter data (excluding provider remittances and cost-sharing data), all data classes and data elements included in a content standard at 45 CFR 170.213 and certain information about prior authorizations maintained by the payer with a date of service within 5 years of the request. Almost any active course would be represented within that dataset. Any active course of treatment covered by 42 CFR 422.112(b)(8)(i)(B) will thereby become part of the patient's record with their new payer. It is important, especially in light of 42 CFR 422.112(b)(8), that MA enrollees are aware that their active course of treatment is being honored and for how long. That will allow MA enrollees in plans subject to this new requirement, and their providers, to plan for a new prior authorization request, if necessary.

Although this particular need for access to information about active courses of treatment is unique to MA enrollees in MA coordinated care plans, the data exchange and Payer-to-Payer API requirements outlined here are applicable to any impacted payer. While we encourage other payers to honor an active course of treatment similar to the requirements of 42 CFR 422.112(b)(8) for MA coordinated care plans, we have not proposed to require that of any payers not covered by that rule.

c. Identifying Previous and Concurrent Payers and Opt In

i. Process Timing

We proposed that all impacted payers develop and maintain processes to identify a patient's previous/concurrent payer(s) and to allow patients or their personal representatives to opt into the payer to payer data exchange (both with previous and concurrent payers) prior to the start of coverage. Additionally, we proposed that impacted payers would be required to establish similar processes for current patients prior to the compliance dates, to ensure those patients have the ability to opt in and have their data shared through the API. We are finalizing a modification to this proposal, as discussed, to establish a deadline for these processes at 1 week after the start of coverage (as that term is defined for each program).

We emphasized in the proposed rule that obtaining a patient's opt in permission and identifying the previous/concurrent payer(s) could not delay an applicant's eligibility determination or start of coverage with any impacted payer. We noted that the proposed requirement to identify a patient's previous/concurrent payer(s) and obtain a patient's opt in may not always be feasible before the start of coverage, for instance, if a patient does not provide enough information to identify their previous payer. We emphasized that payers must begin this process before the start of coverage, but realize that it may take longer than enrollment. In that case, the impacted payer would be required to continue to engage with the patient to gather their permission and identify any previous/concurrent payer(s). Only once the impacted payer has received permission and identified those other payers would they be required to request patient data, as outlined in sections II.C.3.c.ii. and II.C.3.c.iv. of this final rule. Using Medicaid as an example, if a state has all the information necessary to determine an individual's eligibility before it has identified the previous payer, the state must determine the individual's eligibility and enroll the individual in Medicaid coverage, if determined eligible, while continuing to follow the Payer-to-Payer API requirements as expeditiously as possible post-enrollment.

For new patients enrolling on or after the compliance dates, we proposed to require impacted payers to maintain a process for patients to opt into the Payer-to-Payer API data exchange and to identify their previous/concurrent payer(s) prior to the start of their coverage. In section II.C.4.b. of this final rule, we discuss the possible incorporation of these requirements into state applications for Medicaid or CHIP eligibility. In the proposed rule, we stated that making this process available to patients during the enrollment process, or immediately thereafter, would allow the proposed data exchange to take place as quickly as possible once the patient is enrolled with the new payer. For example, where there may not be communication during the enrollment process such as during the QHP enrollment on the FFEs, this process should be done immediately following enrollment. We solicited comment on incorporating the proposed requirements into the FFE QHP enrollment process as described at 45 CFR 156.265.

Concurrent coverage means that an individual has coverage provided by two or more payers at the same time. This could include, for example, individuals dually eligible for Medicare and Medicaid who are enrolled in both an MA plan and a Medicaid managed care plan. Another example of concurrent coverage is when different services are covered by different Medicaid managed care plans for the same Medicaid beneficiary.

Several payer deadlines in this rule are based on a patient's “start of coverage.” For example, we proposed (and are finalizing) a requirement for impacted payers to request previous and concurrent payer information and a patient's opt in for Payer-to-Payer API data exchange (discussed in section II.C.3.c.iv. of this final rule) no later than 1 week after the start of coverage. Throughout the preamble, we are using the term “start of coverage” to mean when coverage begins or, if coverage begins retroactively, to refer to a later milestone, depending on the payer type. However, to ensure feasible timeframes for new patients after the compliance dates, we are finalizing deadlines based on whether coverage starts prospectively or retroactively. Where coverage starts prospectively, the deadline will be based on the coverage start date (also known as the coverage effective date). In the case of retroactive coverage, to avoid a deadline in the past, the deadline for the payer to provide the required information about the Payer-to-Payer API, request identifying information about previous/concurrent payer(s), and an opt in will be based on the date that the payer gets patient information and makes the patient's coverage effective.

Because the enrollment and coverage initiation processes for each program differ in their specifics, in regulation text, the concept of “start of coverage” is described differently for each type of impacted payer. That is, the regulatory text uses different, program-appropriate terminology for each impacted payer.

For MA organizations, the “start of coverage” generally means the effective date of coverage, as used at 42 CFR 422.68. In some instances, an individual's enrollment may be accepted by CMS with a retroactive effective date of coverage, as discussed in the Medicare Managed Care Manual, Chapter 2, section 60.4. In those cases, the “start of coverage” would be the date that the individual's enrollment is accepted by CMS. Effectively, this means that the “start of coverage” is whichever is the later of those two dates—the effective date of coverage or the date that the individual's enrollment is accepted by CMS.

For example, an MA organization that receives an enrollment request from an individual that is accepted by CMS in January for a February 1 effective date of coverage, would have 1 week from February 1 to complete the applicable requirements. An MA organization that receives an enrollment request from an individual in January that is accepted by CMS on February 7 for a retroactive February 1 effective date of coverage, would have 1 week from February 7 (not February 1) to complete the applicable requirements as finalized in this rule.

For Medicaid, a beneficiary's coverage is generally retroactive 3 months from the date that they are enrolled in Medicaid. For CHIP, retroactive coverage varies among states. Therefore, for Medicaid and CHIP FFS and managed care, the “start of coverage” is simply the date the beneficiary is enrolled in the state's MMIS (or equivalent process), not the date coverage takes retroactive effect.

For QHP issuers on the FFEs, the start of coverage is generally the enrollee's QHP coverage start date. In some cases, a payer may provide coverage retroactively, that is, a payer provides coverage starting on a date prior to enrollment, for instance due to the birth, adoption, or foster care placement of a new child. In that case, the “start of coverage” would be the effectuation of coverage, as described at 45 CFR 155.400(e)(1)(iii). Effectively, this means the “start of coverage” is whichever is the later of those two dates—either the coverage start date or the effectuation of coverage. We refer to the coverage start date as the first date for which the enrollee has coverage and the term “effectuation of coverage” to refer to the date that the payer takes the steps to implement coverage, even if that coverage starts retroactively.

For example, an FFE QHP issuer that receives enrollee information during an annual open enrollment period for a consumer whose coverage will start on January 1 of the following year would have 1 week from the enrollee's coverage start date of January 1 to complete applicable requirements. An issuer that receives information and effectuates coverage on March 6 for an enrollee whose coverage starts retroactively on February 1 would have a week from the enrollee's effectuation date, March 6 (not February 1), to complete the applicable requirements.

Comment: Multiple commenters expressed concern regarding processes for opting in and collecting previous/concurrent payer data occurring at the start of coverage, noting logistical challenges to collecting data at the time of a patient's enrollment, including document format and regulatory challenges to updating existing enrollment forms. Multiple commenters provided recommendations regarding actions for payers to take at the time of enrollment to facilitate collecting this information, such as defining specific data and updating enrollment forms.

In addition, multiple commenters stated that payers should be permitted to collect a patient's opt in after enrollment. A commenter specifically recommended that collection should be allowed during the first month of active enrollment. Some commenters urged CMS to not require payers to collect data at enrollment to support the Payer-to-Payer API, and instead to allow outreach to patients after enrollment through existing tools, such as payer portals. Another commenter stated that requesting that information at the time of the patient's application would allow them to incorporate the process into their existing data collection processes. A commenter noted that the inability to opt in after the enrollment start date could result in low participation rates. Another commenter supported allowing patients to opt into data sharing during the open enrollment period. A commenter supported allowing a payer to collect a patient's opt in prior to the compliance dates for state Medicaid and CHIP agencies and prior to enrollment of new beneficiaries after the compliance dates.

Response: We note that the terms used in the preamble and regulation text of our proposed rule were different. Our discussions in the proposed rule referred to “prior to the start of coverage,” which we explained in preamble and fully discussed throughout the proposed rule, but the proposed regulation text used the phrase “at enrollment” (except for QHP issuers on the FFEs where we used “no later than the effectuation of enrollment”). We did not propose that new payers collect previous payer information at the time of enrollment. We stated that payers must begin the process of collecting the previous payer information and opt in prior to the start of coverage, but that it may take longer than the enrollment process. We are modifying the regulatory text to identify the start of coverage (rather than enrollment) as the milestone that tolls these requirements, consistent with the preamble discussion in the proposed rule.

However, in response to public comments, we are finalizing a modification to our proposal by extending the deadline for both requesting identifying information about a patient's previous/concurrent payer(s) and seeking opt in from the patient to 1 week after the start of coverage, with certain differences among payers. For MA organizations, we are modifying the deadline to no later than 1 week after the coverage start date or no later than 1 week after receiving acceptance of enrollment from CMS, whichever is later. In the case of Medicaid and CHIP FFS, we are modifying both deadlines to refer to 1 week after enrollment, to avoid confusion related to the retroactive eligibility rules in Medicaid. For QHP issuers on the FFEs, we are modifying the requirement to no later than 1 week after the after the coverage start date or no later than 1 week after the effectuation of coverage, whichever is later. Commenters were clear that establishing the start of coverage as the deadline for these actions would result in logistical challenges and compliance would be difficult for impacted payers. We understand that while some types of impacted payers, such as MA organizations, may have contact with patients before the start of coverage, in other cases, payers do not. Furthermore, while we are recommending that state Medicaid and CHIP agencies incorporate these requirements into their applications for coverage, states would have few other options for communicating with patients before enrollment (which is how “start of coverage” is captured in the regulation text for Medicaid and CHIP).

We emphasize that payers must begin the process of collecting the previous/concurrent payer information and opt in no later than 1 week after the start of coverage but understand that it may not be completed within that timeframe. We believe it is important to gather this information from patients as soon as possible when a patient enrolls with a new payer in order to facilitate the timely exchange of patient data. Patients may take additional time to respond or follow-up may be required. Impacted payers are encouraged to make a reasonable effort to engage with patients to gather their permission and identify any previous/concurrent payer(s). We rely on payers to develop reasonable processes to follow up with patients, and recommend payers follow-up one time before determining that the patient is choosing not to opt in. Though not required, we encourage payers to build into their request process a method for patients to indicate that they do not want to provide the requested information, so that payers need not follow up with them. We note that the patient education requirements, discussed in section II.C.3.g. of this final rule, will provide patients annual reminders of the payer to payer exchange functionality. Under this final rule, patients must be able to opt in or withdraw permission at any time.

The opt in and identifying previous/concurrent payers processes could include using existing portals to gather this information from patients, as we are not being prescriptive on how each payer implements this process. We also encourage stakeholders to participate in HL7 FHIR workgroups to collaborate with other industry stakeholders on identifying best practices and identifying possible processes.

ii. Gathering Previous and Concurrent Payer Information

We proposed that impacted payers would be required to gather information about patients' previous/concurrent payer(s) that would allow them to identify and request data from those payers. That could include the payer's name and a patient ID number or similar identifier. Under our proposal, an impacted payer would be required to allow a patient to report multiple previous/concurrent payers if they had (or continue to have) concurrent coverage. In this circumstance, we proposed that impacted payers would be required to request the patient's data from all previous/concurrent payers.

Comment: Multiple commenters expressed concern with the lack of a standardized process to identify a patient's previous/concurrent payer(s) and recommended that CMS either establish a policy to identify the payers, provide technical assistance on how to crosswalk unique identifiers, or standardize elements of the process. A commenter highlighted that the lack of clarity on how payers are to identify a patient's previous/concurrent payer makes the Payer-to-Payer API difficult to operationalize and would likely introduce errors. Multiple commenters recommended additional changes to the enrollment process to support data exchange via the Payer-to-Payer API. A few commenters recommended that CMS work with stakeholders to develop a specific process to collect this information. A commenter urged CMS to reinforce to payers that they should make the processes as easy as possible for patients by leveraging touchpoints that the patient would already be engaged in to enroll and initiate new coverage.

Response: Because the requirements for a Payer-to-Payer API and the need to collect information about previous or concurrent coverage for patients crosses many payer programs with variation between enrollment processes, we determined that being prescriptive on a specific process would cause more implementation burden than necessary. In response to comments, we are finalizing a modification to our proposal to require payers to request previous and concurrent payer information no later than 1 week after the start of coverage. As discussed previously, payers might not have contact with patients before enrollment. Therefore, this modification will allow additional time for payers and broaden the range of options for payers to align with their current processes. Initial implementation may be challenging; however, it is important that patients' data are shared as they transition care to a new payer, because the benefits for patients outweigh the upfront implementation burden. Leaving the process open for payers to implement in the least burdensome, most practical way to gather the information from patients makes the most sense. Gathering previous payer information and an opportunity for the patient to opt in ideally should take place through an already established point of contact with the patient. Leveraging established points of contact will reduce patient burden and help impacted payers meet the deadline of no later than 1 week after the start of coverage. In particular, payers often have existing processes to identify concurrent payers to facilitate coordination of coverage and Medicare Secondary Payer/Third Party Liability administration. For instance, per 42 CFR 422.108, MA organizations are required to identify payers that are primary to Medicare and coordinate its benefits to Medicare enrollees with those primary payers. State Medicaid programs are required to collect sufficient information to enable the state to pursue claims against such third parties when making an eligibility determination or redetermination per section 1902(a)(25) of the Act (for beneficiaries enrolled in managed care, states generally make this the responsibility of the MCO with state oversight). That requirement also applies to state CHIP programs by cross reference at section 2107(e)(1)(B) of the Act. Nothing in this rule would prevent payers from using that information for both that purpose and to identify concurrent payers for Payer-to-Payer API data exchange. However, patients would still need to opt in for payers to proceed with requesting patient data via the Payer-to-Payer API.

Comment: A few commenters requested clarification on whether the definition of “previous payer” is limited to the immediately previous payer or to previous payers within a specific time period, such as within the last 5 years.

Response: The minimum requirement is only to request information from the immediately previous payer, however if a patient does report multiple previous payers, impacted payers are required to request that patient's data from any previous/concurrent payers (identified to or known by the impacted payer) within the required 5-year period. We are finalizing that policy because patients may have been enrolled with payers that are not subject to the requirements of this rule. Therefore, allowing patients to have their impacted payers request data from payers other than their immediately previous payer within the 5-year timeframe could maintain as much of their record as possible.

Comment: A commenter suggested that CMS include a process for new payers to inquire whether the previous payer supported the Payer-to-Payer API described in this regulation, such as a monitored email address, and that some type of consequence for non-compliance should be levied.

Response: In section I.D. of this final rule we discuss an NDH that could serve as a centralized place for payers to find other payers' digital endpoints and identify payers that support the Payer-to-Payer API. Without an NDH or similar source of information, payers would likely be required to contact the previous payer directly to determine if they support the Payer-to-Payer API. We are also exploring other solutions, such as using TEFCA, that could be leveraged to determine if the previous payer supports the Payer-to-Payer API. We have addressed program enforcement and compliance mechanisms in section I.D.2. of this final rule, as well, and appreciate public interest in mechanisms for provider and patient appeals and complaints, oversight, and assurance of compliance.

Comment: A commenter noted that a payer's ability to request data from a previous payer would be dependent on the patient providing accurate information about the previous payer. The commenter expressed concern regarding the accuracy of this information and the effort required for necessary follow-up.

Response: As discussed previously, we acknowledge that the obligation to exchange data is contingent on patients supplying the necessary information about previous/concurrent payers. An impacted payer cannot comply with these requirements if the patient has not provided timely or accurate information about their previous/concurrent payer. We emphasize that payers must request this information no later than 1 week after the start of coverage, but that it may take longer than that to obtain information from the patient. If the patient does not respond or additional information is necessary, the impacted payer must make reasonable efforts to obtain their response to the opt in request and to identify any previous/concurrent payer(s).

Comment: Several commenters suggested data elements that would be necessary or extraneous to make that Payer-to-Payer API request. Multiple commenters encouraged including the patient's name, patient's previous/concurrent payer name, member ID, date of birth, physical address, and phone number in a payer's data request to a previous payer. Multiple commenters urged payers not to require patients to provide the specific plan name, which may be long and unintuitive and because patients may have switched plans over time with that payer. A commenter expressed security concerns with exchanging Social Security numbers (SSNs) and suggested that their use be as limited as possible. Another commenter suggested that patients should be encouraged to provide the dates coverage started and ended or information about up to three recent services covered by the previous plan and those dates of service.

Response: We agree with commenters that demographic information such as patient's name, member ID, date of birth, physical address and phone number are appropriate pieces of information to identify patients. We also agree that SSNs should be used to identify patients only when necessary (and permissible by law) due to that identifier's sensitivity. While start and end dates of coverage may be useful in some instances, patients are unlikely to know or remember those exact dates, nor are they likely easy to find. Therefore, we discourage their use for identifying patients. Asking a patient to provide information about recent services covered by the previous payer could be burdensome to a patient. Patients are unlikely to have that information without gathering it from their previous payer. Therefore, there are less burdensome ways to effectuate this process, such as by using the data elements mentioned previously. Payers should implement these requirements in such a way that accomplishes the goal of identifying patients' previous/concurrent payer(s) with the least burden on patients.

The data elements that a payer may need to identify a patient and match that patient to their record are included in the required and recommended standards for the Payer-to-Payer API. Specifically, the required US Core IG and the recommended PDex IG have “Must Support” fields (meaning that the system must be able to support those data elements) that could be used for identifying a patient, such as patient name, addresses, birth sex, gender, birth date, member and subscriber identifiers, and group number. Requesting payers should use those fields to identify the patient whose data they are requesting. If the information provided is insufficient to make a match, or it matches with more than one member, an error should be returned. Payers will need to use a combination of data elements to support patient matching, as they do today with any data exchange. We also will continue to work with ONC and share information on their patient matching research/initiatives here: https://www.healthit.gov/topic/interoperability/standards-and-technology/patient-identity-and-patient-record-matching. We encourage payers to leverage the appropriate patient matching data elements of the IGs and we will continue to work on ONC on their patient matching research and initiatives.

Comment: A commenter suggested the need for a national Health Plan ID (HPID) to identify a patient's previous/concurrent payers. The commenter requested that CMS re-work and re-issue required standards for a national HPID. A commenter also stated that the process would benefit from establishing technical standards to ensure that all payers are using the same data elements to verify a patient's payer(s).

Response: We acknowledge industry's interest in a national standard for a payer identifier. We are aware that there are a few alternative standards used in transactions today, which are located on member ID cards and maintained in payer systems. For example, the Payer ID, used in Electronic Data Interchange (EDI) transactions, is a unique ID assigned to insurance companies to enable them to communicate with each other to verify eligibility, coverage, benefits and submit claims. CMS also maintains a Plan ID for all QHPs on the FFEs, which are 14 alphanumeric characters. Until and unless a national standard is adopted, industry may wish to collaborate with the SDOs on an appropriate payer identifier for the APIs.

Comment: Several commenters raised the concern that for QHPs, the X12 834 transaction standard for health plan enrollment and disenrollment from the FFEs does not currently carry previous payer information, complete information on concurrent payers, member IDs, or opt in needed to support the payer to payer data exchange during QHP enrollment. A commenter also raised concerns about situations where a patient begins the QHP enrollment process but does make the binder payment, and therefore ultimately does not effectuate their coverage.

Response: Requiring payers to gather this information could result in a more streamlined approach than incorporating it into the X12 834 transaction standard enrollment process, given that FFEs are not otherwise required to use or retain the information. However, as discussed previously, we are finalizing a modification to our proposal to account for the timing of QHP coverage effectuation relative to plan selection, which impacts when a QHP can reasonably obtain information from an enrollee. Specifically, QHP issuers on the FFEs will be required to provide enrollees or their personal representatives with an opportunity to opt into the QHP issuer's Payer-to-Payer API data exchange no later than 1 week after the coverage start date or the effectuation of coverage, whichever is later. This timeframe accounts for the date on which an issuer has confirmation that an individual will be enrolled in QHP coverage with the issuer, by receiving the binder payment that is required to effectuate coverage per 45 CFR 155.400(e), as well as instances in which coverage takes effect retroactively.

iii. Currently Enrolled Patients

We proposed that no later than the compliance dates for the Payer-to-Payer API, impacted payers must establish and maintain a process to gather permission and identify previous/concurrent payer(s) from all patients who are currently enrolled.

Some payers may want to have a soft launch, rolling implementation, or pilot for their Payer-to-Payer API before the compliance dates. We therefore tied our proposal to require impacted payers to gather permission from currently enrolled patients to the proposed 2026 compliance dates, rather than when a payer implements its API. We stated that this would allow payers to sequentially target specific plans, populations, or enrollee categories for operational rollout, as long as all currently enrolled patients are given the opportunity to opt into the payer to payer data exchange by the compliance dates.

We received no comments on this proposal. In alignment with the modified compliance dates discussed throughout this final rule, the requirements to request currently enrolled patients' opt in permission and previous/concurrent payer information will be tied to the 2027 compliance dates we are finalizing for the Payer-to-Payer API.

iv. Opt In

We proposed an opt in approach for the data exchange through the Payer-to-Payer API. We stated that an opt in framework means that the patient or their personal representative would need to affirmatively permit a payer to share data, and without that permission, the payer could not engage in the proposed payer to payer data exchange for that patient. We noted that this permission (or lack thereof) would apply only to the data exchange we proposed and would not satisfy any other obligations required under the HIPAA Privacy Rule or other law. Additionally, we stated that we believed patients themselves are the best source for sufficient and accurate information necessary for the payer to make the request. Should a patient choose to provide this information, it would require an affirmative act from the patient, so we stated that the burden of asking a patient to opt in would not create a significant additional barrier to patient participation. We also proposed to require impacted payers to have a process for patients to opt into this data exchange at any time after the start of coverage, or if they have already opted in, to withdraw that permission at any time.

As discussed in section II.C.4.c. of this final rule, this opt in requirement does not apply to data exchanges between a state Medicaid or CHIP program and its contracted managed care plans or entities. We also proposed that states, through their Medicaid and CHIP programs, would be responsible for collecting a patient's choice to opt into the payer to payer data exchange, rather than their contracted managed care plans. We explained that a Medicaid or CHIP beneficiary may switch between FFS and managed care delivery systems within the same state's Medicaid or CHIP program, but despite these shifts, an eligible beneficiary remains a beneficiary of the state program. States may also change the managed care plans that they contract with. Thus, we proposed that the patient permission for this data exchange, as a Medicaid or CHIP beneficiary, would be obtained by the state and would apply regardless of the delivery system in which the beneficiary is enrolled.

In contrast, our policy for the Provider Access API will allow payers to exchange patient data with providers unless a patient has opted out. We proposed an opt out policy for the Provider Access API, in part, based on the existence of a treatment relationship between the patient and provider, a contractual relationship between the payer and the provider, and a coverage relationship between the payer and patient. Specifically, our policy to only require the Provider Access API data exchange with providers in the payer's network and require a process to attribute a patient to that provider before data can be exchanged creates a level of assurance for the payer that it is sending patient data to an appropriate party. Two payers exchanging information may not have a direct relationship, but would be exchanging data based on a patient's separate relationship with each payer. Therefore, in the proposed rule, we stated that it would make sense for the patient to have a larger gatekeeping role for the Payer-to-Payer API.

Comment: Many commenters expressed support for the proposed policy to require patients to opt into the Payer-to-Payer API. Commenters provided various rationales for their support. Multiple commenters stated that the opt in approach would give patients greater access to and control over their information. Other commenters appreciated that the opt in approach protects patient privacy. Some commenters noted that the opt in approach would be easy for a payer to implement when a patient is a new beneficiary or enrollee because the payer's relationship with the patient is new and active and the payer can request a patient's opt in at the same time as the payer requests the patient's previous/concurrent payer information. A commenter noted that the Payer-to-Payer API is particularly well suited for an opt in approach because it is usually a one-time or time limited exchange (unless concurrent payers are involved).

Response: We appreciate commenters feedback in support of an opt in policy and are finalizing this policy as proposed.

Comment: Some commenters voiced concerns about an opt in approach. Multiple commenters expressed concern that an opt in approach will result in lower rates of patient participation in the payer to payer data exchange. Multiple commenters recommended that CMS adopt an opt out approach for the Payer-to-Payer API instead of an opt in approach. Primarily, commenters agreed that an opt out framework would lead to more patient participation and more data available for the new payer, any new network providers, and patients themselves. A commenter was concerned that patients may be confused by the opt in process and recommended providing clear directions to patients detailing how and when patients can opt into data sharing.

Response: We agree that an opt in approach often results in fewer data exchanges than an opt out policy. However, increased data exchange is not necessarily the goal of our policy unto itself, but a process to facilitate improved care. We believe that patients, as they are the owners of their data, should have control over who has access to their data, especially when the two parties exchanging patient data do not have a direct relationship with each other, as in the case with payer to payer exchange versus the Provider Access API where the payer and provider have a network contract. However, we know that the more data available, the more informed decisions about care can be. Patients should see value in having their data exchanged between their previous/current payer(s) and their new payer. As discussed in section II.C.3.g. of this final rule, impacted payers will be required to provide plain language information to patients informing them of the benefits of payer to payer data exchange and directions for opting in.

Comment: A commenter recommended that CMS better explain the length of time that an opt in election is valid.

Response: The patient's opt in election is valid indefinitely with that payer unless the patient decides to withdraw their permission at a later time.

Comment: Multiple commenters requested clarification on the implications of a patient choosing not to opt into the data exchange via the Payer-to-Payer API. Specifically, a commenter agreed that the information proposed for the Payer-to-Payer API can be shared only if the patient opts in, however, requested clarification on how payers could meet obligations to exchange these patients' data for other purposes.

Response: Patients have a choice about whether they want their data shared under this policy as they transition between payers. If a patient chooses not to opt into the data sharing, data will not be exchanged between payers under the requirements in this final rule. However, payers may exchange information without a patient's authorization for other purposes, such as benefit coordination in the case of concurrent payers, or for other permissible reasons under the HIPAA Privacy Rule. There is nothing in this rule that would prohibit payers from using the Payer-to-Payer API as the mechanism for data exchange permissible under other authority, even if the patient has not opted into the payer to payer data exchange policy in this final rule.

Comment: Multiple commenters submitted responses relating the Payer-to-Payer API data exchange to the HIPAA Privacy Rule exception for TPO disclosures, which do not require patient authorization. Some commenters stated that the information CMS proposed to require be made available falls under the scope of that exception and therefore opt in should not be required. Other commenters believe that some of the data (such as prior authorization information) would fall under that exception, but other data (such as claims information) would not. A few commenters suggested that CMS should reduce the scope of the data exchange to allow disclosure under the TPO exception. Furthermore, commenters stated that it may confuse and upset patients who have opted out of sharing their data via the Payer-to-Payer API, but whose PHI may otherwise be disclosed under the HIPAA Privacy Rule.

Response: We emphasize that our final requirements are not intended to change any existing obligations under the HIPAA Privacy, Security, and Breach Notification regulations, the regulations under 42 CFR part 2, or state privacy or other laws, but can and should be implemented in accordance with those rules. To make a blanket determination that the Payer-to-Payer API exchange that we are requiring always constitutes a TPO disclosure would go beyond the scope of this rule and could overstate and conflict with existing HIPAA Privacy Rule requirements and guidance. Making such a determination could have unintended effects on covered entities' ability to disclose PHI. Instead, for the reasons explained previously, it is appropriate to require patients to opt in for payer to payer data exchange. Our payer to payer data exchange requirements are disclosures permitted under the HIPAA Privacy Rule as “uses or disclosures that are required by law,” as defined at 45 CFR 164.103, rather than as a permitted TPO disclosure. “Required by law” disclosures are limited to the relevant requirements of such law, not to the HIPAA minimum necessary standard, thereby ensuring that all content required by our Payer-to-Payer API policy may be disclosed. In addition, the data exchange must not be prohibited by other law, such as restrictions on patient records related to substance use disorder at 42 CFR part 2 or state privacy laws.

We emphasize that the opt in process described here applies only to the payer to payer data exchange in this final rule. That is, it applies only to the requirement for impacted payers to share individual claims and encounter data (excluding provider remittances and cost-sharing data), all data classes and data elements included in a content standard at 45 CFR 170.213 and certain information about prior authorizations maintained by the payer with a date of service within 5 years of the request by a patient's new or concurrent payer. Similar to the discussion in section II.B.3.b.ii. regarding Provider Access API, a patient's choice not to opt into the payer to payer data exchange does not prohibit the payer from using the Payer-to-Payer API to exchange patient data under another permissible authority. For instance, there may be other permissible bases for payers to share data, without a patient's authorization, such as under the HIPAA Privacy Rule's permitted uses and disclosures to carry out treatment, payment, or health care operations. Patients do not have the ability to opt out of a payer using the API itself as a mechanism for sharing data under such bases for disclosure. We urge payers to inform their patients of this possibility in the educational resources discussed in section II.C.3.g. However, we also note that the HIPAA Privacy Rule, at 45 CFR 164.520, has specific notice requirements for covered entities to send to individuals. Payers should make clear the differences between the payer to payer data exchange, which requires patients to opt in, and other permissible disclosures, which may not require authorization.

We also note that the data that may be shared under other permissible bases, such as the TPO exception, may overlap with the data required to be shared by our Payer-to-Payer API policy. For instance, a payer may be permitted to disclose PHI to another covered entity to coordinate benefits or determine cost-sharing amounts for the covered entity's payment purposes under 45 CFR 164.506(c)(3). If that disclosure is permissible, a patient declining to opt into the payer to payer exchange policy in this final rule would not prohibit a payer from using the Payer-to-Payer API to make that disclosure. In fact, we encourage payers to leverage the Payer-to-Payer API as a standardized mode of transmitting this information. Payers may leverage a variety of solutions for exchanging coverage data today and moving to a standard-based API across the industry could benefit payers by reducing the types of connections they must maintain to communicate with other payers.

Per 45 CFR 164.506(b), covered entities may create a process to obtain consent from an individual to use or disclose PHI to carry out treatment, payment, or health care operations. Per 45 CFR 164.522(a), individuals also have the right to request restrictions on how a covered entity will use and disclose PHI about them for TPO. Except in limited circumstances, a covered entity is not required to agree to an individual's request for a restriction. Where covered entities agree to a restriction, it is bound to the restriction to which it agrees unless the restriction is subsequently terminated. We emphasize that the opt in process described in this final rule is specific to the Payer-to-Payer API policy and is therefore not, on its own, a consent mechanism per 45 CFR 164.506(b) or an agreed-upon restriction per 45 CFR 164.522(a).

These nuances are necessary for patients to understand that their personal health information may still be shared in some instances, even if they do not opt into the payer to payer data exchange. Where the requirements of this rule change how covered entities or their business associates may use or disclose PHI, covered entities should consider their obligations under the HIPAA Privacy Rule.

Comment: A commenter recommended that CMS assist states with implementing opt in processes. Another commenter explained that the feasibility of an opt in approach depends on how it would be implemented. A different commenter recommended that CMS to work with stakeholders to develop a standard approach for how an opt in requirement will work when the patient is not the primary insurance holder, noting that a standard approach is necessary to reduce confusion and ensure that patient information is protected.

Response: We agree that the feasibility of an opt in approach depends on how it is implemented, which is why we are leaving the actual implementation process up to the payers. We expect that payers will implement the most viable processes for themselves. Each of our policies in this final rule is targeted toward individual patients, not any family members that may be covered through the same benefits. We note that in some cases, applicable law may allow one individual (such as a parent or guardian) to act as a personal representative for another individual covered under the same benefits (such as a minor) and could therefore opt into the payer to payer data exchange for that individual. Regardless, the opt in is patient-specific and a payer must make the data request based on the individual's permission and the previous/concurrent payer should respond in kind with the individual patient's record. No data should be shared about any patient that has not opted in (or whose personal representative has not opted in), regardless of whether another patient covered under the same benefits has opted in.

Comment: Multiple commenters weighed in on whether patients' opt in should be collected electronically and specifically recommended that payers collect the opt in via a patient portal or mobile device. A commenter explained that payers do not have the means to collect patients' opt in via multiple methods. A different commenter noted that payers should collect opt in data electronically. Another commenter stated that patients should not be required to use a patient portal or mobile device app to opt into data sharing. A commenter also requested guidance on how to collect permission from patients who require assistance enrolling or registering for the patient portal. Another commenter noted the importance of equitable access to patient data and highlighted the current usage of patient portals as a method to authenticate patients' identities and obtain their opt in permission. They recommended a centralized identity service for patient authentication, verification, or consent for patients who cannot, or prefer not to, access the patient portals. A commenter recommended that CMS provide a centralized security verification through CMS. The commenter noted that a centralized security certification validation would relieve burden on payers to manage connectivity with other payers and provide assurances around self-signed certificates.

Response: We are finalizing that all impacted payers must develop and maintain processes to identify a patient's previous/concurrent payer(s) and to allow patients or their personal representatives to opt into the payer to payer data exchange (both with previous and concurrent payers) no later than 1 week after the start of coverage. As finalized in this rule, each new payer will be responsible for gathering permission through an opt in process before requesting data from any previous or concurrent payer. If payers believe that a patient portal or mobile smart device with appropriate security protections is the best way to gather opt in, it is permissible to use those methods. We are not being prescriptive about the process or procedures used by impacted payers for the required opt in process. However, we strongly recommend that there be a way for patients to record their permission telephonically or otherwise if they do not have internet access or do not want to sign up for an electronic portal. We agree that equitable access to patient data is of the utmost importance and emphasize that the Payer-to-Payer API requirements are intended to allow for other solutions besides patient portals for authentication, verification, or consent. For those patients who require assistance, a personal representative would be allowed to assist. However, we do note that 45 CFR part 92 requires impacted payers (as health programs or activities under that section) to provide meaningful access to individuals with limited English proficiency and accessibility requirements for individuals with disabilities. The requirements of that part apply to impacted payers, as described at 45 CFR 92.3.

We also are working closely with ONC on how the Individual Access Services exchange under TEFCA could support patient access to their data on the network, which could include via payer APIs. We appreciate the suggestion of a centralized security process and will consider our authority in this area.

Comment: Multiple commenters generally supported the proposed requirement for payers to implement procedures to allow patients to withdraw permission for the payer to payer data exchange after initially opting in. Several commenters requested clarification from CMS on what action payers must take in such instances. Specifically, multiple commenters recommended that CMS explain whether payers are expected to delete data that have already been received through the Payer-to-Payer API if a patient withdraws their opt in permission after the data exchange has occurred. Another commenter recommended that CMS explain whether patients with concurrent payers will be able to withdraw their opt in permission to stop the quarterly concurrent payer data exchange.

Response: Our opt in policy is only prospective. If a patient opts in, their impacted payers would be required to exchange data via the Payer-to-Payer API, if all other requirements are met. If that patient subsequently withdraws permission, payers will not need to take any additional steps with regard to patient data that have already been received from another payer. Specifically, there is no requirement in our regulations to delete those data from their records. We acknowledge that it may not be possible in all cases to clearly delineate which entity created each part of the patient record and trying to do so would put a burden on payers without benefit to patients. Payers are permitted to identify the previous or concurrent payer as the source of data, but are not required to do so. If a patient withdraws their permission for the payer to payer data exchange after first opting in, the payer will not be permitted to request that patient's data from another payer, including a concurrent payer, unless the patient subsequently opts in again. As discussed previously, payers may exchange information for other purposes not related to the policies described herein, such as for benefit coordination in the case of concurrent payers or other permissible purposes under the HIPAA Privacy Rule, and may still use the Payer-to-Payer API as the mechanism to exchange data for those purposes, even if a patient has not opted in.

Comment: Multiple commenters made recommendations related to CMS monitoring and oversight of the opt in approach. A commenter suggested that CMS conduct oversight to ensure that payers implement the opt in process and provide appropriate messaging to patients. A commenter recommended that CMS require payers to submit data on the number of patients who opted into the data exchange and how they were educated to do so. The commenter stated that this would help CMS understand if the API is meeting its intended goals. Another commenter recommended that CMS consider including Payer-to-Payer API claims in the Healthcare Effectiveness Data and Information Set (HEDIS) measure. Another commenter recommended that CMS monitor the percentage of patients that do not opt into these data exchanges via the Payer-to-Payer API and assess whether those patients are concentrated in certain populations and whether there are equity issues that CMS should address in the future.

Response: We did not propose to require impacted payers to report any metrics regarding the number of patients who opt into data sharing, but we appreciate the recommendation and will consider it for future rulemaking. We note that the specifications of HEDIS measures are out of scope for this rule. We received comments on many of our proposals about the need for specific compliance and enforcement efforts pertaining to each API and we address these comments in section I.D. of this final rule. Oversight and compliance procedures and processes vary among these CMS programs and may have different implications based on a payer's status in the program, previous compliance actions, and corrective action plans.

Comment: Multiple commenters supported our proposal to require state Medicaid and CHIP programs to collect patients' permission for payer to payer data exchange in lieu of their contracted managed care plans and managed care entities. Commenters stated that Medicaid and CHIP agencies are in the best position to collect information from all beneficiaries during eligibility and enrollment. However, commenters warned that if sister agencies within the state perform eligibility and enrollment processes, there would be additional coordination required to collect patients' permission.

Response: We agree with commenters that state Medicaid and CHIP agencies are the logical entity to hold Medicaid and CHIP beneficiaries' permission for payer to payer data exchange. We note that MCOs, PIHPs, and PAHPs are still responsible for collecting previous/concurrent payer information and requesting the data exchange. However, nothing in this rule would prevent a Medicaid or CHIP agency from collecting that information and passing it along to their MCOs. We also acknowledge the specific difficulties that states may face to implement the requirements of this rule and refer readers to section II.E. of this final rule for discussion about available extensions and Federal funding for IT expenditures related to these requirements.

d. Requesting Data Exchange From a Patient's Previous/Concurrent Payer(s) and Responding to Such a Request

i. Timeframe for Requesting Data

We proposed to require impacted payers to request a patient's data from their previous/concurrent payer(s) no later than 1 week after the start of coverage, as defined previously. We stated that 1 week should be sufficient time for payers to complete their process for identifying patients' previous/concurrent coverage and to request data from the other payer(s). We proposed that if, after the start of coverage, a patient opts into the data exchange or provides previous/concurrent payer information or requests a payer to payer data exchange for another reason, then the current payer would be required to request data from the previous/concurrent payer(s) no later than 1 week after the payer received the previous/concurrent payer information and the patient has opted in, or the patient makes the request. We acknowledge that the obligation to request data is contingent on the patient supplying the necessary information about a previous/concurrent payer to enable the new payer to conduct the required exchange. An impacted payer cannot comply with these requirements if the patient has not provided timely or accurate information about their previous/concurrent payer. In that case, payers are required to make reasonable efforts to gather this information from patients. For example, we recommend payers follow-up one time before determining that the patient has not opted in. We are finalizing a modification to the proposed regulatory text to clearly establish that the 1-week timeframe for requesting patient data begins when the impacted payer has sufficient identifying information about previous/concurrent payers and the patient has opted in.

Comment: Many commenters supported our proposal to require impacted payers to request data from a patient's previous payer no later than 1 week after the start of coverage or obtaining previous/concurrent payer information and opt in permission from the patient. Other commenters suggested a variety of alternative timeframes for payers to request patient data from previous/concurrent payers. A few commenters recommended that CMS allow 2 weeks after the start of coverage to request the data. Other commenters recommended that CMS extend the timeframe for a data exchange to be within 30 or 90 days after enrollment to allow payers time to confirm the patient's information, especially during peak volumes such as open enrollment. A commenter highlighted that a 90-day timeframe would allow time for the previous payer to process outstanding claims. Conversely, other commenters recommended a 3-day timeframe for a new payer to request the patient's data from their previous payer to expediate the data exchange.

Response: We continue to believe that 1 week is the appropriate period to require payers to make a request for patient data after they have sufficient identifying information about the previous/concurrent payer and the patient has opted in. The longer the period between the time a patient enrolls with a new payer and that payer receives patient data, the less relevant those data could be. This is particularly true for patients who have chronic conditions or ongoing treatment for life-threatening conditions. For these patients, it is more important that their new payer get information as soon as possible. If necessary, additional information can be exchanged as it becomes available. See our discussion in section II.C.3.d.i. of this final rule regarding optional additional data exchanges between previous and new payers. For instance, the CY 2024 MA and Part D final rule requires MA coordinated care plans to provide a minimum 90-day transition period when an enrollee switches to a new MA plan. During that time, the new MA organization may not require prior authorization for an active course of treatment. Establishing a 90-day timeline for payer to payer exchange could largely negate the utility of the data to comply with that requirement. Even a shorter period, such as 2 weeks or 30 days, could require patients to provide separate information about active courses of treatment, which would add burden to patients rather than reducing it. Regardless of whether impacted payers are subject to that rule, it is important to exchange data quickly so that patients can maintain a continuity of care.

However, we also determined that our proposed data request deadline was no longer feasible with the modified deadline for requesting previous/concurrent payer information and the patient's opt in to be no later than 1 week after the start of coverage. Therefore, we are also finalizing a modification to our proposal to require impacted payers to request data from a patient's previous/concurrent payer(s) no later than 1 week after the payer has sufficient identifying information and the patient has opted in, or within 1 week of a patient's request. We encourage payers to request these data as expeditiously as possible. Specifically in regard to periods of peak volume for payers, we encourage payers to use the Bulk Data Access IG to send bulk requests and responses for multiple patients at once. As discussed in section II.G. of this final rule, we are finalizing our proposal to require payers to implement the Bulk Data Access IG for the Payer-to-Payer API for this very purpose.

Comment: Multiple commenters suggested that CMS explain the meaning of within 1 week of the start of coverage. A commenter highlighted how Medicaid policy requires that they grant eligibility retroactively up to 3 months and recommended that the data request within 1 week of the start of coverage be based on the date that the eligibility update is received into their MMIS, not the effective date of coverage, which could be 3 months prior. Another commenter recommended that only QHP policies that have been effectuated with a binder payment be subject to the payer to payer data transfer requirement, which should leave 1 week after the date that benefits begin for the new payer to request the data transfer.

Response: As noted previously, we are changing the deadlines for payers to request information from other payers by tying them more closely to the date when the payer has sufficient information about a patient's previous and concurrent payers and the patient has opted in. As such, the data request deadline is no longer linked to the start of coverage or enrollment. Further, as explained previously, the term “start of coverage,” as used in the preamble to this rule, means when coverage begins or when the patient enrolls, as applicable. For cases when there may be retroactive coverage, such as in Medicaid, the payer will be required to seek a patient's opt in for Payer-to-Payer API data exchange and to request information about a new patient's previous/concurrent payer(s) no later than 1 week after the patient's enrollment. In Medicaid, the patient's “enrollment” is the date the beneficiary is enrolled in the state's MMIS (or equivalent process), not the date that coverage takes retroactive effect. For that reason, the regulation text in Medicaid FFS reflects this by referring to “enrollment” instead of “start of coverage.”

Comment: Multiple commenters requested clarification that timing requirements are flexible to the extent reasonable and necessary to verify that privacy and security requirements are met. A commenter emphasized that this timeframe could only be followed if it begins after the member has provided sufficient information as determined by the impacted payer to identify a concurrent payer (for example, payer name, member enrollment number, group number).

Response: We agree that the timeframe for sending a request only begins when a payer has sufficient information to send a request to another payer and the patient whose data are being requested has opted in. We are finalizing that the request must be made no later than 1 week after the payer has sufficient identifying information and the patient has opted in. We note that, as discussed previously, payers have an obligation to request that information from their patients no later than 1 week after the start of coverage, as that term is defined previously specific to each impacted payer type.

Comment: A commenter suggested that if payer endpoints are not publicly available or accurate information on a previous payer is not available, payers should only be required to make reasonable efforts to complete the data exchange.

Response: Existing requirements require payers to make technical documentation about their API, including digital endpoint information, on a publicly accessible section of their website. In section I.D. of this rule we discuss an NDH that could serve as a centralized place for impacted payers to find other payers' digital endpoints. Commenters indicated that such a directory would significantly improve the process for requesting patient data.

Payers are required to request patient information from previous and concurrent payers if the conditions in the rule are met, and we encourage payers to make a reasonable effort to locate information about a patient's previous payer. If a payer is unable to obtain a valid endpoint or accurate information for a previous or concurrent payer, we recommend they document the efforts they took to gather the information from the other payer. Doing so could establish a record for future oversight, or in case of a dispute, that the payer made a reasonable effort to comply with the requirements of this rule and the patient's desire for their data to be exchanged. As discussed, payers are not responsible for determining whether the patient's previous payer is an impacted payer, but are required to request previous/concurrent payer information from the patient and to make the data request to the other payer. We encourage payers that are not subject to the requirements in this rule to participate in the Payer-to-Payer API exchange in order to allow their patients to benefit from this policy. However, a payer not subject to this regulation may not have a FHIR API or want to exchange the required information, which would be outside of the impacted payer's control.

Comment: Multiple commenters flagged that impacted payers will need time to establish the necessary technology linkages, data use agreements, and security protocols to exchange information with another payer in a manner compliant with the HIPAA standard transaction and code set requirements. A commenter noted that the data exchange would take longer than 1 week if a payer needs to set up a new connection, as feeds may differ.

Response: We understand that a functional technological connection with other payers to meet the requirements for the Payer-to-Payer API policy can and sometimes will take more than a week to complete. However, there is no applicable HIPAA standard transaction or code set for the payer to payer data exchange we are finalizing in this final rule. The required standards are those being established in this final rule. Giving impacted payers sufficient time to coordinate with other payers to establish the capability to exchange data is one rationale for delaying the compliance dates from the proposed 2026 to 2027. We expect that payers will use that additional time not only to build the requisite API technology, but to coordinate with other payers to establish those linkages. We encourage payers to establish connections and perform testing with other payers before the compliance dates for the Payer-to-Payer API to ensure that the data exchange will work as expected. Payers should also set up a testing or sandbox instance of their Payer-to-Payer API as early as possible for other payers to test against. We also encourage payers to establish data use agreements and register with each other's APIs prior to the compliance dates in order to facilitate exchange as quickly as possible after the compliance dates. We expect that those technological and legal requirements will be most burdensome when one payer connects with another for the first time. Subsequent exchanges should rely on that same foundation, and it should not be necessary to repeat those steps. Finally, we suggest payers prioritize other payers that they are most likely to exchange with, such as those that overlap with their geographical coverage area.

ii. Additional Data Exchange

In the proposed rule, we solicited comments on whether additional data exchanges would be warranted to account for data received or processed by the previous payer after the patient's coverage ends and, if so, what the appropriate parameters would be. Outside the context of concurrent payers, we generally expect our policy to require a one-time data exchange between a previous and new payer. Once the new payer has received the patient's data from the previous payer, we do not generally expect there to be additional exchanges with the previous payer. However, we want to allow patients to request subsequent data exchanges to account for any outlier situations. We are also aware that claims take time to process and may be processed after patients have enrolled with a new payer, thus creating additional data within the patient's record for some time period after the patient has changed payers. We considered proposing a policy where, if the patient opts in, a previous payers would be required to send any additional data within the required dataset to the new payer no later than 1 week of receiving the additional data. However, keeping in mind the burden this could impose on payers, we sought comment on such a policy. We sought comment on whether additional data could be helpful for the new payer in the weeks or months after enrollment, and which specific data could be most pertinent, or whether additional data exchange would be overly burdensome and not provide value to the new payer. We asked whether it would be appropriate to limit such a requirement to send updated data to a certain period after the initial data exchange, for instance within 30 or 90 days. Additionally, we asked whether impacted payers should be required to make an additional data exchange within a week of receiving any new data or on a set cadence, such as monthly or quarterly, to allow payers to streamline transactions for multiple patients.

Comment: We received varying comments around additional data exchanges with multiple commenters supporting a one-time additional data exchange to promote continuity of care. Some commenters thought it would not be feasible to share additional data within 1 week of each update but supported a single exchange at 30-, 60- or 90-days after the patient has moved to a new payer. A commenter stated it would be difficult to track when additional data need to be sent after the initial exchange.

Response: We agree that it could be helpful for payers to supplement the data exchange required under this rule, to account for any claims or data that are received after the initial data are sent to the new payer. While we are not requiring it, we encourage payers to do so in order to pass along a complete patient record. Likewise, we encourage the new payer to send an additional request for data within 90 days of receiving the initial data response. The previous impacted payer would be required to respond to such a request.

iii. Authorization and Authentication Protocols

We proposed that impacted payers would be required to use the OpenID Connect Core authorization and authentication protocols at 45 CFR 170.215(e)(1) to authenticate the identity of the requesting payer. We wanted to ensure payers would not have to send data unless they are confident that the requesting payer is identified. The ONC Cures Act final rule adopted content and vocabulary standards to provide the foundation needed and were finalized for use in the CMS Interoperability and Prior Authorization final rule to support implementation of the policies (85 FR 25521–25522). Thus, we proposed OpenID Connect Core in effort to align standards across API implementations.

Comment: Multiple commenters sought clarification on the general authentication and authorization process and flagged that requiring OpenID Connect Core will not be sufficient for the Payer-to-Payer API. A commenter recommended that CMS consider UDAP or the PDex IG, which uses a SMART framework instead. Another commenter flagged that the OpenID Connect Core standard requires a log-in, whereas the proposal suggested that payers are required to provide these APIs without a user login or credential. A commenter highlighted that the Bulk Data Access IG requirement relies on portal credentials and user logins created by the individuals to be linked to their identity in the payer system.

Response: Upon consideration, we agree that it would not be appropriate to require OpenID Connect Core for the Payer-to-Payer API. OpenID Connect Core is a means to identify individuals and because the Payer-to-Payer API is a business-to-business interaction, OpenID Connect Core is not adequate to meet this use case. Although OpenID Connect Core can be utilized for the Payer-to-Payer API, it is not a scalable approach because it requires user credentials. For similar reasons, we are finalizing a modification to our proposal to not require OpenID Connect Core for the Provider Access, Payer-to-Payer and Prior Authorization APIs. The SMART App Launch IG can also provide a method for authentication within the Payer-to-Payer API; though we note that we are not finalizing our proposal to require that IG, it remains available to payers as an option. However, as part of the Payer-to-Payer API, payers still need to authenticate bi-directionally using industry best practices to ensure that patient data are only shared appropriately. We refer readers to Table H3 in section II.G. for an updated listed of required and recommended standards and IGs. We also advise that the Bulk Data Access IG, which is a required IG for the Payer-to-Payer API, contains a “SHOULD” (that is, strongly recommended) conformance statement to use SMART Backend Services. We also note that SMART Release 2.0.0, which has since been adopted in the HTI–1 final rule at 45 CFR 170.215(c)(2) includes SMART backend services. Though in this final rule we are requiring impacted payers to support the Bulk Data Access IG in their Provider Access and Payer-to-Payer APIs, this requirement does not obligate them to use it for every data exchange if it is not necessary.

Comment: A commenter recommended that CMS collaborate with industry stakeholders to identify best practices for user authentication and authorization with the Payer-to-Payer API. Another commenter highlighted that guidance on how to trust and verify inbound data requests via the Payer-to-Payer API will be essential.

Response: We will continue to collaborate with industry stakeholders through HL7 FHIR workgroups and through HL7 FHIR Connectathons as the standards to support the Payer-to-Payer API continue to be refined to support these final policies. We also will continue to work closely with ONC on the required authentication and authorization standards under 45 CFR 170.215. While we are not specifically requiring an IG or method be used for authentication and authorization, as part of the Payer-to-Payer API payers still need to authenticate the other payer they are exchanging data with.

iv. Attestation

We proposed to require the requesting impacted payer to include an attestation with the request for data affirming that the patient (1) is enrolled with the requesting payer and (2) has opted into the data exchange in a manner that meets the applicable legal requirements. As explained in section II.G. of this final rule, we recommended certain HL7 FHIR IGs to support the data exchange between payers. The recommended PDex IG has been developed to include both the technical and business processes of capturing and sharing a patient's permission for data exchange with the payer to payer data request. Because that IG is recommended and not required, impacted payers could also exchange an attestation regarding patient permission with other implementations, which could meet or exceed the requirements of the PDex IG.

Comment: Multiple commenters supported the attestation proposals for the Payer-to-Payer API. Multiple commenters provided recommendations for processes to share patients' data sharing permission. Multiple commenters suggested processes for payers to verify that a patient opted into data sharing with another payer before giving that payer access to patient data. A commenter requested clarification on whether patients must opt in for each subsequent payer. A commenter recommended that patients' data sharing permission be shared with secondary and tertiary payers. Commenters requested clarification on which payer (the requestor or requestee) is responsible for obtaining patients' permission. A commenter highlighted that an attestation process will not resolve the risks of incorrectly matching data to the patient. Another commenter asked whether FHIR can be used to send the attestation. Another commenter requested clarification on using standards and IGs to facilitate the opt in process. A commenter sought guidance on where a patient's opt in would be indicated on the electronic transmission and how they could verify that the payer provided educational information to the patient.

Response: We appreciate the recommendations for sharing a patient's opt in but leave that exact process up to payers. The impacted payer requesting the data from the previous/concurrent payer is responsible for obtaining the patient's opt in and must include an attestation with that request for data affirming that the patient (1) is enrolled with the requesting payer and (2) has opted into the data exchange in a manner that meets the necessary legal requirements. Patients would have to opt in for each subsequent payer to request their data from a previous/concurrent payer. The purpose of the attestation is not to match the data to the patient, but to affirm that the patient has enrolled with the requesting payer and has opted into the data exchange in a manner that meets the necessary legal requirements. We highly recommend using the IGs discussed in further detail in section II.G. of this final rule to support the Payer-to-Payer API. The latest published version of the PDex IG (STU 2.0.0) includes a means for a payer to communicate that the member has opted in—through a FHIR Consent resource—when requesting data from another payer. An attestation or verification that the requesting payer provided educational information to the patient is not required to be sent with the request.

Comment: A commenter recommended that CMS more clearly explain the Payer-to-Payer API process to ensure that prospective or potential payers are not requesting a patient's data. Another commenter suggested that an attestation from another payer is not sufficient proof to demonstrate a patient's decision to opt in and suggested that some assignment of legal liability be considered for the requesting payer, as it might assuage these concerns.

Response: A prospective or potential payer should not request a patient's data under this rule. Under this rule, a payer must attest that the patient is enrolled with that payer as part of its request for the patient's data from a previous/concurrent payer. We emphasize that the impacted payers must implement an authentication process (discussed previously) that verifies the requesting payer's identity as a legitimate health care coverage entity. If an entity includes a fraudulent attestation that the patient is enrolled with the payer and has opted in to payer to payer data exchange in its request for patient data, that entity could be subject to criminal or civil penalties.

v. Timeframe for Responding to a Request

We proposed that impacted payers that are previous/concurrent payers would be required to respond to a current payer's request, if specified conditions are met, within 1 business day of receiving the request. We explained that 1 business day would be the appropriate timeframe to complete this process to send the data, as new payers need timely access to previous/concurrent payer data to facilitate care coordination and make the information available to providers within their new network. We noted that this timeframe also would align with the 1 business day response time for the Patient Access and Provider Access APIs.

We sought comment on whether the proposed timeframes for the previous/concurrent payer to send these data, are appropriate or whether other timeframes would better balance the benefits and burdens. We sought comment on whether payers need more than 1 business day to respond to a request and sought comments on what might be a more appropriate timeframe if commenters thought a different timeframe was warranted. We explained that it is important for patient data to move to the new payer as soon as possible to send their patient record and to ensure care continuity.

Comment: Multiple commenters expressed support for the 1 business day response time for the Payer-to-Payer API. A commenter recommended a modification that data should be available within 1 calendar day. Another commenter stated that the purpose of standardized API data exchange is to have real-time data availability. A commenter requested that CMS provide at least 24 hours for data from the Prior Authorization API to be available via the Payer-to-Payer API. Some commenters expressed general concern with our proposed response timeframe and suggested that payers may become overwhelmed, especially during open enrollment periods. A commenter expressed concern that the proposed timeframe does not consider the degree of manual effort required to ensure compliance with applicable state laws and regulations regarding health privacy and confidentiality. Multiple commenters recommended that CMS require a response time of 2 business days for the Payer-to-Payer API and another suggested 3 business days.

Response: After reviewing the comments, we believe that keeping the response timeframe at 1 business day is appropriate. This expedient data exchange will support care continuity and still allow time for the processes for payers to appropriately send patient data. We note that this timeframe also aligns with the finalized 1 business day response time for the Patient Access and Provider Access APIs. We acknowledge that some periods may have increased data exchange requests, such as during open enrollment period, and note that the purpose of the required Bulk Data Access IG is to efficiently exchange large volumes of data for multiple individuals and can be utilized for both requesting and sending data.

The data content we are finalizing that must be included in the payer to payer data exchange is generally the same as the current requirements for the Patient Access API, notwithstanding the addition of prior authorization information. Claims and encounter data and all data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI) are structured data, which will help payers identify particular items that are subject to additional privacy requirements. We are also finalizing 2027 compliance dates, in part, to give payers additional time to develop internal processes and train staff. That includes processes make the necessary determinations as to which data are permitted to be shared via the Payer-to-Payer API. For instance, payers may use this time to develop processes that flag certain data elements with metadata—as the payer receives them—if they require special permissions or are prohibited to disclose under other law. We highly encourage payers to engage in this process as they receive data to ease any manual review and decision-making that might be necessary when a payer requests patient data.

Comment: A commenter recommended that CMS address the need for a legal governance framework for the payer to payer data exchange because the technical standards proposed would not enable the requesting payer to substantiate the patient's authorization. The commenter stated the need to provide legal assurances that the payer requesting a patient's records has obtained appropriate authorization to request the records and without a standardized governance framework, payers would struggle to fulfill the requirement to respond within 1 business day of receiving a request.

Response: We understand the importance of legal assurance between payers to ensure the patient has provided appropriate authorization before sharing data across payers. The recommended PDex IG STU 2.0.0, which has since been published since the publication of the CMS Interoperability and Prior Authorization proposed rule, includes both the technical and business processes to capture and share a patient's permission as part of the payer to payer data request. We believe 1 business day is sufficient to fulfill the request for data exchange because the IG is a means for payers to electronically send a record of the patient's permission to receive data from the other payer. We are also working closely with ONC as to how TEFCA could support scalable governance for payer to payer data exchange. We reiterate that we are requiring that the new payer provide an attestation with the request for data affirming that the patient has enrolled with that requesting payer and has opted into the data exchange.

vi. Payers Not Subject to This Regulation

If a previous/concurrent payer is not an impacted payer, they are not subject to our final requirements and, therefore, are not required to send or request data through the Payer-to-Payer API. For example, an employer-based commercial plan would not be subject to this rulemaking. If the previous/concurrent payer is not an impacted payer, they are not subject to our requirements to respond to the request. A new or concurrent impacted payer is not obligated to determine whether the previous/concurrent payer is an impacted payer under this final rule or to limit its requests for a patient's data (or its responses to requests for a patient's data) to only impacted payers. Therefore, we proposed that an impacted new payer would be required to request the data from the patient's previous/concurrent payer, regardless of whether the other payer is an impacted payer. Conversely, we proposed that if an impacted payer receives a request for patient data that meets the requirements of this rule, they would be required to respond by making available the required data through their Payer-to-Payer API, regardless of whether the requesting payer is an impacted payer (which the payer may or may not know).

If a payer not subject to this regulation does not have the capability or refuses to exchange the required data with an impacted payer or is willing to exchange the data but is unable or unwilling to do so through a FHIR API, the impacted payer will not be required to exchange data with that payer. Payers that have not implemented the Payer-to-Payer API would not have accessible digital endpoints to make the required request. We emphasized in the proposed rule that impacted payers would not need to spend resources determining whether other payers are subject to this rulemaking, but would be required to request patient data, if possible, and respond to all requests that are made within the requirements. However, we encourage all payers to implement a Payer-to-Payer API to support data exchange with other payers, even if they are not subject to our final requirements to support care coordination and more efficient operations.

Comment: Multiple commenters flagged concerns regarding interoperability with payers not subject to this regulation. A commenter stated that it is unclear what value would be derived from the investment if there is no response or reciprocation from payers not subject to this regulation. Another commenter noted that payers need to build a connectivity system with other payers, including payers not subject to this regulation.

Response: We disagree that the burden of connecting with a payer not subject to this regulation that has implemented a Payer-to-Payer API in conformance with our requirements is any different than connecting with an impacted payer. Regardless of whether they are covered by an impacted payer, there is value in maintaining a patient's data and exchanging those data when a patient transitions to a new payer or between concurrent payers. Furthermore, requiring impacted payers to exchange data only with other impacted payers would require impacted payers to expend effort to determine whether the other payer is an impacted payer. That effort can be eliminated by simply treating any payer as a possible exchange partner. Furthermore, not requiring impacted payers to exchange data with payers not subject to this regulation would mean that there would be no incentive for those payers to adopt the requirements of payer to payer data exchange. In addition, impacted payers are not required to exchange data outside of the process finalized in this final rule, including using a standards-based API. If a payer not subject to this regulation requests data in a format that is not compatible with the Payer-to-Payer API and specific data formatting, content and vocabulary standards established in regulation, impacted payers will not be required to send data via a different method, unless other law requires them to do so.

We understand that impacted payers may have additional difficulty ascertaining that another payer is not subject to this regulation (or not compliant), as that payer would not have digital endpoints to discover. Payers are required to take reasonable steps to determine whether they can exchange data with the other payer. We encourage payers to contact the previous payer directly to determine whether they support the Payer-to-Payer API. Other solutions could also be explored to help payers determine whether the previous payer supports the Payer-to-Payer API, such as using TEFCA. In section I.D. of this final rule we discuss an NDH that could serve as a centralized place for payers to find other payers' digital endpoints and identify payers that support the Payer-to-Payer API. Once a payer knows that another payer is not capable of payer to payer data exchange, they would not be required to inquire every time they receive a new patient who identifies that previous payer. However, it would be prudent to occasionally (such as annually) check whether the other payer has implemented a Payer-to-Payer API and is now capable of data exchange.

e. Ongoing Data Exchange Requirements for Concurrent Coverage

i. Concurrent Coverage Data Exchange

For individuals who have concurrent coverage with multiple payers, we proposed to require impacted payers to collect identifying information about any concurrent payer(s) from patients before the start of coverage with the impacted payer (consistent with how “start of coverage” is explained previously). Because we believed it would be beneficial for all of a patient's current payers to maintain a complete record of the care that the patient has received, we proposed to require impacted payers to request the same patient data described in section II.C.3.b. of this final rule from all of a patient's concurrent payers, and to send those data in response to a request that meets all the requirements of this final rule. We stated that this would ensure that the patient's concurrent impacted payers maintain a complete patient record and can provide all the information proposed to be required under the Patient Access and Provider Access APIs.

Specifically, we proposed to require impacted payers, no later than 1 week after the start of a patient's coverage, to request data from any concurrent payers that the patient reports. Because all payers will update patient records while a patient is enrolled with those payers, we proposed that when a patient has concurrent coverage with two or more payers, the impacted payers would be required to exchange with every other concurrent payer, at least quarterly. We proposed that should an impacted payer receive a request for a current patient's data from a concurrent payer for that patient, the receiving payer would have to respond with the appropriate data within 1 business day of receiving the request. Operationally, this proposed exchange would function the same as the data exchange with a patient's previous payer.

We also proposed that any impacted payer that receives patient data from another payer under these regulations must incorporate those data into the recipient payer's records about the patient. The required data content we proposed are the same claims and encounter data (excluding provider remittances and cost-sharing information), all data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI), and certain information about prior authorizations that the payer maintains with a date of service on or after January 1, 2016. We stated that that proposal would require impacted payers to both request patients' data from other concurrent payers and to respond to requests from other payers to share patients' data.

Comment: A commenter recommended that we only require concurrent payers making quarterly data transmissions to send data that have been updated since the last data exchange. The commenter stated that this would reduce burden by allowing them to exchange a smaller set of data that can more easily be integrated into their patient records.

Response: We agree that this is a reasonable solution to reduce burden. We are finalizing a modification to our proposal to allow concurrent payers to agree to exclude from ongoing quarterly data exchange any data that were previously transferred to or originally received from the other concurrent payer. We leave it to payers to determine the best process to effectuate this option, as it is intended to reduce payer burden. If exchanging only new data would increase burden on payers versus exchanging all patient data, they are not required to do so. Ultimately, the exchange should result in both concurrent payers having a complete set of patient data to support patient care and care coordination.

Comment: A commenter suggested that CMS require payers to clearly document, in the payer systems, which payer is primary, and which is secondary to ensure providers receive accurate and timely coordination of benefit information.

Response: Coordination of benefits is an established process (though the exact process may vary by payer and jurisdiction) that we specifically did not propose to affect. As discussed previously, if payers find it beneficial to use the Payer-to-Payer API for purposes other than the data exchange finalized in this rule, such as coordinating coverage, they are welcome to do so. To the extent that such coordination information would benefit patients or providers by being available via the Patient Access and Provider Access APIs, we encourage payers to do so.

Comment: Several commenters expressed opinions on the appropriate timeframe for payers to request data from another concurrent payer and for payers to respond to such a request. Multiple commenters stated their general support for timely information exchange between concurrent payers to help minimize unnecessary administrative paperwork and other inefficiencies. Several commenters supported our proposed timeframes. Other commenters suggested that payers have up to 30 days to request patient information. A commenter stated that the data should be available within 1 calendar day instead of 1 business day. A commenter recommended CMS allow at least 3–5 business days for a response.

Response: There should be no procedural or technical difference between requesting data from a previous payer or a concurrent payer, other than the requirement that concurrent payers engage in ongoing quarterly exchange. Similarly, responding to such a request should be the same process, using the same FHIR standards. Therefore, we believe it is prudent to establish the same timeframes for the initial requests to and all responses from concurrent payers as for previous payers. Therefore, we are finalizing that for concurrent payers, the initial request for data must be made no later than 1 week after the payer has sufficient identifying information about concurrent payers and the patient has opted in and quarterly thereafter. We are finalizing our proposal that impacted payers must respond within 1 business day to a request for patient data from a concurrent payer that meets all the requirements of this final rule.

ii. Concurrent Payer Exchange Timeframe

We also considered whether to propose more frequent exchanges (weekly or monthly), or less frequent exchanges (semi-annually or annually) for the required data exchanges between concurrent payers; however, we explained in the proposed rule that we believed a quarterly data exchange would strike the right balance between providing accurate, timely data and payer burden. We believed that sharing data quarterly would be frequent enough to allow new health data to accumulate and still be timely, but not so frequent that it causes unnecessary burden on the payers. We requested comment on this proposal, including on the appropriate frequency for this payer to payer exchange for patients with concurrent coverage.

Comment: A significant majority of commenters supported our proposal to require quarterly data exchange between concurrent payers because it would facilitate care coordination. Some commenters suggested that a more frequent data exchange could benefit patients. Some commenters noted that even quarterly data exchange may miss key clinical events that would be useful for care coordination and recommended that the data exchange should take place monthly. On the other hand, a few commenters stated that impacted payers should only request additional data from concurrent payers when initiated by a member.

Response: We agree with the majority of commenters that a quarterly cadence appropriately balances the benefits and burdens on payers. Payers may make arrangements with each other to exchange information more frequently, if they believe it would benefit their mutual patients. The burden of initiating the exchange should not fall on the patient, especially at times when they are dealing with specific health issues that would most benefit from care coordination. As some commenters recommended more frequent data exchange, we will consider whether to propose amendments to this policy in future rulemaking after the industry has experience meeting the requirements of this final rule.

We note that when a patient has concurrent coverage, the payers must communicate regularly to ensure that the proper payer is responsible for that patient's claims. Nothing in this final rule, including a patient not opting into the Payer-to-Payer API data exchange, is intended to alter payers' ability to exchange data as they do today for that purpose, in accordance with applicable law.

f. Data Incorporation and Maintenance

i. Data Incorporation

We proposed that data received by an impacted payer through this data exchange must be incorporated into the patient's record with the new payer. We stated that those data could then be part of the patient's record maintained by the new payer and should be included as appropriate in the data available through the Patient Access, Provider Access, and Payer-to-Payer APIs. In this way, a patient's data could follow them between payers and be available to them and their providers. We stated that this proposal would not obligate payers to review, utilize, update, validate, or correct data received from another payer, but we encouraged impacted payers to do so, at least to the extent it might benefit the patient's ongoing care. We explained that payers could choose to indicate which data were received from a previous payer so a payer, provider, or the patient looking at the record, would know where to direct questions (such as how to address contradictory or inaccurate information), but would not be required to do. Regardless, all data received, maintained, used, or shared via the proposed Payer-to-Payer API would be required to be received, maintained, used, or shared in a way that is consistent with all applicable laws and regulations.

Comment: Multiple commenters supported our proposal to require payers to incorporate data they receive from other payers via the Payer-to-Payer API into their own patient records in order to ensure that a patient's record is not lost. Other commenters stated that they do not believe that payers are the appropriate holders of a patient's full medical record and that providers or patients themselves should be the maintainers of those data.

Response: We agree that in some cases a payer is not the best entity to hold a patient's longitudinal record and that there is other technology available for patients to download their data, for example, using the Patient Access API, and to store it independently of their payer. As discussed previously, we are finalizing a policy that limits the payer to payer data exchange to data with a date of service within 5 years of the request. After considering public comments, we determined that a 5-year period balances the benefits of new payers having access to recent patient data and the patient not losing recent information against the burden of integrating and maintaining historical data that may or may not be useful to care.

For patients who want to maintain their own information in a PHR, they have that option through the Patient Access API. While in some cases, a patient may have a provider that can and will aggregate their records from each other provider that the patient sees, we do not believe this is a common scenario, as it would require a significant amount of work by the provider. As discussed, because payers receive claims or encounter data from each provider that sees a patient, they typically possess the most complete historical patient record. Requiring a payer to send a patient's data to their new payer will ensure that recent information that could be important for care continuity is not lost.

Comment: A commenter cautioned that CMS should not assume that the information received from a previous payer is whole and/or correct. The commenter noted that the difference in health plans' level of diligence could cause some discrepancies in patient coverage. Another commenter suggested that payers would be incentivized to send incorrect information to another payer rather than correcting the patient's record.

Response: We acknowledge that any set of patient data may have errors or omissions. However, we do not believe that the appropriate response to this issue is to discard data when a patient moves between payers. As stated, we do not wish to burden payers to proactively verify patient records when they receive them from another payer. However, under the HIPAA Privacy Rule, at 45 CFR 164.526, individuals generally have the right to have a covered entity amend PHI or a record about the individual in a designated record set for as long as the PHI is maintained in the designated record set, with certain exceptions. That right exists regardless of whether the covered entity created the PHI itself or received it from elsewhere. That requirement is consistent with our policy, as it does not require proactive verification, but must be addressed upon request by an individual.

We also do not believe that there is any risk of payers intentionally proliferating inaccurate information. There is no reason for a payer to maintain inaccurate records with the ultimate goal of passing that information to another payer when the patient leaves their coverage. Finally, payers are only responsible for maintaining their own records, including that which has been received from another payer. If there is an error to be corrected in data received from a previous payer, neither the patient nor their payer will need to contact the previous payer to correct it and have the patient's record resent. A patient's current payer is required, by the HIPAA right to amend and correct data in its records, even if that incorrect information was initially received from a previous payer.

Comment: A few commenters recommended that all the APIs should support optional provenance resources that could be added by either the sender or the receiver to indicate the source of data. A commenter recommended that instead of CMS recommending payers to note where the data originated, CMS instead propose that specific provenance resources be required to indicate which data came from a previous payer, which could also be included in subsequent data exchanges.

Response: When incorporating the data from an old or concurrent payer, payers are free to indicate the provenance of that information, which would then be included in the data available through the Patient Access or Provider Access APIs. As discussed in section II.G., we are recommending, but not requiring, the PDex IG for the Payer-to-Payer API. The PDex IG requires provenance information be included in outbound FHIR transactions and that a payer receiving such a transaction must incorporate any included provenance information. There is also a “SHOULD” recommendation within the IG that payers create provenance records when the provenance is not included in a data set (for example, when it was received through non-FHIR mechanisms). We highly recommend that payers use the IG for several reasons, including that it would help address this issue and help payers, providers, and patients understand the source of data. We will consider whether to propose to require provenance information through future rulemaking.

Comment: Multiple commenters highlighted that our Payer-to-Payer API policy would require extensive data translation and de-duplication. They suggested that CMS encourage payers to work with HIEs to determine the best solutions to avoid data duplications and associated errors. A commenter expressed concern regarding the potential for duplicate data to be transmitted throughout the health care system.

Response: We appreciate commenters' suggestions that there are existing marketplace solutions to address some of the concerns about data duplication. We understand the concern over duplicative information. There are IT solutions, such as EHR vendors and HIEs, available that can make the data actionable and help payers avoid receiving duplicative information via the Payer-to-Payer API. To the extent it would benefit payers, we encourage them to work with HIEs and HINs to facilitate payer to payer data exchange. We note that nothing in our policies prohibits a payer from using an intermediary to aid with various functions, such as patient matching, data exchange, or data hygiene.

Comment: A commenter stated that they believe data acquired via Payer-to-Payer APIs should be dated with the original date of service to prevent duplication in future Patient Access or Provider Access API requests, if a patient or provider already had that information from the previous payer.

Response: We agree that it is important to maintain the fidelity of data received via the Payer-to-Payer API. While creating additional metadata is recommended to be able to track where the data came from and when it was acquired, payers should not be changing the underlying data itself. For example, the “date of service” or “date claim processed” should not be updated to the date that the new payer receives the record of the claim from a previous payer.

Comment: A commenter stated claims are not typically considered “patient records” and suggested CMS define the “patient record” into which information from a previous/concurrent payer must be incorporated.

Response: We do not need to define “patient record” as we are defining the set of data that must be shared between payers, that is, claims and encounter data (excluding provider remittances and patient cost-sharing information), all data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI), and certain information about prior authorizations maintained by the payer with a date of service within 5 years of the request by a patient's new or concurrent payer. Furthermore, we have defined maintain in the Interoperability and Patient Access final rule “to mean the payer has access to the data, control over the data, and authority to make the data available through the API” (85 FR 255380). Payers must incorporate patient data into the appropriate place where they maintain that type of information that they generate while covering a patient. We understand that payers will store that information in a variety of ways, depending on their own data infrastructure.

Comment: A commenter requested clarification as to how payers should integrate data into a patient's records if the data from their previous payer includes information from other individuals who were on the same coverage plan (for example, a family health plan).

Response: Each of our policies in this final rule are tailored toward individual patients, not any family members that may be covered through the same benefits. In some cases, applicable law may allow one individual (such as a parent or guardian) to act as a personal representative for another individual covered under the same benefits (such as a minor) and could therefore opt into the Payer-to-Payer API data exchange for that individual. Regardless, the opt in is patient-specific and a payer must make the data request based on the individual permission and the previous/concurrent payer should respond in kind with the individual patient's record. No data should be shared about any patient that has not opted in, regardless of whether another patient covered under the same benefits has opted in.

Comment: A commenter cautioned that when a new payer takes on another payer's information, this may cause a significant amount of risk for patients as they may get billed for services that are not approved under their new payer.

Response: We are not requiring impacted payers to honor another payer's prior authorization decision, nor do our final rules require reprocessing claims submitted to previous payers. If payers believe that sending these data will be confusing for patients, they should include information in their educational resources that makes clear what the data exchange is and is not used for.

ii. Data Retention

In the proposed rule, we noted that our proposals would not impact any payer's data retention requirements. Specifically, we did not propose to require impacted payers to maintain data for unenrolled patients any longer or differently than they do today under current law, regulation, or policy. We understand that if a patient is uninsured or moves to a payer not subject to this regulation that does not request information from the previous payer, after a period of time, the previous payer may discard information, which would make it unavailable to the patient or other payers in the future.

We acknowledged that imposing requirements that would require payers to alter their data retention policies based on the actions of other payers would be a significant burden that would outweigh the benefits of such a policy. We considered proposing a minimum period during which a payer must maintain patient records after disenrollment, such as 1 or 2 years. However, we stated that most payers have policies in place that would maintain patient data for at least that long, and thus, such a requirement would be unnecessary and duplicative. We requested comment on whether our understanding is correct and whether there is a benefit to considering a data retention requirement in the future.

Comment: Multiple commenters supported our decision not to propose or establish a data retention requirement for patient records that would be different or longer than that required by current laws, regulations, and policies. Other commenters recommended that CMS set a minimum data retention timeframe. A commenter suggested that a payer should have to retain data until they are requested by a subsequent payer or after a minimum period of years, whichever occurs first. Other commenters recommended data be maintained for 5 or 10 years after a patient is unenrolled. Some commenters requested further guidance regarding the time for which impacted payers should maintain the data received from previous/concurrent payers.

Response: We do not believe that additional data retention requirements are necessary at this time, as we do not wish to change or create conflict with existing rules. For example, under 42 CFR 422.504(d), 438.3(u), and 457.1201(q), MA organizations, Medicaid managed care plans, and CHIP managed care entities, respectively, must retain records for at least 10 years. Similarly, most states require 5–10 years of data retention. Nothing in this final rule would extend existing data retention requirements or create an obligation for perpetual maintenance. We emphasize that once a payer receives patient data from another payer, it becomes part of the patient's record and should be treated the same as data in the patient record created by the current payer. There should be no difference for data retention or data availability, as well as the same obligation to update or correct the data. The only difference is that payers may attach provenance information designating where the data originated.

Comment: A commenter noted that a patient's previous payer should not be required to respond to requests from the patient's current payer more than 90 days after the patient has disenrolled from the previous payer.

Response: We disagree with setting a 90-day limit on the initiation of a payer to payer data exchange by a patient's new payer. Patients should have access to their data for a significantly longer period than that. Some patients may not learn about payer to payer exchange for more than 90 days after the start of coverage. Others may move to payers that are not subject to this rule and do not have a Payer-to-Payer API or become uninsured for a period before moving back to an impacted payer. However, we do expect that a significant majority of the payer to payer data exchanges will be near the beginning of a patients' new coverage, particularly if the required patient educational resources clearly present the option at or shortly after enrollment. Impacted payers are required to exchange the data they maintain on a patient, with a date of service within 5 years of the request. We note that we discuss the timeframe for data retention in this section, for which we are not changing any regulation or requirement. We may consider, in future rulemaking, establishing a time period for the data to be available via Payer-to-Payer API, but such a timeframe would likely be a matter of years, not days or months.

g. Patient Education Resources

Consistent with our proposals for the Provider Access API, we proposed that impacted payers (excluding including Medicaid managed care plans and CHIP managed care entities) would be required to provide patients with educational resources in non-technical, simple, and easy-to-understand language, explaining at a minimum: the benefits of the Payer-to-Payer API data exchange, patients' ability to opt in or withdraw their permission, and instructions for doing so. We proposed that state Medicaid and CHIP programs would provide this information to beneficiaries to be consistent with our proposal that states would be responsible for collecting beneficiaries' permission for payer to payer exchange. We proposed that those impacted payers would be required to provide these educational resources to patients at or before requesting permission for the Payer-to-Payer API data exchange. As discussed previously, currently enrolled patients must be given the opportunity to opt into the payer to payer data exchange and to provide previous/concurrent payer information before the API compliance dates. We proposed that impacted payers would be required to provide these educational resources to those currently enrolled patients at or before requesting their opt in as well. In addition, we proposed that similar resources would have to be provided annually to all covered patients in mechanisms that the payer regularly uses to communicate with patients. Impacted payers would also be required to post these resources in an easily accessible location on the payer's public website. We requested comment on whether it would reduce payers' burden to only be required to provide these resources annually to any patients who have not opted in and those with known concurrent payers.

Because we are finalizing a modification to our proposal and establishing Payer-to-Payer API compliance dates in 2027 this requirement to provide educational resources is also being moved from the proposed 2026.

Comment: Multiple commenters expressed support for CMS's proposed requirements related to resources to educate patients about the benefits of data exchange between payers, the patient's right to opt in and to withdraw their permission, and instructions for doing so. Multiple commenters supported CMS's proposals to require that patient educational resources be in non-technical, simple, and easy to understand language. A commenter noted health literacy is the single largest barrier to health care access for those with coverage. A commenter recommended that CMS amend the patient resources requirements to require impacted payers to write resources at the fourth to sixth grade reading level.

Response: We are slightly modifying the final regulation text to require that this information be provided in “plain language” instead of using the longer, more cumbersome phrase “non-technical, simple, and easy-to-understand language.” This modification does not change the meaning of the requirement that the educational information be non-technical and easy-to-use, but is intended to be more straightforward and to encourage impacted payers to follow the Federal Government's plain language guidelines. Those guidelines were informed by the Plain Writing Act of 2010, which requires Federal agencies use clear government communication that the public can understand and use. That statute applies only to Federal Government agencies, but we believe that the plain writing guidance developed for the Federal Government will be useful for impacted payers when developing educational resources for patients. We also encourage payers to review and utilize the health literacy resources that the AHRQ makes available on their website.

We do not believe that it is prudent to establish a specific “grade level” requirement. A grade level score is based on the average length of the words and sentences. Readability formulae vary and the grade level scores for the same text can differ depending on how it is used. Furthermore, edits that are done to make text score at a lower grade level can produce choppy text that lacks cohesion.

However, we do note that 45 CFR part 92 requires impacted payers (such as health programs or activities under that section) to provide meaningful access to individuals with limited English proficiency and accessibility requirements for individuals with disabilities. The requirements of that part apply to impacted payers, as described at 45 CFR 92.3.

Comment: Multiple commenters recommended that CMS develop resources, such as standardized language, tools, and delivery models, that payers could customize to ensure a consistent message to patients on what will be a confusing and complicated topic. A commenter noted that if CMS led the development, then the educational resources and programs for the Payer-to-Payer API could be standardized across carriers, FFS program administrators, and enrollment administrators to support consistent messaging and improve engagement with the API.

Response: In an effort to assist payers in meeting these requirements, we intend to provide templates or outlines for educational resources after this final rule is published and in time for payers to review and use prior to the compliance dates. However, we do not expect those resources to be fully sufficient to meet the requirements of this rule without additional content and customization by payers to include their specific processes for patients to opt in or withdraw their permission. To the extent possible, we encourage payers to collaborate on standardized resources to ensure consistent messaging to patients, regardless of the payer with whom they are enrolled. However, we also expect each payer to have to customize their resources with their own information and opt in process.

Comment: A commenter suggested that it would benefit both patients and providers for us to allow third parties, such as an HIE or HIN, to provide educational resources to patients on the payer's behalf. The commenter stated that if multiple payers use the same third-party resources, it could simplify the solution across the industry.

Response: Nothing in this rule will prevent a payer from working with a third party to develop the educational resources discussed here or from using subcontractors or downstream entities to the extent that program-specific laws permit that. As discussed in this section, payers may use an HIE or HIN to facilitate the Payer-to-Payer API exchange. However, we encourage payers to make it clear that any resources disseminated to patients under this requirement are from the payer. Patients are unlikely to devote attention to resources they receive from entities with which they are not familiar. While we expect that patients would recognize the name, logo, and other markings of official correspondence from their payer, they are unlikely to recognize their payer's partners. Therefore, while a third party may develop (and send on the payer's behalf) the required educational resources, we strongly recommend that these resources be clearly branded as communications from the patient's payer.

Comment: Multiple commenters highlighted the need to educate patients specifically on the opt in framework. Specifically, these commenters encouraged CMS to ensure that those educational resources are easy for patients to find. Some commenters recommended including that information in the patient's enrollment resources, while others disagreed and believe that that information may be easily missed within the larger quantity of information. A commenter recommended that in addition to payers, Federal agencies should play a role in patient education regarding data sharing. Another commenter recommended that CMS engage in testing patient education and opt in notifications before the compliance dates.

Response: We agree that it is particularly important for patients to understand what they are opting in to. The educational information should highlight the benefits of API-based data exchange and explain patients' permission rights. Additionally, we emphasize that that information should be communicated in a way that is conspicuous and makes clear to patients that this policy provides them rights as consumers. However, each payer has different processes and modalities for communicating with patients and we do not want to be prescriptive in a way that may add unintended and unnecessary burden to payers.

As stated previously, we are committed to providing outlines or templates for these educational resources. In developing those resources, we will prioritize using plain language for patients. In addition, we have stated that Medicare FFS intends to conform to the requirements of this rule, which includes patient educational resources. Beyond that, we will consider what role CMS may play in patient education. However, we know that patients have a relationship with their payers and expect to receive various communications from their payer relating to their coverage. Therefore, patients are more likely to consider educational resources that come directly from their payer. Further, these educational resources will need to include instructions for how patients can opt into Payer-to-Payer API data exchange and withdraw their permission; such instructions will need to be tailored to the specific procedures for each payer. While additional education from Federal agencies may supplement information from payers, it is not a substitute.

Comment: Multiple commenters recommended that CMS limit the dissemination of annual Payer-to-Payer API educational resources to only those patients who have not opted in and those with known concurrent payers. A commenter recommended that making patient educational resources available on a payer's website should be sufficient and CMS should not require payers to send that information on an annual basis.

Response: While we understand that there may be additional burden to send all patients educational resources annually, we believe that such a requirement is necessary. As discussed previously, in section II.C.3.c.iv. of this final rule, patients must have the opportunity to withdraw their permission for payer to payer exchange at any time. While we generally expect exchange between a previous and new payer to be a one-time transaction, we do allow for the possibility of additional data exchanges, as discussed in section II.C.3.d.ii. of this final rule. Therefore, the opportunity to withdraw permission needs to be offered to all patients at any time. In order to be aware of this right, patients need to be informed of it. Payers are already required to send information to patients annually and including information about payer to payer data exchange should not be a significant burden to include with those resources. We do not believe that it would serve patients to have resources and information about the Payer-to-Payer API data exchanges and the patients' rights to opt into and out of those data exchanges available only on a payer's website. That would require patients to affirmatively seek out that information on their own, or to stumble across it by chance.

Comment: Multiple commenters encouraged CMS to use community outreach and education campaigns to encourage patients to opt into sharing their data via the Payer-to-Payer API.

Response: We will look into opportunities to educate patients on opting into data sharing. As mentioned previously, we are committed to providing outlines or templates for these educational resources. In developing those resources, we will prioritize patient comprehension. Beyond that, we will consider what role CMS may play in patient education.

4. Payer to Payer Data Exchange in Medicaid and CHIP

a. Inclusion of Medicaid and CHIP Fee-for-Service

As discussed in the CMS Interoperability and Prior Authorization proposed rule (87 FR 76267), we did not require state Medicaid and CHIP FFS programs to comply with the payer to payer data exchange policies in the CMS Interoperability and Patient Access final rule (85 FR 25568).

We proposed to make the payer to payer data exchange policies in this rule applicable to state Medicaid and CHIP FFS programs. We stated that requiring state Medicaid and CHIP FFS programs to implement the Payer-to-Payer API data exchange in this rule would not be as burdensome as the non-API-based payer to payer data exchange that was finalized in the CMS Interoperability and Patient Access final rule (85 FR 25524), which we are now rescinding. That is because this new API would be leveraging the same data and technical standards as the Patient Access API. State programs should have already implemented Patient Access APIs and should thus be able to leverage the work done for that API to make implementing this new API more manageable. Additionally, in the proposed rule we discussed the various benefits that the Payer-to-Payer API could produce for state Medicaid and CHIP programs, including creating efficiencies, reducing burden, and improving health outcomes (87 FR 76276).

Comment: Commenters supported applying the proposed requirements to Medicaid and CHIP FFS and agreed that such a policy would benefit Medicaid and CHIP beneficiaries who are covered by FFS by improving care coordination and continuity of care. Other commenters stated that the Payer-to-Payer API would reduce burden on patients and providers and allow state Medicaid agencies to operate more efficiently.

Response: We appreciate the support for including state Medicaid and CHIP FFS as impacted payers and are finalizing that proposal.

Comment: A commenter questioned the expected value of the Payer-to-Payer API to state Medicaid agencies and the return on investment for the time and effort to implement systems.

Response: Data exchange from one payer to another as patients transition between payers is a powerful way to support care coordination and continuity of care during coverage transitions, particularly in the Medicaid program where patients often churn in and out of the program and between payers. Electronic data exchange between payers would support payer operations and a patient's coverage transition to a new payer efficiently and accurately.

b. Medicaid and CHIP—Seeking Permission Using an Opt In Approach in the Payer-to-Payer API

We proposed that state Medicaid and CHIP agencies, like other impacted payers, establish a process to allow beneficiaries to opt into the payer to payer data exchange. We stated that an opt in framework means that the beneficiary or their personal representative would need to affirmatively permit state Medicaid and CHIP agencies to share their data, and without first obtaining that permission, the agency could not engage in the payer to payer data exchange for that beneficiary. In contrast, we proposed an opt out policy for the Provider Access API, in part, based on the existence of a treatment relationship between the beneficiary and provider. Specifically, our policy to only require the Provider Access API data exchange with enrolled Medicaid and CHIP providers and require a process to attribute a patient to that provider before data can be exchanged creates a level of assurance for the Medicaid or CHIP agency that it is sending patient data to an appropriate party. Two payers exchanging information may not have a direct relationship but would be exchanging data based on a patient's separate relationship with each payer. Therefore, in the proposed rule, we stated that it would make sense for the patient to have a larger gatekeeping role and be required to provide affirmative permission for the Payer-to-Payer API data exchange.

We proposed that state Medicaid and CHIP agencies, rather than their managed care plans or managed care entities, would be responsible for obtaining the required permission. We also proposed that the requirement to identify patients' previous/concurrent payers would apply to state Medicaid and CHIP agencies rather than managed care plans or managed care entities. For clarity and consistency with existing Medicaid and CHIP rules, we also proposed that a patient's permission would not be necessary to exchange data between a state Medicaid or CHIP agency and its contracted managed care plans or entities.

We explained in the proposed rule that the opportunity for newly enrolling patients to opt in could take place through a single streamlined application, or at some later point of contact with the beneficiary prior to enrollment, but in no instance would our proposals permit a delay in the enrollment process or a beneficiary's coverage.

We sought comments, specifically from states and contracted managed care plans and entities, how we could establish standards for patient data exchange for state Medicaid and CHIP agencies and their contracted managed care plans and entities without creating additional barriers or burden. We requested comment on the workflow and data exchanges that occur when a Medicaid or CHIP beneficiary is enrolled into a managed care plan or entity and the feasibility of sending patient permission during the enrollment process.

We considered proposing that the Payer-to-Payer API requirements would not apply for beneficiaries moving between or with concurrent coverage with a state Medicaid or CHIP agency and its contracted Medicaid or CHIP (as applicable) managed care plan or entity for the reasons outlined previously. However, we are concerned that many states today do not exchange data between their Medicaid or CHIP FFS programs and managed care programs. We requested comments on whether there are other ways we can ensure patient data are exchanged in this case in a manner that would reduce burden on states.

Comment: Multiple commenters recommended that CMS reexamine whether its interpretation of 42 CFR 431.306(d) and 457.1110(b) would prohibit Medicaid agencies from participating in HIEs. A commenter encouraged CMS to explain whether requirements at 42 CFR 431.306(d) and 457.1110(b) prohibits Medicaid and CHIP programs from sharing beneficiary information with HIEs for the purposes of the Payer-to-Payer API. The commenters advocated for CMS to make a change to privacy regulations to support an opt out model consistent with industry standards. Multiple commenters that agreed with the proposal specifically recommended that state Medicaid and CHIP agencies leverage current solutions by HIEs and HINs to implement the proposed opt in requirement.

Response: We do not agree that 42 CFR 431.306(d) and 457.1110(b) prohibit Medicaid or CHIP agencies from contracting with an entity that offers the technology to allow for digital access and transfer of a patient's medical records, often referred to as an HIE. Section 1902(a)(7) of the Social Security Act (the Act), which our regulations at 42 CFR part 431, subpart F, implement, requires that a state's Medicaid plan provide safeguards that restrict the use or disclosure of information concerning Medicaid applicants and beneficiaries to purposes directly connected with administration of the state plan. Our regulations at 42 CFR part 431, subpart F, set forth requirements for states to safeguard Medicaid applicants' and beneficiaries' information in accordance with section 1902(a)(7) of the Act, including requirements for safeguarding the information, what types of information must be safeguarded, and when and how to release otherwise safeguarded information. The same requirements also apply to separate CHIPs through a cross reference at 42 CFR 457.1110(b). The disclosures of beneficiary data to an HIE contracted to implement and maintain the required Payer-to-Payer API would be directly related to the administration of the state plan because sharing beneficiary data through the Payer-to-Payer API supports the provision of services for beneficiaries, as described at 42 CFR 431.302(c). States that share information about Medicaid beneficiaries or former beneficiaries with their concurrent and new payers support opportunities for improved care coordination, reduce time needed to evaluate beneficiaries' current care plans, their health risks, and their health conditions at the time they enroll with the Medicaid program, or another payer. Further, under section 1902(a)(4) of the Act, Medicaid agencies may contract with organizations to enhance the agency's capability for effective administration of the program.

The regulation at 42 CFR 431.306(d) generally requires states to obtain permission from an individual Medicaid applicant or beneficiary, or their personal representative, before responding to a request for information from an outside source to disclose that applicant's or beneficiary's data safeguarded under 42 CFR 431.305. State Medicaid and CHIP agencies may share Medicaid and CHIP beneficiary information with entities with which the agency has contracted to support the administration of its Medicaid or CHIP state plan. Such contractors would not be considered “outside sources” because they are contracted to carry out functions directly related to administration of the state Medicaid or CHIP plan. Thus, if a Medicaid or CHIP agency contracts with an HIE to carry out administrative functions of the state's Medicaid or CHIP program, including implementing and maintaining the required Payer-to-Payer API, the HIE would not be considered an “outside source” and the state Medicaid or CHIP agency could share Medicaid or CHIP beneficiary information with the HIE for purposes directly connected to administration of the state plan without prior permission from the Medicaid or CHIP beneficiary required by 42 CFR 431.306(d) and 457.1110(b), respectively. Regardless, whether a Medicaid or CHIP agency contracts with an HIE to develop and maintain the required Payer-to-Payer API, the Medicaid or CHIP agency is responsible for ensuring the contracted entity implements a Payer-to-Payer API that meets all regulatory requirements, which includes that an individual or their representative has provided permission (opted in) prior to their information being shared with other payers via the Payer-to-Payer API.

In addition, to receive beneficiaries' information from the Medicaid or CHIP agency, Medicaid or CHIP providers, plans, or contractors must be subject to standards of confidentiality comparable to those of the state Medicaid and CHIP agency in accordance with 42 CFR 431.306(b) and 457.1110(b) respectively. Furthermore, Medicaid regulation at 42 CFR 434.6(a)(8) requires that each of the state Medicaid agency's contracts must provide that the contractor safeguards information about beneficiaries as required by 42 CFR part 431, subpart F. Under these requirements, if a state Medicaid or CHIP agency contracted with an HIE or other entity, the contractor would be required to meet the same standards of confidentiality as the state Medicaid agency (as set forth in section 1902(a)(7) of the Act and our implementing regulations at 42 CFR part 431, subpart F), including but not limited to:

• Providing safeguards that restrict the use or disclosure of information concerning applicants and beneficiaries to purposes directly connected with the administration of the plan in accordance with section 1902(a)(7) of the Act and 42 CFR 431.300 and 431.302; and

• Not disclosing data to an outside source, such as non-Medicaid or non-CHIP payers with whom the HIE might exchange data, without prior permission from the individual in accordance with 42 CFR 431.306(d).

We did not propose any changes to Medicaid or CHIP confidentiality regulations at 42 CFR part 431, subpart F, and 42 CFR 457.1110(b), but we appreciate the comment and will consider it for any future rulemaking.

Comment: A commenter stated that an opt in process implemented within its system would not authorize another payer (particularly payers not subject to this regulation) to release patient information to the commenter or for the commenter to release a patient's data to a patient's subsequent payer.

Response: All data received, maintained, used, or shared via this proposed Payer-to-Payer API must be received, maintained, used, or shared in a way that is consistent with all applicable laws and regulations. As discussed previously, our regulation for Medicaid at 42 CFR 431.306 (incorporated via cross reference for CHIP at 42 CFR 457.1110(b)) sets forth certain requirements for release of Medicaid and CHIP applicant and beneficiary data. Consistent with our proposal, we are finalizing that when another payer (including a payer not subject to this final rule) is requesting a former Medicaid or CHIP beneficiary's information from the state Medicaid or CHIP agency, an attestation from a requesting payer that the patient or their representative has opted into data exchange with the requesting payer (that is, given permission for the Medicaid or CHIP agency to share the beneficiary's data) is sufficient to meet the requirements at 42 CFR 431.306 and 457.111(b) to allow the state Medicaid or CHIP agency to respond to the data request, though such permission must be received prior to the state Medicaid or CHIP agency sharing any beneficiary data. For more information about how the HIPAA Privacy Rule interacts with Payer-to-Payer API, see section II.C.3.c.iv.

Comment: Multiple commenters agreed with the proposal for state Medicaid and CHIP agencies to collect and manage patient decisions to opt into the payer to payer data exchange when beneficiaries are enrolled in Medicaid or CHIP managed care. Multiple commenters agreed that collecting a beneficiary's choice to opt into the payer to payer data exchanges as part of existing Medicaid and CHIP eligibility and enrollment processes would be the most effective and technically feasible approach for most states operating managed care programs in Medicaid and CHIP and would streamline the process for beneficiaries.

Response: For many reasons, we agree that the state Medicaid or CHIP program is the appropriate custodian of the patient's permission record, rather than the particular managed care plan or managed care entity through which a patient receives Medicaid or CHIP covered services. A Medicaid or CHIP beneficiary may switch between FFS and managed care delivery systems within the same state's Medicaid or CHIP program. Despite these shifts, an eligible beneficiary remains a beneficiary of the state program. States may also change the Medicaid or CHIP managed care plans or entities with which they contract. Thus, a Medicaid or CHIP beneficiary's opt into the payer to payer data exchange, should be obtained by the state and will apply regardless of the delivery system in which the beneficiary is enrolled. Furthermore, we understand that in many states, managed care plans may not have any contact with beneficiaries prior to their enrollment in the Medicaid managed care plan or CHIP managed care entity.

We believe the ideal time to allow patients to opt into the payer to payer data exchange is during their application for Medicaid or CHIP. As stated previously, obtaining a patient's opt in permission and identifying the previous/concurrent payer(s) cannot delay an applicant's eligibility determination or start of coverage. If a state has all the information necessary to determine an individual's eligibility before it obtains the individual's permission for the payer to payer data exchange, the state must determine the individual's eligibility and enroll the individual in Medicaid or CHIP coverage, if determined eligible, while continuing to follow the Payer-to-Payer API requirements as expeditiously as possible post-enrollment.

Because we expect higher rates of patients to opt in when they are presented with the option at a point when they are already providing information (such as at application or plan selection), we highly encourage states to leverage any touchpoints before patients are enrolled in Medicaid or CHIP rather than expecting patients to opt in through a separate process.

We are finalizing our proposal to require the state to establish a process for obtaining opt into the payer to payer data exchange prior to the state Medicaid or CHIP agency's Payer-to-Payer API compliance dates, and prior to the enrollment of new beneficiaries after that date, and that the state Medicaid and CHIP agencies will be responsible for obtaining the required permission.

To the extent that doing so is consistent with Federal Medicaid and CHIP requirements, including those at section 1902(a)(7) of the Act and implementing regulations at 42 CFR part 431, subpart F, and applied to separate CHIPs through a cross reference at 42 CFR 457.1110(b), Medicaid and CHIP agencies are welcome to contract with HIEs or HINs, especially those operating under TEFCA, to facilitate payer to payer data exchange. Some HIEs may already have the technical framework to manage patient consent or engage in standardized data exchange via FHIR APIs in ways that Medicaid or CHIP agencies' systems do not. Nothing in this rule would prohibit a Medicaid or CHIP agency from partnering with an HIE to meet its requirements, but Medicaid and CHIP agencies must continue to comply with all other Federal requirements applicable to the operation of Medicaid and CHIP.

Comment: Multiple commenters expressed concerns about state Medicaid and CHIP agencies' resources to collect and manage patient decisions to opt into the exchange of their data via the Payer-to-Payer API. A commenter stated that it may need to build separate functionality to support implementation of the opt in requirement if it is unable to support the requirement within the state's existing eligibility system. A commenter noted that it will require significant work to implement an opt in process in states and territories where the Medicaid agency does not complete eligibility and enrollment processes and recommended that CMS ensure an appropriate implementation timeline in these instances. A commenter suggested that CMS work with states to implement a consistent solution to avoid inconsistencies in what data are collected and how to address the concern about resources. Another commenter specifically expressed that the process to identify a previous/concurrent payer would be challenging for Medicaid.

Response: We understand and appreciate that state Medicaid and CHIP agencies will need to create new processes to request a patient's permission to exchange data and identifying information about their previous/concurrent payer(s), and then to share that information with their managed care plans and managed care entities. States have different eligibility and enrollment processes, and a one-size-fits all approach may not be optimal. We are not being prescriptive on this process, as we want each program to implement the requirements in the least burdensome, most efficient way for them.

We also understand that making changes to applications can be a significant administrative process, and for states where Medicaid or CHIP eligibility is determined by a state or regional agency other than the Medicaid or CHIP agency, there will be additional administrative steps to implementation. We are extending our compliance dates for the Payer-to-Payer API from our proposed 2026 to 2027 in order to provide adequate time for payers to implement these requirements. Further, there may be other places where a state could obtain a patient's data exchange permission for the Payer-to-Payer API data exchange. For instance, a state could leverage an online portal or app, if beneficiaries frequently use those pathways for other purposes, such as reporting a change in circumstance or providing information for eligibility renewal. However, the option should be equally available for all beneficiaries and if only a small portion of the Medicaid or CHIP population uses these tools to communicate with the Medicaid or CHIP agency, that subset would be self-selected for greater technology literacy and taking this approach could exacerbate inequality.

We note that the single streamlined application, which for Medicaid and CHIP purposes is described at 42 CFR 435.907(b)(1) and 457.330, respectively, and is also used for applications through the FFEs, includes questions about concurrent coverage information. We also expect that some states that do not use the single streamlined application already ask for this information for Coordination of Benefits and Third-Party Liability purposes. We believe that it would generally make sense to gather permission for payer to payer data exchange at the point the state collects concurrent payer information. We note that the patient permission provisions in this rule will apply only to the payer to payer data exchange discussed here and would not affect states' ability to perform Coordination of Benefits or Third-Party Liability activities as they do today.

Comment: Multiple commenters stated that CMS should ensure that regulatory language clearly makes the opt in requirement applicable to Medicaid managed care plans.

Response: We intentionally did not include regulatory text requiring Medicaid managed care plans and CHIP managed care entities to meet the requirement to collect patient permission for payer to payer data exchange. As discussed in section II.C.4.b. of this final rule, we are finalizing that requirement for state Medicaid and CHIP agencies because we believe that they are the proper entity to hold a patient's opt in decision. State Medicaid and CHIP agencies may work with their managed care plans and entities to gather that information, but ultimately the requirement to gather and maintain that information is the responsibility of the state Medicaid or CHIP agency. As proposed and discussed in section II.E.2.a. of this final rule, we are finalizing that the responsibility to collect patient permission for the Payer-to-Payer API data exchange is not eligible for exemption from the API requirements. Therefore, even if a state receives an exemption from the Payer-to-Payer API, it is still responsible for collecting and maintaining a record of patient opt in permission for this data exchange. We note that we are also finalizing that state Medicaid and CHIP programs, rather than their managed care organizations, are responsible for providing educational resources at the time of requesting permission for payer to payer data exchange and for collecting identifying information about patients' previous/concurrent payer(s).

Comment: A commenter requested clarification on whether a patient's opt in permission is required to share data between impacted payers within the same state Medicaid program. Another commenter asked us to explain what types of managed care plans are included in this statement (for example, MCOs, PIHPs, PAHPs, Primary Care Case Managers (PCCMs), integrated plans for patients dually eligible for Medicare and Medicaid).

Response: As we explained in the preamble to the proposed rule (87 FR 76238), we know that state Medicaid or CHIP agencies regularly exchange data with their managed care plans and entities. We do not intend the opt in requirements for the Payer-to-Payer API to interfere with or affect this permissible exchange. Medicaid managed care plans, and CHIP managed care entities are not outside sources as described at 42 CFR 431.306(d), but are part of a state's Medicaid and/or CHIP programs as a whole, because these entities are contracted to support the agency's administration of its Medicaid or CHIP state plan. Specifically, Medicaid managed care plans and CHIP managed care entities are contracted with the Medicaid state agency to deliver Medicaid program health care services to beneficiaries under the state plan.

Hence, we are finalizing our proposal that if a Medicaid or CHIP agency is exchanging information per our Payer-to-Payer API proposals with a managed care plan or managed care entity with which they have a contract, the requirement to obtain patient opt in would not apply. We consider any plan and entity that has a contract with the state Medicaid or CHIP agency to deliver Medicaid program health care services to beneficiaries under the state plan, including state Medicaid agency contracts with D–SNPs under 42 CFR 422.107, to be part of the state's Medicaid or CHIP programs, regardless of the coverage model. We note that this policy and opt in requirement to share data between impacted payers would not replace regulatory requirements as described at 42 CFR part 422, including as they relate to integrated D–SNPs.

We note that permissible data exchange only covers data that facilitate that plan's contracted services. For instance, it would be inappropriate to share patient data with a managed care plan or entity other than the one with which the patient is enrolled. The other Payer-to-Payer API requirements, such as the requirement to use a FHIR API and the authorization and authentication protocols would apply to data exchange required in this final rule between state Medicaid and CHIP agencies and their managed care plans or managed care entities. The exchange must also not be prohibited by other law.

c. Federal Matching Funds for State Medicaid and CHIP Expenditures on Implementation of Payer to Payer Data Exchange

In section II.E. of this final rule, we discuss Federal matching funds for certain state Medicaid and CHIP FFS programs' expenditures related to implementation of the payer to payer data exchange (this was also addressed in the proposed rule at 87 FR 76278).

d. Medicaid Expansion CHIP

In section II.E. of this final rule, we discuss implementation for states with Medicaid Expansion CHIP programs (this was also addressed in the proposed rule at 86 FR 76279).

5. Extensions, Exemptions, and Exceptions

See section II.E. of this final rule for a discussion of extensions and exemptions and the final policies for the Payer-to-Payer API for state Medicaid and CHIP FFS programs and exceptions for the Payer-to-Payer API for QHP issuers on the FFEs (this was also addressed in the proposed rule at 86 FR 76279).

6. Final Action

After considering the comments received, and for the reasons discussed in the CMS Interoperability and Prior Authorization proposed rule and our response to those comments (as summarized previously), we are finalizing our proposal with the following modifications:

• Impacted payers must implement and maintain a Payer-to-Payer API beginning in 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs) rather than in 2026.
• Impacted payers are not required to share the quantity of items or services used under a prior authorization via the Payer-to-Payer API.
• The data exchange between a previous payer and a new payer is limited to data with a date of service within the previous 5 years.
• Impacted payers are required to request patients' permission for payer to payer data exchange and identifying information about patients' previous/concurrent payers no later than 1 week after the start of coverage, as that term is defined for each type of impacted payer, rather than at enrollment.

See further discussion for the exact details of the final requirements for impacted payers.

We are finalizing the rescission of the payer to payer data exchange policy previously finalized in the CMS Interoperability and Patient Access rule (85 FR 25568) at 42 CFR 422.119(f)(1) and 438.62(b)(1)(vi) and (vii) and 45 CFR 156.221(f)(1).

We are finalizing a requirement that, beginning in 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs), impacted payers must implement and maintain a Payer-to-Payer API that is conformant with certain technical standards, documentation requirements, and denial or discontinuation policies. Specifically, those technical standards are HL7 FHIR R4 at 45 CFR 170.215(a)(1), US Core IG at 45 CFR 170.215(b)(1)(i), and Bulk Data Access IG at 45 CFR 170.215(d)(1).

We are also finalizing a requirement that, by the deadlines, impacted payers (except Medicaid managed care plans and CHIP managed care entities) must establish and maintain a process to gather patient permission for payer to payer data exchange no later than 1 week after the start of coverage. We are finalizing an opt in framework whereby a patient or personal representative must affirmatively agree to allow that data exchange. Impacted payers must also have a process for patients to change their permission at any time.

We are finalizing a requirement that, by the deadlines, impacted payers must establish and maintain a process to identify a patient's previous/concurrent payer(s) no later than 1 week after the start of coverage. As part of this process, impacted payers are required to allow a patient to report multiple previous/concurrent payers if they had (or continue to have) concurrent coverage. If a patient does report multiple previous payers, impacted payers are required to request that patient's data from all previous/concurrent payers. If a patient does not respond or additional information is necessary, the impacted payer must make reasonable efforts to engage with the enrollee to collect this information.

We are also finalizing a requirement that, no later than the compliance dates, impacted payers must establish and maintain a process to gather permission and previous/concurrent payer(s) information from patients who are already enrolled.

We are finalizing a requirement that, by the deadlines, impacted payers must request a patient's data from a patient's previous/concurrent payer(s) no later than 1 week after the payer has sufficient identifying information and the patient has opted in. Impacted payers must also request data from a patient's previous/concurrent payers(s) within 1 week of that patient's request to do so. Impacted payers must include an attestation with this request for data affirming that the patient is enrolled with the requesting payer and has opted into the data exchange in a manner that meets the legal requirements.

Additionally, we are finalizing a requirement that, by the deadlines, when an impacted payer has sufficient identifying information and the patient has opted in, they must request data from any concurrent payers at least quarterly. Impacted payers who receive a request for a patient's data from a known concurrent payer must respond with the required data within 1 business day of receiving the request.

We are finalizing a requirement that, by the deadlines, upon receiving a request that meets the legal requirements, impacted payers must make any of the required information that they maintain available to new payers no later than 1 business day after receiving the request.

We are finalizing a requirement that, by the deadlines, impacted payers must make available via the Payer-to-Payer API, by request from payer that meets certain requirements, claims and encounter data (excluding provider remittances and patient cost-sharing information), all data classes and data elements included in a content standard at 45 CFR 170.213, and certain information about prior authorization requests and decisions (excluding those for drugs and those that were denied) that the payer maintains with a date of service within 5 years of the request. The required information is—

• The prior authorization status;
• The date the prior authorization was approved;
• The date or circumstance under which the prior authorization ends;
• The items and services approved; and
• Structured and unstructured administrative and clinical documentation submitted by a provider.

We are finalizing a requirement that impacted payers are required to make this information about prior authorizations available for the duration that the authorization is active and for at least 1 year after the prior authorization's last status change.

We are finalizing a requirement that, by the deadlines, information received by an impacted payer through the payer to payer data exchange must be incorporated into the payer's patient record.

We are finalizing a requirement that, by the deadlines, impacted payers (except Medicaid managed care plans and CHIP managed care entities) must provide educational resources to their patients about the Payer-to-Payer API in plain language. These resources must include information about the benefits of Payer-to-Payer API data exchange, the patient's ability to opt in or withdraw that permission, and instructions for doing so. Impacted payers must make this information available to patients when requesting the opt in decision. Thereafter, impacted payers must provide this information to patients annually, in mechanisms the payer ordinarily uses to communicate with patients. These resources must also be available in an easily accessible location on payers' public websites.

These final policies apply to MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities (excluding NEMT PAHPs), and QHP issuers on the FFEs at the CFR sections listed in Table D1.

7. Statutory Authorities for Payer to Payer Data Exchange Proposals

We note that we received no public comments on the statutory authorities for our Payer-to-Payer API policies.

a. MA Organizations

For MA organizations, we are finalizing these Payer-to-Payer API requirements under our authority at section 1856(b) of the Act to adopt by regulation standards consistent with and to carry out Part C of Title XVIII of the Act (such as section 1852(d)(1)(A) of the Act). In addition, section 1857(e)(1) of the Act authorizes the Secretary to adopt contract terms and conditions for MA organizations that are necessary, appropriate, and not inconsistent with the statute. In total, the regulations we are adopting in this final rule for MA organizations and MA plans are necessary and appropriate because they address and facilitate continued access to enrollees' medical records and health information when they change payers, which will support consistent and appropriate coordination of coverage when enrollees have concurrent payers and will support coordination of care and continuation of active courses of treatment when enrollees change payers.

In regulations establishing the MA program, CMS described it as a program designed to: provide for private plan options available to Medicare beneficiaries, especially those in rural areas, enrich the range of benefit choices, provide incentives to plans and add specialized plans to coordinate and manage care in ways that comprehensively serve those with complex and disabling diseases and conditions, use competition to improve service and benefits, invest in preventive care, hold costs down in ways that attract enrollees, and advance the goal of improving quality and increasing efficiency in the overall health care system. This final rule supports these goals and enables the MA program to advance services for its enrollees by providing greater access to information in a way that will improve care management for payers, providers, and the patient.

Section 1856(b) of the Act requires the Secretary to establish regulatory standards for MA organizations and plans that are consistent with, and carry out, Part C of the Medicare statute, Title XVIII of the Act. The Payer-to-Payer API proposals support MA organizations sharing certain claims, encounter, and clinical data, as well as prior authorization requests and decisions, with another payer that, as identified by the enrollee, has or does cover the enrollee. Such exchanges of data about patients could facilitate continuity of care and enhance care coordination. As discussed for the Provider Access API in section II.B. of this final rule, allowing payers to share health information for one or more patients at once could increase efficiency and simplicity of administration. Though we are not requiring payers to share data for more than one patient at a time, there are efficiencies to doing so, both for communicating information and for leveraging available technology.

Further, providing MA organizations with additional data about their enrollees through these data exchanges will increase the scope of data that the MA organizations must make available to enrollees through the Patient Access API. It will give payers access to all their enrollees' information with limited effort and enable the payer to then make that information available to providers and to enrollees through the Provider Access and Patient Access APIs. It may reduce the amount of time needed to evaluate a patient's current care plan and possible implications for care continuity, which may introduce efficiencies and improve care. As discussed earlier, if a new payer receives information and documentation about prior authorization requests from a previous payer, the new payer can review this information and determine that a new prior authorization may not be necessary for an item or service that was previously approved. Instead, the same care may be continued, reducing burden on both payers and providers, and improving patient care. While the statutory provisions governing the MA program do not explicitly address sharing data with other payers that cover or have covered an enrollee, the benefits to be gained by sharing data make adoption of Payer-to-Payer API policies necessary and appropriate for the MA program. Further, requiring use of the API and the specifications for the data to be shared provides a step toward greater interoperability among payers. Ultimately, using the Payer-to-Payer API is anticipated to ensure that payers receive patient information in a timely manner, which could lead to more appropriate service utilization and higher patient satisfaction. Such goals are consistent with the MA statute.

Section 1852(h) of the Act requires MA organizations to provide their enrollees with timely access to medical records and health information as far as MA organizations maintain such information. As technology evolves to allow for faster, more efficient methods of information transfer, so do expectations as to what is generally considered “timely.” Currently, consumers across public and private sectors have become increasingly accustomed to accessing a broad range of personal records, such as bank statements, credit scores, and voter registrations, immediately through electronic means and with updates received in near real-time. Thus, we to align our standards with current demands, we must take steps for MA enrollees to have immediate, electronic access to their health information and plan information. The information exchanged via the Payer-to-Payer API will ultimately be accessible to enrollees via the Patient Access API and will therefore improve timeliness to medical records and health information as enrollees will no longer have to spend time contacting previous payers to access their information. These data will be accessible as needed by the enrollee's current payer and would therefore support timely access.

Section 1852(d)(1)(A) of the Act requires MA organizations to, as a condition of using a network of providers, make covered benefits available and accessible to enrollees in a manner which assures continuity in the provision of benefits. In implementing section 1852(d)(1)(A) of the Act, we adopted a regulation, at 42 CFR 422.112(b), that requires MA organizations to ensure the continuity of care and integration of services through arrangements with providers that include procedures to ensure that the MA organization and the contracted providers have access to the information necessary for effective and continuous patient care. Consistent with section 1852(d)(1)(A) of the Act, the final requirement here for MA organizations to implement and maintain a Payer-to-Payer API will facilitate exchanges of information about enrollees that are necessary for effective and continuous patient care. Under this final rule, the data received from other impacted payers will become part of the data the MA organization maintains and will therefore be available (subject to other law authorizing the disclosure) to providers via the Provider Access API discussed in section II.B. of this final rule; the data could then be used for treatment and coordination of care purposes.

The finalized policies in this rule are necessary, appropriate, and consistent with Part C of Title XVIII of the Act. Overall, establishing these regulatory requirements for MA organizations will improve enrollee's quality of care by ensuring that they do not lose their patient records when they change payers.

b. Medicaid and Children's Health Insurance Program

Our provisions in this section fall generally under our authority in the following provisions of the Act.

• Section 1902(a)(4) of the Act, which requires that a state Medicaid plan provide such methods of administration as are found by the Secretary to be necessary for the proper and efficient operation of the state Medicaid plan.
• Section 1902(a)(8) of the Act, which requires states to ensure that Medicaid services are furnished with reasonable promptness to all eligible individuals.
• Section 1902(a)(19) of the Act, which requires states to ensure that care and services are provided in a manner consistent with simplicity of administration and the best interests of the recipients.

The final requirements related to the Payer-to-Payer API are authorized by sections 1902(a)(4), (a)(8), and (a)(19) of the Act for the following reasons. First, because the Payer-to-Payer API is designed to enable efficient exchange of data between payers, we anticipate that it will help state Medicaid programs improve the efficiencies and simplicity of their own operations under a Medicaid state plan, consistent with sections 1902(a)(4) and (a)(19) of the Act. It will give Medicaid agencies and their managed care plans access to their beneficiaries' information in a standardized manner and enable states to then make that information available to providers and patients through the Patient Access and Provider Access APIs. It may also reduce the amount of time needed to evaluate a patient's current care plan and have possible implications for care continuity, which may introduce efficiencies and improve care. Receiving patient information at the start of coverage will lead to more appropriate service utilization and higher beneficiary satisfaction by Medicaid agencies and those managed care plans considered impacted payers under this final rule by supporting efficient care coordination and continuity of care, which could lead to better health outcomes.

As discussed in section II.C.3.b. of this final rule, when a state Medicaid program has access to a previous payer's prior authorization decisions, the Medicaid program may choose to accept the existing decision and support continued patient care without requiring a new prior authorization or duplicate tests. This information exchange might also improve care continuity for beneficiaries who have concurrent coverage in addition to Medicaid by improving the coordination of health coverage they receive, reducing gaps, or duplication of coverage.

Our final rule is expected to help states and managed care plans furnish Medicaid services with reasonable promptness and in a manner consistent with beneficiaries' best interests, consistent with sections 1902(a)(8) and (a)(19) of the Act. A significant portion of Medicaid beneficiaries experience coverage changes and churn in a given year. Therefore, exchanging this information with a beneficiary's next payer may also better support care continuity for Medicaid beneficiaries. When states share information about Medicaid beneficiaries or former beneficiaries with their concurrent and next payers, they can support opportunities for improved care coordination for Medicaid beneficiaries and former beneficiaries. Exchanging information about Medicaid beneficiaries and former beneficiaries between payers might also reduce the amount of time needed to evaluate beneficiaries' current care plans, their health risks, and their health conditions at the time they enroll with the Medicaid program, as well as with another payer. This information exchange might be of particular value to improve care continuity for beneficiaries who might churn into and out of Medicaid coverage. The final rule may also improve the provision of Medicaid services, by potentially helping to ensure that Medicaid beneficiaries who may require coordinated services with concurrent payers can be identified and provided case management services, reduce duplication of services, and improve the coordination of care, as appropriate.

In addition, section 1902(a)(7) of the Act requires that states must provide safeguards that restrict the use or disclosure of information concerning Medicaid applicants and beneficiaries to purposes that are directly connected with the administration of the Medicaid state plan. The implementing regulations at 42 CFR part 431, subpart F, for section 1902(a)(7) of the Act list purposes that CMS has determined are directly connected with administration of Medicaid state plans (42 CFR 431.302) and require states to provide safeguards meeting certain requirements to restrict uses and disclosures of Medicaid beneficiary data, including requirements about releasing applicant and beneficiary information at 42 CFR 431.306.

Requiring the data described in this section to be shared via the Payer-to-Payer API is consistent with states' requirements to provide safeguards meeting certain requirements to share these data since it is related to providing services for beneficiaries, a purpose listed at 42 CFR 431.302(c). As described previously in sections II.A.5.b. and II.B.6.b. of this final rule related to authority under sections 1902(a)(8) and 1902(a)(19) of the Act, states that share information about Medicaid beneficiaries or former beneficiaries with their concurrent and next payers, may support opportunities for improved care coordination, reduction in the amount of time needed to evaluate beneficiaries' current care plans, their health risks, and their health conditions at the time they enroll with the Medicaid program, as well as with another payer. This information exchange might be of particular value to improve care continuity for beneficiaries who churn into and out of Medicaid coverage, described in more detail previously. When state Medicaid agencies share medical records or any other health or enrollment information pertaining to individual beneficiaries, they must comply with the requirements of 42 CFR part 431, subpart F, including 42 CFR 431.306.

For Medicaid managed care, and in addition to the general authorities cited previously regarding Medicaid programs, the finalized exchange of adjudicated claims and encounter data, all data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI), and certain information about prior authorizations maintained by the payer with a date of service within 5 years of the request by a patient's new or concurrent payer will greatly enhance an MCO's, PIHP's, or PAHP's ability to fulfill its obligations under 42 CFR 438.208(b), which require them to: implement procedures to deliver care to and coordinate services including ensuring that each enrollee has an ongoing source of appropriate care; coordinate services between settings of care, among Medicaid programs, and with community and social support providers; make a best effort to conduct an initial screening of each enrollee's needs; and share with the state or other MCOs, PIHPs, and PAHPs serving the enrollee the results of any identification and assessment of that enrollee's needs to prevent duplication of those activities. The data provided via the Payer-to-Payer API in this final rule will give managed care plans the information needed to perform these required functions much more easily, thus enhancing the effectiveness of the care coordination, and helping enrollees receive the most appropriate care in an effective and timely manner.

For CHIP, we finalized these requirements under our authority in section 2101(a) of the Act, which states that the purpose of Title XXI of the Act is to provide funds to states to provide child health assistance to uninsured, low-income children in an effective and efficient manner that is coordinated with other sources of health benefits coverage. The provisions in this final rule can strengthen our ability to fulfill these statutory obligations in a way that recognizes and accommodates using electronic information exchange in the health care industry today and will facilitate a significant improvement in the delivery of quality health care to our beneficiaries.

As with the Medicaid FFS and Medicaid managed care programs, the provisions in this section of the final rule for CHIP FFS and CHIP managed care entities require using a Payer-to-Payer API to exchange claims, encounter, clinical and prior authorization data at a beneficiary's request, or any time a beneficiary changes payers, using a FHIR API. The current payer can use data from the previous payer to respond to a request for a prior authorization more effectively or accurately, because under this final rule, a new payer will have historical claims or clinical data upon which they may review a request with more background data. Access to information about new patients will enable appropriate staff within the CHIP program to coordinate care and conduct care management more effectively because they will have better data available to make decisions for planning. In many cases, patients do not remember what services they have had, or other possibly relevant encounters that could help payers manage their care. This final rule is consistent with the goal of providing more informed and effective care coordination, which will help to ensure that CHIP services are provided in a way that supports quality care, which aligns with section 2101(a) of the Act.

Finally, the safeguards for applicant and beneficiary information at 42 CFR part 431, subpart F, are also applicable to CHIP through a cross reference at 42 CFR 457.1110(b). As discussed previously for Medicaid, CHIP agencies' data exchange through the Payer-to-Payer API is related to providing services to beneficiaries, which is described at 42 CFR 431.302(c) as a purpose directly related to state plan administration. We remind states that when they share medical records or any other health or enrollment information pertaining to individual beneficiaries, they must comply with the privacy protections at 42 CFR 457.1110 and the release of information provisions at 42 CFR 431.306.

c. Qualified Health Plan Issuers on the Federally-Facilitated Exchanges

For QHP issuers on the FFEs, we finalized these new requirements under our authority in section 1311(e)(1)(B) of the Affordable Care Act, which affords the Exchanges the discretion to certify QHPs if the Exchange determines that making available such health plans through the Exchange is in the interests of qualified individuals in the state in which the Exchange operates.

Requiring QHP issuers on the FFEs to implement and maintain a Payer-to-Payer API will allow the seamless flow from payer to payer of adjudicated claims, and encounter data, all data classes and data elements included in a standard at 45 CFR 170.213 (USCDI), and certain information about prior authorizations, that are maintained by the payer with a date of service within 5 years of the request by a patient's new or concurrent payer. Ensuring a means for an enrollee's new issuer to electronically obtain the enrollee's claims, encounter, and other data, as well as prior authorization information with corresponding medical records, from the previous issuer will reduce administrative burden and result in more timely and efficient care coordination and responses to prior authorization requests.

We believe that it is in the interest of qualified individuals that QHP issuers on the FFEs have systems in place to send information important to care coordination to a departing enrollee's new payer, and that QHP issuers on FFEs also have systems in place to receive such information from other payers on behalf of new and concurrent enrollees, as appropriate and consistent with the provisions in this section. Having patient information at the beginning of a new plan may assist the new payer in identifying patients who need care management services, which could reduce the cost of care. We encourage SBEs to consider whether a similar requirement should be applicable to QHP issuers participating in their Exchange.

Though we are not requiring the exchange of all enrollees' data at one time between impacted payers, we encourage QHP issuers on the FFEs to use the Bulk Data Access IG for the Payer-to-Payer API once it is available, as it will improve the efficiency and simplicity of data transfers between issuers by enabling the exchange of all data for all patients at once. The opportunity to support the exchange of data from multiple patient records at once, rather than data for one patient at a time, may be cost effective for the issuers.

D. Prior Authorization API and Improving Prior Authorization Processes

1. Background

This section of the final rule addresses the topic of prior authorization and includes both technical and operational requirements intended to improve the prior authorization process for payers, providers, and patients. Here, we finalize our proposals for payers to implement and maintain an API to support and streamline prior authorization processes; respond to prior authorization requests within certain timeframes; provide a specific reason for prior authorization denials; and publicly report on prior authorization approvals, denials, and appeals.

In the CMS Interoperability and Prior Authorization proposed rule (87 FR 76286) we provided a comprehensive review of the work HHS conducted regarding prior authorization processes and their associated burden to identify the primary issues that needed to be addressed to alleviate the burdens of these processes on patients, providers, and payers. We cited studies from ONC which highlighted the burdens associated with prior authorization including difficulty determining payer-specific requirements for items and services that require prior authorization; inefficient use of provider and staff time processing prior authorization requests and information (sending and receiving) through fax, telephone, and web portals; and unpredictable wait times to receive payer decisions.

We referenced American Medical Association (AMA) physician surveys from 2018, 2020, and 2022 which noted issues with prior authorization, and we used these studies to estimate the costs and savings for this final rule. Please see the CMS Interoperability and Prior Authorization proposed rule (87 FR 76286–76287) for the detailed context of these industry surveys as well as the reports from the 2019 meetings of the two Federal advisory committees, the Health Information Technology Advisory Committee (HITAC) and the National Committee on Vital and Health Statistics (NCVHS), which conducted joint hearings to discuss persistent challenges with prior authorization workflows and standards; and the follow up 2020 task force on the Intersection of Clinical and Administrative Data (ICAD) Task Force at 87 FR 76287.

We use the term prior authorization to refer to the process by which a provider must obtain approval from a payer before providing certain covered items and services to receive payment for delivering those items or services to a covered individual. As we stated in the CMS Interoperability and Prior Authorization proposed rule, prior authorization has an important place in the health care system, but the process of obtaining prior authorization can be challenging for patients, providers, and payers. Interested parties, including payers and providers, say that dissimilar payer policies, inconsistent use of electronic standards, and other technical barriers have created provider workflow challenges and an environment in which the prior authorization process is a primary source of burden for both providers and payers, a major source of burnout for providers, and can create a health risk for patients if inefficiencies in the process cause delays in medically necessary care. The prior authorization policies in this final rule apply to any formal decision-making process through which impacted payers render an approval or denial determination in response to prior authorization requests based on the payer's coverage guidelines and policies before services or items are rendered or provided.

As discussed in section I.D. of this final rule, we exclude drugs from the provisions in this section, meaning any drugs that could be covered by the impacted payers affected by these provisions. Thus, the policies herein do not apply to prescription drugs that may be self-administered, administered by a provider, or that may be dispensed or administered in a pharmacy or hospital, or OTC drugs that may be covered by an impacted payer. We include a definition of drugs for purposes of this exclusion for each impacted payer in the CFR where applicable to provisions for implementation of the Prior Authorization API. For MA organizations, the definition of drugs also includes any products that constitute a Part D drug, as defined by 42 CFR 423.100, and are covered under the Medicare Part D benefit by MA–PDs; this part of the definition specific to MA organizations provides a clear dividing line for MA–PD plans that must comply with this new rule. However, payers may voluntarily incorporate their business rules for prior authorizations for drugs using the Prior Authorization API now being finalized in this rule.

As noted in section I.D., although Medicare FFS is not directly affected by this final rule, we will evaluate opportunities to improve automation of prior authorization processes in the Medicare FFS program as feasible.

We received nearly 900 letters in response to the CMS Interoperability and Prior Authorization proposed rule, with hundreds of individual comments specific to the importance of the topic of prior authorization and the critical timing of addressing this issue. Most of the comments were relevant to the proposals and others were out of scope. The majority of commenters supported our proposals which are intended to mitigate longstanding issues with prior authorization processes and many commenters stressed the importance of finalizing the policies in this final rule as soon as practicable to resolve patient access to care issues. Some commenters identified concerns with the timing of compliance for the policies (too soon or too late), with prior authorization decision timeframes (too short or too long), and with reporting of metrics (too little or too much). We carefully reviewed each comment and considered the input to inform the policies now being described in this final rule. To be fully responsive to the public comment process, yet avoid creating an overwhelming final rule, we have consolidated input from all of the comments and summarized the contents with our responses for each provision. We value the diverse commentary provided by all interested parties as the volume and scope helped shape our approach to these final policies which advance our commitment to interoperability, burden reduction, process improvement for prior authorization, and transparent rulemaking. Comments that were out of scope for this final rule are not addressed here.

Comment: Multiple commenters stated that, while prior authorizations may improve the safety or efficiency of care in some circumstances, they can lead to negative effects for patients and providers. A commenter suggested that CMS implement a broader set of changes to prior authorization processes to correct current abuses, specifically noting that improving the speed of prior authorizations without addressing the content of prior authorization requests will not improve outcomes of inappropriate use of prior authorizations. Another commenter recommended that CMS further evaluate prior authorization burdens and make additional proposals.

Response: We appreciate that there are still concerns about the general use of prior authorization in the health care system. However, prior authorization continues to have a place in the health care system and can support functions such as utilization management, cost-effective care delivery, patient safety, and preventing unnecessary treatment. The policies we are finalizing in this rule are intended to improve the transparency and efficiency of the process.

Regarding suggestions for us to implement broader policy changes for prior authorization, we acknowledge that Federal policies alone cannot control all payer specific processes or patient health outcomes. Policies must be applied with good medical judgment and review, and we reiterate that we, in the administration of its programs and implementation of programmatic authority, continue to evaluate opportunities for future rulemaking to alleviate burdens, mitigate harm, and improve patient care. For example, in the CY 2024 MA and Part D final rule (88 FR 22120), we finalized several provisions to ensure that utilization management tools, including prior authorization requirements, are used in ways that ensure timely and appropriate access to medically necessary care for beneficiaries enrolled in MA plans. Specifically, we explained current rules related to acceptable coverage criteria for basic benefits that require MA organizations to comply with national coverage determinations (NCDs), local coverage determinations (LCDs), and general coverage and benefit conditions included in Traditional Medicare regulations. In addition, under new regulations adopted in that final rule, when coverage criteria are not fully established, MA organizations may create internal coverage criteria based on current evidence in widely used treatment guidelines or clinical literature made publicly available to us, enrollees, and providers. The CY 2024 MA and Part D final rule also streamlines prior authorization requirements, including adding continuity of care requirements and reducing disruptions for beneficiaries. First, we finalized that prior authorization policies for coordinated care plans may only be used to confirm the presence of diagnoses or other medical criteria that are the basis for coverage determinations and/or ensure that an item or service is medically necessary based on standards specified in that final rule (see 42 CFR 422.138(b)). Second, we finalized that for MA coordinated care plans, an approval granted through prior authorization processes must be valid for as long as medically necessary to avoid disruptions in care in accordance with applicable coverage criteria, the patient's medical history, and the treating provider's recommendation, and that plans provide a minimum 90-day transition period when an enrollee who is currently undergoing an active course of treatment switches to a new MA plan or is new to MA (see 42 CFR 422.112(b)(8)). Finally, to ensure prior authorization and other utilization management policies are consistent with CMS rules, we finalized a requirement that all MA plans that use utilization management policies must establish a Utilization Management Committee to review all utilization management policies, including prior authorization, annually and ensure they are consistent with regulatory standards for MA plan coverage, including compliance with current, Traditional Medicare's NCDs and LCDs (see 42 CFR 422.137).

a. Compliance Dates

We proposed compliance dates for most impacted payers in 2026 (by January 1, 2026, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2026, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2026, for QHP issuers on the FFEs). There was one exception for some of the Medicaid FFS fair hearing and notice requirements, as discussed in the CMS Interoperability and Prior Authorization proposed rule (87 FR 76299 and 76300), which would take effect upon the effective date of this final rule.

Based on commenter feedback, we are extending the compliance dates for the Prior Authorization API for all impacted payers consistent with the compliance dates for the Provider Access and Payer-to-Payer APIs to 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs). Throughout this rule, we generally refer to these compliance dates as “in 2027” for the various payers. The prior authorization business process improvements, or those provisions that do not require API development or enhancement, including the requirement to communicate a specific reason for a denial, reduced decision timeframes for standard and expedited prior authorization decisions, and public reporting of certain prior authorization metrics are being finalized as proposed with a compliance dates in 2026 (by January 1, 2026, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2026, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2026, for QHP issuers on the FFEs). Throughout this rule, we generally refer to these compliance dates as “in 2026” for the various payers.

We received comments on the compliance dates for both the Prior Authorization API and process improvement proposals that do not require API development or enhancement. Overall compliance timeline comments are addressed in greater detail in section I.B. of this final rule. In this section, we discuss comments more specifically related to the Prior Authorization API and process improvement policies.

Comment: Multiple commenters recommended that CMS require the shortened prior authorization decision timeframes earlier than 2026, with some noting that payers, specifically MA organizations, already have the technological capability to implement these new decision timeframes in 2024. These commenters did not provide additional context for the reference to technological capabilities. Other commenters recommended that CMS should require compliance with all requirements that are not contingent on implementation of the Prior Authorization API by January 2025 (for example, decision timeframes, providing specific denial reasons, and reporting of metrics). Commenters said payers should not have trouble adapting their processes to meet the requirements related to decision timeframes and communication with patients and providers by that date, and that patients and providers should not have to wait any longer to benefit from the proposals in this rule. Other commenters cited reasons for implementing the Prior Authorization API proposal as soon as possible or in 2024 or 2025, such as to ensure that bidirectional flow of electronic prior authorization information is fully operational by January 1, 2026 and to protect patients from delays in, and restricted access to, cancer care.

Other commenters indicated that transitioning to use the API-facilitated process for prior authorization will require significant development and implementation efforts. A commenter explained that developers would need 12 to 18 months following publication of the final rule to design, develop, test, and release updated software. The commenter went on to state that payers would likely need this same amount of time following publication of the final rule to build their specific coverage and prior authorization criteria and rules into the system for each of their impacted health plans for the Prior Authorization API. This commenter explained that providers and payers will also need time to work together to reconcile variances in the FHIR implementations to ensure that they can engage in accurate exchange of prior authorization information.

Response: We appreciate the comments in support of the proposed compliance dates in 2026 for the business process improvement provisions of the CMS Interoperability and Prior Authorization proposed rule that do not require API development or enhancement, specifically the requirement to communicate a specific reason for a denial, reduced decision timeframes for standard and expedited prior authorization decisions, and public reporting of certain prior authorization metrics. We are finalizing those compliance dates for those new requirements in this final rule. We agree that those prior authorization process improvements will initiate burden reductions and support both payers and providers.

Although there are several early implementations and pilots of the Prior Authorization API in place today, it is important to take into account the capabilities of all payer types and sizes to implement the requirements of the Prior Authorization API, including internal resource allocation for implementation and testing. All payers must identify relevant prior authorization coverage criteria and rules and program these criteria and rules into the appropriate format for the API in accordance with the IG. Subsequent programming and testing for the questionnaires within the API must take place to ensure functionality. To accommodate these development efforts, CMS is finalizing 2027 compliance dates for the Prior Authorization API. The compliance timeframe should enable the industry to establish a strong technical framework to support the development and scalability of the API-based solution. We anticipate that this timeframe will provide more time for development and testing to enable the integration of the Prior Authorization API between payers, providers, and EHR developers. Additional time for the API implementation also supports state efforts to process the extraordinarily high volume of renewals and other eligibility and enrollment actions that need to be conducted following the end of the Medicaid continuous enrollment condition at section 6008(b)(3) of the Families First Coronavirus Response Act (FFCRA), which has consumed both staff and technical resources.

2. Requirement Tto Implement an API for Prior Authorization

a. Prior Authorization API

To help address prior authorization process challenges and continue our roadmap to interoperability, we proposed that certain payers implement and maintain a PARDD API to be used by providers to facilitate the prior authorization process. As we explained in section I.B. of this final rule, for consistency with the naming conventions of the other APIs, we have elected to finalize the name of this API to the Prior Authorization API rather than the PARDD API. The purpose of the API is to support the full prior authorization process, as described in the CMS Interoperability and Prior Authorization proposed rule. We believe this revised name best reflects that purpose in this final rule.

In this section, we are finalizing policies to improve the prior authorization process between payers and providers using a Prior Authorization API. The purpose of the API is to streamline the process and ensure that payers use technology to provide more useful information about when and how to obtain a prior authorization and the status of an approved or denied prior authorization.

In the CMS Interoperability and Prior Authorization proposed rule, we discussed the anticipated benefits of the Prior Authorization API and explained how this API would automate certain tasks, thereby mitigating some of the obstacles of the existing process. We stated that the API would allow a provider to query the payer's system to determine whether prior authorization was required for certain items and services and identify documentation requirements. The Prior Authorization API would send the prior authorization request from the provider's EHR or practice management system to the payer. In this final rule, we are finalizing the requirement to use certain standards and making recommendations to use certain IGs to support development of the FHIR API. Use of the Prior Authorization API will enable automation for the prior authorization request and response within the clinical workflow of the provider. The IGs and relevant standards, which are discussed in section II.G. of this final rule, serve as the instructional manuals for the functional capability of the API. When operational, the API enables a provider to submit a request about a medical item or service, determine if additional information is required, submit that information, and additionally assemble the necessary information to submit a prior authorization request. The response from the payer must indicate whether the payer approves (and for how long) or denies the prior authorization request or requests more information from the provider to support the request.

To support the implementation and maintenance of the Prior Authorization API, we are requiring certain standards and recommending certain IGs, as discussed elsewhere and in section II.G. of this final rule. With the publication of the HTI–1 final rule (89 FR 1192), our cross references to 45 CFR 170.215 have been updated to reflect the updated citations as needed. Changes to the structure of 45 CFR 170.215 and versions of the API standards codified there are discussed further in section II.G. of this final rule and reflected throughout this final rule. For the Prior Authorization API, impacted payers must use the following standards: HL7 FHIR Release 4.0.1 at 45 CFR 170.215(a)(1), US Core IG STU 3.1.1 at 45 CFR 170.215(b)(1)(i), and SMART App Launch IG Release 1.0.0 at 45 CFR 170.215(c)(1). Impacted payers are permitted to voluntarily use updated standards, specifications, or IGs that are not yet adopted in regulation for the APIs discussed in this final rule, should certain conditions be met. For the standards at 45 CFR 170.215 required for the Prior Authorization API, updated versions available for use under our policy include, but are not limited to, US Core IG STU 6.1.0 and the SMART App Launch IG Release 2.0.0, which have been approved for use in the ONC Health IT Certification Program. We refer readers to section II.G.2.c. of this final rule for a full discussion on using updated standards. We are also recommending payers use the CRD IG STU 2.0.1, HL7® FHIR® Da Vinci Documentation Templates and Rules (DTR) IG STU 2.0.0, and PAS IG STU 2.0.1. We refer readers to Table H3 for a full list of the required standards and recommended IGs to support API implementation.

Comment: Many commenters supported the proposal to require impacted payers to implement and maintain a Prior Authorization API to improve automation of the prior authorization process. Many commenters stated that the API has the potential to support the needed transition to electronic prior authorization. Commenters also stated that the Prior Authorization API would reduce the burden for providers and speed up the prior authorization process for patients to improve care and access treatment options. A commenter stated that the API would offer much-needed transparency for rural providers around the prior authorization process. Other commenters stated that the API would potentially replace old ways of conducting the prior authorization process and give way to new ways of conducting prior authorization and explained that the prior authorization provisions laid out in the CMS Interoperability and Prior Authorization proposed rule could provide a good return on investment for payers. Multiple commenters supported CMS's efforts to implement a standardized API that makes payers' prior authorization and other documentation requirements electronically accessible to providers and that supports a more streamlined prior authorization request and response process. Multiple commenters believe this change will offer many benefits for patients and providers, including increasing access to care for patients and increasing providers' understanding of prior authorization requirements by providing upfront information about which services require prior authorization and what type of documentation is required to support approval of a prior authorization request; and increasing automation in the submission, receipt, and processing of requests, which could support more timely responses. Commenters also stated that this automation will help decrease administrative costs and that the Prior Authorization API would improve the efficiency of providing services to patients due to the request and response being automated and in real-time, as well as the quality of patient care. A large group of commenters expressed their support for the proposed requirement for payers to implement the Prior Authorization API because it will make their physical therapy businesses more efficient and allow them to focus on treating patients.

Response: We agree that these policies will serve to mitigate some of the burdens that exist in the prior authorization process today. This is the reason we are finalizing a modification to the compliance dates. Our proposal did not include a requirement for the Prior Authorization API to provide real-time processing of the prior authorization request, but we agree that incorporating a level of automation and facilitating electronic prior authorization processing could improve processing timelines in the future. Though we anticipate that some of the responses or decisions potentially may be made in real-time, other decisions will continue to necessitate review and evaluation by clinical staff. The complete automation of a complex process such as prior authorization is an ongoing process of continuous improvement.

Comment: Multiple commenters stated that the Prior Authorization API would not do enough to resolve existing issues surrounding prior authorization burden and turnaround times. A commenter stated that the amount of data to be transmitted and used by payers and providers through the API is burdensome and impractical. This commenter wrote that the continued transmission of medical information from non-FHIR systems (for example, administrative transactions) will require payers to translate such information into a format that is useable for the Prior Authorization API, which would only shift the manual prior authorization burden, not alleviate it. The commenter stated it is important to maintain industry flexibility around prior authorization to continue industry innovation in interactive decision-making processes with providers to ensure the best care experience possible for patients. Multiple commenters expressed concern that the required implementation of the Prior Authorization API might increase the burden for both providers and payers. A commenter expressed concerns that what time may be saved through the API may end up being redirected to maintain the API, field questions from patients and providers, and support external development when requests are incomplete, which may even require a dedicated team to answer provider questions throughout the electronic prior authorization lifecycle. This commenter provided insight into their experience with their current online portal and provider submissions of prior authorizations, and continued reliance on electronic faxes. A commenter expressed concerns that the maintenance of the API will also place significant burdens on payers to translate all coverage criteria to questions suitable for the electronic prior authorization process and to keep such information up to date. Another commenter also stated that the work involved in identifying all policies and authorization processes that would be included in the Prior Authorization API will be a significant effort as it will require significant resources, staff, and time.

Response: We acknowledge concerns about the new technology and processes associated with the Prior Authorization API, including implementation challenges, potential conflicts with existing workflows, and increased workload for initially implementing the Prior Authorization API. Payers will need to identify the policies, conduct the analysis, and do the necessary programming for the next few years. Providers will also experience an initial implementation and data collection burden associated with translating records into FHIR-compatible formats. It is in part based on these considerations that we decided to modify our proposed compliance dates so that the impacted payers and providers alike will have sufficient time to conduct testing on the newly structured prior authorization process. We disagree with commenters who indicated that the Prior Authorization API would not do enough to resolve existing issues surrounding prior authorization burden and turnaround times, and with those who were concerned that the transmission of medical information from systems would shift the prior authorization burden to manual processes rather than alleviate it. The benefits of using an electronic prior authorization process improve the manual and burdensome process used today. Making the prior authorization process electronic will reduce the time and burden associated with the current process, allowing providers to put time back into direct patient care, and ultimately will reduce provider burnout. Once the Prior Authorization API is in place and a provider can connect to a payer's system using that API, the manual effort for both payers and providers should decrease because clinical and administrative staff will be able to leverage the technology to conduct a more streamlined process for submitting prior authorization requests. Payers should be able to shift resources to review the requests more efficiently. While payers may have their policies documented, these are not in any standard formats, nor are they readable in any structured way. Providers must often download documents from different portals and then interpret them individually. The API will centralize and automate this process for both payers and providers. Further, we have included several significant policies that do not require API development or enhancement in this final rule, one of which relates to shortening the deadline by which impacted payers must respond to prior authorization requests from providers. The policies being finalized in this rule have been developed over time with input from providers, payers, and patients to address the technical and operational issues described to us as the most significant issues in the prior authorization process.

b. FHIR Implementation Guides

In the CMS Interoperability and Prior Authorization proposed rule, we proposed to require the use of certain technical specifications (that is, IGs adopted as implementation standards) adopted at 45 CFR 170.215 (87 FR 76239). We also proposed that the same documentation requirements and discontinuation and denial of access standards as we proposed for the Patient Access API (discussed in section II.A.2. of this rule), the Provider Access API (discussed in section II.B.2. of this rule), and the Payer-to-Payer API (discussed in section II.C.3. of this rule) would apply to the Prior Authorization API. Additionally, for the Prior Authorization API, we specifically recommended using certain FHIR IGs that have been developed to support the functionality of the Prior Authorization API. These IGs are as follows:

• The CRD IG
• The DTR IG
• The PAS IG

These three IGs are designed to be used by the payer, or implementer, to develop and implement the Prior Authorization API. The IGs undergo regular development and testing to support implementation and use of the Prior Authorization API and to improve the API's functionality in support of an improved prior authorization process. Technical information and website access are provided in section II.G. of this final rule.

The first IG recommended for use to develop the Prior Authorization API is the CRD IG. As described on the HL7 web page, the CRD IG defines a workflow to allow payers to provide information about coverage requirements to providers through their clinical systems. Use of this IG improves the transparency of specific coverage rules specific to the patient and the provider based on the payer's prior authorization policies, and, when implemented, provides decision support to providers when they are ordering services. This is the first stage of the process for determining whether authorization is required for certain items or services. The CRD IG provides the functionality to enable the API to inform the provider if a prior authorization is required, and information about the payers' prior authorization coverage rules, so the provider knows what information is necessary to support a request. The functionality of the CRD may return a decision to the provider if there is sufficient information and the payer supports early determinations.

The second IG recommended for use by payers to develop the Prior Authorization API is the DTR IG. On the HL7 IG web page, the description explains how this IG specifies how payer rules can be executed in a provider context to ensure that documentation requirements are met. This IG is a companion to the CRD IG. Its purpose is to automate the process of assembling documentation to support a prior authorization request for a specific payer. The instructions will allow the provider to download questionnaires and populate them automatically with information from the EHR or other systems for the completion of documentation requirements needed to demonstrate medical necessity for a proposed item or service, based on payer rules. The DTR IG enables the return of completed templates with specific FHIR resources identified as required to support the medical necessity of the service or item that is being requested for a prior authorization. This process replaces the need to manually request, gather, and submit documentation.

The third IG recommended for the Prior Authorization API is the PAS IG. On the HL7 web page, the description explains that the PAS IG enables direct transmission of prior authorization requests (and can request/receive immediate authorization) from within EHR systems using the FHIR standard and that it can create the mapping between FHIR and HIPAA compliant X12 transactions. The PAS IG ensures that the API takes the information from the CRD and DTR and allows provider systems to send (and payer systems to receive) requests using FHIR. Providers and payers can still meet separate regulatory requirements, where required, to use the X12 278 transaction standard for prior authorization(s) to transport the prior authorization request and response. The PAS IG is the basis for: (1) assembling the information necessary to substantiate the clinical need for a particular treatment; and (2) submitting the assembled information and prior authorization request to an intermediary before it is sent to the intended recipient. As these IGs have been expanded and improved, the workgroup has enhanced the graphic display depicting the workflow and made it available on the HL7 website.

Most importantly, use of the instructions from the IG and the API provides the necessary information about the status of the prior authorization request—the response indicates whether the payer approves (and for how long) or denies (and the reason) the prior authorization request, or requests more information from the provider to support the prior authorization request. The PAS IG also defines capabilities around the management of prior authorization requests, including checking on the status of a previously submitted request, revising a previously submitted request, and canceling a request. Section II.G. of this final rule provides additional discussion of both the required and recommended standards and IGs to support the Prior Authorization API.

Comments regarding requiring versus recommending the IGs, maturity of the IGs, and technical implementation challenges are addressed in section II.G. of this final rule. For example, commenters recommended that the FHIR IGs should be required rather than recommended, as merely recommending the IGs would lead to an additional burden for both payers and providers as they may use varied implementations of the required APIs that would ultimately reduce interoperability. We also received multiple comments about technical implementation challenges and the maturity of the recommended IGs. Technical comments such as these are addressed in section II.G. Here we respond to the comments specific to the standards and IGs for implementation of the Prior Authorization API.

Comment: Multiple commenters recommended that CMS and HL7 ensure the recommended CRD, DTR, and PAS IGs are fully tested before the effective date of the final rule, as the IGs have not been adequately or widely tested in real-time clinical settings. The commenter noted that these IGs have data elements and processes that are listed as optional despite their utility for automation. Another commenter cautioned that the IGs have several data elements and processes that are optional, which means payers could meet decision requirements with vague responses, hence jeopardizing CMS's prior authorization reform goal. Multiple commenters supported using the PAS IG and stated that the IG is well-positioned to support the development of the proposed Prior Authorization API. A commenter noted that many of the proposed requirements are covered in the PAS IG STU 2.0.0, which is targeted for publication in calendar year 2023. The commenter continued by stating that based on functional requirements, additional updates can be made to the IG to ensure it fully supports the proposed Prior Authorization API once finalized in preparation for compliance in 2026. However, other commenters expressed some concerns about recommending these IGs. Multiple commenters noted that hospitals and insurers may need to use more than one technology solution to participate and track activity using the Prior Authorization API. A commenter expressed concern with the proposed IGs, which seem to require fast responses, within 5 seconds, and encouraged CMS to monitor technical standards as they are developed to avoid excessive burdens that the agency did not intend to create.

Response: CMS is recommending the three IGs to implement the Prior Authorization API. These IGs, the CRD, DTR, and PAS IGs, were created to be used together to provide implementation flexibility. Several optional or “situational” elements were included in these guides as a means to connect them in a single workflow while allowing for the decoupling of these processes where necessary. For example, the CRD IG might be used to develop an API specific to prior authorization coverage requirements, and a separate API, linked to that one, built using the DTR IG. Some hospitals and providers will need more than one technology solution to connect to the payer's Prior Authorization API endpoint based on the architectures and systems of the provider organization. Impacted payers and providers may have separate and unconnected systems that address coverage and eligibility, documentation, and prior authorization. Since publication of the CMS Interoperability and Prior Authorization proposed rule, updated versions of the CRD, DTR, and PAS IGs have all been published. We refer readers to Table H3 for the required standards and recommended IGs to support API implementation.

In response to the specific comment about implementation strategies, we refer implementers to the HL7 Da Vinci workgroups for technical guidance; however, we understand that payers may need to pull multiple technology solutions together to meet the overall Prior Authorization API requirements. Concerning the response time of 5 seconds, which is near real-time, we anticipate that most systems can accommodate this communication exchange when the information is available. The PAS IG has a recommended synchronous response time of 15 seconds. Instructions are available in the IG for how systems should respond in a timeframe with the best possible information. For further technical details, we encourage interested parties to reach out to the appropriate HL7 workgroups.

Comment: Multiple commenters stated that there are potential technological challenges for the implementation of the Prior Authorization API. A commenter noted that the proposed rule does not specify what technology hospitals need to support or implement the API, nor what technology is needed to track participation or be required to participate in the API once finalized. This commenter noted that providers will be using the Prior Authorization API without any meaningful testing. Another commenter noted that they currently offer providers an option to submit electronic prior authorizations through an online portal, but utilization is low as most providers still favor fax as their preferred method to send prior authorizations, and portal prior authorizations often require corrections to incorrect data entries.

Multiple commenters said CMS should do more to support the implementation of the Prior Authorization API. A commenter supported regulatory efforts to require payers to build APIs to automate prior authorization, but questioned whether the CMS Interoperability and Prior Authorization proposed rule goes far enough to accomplish that goal. Another commenter noted that the Prior Authorization API will require payers, providers, and vendors to connect but noted that multiple infrastructure challenges will have to be resolved to ensure API implementation success and cited the work of the HL7 FAST Accelerator to identify and address scalability issues to avoid duplication of efforts, including security and authentication.

Response: The regulations we are finalizing in this rule require impacted payers to implement a Prior Authorization API, and providers are encouraged to use the technology in their CEHRT to take advantage of the improvements in prior authorization processes that will be available through use of the Prior Authorization API. As we noted in the proposed rule, HL7 launched an implementation division in 2021, specifically to provide support for implementers, including education and technical support. This division will provide payers, providers, and vendors with access to information about the types of technology and software that will address implementation, education, and testing of the standards, IGs, and APIs. Furthermore, the HL7 workgroups, which are open to the public, continue to be the best resources to learn about implementation. We will continue to work with associations, developers, and HL7 on identifying or supporting the development of appropriate resources for education.

The HL7 FAST Accelerator is addressing the scalability issues of the FHIR standard through its work on security and the directory IGs. We and ONC participate in the HL7 FAST Accelerator and will monitor progress on the IGs being developed by that project.

The policies in this final rule are an important component of the overall CMS strategic plan to reduce burden, advance interoperability, and improve patient care. This rule finalizes significant changes to improve the patient experience and alleviate some of the administrative burden by applying policies which address both technical and process barriers. These policies represent foundational regulatory steps toward addressing the longstanding challenges of prior authorization.

Comment: A commenter, writing from the provider perspective, stated that the Prior Authorization API would complicate clinical and administrative workflows by requiring some combination of staff time and additional technological advances and recommended the FHIR API be combined with the HIPAA transaction standard.

Response: We do not agree that using the Prior Authorization API will complicate clinical work. Rather, time will be saved across all personnel tasks, including researching the requirements for prior authorization across multiple payers, entering information into systems, submitting requests, processing approvals, or determining next steps if a denial is received. The Prior Authorization API is capable of conducting the prior authorization request as a FHIR only data exchange, or in combination with the HIPAA transaction standard.

Comment: Multiple commenters urged CMS to name the CDex IG as one of the recommended IGs to use in support of the Prior Authorization API and stated that it is a critical part of burden reduction and plays an important role in supporting FHIR prior authorization transactions as proposed. To support the attachments for the Patient Access, Provider Access, and Payer-to-Payer APIs, as well as the supporting documentation requirements for the Prior Authorization API, this IG provides the instructions to enable the exchange of structured documents —meaning those which could be read and interpreted by a computer. This functionality to attach documents to support a prior authorization is currently missing from the other FHIR IGs and standards. A commenter stated that the PAS IG could support existing Federal and state requirements to exchange attachments if implementers also added the functionality of using the CDex IG. Use of this IG would further support efficiencies in the prior authorization process.

Response: We are aware that early adopters have begun testing with the CDex IG for attachments to advance additional use cases for the Prior Authorization API. This final rule does not address standards for attachments and does not prohibit using the CDex IG or other attachment standards.

c. Implementation, Automation, and Other General Considerations for the Prior Authorization API and Processes

We proposed and are finalizing requirements for impacted payers to implement a Prior Authorization API to improve the prior authorization process. The policy would require use of new standards for some impacted payers and some changes in procedures. We received comments on the use of new standards, technology, and automation with considerations for implementation and have grouped them here.

Comment: A commenter stated that they support the proposed requirements for the Prior Authorization API; however, they believe much more needs to be done to achieve the CMS objectives for this policy. Multiple commenters shared potential concerns and challenges with the implementation of a Prior Authorization API. A commenter wrote that the Prior Authorization API use case will not work without provider participation, as the API requires bidirectional exchange between impacted payers and providers. A commenter expressed concern regarding the resource development needed for providers and noted this needs to be more widely understood before the implementation of the Prior Authorization API. The commenter recommended CMS work with interested parties to ensure practices can utilize and leverage this API. The commenter encouraged CMS to work with ONC to extend the applicability of the Prior Authorization API requirements to providers and EHR vendors to ensure technical readiness and enable greater adoption of the Prior Authorization API and electronic prior authorization. A commenter suggested that CMS require plans to provide to each contracted physician, upon request and regardless of their use of the API, the references to the clinical research evidence that underlie medical policy determinations when they approve or deny a service. The commenter noted that some physicians may not be able to adopt these systems by the compliance dates.

Response: We are finalizing compliance dates in 2027 for payers to implement the Prior Authorization API which should provide sufficient time for payers to implement the APIs, collaborate with EHR vendors to support appropriate connections for their providers, and develop outreach materials. Ongoing pilots demonstrate that payers and providers can implement the necessary infrastructure by those compliance dates. While providers are not required by this final rule to use the Prior Authorization API, in section II.F. of this final rule we are incentivizing providers to use this API by finalizing new electronic prior authorization measures for MIPS eligible clinicians under the MIPS Promoting Interoperability performance category and for eligible hospitals and CAHs under the Medicare Promoting Interoperability Program. To promote Prior Authorization API adoption, implementation, and use among MIPS eligible clinicians, eligible hospitals, and CAHs, we are adding a new measure titled “Electronic Prior Authorization” under the HIE objective in the MIPS Promoting Interoperability performance category and the Medicare Promoting Interoperability Program, beginning with the calendar year (CY) 2027 performance period/2029 MIPS payment year and CY 2027 EHR reporting period. There could be many benefits for providers for improvements in the prior authorization process, and we encourage all providers to evaluate whether use of the Prior Authorization API could benefit their practices. Payers should also encourage providers in their network to use the Prior Authorization API, given that it could be timesaving for both parties, and we anticipate that many payers will begin education and awareness campaigns as more pilots are launched and/or payer APIs are readied for testing. We are monitoring the activities of existing pilots and receiving positive reports from participants. ONC may consider developing and making available additional criteria for EHR certification for electronic prior authorization in future rulemaking.

We did not propose to specifically require payers to make available the references to the clinical research evidence that underlie medical policy determinations when they approve or deny a service, but we did propose that when an impacted payer denies a prior authorization request, the payer must include a specific reason for that denial in a notice to the provider who requested the prior authorization. See section II.D.3. regarding that proposal and the final policy. While we do not oversee contract provisions between payers and providers, the CY 2024 MA and Part D final rule (88 FR 22120) finalized a new requirement at 42 CFR 422.101(b)(6) for MA plans to make certain information about their internal coverage policies publicly accessible, including a list of the evidence considered in developing the internal coverage criteria; that final rule also limits using internal coverage criteria for Part A and Part B benefits to when coverage criteria are not fully established in Medicare statute, regulation, NCD, or LCD. We anticipate this information, along with the requirement that MA plans provide a reason for denying a request for prior authorization (at 42 CFR 422.122 as adopted here and currently in existing 42 CFR 422.568(e)) will address the commenter's concern about access to clinical research and evidence supporting denials of coverage in the MA program. In addition, the CY 2024 MA and Part D final rule adopted a new regulation, at 42 CFR 422.137, that requires a Utilization Management Committee to annually review the policies and procedures for all utilization management, including prior authorization, used by the MA plan, and a new regulation at 42 CFR 422.138 that limits how prior authorization may be used by certain MA plans. Per 42 CFR 422.138, coordinated care MA plans (for example, Health Maintenance Organization [HMO], Preferred Provider Organization [PPO], and point-of-service [POS] plans) may only use prior authorization to confirm the presence of diagnoses or other medical criteria that are the basis for coverage determinations for the specific item or service and to ensure that the requested item or service is medically necessary (for Part A and B benefits) or clinically appropriate (for supplemental benefits). Finally, we remind readers that MA regulations at 42 CFR 422.202(b) and 422.136(a) require MA organizations to provide education and outreach about utilization management policies and engage in consultation with contracted providers.

Comment: Multiple commenters discussed automating prior authorizations, and many were in support of automation, providing technological suggestions for automation of the prior authorization process. A commenter stated that, for prior authorization forms, specific clinical questions require answer formats that are easily understood and automated by a computer. Another commenter described how payers might automate the prior authorization process by utilizing existing matrices to create algorithms that would be able to review a large proportion of their prior authorization requests. A commenter noted that deep learning AI methods for submitted clinical data could be used to inform the review and electronic prior authorization approval process to expedite a decision that simulates a consensus of expert human judgment.

Multiple commenters recommended that CMS explore automating service “bundle” prior authorizations for instances where one episode of care needs multiple prior authorizations (for example, a knee replacement surgery), as this would help ease administrative burden and reduce delays in patient care.

Response: We are closely following the level of interest in the types of automation that might be brought to bear on the prior authorization process, particularly around the infrastructure for communications, and the innovative thinking shared in the public comments. While CMS did not directly address using AI for purposes of implementing the prior authorization policies, or any provisions of this final rule, we encourage innovation that is secure; includes medical professional judgment for coverage decisions being considered; reduces unnecessary administrative burden for patients, providers, and payers; and involves oversight by an overarching governance structure for responsible use, including transparency, evaluation, and ongoing monitoring. We also reiterate that impacted payers must comply with Federal and state policies and the requirements of the standards and recommended IGs in implementing these APIs. We encourage these and other individuals to participate in the HL7 IG development groups to share these ideas with the drafters of the IGs to further refine their functionality.

Comment: Multiple commenters recommended that CMS include additional requirements for payers. A commenter recommended that CMS require payers to offer their electronic prior authorization system at no cost to providers. Multiple commenters stated that health plans should be required to provide a web-based interface for providers and patients with a standardized, easy-to-use web page with an up-to-date database that quickly indicates whether prior authorization is required. The commenter stated that this web page should include prior authorization rules and medical policies. A commenter requested that the required response to the query on the online database include the following data points: transaction ID, group or member ID, date of service, prior authorization required, instructions, and a medical policy link. A commenter recommended that, in the case of a technical glitch with the prior authorization process, insurance plans should develop a backup system.

Response: We did not specifically address whether payers could charge providers for use of or access to the Prior Authorization API. We would encourage payers not to charge additional costs beyond those that may exist to conduct prior authorization business functions today, including the costs of conducting transactions. We do not anticipate that fees would be charged for use of the API or other services required by this final rule, but are aware that payers will be funding their own development and vendor related costs.

Concerning the specific functionalities commenters requested be available through portals, online systems, or the API, such as easy-to-use web pages with an up-to-date database that quickly indicates whether prior authorization is required or what the medical policies are, we reiterate that payers are required to implement a Prior Authorization API that allows a provider to query a payer's system to determine whether a prior authorization is required, to identify documentation requirements, and to receive information about whether a specific prior authorization request has been approved or denied. As part of fulfilling these required functions, information about the policies and how they have been developed may be available, but we understand that the level of additional information and detail about the development of prior authorization and coverage policies could vary by payer. There may be other connected systems and resources available with information about the medical policies that are associated with the Prior Authorization API to which the provider will be able to refer to understand how decisions are being made for certain items and services. Furthermore, under existing Federal and state laws, such as the HIPAA Privacy and Security Rules, administrative, technical, and physical safeguards policies and procedures must be in place to ensure that systems have effective backup controls to protect access to patient data during planned and unplanned downtime. We would expect impacted payers to already have such procedures in place for reliable backup systems.

Comment: Multiple commenters noted that payers will have to digitize their prior authorization policies to meet the Prior Authorization API requirements, which will be difficult and time-consuming. Multiple commenters noted that payers may be concerned that if a significant amount of their providers do not adopt the new prior authorization API process, the payer will not receive the full benefit of their investment.

Response: We acknowledge that payers will have to digitize their prior authorization policies to meet the API requirements. Several organizations have implemented the Prior Authorization API as pilot projects or as part of the Da Vinci Exception Project, and we are aware that implementation of the API requires a significant investment of resources. We also recognize that the full benefit of the API will be achieved when providers use the API to request information about prior authorization requirements and change existing workflow patterns. The changes for both payers and providers will maximize the return on investment from the new electronic exchange. We encourage other impacted payers to engage with these early implementers to learn from their experience and to begin evaluating their policies to understand the level of effort that will be required within their organizations. To support the analysis, implementation, and testing, we are also finalizing compliance dates that are a year later than we proposed to provide additional time for the necessary work to implement the Prior Authorization API and to conduct outreach and education to the provider community.

Comment: A commenter recommended that CMS include a Prior Authorization API opt out policy and another commenter recommended that CMS explain providers' responsibilities related to communicating patients' right to opt out of the Prior Authorization API and their responsibility to notify the payer of that decision.

Response: Prior authorization is an administrative process between a payer and provider that is conducted almost completely electronically today with no direct burden on the patient. We would anticipate that an individual who wishes to obtain medical services expediently might wish for their provider to use the most efficient resource available to them. The opt out/opt in rules that we are finalizing in this rule are for the Provider Access and Payer-to-Payer APIs' data exchange requirements, discussed in sections II.B. and II.C., and do not apply to the Prior Authorization API. While this final rule does require impacted payers to develop and implement the Prior Authorization API, this rule does not require providers to use the API. As discussed in section II.F., this final rule does include policies regarding using the Prior Authorization API for the Promoting Interoperability performance category of MIPS and the Medicare Promoting Interoperability Program. As many providers are currently conducting these processes through EHRs in the office, with the patient present, we would encourage providers to explain any activity to the patient, as is being done for any electronic transaction, including electronic prescribing, lab orders, and scheduling. We also anticipate that providers would want to use a process in which their EHR or other medical record systems are capable of connecting with the APIs and exchanging certain data and documents using FHIR standards. At a minimum, the Prior Authorization API will provide a means for providers to identify the prior authorization requirements for the impacted payers, which will save time and burden associated with having to research those requirements manually. We do not believe it is necessary to add a new opt out process for patients regarding prior authorization. These are administrative tasks already in place in provider offices. We reiterate that providers are not required by this rule to use the Prior Authorization API.

Comment: Multiple commenters discussed prior authorization criteria and specifically referenced the CY 2024 MA and Part D final rule for the enhancements it provides for prior authorization requirements. A commenter requested that CMS require payers to make their prior authorization criteria public in advance of the publication of this final rule and to ensure that physicians with expertise in the services are involved in their development. Other commenters requested that CMS ensure that prior authorization criteria be peer-reviewed. A commenter wrote that the Prior Authorization API will increase transparency into payer prior authorization criteria, and another noted that using an electronic data exchange could improve the accuracy of prior authorization determinations. A few commenters wrote that the solution to prior authorizations must include both an expedited prior authorization process as well as appropriate clinical decision-making, particularly with treatment guidelines supported by clinical evidence. Another commenter stated that the Prior Authorization API could specifically speed up the process of prior authorization for key treatments of gynecologic cancers. Commenters noted that the increased transparency will include better timing for responses and accuracy for treatment protocols subject to prior authorization.

Response: We agree that if the API can enhance provider understanding of the requirements for requesting a prior authorization, a provider's ability to submit a complete and accurate request electronically will be improved and the manual intervention needed to collect additional information reduced. This transparency in requirements and criteria should improve communication between payers and providers during the prior authorization process, which is a core element of the functionality of the Prior Authorization API. We also appreciate comments suggesting that prior authorization criteria should be peer-reviewed and include appropriate clinical decision-making information with treatment guidelines that are supported by clinical evidence. Use of such clinical evidence is helpful to reviewers when creating care treatment plans and evaluating prior authorization requests. We have also heard from many payer organizations that aligning with clinical guidelines is part of their process when establishing prior authorization criteria and we encourage this practice for all payers. We did not make specific proposals related to developing prior authorization criteria, but acknowledge the value of such clinical involvement.

We also note that the provisions in this final rule on prior authorization will work with several of the utilization management and prior authorization policies in the CY 2024 MA and Part D final rule to further CMS's overall goals of improving prior authorization processes to serve the needs of payers, providers, and patients. We encourage readers to review that rule as well (88 FR 22120) to have a greater understanding of the limits on how MA organizations may use and implement prior authorization.

Comment: Multiple commenters discussed the need for APIs to be integrated with EHR systems. A commenter expressed concern that current EHR systems will not be set up to accommodate the requirements of this rule. Another commenter noted that an obstacle to the effective implementation of the Prior Authorization API is the lack of standardized coding and structured data in provider EHRs to support adjudication of a prior authorization request. The commenter stated that it will be important for EHR clinical data to be standardized to successfully adjudicate prior authorization requests through API interfaces.

Response: We appreciate comments about standardization and the need for providers and EHR system vendors to address consistency in the coding of medical records for interoperable data exchange. Such comments do not reflect a technical readiness issue for the Prior Authorization API or the standards but rather an industry readiness to meet the requirements to enable and automate prior authorization processes. Over the next few years, both provider management systems, as well as certified EHRs, will advance in their use of standards, data exchange, and connectivity. Implementation of a content standard at 42 CFR 170.213 (USCDI) for all data classes and data elements will support communication about medical records will reduce the variation in medical record coding, increase structured data, and support the ability for interoperable data exchange. The IGs that support the Prior Authorization API provide the framework for exchanging standard information between the payer and provider systems.

We note that ONC previously sought comment on how updates to the ONC Health IT Certification Program could support electronic prior authorization through an RFI titled “Electronic Prior Authorization Standards, Implementation Specifications, and Certification Criteria” (87 FR 3475), which appeared in the January 24, 2022, issue of the Federal Register . The Unified Agenda, current at the time of this final rule's publication, includes an entry for a proposed rule from ONC entitled “Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability” (RIN 0955–AA06). The description indicates that this proposed rule aims to advance interoperability, including proposals to expand the use of certified APIs for electronic prior authorization.

Comment: A few commenters recommended that CMS work with states to resolve conflicts between this rule and existing state regulations. A commenter noted that Arizona has recently enacted legislation and published guidance establishing a uniform prior authorization request form. The commenter expressed concern that potentially conflicting policies would create confusion and operational process challenges for QHP issuers on the FFEs and providers.

Response: We are aware that many states are also attempting to improve prior authorization processes and have read the Arizona legislation HB 2621 from 2022 regarding using standard paper forms and electronic portals. We do not believe there is a conflict between those requirements and this final rule as the Prior Authorization API required by this final rule can support the various state required standardized forms for electronic submission of the prior authorization request. The AMA also provides a list of other state legislation designed to improve prior authorization processes, many of which support or enhance the provisions in this final rule, for example, by supporting the establishment of an electronic prior authorization process. Should a conflict present between state and Federal requirements, the general rule is that the regulated entity must comply with both requirements unless compliance with one makes compliance with the other impossible; in such a situation, Federal law generally preempts state law in the absence of statutory direction otherwise.

d. Implementation Timing Considerations

In the proposed rule (87 FR 76290), we stated that we had considered proposing that the Prior Authorization API be implemented in a phased approach. However, we explained that we did not think a phased implementation strategy would reduce the burden on impacted payers or providers, but rather could increase burden during the initial implementation. We also explained that a phased approach could delay the availability of electronic prior authorization for certain items and services, which could in turn reduce the overall adoption of the Prior Authorization API by providers who do not see their specialties and services represented in the initial rollout of the available Prior Authorization API. We sought comment on whether to require payers to make prior authorization rules and documentation requirements available through the API incrementally, beginning in 2026. Additional comments and responses regarding the timing and deadlines for compliance with the Prior Authorization API and those policies that do not require API development or enhancement are discussed in sections I.B. and II.D.1.

Comment: Some commenters supported a phased implementation of the Prior Authorization API to allow impacted payers sufficient time to build the API and recommended processes that would use the IGs in a staggered fashion rather than implementing the entire process for prior authorizations. Other commenters recommended a phased implementation based on the following order for the IGs: CRD IG first, DTR IG second, and PAS IG third. A commenter stated there are already states making plans to implement an electronic prior authorization process and suggested that a staggered approach could help to avoid unnecessary variation in implementations. A commenter stated that if CMS does not provide an explanation of terminology (such as “documentation”) and specify IGs and common standards on time for the Prior Authorization API there may need to be a staggered approach for implementing the API. A commenter agreed with CMS's observation that a phased implementation approach would still result in having to request and process prior authorization requests in at least two different manners for a provider working with the same impacted payer, which makes little sense given the difficulties in the current state to even get the HIPAA Referral Certification and Prior Authorization transaction adopted under HIPAA Administrative Simplification. Multiple commenters recommended a 3-year timeframe for phased implementation based on the specific/common services approach. A commenter recommended that instead of using a percentage criterion, CMS should use a 3-year timeframe with year 1 requiring authorization rules, year 2 adding rules to different specialty facilities, and year 3 adding the Prior Authorization API to specific services and care sectors.

Response: As stated at the beginning of this section, we are finalizing a modification to our proposed compliance dates for the Prior Authorization API in 2027. We continue to believe, for the reasons outlined in the CMS Interoperability and Prior Authorization proposed rule and in our responses to comments on this issue, that mandating a phased approach is not necessary. Payers may choose to implement the IGs in a phased approach within their operations, as long as the API is fully functional by the compliance date. Each payer will evaluate the scope of work required to program their prior authorization requirements, build the rules and questionnaires, and develop appropriate testing. For those payers with extensive prior authorization requirements and less structured documentation policies for different benefit packages, the scope will be more significant. However, a phased approach will not change the scope of this work; the IGs provide the road map or instructions for implementation. Use of these guides will help payers determine the scope and level of effort required for the work that must be completed for system changes, as well as operational changes for their organizations.

Comment: Multiple commenters stated the phased approach may result in inconsistent implementation and/or fragmentation when it comes to leveraging the Prior Authorization API, as different payers and providers may be at different stages of implementation. Multiple commenters stated that a phased approach could reduce adoption of Prior Authorization API by providers, particularly if certain items or services are listed in the initial rollout and others are not. A commenter noted that the slow and delayed rollout of the Prior Authorization API is unlikely to result in standardized, streamlined, electronic prior authorization experiences for physicians, clinicians, providers, and health IT vendors. Therefore, multiple commenters supported the full implementation of Prior Authorization API on January 1, 2026.

Response: We thank commenters for affirming that a phased approach could result in inconsistent and fragmented implementation of the Prior Authorization API and reiterate that the decision to provide an additional year for implementation for all impacted payers was made to ensure that the organizations would have sufficient time for training, development, testing, and outreach to providers.

e. Existing Prior Authorization Standards: HIPAA Exceptions for Testing New Standards

In the CMS Interoperability and Prior Authorization proposed rule, we explained that the X12 278 transaction standard (Version 5010) and NCPDP D.0 are the current standards for electronic prior authorization transactions, adopted by HHS under provisions of HIPAA. Many payers and providers do not use the HIPAA transaction standards, and instead use proprietary payer interfaces and web portals through which providers submit their requests, as well as phone calls or faxes to complete the process for a response. The prior authorization process remains inefficient and burdensome and creates service issues for patients. We provided findings from industry surveys and HHS reports about gaps in the current processes and standards for prior authorization.

The Council for Affordable and Quality Health Care (CAQH) Committee on Operating Rules for Information Exchange (CORE) annual report, the CAQH CORE Index, includes data on health plan and provider use of HIPAA standard transactions, and as noted in the proposed rule (at 87 FR 76288), shows that prior authorization using the X12 278 transaction standard was the least likely to be supported by payers, practice management systems, vendors, and clearinghouse services. The 2021 report showed an incremental increase in using the X12 278 transaction standard for prior authorization of 26 percent. CAQH CORE published its 2022 report in November 2022 with data showing that while medical plans' adoption of the X12 278 transaction standard increased by two percentage points (to 28 percent), it was still low as compared to the other HIPAA transactions.

We received many comments about the adopted HIPAA transaction standard and its intersection with the proposed rule and address applicable comments here.

The provisions of this final rule will provide enhancements to the electronic prior authorization process overall. We are finalizing our proposal to require impacted payers to implement a Prior Authorization API that can provide the necessary data to support a payer's use of electronic prior authorization processes.

In the proposed rule, we referenced section 1104 of the Affordable Care Act, which amended HIPAA to require that HHS adopt operating rules for HIPAA standard transactions. “Operating rules” are defined at 45 CFR 162.103 as the “necessary business rules and guidelines for the electronic exchange of information that are not defined by a standard, or its implementation specifications as adopted for purposes of HIPAA Administrative Simplification.” Operating rules have not been adopted for the X12 278 transaction standard.

The NCVHS reviews operating rules and advises the Secretary as to whether HHS should adopt them (section 1173(g) of the Act). The Secretary adopts operating rules through regulation in accordance with section 1173(g)(4) of the Act. In June 2022, CAQH CORE submitted revised and new operating rules to NCVHS for consideration. In June 2023, NCVHS sent a letter to HHS recommending adoption of revised operating rules for Eligibility & Benefits, Claim Status, and Payment & Remittance Advice transaction standards, as well as a Connectivity operating rule. In that letter, NCVHS recommended that HHS not adopt the proposed CAQH CORE Attachments Prior Authorization Infrastructure operating rule or the CAQH CORE Attachments Health Care Claims Infrastructure operating rule. NCVHS wrote that “[t]he need for these operating rules should be considered only after publication of a final rule adopting a health care attachments transaction standard under HIPAA.” Should a future proposal or recommendation for adoption be submitted to HHS, we would evaluate the effect, if any, on the policies included in this final rule. After the publication of this final rule, CMS will continue to evaluate the impact of any NCVHS recommendation and any separate actions by HHS in that regard.

We also noted in the CMS Interoperability and Prior Authorization proposed rule (87 FR 76289), that in March 2021, HHS approved an application from an industry group of payers, providers, and vendors for an exception under 45 CFR 162.940 from the HIPAA transaction standards to allow testing of an alternative to the adopted HIPAA standard for prior authorization. The purpose of this exception is to test an automated exchange of a prior authorization request and response using only the FHIR standard and the FHIR IGs recommended in the proposed rule and included in this final rule. Under this exception, participants are testing the prior authorization exchange using a FHIR-to-FHIR exchange using the FHIR standard without using the X12 278 transaction standard. Preliminary findings suggest that this alternative standard can be used successfully to conduct the prior authorization request and response as end-to-end FHIR in a cost-effective, efficient way. Payer and provider groups have presented these preliminary findings in public forums.

HHS provides information about requests for exceptions from standards to permit testing of proposed modifications on the HIPAA administrative simplification website.

Comment: Multiple commenters made statements about the HIPAA exceptions process (45 CFR 162.940) and described various burdens associated with it, including the application process, lack of clarity for the evaluation criteria, and the time for approval. Commenters noted the current exceptions process may serve as a barrier for the industry to take advantage of the opportunity to move interoperability forward and urged CMS to make it less burdensome to accelerate opportunities for entities to beta test new standards and approaches to more efficient data exchange. A commenter recommended that CMS work with HHS or other agencies to improve the HIPAA exceptions process such that it is less onerous and more flexible to facilitate innovation. Another commenter strongly urged CMS to eliminate the requirement for payers to request an exception to any of the HIPAA transaction and code standards. This commenter stated that Da Vinci member exceptions should be discontinued, and CMS should work with other government entities as needed to eliminate the requirement to obtain an exception from the HIPAA standard for organizations seeking to directly exchange data using the FHIR standard without X12 translation. A commenter requested that HHS develop an administrative process or “onramp” for states to request a HIPAA exception for this specific transaction that individual states could utilize at their discretion.

Response: The opportunity to apply for an exception to test an alternative to an adopted standard is established in the HIPAA statute and implemented in regulation at 45 CFR 162.940. Although we appreciate these comments regarding the HIPAA exceptions process, they are out of scope of this rule.

Comment: Many commenters stated that the CMS Interoperability and Prior Authorization proposed rule failed to address the limitations of the X12 278 transaction standard. Many others noted that current industry use of the X12 278 transaction standard is very low, noting it is complex and outdated, and thus mandating the conversion of FHIR to the X12 278 transaction standard serves no real value beyond compliance. A commenter discussed how the CAQH CORE Index report consistently reports that full automation for X12 standards for prior authorization lags far behind payment-related use cases. A commenter noted that because of the low use of the X12 278 transaction standard, entities would have to develop an implementation process to complete a FHIR exchange just to convert it to an X12 278 transaction standard. Another commenter noted the industry will continue to have interoperability challenges around the Prior Authorization API capability due to a lack of uniformity if existing issues with the X12 278 transaction standard are not addressed. Multiple commenters requested that CMS consider certain flexibilities in implementation. A commenter recommended that CMS consider a floor versus ceiling approach in which the X12 standard is seen as the floor and a standard FHIR approach using the PAS IG is the ceiling. Multiple commenters recommended that CMS provide a waiver for the X12 278 transaction standard for payers that can implement end-to-end FHIR data exchange. A commenter requested that CMS grant such payers a safe harbor that provides an automatic waiver of the X12 278 transaction standard requirement. A commenter noted these waivers would preferably be automatic or minimally burdensome to obtain. Another commenter recommended CMS allow for exceptions to the requirement of converting Prior Authorization API messages to the X12 278 transaction standard in scenarios where there is no need for the receiving entity to pass along the prior authorization transaction to another system. A commenter sought guidance on whether CMS will consider payers that are not currently covered under the HIPAA administrative simplification exception of having prior authorizations sent through the PAS phase of the Prior Authorization API, translated into and out of the X12 278 transaction standard for an exception. A commenter requested clarification on whether CMS proposed that the Prior Authorization API can be used to transform the provision of a health care attachment into a valid X12 278 transaction standard for meeting HIPAA requirements or is suggesting that the Prior Authorization API provides an alternative basis to the proposed X12 278 transaction standard.

Response: We appreciate stakeholder interest in using the FHIR standard to implement the Prior Authorization API. Unless an impacted payer is included in the current Da Vinci pilot to test an exception to the HIPAA transaction, that payer may be required to use the adopted HIPAA standard when implementing the API. Information on the Da Vinci pilot is available on the HL7 Da Vinci website. The participants in the pilot are testing the prior authorization API over 3 years and will report to HHS at the end of that time on such metrics as response time, ability to exchange supporting clinical information, integration into the provider's workflow, reducing total provider/staff time to obtain prior authorization, flexibility of the standard, ability to provide a timely response, and more. The Prior Authorization API can support the submission of a prior authorization request itself, or provide data that can support the HIPAA-compliant X12 278 transaction standard, if used, for prior authorizations, which is then sent as a separate transmission between the providers and payers, either through a clearinghouse or through the provider's practice management system. HL7 provides detailed workflows and graphical depictions of the API and the HIPAA transaction process. Finally, this final rule does not address health care attachments.

Comment: A commenter noted that the lack of requirements for specific data elements with the X12 278 transaction standard for prior authorizations limits the value of that transaction standard and would affect the adoption of the API because providers would lack an efficient way to identify what critical information to include in a prior authorization request. Multiple commenters expressed concern regarding the functionality of the proposal to use the X12 278 transaction standard with the API, and another commenter noted that the X12 275 transaction standard for health care claims attachments does not allow for using FHIR, which creates concerns about the implementation of the Prior Authorization API. Another commenter stated that certain CAQH CORE operating rules to support HIPAA transactions were submitted to NCVHS for review and recommendation to HHS in 2023. These operating rules were specific to certain HIPAA transactions and included required documentation requirements. The commenter noted that the operating rules do not name an API documentation requirement, which is key to locating data in various formats. Finally, another commenter noted that the X12 and FHIR standards do not currently share compatible coding for all the information that would need to be translated.

Response: We appreciate the concerns commenters expressed regarding the ability to use the adopted X12 prior authorization transaction with the Prior Authorization API. Code mapping between the X12 standard and the FHIR IGs contains X12 standard proprietary information and will require a license for its use to support the X12 transaction. This mapping is available on the X12 website through the Glass online viewer as HL7 does not publish an X12 mapping artifact.

We also note that we did not propose in this rulemaking that the X12 275 transaction standard be required for use with the Prior Authorization API. That transaction was proposed for use in the HIPAA Standards for Health Care Attachments proposed rule (87 FR 78438), which has not yet been finalized. We reiterate that there are no operating rule requirements in the HIPAA Administrative Simplification rules (45 CFR part 162) applicable to the API required for use in this final rule, or, at this time, to the required HIPAA-compliant X12 278 transaction standard.

Comment: Multiple commenters expressed support to CMS for proposing an electronic Prior Authorization API that uses the FHIR standard and IGs in addition to the adopted X12 278 transaction standard to conduct electronic prior authorization.

Response: We appreciate commenter support for the policy that utilizes both FHIR and X12 transaction standards. The FHIR standard and IGs will be used to implement the Prior Authorization API while supporting compliance with the HIPAA administrative transaction standard.

Comment: Multiple commenters requested support for their organizations that are ready and willing to exchange data using FHIR data and process standards instead of X12 standards. Other commenters recommended that CMS recognize FHIR data and process standards as a permitted option for standard transactions (that is, adopted in place of the X12 standards). These commenters noted that FHIR has increasingly become the de facto standard in health care since it was mandated as a standard in the implementation of the Cures Act. To further accelerate the FHIR standard and exchange of data via FHIR, commenters recommended that CMS work with other government entities to eliminate the need for the HIPAA exception requirement for organizations seeking to exchange data via FHIR directly without X12 transaction standard translation. Some commenters stressed the costs involved in having to comply with both a new set of standards and maintain a system for an outdated standard they were not using and for which they had already developed workarounds. Others suggested that CMS support both X12 and FHIR to meet market needs and innovation. The SDOs supported this approach, noting that the FHIR IG is written in such a way that if the requirement to use the HIPAA standard is removed, the structure is in place for a FHIR-only transaction.

Response: We appreciate industry interest in moving towards using the FHIR standard and reiterate that the HIPAA standards are adopted by HHS. HIPAA covered entities may consider submitting comments regarding updates to those standards to the Secretary of HHS for consideration.

Comment: Multiple commenters emphasized the importance of exploring the integration of real-time electronic prior authorization transactions into workflows as these could reduce payer costs. A commenter noted that this was also recommended in the 2020 ONC report: “Strategy on Reducing Regulatory and Administrative Burden Relating to the Use of Health IT and EHRs.” A commenter noted these could be used for medical services and medications that do not typically require large amounts of supporting documentation. Another commenter recommended that CMS adopt policies that support integration of electronic prior authorization into physicians' practice workflows such as direct financial support for investments in compliant IT platforms, allowing physicians to access insurer APIs as they work towards full capability, and supporting flexible sources of documentation for prior authorization requests within the established framework. A commenter recommended the electronic prior authorization system be universal across all payers with information displayed in real-time, with no cost to clinicians or health systems. The commenter stated that research showed that switching to real-time electronic prior authorization could save more money and reduce the time a provider takes to complete a transaction by 15 minutes on average. The commenter stated that improving prior authorization processes would benefit every actor in this transaction. Another commenter expressed the importance for CMS to acknowledge that real-time prior authorization should be the goal and that the standards and technology currently exist to implement real-time prior authorization for certain use cases. A commenter recommended that payers implement real-time determination by January 1, 2026, for Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs.

Response: Many commenters discussed the potential the Prior Authorization API and policies in this final rule have for payers to make real-time decisions, particularly when integrated into both the payer and provider workflows; however, we did not propose a real-time decision requirement and are not finalizing such a requirement in this final rule. Though we anticipate that some of the responses or decisions may be made in real-time, we anticipate others will continue to necessitate review and evaluation by clinical staff. We agree that the automation of a complex process such as prior authorization will require continuous improvement. Furthermore, some cases will require manual review because of their complexity. Nonetheless, the overarching improvements in automation will be an improvement in what exists today.

f. Federal Matching Funds for State Medicaid and CHIP Fee-for-Service Programs' Expenditures on Implementation of the Prior Authorization API

In section II.E. of this final rule, we discuss Federal matching funds for certain state Medicaid and CHIP FFS programs' expenditures related to implementation of the Prior Authorization API (this was also addressed in the proposed rule at 87 FR 76291 and 76292).

g. Medicaid Expansion CHIP

In section II.E. of this final rule, we discuss implementation for states with Medicaid Expansion CHIP programs (this was also addressed in the proposed rule at 87 FR 76292).

3. Requirement for Payers To Provide Reason for Denial of Prior Authorizations and Notifications

Throughout the Interoperability and Prior Authorization proposed rule at 87 FR 76292, we described opportunities for improvement with the prior authorization process, specifically where better communication between payers and providers could mitigate confusion about the status of a prior authorization, particularly if it was not approved. This section addresses issues about the proposed and final policy for communication about prior authorization denials and existing requirements for notifications from impacted payers.

a. Background on Providing a Reason for Denial of Prior Authorization

Payers deny prior authorizations for different reasons, including because the payer does not consider the items or services to be medically necessary, the patient exceeded limits on allowable covered care for a given type of item or service, or documentation to support the request was missing or inadequate. When a payer provides a specific reason for a denial, a provider can take appropriate actions such as re-submitting the request with updated information, identifying alternatives for the patient, appealing the decision, or communicating the decision to the patient to enable the patient to consider other options or to appeal as well. Today, impacted payers send denials either electronically or through the mail, and the information provided varies substantially between payers. For denials sent using the X12 278 transaction standard, payers must use the codes from the external code set maintained by X12. For responses sent through portals, fax, or other means, payers may use proprietary codes or text to communicate denial reasons. The process is inefficient and unsatisfactory; and in general, providers do not have consistent direction on the next steps for a denied authorization. Our proposal for impacted payers to send a specific denial reason was one approach to address current inefficiencies.

We proposed, and are finalizing in this final rule, that, beginning in 2026, impacted payers must provide a specific reason for denied prior authorization decisions, regardless of the method used to send the prior authorization request. As with all policies in this final rule, this provision does not apply to prior authorization decisions for drugs. This final policy is an effort to improve the communication about denials from an impacted payer in response to a request for a prior authorization through existing mechanisms, such as electronic portals, telephone calls, email, standard transactions, or other means.

b. Denial Reason and Denial/Decision Codes

Some payers subject to this requirement to provide a specific reason for denied prior authorization decisions will also remain subject to existing requirements to provide notice to patients, providers, or both, with the specific reasons for the denial. In addition, for certain payers impacted by this final rule, existing communication requirements related to coverage decisions, notices of coverage decisions, and appeal processes, remain in effect for coverage decisions that are made as part of a prior authorization denial or approval. These requirements are not changed under this final rule. For example, before an MA plan may issue a prior authorization denial (or any other organization determination that is a denial) based on medical necessity, the decision must be reviewed by a physician or other appropriate health care professional with expertise in the field of medicine or health care that is appropriate for the services being requested, including knowledge of Medicare coverage criteria, per 42 CFR 422.566(d); this will apply to any denial of a prior authorization request, regardless of whether the Prior Authorization API has been used to request, check the status of, or communicate the decision on the prior authorization. Nothing in this final rule limits the scope of the MA regulation at 42 CFR 422.566(d) and it continues to apply to any prior authorization request and decision that is also subject to the policies being finalized in this final rule.

Comment: Some commenters recommended that CMS define and provide examples for terms such as “approval,” “denial,” and “specific reason” concerning prior authorization denials in the final rule.

Response: We are not adding regulatory definitions for these terms in this rule, as these terms are clear, frequently used in many contexts, and commonly used. For this final rule, these terms mean the following:

• Approvals are when the payer authorizes coverage of items or services for which prior authorization has been requested.
• Denials are the refusal by a payer to approve the prior authorization for a health care item or service. Denials, or rejection of a prior authorization, may result because the service was not considered medically necessary under the payer's medical guidelines or the provider did not provide complete or accurate documentation to support the request.
• A specific reason for denial could include reference to the specific plan provisions on which the denial is based; information about or a citation to coverage criteria; how documentation did not support a plan of care for the therapy or service; a narrative explanation of why the request was denied, and specifically, why the service is not deemed necessary or that claim history demonstrated that the patient had already received a similar service or item.

Comment: Multiple commenters expressed their support for CMS's proposal to require impacted payers to provide specific reasons for prior authorization denials, regardless of the mechanism used to submit the prior authorization request. Multiple commenters also specifically expressed support for requiring impacted payers to provide the reasons for denial as part of the information included in the Prior Authorization and Patient Access APIs. Similarly, commenters expressed support for CMS's proposal to require impacted payers, particularly MA organizations, to give providers specific reasons for their prior authorization denials. Many commenters supported the proposal to require payers to include in the Prior Authorization API specific information about prior authorization requests, including the determination of approval (and for how long), determination of denial (with a specific reason), and a request for more information from a provider.

Response: We appreciate the general support for the proposal to improve this aspect of the prior authorization process, specifically communication about prior authorization decisions and information about denials.

Comment: Multiple commenters noted that requiring a reason for denials and public reporting of prior authorization metrics could help providers, patients, policymakers, and other interested parties understand the prior authorization process better. These commenters asserted that this increased transparency could improve providers' submissions of prior authorization requests, ensure prior authorizations are based on the best medical evidence and guidelines, and allow patients to be better informed regarding their health care purchasing decisions.

Response: We appreciate the many other comments we received in support of the proposals to require a reason for denials and public reporting and discuss other comments specific to those provisions later in this section. Specifically, we concur that the transparency of information will support communication between payers, providers, and patients.

Comment: Multiple commenters recommended that CMS be more specific about which prior authorization decision information payers should include as well as how they should provide this information. Specifically, multiple commenters recommended that CMS further specify the level of detail that impacted payers must provide about their reasons for denial. Other commenters recommended that the information payers provide regarding reasons for prior authorization denials include the policy on which the decision was based and the requirements for coverage assessed, including the standards used to determine medical necessity. The commenters recommended that CMS require that the reason for denial provided by payers include the clinical rationale and patient-specific evidence supporting the denial decision (that is, which specific criteria the patient did not meet). A commenter recommended that CMS require payers to provide the following with each prior authorization decision: whether the prior authorization adjudication was automatically adjudicated; whether statistical methods such as AI, machine learning, or other algorithms were used; and whether a human decision-maker was involved and the name and credentials of the employee. This commenter noted algorithms should be publicly accessible so that they can be examined for implicit bias. Another commenter recommended that CMS require impacted payers to provide a clinical rationale for prior authorization denials according to the national medical specialty society guidelines for peer-reviewed clinical literature. Multiple commenters recommended that CMS specify that impacted health plans must provide all the prior authorization decision and denial information in a form that is understandable and outlines specific steps for the provider, including any additional information the provider needs to provide to further support the request, a list of covered alternative treatments, and details regarding their right to appeal and the process for appeals.

Response: In this final rule, we are requiring impacted payers to provide a specific reason to the provider when denying a prior authorization. The volume of comments in this area, as in other areas of these proposals, was indicative of the challenges providers face in obtaining specific information about prior authorization decisions and denials, and that payers face in providing adequate detail for the decisions they give back to a provider about a prior authorization denial, such that the provider can take appropriate action. The CMS Interoperability and Prior Authorization proposed rule and this final rule do not directly address how prior authorization decisions are made, such as using AI, statistical methods, requirements for clinical decisions, or other algorithms, which are out of scope of this specific rulemaking. However, prior authorization decisions involving AI or other algorithmic systems must still comply with applicable requirements, including requirements around clinical decision-making and the finalized policy requiring communication of the specific reason for denial. This rule intends to ensure that payers provide better communication about denials than has been available to date.

There are existing programmatic rules for some of the impacted payers that also address the content of a denial decision. MA organizations are required to provide the specific reasons for the denial to their enrollees when an item or service is denied, along with certain other information (such as the ability to appeal the decision and how). CMS provides a standard form for MA organization use, which captures a specific and detailed explanation of why the medical services were denied, including a description of the applicable coverage rule or applicable plan policy (for example, Evidence of Coverage provision) upon which the action was based, and a specific explanation about what information is needed to approve coverage if applicable. For Medicaid managed care prior authorization decisions, 42 CFR 438.210(b) requires the MCO, PIHP, or PAHP contract with the state to include provisions requiring the Medicaid managed care plan to consult with the requesting provider when appropriate and that any decision to deny a service authorization request or to authorize a service in an amount, duration, or scope that is less than requested, be made by an individual who has appropriate expertise in addressing the enrollee's medical, behavioral health, or long-term services and supports needs. The regulation at 42 CFR 438.210(c) requires notice (albeit not necessarily written notice) to the provider of the Medicaid managed care plan's denial of a service authorization request, or decision to authorize a service in an amount, duration, or scope that is less than requested. For Medicaid FFS, 42 CFR 435.917(a) requires state Medicaid agencies to provide the beneficiary with timely and adequate written notice of any decision regarding the beneficiary's prior authorization request, as any such decision would cause a “denial or change in benefits and services.” When a state denies the prior authorization request in whole or in part, the beneficiary notice must include, in addition to the content described at 42 CFR 435.917, the notice content described at 42 CFR part 431, subpart E, including the requirement at 42 CFR 431.210 that notices contain a clear statement of the specific reasons supporting the intended action. Notices must be written in plain language and be accessible to individuals who have limited English proficiency and individuals with disabilities consistent with 42 CFR 435.905(b). These existing provisions, which include a requirement for enrollees to be provided written notice about an adverse decision, could be useful examples for the level of specificity that could be given to a provider, including the applicable medical necessity criteria. Likewise, for CHIP managed care entities' prior authorization decisions, 42 CFR 457.1230(d) cross references to 42 CFR 438.210 to apply Medicaid managed care plans' prior authorization decision requirements to CHIP managed care entities. Additionally, for QHP issuers on the FFEs, 45 CFR 147.136(b)(2)(ii)(E) and 29 CFR 2560.503–1(g) and (j) require group health plans and issuers of group and individual health insurance coverage to provide notice to individuals, in a culturally and linguistically appropriate manner, of adverse benefit determination or final internal adverse benefit determination and specifies information that this notice must include, such as a description of the plan's or issuer's standard, if any, that was used in denying the claim.

When denial information is sent to a provider by any communication method, including existing notices, the content of a denial should be sufficiently specific to enable a provider to understand why a prior authorization has been denied and what actions must be taken to re-submit or appeal. This requirement would improve the current processes and reduce manual effort and costs. When implemented, the Prior Authorization API could mitigate some denials by providing information about the documentation and information or data necessary to support a prior authorization request for the service or item.

Comment: Multiple commenters recommended that CMS work with X12 and other appropriate industry organizations to update the X12 278 Service Decision Reason Code Set with additional codes for scenarios not yet covered by the existing code set or for use of the X12 Service Decision Reason Codes as the code set for communicating reasons for the denial. The X12 Service Decision Reason Code List is a code set maintained by X12 used by HIPAA covered entities with the HIPAA standard transaction for electronic prior authorization decisions. A commenter supported using denial codes under the condition that CMS continue to work with SDOs, NCVHS, and other relevant organizations to expand the denial reasons and add support for more specific options. Another commenter requested clarification on whether the specific reason for the denial requirement must be met by using the X12 code list of denial reasons. The commenter added that this code list allows varying interpretations which would result in ambiguity. Other commenters recommended that CMS establish a clearly defined standardized set of specific reasons for the denial and require payers to use them for communicating prior authorization decisions for all items and services. A commenter recommended that CMS align the FHIR Certification Action Codes and the X12 Service Decision Reason Codes. Another commenter stated that the HCR 03 Decision Reason Code is an optional field in the X12 278 transaction standard and recommended that CMS refer to “denial reasons” as “decision reason codes.”

Response: We confirm that the X12 Service Decision Reason Code List is a code set maintained by X12 for electronic prior authorization decisions. Updates to this code set must be requested through the X12 code maintenance workgroup. We strongly encourage both impacted payers and providers to evaluate the X12 Decision Reason Code List and make recommendations to X12 for necessary updated or new codes as appropriate. We encourage interested organizations and SDOs to continue their collaboration efforts on crosswalks needed for the IGs supporting the Prior Authorization API and maintenance of code sets that could be used with the API. We decline to change the terminology in this final rule from “reason for the denial” to “decision reasons” or “decision reason codes.” The obligation under this final rule for impacted payers to provide a specific reason for the denial of a prior authorization request goes beyond using a single code set and means that payers must provide sufficient detail in the denial response to enable the provider to know what action to take as the follow-up to the denial to obtain coverage—that is whether to appeal, submit additional documentation, or identify alternative treatment options. Impacted payers may send additional information through the API which could provide additional clarity. Finally, though the Medicare FFS program has a list of decision reason codes in use for its program, and these could be considered for inclusion in the X12 code set, we did not propose these for use by all payers as part of this policy. However, the industry could submit similar text to X12 as additions to that external code set. We affirm that all denial reasons must be specific.

Comment: Multiple commenters shared concerns about and made recommendations related to MA organizations' utilization management policies as these pertain to the denial of prior authorizations.

Response: This rulemaking does not address requirements or limitations for all utilization management guidelines or policies used by MA organizations. This rulemaking adopts certain procedural and timing requirements for prior authorizations and several API requirements for MA organizations and other impacted payers, including implementation of a Prior Authorization API, new reporting to CMS, and new requirements to provide to the applicable provider a specific reason for the denial of a request for prior authorization. However, in separate rulemaking for MA organizations, we addressed standards and requirements for how MA organizations develop and use clinical criteria and prior authorization policies to help ensure MA beneficiaries receive the same medically necessary care they would receive under Traditional Medicare in the CY 2024 MA and Part D final rule (88 FR 22120). We recommend interested readers review the CY 2024 MA and Part D final rule for more information on these other requirements for MA organizations.

Comment: Many commenters described challenges with denials, including the burdens they faced when attempting to appeal those denials on behalf of their patients and delays created in access to care when they did not have information about the reason for the denial, and therefore little information to include in the response back to the payer. Multiple commenters wrote that requiring impacted payers to provide reasons for prior authorization denials would have positive impacts on the health care system. Multiple commenters stated that this requirement would facilitate better transparency and communication between providers and payers. Commenters noted that this requirement would: (1) allow providers to better communicate the reason for denial and reasons for potential treatment plan changes to their patients; (2) provide patients with more insight into how decisions are made relating to access to care; (3) decrease the number of arbitrary prior authorization denials and minimize the number of denials that are overturned on appeal; and 4) reduce unnecessary delays in patient care.

Response: We appreciate the many letters from commenters indicating support for the provisions of this rule and including in those letters descriptions of the process challenges that they believe could be mitigated by the policies being finalized. We concur with the information in many of the letters that the requirement to provide the specific reason for the denial in a response to the provider has the potential to improve communication between payers and providers for the prior authorization process.

c. Existing Notice Requirements To Communicate Prior Authorization Denial Information—By Program

Some of the impacted payers are required by existing Federal and state laws and regulations to notify providers or patients when the payer makes an adverse decision on a prior authorization request. Our proposals to impose requirements on payers to communicate certain information to providers about prior authorization denials were intended to reinforce and supplement existing Federal and state requirements and do not alter or replace existing requirements to provide notice to patients, providers, or both. Further, the requirements include implementation of a Prior Authorization API that can provide responses about whether an authorization request has been approved (and for how long) or denied, a specific reason for the denial, or request more information from the provider to support the prior authorization. Communicating denial reasons with specific information, in addition to the existing program notification requirements, will increase transparency, reduce burden, and improve efficiencies for both payers and providers. The API requirements have compliance dates in 2027.

i. Denial Notice Requirements

This section of the final rule addresses denial notice requirements which will remain in place for MA organizations, CHIP FFS, Medicaid managed care plans, and CHIP managed care entities.

Under the MA program, the actions that constitute an “organization determination” include a prior authorization decision (as well as a decision in response to a voluntary pre-service request for a decision on coverage), as it is defined as including an MA organization's refusal to provide or pay for services, in whole or in part, including the type or level of services that the enrollee believes should be furnished or arranged by the MA organization as well as other types of decisions about coverage and payment. Existing MA program regulations impose requirements as to the form and content of the written notice to enrollees in the event of a partial or full denial. For example, existing regulations regarding written notices for enrollees for standard organization determinations require that notice for any denial by the plan of coverage of an otherwise covered service or item must—

• Use approved notice language in a readable and understandable form;
• State the specific reasons for the denial;
• Inform the enrollee of their right to a reconsideration;
• Describe both the standard and expedited reconsideration processes, including the enrollee's right to, and conditions for, obtaining an expedited reconsideration and the rest of the appeal process; and

• Comply with any other notice requirements specified by CMS.

Under existing requirements, if the MA organization expedites an organization determination, the MA organization must notify the enrollee (or the enrollee's representative) and the physician involved, as appropriate, of its decision, whether adverse or favorable, as expeditiously as the enrollee's health condition requires, but no later than 72 hours after receiving the request. Either an enrollee or a physician, regardless of whether the physician is affiliated with the MA organization, may request that an MA organization expedite an organization determination. The notice of expedited determination must state the specific reasons for the determination in understandable language and if the determination is not completely favorable to the enrollee, the notice must also—

• Inform the enrollee of their right to a reconsideration;
• Describe both the standard and expedited reconsideration processes, including the enrollee's right to request, and conditions for obtaining an expedited reconsideration, and the rest of the appeal process; and

• Comply with any other requirements specified by CMS as to the content of the notice.

Because applicable integrated plans (D–SNPs that have exclusively aligned enrollment with an affiliated Medicaid MCO) are a type of MA plan, the regulations regarding prior authorization processes that we are finalizing apply to them. The final rule revises the specific timeframes for prior authorization decisions by applicable integrated plans. Applicable integrated plans cover both Medicaid long term services and supports and MA benefits in ten states. Existing requirements already govern denial notices issued by applicable integrated plans to their enrollees and are similar to the Medicaid managed care and MA rules described in the prior paragraphs. Integrated organization determination notices must be written in plain language, available in a language and format that is accessible to the enrollee, and explain—

• The applicable integrated plan's determination;
• The date the determination was made;
• The date the determination will take effect;
• The reasons for the determination;
• The enrollee's right to file an integrated reconsideration and the ability for someone else to file an appeal on the enrollee's behalf;
• Procedures for exercising an enrollee's rights to an integrated reconsideration;
• The circumstances under which expedited resolution is available and how to request it; and
• If applicable, the enrollee's rights to have benefits continue pending the resolution of the integrated appeal process.

As with the notices required from MA plans, our finalized policies do not change the content requirements for these written denial notices to enrollees but will supplement these notices by requiring applicable integrated plans to notify the provider of the reason for a denial of a prior authorization request.

For Medicaid managed care plans and CHIP managed care entities, existing regulations at 42 CFR 438.210(c) require notice to the provider without specifying the format or method, while 42 CFR 438.210(c) and 438.404(a) require written notice to the enrollee of an adverse benefit determination. In addition, 42 CFR 438.210(c) requires notice (albeit not necessarily written notice) to the provider as well of the Medicaid managed care plan's denial of a service authorization request or decision to authorize a service in an amount, duration, or scope that is less than requested. CHIP managed care entities are required to comply with similar standards at 42 CFR 457.1230(d) (referencing 42 CFR 438.210) and 457.1260(c) (referencing 42 CFR 438.404). Nothing in this final rule will limit the existing enrollee notification requirements at 42 CFR part 438 for Medicaid managed care plans and at 42 CFR part 457 for CHIP managed care entities as these requirements will remain in full effect. This final rule fills a potential gap concerning the information communicated to providers regarding a denial of a prior authorization request. We proposed and are finalizing that the response—whether the authorization request has been approved (and for how long), denied (with the reason for the denial), or a request for more information to support the prior authorization—if transmitted to providers via the Prior Authorization API workflow process or other means, will be sufficient to satisfy the current requirement for notice to providers at 42 CFR 438.210(c) and 457.1230(d). We are finalizing a slight modification to the regulatory language to use “the date or circumstance under which the authorization ends” instead of “how long” as the scope of information that must be provided by the payer. The payer will not be required to send the response to the provider via both the Prior Authorization API (which is required to furnish certain information, including denial reason) and a separate, additional manner (for example, separate written notice or phone call) with duplicate information. However, given that providers are not required to use the Prior Authorization API, the payer must ensure that the response to the provider with the reason for the denial must be furnished to the provider through some means.

We also remind all Medicaid managed care plans and CHIP managed care entities subject to this final rule that their existing obligations to provide these required notices to patients are not changed by the final policies in this rule. These payers will still have to provide a separate written notice to the enrollee.

QHP issuers on the FFEs that offer individual health insurance must provide the specific reason for an adverse benefit determination, which includes denial of prior authorization. Furthermore, plans and issuers must ensure that notice is made to individuals in a culturally and linguistically appropriate manner that complies with existing requirements.

Finally, impacted payers may be required to provide this information in languages other than English, which requires impacted payers (as health programs or activities under that section) to provide meaningful access to individuals with limited English proficiency and accessibility requirements for individuals with disabilities.

ii. Notice and Payer Communications

We received comments on the current processes for notice and payer communications and summarize those and our responses here. Generally, such processes exist for MA organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs.

Comment: Multiple commenters expressed frustration with the variation of prior authorization requirements across MA plans, inconsistencies in access to care and coverage, and painful interactions during lengthy peer-to-peer review of medical necessity assessments with MA organizations. A commenter expressed support for the proposal in the CY 2024 MA and Part D proposed rule (87 FR 79452) to prohibit MA plans from diverting a patient to a different level of care than recommended by the patient's physician when the patient otherwise meets all the clinical criteria appropriate for the setting requested by the physician. Commenters noted these factors have contributed to a more complicated prior authorization process, extended wait times, duplicate or inaccurate prior authorization denials and post-claim denials, and a shifting focus from patient care. Multiple commenters recommended CMS implement increased oversight policies to address MA's challenging prior authorization landscape. Multiple commenters recommended that CMS continue to oversee MA plans' use of prior authorization and advance policies that ensure that MA enrollees have the same access to covered services as those enrolled in Traditional Medicare and that MA organizations cannot use more stringent criteria than Traditional Medicare.

Response: As finalized in the CY 2024 MA and Part D final rule, 42 CFR 422.138 provides that coordinated care plan prior authorization policies may only be used to confirm the presence of diagnoses or other medical criteria and/or ensure that an item or service is medically necessary. Second, the CY 2024 MA and Part D final rule requires coordinated care plans to provide a minimum 90-day transition period when an enrollee currently undergoing treatment switches to a new MA plan, during which the new MA plan may not require prior authorization for the active course of treatment (42 CFR 422.112(b)(8)(ii)(B)). Third, to ensure prior authorization is being used appropriately, we are requiring all MA plans that use utilization management policies (like prior authorization) to establish a Utilization Management Committee to review policies annually and ensure consistency with Traditional Medicare's NCDs, LCDs, and guidelines; compliance with limits on how prior authorization can be used; compliance with other MA regulations on determining medical necessity (42 CFR 422.101(c)); and consultation with network providers (42 CFR 422.202(b) and 422.137). Finally, to address concerns that the CY 2024 MA and Part D proposed rule did not sufficiently define the expected duration of “course of treatment,” a newly adopted regulation at 42 CFR 422.112(b)(8) requires that a coordinated care MA plan's approval of a prior authorization request for a course of treatment must be valid for as long as medically necessary to avoid disruptions in care in accordance with applicable coverage criteria, the patient's medical history, and the treating provider's recommendation. The CY 2024 MA and Part D final rule and this final rule taken together provide significant guardrails for prior authorization in the MA program and support a more streamlined process, which will ultimately lead to reduced burden in health care.

Comment: A commenter was concerned that without specific guidance for MA plans regarding certain benefits, the proposed rule will negatively impact the already existing barriers to electronic exchange of information between MA organizations and religious nonmedical health care institution (RNHCI) providers. This commenter supported the concept of the Prior Authorization API because it makes possible the electronic exchange of certain prior authorization information between payers and providers, which RNHCIs have long desired. However, the organization was concerned about the requirement at 42 CFR 422.122(b) because of concerns about its applicability to nonmedical benefits. This commenter proposed amendments to the regulatory text regarding the obligation to accept and exchange information.

Response: The requirements proposed at 42 CFR 422.122(b) apply to all covered Medicare services, including covered items and services furnished by a RNHCI, and all MA supplemental benefits covered by an MA plan, excluding all drugs, as defined at 42 CFR 422.119(b)(1)(v). See section I.D. for more information about the exclusion of drugs from the scope of the prior authorization policies in this rule.

We are finalizing that the prior authorization requirements adopted in this final rule supplement and do not replace requirements in other applicable laws, including existing requirements for MA plans, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs regarding decisions made on requests for prior authorization of covered benefits. For additional explanation on the continued applicability of existing standards in this final rule, we are adding paragraph (b)(5) to 42 CFR 422.122 to explain that prior authorization decisions made under 42 CFR 422.122 must meet all other applicable MA requirements in subpart M of part 422, such as the adjudication timeframes and notice requirements. Under existing standards for Medicaid managed care plans, all prior authorization decisions by Medicaid managed care plans must comply with 42 CFR 438.210 as well as notice requirements at 42 CFR 438.404.

4. Requirements for Prior Authorization Decision Timeframes and Communications

a. Impact of Delays in Prior Authorization Decisions: Background of Decision Timeframes

As discussed in the CMS Interoperability and Prior Authorization proposed rule (87 FR 76294), CMS learned through listening sessions and other public meetings that excessive wait time for prior authorization decisions could cause delays to patient care and create medical risks in some cases. Providers face delays for the approval of the initial request, or, secondarily, for the resolution of a request “in process,” often meaning the payer is reviewing requested documentation. In 2019, CMS conducted outreach to external entities (87 FR 76294) and received many comments about timeframes for processing prior authorizations, where commenters explained that the process of securing approvals for prior authorization directly affects patient care by delaying access to services, including transfers between hospitals and post-acute care facilities, treatment, medication, and supplies. Commenters believed that these delays occur partly because payers have different policies and review processes, do not use available technologies consistently, and continue to rely on manual systems such as phone, fax, and mail, which are more labor-intensive.

b. Standard and Expedited Prior Authorization Requests and Decision Timeframes

In the CMS Interoperability and Prior Authorization proposed rule we used the terms standard and expedited prior authorizations to refer to two types of prior authorizations for which we are now finalizing our policies—in this final rule, we affirm that the term “standard” prior authorization refers to non-expedited, non-urgent requests and the term “expedited” prior authorization indicates an urgent request. These terms continue to be used in CMS regulations. We received a few comments on these terms and respond to those here.

Comment: Multiple commenters stated that there was a lack of clarity and guidance on the definition of a standard versus an expedited prior authorization. A commenter recommended that CMS create additional specificity around what “expedited” means, especially for mental health and substance use disorder conditions. Another commenter stated that what one provider may deem an expedited request may not be considered one by the payer. A commenter noted that the lack of a standard definition leads to discrepancies on what a payer considers “urgent” and sometimes leaves some discretion up to the provider. This lack of standardization can adversely affect a patient. If a payer has a stricter definition of what constitutes an expedited prior authorization, this could lead to the patient waiting up to 7 days for a decision and delay access to care further if prior authorization is denied. Commenters stated that CMS should release guidance on definitions of these terms to facilitate more alignment for payers and strengthen patient access by minimizing variation between network standards on what is considered “urgent” versus “normal.” Another commenter requested that CMS provide clarification on timeframes in emergencies and if emergency care would override prior authorization rules.

Response: We decline to create a new definition for standard and expedited, as the definitions for standard and expedited requests provide a foundation upon which both payers and providers can rely for making professional judgments. These terms are used in the provisions at 42 CFR 422.568, 422.570, 422.572, and 422.631 for MA organizations and applicable integrated plans. Similar terms are used at 42 CFR 438.210(d) for Medicaid managed care plans, at 42 CFR 457.1230(d) for CHIP managed care entities (87 FR 76294), and we are adding requirements at 42 CR 440.230 for Medicaid FFS and at 42 CFR 457.495 for CHIP FFS to meet these timelines—specifically, as expeditiously as a beneficiary's health condition requires, that may not exceed either 7 calendar days or 72 hours after receiving the request for standard or expedited requests respectively.

A standard for when expedited determinations are required currently exists for MA organizations at 42 CFR 422.566(a), which requires MA organizations to have an expedited procedure for situations in which applying the standard procedure could seriously jeopardize the enrollee's life, health, or ability to regain maximum function. This long-standing medical exigency standard is familiar to MA plans and providers and affords sufficient guidance on when an expedited decision is necessary. There is adequate guidance on these standards for the MA appeals and organization determination deadlines already. For Medicaid managed care and (by cross reference) CHIP managed care, 42 CFR 438.210(d)(2)(i) specifies an expedited authorization is required when “following the standard timeframe could seriously jeopardize the enrollee's life or health or ability to attain, maintain, or regain maximum function.” Standard prior authorization requests are used when the enrollee's life or health or ability to attain, maintain, or regain maximum function are not seriously jeopardized by the managed care plan using the longer, standard authorization timeframes. These policies are intended to ensure that impacted payers, including Medicaid FFS, Medicaid managed care plans, and CHIP managed care entities will evaluate expedited prior authorization review procedures that will minimize patient risk. We confirm that MA plans, Medicaid managed care plans, and CHIP managed care entities are prohibited from applying prior authorization requirements to evaluation and stabilization services for emergency medical conditions.

Comment: A commenter asserted that eliminating the need for a provider to reach out to a payer and notify them of a request that requires an expedited response would reduce a provider's administrative burden and further the efficiency of the prior authorization process. The commenter recommended CMS request that payers be required to have systems that enable providers to electronically differentiate between standard and expedited prior authorization requests.

Response: While this final rule addresses several important prior authorization processes, it does not specifically dictate all payer operational procedures. Existing regulations in the applicable programs covered by this final rule may address the circumstances under which a payer must make a coverage decision, such as a prior authorization request on an expedited basis. For example, under the MA rules at 42 CFR 422.570, an enrollee or a physician (regardless of whether the physician is affiliated with the MA organization) may request that an MA organization expedite an organization determination involving a request for an item or service. The MA organization must promptly decide whether to expedite an organization determination. Under the rules at 42 CFR 422.570(c)(2), if a request is made by an enrollee, the MA organization must provide an expedited determination if it determines that applying the standard timeframe for making a determination could seriously jeopardize the life or health of the enrollee or the enrollee's ability to regain maximum function. If a request for an expedited decision is made or supported by a physician, the MA organization must provide an expedited determination if the physician indicates that applying the standard timeframe for making a determination could seriously jeopardize the life or health of the enrollee or the enrollee's ability to regain maximum function. The existing medical exigency standard related to expedited requests will continue to apply to organization determinations that involve prior authorization.

The recommended PAS IG may not currently have the instructions to provide the capability to differentiate between standard and expedited prior authorization requests. However, this data element could be a helpful addition for the next version, and interested parties are encouraged to discuss this at an HL7 workgroup meeting. There may be other means through the payer's Prior Authorization API to determine how an indicator for the type of prior authorization request might be incorporated. The current version of FHIR includes a required data element to indicate the urgency of a request. In FHIR technical terminology, this required data element is named “claim.priority.” However, there is no equivalent value in the HIPAA X12 278 transaction standard or the X12 external code lists because that data element is not required in that standard. The PAS IG does not provide any mapping to X12. For those entities conducting the end-to-end FHIR exchange, the information about expedited and standard prior authorization requests is available to them through the FHIR claim.priority data element. As noted, the X12 278 transaction standard does not include this information because the current version of the X12 278 transaction standard for prior authorizations does not support this concept. An alternative to using the claim.priority data element when using the X12 278 transaction standard for expedited requests would be to include a service date, to indicate urgency.

c. Decision Timeframes for Standard and Expedited Prior Authorization Requests

To improve patient care outcomes and ensure that patients have more timely access to services, we are finalizing our proposals to create, improve, or shorten prior authorization timeframes for certain payers to respond to prior authorization requests for covered items and services, excluding drugs. Specifically, we are finalizing that these timeframes would be 72 hours for expedited requests, unless a shorter minimum timeframe is established under applicable state law, and 7 calendar days for standard requests with the possibility of an extension to up to 14 days in certain circumstances. We acknowledged that some of the payers affected by this final rule had different requirements for prior authorization decision notice and appeal timeframes, and we are aligning the prior authorization decision timeframes across those payers except for QHPs on the FFEs, as further discussed. For some payers, the existing regulation already uses the timeframe we are adopting in this final rule for standard or expedited requests for prior authorization; those regulations will continue to apply while amendments to adopt the new timeframes for other payers will apply to their prior authorization decisions, beginning in 2026.

In the CMS Interoperability and Prior Authorization proposed rule (87 FR 76295), we provided a chart identifying which regulations we proposed to modify the decision timeframes for standard prior authorization decisions made by MA organizations and applicable integrated plans, CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities. Table E1 at the end of this section provides the final Federal requirements for prior authorization decision timeframes that will apply to each payer beginning in 2026.

We did not propose to change any existing timeframes that might apply to expedited authorization decisions made by any of the impacted payers, especially given that many of these payers already apply a 72-hour maximum timeframe for such requests. To ensure consistency and correctly describe the new timeframes being finalized for these payers to provide notice of standard determinations, we proposed and are finalizing certain conforming amendments to the CFR sections listed in Table E2.

QHPs are not included in the policy on timeframes for the reasons described at the end of this section. Note that these timeframes do not apply to any drugs, as discussed in section I.D. of this final rule.

We proposed that beginning January 1, 2026, MA organizations and applicable integrated plans must provide notice of prior authorization decisions as expeditiously as a patient's health condition requires, but no later than 7 calendar days for standard requests. For MA organizations, on or after January 1, 2026, prior authorization requests for items and services covered by the finalized requirements at 42 CFR 422.122 will be affected by this final rule; for all other items and services, existing timeframes under the MA regulations for other pre-service requests for an organization determination would remain applicable. These deadlines are reflected in amendments to 42 CFR 422.568(b)(1) (for MA plans) and 422.631(d)(2)(i) (for applicable integrated plans).

We proposed and are finalizing conforming amendments to certain regulations that reference or describe the timeframes that are being amended in this final rule. Specifically, we proposed and are finalizing an amendment to the MA program regulation at 42 CFR 422.570; the revision replaces references to the specific length of the timeframe for standard decisions with a general reference to 42 CFR 422.568 which we are also amending to include the new timeframe(s) for prior authorization decisions for items and services.

In addition, this final rule does not change existing Federal timeframes for expedited and standard determinations on requests for Part B drugs for MA organizations and applicable integrated plans; current regulations require notice to the enrollee as expeditiously as the enrollee's health condition requires, but no later than 72 hours after receiving the request for a standard determination and as expeditiously as the enrollee's health condition requires, but no later than 24 hours after receiving an expedited request. Due to the finalized revisions to 42 CFR 422.568(b), we are redesignating existing 42 CFR 422.568(b)(2) related to requests for Part B drugs for MA organizations to 42 CFR 422.568(b)(3).

Furthermore, an MA plan must automatically transfer a request to the standard timeframe if the MA plan denies a request for an expedited organization determination or an applicable integrated plan denies a request for an expedited integrated organization determination. This step to automatically transfer expedited requests to the standard timeframe is consistent with Medicaid and CHIP managed care provisions listed in Tables E2, E3, and E4.

As there are no existing CMS regulations imposing timeframes for state Medicaid FFS programs to provide notice of prior authorization decisions, in the proposed rule we specified that these programs must provide notice of such decisions as expeditiously as a patient's health condition requires, but no later than 72 hours for expedited requests and 7 calendar days for standard requests unless a shorter minimum timeframe is established under state law. For CHIP FFS, existing regulations require states to provide prior authorizations within 14 days or according to existing state law, in accordance with the medical needs of the beneficiary. Also, a possible extension of up to 14 days may be permitted if the beneficiary requests the extension or if the physician or health plan determines that additional information is needed. To align with Medicaid, we are finalizing for CHIP FFS that beginning in 2026, states must provide notice of prior authorization decisions in accordance with the medical needs of the beneficiary, but no later than 7 calendar days after receiving the request for a standard determination and by no later than 72 hours after receiving the request for an expedited determination.

For Medicaid managed care plans and CHIP managed care entities, we proposed, and are now finalizing, to change the maximum permitted timeframe for the payer to send notices of prior authorization decisions as expeditiously as a patient's health condition requires, but no later than 7 calendar days for standard requests beginning with the first rating period that starts on or after January 1, 2026. We are also finalizing requirements for Medicaid managed care plans and CHIP managed care entities concerning the timeframes for prior authorization of services (under 42 CFR 438.210 and 457.1230) but not the timeframes for issuing notices of other adverse benefit determinations and appeals under 42 CFR 438.404(c)(1) and (2) and 457.1260.

The provisions at 42 CFR 438.210(d)(2)(i) and 457.1230(d) require Medicaid managed care plans and CHIP managed care entities to make an expedited authorization decision no later than 72 hours after receipt of the request if the provider requesting the authorization indicates that following the standard timeframe could seriously jeopardize the beneficiary's life or health or ability to attain, maintain, or regain maximum function. If Medicaid managed care plans or CHIP managed care entities deny an expedited request, that request becomes standard and must be reviewed within 7 days.

State law or managed care plan contracts may impose a shorter timeframe for these decisions in Medicaid and CHIP; the shorter timeframe would govern for state Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities, as applicable. If state law imposes a longer timeframe, payers must comply with Federal regulations within the shorter Federal timeframe—which will automatically make them compliant with their state regulations. For this reason, we are adding to the Medicaid managed care regulations at 42 CFR 438.210(d)(2)(i) and (d)(1), respectively, and CHIP managed care regulations at 42 CFR 457.1230(d), respectively, that the decision must be made as expeditiously as the enrollee's condition requires but no later than 72 hours in the case of expedited requests or 7 calendar days in the case of standard requests unless a shorter minimum timeframe is established under state law.

State laws do not apply to MA plans, based on the preemption provision in section 1856(b) of the Act and at 42 CFR 422.402, which provides that the Federal standards established for MA plans supersede any state law or regulation, other than state licensing laws or state laws relating to plan solvency, with respect to the MA plans that are offered by MA organizations.

This final rule does not change the 72-hour timeframe required by current Federal regulations, or the authority for an extension of that timeframe, for expedited decisions made by MA organizations and applicable integrated plans, Medicaid managed care plans, and CHIP managed care entities.

For the reasons discussed in the CMS Interoperability and Prior Authorization proposed rule, we are not requiring that impacted payers approve a request for prior authorization if that payer did not meet the required standard or expedited decision timeframe (87 FR 76297). If a payer fails to meet the timeline for approval or other decision, providers should contact the payer to obtain the status of the request and determine if supporting documentation is needed to complete the processing of the authorization or if there are other reasons for the delay in a decision. Some programs, such as the MA program (and including applicable integrated plans) and the Medicaid and CHIP managed care programs, have regulations that include provisions for the failure to provide timely notice of an organization determination; generally, such a failure to meet the timeframe constitutes an adverse decision that may be appealed.

The final rule does not change timeframes for prior authorization processes for QHP issuers on the FFEs, in part because existing regulations at 45 CFR 147.136 establish internal claims and appeals processes, external review processes, and pre-service claims requirements for all non-grandfathered group and individual market plans or coverage. Specifically, individual health insurance issuers are required to meet minimum internal claims and appeals standards. The current regulations for group health plans and group and individual market health insurance issuers adequately protect patient interests. QHP issuers on the FFEs are required to provide notification of a plan's benefit determination within 15 days for standard authorization decisions and within 72 hours for expedited requests, which is consistent with the other CMS payers affected by this provision.

We requested comments on the timeframe proposals and provide the summarized comments and responses here.

Comment: Multiple commenters disagreed with the proposal to exclude QHP issuers on the FFEs from prior authorization shortened decision timeframe requirements and recommended that CMS reconsider the exclusion of these payers. Some commenters expressed concern that excluding QHP issuers on the FFEs from shorter prior authorization decision timeframe requirements would result in a negative effect on patient care. Commenters asserted that patients under these plans should be entitled to the same protections as others under this regulation. A commenter stated that they did not believe that shortening a QHP issuer on the FFEs' decision timeframe from the current 15-day response time for standard requests to 7 days would pose an undue burden. Another commenter encouraged CMS to work to align prior authorization notification requirements across all impacted payers as this could avoid confusion amongst patients and providers regarding whether a patient is covered by a QHP. Multiple commenters wrote that CMS should include QHP issuers on the FFEs in regulations requiring even shorter prior authorization decision timeframes: 24 hours for urgent or expedited requests and 72 hours for standard requests. A commenter recommended CMS impose a standard of 24 hours for expedited requests and 48 hours for standard requests and specified that this standard should apply to all payers, including those on the Exchanges. However, multiple commenters supported the proposal to leave in place the current prior authorization decision timeframes applicable to QHP issuers on the FFEs. These commenters raised general concerns about payer burden due to expedited timeframes and agreed specifically that applying expedited timeframes to QHP issuers on the FFEs could harm consumers by reducing participation by QHP issuers on the FFEs. A commenter recommended that timeframes be measured with business days as opposed to calendar days.

Response: We discussed in the CMS Interoperability and Prior Authorization proposed rule the reasons why we did not propose to change timeframes for prior authorization processes for QHP issuers on the FFEs. We did not propose and are not finalizing, any changes to prior authorization timeframes for QHP issuers on the FFEs, in part because existing regulations at 45 CFR 147.136 establish internal claims and appeals processes, external review processes, and pre-service claims requirements for all non-grandfathered group and individual market plans or coverage. Specifically, individual health insurance issuers are required to meet minimum internal claims and appeals standards. We believe the current standard adequately protects patient interests. QHP issuers on the FFEs are required to provide notification of a plan's benefit determination within 15 days for standard authorization decisions and within 72 hours for expedited requests; thus, QHP issuers on the FFEs have the same timeframe for expedited authorization decisions as other impacted payers in this final rule. For reasons discussed in this section, we are not finalizing any timeframes shorter than 72 hours for expedited requests for any impacted payers at this time. Additionally, the benefits for the patient of a shorter timeframe for standard prior authorization decisions should outweigh the additional burden that QHP issuers on the FFEs might experience, as compared to off-Exchange plans. Aligning timeframe requirements for prior authorization decisions across individual and group market plans would reduce the burden of compliance for QHP issuers on the FFEs for the proposed prior authorization requirements while continuing to protect consumer interests. Finally, making changes to regulations applicable to all non-grandfathered group and individual market plans or coverage for consistency with the proposed approach was outside the scope of the proposed rulemaking. While we are finalizing this rule as proposed, the prior authorization information that this final rule requires QHP issuers on the FFEs to publicly report per 45 CFR 156.223(c) will help provide insight into prior authorization timelines and practices that may support further improvements in the future.

Comment: Multiple commenters supported the revised standard prior authorization decision timeframe of 7 calendar days, and many commenters supported the 72-hour decision timeframe for expedited prior authorization requests. Additionally, a commenter requested clarification on whether the 7-day standard decision timeframe would be calendar days or business days. A commenter recommended counting the turnaround time in business days rather than calendar days because processing prior authorization requests requires careful evaluation by payers and a review process that is dependent on working days as opposed to calendar days. Defining the turnaround timeframe by calendar days limits the time needed by payers to accurately reach a decision and is further reduced during holidays. This commenter suggested providing a timeframe that aligns with the number of working hours a payer has to evaluate a request and suggested CMS provide 7 business days. The commenter indicated that such an approach aligns with turnaround times for HIPAA transactions and would therefore prevent confusion over using both calendar days and business days. Another commenter recommended that the proposed standard be reduced from 7 days to 72 hours, stating that tracking timelines using hours instead of days will preclude any confusion or ambiguity regarding calendar days or business days.

Response: We reiterate that current regulations are specific to using hours for expedited requests and we are not modifying the terminology for that requirement of 72 hours for expedited requests. For example, if a prior authorization request is submitted at 1:00 a.m. on Sunday, a response within 72 hours would mean by 1:00 a.m. on Wednesday. The regulations do not contemplate delays based on business hours or business days. For standard prior authorization requests, the current regulations (that is, before the amendments made by this final rule) for MA plans and Medicaid and CHIP managed care programs use the term “calendar days,” in recognition of health care services being agnostic of business days. The amendment we proposed and are finalizing for standard prior authorization decisions is “7 calendar days.” This final rule applies to the business process of the prior authorization request and decision, and not the transmission of the HIPAA standards when used for the request.

Comment: Multiple commenters recommended having shorter decision timeframes that are less than 7 calendar days for standard prior authorization requests, ranging from 5 days, 72 hours, 48 hours, and 24 hours. Some commenters also suggested that decisions be made in real-time. In general, commenters recommended that CMS create faster prior authorization response timelines to improve the patient experience and access to care.

Response: We are finalizing a requirement that prior authorization decisions be rendered as expeditiously as the patient's condition requires, but no later than 7 calendar days requires impacted payers to render their decision based on patient-specific information within 7 calendar days (or shorter if otherwise required via contract or state law) being the maximum. Further, as discussed in the proposed rule, we did not propose to change timeframes for prior authorization processes for QHP issuers on the FFEs, in part because existing regulations at 45 CFR 147.136 establish internal claims and appeals processes, external review processes, and we believe the current standard adequately protects patient interests. We will continue to review these comments and the supporting information to determine how we might incorporate such policies in future rulemaking as part of our ongoing mission to improve the patient and provider experience.

Comment: Another commenter indicated that timely approvals for discharge to an appropriate setting of care are paramount to delivering high-quality care. The commenter explained that inappropriate and lengthy delays in payer responses to requests for transfers to post-acute care settings put patient care at risk. Specifically, the commenter explained that in nine percent of cases, the delay is caused by an untimely response from a payer. The commenter stated that while that percentage may seem low, it accounted for over 20,500 patient encounters across the commenter's system in 2022.

Response: We agree that timely response to such requests can impact patient care, and thus we are finalizing policies to reduce prior authorization decision timeframes. We also encourage payers to review their procedures for this and other similar cases to determine where process improvements would be appropriate to prevent such delays within their own organizations and provider relationships.

Comment: A commenter stated that ensuring appropriate review timeframes to make decisions for patients is critical to avoiding mistakes in care and that accelerated review timeframes increase the risk of failed or non-optimal therapies. A commenter wanted CMS to maintain the current 14-day decision timeframes for standard requests in Medicaid managed care. Another commenter suggested that CMS remove the proposal to shorten prior authorization turnaround timeframes until the Prior Authorization API is implemented and the agency can re-evaluate whether the policy is necessary and then re-issue a proposal. Multiple commenters had concerns about shortening the prior authorization timeframes. Several state commenters expressed concern that they will neither have the staffing capacity nor the operational efficiencies to implement the prior authorization timeframes by the compliance date. Some commenters noted that state legislative approval will be needed to increase state staffing or adjust vendor contracts, requiring additional time to implement. Some commenters also noted that states will need to evaluate and overhaul their entire prior authorization processes to attain the operational efficiencies needed to achieve the shortened decision timeframes.

Response: We thank the commenters for their concerns about accuracy in making decisions about prior authorizations, but that utilization management techniques and other professional safeguards are in place to mitigate such concerns. As we stated in the CMS Interoperability and Prior Authorization proposed rule, shorter prior authorization timeframes will improve patient care, reduce burden, and improve equity (87 FR 76297). The volume and substance of other comments support our proposals to shorten certain existing timeframes, and thus we are finalizing our proposal as described in this final rule. When the Prior Authorization API is implemented in 2027, this resource should further improve efficiencies in the process. We recognize the unique challenges some state commenters shared concerning the practical ability to implement the new prior authorization timeframes in state Medicaid and CHIP FFS by January 1, 2026. We understand that states often require longer timeframes to create new positions, adjust procurement arrangements, and rework system processes. We are willing to work with state Medicaid and CHIP FFS programs that may be unable to meet the new compliance date for the prior authorization timeframes. States should contact their Medicaid state lead or CHIP project officer before April 1, 2025, to discuss their extenuating circumstances. Any flexibility granted to a state Medicaid or CHIP FFS program for the implementation of the new prior authorization decision timeframe requirements will be temporary and limited to the unique circumstances of the program.

Comment: A commenter stated that providers and health plans have multiple exchanges of information back and forth, including additional medical documentation and patient-specific information before a final determination. The commenter noted that the currently proposed decision timeframes do not account for these situations as most requests often require additional information from providers. The commenter also stated that these requirements, in combination with a lack of required information about the data content, could unintentionally increase the number of denials. Multiple commenters stated that shorter timeframes would mean an increase in staff and administrative resources and that without enough time there could be an increase in denials.

Response: We also acknowledge that additional staff resources may be necessary. Firstly, the Prior Authorization API could mitigate communication and staffing issues, once it is fully implemented, but acknowledge that additional staff may be necessary during the implementation process. Also, the focus on process improvement overall may lead to improved efficiencies as payers address opportunities to reduce inefficiencies and meet the requirements of the final rule. Furthermore, the requirement to provide a specific reason for denials, regardless of the method of the prior authorization, should also support improvements in communication between health plans and providers. By making the documentation requirements clearer through the API, providers should submit more complete and appropriate documentation in the first submission, thus enabling quicker processing and fewer denials. Additionally, for Medicaid managed care plans at 42 CFR 438.210(d)(1) and for CHIP managed care entities through an existing cross reference at 42 CFR 457.1230(d), we are finalizing (with slight redesignations from current regulations) a provision that permits standard authorization decisions to have an extension of up to 14 additional calendar days (to the 7-calendar day timeframe) if the enrollee or the provider requests the extension or if the managed care plan justifies a need for additional information and how the extension is in the enrollee's interest. Medicaid managed care plans have been able to utilize a 14-calendar day extension since 42 CFR 438.210(d)(1) was first promulgated in 2001 (66 FR 43670). We believe this provides sufficient time for managed care plans and providers to complete the needed information exchange and enable the managed care plan to render its decision. Similarly for CHIP FFS, we are finalizing our policy at 42 CFR 457.495 to allow for a possible extension of up to 14 days if the enrollee requests the extension or if the physician or health plan determines that additional information is needed to furnish a prior authorization decision.

Comment: A commenter suggested that CMS convene a multi-stakeholder panel of health professionals and payer representatives to determine an appropriate timeframe for prior authorizations.

Response: We do not agree that a multi-stakeholder panel of health professionals and payer representatives is necessary to determine an appropriate timeframe for prior authorizations. CMS has conducted surveys and listening sessions for nearly a decade, as have professional associations. Results are consistent for challenges of timeframes, with the consensus that this issue must be addressed. While some states have additional requirements for decision timeframes, they are not the same across the country. This final rule establishes policies for most of the programs over which CMS has authority to provide consistent and aligned structure for providers and payer communications on this important matter. To continue the conversation with another panel would further delay implementing these important changes that provide the opportunity for improving access to care and ensure that the industry collaborates on a solution to a critical problem that has widespread consensus. CMS will evaluate these reduced timeframes over time to see if future changes are needed, and may at that time conduct additional stakeholder meetings, but at this time we do not believe this is a necessary step to finalizing this policy, which will reduce timeframes and improve prior authorization processes across impacted payers.

Comment: Multiple commenters requested clarification regarding the consequences and the available appeals process if payers do not meet decision timeframes. For example, a commenter stated that for cancer treatments, there should be no extensions unless a peer-to-peer review is needed, and if so, it should only be for 48 hours from the original request. Another commenter stated that policies should be implemented for payer oversight and dispute resolutions like targeted audits and penalties for violations. Multiple commenters highlighted that if decision timeframes are not met there should be a presumption of coverage for standard and pre-service determinations for providers and expedited appeal rights. A commenter noted that payers should be required to provide more information for denials when they do not meet decision timeframes and there should be civil monetary penalties on entities that demonstrate a statistical pattern of unnecessary documentation requests.

Response: We agree that data will be useful for oversight activities. The impacted payers are subject to the oversight and enforcement of the respective programs, in accordance with annual reporting, certification, and/or auditing. We have addressed program enforcement and compliance mechanisms in response to other similar comments in section I.D.2. of this final rule. For Medicaid managed care, 42 CFR 438.66(a) through (c) requires states to have a monitoring system for all of their managed care programs that addresses all aspects of the program and requires that data collected from these monitoring activities are used to improve program performance. Further, 42 CFR 438.66(e) requires states to complete an annual report on the performance of each of its managed care programs, submit that report to CMS, and post it on the state's website. CMS reviews these reports and can take enforcement action when needed. Along with the metrics published under 42 CFR 438.210(f), we will have broad visibility into the timeliness of Medicaid managed care plans' prior authorization decisions. For QHP issuers on the FFEs, penalties associated with failure to comply with deadlines or other provisions of 45 CFR 147.136 are generally within the purview of state regulators. The AMA published a summary of some state initiatives regarding prior authorization practices.

For the reasons discussed in the CMS Interoperability and Prior Authorization proposed rule at 87 FR 76297, we are not requiring that impacted payers approve a request for prior authorization if that payer did not meet the required standard or expedited decision timeframe. If a payer fails to meet the timeline for approval or other decision, providers should contact the payer to obtain the status of the request and determine if supporting documentation is needed to complete the processing of the authorization or if there are other reasons for the delay in a decision. We do not believe it is practical to require payers to default to approval for prior authorization requests for which a timely response has not been provided. Therefore, impacted payers may choose to evaluate process improvements to meet the proposed timeframes and API in this final rule, and consider how to efficiently support provider inquiries on status should responses or timeframes be missed. Some programs, such as the MA program (and including applicable integrated plans) and the Medicaid and CHIP managed care programs, have regulations that include provisions for the failure to provide timely notice of an organization determination; generally, such a failure to meet the deadline constitutes an adverse decision on the prior authorization request that may be appealed.

d. Operational Topics

We solicited comments on what administrative, regulatory, technical, governance, operational, and workflow solutions would need to be addressed, for and by payers, to comply with the proposed timeframes for handling prior authorization review and approval activities. We also solicited comments on what operational or procedural changes payers or providers would need to make in their workflows or systems to reduce decision timeframes from 14 calendar days to 7 calendar days (for standard prior authorization requests) and from 72 hours to 1 day or 24 hours (for expedited prior authorization requests). We indicated that we wished to learn more about barriers that prevent payers from meeting shorter timeframes than those we proposed and requested input on whether MA organizations and applicable integrated plans, state Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities could provide notice of standard and expedited prior authorization decisions within shorter timeframes (for example, 5 calendar days and 48 hours, respectively), and if not, what issues and obstacles prevent that. We solicited comments on whether implementation of the Prior Authorization API could yield process improvements to support shorter decision timeframe requirements for prior authorization requests and on anticipated operational challenges of implementing the API that might affect a payer's ability to meet the proposed timeframes. Finally, we requested comments regarding the costs, benefits, and operational impact on providers and payers, as well as the impact on patients, of making and communicating prior authorization decisions on a shorter timeframe than those in the proposed rule. We received a substantial number of comments on these topics which will be useful as we consider future policies and guidance on these issues.

These policies for the impacted payers are being finalized in this final rule in the CFR sections listed in Table E4.

The timeframe for standard prior authorization requests and expedited organization determinations for certain programs may be extended for either 14 or 15 days for reasons specified and permitted under existing or new policies. The specific citations are provided here for reference.

• Medicaid FFS at 42 CFR 440.230(e)(1)(i). Timeframes for prior authorization decisions under the Medicaid FFS program have been newly established with this final rule. The timeframe for standard authorization decisions can be extended by up to 14 calendar days if the beneficiary or provider requests an extension or if the state agency determines that additional information from the provider is needed to make a decision.
• MA expedited organization determinations at 42 CFR 422.572(b) and MA standard organization determinations at 42 CFR 422.568(b)(1)(i). Extensions are permitted for expedited and standard integrated organization determinations by applicable integrated plans (see 42 CFR 422.631(d)(2)(ii)).
• Medicaid managed care plan expedited authorization decisions at 42 CFR 438.210(d)(2)(ii) and Medicaid managed care plan standard authorization decisions at 42 CFR 438.210(d)(1)(ii). Extensions are permitted for expedited and standard prior authorization requests by up to 14 calendar days under certain circumstances.
• QHP issuers on the FFEs are permitted additional time on expedited requests under certain circumstances when a claimant does not provide sufficient information. See 29 CFR 2560.503–1(f)(2)(i). Limited extensions of the timeframe for standard requests are also allowed under certain circumstances. See 29 CFR 2560.503–1(f)(2)(iii)(A).

5. Requirements for Timing of Notifications Related to Prior Authorization Decisions

This section outlines the regulatory amendments adopted in this rule as applicable based on other laws for the timing of notifications sent by certain payers to patients regarding prior authorization decisions. These requirements also apply to most impacted payers. However, we did not address notifications from the QHP issuers on the FFEs for the same reasons we explained in section II.D.4. of this final rule.

a. Medicare Advantage Organizations

MA organizations are currently required to provide notifications to enrollees of decisions regarding coverage, called organization determinations, which include decisions regarding prior authorizations. To support more timely decisions and communication of those decisions, we proposed to amend 42 CFR 422.568(b)(1) to require MA organizations to notify the enrollee of its prior authorization determination as expeditiously as the enrollee's health condition requires, but no later than 7 calendar days after the organization receives the request for a standard organization determination for a medical item or service subject to the prior authorization rules at 42 CFR 422.122. We also proposed to move the existing language at 42 CFR 422.568(b)(1)(i) and (ii) (regarding extensions of the adjudication timeframe for standard organization determinations) to 42 CFR 422.568(b)(2). We proposed to move the language previously at 42 CFR 422.568(b)(2) to a new paragraph (b)(3). We emphasized that this change to the regulation text structure would not change current requirements and that the proposed new 7-calendar day timeframe would remain subject to the existing standards and limits (currently at 42 CFR 422.568(b)(1)(i), proposed to be at 42 CFR 422.568(b)(2)) related to when an MA organization may extend the adjudication timeframe by up to 14 additional calendar days. For additional explanation on the continued applicability of existing standards, in this final rule, we are adding paragraph (a)(3) to 42 CFR 422.122 to explain that prior authorization decisions made under 42 CFR 422.122 must meet all other applicable requirements in subpart M of part 422, such as the adjudication timeframes and notice requirements. In this final rule we are also adding explanatory language to the beginning of paragraph (b)(1)(i) of 42 CFR 422.568; specifically, we are adding the phrase “For a service or item not subject to the prior authorization rules at § 422.122” to the beginning of the sentence to be clear that those requests not subject to the prior authorization rules at 42 CFR 422.122 will be adjudicated under the existing 14-calendar day timeframe, such as a request for a supplemental benefit that involves an OTC drug or a pre-service request made by an enrollee who is seeking an advance determination on an item or service that is not subject to prior authorization under the rules at 42 CFR 422.122. In contrast, 42 CFR 422.568(b)(1)(ii) sets forth the 7-calendar day timeframe for those requests for a service or item that are subject to the prior authorization rules at 42 CFR 422.122.

We proposed similar amendments to the integrated organization determination requirements at 42 CFR 422.631 for applicable integrated plans. We are making in this final rule explanatory revisions to the regulation text at 42 CFR 422.631 consistent with the revisions made at 42 CFR 422.568 and amended 42 CFR 422.631(d)(2)(i)(B) to state that when a provider makes a request for an item or service, the applicable integrated plan must notify the enrollee of its determination as expeditiously as the enrollee's health condition requires, but no later than 7 calendar days after the organization receives the request for a standard pre-service organization determination that is subject to 42 CFR 422.122. We also proposed an amendment to 42 CFR 422.631(d)(2)(iv)(B) to state that when an applicable integrated plan denies a request for an expedited determination and automatically transfers the request to the standard timeframe, it must make its determination within the applicable timeframe established at 42 CFR 422.631(d)(2)(i)(B). This means that for prior authorization requests within the scope of 42 CFR 422.122, the 7-calendar day timeframe applies, rather than the current 14-calendar day timeframe for an integrated organization determination. These changes also apply to applicable integrated plans that are MCOs as defined at 42 CFR 438.2, because per 42 CFR 438.210(d)(4), 42 CFR 422.631 also applies to these Medicaid plans. These amendments are consistent with changes for other Medicaid managed care plans being finalized at 42 CFR 438.210(d)(1) and (2). Concerning MA organizations (including applicable integrated plans), our proposal was limited to the timeframes for standard determinations involving prior authorization, and there are no changes to the timeline for expedited integrated organization determinations, extensions, or the requirements for notice to enrollees.

Comment: A commenter urged CMS to require that any failure by an MA plan or applicable integrated plan to provide notice of an organization determination within the same timeframes (and without having requested an extension) constitute a deemed denial for which the provider may request a reconsideration by an independent reviewer.

Response: We acknowledge this commenter's concern about the failure of MA plans to provide notice within the required timeframes. Under the existing MA rules, a failure to meet the deadline by which an organization determination, including a request for prior authorization, constitutes a denial that can be appealed to the next level (reconsideration by the MA organization). See 42 CFR 422.568(f) and 422.631(d)(1)(ii). The MA program regulations (42 CFR 422.592 through 422.596 and 422.634) provide for review by an Independent Review Entity (IRE) after an MA organization's adverse reconsidered organization determination, including where the MA organization fails to issue a reconsidered organization determination in a timely fashion. We did not propose, and are therefore not finalizing here, an amendment to those rules to escalate prior authorization denials to the IRE. However, the existing regulations at 42 CFR 422.590(h)(1) and 422.629(k)(4) provide that for reconsiderations by MA plans and applicable integrated plans, the individuals who make the reconsideration determination must not have been involved in the organization determination. We also reiterate that providers should follow up on the status of a request with the payer. Failure to respond to a request for the status of the pending prior authorization request does not constitute a denial (unless the lack of response continues beyond the deadline for response) but may indicate other issues in the process such that an appeal may not be necessary. We acknowledge that issues in communication between payers and providers may continue to exist, and encourage providers to notify payers or CMS of any patterns for poor communication and untimely issuance of prior authorization decisions.

b. Medicaid Fee-for-Service, Including Beneficiary Notice and Fair Hearings

For the Medicaid FFS program, we proposed, in the CFR sections listed in Table E2, regulatory timeframes to provide notice of decisions on both expedited and standard prior authorization requests. We stated that the new requirements would apply to prior authorization decisions beginning January 1, 2026. We are finalizing that policy in this final rule.

Under the new requirement for Medicaid FFS, which appears at 42 CFR 440.230(e)(1), notice of the state Medicaid program's decision regarding an expedited request for prior authorization will have to be communicated as expeditiously as a beneficiary's health condition requires, but no later than 72 hours after receiving a provider's request for an expedited determination, unless a shorter minimum timeframe is established under state law. Notice of a decision on a standard request for prior authorization will have to be communicated to the requesting provider as expeditiously as a beneficiary's health condition requires, but no later than 7 calendar days after receiving the request, unless a shorter minimum timeframe is established under state law. If the state determines that it needs additional information from a provider to make a decision, or if the beneficiary or provider requests an extension, the proposed decision-making and communication timeframe for a standard request may be extended by up to 14 calendar days if the beneficiary or provider requests an extension, or if the state agency determines that additional information from the provider is needed to make a decision. Such extensions may be justified and in the beneficiary's interest if medical evidence from outside providers is needed to support the request, or if there are other circumstances identified by either the provider or the beneficiary.

Independent of this final rule's API proposals and their application to Medicaid prior authorization requests, Medicaid has longstanding beneficiary notice and fair hearing regulations. CMS has interpreted these existing regulations to apply to prior authorization requests for Medicaid FFS and will continue to do so in the future. These existing Medicaid beneficiary notice and fair hearing requirements will remain in full effect without change, in concert with other provisions of this final rule, including the Prior Authorization API.

As discussed in detail in the proposed rule (87 FR 76299 and 76300), the current Medicaid notice and fair hearing regulations at 42 CFR 435.917 and 42 CFR part 431, subpart E, apply to all prior authorization decisions. Therefore, states are required to—

• Provide the beneficiary with timely and adequate written notice of any decision regarding the beneficiary's prior authorization request;
• Include the content described at 42 CFR 435.917 and at 42 CFR part 431, subpart E, including information about the beneficiary's right to request a fair hearing to appeal the partial or total denial, in the beneficiary notice when a state denies the prior authorization request in whole or in part;
• Provide beneficiaries the opportunity to request a fair hearing if the state fails to act on a claim, which includes prior authorization requests, with reasonable promptness; and
• Provide at least 10-day advance notice to beneficiaries of any termination, suspension of, or reduction in benefits or services for which there is a current approved prior authorization, including information regarding the beneficiary's right to request a fair hearing.

These notice and fair hearing requirements are not affected by any of the changes made elsewhere in this final rule. As noted in the CMS Interoperability and Prior Authorization proposed rule, the Medicaid notice requirements are separate from and independent of, the new timeline for provider notice that is finalized at 42 CFR 440.230(e)(1).

To make it explicit that existing Medicaid beneficiary notice and fair hearing rights apply to Medicaid FFS prior authorization decisions, we proposed several updates to the existing regulations at 42 CFR 431.201, 431.220, and 435.917, and a new 42 CFR 440.230(e)(2). The proposed changes are intended to further explain, but not change, Medicaid notice or fair hearing policy or operational requirements for states. We proposed and are finalizing, with one exception discussed below, that the changes referenced in this paragraph take effect on the effective date of the final rule. Please see 87 FR 76300 for the detailed text. The regulations and amendments are listed in Table E3.

The proposed changes for 42 CFR 431.201 included replacing the term “beneficiary” with “enrollee” in the revised definition of “Action.” This change was proposed in error, and the preamble to the CMS Interoperability and Prior Authorization proposed rule did not discuss the potential impact of changing “beneficiary” to “enrollee” on the definition of “Action.” In this final rule, we are reverting to the term “beneficiary” in the definition of “Action” at 42 CFR 431.201, consistent with the current definition and with our stated intent in the proposed rule that the changes would not change Medicaid notice or fair hearing policy or operational requirements for states.

We received comments on fair hearings and provide those and our responses here.

Comment: Multiple commenters expressed support for our proposal to further explain the application of Medicaid notice and fair hearing requirements to Medicaid FFS prior authorization decisions and recommended that the proposed changes be codified. A few commenters noted that states already apply notice and fair hearing requirements to Medicaid FFS prior authorizations. Multiple commenters noted that Medicaid agencies already have provider hearing rights for prior authorization decisions in place.

Response: We appreciate commenters' support for the proposed updates to the Medicaid notice and fair hearing regulations, which we are finalizing as proposed.

Comment: A few commenters noted that patients should receive equitable fair hearing rights for their prior authorizations, regardless of whether they are enrolled in a Medicaid FFS or a managed care plan. A few commenters expressed support for the proposed changes which would explain that Medicaid FFS notice and fair hearing requirements are consistent with current regulations for notice and appeal rights for managed care prior authorization decisions.

Response: We agree that comparable and aligned notice and fair hearing rights should apply across delivery systems. As discussed in the CMS Interoperability and Prior Authorization proposed rule, we have historically interpreted the existing Medicaid notice and fair hearing regulations to apply to prior authorization requests for Medicaid FFS. Given the alignment between these state-level requirements and the managed care plan-level requirements, equitable notice and appeal rights have been and will continue to be available to Medicaid FFS and managed care beneficiaries and that the updates, which we are finalizing as proposed, will further strengthen the existing alignment between delivery systems regarding notices and fair hearings/appeals.

Comment: A commenter stated that there needs to be more clarification in the rule that existing Medicaid beneficiary notice and fair hearing rights apply to prior authorization decisions for Medicaid FFS beneficiaries. Another commenter recommended CMS mandate more details on the hearing process to ensure that a hearing can be conducted expeditiously and objectively. A commenter recommended that the language in the regulation be strengthened to explicitly state that failure to act on a request for prior authorization will give rise to notice and hearing rights.

Response: The updates we are making to these regulations, which we are finalizing as proposed, provide additional details regarding how Medicaid beneficiary notice and fair hearing rights apply to prior authorization decisions for Medicaid FFS beneficiaries. These changes provide further detail about, but do not change, the current application of these regulations to Medicaid FFS prior authorization decisions. Therefore, the existing requirements for the fair hearing process at 42 CFR part 431, subpart E, apply to Medicaid FFS prior authorization fair hearings. These include a requirement that fair hearings must be conducted by an impartial person who was not directly involved in the initial decision (42 CFR 431.240(a)(3)) and requirements for when the state must take final administrative action on a fair hearing request (42 CFR 431.244(f)). These regulations also require the state to provide notice to a beneficiary (42 CFR 431.206(c)(2)) whenever a hearing is required in accordance with 42 CFR 431.220(a), which includes when the state fails to act upon a claim, including a prior authorization decision, with reasonable promptness.

Comment: A commenter recommended that CMS expand on proposed 42 CFR 440.230(e)(2) to require written notice of a prior authorization decision be provided to the provider as well as the beneficiary.

Response: The Medicaid notice and fair hearing provisions at 42 CFR 435.917 and 42 CFR part 431, subpart E, which are cross referenced at 42 CFR 440.230(e)(2), apply to applicants and beneficiaries, not providers. Therefore, we decline this recommendation and will finalize 42 CFR 440.230(e)(2) as proposed. There are separate requirements regarding provider notification of prior authorization decisions. As stated in this final rule, we are finalizing requirements for payers to provide a specific reason for denials, as well as the status of a prior authorization, either through the Prior Authorization API as specified, or through existing processes. When providing a status for a prior authorization, the response must indicate whether the payer approves (and for how long) or denies (and the reason) the prior authorization request, or the payer may request more information from the provider to support the prior authorization request.

Comment: A commenter raised concerns about whether and how notice and appeal rights can be provided electronically and noted that lower-income consumers may have inconsistent access to electronic communications. This commenter recommended that HHS continue to require a redundant written notice for all important Medicaid notices, including those related to prior authorization.

Response: The provision of electronic notices to Medicaid applicants and beneficiaries is addressed at 42 CFR 435.918. Individuals must be provided a choice to receive notices in electronic format or by regular mail and have the option to request that all electronic notices also be provided by regular mail. Changes to 42 CFR 435.918 are outside the scope of this rule. The Medicaid notice requirements, which include the provision of fair hearing rights, will continue to apply unchanged when API-based notifications begin. Therefore, low-income beneficiaries enrolled in Medicaid will continue to receive notices by mail, electronically, or both, even after the API-based notifications begin.

Comment: A commenter expressed that CMS's proposal to make explicit the requirement for a fair hearing to appeal prior authorization non-compliance is inadequate to address prevalent and profitable wrongful denials of prior authorization. This commenter stated that very few patients can appeal wrongful denials and rarely do appeal and noted that medical practices aren't compensated for prior authorizations or appeals, which harms patients as well.

Response: Fair hearings are an important part of a beneficiary's due process rights. While fair hearings cannot directly prevent inappropriate denials of prior authorization requests, they do provide a pathway for a beneficiary to remedy an inappropriate prior authorization denial, termination, or reduction and provide data to states to help them identify problems with the prior authorization process. We believe that improvements in the process overall will occur by using the API once that is in place, as providers will have additional information on which to base the submission of an initial prior authorization request.

c. Medicaid Managed Care

For Medicaid managed care, we proposed new timeframes for notice of decisions on standard (non-expedited) prior authorization requests which would apply beginning with the rating period that starts on or after January 1, 2026, and proposed to revise 42 CFR 438.210(d)(1) and (2) to accomplish this. Specifically, we proposed to revise 42 CFR 438.210(d)(1) to reflect that, beginning with the rating period that starts on or after January 1, 2026, managed care plans must provide notice of standard authorization decisions as expeditiously as the enrollee's health condition requires and within state-established timeframes that may not exceed 7 calendar days following the plan's receipt of the request for service. Our proposed amendment provided that for rating periods that begin before January 1, 2026, the current rule would remain in effect. We proposed to specify the standard authorization requirements by the compliance dates by leaving the section header “Standard authorization decisions” as 42 CFR 438.210(d)(1) and redesignating standard authorization timeframes as 42 CFR 438.210(d)(1)(i)(A) and (B). We also proposed to move the current regulation text on extending the prior authorization decision timeframe from 42 CFR 438.210(d)(1)(i) and (ii) to 42 CFR 438.210(d)(1)(ii)(A) and (B) and proposed to make slight revisions to the text for readability. We explained that our proposal would not change the current provisions for how failure to issue a decision within the required timeframe constitutes an adverse benefit determination that can be appealed under 42 CFR 438.404(c)(5). The regulations at 42 CFR 438.404 and other regulations governing appeal rights at 42 CFR part 438, subpart F, would continue to apply and we did not propose to amend those regulations. We note that 42 CFR 438.404(c)(3) through (6) provide that certain adverse benefit determinations must be issued on the timing specified at 42 CFR 422.210(d); the new timeframes proposed (and finalized) in this rulemaking will apply to those specific adverse benefit determinations. In addition, under current regulations at 42 CFR 438.3(s)(1) and (6) and 438.210(d)(3), Medicaid managed care plans must also comply with the requirements in section 1927 of the Act regarding coverage and prior authorization of covered outpatient drugs; nothing in this rulemaking would change these requirements. Finally, because some Medicaid MCOs are applicable integrated plans as defined at 42 CFR 438.2, our proposal related to 42 CFR 422.631(d) applied to those plans.

We received a few comments on this subject and provide our responses to those here.

Comment: A commenter agreed with the proposal to provide notice of decisions for standard prior authorization requests within state established timeframes not exceeding 7 calendar days, and another commenter disagreed with the proposal to shorten the maximum amount of time for Medicaid managed care plans to respond with a decision from 14 to 7 days. Another commenter proposed that the standard should be 24 hours or less for standard requests. A commenter stated that Medicaid and CHIP managed care programs already have requirements to issue prior authorization decisions within a certain timeframe established by the state and that those standards provide adequate protection for enrollees and providers.

Response: As we stated in the proposed rule, and based on CMS and other industry studies on the impact of delays to patient health or access to care from extended authorizations, reducing standard prior authorization decision timeframes from 14 calendar days to 7 calendar days should improve patient care outcomes and ensure that patients have more timely access to services (87 FR 76296).

d. CHIP Fee-for-Service and Managed Care

To implement the proposed prior authorization timeframes for CHIP, we proposed to revise certain policies affecting the timing for making decisions on prior authorization requests under the CHIP FFS and managed care programs. These changes are listed in Table E2. We proposed that beginning on January 1, 2026, decisions related to prior authorization of health services would be required to be completed in accordance with the medical needs of the patient, but no later than 7 calendar days after receiving the request for a standard determination and 72 hours after receiving the request for an expedited determination, unless an alternative option is preferred by industry based on public comments. Further, we stated that if a beneficiary requests an extension of a prior authorization review, or if the provider or health plan determines that additional information is needed for such review, an extension of up to 14 calendar days may be granted. We proposed to remove the option for states to follow existing state law regarding prior authorization of health services, requiring states to instead follow these updated timeframes. However, if state laws are more stringent than our proposal, states would be allowed to apply and enforce those shorter timeframes for prior authorization responses. Timely prior authorization decisions are important patient protections, and CHIP patients should be afforded the same decision timeframes as Medicaid and Medicare patients.

Existing CHIP regulations at 42 CFR 457.1130(b) require a state to ensure that a beneficiary has an opportunity for external review of health services matters, including a delay, denial, reduction, suspension, or termination of health services, in whole or in part, including a determination about the type or level of service. Under this regulation, CHIP beneficiaries must have an opportunity for external review of prior authorization decisions. We did not propose any changes to this requirement, as it already applies to decisions related to the prior authorization of services.

In the CMS Interoperability and Prior Authorization proposed rule we explained that overall, we believed that the decision and notification timeframes proposed for certain impacted payers would help ensure that prior authorization processes do not inappropriately delay patient access to necessary services. Introducing prior authorization decision timeframes that are the same across these impacted payers for items and services that require prior authorization would also help providers better organize and manage administrative resources and thus may make more time available for providers to render patient-centered care.

Currently, CHIP managed care program regulations reference the Medicaid managed care regulations for the timelines and requirements for CHIP managed care entities as to prior authorization decisions and notices as well as appeal processes. We explained in the proposed rule that the proposal to amend 42 CFR 438.210(d) for timeframes would also apply to standard and expedited decisions made by CHIP managed care entities because of the cross reference to 42 CFR 438.210 in current 42 CFR 457.1230(d). We did not propose to change the required timeframes for expedited decisions at 42 CFR 438.210(d)(2), but we proposed to amend 42 CFR 438.210(d)(2)(i) to explain that the MCO, PIHP, or PAHP must make these decisions on shorter timeframes if the state requires shorter timeframes. We did not propose any changes to the authority for a 14-calendar day decision timeframe provided at 42 CFR 438.210(d)(2)(ii).

We received the following comments related to CHIP FFS and managed care and include our responses to those comments here.

Comment: A commenter disagreed with CMS's proposal to shorten the maximum amount of time for CHIP FFS and managed care to respond with a decision from 14 to 7 days. The commenter proposed that the standard should be 24 hours or less. Another commenter recommended CMS provide equal protection for children enrolled in CHIP FFS against unnecessary delays in accessing necessary services due to prior authorization procedures. The commenter also recommended that state CHIP agencies follow the same rules as state Medicaid agencies, including specific timelines for prior authorization responses for outpatient prescription drugs. Another commenter expressed their support for aligning the beneficiary protections in CHIP and Medicaid managed care and recommended CMS maintain 42 CFR 457.1230(d) as proposed, applying 42 CFR 438.210 to CHIP managed care entities with the proposed shorter timelines for responses to standard requests for prior authorization, characterizing these as stronger beneficiary protections.

Response: Though we anticipate the Prior Authorization API will introduce additional efficiencies into the prior authorization process, we are uncertain that such a truncated standard decision timeframe would be possible until we have completed further data collection and analysis after the implementation of the API. The recommendation concerning CHIP prior authorization decision timeframes for outpatient prescription drugs is outside the scope of the final rule. We agree with comments that recommend CHIP prior authorization decision timeframes be in alignment with Medicaid.

We are finalizing the proposals to adopt the timeframes we proposed for responses by MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities to prior authorization requests. We are not requiring that impacted payers approve a request for prior authorization if that payer fails to meet the required standard or expedited decision timeframe. If a payer fails to meet the timeline for approval or other decision, providers should contact the payer to obtain the status of the request and determine if supporting documentation is needed to complete the processing of the authorization or if there are other reasons for the delay in a decision. The 72-hour requirement for expedited requests is measured in hours, whereas the 7-day requirement for standard requests is measured in calendar days. In the case of expedited and standard requests, the timeframes are 72 hours and 7 days, respectively, unless a shorter minimum timeframe is established under state law.

Tables E2 and E3 provide a list of some, but not all of the final policies for decision notification timelines for the impacted payers. The full list of final policies and citations is included in Table E4 at the end of this section. We included these tables for ease of reference for the narrative on the discussion of notifications and timeframes.

Table E3 is specific to the Medicaid FFS notice and fair hearings provisions, which provide an important service to beneficiaries and providers alike. This rule finalizes modifications to those provisions, and this table and accompanying narrative provide the reader with citations to new and existing provisions.

6. Extensions, Exemptions, and Exceptions

See section II.E. of this final rule for a discussion of extensions and exemptions and the final policies for the Prior Authorization API for state Medicaid and CHIP FFS programs and exceptions for the Prior Authorization API for QHP issuers on the FFEs (this was also addressed in the proposed rule at 87 FR 76279).

7. Public Reporting Requirements for Prior Authorization Metrics

In the CMS Interoperability and Prior Authorization proposed rule we discussed the importance of accountability for payer prior authorization practices and proposed that certain data be made publicly available for patients and providers to better understand the types of items and services which required prior authorization and how each payer performed over time for approvals and denials. We are finalizing our proposal to require impacted payers to report certain aggregated metrics about prior authorization by posting them on the payer's website. This requirement underscores the importance of transparency and accountability in the health care system. Public disclosure of the items and services which are subject to prior authorization, as well as organizational performance, offers useful information to providers, patients, and other interested parties. Performance data could allow for objective evaluation of the efficiency of prior authorization practices of each organization, and it enables payers to assess trends, identify areas for improvement, and work towards continuous process improvement while maintaining necessary quality checks for quality and appropriateness of care.

We are finalizing as proposed that state Medicaid and CHIP FFS programs will report at the state level, Medicaid managed care plans and CHIP managed care entities will report at the plan level, and QHP issuers on the FFEs will report at the issuer level. We are finalizing a modification to our proposal for reporting to be at the organization level to require that reporting be at the contract level for MA organizations as discussed in this section (section II.D.7. of this final rule). Additionally, we explain that integrated plans will report items and services covered by MA organizations at the MA contract level and items and services covered by Medicaid managed care plans at the plan level as the separate requirements for MA organizations and Medicaid managed care plans will apply under the respective contracts.

We described how payers might use the information for process improvements and performance analysis in the proposed rule (87 FR 76304). For example, an impacted payer could use these data to examine its performance trends. In addition, we explained how providing this information publicly would benefit patients (who could use the information when selecting among plan or organization options) and providers (in when and whether to contract with an impacted payer). The legal authority for requiring such public reporting is discussed in section II.D.10. of this final rule.

We are finalizing our proposal that for each metric listed, data would be reported in aggregate for all items and services. We received many comments on the proposed public reporting of metrics, the timing, and the level of reporting. The suggestions were detailed and represented diverse issues and concerns from interested parties about prior authorization challenges and potential uses for the data. CMS will use the comments received as CMS considers future policy development. We intend to support transparency and accountability and enable patients to access data that are meaningful and easy to use for decision-making and understanding the prior authorization processes. The metrics we are finalizing represent the most significant issues for both patients and providers identified over the past decade on a national level, including the CMS listening sessions referenced at the beginning of this section. Furthermore, payers can supplement the information they report with additional metrics on prior authorization. We may consider additional reporting options in the future. We reiterate that the prior authorization reporting metrics are on medical items and services, excluding drugs covered by the impacted payers.

We are finalizing the requirement for impacted payers to make reports available annually on all of the following:

• A list of all items and services that require prior authorization.
• The percentage of standard prior authorization requests that were approved, aggregated for all items and services.
• The percentage of standard prior authorization requests that were denied, aggregated for all items and services.
• The percentage of standard prior authorization requests that were approved after appeal, aggregated for all items and services.
• The percentage of prior authorization requests for which the timeframe for review was extended, and the request was approved, aggregated for all items and services.
• The percentage of expedited prior authorization requests that were approved, aggregated for all items and services.
• The percentage of expedited prior authorization 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 prior authorizations, 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 prior authorizations, aggregated for all items and services.

a. Reporting Prior Authorization Metrics

As described previously, we proposed to require impacted payers to report certain metrics to support a level of accountability for the requirements in this final rule. As discussed previously, public disclosure of information for each audience—patients, providers, and the general public—supports the intent of this final rule to improve the prior authorization process, patient care, and burden reduction.

Comment: Many commenters supported CMS's efforts to promote transparency through public reporting of these aggregated metrics. These commenters believe such reporting will increase transparency from payers related to the volume of prior authorizations. For example, a commenter wrote to encourage CMS to propose in future rulemaking to use the prior authorization data the agency would collect from impacted payers to help develop quality measures to incorporate into quality ratings across certain payer programs, specifically for MA organizations. This would ensure that such data are incorporated more directly into a consumer-friendly comparison tool so that payers' prior authorization practices are available to physicians and practitioners, including gastroenterologists, to ensure transparency and accountability in the prior authorization process. Multiple commenters stated that reporting metrics could be informative to providers in the context of what they submit to payers for prior authorization requests, as the data might provide insights about the types of services that are approved or denied. A commenter noted that prior authorization metrics could be useful to patients as they decide which health plans to select, and another commenter appreciated that CMS's proposal aimed to strike a balance between data reporting burden and providing meaningful data to consumers and providers. Another commenter supported reporting prior authorization metrics on the payer's website by March 31, 2026. Some commenters believed that CMS should require public reporting of the metrics sooner than proposed, and multiple commenters recommended that CMS require the public reporting requirement immediately upon finalizing the rule.

Response: We thank commenters for their support of our proposed prior authorization reporting metrics, including those commenters who recommended that CMS consider additional future uses for the data for other program purposes and require compliance as soon as the rule is finalized. We agree that payers have the data available now, as they are currently conducting the prior authorization process, and that the data would provide a baseline for reporting. As proposed and finalized, CMS is not collecting these data, but instead requiring impacted payers to post such data on the payer's website. We encourage payers to consider developing and posting reports of these metrics at the earliest date feasible. We are finalizing the requirements for public reporting as well as the compliance dates in 2026, as proposed.

Comment: Multiple commenters recommended that CMS require payers to report prior authorization data at a more granular level. Specifically, multiple commenters recommended that CMS require MA organizations to report prior authorization metrics at the plan level or state level. Commenters stated that the organization level for MA organizations was a higher level of aggregation than the plan level for Medicaid managed care plans and CHIP managed care entities and therefore would not present the same level of detail. Those commenters pointed out that MA organization metrics reported at the organization level would not be useful to consumers choosing plans in their area. Other commenters suggested more discrete reporting levels, including county level, specialty/benefit level, or service level.

Response: Upon further consideration and taking the comments into account, we determined that contract level is the more appropriate reporting level for MA organizations. MA organizations generally have multiple plans under the same contract as it is common throughout the industry to offer a variety of plans within a service area. Contract-level data are aggregated data that are collected from the plan benefit packages (PBPs) (that is, the various MA plans) offered under an individual contract; these data are specific to the contract to which they correspond. CMS already requires MA organizations to report some contract-level data about their organization determinations to the agency on an annual basis and Star Ratings are assigned at the contract level. While this particular provision does not require MA organizations to submit data to CMS, a consistent approach of contract-level reporting in the MA program will give consumers useful information while limiting plan burden. By requiring contract-level reporting for these data, we ensure that the format of this reported data remains consistent with that of other similar data that MA organizations are required to report.

We agree that requiring Medicaid managed care plans and CHIP managed care entities to report at the plan level will allow beneficiaries and states to compare plans within the state. Requiring QHP issuers on the FFEs to report at the issuer level, aggregating plans under their purview, is consistent with their reporting on quality improvement strategies as described in section 1311(g) of the Affordable Care Act (45 CFR 156.1130), which provides consistency with other QHP reporting requirements.

While we understand the desire from some commenters to increase the level of granularity for reporting, we have concerns about data overload, patient understanding, and usability of the data. For example, reporting at the specialty level and service level could be overwhelming because of the volume of information presented. A patient might not be able to relate to the data and would not refer to the reports as intended. There can and should be both transparency and accountability in the information that is presented to the public and we will continue to explore opportunities to strike the appropriate balance with impacted payers. We are finalizing a modification to our proposal for MA organizations to report at the contract level. We are finalizing, as proposed, that state Medicaid and CHIP FFS programs will report at the state level, Medicaid managed care plans and CHIP managed care entities will report at the plan level, and QHP issuers on the FFEs will report at the issuer level.

We may assess whether to collect more detailed metrics than we are finalizing here in program-specific rulemaking in the future. For instance, we may consider requiring in future rulemaking that MA plans report at a more discrete level. Similarly, should a state Medicaid or CHIP agency believe it would be beneficial to require more detailed data, the state may require additional metrics in its managed care contracts.

Comment: A commenter requested clarification on whether integrated care plans for dually eligible individuals, such as FIDE SNPs, should report these data consistent with MA organizations, at the contract level, or consistent with Medicaid managed care plans, at the plan level.

Response: Integrated care plans generally combine D–SNPs, which include FIDE SNPs and HIDE SNPs—both as defined at 42 CFR 422.2—and Medicaid managed care plans offered by the same parent organization. D–SNPs are a type of MA plan designed to meet the needs of individuals who are dually eligible for Medicare and Medicaid, also known as dually eligible individuals. In these arrangements, there is an MA organization with a contract with CMS for the MA D–SNP and an organization with a contact with the state for the Medicaid managed care plan.

For items and services that require prior authorization under an integrated plan's MA benefit package, data must be reported in a manner consistent with the requirements for MA organizations, which we are finalizing at the contract level. In the case of integrated care, the affiliated Medicaid managed care plan will report prior authorizations of items and services covered under the plan's Medicaid benefit package at the plan level. Where there is not a clear delineation between whether items or services are covered under Medicare or Medicaid (for example, home health services), we will accept any reasonable methodology for attributing the prior authorization reporting to one payer versus the other.

Comment: Multiple commenters recommended a more phased-in approach to the reporting of prior authorization metrics. A commenter stated that while prior authorization metrics should not be publicly reported until after the electronic FHIR APIs have been implemented, the prior authorization metrics should still be reported to CMS beginning March 2026. A commenter recommended that CMS begin to phase in reporting requirements before the 2026 implementation period (for example, require payers to report some, but not all, metrics soon after the rule is finalized) to help identify any issues with the reporting process so that they can be addressed timely.

Response: We disagree that a phased-in approach to reporting metrics is necessary given that payers already conduct prior authorization processes and likely already track data for many of the metrics for their usual business operations. We are finalizing compliance dates in 2026, as stated previously. We agree that reporting prior authorization metrics conducted using the Prior Authorization API will not be reported until after the Prior Authorization API has been implemented, and that the technology could be capable of supporting automated reporting on its use. The metrics to be included in the reports beginning in March 2026 will be based on an impacted payer's current prior authorization processes, in advance of implementation of the Prior Authorization API. Reporting information about performance data in advance of implementation could provide valuable data in the years post-implementation.

Comment: Multiple commenters expressed concerns about how the prior authorization metrics could be used by payers in inappropriate or harmful ways to providers. A commenter flagged that the publicly reported metrics could lead to plans “self-selecting” patients by implementing other burdensome prior authorization processes to avoid approving services, which could lead to patients who need those services enrolling in other plans. Another commenter recommended that CMS address steps it will take to protect against adverse selection. This commenter urged CMS to consider how it will mitigate unintended consequences that may occur as competing payers decide to analyze each other's data once it becomes public. The commenter wrote that CMS should make clear that any such practices would be against the spirit and intent of the reporting requirements.

Response: We acknowledge concerns by a few commenters that prior authorization policies and information on the publicly reported metrics could technically be used inappropriately for improper decision-making purposes or other reasons. Public reporting does not in and of itself create such behavior. However, we believe requiring that public availability of prior authorization metrics will have the opposite effect; that is, payers will use the data to try to improve their performance to improve their competitive standing in a program.

In addition, there are some safeguards in place to help address the concerns raised by commenters about inappropriate efforts to discourage enrollment by individuals who need certain covered services. Medicaid managed care regulations also provide significant patient protections for access to covered services at 42 CFR 438.206 through 438.210. For example, 42 CFR 438.210(a) requires states' contracts with Medicaid managed care plans to identify, define, and specify the amount, duration, and scope of each service covered by the plan and such amount, duration, and scope must be no less than that furnished to Medicaid FFS beneficiaries. Existing regulations at 42 CFR 438.66 require states to have a monitoring system that addresses all aspects of each Medicaid managed care program and to use the data collected from their monitoring activities to improve the performance of their managed care program, including at a minimum enrollment and disenrollment trends in each managed care plan. Additionally, 42 CFR 438.66(e) requires states to submit to CMS a report on each of their Medicaid managed care programs that provides information on and an assessment of the operation of the managed care program.

Further, section 1852(b)(1) of the Act prohibits discrimination by MA organizations on the basis of health status-related factors and directs that CMS may not approve an MA plan if CMS determines that the design of the plan and its benefits are likely to substantially discourage enrollment by certain MA eligible individuals. In addition, MA organizations must comply with applicable Federal civil rights laws that prohibit discrimination on the basis of race, color, national origin, sex, age, or disability, including section 1557 of the Affordable Care Act, Title VI of the Civil Rights Act of 1964, section 504 of the Rehabilitation Act of 1973, and the Age Discrimination Act of 1975. The regulation at 42 CFR 422.110 provides that an MA organization may not deny, limit, or condition the coverage or furnishing of benefits to individuals eligible to enroll in an MA plan offered by the organization on the basis of any factor that is related to health status. MA organizations discouraging or preventing enrollment in an MA plan by beneficiaries by implementing burdensome prior authorization processes to avoid approving services would be prohibited by 42 CFR 422.110. CMS relies on the MA anti-discrimination provision; the agency's authority under section 1856(b) of the Act to adopt standards for MA organizations; and the agency's authority under section 1857(e) of the Act to add terms and conditions that are necessary, appropriate, and not inconsistent with the Medicare statute. CMS does not collect detailed information on prior authorization policies as part of the bid. However, CMS will continue to monitor for potential discrimination by plans through prior authorization and other utilization management programs in our review of complaints received from beneficiaries and providers and will take action, as necessary. CMS may also consider future sub-regulatory guidance based on a review of complaints.

We also believe that MA and other managed care plans will use the published data to drive performance improvement to facilitate provider network development and that providers will use the prior authorization metrics to evaluate managed care plans and make decisions on whether to join or remain part of a plan's network.

Comment: A commenter recommended that if CMS intends to require public reporting in the final rule, CMS should explain how the data would benefit interested parties and conduct education and outreach to prevent confusion or misinterpretation of data. Multiple commenters stated their hesitation to require public reporting of prior authorization data without understanding the purpose of the reporting, and another recommended that CMS reevaluate the need and value of payers reporting the prior authorization metrics versus its costs and resource burden. Multiple commenters highlighted the significant new administrative burden that reporting prior authorization metrics would cause. Other commenters recommended that CMS remove the proposed requirement for payers to publicly report prior authorization metrics.

Response: We are aware that payers have many reporting requirements for state and Federal programs and that preparing these public disclosures may require additional effort. Payers also provide educational resources to patients and providers for enrollment, directories, and other health care reminders—all to explain benefits and services and improve the health care experience. We are finalizing policies in this final rule to address longstanding, important process challenges related to prior authorization. Reporting on these metrics, including, for example, the services that require prior authorizations, the number of denials, those approved, and those overturned after appeal, will give the patients and providers a better understanding of payer performance in those categories—and over time—of the changes in performance in those categories. These data will demonstrate the intended impact of these policies. Public reporting is one of the most universal, effective means to demonstrate improvement or change. This public reporting has value because it can provide a benchmark for patients or providers to understand, at a high level, the volume of services a payer approves or denies, the types of services it authorizes, or changes in those decisions over time. Not all patients will use or necessarily understand all of the data, but it may help support the beginning of a conversation between either the patient and the payer, or the patient and the provider. We anticipate payers will identify the most appropriate locations on their website for the information to be public. We additionally note that the Medicare FFS program currently publicly reports prior authorization metrics on its website and invites payers to reference the presentation of those metrics as they develop their public reporting strategy.

Comment: A commenter recommended that a voluntary consensus SDO should develop standardized codes that could be used to document prior authorization denial reasons. Then, CMS could revise the metrics to include information on the reason for denial to provide a more complete picture of a plan's prior authorization process.

Response: As discussed previously in the section on providing a reason for denial, the standard codes for denial reasons are an external code set maintained by X12, which is a voluntary SDO. Any organization or individual interested in providing updates to this code set may do so by submitting a request to X12. At this time, we are not requiring payers to publicly report the reason for denial in these reporting metrics; that information is only provided to the requesting provider and the patient.

Comment: Another commenter recommended that state Medicaid agency reporting requirements be changed to begin 1 year following the implementation of the APIs (by March 31 of each year). Another commenter stated that the proposed metrics do not align with the data elements required to be reported for appeal for the Managed Care Annual Care Program Report (MCPAR) that states are required to report. The commenter stated that alignment is necessary to assess the impact of an MCO, PHIP, or PAHP's prior authorization determinations on beneficiary access to requested services.

Response: We disagree that any payer should begin their reporting period substantially after any other payer, as all payers already have data to support their prior authorization activities. Even if a state Medicaid agency were granted an exception or extension, their prior authorization processes are already in effect and they have data regarding their current prior authorization activities. The final action statement in this section of the final rule includes the compliance dates and reporting requirements for impacted payers, which remains March 31, 2026, for reporting data for the prior year. Concerning the MCPAR, alignment is neither necessary nor feasible. The MCPAR collects information specifically on appeals, and we are requiring information specifically on prior authorization. While it is true that a denied prior authorization could generate an appeal, that is not relevant to these two reporting vehicles. We may revise the data collected in the MCPAR in the future and will use the existing data from the MCPAR and this reporting to inform any such revisions.

Comment: Multiple commenters recommended that CMS develop standard guidance or IGs for payers to have a set format and consistent calculation of the metrics. A commenter flagged that the lack of guidance on report formatting could lead to a wide variation across impacted payers. Another commenter stated that CMS should issue the guidance and allow adequate time for impacted payers and vendors to make the appropriate modification to their system before public reporting begins. A commenter sought clarification as to whether the public reporting of prior authorization metrics would only apply to prior authorization requests that are received on or after the compliance dates. Another commenter recommended that rule language specify the data required, ensure the data are placed prominently on the payers' websites, and indicate the cadence at which payers must refresh the publicly reported data. Many other commenters suggested various dissemination mechanisms for the prior authorization metrics. A commenter stated that they support an active distribution method for the prior authorization metrics, like a newsletter. Another commenter recommended that prior authorization metrics be available to be downloaded in Excel and PDF.

Response: The Medicare FFS program currently publicly reports prior authorization metrics on its website and invites payers to reference the presentation of those metrics as they develop their public reporting strategy. We will consider what additional support we can provide to impacted payers before the compliance date of the final rule regarding recommended content and format for use in their public reports. The requirement for data in the first report for prior authorization metrics to include information about prior authorization activity for the prior year will provide a baseline for impacted payers as well as the public. The reporting requirement applies to prior authorization requests that were received the year before the compliance date.

Comment: Multiple commenters recommended that CMS report the required prior authorization information on the CMS website. A commenter stated that this will enable easy retrieval of data by physicians and patients, especially for plan comparison. Another commenter stated that CMS should also make sure it publishes this information on pages of its website that correlate to a particular payer. A commenter stated that CMS should report on the impact prior authorization has on the quality of care patients receive, potential delays in care, and associated cost savings due to the prior authorization process. The commenter suggested that reporting these data can help policymakers, researchers, providers, and patients make more informed decisions about the prior authorization process, ensuring that patient care remains central. Multiple commenters recommended that instead of payers publicly reporting metrics, there should be confidential reporting to CMS so it can track outliers and avoid misleading patients on data that are not comparable across plans. Another commenter recommended that CMS consider confidential payer reporting to CMS until the Prior Authorization API experiences significant uptake by providers.

Response: We considered requiring that payers submit their reports to a central website for publication. However, as we explained in the CMS Interoperability and Prior Authorization proposed rule (87 FR 76347), we did not select this alternative because we believe patients likely would view their health plan and payer as the resource for information about their plan. While CMS does provide comparative data for plans in certain programs (for example, the MA program) and may use such information in future public reports, we are not finalizing such an approach in this rule. Patients should be able to find information about their plan or payer from those websites to minimize burden and confusion. For Medicaid and CHIP, patients generally associate their coverage with their state or managed care plan, not CMS. While having the prior authorization data posted on each payer's website is the most appropriate place, we also encourage state Medicaid agencies to include the data on their websites (which are required by 42 CFR 438.10(c)(3)) to improve the value of information available to their patients. Similarly, MA patients look to their MA organization websites for information and resources about those plans and their performance. Payers must already include significant patient resource information on their websites, and CMS will conduct outreach to payers, patients, and providers to help provide guidance on best practices about the website locations for such public reporting of prior authorization information. In our oversight role, we may begin to look at data after the compliance date to evaluate compliance with these new reporting requirements. CMS may consider additional reporting requirements as well as publication of comparative information in the future.

Comment: Multiple commenters stated it would be helpful for additional context to explain metrics in the event of an outlier, such as explaining denial or approval rates for services-related data. Multiple commenters suggested including the total number of requests approved/denied, rather than only aggregate percentages. A commenter stated that they also would like to see specific data for common services to show a direct comparison across different payers and plans as certain prior authorization requests are more complex than others.

Multiple commenters stated that service-specific reporting will aid in identifying services for which there is a high rate of approval and for which prior authorization requirements may no longer be necessary, or for identifying critical services or items being routinely denied. A commenter recommended CMS require payers to provide more detailed information by item or service including Healthcare Common Procedure Coding System (HCPCS) code, Current Procedural Terminology (CPT) code, and International Classification of Diseases, Tenth Revision (ICD–10) code. Other suggestions included requiring payers to report disaggregated data by diagnosis, race and ethnicity, gender, and age. A commenter warned that without item- and service-level reporting, it will be impossible for CMS and the public to understand some data and to hold impacted payers accountable for excessive denials and delays in responding to prior authorization requests. Other commenters recommended CMS require payers to report data with setting-specific data or by type of provider (for example, physician, short-term care, long-term care, rehabilitation, psychiatric, and skilled nursing services). A commenter stated that only with this setting level of specificity will patients and providers be able to assess which services are routinely denied, appealed, and overturned in favor of patients and providers. Another commenter warned that segmentation by the provider should encompass short-term acute care, long-term care, rehabilitation, psychiatric, and skilled nursing services to allow consumers, providers, and regulators to gain a better understanding of prior authorization processes and where there is a need for improvement. A commenter recommended that CMS should require metrics be broken down at the Health Care Provider Taxonomy code set Level II, Classification, which is a code set used in HIPAA standard transactions. Another commenter recommended that the metrics be reported by the payer based on service type, site of care, and whether the service is inpatient or outpatient. Another commenter wanted CMS to compare the metrics for MA organization plans to Medicare FFS and commercial health plans.

Response: Service-specific and demographic reporting may be very useful to the impacted payers in evaluating their programs and expect that they use such data today and will continue to do so as they implement the policies of this final rule. While we agree that there could be many more reporting requirements, and at more granular levels, and data are an important tool for different evaluation purposes, reporting should serve its intended purposes and not become a burden to the users. Too much data can also become overwhelming. We anticipate patient and provider feedback following implementation and will review opportunities after that time.

We agree that it would be appropriate to compare the metrics for all payers several years after the policies of this final rule have been implemented to determine its impact on the prior authorization barriers and burdens. However, commercial plans other than QHPs on the FFEs are not subject to the provisions of this rule, and CMS does not have access to performance data for those organizations. If states are collecting such data, they might be able to analyze the data at the state level.

b. Publication of Prior Authorization Metrics

We requested comments on how the information might be displayed on payer websites in a useful and meaningful manner for patients and providers, including which data would be most useful. The summarized comments and our responses follow.

Comment: Multiple commenters recommended that the prior authorization metrics be presented in a readable and accessible format, particularly for individuals with disabilities, individuals with limited or low health and data literacy, and individuals with limited English proficiency. Other commenters recommended that CMS require plans to write publicly reported data at a sixth grade reading level, conduct consumer-focused testing on data readability, and provide translations in multiple languages. Multiple commenters recommended that CMS should require payers to provide access to prior authorization data in multiple languages (based on the most common languages in a community) and in a format that is comprehensible to the average consumer. A commenter recommended CMS should make the reported payer data patient-friendly and public to enable comparison of metrics.

Response: We appreciate commenter suggestions that payer data be “patient-friendly,” easy to understand, and in an accessible format. We may consider how best to provide guidance to encourage impacted payers to develop their reports with these factors in mind, as the intent of these public reports is to ensure that individuals can use and interpret the information.

c. Types of Prior Authorization Metrics

Impacted payers are required to post a general set of prior authorization metrics on their public websites to support process improvement, as well as patient and provider insight into trends for different payers. While the data will not be submitted to CMS at this time, it will be available for public review and evaluation and may be informative as experience with the new policies evolves.

Comment: Some commenters wrote that CMS should include more data on use of the Prior Authorization API. A commenter suggested certain metrics be considered for adoption: the number of requests initiated using the Prior Authorization API, average response time for requests not requiring a prior authorization, the number of requests initiated using the Prior Authorization API requiring a prior authorization, the number of requests initiated using the Prior Authorization API requiring a prior authorization that had all of the required documentation available automatically, the percentage of Prior Authorization API requests requiring a prior authorization with all required documentation available processed automatically, the number of requests initiated using the Prior Authorization API requiring a prior authorization that were unable to automatically supply required documentation, and a list of all SMART on FHIR app/EHR combinations or equivalent technology used for Prior Authorization API requests at provider organizations. A commenter encouraged CMS to consider breaking reporting out by prior authorization transactions supported by a FHIR API transaction and those otherwise conducted.

Response: The intended goal of publicly reporting these metrics is to help providers and patients gain insights into the payers' prior authorization practices and performance, and to assist payers in evaluating their prior authorization practices. While the performance and utilization of the Prior Authorization API is valuable information for assessing the adoption and use of the API itself, it may not adequately represent the full scope of a payer's prior authorization practices. As noted in a prior response, we may consider issuing guidance before the compliance date with more specifics on the recommended format and content; however, the lack of regulations or guidance on the format and content does not prevent payers from including additional information that could be of value to patients and providers.

8. “Gold-Carding” Programs for Prior Authorization

We solicited comments on the potential for gold-carding or prior authorization exemption programs and how they might reduce provider and payer burden and improve services to patients. We also solicited comments on the incorporation of such a measure into Star Ratings for these organizations. We received several comments on this topic and appreciate the input. Since no policies were proposed, we are not finalizing policies in this area at this time. We thank commenters for their feedback and will consider all comments for possible future rulemaking.

9. Final Action

After considering the comments received, and for the reasons discussed in the CMS Interoperability and Prior Authorization proposed rule and our response to those comments (as summarized previously), we are finalizing our proposals with the following modifications:

• Impacted payers must implement and maintain a Prior Authorization API beginning 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs) rather than in 2026.
• MA organizations must report prior authorization metrics at the contract level rather than at the proposed organization level.

See further discussion for exact details of the final requirements for impacted payers.

We are finalizing that, beginning 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs), impacted payers must implement and maintain a Prior Authorization API that is compliant with certain technical standards, documentation requirements, and denial or discontinuation policies. Specifically, those technical standards are HL7 FHIR at 45 CFR 170.215(a)(1), US Core IG at 45 CFR 170.215(b)(1)(i), and SMART App Launch IG at 45 CFR 170.215(c)(1).

We are finalizing that, by the compliance dates, impacted payers must implement a Prior Authorization API that:

• Is populated with the payer's list of covered items and services (excluding drugs) that require prior authorization;
• Can identify all documentation required for approval of any items or services that require prior authorization;
• Supports a HIPAA-compliant prior authorization request and response; and
• Communicates whether the payer approves the prior authorization request (and the date or circumstance under which the authorization ends), denies the prior authorization request (with a specific reason), or requests more information.

We are finalizing that, beginning 2026 (by January 1, 2026, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2026, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2026, for QHP issuers on the FFEs), impacted payers' must provide a specific reason for a denial within their decision timeframe regardless of the method that was used to send the prior authorization request or decision.

We are finalizing that, beginning in 2026, MA organizations, including applicable integrated plans, state Medicaid and CHIP FFS programs, and Medicaid managed care plans and CHIP managed care entities must provide notice to providers and patients of prior authorization decisions as expeditiously as a patient's health condition requires, but no later than 7 calendar days for standard requests, unless a shorter minimum timeframe is established under applicable state law.

We are finalizing that, beginning in 2026, MA organizations, including applicable integrated plans, and state Medicaid and CHIP FFS programs, must provide notice to providers and patients of prior authorization decisions as expeditiously as a patient's health condition requires, but no later than 72 hours for expedited requests, unless a shorter minimum timeframe is established under applicable state law. That requirement already exists for Medicaid managed care plans and CHIP managed care entities, but for consistency with Medicaid FFS, we are finalizing that those payers must also send notices to patients and comply with a shorter timeframe, if established by state.

In response to public comments, CMS will work with state Medicaid and CHIP FFS programs that may be unable to meet the new prior authorization decision timeframes compliance date in 2026. States should contact their Medicaid state lead or CHIP project officer before April 1, 2025, to discuss their extenuating circumstances. Any flexibility granted to a state Medicaid or CHIP FFS program for the implementation of the new prior authorization decision timeframes requirements will be temporary and limited to the unique circumstances of the program.

We are finalizing that, as of the effective date of this final rule, existing Medicaid beneficiary notice and fair hearing regulations apply to Medicaid FFS prior authorization decisions.

We are finalizing that, beginning in 2026, impacted payers must annually report certain aggregated prior authorization metrics. Specifically, by March 31, MA organizations at the contract level, state Medicaid and CHIP FFS programs at the state level, Medicaid managed care plans and CHIP managed care entities at the plan level, and QHP issuers on the FFEs at the issuer level must post the required metrics on their websites. Impacted payers must publicly report the previous calendar year's metrics by March 31 following any year that they offered that type of plan.

These policies apply to MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs at the CFR sections listed in Table E4.

10. Statutory Authorities To Require Improvements in Prior Authorization Processes, Decision and Notification Timeframe Policies

We did not receive any public comments on the statutory authorities for the Prior Authorization API and prior authorization process policies discussed in this section.

a. Medicare Advantage

Section 1856(b) of the Act directs the Secretary to establish regulatory standards for MA organizations that are consistent with, and carry out, Part C of the Medicare statute, including the provisions in section 1852 of the Act. Section 1852(a) and (d) of the Act provide for MA plans to cover medically necessary Part A and Part B benefits, including by making benefits available and accessible with reasonable promptness. Section 1852(c)(1)(G) of the Act requires that MA organizations disclose to their enrollees any rules regarding prior authorization or other review requirements that could result in nonpayment. Section 1852(g)(1)(A) of the Act requires an MA plan to have a procedure for making determinations about whether an enrollee is entitled to receive a health service, how much the enrollee is required to pay for such service, and to provide an enrollee with a written notice if the plan denies coverage. Section 1852(g)(1)(A) of the Act also requires that coverage determinations be made on a timely basis. Section 1852(g)(3)(B)(iii) of the Act requires that the organization notify the enrollee (and physician involved, as appropriate) of an expedited determination (and reconsideration) under time limitations established by the Secretary, but not later than 72 hours after the time of receipt of the request. The prior authorization requirements in this final rule ensure that MA organizations carry out their responsibilities under section 1852 of the Act in a consistent and standardized fashion and in compliance with standards that carry out and serve the purposes of the MA program.

Under the authorities referenced previously, we are finalizing certain requirements for MA organizations. These requirements are to ensure that MA organizations provide enrollees with appropriate access to care and information by using certain standards, technologies, and business processes. The requirements include implementing certain APIs that provide information about the coverage and documentation requirements for prior authorization, responding to prior authorization requests with the status of that request, and meeting certain timeframes for making decisions on prior authorization requests.

We are requiring that MA organizations implement the Prior Authorization API using certain implementation specifications as discussed in section II.G. of this final rule. These implementation specifications are expected to improve the overall prior authorization process by addressing deficiencies that exist in the process today concerning providers' access to information about the prior authorization rules and documentation requirements. The Prior Authorization API will communicate the coverage and documentation requirements for prior authorization, indicating if authorization is required for a specific item or service and what documentation is required to support an authorization request. Use of the Prior Authorization API is consistent with the disclosure obligation on MA organizations in section 1852(c)(1)(G) of the Act by disclosing to providers the same information that generally must be provided to enrollees about which covered benefits are subject to prior authorization and serves the same larger purpose of ensuring access to coverage by communicating the limits and rules for covered services.

Additionally, the Prior Authorization API is a mechanism for receiving and responding to requests for coverage determinations before the services are rendered or items furnished; therefore, the requirement to adopt and use the Prior Authorization API is an additional standard for implementing and complying with section 1852(g) of the Act regarding an MA organization's obligation to make coverage determinations. The Prior Authorization API will enable the provider to submit a HIPAA-compliant prior authorization request through their existing workflow and receive a timely response to that request. In concert with these APIs, we are requiring the payer to provide the status of the request, such as whether it was approved or denied, along with a specific denial reason, so that the provider knows what steps to take next—whether to request a different service for the patient, to submit additional information, or to appeal the decision. These final requirements will improve patient care and reduce redundancies in administrative processes between providers and payers because they give providers clearer instructions, both for submitting the original request and, if necessary, providing additional information. The required API has the potential to improve the efficiency of the prior authorization process because it enables providers to submit accurate information with the request, which could reduce the number of appeals or denials, and possibly eliminate requests for additional documentation.

We expect the prior authorization policies in this final rule to improve timely access to care for beneficiaries by mitigating delays that sometimes occur when a provider is trying to determine coverage requirements or does not know what documents to submit to obtain approval for a service. Improvements in the timeliness of payer operations and provider services will contribute to program efficiency, and effective operations and will be in the best interest of the enrollees. The requirement for MA organizations to make certain changes to the timeframes in which they provide notice for prior authorization has the potential to improve patient access to care in program operations as discussed in section II.D.5. of this final rule. This could prevent some patients from abandoning care while waiting for authorization, and it could improve efficiencies by avoiding repeat phone calls from providers who must check on the status of authorization over several days, or sometimes weeks. We finalized requirements to improve some timeframes for expedited and standard decisions under the premise that these changes are overdue, feasible, and would benefit patients and providers. Furthermore, by establishing more certainty in the process for providers, there may be a reduction in unnecessary repeat requests for services. More responsive timeframes will also enhance enrollee access to timely and appropriate care. A shorter timeframe for both standard and expedited decisions may reduce administrative time and expense for providers and payers, as they would spend fewer resources on follow-up inquiries. As such, these requirements are consistent with our authorities to adopt standards to carry out and implement the requirements in section 1852 of the Act for MA organizations to have a procedure for making timely determinations and to make benefits available and accessible with reasonable promptness.

Finally, section 1857(e)(1) of the Act explicitly authorizes the adoption of additional reporting requirements by MA organizations where necessary and appropriate. The requirement for MA plans to publicly report prior authorization metrics will enable CMS to assess the implementation of the policies and attempt to determine the impact of these new requirements on payers and providers. A review of these metrics may help CMS and the plans understand the impact of the requirements, including the impact of using the APIs and improved decision timeframes. The data may also help plans evaluate operations, implement new policies and the API, and determine what changes may be appropriate.

b. Medicaid

For Medicaid, most of the requirements finalized in this section are authorized by sections 1902(a)(4), (8), and (19) of the Act. Section 1902(a)(4) of the Act requires that a state Medicaid plan provide such methods of administration as are found by the Secretary to be necessary for the proper and efficient operation of the state Medicaid plan, section 1902(a)(8) of the Act requires states to ensure that Medicaid services are furnished with reasonable promptness to all eligible individuals, and section 1902(a)(19) of the Act requires states to ensure that care and services under a Medicaid state plan are provided in a manner consistent with the simplicity of administration and the best interests of the recipients. Some requirements finalized in this section are also authorized by additional sections of the Act as discussed in this section of the final rule.

Additionally, section 1902(a)(7) of the Act requires that states must provide safeguards that restrict the use or disclosure of information concerning Medicaid applicants and beneficiaries to purposes that are directly connected with the administration of the program or plan. The implementing regulations at 42 CFR part 431, subpart F, for this section 1902(a)(7) of the Act list purposes that CMS has determined are directly connected with the administration of Medicaid state plans (42 CFR 431.302) and require states to provide safeguards meeting certain requirements to restrict uses and disclosures of Medicaid beneficiary data. CHIP programs are subject to the same requirements through a cross reference at 42 CFR 457.1110(b).

Our finalized policy that the data described in this section be shared via the Prior Authorization API is consistent with the requirement at section 1902(a)(7) of the Act, providing that states may share these data only for purposes directly connected with the administration of the Medicaid state plan. This data sharing policy for the Prior Authorization API is related to providing services for beneficiaries, a purpose listed at 42 CFR 431.302(c). The services include those for which the state requires that a provider submit a prior authorization request, and thus needs to communicate about that prior authorization with other providers enrolled with or authorized by the state to provide care to its beneficiaries. Prior authorization can be an integral part of the Medicaid program and facilitates access to care as well as provider payment processes.

We remind states that to meet the requirements of the regulations at 42 CFR part 431, subpart F, states must have consistent criteria for the release and use of information (which should comply with the proposed Prior Authorization API requirements), in accordance with 42 CFR 431.306(a). Access to information concerning beneficiaries must be restricted to persons who are subject to standards of confidentiality that are comparable to that of the state Medicaid agency, in accordance with 42 CFR 431.306(b). Similar to the Provider Access API discussed previously, the permission requirement at 42 CFR 431.306(d), which requires that the state agency obtain permission from a family or individual, whenever possible, before responding to a request for information from an outside source, is not relevant to the Prior Authorization API, because any request for beneficiary information would be from an enrolled Medicaid or CHIP provider and thus would not be from an outside source. While the beneficiary's permission is not required under 42 CFR 431.306(d) for the Prior Authorization API, state or other laws may require such permission. When requesting approval to provide certain services from the state using the state's Prior Authorization API as described in section II.D.2.a. of this final rule, the provider will be able to determine if prior authorization is required and what supporting documentation is necessary to obtain approval for that care.

i. Prior Authorization API

The requirement for state Medicaid FFS programs and Medicaid managed care plans to implement the Prior Authorization API is expected to improve the efficiency and timeliness of the prior authorization process for Medicaid beneficiaries, providers, state Medicaid agencies, and Medicaid managed care plans by addressing inefficiencies that might exist in the process today. As discussed in section II.D.2.a. of this final rule, the Prior Authorization API will allow a provider to determine whether a prior authorization is required and the documentation requirements for that prior authorization request. The Prior Authorization API will:

• Enable providers to submit a complete prior authorization request faster and easier;
• Support more timely notice to the provider and beneficiary of the disposition of the prior authorization request; and
• Permit improved scheduling of services or filing appeals, depending on the decision. The Prior Authorization API has the potential to improve the prior authorization process by making it more efficient, including by reducing the number of denials and appeals, or even by eliminating requests for additional documentation, as noted elsewhere in this final rule.

ii. Requirement for Payers To Provide Specific Reason for Denial of Prior Authorizations

Based on the provisions of this final rule, states and Medicaid managed care plans must provide specific information to providers about the status of prior authorization requests to enable providers to plan care for their patients after submitting a prior authorization request. As discussed in section II.D.3. of this final rule, when providers receive a response to a prior authorization request, the payer will typically indicate whether the request is approved, or denied, or if additional information is needed. If prior authorization has been denied, the payer must give the provider the specific reason for the denial; that information may be used by the provider to decide next steps, such as re-submitting the request with updated information, identifying alternative treatments for the patient, or appealing the decision. These requirements will improve the timeliness, clarity, and consistency of information for providers regarding prior authorization requests; help providers determine the next steps for timely patient care; and reduce payer, provider, and patient burden by eliminating the need for repeated inquiries.

iii. Requirements for Prior Authorization Decision Timeframes, Notifications Related to Prior Authorization Decision Timeframes, and Amendments to Existing Medicaid Fair Hearings and Appeals Regulations

As discussed in section II.D.5. of this final rule, delayed prior authorization decisions may directly affect patient care by delaying access to treatment, services, and supplies, as well as transfers between hospitals and post-acute care facilities. The required timeframes for making prior authorization decisions about items and services that require prior authorization in Medicaid FFS and managed care programs will help providers better manage administrative resources, make more time available for providers to render patient care, and facilitate faster access to services. These requirements should make substantive improvements to the care experience for Medicaid beneficiaries and lead to better health outcomes. In turn, better health outcomes will contribute to more efficient use of Medicaid program resources.

The requirement to shorten the maximum amount of time for a Medicaid managed care plan to make a prior authorization decision from 14 calendar days to 7 calendar days will improve the efficient operation of the Medicaid program by facilitating faster receipt of services or filing of appeals.

Our amendment to explicitly state in the regulation text that current notice and fair hearing requirements apply to Medicaid FFS prior authorization decisions is authorized under section 1902(a)(3) of the Act. Section 1902(a)(3) of the Act requires that a Medicaid state plan provide an opportunity for a fair hearing to any individual whose claim for medical assistance under the plan is denied or is not acted upon with reasonable promptness. This is also supported by the 14th Amendment to the United States Constitution and case law on due process, specifically, Goldberg v. Kelly, 397 U.S. 254 (1970). States must establish timely notice and fair hearing processes meeting due process standards under Goldberg v. Kelly, as incorporated into existing Medicaid fair hearing regulations at 42 CFR part 431, subpart E, see 42 CFR 431.205(d).

Additionally, section 1902(a)(17) of the Act requires state Medicaid plans to include reasonable standards for determining the extent of medical assistance under the plan that are consistent with the objectives of Title XIX of the Act. As set forth at 42 CFR 440.230, the standards that states establish under section 1902(a)(17) of the Act could include appropriate limits on a service based on such criteria as medical necessity or on utilization control procedures, as long as each service is sufficient in amount, duration, and scope to reasonably achieve its purpose. Items and services covered under Title XIX benefit authorities are subject to 42 CFR 440.230, unless statute or regulation expressly provides for an exception or waiver. This would include covered items and services described in sections 1905(a), 1915(c), 1915(i), 1915(j), 1915(k), 1915(l), 1937, and 1945 of the Act, and any other authorities as established by Congress. The standards that states establish under section 1902(a)(17) of the Act and 42 CFR 440.230 could include prior authorization requirements. The requirements to establish timeframes for prior authorization decisions are authorized under section 1902(a)(17) of the Act because they would be expected to help ensure that states make prior authorization decisions in a manner that is consistent with the requirements in section 1902(a)(4), (a)(8), and (a)(19) of the Act, thus helping to ensure that states' standards for determining the extent of medical assistance under the plan are consistent with the objectives of Title XIX.

Section 1932(b)(4) of the Act provides that each Medicaid MCO must establish an internal grievance procedure whereby a beneficiary who is eligible for medical assistance may challenge the denial of coverage or payment for such assistance. CMS has implemented requirements for those procedures at 42 CFR 438.210, which applies the same appeal and grievance requirements for PIHPs and PAHPs as for Medicaid MCOs. We rely on our authority in section 1902(a)(4) of the Act to adopt standards for PIHPs and PAHPs that mirror requirements for MCOs. This is consistent with our prior practice for adopting standards for Medicaid managed care plans (81 FR 27507). We rely on the same authority here to revise the procedures under which Medicaid managed care plans may make prior authorization decisions about coverage and provide those decisions to providers and enrollees. Reducing plan response time for prior authorization decisions may enable beneficiaries to file appeals if necessary and receive a resolution to those appeals sooner. The earlier an appeal is filed, and the disposition known, the sooner the provider and beneficiary can determine whether to request a state fair hearing or to identify treatment alternatives, if necessary. The prior authorization requirements in this rule are also consistent with how section 1932(c)(2)(A)(i) of the Act requires MCO contracts to contain a provision for an annual external quality review of quality outcomes and access to and timeliness of covered services. If the shorter prior authorization response requirements successfully improve workflow and processes that facilitate timely access to services, improvements to the care experience for patients, and better health outcomes, the results should be visible in external reviews. This requirement reflects the importance and potential advantages of timely access for beneficiaries to covered services through more efficient processing of prior authorization requests as proposed in this rule.

iv. Public Reporting of Prior Authorization Metrics

We are also requiring Medicaid FFS programs and Medicaid managed care plans to publicly report certain prior authorization metrics by posting them on the payer's website. As discussed in section II.D.7. of this final rule, publicly reporting these metrics may support more timely access to services by identifying prior authorization process weaknesses or deficiencies and enabling the implementation of corrective action, and for managed care programs, helping beneficiaries select Medicaid managed care plans that best meet their needs and helping some Medicaid providers make informed decisions on which Medicaid managed care plan networks to join.

Section 1902(a)(4) of the Act authorizes this requirement because enabling more timely access to services by identifying prior authorization deficiencies and facilitating the implementation of corrective action to improve the prior authorization process will support the proper and efficient operation of the state Medicaid plan. Requiring Medicaid managed care plans to publicly report their prior authorization metrics will hold them accountable and enable them to monitor their performance and identify process improvement opportunities, which may be an integral part of implementing a quality assessment and improvement strategy more easily. This is consistent with the requirements for quality strategies for managed care programs at section 1932(c)(1)(A)(i) of the Act.

Section 1902(a)(8) of the Act authorizes this requirement because identifying prior authorization process weaknesses or deficiencies and enabling the implementation of corrective action as well as helping beneficiaries select a Medicaid managed care plan that best meets their needs may improve the promptness with which services are provided to beneficiaries. Section 1902(a)(19) of the Act authorizes this requirement because identifying prior authorization process weaknesses or deficiencies and enabling the implementation of corrective action will help ensure that care and services are provided in a manner consistent with the simplicity of administration. Additionally, implementation of corrective action to improve prior authorization processes, helping beneficiaries select a managed care plan that best meets their needs, and helping providers make informed decisions on which Medicaid managed care plan networks to join is in the best interest of beneficiaries.

c. CHIP

For CHIP, we finalized these requirements under the authority of section 2101(a) of the Act, which sets forth that the purpose of Title XXI is to provide funds to states to provide child health assistance to uninsured, low-income children effectively and efficiently that is coordinated with other sources of health benefits coverage. This provision authorizes us to adopt these requirements for CHIP to obtain access to program data for analysis. Such analysis supports improvements in the efficacy of CHIP programs and more efficient administration of services.

As discussed previously, we are requiring the implementation of the Prior Authorization API in section II.D.2.a. of this final rule to improve the prior authorization process for patients, providers, and payers by addressing deficiencies and inefficiencies that exist currently. Today, a payer's rules about when prior authorization is required and what documentation requirements must be fulfilled to submit the request are not necessarily easily accessible for providers. The Prior Authorization API will enable a provider to determine if a prior authorization is required electronically, in real-time and what the documentation requirements are regarding such requests. While we expect providers to be the primary beneficiaries of this API, making this information available in a standardized way and permitting access through an API will also serve the requirements in section 2101(a) of the Act that CHIP ensures access to coverage and coordinated care.

The Prior Authorization API is a mechanism for receiving and responding to requests for coverage determinations before the services are furnished; this API will streamline the initial authorization process for the payer by sharing this information in an easily accessible way. The API will also allow the provider to know what to do if prior authorization is required for a certain service, which will improve the provider's ability to treat the patient timely. The Prior Authorization API enables the payer to send a real-time response back to a provider, based on the request for authorization. This, too, will improve the efficiency of providing services to the patient because the request and response are automated and in real-time. We expect payers' use of this API to ensure that a provider can submit a request for prior authorization with the correct and complete documentation to avoid an incorrect submission which might result in an unnecessary denial. The Prior Authorization API will: (1) enable providers to submit a prior authorization request faster and easier; (2) support more timely notice to the provider and beneficiary of the disposition of the prior authorization request; and (3) permit faster scheduling of services or filing appeals, depending on the decision. The Prior Authorization API has the potential to improve the prior authorization process by making it more efficient, including limiting the number of denials and appeals, or even eliminating requests for additional documentation, as noted elsewhere.

The safeguards for beneficiary information at 42 CFR part 431, subpart F, are also applicable to CHIP through a cross reference at 42 CFR 457.1110(b). As discussed previously for Medicaid, CHIP payers' and providers' data exchange through the Prior Authorization API is related to providing services to beneficiaries, which is described at 42 CFR 431.302(c) as a purpose directly related to state plan administration. We remind states that when they share medical records or any other health or enrollment information about individual beneficiaries, they must comply with the privacy protections at 42 CFR 457.1110 and the release of information provisions at 42 CFR 431.306.

The requirement in section II.D.5. of this final rule that CHIP FFS and CHIP managed care entities meet certain timeframes to provide decisions for prior authorizations for expedited and standard decisions is an improvement from the current state, where there is uncertainty about expectations for when a prior authorization might be approved. This requirement is intended to establish more certainty in the prior authorization process for providers and improve access to appropriate care for all patients, particularly those with chronic conditions or complicated health risks. Health parity may be increased as barriers due to process and timeframes will be removed. Similarly, improved process improvements may reduce administrative costs for providers and payers as redundancies will be removed from the system. We expect the requirement to improve timeliness in responding to providers and patients to support process improvements for the state and managed care programs and is consistent with our authorities under section 2101(a) of the Act in that it improves the efficiency of the CHIP programs.

The policy to require CHIP FFS and CHIP managed care entities to publicly report prior authorization metrics will also support the states' oversight, evaluation, and administration responsibilities. CMS may occasionally view some of the CHIP's FFS and managed care websites to check for compliance, see how data are being reported, and determine if any trends in prior authorization changes could be indicative of the benefits of the prior authorization policies as discussed in section II.D.7. of this final rule. The data may indicate the use of the APIs, improvements in prior authorization numbers, or changes in total numbers, denials, and appeals.

d. Qualified Health Plan Issuers on the Federally-Facilitated Exchanges

For QHP issuers on the FFEs, we finalized the requirements in this section under the authority of section 1311(e)(1)(B) of the Affordable Care Act, which affords the Exchanges the discretion to certify QHPs if the Exchange determines that making available such health plans through the Exchange is in the interests of qualified individuals in the state in which the Exchange operates.

The policies finalized here may improve the efficiency of the issuers that are certified to offer QHPs on the FFEs and improve the quality of services they provide to providers and their patients by increasing the efficiency in the prior authorization submission and review process. In section II.D.2.a. of this final rule, we are requiring that QHP issuers on the FFEs implement an API to support the prior authorization process. The Prior Authorization API will allow QHP issuers on the FFEs to communicate requirements for prior authorization more efficiently and enable providers to similarly operate more efficiently to determine when a prior authorization is needed and locate the documentation requirements. The Prior Authorization API may enable more accurate submission and subsequent processing of prior authorization requests, with the potential of improving the delivery of services to patients. Qualified individuals enrolled in QHPs on the FFEs may receive covered services more quickly using the API. Similar to the other APIs, we believe that certifying only health plans that implement the Prior Authorization API and adhere to the other requirements described in this section of the preamble is in the interests of qualified individuals in the state or states in which a QHP issuer on the FFEs operates because of the opportunities for improvements in patient care, in alignment with the goals of the Affordable Care Act. We encourage SBEs to consider whether a similar requirement should apply to QHP issuers participating in their Exchanges.

We are also requiring that QHP issuers on the FFEs provide a specific reason for denial when sending a response to a prior authorization request, to facilitate better communication and understanding between the provider and issuer. This may enable efficient and successful resubmission of the previously denied prior authorization request, which may more promptly facilitate the needed patient care.

Finally, the requirement for QHP issuers on the FFEs to publicly report prior authorization metrics in section II.D.7. of this final rule will hold issuers accountable to their providers and patients, which could help these organizations improve their program administration. These data may help QHP issuers on the FFEs evaluate their processes and determine if there are better ways to leverage the APIs, including the quality and sufficiency of the coverage and documentation information included in the APIs.

E. Extensions, Exemptions, and Exceptions and Federal Matching Funds for Medicaid and CHIP

1. Background

The CMS Interoperability and Prior Authorization proposed rule discussed extensions, exemptions, and exceptions for state Medicaid and CHIP FFS Programs and QHP issuers on the FFEs, Federal funding available to states, and applicability to state Medicaid expansion programs for CHIP populations. As stated in the Provider Access, Payer-to-Payer, and Prior Authorization API sections of this final rule we are consolidated in one section the requirements for applying for an extension, exemption, or exception. Here we discuss those proposals, provide responses to the comments received regarding the proposals, and include the final policies.

2. Extensions, Exemptions, and Exceptions

a. Extensions and Exemptions for State Medicaid and CHIP Fee-for Service

In the proposed rule we explained that state Medicaid and CHIP FFS agencies face certain unique financing and operational circumstances that would not apply to other impacted payers. For example, some states would need legislative approval to initiate a public procurement process to secure contractors, particularly those with the necessary skills to support a state's implementation of the policies that require API development or enhancement. The timeline for an openly competed procurement process, together with the time needed to onboard contractors to develop the APIs can be lengthy for states (87 FR 76302). We described the issues impacting the state Medicaid and CHIP FFS programs in the proposed rule for the Provider Access (87 FR 76261), Payer-to-Payer (87 FR 76279), and Prior Authorization (87 FR 76302) APIs. However, we also stated that if our proposals regarding these APIs were finalized, we would strongly encourage state Medicaid and CHIP FFS programs to implement them as soon as possible, because of the anticipated benefits for the impacted payers, patients, and providers. Therefore, to address implementation concerns for state Medicaid and CHIP FFS programs, we proposed a process through which states could seek an extension to, and, in specific circumstances, an exemption from, the requirements to implement and maintain Provider Access, Payer-to-Payer, and Prior Authorization APIs.

We also proposed that states could request a one-time, 1-year extension through their annual Advance Planning Document (APD) for Medicaid Management Information System (MMIS) operations expenditures. We also proposed to permit state Medicaid FFS programs to request an exemption from any or all of these three API requirements when at least 90 percent of the state's Medicaid beneficiaries are enrolled in Medicaid MCOs as defined at 42 CFR 438.2. Similarly, we proposed that separate state CHIP FFS programs could request an exemption from the API requirements if at least 90 percent of the state's separate CHIP beneficiaries are enrolled in CHIP MCOs as defined at 42 CFR 457.10. We proposed that states could apply for an exemption by submitting a written request for the exemption as part of the annual APD for MMIS operations expenditures. CMS approves project plans and enhanced FFP for Medicaid Enterprise Systems (MES) using the APD process. CHIP waiver requests and expenditures for systems are managed at CMS in the operations division responsible for management of APDs. Guidance on the application process is available through each state's Regional Office contact.

As discussed in section II.C.4.b. of this final rule, we proposed and are finalizing, that for the payer to payer data exchange, state Medicaid and CHIP programs, rather than their managed care plans or managed care entities, will be responsible for obtaining beneficiaries' permission, providing educational resources at the time of requesting permission, and identifying patients' previous/concurrent payers, including for beneficiaries covered under managed care (87 FR 76280). Therefore, we also proposed that an exemption would not apply to those requirements, but only the API requirements, because it would prevent Medicaid managed care plans and CHIP managed care entities from meeting their obligations.

For Medicaid managed care plans and CHIP managed care entities, we did not propose an extension process because we believe that these managed care plans are actively working to develop the necessary IT infrastructure to be able to comply with the requirements at 42 CFR 438.272(d)(5) and 42 CFR part 457. Many of these plans might benefit from efficiencies based on all of the plan types that they offer. For example, many of these managed care plans with Medicaid and CHIP beneficiaries are part of a larger organization serving MA and Marketplace populations. These larger organizations often provide the technical and operational capacity that would enable implementation of the APIs across all lines of business. We believe this would be a practical and efficient use of resources to service all enrollees. Additionally, because the majority of Medicaid beneficiaries receive all or some of their benefits in a managed care delivery system, these plans should be held to the implementation times finalized in this rule to support the intended policy goals. Please see 87 FR 76263 for the supporting narrative in the proposed rule.

Comment: Multiple commenters expressed support for the proposed Medicaid and CHIP FFS extension policy and urged CMS to finalize this flexibility regarding compliance with the Provider Access, Payer-to-Payer, and Prior Authorization APIs. Multiple commenters highlighted extenuating circumstances that state Medicaid and CHIP agencies may face, especially related to the conclusion of the COVID–19 public health emergency (PHE), and the resulting impact on IT and personnel resources.

Multiple commenters submitted comments about which APIs should be included in the extensions, exemptions, and exceptions proposals and some recommended that CMS extend these flexibilities to all APIs included in the rule. A commenter recommended that CMS provide clarity regarding the exemption and extension provisions for the Patient Access API requirements.

Response: We acknowledge that states will be conducting long-term efforts to return to normal Medicaid and CHIP operations after the end of the COVID–19 PHE and the continuous enrollment condition under section 6008(b)(3) of the FFCRA. These efforts will continue through 2024, and many of these states have ongoing system development initiatives that require integration with MES and modules. Some states must work within their state legislative budget request cycle, as well as the Federal request cycle for requesting and obtaining funds for updates to their systems or new contracts.

We reiterate that this final rule requires impacted payers to implement and maintain Provider Access, Payer-to-Payer, and Prior Authorization APIs. Impacted payers should have already implemented or begun implementation of the Patient Access and Provider Directory APIs as required in the CMS Interoperability and Patient Access final rule, except for those organizations that have approved exceptions, as applicable. We did not propose a new Patient Access API, but rather additional data requirements for that API, and reporting requirements for use metrics. We did not propose any new extensions, exemptions, or exceptions for the Patient Access API in the proposed rule and are not adding policies of that nature in the final rule.

Comment: Multiple commenters expressed concern regarding the proposed state Medicaid and CHIP FFS extension policies, specifically citing the importance of the impact of these policies on Medicaid enrollees, and on the need for provider adoption to truly achieve the burden reduction goals of the proposed rule for patients, payers, hospitals, and providers. A commenter recommended that CMS not allow certain payers to have extensions because this could affect provider adoption of the necessary technology. Another commenter expressed appreciation of CMS for the proposal to allow extensions but stated that they believe provider adoption is going to be the most important factor in achieving burden reduction. The commenter emphasized the importance of having a certain percentage of their prior authorizations be electronic so that there is a return on investment from the changes necessary (for example, workflow changes, training, IT changes). The commenter stated that if payers are not held to the requirements in the rule, it could be perceived as a disincentive to providers to invest in the necessary technology.

Response: We thank commenters for confirmation that payers must be held accountable for implementation of the APIs, and that provider adoption of certain APIs is going to be an important factor in achieving burden reduction—particularly the Prior Authorization API. Participation by both payers and providers in some of the API provisions of this final rule will be important to ensure widespread adoption of the APIs. Because we also believe that provider participation is important for the Prior Authorization API, we are finalizing a modification to our proposal to adopt new Electronic Prior Authorization measures to incentivize providers (specifically, MIPS eligible clinicians, eligible hospitals, and CAHs) to use the Prior Authorization API under MIPS and the Medicare Promoting Interoperability Program as discussed in section II.F. of this rule. We also reiterate that while these extensions and exemptions apply to the new API provisions of this final rule, other policies must still meet the compliance dates established in this final rule. These include the prior authorization information to be included in the Patient Access API; information required under the finalized prior authorization process, such as providing a specific reason for denial, and revised timeframes for issuing prior authorization decisions. We encourage states to communicate their implementation plans about the policies in this final rule (including those to which an extension or exemption may apply) to network and enrolled providers. Such communication may help providers prepare for changes in procedures or notify their vendors to make appropriate system changes on a similar schedule.

Comment: A commenter said that the exemption for the APIs was a concern because it creates an unfair, two-tiered system that may leave people with disabilities behind; these people already face high barriers to care due to administrative burdens and uncertainties caused by prior authorization. The commenter wrote that the proposed exemption process will leave some FFS Medicaid populations—groups that include a disproportionate share of people with disabilities—without comparable access to any benefits derived from streamlining the prior authorization process with the Patient Access, Provider Access, and Payer-to-Payer APIs. The commenter noted the potential challenges of developing and maintaining the necessary data infrastructure for a relatively small FFS population, but wrote that in many states, people receiving Home and Community-Based Services (HCBS) through waivers that are carved out of managed care, may be individuals who would fall under the proposed API exemption and would fail to benefit from the streamlined prior authorization process in this regulation. Another commenter requested clarification on whether and how CMS considered health equity when proposing exemptions for some state Medicaid and CHIP programs. Other commenters expressed disagreement with the proposed exemptions and stated that these exemption proposals should be withdrawn, to make the APIs available to every Medicaid beneficiary. A commenter noted that states with managed care populations close to the proposed threshold for exemption may be incentivized to pressure beneficiaries into managed care to qualify for the exemption.

Response: We agree that it is important to consider access and equity issues, and the risk of a two-tiered system that may impose barriers to care. CMS will only grant a state an exemption from the Provider Access, Payer-to-Payer, and Prior Authorization APIs if the state establishes an alternative plan to enable the electronic exchange and accessibility of the required information that would otherwise be shared through the API. For example, CMS will only grant a state an exemption from the Provider Access API requirement if the state has established an alternative plan to ensure that enrolled providers have efficient electronic access to the same required data content about their patients through other means while the approved exemption is in effect. Similarly, states would be expected to use efficient means for electronic prior authorization that would reduce burden for providers and improve access to information about the requirements for when prior authorization is required for items and services or what documentation is required in advance. In light of requirements for the accessibility of this information, states implementing an alternative plan will be required to provide this information to all patients and providers in plain language and to offer auxiliary aids and services to ensure effective communications with individuals with disabilities.

Comment: Multiple commenters recommended that CMS include managed care plans in the proposed flexibilities (for extensions and exemptions) and some commenters said that each state should be able to decide whether to allow an extension to managed care plans. A commenter noted that managed care plans have greater resources than state Medicaid and CHIP FFS programs and would be able to meet the rule requirements on time. On the other hand, a commenter recommended that state Medicaid agencies offer managed care plans a 1-year extension.

Response: We acknowledge commenters who recommended that CMS provide the opportunity for an extension or exemption to Medicaid managed care plans and CHIP managed care entities to align with our approach throughout the rule to apply most policies to both state Medicaid and CHIP FFS programs and Medicaid managed care plans and CHIP managed care entities. However, we reiterate that the purpose of the extension policy for state Medicaid and CHIP FFS programs is to provide states that are making a good faith effort with additional time to work through lengthy and complex state procurement processes, to secure the necessary funding, personnel, and technical resources to successfully implement the requirements. The purpose of the exemption policy for state Medicaid and CHIP FFS programs is to accommodate the different enrollment models that are now in effect for each state and provide consideration for states with relatively small FFS populations. In response to these and many other comments requesting additional time for payers to implement the Provider Access, Payer-to-Payer, and Prior Authorization APIs, we are extending the compliance dates for the policies in this final rule that require API development or enhancement to 2027. This allows all impacted payers an additional year to meet these requirements, compared to our initial proposal to implement the requirements in 2026. We are finalizing the state Medicaid and CHIP FFS extension and exemption policies as proposed without extending this option to other payers in the Medicaid program, such as Medicaid managed care plans. We do not agree with commenters who suggested that each state be able to decide separately to allow an extension to managed care plans because the purpose of this final rule is to encourage adoption of these policies as soon as is practicable. As we have noted, Medicaid managed care plans are often owned and operated by larger private organizations, also subject to this final rule, and likely have the resources and capabilities to implement these policies and can efficiently leverage the work they do to build APIs across their Medicaid, MA, and Marketplace lines of business. We do not want to encourage a system where fewer Medicaid beneficiaries have access to the benefits of the policies in this final rule versus those with other types of coverage.

Comment: Multiple commenters provided recommendations regarding additional payers and plan types that should be eligible to benefit from the extensions, exemptions, and exceptions proposals. Multiple commenters recommended that CMS extend these flexibilities to all impacted payers. For example, a commenter recommended that HHS consider permitting state Medicaid and CHIP agencies that have a direct relationship with patients and providers to be eligible for extensions, exemptions, or exceptions. Another commenter recommended that CMS create an exception process for state Medicaid agencies in states or territories with HIEs that would give participating providers the same data as the Provider Access API. Some Medicaid agencies report concerns about duplication with these HIEs, as this would be an inefficient use of resources, could confuse providers, and may inhibit efforts to expand HIEs. A commenter wrote that CMS should create an exception process for Medicaid agencies in states or territories with robust HIEs that provide access to the same data. Another commenter recommended that CMS consider exception and extension criteria for plans where the proposed timelines and requirements would jeopardize their ability to operate.

Response: We thank all commenters for their input regarding extensions, exemptions, and exceptions for all payers. We are finalizing the extensions and exemptions policies as proposed for state Medicaid and CHIP FFS programs without extending them to additional payers because state Medicaid and CHIP FFS programs face certain unique challenges. As noted previously, unlike other impacted payers, state Medicaid and CHIP FFS programs do not have many discrete health care plans, and therefore cannot balance implementation costs across plans with low enrollment and those with higher enrollment. As stated at the beginning of this section, many states have complex procurement and staffing/recruitment challenges which do not apply to non-governmental organizations. We acknowledge HIEs could be helpful partners for payers when implementing these APIs. Nothing in this rule would prohibit a state from partnering with an HIE to meet its requirements. Further discussion regarding HIEs can be found in sections II.B.3.b.iii. and II.C.3.a. of this final rule.

Comment: Some commenters recommended that CMS include extensions and/or exemptions in the proposal for MA organizations, Special Needs Plans (SNPs), D–SNPs, or Institutional Special Needs Plans (I–SNPs). A commenter wrote that CMS should also permit extensions and exemptions for MA organizations offering integrated D–SNPs, especially if CMS does not finalize a phased-in approach to implementation. The commenter wrote that some of these payers are facing the challenge of unwinding current flexibilities implemented due to the PHE and are also facing significant requirements in coming years as finalized in the CY 2024 MA and Part D final rule (88 FR 22120). Another commenter asked that CMS consider whether there may be appropriate circumstances where it would be permissible for very small MA organizations, such as SNPs or I–SNPs to seek a one-time extension to the compliance dates.

Response: We did not propose extensions or exemptions for MA organizations or Medicaid managed care plans, including plans that integrate managed care Medicare and Medicaid benefits (for example, D–SNPs or applicable integrated plans). We have provided explanations for excluding Medicaid managed care plans in previous responses. We believe that most MA organizations are supported by entities with an operational and technical infrastructure that can support the API requirements because these organizations can leverage existing staff and vendor resources from implementation of the Patient Access and Provider Directory APIs. Further, MA organizations should have the operational infrastructure to analyze and implement the requirements for the new APIs based on that expertise. Finally, because we did not propose extensions or exemptions for MA organizations in the proposed rule, we cannot finalize such a policy for these entities in this rule.

Comment: Some commenters recommended that CMS grant exemptions for states that are already implementing electronic prior authorization solutions or state-level policies that conflict with the proposed Prior Authorization API requirements.

Response: The option for states to apply for an exemption exists to alleviate burden for states with small FFS populations and that have established an alternative plan to ensure that enrolled providers have efficient electronic access to the same information through other means while the exemption is in effect. We will not grant exemptions for situations where state law conflicts with the final rule. The final rule pre-empts any conflicting state law.

Comment: Multiple commenters recommended that CMS consider allowing states to obtain two 1-year extensions. A commenter stated that an additional, 1-year extension would allow states to better meet the proposed requirements. Another commenter noted that states face certain challenges that may be out of their control and prolong implementation.

Response: After consideration of comments received and for the reasons outlined in our response to these comments, we are extending the compliance dates for all of the polices that require API development or enhancement finalized in this rule to begin January 1, 2027, which will allow for additional time for the FHIR standard and IGs to continue to be refined and advanced to support all of the policies in this final rule. This applies to the compliance dates for the Provider Access, Payer-to-Payer, and Prior Authorization APIs. State Medicaid and CHIP FFS programs will be eligible to apply for up to a 1-year extension as proposed.

Comment: Multiple commenters expressed support for CMS's proposal regarding exemptions for state Medicaid and CHIP FFS programs and recommended that CMS finalize these proposed flexibilities regarding implementation of the Provider Access, Payer-to-Payer, and Prior Authorization APIs. A commenter indicated that in reviewing exemption requests and the compliance dates in the proposed rule, as well as other information system projects that are in development, their plans to implement a comprehensive systems integration platform that would integrate the MES would necessitate the option for an exemption. This commenter indicated that the project was particularly urgent due to the end of system support for another legacy system. Another commenter recommended that CMS use a flexible interpretation for the exemption process and noted that it would not be reasonable to require a state to build out APIs for a Federal Emergency Services Program (FESP), explaining that some agencies report having a high number of FFS enrollees in an FESP, such that less than 90 percent of their members are technically enrolled in managed care.

Response: We appreciate the support for the proposed exemption process, as well as for the simultaneous encouragement for payers to secure the necessary resources to implement the technology for the prior authorization and other APIs being finalized in this rule. We also confirm that the policy in this final rule does not apply to FESPs, and that other payers are not being considered eligible for exemptions, extensions, or exceptions at this time.

Comment: A commenter noted that states with managed care populations close to the proposed threshold for exemption may be incentivized to pressure beneficiaries into managed care to qualify for the exemption. A commenter stated that larger states qualifying for an exemption will have a total number of FFS beneficiaries that is greater than the total Medicaid population of smaller states that would not qualify for the exemption.

Response: CMS needs to balance the benefits to small populations of beneficiaries with the burden of new operations and costs being placed on states. CMS will not approve exemptions unless a state has established an alternative plan to ensure that enrolled providers have efficient electronic access to the same information, including prior authorization information, through other means while the exemption is in effect, or that states are providing efficient electronic access to other payers. Additionally, state agencies with an approved exemption will be required to meet the policies that do not require API development or enhancement for their FFS populations (that is, the reduced prior authorization decision timeframes, providing a specific reason for a denial, and reporting prior authorization metrics). These policies, to the extent they will mitigate barriers to care or support improvements in the transparency of information between the states and providers, are part of the overall scope for this final rule to address challenges with prior authorization. Concerning the methodology states use to apply and be approved for an exemption, we believe we have provided a threshold where a state could appropriately claim an exemption without taking actions that would inappropriately influence the enrollment process or individual enrollee's enrollment decisions. States' use of enrollment brokers for choice counseling and enrollment processing also protects enrollees from undue pressure during the enrollment process. We remind states of the enrollee protections specified at 42 CFR 438.54 and 457.1210 for Medicaid and CHIP managed care enrollment respectively, as well as disenrollment rights specified at 42 CFR 438.56(c) and 457.1212, respectively.

Comment: A commenter urged CMS to use a flexible interpretation for the exemption process for the API requirements for Medicaid agencies with at least 90 percent of their members enrolled in managed care, noting that some states have a high number of FFS beneficiaries in an FESP that are only covered for emergency care. The commenter stated that it would not be reasonable to require a state to build out APIs for beneficiaries and programs that cover such a narrow scope of services.

Response: We appreciate the commenter highlighting that some states may have larger populations in FFS where beneficiaries are not receiving comprehensive benefits and thus may experience only limited value from the APIs. Our intent with establishing this condition for exemption approval is that no FFS population will experience diminished health care delivery or information exchange capabilities as a result of an approved exemption. The exemption intends to alleviate the cost burden of implementing the API provisions on state Medicaid and/or CHIP agencies with small FFS populations, regardless of the scope of their benefit package. We remind states that CMS will grant an exemption if the state establishes to CMS's satisfaction that the state meets the criteria for the exemption and has established an alternative plan to ensure that enrolled providers have efficient electronic access to the same information through other means while the exemption is in effect, including patient information and prior authorization information.

b. Exception for Qualified Health Plan Issuers on the Federally-Facilitated Exchanges

For QHP issuers on the FFEs, we proposed an exception process to the Provider Access, Payer-to-Payer, and Prior Authorization APIs for issuers applying for QHP certification that cannot satisfy the proposed requirements. To apply for an exception, we proposed that an issuer must include as part of its QHP application a narrative justification describing the reasons why it cannot reasonably satisfy the requirements for the applicable plan year, the effect of non-compliance upon providers and enrollees, the current or proposed means of providing the required information to providers or other payers, and solutions and a timeline to achieve compliance with the requirements (87 FR 76304). We reiterate in this final rule that QHP issuers on the FFEs submit a new application each year and that this information will be part of the annual QHP Certification application submission. Thus, should the size, financial condition, or capabilities of the QHP issuer change such that it believes it can implement one or more of the APIs, that information would be included in the application. We received a few comments on the proposals for exceptions for QHPs.

Comment: Multiple commenters expressed support for the proposed exception process for QHP issuers on the FFEs, highlighting the need for this policy and recommending that CMS finalize the proposal to allow exceptions for QHP issuers on the FFEs regarding compliance with all proposed APIs.

Response: We appreciate the support for the policy that QHPs be permitted an exception for the policies that require API development or enhancement in cases where the FFE determines that making such QHPs available is in the interests of qualified individuals in the state or states in which the FFE operates, and an exception would be warranted to permit the QHP issuer to offer QHPs through the FFE. This policy and the exceptions per 45 CFR 156.222(c) are consistent with the exception for QHP issuers on the FFEs that we finalized for the Patient Access API in the CMS Interoperability and Patient Access final rule (85 FR 25552). We believe that having a QHP issuer offer QHPs through an FFE generally is in the best interest of patients; we would not want patients to have to go without access to QHP coverage because an issuer is unable to implement these APIs.

Comment: Multiple commenters expressed concern regarding the proposed exception process for QHP issuers on the FFEs. Commenters specifically highlighted the ability for a QHP issuer to be certified, even with an exception to these requirements. A commenter recommended that CMS limit using exceptions for QHP issuers on the FFEs for the Provider Access API, and another commenter recommended that CMS explain that QHP issuers on the FFEs must eventually comply with the proposed requirements. A commenter expressed concern that if QHP issuers on the FFEs can be certified without complying with the regulation, then there would not be an incentive for compliance. A commenter stated that the proposal does not make sense given the financial position of QHP issuers on the FFEs and their ability to afford cost-saving technology. The commenter recommended that any exception be conditioned on “no profit taking” by a health plan and limited executive compensation plans until the plan can comply. Additionally, the commenter stated that CMS had not offered a reasonable proposal for criteria to qualify a QHP issuer to be exempt from the proposed API requirements.

Response: We understand concerns from commenters about permitting delayed implementation of requirements to promote access to information and expedited decision-making. However, given the comments in support of the proposed exceptions process and our interest in ensuring a variety of coverage options for FFE enrollees, we are finalizing this exception as proposed. While some issuers are in a position to implement the updates that this rule requires, a wide range of issuers participate in the FFEs and vary in terms of when they will have available resources to adopt these new requirements. Per applicable rules at 45 CFR 156.221(h), 156.222(c), and 156.223(d), we have been and will continue granting exceptions to QHP issuers on the FFEs on an annual basis, and use information that issuers submit as part of the QHP certification process to track their progress.

We will implement the exceptions processes per 45 CFR 156.222(c), and 45 CFR 156.223(d), based on our experience to date with implementing the existing exception per 45 CFR 156.221(h) that is available to QHP issuers on the FFEs that cannot satisfy the requirements per 45 CFR 156.221(a) through (g) to implement and maintain the Patient Access API for the applicable plan year. When determining whether a QHP issuer on an FFE may qualify for an exception to the current requirement to provide a Patient Access API, we take into consideration the content that the issuer submits per the requirement at 45 CFR 156.221(h), including the impact of non-compliance upon enrollees, the current or proposed means of providing health information to enrollees, and solutions and a timeline to achieve compliance with the requirements of this section. This information allows us to assess whether a QHP issuer has a plan in place to mitigate harm or inconvenience to enrollees by ensuring they can access necessary information, as well as a plan to fully implement the requirements as soon as possible. Information that issuers submit during the QHP certification process also allows us to develop a knowledge base of API development capacity for issuers based on size and other circumstances, which can inform future decisions about whether to allow exceptions. We expect to build on this knowledge base as we implement the exceptions processes per 45 CFR 156.222(c) and 156.223(d), and as part of our updates to the QHP certification process in the coming years to reflect this rule's new requirements, we will continue to work closely with issuers and other stakeholders to ensure that our implementation balances the importance of access to information with robust QHP issuer participation on the FFEs.

Finally, QHP issuer applications for plan years 2023 and 2024 indicated that most issuers were compliant with the requirement to provide a Patient Access API. Further, issuers that sought an exception under 45 CFR 156.221(h) generally explained in their justifications that they planned to become compliant with the API requirements mid-way through the upcoming plan year, or shortly after the start of the plan year. This high level of compliance suggests that the availability of an exception does not discourage or de-incentivize issuers' implementation of these standards.

We agree that the intent of our final policies is for all impacted payers to provide patients with the benefits of the Provider Access, Payer-to-Payer, and Prior Authorization APIs as soon as they are financially and operationally able. For example, for each of the API provisions for which an exemption is available, we have indicated that if the payer cannot implement the API and is seeking an exemption, it must offer alternative options to the providers to support the intent of the policies; such programs would generally improve the exchange of patient data between payers for care management or access to information for patients, and to improve the prior authorization process for providers and payers. We believe that by requiring alternatives to the APIs during the exemption, payers will investigate options to implement the APIs because, in the long term, these will be more efficient and financially viable than maintaining current manual processes.

Table F1 shows the impacted payers that are eligible to apply for an extension, exemption, or exception for the Provider Access, Payer-to-Payer, and/or Prior Authorization APIs required in this final rule. Tables C1, D1, and E4 found in sections II.B., II.C., and II.D. of this final rule include the regulatory citations for the extensions, exemptions, and exceptions for each impacted payer.

3. Federal Matching Funds for State Medicaid and CHIP Expenditures on Implementation of the Provider Access, Payer-to-Payer, and Prior Authorization APIs

We explained in the proposed rule for each of the APIs, we would anticipate that states operating Medicaid and CHIP programs would be able to access Federal matching funds to support their implementation of the APIs—specifically, the Provider Access, Payer-to-Payer, and Prior Authorization APIs. We expect these APIs to lead to more efficient administration of Medicaid and CHIP state plans by supporting more efficient data exchange and prior authorization processes, consistent with sections 1902(a)(4) and 2101(a) of the Act, respectively.

We do not consider state expenditures for implementing the Provider Access, Payer-to-Payer, or Prior Authorization APIs to be attributable to any covered Medicaid item or service within the definition of “medical assistance.” Thus, in Medicaid, CMS will not match these expenditures at the state's regular Federal Medical Assistance Percentage (FMAP). However, FFP at a rate of 50 percent could be available for state expenditures related to implementing these APIs for Medicaid programs under section 1903(a)(7) of the Act (for the proper and efficient administration of the Medicaid state plan). The three APIs should, over time, help the state more efficiently administer its Medicaid program by supporting data exchange with providers and other payers and improving efficiencies in the prior authorization process. As we stated in the proposed rule, sharing certain data through the Provider Access API with participating providers could improve the quality of care for patients, using the Payer-to-Payer API may help patients manage their information across payers to support patient care, and using the Prior Authorization API will enable administrative efficiencies by reducing delays in the prior authorization process overall, and by helping reduce the number of denied and appealed prior authorization decisions.

States' expenditures to implement the proposed requirements could be eligible for 90 percent enhanced FFP under section 1903(a)(3)(A)(i) of the Act if the expenditures can be attributed to the design, development, and installation (DDI) of mechanized claims processing and information retrieval systems. Additionally, 75 percent enhanced FFP, under section 1903(a)(3)(B) of the Act, could be available for state expenditures to operate Medicaid mechanized claims processing and information retrieval systems to comply with the finalized API requirements.

States can request Medicaid enhanced FFP under section 1903(a)(3)(A)(i) or (B) of the Act through the APD process described at 45 CFR part 95, subpart F. Additionally, 42 CFR 433.112(b)(12) and 433.116(c) require that any system for which states are receiving enhanced FFP under section 1903(a)(3)(A)(i) or (B) of the Act align with and incorporate the ONC Health IT standards adopted at 45 CFR part 170, subpart B. The APIs complement this requirement because they further interoperability by using standards adopted by ONC at 45 CFR 170.215. States must comply with 42 CFR 433.112(b)(10) and 433.116(c) to explicitly support exposed APIs, meaning the API's functions are visible to others to enable the creation of a software program or application, as a condition of receiving enhanced FFP under section 1903(a)(3)(A)(i) or (B) of the Act. We note that FHIR is an open-source standard that can meet the requirements at 42 CFR 433.112(b)(10) and 433.116(c) if implemented by following our regulations, particularly the technical, documentation and denial or discontinuation requirements at 42 CFR 431.60.

Finally, 42 CFR 433.112(b)(13) and 433.116(c) require states to promote sharing, leverage, and re-use of Medicaid technologies and systems within and among states as a condition of receiving enhanced FFP under section 1903(a)(3)(A)(i) or (B) of the Act. CMS interprets that requirement to apply to technical documentation associated with a technology or system, such as technical documentation for connecting to a state's APIs. Making the needed technical documentation publicly available so that systems that need to do so can connect to the APIs finalized in this rule is required as part of the technical requirements at 42 CFR 431.60(d) for all APIs, including the Provider Access, Payer-to-Payer, and Prior Authorization APIs.

Separately, for CHIP agencies, section 2105(c)(2)(A) of the Act and 42 CFR 457.618, limiting administrative costs to no more than 10 percent of a state's total computable expenditures for a fiscal year (FY), will apply to administrative claims for developing the APIs finalized in this rule.

Comment: Multiple commenters expressed appreciation for the inclusion of language that states may be eligible for enhanced FFP to support implementation of the Provider Access, Payer-to-Payer, and Prior Authorization APIs in this final rule. While these commenters expressed support for this option, others asked CMS to explain whether enhanced FFP is also available to implement the Patient Access API requirements.

Response: Many states have already requested enhanced Federal matching funds for their expenditures on implementation of the Patient Access API required in the CMS Interoperability and Patient Access final rule. Additionally, enhanced funding under section 1903(a)(3)(A)(i) of the Act may be available for certain expenditures to design, develop, and install the enhancements to the Patient Access API finalized in this rule, in addition to expenditures related to the Provider Access, Payer-to-Payer, and Prior Authorization APIs. CMS encourages states to seek enhanced FFP where it might be applicable for states' expenditures on work needed to meet state Medicaid and CHIP agencies' requirements under this rule and looks forward to reviewing any APDs submitted by states. Instructions for submitting the APDs are available on the Medicaid website under the topic of “Medicaid State Plan Amendments” with information about what categories of costs may be included in the requests, such as HIE connection/interface costs. The information on the categories that are included in these requests can be found in the State Medicaid Manual (SMM), Chapter 11, sections 265 & 276, the State Medicaid Director Letter (SMDL) 16–004, “Mechanized Claims Processing and Information Retrieval Systems-Enhanced Funding,” and the State Health Official (SHO) #20–003, “Implementation of the CMS Interoperability and Patient Access final rule.”

Comment: A commenter recommended that states receive a 90 percent Federal match to support implementation of these requirements. Another commenter urged CMS to explain in the final rule, or additional guidance, whether all, or likely all, of the required state investment to develop these APIs, would qualify for enhanced Federal matching to establish and operate API systems.

Response: States' expenditures to implement the proposed requirements for each of the APIs may be eligible for 90 percent enhanced FFP if the expenditures can be attributed to the DDI for those APIs that benefit the Medicaid program. CMS determines on a case-by-case basis when states' APDs requesting this 90 percent FFP are approvable, consistent with the requirements at 42 CFR part 433, subpart C, and 45 CFR part 95, subpart F. States should work with their MES State Officers for further guidance specific to their programs.

Comment: A commenter recommended that CMS clarify that the Federal funding resources available for states meeting the Prior Authorization API requirement can also include pass-through payments to providers to obtain and utilize interoperable EHR technology for these purposes. This commenter also expressed concern that the proposed rule did not offer any indication of available resources for providers, but they appreciate CMS's clarification of available Federal resources available to states for implementing the Prior Authorization API requirement. Another commenter said that states should be granted flexibility for Federal funding sources to expand the number of SNF providers able to utilize the new Provider Access API.

Response: We encourage states to apply for Federal funding to support their planning, development, and implementation of state systems including the Provider Access, Payer-to-Payer, and Prior Authorization APIs, because these APIs will enable more providers to engage in data exchange with state systems to improve patient care. As previously noted, enhanced Federal Medicaid funding at the 90 percent rate may be available for the DDI and at the 75 percent rate for the operation of these API initiatives that benefit the Medicaid program. These enhanced Federal matching funds, as outlined at 42 CFR 433.112 (DDI) and 433.116 (operation), are available for state expenditures on Medicaid state systems only, and not available for other state or provider expenditures on provider-only systems to support providers' or other entities' efforts to implement APIs. Similarly, Federal matching funds at 50 percent under section 1903(a)(7) of the Act might be available to support Medicaid state specific activities for the required provisions. However, none of these funds are available for funding to providers, as these are designated to support state-specific initiatives.

4. Medicaid Expansion CHIP

Most states have Medicaid expansion CHIP programs, in which a state receives Federal funding to expand Medicaid eligibility to optional targeted low-income children that meet the requirements of section 2103 of the Social Security Act. We proposed and are now finalizing our policy at 42 CFR 457.700(c), that for states with Medicaid Expansion CHIP programs, the final requirements as proposed for Medicaid will apply to those programs rather than separate provisions for the CHIP program. In this final rule, we make explicit that the Medicaid requirements at §§ 431.60, 431.61, and 431.80 apply to the Medicaid expansion CHIP programs rather than the separate CHIP requirements at §§ 457.730, 457.731, and 457.732.

Comment: A commenter stated that most states have operating Medicaid expansion CHIP programs and that the provisions outlined in the proposed rule would apply to most states.

Response: We agree with this commenter and as stated, are confirming that Medicaid requirements apply equally to Medicaid expansion CHIP programs.

5. Final Action

After consideration of the comments received, and for the reasons discussed in the CMS Interoperability and Prior Authorization proposed rule and our responses to those comments (as summarized), we are finalizing our proposal to allow for state Medicaid and CHIP FFS programs and QHP issuers on the FFEs to apply for certain extensions, exemptions, or exceptions for the Provider Access, Payer-to-Payer and/or Prior Authorization APIs. We are also finalizing our proposal regarding Medicaid Expansion CHIP programs.

We are finalizing the policy to allow state Medicaid and CHIP FFS programs to apply for an extension to the deadline from the requirements to implement the Provider Access, Payer-to-Payer, and/or Prior Authorization APIs. Specifically, we are finalizing that states may request a one-time, 1-year extension as part of their annual APD for MMIS operations expenditures before the compliance dates. The written extension request must include the following: (1) a narrative justification describing the specific reasons why the state cannot satisfy the requirement(s) by the compliance dates, and why those reasons result from circumstances that are unique to the agency operating the Medicaid and/or CHIP FFS program; (2) a report on completed and ongoing state activities that evidence a good faith effort toward compliance; and (3) a comprehensive plan to meet the requirements no later than 1 year after the compliance date. CMS will grant an extension if the state establishes, to CMS's satisfaction, that the request adequately establishes a need to delay implementation; and that the state has a comprehensive plan to meet the requirements no later than 1 year after the compliance date.

We are finalizing a policy to allow state Medicaid and CHIP FFS programs to apply for an exemption from the requirements of the Provider Access, Payer-to-Payer, and/or Prior Authorization APIs when at least 90 percent of the state's Medicaid beneficiaries are enrolled in Medicaid MCOs or when at least 90 percent of the state's separate CHIP beneficiaries are enrolled in CHIP MCOs. We are finalizing that the requirements for the Payer-to-Payer API to obtain beneficiaries' permission, provide educational resources at the time of requesting permission, and identify patients' previous/concurrent payers, including for beneficiaries covered under managed care are not eligible for the exemption. Specifically, we are finalizing the policy that a state may request an exemption, as part of their annual APD for MMIS operations expenditures before the compliance date (which may be extended by 1 year if the state receives an extension). The exemption request must include documentation showing that the state meets the threshold criterion based on enrollment data from the most recent CMS “Medicaid Managed Care Enrollment and Program Characteristics” (for a Medicaid FFS exemption) or enrollment data from section 5 of the most recently accepted state submission to CHIP Annual Report Template System (CARTS). The state must also include an alternative plan to ensure that providers have efficient electronic access to the same information through other means while the exemption is in effect. CMS will grant the exemption if the state establishes, to CMS's satisfaction, that the state meets the criteria for the exemption, including an alternative plan to ensure efficient electronic access to the same information through other means while the exemption is in effect.

We are finalizing that an exemption will expire under two scenarios. First, an exemption will expire if, based on the 3 previous years of available, finalized Medicaid Transformed Medicaid Statistical Information System (T–MSIS) and/or CHIP CARTS enrollment data, the State's MCO enrollment for 2 of the previous 3 years is below 90 percent. Second, an exemption will expire if CMS approves a state plan amendment, waiver, or waiver amendment that would significantly reduce the percentage of beneficiaries enrolled in managed care and the anticipated shift in enrollment is confirmed by the first available, finalized Medicaid T–MSIS and/or CHIP CARTS enrollment data.

We are finalizing that states must provide written notification to CMS if they no longer qualify for an approved exemption. Written notification must be submitted to CMS within 90 days of the finalization of the first annual Medicaid T–MSIS managed care enrollment data and/or the CARTS report for CHIP demonstrating the enrollment shift to below 90 percent in managed care. States must obtain CMS approval of a timeline for compliance with the API requirements for Medicaid FFS and/or CHIP FFS within 2 years of the expiration of the exemption. For additional context, please refer to the proposed rule (87 FR 76263).

In addition, we are finalizing that for states with Medicaid expansion CHIPs, the requirements for Medicaid will apply to those programs rather than-the provisions for separate CHIPs.

We are finalizing that an issuer applying for QHP certification may apply for an exception from requirements of the Provider Access, Payer-to-Payer, and/or Prior Authorization APIs. The issuer must include, as part of its QHP application, a narrative justification describing the reasons why the issuer cannot reasonably satisfy the requirements for the applicable plan year, the impact of non-compliance upon providers and enrollees, the current or proposed means of providing health information to providers or other payers, and solutions and a timeline to achieve compliance with the requirements. An FFE may grant an exception to the requirements if it determines that making that issuer's QHPs available through the FFE is in the interests of qualified individuals in the state or states in which the FFE operates, and an exception is warranted to permit the issuer to offer QHPs through the FFE.

These final policies apply to state Medicaid and CHIP FFS programs and QHP issuers on the FFEs at the CFR sections listed in Tables C1, D1, and E4.

F. Electronic Prior Authorization Measures for the Merit-Based Incentive Payment System Promoting Interoperability Performance Category and the Medicare Promoting Interoperability Program

1. Background

As discussed in detail in section II.D. of this final rule, the current prior authorization process needs improvement to reduce the burden associated with the process itself. To facilitate those needed improvements in the prior authorization process, we are requiring impacted payers to implement and maintain a Prior Authorization API. The Prior Authorization API aims to improve care coordination and shared decision-making by enabling enhanced electronic documentation discovery and facilitating electronic prior authorization. We believe the Prior Authorization API will reduce administrative burden, improve efficiency, and ensure patients promptly receive necessary medical items and services. We also recognize that efficiencies from payer implementation of these APIs will only be realized if they are utilized by requesting providers to complete prior authorization requests.

Therefore, we proposed a new measure for MIPS eligible clinicians (as defined at 42 CFR 414.1305) under the MIPS Promoting Interoperability performance category, as well as for eligible hospitals and CAHs under the Medicare Promoting Interoperability Program, related to electronic prior authorization and the Prior Authorization API (87 FR 76312–76314). We proposed the new measures, titled “Electronic Prior Authorization,” to be included in the HIE objective for the MIPS Promoting Interoperability performance category and in the HIE objective for the Medicare Promoting Interoperability Program. The Electronic Prior Authorization measure aims to address concerns, specifically from commenters in response to the December 2020 Interoperability proposed rule (85 FR 82586), that few providers would use the Prior Authorization API established by impacted payers.

MIPS is authorized under section 1848(q) of the Act. As described in sections 1848(q)(2) and (5) of the Act, we evaluate the performance of MIPS eligible clinicians in four performance categories, which we refer to as the quality, cost, improvement activities, and Promoting Interoperability performance categories. Under 42 CFR 414.1375(b)(2), MIPS eligible clinicians must report on objectives and measures as specified by CMS for the Promoting Interoperability performance category. We refer readers to the CY 2024 Physician Fee Schedule (PFS) final rule (88 FR 79357–79362) for a list of the current objectives and measures required for the MIPS Promoting Interoperability performance category. We determine a final score for each MIPS eligible clinician based on their performance in the MIPS performance categories during a MIPS performance period for a year. Based on the MIPS eligible clinician's final score, we calculate a MIPS payment adjustment (which can be positive, neutral, or negative) that applies for the covered professional services they furnish in the MIPS payment year which occurs 2 years later.

The Medicare Promoting Interoperability Program for eligible hospitals and CAHs is authorized in part under sections 1886(b)(3)(B)(ix) and 1814(l)(4) of the Act. Under these statutory provisions, eligible hospitals and CAHs that are not meaningful EHR users are subject to Medicare payment reductions. To be considered a meaningful EHR user (as defined under 42 CFR 495.4), the eligible hospital or CAH must demonstrate meaningful use of CEHRT by satisfying objectives and measures as required under 42 CFR 495.24. We refer readers to the FY 2024 Hospital Inpatient Prospective Payment System (IPPS) and Long-Term Care Hospital (LTCH) final rule (88 FR 59269–59277) for a summary of the currently adopted objectives and measures for the Medicare Promoting Interoperability Program.

2. Electronic Prior Authorization

To support the policies in this final rule and maximize the potential to improve the prior authorization process for providers and patients, we proposed to add new measures, titled “Electronic Prior Authorization,” under the HIE objective of the MIPS Promoting Interoperability performance category and under the HIE objective of the Medicare Promoting Interoperability Program. These measures support the electronic exchange of health information to improve the quality of health care, such as promoting care coordination, as described in section 1848(o)(2)(A)(ii) of the Act with respect to MIPS eligible clinicians, and section 1886(n)(3)(A)(ii) of the Act with respect to eligible hospitals and CAHs.

We proposed that for purposes of the Electronic Prior Authorization measures, a prior authorization request must be made using the Prior Authorization API to satisfy the measure, unless the MIPS eligible clinician, eligible hospital, or CAH could claim an applicable exclusion. As discussed in more detail in the proposed rule (87 FR 76313) and further in this section II.F., we proposed that MIPS eligible clinicians, eligible hospitals, and CAHs would report the number of prior authorizations requested electronically via the Prior Authorization API using data from their CEHRT as a numerator and denominator, unless they could claim an applicable exclusion. We proposed that beginning with the CY 2026 performance period/CY 2028 MIPS payment year for MIPS eligible clinicians and the CY 2026 EHR reporting period for eligible hospitals and CAHs, a MIPS eligible clinician, eligible hospital, or CAH that fails to report the measure or claim an exclusion would not satisfy the MIPS Promoting Interoperability performance category or Medicare Promoting Interoperability Program reporting requirements. For the CY 2026 performance period/CY 2028 MIPS payment year for MIPS eligible clinicians and the CY 2026 EHR reporting period for eligible hospitals and CAHs, we proposed that the Electronic Prior Authorization measure would not be scored and would not affect the total score for the MIPS Promoting Interoperability performance category or the Medicare Promoting Interoperability Program. In other words, for CY 2026, a MIPS eligible clinician, eligible hospital, or CAH would be required to report a numerator of at least one for the measure or claim an exclusion, but the measure would not be scored. We proposed that, if the MIPS eligible clinician or eligible hospital or CAH does not report a numerator of at least one for the measure or claim an exclusion, they would receive a zero score for the MIPS Promoting Interoperability performance category or the Medicare Promoting Interoperability Program, respectively. We noted that we intend to propose a scoring methodology for the measure in future rulemaking.

First, we are finalizing that MIPS eligible clinicians report the Electronic Prior Authorization measure beginning with the CY 2027 performance period/2029 MIPS payment year (rather than the CY 2026 performance period/2028 MIPS payment year), and that eligible hospitals and CAHs report the Electronic Prior Authorization measure beginning with the CY 2027 EHR reporting period (rather than the CY 2026 EHR reporting period). We believe that this modification to our proposed policy for the Electronic Prior Authorization measures will allow more time for MIPS eligible clinicians, eligible hospitals, and CAHs to adjust to the new electronic prior authorization workflow using the Prior Authorization API.

Second, we are finalizing the Electronic Prior Authorization measure with a modification such that it is structured as an attestation (yes/no) measure, instead of a numerator and denominator measure as originally proposed, for both MIPS eligible clinicians and eligible hospitals and CAHs. As an attestation measure, MIPS eligible clinicians, eligible hospitals, and CAHs will report a “yes” or “no” response or report an applicable exclusion for the Electronic Prior Authorization measure. Instead of reporting how many times the MIPS eligible clinician, eligible hospital, or CAH requested prior authorization electronically via the Prior Authorization API in a numerator and all prior authorizations in a denominator as proposed (87 FR 76313), the MIPS eligible clinician, eligible hospital, or CAH will either submit an attestation (yes/no) regarding whether they used the Prior Authorization API to submit at least one prior authorization request electronically or claim an applicable exclusion to report the modified Electronic Prior Authorization measures. We are modifying the proposed reporting methodology to align with the modification to the measure specifications we are finalizing, specifically reporting this measure as an attestation yes/no response instead of a numerator and denominator. We believe that this modification to our proposed policy for the Electronic Prior Authorization measures will reduce burden by not requiring MIPS eligible clinicians, eligible hospitals, and CAHs to calculate and report a numerator and denominator for the Electronic Prior Authorization measure.

Additionally, we are finalizing that the measures will not be scored (that is, not assigned points for completion or failure). Instead, if a MIPS eligible clinician, eligible hospital, or CAH fails to report the measure as specified, they would not meet the minimum reporting requirements, not be considered a meaningful EHR user, and fail the Medicare Promoting Interoperability Program or the MIPS Promoting Interoperability performance category. A failure in the Medicare Promoting Interoperability Program would result in a downward payment adjustment for eligible hospitals or CAHs (unless the eligible hospital or CAH receives a hardship exception). A failure in the Promoting Interoperability performance category would result in the MIPS eligible clinician receiving a score of zero for the performance category, which is currently worth 25 percent of their final score for MIPS. This is consistent with our original proposal that failure to report a numerator of at least one for the measure, or claim an exclusion, warrants a zero score for the MIPS Promoting Interoperability performance category and failure to meet Medicare Promoting Interoperability Program reporting requirements (87 FR 76313).

For the MIPS Promoting Interoperability performance category, satisfactory performance on this measure can be demonstrated only by reporting a “yes” response on the attestation or claiming an applicable exclusion. A “no” response on the attestation will result in the MIPS eligible clinician failing to meet the minimum reporting requirements, therefore not being considered a meaningful EHR user for MIPS, as set forth in section 1848(o)(2)(A) of the Act and defined at 42 CFR 414.1305, for the MIPS payment year (42 CFR414.1305). MIPS eligible clinicians that do not report a “yes” response or claim an applicable exclusion for the Electronic Prior Authorization measure as specified (that is, they do not submit the measure or claim an exclusion or report a “no” response) will not earn a score for the MIPS Promoting Interoperability performance category (a score of zero for the category). A MIPS eligible clinician's score in the Promoting Interoperability performance category is generally worth 25 percent of their total final score for MIPS. We note that to report a “yes,” the action of the measure must occur during the selected performance period or EHR reporting period, as per the measure specifications defined below.

For the Medicare Promoting Interoperability Program, only a “yes” response on the attestation, or claiming an applicable exclusion, will fulfill the minimum requirements of this measure. A “no” response will result in the eligible hospital or CAH failing to meet the measure, and therefore failing to meet minimum program reporting requirements, thus not being considered a meaningful EHR user for an EHR reporting period, as defined in section 1886(n)(3) of the Act. Eligible hospitals and CAHs that do not meet the minimum program reporting requirements are subject to a downward payment adjustment (unless the eligible hospital or CAH receives a hardship exception).

The following is a summary of the comments we received on our proposals and our responses.

Comment: Multiple commenters expressed support for our proposal to add the Electronic Prior Authorization measure under the MIPS Promoting Interoperability performance category for MIPS eligible clinicians and the Medicare Promoting Interoperability Program for eligible hospitals and CAHs to incentivize use of the Prior Authorization API among providers. Multiple commenters agreed that it is appropriate to place the proposed Electronic Prior Authorization measure under the HIE objective for both the MIPS Promoting Interoperability performance category and the Medicare Promoting Interoperability Program. Multiple commenters noted that the Electronic Prior Authorization measure would incentivize MIPS eligible clinicians, eligible hospitals, and CAHs to use the Prior Authorization API capabilities to automate the prior authorization process, which could lead to more timely delivery of care. A commenter stated that this proposal would help ensure that providers utilize the Prior Authorization and Provider Access APIs' technology, in addition to promoting interoperability and the electronic exchange of health information.

Response: We thank commenters for their feedback and support of the proposed Electronic Prior Authorization measure under the MIPS Promoting Interoperability performance category and the Medicare Promoting Interoperability Program. We agree that the Electronic Prior Authorization measure will help incentivize MIPS eligible clinicians, eligible hospitals, and CAHs to use the Prior Authorization API to automate the prior authorization process, which could lead to more timely delivery of care.

Comment: Multiple commenters encouraged CMS to continue to explore additional and alternative opportunities to foster API adoption and utilization of electronic prior authorization tools, as well as incentivize the adoption of the Prior Authorization API across the industry and include a broader set of providers outside of these incentive programs. Commenters suggested expanding the Electronic Prior Authorization measure to other programs to reach additional provider populations, such as the Medicare Shared Savings Program (MSSP) and Alternative Payment Models (APMs). A commenter also recommended implementing a pilot program as part of CMS's Primary Care First (PCF) model. A commenter recommended that CMS should work in partnership with ONC to implement incentives that encourage further adoption of electronic prior authorization. Another commenter supported further development of performance measures to encourage interoperability enhancements and API uptake. A commenter recommended that CMS engage with various associations to encourage further adoption. A commenter supported industry-wide adoption of electronic prior authorization processes but suggested that only requiring impacted payers to build APIs would not lead to broad adoption. A commenter stated that CMS should use every available option to influence and incentivize adoption of these standards within the health care industry if it intends to mandate that impacted payers participate. Commenters also acknowledged that the provider community is an important, interested group in the drive to enable widespread interoperability.

Response: We thank the commenters for their support and additional recommendations on how we can incentivize using the Prior Authorization API. We will continue to monitor and assess opportunities we can leverage to encourage API implementation uptake. Additionally, we will continue to collaboratively work with ONC to identify ways to incentivize the adoption of electronic prior authorization. We believe that establishing the Electronic Prior Authorization measure is a viable method to begin fostering the adoption and utilization of the Prior Authorization API by MIPS eligible clinicians, eligible hospitals, and CAHs in these initiatives. We note that nothing in the Prior Authorization API proposal we are finalizing would prohibit providers that are not subject to MIPS or the Medicare Promoting Interoperability Program from using the API for electronic prior authorization as well. Where permitted under applicable law and relevant program requirements, we encourage providers who are not included in these programs to leverage the Prior Authorization APIs to gain the intended benefits, such as improving efficiency and reducing the administrative burden of prior authorization processes. We agree that requiring impacted payers to build the APIs would not lead to broad adoption. However, we believe that establishing the Electronic Prior Authorization measure under both MIPS and the Medicare Promoting Interoperability Program will help promote the implementation and use of the Prior Authorization API by MIPS eligible clinicians, eligible hospitals, and CAHs. In order for the industry to realize the efficiencies of the Prior Authorization API and achieve the goals set forth in this final rule, it is essential that both impacted payers and providers adopt and use a Prior Authorization API.

Comment: Multiple commenters opposed adoption of the proposed Electronic Prior Authorization measure stating that the measure would be inefficient and burdensome, citing challenges with additional workflow requirements, increased provider burden, and financial burden. A commenter stated that it would potentially leave providers unfairly penalized. Several commenters noted that the burden of reporting outweighs the benefits of use and that hospital IT resources are already overloaded and limited. Other commenters noted that mandating the Electronic Prior Authorization measure could further increase provider burden and detract from patient care, directing MIPS eligible clinicians, eligible hospitals, and CAHs' attention away from patients. A commenter stated that the Electronic Prior Authorization measure proposal is unlikely to provide significant relief to providers (that is, MIPS eligible clinicians, eligible hospitals, and CAHs). Another commenter stated that payers should compensate providers fairly for the cost of each prior authorization for the implementation of costly and burdensome electronic prior authorization requirements. This commenter stated that each prior authorization is a net financial loss for practices. Another commenter recommended that the Electronic Prior Authorization measure should remain optional until a time when the benefit, both monetarily and in reduced administrative burden, can be quantified for a calculated return on investment.

Response: We appreciate the feedback provided by commenters and note that we believe the benefit of the Prior Authorization API will outweigh the burden of implementation. We refer readers to the Collection of Information (COI) requirements in section III. of this final rule regarding burden and the regulatory impact analysis (RIA) we conducted in section IV. of this final rule for the additional information on the cost calculations of this Electronic Prior Authorization measure for MIPS eligible clinicians reporting for the MIPS Promoting Interoperability performance category and for eligible hospitals and CAHs reporting for the Medicare Promoting Interoperability Program. We acknowledge that there is an initial implementation and data collection burden associated with the Electronic Prior Authorization measure. However, we believe that the benefits of using an electronic prior authorization process outweigh the burdensome manual process used today. We believe that making the prior authorization process electronic will improve the time and burden associated with the current process, allowing providers to put time back into direct patient care, and ultimately will reduce provider burnout. We emphasize that we are implementing requirements for both impacted payers and providers (that is, MIPS eligible clinicians, eligible hospitals, and CAHs) to help streamline the prior authorization process because both payers and providers have a role to play in this process and the solution cannot be one-sided. As discussed further in this section, in order to address concerns regarding the burden of the Electronic Prior Authorization measure on MIPS eligible clinicians, eligible hospitals, and CAHs, we are modifying the measure to be an attestation (yes/no) measure rather than a numerator and denominator measure. Therefore, data collection to report a numerator and denominator for the Electronic Prior Authorization measure is no longer required.

Comment: A commenter cautioned that the Electronic Prior Authorization measure for the MIPS Promoting Interoperability performance category would reflect data regarding a different population than other MIPS measures, stating that other measures in MIPS are designed to capture information about the Medicare beneficiary population specifically. The commenter stated that this would make these measures difficult to compare. Another commenter stated that the Electronic Prior Authorization measure proposed for the MIPS Promoting Interoperability performance category does not apply to Medicare FFS, which results in misalignment.

Response: We thank the commenters for their feedback. First, we disagree that the Electronic Prior Authorization measure will reflect data regarding a different population than other MIPS measures. We note that all of the MIPS Promoting Interoperability performance category measures are based on using CEHRT, utilizing data that are captured in the CEHRT, and require submission of applicable data, regardless of payer. The Electronic Prior Authorization measure is consistent with other measures reported under the MIPS Promoting Interoperability performance category.

Second, although Medicare FFS is not an impacted payer, we refer readers to section I.D.1. of this final rule where we discuss CMS's intent to align Medicare FFS to the requirements of this final rule, as applicable. Although, generally, the policies in this final rule do not directly pertain to Medicare FFS, we want to ensure that Medicare beneficiaries, as well as other individuals, can benefit from these policies, regardless of their coverage, delivery system, or payer.

Comment: A commenter stated that, if CMS does move forward with the proposed Electronic Prior Authorization measure for the MIPS Promoting Interoperability performance category, CMS should consider exempting small, rural, and underserved practices from reporting the Electronic Prior Authorization measure, which would redistribute the Promoting Interoperability performance category's weight to other performance categories. A few commenters suggested that the inclusion of the Electronic Prior Authorization measure would have a disproportionately adverse effect on small business entities, federally recognized American Indian and Alaska Native-Tribal communities, psychiatric practices, and other specialties and could contribute to the electronic divide.

Response: We thank commenters for their feedback and would like to note that there are a number of situations in which MIPS eligible clinicians may qualify for reweighting of the MIPS Promoting Interoperability performance category. This includes policies implemented in our regulations at 42 CFR part 414, subpart O, including 42 CFR 414.1380(c)(2), if they have a special status (defined at 42 CFR 414.1305), are a qualifying clinician type, or have a CMS-approved significant hardship or other exception application. For example, MIPS eligible clinicians in small practices (fifteen or fewer MIPS eligible clinicians) may have the MIPS Promoting Interoperability performance category reassigned a weight of zero percent automatically in the event the MIPS eligible clinician in a small practice (as verified by CMS on an annual basis) does not submit any data for any of the measures in that category as provided at 42 CFR 414.1380(c)(2)(i)(C)( 9), and therefore would not be required to meet the MIPS Promoting Interoperability performance category's requirements including reporting on this Electronic Prior Authorization measure (86 FR 65485–65487). If the MIPS Promoting Interoperability performance category is reweighted to zero percent as provided at 42 CFR 414.1380(c)(2)(i), the category's 25 percent weight will be redistributed to the remaining MIPS performance categories in accordance with 42 CFR 414.1380(c)(2)(ii).

Comment: Multiple commenters opposed the proposed addition of the Electronic Prior Authorization measure. Commenters believed that the finalization of the Electronic Prior Authorization measure would not be necessary because MIPS eligible clinicians, eligible hospitals, and CAHs would be prompted to voluntarily adopt and use the Prior Authorization API if the API achieves the goal of streamlining the prior authorization process, which likely would reduce provider burden, improve prior authorization processing time, and enable more timely access to care. Multiple commenters expressed that they do not believe that the proposed Electronic Prior Authorization measure would address concerns about low provider utilization of APIs, especially for small, rural providers, due to cost, limited bandwidth, and lack of dedicated health IT staff. A commenter expressed that they do not believe that the inclusion of the Electronic Prior Authorization measure would be a sufficient incentive for MIPS eligible clinicians, eligible hospitals, and CAHs to overcome the costs associated with the transaction. Some commenters stated that, as electronic prior authorization becomes more common and affordable, providers would be incentivized to adopt this process, which promises to free up resources and allow providers to spend more time on patient care. A commenter stated that providers will be naturally incentivized to engage in electronic prior authorization processes if the processes lower costs, carry a minimal burden, do not cause unreasonable delays in care, and lead to care that is in their patients' best interests. Another commenter stated that the proposal to add a measure on conducting electronic prior authorization for items or services using the Prior Authorization API is not sufficient to encourage robust use of the Prior Authorization API by providers and stated that the proposals will be a one-sided mandate on impacted payers.

Response: We appreciate the commenters' feedback and are glad to hear that providers likely would be naturally incentivized and prompted to voluntarily adopt and use the Prior Authorization API if the API achieves the goal of streamlining the prior authorization process, which we believe it will. However, based on experience with adoption of other similar new EHR technology, we believe there needs to be an initial drive to encourage all parties involved (payers and providers) to develop, implement, and use the new Prior Authorization API to support widespread adoption, thus reaping the benefits of burden reduction through the electronic prior authorization processes. We understand and agree that the Electronic Prior Authorization measure itself may not be enough to address concerns about low provider utilization of APIs, particularly for small and rural providers. However, we believe the improvement and benefits in the prior authorization processes resulting from using the Prior Authorization API, specifically, may encourage such providers to adopt the API to help streamline existing paper-based or portal-based processes.

We acknowledge that small, rural providers may have limited bandwidth and fewer dedicated IT staff. We note that implementing an electronic prior authorization process could free up resources and allow providers to spend more time on patient care, which can be a challenge for small, rural providers. We also note that MIPS eligible clinicians in small practices (fifteen or fewer MIPS eligible clinicians) may have the MIPS Promoting Interoperability performance category reassigned a weight of zero percent automatically in the event the MIPS eligible clinician in a small practice (as verified by CMS on an annual basis) does not submit any data for any of the measures in that category as provided at 42 CFR 414.1380(c)(2)(i)(C)( 9), and therefore would not be required to meet the category's requirements including reporting on this Electronic Prior Authorization measure (86 FR 65485–65487). We believe that using electronic prior authorization processes will benefit small, rural providers, and small practices in underserved communities who are able to implement and maintain the Prior Authorization API in their processes with by saving time, faster turnaround on prior authorization requests, and, in turn, improved patient satisfaction.

Comment: A commenter requested that CMS calculate the additional cost of compliance with the MIPS requirements generally and consider what benefit MIPS reporting offers when practices already have a great interest in lowering their expenses related to prior authorization.

Response: We appreciate the commenter's feedback regarding cost of the Electronic Prior Authorization measure and refer readers to the RIA we conducted in section IV. of this final rule for the additional information on the cost calculations of this Electronic Prior Authorization measure for MIPS eligible clinicians reporting for the MIPS Promoting Interoperability performance category and for hospitals and CAHs reporting for the Medicare Promoting Interoperability Program. We note that the cost of compliance and benefits of reporting for MIPS as a whole are outside the scope of this rule. We will continue to evaluate use of the Prior Authorization API and assess whether the Electronic Prior Authorization measure has achieved its goal of promoting widespread Prior Authorization API adoption.

Comment: Multiple commenters acknowledged that the proposed Electronic Prior Authorization measure is not directed toward the impacted payers. A commenter stated that CMS should collect prior authorization data from payers to measure their performance rather than from providers. Another commenter noted that the electronic prior authorization proposal does not assess any financial costs against payers to discourage their overuse of prior authorizations.

Response: We thank the commenters for their feedback and acknowledge that this Electronic Prior Authorization measure is not intended to incentivize payers to use the Prior Authorization API. For more information about the Prior Authorization API requirements for payers, we refer readers to section II.D. of this final rule.

To reiterate, the success of the Prior Authorization API is dependent upon both payers and providers using the Prior Authorization API. We want to stress the importance of both payers and providers using the Prior Authorization API to ensure that all parties can experience the maximum benefits of engaging in the electronic prior authorization process. Thus, we recognize the importance of not only requiring impacted payers to build, implement, and maintain the API, but also to drive MIPS eligible clinicians, eligible hospitals, and CAHs to use it.

We agree that collecting prior authorization data from payers is important and provides accountability for using prior authorization processes. As such, we are finalizing our proposal to require payers to publicly report certain prior authorization metrics. We refer readers to section II.D. of this final rule for further information on these requirements for impacted payers.

We note that prior authorization is an established administrative process used by payers to help control costs and ensure payment accuracy by verifying that an item or service is medically necessary, meets coverage criteria, and is consistent with standards of care before the item or service is provided. The policies we are finalizing are not intended to discourage the use of prior authorization, nor do they impose direct financial repercussions for using prior authorization by payers. The policies we are finalizing in this final rule are intended to streamline the existing prior authorization process.

Comment: Multiple commenters noted that the adoption of the Electronic Prior Authorization measure contradicts CMS's goal of reducing provider burden and urged CMS not to replace one type of administrative burden with another. Another commenter cautioned that the proposed Electronic Prior Authorization measure is not suitable for a quality improvement program given that the focus is on technological capability. A commenter stated that measures related to prior authorization conflict with the goal of MIPS to improve quality of health care, stating there is no evidence to indicate that prior authorization improves outcomes.

Response: We disagree that the Electronic Prior Authorization measure conflicts with our goals and believe the policies we are finalizing in this rule are necessary to support a more efficient prior authorization process in the future. We believe this measure is entirely suitable for MIPS since the goal of MIPS is to provide financial incentives to clinicians that provide high-value and high-quality care to Medicare patients. MIPS supports care improvements by focusing on better patient outcomes and decreasing clinician burden. We believe that electronic prior authorization aligns with these goals, as it streamlines a historically burdensome process to allow providers to spend more time focused on improving patient outcomes instead of administratively burdensome processes.

We also believe that the Electronic Prior Authorization measure fits within the goals of the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category by enhancing the meaningful use of CEHRT. For the MIPS Promoting Interoperability performance category, section 1848(q)(2)(B)(iv) of the Act requires MIPS eligible clinicians to report on specified measures and activities demonstrating that they meet the requirements established under section 1848(o)(2) of the Act for determining whether the MIPS eligible clinician is a meaningful EHR user. For the Medicare Promoting Interoperability Program, section 1886(n) of the Act similarly requires eligible hospitals and CAHs to demonstrate that they meet requirements established under section 1886(n)(3)(A) (which align with section 1848(o)(2)(A) of the Act) for determining whether the eligible hospital or CAH is a meaningful EHR user. Electronic exchange of information to improve health care and care coordination is a central statutory requirement for both the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category.

We proposed this measure under sections 1848(o)(2)(A)(ii) and 1886(n)(3)(A)(ii) of the Act for MIPS and the Medicare Promoting Interoperability Program, respectively, because we believed, and continue to believe, this measure will further enable the electronic exchange of health information to improve the quality of health care (87 FR 76312). More specifically, we believe the proposed Electronic Prior Authorization measure, which we are finalizing with modifications, is fundamental to determining whether a MIPS eligible clinician, eligible hospital, or CAH meets criterion two of being a meaningful EHR user: demonstrating that their CEHRT is connected in a manner that provides for the electronic exchange of health information to improve the quality of health care, such as promoting care coordination (sections 1848(o)(2)(A)(ii) and 1886(n)(3)(A)(ii) of the Act). We believe the Electronic Prior Authorization measure is another means by which MIPS eligible clinicians, eligible hospitals, and CAHs, can use their health IT to timely and efficiently share key health information with payers to obtain prior authorizations promptly and thereby provide necessary health care to their patients expeditiously. Therefore, we believe the Electronic Prior Authorization measure does meet the intended goal of these programs to promote interoperability and electronically exchange health information.

Comment: Multiple commenters opposed the Electronic Prior Authorization measure stating that prior authorizations are a harmful practice that result in delays and denials of necessary care which can worsen a patient's condition. Several commenters shared concerns about payer prior authorization policies themselves. A commenter stated that prior authorizations lower the costs for payers but raise the overall cost of care by delaying care and shifting costs to providers and patients, thus worsening clinical outcomes which necessitates the escalation of more expensive care.

Response: We would like to thank commenters for their feedback regarding payers' prior authorization processes and the burden placed on patients and providers. We understand that some commenters expressed concerns about prior authorization itself, regardless of whether it could be completed electronically, and whether or not these existing prior authorization requirements support improved outcomes. We note that the existence and use of prior authorization processes is outside the scope of this rule. Our policies are limited to streamlining this already existing process.

The policies we are finalizing in this rule are not intended to encourage or discourage the prior authorization requirements that payers already have; these policies are intended to increase the efficiency of these existing requirements and processes by encouraging use of electronic methods. We understand that the existing prior authorization process can be burdensome, and thus believe the policies we are finalizing in this rule are necessary to support a more efficient prior authorization process in the future.

We received many comments on the December 2020 CMS Interoperability proposed rule, which has since been withdrawn, and in response to the CMS Interoperability and Prior Authorization proposed rule that indicated that prior authorization processes could be improved by electronic, interoperable data exchange. Those comments have informed the policies we are finalizing in this rule.

Comment: Multiple commenters stated that the Electronic Prior Authorization measure should not penalize LTCHs and Inpatient Rehabilitation Facilities (IRFs) for failing to use EHRs. Another commenter expressed that practices have many different technical and infrastructure capabilities; therefore, they recommended that CMS consider ways to further engage and support all provider types—especially safety-net, small/independent, and/or rural health providers—to adopt and use the Prior Authorization API. The commenter continued by stating that they are concerned that these providers are at risk of being left behind. Likewise, the commenter stated that CMS should also explore ways to expand provider incentives to reach broadly across the health care system to encourage widespread adoption of the Prior Authorization API. Another commenter recommended that CMS include all health care providers as recipients of the benefits of the final rule, whether they are recipients of Meaningful Use dollars or are participants in MIPS. The commenter continued by providing a possible scenario in which payers further delay decisions of excluded providers in favor of meeting the requirements for providers included under the provisions of the rule.

Response: We note that LTCHs and IRFs are not included in the definition of an eligible hospital or CAH (42 CFR 495.4 definitions, 75 FR 44327) and therefore would not be required to report the Electronic Prior Authorization measure under the Medicare Promoting Interoperability Program. We also understand that different practices have different technical and infrastructure capabilities. To the extent that these facilities or any provider type ordering items or services requiring prior authorizations have access to appropriate health IT and the Prior Authorization API and are otherwise permitted to use the Prior Authorization API, we encourage them to use this technology for their own benefit. Our proposals for the Prior Authorization API technology and functionality do not limit its use to participants under the MIPS Promoting Interoperability performance category and the Medicare Promoting Interoperability Program. We will continue to look for ways to encourage API implementation uptake and ways to incentivize the adoption of electronic prior authorization across additional programs and provider types, especially safety-net, small/independent, and rural health providers.

Additionally, we appreciate the comment regarding possible scenarios in which impacted payers further delay decisions on prior authorizations from providers not participating in MIPS or the Medicare Promoting Interoperability Program or not using the Prior Authorization API. However, to mitigate this, we are finalizing certain prior authorization decision timeframes for all impacted payers. We refer readers to section II.D. of this final rule for more information on the prior authorization decision timeframe provisions.

Comment: A commenter suggested that instead of developing the Electronic Prior Authorization measure, CMS should engage in stringent oversight to ensure that impacted payers are not only developing and implementing a Prior Authorization API but are also implementing all of the provisions of this final rule. The commenter also suggested that CMS should release additional information on how it will enforce the proposed requirements contained in the CMS Interoperability and Prior Authorization proposed rule to ensure compliance.

Response: As explained in the proposed rule, and in the CMS Interoperability and Patient Access final rule, each program oversees compliance under existing program authorities and responsibilities. These compliance processes vary among programs and may have different implications based on a payer's status in the program, previous compliance actions, and corrective action. Patients and providers should submit an inquiry or complaint to the appropriate program, depending on their coverage as described in section I.D.2. of this final rule. Compliance questions or complaints about compliance may be sent to the respective program contact at the website or email address provided there. Compliance will be tracked through specific methods managed by the programs. While these compliance efforts will help payer compliance, as we have stated repeatedly throughout this section, it is imperative that both payers and providers come together to use the Prior Authorization API to ensure that all parties can experience the maximum benefits of engaging in the electronic prior authorization process. Thus, we recognize the importance of not only requiring impacted payers to build the Prior Authorization API, but also to incentivize MIPS eligible clinicians, eligible hospitals, and CAHs to use it through the finalization of this Electronic Prior Authorization measure.

Comment: A commenter stated that CMS lacks a legitimate justification for imposing the new Electronic Prior Authorization measure, as it does not align with the legal requirements under section 1848(q) of the Act. The commenter sought clarification on how the proposed measure complies with the governing regulations.

Response: We have authority under section 1848(q)(2)(A)(iv) and (B)(iv) of the Act, which requires that we assess MIPS eligible clinicians' performance with respect to their meaningful use of CEHRT in accordance with the requirements established in section 1848(o)(2) of the Act. We also have authority under section 1848(q)(2)(B)(iv) of the Act to create new measures under the MIPS Promoting Interoperability performance category as well as for determining whether an eligible professional is a meaningful EHR user in accordance with the requirements established in section 1848(o)(2) of the Act. Connecting to the API technology identified in the Electronic Prior Authorization measure helps to facilitate bi-directional data exchange electronically and can significantly reduce the burden associated with the prior authorization processes for providers using data from CEHRT when accessing the Prior Authorization API. This type of function demonstrates meaningful use of CEHRT and is therefore appropriate in assessing whether a MIPS eligible clinician is a meaningful EHR user under section 1848(o)(2)(A) of the Act.

Comment: A commenter requested that CMS use its authority to permit payers to include quality measures tied to use of the APIs in the provider contracts.

Response: We appreciate the commenter's recommendation. However, we leave this decision—whether payers require measures like this for their providers and how they work with their providers on using the Prior Authorization API—up to the discretion of the payers.

a. Measure Specifications

In the proposed rule (87 FR 76313), we proposed the following specifications for the Electronic Prior Authorization measure:

1. For MIPS Eligible Clinicians Under the MIPS Promoting Interoperability Performance Category—Electronic Prior Authorization

• Measure Description: For at least one medical item or service (excluding drugs) ordered by the MIPS eligible clinician during the performance period, the prior authorization is requested electronically from a Prior Authorization API using data from CEHRT.

The MIPS eligible clinician would be required to report a numerator and denominator for the measure or (if applicable) report an exclusion:

• Denominator: The number of unique prior authorizations requested for medical items and services (excluding drugs) ordered by the MIPS eligible clinician during the performance period, excluding prior authorizations that cannot be requested using the Prior Authorization API because the payer does not offer an API that meets the Prior Authorization API requirements outlined in section II.D.3.a. of the CMS Interoperability and Prior Authorization proposed rule.

• Numerator: The number of unique prior authorizations in the denominator that are requested electronically from a Prior Authorization API using data from CEHRT.

• Exclusion: Any MIPS eligible clinician who:

(1) Does not order any medical items or services (excluding drugs) requiring prior authorization during the applicable performance period; or

(2) Only orders medical items or services (excluding drugs) requiring prior authorization from a payer that does not offer an API that meets the Prior Authorization API requirements outlined in section II.D.3.a. of the CMS Interoperability and Prior Authorization proposed rule during the applicable performance period.

2. For Eligible Hospitals and Critical Access Hospitals Under the Medicare Promoting Interoperability Program—Electronic Prior Authorization

• Measure Description: For at least one hospital discharge and medical item or service (excluding drugs) ordered during the EHR reporting period, the prior authorization is requested electronically via a Prior Authorization API using data from CEHRT.

The eligible hospital or CAH would be required to report a numerator and denominator for the measure or (if applicable) report an exclusion:

• Denominator: The number of unique prior authorizations requested for medical items and services (excluding drugs) ordered for patients discharged from the eligible hospital or CAH inpatient or emergency department (POS code 21 or 23) during the EHR reporting period, excluding prior authorizations that cannot be requested using the Prior Authorization API because the payer does not offer an API that meets the Prior Authorization API requirements outlined in section II.D.3.a. of the proposed rule.

• Numerator: The number of unique prior authorizations in the denominator that are requested electronically from a Prior Authorization API using data from CEHRT.

• Exclusions: Any eligible hospital or CAH that—

++ Does not order any medical items or services (excluding drugs) requiring prior authorization during the applicable EHR reporting; or

++ Only orders medical items or services (excluding drugs) requiring prior authorization from a payer that does not offer an API that meets the Prior Authorization API requirements outlined in section II.D.3.a. of the proposed rule during the applicable EHR reporting period.

Comment: Multiple commenters expressed support for CMS's proposal regarding the proposed Electronic Prior Authorization measure's numerator and denominator criteria. Specifically, a commenter agreed with the numerator being the number of unique prior authorizations that are requested electronically via a Prior Authorization API using data from CEHRT if the Electronic Prior Authorization measure includes electronic prior authorizations from commercial payers. A commenter recommended that CMS ask for the percentage of prior authorization requests that are not being completed through the Prior Authorization API. Another commenter supported CMS's proposal to include prior authorization requests that are made using fax, mail, or portal in the denominator of the Electronic Prior Authorization measure unless the prior authorization cannot be requested using the Prior Authorization API because the payer does not offer an API that meets the Prior Authorization API requirements, in which case it would be excluded from the denominator. A commenter expressed support for CMS progressing the proposed Electronic Prior Authorization measure to a performance-based measure in future years.

Response: We thank the commenters for their feedback and appreciate their support for the numerator and denominator criteria for the Electronic Prior Authorization measure for the MIPS Promoting Interoperability performance category and the Medicare Promoting Interoperability Program. We agree that requiring participants to report a numerator and denominator for the measure would ultimately give us the most insight into the degree of adoption and use of the Prior Authorization API. However, after consideration of comments received, and as discussed in more detail later in this section, we are modifying the specifications of the Electronic Prior Authorization measure to require an attestation (yes/no), in lieu of reporting data for a numerator and denominator as proposed, for this measure beginning with the CY 2027 performance period/2029 MIPS payment year for MIPS and the CY 2027 EHR reporting period for the Medicare Promoting Interoperability Program.

Comment: A commenter suggested that CMS explore different mechanisms for tracking electronic prior authorization requests. A few commenters also noted that tracking these data elements should be the responsibility of payers, as they would have this information more easily accessible. Another commenter stated that CMS needs to determine an approach to measure the usage of electronic prior authorization tools that does not require collecting information about the availability of corresponding APIs or functionality. Another commenter stated that measuring the success of these policies should not be punitive for providers and that the metrics of success should exist for all stakeholders. Multiple commenters urged CMS to work with the provider community, as well as other stakeholders, on various aspects of the Electronic Prior Authorization measure as well as other prior authorization reforms to identify ways to incentivize provider uptake without creating unnecessary provider burden and determine how to engage providers in the testing and development of the proposed Electronic Prior Authorization measure. Another commenter noted that the technology supporting electronic prior authorization must be widely available and demonstrated to be effectively integrated into EHR workflows through real-world testing prior to requiring MIPS eligible clinicians, eligible hospitals, and CAHs to report on use of the Prior Authorization API for the Electronic Prior Authorization measure. A commenter suggested that CMS should require payers to provide these data on electronic prior authorization, rather than place increasing demands on providers.

Response: We thank the commenters for their recommendations. We will consider exploring additional mechanisms for tracking electronic prior authorization requests in future rulemaking. We believe that tracking the use of electronic prior authorization processes by impacted payers and providers (that is, MIPS eligible clinicians, eligible hospitals, and CAHs) is important to ensure widespread implementation and use of the Prior Authorization API by both user groups. In this context, we view the Electronic Prior Authorization measure not merely as a way to track performance or success. Instead, we view this measure as a way for MIPS eligible clinicians, eligible hospitals, and CAHs to adopt and use the electronic Prior Authorization APIs implemented by payers. As we have noted previously, payers impacted by this rule are required to implement and maintain the Prior Authorization API. To fully recognize the benefits and efficiencies of payer implementation of this API, we need to encourage providers to use said API to complete prior authorization requests. While we are encouraged by commenters' statements that the benefits of the Prior Authorization API are enough to encourage providers to use it, we also believe that accessing this API using data from CEHRT demonstrates meaningful use of CEHRT that can improve patient care under sections 1848(o)(2)(A) and 1886(n)(3)(A) of the Act, and thus believe this measure is appropriate to incentivize providers to adopt and use this technology. We refer readers to section II.D. of this rule where we discuss in further detail the metrics impacted payers will be required to report on electronic prior authorizations.

We note that we do not currently use established workgroups to test and develop measures for the Medicare Promoting Interoperability Program or the MIPS Promoting Interoperability performance category outside of our annual call for measures. We do work with members of the provider community in HL7 workgroups to obtain their feedback during the development and testing phases of the IGs that support the Prior Authorization API, as well as during discussions around technical workflow. We encourage providers to engage in the HL7 FHIR workgroup meetings to get involved in the standards development and implementation discussions for specific use cases. The IGs are also tested during Connectathons and throughout the IG development lifecycle and refined based on testing and implementation feedback. We have also previously reviewed public comments received on the Reducing Burden and Improving Electronic Information Exchange of Prior Authorizations RFI (85 FR 82639) and December 2020 CMS Interoperability proposed rule (85 FR 82586) regarding ways in which we could incentivize and encourage provider use of the electronic Prior Authorization API and used that feedback to develop our policies outlined in this final rule.

Comment: Multiple commenters expressed their disapproval of the proposed Electronic Prior Authorization measure's numerator and denominator criteria. Numerous commenters stated that the Electronic Prior Authorization measure as proposed would create significant data collection and reporting burden on MIPS eligible clinicians, eligible hospitals, CAHs, and support staff. Many commenters specifically identified the excessive burden with calculating the denominator. Multiple commenters expressed concern regarding identifying which prior authorization requests meet the denominator requirements of the proposed Electronic Prior Authorization measure (for example, which payers offer a Prior Authorization API or how a provider will be able to determine the number of prior authorization requests that should be counted in the denominator) making this measure particularly burdensome, contributing to provider burnout, and causing further delays in care. A commenter sought clarification on whether CMS is considering alternatives to the proposed numerator and denominator measure criteria and requested changes to these specifications that would reduce the implementation burden for both providers and health IT developers.

Some commenters expressed concern regarding compliance and documentation for the proposed Electronic Prior Authorization measure. Commenters stated that providers submit prior authorizations in a variety of modalities and noted it will be hard to track all prior authorizations submitted. Other commenters expressed similar concerns given that data surrounding prior authorizations are captured outside of an EHR, which would make the data collection process extremely burdensome.

Several commenters urged CMS not to implement the Electronic Prior Authorization measure as proposed due to these concerns or consider ways the measure could be implemented without increasing provider burden. A commenter recommended that CMS continue to evaluate the numerator and denominator proposals and adjust the requirements based on real-world testing. Another commenter questioned why CMS would create a numerator/denominator measure that is not automatically calculated by EHRs. The commenter continued by stating that several EHR vendors will likely not have the capability to assist in tracking prior authorization requests for reporting purposes. Another commenter disagreed with the proposed measure criteria to collect information on the total number of prior authorization requests submitted by the Prior Authorization API versus other request methods given that collecting these data does nothing to improve patient clinical outcomes. Therefore, multiple commenters recommended that CMS should use an attestation (yes/no) measure and remove the proposed numerator/denominator criteria.

Response: We appreciate the commenters sharing their concerns regarding the burden associated with calculating a numerator and denominator as proposed for the Electronic Prior Authorization measure. Generally, we proposed that to report these measures, MIPS eligible clinicians, eligible hospitals, and CAHs must use data from their CEHRT to request prior authorization from a payer for at least one medical item or service (excluding drugs), and, for eligible hospitals and CAHs, one hospital discharge and medical item or service that they ordered via the Prior Authorization API (87 FR 76313). However, we recognize that the challenge of consistently calculating a numerator and denominator for these proposed measures across providers increases if providers are accessing the Prior Authorization API in different ways. We further recognize that it would be challenging for MIPS eligible clinicians, eligible hospitals, and CAHs to report a numerator and denominator for these measures as we proposed until such time as the ONC Health IT Certification Program establishes health IT certification criteria to support standardized exchange via the Prior Authorization API and adopts updated certification criteria supporting numerator and denominator calculation.

We acknowledge that modifying the Electronic Prior Authorization measure to be attestation-based would substantially reduce the reporting burden placed on MIPS eligible clinicians, eligible hospitals, and CAHs. With an attestation-based yes/no measure, those providers would be required to report a yes/no response, rather than a numerator and denominator, to indicate whether they used a Prior Authorization API to submit at least one electronic prior authorization during the applicable performance period/MIPS payment year or EHR reporting period. After consideration of this feedback, and as discussed in more detail later in this section, we are modifying the Electronic Prior Authorization measure to be an attestation measure, meaning that MIPS eligible clinicians, eligible hospitals, and CAHs will report a yes/no response for the measure. We will continue to explore ways to move toward numerator and denominator reporting for future years of the measure, particularly should ONC Health IT Certification Program criteria be made available to support certification of EHRs to the capability associated with tracking prior authorizations requested electronically via the Prior Authorization API using data from CEHRT.

Comment: A commenter stated that the Electronic Prior Authorization measure should not be restricted only to items and services but should also include drugs to provide consistency across prior authorization needs.

Response: As discussed earlier in this final rule, the Prior Authorization API requirements we have finalized for impacted payers are limited to medical items and services (excluding drugs). Therefore, for consistency, we are aligning using the API for the Electronic Prior Authorization measure to limit it to evaluating using a Prior Authorization API for medical items and services authorization requests only. We refer readers to section II.D. for additional information on the Prior Authorization API requirements for impacted payers and the exclusion of drugs.

Comment: A commenter stated that industry would need to review and endorse the specification criteria prior to requiring the Electronic Prior Authorization measure.

Response: We thank commenters for this suggestion; however, we must note that there is no requirement for industry to review or endorse measures in either the MIPS Promoting Interoperability performance category or the Medicare Promoting Interoperability Program. We welcome comments from any interested parties through public comment during rulemaking, and also during the annual call for measures for the MIPS Promoting Interoperability performance category and the Medicare Promoting Interoperability Program, every summer.

Comment: Multiple commenters expressed concern that MIPS eligible clinicians, eligible hospitals, and CAHs will not have the necessary health IT to support the Prior Authorization API and therefore will not be able to report the proposed Electronic Prior Authorization measure by the proposed implementation year of CY 2026. Multiple commenters urged CMS to delay mandating the proposed Electronic Prior Authorization measure until adequate standards and specifications are available to support electronic prior authorization, the Prior Authorization API is implemented, and workflow is established. A commenter stated that providers should have the flexibility to stage their adoption, as recognized in the Electronic Prior Authorization measure proposal, to support a smooth transition from the current, manual process to a fully electronic workflow. Another commenter suggested that CMS needs to provide eligible hospitals with adequate time to convert their current processes into an electronic prior authorization process prior to implementing the Electronic Prior Authorization measure under the Medicare Promoting Interoperability Program. The commenter expressed their concern that this transition to a new electronic process will allow cases to fall through the cracks.

Response: We thank the commenters for their feedback. After reviewing comments for both the Prior Authorization API and for using that API in this Electronic Prior Authorization measure, we reconsidered our proposal and agree that provision of additional time for implementation would be beneficial. As previously discussed, we understand that there may be challenges with the availability of health IT to calculate a measure numerator and denominator consistently for the Electronic Prior Authorization measures as we originally proposed. We also believe the functionality of the Prior Authorization API should be in place and used by hospitals and providers prior to requiring a numerator and denominator be reported. We will continue to work with ONC to explore the adoption of standards and health IT certification criteria where appropriate to streamline data exchange, support interoperability, and increase efficiencies associated with the policies in this final rule. As noted previously, the Unified Agenda, current at the time of this final rule's publication, includes an entry for a proposed rule from ONC (RIN 0955–AA06). The description indicates that that proposed rule aims to advance interoperability, including proposals to expand the use of certified APIs for electronic prior authorization.

As previously discussed, we are finalizing the Electronic Prior Authorization measure with modification, to delay implementation for a year later than originally proposed, beginning with CY 2027 performance period/2029 MIPS payment year for MIPS eligible clinicians in the MIPS Promoting Interoperability performance category, and beginning with the CY 2027 EHR reporting period for eligible hospitals and CAHs under the Medicare Promoting Interoperability. This modification also aligns with the finalized compliance dates in 2027 for the Prior Authorization API. Also, as previously discussed, we are finalizing the Electronic Prior Authorization measure with modification as an attestation (yes/no) measure, instead of requiring reporting of data for a numerator and denominator. We believe this modification will minimize data collection and reporting burden for this measure.

Comment: Many commenters recommended that the Electronic Prior Authorization measure be an attestation (yes/no) measure to mitigate provider burden if CMS moves forward with the proposed measure. Some commenters stated that they are not opposed to the Electronic Prior Authorization measure and appreciated CMS not scoring it initially. However, a commenter noted there may be implementation challenges due to eligible hospitals and CAHs still recovering from the PHE and not having enough resources to implement. Another commenter suggested that the Electronic Prior Authorization measure remain unscored indefinitely. The commenter noted that the Prior Authorization API still being in the pilot testing phase is an additional challenge. Another commenter expressed their appreciation for the implementation timeline of the Electronic Prior Authorization measures stating that it would allow for technical implementation, provider implementation, and education. Multiple commenters were displeased with the proposed scoring methodology for the Electronic Prior Authorization measure. Multiple commenters recommended that CMS consider making the Electronic Prior Authorization measure voluntary or award bonus points for the proposed Electronic Prior Authorization measure rather than including the measure in the composite score. A commenter stated that an attestation (yes/no) measure would align the proposed Electronic Prior Authorization measure with the other measures within the HIE objective.

Response: We appreciate the commenters' concerns and recommendations on ways to ease burden by making the Electronic Prior Authorization measure an attestation (yes/no) measure. We agree and acknowledge that it would significantly reduce the reporting burden for MIPS eligible clinicians, eligible hospitals, and CAHs if we did not require a numerator and denominator to be calculated, and instead require only a “yes” or “no” response be reported to indicate whether the Prior Authorization API was used for at least one prior authorization during the applicable performance period/MIPS payment year or EHR reporting period. After consideration of this feedback, and as discussed in more detail elsewhere in this section, we are modifying the proposed Electronic Prior Authorization measure to be reported as an attestation (yes/no) measure.

We appreciate the commenters' recommendations for scoring this measure, such as not scoring the measure or only assigning bonus points. However, we respectfully disagree with these approaches. First, we did not propose to score this measure by assigning points (for example, between 10 and 30 points for successful completion as provided at 42 CFR 414.1380(b)(4)(ii) for MIPS). However, we did propose that a MIPS eligible clinician, eligible hospital, or CAH would “receive a zero score for the MIPS Promoting Interoperability performance category or the Medicare Promoting Interoperability Program” if they did not “report a numerator of a least one for the measure or claim an exclusion” (87 FR 76313). In other words, we proposed that if a MIPS eligible clinician, eligible hospital, or CAH failed to request at least one prior authorization electronically via the Prior Authorization API using data from their CEHRT, as would be required to report a numerator under the originally proposed measure specifications (attesting “no” to the measure), or claim an applicable exclusion, then they would not meet the minimum reporting requirements, not be considered a meaningful EHR user, and fail the Medicare Promoting Interoperability Program or the Promoting Interoperability performance category. A failure in the Medicare Promoting Interoperability Program would result in a downward payment adjustment for eligible hospitals or CAHs (unless the eligible hospital or CAH receives a hardship exception). A failure in the MIPS Promoting Interoperability performance category would result in the MIPS eligible clinician receiving a score of zero for the performance category, which is currently worth 25 percent of their final score for MIPS.

Second, we clarify our rationale for proposing this scoring policy of zero for this measure, which we are finalizing with modification to align with the attestation-based measure specifications we are finalizing in this section. Fundamentally, a MIPS eligible clinician, eligible hospital, or CAH must demonstrate it is a meaningful EHR user by meeting three statutory criteria set forth in sections 1848(o)(2)(A) and 1886(n)(3)(A) of the Act, to earn a score for the MIPS Promoting Interoperability performance category (section 1848(q)(2)(B)(iv) of the Act) or avoid a downward payment adjustment for the Medicare Promoting Interoperability Program. We proposed this measure under sections 1848(o)(2)(A)(ii) and 1886(n)(3)(A)(ii) of the Act for MIPS and Medicare Promoting Interoperability Program, respectively, because we believed, and continue to believe, this measure would further enable the electronic exchange of health information to improve the quality of health care (87 FR 76312). More specifically, we believe the proposed Electronic Prior Authorization measure, which we are finalizing with modification, is fundamental to determining whether a MIPS eligible clinician, eligible hospital, or CAH meets criterion two of being a meaningful EHR user: demonstrating that their CEHRT is connected in a manner that provides for the electronic exchange of health information to improve the quality of health care, such as promoting care coordination (sections 1848(o)(2)(A)(ii) and 1886(n)(3)(A)(ii) of the Act). A MIPS eligible clinician, eligible hospital, or CAH using the Prior Authorization API to request at least one prior authorization electronically for, or claiming an applicable exclusion from, reporting this measure, fundamentally demonstrates that they are a meaningful EHR user. Therefore, we believe that failure to report the Electronic Prior Authorization measure as specified, or to claim an applicable exclusion, demonstrates they are not a meaningful EHR user and warrants the MIPS eligible clinician, eligible hospital, or CAH receiving a score of zero for the MIPS Promoting Interoperability performance category or Medicare Promoting Interoperability Program.

After consideration of public comments we received, we are finalizing a modification to our proposal that the Electronic Prior Authorization measure will require MIPS eligible clinicians, eligible hospitals, and CAHs to report a numerator and denominator, and instead, require that MIPS eligible clinicians, eligible hospitals, and CAHs attest “yes” or “no” to having performed at least one electronic prior authorization using the Prior Authorization API, or claim an applicable exclusion. We are also finalizing that, if a MIPS eligible clinician, eligible hospital, or CAH attests “no” or fails to claim an applicable exclusion for this measure, then they will receive a zero score for the MIPS Promoting Interoperability performance category (currently worth 25 percent of their final score for MIPS) or fail to meet Medicare Promoting Interoperability Program reporting requirements. To allow for additional implementation time, we are finalizing inclusion of the Electronic Prior Authorization measure in the MIPS Promoting Interoperability performance category beginning with the CY 2027 performance period/2029 MIPS payment year and in the Medicare Promoting Interoperability program beginning with the CY 2027 EHR reporting period.

Comment: Some commenters expressed concerns that providers may be unfavorably evaluated or unfairly penalized for infrastructure and system issues or lack of capabilities and not the providers' willingness or desire to conduct electronic prior authorizations. A commenter requested clarification on the proposed measure exclusion criteria applying only to medical items and services (excluding drugs) requiring prior authorization from a payer that does not offer a Prior Authorization API, questioning whether this exclusion would lead to unintended consequences.

Response: We recognize that these capabilities may not yet be widely adopted in some settings, and that successful implementation of these capabilities may vary across providers and systems. We note that we are finalizing that the Electronic Prior Authorization measure would be reported as an attestation (yes/no) measure, as opposed to the proposed numerator and denominator, which should reduce some of the initial implementation challenges. We are also finalizing that the measure would first be reportable beginning with the CY 2027 performance period/2029 MIPS payment year and CY 2027 EHR reporting period. This delayed implementation will give both providers (that is, MIPS eligible clinicians, eligible hospitals, and CAHs) and payers time to implement these changes to workflows and establish integrations prior to the measure reporting being required.

We believe electronic prior authorization capabilities represent an important investment that will benefit providers, patients, and other health care system entities. We note that some payers do not fall under the definition of impacted payers in this final rule. Therefore, we are finalizing the measure's exclusion criterion (excluding MIPS eligible clinicians, eligible hospitals, and CAHs that only order medical items or services [excluding drugs] requiring prior authorization from a payer that does not offer an API that meets the Prior Authorization API requirements finalized in this final rule) because we do not want to penalize MIPS eligible clinicians, eligible hospitals, or CAHs for ordering medical items or services (excluding drugs) from payers that do not have the API functionality for reasons such as not being an impacted payer.

Comment: A commenter stated that they oppose measures that could negatively impact a MIPS eligible clinician's score, such as the current all-or-nothing scoring methodology used to score the MIPS Promoting Interoperability performance category. Another commenter stated their belief that the proposed rule lacks detail on how the Electronic Prior Authorization measure will be scored and tied into the broader scoring of the Medicare Promoting Interoperability Program for eligible hospitals and CAHs.

Response: We note that the overall scoring methodology for MIPS Promoting Interoperability performance category is not being changed with the addition of the Electronic Prior Authorization measure, nor the scoring methodology for the HIE measure itself. As discussed previously in this section, we believe that failure to report the Electronic Prior Authorization measure as specified, or to claim an applicable exclusion, demonstrates that the MIPS eligible clinicians is not a meaningful EHR user and warrants the MIPS eligible clinician receive a score of zero for the MIPS Promoting Interoperability performance category. While we understand that the all-or-nothing approach requires MIPS eligible clinicians to report and attest to all requirements, we note that requiring the Electronic Prior Authorization measure is in alignment with our scoring policies and methodologies. Our regulation at 42 CFR 414.1375(b) provides that, to earn a score for the MIPS Promoting Interoperability performance category, the MIPS eligible clinician must report on objectives and associated measures as specified by CMS.

For additional information on overall MIPS scoring policies and MIPS Promoting Interoperability performance category scoring policies, we refer readers to our regulations at 42 CFR 414.1375 (governing the requirements for the MIPS Promoting Interoperability performance category), 42 CFR 414.1380 (governing scoring for MIPS), as well as Table 46: Scoring Methodology for the Performance Period in CY 2024 for the Promoting Interoperability performance category in the CY 2024 PFS final rule (88 FR 52587). For information on the overall scoring methodology currently used to calculate MIPS final scores, we refer readers to the MIPS Final Score Methodology section in the CY 2024 PFS final rule (88 FR 52591).

To be considered a meaningful EHR user, fulfill the minimum reporting requirements, and avoid a downward payment adjustment, the Medicare Promoting Interoperability Program requires that eligible hospitals and CAHs meet, by reporting on or attesting to, all objectives and measures selected by CMS. Failure to meet the minimum reporting requirements results in failure of the Medicare Promoting Interoperability Program, subjecting the eligible hospital or CAH to a downward payment adjustment (unless the eligible hospital or CAH receives a hardship exception).

b. Prior Authorization API Functionality

In the proposed rule (87 FR 76313), we proposed that a prior authorization request must be made using the Prior Authorization API to satisfy the Electronic Prior Authorization measure. The Prior Authorization API functionality is outlined in further detail in section II.D.2. of this final rule. We proposed that prior authorization requests that are made using fax, mail, or portal would be included in the denominator of the measure unless the prior authorization cannot be requested using the Prior Authorization API because the payer does not offer an API that meets the Prior Authorization API requirements, in which case any such prior authorization request would be excluded from the denominator. Instances where a payer offering the Prior Authorization API specifically requests a mailed or faxed prior authorization would be included in the denominator. Prior authorization requests that are made using fax, mail, or portal would not be included in the numerator of the measure because these methods would not incentivize using the standards-based API functionality as intended by the measure. Prior authorizations for any and all drugs would be excluded from both the numerator and denominator of the measure. (For a more detailed discussion of the exclusion of drugs, see section I.C. of this final rule.)

We proposed that only prior authorizations that are requested electronically via a Prior Authorization API using data from CEHRT would be included in the numerator. Using the API to query documentation requirements alone, and not to request the prior authorization, would not count in the numerator or denominator.

To satisfy the Electronic Prior Authorization measure, the health care provider uses data from their CEHRT (such as patient demographics and medical information) to justify the prior authorization request. The Prior Authorization API then automates the HIPAA-compliant prior authorization request. Additional information not contained in CEHRT may also be required for submission.

Comment: Multiple commenters urged CMS to delay mandating the proposed Electronic Prior Authorization measure until adequate standards and specifications are available to support electronic prior authorization and until the Prior Authorization API workflow is established. A commenter urged CMS to evaluate whether sufficient implementation guidance exists to support automating data retrieval before moving to require the Electronic Prior Authorization measure in future years. Some commenters noted that CMS must ensure that the desired standards outlined in the Electronic Prior Authorization measure specification are achievable. Another commenter recommended that CMS make all IGs required for payers so the burden is not placed on providers to figure out something that will be incredibly difficult and resource-intensive to do. Another commenter recommended that CMS or ONC should issue an IG to ensure there is standardization of implementation across payers. The commenter stated that IGs could reduce payer variability in the creation of the Prior Authorization API. Another commenter sought clarification on how it will be feasible for CEHRT to implement an API-based prior authorization functionality to support performance measurement if payers are not required to adhere to standardized IGs. The commenter stated that for this to occur seamlessly CEHRT standards would need to be updated appropriately.

Response: We thank the commenters for sharing their recommendations. We are working with HL7, the HL7 FHIR accelerator workgroups, and interested parties within the standards development industry to move the IGs towards greater maturity by defining technical specifications, participating in and convening testing events for them, and developing and maintaining the technical specifications. Electronic prior authorization using a FHIR API has been implemented and is in production, proving sufficient implementation guidance exists. We agree that IGs help to ensure standardization of implementation across the industry. In section II.G. of this final rule, we outline the required standards and technical specifications necessary to build the Prior Authorization API and to ensure that implementation is consistent across all impacted payers and providers to avoid unnecessary duplication of efforts. We have also recommended certain IGs to help providers and payers meet that requirement. These IGs are developed using a consensus process involving many members of the payer and provider communities. They aid in the implementation process of the APIs. We anticipate that payers will use the recommended IGs so that most, if not all, providers benefit from a standardized approach to accessing patient data with all payers with whom they contract. Our approach in the proposed rule of recommending, but not requiring, the specific IGs for each API implementation was to provide directional guidance with flexibility to the industry without locking implementers into the versions available at the time of the proposed rule. As industry moves forward with implementation of these policies and use of these standards, industry can continue to harmonize on common approaches that work, eventually culminating in a required set of specifications when ready.

Comment: A commenter recommended that CMS explain that the electronic prior authorization workflow does not necessarily need to be completed by the provider and that such workflows do not necessarily need to be included in CEHRT. The commenter recommended that CMS emphasize that only using data from CEHRT as part of the process for requesting prior authorization via a payer's Prior Authorization API is sufficient to meet the Electronic Prior Authorization measure. Another commenter suggested that CMS should consider not limiting the Electronic Prior Authorization measure to only data relevant to a prior authorization that is obtained from an EHR as relevant prior authorization data may not be limited to the provider's EHR alone. A commenter stated that certain health insurance data, clinical data, and other administrative data subject to follow-up requests or initial submissions may exist in non-EHR systems in use. The commenter stated that this further underscores the premise that any health IT developer wishing its health IT to be certified must support all USCDI in its health IT. The commenter stated that USCDI as a driver to enable standards-based exchange is increasingly less relevant and, instead, the various IGs would indicate what participating systems should support. A commenter requested clarification on the expectations for incorporating such workflows into the Medicare Promoting Interoperability Program. The commenter sought clarification on whether eligible hospitals are expected to begin to share prior authorization information via the integrations with HINs to meet the bi-directional HIE measure. Multiple commenters encouraged the use of HIEs to connect impacted payers and providers to facilitate electronic prior authorization. A commenter stated that HIEs could provide support for continuing to connect providers and payers, including for the purposes of prior authorization. Another commenter recommended that CMS should include an optional, alternative measure that allows MIPS eligible clinicians, eligible hospitals, and CAHs to claim a Promoting Interoperability credit by attesting to using a HIE/HIN to request a prior authorization. Another commenter recommended that CMS create a health IT activity as part of the HIE Objective for mapping to a Prior Authorization API that is measured by the transmission of at least one prior authorization through the Prior Authorization API.

Response: We did not propose, and are not finalizing, details of a specific workflow, or by whom, that must be completed to report the Electronic Prior Authorization measure beyond specifying that data from CEHRT must be used for the transaction with a Prior Authorization API. CMS recognizes that, under the Electronic Prior Authorization measure that we are finalizing in this rule, MIPS eligible clinicians, eligible hospitals, and CAHs may utilize different workflows to submit an electronic prior authorization request. As noted, the Unified Agenda, current at the time of publication of this final rule, includes an entry for a proposed rule from ONC entitled “Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability” (RIN 0955–AA06). The description for this proposed rulemaking notes that this rule aims to advance interoperability through proposals for the expanded use of certified APIs for electronic prior authorization, among other proposals. We plan to continue to explore how potential future updates to the ONC Health IT Certification Program can support our policies and will address any updates to our requirements related to these future updates to the ONC Health IT Certification Program criteria if finalized, in future rulemaking. In reference to the USCDI, we note that health IT modules may be certified to only one or a few certification criteria that do not reference the USCDI standard, and therefore are not all required to support USCDI.

With regard to workflows, there is no requirement under the MIPS Promoting Interoperability performance category or the Medicare Promoting Interoperability Program that a specific individual person must request prior authorization electronically via the Prior Authorization API to meet requirements of the Electronic Prior Authorization measure. Instead, it can be someone who legally can enter information into the medical record in accordance with applicable laws and professional guidelines. Regarding the measure's specifications, we emphasize that data must come from the CEHRT, as use of CEHRT is a required element of both the MIPS Promoting Interoperability performance category and the Medicare Promoting Interoperability Program. However, additional data outside of CEHRT may also be used in addition to support the interaction with a Prior Authorization API.

Regarding the USCDI, we note that this standard is referenced in many of the IGs recommended for these use cases, however, the relative utility, in the abstract, of USCDI as a standard adopted for use in certified health IT and cross referenced in certain ONC Health IT Certification Program criteria is outside the scope of this final rule. We also note that we did not propose and are not finalizing a requirement under the MIPS Promoting Interoperability performance category or the Medicare Promoting Interoperability Program to share prior authorization information via the integrations with HINs to meet the Bi-Directional HIE measure. Additionally, we thank commenters for their recommendations on additional measures to promote electronic prior authorization. CMS reiterates that to meet the requirements of the Electronic Prior Authorization measure, the electronic prior authorization must use a Prior Authorization API as finalized in this rule. CMS agrees that using HIEs and other HINs could help to facilitate sharing of prior authorization information. Nothing in the Electronic Prior Authorization measures we are finalizing would restrict using such networks as long as the payer's Prior Authorization API is used for the electronic prior authorization.

Comment: A commenter sought clarification on whether a provider must implement capabilities to connect to all parts of the Prior Authorization API for full automation of the electronic prior authorization processing in order to claim numerator credit. Another commenter questioned whether a provider meets the numerator criteria if they use the Prior Authorization API that does not meet all the capabilities outlined in the recommended HL7 Da Vinci CRD, DTR, and PAS IGs. Another commenter requested clarification regarding whether a MIPS eligible clinician using the Prior Authorization API to submit a prior authorization request is not required to use all capabilities (that is, CRD, DTR, and PAS) in order to meet the numerator qualification, but rather that, at a minimum, the PAS IG request is used.

Response: We thank the commenters for their feedback and note that we are finalizing this measure with modification to no longer require MIPS eligible clinicians, eligible hospitals, and CAHs to report a numerator and denominator for the measure. Instead, we are finalizing this measure to require MIPS eligible clinicians, eligible hospitals, and CAHs to attest a “yes” or “no” response for the measure or claim an applicable exclusion. In order to attest “yes,” for at least one medical item or service (excluding drugs) and, for eligible hospitals and CAHs, for one hospital discharge ordered during the performance period or EHR reporting period, a prior authorization request must be submitted to a payer using a Prior Authorization API. We note that to report a “yes,” the action of the measure must occur during the selected performance period or EHR reporting period, as per the measure specification. The Prior Authorization API is discussed in more detail in section II.D. of this final rule, and we note that the submission of the prior authorization request itself is described through the recommended PAS IG.

Comment: Some commenters stated that certain EHR systems are more sophisticated than others and could track Prior Authorization API activity, while other hospitals and providers lack this technology. A commenter sought clarification on how a provider can use their EHR to identify situations where the prior authorization cannot be requested via a payer's Prior Authorization API for the purposes of performance measurement. A commenter stated that some provider systems do not support one or more payer APIs due to slight differences in structure, interpretation, or both, which could result in the provider being penalized due to an EHR system's lack of capability and not the provider's lack of desire to use the Prior Authorization API. A commenter noted that the Electronic Prior Authorization measure would be counterproductive to ONC's strategy of reducing burden related to using health IT and EHRs and that there should be near-zero reporting burden. Multiple commenters noted that there will be technical and financial challenges with adopting an electronic prior authorization process. Some commenters recommended that CMS should provide financial and technical assistance/training to providers to adopt and implement the technology requirements. The commenter noted that some provider types, such as physical therapists, are ineligible to participate in the Medicare and Medicaid EHR Incentive Programs and have received little guidance on using EHR systems. A commenter stated that CMS should acknowledge the significant financial and administrative risk providers face when purchasing EHR systems in the context of MIPS. A commenter noted that many health IT vendors currently charge separately for electronic prior authorization functionality and the cost associated with purchasing these functionalities has been a substantial barrier to adoption for many small and independent practices, as well as rural hospitals. Some commenters noted the financial burden associated with using APIs and that practices must first be able to affordably adopt this technology before a new requirement is established for its use.

Response: We acknowledge there will be variability in EHR technology capabilities to track Prior Authorization API activity. As noted previously, for this reason and to reduce reporting burden, we are finalizing the Electronic Prior Authorization measure as an attestation (yes/no) measure. As noted, ONC has sought comment on how updates to the ONC Health IT Certification Program could support electronic prior authorization (87 FR 3475). We also note that the Unified Agenda, current at the time of publication of this final rule, has been updated to include an entry for a proposed rule from ONC (RIN 0955–AA06) that includes proposals for the expanded use of certified APIs for electronic prior authorization. We will monitor these developments in order to inform updates to the Electronic Prior Authorization measure in the future, for instance, requiring reporting of a numerator and denominator.

While we acknowledge there may be costs associated with implementing functionality needed to interact with a payer's Prior Authorization API, as well as add-on costs charged by health IT vendors for adding these features, we believe that the benefits of the technology outweigh the costs. We also remind readers that this attestation (yes/no) measure would not be included under the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category until the CY 2027 performance period/2029 MIPS payment year and CY 2027 EHR reporting period. We believe extending the inclusion of the Electronic Prior Authorization measure to the CY 2027 performance period/2029 MIPS payment year for MIPS eligible clinicians and the CY 2027 EHR reporting period for eligible hospitals and CAHs will allow participants in these programs to work with health IT vendors to adopt and implement functionality that can facilitate the actions needed to satisfy the Electronic Prior Authorization measure.

As far as technical assistance, CMS does host CMS and HL7 FHIR Connectathons, which are free for interested parties to attend, as well as provides educational webinars with overviews of the technical requirements in the CMS Interoperability and Patient Access final rule and proposed requirements in the CMS Interoperability and Prior Authorization proposed rule. Additional public resources also exist through HL7, such as HL7 FHIR Connectathons, HL7 website resources, and HL7 FHIR workgroup meetings. CMS believes that using the EHR systems, and training for staff using them, is up to each practice or hospital system to ensure occurs.

CMS also is aware that the initial incentive programs (that is, the Medicare and Medicaid EHR Incentive Programs) supported EHR adoption for only certain provider types and the challenges that brings for certain provider types that were not originally eligible for this funding. CMS continues to evaluate ways to support providers that may lag in health IT adoption.

Comment: A commenter requested that CMS establish requirements for impacted payers to publish their API endpoints for the Prior Authorization API or provide information on where to find the APIs and make information concerning how to connect to them conspicuously available for third-party app developers and for providers through their public websites similar to what is asked of certified health IT developers of API functions as a part of their basis of CEHRT under 45 CFR 170.315(g)(10).

Response: We understand that a directory of impacted payers' digital endpoints would be highly beneficial to facilitate the Prior Authorization API. Without such a directory, payers would need to discover other payers' endpoints one by one, and each payer would have to maintain a list of payers with whom they have previously connected. Therefore, we are committing to exploring an NDH that contains payers' digital endpoints before the 2027 compliance dates for the Prior Authorization API, which could allow providers to easily access those APIs and thereby facilitate electronic prior authorization, as discussed in this final rule. Further details about the NDH structure, requirements, and timing will be released if and when they become available.

Comment: A commenter discussed the X12 standards and expressed that they do not believe that the inclusion of the Electronic Prior Authorization measure would be a sufficient incentive for MIPS eligible clinicians, eligible hospitals, and CAHs to overcome the costs associated with the transaction. Multiple commenters recommended that CMS should include the usage of the X12 278 standard in the numerator of the proposed measures. A commenter noted organizations that have standardized usage of the X12 standard may find this effective and efficient. The commenter stated that requiring these groups to transition to the Prior Authorization API to meet the measure requirements would be disruptive and burdensome. Another commenter recommended CMS use a single standard if CMS would like to incorporate the Electronic Prior Authorization measure. A commenter also recommended that CMS provide guidance on the role of HIPAA administrative transaction standards.

Response: We thank the commenters for their feedback; however, we do not agree that the X12 278 standard is appropriate for the numerator of the proposed Electronic Prior Authorization measure because of its persistent and historically low utilization. While the CAQH efficiency index report is more reflective of payer and vendor uptake of the HIPAA standards, it does include some provider information. In the last four reporting years, the utilization of the X12 278 transaction has not exceeded 21 percent. Comments from reporting submitters (for the CAQH Index) indicate that providers do not use the X12 278 because it does not include the data elements they need for complete processing, and many payers are still not supporting it. Thus, to consider using that standard as the numerator, knowing the utilization rates are low, would not seem appropriate. We believe the benefit of moving towards a standardized electronic prior authorization process that leverages FHIR outweighs the initial implementation cost and burden of the transition. We will continue coordinating with colleagues across CMS and other Federal agencies on all ways that that HIPAA administrative transaction standards could impact our policies. We also note that we are finalizing a modification to our proposal to no longer require reporting of a numerator and denominator for this measure, as discussed in more detail throughout this section.

c. Measure Exclusions

In the proposed rule (87 FR 76314), we proposed that MIPS eligible clinicians, eligible hospitals, or CAHs that do not order any medical items or services (excluding drugs) requiring prior authorization during the applicable performance period or EHR reporting period could claim an exclusion for the Electronic Prior Authorization measure. We also proposed that MIPS eligible clinicians, eligible hospitals, or CAHs that only order medical items or services (excluding drugs) requiring prior authorization from a payer that does not offer an API that meets the Prior Authorization API requirements outlined in section II.D.2. of this final rule (that is, payers not subject to this regulation or impacted payers that are non-compliant with the Prior Authorization API requirements outlined in section II.D.2. of this final rule), during the applicable performance period/MIPS payment year or EHR reporting period, could claim an exclusion for the Electronic Prior Authorization measure. As an alternative to this proposal, we considered whether MIPS eligible clinicians, eligible hospitals, and CAHs that request a small number of prior authorizations, such as five prior authorizations during the performance period/EHR reporting period, should also be able to claim the exclusion. We sought public comment on the alternative we considered and whether another minimum number of prior authorization requests would be appropriate for the exclusion. Given the previously discussed limitations of the current prior authorization process, we believe that all MIPS eligible clinicians, eligible hospitals, and CAHs (as well as their patients and the payers they request prior authorization from) would benefit from using the electronic process described here, regardless of how often they request prior authorization. Therefore, we believe that no minimum number of prior authorization requests, other than zero, would be a reasonable threshold for claiming an exclusion for the Electronic Prior Authorization measure.

Comment: A few commenters stated that if a payer insists on faxing or other means of communication, CMS should consider treating this scenario as the basis for exclusion from the Electronic Prior Authorization measure versus still having authorizations impacted by such a requirement of a payer included in the denominator. A commenter stated that some practitioners do not have enough prior authorization requests or the necessary technology to support electronic prior authorization, and suggested the exclusion should be based on not only quantity but also on technical capability of those who do not submit a high volume of prior authorization requests. The commenter encouraged CMS to consider alternative exclusion criteria, such as the technical capability of those who do not submit a high volume of prior authorization requests. The commenter continued by stating that CMS should not penalize providers for failing to use EHRs for this purpose of electronic prior authorization if they either do not have enough requests or if the technology they use does not support this capability.

Response: We appreciate commenters' recommendations and feedback that some providers may not have enough prior authorization requests or the necessary technology to support electronic prior authorization. We believe that all MIPS eligible clinicians, eligible hospitals, and CAHs (as well as their patients and the impacted payers they request prior authorization from) would benefit from using the electronic prior authorization process described in this final rule. We also note that the modified version of the Electronic Prior Authorization measure being finalized in this rule only requires reporting of “at least one” medical item or service (excluding drugs) ordered during the performance period/MIPS payment year or EHR reporting period. We believe this is achievable for all MIPS eligible clinicians, eligible hospitals, and CAHs who make any prior authorization requests in a given year. For those who do not have any prior authorization requests, we are finalizing our exclusion as proposed. MIPS eligible clinicians, eligible hospitals, and CAHs who do not order any medical items or services (excluding drugs) requiring prior authorization during the applicable performance period/MIPS payment year or EHR reporting period would be able to report that they qualify for the exclusion for the Electronic Prior Authorization measure.

We acknowledge that EHR technology may not consistently support interactions with the Prior Authorization APIs at this time, and as discussed in further detail elsewhere in this section, we will continue to work with ONC on potential ONC Health IT Certification Program criteria that would support the Electronic Prior Authorization measure. For this reason, we are finalizing this measure for the MIPS Promoting Interoperability performance category beginning with the CY 2027 performance period/2029 MIPS payment year and for the Medicare Promoting Interoperability Program beginning with the CY 2027 EHR reporting period.

d. Office of the National Coordinator for Health Information Technology Health IT Certification Program

As described previously, ONC previously sought comment through an RFI titled “Electronic Prior Authorization Standards, Implementation Specifications, and Certification Criteria” (87 FR 3475), which appeared in the January 24, 2022, issue of the Federal Register , on how updates to the ONC Health IT Certification Program could support electronic prior authorization. Since then, the Unified Agenda has been updated to include a proposed rule from ONC (RIN 0955–AA06) that aims to advance interoperability through proposals for the expanded use of certified APIs for electronic prior authorization, among other proposals. We plan to continue to explore how potential updates to the ONC Health IT Certification Program could support our policies and will address any updates to our requirements related to future updates to the ONC Health IT Certification Program, if finalized, in future rulemaking.

e. Other Considerations

We invited public comment on considerations and alternatives related to the Electronic Prior Authorization measure. For example, we sought comment on the proposed numerator and denominator of the Electronic Prior Authorization measure or any changes to the specifications that would reduce the implementation burden for both impacted providers (MIPS eligible clinicians, eligible hospitals, and CAHs) and health IT developers. We also sought comment on challenges that MIPS eligible clinicians, eligible hospitals, and CAHs might face in identifying those payers that have the Prior Authorization API technology to accurately include eligible prior authorization requests in the denominator. Additionally, we sought comment on challenges MIPS eligible clinicians, eligible hospitals, and CAHs could face in performing the actions included in the Electronic Prior Authorization measure specifications if certification criteria are not available in the ONC Health IT Certification Program at the time MIPS eligible clinicians, eligible hospitals, and CAHs are required to report the Electronic Prior Authorization measure under the Medicare Promoting Interoperability Program or MIPS Promoting Interoperability performance category.

We received many comments in response to our request for comment. We thank commenters for their feedback as we consider any future rulemaking, including collaboration with ONC as appropriate.

Comment: Multiple commenters opposed the proposed Electronic Prior Authorization measure because of the lack of health IT certification criteria to ensure EHRs communicate with payers through Prior Authorization API. Multiple commenters expressed concern about the inclusion of the Electronic Prior Authorization measure due to possible technical challenges and the lack of health IT that has the capacity to support electronic prior authorization. Multiple commenters encouraged CMS to focus on ensuring that the proposed APIs are implemented and supported by CEHRT to make sure they are successfully implemented within the provider's workflow rather than developing a measure related to electronic prior authorization.

Several commenters noted that ONC has not established health IT certification criteria to support electronic prior authorization in such technologies. Multiple commenters suggested various alternative timeframes for CMS to consider. A commenter recommended that CMS require payers to make the Prior Authorization API available to providers no later than 12 months following the publication of this final rule. Another commenter suggested a compliance date 12 months after the implementation of the Prior Authorization API or 36 months following publication of this final rule, whichever is later. Another commenter requested that CMS consider reopening the comment period for this rule following the publication of the HTI–1 proposed rule (88 FR 23746). The commenter stated that CMS should give industry 24 months from the reopening of the comment period to create specifications, perform development, complete certification testing, and execute client deployments. Another commenter recommended that CMS suspend the proposed Electronic Prior Authorization measure until payers implement and maintain the Prior Authorization API as specified in this rule and the Prior Authorization API is in effect for at least 3 years. Multiple commenters were concerned that providers will not be guaranteed access to the Prior Authorization API if health IT developers are not required to incorporate the functionality into CEHRT and therefore should not be held accountable for using the Prior Authorization API nor reporting on the proposed Electronic Prior Authorization measure. A commenter recommended that CMS and ONC work in collaboration to leverage technologies, such as electronic prior authorization tools. Another commenter urged CMS to work with ONC to establish ONC Health IT Certification Program criteria to require providers and EHR vendors to adopt the IGs associated with electronic prior authorization. Commenters stated that it is unreasonable to measure utilization by MIPS eligible clinicians, eligible hospitals, and CAHs of electronic prior authorization processes for incentive payments until the ONC Health IT Certification Program requires CEHRT to include the functionality necessary for health IT systems to communicate through a Prior Authorization API. Another commenter stated that CMS should postpone implementation of the Electronic Prior Authorization measure until both the ONC Health IT Certification Program and HIPAA attachment standards are updated. Another commenter stated that the proposed Electronic Prior Authorization measure would subject MIPS eligible clinicians, eligible hospitals, and CAHs to be reliant upon untested technology and tie their performance to such technology. A commenter emphasized the importance of industry adoption and noted that the API will have minimal value if EHR vendors do not build the necessary connections to allow clinicians to access it and if clinicians are not incentivized to adopt. To mitigate this, the commenter recommended that CMS require EHR vendors to provide bi-directional patient data access via an API so payers can better leverage digital patient information and automate prior authorization requests. Another commenter recommended that CMS ensure that the proposed Electronic Prior Authorization measure is supported by technology used by all of the impacted users. Several commenters stated that providers should not be subject to punitive action if they do not implement the Prior Authorization API requirements and should not be evaluated on electronic prior authorization utilization for payment purposes until EHRs are required to provide this functionality by the ONC Health IT Certification Program.

Response: We appreciate the comments received on this request for comments. As noted, the Unified Agenda, current at the time of publication of this final rule, includes an entry for a proposed rule from ONC (RIN 0955–AA06) that aims to advance interoperability through proposals for the expanded use of certified APIs for electronic prior authorization. We will work with ONC to ensure that any future updates to the ONC Health IT Certification Program around electronic prior authorization will improve health care providers' capabilities to interact with the Prior Authorization APIs established by impacted payers, as well as further support health care providers' ability to complete the action specified in the Electronic Prior Authorization measure we are finalizing. We will provide further guidance in future rulemaking about how any updates made by ONC to the ONC Health IT Certification program related to electronic prior authorization relate to the requirements of the Medicare Promoting Interoperability Program and Promoting Interoperability performance category of MIPS. We note that CMS does not have authority to regulate EHR vendors directly; however, we collaborate with ONC regarding certification criteria for health IT that are included in the voluntary ONC Health IT Certification Program and referenced in CMS program requirements.

In the interim, we note that MIPS eligible clinicians, eligible hospitals, and CAHs are required to use CEHRT for the measure as a means to capture clinical information as structured data and to use such structured data for the prior authorization. This function of gathering structured data from CEHRTs is achievable today without additional CEHRT criteria. The request for prior authorization through the Prior Authorization API could be accomplished through the use of additional technology to complement CEHRT depending on implementation preference. We note that MIPS eligible clinicians, eligible hospitals, and CAHs can report on the measure, saying “yes” they submitted a prior authorization request electronically using the Prior Authorization API with data from CEHRT, without needing additional certification criterion in the ONC Health IT Certification Program.

We also note that in December 2022, HHS proposed to adopt a standard for attachments in the HIPAA Standards for Health Care Attachments proposed rule (87 FR 78438). That proposed rule has not yet been finalized. At this time there are no operating rule requirements applicable to the APIs required for use in this final rule, or to the HIPAA X12 278 transaction standard.

We appreciate commenters' recommendations regarding implementation timelines, such as making the Prior Authorization API available to providers no later than 12 months or 36 months following the publication of this final rule. We note that, after consideration of comments received and discussed in more detail elsewhere in the rule, we are finalizing our proposal with the modification to have MIPS eligible clinicians report the Electronic Prior Authorization measure beginning with the CY 2027 performance period/2029 MIPS payment year and eligible hospitals and CAHs report the Electronic Prior Authorization measure beginning with the CY 2027 EHR reporting period. We also acknowledge that a commenter recommended suspending the Electronic Prior Authorization measure until payers implement the Prior Authorization API as specified in this rule and use it for some time period. However, we believe finalization of this Electronic Prior Authorization measure encourages all parties involved (payers and providers) to develop, implement, and use the new Prior Authorization API to drive widespread adoption, thus reaping the benefits of burden reduction through electronic prior authorization processes. The Prior Authorization API needs parties on both ends of a request to be using the API in order for the API to be beneficial to everyone involved.

Comment: Multiple commenters recommended that ONC conduct oversight of CEHRT products to determine if the products do or do not successfully support electronic prior authorization, and then publicize CEHRT products that fail ONC review on the Certified Health IT Product List (CHPL) so providers can avoid products that will not support the new electronic prior authorization requirements. The commenter recommended that ONC work with professional associations to educate providers about their oversight and reporting process.

Response: There is not a dedicated certification criterion related to electronic prior authorization in the ONC Health IT Certification Program at this time. However, as noted previously, ONC previously sought comment on how updates to the ONC Health IT Certification Program could support electronic prior authorization (87 FR 3475). We also note that the Unified Agenda, current at the time of publication of this final rule, includes an entry for a proposed rule from ONC (RIN 0955–AA06), which describes planned proposals for the expanded use of certified APIs for electronic prior authorization. We note that the Electronic Prior Authorization measure requires using data from CEHRT, and the Prior Authorization API can be implemented without regard to any changes ONC may propose for the ONC Health IT Certification Program.

While ONC oversight and enforcement authority is beyond the scope of this final rule, we note that health IT products certified to all certification criteria are subject to oversight mechanisms within the ONC Health IT Certification Program. For more information about the oversight elements within the ONC Health IT Certification Program, readers should visit the ONC website at https://www.healthit.gov/topic/certification-ehrs/oversight-and-surveillance. Regarding the CHPL ( https://chpl.healthit.gov/ ), we note this resource includes listings of those health IT products that have successfully certified to health IT certification criteria under the Certification Program.

Comment: Multiple commenters recommended that CMS and ONC outline a roadmap for electronic prior authorization adoption that leverages the ONC Health IT Certification Program. A commenter recommended that the roadmap should include details from the ONC Cures Act final rule (85 FR 25642) and these requirements. Another commenter stated that an established path to electronic prior authorization will avoid delays and confusion.

Response: We appreciate commenters' feedback. CMS will consider developing a roadmap for electronic prior authorization adoption in collaboration with ONC. We will collaborate with ONC to incorporate any future policies for the ONC Health IT Certification Program as part of a comprehensive approach to ensuring electronic prior authorization is conducted in a standardized fashion across parties.

3. Final Action

After consideration of the comments received and for the reasons discussed in the CMS Interoperability and Prior Authorization proposed rule and our response to those comments (as summarized previously), we are finalizing our proposal with the following modifications:

• The “Electronic Prior Authorization” measure will be reported as an attestation (yes/no) measure, instead of reporting a numerator and denominator, regarding whether the MIPS eligible clinician, eligible hospital, or CAH submitted at least one prior authorization request electronically via a Prior Authorization API using data from CEHRT during the performance period/EHR reporting period, as further specified below.
• MIPS eligible clinicians will report the “Electronic Prior Authorization” measure for the MIPS Promoting Interoperability performance category beginning with the CY 2027 performance period/2029 MIPS payment year and eligible hospitals and CAHs participating under the Medicare Promoting Interoperability Program will report the measure beginning with the CY 2027 EHR reporting period.

See further discussion below for exact details of the final requirements for MIPS eligible clinicians, eligible hospitals, and CAHs.

We are finalizing the following specifications for the Electronic Prior Authorization measures:

1. For MIPS Eligible Clinicians Under the MIPS Promoting Interoperability Performance Category—Electronic Prior Authorization

• Measure Description: For at least one medical item or service (excluding drugs) ordered by the MIPS eligible clinician during the performance period, the prior authorization is requested electronically via a Prior Authorization API using data from CEHRT.

• Reporting Requirements: Yes/No response.

To successfully report this measure, MIPS eligible clinicians must attest “yes” to requesting prior authorization electronically via a Prior Authorization API using data from CEHRT for at least one medical item or service (excluding drugs) ordered by the MIPS eligible clinician during the performance period or (if applicable) report an exclusion.

• Exclusion: Any MIPS eligible clinician who—

++ Does not order any medical items or services (excluding drugs) requiring prior authorization during the applicable performance period; or

++ Only orders medical items or services (excluding drugs) requiring prior authorization from a payer that does not offer an API that meets the Prior Authorization API requirements outlined in section II.D.2. of this final rule during the applicable performance period.

2. For Eligible Hospitals and Critical Access Hospitals Under the Medicare Promoting Interoperability Program—Electronic Prior Authorization

• Measure Description: For at least one hospital discharge and medical item or service (excluding drugs) ordered during the EHR reporting period, the prior authorization is requested electronically via a Prior Authorization API using data from CEHRT.

• Reporting Requirements: Yes/No response.

To meet this measure, the eligible hospital or CAH 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 EHR reporting period or (if applicable) report an applicable exclusion.

• Exclusions: Any eligible hospital or CAH that—

++ Does not order any medical items or services (excluding drugs) requiring prior authorization during the EHR reporting period.

++ Only orders medical items or services (excluding drugs) requiring prior authorization from a payer that does not offer an API that meets the Prior Authorization API requirements outlined in section II.D.2. of this final rule during the applicable EHR reporting period.

We intend to reevaluate the Electronic Prior Authorization measure criteria and reporting structure of this measure in future years as the Prior Authorization API becomes more widely adopted and if additional certification criteria become available for CEHRT to determine whether a numerator/denominator reporting structure would be more appropriate at that time. We would address those issues in future rulemaking.

We are finalizing our proposal that the Electronic Prior Authorization measure will not be assigned points for the CY 2027 performance period/2029 MIPS payment year for MIPS eligible clinicians, and the CY 2027 EHR reporting period for eligible hospitals and CAHs. Instead, if a MIPS eligible clinician, eligible hospital, or CAH fails to report the measure as specified, they would not meet the minimum reporting requirements, not be considered a meaningful EHR user, and fail the Medicare Promoting Interoperability Program or the MIPS Promoting Interoperability performance category. A failure to meet the minimum reporting requirements of the Medicare Promoting Interoperability Program would result in a downward payment adjustment for eligible hospitals or CAHs (unless the eligible hospital or CAH receives a hardship exception). A failure in the Promoting Interoperability performance category would result in the MIPS eligible clinician receiving a score of zero for the performance category, which is currently worth 25 percent of their final score for MIPS.

For the MIPS Promoting Interoperability performance category, satisfactory performance on this measure can be demonstrated only by reporting a “yes” response on the attestation or claiming an applicable exclusion. A “no” response on the attestation will result in the MIPS eligible clinician failing to meet the minimum reporting requirements, therefore not being considered a meaningful EHR user for MIPS, as set forth in section 1848(o)(2)(A) of the Act and defined at 42 CFR 414.1305, for the MIPS payment year (42 CFR 414.1305). MIPS eligible clinicians that do not report a “yes” response or claim an applicable exclusion for the Electronic Prior Authorization measure as specified (that is, they do not submit the measure or claim an exclusion or report a “no” response) will not earn a score for the MIPS Promoting Interoperability performance category (a score of zero for the category). A MIPS eligible clinician's score in the Promoting Interoperability performance category is generally worth 25 percent of their total final score for MIPS (42 CFR 414.1375(a); 414.1380(c)(1)). We note that to report a “yes,” the action of the measure must occur during the selected performance period or EHR reporting period, as per the measure specification defined below.

For the Medicare Promoting Interoperability Program, only a “yes” response on the attestation, or claiming an applicable exclusion, will fulfill the minimum requirements of this measure. A “no” response will result in the eligible hospital or CAH failing to meet the measure, and therefore failing to meet minimum program reporting requirements, thus not being considered a meaningful EHR user for an EHR reporting period, as defined in section 1886(n)(3) of the Act. Eligible hospitals and CAHs that do not meet the minimum program requirements are subject to a downward payment adjustment (unless the eligible hospital or CAH receives a hardship exception).

G. Interoperability Standards for APIs

1. Background

In the CMS Interoperability and Patient Access final rule (85 FR 25510), we finalized a requirement to implement, maintain, and use API technology conformant with the API technical standards at 45 CFR 170.215, which at the time included (85 FR 25521):

• Health Level Seven (HL7®) Fast Healthcare Interoperability Resources (FHIR®) Release 4.0.1
• HL7® FHIR® US Core Implementation Guide (IG) Standard for Trial Use (STU) 3.1.1
• HL7® SMART Application Launch Framework IG Release 1.0.0, including mandatory support for the “SMART Core Capabilities”
• FHIR® Bulk Data Access (Flat FHIR) IG (v1.0.0: STU 1), including mandatory support for the “group-export” “OperationDefinition”
• OpenID Connect Core 1.0, incorporating errata set 1

When we finalized the requirement for conformance with the specifications at 45 CFR 170.215 in the CMS Interoperability and Patient Access final rule, we required impacted payers to comply with all standards at 45 CFR 170.215 for each of the APIs finalized in that rule. However, we understand that the existing requirements for payers to “use API technology conformant with 45 CFR 170.215” (85 CFR 25632) for each API may introduce confusion to the compliance requirements, because not all the standards at 45 CFR 170.215 may be applicable for each specific API.

Accordingly, to provide clarity, in the CMS Interoperability and Prior Authorization proposed rule, we outlined modifications to be more specific regarding which standards at 45 CFR 170.215 are applicable to each API (87 FR 76314–21). Specifically, instead of the existing requirements to use “API technology conformant with 45 CFR 170.215,” we proposed that each standard at 45 CFR 170.215 would apply to a given set of APIs. The specific CFR citations were listed in Table 8 of the proposed rule (87 FR 76318). We are now finalizing those requirements, with modifications to some of the specific API requirements. We are finalizing that impacted payers will only be required to use those specifications at 45 CFR 170.215 that are listed in Table H3 as necessary for the Patient Access, Provider Access, Provider Directory, Payer-to-Payer, and Prior Authorization APIs. We are also finalizing our proposal to allow impacted payers to use updated standards, specifications, or IGs for each of these APIs. Finally, we are reiterating our recommendations to use the IGs listed in Table H3. We discuss these policies in detail elsewhere in the final rule.

2. Modifications to Required Standards for APIs

We proposed specific standards at 45 CFR 170.215 that would apply to each API. In the proposed rule, we listed the standards applicable to each API in Table 10 (87 FR 76320). Since the publication of the CMS Interoperability and Prior Authorization proposed rule, ONC has published the HTI–1 final rule which reorganized the structure of 45 CFR 170.215 to delineate the purpose and scope more clearly for each type of standard or implementation specification (89 FR 1283). We note that the HTI–1 final rule adopted updated versions of several standards at 45 CFR 170.215, which now includes:

• Health Level Seven (HL7) Fast Healthcare Interoperability Resources (FHIR) Release 4.0.1 at 45 CFR 170.215(a)(1) (HL7 FHIR);
• HL7 FHIR US Core IG Standard for Trial Use (STU) 3.1.1, which expires on January 1, 2026, at 45 CFR 170.215(b)(1)(i);
• HL7 FHIR US Core IG STU 6.1.0 at 45 CFR 170.215(b)(1)(ii) (US Core IG),
• HL7 SMART Application Launch Framework IG Release 1.0.0, which expires on January 1, 2026, at 45 CFR 170.215(c)(1);
• HL7 SMART App Launch IG Release 2.0.0 at 45 CFR 170.215(c)(2) (SMART App Launch IG);
• FHIR Bulk Data Access (Flat FHIR) IG (v1.0.0: STU 1) at 45 CFR 170.215(d)(1) (Bulk Data Access IG); and
• OpenID Connect Core 1.0, incorporating errata set 1 at 45 CFR 170.215(e)(1) (OpenID Connect Core).

We refer readers to the HTI–1 proposed and final rule for additional information (FR 1284 through 1295). The specific standards at 45 CFR 170.215 that we identified in our proposed rule were restructured by HTI–1 and moved to new locations at 45 CFR 170.215. In addition, in several cases ONC adopted new versions of the same standards proposed in the CMS Interoperability and Prior Authorization proposed rule. Specifically, ONC finalized US Core IG STU 6.1.0 (at 45 CFR 170.215(b)(1)(ii)) and the SMART App Launch IG Release 2.0.0 (at 45 CFR 170.215(c)(2)). Additionally, ONC has finalized expiration dates for the US Core IG STU 3.1.1 (at 45 CFR 170.215(b)(1)(i)) and the SMART App Launch Framework IG Release 1.0.0 (at 45 CFR 170.215(c)(1)) to indicate when a version of a standard may no longer be used for the ONC Health IT Certification Program. While we did not propose to require those updated versions, we emphasize that impacted payers are permitted to use them based on our policy to allow updated versions of required standards, as discussed. We intend to align with the updated versions finalized at 45 CFR 170.215 through future rulemaking prior to our API compliance dates.

We are finalizing our proposals to identify specific required standards at 45 CFR 170.215 that are applicable to each of the APIs, with modifications. The finalized requirements include any additional mandatory support requirements listed, such as for both the SMART App Launch IG at 45 CFR 170.215(c) and Bulk Data Access IG at 45 CFR 170.215(d). We are cross-referencing the new locations for these standards at 45 CFR 170.215 finalized by ONC in the HTI–1 final rule. Table H3 lists the required versions of each standard and their citation. Throughout this preamble we refer to the current structure of 45 CFR 170.215 as updated by the HTI–1 final rule.

For the Patient Access API, we are finalizing the required standards as proposed with modifications to incorporate the expiration dates ONC adopted at 45 CFR 170.215(b)(1)(i) and (c)(1). For the Provider Directory API, we are finalizing our proposal with modifications to incorporate the expiration date ONC adopted at 45 CFR 170.215(b)(1)(i), and to remove the SMART App Launch IG at 45 CFR 170.215(c)(1) and OpenID Connect Core at 45 CFR 170.215(e), which were erroneously included in the proposed rule. We refer readers to the footnote in Table H3 for additional information. For the Provider Access API, we are finalizing our proposal with the modification to not require OpenID Connect Core at 45 CFR 170.215(e) and with modifications to incorporate the expiration dates ONC adopted at 45 CFR 170.215(b)(1)(i) and (c)(1). For the Payer-to-Payer API, we are finalizing our proposal with modifications to not require the SMART App Launch IG at 45 CFR 170.215(c) and OpenID Connect Core at 45 CFR 170.215(e), and to incorporate the expiration date ONC adopted at 45 CFR 170.215(b)(1)(i). For the Prior Authorization API, we are finalizing our proposal with modifications to not require OpenID Connect Core at 45 CFR 170.215(e) and to incorporate expiration dates ONC adopted at 45 CFR 170.215(b)(1)(i) and (c)(1). Payers will be required to comply with the applicable specifications that we have identified for the Patient Access, Provider Access, Provider Directory, Payer-to-Payer, and Prior Authorization APIs as listed in Table H3. The exact regulation text for each API will vary depending on which standards apply to that API. These updates particularize the specifications at 45 CFR 170.215 that are required for each API. We received comments on these proposals and discuss details of the modifications.

a. HL7 FHIR and Technical Readiness

Comment: Multiple commenters expressed support for CMS's proposal to specify technical standards for each API and recommended that CMS finalize the proposal. A commenter expressed appreciation for CMS's efforts to explain the technical requirements for each API and agreed with the proposal to add more specific language regarding which standards apply to which API.

Multiple commenters also supported CMS's proposal to require payers to use the FHIR standard to facilitate information exchange and promote interoperability. Multiple commenters stated that FHIR APIs help connect patients, providers, and payers to the correct information. A commenter stated that FHIR-based standards maximize the chance for innovation and the proposed revision provides technical clarity to payers. Another commenter stated that utilizing the FHIR standard continues to advance the use of transparent, widely available standards and helps to facilitate electronic information exchange, while another stated that the FHIR-based IGs support the provider team's workflow and enable them to better understand patient-specific benefits.

Response: We appreciate commenters support for using the FHIR standard and FHIR APIs to improve information exchange and agree with the commenters' assessments that these will advance interoperability.

Comment: Multiple commenters expressed concern about mandating the FHIR standard. Multiple commenters expressed concern regarding the maturity of the proposed standards, specifications, and recommended IGs. Multiple commenters stated that it would be inadvisable to specify technical requirements at this time given that the technical standards and IGs have not fully matured. Multiple commenters recommended that CMS, along with ONC, take steps to adequately and inclusively develop technical standards and relevant IGs to full maturity as a baseline of industry consistency, ensuring standards are tested and transparently evaluated prior to mandated adoption. Another commenter encouraged CMS to maintain flexibility in the agency's ongoing data exchange activities to ensure the success of interoperability programs. Another commenter urged CMS to ensure careful consideration of what technical standards to require in the future. Another commenter suggested that requiring all entities to use the FHIR standard may be burdensome. The commenter stated that CMS has not proposed any alternatives and that adoption of the FHIR standard may not be feasible for small entities and asked questions such as what will happen if small businesses are not able to convert to FHIR.

A commenter cautioned CMS not to view the FHIR standard as the sole solution to interoperability and patient data exchange challenges. The commenter noted that as currently proposed, the Patient Access API would experience challenges if the FHIR standard failed to reach widespread adoption and maturity. A commenter stated that the HL7 Da Vinci IGs that support the Patient Access API have not yet reached sufficient maturity for widespread adoption. The commenter stated that using the FHIR standard, agnostic of a particular IG, will give industry stakeholders greater flexibility to pilot different approaches and build consensus without the risk of distortions that could result from mandatory adoption of immature specifications.

Response: We thank commenters for providing their thoughts regarding the FHIR standard. However, we disagree that FHIR is not mature. The primary components of the FHIR standard are mature, as are the standards we are requiring in this rule, such as the US Core IG. We acknowledge that the FHIR resource profiles included in the IGs we recommend are of varying levels of maturity, but we believe they are sufficiently mature for industry to start implementing them. We refer readers to our discussion on IG maturity in section II.G.3.b. of this final rule. The FHIR standard will help move the health care industry toward a more interoperable state, and we believe that it supports transmission of health data in a standard, structured, but flexible format as FHIR specifications continue to advance and mature. HHS has already adopted standards for FHIR APIs at 45 CFR 170.215, as finalized in the ONC Cures Act final rule, and therefore we did not propose any alternatives (85 FR 25521). We disagree that the HL7 Da Vinci IGs that support the Patient Access API have not yet reached sufficient maturity for widespread adoption as they have already been successfully implemented and are being used today. Since 2021 impacted payers have been required to implement and maintain a standards-based Patient Access API that uses FHIR and other technical standards at 45 CFR 170.215, as finalized in the CMS Interoperability and Patient Access final rule (85 FR 25558). We are delaying the compliance date for policies that require API enhancement or development to 2027, which will allow additional time for the recommended FHIR IGs to be refined to support the policies in this final rule. We believe the adoption of the FHIR standard is feasible for all the APIs finalized in this rule, especially with the additional implementation time.

Comment: Multiple commenters appreciated CMS's efforts to move industry towards interoperability and expressed support for CMS's proposals to promote electronic data exchange among patients, providers, and payers via APIs leveraging technical standards and IGs. Multiple commenters supported using FHIR-based standards to facilitate data transport across the industry and that FHIR-based exchange is technically feasible for both payers and providers to adopt and implement. A commenter stated that the FHIR standard and IGs promote a level of consistency in terms of format, structure, and vocabulary, as well as allow for a variety of interoperability paradigms that best suit the interaction requirements between providers, payers, and patients. A commenter supported using USCDI data classes and data elements in addition to claims and encounter data when exchanging patient information.

Multiple commenters expressed support for CMS's proposals to use standards-based APIs and stated that the industry-wide adoption of uniform standards will help enhance interoperability and minimize complexity. Multiple commenters stated that having an established technical infrastructure to support the development and adoption of the new APIs outlined in this rule is crucial to prevent added administration burden, complexity, and variability in implementation.

Response: We agree with the commenters' assessments and thank them for their support of our policies.

Comment: A commenter requested that CMS define a more prescriptive designated data set for claims and encounter data akin to USCDI. The commenter continued by stating that CMS should explicitly call out the Common Payer Consumer Data Set (CPCDS), which would ensure a more uniform implementation and ensure that patients, providers, and payers can use those capabilities in a way that the rule intended. Another commenter suggested a realignment of the purpose and use of USCDI as a library of data types, classes, and specifications from which interoperability requirements can be drawn.

Response: While altering the design and structure of the USCDI are out of scope for this rule, we will continue to work with ONC to expand and build upon the USCDI. For instance, we have worked with ONC on the USCDI+ initiative, which aims to harmonize data sets that extend beyond the USCDI for additional use cases. While USCDI is one category of data required to be exchanged via the APIs, we understand that the USCDI is limited in scope and that additional data and standards will be necessary to implement these APIs. For instance, the recommended HL7® FHIR® CARIN Consumer Directed Payer Data Exchange IG (CARIN IG for Blue Button) (87 FR 76316), which was itself informed by and includes mappings to CPCDS.

Comment: A commenter noted that the implementation of the APIs is contingent on compliant technical solutions being available in the marketplace. Another commenter stated that the lack of specificity in API requirements gives payers significant latitude to determine what data elements they want to include in their APIs and under what circumstances, which will not promote widespread interoperability. Another commenter stated that technical standardization and payer participation are the only ways that these proposals could be effective. The commenter stated if the responsibility is not shared across stakeholders, CMS will simply shift more burden onto providers. Another commenter stated that variance in API implementation could require providers to need significant assistance from health IT vendors to navigate these systems, which would eliminate any efficiencies CMS expected to derive from the new interoperability requirements. Another commenter noted a frequent problem with the implementation of technical processes is variation from system-to-system and interpretation differences since guidance is not universally communicated to developers who need the information. Similarly, a commenter noted that these technical API standards may require providers to hire additional staff to implement them.

Response: The industry already has significant adoption of the FHIR standard for several use cases and there are solutions available today to FHIR-enable existing systems. Additionally, many of the IGs recommended in this rule have already been implemented by multiple implementers at some level. We anticipate more solutions will be available in the marketplace ahead of the API compliance dates in 2027. We acknowledge that using marketplace technical solutions may ease implementation. We understand that there is still a learning curve with respect to the FHIR-based standards and IGs and that entities may need to hire and train staff.

We appreciate these perspectives and acknowledge that standards are what promote interoperability. The adoption of the FHIR standard and the IGs promote interoperability by enabling the secure exchange of health information across disparate systems. The FHIR APIs provide the framework for this exchange. Regarding concerns for the lack of specificity in the API requirements, we acknowledge that we are only recommending rather than requiring several IGs because they continue to evolve and are not adopted by HHS at 45 CFR 170.215. As these IGs continue to mature, we will consider proposing to require them through future rulemaking. The IGs provide the exchange of the essential data elements, such as patient demographics, clinical information, prior authorization requests, and other data to ensure the necessary information is shared between payers and providers. We acknowledge that implementation and testing will take time and welcome ongoing feedback through the programs and standards workgroups.

Comment: Multiple commenters expressed concern regarding the proposed technical standards and IG provisions outlined in the proposed rule. Multiple commenters noted that technical challenges around health information exchange could persist despite these proposals and that the technical standards lack the specificity and flexibility to properly support the interoperable exchange of data.

Response: We received many comments regarding our approach in the proposed rule of recommending, rather than requiring, specific IGs. We believe that this approach optimally balances the need for us to provide directional guidance without locking implementers into the versions of the recommended IGs that were available at the time of the proposed rule. As these IGs mature, industry can continue to harmonize on common approaches that work, eventually culminating in a required set of specifications, which, when ready, could be proposed through future CMS rulemaking. If we chose not to recommend specific IGs, this lack of direction would mean a more diverse set of proprietary solutions, resulting in little to no interoperability.

Comment: A commenter stated that there is transformative effort and overall risk in requiring the Patient Access, Provider Access, and Payer-to-Payer APIs to be implemented around the same time. A commenter noted that the attachments standard is not mature and that could hinder non-structured data exchange such as in CMS's proposals to require prior authorization documentation in the Patient Access, Provider Access, and Payer-to-Payer APIs. The commenter noted there is a risk in needing necessary endpoint connections and the functionality to convert documents between FHIR exchanges to be established by payers, providers, and health IT vendors for the purpose of data exchange. The commenter recommended that CMS first require the APIs and then add the exchange of attachments a few years later.

Response: For the Patient Access, Provider Access, and Payer-to-Payer APIs, we are requiring impacted payers to share claims and encounter data, all data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI), and certain information about prior authorizations. Many of the data classes and data elements are already required for the Patient Access API, which means that payers have already formatted these data and prepared their systems to share via a FHIR API. We thus believe that payers can concurrently implement the APIs in this final rule.

We agree that standards for transmitting documentation and attachments via the FHIR APIs are still under development and in testing, and thus not yet in widespread use across the industry. Further, as elaborated in sections II.A. and II.B. of this final rule, we agree that the burden of requiring impacted payers to make unstructured documentation available via the Patient Access and Provider Access APIs outweighs the benefits such documentation would provide. However, as discussed in section II.C., for the Payer-to-Payer API we are finalizing a requirement to exchange structured and unstructured administrative and clinical documentation submitted by providers related to prior authorization requests and decisions.

Comment: Multiple commenters encouraged CMS to work with ONC to ensure relevant technical standards and related IGs are sufficiently mature and reflect the proper content and policies to allow seamless data transfers between payers and providers. Another commenter urged CMS to work in partnership with ONC to establish a clear pathway for the required IGs including: (1) the ability to advance IG versions outside the regulatory cycle; (2) adequate time for industry to understand and adopt new IG versions; and (3) limiting options, so as not to disrupt interoperability.

Response: As previously mentioned in this section, the primary components of the FHIR standard are mature, as are the standards we are requiring in this rule. We acknowledge that the FHIR resource profiles included in the IGs we recommend are of varying levels of maturity, we believe they are sufficiently mature for industry to start implementing them. We refer readers to our discussion on IG maturity in section II.G.3.b. of this final rule. We will continue to closely coordinate our policies with ONC to ensure that they are mutually reinforcing. We are also finalizing our proposal to allow payers to use updated standards, specifications, or IGs for each API, as long as certain conditions are met, including that the updated version does not disrupt an end user's ability access the data required for that API.

Comment: A few commenters shared concerns with the lack of a mandatory testing system, as well as lack of available test data, staging environments, sandboxes, and other mechanisms to help developers test their APIs. A commenter suggested CMS conduct usage validity testing of the payers' APIs throughout the development and deployment process of the APIs to track and mitigate any risks associated with missing or incorrect data. The commenter requested that CMS delay the enforcement timeline to accommodate these critical prerequisites. Likewise, another commenter recommended that CMS postpone publication of the final rule until it can require both the technical standards and IGs to prevent non-standard implementation across the industry. The commenter recommended that CMS work with the HL7 Da Vinci workgroup and ONC to ensure the APIs and associated standards are tested for complex use cases and to scale. Another commenter recommended CMS define or promote conformity to the ONC Inferno Framework. Another commenter recommended that CMS should establish a mandatory testing system like the ONC Cypress testing tool for the proposed APIs and data standards requirements.

Multiple commenters noted that testing should be conducted in a variety of clinical settings, including small, independent, and rural practices, and with all end users to ensure that the technical standards and IGs are effective, adaptable, and efficient. A commenter highlighted that it is critical that any solution be fully developed and tested prior to wide-scale industry rollout and required usage to ensure the best return on the investment of industry resources. The commenter stated that this process should include careful consideration of the transactions' scalability, privacy guardrails, and ability to complete administrative tasks in a real-world setting. Other commenters recommended that CMS establish additional pilot testing programs to ensure industry readiness before the compliance dates.

Response: We agree that testing is an important part of the implementation process and will continue to support industry efforts to do so, including coordinating with ONC and HL7, including the DaVinci Accelerator, on such efforts. We will also continue to engage with ONC to determine whether the Inferno Framework could be utilized in the future. HL7's IG testing process includes privacy and security testing. Also, FAST, which is an initiative started by ONC, identifies FHIR scalability gaps, defines solutions to address current barriers, and identifies needed infrastructure for scalable FHIR solutions. Real-world testing can only be accomplished if payers choose to pilot an implementation during the testing phase, which CMS cannot require participation in. However, we are not delaying publication of this final rule, as we understand that industry requires a firm commitment from the Federal Government to the adoption and recommendation of standards. Based on comments received, and as discussed throughout this final rule, we are delaying the compliance dates for all the policies that require API development and enhancement to 2027, which will allow additional time for FHIR specifications to continue to be refined and advanced to support the policies in this final rule.

We also appreciate the multiple comments received on the importance of testing and the provision of examples, such as the ONC Cypress testing tool, which is an open-source tool used in the ONC Health IT Certification Program to ensure certified health IT accurately calculates electronic clinical quality measures (eCQMs). We will continue to collaborate with ONC and DaVinci on testing the APIs and with HL7 on communication and outreach to payers, developers, and providers.

Comment: Multiple commenters urged CMS to closely track and participate in the standards development process to ensure that all perspectives are considered, such as providers, payers, and other applicable end users. Multiple other commenters urged CMS and ONC to provide funding to HL7 FHIR Accelerators and task forces. A commenter expressed their desire for CMS to increase opportunities for greater stakeholder participation in the standards development process. Another commenter recommended that CMS release a formal assessment of the status of technology development in support of the new requirements to demonstrate that the technology is fully developed and implementable.

Response: We are an active participant in the standards development process through various workgroups and FHIR Accelerators. A few of the recommended IGs have been developed by HL7 FHIR Accelerator programs, which bring together individuals across the industry to create and adopt IGs in alignment with HL7, which allows new and revised requirements to become open industry standards. Under HL7 FHIR Accelerators, interested parties within the industry have defined, designed, and created use-case-specific implementations of FHIR to address value-based care initiatives. Some HL7 FHIR Accelerators, such as Da Vinci and CARIN, have created IGs that we recommend be used for the Patient Access, Provider Directory, Provider Access, Payer-to-Payer, and Prior Authorization APIs. We also provide contract support to supplement existing work led by the SDOs and FHIR Accelerators. Further, we cohost an annual FHIR Connectathon testing event with HL7 and encourage diverse stakeholder participation from payers, providers and patient advocates. HL7 has developed a FHIR Maturity Model (FMM) that defines thresholds of standards maturity as part of their standards development and publication process. HL7 requires a specific maturity level for parts of the standards development and publication process. We also note that ONC publishes an Interoperability Standards Assessment (ISA). The latest published 2023 version provides information on the HL7 standards that are required or recommended in this rule.

Comment: A commenter urged CMS to pay close attention to principles that focus on assessing provider impact, measuring success in achieving stated goals, and monitoring standards development and use. The commenter stated that these principles can help guide CMS and developers to better respond to provider needs. Another commenter urged CMS to ensure that the technical standards meet provider and patient needs and accurately embody CMS's goals to improve care and reduce provider burden.

Response: We will continue to assess standards development and use as an active participant in the HL7 community and FHIR workgroups. We also encourage stakeholders to participate and contribute to the work of the SDOs in the standards development and evolution, because broad engagement would support the improvement of interoperable standards.

Comment: A commenter recommended continued Federal support of ongoing standards development and data interoperability work, including financial and technical support, for SDOs such as the HL7 Da Vinci Workgroup, FAST, and other applicable workgroups. Some commenters encouraged CMS to advance the FAST initiatives to address the ongoing challenges of patient matching, identity management, security and authentication, and access to the necessary digital endpoints. Another commenter expressed support for incentives and investment in FHIR-based pilots and technology, stating that this would move the industry towards FHIR APIs for real-time information exchange.

Response: We agree and intend to continue our support for and participation in various standards development activities. As noted previously, we provide contract support to supplement existing work led by the SDOs and FHIR Accelerators. We believe that the policies that we are finalizing are a crucial step in moving the industry towards real-time information exchange.

Comment: A commenter stated that to assist providers in making informed decisions, CMS should apply the same “discrete data element standards” the agency applied to the original Patient Access API to the new prior authorization data added to the Patient Access, Provider Access, and Payer-to-Payer APIs. Another commenter requested that CMS consider synchronizing the required technical standards for those three APIs given that the APIs are functionally identical. The commenter stated that having a single standardized API for the three different access types (patient, provider, and payer) would provide three key benefits: (1) simplifies the technical approach for initial rollout and any future changes; (2) allows Medicaid programs to focus on challenges that these APIs pose; and (3) reduces end user confusion since end users will see the same data shared through the APIs. A commenter requested that CMS continue to standardize and harmonize API requirements to reduce potential burden for providers and confusion for consumers. Another commenter stated that these requirements should be consistent across all stakeholders.

Response: Each of the APIs in this rule will require sharing only structured documentation, except for the Payer-to-Payer API, which includes unstructured administrative and clinical documentation submitted by a provider to support a prior authorization request. We intentionally based the requirements for the Provider Access and Payer-to-Payer APIs on the content requirements for the Patient Access API, to facilitate reuse, since payers have already formatted these data elements and prepared their systems to share these standardized data via a FHIR API. Payers already devoted the development resources to build a FHIR API infrastructure when they implemented the Patient Access API, which can be adapted for additional interoperability use cases. While the data we are requiring to be shared via these APIs would be nearly identical, they have different use cases, thus necessitating separate API regulatory requirements. We also encourage payers to reuse infrastructure for all the APIs. Payers may implement the API functionality by using one or multiple APIs, depending on their approach, as long as all requirements are met for each of the APIs.

Comment: Multiple commenters recommended that CMS align the technical standards provisions outlined in this rule with the HIPAA Standards for Health Care Attachments proposed rule (87 FR 78438). A commenter recommended that CMS work with ONC to do so. Another commenter stated that they support both rules and urged CMS to ensure that there are no duplicative efforts. Another commenter recommended removing the prior authorization provisions outlined in the HIPAA Standards for Health Care Attachments proposed rule and moving forward with finalizing FHIR-based standards and transactions. Another commenter encouraged CMS to work with ONC to align any prior authorization proposals with HHS's proposal to establish a national standard for electronic attachments.

Response: Requirements to use certain HIPAA transaction standards for prior authorization were proposed in the HIPAA Standards for Health Care Attachments proposed rule. These are related policies, and we will ensure a path toward implementation that will allow payers and providers to comply with both. However, because that rule has not been finalized, we cannot comment on how the standards would align with the policies in this rule. If finalized, in that final rule we would discuss the impact of those policies and any opportunities to align with our policies in this final rule. We will also continue to work with ONC on alignment between standards in this rule, and other standards adopted across CMS.

Comment: Multiple commenters recommended that CMS institute financial incentives for market suppliers, providers, and payers to participate in the testing and development of technical standards, IGs, and applicable processes. The commenter stated that one of the primary challenges of standards development and testing is a lack of financial and regulatory incentives for stakeholders to participate, which then slows down testing. Multiple commenters cautioned CMS to consider the cost of establishing the proposed API infrastructure. Another commenter noted that implementation will require integration between the newly acquired API functionality and the existing data sources, which includes exporting data from current systems to be imported and stored within a FHIR-compliant repository so that it can be presented via the API to the user. Multiple commenters requested that CMS provide technical assistance and resources to help the industry implement the APIs and meet all the technical standards and requirements outlined in this rule. Another commenter requested that CMS engage with stakeholders to develop resources and technical assistance to help industry operationalize and meet the proposed technical standards and API requirements outlined in the rule and any other parallel agency efforts.

Response: At this time, we lack statutory authority to provide financial incentives to participate in the testing and development of technical standards, IGs, and applicable processes. While we do not currently provide funding for IT infrastructure development costs (except for Medicaid agencies, as discussed in section II.E. of this final rule), we do provide educational webinars providing overviews of the technical requirements in the interoperability rules. Additional public resources also exist through HL7, such as their Connectathons, HL7 website resources, and HL7 FHIR workgroup meetings that are generally available. We also cohost an annual Connectathon with HL7, which is free for stakeholders to attend. Ultimately, each payer is responsible for ensuring that their users are trained on their systems.

Comment: A commenter stated that a frequent problem is that there is not a well-established or monitored mechanism for an implementer to contact a payer about implementation issues or implementation questions. The commenter stated that this is an important missing piece to making widespread implementation viable. The commenter reflected on the experience of third-party apps engaging with payers to implement the existing Patient Access API. They stated that third-party apps struggle with finding someone to fix issues, answer questions, approve their registrations, and address other barriers to implementation they experienced.

Multiple commenters stated that to support the proposed APIs, provider and payer endpoints must be included in a national directory, available to support endpoint discovery, before the compliance dates of the Provider Access, Payer-to-Payer, and Prior Authorization APIs. A commenter stated that a CMS NDH should be initiated to help find provider and payer endpoints. Another commenter stated that the lack of an authoritative central directory could create a significant gap in the ability for industry to move many critical interoperability initiatives forward. Another commenter stated the proposed technical standards for APIs is a helpful step to greater interoperability; however, CMS failed to properly account for the complexity of this implementation. The commenter recommended that CMS should implement a national directory so that each plan and provider must maintain only one incoming/outgoing connection.

Response: We acknowledge commenter concerns that there is not a monitored mechanism for contacting a payer about implementation issues or implementation questions. We thank the commenters for their concern that the lack of an authoritative central directory is a gap in the ability to move forward with interoperability initiatives. We do understand that a directory of payer and provider digital endpoints would be highly beneficial to facilitate our Payer-to-Payer, Provider Access, and Prior Authorization APIs policies, and as discussed in section I.D. of this final rule we are committing to exploring an NDH that contains payers' digital endpoints in support of the Payer-to-Payer API and providers' digital endpoints. We will also explore including payer contact information, including whom to contact regarding API implementation issues or questions, in any NDH we propose.

Comment: A commenter stated that adding standard data classes and data elements around high-priority use cases is an effective strategy to make data more accessible to consumers. The commenter noted that the Provider Directory and Patient Access APIs can serve as a base for the other proposed APIs. The commenter provided recommendations to help CMS achieve this goal such as establishing operational standards to help developers, requiring payers to register app developers and grant authorization to production access without regard to out-of-band consent standards payers choose to implement, and establishing stronger requirements for payers to make this information available. The commenter also recommended that (1) CMS require impacted payers to establish sandbox environments; (2) CMS impose a reasonable time standard to mitigate implementation delays; (3) CMS require impacted payers to perform conformance tests and report results to the public; and (4) CMS require that impacted payers' technical documentation for the Patient Access API notes what USCDI data are made available. Another commenter recommended that CMS should develop a roadmap in partnership with the private sector for all the technical use cases outlined in the proposed rule.

Response: We appreciate the additional suggestions, however, many of those were not proposed and therefore, we cannot include such provisions in the final rule. We also understand the value of a sandbox environment and acknowledge the value of payers establishing sandbox environments for implementers to test; however, we realize there are industry costs to doing so.

Comment: Multiple commenters encouraged CMS to consider alternative approaches to achieving data exchange. A commenter recommended that CMS consider other types of interoperability technology beyond APIs and request/response data exchange, which can lead to multiple copies of data. The commenter suggested CMS consider services that provide virtual real-time data updates. Another commenter recommended that CMS work with ONC to develop a future-looking approach to allow consumers to direct the sharing of claims data with third-party entities via a national exchange platform. A commenter recommended that CMS, ONC, and HL7 work together to build the infrastructure for a standard for ADT data.

Response: While we appreciate the commenters who asked us to consider services that provide virtual real-time data updates and we recognize the importance of needing the patient information as soon as possible or in real time, we also believe that requiring that at this time would cause undue burden on impacted payers. We nonetheless encourage payers to make data available to requesting providers as soon as they are able. We understand the concern over duplicative information, and it is not our intention to increase provider burden sharing data through the APIs referenced in this final rule. There are IT solutions available for providers' EHRs or practice management systems, such as SMART on FHIR apps, which can make the data received via the APIs actionable and avoid duplicative information. We also note that standards for ADT data are outside the scope of this final rule.

Comment: A commenter highlighted that health IT challenges can sometimes be larger than they appear. The commenter stated that regulatory requirements can be tailored to coincide with health IT functionalities that are currently available to support organizations in accomplishing interoperability in a more affordable way.

Response: We thank the commenter for their input and will continue to closely coordinate with industry to decrease implementation burden wherever possible.

Comment: A commenter urged CMS not to finalize the interoperability proposals until stakeholders have had a chance to review and comment on ONC's HTI–1 proposed rule, which was still under review at the Office of Management and Budget (OMB) at the time of publication of the CMS Interoperability and Prior Authorization proposed rule.

Response: We recognize that commenters are interested in ONC policies that relate to the policies in the proposed rule. ONC has since published the HTI–1 final rule. While related, these rules address separate areas of CMS and ONC authority. We are not finalizing any modifications from the proposed rule based on HTI–1 other than updating our regulatory citations and incorporating expiration dates ONC has finalized for particular standards at 45 CFR 170.215. Therefore, we did not offer an additional comment period.

Comment: Multiple commenters expressed appreciation for CMS not requiring health IT certification for the interoperability requirements outlined in this proposed rule. A commenter stated that establishing certification criteria based on the current HL7 Da Vinci IGs is premature. The commenter noted that providers must use data from CEHRT for the electronic prior authorization measure, which will serve as a spur for adoption of certified health IT. Another commenter noted that some of the proposed APIs require multiple health IT systems to interact and support a complex workflow and stated that establishing a certification approach using functional capabilities would be challenging, and encouraged CMS to engage with providers and payers to gather information to establish a well-defined and scalable set of guidelines and capabilities.

Opposite to that, a commenter recommended that CMS work with ONC to incorporate new standards and requirements for API use by EHR vendors as certification criteria in the ONC Health IT Certification Program.

Response: We did not propose and are not finalizing any other requirements related to certification under the ONC Health IT Certification Program in this final rule. However, we note that the Unified Agenda, at the time of this final rule's publication, includes an entry for a proposed rule from ONC (RIN 0955–AA06). The description indicates that that proposed rule aims to advance interoperability, including proposals to expand the use of certified APIs for electronic prior authorization. We plan to continue to explore how potential updates to the ONC Health IT Certification Program could support our policies and will address any updates to our requirements related to the Certification Program in future rulemaking.

Comment: A commenter recommended that CMS should establish a consistent set of technical standards between the TEFCA and CMS-required APIs so that the industry does not have to implement multiple different standards depending upon the exchange partner or mechanism for exchange.

Response: We refer readers to section II.B. of this final rule for a discussion on the interaction between policies that require API development or enhancement and TEFCA.

Comment: A commenter recommended CMS consider a policy requiring third-party payers, benefit managers, and any other party conducting utilization management to accept and respond to standard electronic prior authorization transactions for pharmacy benefits that use a nationally recognized format, such as the NCPDP SCRIPT standard. Similarly, another commenter stated that CMS should encourage health IT vendors and developers to provide retail pharmacies with technical IT infrastructure to bridge the gap between pharmacy claim systems and medical benefit claims systems and noted that many retail pharmacies only utilize the NCPDP standards and do not have the capability to enroll as DME suppliers and submit claims using X12 transactions. Another commenter recommended that CMS explore the need to designate an electronic transaction standard for drugs covered under a medical benefit.

Response: We appreciate stakeholders' interest in pharmacy standards and bridging the gap between pharmacy and medical benefit systems and we recognize the need to do so in the future. However, as noted in section I.D.3., standards for data exchange for any pharmacy claims and drugs covered under medical benefits are excluded from our policies and out of scope for this rule.

Comment: A commenter stated that under the ONC Health IT Certification Program, APIs must be registered within 15 days (45 CFR 170.315(g)(10)). However, the commenter stated that CMS did not impose any registration requirements for the proposed payer APIs. The commenter recommended that CMS should consider imposing a reasonable registration period for APIs to address delays reported by CARIN members throughout the onboarding and authorization process to acquire test accounts, sandbox access to test API connections, and troubleshooting support.

Response: We did not propose registration deadlines as a requirement for payer APIs in the same fashion as the health IT certification criterion at 45 CFR 170.315(g)(10), such that Health IT Modules certified to 45 CFR 170.315(g)(10) must register patient-facing applications within 15 days (per associated requirements at 45 CFR 170.404(b)); however, we acknowledge that such requirements can help to support the usability of APIs. We may further explore how to incorporate registration deadlines into our API requirements in future rulemaking.

Comment: A commenter recommended setting an implementation date before January 1, 2026, and mandating HL7 FHIR Release 4.0.1. The commenter also recommended operational enhancements for payers such as payers allowing longer lifespans on access tokens, payers not imposing unsupported security and authentication workflows, and payers supporting test accounts and synthetic data in production environments. The commenter noted that these recommendations would dramatically improve access to data from available open APIs while setting standards for payers and their interoperability vendors to follow.

Response: HL7 FHIR Release 4.0.1 has already been adopted by HHS in the ONC Cures Act final rule at 45 CFR 170.215 (85 FR 25521). We will continue to work with payers on testing and implementation of their interoperability APIs through FHIR Connectathons and encourage stakeholders to participate in FHIR workgroups. We will explore additional enhancements through future rulemaking.

Comment: A commenter recommended using the most recently approved HL7 Da Vinci IG that supports HL7 FHIR Release 4.0.1. The commenter stated that the SMART App Launch IG does not support HL7 FHIR Release 4.0.1.

Response: We thank the commenter for their recommendation, but we disagree that the SMART App Launch IG does not support HL7 FHIR Release 4.0.1, as the SMART App Launch IG is built on top of the FHIR Release 4.0.1 specification itself. The SMART App Launch IG specifies a number of capabilities, including user authentication and authorization, back-end service authentication, application launch, and context sharing, that systems can use to interact within the FHIR R4 standard.

Comment: A commenter sought clarification on the use case for the Bulk Data Access IG for the Patient Access API, since one of the biggest challenges for EHR vendors today is determining how to handle inbound data exchanged via the FHIR standard.

Response: We did not propose, nor are we finalizing, a requirement to require the Bulk Data Access IG for the Patient Access API.

b. Additional Implementation Guide Discussion

In the proposed rule, we discussed that several of the recommended IGs, such as HL7® FHIR® Da Vinci Payer Data Exchange (PDex) IG, build on specific profiles within the US Core IG (87 FR 7615). Following the publication of the HTI–1 final rule, at 45 CFR 170.215(b)(1) there are two adopted versions of the US Core IG: the US Core IG STU 3.1.1 (at 45 CFR 170.215(b)(1)(i)), until this standard expires on January 1, 2026, and the US Core IG STU 6.1.0 (at 45 CFR 170.215(b)(1)(ii)). We only proposed to require US Core STU 3.1.1 because it was the only version adopted at the time of the proposed rule. However, we recognize that some of the recommended IGs (and subsequent versions) may use profiles added in US Core IG STU 6.1.0. Payers can use updated versions of the recommended IGs that rely on newer versions of the US Core IG, if those updated versions meet our existing requirements finalized in the CMS Interoperability and Patient Access final rule (85 FR 25532), as discussed further below.

Specifically, in the proposed rule, we recognized that the data content for each API may only require a subset of the profiles defined within the US Core IG and gave examples (87 FR 76314–76315). While we want to ensure that implementers' systems create FHIR resources conformant to the US Core IG, where applicable, to support interoperability across implementations, we also do not want to require payers to engage in unnecessary development. Therefore, we proposed and are finalizing that impacted payers are only required to use technology conformant with the US Core IG, where applicable (that is, where there is a corresponding FHIR resource to the data content requirements for the API). If a FHIR resource is part of the required data content and has been profiled by the US Core IG, then the payer must support the FHIR resource according to the FHIR resource profile's “Structure Definition” in the US Core IG. For example, because the “Patient” FHIR resource is required in the Patient Access API, the “Patient” FHIR resource must conform with the “US Core Patient Profile,” including all the “mandatory” and “must support” requirements specified in the US Core IG.

c. Using Updated Versions of Required Standards

In the CMS Interoperability and Patient Access final rule (85 FR 25510), we established that impacted payers could use an updated version of a required standard for the Patient Access or Provider Directory APIs under certain conditions. Payers may use updated versions of standards at 45 CFR 170.213 and 170.215 if the following conditions are met: (1) the National Coordinator has approved the updated version for use in the ONC Health IT Certification Program, (2) the updated version of the standard does not disrupt an end user's ability to access the required data via that API, and (3) the updated standard is not prohibited by law (85 FR 25522). Payers may use an updated version if required by other applicable law. We proposed to extend this policy to allow payers to use updated versions of a standard to the Provider Access, Payer-to-Payer, and Prior Authorization APIs. Under that proposal, impacted payers could upgrade to newer versions of the required standards, subject to those limiting conditions (87 FR 76315).

One of those conditions for using updated versions of the standards at 45 CFR 170.213 and 170.215 is that the National Coordinator has approved the updated version for use in the ONC Health IT Certification Program. The National Coordinator approves updated versions of standards in the ONC Health IT Certification Program through SVAP, pursuant to 45 CFR 170.555, which was finalized in the ONC Cures Act final rule as a Maintenance of Certification flexibility included in the real-world testing Condition of Certification (85 FR 25775). This flexibility permits health IT developers to voluntarily use, in certain certified Health IT Modules, newer versions of adopted standards so long as specific conditions are met, providing a predictable and timely approach within the ONC Health IT Certification Program to keep pace with the industry's standards development efforts.

Under SVAP, after a standard has been adopted through notice and comment rulemaking, ONC engages in an open and transparent process to timely ascertain whether a more recent version of an adopted standard or implementation specification should be approved by the National Coordinator for developers' voluntary use in the ONC Health IT Certification Program. ONC publishes updated versions of standards under consideration for SVAP and lists the updated versions of standards that the National Coordinator has approved as part of the Interoperability Standards Advisory on HealthIT.gov . Members of the public can use this resource to review standards that may be approved through SVAP in the future, as well as provide input on which updated versions should be approved. We encourage impacted payers to review these resources to better understand how updated versions of the standards at 45 CFR 170.213 and 170.215 may be approved by the National Coordinator through SVAP and become available for payers to use in their APIs, provided other specified conditions for using updated standards are met. Several updated versions of the standards currently at 45 CFR 170.213 and 170.215 have been approved by the National Coordinator through SVAP, including USCDI v2 and v3; US Core IG STU 4.0.0, 5.0.1, and 6.1.0; SMART App Launch IG Release 2.0.0; and Bulk Data Access IG v2.0.0: STU 2. As soon as the National Coordinator approves updated versions through SVAP, we consider the updated versions to have met this condition for use by impacted payers for our API requirements. We emphasize that if impacted payers choose to use updated standards, it must not disrupt an end user's ability to access the required data. We are finalizing this proposal, as proposed.

Comment: Multiple commenters expressed support for CMS's proposal to allow flexibility for payers to use updated versions of certain standards and specifications required for APIs in the proposed rule. A commenter expressed support for aligning standards between the Patient Access, Provider Access, and Payer-to-Payer APIs, as this ensures data compatibility between use cases. Another commenter stated that the standards and specifications at 45 CFR 170.215 are more advanced and better aligned with present efforts to streamline prior authorization workflows by leveraging HL7's FAST work. Another commenter stated that these standards support widespread interoperability, ease implementation, and minimize complexity and costs. A commenter expressed strong support for CMS's efforts to promote portability of patients' EHI between providers and payers to assure continuity of care by further building on the common standards platform of FHIR APIs using USCDI, where applicable. Multiple commenters expressed support for the continued alignment between CMS and ONC regarding updates to technical standards and specifications through the rulemaking process.

Response: We acknowledge and thank commenters for their support of our policies.

Comment: A commenter stated that CMS's approach to mandating technical standards by referencing specific standards in regulation is novel for health information exchange. The commenter stated that prior data exchanges, such as the HIPAA standard transactions or the machine-readable files, have everything defined in the named specifications and not defined by reference to another standard in regulation. The commenter stated that having standards specified elsewhere allows for the referenced standards to be changed which would then have the cascading effect of requiring changes in all the APIs on the timeframe of the standard change for the APIs to remain conformant. The commenter disagreed with this regulatory approach and stated that it is better to have each API specified separately and to be self-contained (that is, not having referenced standards). The commenter stated that this way individual APIs could be evaluated for change on their own merits, as standards in the HIPAA Standards for Health Care Attachments proposed rule are currently being evaluated with the potential change in the version for the X12 278 transaction standard for attachments under HIPAA (version 6020) or for the X12 837 transaction standard for claims, and the X12 835 transaction standard for remittance advice being recommended by X12 for consideration to X12 8020 transaction standard for plan premium payments, or the recommended upgrade of three other X12 transactions to version 8030, including claim status, health plan enrollment, and health plan premium payments.

Response: We appreciate the commenter's concerns regarding the timing of updates to required standards via reference to other regulations. We intend to collaborate with ONC to ensure updates to standards are deployed with reasonable timeframes and sufficient advance notice for payers to make any required updates to their APIs. Aligning with the HHS-adopted API standards and associated implementation specifications at 45 CFR 170.215 is important to ensure consistency. We are finalizing the versions of the required standards that were at 45 CFR 170.215 at the time of this proposed rule. However, ONC has since finalized the HTI–1 final rule (89 FR 1192), which adopted updated versions of certain standards including the US Core IG STU 6.1.0 (at 45 CFR 170.215(b)(1)(ii)) and the SMART App Launch IG Release 2.0.0 (at 45 CFR 170.215(c)(2)). Additionally, ONC has finalized expiration dates for the US Core IG STU 3.1.1 (at 45 CFR 170.215 (b)(1)(i)) and the SMART App Launch Framework IG Release 1.0.0 (at 45 CFR 170. 215(c)) to indicate when a version of a standard may no longer be used. We intend to align with the updated versions finalized at 45 CFR 170.215 through future rulemaking prior to the API compliance dates. While we did not propose to require those updated versions, we emphasize that impacted payers are permitted to use them based on our policy to allow updated versions of required standards, as discussed below.

The update and review process for HIPAA transaction standards follows a statutory review process but does not include the same testing and balloting process we require for the standards and IGs. Furthermore, the HL7 standards and IGs adopted by ONC may be updated for use in the ONC Health IT Certification Program through the SVAP. We rely on this flexibility in our update policy by allowing payers to use versions of standards at 45 CFR 170.213 and 170.215 that have been approved by the National Coordinator, enabling a nimble approach to industry testing and innovation. This does not currently exist under the HIPAA standard transaction reference model process.

Comment: Multiple commenters recommended that CMS update the clinical data requirements to USCDI v2. The commenters also recommended that CMS give guidance on if and when USCDI v3 and v4 may be required. The commenters noted that use of these updated standards would advance health equity and public health work. A commenter strongly recommended that impacted payers incorporate data elements identified in a newer version of the USCDI, specifically USCDI v3, instead of the proposed USCDI v1. The commenter noted that USCDI v1 does not constitute an elaborated list of data elements compared to the most recent versions, which incorporate elements that play a critical role in electronic data exchange. Another commenter requested CMS and ONC provide guidance regarding using newer versions of USCDI and associated US Core IG. The commenter noted that this guidance will be helpful when multiple versions of the USCDI are available for use, so all third-party app developers have clear expectations and understanding regarding what data they need to be able to share and receive.

Response: As discussed in section II.A.2.d., we are finalizing a change to the required data content for the Patient Access, Provider Access and Payer-to-Payer APIs to a standard listed at 45 CFR 170.213. At the time of the CMS Interoperability and Prior Authorization proposed rule, USCDI v1 was the only version of the USCDI adopted at 45 CFR 170.213. However, ONC has since published the HTI–1 final rule, which establishes a January 1, 2026, expiration date for USCDI v1 and adopts USCDI v3 at 45 CFR 170.213. After January 1, 2026, USCDI v3 would be the only version specified at 45 CFR 170.213 that has not expired (89 FR 1192). In this way, the required version of the USCDI for the APIs in this final rule will advance in alignment with versions adopted by ONC in 45 CFR 170.213. When more than one version of USCDI is adopted at 45 CFR 170.213 and have not expired, payers may conform to either version.

As stated previously in this section, we are also finalizing our proposal that an updated version of a standard could be used if it is required by other law, or if ONC has approved the updated version for use in the ONC Health IT Certification Program, users are able to access the required data via the API, and it is not prohibited by other law. In order to identify updated standards that have been approved for use in the ONC Health IT Certification Program, payers can review the standards approved through the SVAP on ONC's website https://www.healthit.gov/isa/standards-version-advancement-process, as well as standards that are being considered for approval through SVAP (new standards for SVAP are approved annually).

We note that USCDI v2 was approved in the 2022 SVAP cycle, while USCDI v3 was approved as part of the 2023 SVAP cycle. We also note that several updated versions of the US Core IG subsequent to the required US Core IG STU 3.1.1 have been approved by the National Coordinator through the SVAP and are available for payers to use under this policy, including US Core IG STU 4.0.0, 5.0.1, and 6.1.0.

The US Core IG is updated annually to reflect changes to the USCDI, and each US Core IG version is built to a specific version of the USCDI. For instance, US Core IG STU 3.1.1 is built to USCDI v1 and the US Core IG STU 6.1.0 is built to USCDI v3. As the recommended IGs continue to be refined and advance, they may reference different versions of the US Core IG based on updated versions of the USCDI. Implementers are encouraged to adopt the newer versions of the recommended IGs as they are published. Consistent with our final policies to allow payers to use updated standards at 42 CFR 170.215 if they have been approved by the National Coordinator for use in the ONC Health IT Certification Program and other conditions, implementers may use updated versions of US Core referenced to the specifications in recommended IGs. HL7 and the FHIR Accelerators are aware of these concerns and are working on an approach to enable greater version support for IGs.

Comment: Multiple commenters supported flexibility to use updated standards, such as ONC's SVAP for certified health IT developers, to allow payers to use the most current recognized versions of vocabulary standards and interoperability standards or specifications used in the certification. A commenter stated that CMS should only require new versions of standards, specifications, and IGs after testing and adequate time for implementation. Another commenter stated that the mechanism to allow implementers to advance versions of standards in this rule as long as using an updated standard does not impair access to data through the API can be used for any or all IGs used to support these APIs or related auxiliary processes (for example, patient attribution).

Response: We appreciate the support for this policy. The standards we are requiring in this final rule are those that we believe are sufficiently mature. We intend for future rulemaking to operate similarly. As stated, payers can implement the latest versions of the required standards and IGs as long as they meet the specified conditions, such as not impairing access to data through the API.

Comment: Multiple commenters stated that use of specific FHIR-based standards, specifications, and IG versions should align with those approved by ONC through SVAP. A commenter stated that CMS requirements and adoption timelines should remain coordinated with ONC's progression. The commenter suggested that CMS use a more general reference to the ONC Health IT Certification Program and SVAP. Another commenter stated that ONC will be providing a more current set of standards and specification versions soon through ONC Health IT Certification Program updates. The commenter stated that it is imperative that CMS require developed APIs to conform to the most recently approved SVAP standards within 12 months of approval. The commenter also recommended that CMS coordinate with ONC to include more standards and IGs in the SVAP to align with the rule. The commenter also recommended that CMS include a transition period (for example, 12 months).

Response: We appreciate the commenters feedback and remind readers that under this final rule, in addition to our coordination with ONC, payers are permitted to voluntary use updated standards provided it does not disrupt an end user's ability to access the data available through the API. In addition, implementers may advance to those standard versions approved by the ONC through SVAP.

We decline at this time to set a timeline by which we would require impacted payers to use the updated version of the standard rather than the adopted version of the standard. We believe the voluntary nature of the SVAP supports a transitional period—also a request from commenters—by allowing for a flexible implementation of standards versions between regulatory cycles during which ONC revises the adopted version to the latest update for each standard. We will continue to engage with patients, providers, payers, health IT developers, and our Federal partners to ensure that this approach balances the need to advance standards with the need for flexible transition periods for updates. We will also continue to work with ONC in their efforts to support HHS and the health care industry through the advancement and adoption of interoperable standards and implementation specifications for a wide range of health IT use cases.

We support innovation and continued efforts to refine standards in a way that will leverage the most recent technological advancements. Thus, we also sought comment on the process we should use to adopt or allow new versions of standards and implementation specifications over time. We received many comments in response to our request for comment and will consider this feedback for future rulemaking and guidance. We are finalizing the proposal to allow payers to use an updated standards, specifications, or IGs if required by law, or if the updated standard, specification, or IG is approved for use in the ONC Health IT Certification Program, do not disrupt an end user's ability to access the required data, and is not prohibited by law for each of the APIs at the CFR sections listed in Table H2.

3. Recommended Standards To Support APIs

In the CMS Interoperability and Patient Access final rule (85 FR 25529), we noted that there are publicly available IGs that provide implementation information that impacted payers can use to meet the regulatory requirements for these APIs. Using those IGs supports interoperability and allows impacted payers to avoid developing an approach independently, which could save time and resources. In this final rule, we are recommending specific IGs that are relevant to each of the APIs, which may be used in addition to the required standards at 45 CFR 170.215.

In the December 2020 CMS Interoperability proposed rule, we proposed to require impacted payers to use certain IGs, including the CARIN IG for Blue Button®, HL7® FHIR® Da Vinci PDex IG, HL7® FHIR® Da Vinci PDex U.S. Drug Formulary IG, HL7® FHIR® Da Vinci PDex Plan Net IG, HL7® FHIR® Da Vinci Coverage Requirements Discovery (CRD) IG, HL7® FHIR® Da Vinci Documentation Templates and Rules (DTR) IG, and HL7® FHIR® Da Vinci Prior Authorization Support (PAS) IG (85 FR 82586) to support the APIs in that proposed rule. As discussed in section I.A. of this final rule, we are withdrawing the December 2020 CMS Interoperability proposed rule. We also noted that these IGs continue to be developed and refined through the HL7 ballot and standard advancement process to better support the Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization APIs.

a. Recommending vs. Requiring Implementation Guides

In the CMS Interoperability and Prior Authorization proposed rule, we proposed to recommend CARIN for Blue Button, PDex, PDex U.S. Drug Formulary, PDex Plan Net, CRD, DTR, and PAS IGs for specific APIs, as listed in Table 10 of the proposed rule (87 FR 76320). We also solicited comments on whether CMS should propose to require these recommended IGs in future rulemaking and other ways that we could support innovation and interoperability. We emphasize that while we are not requiring payers to use the recommended IGs listed in Table H3, we may propose requiring payers to use these and other IGs in future rulemaking, should they reach sufficient maturity.

After careful consideration of the versions of the IGs that were available at the time of the proposed rule, we determined that we were not ready to propose them as requirements. We stated that we believed these IGs would continue to be refined over time as interested parties have opportunities to test and implement them, and as such, we chose to recommend them rather than require them. Specifically, we stated we would continue to monitor and evaluate the IG development and consider whether to propose them as a requirement at some future date. In this final rule, we are finalizing our recommendation to use the CARIN for Blue Button, PDex, PDex U.S. Drug Formulary, PDex Plan Net, CRD, DTR, and PAS IGs for the Patient Access, Provider Access, Provider Directory, Payer-to-Payer, and Prior Authorization APIs, as applicable and listed in Table H3. We also note that several of the recommended IGs have had updated versions published since the CMS Interoperability and Prior Authorization proposed rule. Thus, we have updated Table H3 accordingly to represent the most recent published versions of the recommended IGs. Because these are only recommended IGs, we do not codify version updates through rulemaking.

We acknowledge that by recommending rather than requiring certain IGs, there is potential for implementation variation that could limit interoperability and ultimately lead to rework for implementers if requirements are introduced later. However, we concluded at the time of the proposed rule that it was more important to not require the IG versions available at that time due to the maturity of the versions available. We recommended, but did not propose to require, these IGs because we wanted to ensure that implementers can use subsequent versions of these IGs without being restricted to the version available when we issued the notice of proposed rulemaking. As discussed in section II.G.2.c. of this final rule, we are finalizing a provision to allow payers the flexibility to use updated versions of certain standards required for the APIs in this final rule. In the CMS Interoperability and Prior Authorization proposed rule (87 FR 76316), we acknowledged that subsequent versions of the recommended IGs may include substantial changes that would not be consistent with the requirement that an updated standard must not impair access to data through the API. We intend to monitor IG development and may propose to require specific IGs at a future date and/or allow for voluntary updates under our flexibility policies. We received comments on our decision to recommend, rather than require the listed IGs in the proposed rule.

Comment: Multiple commenters appreciated CMS's decision to recommend rather than require the CARIN for Blue Button, PDex, PDex U.S. Drug Formulary, PDex Plan Net, CRD, DTR, and PAS IGs. A commenter supported CMS's decision to recommend instead of requiring IGs given that some of the standards and IGs are not yet mature enough for industry adoption. Another commenter appreciated CMS's decision to recommend rather than require IGs due to the interplay between this rule and the HIPAA Standards for Health Care Attachments proposed rule.

Response: We thank commenters for their support of our decision to recommend certain IGs in the proposed rule, which we believe balanced the need to provide guidance and flexibility to industry as standards advance.

Comment: Multiple other commenters supported the recommended IGs, but noted concern that these IGs do not have enough outside involvement in the development phase, which could result in gaps in workflows. However, the commenters noted that they are confident that the HL7 Accelerator workgroups will provide the necessary maturity if given sufficient time.

Response: These standards development activities do have outside parties involved throughout the standards development process. We encourage all interested parties, especially those who already have the experience implementing the APIs, to engage with the process. HL7 and the Accelerators welcome and solicit feedback for all of their IGs and specifications. Meeting participation is largely open to the public, and one does not have to be a member to participate in testing events and many other standards development activities.

Comment: Multiple commenters disagreed with CMS's decision to recommend rather than require the IGs and expressed concern for CMS's decision to not require certain IGs, with one concerned that not requiring the IGs will impact the level of interoperability necessary to support data exchange. Commenters urged CMS to consider the potential for implementation variation in APIs and limit industry-wide interoperability. Multiple commenters expressed that it is important that adherence to IG requirements is required, not just encouraged, to ensure the industry adopts these to obtain the benefits of the near real-time Prior Authorization API transactions. Another commenter recommended that CMS adopt and require IGs as quickly as possible. The commenters stated that without IGs, there is a risk that early work done by health IT developers and the health care community will have to be refactored or restarted to meet the IG guidelines. A commenter stated that CMS should act swiftly to encourage the creation of more appropriate IGs and recommended that CMS work with payers to create electronic systems and interfaces that are consistent and easy to use.

Another commenter stated that not requiring certain IGs is not in line with the interoperability goals and prior authorization initiatives outlined in this rule to obligate providers to report on their adoption of this technology if that technology will not be uniformly adopted and implemented between different payers. A commenter stated that it is critical that all data contributors be held to the same set of rules and required to adopt the same standards and IGs. To ameliorate this, the commenter recommended that the IGs be required rather than recommended, and that a mere recommendation may result in more burden and duplicative work. A commenter stated that because CMS is not requiring certain IGs, it is unfair and contrary to the goals of these interoperability and prior authorization initiatives to obligate MIPS eligible clinicians, eligible hospitals, and CAHs to report on their adoption of this technology when that technology will not be uniformly adopted and implemented between different payers.

Multiple commenters recommended that CMS require impacted payers to use the CARIN for Blue Button, HL7® FHIR® Da Vinci Patient Coverage Decisions Exchange (PCDE), PDex, PDex U.S. Drug Formulary, PDex Plan Net, CRD, DTR, and PAS IGs while allowing for adaptability and advancement of those IGs over time. A commenter stated that requiring certain IGs would move payers toward standardized data exchange. A commenter noted that most of the IGs have been around for several years, and most have been tested in multiple Connectathons, pilot projects, and in production environments. The commenter believes having consistent, well-understood data fields with clear meaning that everyone uses the same way is a key element of any API or any successful data exchange. The commenter stated that using standard IGs would move industry toward interoperable data exchange.

Response: We received a significant number of comments on both sides regarding requiring IGs and not requiring IGs, which indicates that there is not broad agreement across the industry. In the proposed rule, we sought to strike a balance by requiring the standards and IGs adopted at 45 CFR 170.215 in alignment with ONC and recommending additional IGs for each API implementation. We acknowledge that by not requiring all the available IGs, there is potential for implementation variation in these APIs that could limit interoperability and ultimately lead to re-work for implementers if requirements are introduced later. However, at the time of the proposed rule, we believed it was more important not to require these IGs while they were still undergoing additional enhancements. We disagree with the concern that our decision to not propose to require certain IGs is unfair and contrary to the goals of these interoperability and prior authorization initiatives of this final rule. The required standards at 45 CFR 170.215 mean that impacted payers must implement these APIs using the FHIR standard, which will advance interoperability. We continue to strongly recommend using the other recommended IGs listed in Table H3.

As stated previously, we also believe that the approach in the proposed rule of recommending, but not requiring, the specific IGs and versions provided directional guidance with flexibility to the industry in order to allow for additional improvements to be made without locking implementers into versions of the IGs available at the time of the proposed rule. Under the recommendations in the proposed rule, as these IGs progress, industry could continue to harmonize on common approaches that work, eventually culminating in a required set of specifications when ready through updates to CMS policy. To not identify any specific IGs would have meant a more diverse set of proprietary solutions with little to no interoperability. Our recommendations provide direction to implementers.

Comment: A commenter stated that the development and maintenance of standards and IGs are an extension of Federal policy that does not go through the rulemaking process. They noted that it is critical that this development and maintenance process be consensus-based, fair, transparent, and open to all stakeholders. The commenter continued by stating that the IG creation process is currently driven by a limited number of volunteers that do not broadly represent the industry, which results in IG resource and profile versioning issues. The commenter stated that CMS should ensure there is no fee to fully participate in the process for the regulatorily required exchanges and relying on an American National Standards Institute (ANSI)-accredited process to develop the IGs would improve the approach.

Response: We acknowledge that standards and IGs are not developed through the rulemaking process. Rather, standards and IGs go through the rulemaking process if and when they are proposed to be adopted. We also appreciate that commenters are invested in the quality of the IGs and the SDO, and affirm, as we stated in the CMS Interoperability and Patient Access final rule (85 FR 25540), that development and maintenance of standards are the purview of SDOs, and that interested parties, including Federal agencies, participate in that process. Stakeholders have the opportunity for review and comment on the standards both at the time they are being developed, as well as during the proposed rule comment period. HL7 is an ANSI-accredited SDO, and Da Vinci is an accelerator workgroup under the umbrella of HL7 and operates under the same rules of all ANSI accredited SDOs in the manner in which they obtain consensus on standards. Furthermore, HL7 standards are free and open-source, and documentation is available to anyone to ensure that all developers can equally access information. Using these freely available materials will reduce the development burden for both payers and app developers and facilitate industry-wide interoperability. Similarly, participation in online working meetings and providing feedback as part of the standards development process is free, and diverse organizational representation is critical to the quality of the standards and IGs. Thus, we encourage as many organizations as possible with a stake in the development and quality of these guides to participate. HHS uses different authorities to adopt and require standards that are developed and maintained by organizations such as HL7 using the processes described previously. For instance, ONC has adopted the standards and implementation specifications at 45 CFR 170.215 cross-referenced in this final rule under the authority of section 3004 of the Public Health Service Act.

Comment: A commenter suggested CMS emphasize that using the IGs is not limited to literal use, but also interpretive use to model interactions within the respective health IT configuration in a way that is illustrative rather than prescriptive.

Response: IGs contain both SHALL and SHOULD statements, which respectively indicate whether health IT systems must meet certain requirements to conform to the IG or are just strongly recommended to. While implementers will be required to conform with the required IGs we are finalizing, we remind readers that the recommended IGs can be implemented as they see fit as long as they meet the requirements of the API.

b. Implementation Guide Maturity

In the proposed rule, we welcomed further information about the maturity of the recommended IGs, including considerations about further development that may be needed prior to us proposing to require the IGs we recommended (87 FR 76317).

Comment: Multiple commenters expressed concern regarding the maturity, scalability, and real-world testing of the IGs recommended in the proposed rule. Multiple commenters were concerned that there may be compatibility issues between the current and future versions of the IGs given that the IG versions are not currently finalized. A commenter stated that slight variations in API implementation could significantly increase burden placed on the provider community. A commenter recommended that CMS and ONC issue guidance on what could be expected in the IG guidelines to inform early work and to encourage as much fidelity to these IGs as possible.

Response: We are committed to continuing to work with HL7, the Accelerators, and interested parties within the industry to define, participate in, and convene testing events, as well as developing and maintaining the specifications, thereby moving them toward greater maturity. We acknowledge that, as with any standard, potential compatibility issues could arise throughout development. These standards are subject to a standards development process where changes are reviewed and compatibility is an important consideration, increasing with the level of use and adoption. As IGs mature, the number of potential compatibility issues between versions is expected to decrease. Likewise, as IGs continue through the standards development process, they will be enhanced to address areas of variance among payers that are barriers to interoperability. We determined that it was important to recommend these IGs to move the industry and provide direction towards a common set of specifications, as opposed to not including these recommendations, which would lead to a greater number of variations and cause a greater burden.

Comment: A commenter recommended that CMS explain that support for SMART Backend Services specification is also required with the Bulk Data Access IG. Another commenter stated that significant limitations exist for the Bulk Data Access IG and OpenID Connect Core standard. The commenter noted that it is unknown when the Bulk Data Access IG will be ready for implementation and use on a large scale.

Response: The Bulk Data Access IG v1.0.0: STU 1 includes the option for SMART Backend Services specification to enable system-to-system authentication and authorization of backend services. The Backend Services specification that was included in Bulk Data Access IG v1.0.0: STU 1 was moved to SMART App Launch IG Release 2.0.0. Therefore, we strongly recommend that the SMART Backend Services specification of the SMART App Launch IG Release 2.0.0 be supported and thus have included this recommendation for both the Provider Access and Payer-to-Payer APIs in Table H3. We acknowledge that not all connections may use backend services, but when such services are available, payers may wish to use the HL7 SMART Framework. More recent versions of the SMART App Launch IG specification, starting with Release 2.0.0, incorporate the SMART Backend Services, which ONC has adopted in the HTI–1 final rule at 45 CFR 170.215(c). We further remind readers that though we are requiring impacted payers to support Bulk Data Access IG for the Provider Access and Payer-to-Payer APIs in this final rule (Table H3), payers are free to set their own criteria for using bulk data exchange.

Comment: A commenter recommended that CMS delay API implementation until the recommended IGs are ready to be required. The commenter noted that the proposed APIs are not feasible without standardized adoption and expressed concern that the necessary IGs to implement the APIs are not mature, tested, or ready to scale. A commenter suggested that CMS should work with interested parties across the health IT community to propose and finalize IGs that are not mature prior to mandating their use.

Response: We remind readers that we are finalizing 2027 compliance dates for the policies that require API development and enhancement partly to allow industry additional time to implement the needed functionality within their internal systems. By requiring some IGs and recommending others, we believe that we achieved the appropriate balance between moving industry forward, while allowing flexibility for continued development of IGs that were not sufficiently mature at the time of the proposed rule to propose to require.

Comment: A commenter encouraged CMS to take on an active role in the continued development and testing of the HL7 Da Vinci IGs. The commenter recommended that CMS review and release a formal assessment of the technology development no later than July 1, 2024.

Response: We are a member of HL7 and monitor their activities by attending the HL7 Da Vinci workgroups, providing contract support for the development of the IGs, and tracking the ballot process. Through these efforts, we are continuously engaged in IG development and maintenance. We thank commenters for their suggestion but note that the request to release a formal assessment of technology development no later than July 1, 2024, is out of scope for this final rule.

Comment: Multiple commenters urged CMS to identify a baseline or “floor” version of the technical standards and IGs, and multiple other commenters recommended CMS develop a formal standards advancement process, like the SVAP, to give industry the opportunity to continue refining, testing, and deploying new versions. Multiple commenters noted that requiring an updated version of an IG as a baseline requirement must be done officially through government regulation. Another commenter recommended CMS develop a strategy or a process to decide which version of IGs or standards should be required. A commenter believed that all interested parties should agree upon IGs for each of the APIs. The commenter stated that in the final rule, CMS should identify the requirements, including IGs, for all interested parties. Another commenter recommended that CMS explain the functionalities of specific IGs they would like applied to each of the APIs.

Multiple commenters urged CMS to work with interested parties to identify a limited number of IGs to require so industry is not overwhelmed with too many IGs. Moreover, multiple commenters expressed concern about requiring more than one IG for specific API implementations and requested that CMS only require one IG. A commenter noted they support clear and unambiguous standards to achieve true interoperability.

Response: The required standards and recommended IGs for each of the APIs are listed in Table H3 and represent the minimum expected of impacted payers. The FHIR IGs have been developed to fulfill a specific purpose and therefore requiring more than one IG for a specific API is appropriate. Specifically, the IGs we are recommending all have individual purposes and we are only recommending those relevant to each API as listed in Table H3. We also remind interested parties that the IGs go through a consensus-based process and participation in the online meetings and providing feedback is free, thus, we encourage as many organizations as possible with an investment in the development and quality of these guides to participate.

Comment: Multiple commenters recommended that CMS explain how technical standards and IGs will be mapped to specific API functionalities.

Response: We refer readers to Table H3 for an outline of which standards and IGs pertain to which APIs. We also remind readers that our recommended IGs can support the required standards for the specific API we are recommending them for.

Comment: Multiple commenters expressed support for work done by the CARIN Alliance, which provides a method for all payers to make submitted and processed claims data available to patients and has sufficient maturity to ensure a successful implementation. Multiple commenters requested that CMS consider mandating the CARIN IG for Blue Button. A commenter stated that otherwise, stakeholders will have to support multiple IGs, which adds burden and increases technology complexity making development and implementation challenging. Multiple commenters expressed support for clear and unambiguous standards.

A commenter stated the CARIN IG for Blue Button already produces an EOB for in-patient, out-patient, professional, pharmacy, dental, and vision services through a set of FHIR profiles. The commenter noted that these same profiles could provide the required non-financial view of the EOBs to meet the requirements outlined in this proposed rule by using the “Summary View” returned by FHIR's summary parameter search.

Response: We agree about the importance of the CARIN Alliance's work. However, for reasons explained in section II.G.3.a. of this final rule, we did not propose to require several IGs which are listed in Table H3 as Recommended IGs, including the CARIN IG for Blue Button. Regarding the recommendation to leverage the non-financial view of a CARIN IG for Blue Button, we note that in order to do this, the CARIN IG for Blue Button would need to be updated, or other guidance provided to support this requirement, and that the data be made available through the appropriate API. Work is currently underway in CARIN and in coordination with HL7 Da Vinci PDex workgroup to define this guidance.

Comment: A commenter noted that a September 2021 Frequently Asked Questions (FAQ) document published by CMS states that payers would be compliant with the Patient Access API requirements if they used the CMS-recommended IG (CARIN for Blue Button IG v1.1.0: STU 1) to build their APIs, but that that IG version does not enable the inclusion of dental or vision claims, which were added in the most recent version. Multiple commenters supported guidance or rulemaking to support oral and vision claims using the CARIN IG for Blue Button v2.0.0: STU 2 version.

A commenter recommended that CMS reaffirm that impacted payers would be compliant with the requirements for the Patient Access and Provider Access, and Payer-to-Payer APIs if they follow the CMS recommended IGs. The commenter also recommended that CMS further explain that the absence of dental and vision claims information in the proposed APIs would not result in payer noncompliance given that the recommended CARIN IG for Blue Button does not include dental and vision claims.

Response: At the time the proposed rule was drafted, the CARIN IG for Blue Button v1.1.0: STU 1 was the latest published version for use. Since then, CARIN IG for Blue Button v2.0.0: STU 2 was released, which indeed includes dental and vision (vision as part of the professional and non-clinician profile). We are therefore modifying our recommendation listed in Table H3 to “HL7 FHIR Consumer Directed Payer Data Exchange (CARIN IG for Blue Button) IG v2.0.0: STU 2.” In addition to the required standards listed in Table H3, if impacted payers use the recommended IGs also listed in Table H3 for the APIs and follow the IGs to specification to build their APIs, they would be conformant with the technical requirements.

Comment: A commenter expressed support for exchanging data via FHIR APIs and noted that the PDex IG STU 2.0.0 includes a prior authorization profile to share prior authorization information, but this profile is not yet published. However, another commenter noted that the HL7 Da Vinci PDex workgroup is actively completing an initial set of updates to the PDex IG to facilitate sharing prior authorization information and that the workgroup will make any necessary revisions to support the provisions outlined in the proposed rule to include any related administrative and clinical documentation. Another commenter was concerned that some of the proposed data elements for prior authorization have not yet been profiled within FHIR IGs.

A commenter stated that payers should already have familiarity with the PDex IG as it was recommended as part of the Patient Access API. The commenter continued that using the PDex IG to support the new set of information will also reduce burden.

Response: The recently published PDex IG STU 2.0.0 specification does include a Prior Authorization profile that enables payers to communicate prior authorization decisions and changes to the status of a prior authorization requests. Based on feedback and developments in the industry, in addition to the required IGs and previously recommended IGs, we are now recommending the PDex IG STU 2.0.0. for the Patient Access, Provider Access, and Payer-to-Payer APIs, as listed in Table H3. We are delaying the compliance dates for the APIs finalized in this rule to 2027, which allows for additional time for the FHIR standard and IGs to continue to be refined and advanced to support all of the policies in this final rule.

Comment: A commenter noted that the proposed rule suggested that the Provider Directory API finalized in the CMS Interoperability and Patient Access final rule will be conformant with the PDex Plan Net IG STU 1.1.0. A commenter stated their belief in standards-based methods for the electronic transmission of health information. The commenter continued that successful standards-based conveyance of digital health care information relies on clear and unambiguous standards that apply across the industry. The commenter stated that the PDex Plan Net IG meets this requirement.

Response: We agree with commenters on the utility of the PDex Plan Net IG, and are thus recommending its use for the Provider Directory API.

Comment: Multiple commenters recommended CMS and HL7 ensure the CRD, DTR, and PAS IGs are fully tested prior to the effective date of the final rule, as the IGs have not been adequately or widely tested in real-time clinical settings. A commenter expressed concern with required versus situational data elements in the current versions of the recommended IGs outlined in the proposed rule. The commenter noted that the CRD, DTR, and PAS IGs have data elements and processes that are listed as optional despite their utility for automation. Another commenter provided the example that the CRD IG does not require the return of documentation templates and rules, so the provider would be required to initiate a separate transaction to determine the requirements for a prior authorization. Additionally, this commenter stated that the CRD IG allows for hyperlinks to be returned to the provider. The commenter stated that this means that a valid response to a coverage requirements discovery request can be a hyperlink to a third-party prior authorization vendor where the provider would have to initiate a prior authorization request through a provider portal and drop to a manual process outside of their EHR and practice management system.

Response: The HL7 Da Vinci IGs that we recommend specifically for the Prior Authorization API are the CRD, DTR, and PAS IGs. These were created as three distinct IGs that were loosely coupled instead of created as a single IG in order to provide implementation flexibility and the ability to disconnect the processes where necessary. A number of optional or “situational” elements are included in these guides to connect them into a single workflow where needed. While we value the specificity of other comments regarding the functions of the IGs, such as hyperlinks and connecting to external portals, these are the purview of the HL7 Implementation division. We will work with HL7 and implementers to coordinate appropriate support for such questions prior to the compliance dates.

Comment: A commenter stated that it was their understanding that the HL7 Da Vinci PCDE IG was developed with minimal payer input. The commenter stated that there may be a need for additional time for impacted payers to understand and implement the IG. Furthermore, the commenter expressed concern that the PCDE IG only addresses the movement of data between the provider and payer and does not address the back-end systems that will need to ingest and process new information for continuity of care. The commenter urged CMS to continue exploring other opportunities to promote data exchange. The commenter acknowledged that there are many industry solutions being developed to facilitate the coordination of benefits between providers. The commenter stated that these options could prove to be better solutions for the industry in the future and recommended that CMS continue to monitor and enable technical innovation in this area.

A commenter noted that CMS has included two mentions of the PCDE IG. They stated that there is one reference in the preamble of the proposed rule (87 FR 76336); however, in the preamble “Payer Coverage Decision Exchange” is followed by a parenthetical reference to “PDex.” The commenter stated that the PCDE IG was also listed in Table 10 (87 FR 76321), though, there are no additional or substantive mentions of the PCDE IG in the proposed rule. The commenter believes that it is possible the mention of the PCDE IG was unintentional.

Response: We acknowledge that the PDex IG has expanded to include prior authorization data and development of PCDE IG is not currently active. Thus, while we acknowledge the drafting error the commenter previously noted, we are no longer recommending the PCDE IG for the Payer-to-Payer API.

Comment: A commenter suggested that CMS consider recommending the HL7® FHIR® Member Attribution (ATR) List IG, which is currently in the publication process. The commenter stated this IG focuses on attribution lists for risk-based contracts and it could serve as an exchange standard for all payers.

Response: While we did not include the ATR List IG as one of recommendations listed in Table H3, we note that industry expects that the next version will be published well before the compliance dates for API development and enhancement policies in this final rule. Payers are permitted to use the ATR List IG, and we will explore including it, either as a recommendation or requirement, in future rulemaking.

Comment: Multiple commenters recommended that CMS consider leveraging the HL7 FHIR Da Vinci Reducing Clinician Burden (RCB) IGs. A commenter shared that revisions to the RCB IGs are underway to make prior authorization documentation supporting medical necessity, which is assembled by the ordering provider, available to the performing provider. The updated IG is currently titled FHIR Orders Exchange (FOE), and updates should be balloted in the September 2023 SVAP cycle. Another commenter stated that they believe RCB IGs would help industry work towards future readiness for a certified Health IT Module(s) to be included within the ONC Health IT Certification Program.

Response: We thank commenters for their suggestions and will consider them for future rulemaking.

Comment: A commenter stated that the HL7® FHIR® Da Vinci Clinical Data Exchange (CDex) IG would enable providers to obtain additional information that may have been missing or not yet available on the initial order request.

Response: Though we neither proposed nor recommended the CDex IG, we recognize that the CDex IG is being developed to exchange attachments via the Prior Authorization API. Impacted payers are permitted to use the CDex IG and are encouraged to participate in the ongoing testing as the IG is further developed. Though HL7 has included the ability to exchange attachments in its suite of IGs, and this would be available for use voluntarily, this final rule does not address health care attachments. We will consider either requiring or recommending the CDex IG in future rulemaking.

Comment: A commenter recommended using the HL7 Da Vinci DTR IG to specify how payers codify their rules in clinical quality language for real-time determination.

Response: We are currently recommending the DTR IG for the Prior Authorization API. We will continue to monitor and evaluate the development of the recommended IGs listed in Table H3 and consider whether to propose them as a requirement at some future date.

c. Authentication and Authorization

Comment: Multiple commenters encouraged CMS to work with HL7 to integrate the UDAP into the IGs created by HL7. A commenter stated that a security framework based on a tiered OAuth security specification is required to enable the scalable exchange within trust frameworks. The commenter stated that industry will not be able to implement at scale based on how the standards were proposed and suggested CMS focus on making sure this work is in place prior to making the APIs in the proposed rule mandatory. In addition, the commenter stated that the HL7 Da Vinci PDex IG depends on mTLS to establish the identity of each of the organizations involved in the exchange while other payer-to-provider and payer-to-patient exchanges rely on OAuth and the SMART framework.

Response: We thank the commenters for their responses and understand their concerns. As discussed in section II.B. of this final rule, we are currently supporting efforts to define the specifications for authentication at scale through UDAP via the FAST Security IG and mTLS through the PDex IG.

We acknowledge that authentication and authorization via user credentials, using means such as OpenID Connect Core and OAuth 2.0, is a requirement for APIs in which individually identifiable user access is necessary, such as the Patient Access API. In order to use OpenID Connect Core, each user would need to have credentials with the payer (or delegated authentication/authorization entity) to access the API. Thus, we are maintaining OpenID Connect Core 1.0 as a required standard for the Patient Access API.

We recognize that while protocols involving specific user credentials as managed by a payer could be used for the Provider Access and Prior Authorization APIs, other protocols, such as SMART Backend Services, mTLS, UDAP, or other trust community-specified means, may be easier to implement at scale. Likewise, protocols requiring user level credentials, managed by the payer, are generally not appropriate for business-to-business data exchanges like the Payer-to-Payer API where an individual may not be directly initiating the exchange. Therefore, upon further consideration of our proposals, we are not finalizing OpenID Connect Core (at 45 CFR 170.215(b)) as either a required or recommended standard for the Provider Access, Payer-to-Payer, and Prior Authorization APIs.

We are recommending SMART Backend Services Authorization for both the Provider Access and the Payer-to-Payer APIs. However, payers will be able to choose the protocols or combination of protocols they deem appropriate as long as they meet appropriate security and privacy requirements. We acknowledge that payers will likely use different protocols, which could represent a barrier to enabling data exchange at scale. Specifications such as UDAP and the tiered OAuth profile is an available option for payers and may enable data exchange in a scalable way by providing dynamic client registration and delegated authentication potentially within and across trust communities. We appreciate the comments, will continue to monitor the progress of UDAP development and implementation, and will consider including it in future rulemaking.

Comment: A commenter stated that the HL7® FHIR® Da Vinci Health Record Exchange (HRex) IG Coverage Profile allows for UDAP, which may be viable solution for authentication. The commenter stated that the HL7 FAST STU 1 Security IG should be considered foundational in the future for all IGs that require registration, authentication, and authorization. Additionally, the commenter suggested that CMS should explain that requiring handwritten signatures continues to be appropriate when the impacted payer deems it necessary. The commenter recommended that CMS should support industry discussions and actions toward UDAP alignment across IGs, when and where appropriate.

Response: We recognize that methods including, but not limited to UDAP, may be appropriate depending on the payer's specific needs and the API. We believe that appropriate security controls can be implemented without requiring handwritten signatures, unless required by other applicable law. We continue to monitor the progress of IG development and remind readers that this final rule does not restrict payers from using other IGs (assuming they are not an earlier version than we specify). We will continue to monitor IG development and consider requiring or recommending additional IGs in future rulemaking.

4. Required Standards and Recommended Implementation Guides To Support APIs

Using standards and IGs supports consistent implementations across the industry. In Table H1 of this final rule, we list the CFR citations that require impacted payers to use API technology conformant with the standards and specifications outlined in this section of the rule. We also include Table H3 to provide a clear outline of which standards we require and which IGs we recommend for each API.

5. Final Action

After considering the comments received, and for the reasons discussed in the CMS Interoperability and Prior Authorization proposed rule (87 FR 76238) and our response to those comments (as summarized previously), we are finalizing our proposals regarding interoperability standards for the Patient Access, Provider Access, Provider Directory, Payer-to-Payer, and Prior Authorization APIs.

We are finalizing greater specificity for the standards at 45 CFR 170.215 that are applicable to each API, with some modifications. Specifically, impacted payers will only be required to use the applicable standards and specifications that we have identified as necessary for the Patient Access, Provider Access, Provider Directory, Payer-to-Payer, and Prior Authorization APIs. Those standards are listed as “required” in Table H3. We are also finalizing a modification to incorporate the expiration dates ONC adopted at 45 CFR 170.215(b)(1)(i) and (c)(1) since the CMS Interoperability and Prior Authorization proposed rule was published.

We are finalizing our proposal to allow impacted payers to use updated standards, specifications, or IGs for each of these APIs, under the following conditions: the updated version of the standard is required by other applicable law; or (1) the updated version of the standard is not prohibited under other applicable law, (2) the National Coordinator has approved the updated version for use in the ONC Health IT Certification Program, and (3) the updated version does not disrupt an end user's ability to access the data required to be available through the API. We note that for the required standards at 45 CFR 170.215, several updated versions have been approved by the National Coordinator for use in the ONC Health IT Certification Program, including, but not limited to, the US Core IG STU 6.1.0, the SMART App Launch IG Release 2.0.0, and the Bulk Data Access IG (v2.0.0: STU 2).

Finally, we are recommending specific IGs, listed as “recommended” in Table H3, which we encourage payers to use in addition to the required standards at 45 CFR 170.215.

III. Collection of Information Requirements

Under the Paperwork Reduction Act (PRA) of 1995, we are required to provide 60-day notice in the Federal Register and solicit public comment before a collection of information requirement is submitted to the OMB for review and approval. To fairly evaluate whether an information collection should be approved by OMB, section 3506(c)(2)(A) of the PRA of 1995 requires that we solicit comment on the following issues:

• The need for information collection and its usefulness in carrying out the proper functions of our agency.
• The accuracy of our estimate of the information collection burden.
• The quality, utility, and clarity of the information to be collected.
• Recommendations to minimize the information collection burden on the affected public, including automated collection techniques.

We requested public comment on areas of this document that contain information collection requirements (ICRs).

A. Background

Payers and providers should be able to take advantage of new technologies that improve their ability to exchange information efficiently, enhance operations, and streamline processes to benefit patient care. Payers should share prior authorization rules in more transparent ways to enable providers to meet their requirements, and thereby, avoid care delays. To continue advancements in our commitment to interoperability, we are finalizing our proposals for certain impacted payers to implement FHIR APIs and make other process improvements to help streamline prior authorizations and improve data exchange between payers, providers, and patients. Impacted payers will be required to report metrics for the information about how often patients use the Patient Access API and about prior authorization processes to assess implementation of our policies. The final rule includes provisions that will reduce the amount of time to process prior authorization requests and improvements for communications about denied prior authorizations. Combined, these provisions should reduce the burden on providers, payers, and patients and enhance patient care coordination.

To incentivize provider use of the Prior Authorization API, we are finalizing a policy to add a new measure for MIPS eligible clinicians under the MIPS Promoting Interoperability performance category and for eligible hospitals and CAHs under the Medicare Promoting Interoperability Program. Beginning with the CY 2027 performance period/2029 MIPS payment year (rather than the CY 2026 performance period/2028 MIPS payment year), we are finalizing this measure as an attestation (yes/no response); we intend to propose a scoring methodology for the measure in future rulemaking. This new measure will be included in a PRA package related to this final rule.

B. Wage Estimates

To derive average costs, we used data from the U.S. Bureau of Labor (BLS) Statistics' National Occupational Employment and Wage Estimates and aligned our analysis with other CMS regulatory actions. Table J1 presents the mean hourly wage, the cost of fringe benefits and overhead (calculated at 100 percent of salary), and the adjusted hourly wage.

We adjusted the employee hourly wage estimates by a factor of 100 percent or doubling of the BLS wage estimates. This is a rough adjustment because fringe benefits and overhead costs vary significantly across employers based on the age of employees, location, years of employment, education, vocations, and other factors.

C. Information Collection Requirements

Consistent with our approach in the CMS Interoperability and Patient Access final rule (85 FR 25622), we determined ICRs by evaluating cost and burden at the impacted payer level. We determined that 365 impacted payers together represent the possible plans, entities, issuers, and state programs impacted by these proposals. The increase in impacted payers from the first CMS Interoperability and Patient Access final rule (85 FR 25510) corresponds to the average annual increase in impacted payers for new market entries. The total estimated burden on these impacted payers is described in detail in the following ICRs and Table J9 at the end of this section. We estimated the total number of burden hours across all impacted payers in the first year of implementation at 6.9 million hours; assuming a total cost to impacted payers to begin at approximately $182 million in the first and second years, increasing to $199 million in the third year and decreasing to $142 million by the fourth and subsequent years.

We requested comments on each ICR described in the proposed rule (87 FR 76330), and on the assumptions made in deriving these burden estimates. We received a few comments on the burden of the proposals and acknowledge those comments with responses later in this section. Since we did not receive specific data to include to modify estimates, no revisions have been made.

1. Information Collection Requirements Regarding Reporting of Patient Access API Metrics to the Centers for Medicare and Medicaid Services (42 CFR 422.119, 431.60, 438.242, 457.730, and 457.1233 and 45 CFR 156.221)

CMS does not currently collect data on using the Patient Access API and does not have industry data on the extent to which patients are requesting to download their data from their payer into an app. We are finalizing the requirement that impacted payers annually report certain metrics to CMS about usage of the Patient Access API. Specifically, we will collect 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 are transferred more than once via the Patient Access API to a health app designated by the patient. We estimate that impacted payers will conduct two major work phases: (1) implementation, which includes defining requirements and system design to generate and compile reports; and (2) maintenance, which we define as including the compilation and transmission of annual reports to CMS. During the implementation phase, impacted payers will need to prepare their systems to capture the data to be transmitted to CMS.

The burden estimate related to the requirements reflects the time and effort needed to identify, collect, and disclose the information. The costs include an initial set of one-time costs associated with implementing the reporting infrastructure and ongoing annual maintenance costs to report after the reporting infrastructure has been established.

Table J2 includes our computational estimates for first-year implementation and ongoing maintenance costs and was used to develop the official statement of burden found in Table J9. In finalizing these calculations, we assumed a two-person team of software/web developers and a business operations specialist spending an aggregate of 160 and 40 hours, respectively, for the first and subsequent years, at a total cost per impacted payer (rounded) of $15,000 and $3,000. The aggregate burden (rounded) for 365 impacted payers will be 60,000 hours and 15,000 hours for the first and subsequent years at a cost of $5.5 million and $1 million.

We did not receive comments specific to the estimates for the Patient Access API metrics reporting.

2. Information Collection Requirements Regarding the Provider Access API (42 CFR 422.121, 431.61, 438.242, 457.731, and 457.1233 and 45 CFR 156.221)

Research shows that patients achieve better outcomes when their medical records are more complete and there are more data available to the health care provider at the point of care. Making comprehensive information available to providers could thus improve the care experience for patients. Ensuring that providers have access to relevant patient data could also reduce the burden on patients to recall and relay information during an appointment and provide confirmation that the patient's recollection of prior care is accurate. This has not always been possible in a disconnected health care system. However, interoperable standards and technology now make it possible for providers to access more patient data for a more comprehensive view of their patients' health history and status. We are finalizing the Provider Access API requirements as described in section II.B.2. of this final rule which permits providers to receive standardized patient data to coordinate care. Cost estimates for this API were developed based on the methodology finalized in the CMS Interoperability and Patient Access final rule (85 FR 25510). In that rule, we estimated that impacted payers would conduct three major work phases: initial design, development and testing, and long-term support and maintenance (85 FR 25605). In this final rule, we assume the same major phases of work will take place for each of the new APIs, with a different level of effort during each work phase.

In the initial design phase, tasks include determining available resources (for example, personnel, hardware, cloud storage space, etc.), assessing whether to use in-house or contracted resources to facilitate an API connection, convening a team to scope, build, test, and maintain the API, gap analysis, and gap mitigation. During the development and testing phase, impacted payers will conduct mapping of existing data to the FHIR standards, hardware allocation for the necessary environments (development, testing, production), building a new FHIR-based server or leveraging existing FHIR servers, determining the frequency and method by which internal data are populated on the FHIR server, building connections between the databases and the FHIR server, performing capability and security testing, and vetting provider requests.

Table J3 summarizes the aggregate burden for complying with the Provider Access API requirements. We provide illustrative points to explain the calculations within the table and the terms used for the headings. The occupational categories on the left side of the table include the titles of the types of labor categories who will perform the work, for example, Database Administrators and Architects, Engineers, and Computer System Analysts.

On the top row, under the label “Database Administrators,” the labor cost of $97.20 per hour was obtained from the BLS. The $97.20 represents the mean wage for this occupational title. The calculations in Table J3 reflect time over the period of the project. We estimate that a Database Administrator might spend 480 hours in total to complete this task. The 480 hours are found in the column titled “Primary Hours.” The word primary, as used in the CMS Interoperability and Patient Access final rule (85 FR 25510), refers to the amount of time most organizations would require for this work. The total cost of $46,656 for each organization is obtained by multiplying the 480 hours by the $97.20 per hour wage. This $46,656 is found in the column labeled “Total Cost, Primary.”

We provide low and high estimates representing a range of possible time and costs across all organizations. The low estimate is half the primary estimate, which is 240 hours. The high estimate is 720 hours. These numbers are found in the low and high columns (hours) of the top row. The corresponding low and high costs are obtained by multiplying the low and high estimates of hours by the $97.20 per hour wage. This is a reasonable range that captures the amount of time and cost all organizations may spend on completing this work.

The explanation provided for the top row applies to each of the ten occupational titles. The sum of the total hours and costs provides a typical organization's total cost. This number is found in the “Totals for a Single Impacted Payer” row. As depicted, the typical organization might take a total of 2,800 hours at a cost of $270,045. We estimate the impact by organization rather than by payer since many organizations may have entities in several of the programs to which this final rule applies: MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs.

To arrive at the total cost of the final rule, we multiplied the single organization cost by 365 payers—that is, the number of organizations hosting plans across the programs. For example, the total primary hourly burden of the rule is 1,022,000 (365 organizations × 2,800 for a single organization).

Similar to the methodology used in the CMS Interoperability and Patient Access final rule (85 FR 25510), we estimate maintenance costs for future years after the API is established at 25 percent of the aggregate cost. We arrived at 25 percent based on our experience with the industry. Rather than list more columns or create another table, we provide a footnote indicating that maintenance is estimated to be 25 percent of the cost. For example, the primary aggregate burden over all 365 organizations is $98.6 million, implying that the annual maintenance costs are expected to be $24.6 million (25 percent × $98.6 million).

Although compliance with this provision will be required on January 1, 2027, we believe it is reasonable to assume that this API will have to be under development before this date to conduct testing and ensure compliance. Acknowledging that impacted payers will have varying technological and staffing capabilities, as we did in the first CMS Interoperability and Patient Access final rule (85 FR 25606), we are finalizing our estimate that the development of this API will require 1,400 to 4,200 hours of work. We have distributed the cost over 3 calendar years to give impacted payers the flexibility to complete the necessary work (see Table J9).

Comment: A few commenters disagreed with CMS's calculations for the total burden regarding hours and costs across all impacted payers and stated that the estimates are significantly understated. These commenters stated that they were not confident that the proposed rule captured the true cost of transitioning to the technical standards.

Response: We acknowledge comments about our calculations capturing the costs of transitioning to the technical standards, however, the commenters who made these statements did not include any supporting data which we could analyze or include in the final rule. We are aware of and have included available information in our estimates and analysis to address connections, testing, security, and onboarding of third parties, to accommodate the potential costs and burden for each API implementation. Additionally, we believe our estimates are the best possible, without additional information, and reasonable assumptions of staff and time, with ranges to account for low and high costs. We welcome continued input from payers and developers based on implementation of the Patient Access and Provider Directory APIs from the CMS Interoperability and Patient Access final rule, as well as the requirements finalized in this final rule. Such information will also be informative for purposes of future rulemaking.

Comment: A commenter noted that it is unrealistic for CMS to expect that the industry can obtain the resources necessary to comply with the provisions outlined in the proposed rule within the current budget year when the requirements will not be finalized until the final rule is issued. The commenter recommended that CMS revise the compliance dates of these provisions to be 36 months after issuance of the final rule and scheduled on a date other than the end of a calendar year.

Response: We have acknowledged the constraints on both budget cycles for certain impacted payers such as state Medicaid and CHIP agencies, as well as the technical complexities of implementation, and are finalizing a compliance date in 2027 for policies in this final rule that require API development or enhancement. As explicitly noted previously, the hours of work needed to build the API as indicated in Table J3, acknowledges that impacted payers will have varying technological and staffing capabilities.

a. API Maintenance Costs—All APIs

The third phase for implementation is long-term support and maintenance. Here we discuss our methodology for the development of the costs in aggregate for all APIs outlined in this final rule. As relevant to the APIs discussed in sections III.C.2., 3., and 6. of this final rule, we estimate ongoing maintenance costs for the Provider Access, Payer-to-Payer, and Prior Authorization APIs, in aggregate. The costs of the API development are split into three phases: initial design, development and testing, and long-term support and maintenance. We assume that maintenance costs only account for the cost associated with the technical requirements as outlined in this rule. Any changes to requirements would add burden, which would be discussed in future rulemaking. Throughout this section, we discuss the initial design, development, and testing costs per API. This final rule addresses the total maintenance cost for all three APIs.

As discussed in the first CMS Interoperability and Patient Access final rule (85 FR 25606), once the API is established, there will be an annual cost to maintain the FHIR server, including the cost of maintaining the necessary patient data and performing capability and security testing. We believe there are efficiencies to be gained in implementation and maintenance since the APIs rely on several of the same underlying foundational technical specifications and content. For example, the same standards will be used to implement the new APIs as were used to implement the Patient Access and Provider Directory APIs, including FHIR and complementary security and app registration protocols. We also believe that maintenance costs will be higher than what we estimated for the CMS Interoperability and Patient Access final rule for the new APIs in this final rule, as our estimates also account for new data mapping needs, standards upgrades, additional data storage, system testing, initial bug fixes, fixed-cost license renewals, contracting costs, and ongoing staff education and training.

To account for these maintenance costs, we based our estimates on input from industry experience piloting and testing APIs for provider access, prior authorization, and payer to payer data exchange. We estimated an annual cost averaging approximately 25 percent of the primary estimate for one-time API costs. In Table J9, we account for this maintenance cost separately for each API (at 25 percent of the one-time API cost). As discussed previously, the overlap in some of the recommended IGs across the APIs should result in shared efficiency that we believe supports the assumption that maintenance should be accounted for in aggregate and is presented in this section as such.

We requested public comment on our approach and assumptions for the aggregate maintenance cost of the APIs, including whether our estimate was reasonable or should be modified, and did not receive specific comments on the aggregate maintenance costs.

3. Information Collection Requirements Regarding the Prior Authorization API (42 CFR 422.122, 431.80, 438.242, 457.732, and 457.1233 and 45 CFR 156.223)

This API addresses ongoing challenges of the prior authorization process, including identifying whether a prior authorization is required for an item or service; identifying the payer documentation requirements for prior authorization; compiling the necessary data elements to populate the HIPAA-compliant prior authorization transactions; and enabling payers to provide a specific response regarding the status of the prior authorization, including information about the reason for denial. We are finalizing the requirement for impacted payers to implement and maintain a Prior Authorization API in this final rule. Use of the Prior Authorization API will begin 2027 (by January 1, 2027, for MA organizations and Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs).

As discussed previously, with respect to the Provider Access API, we estimate that impacted payers will need to conduct three major work phases to implement the requirements for the Prior Authorization API: initial design, development and testing, and long-term support and maintenance. Furthermore, for the Prior Authorization API, additional tasks are necessary to accomplish the requirements. For the costs for the third phase—long-term support and maintenance—our methodology for the development of those costs in aggregate for all APIs is presented in section III.D. of this final rule.

We based our estimate on feedback from industry experts on the anticipated burden of implementing the Prior Authorization API and on current pilots. We continue to believe the estimates to be reasonable regarding the implementation burdens on impacted payers to develop APIs that can facilitate the prior authorization process. In addition to implementing this API, impacted payers will be required to send a specific reason for prior authorization requests that are denied. As discussed in section II.D. of this final rule, while the Prior Authorization API will use the FHIR standard to support its basic capabilities, covered entities must also use the adopted X12 278 transaction standard and remain HIPAA-compliant. Given the added complexity of accounting for the HIPAA standards, we have accounted for the multiple skill sets required and licensing costs for accessing the X12 standards in developing the burden estimates. The recommended HL7 IGs are freely available, as HL7 provides access to all IGs as open-source materials. This makes the HL7 standards, IGs, reference implementations, and test scripts available free of charge to the health care and developer community but requires usage and possibly transaction costs for the X12 standards. We have accounted for the necessary engineers, subject matter experts, and health informaticists in our estimates. These personnel resources will need to convert payers' prior authorization rules into computable, structured formats, create provider questionnaires regarding whether a patient had a medical necessity for a medical item or service, create formats that can interface with the provider's EHR or practice management system, create and execute mapping between the HL7 and X12 codes, and integrate the Prior Authorization API with external systems or servers.

Though this provision will be effective on January 1, 2027, this API will be under development before that date. Acknowledging that impacted payers have varying technological and staffing capabilities, we estimate that the development of the API will require 5,440 to 16,320 hours of work. In Table J9, we have distributed the cost over approximately 3 calendar years to give impacted payers the flexibility to complete the necessary work.

Table J4 presents total burden estimates for the Prior Authorization API (initial design, followed by development and testing). This table presents the calculations associated with the total costs. The numbers from this table are used in Table J9 to present costs per year for 3 years. Based on the same assumptions as those included in the CMS Interoperability and Patient Access final rule (85 FR 25510), we used the medium estimate as the primary estimate.

The narrative description provided for Table J3 also applies to Table J4. Both tables estimate API costs for 365 organizations and indicate follow-up annual maintenance costs by analyzing costs for a single payer using a team spanning approximately ten occupational titles.

We requested public comment on our approach and assumptions for the implementation cost of the Prior Authorization API, including whether our estimates and ranges are reasonable or should be modified. We did not receive any comments on this section.

4. Information Collection Requirements Regarding Requirements To Send Prior Authorization Decisions Within Certain Timeframes (42 CFR 422.568, 422.570, 422.631, 438.210, 440.230, 457.495, and 457.1230)

Patients need to have timely access to care, and providers need to receive timely responses to their requests for authorization to requests for services for their patients, particularly when waiting for answers can delay the pursuit of alternatives. To increase transparency and reduce burden, we are finalizing our proposal to require that certain impacted payers, not including QHP issuers on the FFEs, send prior authorization decisions within 72 hours for expedited requests and 7 calendar days for standard requests. Impacted payers will have to comply with these provisions beginning January 1, 2026. We note that Medicaid managed care plans and CHIP managed care entities will have to comply with these provisions by the rating period beginning on or after January 1, 2026.

To implement this policy, there will be up-front costs for impacted payers to update their policies and procedures. We anticipate this burden per payer is 8 hours of work by a general and operations manager to update the policies and procedures, reflecting two half-days of work at a per-entity cost of $967. Therefore, the total burden for all 365 impacted payers is 2,920 hours of work at a first-year cost of $0.4 million (rounded). These calculations are summarized in Table J5.

We requested public comment on our assumptions, estimates, and approach but received no comments on this proposal and therefore are finalizing these estimates without modification.

5. Information Collection Requirements Regarding the Requirement for Public Reporting of Prior Authorization Metrics (42 CFR 422.122, 438.210, 440.230, 457.732, and 457.1230 and 45 CFR 156.223)

To support transparency for patients to understand prior authorization processes, provide some assistance in choosing health coverage, and for providers when selecting or evaluating payer networks we are finalizing our proposal to require that impacted payers publicly report certain prior authorization metrics on their websites. Impacted payers will be required to report aggregated data annually for the previous calendar year's data, beginning March 31, 2026.

We estimate that impacted payers will conduct two major work phases: implementation, which includes defining requirements, system design, and updates to generate and compile reports; and maintenance, including an annual compilation of reports and public reporting of metrics on a website. In the first phase, impacted payers will need to define requirements concerning the types and sources of data that need to be compiled regarding prior authorization activities and data, build the capability for a system to generate reports, and update or create a public web page to post the data. In the second phase, impacted payers will need to create the reports and post them to a public web page annually.

Table J6 itemizes the activities, hours, and dollar burdens for the first-year implementation and estimated annual maintenance costs. We assumed a team of two staff consisting of a software and web developer with a business operations specialist.

• First-year implementation will impose a burden of 320 hours for the first year and 120 hours for subsequent years, at the cost of $30,000 and $9,000 (rounded), for the first and subsequent years, respectively.
• The aggregate burden of the first-year implementation across 365 impacted payers will be 117,000 hours and 44,000 hours (rounded) for the first and subsequent years, respectively, at a cost of $10.8 million and $3.3 million (rounded) for the first and subsequent years.

6. Information Collection Requirements Regarding the Payer-to-Payer API Implementation (42 CFR 422.121, 431.61, 438.242, 42 CFR 457.731, and 457.1233 and 45 CFR 156.222)

Patients may wish to carry certain health information with them when they change payers, in part so that they can track the services they have received, and to ensure that a new payer has information about their past health history for purposes of managing their care with new or current providers. We are finalizing the requirements for impacted payers to implement and maintain a Payer-to-Payer API as described in section II.C. of this final rule. These provisions will improve care coordination among payers by requiring payers to exchange, at a minimum, adjudicated claims and encounter data (excluding provider remittances and patient cost-sharing information), all data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI), and certain information about prior authorizations. This exchange will be required via a Payer-to-Payer API beginning in 2027 (by January 1, 2027, for MA organizations and Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs).

As discussed for the other APIs in this rule, impacted payers will conduct three major work phases: initial design, development and testing, and long-term support and maintenance.

There will be some costs for impacted payers to implement the Payer-to-Payer API that are unique to this API. There could be costs to test and integrate the Payer-to-Payer API with payer systems, albeit potentially lower costs than those estimated for the Provider Access API. We estimate the one-time implementation costs at about one-third the cost of a full de novo Provider Access API implementation based on input from developers who have implemented and piloted prototype APIs using the required standards. We accounted for the necessary skill sets of staff required as we also believe there will be unique costs for implementing the PDex IG so that payers can exchange active and pending prior authorization decisions and related documentation and forms when an enrollee or beneficiary enrolls with a new impacted payer.

Table J7 presents the total activities, hours, and dollar burdens for implementing the Payer-to-Payer API given our assumptions on the initial design phase and the development and testing phase. Based on the same assumptions as those published in the CMS Interoperability and Patient Access final rule (85 FR 25510), we have the medium estimate as the primary estimate. We provide the following narrative explanation of Table J7:

• For the primary estimate, one-time implementation efforts for the first two phases will require, on average, a total of 916 hours per organization at an average cost of $96,072 per organization.
• The aggregate burden of the one-time implementation costs across 365 impacted payers will be 334,000 hours (rounded) at the cost of $35.1 million (rounded). This corresponds to the primary estimate; the low and high estimates are obtained by multiplying the primary estimate by factors of one-half and one and one-half, respectively.

Though this provision will be effective on January 1, 2027, the API will be under development before that date. Acknowledging that impacted payers will have varying technological and staffing capabilities, the development of the API will require 458 to 1,374 hours of work. In Table J9, we have distributed the cost estimates over 3 calendar years to give impacted payers the flexibility to complete the work.

We requested public comment on our approach and assumptions for the cost of the Payer-to-Payer API, including whether our estimates and ranges are reasonable or should be modified, and received none.

7. Information Collection Requirements Regarding the Electronic Prior Authorization Measure for Merit-Based Incentive Payment System and the Medicare Promoting Interoperability Program

The estimates in this section have been submitted to OMB in a PRA package (OMB control number 0938–1278). The burden associated with the proposed requirement for eligible hospitals and CAHs to report the Electronic Prior Authorization measure for the Medicare Promoting Interoperability Program will be captured in the next revision to the PRA package currently approved under OMB control number 0938–1278 (CMS–10552).

As explained in section II.F. of this final rule, in response to the December 2020 CMS Interoperability proposed rule (85 FR 82586), commenters indicated that provider reporting would be an appropriate lever by which CMS could encourage using the APIs to enable enhanced electronic documentation discovery and facilitate electronic prior authorization. Thus, to encourage MIPS eligible clinicians, eligible hospitals, and CAHs to implement and use electronic prior authorization and the corresponding API, we proposed to add a new measure, called the Electronic Prior Authorization measure, for MIPS eligible clinicians under the MIPS Promoting Interoperability performance category and for eligible hospitals and CAHs under the Medicare Promoting Interoperability Program. After consideration of public comments, we have modified the Electronic Prior Authorization measure requirements which are further described and addressed in section II.F. of this final rule.

We are finalizing that MIPS eligible clinicians would report the Electronic Prior Authorization measure beginning with the CY 2027 performance period/2029 MIPS payment year (rather than the CY 2026 performance period/2028 MIPS payment year) and that eligible hospitals and CAHs would report the Electronic Prior Authorization measure beginning with the CY 2027 EHR reporting period (rather than the CY 2026 EHR reporting period). For the CY 2027 performance period/2029 MIPS payment year for MIPS eligible clinicians and the CY 2027 EHR reporting period for eligible hospitals and CAHs, we are finalizing with a modification that the Electronic Prior Authorization measure be structured as an attestation (yes/no), instead of a numerator and denominator measure as originally proposed for both MIPS eligible clinicians, and eligible hospitals and CAHs. As an attestation measure, MIPS eligible clinicians, eligible hospitals, and CAHs are required to report a “yes” or “no” response or report an applicable exclusion, for the Electronic Prior Authorization measure. Additionally, we are finalizing that this measure will not be assigned points.

For the MIPS Promoting Interoperability performance category, satisfactory performance on this measure can be demonstrated only by reporting a “yes” response or claiming an applicable exclusion. A “no” response will result in the MIPS eligible clinician failing to meet the minimum reporting requirements, and therefore not being considered a meaningful EHR user for MIPS, as set forth in section 1848(o)(2)(A) of the Act and defined in 42 CFR 414.1305, for the MIPS payment year. MIPS eligible clinicians who do not report a “yes” response or claim an applicable exclusion for the Electronic Prior Authorization measure as specified (that is, they do not submit the measure or report a “no” response on the attestation without claiming an applicable exclusion) will not earn a score for the MIPS Promoting Interoperability performance category (a score of zero for the category). A MIPS eligible clinician's score in the Promoting Interoperability performance category is generally worth 25 percent of their total final score for MIPS (42 CFR 414.1375(a); 414.1380(c)(1)).

For the Medicare Promoting Interoperability Program, only a “yes” response on the attestation, or claiming an applicable exclusion, will fulfill the minimum requirements of this measure. A “no” response will result in the eligible hospital or CAH failing to meet the minimum program requirements, and therefore would not be considered a meaningful user of CEHRT, as defined in section 1886(n)(3) of the Act for an EHR reporting period (42 CFR 495.24(f)(1)(i)(A)). Eligible hospitals and CAHs that do not meet the minimum program requirements are subject to a downward payment adjustment.

The burden in implementing these requirements consists of reporting an attestation (a “yes” or “no” response) or claiming an exclusion. In the RIA, section IV. of this final rule, we estimate burden based on the effort it takes to report a response for the measure. This estimated burden to report would be the same whether it is to report a “yes or no” response or to report a numerator and denominator as initially proposed. Therefore, modifying the measure to be reported as an attestation does not change the overall cost estimates included in the RIA for this provision. System maintenance is an umbrella term that includes all activities needed to keep a system running. The two main components of system maintenance are preventive and corrective maintenance, which include software tasks such as fixing bugs, updating data sources, deleting old software tasks, adding new tasks, testing, and verification. Maintenance requirements for systems were estimated at 25 percent of total software creation costs, reflecting updates and bug fixes, as well as deletion and creation of software tasks (85 FR 82649). There will be a moderate software update to implement the provisions of this final rule, and there will be no added burden over and above the burden of maintaining already existing software.

The data for the reports on prior authorizations and related claims should already be stored in the system software of health care providers who may be required to retain such data for compliance and regulatory reasons. To report the Electronic Prior Authorization attestation (yes/no) measure as specified by CMS, the provisions in this rule should not impose a significant burden of denoting the information in the system.

For the added burden of extracting, compiling, reviewing, and submitting the attestation, we assume that for each report, a Medical Records Specialist will spend about half a minute (0.0083 hours) extracting the already-existing data at a cost of $0.39 (1/120 hour ( 1/2 minute) × $46.42 per hour). To obtain the aggregate burden, we multiply by the number of entities. This is done separately for eligible hospitals and CAHs, and MIPS eligible clinicians in Table J8.

The following items provide support and rationale for the entries in Table J8:

• The hourly burden estimates of 1/2 minute (1/120 = 0.00833 hour) for transmission of the Electronic Prior Authorization attestation (yes/no) response to CMS are consistent with the revised estimates of burden presented in the FY 2024 IPPS/LTCH proposed rule (88 FR 27204). The hourly burden estimates for the Electronic Prior Authorization measure are based on the collection of burden estimates calculated for the Query of Prescription Drug Monitoring Program measure.

• The estimate of 4,500 hospitals (including eligible hospitals and CAHs) is consistent with the revised estimates presented in the FY 2024 IPPS/LTCH final rule (88 FR 27205).
• The existing MIPS reporting policies allow MIPS eligible clinicians to report at the individual or group level. As noted in the CY 2024 PFS proposed rule (88 FR 52666), CMS did not propose any submission changes for the MIPS Promoting Interoperability performance category and therefore refers to previous rules for respondent and burden estimates. In Table 132 of the CY 2023 PFS final rule (87 FR 70163), the estimated number of respondents submitting MIPS Promoting Interoperability performance data was based on 2021 participation data collected during the PHE for the COVID–19 pandemic. We anticipate that participation will change over the next 10 years and volumes will rebound to pre-pandemic numbers. We determined that the respondent estimates in Table 122 of the CY 2023 PFS proposed rule (87 FR 46370) are more representational of what we anticipate participation will look like when the Prior Authorization API and associated Electronic Prior Authorization measure provisions are implemented given that these estimates are based on pre-pandemic participation data from CY 2019. Therefore, we maintain that an estimated 54,770 individual or group MIPS eligible clinicians will submit an attestation for the Electronic Prior Authorization measure under the MIPS Promoting Interoperability performance category for the CY 2027 performance period/2029 MIPS payment year. The 54,770 is the sum of the 43,117 individual MIPS eligible clinicians, 11,633 groups, and 20 subgroups estimated to submit MIPS Promoting Interoperability performance data. The ICRs currently approved under OMB control number 0938–1314 are approved through January 31, 2025.
• The FY 2024 IPPS/LTCH proposed rule uses mean hourly wage estimates (88 FR 27204), consistent with this final rule and the CMS Interoperability and Patient Access final rule (85 FR 25605). For purposes of clarification, we have provided both mean and median estimates.

++ For eligible hospitals and CAHs, the total cost is $1,741 (4,500 hospitals and CAHs × 1/2 minute × $46.42 per hour), which equals $0.002 million as shown in Table J9. This rounds to $0.0 million. Calculations using the median instead of the average after rounding are identical. This shows that the bottom-line rounded figure would not change if we used the median instead of the average. The entries in Table J9 are rounded numbers while the actual dollar amounts are provided in Table J8.

++ For MIPS eligible clinicians, the total cost is $21,186 (54,770 clinicians × 1/2 minute × $46.42 per hour). Since Table J9 relates to Table K6 in the RIA, we expressed the $21,186 using RIA accounting standards, which require rounding to the nearest tenth of a million. It follows that $21,186 is equivalent to $0.021 million, as shown in Table J9. This value is rounded to $0.0 in the RIA.

Comment: A commenter stated the calculation for the aggregate estimates for the Electronic Prior Authorization measure costs is unreasonable and lacks a reasonable basis. This commenter stated there is no way for an employee to run a report in half a minute, as logging into the computer system with two-factor authentication alone can take 1 to 2 minutes. The commenter stated getting to the report in the EHR can take 1/2 to 1 minute and running a large report can easily take 1/2 to 2 minutes. The report then needs to be verified and transmitted. The commenter stated instead of half a minute, the process is closer to 5 to 10 minutes. Another commenter stated that the analysis does not account for the payer burden of connecting and testing with all EHRs and practice management systems, specifically the high costs and time commitments. The commenter requested CMS's clarification on whether payers are only required to share with EHR systems certified under the ONC Health IT Certification Program.

Response: We appreciate concerns about the timing for reporting but respectfully disagree, particularly because we have modified the reporting specifications for the Electronic Prior Authorization measure. We are finalizing this measure with modifications such that, beginning with the CY 2027 performance period/2029 MIPS payment year and the CY 2027 EHR reporting period, a MIPS eligible clinician, eligible hospital, or CAH will report a “yes” or “no” response for the Electronic Prior Authorization measure or claim an exclusion, instead of a numerator and denominator measure as originally proposed. If the MIPS eligible clinician, eligible hospital, or CAH does not report a “yes” response for the Electronic Prior Authorization measure or claim an exclusion, they will receive a zero score for the MIPS Promoting Interoperability performance category or the Medicare Promoting Interoperability Program, respectively. We are finalizing reporting of the Electronic Prior Authorization measure as an attestation (yes/no) measure beginning with the CY 2027 performance period/2029 MIPS payment year and the CY 2027 EHR reporting period. With these modifications, completing and reporting the attestation for the Electronic Prior Authorization measure will not take 10 minutes, but significantly less time to enter into the reporting system. We are explicitly describing time spent reporting the Electronic Prior Authorization measure in this final rule, and half a minute is more representational for reporting a single attestation measure. The entire reporting process for these programs may take longer to complete, for example, 5-to-10 minutes. The amount of time it takes to report data to CMS is dependent on whether the person reporting the data needs to establish their account credentials, the amount of data being reported, and the method through which the data is being submitted. However, this calculation does not intend to calculate the amount of time it takes to conduct the entire process or report all performance data, rather it is solely evaluating the estimated amount of time a person would spend on reporting the Electronic Prior Authorization measure.

We also acknowledge this commenter's concern about the basis for the aggregate estimates for the Electronic Prior Authorization measure. However, this commenter did not provide additional data to which we could compare our estimates. Furthermore, we disagree with the commenter as we used information from other interested parties as well as studies to determine that the cost savings will be substantial after a period of years because of the improvements in the prior authorization process for reducing manual effort and delays in services.

We did not receive any other comments on this section of the rule. After consideration of public comments, we are finalizing the estimates without modification.

D. Summary of Information Collection Burdens

We have explained the costs of individual provisions in this section. Table J9 summarizes costs for the first and subsequent years of these provisions and is based on the following assumptions:

• Modified compliance dates for the policies in this final rule that require API development or enhancement, Medicare Promoting Interoperability Program, and MIPS Promoting Interoperability performance category until the CY 2027 performance period/2029 MIPS payment year or CY 2027 EHR reporting period to give 3 years (36 months) for appropriate implementation activities.
• Maintenance costs for the three APIs are, as indicated in the tables of this section, assumed to be 25 percent of total costs; these maintenance costs will be incurred in CY 2027 and subsequent years.
• Certain provisions will be effective in January 2026; thus, no costs are reflected from 2023 through 2025. However, for the building of the API systems, we assume impacted payers will be performing these updates in CY 2024 through 2026 to be prepared for the CY 2027 compliance date.
• Labor costs in Table J9 are either BLS wages when a single staff member is involved or a weighted average representing a team effort, which is obtained by dividing the aggregate cost by the aggregate hours.
• Table J9 reflects the primary estimate. The full range of estimates for all provisions is presented in the RIA section of this final rule.

E. Conclusion

The provisions of this final rule are expected to improve data sharing across impacted payers and providers by facilitating access, receipt, and exchange of patient data. We are committed to providing patients, providers, and payers with timely access to patient health information. We requested comments on our approaches for estimating cost burden and cost savings and received a few comments which have been incorporated herein.

The requirements of this final rule are extensions of the requirements of the CMS Interoperability and Patient Access final rule (85 FR 22510). Therefore, the ICRs have been submitted to OMB for review and approval.

IV. Regulatory Impact Analysis

A. Statement of Need

As described in prior sections of this final rule, the changes to 42 CFR parts 422, 431, 435, 438, 440, and 457 and 45 CFR part 156 further support CMS's efforts to empower patients by increasing electronic access to health care data, while keeping that information safe and secure. The provisions in this final rule build on the foundation we laid out in the CMS Interoperability and Patient Access final rule to move the health care system toward increased interoperability by enabling better data sharing capabilities of impacted payers, encouraging health care providers' use of new capabilities, and making health-related data more easily available to patients through standards-based technology.

The provisions in this final rule place new requirements on MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to further improve the electronic exchange of health-related data and streamline prior authorization processes. We believe these provisions will improve health information exchange and facilitate appropriate patient, provider, and payer access to health information via APIs, while the policies related to prior authorization should improve certain administrative processes. The final rule also adds a new attestation measure for eligible hospitals and CAHs under the Medicare Promoting Interoperability Program and for MIPS eligible clinicians under the MIPS Promoting Interoperability performance category.

B. Overall Impact

We examined the impacts of this final rule as required by Executive Order 12866 on Regulatory Planning and Review (September 30, 1993), Executive Order 13563 on Improving Regulation and Regulatory Review (January 18, 2011), Executive Order 14094, entitled “Modernizing Regulatory Review” (April 6, 2023), the Regulatory Flexibility Act (RFA) (September 19, 1980, Pub. L. 96–354), Executive Order 13272 on Proper Consideration of Small Entities in Agency Rulemaking (August 13, 2002), section 1102(b) of the Act, section 202 of the Unfunded Mandates Reform Act of 1995 (UMRA) (March 22, 1995, Pub. L. 104–4), and Executive Order 13132 on Federalism (August 4, 1999) and the Congressional Review Act (5 U.S.C. 804(2)).

Executive Orders 12866 and 13563 direct agencies to assess all costs and benefits of available regulatory alternatives and, if regulation is necessary, to select regulatory approaches that maximize net benefits (including potential economic, environmental, public health, and safety effects, distributive impacts, and equity). Executive Order 14094, entitled “Modernizing Regulatory Review,” amends section 3(f)(1) of Executive Order 12866 (Regulatory Planning and Review). The amended section 3(f) of Executive Order 12866 defines a “significant regulatory action” as an action that is likely to result in a rule: (1) having an annual effect on the economy of $200 million or more in any 1 year (adjusted every 3 years by the Administrator of the Office of Information and Regulatory Affairs (OIRA) for changes in gross domestic product), or adversely affect in a material way the economy, a sector of the economy, productivity, competition, jobs, the environment, public health or safety, or state, local, territorial, or tribal governments or communities; (2) creating a serious inconsistency or otherwise interfering with an action taken or planned by another agency; (3) materially altering the budgetary impacts of entitlement grants, user fees, or loan programs or the rights and obligations of recipients thereof; or (4) raise legal or policy issues for which centralized review would meaningfully further the President's priorities or the principles set forth in this Executive order, as specifically authorized in a timely manner by the Administrator of OIRA in each case.

Based on our estimates, OMB's OIRA has determined this rulemaking to be significant per section 3(f)(1) as measured by having an annual effect of $200 million in at least 1 year, and hence is also a major rule under Subtitle E of the Small Business Regulatory Enforcement Fairness Act of 1996 (also known as the Congressional Review Act). Accordingly, we have prepared an RIA that, to the best of our ability, presents the costs and benefits of this final rule.

These provisions will result in some financial burden for impacted payers and certain providers as discussed in section III. of this final rule. In the proposed rule, we weighed the potential burdens against the potential benefits and believe the benefits outweigh the costs (87 FR 76340). Based on our estimates, the total burden across all providers would be reduced by at least 220 million hours over 10 years, resulting in a total cost savings of at least $16 billion over 10 years as seen in Table K6. We did not include these savings in the 10-year Summary Table (Table K9), nor in the Monetized Table (Table K11), as explained later on in this section of the final rule.

Comment: Some commenters disagreed with CMS's calculated cost to implement the provisions outlined in the proposed rule and expressed that the actual cost will be much higher than estimated. A commenter stated that they fail to see how the estimated total burden across all providers would be reduced by the proposed rule's estimates of 206 million hours resulting in the total cost saving of $15 billion that CMS asserted in the proposed rule.

Response: While we appreciate that commenters do not concur with the cost estimates, we used the best available data to us at the time we developed the rule and made related assumptions about the reduction in hours for clerical, nursing, and provider staff as a result of the final policies. We are re-stating our assessments of those assumptions and calculations in this final rule. Though commenters and implementers did not submit new data for consideration, we did make a slight revision in the total cost savings to say “at least $16 billion” which includes adjustments of where some of the savings would occur. The potential savings are significant, and we firmly believe that the policies in this final rule will streamline operations, improve efficiencies, and pave the way for substantial changes in the way staff use technology to exchange data and conduct business, particularly for prior authorization. We welcome tangible data from commenters which we could use for comparative analysis of costs and savings.

Comment: A commenter raised concerns with the impact analysis and cost calculations CMS included in the proposed rule, taking issue with CMS using data that includes the cost of all prior authorizations, which includes prescription drugs (accounting for 70 percent of prior authorizations), to calculate the savings potential of the proposed rule, as the policies do not apply to all prior authorizations. The commenter stated that accurate calculations would likely reveal that the rule as proposed is too costly to implement unless CMS modifies it to include prior authorization for prescription drugs, as well as all health plans.

Response: We emphasize that this rule does not apply to prescription drugs that may be self-administered, administered by a provider, or that may be dispensed or administered in a pharmacy or hospital, or OTC drugs. We explicitly note that estimates do not include all prior authorizations and that formulary prior authorizations are excluded from our calculation of savings. In addition, this rule does not apply to all health plans and services, but rather to certain impacted payers, including MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs. We welcome alternative data to support further analysis and will continue to collect information as the final rule is implemented.

C. Regulatory Flexibility Act

Executive Order 13272 requires that HHS thoroughly review rules to assess and take appropriate account of their potential impact on small businesses, small governmental jurisdictions, and small organizations (as mandated by the RFA). HHS considers a “significant” impact to be 3 to 5 percent or more of the affected entities' costs or revenues. For background on the RFA references in the proposed rule, please see 87 FR 76340.

We confirm our analysis of the impacted entities as described in section IV.C. of this final rule.

1. Payers

The 365 payer organizations will perform updates to systems to implement the required APIs and prepare for reporting requirements. As in the proposed rule, we use the term parent organizations in this final rule to refer to the impacted payers (87 FR 76238). The combined parent organizations administer MA plans, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs.

The North American Industry Classification System (NAICS) category relevant to these provisions is Direct Health and Medical Insurance Carriers, NAICS 524114, which has a $47.0 million threshold for small size. 75 percent of payers in this category have under 500 employees, thereby meeting the definition of small businesses.

The 365 parent organizations, including state Medicaid and CHIP agencies, are responsible for implementing and maintaining three new APIs, updating policies and procedures to accommodate revised timeframes for making prior authorization decisions, and reporting certain metrics either to CMS or making information available to the public. We determined that state Medicaid and CHIP agencies, as well as many MA organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs are not considered small entities. Furthermore, MA organizations and Medicaid managed care plans and CHIP managed care entities have many of their costs covered through capitation payments from the Federal Government, and thus we conclude there is no significant burden on small entities in this final rule.

We are finalizing the provisions that require API development or enhancement as proposed. We also note that some QHP issuers on the FFEs will be able to apply for an exception to these requirements, and certain states operating Medicaid and CHIP FFS programs will be able to apply for an extension or exemption, under which they will not be required to meet the new provisions of this final rule that require API development or enhancement on the compliance dates, provided certain conditions are met, as discussed in section II.E. further mitigating potential burden for those payers.

a. Medicare Advantage

On an annual basis, MA organizations estimate their costs for the upcoming year and submit bids and proposed plan benefit packages to CMS. Upon approval, the plan commits to providing the proposed benefits, and CMS commits to paying the plan either the full amount of the bid, if the bid is below the benchmark (a ceiling on bid payments annually calculated from Original Medicare data); or the benchmark amount, if the bid amount is greater than the benchmark. Thus, there is a cost to plans to bid above the benchmark that is not funded by government payments. Additionally, if an MA organization bids above the benchmark for any of its plans, section 1854 of the Act requires the MA organization to charge enrollees a premium for that amount. In the proposed rule, we provided a further explanation regarding MA organizations' bids and government payment processes for MA plans and MA plans with prescription drug coverage (MA–PDs) and refer readers to that discussion for additional detail (87 FR 76341).

Table K1 reports the percentage of MA organizations bidding above the benchmark, along with the percentage of affected enrollees in recent years. This table reports aggregates of proprietary bid data collected by the Office of the Actuary (OACT). The CMS threshold for what constitutes a substantial number of small entities for purposes of the RFA is 3 to 5 percent. As shown in Table K1, both the percentage of plans and the percentage of affected enrollees are below this 3 to 5 percent threshold. Consequently, we conclude that the number of plans bidding above the benchmark is not substantial for purposes of the RFA.

The preceding analysis shows that meeting the direct costs of this final rule does not have a significant economic impact on a substantial number of small entities as required by the RFA.

There are certain indirect consequences of the final policies, which will also have an economic impact. We explained that at least 98 percent of MA organizations bid below the benchmark. Thus, we estimate that their projected costs for providing services to Medicare beneficiaries for the coming year are fully paid by the Federal Government. However, the government additionally pays the plan a “beneficiary rebate” amount that is an amount equal to a percentage (between 50 and 70 percent, depending on a plan's quality rating) multiplied by the amount by which the benchmark exceeds the bid. The rebate is used to provide additional benefits to enrollees in the form of reduced cost-sharing or other supplemental benefits or to lower the Part B or Part D premiums for enrollees (supplemental benefits may also partially be paid by enrollee premiums). If the provisions of this final rule cause the MA organization's bids to increase and if the benchmark remains unchanged or increases by less than the bid does, the result will be a reduced rebate and, possibly fewer supplemental benefits, or higher premiums for the health plans' enrollees. However, as noted previously, the number of plans bidding above the benchmark to whom this burden applies does not meet the RFA criteria of a significant number of plans.

It is possible that if the provisions of this final rule cause bids to increase, MA organizations will reduce their profit margins, rather than substantially change their benefit packages. This may be in part due to market forces; a plan lowering supplemental benefits even for 1 year may lose enrollees to competing plans that offer these supplemental benefits. Thus, it can be advantageous to the plan to reduce profit margins, rather than reduce supplemental benefits. With this, plans would balance competitive pressures with profit targets immediately following a new regulation. As the regulations are typically finalized within a few months of the bid submission deadline, plans may have more time to enact strategies that do not require large benefit changes in subsequent years, such as negotiations for supplemental benefit offerings. However, it may be inappropriate to consider the relevant regulatory impacts (and thus the profit considerations) as temporary because the issuance of a series of regulations sustains the effects. As a result, changes in benefits packages may be plausible. We did not receive any comments on this section of the RIA regarding small entities, nor on our assumptions about the impact or the general summary of the structure for MA bids. We are therefore finalizing this analysis as is. Based on the previously discussed considerations, the Secretary has certified that this final rule will not have a significant impact on a substantial number of small entities.

b. Medicaid and CHIP

Title XIX of the Act established the Medicaid program as a Federal-state partnership to provide and finance medical assistance to specified groups of eligible individuals. States claim Federal matching funds quarterly based on their program expenditures. Since states are not small entities under the RFA, we need not discuss the burden imposed on them by this final rule.

Medicaid managed care plans and CHIP managed care entities receive 100 percent capitation from the state; we expect that the projected costs associated with the provisions of this final rule will be included in their capitation rates. Consequently, we assert that there will be no substantial impact on a significant number of these entities.

As discussed in section II.E. of this final rule for the provisions that require API development or enhancement, states operating Medicaid and CHIP FFS programs may apply for an extension of 1 year to come into compliance with the requirements of this final rule. These same organizations may also apply for an exemption from the requirements if certain conditions are met.

Comments pertaining to the Medicaid and CHIP explanation of Federal matching funds are addressed in that section of this final rule, as are those related to the extension and exemption processes.

c. Qualified Health Plan Issuers on the Federally-Facilitated Exchanges

Few, if any, QHP issuers on the FFEs are small enough to fall below the size thresholds for a small business established by the SBA. Consistent with previous CMS analysis in the SHOP/QHP final rule (78 FR 33233), we estimated that any issuers considered small businesses would likely be subsidiaries of larger issuers that would not be considered small businesses (78 FR 33238), and thus would not share the same burdens as an independent small business. Therefore, even though QHP issuers do not receive Federal reimbursement for the costs of providing care, we do not conclude that there would be a significant small entity burden for these issuers. In addition, an exception process is available to QHP issuers on the FFEs, which could further help to address regulatory burden that could otherwise prohibit a QHP issuer from participating in an FFE.

We did not receive any comments specific to the QHP summary section of this RFA. Comments related to the exception process for QHPs are addressed in section II.E.

2. Providers

In response to public comments on the December 2020 CMS Interoperability proposed rule (85 FR 82586), CMS proposed a new Electronic Prior Authorization measure for MIPS eligible clinicians under the MIPS Promoting Interoperability performance category, and for eligible hospitals and CAHs under the Medicare Promoting Interoperability Program. CMS proposed that the Electronic Prior Authorization measure would be required for MIPS eligible clinicians beginning with the CY 2026 performance period/2028 MIPS payment year and for eligible hospitals and CAHs beginning with the CY 2026 EHR reporting year. However, after consideration of substantial feedback from commenters described in section II.F. of this final rule, we are finalizing a modification to the Electronic Prior Authorization measure proposal. Rather than requiring MIPS eligible clinicians, eligible hospitals, and CAHs to report a numerator and denominator for the Electronic Prior Authorization measure, we are finalizing the measure structured as an attestation (yes/no) measure for both MIPS eligible clinicians, and eligible hospitals and CAHs. As an attestation measure, MIPS eligible clinicians, eligible hospitals, and CAHs will report a “yes” or “no” response or report an applicable exclusion for the Electronic Prior Authorization measure. Additionally, we are finalizing that this measure will not be assigned points.

For the MIPS Promoting Interoperability performance category, satisfactory performance on this measure can be demonstrated only by reporting a “yes” response or claiming an applicable exclusion. A “no” response will result in the MIPS eligible clinician failing to meet the minimum reporting requirements, and therefore not being considered a meaningful EHR user for MIPS, as set forth in section 1848(o)(2)(A) of the Act and defined at 42 CFR 414.1305, for the MIPS payment year. MIPS eligible clinicians that do not report a “yes” response or claim an applicable exclusion for the Electronic Prior Authorization measure as specified (that is, they do not submit the measure or report a “no” response on the attestation without claiming an applicable exclusion) will not earn a score for the MIPS Promoting Interoperability performance category (a score of zero for the category). A MIPS eligible clinician's score in the Promoting Interoperability performance category is generally worth 25 percent of their total final score for MIPS (42 CFR 414.1375(a); 414.1380(c)(1)).

For the Medicare Promoting Interoperability Program, only a “yes” response on the attestation, or claim of an applicable exclusion, will fulfill the minimum requirements of this measure. A “no” response will result in the eligible hospital or CAH failing to meet the minimum program requirements, therefore not being considered a meaningful user of CEHRT, as defined in section 1886(n)(3) of the Act for an EHR reporting period (42 CFR 495.24(f)(1)(i)(A)). Eligible hospitals and CAHs that do not meet the minimum program requirements are subject to a downward payment adjustment.

With regard to MIPS eligible clinicians, eligible hospitals, and CAHs, a discussion of the burden is provided in section III., and supporting data are shown in Table J8. As noted previously, we modified the provision for the Electronic Prior Authorization measure in this final rule based on comments indicating that the denominator calculation would impose a significant burden on providers. We have calculated the burden per individual provider at under $2.50 per year ( 1/2 minute of labor times an hourly wage of under $50).

Based on all information provided herein, we conclude that the requirements of the RFA have been met by this final rule.

We did not receive comments on this subject in the RFA. The modification to the Electronic Prior Authorization measure was not determined to have a significant financial effect on this RIA because there is no need to re-calculate the numerator and denominator and the information will be reported as an attestation. We are finalizing this section as is.

D. Unfunded Mandates Reform Act and Executive Order 13132 Requirements

Section 202 of the UMRA also requires that agencies assess anticipated costs and benefits before issuing any rule whose mandates require spending in any 1 year of $100 million in 1995 dollars, updated annually for inflation. In 2023, that threshold is approximately $177 million. This final rule will not impose an unfunded mandate that results in the expenditure by state, local, and tribal governments, in the aggregate, or by the private sector, of more than $177 million in any 1 year.

Executive Order 13132 establishes certain requirements that an agency must meet when it publishes a final rule that imposes substantial direct costs on state and local governments, preempts state law, or otherwise has federalism implications. As previously outlined, while the provisions that require API development or enhancement will be a requirement for state Medicaid and CHIP agencies as described in this final rule, the cost per beneficiary for implementation is expected to be negligible when compared with the overall cost per beneficiary. The analysis we conducted did not consider Federal matching funds provided to state Medicaid and CHIP agencies, and the conclusion was the same: there is not expected to be a significant cost impact on state entities.

For Medicaid and CHIP, we are unaware of any provisions in this final rule that conflict with state law, and no commenters raised a pre-emption issue other than the timeframe issue discussed later in this section. Therefore, we do not anticipate any preemption of state law. As discussed in section II.D. of this final rule, some state laws regarding timeframes for prior authorization decisions may be different than the provisions in this final rule. However, an impacted payer will be able to comply with both state and Federal requirements by complying with whichever imposes the shorter timeframe. We invited states to comment on the proposed rule if they believed that any proposal in this rule would conflict with state law. We received a few comments from states and other organizations regarding the preemption of state law regarding timeframes and addressed these comments regarding prior authorization decision timeframes and compliance with state law in section II.D. of this final rule.

As noted previously in this section, we considered whether the provisions in this final rule imposed substantial costs on state or local governments, preempted state law, or had federalism implications and concluded that the rule does not. Therefore, the requirements of Executive Order 13132 are not applicable.

E. Regulatory Review Costs

If regulations impose administrative costs on private entities, such as the time needed to read and interpret this final rule, we are required to estimate the cost associated with regulatory review. We modeled our estimates of this burden based on similar estimates presented in the CMS Interoperability and Patient Access final rule (85 FR 25510). In the proposed rule, we cited three numbers that were needed to calculate this estimate: (1) number of staff per entity performing the reading; (2) number of hours of reading; and (3) number of entities reviewing the final rule. We estimated a one-time aggregated total review cost of $1.3 million ($128.71 × 10 hours of reading time × 500 entities × two staff per entity). We requested comments on our estimate and assumptions. However, we did not receive any comments. For further details on this matter, refer to the proposed rule at 87 FR 76343. Therefore, we are finalizing the analysis as presented.

F. Impact of Individual Proposals

The provisions of this final rule all have information collection-related burdens. This information is provided in Table J9 in section III. of this final rule. Table K2 provides a list of the ICRs by number and title, as well as the table numbers in which we provided an impact assessment.

Additionally, this RIA section provides an analysis of expected savings to providers arising from the replacement of paper documents related to prior authorization and other plan requirements with EHRs. Although these savings are neither included in the Monetized Table (Table K11) nor in the Summary Table (Table K9), we believe that these large savings are an important consideration in understanding this final rule. We have identified our assumptions for savings at the end of this section.

Comment: Several commenters sought clarification regarding CMS's analysis of how the proposed rule would impact industry. Commenters stated that the discussion of the costs and benefits of the proposed rule was not specific enough and disagreed with CMS's claim that the benefits of the provisions are greater than the costs. Additionally, a commenter noted that the costs estimated in the proposed rule vastly underestimate the true cost of implementing and complying with the provisions. The commenters provided recommendations on certain concepts and ideas that CMS should take into consideration when assessing the regulatory impact of this rule.

A few commenters expressed concerns over the calculations associated with prior authorization. For example, one commenter noted that CMS failed to account for the increase in prior authorization burden since the publication of the Casalino report in 2009. Another commenter noted that CMS failed to include a 2.5 percent fee for electronic prior authorization transactions and the costs healthcare providers expect to incur. A commenter agreed that some upfront costs would be incurred but noted that new burdens and costs would be imposed on payers, which must be considered. Another commenter noted that there is little to no quantitative or qualitative data to justify CMS's approach to calculating cost and savings associated with the provisions in this rule.

Several commenters recommended that CMS work with payers and providers to develop protocols to help identify specific cost savings and efficiencies from automating the prior authorization process.

Response: CMS bases the impact analysis on data we can obtain from past research and other available information. During development of the proposed rule, we made certain assumptions about implementation and development costs. However, based on the number of pilots in the launch phase, we are optimistic that we will have additional data following implementation. To the extent feasible, we encourage industry to share data with us, which would be subject to all requested confidentiality and proprietary protections afforded under the Freedom of Information Act. We will look for opportunities to engage with impacted entities to identify both cost savings and expenditures based on automation of prior authorization processes which would support the publication of the findings.

Comment: A commenter noted that it is unrealistic for CMS to expect that industry can obtain the resources necessary to comply with these policies within the current budget year when the requirements will not be finalized until the final rule is issued. The commenter recommended that CMS revise the compliance dates for these provisions to be 36 months after issuance of the final rule and scheduled on a date other than the end of a calendar year. Another commenter recommended that CMS reconsider the proposed timeline of certain provisions in the rule given the critiques on the RIA and consider reshaping this rule into a roadmap with milestones along the journey that would signal that a new requirement was ready for implementation. A commenter recommended that CMS adjust the RIA to account for changes in the FHIR-based standards and recommended IGs.

Response: We appreciate concerns about implementation costs and timing, as they pertain to this impact analysis, for states which are dependent on state fiscal timelines for approvals and procurements. We also remind readers that some impacted payers may be eligible to apply for extensions, exceptions, and exemptions under certain circumstances, as described in section II.E. of this final rule. We believe that the finalized extensions, exceptions, and exemptions will adequately address any contingencies faced by individual payers and other affected entities. Finally, as stated in section I.D. of this final rule, we are finalizing compliance dates in 2027 for the policies in this final rule that require API development or enhancement, in recognition of the need for analysis, procurement, training, testing, and development. We appreciate the commenter's feedback on updating our impact analyses to account for changes to the FHIR standards, specifications, and IGs. However, we disagree that updates to standards, specifications, and IGs should be accounted for in the impact analysis. Changes to standards, specifications, and IGs do not have any bearing on the calculation of an impact analysis. We acknowledge that it will be important for implementers to remain engaged in the HL7 workgroups and implementation forums. We are requiring entities to use certain IGs specified in this final rule and the ONC Cures Act final rule (85 FR 25642); those standards will remain consistent. Should there be updates to any of those standards or IGs, changes will be made available to implementers through SVAP, as they are tested and approved by ONC. Industry is strongly encouraged to participate in that process to ensure awareness and readiness, but we do not believe that the changes or process for those changes is of significance for the impact analysis.

Finally, as discussed earlier in this final rule, some commenters wrote regarding the potential costs that might be passed on to providers from EHR vendors or payers for use of the APIs, in the form of user fees. We recognize that EHR vendors, providers, and payers have costs of doing business, particularly for the development and implementation of the APIs, as described in this RIA. We strongly encourage EHR vendors to only charge reasonable fees for any initial or periodic system configurations required to access payers' API endpoints. We did not include information regarding user fees for APIs in this impact analysis because of the lack of available data on the costs incurred between payers, developers, EHRs and providers. However, we are committed to monitoring and evaluating the expanding landscape of API usage and will consider opportunities to provide future guidance on this topic, to ensure that we can provide comprehensive and up-to-date information for our industry partners.

The Summary Table (Table K9) of this section, using Table J9 as a basis, provides a 10-year impact estimate. Table K9 includes impact by year, by type (parent organizations, including state Medicaid and CHIP agencies), as well as the cost burden to the Federal Government, allocations of cost by program, and payments by the Federal Government to MA organizations, Medicaid, and CHIP, as well as the premium tax credits (PTCs) paid to certain enrollees in the individual market.

G. Alternatives Considered

We stated in the proposed rule that we are continuing to build on the efforts initiated with the CMS Interoperability and Patient Access final rule (85 FR 25510) and the work we have done to advance interoperability, improve care coordination, and empower patients with access to their data. This final rule covers several provisions aimed at achieving these goals. We described alternatives to our proposals in the proposed rule and the reasons we did not select them as proposed provisions. The details for each of those alternatives and the rationale behind not including them are available in the proposed rule at 87 FR 76344.

1. Alternatives Considered for the Patient Access API Enhancements

We are finalizing modifications to our proposals to require payers to make enhancements to the Patient Access API, which was finalized in the CMS Interoperability and Patient Access final rule (85 FR 25510). We are requiring payers to make additional information available to patients through the Patient Access API and to report certain metrics about patient use of the Patient Access API to CMS annually. We considered several policy alternatives for the Patient Access API. These are described in the proposed rule at 87 FR 76344, and relevant comments regarding the Patient Access API are addressed in section II.A. of this final rule.

Regarding reporting Patient Access API metrics, we considered requiring impacted payers to publicly report these metrics more frequently than annually. For example, we considered a quarterly requirement. Public comments on the December 2020 CMS Interoperability proposed rule (85 FR 82586) indicated a preference for less frequent reporting to reduce burden on payers. Annual statistics on such utilization should be sufficient to accomplish our goal of understanding patient utilization of the API. Comments regarding reporting on Patient Access API metrics are addressed in section II.A. of this final rule.

The quantitative effect of quarterly reporting will likely not change the bottom line of $1.6 billion cost over 10 years shown in Table K9. However, we acknowledge it may change marginally to $1.7 billion. As shown in the various tables of section III. of this final rule, the annual cost of reporting is estimated at $3.2 million based on hours of work required by a business operations specialist. If we required quarterly reporting this would quadruple the estimate or add about $10 million annually—or a little under $100 million over 10 years. This would raise the $1.558 billion cost to at most $1.658 which, when rounded, would be either $1.6 or $1.7 billion.

We also considered earlier compliance dates for the proposed enhancements to the Patient Access API. In the proposed rule, we stated it would be more appropriate, and less burdensome on impacted payers to propose compliance dates for these provisions in 2026 (by January 1, 2026, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2026, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2026, for QHP issuers on the FFEs), which would have provided a 2-year implementation timeframe. However, based on public comments, we are finalizing a compliance dates in 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs) for the policies in this final rule that require API development or enhancement. Additional information regarding the updated compliance dates for the APIs is available in sections I.D., II.A., II.B., II.C., and II.D. of this final rule.

Had we implemented the rule a year earlier, the aggregate $1.6 billion over 10 years would change to $1.7 billion over 10 years. The total cost for creating the various APIs would not change; rather, they would be apportioned over 2 years rather than 3 years. However, if we required compliance a year earlier, then the maintenance costs of $142 million per year would begin in year 3 rather than in year 4. This would add an extra $142 million per year of cost raising the aggregate 10-year cost of $1.55 billion to $1.69 billion or $1.7 billion after rounding.

2. Alternatives Considered for the Provider Access API

To better facilitate the coordination of care across the health care continuum, we are finalizing our proposal to require impacted payers to implement and maintain a Provider Access API. This API will require payers to make available to certain providers the same types of data they make available to patients via the enhanced Patient Access API.

As noted in the proposed rule at, we considered other data types that could be exchanged via the Provider Access API and considered only requiring the exchange of all data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI) (87 FR 76345). While this would have required that less data be exchanged and, thus, be less burdensome for impacted payers to implement, we believed that claims and encounter information would complement the content standard and offer a broader and more holistic understanding of a patient's interactions with the health care system. Furthermore, the data that we proposed to be made available through the Provider Access API aligns with the data that we proposed to be made available to individual patients through the Patient Access API. We also considered including additional data elements as required for the Provider Access API, requiring a complete set of data available from the payer's system. However, we did not receive such suggestions from industry, including patients, and such a large volume of data types might have been overwhelming for providers, would have been an excessive cost, and would likely not have met minimum necessary provisions. A more robust description of the alternatives and our rationale for not selecting those are set out in the proposed rule (87 FR 76346). We did not receive comments specifically on the alternatives considered in this section. Other comments regarding the Provider Access API are addressed in section II.B. of this final rule.

3. Alternatives Considered for the Payer-to-Payer API

We are finalizing our proposal to require impacted payers to implement and maintain a Payer-to-Payer API that makes certain data available to other payers via a FHIR API. This provision will make the same data that is being made available to patients and providers also available to other payers when a patient changes plans. This will allow patients to take their data with them as they move from one payer to another. Before finalizing this provision, we considered several alternative provisions which we described in detail in the proposed rule (87 FR 76346).

For example, in the CMS Interoperability and Patient Access final rule, we finalized a policy to require payers to exchange data with other payers but did not require a specific mechanism for the payer to payer data exchange to occur. Rather, we required impacted payers to receive data in whatever format it was sent and accept data in the form and format it was received, which ultimately complicated implementation by requiring payers to accept data in different formats. The cost to implement these various formats cannot be calculated because there are endless possibilities and combinations of ways the data could have been exchanged under the previously finalized policy.

Unlike the policy finalized in the CMS Interoperability and Patient Access final rule, the use of an API would reduce the amount of implementation cost needed for this data exchange. Importantly, for the Payer-to-Payer API, once an organization implements the other APIs of this final rule, less additional investment will be necessary to implement the payer to payer data exchange, as payers would be able to leverage the infrastructure already established for the Patient Access and Provider Access APIs. The updated background information for the recommended IGs is found in section II.G. and explains how the existing resources can be tailored to meet the provisions set out in this final rule. Given this available infrastructure and the efficiencies of sharing standardized data via the API, we determined it was most advantageous for payers to implement an API for this enhanced data exchange. We did not receive any comments on this section, but comments specific to the proposal for the Payer-to-Payer API are addressed in section II.C. of this final rule.

4. Alternatives Considered for the Prior Authorization API and Other Prior Authorization Process Requirements

We are finalizing our proposals for several important policies to improve the prior authorization process, which we described in the proposed rule (87 FR 76346). Our final policy to require that all impacted payers implement and maintain a Prior Authorization API will ultimately help patients receive the items and services they need in a timely fashion, and support streamlined communication between providers and payers. The Prior Authorization API aims to improve care coordination by providing more structured information about when a prior authorization is required, information that is required to approve a prior authorization, and facilitating electronic prior authorization. The API will be accessible to providers to integrate directly into their workflow while maintaining compliance with the mandatory HIPAA transaction standard. The standards and IGs that support the development of this API are already being tested and piloted with some success between providers and payers, and we believe as enhancements to the IGs are made over the next few years, more organizations will see the benefit for their programs.

As noted previously, we described our considerations for a phased approach, or partial implementation of the API over time, and explained why we did not propose those options. We did not receive comments in support of a partial implementation in part because of the risk that such an option might result in inconsistent implementations and increase burden for providers. As indicated, though quantitative data from current prior authorization pilots have been shared informally with the public, it has not yet been submitted to CMS for use in official evaluations or analysis. CMS anticipates receipt of the pilot results in CY 2024.

Though we do not have specific data, we believe the quantitative effects of a phased in implementation option would be negligible. The total cost of developing the Prior Authorization API would not change; however, such an approach could mean delaying the 25 percent maintenance costs by 1 or 2 years, as well as the overall benefits of the API.

We are finalizing our requirement that impacted payers publish certain data about their performance on prior authorization, on a public website, and though we considered options for this reporting, we believe in the first few years of program implementation it will be important to gather feedback from payers, providers and patients as to the usability of the information being made available before modifying the requirement. As explained in section II.D. of this final rule, CMS is committed to working with impacted entities on best practices for reporting.

We considered using only the X12 278 transaction standard adopted under HIPAA rather than requiring the implementation of a FHIR API to support the Prior Authorization API. While the adopted X12 278 transaction standard defines the content and format for the exchange of data for prior authorization, it does not have the functionality of the FHIR standard or IGs to support the requirements of the Prior Authorization API. This includes the ability to accommodate all of a payers' business rules, indicate which supporting documents are required, create a questionnaire, and conduct an end-to-end transaction via FHIR for real-time responses. We received confirmation through many comments that the X12 standard is not designed to enable using SMART on FHIR apps connected to the provider's EHR system, nor is it designed for the scope envisioned in this rule, including extraction of payer rules, a compilation of data into electronic-based questionnaires, or communication with EHRs. The substantive comments on this subject are addressed in section II.D. of this final rule.

We are finalizing the operational, non-technical provisions related to prior authorization processes, including requirements for certain impacted payers to respond to expedited prior authorization requests within 72 hours, and to standard prior authorization requests within 7 calendar days. We received many comments suggesting that the response timeframes be shortened because of the potential impact on patient care, and those comments are addressed in section II.D. of this final rule.

Understanding the importance of providers and patients getting decisions as quickly as possible, we believe that the timeframes outlined in the proposed rule are a significant step to help increase reliability in the prior authorization process and establish clear expectations without being overly burdensome for payers.

H. Savings Through the Adoption of the Prior Authorization Provisions by Health Care Providers

1. Overview

As described in section II.D. of this final rule, we have finalized new requirements related to prior authorization for impacted payers, and in section II.F. of this final rule, we described a new Electronic Prior Authorization measure and the associated reporting requirements for MIPS eligible clinicians, eligible hospitals, and CAHs.

In section III.C. of this final rule, we discussed the ICRs regarding cost estimates for reporting and the potential burden specifically for the MIPS eligible clinicians, eligible hospitals, and CAHs. Here we address the anticipated cost savings of these provisions for the broader health care provider population, which is inclusive of, but not limited to the MIPS eligible clinicians, eligible hospitals, and CAHs.

We believe that all health care providers can benefit from the provisions for impacted payers to implement the APIs in this final rule and base these cost-savings estimates over 10 years. We use the estimated total number of providers, with estimates described in this section of the final rule. To conduct this analysis, we used available resources and invited comments on our assumptions, the data, and our citations.

The savings estimated in this final rule are true savings, not transfers, since they reflect savings in reducing the administrative costs required to process prior authorizations. However, these savings will be an indirect consequence of the final rule, not direct savings. This final rule supports efforts to significantly reduce time spent on manual activities. In general, it is only appropriate to claim that a regulatory provision's benefits are greater than its costs after a substantive and preferably quantitative, assessment of the pre-existing market failure and the provisions' suitability for addressing it. As a result of data limitations and other analytic challenges preventing such an assessment, the illustrative savings estimates are neither included in the Monetized Table (Table K11) nor the Summary Table (Table K9) of this final rule. Nevertheless, the savings could be significant, and we believe should be a factor in the industry's assessment of this final rule. In the proposed rule, we requested comments on how CMS might attribute savings benefits to avoid double-counting, and how CMS could account for both costs and benefits from policy interactions but did not receive specific comments in response.

We are only quantifying savings of reduced paperwork for health care providers. However, the improved efficiencies outlined in this rule have potential positive consequences, which could lead to savings. Several surveys by the AMA cited in section II.D. of this final rule, list adverse qualitative consequences of the current paper-based prior authorization system, including life-threatening adverse medical events, missed, or abandoned treatments, hospitalization, and permanent bodily damage, however, we do not have specific data related to outcomes.

2. Methodology for Savings Analysis

The approach adopted in quantifying savings is to quantify those that we can reliably estimate and note that they are minimal savings. The provisions of this rule potentially affect individual physicians, physician groups, hospitals, and CAHs. However, for purposes of quantification, we initially estimate a reduced paperwork burden for individual physicians and physician groups, which shows a savings of several billion dollars over 10 years. We base the estimate on the number of hours per week spent on prior authorization, using information about individual physicians and physician groups from survey data we believe to be reliable (three surveys of several thousand groups from 2006, 2021, and 2022 cited in this section of the final rule). To calculate our estimates, we used the same physician information and made certain assumptions of its applicability to hospitals. The purpose of using this comprehensive provider information from three different periods was that no other comprehensive data set was available to identify savings from reduced paperwork. Our initial estimate was for savings of several billion dollars for individual physicians and physician groups.

To estimate reductions in spending on paperwork for prior authorization for hospitals, we assumed that hospitals perform similar prior authorization activities to individual physicians and physician groups. We made this assumption because we do not have a basis for making a more accurate assumption; that is, we do not have survey data of similar quality for hospitals on the number of hours per week spent on prior authorization and the proportion of hours per week spent by physicians, nurses, and clerical staff.

To support the assumptions on potential benefits for hospital prior authorization, we rely on data from previously published rules. To avoid repetition of numbers and sources we summarize all updates in this final rule, along with the estimates of the proposed rule, subtotals, and sources in Table K3. Throughout this section, numbers without specified sources, come from this table.

To calculate the burden and savings for the final rule, we are using the data from the FY 2024 IPPS/LTCH proposed rule (88 FR 27205), FY 2024 OPPS proposed rule (88 FR 49552), and CY 2023 PFS proposed rule (87 FR 46370) rather than the CY 2023 PFS final rule (87 FR 69404) or CY 2024 PFS final rule (88 FR 78818), as these sources more accurately reflect the anticipated number of hospitals and providers impacted by our provisions beginning on January 1, 2027. We believe these sources are more reflective of the eligible hospitals and CAHs who will participate in the Medicare Promoting Interoperability Program and the MIPS eligible clinicians participating in the MIPS Promoting Interoperability performance category over time. We elected to use MIPS eligible clinician participation data from the CY 2023 PFS proposed rule, rather than the CY 2023 PFS final rule or CY 2024 PFS final rule, to estimate the number of MIPS eligible clinicians reporting MIPS Promoting Interoperability data to CMS because the 45 percent reduction in the estimated number of individual MIPS eligible clinicians reporting MIPS Promoting Interoperability data between the CY 2023 PFS proposed rule (based on CY 2019 participation data) and the CY 2023 PFS final rule (based on CY 2021 participation data) appear to be lower due to the effects of the COVID–19 PHE. Likewise, the number of individual MIPS eligible clinicians reporting MIPS Promoting Interoperability data as estimated in the CY 2024 PFS final rule (based on CY 2022 participation data) remain impacted by the COVID–19 PHE, which formally ended on May 11, 2023. We do not believe this reduction in MIPS eligible clinicians reporting MIPS Promoting Interoperability data will be persistent and believe it is reasonable that participation numbers in future years may revert to their former levels (before the COVID–19 PHE).

Additionally, we modified another assumption for this final rule, acknowledging an increase in hours spent on prior authorization from 13 hours per week spent on prior authorization in 2021 to 14 hours per week spent on prior authorization in 2022. We did so using AMA survey data results which we believe are more reasonable. This change in data encouraged us to update our estimations accordingly.

To account for these changes, and to avoid injecting our own subjective biases on the changes, we have included calculations using both years of the AMA prior authorization survey data. The two total savings estimates are based on the AMA prior authorization survey data, one using 2021 survey data and the other using 2022 survey data, which differed by about 10 percent. Both resulted in estimated savings of several billion dollars over 10 years. The amount and effect of these changes as well as the deviation from the proposed rule estimates are set out below.

Additionally, given that estimates for MIPS eligible clinicians reporting MIPS Promoting Interoperability data in the CY 2023 PFS final rule were based on CY 2021 participation data collected during the COVID–19 PHE, we are using data published in the CY 2023 PFS proposed rule as cited in Table K3 for our calculations. We believe that this is reasonable because the MIPS eligible clinician estimates from the CY 2023 PFS proposed rule are based on pre-pandemic participation data from CY 2019. As noted previously, we do not believe the reductions in participation in the MIPS Promoting Interoperability performance category will continue long term. We believe it reasonable to assume that participation numbers will continue to increase, at a minimum, by the compliance dates for the policies that require API development or enhancement (beginning on January 1, 2027).

3. Physicians and Hospitals

The approach presented in the proposed rule, and finalized here, computes aggregate savings for physician or group physician practices by first estimating the savings for a single individual physician or group physician practice based on supporting surveys, and then multiplying this single savings by the number of practices. Using the updated numbers from Table K3 results in savings of at least $15.8 billion over 10 years for individual and physician groups.

We assume hospitals are conducting the prior authorization process in a manner similar to physicians. Thus, the individual physician and group physician practices would save at least $15.8 billion over 10 years, as shown in Table K6, and the combined physician practices and hospitals (207,515 practices consisting of 199,543 individual physician and group physician practices plus 7,972 hospitals and CAHs) would save at least $16.5 billion (207,515/199,543 × $15.8 billion). To the nearest billion, both $15.8 and $16.5 round to $16 billion. The numerical savings are the same whether we include or exclude hospitals.

4. Base Estimates of Paperwork Savings to Providers

In calculating the potential savings, uncertainties arise in four areas. The result of this illustrative analysis is that we find a minimal potential savings point estimate of $15 billion (using 2021 AMA prior authorization survey data) and $16 billion (using 2022 AMA prior authorization survey data) over 10 years. To provide credibility to this savings analysis we have, where we lacked better data, underestimated any unknown quantities with minimal estimates and additionally studied the effect of a range of estimates.

In the next few paragraphs, we summarize the four uncertainties and indicate how we approached the estimation. We refer readers to a more detailed discussion of these assumptions in the proposed rule (87 FR 76348). We received one comment on the quantitative estimate for providers and have responded to that comment elsewhere in the final rule. However, because no additional data was provided, we are not changing general assumptions in this final rule, except that we are updating numbers based on Table K3.

a. Assumptions on the Relative Proportion of Current Workload Hours and Costs by Staff for Prior Authorization

• For labor costs, we used the mean hourly wages from the BLS.
• For total hours spent per week on prior authorization by staff overall we use the latest 2022 AMA survey (Table K3) rather than the estimate used in the proposed rule, which was based on the 2021 AMA prior authorization survey.

• For the estimates of the current proportions by the staff of paperwork involved in prior authorization processes, the type of staff involved, and the type of physician offices, we used numbers in a survey presented by Casalino et al. (2009), which gave a detailed analysis based on a validated survey instrument employed in 2006. By dividing, for each staff type, the total prior authorization time spent per week across all physician practices, over the total prior authorization time spent across all practices and all staff types, we obtained the proportion of time each staff type spent per week on prior authorization. These proportions were applied to the updated total time per week spent on prior authorization as given in Table K3.

The updated results are presented in Table K4 which shows that individual and group physician practices annually used, on average, at least 728 hours per year at a cost of at least $52,642 on prior authorization.

Here, we provide information on the row on registered nurses for demonstration purposes. Registered nurses are estimated to spend at least 9 hours per week on prior authorization, and hence, spend 467.5 hours per year (9 hours per week × 52 weeks per year). By multiplying the 467.5 hours per year spent on prior authorization by the mean wages per hour for registered nurses, $76.94, obtained from the BLS, we obtain an aggregate annual cost of $35,969 for registered nurses dealing with prior authorization. The other rows are interpreted following the same process.

b. Assumptions on the Total Number of Individual and Group Physician Practices

Table K4 presents the current hour and dollar burden for a single physician group and single physician office. To obtain the aggregate annual burden of prior authorizations for all physician practices, we use the data in Table K3, which includes a reference to 199,543 total individual and group physician practices. This number is used to inform Table K6 which represents a 10-year summary of annual costs.

c. Assumptions on the Reduction in Hours Spent on Prior Authorization as a Result of the Provisions of This Final Rule

Table K4 provides current hours spent on prior authorizations. To calculate potential savings, we assume how much these hours will be reduced as a result of the provisions of this final rule.

A detailed discussion driving our assumptions was presented in the proposed rule (87 FR 76350). Based on the provisions in this final rule, we assume that physicians, nurses, and clerical staff will reduce the time they spend on prior authorization by 10 percent, 50 percent, and 25 percent respectively. Having received no comments on our estimates, we have retained these estimates for purposes of the final calculations. The savings, updated with the numbers from Table K3, is presented in Table K5.

The narrative following Table K5 presents the total 10-year savings with different reduction assumptions; however, these different reduction assumptions do not materially change the range of estimates.

To provide an explanation of Table K4, we use registered nurses as an example. registered nurses spend 467.5 hours per year on prior authorization (see Table K3). If we assume that registered nurses, as a result of the finalized provisions of this rule, reduce the number of hours per week by 50 percent (about half a day, or 4 hours, per week) then they would save 233.7 hours per year (50 percent × 467.5 hours). Multiplying the hours saved, 233.7 hours, by the mean hourly wage for registered nurses, $76.94, the annual aggregate savings per physician practice is $17,984. The other rows may be interpreted similarly.

d. Assumptions on the Number of Individual and Group Physician Practices Adopting the Provisions of This Final Rule

As in the proposed rule, we are not assuming that over 10 years all 199,543 individual and group physician practices would adopt the provisions outlined in this final rule. Instead, we assume the following:

• Because of the payment consequences for not adopting the provisions of this final rule, we assume all 54,770 MIPS eligible clinicians (individual and group), a subset of the 199,543 estimated individual and group physician practices, would adopt the provisions in this rule in CY 2027 (the first year for payer compliance). This assumption of compliance by all MIPS eligible clinicians (individual and group) in the first year of payer compliance is consistent with the assumptions in the proposed rule (87 FR 76351).

• As in the proposed rule, by 2036, we assume 50 percent of all individual and physician practices will adopt the provisions of this final rule. The reasons for this assumption are fully discussed in the proposed rule (87 FR 76351). However, we acknowledge that 78 percent of providers have adopted EHRs, in part to meet ONC requirements. Therefore, this estimate of 50 percent is already an underestimate of the percent of individual and physician practices who would adopt and benefit from the provisions of this rule.

• We do not assume a constant increase per year but rather a gradual increase per year, starting with the participation of 54,770 MIPS eligible clinicians in 2027 and growing exponentially to 99,772 (50 percent of 199,543) individual and physician group practices in 2036.

Applying these assumptions, based on the 2022 estimates results (as shown in Table K6), is at least a $15.8 billion ($15,829.3 million) savings over 10 years for individual and group physician practices. If we include hospitals by increasing the amount by 4 percent, the estimate would be at least $16.5 billion ($16,461.7 million). The estimate rounded to the nearest billion is at least $16 billion. Had we used the 2021 estimates we would obtain $15 billion in savings.

This $16 billion revised estimate differs from the $15 billion estimate presented in the proposed rule is due to the change noted in Table K3: a 7.7 percent increase in hours per week spent on prior authorization (14 hours in 2022 versus 13 hours in 2021 based on the AMA survey). This result is consistent with comments from industry who thought our estimates were too low regarding the impact of prior authorization on practices and hospitals. After adjusting for this change estimate, and as noted in Tables K4 and K5, we obtain the additional savings potential. Note that the range of savings based on different assumptions of savings per staff, $13 to $20 billion over 10 years, still includes the estimate of $15 billion as noted in the proposed rule.

The headers of Table K6 show the logic and sources of the column entries. The reduced hours per year per practice spent on prior authorization for 2027 is calculated as shown here: 16.1 million hours equals 294 hours per year per practice × 199,543 practices × 27.45 percent participation. Similarly, the dollar savings per year per practice resulting from reduced time spent on prior authorization, $21,026, obtained from Table K5, when multiplied by 27.45 percent of all 199,543 group and physician practices yields $1.2 billion ($1,151.6 million) reduced dollar spending in 2027.

By summing the reduced hours and dollars per year we obtain an aggregate reduction of at least 220.97 million hours and at least $15.8 billion ($15,829.3 million) in reduced spending on paperwork activities. Finally, by adding 4 percent of these numbers to account for hospitals, we obtain a total annual reduction of at least 229.27 million hours and at least a $16.5 billion ($16,461.7 million) reduction.

As in the proposed rule, we obtained a range of estimates by varying the assumptions of Table K5 which assume that physicians, nurses, and clerical staff save 10, 50, and 25 percent respectively. If we assume that all staff types uniformly reduce hours spent by 33 percent, then dollar spending is reduced by $13.2 billion without hospitals to $13.7 billion with hospitals factored in over 10 years. If we assume that all staff types uniformly reduce hours spent by 50 percent, then dollar spending is reduced by about $19.8 billion without hospitals to $20.6 billion with hospitals factored in. Thus, the range of savings, $10 billion to $20 billion presented in the proposed rule, is slightly narrowed in this final rule to $13 to $20 billion, including providers and hospitals.

I. Summary of Costs to the Federal Government

In this section, we present a 10-year Summary Table of costs (Table K9), an analysis of Federal impacts, and the Monetized Table (Table K11).

To analyze the cost of this final rule to the Federal Government, we utilize a method of allocating costs by program (MA, Medicaid, CHIP, and QHP issuers on the FFEs). As the cost is shared by the 365 parent organizations, including state Medicaid and CHIP agencies, there is no readily available way to allocate costs per parent organization across programs since the percentage of each parent organization's expenditures on the different programs is not publicly available.

To address this, we utilize the same method used in the CMS Interoperability and Patient Access final rule (85 FR 25612). In that final rule, we used the public CMS Medical Loss Ratio (MLR) files, which break out total premiums among the various programs. The advantages and disadvantages of such an approach are fully discussed in that rule. Table K7 presents the 2021 MLR data of premiums by program and the resulting percentages by program. We use these percentages to allocate costs by program. This allocation of cost by program forms a basis to calculate the Federal Government's cost for the proposed provisions of this rule.

To calculate Federal costs for MA organizations, we use the CMS internal data used to produce the CMS Trustees' Report. This internal data indicates that the Trust Fund will pay about 34 percent of plan costs over the next 10 years. The remaining costs (for the 98 to 99 percent of plans bidding below the benchmark) are borne by the plans. Similarly, we can calculate the Federal Medicaid payments using the percentages in Table K8.

Table K8 is based on the most recent projections of the CMS OACT for the FY 2024 Budget.

We illustrate the interpretation of the column by explaining the items in the 2025 column. The number at the bottom of the column, 65.40 percent, answers the question “What proportion of the interoperability systems costs for Medicaid is the Federal Government expected to pay?” There are two components to this calculation.

The first is the share of Medicaid managed care. Those costs are directly paid by the MCOs, which in turn would be expected to raise administrative costs for those plans. The Federal share of that is: Federal Medical Assistance Percentage (FMAP) × the managed care (MC) share of Medicaid; for 2025, this is 58.10 percent × 56.80 percent. The second is the share of the FFS program costs. The FFS program side of Medicaid would have higher administrative costs. The Federal share of this would be 90 percent in year 1 and 75 percent after year 1. For 2025, this is equal to 75 percent × (1–56.8 percent). The sum of these two components, 58.10 percent × 56.80 percent + 75 percent × (1−56.8 percent), equals 65.40 percent as shown in the bottom row. When we multiply, in Table K9, the total annual cost of interoperability for Medicaid by 65.40 percent we obtain the amount the Federal Government is expected to pay for the interoperability system costs for Medicaid.

It should be noted that although the compliance dates for policies in this final rule that do not require API development or enhancement are in 2026, and the compliance dates for policies that require API development or enhancement are in 2027. We expect plans to begin constructing software systems for the provisions that require API development or enhancement upon publication of this final rule.

Based on the discussion presented in Tables K7 and K8, Table K9 presents the calculation of all numerical impacts of this final rule by program, government, and QHP issuers on the FFEs.

For Table K9:

• As explained in connection with Table J9 in the Collection of Information section, the data in Table K9 is based on 2027 compliance dates for policies that require API development or enhancement and the Electronic Prior Authorization measure for MIPS and the Medicare Promoting Interoperability Program and compliance dates in 2026 for the policies that do not require API development or enhancement.

• The bottom-line totals in the columns of Table J9 labeled “1st Year Cost” through “4th Year Cost” are the totals found in the “Total Cost” column of Table K9 in rows 2024 through 2027 respectively. The totals in the column “4th and Subsequent Year Costs” in Table J9 are found in the rows labeled 2028 through 2033 in the “Total Cost” column of Table K9.
• The Total Cost to MIPS Eligible Clinicians, Eligible Hospitals and CAHs column reflects the aggregate cost of producing reports for MIPS eligible clinicians (including individual clinicians and groups), eligible hospitals, and CAHs, as found in Table J9 for years 2027 and further.
• The total 10-year cost (excluding PTC payments and savings from prior authorization) is, as shown in Table K9, $1.6 billion. This number uses the primary estimates for the provisions that require API development or enhancement. The low and high 10-year total costs are $0.8 billion and $2.3 billion, respectively.
• The Cost of Final Rule to Payers by Program columns: We applied the percentages from Table K7 to obtain the cost of the rule to payers by program (MA, Medicaid, CHIP, and QHP issuers on the FFEs).
• The Cost of Final Rule to Government by Program columns: For the QHP issuers on the FFEs, the government does not pay anything. For managed care the Government pays approximately 34 percent (the exact amount varying slightly from year to year and was obtained from projections by OACT). For Medicaid, we applied the percentages of payment by the Federal Government discussed in the narrative in Table K8 to obtain the cost by program.

• PTC Payments: The Government does not reimburse QHP issuers on the FFEs, neither prospectively nor retrospectively, for their expenses in furnishing health benefits. However, the government offers QHP enrollees PTCs to help cover the cost of premiums for the plans. QHP issuers on the FFEs have the option to deal with increased costs by either temporarily absorbing them (for purposes of market competitiveness—see, however, a caveat elsewhere in this RIA), increasing premiums to enrollees, or reducing non-essential health benefits. To the extent that issuers increase premiums for individual market QHPs on the FFEs, there would be Federal PTC impacts. The purpose of the PTC is to assist enrollees in paying premiums. Because PTC is available only if an individual purchases a QHP on an Exchange and the individual generally has a household income between 100 and 400 percent of the Federal Poverty Level, the PTC estimates apply only to Exchange plans. Note, the Inflation Reduction Act of 2022 (IRA) extended the expanded PTC eligibility provision set forth in the American Rescue Plan Act of 2021 (ARP) through the 2025 plan year.

In the PTC estimate, we have accounted for the fact that some issuers have both Exchange and non-Exchange plans, and some issuers have only non-Exchange plans. We reflected these assumptions with global adjustments, so we believe the estimates are reasonable in aggregate. Specifically, the methodology to estimate the PTC impact of the projected expense burden is consistent with the method used to estimate the PTC impact in the CMS Interoperability and Patient Access final rule (85 FR 25612). Within the FFE states, the estimated expense burden would impact premium rates in the individual market and is spread across both Exchange and non-Exchange plans. PTCs are only paid in the Exchanges and are calculated as a function of the second lowest-cost silver plan and the eligible individual's household income. The estimate of these impacts uses the assumption that the industry would increase the second lowest-cost silver plan premium rate in the same amount as the overall premium rate increase. This assumption allows the application of the overall rate increase to the projected PTC payments in the FFE states to estimate the impact on PTC payments.

• The total cost to the government is the sum of payments related to each program. This payment is a transfer from the Government to payers for MA and Medicaid, CHIP, and QHP enrollees.
• For MA organizations, Medicaid and CHIP, the remaining costs are the difference between the total cost to payers and what the Federal Government pays. For the individual market, the remaining costs to payers would be the total cost absorbed by the payers and not passed on through premium increases. Since the PTC is paid on behalf of individuals and not the payers, it therefore does not reduce the expenses of the payers.

The dollar savings from reduced paperwork burden for an increase in using electronic prior authorization (Tables K4 and K5) is not included in Table K9.

Table K10 describes how the various plans (and states) would bear the costs remaining after federal payments. We follow the same methodology and discussion presented in the CMS Interoperability and Patient Access final rule (85 FR 25612). In the table we explain the possible ways payers may manage extra implementation costs. We emphasize that Table K10 only includes possibilities. The impacted payers would make decisions about how to defray these remaining costs based on market dynamics and internal business decisions; we have no uniform way of predicting what these actual behaviors and responses will be.

• Individual Market Plans: Individual market plans have the option of absorbing costs or passing costs to enrollees in the form of higher premiums. In some cases, for reasons of market competitiveness, plans may absorb the increased costs rather than increase premiums.

• Medicaid and CHIP: Assuming roughly 71 million patients enrolled nationally (inclusive of state Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities), Medicaid and CHIP would see an added cost of under a dollar per beneficiary per year; this contrasts with a total cost per beneficiary per year for the Medicaid and CHIP programs of several thousand dollars.

• Medicare Advantage: In their bids (submitted in the month of June prior to the beginning of the coverage year), MA plans would address the reduced rebates (arising from increased bid costs due to the increased costs of this final rule being included in the bid) by either: temporarily absorbing costs by reducing profit margins, reducing the supplemental benefits paid for by the rebates, or raising enrollee cost-sharing or premium. We believe many plans, for competitive reasons, would choose to retain a zero-dollar premium increase and either absorb losses for 1 year or reduce rebate-funded supplemental benefits.

We received no comments specific to Table K10 or the methods impacted payers will use to deal with the costs of this rule and are therefore finalizing it as is.

J. Accounting Statement and Table

As required by OMB Circular A–4 (available at https://www.whitehouse.gov/wp-content/uploads/legacy_drupal_files/omb/circulars/A4/a-4.pdf ), the following table, Table K11, summarizes the classification of annualized costs associated with the provisions of this final rule for the 10 years, 2024 through 2033. This accounting table is based on Table K9 and includes the costs of this final rule to certain providers, including hospitals and CAHs, MA organizations, state Medicaid and CHIP programs, and QHP issuers on the FFEs. It does not include the potential savings from Table K6 arising from reduced burden due to providers, hospitals, and CAHs using electronic prior authorization. Minor discrepancies in totals reflect use of underlying spreadsheets, rather than intermediate rounded amounts. Table K11 is stated in 2023 dollars, with expected compliance dates in 2027 for the provisions of this final rule that require API development or enhancement.

In accordance with the provisions of Executive Order 12866, this final rule was reviewed by OMB.

Chiquita Brooks-LaSure, Administrator of the Centers for Medicare & Medicaid Services, approved this document on January 12, 2024.

List of Subjects

42 CFR Part 422

• Administrative practice and procedure
• Health facilities
• Health maintenance organizations (HMO)
• Medicare
• Penalties
• Privacy
• Reporting and recordkeeping requirements

42 CFR Part 431

• Grant programs—health
• Health facilities
• Medicaid
• Privacy
• Reporting and recordkeeping requirements
• State fair hearings

42 CFR Part 435

• Aid to Families with Dependent Children
• Grant programs—health
• Medicaid
• Notices
• Reporting and recordkeeping requirements
• Supplemental Security Income (SSI)
• Wages

42 CFR Part 438

• Grant programs—health
• Medicaid
• Reporting and recordkeeping requirements

42 CFR Part 440

• Grant programs—health
• Medicaid

42 CFR Part 457

• Administrative practice and procedure
• Grant programs—health
• Health insurance
• Reporting and recordkeeping requirements

45 CFR Part 156

• Administrative practice and procedure
• Advertising
• Brokers
• Conflict of interests
• Consumer protection
• Grant programs—health
• Grants administration
• Health care
• Health insurance
• Health maintenance organizations (HMO)
• Health records
• Hospitals
• Indians
• Individuals with disabilities
• Intergovernmental relations
• Loan programs—health
• Medicaid
• Organization and functions (Government agencies)
• Prescription drugs
• Public assistance programs
• Reporting and recordkeeping requirements
• Technical assistance
• Women
• Youth

For the reasons set forth in the preamble, the Centers for Medicare & Medicaid Services amends 42 CFR chapter IV and the Department of Health and Human Services amends 45 CFR part 156 as set forth below:

PART 422—MEDICARE ADVANTAGE PROGRAM

1. The authority citation for part 422 continues to read as follows:

Authority: 42 U.S.C. 1302, 1306, 1395w–22 through 1395w–28, and 1395hh.

2. Section 422.119 is amended by—

a. In paragraph (b)(1)(ii), removing the word “and” at the end of the paragraph;

b. Revising paragraph (b)(1)(iii);

c. Adding paragraphs (b)(1)(iv) and (v); and

d. Revising paragraphs (c)(1), (c)(4)(ii)(C), (e)(2), (f), and (h).

The revisions and additions read as follows:

3. Section 422.121 is added to read as follows:

4. Section 422.122 is added to read as follows:

5. Section 422.568 is amended by—

a. Revising paragraph (b)(1);

b. Redesignating paragraph (b)(2) as paragraph (b)(3);

c. Adding new paragraph (b)(2); and

d. In newly redesignated paragraph (b)(3), removing the phrase “under the provisions in paragraph (b)(1)(i) of this section” and adding in its place the phrase “under the provisions in paragraph (b)(2) of this section.”

The revision and addition read as follows:

6. Section 422.570 is amended in paragraph (d)(1) by removing the phrase “request to the standard timeframe and make the determination within the 72-hour or 14-day timeframe, as applicable, established” and adding in its place the phrase “request to a standard organization determination and make the determination within the applicable timeframe, established”.

7. Section 422.631 is amended by revising paragraphs (d)(2)(i)(B), (d)(2)(iv)(B)( 1), and (d)(2)(iv)(B)( 2)( i) to read as follows:

PART 431—STATE ORGANIZATION AND GENERAL ADMINISTRATION

8. The authority citation for part 431 continues to read as follows:

Authority: 42 U.S.C. 1302.

9. Section 431.60 is amended by—

a. Revising paragraph (b)(3);

b. Adding paragraphs (b)(5) and (6);

c. Revising paragraphs (c)(1), (c)(4)(ii)(C), and (e)(2);

d. Removing paragraph (g);

e. Redesignating paragraph (f) as paragraph (g); and

f. Adding new paragraph (f) and paragraph (h).

The revisions and addition read as follows:

10. Section 431.61 is added to read as follows:

11. Section 431.80 is added to subpart B to read as follows:

12. Section 431.201 is amended by revising the definition of “Action” to read as follows:

13. Section 431.220 is amended by—

a. In paragraph (a)(1)(iv), removing the term “or” from the end of the paragraph;

b. In paragraph (a)(1)(v), removing the period from the end of the paragraph and adding in its place “; or”; and

c. Adding paragraph (a)(1)(vi).

The addition reads as follows:

PART 435—ELIGIBILITY IN THE STATES, DISTRICT OF COLUMBIA, THE NORTHERN MARIANA ISLANDS, AND AMERICAN SAMOA

14. The authority citation for part 435 continues to read as follows:

Authority: 42 U.S.C. 1302.

15. Section 435.917 is amended by—

a. Revising the headings of paragraphs (a) and (b); and

b. Revising paragraph (b)(2).

The revisions read as follows:

PART 438—MANAGED CARE

16. The authority citation for part 438 continues to read as follows:

Authority: 42 U.S.C. 1302.

17. Section 438.9 is amended by revising paragraph (b)(7) to read as follows:

18. Section 438.62 is amended by removing paragraphs (b)(1)(vi) and (vii).

19. Section 438.210 is amended by—

a. Revising paragraphs (d)(1) and (d)(2)(i);

b. Redesignating paragraph (f) as paragraph (g); and

c. Adding new paragraph (f).

The addition and revision read as follows:

20. Section 438.242 is amended by revising paragraph (b)(5) and adding paragraphs (b)(7) through (9) to read as follows:

PART 440—SERVICES: GENERAL PROVISIONS

21. The authority citation for part 440 continues to read as follows:

Authority: 42 U.S.C. 1302.

22. Section 440.230 is amended by adding paragraph (e) to read as follows:

PART 457—ALLOTMENTS AND GRANTS TO STATES

23. The authority citation for part 457 continues to read as follows:

Authority: 42 U.S.C. 1302.

24. Section 457.495 is amended by revising paragraph (d) to read as follows:

25. Section 457.700 is amended by revising paragraph (c) to read as follows:

26. Section 457.730 is amended by—

a. Revising paragraph (b)(3);

b. Adding paragraphs (b)(5) and (6);

c. Revising paragraphs (c)(1), (c)(4)(ii)(C), and (e)(2);

d. Removing paragraph (g);

e. Redesignating paragraph (f) as paragraph (g); and

f. Adding new paragraph (f) and paragraph (h).

The revisions and additions read as follows:

27. Section 457.731 is added to read as follows:

28. Section 457.732 is added to read as follows:

29. Section 457.1206 is amended by revising paragraph (b)(6) to read as follows:

30. Section 457.1230 is amended by revising paragraph (d) to read as follows:

TITLE 45—Public Welfare

PART 156–HEALTH INSURANCE ISSUER STANDARDS UNDER THE AFFORDABLE CARE ACT, INCLUDING STANDARDS RELATED TO EXCHANGES

31. The authority citation for part 156 continues to read as follows:

Authority: 42 U.S.C. 18021–18024, 18031–18032, 18041–18042, 18044, 18054, 18061, 18063, 18071, 18082, and 26 U.S.C. 36B.

32. Section 156.221 is amended by—

a. In paragraph (b)(1)(ii), removing the word “and” at the end of the paragraph;

b. Revising paragraph (b)(1)(iii);

c. Adding paragraphs (b)(1)(iv) and (v); and

d. Revising paragraphs (c)(1), (c)(4)(ii)(C), (e)(2), (f), and (i).

The revisions and addition read as follows:

33. Section 156.222 is added to read as follows:

34. Section 156.223 is added to read as follows: