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:

Proposed rule.

SUMMARY:

This proposed rule would place new requirements on 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) to improve the electronic exchange of healthcare data and streamline processes related to prior authorization, while continuing CMS' drive toward interoperability in the healthcare market. This proposed rule would also add a new measure for eligible hospitals and critical access hospitals (CAHs) under the Medicare Promoting Interoperability Program and for Merit-based Incentive Payment System (MIPS) eligible clinicians under the Promoting Interoperability performance category of MIPS. These policies taken together would play a key role in reducing overall payer and provider burden and improving patient access to health information.

DATES:

To be assured consideration, comments must be received at one of the addresses provided below, no later than 5 p.m. on March 13, 2023.

ADDRESSES:

In commenting, please refer to file code CMS-0057-P.

Comments, including mass comment submissions, must be submitted in one of the following three ways (please choose only one of the ways listed):

1. Electronically. You may submit electronic comments on this regulation to https://www.regulations.gov. Follow the “Submit a comment” instructions.

2. By regular mail. You may mail written comments to the following address ONLY: Centers for Medicare & Medicaid Services, Department of Health and Human Services, Attention: CMS-0057-P, P.O. Box 8013, Baltimore, MD 21244-8013.

Please allow sufficient time for mailed comments to be received before the close of the comment period.

3. By express or overnight mail. You may send written comments to the following address ONLY: Centers for Medicare & Medicaid Services, Department of Health and Human Services, Attention: CMS-0057-P, Mail Stop C4-26-05, 7500 Security Boulevard, Baltimore, MD 21244-1850.

For information on viewing public comments, see the beginning of the SUPPLEMENTARY INFORMATION section.

FOR FURTHER INFORMATION CONTACT:

Alexandra Mugge, (410) 786-4457, for general questions related to any of the policies in this proposed 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 Requirements, Documentation, and Decision (PARDD) Application Programming Interface (API).

Shanna Hartman, (410) 786-0092, for issues related to the Payer-to-Payer API, the Electronic Prior Authorization measure 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 proposed rule.

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

Scott Weinberg, (410) 786-6017, for issues related to the Provider Access API policies, or the Requests for Information.

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.

Ariel Novick, (301) 492-4309, 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:

Inspection of Public Comments: All comments received before the close of the comment period are available for viewing by the public, including any personally identifiable or confidential business information that is included in a comment. We post all comments received before the close of the comment period on the following website as soon as possible after they have been received: https://www.regulations.gov. Follow the search instructions on that website to view public comments. CMS will not post on Regulations.gov public comments that make threats to individuals or institutions or suggest that the individual will take actions to harm the individual. CMS continues to encourage individuals not to submit duplicative comments. We will post acceptable comments from multiple unique commenters even if the content is identical or nearly identical to other comments.

Table of Contents

I. Background and Summary of Provisions

A. Purpose and Background

B. Summary of Major Proposals

II. Provisions of the Proposed Rule

A. Patient Access API

B. Provider Access API

C. Payer to Payer Data Exchange on FHIR

D. Improving Prior Authorization Processes

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

F. Interoperability Standards for APIs

III. Requests for Information

A. Request for Information: Accelerating the Adoption of Standards Related to Social Risk Factor Data

B. Request for Information: Electronic Exchange of Behavioral Health Information

C. Request for Information: Improving the Electronic Exchange of Information in Medicare Fee-for-Service

D. Request for Information: Advancing Interoperability and Improving Prior Authorization Processes for Maternal Health

E. Request for Information: Advancing the Trusted Exchange Framework and Common Agreement (TEFCA)

IV. Collection of Information Requirements

V. Response to Comments

VI. Regulatory Impact Analysis

Regulations Text

I. Background and Summary of Provisions

A. Purpose and Background

In the May 1, 2020, Federal Register , we published a final rule implementing the first phase of CMS interoperability rulemaking 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) (hereinafter referred to as the “CMS Interoperability and Patient Access final rule”).

On December 18, 2020, we published a proposed rule (85 FR 82586) (hereinafter referred to as the “December 2020 CMS Interoperability proposed rule”) in which we proposed new requirements for state Medicaid FFS programs, state CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to improve the electronic exchange of healthcare data and streamline processes related to prior authorization, while continuing CMS' drive toward interoperability and reducing burden in the healthcare market. In addition, on behalf of the Department of Health and Human Services (HHS), the Office of the National Coordinator for Health Information Technology (ONC) proposed the adoption of certain specified implementation guides (IGs) needed to support the proposed Application Programming Interface (API) policies in that proposed rule.

We received approximately 251 individual comments on the December 2020 CMS Interoperability proposed rule by the close of the comment period on January 4, 2021. While commenters largely supported the intent of the proposals and the proposals themselves, many noted and emphasized that MA organizations were not included among the impacted payers. The National Association of Medicaid Directors and state Medicaid programs expressed concerns about the implementation timeframes, states' constraints to secure the funding necessary to implement the requirements of the rule in a timely manner, and states' ability to recruit staff with necessary technical expertise. Commenters also raised concerns that the relatively short comment period inhibited more thorough analyses of the proposals and, for membership organizations, the ability to receive input from and gain consensus among their members. The December 2020 CMS Interoperability proposed rule will not be finalized; we considered whether to issue a final rule based on that proposed rule, but considering the concerns raised by the commenters, we have opted not to do so. Instead, we are withdrawing the December 2020 CMS Interoperability proposed rule and issuing this new proposed rule that incorporates the feedback we received from stakeholders on that proposed rule. This approach will allow us to incorporate the feedback we have already received and provide additional time for public comment.

Some of the changes we have incorporated in this proposed rule were influenced by the comments we received on the December 2020 CMS Interoperability proposed rule. For example, unlike in that proposed rule, we now propose to require impacted payers to use those health information technology (IT) standards at 45 CFR 170.215 that are applicable to each set of API requirements proposed in this rule, including the HL7 Fast Healthcare Interoperability Resources (FHIR) standard, the HL7 FHIR US Core Implementation Guide, and the HL7 SMART Application Launch Framework Implementation Guide. Also, in this proposed rule, we include MA organizations as impacted payers and propose that the policies included herein would have a longer implementation timeline.

Most of the implementation dates for the proposals included in this proposed rule would begin in 2026, including those for the API proposals, prior authorization decision timeframes for certain impacted payers, and certain reporting proposals. We believe a three-year timeline to recruit and train staff, update or build the APIs, and update operational procedures would be sufficient for these proposals, particularly based on the information we have from some payers and providers regarding similar initiatives already in progress. In addition to the proposed three-year implementation timeframe, we propose to give state Medicaid and CHIP FFS programs an opportunity to seek an extension of proposed implementation deadlines, or an exemption from meeting certain proposed requirements, in certain circumstances. Additionally, we include a proposal to provide an exceptions process for issuers of QHPs on the FFEs. We believe the three-year timeframe would offer sufficient time for these impacted payers to evaluate their qualifications to participate in the API proposals in this proposed rule and to prepare the necessary documentation to request an extension, exemption, or exception.

We are proposing some clarifications to existing Medicaid beneficiary notice and fair hearing regulations which apply to Medicaid prior authorization decisions. Because these are clarifications and improvements to existing regulations, these policies would become effective upon the effective date of a final rule if these proposals are finalized as proposed. We are also proposing terminology changes in section II.A.2.e related to the Patient Access API that would take effect with the effective date of the final rule, should these proposals be finalized as proposed.

We are proposing a new Electronic Prior Authorization measure for eligible hospitals and CAHs under the Medicare Promoting Interoperability Program and for MIPS eligible clinicians under the Promoting Interoperability performance category of MIPS, which is in direct response to comments we received on the December 2020 CMS Interoperability proposed rule.

We are re-issuing two requests for information (RFIs) that were included in the December 2020 CMS Interoperability proposed rule. We are also issuing three new RFIs: one to solicit information related to opportunities for improving the electronic exchange of medical documentation between providers to support prior authorization programs for Medicare FFS, a second to gather public feedback regarding data standardization and use of prior authorization to improve maternal health care, and a third to solicit comment regarding enabling exchange under the Trusted Exchange Framework and Common Agreement (TEFCA).

With this new proposed rule, we are taking an active approach to move certain participants in the healthcare market toward interoperability by proposing policies for the MA program, Medicaid, CHIP, and QHP issuers on the FFEs, as well as eligible hospitals and CAHs under the Medicare Promoting Interoperability Program and for MIPS eligible clinicians under the Promoting Interoperability performance category of MIPS.

Our proposals emphasize improving health information exchange and facilitating appropriate and necessary patient, provider, and payer access to information in health records. We also include several proposals intended to reduce payer, provider, and patient burden by improving prior authorization processes and helping patients remain at the center of their own care. Prior authorization refers to the process through which a healthcare provider, such as an individual clinician, acute care hospital, ambulatory surgical center, or clinic, obtains approval from a payer before providing care. Prior authorization requirements are established 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.

For purposes of this proposed 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 proposed provisions of this rule. We believe that the proposed standards would be overly burdensome for both SADP and SHOP issuers. Requiring issuers offering only SADPs and QHPs in the FF-SHOPs, which have relatively lower enrollment and premium intake compared to individual market QHPs, to comply with the proposals in this rule could result in those issuers no longer participating in the FFEs, which would not be in the best interest of the enrollees. The categorical exclusion of these issuers is consistent with CMS' approach to some other QHP requirements. We also propose offering an exceptions process for QHP issuers on the FFEs for the API requirements proposed in this rule, that would be conditioned upon approval of a narrative justification that meets CMS requirements. The proposed exceptions processes could apply to small issuers, financially vulnerable issuers, or new entrants to the FFEs that demonstrate that deploying standards-based API technology consistent with the proposed policies would pose a significant barrier to the issuers' ability to provide coverage or service to patients and that not certifying the issuers QHP or QHPs would result in patients having few or no plan options in certain areas. This approach is consistent with the exceptions process finalized for the Patient Access API in the CMS Interoperability and Patient Access final rule. Were we to apply the proposed standards to such issuers, we believe it could result in those issuers no longer participating in the FFEs, which would not be in the best interest of enrollees. We note that, in this proposed 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 would not be subject to the requirements in this proposed 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 proposed rule, we use terms such as “patient,” “consumer,” “beneficiary,” “enrollee,” and “individual.” Every reader of this proposed rule is a patient and has received, or will receive, medical care at some point in their life. In this proposed 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 proposals herein, we will use additional, specific terms applicable to individuals covered under the healthcare 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 consent to certain types of information exchange under our proposals. But when we refer to a patient's medical needs or health records, we are not including the medical needs or health records of the patient's personal representative. Per the Privacy, Security, and Breach Notification Rules (HIPAA Rules) issued under the Health Insurance Portability and Accountability Act of 1996 (HIPAA) (Pub. L. 104-191, enacted on August 21, 1996), as modified, at 45 CFR 164.502(g), and related guidance thereof, a personal representative, generally and for purposes of access to protected health information (PHI), defined at 45 CFR 160.103, is someone authorized under state or other applicable law to act on behalf of an individual in making healthcare-related decisions (such as a parent, guardian, or person with a medical power of attorney). As permitted by the HIPAA Rules, a patient's personal representative could act on a patient's behalf using the processes within this proposed rule.

We also use terms such as “payer,” “plan,” and “issuer” in this proposed rule. Certain portions of this proposed 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 proposed provisions may not be applicable 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 proposed rule as an inclusive term for all these programs and, in the case of plans, plan types, but we also use specific terms as applicable in various sections of this proposed rule. We are proposing at 42 CFR 457.700(c) that states that have a Medicaid expansion CHIP (a program under which a state receives Federal funding to expand Medicaid eligibility to optional targeted low-income children that meets the requirements of section 2103 of the Social Security Act), the proposals in this rule for Medicaid would apply to those programs rather than our proposals for a separate CHIP. Functionally, our proposals are the same; however, for clarity, we are making explicit that the Medicaid requirements at §§ 431.60, 431.61, and 431.80 would apply to those programs rather than the separate CHIP requirements at §§ 457.730, 457.731, and 457.732.

We use the term “items and services” when discussing prior authorization in this proposed rule, and note that, unless otherwise stated, the proposals 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 proposed rule (for example, this would include outpatient drugs, drugs that may be prescribed, those that may be administered by a physician, or that may be administered in a pharmacy or hospital), because the processes and standards for prior authorization applicable to drugs differ from the other “items and services” for which we propose regulation. In the CMS Interoperability and Patient Access final rule, we finalized policies that would require payers to send claims data related to prescription and other drug claims via an API, and we make several proposals related to claims data in this proposed 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 longitudinal record and giving patients, providers, and payers access to claims data for prescription and other drugs can offer valuable insights into a patient's healthcare, 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 for drugs for the impacted payers in this proposed rule. Thus, while the claims data included in our proposed and previously finalized policies did include prescription and other drug claims, our proposals related to prior authorization in this proposed rule 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.

Additionally, we use the terms “provider” and “supplier” as inclusive terms composed of individuals, organizations, and institutions that provide health services, such as clinicians (that is, physicians and other practitioners), hospitals, skilled nursing facilities, 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 proposed rule we make several API-related proposals in which we refer to the functionality as a singular API, or API gateway, though we acknowledge that this functionality may be made up of one or multiple APIs. For example, while we refer to the Patient Access API (discussed in section II.A. of this proposed rule) as a single API for the purpose of describing the functionality, the same functionality may be achieved with one or multiple APIs, depending on the implementation approach chosen by the applicable payer.

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 associated with applications, which are familiar in other aspects of patients' daily lives, such as travel and personal finance. Standardized, secure, transparent, and pro-competitive API technology can enable similar benefits for patients of healthcare services.

Health Level 7 (HL7®) is the standards development organization which develops the Fast Healthcare for Interoperability Resources (FHIR®) standard and IGs referenced throughout this proposed 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, we note that throughout this proposed rule we discuss the APIs in relation to the proposed programmatic requirements to share data between payers, between payers and providers, and between payers and patients under specific rules. However, these APIs could be used for a multitude of transactions, aside from those currently described by section 1173(a)(1) of the Social Security Act, beyond those proposed in this rule. For instance, a patient could request data outside the scope of this proposed rule, or program integrity entities could request data from payers or providers (such as under the Inspector General Act of 1978). Nothing in this proposed rule would prevent the requested data from being shared via the APIs discussed in this proposed rule, if technologically feasible, for appropriate purposes. In fact, we encourage the use of these standards-based APIs for purposes beyond the proposed requirements to improve the interoperability of health data regardless of the use case.

B. Summary of Major Proposals

To drive interoperability, improve care coordination, reduce burden on providers and payers, and empower patients, we are proposing several requirements for MA organizations, state Medicaid FFS programs, state CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs, as well as MIPS eligible clinicians participating in the MIPS Promoting Interoperability performance category, and eligible hospitals and CAHs in the Medicare Promoting Interoperability Program. We are also including RFIs to gather information that may support future rulemaking or other initiatives.

Executive Order (E.O.) 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 we believe the proposals in this rule are aligned with this E.O. because they represent efforts to mitigate existing inefficiencies in policies, processes, and technology which affect many patient populations. Some patient populations are more negatively affected by existing processes than others and thus might realize greater benefits through the improvements we propose. One of the main components of this proposed rule is 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. We are soliciting comments from the public, particularly individuals who have knowledge about how underserved populations use healthcare apps and technology, such as researchers, policy advocates, social service agency staff, providers who serve underserved populations, and others who may be able to provide insight about accessibility, readability, and other relevant factors for consideration. 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 through the use of secure technologies, such as OAuth 2.0 and OpenID Connect for authentication, and as further discussed in the CMS Interoperability and Patient Access final rule (85 FR 25516). While we have proposed policies that we believe would address some healthcare inequities, we are soliciting comment about how to help ensure that individuals from all communities and populations can actively benefit from our healthcare interoperability proposals.

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 applications of their choice, to easily access their claims and encounter information as well as clinical data, including laboratory results, and provider remittances and enrollee cost-sharing pertaining to such claims, if maintained by the impacted payer, (85 FR 25558). In this proposed rule, we are proposing to require that 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) include information about prior authorizations in the data that are available through the Patient Access API. In addition, we are proposing to require these impacted payers to annually report to CMS certain metrics about patient data requests via the Patient Access API.

To improve coordination across the care continuum and movement toward value-based care, we are proposing to require that impacted payers implement and maintain a Provider Access API that, consistent with the technical standards finalized in the CMS Interoperability and Patient Access final rule (85 FR 25558), utilizes HL7 FHIR version 4.0.1. That API can be used to exchange current patient data from payers to providers, including all data classes and data elements included in a standard adopted at 45 CFR 170.213 (currently USCDI version 1), adjudicated claims and encounter data (not including provider remittances and enrollee cost-sharing information), and the patient's prior authorization decisions.

In the CMS Interoperability and Patient Access final rule, CMS required certain payers (MA organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs) to exchange a patient's health data with other payers at the patient's request, beginning on January 1, 2022, or plan years beginning on or after January 1, 2022, as applicable (85 FR 25568). We also required those payers to incorporate the data they receive through this payer to payer data exchange into patient records, with the goal of creating longitudinal records that would follow patients as they move from payer to payer throughout their healthcare journey. However, we did not require a standards-based API for the payer to payer data exchange.

Since the rule was finalized in May 2020, multiple impacted payers reported to CMS that the lack of technical specifications for the payer to payer data exchange requirement in the CMS Interoperability and Patient Access final rule was creating challenges for implementation, which, they stated, could lead to incompatible implementations across the industry, poor data quality, operational challenges, and increased administrative burdens. They were concerned that different implementation approaches could create gaps in patient health information, which would directly conflict with the intended goal of interoperable payer to payer data exchange.

After considering stakeholder concerns about implementing the payer to payer data exchange requirement finalized in the CMS Interoperability and Patient Access final rule, we announced in a December 10, 2021 Federal Register notification (86 FR 70412) that we would not enforce the payer to payer data exchange requirements until further rules are finalized. In this proposed rule, we are proposing to rescind our previous payer to payer data exchange requirements and replace them with a new policy. The CMS Interoperability and Patient Access final rule also did not apply the payer to payer data exchange requirements to Medicaid and CHIP FFS programs. We are now proposing to apply our newly proposed Payer-to-Payer API requirements to Medicaid and CHIP FFS programs, in addition to other impacted payers as discussed further in section II.C.4.a. The new proposed policy would require impacted payers to build a Payer-to-Payer API to facilitate the exchange of patient information between payers, both at a patient's request and at the start of coverage with a new payer. Specifically, that data exchange would include all data classes and data elements included in a standard adopted at 45 CFR 170.213 (currently USCDI version 1), adjudicated claims and encounter data (not including provider remittances and enrollee cost-sharing information), and the patient's prior authorization decisions.

To improve the patient experience and access to care, we are also proposing several new requirements for prior authorization processes that we believe would ultimately reduce burden on patients, providers, and payers. To streamline the prior authorization process, we are proposing to require all impacted payers to implement and maintain a FHIR Prior Authorization Requirements, Documentation, and Decision API (PARDD API). The API would streamline the prior authorization process by automating the process to determine whether a prior authorization is required for an item or service, thereby eliminating one of the major pain points of the existing prior authorization process. The API would then be able to query the payer's prior authorization documentation requirements and make those requirements available within the provider's workflow as well as support the automated compilation of certain information from the provider's system. Finally, the API would support an automated approach to compiling the necessary data elements to populate the HIPAA-compliant prior authorization transactions and enable payers to compile specific responses regarding the status of the prior authorization, including information about the reason for a denial. For the exchange of the prior authorization transaction, covered entities would continue to use the HIPAA-mandated transaction standards. Use of the FHIR API integrates identification of prior authorization and documentation requirements as well as information about prior authorization requests and decisions into a provider's workflow while maintaining compliance with the adopted HIPAA standard.

We are proposing to require that impacted payers send information to providers regarding the specific reason for denial when a prior authorization request is denied, regardless of the mechanism used to submit the prior authorization request. We are proposing to require impacted payers, except for QHP issuers on the FFEs, to respond to prior authorization requests within certain timeframes. In addition, we are proposing to require impacted payers to publicly report certain metrics about their prior authorization processes for transparency.

We are proposing a new measure for electronic prior authorization for MIPS eligible clinicians under the Promoting Interoperability performance category of MIPS and for eligible hospitals and CAHs under the Medicare Promoting Interoperability Program. To promote PARDD API adoption, implementation, and use among MIPS eligible clinicians, eligible hospitals, and CAHs, we are proposing to add a new measure 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 performance period/EHR reporting period in calendar year (CY) 2026. For this measure, we are proposing that a MIPS eligible clinician, eligible hospital, or CAH must report a numerator and denominator or (if applicable) an exclusion.

Although these proposals do not directly pertain to Medicare FFS, we want to ensure that people with Medicare can benefit from the policies we are proposing, 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, seek comment throughout on how these proposals could apply to Medicare FFS. Similarly, we encourage other payers not directly impacted by this proposed rule to evaluate our proposals for voluntary adoption to reduce burden and support greater interoperability. Further information about CMS initiatives to achieve the desired level of data exchange with patients, providers and other payers can be found in those sections in this proposed rule.

We are also including five RFIs to gather information that may support future rulemaking or other initiatives. Specifically, we request information on barriers to adopting standards, and opportunities to accelerate the adoption of standards, for social risk data. We recognize that social risk factors (for example, housing instability and food insecurity) influence patient health and healthcare utilization. In addition, we understand that providers in value-based payment arrangements rely on comprehensive, high-quality social risk data. Given the importance of these data, we want to understand how we can better standardize and promote the exchange of these data in accordance with the law.

Additionally, we are seeking comment on how CMS could leverage APIs (or other technology) to facilitate electronic data exchange between and with behavioral healthcare providers, which generally have lower rates of EHR adoption than other provider types.

Furthermore, in the Medicare FFS program, the ordering provider can be different than the rendering provider of items or services, which creates unique obstacles to the coordination of patient care and exchange of medical information needed to ensure an accurate and timely payment. We are interested in public comments regarding how Medicare FFS could support improved medical documentation exchange between and among providers, suppliers, and patients as we believe it could enable better care for beneficiaries if covered services are not delayed by inefficiencies.

We also seek comment on how using data standards and electronic health records can improve maternal health outcomes. Additionally, we include questions related to how prior authorization can be improved and what special considerations should be given to support data sharing in maternal health care.

Finally, we seek comment on how to encourage providers and payers to enable exchange under TEFCA to make patient information more readily available for access and exchange in a variety of circumstances. We wish to understand how CMS can support enabling exchange under TEFCA and what concerns commenters have about potential requirements related to enabling exchange under TEFCA.

II. Provisions of the Proposed Rule

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 subset 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 healthcare experience. In the CMS Interoperability and Patient Access final rule (85 FR 25523), we gave examples of how claims data can be used to benefit patients and providers. For example, inconsistent benefit utilization patterns in an individual's claims data, such as a failure to fill a prescription or receive recommended therapies, can indicate to a provider or payer that the individual has had difficulty financing a treatment regimen and may require less expensive prescription drugs or therapies, additional explanation about the severity of their condition, or other types of assistance.

Patients tend to receive care from multiple providers, leading to fragmented patient health records where various pieces of an individual's longitudinal 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.

As stated in section I.A. of this proposed rule, we are withdrawing the December 2020 CMS Interoperability proposed rule and issuing this new proposed rule that incorporates feedback we received from stakeholders. We understand that many readers may be familiar with that proposed rule, and, in an effort to distinguish the differences between that proposed rule and our proposals herein, we refer readers to section I.A. of this proposed rule outlining the overarching differences between them. In this proposed rule, we are again proposing to require impacted payers to report Patient Access API metrics to CMS. However, we have changed the proposal to require reporting annually, as opposed to quarterly. In addition, we are no longer proposing that impacted payers maintain a process for requesting an attestation from health app developers when the developers register their app with the payer's Patient Access API. Instead, we are seeking comment on a variety of privacy considerations. Finally, we propose to extend the compliance date for our proposed policies to January 1, 2026.

As mentioned in section I.A. of this proposed rule, the proposals in this rule do not directly pertain to Medicare FFS. However, if our proposals are finalized, we plan to implement these provisions for Medicare FFS so that people with Medicare FFS could also benefit from their data availability. Through Blue Button 2.0, CMS makes Parts A, B, and D claims data available electronically via an API to people with Medicare FFS and those enrolled in Part D. To align with the API provisions included in the CMS Interoperability and Patient Access final rule, we have updated the Blue Button 2.0 API to FHIR Release 4, and begun using the CARIN Consumer Directed Payer Data Exchange IG for Blue Button 2.0. If we finalize our proposals, we plan to further align and enhance Blue Button 2.0 accordingly, as feasible. We seek comment on any considerations for applying these requirements to apply to Medicare FFS, if we finalize these proposals.

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, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs, to implement and maintain APIs that permit enrollees to use health apps to access data specified at 42 CFR 422.119, 431.60, 457.730, 438.242(b)(5), and 457.1233(d) and 45 CFR 156.221, respectively. The Patient Access API must make available, at a minimum, adjudicated claims (including provider remittances and enrollee 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. We finalized a policy that 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.

a. Prior Authorization Information

To enhance our policy by improving the usefulness of the information available to patients, we are proposing to add information about prior authorizations to the categories of data required to be made available to patients through the Patient Access API. In this section, 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.” This proposal would apply to all prior authorization requests and decisions for items and services (excluding drugs) for which the payer has data, whether the decision is still pending, active, denied, expired, or is in another status, as discussed further in this section. The primary goal of the Patient Access API is to give patients access to their health information. By expanding patient access to prior authorization information, we intend to help patients be more informed decision makers and true partners in their healthcare.

As discussed in section I.A. of this proposed rule, our proposals for prior authorization APIs and processes do 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, or drugs that may be administered in a pharmacy or hospital. In section II.D. of this proposed rule, we propose several provisions focused on making the prior authorization process less burdensome for providers and payers, which we anticipate would reduce care delays and improve patient outcomes. We believe that giving patients access to information about prior authorization requests and decisions would enable patients to take a more active role in their own healthcare. As a result, we are proposing to require impacted payers to provide patients with access to information about the prior authorization requests made for their care through the Patient Access API.

We propose to require that via the Patient Access API, impacted payers make information about prior authorization requests and decisions (and related administrative and clinical documentation) for items and services (excluding drugs) available to patients no later than 1 business day after the payer receives the prior authorization request or there is another type of status change for the prior authorization. Examples of status changes include: a payer approves or denies a pending prior authorization request, a provider or patient updates a denied prior authorization request with additional information for reconsideration, or the count of the items or services used under the prior authorization decision is updated. 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 would require an update to the information available to the patient. For the requirement to include prior authorization information in the data available via the Patient Access API, we propose a January 1, 2026 compliance date (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).

The required information available through the API would include the prior authorization status, the date the prior authorization was approved or denied, the date or circumstance under which the authorization ends, the items and services approved, and the quantity used to date under the authorization. The documentation required to be shared includes 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. In section II.D.4.a. of this proposed rule, we propose that in the case of a prior authorization denial, the payer must provide a specific reason for the denial. We propose that impacted payers would have to make that specific reason for denying a prior authorization request available to the patient via the Patient Access API as well. This information can help patients understand both why a payer denied a prior authorization request and/or what items and services were authorized for the patient's recent care.

As further discussed in sections II.B. and II.C. of this proposed rule, we are proposing to require impacted payers to share the same information about prior authorization requests and decisions with a patient's provider via the Provider Access API and via the Payer-to-Payer API. In this way, these prior authorization data can potentially be available to all relevant parties. We note that the requirement to share information about prior authorization via the API is in addition to any notice requirement that applies to prior authorization requests and decisions, such as the proposals to require notice of a decision within certain timeframes discussed in section II.D.5.b. of this proposed rule.

We believe that 1 business day is appropriate, as 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 proposed rule, we are proposing to require payers to make much of the same information about prior authorization requests and decisions available via the PARDD API during the decision-making process. In addition, because impacted payers would be required to exchange prior authorization information electronically, we believe it would be reasonable for them to share prior authorization information and documentation with patients within 1 business day of any update to the prior authorization request or decision.

We are also proposing to require that information about prior authorizations (and related administrative and clinical documentation) 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 we are formulating our proposal for at least 1 year after any status change, but 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 do not propose to require that payers 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/or clinical data can provide important 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 would be redundant. Also, as prior authorization rules may change over time, we believe that this 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 be related to ongoing care.

We anticipate that requiring payers to make prior authorization information accessible through the Patient Access API would help patients better understand the lifecycle of a prior authorization request, the items and services that require prior authorization, the information being considered, and specific clinical criteria their payer uses to make a determination. We believe that more transparency would better equip patients to engage with their payer(s) and/or provider(s). For example, by having access to certain prior authorization information via the Patient Access API, a patient could see that prior authorization is needed and has been submitted for a particular item or service, which could help them better understand the timeline for the process and plan accordingly. Supporting documentation could give patients better visibility into what the payer is evaluating so they could help providers get the best and most accurate information to payers to facilitate a successful request, thus potentially avoiding unnecessary care delays and reducing burden on providers and payers. The proposed requirement could also reduce the need for patients to make repeated calls to their providers and payers to understand the status of requests, or to inquire why there are delays in care.

We believe that this proposal would enable patients to participate in their care more and reduce burden on both providers and payers to allow them to more efficiently navigate the prior authorization process. The proposal may also add an additional layer of accountability for payers to make timely prior authorization decisions, as patients would be able to follow the prior authorization process from initiation to conclusion. As with all information made available via the Patient Access API, we believe industry is in the best position to develop apps for patients to effectively use this information, and to make sure that the apps are accessible to people with disabilities. We look to industry innovators to produce apps that will help patients understand their health information and access it in a manner that is useful to them.

In summary, we propose 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 would be required to make information available to patients via the Patient Access API about prior authorization requests and decisions (and related administrative and clinical documentations), including, as applicable, the status of the prior authorization; the date the prior authorization was approved or denied; the date or circumstance under which the authorization ends; the items and services approved; the quantity used to date; and, if the prior authorization was denied, a specific reason why the request was denied, no later than 1 business day after the payer receives a prior authorization request for items and services (excluding drugs) or there is another type of status change for the prior authorization. We are also proposing 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 make prior authorization information (and related administrative and clinical documentation), available to patients via the Patient Access API for the duration it is active and at least 1 year after the last status change. These proposals would apply to MA organizations, state Medicaid FFS and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs at the CFR sections identified in Table 1.

The requirements for a Patient Access API imposed on Medicaid managed care plans and CHIP managed care entities are set forth at 42 CFR 438.242(b)(5) and 457.1233(d), respectively. Through an amendment to paragraph (b)(5) and by adding a new paragraph (b)(8) at 42 CFR 438.242, we are proposing to require Medicaid managed care plans (and through § 457.1233(d), CHIP managed care entities) to include information about prior authorization requests and decisions and related administrative and clinical documentation in the data available via to the Patient Access API by the rating period beginning on or after January 1, 2026. We request comment on this proposal.

We request comment on how we could or should apply these requirements to Medicare FFS and its existing prior authorization requirements and standards.

As stated earlier in this preamble, the proposals in this proposed rule do not apply to any drugs. However, we also request comments on whether we should consider policies to require impacted payers to include information about prior authorizations for drugs, when the payer covers drugs, via the Patient Access API, the Provider Access API, and the Payer-to-Payer API. We request comments on how future rulemaking to make information about prior authorizations for drugs available through these APIs might interact with existing prior authorization requirements and standards.

b. Interaction With HIPAA Right of Access Provisions

Previous proposals have elicited numerous comments regarding the interaction between the Patient Access API and HIPAA Privacy Rule requirements for individual access. Per 45 CFR 164.524, an individual patient generally has a right of access to inspect and obtain a copy of protected health information (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 proposals would complement that right by requiring payers to make the PHI that patients already have a right to access available through a standards-based and interoperable Patient Access API. It is critical that individuals have access to their information and the ability to share it with others who are involved in their care, particularly when it could involve care coordination between providers and prior authorization for certain items and services.

When an individual requests an electronic copy of PHI that a covered entity maintains electronically (ePHI), per 45 CFR 164.524(c)(2)(ii), the covered entity must provide the individual with access to the information in the requested electronic form and format, if it is readily producible in that form and format. When the ePHI is not readily producible in the electronic form and format requested, then the covered entity must provide access to an agreed upon alternative readable electronic format. As health apps become more common, we believe that it behooves us to require that all impacted payers be able to provide individuals' ePHI via an industry standard FHIR API, as demonstrated by both our current requirements and our proposals in this section. We believe that, in addition to the other benefits described in this proposed rule, ensuring that patients can receive their ePHI in a standard, interoperable format that they can use with the latest technologies would reduce instances of an individual requesting ePHI in an electronic format that is not readily producible.

Individuals have the right under the HIPAA Privacy Rule to request access to PHI in the form and format requested by the individual, if it is readily producible in the manner requested. For example, the covered entity must transfer or transmit the PHI to the individual even where the requested mode of transfer or transmission is unsecure as long as the PHI is “readily producible” in such manner, the covered entity is capable of transmitting the PHI in the manner the individual requests, and the manner of transmission would not present an unacceptable level of security risk to the PHI on the covered entity's systems. In the CMS Interoperability and Patient Access final rule, we specifically cited this security risk exception as the only reason payers could deny API access to a health app that a patient wishes to use. 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 through which patients seek to access their electronic health information. See 42 CFR 422.119(e) for MA organizations; 42 CFR 431.60(e) for state Medicaid FFS programs, through the existing cross reference at 42 CFR 438.242(b)(5) for Medicaid managed care plans; 42 CFR 457.730(e) for state CHIP FFS programs, through the existing cross reference at 42 CFR 457.1233(d) for CHIP managed care entities; and 45 CFR 156.221(e) for QHP issuers on the FFEs.

Disagreement with the individual about the worthiness of a health app as a recipient of PHI, or even concerns about what the app might do with the requested PHI, would not be acceptable reasons to deny an individual's request. Therefore, as we also noted in the CMS Interoperability and Patient Access final rule, covered entities and business associates would be free to offer advice to patients on the potential risks involved with requesting data transfers to an app or entity not covered by HIPAA, but such efforts generally must stop at education and awareness or advice related to a specific app. For instance, if a payer noted that the app a patient was using to access their data did not explain in its privacy policy specifically how the patient's personal data would be used or sold (a possibility for apps not covered by HIPAA), the payer could choose to inform the patient that they may not want to share their data with that app without a clear understanding of how the app may use the data, including details about the app's secondary data use policy. If the patient still wants their data to be shared, or does not respond to the payer's warning, the payer would need 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. The requirements we are proposing do not affect or alter any obligations under the HIPAA Privacy and Security Rules.

We discussed privacy and safety concerns in the context of APIs in the CMS Interoperability and Patient Access final rule (85 FR 25516). We note that while the FHIR standard 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 for secure data exchange. Furthermore, the 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 proposals in this section address how a 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 PHI. As discussed, per the CMS Interoperability and Patient Access final rule, impacted payers may only deny or discontinue an app's connection to their APIs if an impacted payer makes a determination using objective, verifiable criteria that the specific health app would present a danger to the impacted payer's own systems, such as increasing the risk of cyber-attack.

Regardless of whether HIPAA applies to a health app, other Federal laws may apply, even where HIPAA does not apply, such as the Federal Trade Commission (FTC) Act. 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, which covers most health apps and similar technologies that are not covered by HIPAA, and therefore, not subject to the HIPAA Breach Notification Rule. The FTC's Health Breach Notification Rule sets forth steps 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 subject to civil penalties of up to $46,517 per violation per day.

c. Privacy Policy

As we discussed earlier in this proposed rule and in detail throughout the CMS Interoperability and Patient Access final rule (85 FR 25550), one of the most important aspects of making health data accessible to patients is to protect the privacy and security of patient health information, especially because once a patient's data are received by a health app, their data may no longer be protected by the HIPAA Rules. Also as discussed earlier, we do not have the authority to directly regulate health apps. Yet, we take the privacy and security of PHI seriously and understand that patients may not know the implications of giving a health app access to their health information. We are continually working to find ways to further protect patient data.

In the CMS Interoperability and Patient Access final rule, we required that impacted payers make educational resources available to their current and former patients with information to help protect the privacy and security of their health information. That includes factors to consider in selecting an app, including potential secondary uses of data, and the importance of understanding the security and privacy practices of any app to which they will entrust their health information. Furthermore, impacted payers must provide an overview of which types of organizations or individuals are and are not likely to be HIPAA-covered entities, and the oversight responsibilities of the Office for Civil Rights (OCR) and the FTC, and how to submit a complaint to those entities. See 42 CFR 422.119(g) for MA organizations, 42 CFR 431.60(f) for Medicaid FFS programs, through existing cross-reference at 42 CFR 438.242(b)(5) for Medicaid managed care plans, 42 CFR 457.730(f) for CHIP FFS programs, through existing cross reference at 42 CFR 457.1233(d) for CHIP managed care entities, and at 45 CFR 156.221(g) for QHP issuers on the FFEs. We continue to believe these resources are important to provide to patients, but seek comments on how we can improve this policy so patients can make educated decisions about sharing their personal health information.

In the 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program final rule (21st Century Cures Act final rule) (85 FR 25642, 25814 through 25815), ONC noted that providing information that is factually accurate, objective, unbiased, not unfair or deceptive, and provided in a non-discriminatory manner to inform a patient about the advantages, disadvantages and any risks of sharing their health information with a health app, would be unlikely to interfere (as defined in that rule) with the access, exchange, or use of electronic health information (EHI) for purposes of the information blocking regulations at 45 CFR part 171.

In response to comments on the CMS Interoperability and Patient Access proposed rule (84 FR 7610), we noted in the final rule (85 FR 25549-25550) commenters' observations that many patients were unlikely to understand the potential risk of disclosure when their data are transmitted to a health app and are thus no longer protected by the HIPAA Rules. Commenters were specifically concerned about secondary uses of data, such as whether developers would sell their data to third parties for marketing or other purposes. In the CMS Interoperability and Patient Access final rule (85 FR 25549), we noted that a clear, plain language privacy policy is the best vehicle to inform patients about how their information will be protected and how it will be used once shared with the health app.

In the December 2020 CMS Interoperability proposed rule (85 FR 82592 through 82594), we proposed to require impacted payers to request a privacy policy attestation from health app developers when their app requests to connect to the payer's Patient Access API. We proposed that the attestation would include, at a minimum, statements that the app has a plain language privacy policy that is always publicly available and accessible, and has been affirmatively shared with the patient prior to the patient authorizing the app to access their health information. In addition, the attestation we proposed included yes/no elements as to whether the privacy policy specifically communicates how the patient's health information could be accessed, exchanged, or used.

While we still believe that certain aspects of our previously proposed attestation policy could support enhanced patient education about health apps' privacy policies, based on public comments and feedback, we are concerned that this type of attestation would not serve to benefit patients in ways that would outweigh the burden on impacted payers. We are also concerned that such a policy could have unintended consequences for patients. Under the proposal in the December 2020 CMS Interoperability proposed rule, a health app developer would only be attesting to the format and inclusion of certain information. There would be no attestation that the substance of the privacy policy meets specific minimum requirements or best practices. We believe that having payers inform patients that an app developer has attested to the form and format of a privacy policy could easily be misinterpreted as assurance that the substance of the privacy policy has been reviewed and found acceptable by the payer (or CMS). We believe this is especially true in the case of patients with low health or technology literacy, who are least likely to be able to find and interpret an app's privacy policy to make well-informed decisions about their health data. We are concerned that requiring such an attestation would only give the appearance of privacy and security for patients' health data, without providing additional benefit.

Because CMS does not have the statutory authority to regulate health apps, we cannot require developers to respond to that attestation. Furthermore, as discussed, even if a health app developer does not respond to the attestation (or responds in the negative), a payer would be required to allow that app to connect (unless it would create a security risk to the payer's own system) and provide a patient's health information through the app selected by the patient.

Commenters also responded that the proposed process would put an undue burden on payers to manage an attestation process for app developers with whom they may have no legal or contractual relationship. Furthermore, commenters expressed concerns about payers' lack of adherence mechanisms and payer liability due to the HIPAA right of access requirements discussed previously.

We still believe it is important for patients to have a clear understanding of how their health information may be used by a person or entity not covered by the HIPAA Rules, such as a health app, whether their data would be sold or marketed, and how to stop sharing their health information with such entities if they so choose. In particular, explaining certain privacy and security practices in a patient-friendly, easy-to-read privacy policy would help patients understand those elements and how they can be an active participant in the protection of their information. We also encourage app developers to follow industry best practices, including the CARIN Alliance's Code of Conduct and the ONC Model Privacy Notice (MPN). We note that the developer attestation discussed in the December 2020 CMS Interoperability proposed rule (85 FR 82593) included some of the elements of the 2018 ONC MPN, such as explaining how a patient's health information may be accessed, exchanged, or used by any person or other entity, including whether the patient's health information may be shared or sold at any time. As discussed, if an app has a written privacy policy and the app or developer operates contrary to that policy, the FTC has authority to act.

We request comments on how we can help give patients the tools they need to understand the privacy and security implications of using a health app within the scope of our regulatory authority. We seek ideas on how we can balance our desire to both educate patients and respect their rights under the HIPAA Privacy Rule. For example, should there be a process at the time a developer registers an app with a payer for access to the API to submit information about its privacy policy? Should payers be required to provide that information in an easy-to-understand format the first time a patient requests access via an app? We encourage comments about how we can leverage the MPN (most recent version from 2018). While we cannot require health app developers to utilize the MPN, should payers notify patients, the first time the patients request data through an app, whether the app utilizes the MPN or not? To encourage visibility for apps that use the MPN versus those that do not, should payers be required to list apps that have established access to their API on their websites that comply with the MPN's transparency requirements? We note that payers would have to treat apps identically based on the substance of their privacy policies and could not favor certain apps over others, such as for competitive advantage. Again, we (and payers) cannot prohibit patients from using health apps that do not comply with best privacy and security practices unless it presents an unacceptable security risk to the payer's systems.

We also request comment on whether we can leverage and build on other HHS health information exchange initiatives, such as TEFCA, to address these issues. For more background on TEFCA, see the related Request for Information in section III.E. of this proposed rule. The Common Agreement and Framework Agreement include privacy and security requirements for Qualified Health Information Networks (QHINs), Participants, and Subparticipants that elect to exchange information pursuant to it, including entities not covered by the HIPAA Rules. Within the Common Agreement, any QHIN, Participant, or Subparticipant that offers Individual Access Services (IAS) by which an individual can access, inspect, or obtain a copy of that individual's information is an IAS Provider. If a health app developer becomes a signatory to a Framework Agreement and offers IAS Services, that developer would be an IAS Provider. That developer would be providing services utilizing the TEFCA Connectivity Services to an Individual with whom the QHIN, Participant, or Subparticipant has a Direct Relationship to satisfy that Individual's ability to access, inspect, or obtain a copy of that Individual's Required Information that is then maintained by or for any QHIN, Participant, or Subparticipant.

IAS Providers must, among other requirements, have a written privacy and security notice; obtain express written consent from individuals regarding the way their information will be accessed, exchanged, used (as defined in the Common Agreement), or disclosed (as defined in the Common Agreement), including the sale of their health information; provide individuals with the right to delete their individually identifiable information as well as the right to revoke their consent, with certain exceptions, in addition to a disclosure of any applicable fees or costs related to IAS; and provide individuals with the right to obtain an export of their individually identifiable information in a computable format. Additionally, IAS Providers are required to protect all individually identifiable information (including health information) they hold in accordance with security requirements specified in the Common Agreement and applicable Standard Operating Procedures, such as the draft IAS Provider Privacy and Security Notice and Practices Standard Operating Procedure (SOP) and the IAS Exchange Purpose Implementation SOP.

Given the Common Agreement's privacy and security requirements, and particularly those that will apply when patients access their health information through a participating IAS Provider, we request comment on whether CMS should explore requirements or ways to encourage exchange under TEFCA as a way to ensure that more patients are informed about the privacy and security implications of using health apps to access their health information, consistent with the requirements for IAS Providers described previously. For instance, how could CMS encourage health apps that are not subject to the HIPAA Rules to connect to entities that exchange information under TEFCA? If so, what should be the contours of, and levers for, such encouragement? What other approaches can CMS take to encourage app developers to enable exchange under TEFCA and therefore leverage the Common Agreement's privacy and security requirements?

In addition, we request comments on 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 an appropriate literacy level and in plain language. We note that the draft IAS Provider Privacy and Security Notice and Practices SOP includes guidance regarding plain language and literacy requirements. We believe apps with these features are important to ensure that all patients can benefit from the proposals in this rule. We request comment on any actions that we can take to ensure patients' equitable access to their health information.

d. Patient Access API Metrics

We are proposing to require impacted payers to report metrics in the form of aggregated, de-identified data to CMS on an annual basis about how patients use the Patient Access API. This reporting 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. Aggregated usage data from every impacted payer would help us evaluate whether the Patient Access API policies are achieving the desired goals. Gathering this information would also 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. We propose to require MA organizations to report these data to CMS at the organization level, state Medicaid and CHIP FFS programs to report at the state level, Medicaid managed care plans to report at the state level, CHIP managed care entities to report at the state level, and QHP issuers on the FFEs to report at the issuer level. We are considering, and therefore seek 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 seek comment on the benefits or drawbacks of an alternative final policy that would permit MA organizations, entities offering Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to report aggregate data for the same plan type at higher levels (such as the parent organization level or all plans of the same type in a program). We note that in the December 2020 CMS Interoperability proposed rule (85 FR 82594), we proposed that these data be reported quarterly, and received comments from a broad variety of stakeholders strongly in favor of annual reporting. Based on that feedback, we are now proposing annual reporting.

Specifically, we propose that these 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 are allowing apps to update their information over the course of the year. While we are not certain whether such data transfers would indicate to what extent patients are using the apps to manage their healthcare, it would be a preliminary indicator of interest in the technology to access their data.

We are proposing that payers must report data from the previous calendar year to CMS by March 31 of each year. The first year the requirement would be applicable, payers would report calendar year 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.

In summary, we propose that beginning in 2026, MA organizations at the organization level, state Medicaid and CHIP FFS programs at the state level, Medicaid managed care plans at the state level, CHIP managed care entities at the state level, and QHP issuers on the FFEs at the issuer level must annually report the following metrics to CMS in the form of aggregated, de-identified data: (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. Collecting this information would facilitate CMS' oversight and evaluation of the MA, Medicaid, and CHIP programs and of QHP issuers on the FFEs. We propose that impacted payers report the previous calendar year's metrics, in the form of aggregated, de-identified data, to CMS by March 31 of each year. MA organizations, Medicaid managed care plans, and CHIP managed care entities would report metrics to CMS following any year that they operated, and QHP issuers would report metrics to CMS following any year that they offered a QHP on the FFEs. We are making this proposal at the CFR sections identified in Table 1.

If we finalize this proposal, 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 does not include names of specific state agencies, plans, or issuers. We solicit comment on this aspect of our proposal.

In addition, we request comment on what other Patient Access API metrics we should consider requiring payers to report to CMS and/or make available to the public on their own websites, for consideration in possible future rulemaking. For instance, we are seeking comments on whether payers could report aggregated demographic information, such as sex, race, age, ethnicity, and geographical (for instance, by zip code) data that they may already have to help identify disparities in patient access to health data or underserved populations and, if so, what policies should be considered to minimize those disparities. We are also seeking comment on the potential benefits and burden of requiring payers to report the names of all apps that patients have used to access the payers' API each year. We are considering either collecting this information, or requiring payers to make it public, not to recommend or endorse specific apps, but to maintain a view of the apps that patients use to access their health information, which could help us review for best practices and to evaluate patient ease of use.

e. Patient Access API Amendments

To accommodate the proposed requirements regarding the use of the Patient Access API, we are proposing two minor terminology changes to the requirements finalized in the CMS Interoperability and Patient Access final rule (85 FR 25558, 25547). We note that unlike most of our proposals, we are proposing that these amendments would go into effect on the effective date of the final rule. We are proposing these changes to clarify terms, but do not expect them to substantively change any current regulatory obligation.

First, we are proposing to revise the description of the clinical data to be made available via the Patient Access API by 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 identified in Table 1. These provisions currently require payers to make available “clinical data, including laboratory results.” We are proposing 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.” The standard currently referenced at 45 CFR 170.213 is the USCDI version 1. Laboratory Values/Results is a USCDI version 1 data element, and USCDI version 1 includes data classes for other aspects of clinical information such as Immunizations, Procedures, and Assessment and Plan of Treatment. Referring explicitly to the data set in a standard at 45 CFR 170.213 in the rule text would help avoid unnecessary confusion, as this reference would more clearly identify exactly what data must be available through the Patient Access API.

In the future, as versions of the USCDI evolve, there may be multiple versions of the standard referenced at 45 CFR 170.213 at one time. For the ONC Health IT Certification Program, this allows for a transition period between standards as health IT developers incorporate updated standards versions within their systems and complete required certification. Through this proposal, we are seeking to ensure that the same flexibility would apply for payers as they transition between the versions of the USCDI. 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-available standards at 45 CFR 170.213 for the data classes and elements that they make available through the API.

Second, we are proposing to revise the language previously finalized for denial or discontinuation of a health app's access to the API. Currently, the rules require that the payer 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 EHI. We are proposing to change the terms “enrollees” and “beneficiaries” to “parties” for consistency with our proposal to apply this provision to the Provider Access API, Payer-to-Payer API, and the PARDD API discussed further in sections II.B., II.C., and II.D. of this proposed rule. Because other parties would be accessing these APIs, such as providers and payers, it would be more accurate to use the term “parties” rather than “enrollees” or “beneficiaries.”

In summary, we propose that we will replace “clinical data, including laboratory results” with “all data classes and data elements included in a content standard at 45 CFR 170.213” for 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 identified in Table 1. We also propose that we will change the terms “enrollees” and “beneficiaries” to “parties” for 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 identified in Table 1.

We request comment on these proposals. We also direct readers to section II.F. of this proposed rule for a discussion of proposed changes to the interoperability standards for APIs that affect the Patient Access API.

f. Specific CHIP-Related Regulatory Framework

Specifically, for CHIP, the proposed amendments to 42 CFR 457.1233(d) would align separate CHIP managed care API requirements with the Medicaid managed care 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 propose to apply the API requirements in this proposed 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, and have noted this throughout the proposals in this proposed rule.

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 (the Act). We are proposing at 42 CFR 457.700(c) that for states with Medicaid Expansion CHIP programs, the proposals in this rule for Medicaid would apply to those programs rather than our proposals for separate CHIP programs. Functionally, our proposals are the same, however, for clarity, we are making explicit that the Medicaid requirements at 42 CFR 431.60, 431.61, and 431.80 would apply to those programs rather than the separate CHIP requirements at 42 CFR 457.730, 457.731, and 457.732.

3. Statutory Authorities for the Patient Access API Proposals

a. MA Organizations

For MA organizations, we are proposing these new requirements and the revisions to current requirements under our authority at sections 1856(b)(1) (to promulgate regulations implementing MA 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 proposal 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 proposals 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 proposal.

The proposal in section II.A.2.a. of this proposed rule that would require MA organizations to make an enrollee's prior authorization requests and related clinical documentation available through the Patient Access API would, if finalized as proposed, allow these enrollees to have access to that information in a convenient, timely, secure, and portable way, which is in enrollees' best interests. This proposed 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 enrollees support the prior authorization process, as well. Enrollees could see what information is needed and what information has been provided on their behalf to facilitate a prior authorization request. Enrollees 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 timelier 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 proposed here and finalized in the CMS Interoperability and Patient Access final rule (85 FR 25558 through 25559) would be most effective, CMS proposes in this rule that MA organizations report specific metrics to CMS on enrollee 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 proposed 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 healthcare and ensuring patients have secure access to their health information. We believe these proposals 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 proposed 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 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 uses or disclosures of information that are directly connected with the administration of the Medicaid state plan. The implementing regulations for this section of the Act list purposes that CMS has determined are directly connected to Medicaid state plan administration at 42 CFR 431.302 and provide safeguards states must apply to uses and disclosures of beneficiary data at 42 CFR 431.306. CHIP programs are subject to the same requirements through a cross reference at 42 CFR 457.1110(b). Our proposal to require that the data described in this section be shared via the Patient Access API would be consistent with the requirement that states may share these data only for purposes directly connected to the administration of the Medicaid state plan, since this data sharing would be related to providing services for beneficiaries, a purpose listed in § 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). 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 in order to meet the requirements of that regulation, states must have consistent criteria for release and use of information (which should comply with the proposed Patient Access API requirements, if finalized), 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 Medicaid agency, in accordance with 42 CFR 431.306(b). The permission requirement at § 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 proposal, 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 section 431.306 are relevant because they cover data release and use in contexts outside of our proposals in this section. However, we welcome comments from state Medicaid agencies and other members of the public on this topic.

The proposed 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 healthcare, 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 Medicaid FFS programs and managed care plans to prior authorization requests, thus facilitating more timely and successful prior authorizations, which 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 proposals are authorized under section 1902(a)(4), (8), and (19) of the Act.

In addition, this proposal would help implement section 1932(b)(4) of the Act, which provides that each Medicaid managed care organization 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 managed care organizations 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)(2)(A) 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 are also proposing to require state Medicaid agencies and Medicaid managed care plans to report Patient Access API metrics to CMS annually. We believe that having these metrics would support CMS' oversight, evaluation, and administration of the Medicaid program, as it would allow us to evaluate beneficiary access to the Patient Access API. Use of the API 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 would serve as a report to evaluate the implementation and execution of the Patient Access API.

For CHIP, we propose 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 proposed 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 different 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 would ultimately lead to these beneficiaries accessing that information in a convenient, timely, and portable way. This improved access would 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 would result in better health outcomes and patient satisfaction and improve the cost effectiveness of the entire healthcare system, including CHIP.

These proposals align with section 2101(a) of the Act in that they also would improve the efficiency of CHIP programs. For example, adding information about prior authorization requests to the Patient Access API would allow beneficiaries to easily obtain the status of prior authorization requests made on their behalf. This would 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, ultimately streamlining the prior authorization process.

Additionally, the safeguards for applicant and beneficiary information at subpart F of 42 CFR part 431 are also applicable to CHIP through a cross-reference at 42 CFR 457.1110(b). As discussed above 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, proposing to require state CHIP agencies and CHIP managed care entities to report Patient Access API metrics to CMS annually would 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 use of the Patient Access API, 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. QHP Issuers on the FFEs

For QHP issuers on the FFEs, we propose 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.

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. Having simple and easy access, without special effort, to their health information also would facilitate enrollees' ability to detect and report fraud, waste, and abuse—a critical component of an effective program. 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 healthcare, 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. This would also facilitate timelier 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, proposing to require QHP issuers on the FFEs to report Patient Access API metrics to CMS annually would help CMS assess the effect this API is having on enrollees and would 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, to ensure this requirement is being met efficiently and adding value to CMS operations, including leading to the efficiencies intended.

B. Provider Access API

1. Background

In the CMS Interoperability and Patient Access final rule, we implemented policies regarding the Patient Access API (85 FR 25558) that would allow patients to access their health information through an 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 and stored on their mobile smart device, which could help inform a discussion with their provider about their health status.

We also discussed the potential benefits of payers sharing patient health information directly with providers in that final rule (85 FR 25555) and encouraged payers to consider an API solution that would enable providers to access appropriate health information through the payers' APIs to support the delivery of care. We 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 an individual's total care and providers could reduce or eliminate duplicate tests, which might avoid diagnostic errors. Payers might also see fewer duplicate requests for services, fewer appeals and, possibly, lower costs. We specifically agreed with commenters that making information about prior authorization decisions available via an API would reduce burden on providers and their staff (85 FR 25541).

While using the Patient Access API is a significant first step toward sharing individual patient health information with providers, it would also be beneficial for payers 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 this rule we propose to require that impacted payers 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 proposed 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.

In the December 2020 CMS Interoperability proposed rule, we proposed to require payers to build a Provider Access API. As discussed in section I.A. of this proposed rule, we are withdrawing the December 2020 CMS Interoperability proposed rule and issuing this new proposed rule that incorporates the feedback we received from stakeholders on that proposed rule. We understand that many readers may already be familiar with that proposed rule. To distinguish between that proposed rule and our proposals herein, we refer readers to section I.A. of this proposed rule, which outlines the overarching differences between the two proposed rules.

We are again proposing to require impacted payers to implement and maintain a FHIR API to exchange data with providers, but with changes from the December 2020 CMS Interoperability proposed rule. We are again proposing a FHIR API, but we are now taking a different approach to the standards required for the API, as further described in section II.F. of this proposed rule. We are also proposing 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 proposed herein. Finally, we propose to establish the Provider Access API compliance date as January 1, 2026.

As mentioned in section I.A. of this proposed rule, these proposals do not pertain to Medicare FFS. We seek comment on how each of our proposals discussed below on Provider Access API could be implemented for the Medicare FFS program. We expect that a Medicare FFS implementation would conform to the same proposed requirements that apply to the impacted payers under this proposed rule, as applicable, so Medicare FFS providers and patients enrolled in Medicare FFS could also benefit from this type of data sharing. We seek comment on whether this could be implemented as proposed for the Medicare FFS program, how we could apply each of these proposals below, and if there would be any differences for implementing the Provider Access API in the Medicare FFS program as a Federal payer. As noted later in this section of this proposed rule, 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. We note that because Medicare FFS provider remittances and enrollee cost-sharing information are not proprietary, those data are shared in the DPC pilot; however, as discussed in this section, impacted payers would not be required to share that information under our proposals. The information gained from the DPC pilot will be useful to implementers should the proposals in this proposed rule be finalized.

2. Proposed 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 to health apps when requested by a patient, through a Patient Access API. We believe it would be valuable for providers to have access to the same patient data, except for provider remittances and enrollee cost-sharing information, through a FHIR API that allows a provider to request data for an individual patient, as needed, thereby providing further insight into the patient's care activity. Research shows that patients achieve better outcomes when their record is more complete and there are more data available to the healthcare 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 are proposing to require that impacted payers implement and maintain a Provider Access API to enable current patients' information to be exchanged from payers to providers that are in that payer's network, at the provider's request. A provider in the payer's network, for purposes of this proposal, would be any provider or healthcare facility that is part of a specific health plan's network of providers with which it has a contract. In the case of Medicaid and CHIP FFS programs, it would be any providers or healthcare facilities that are enrolled with the state as Medicaid or CHIP providers. We note 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 this proposal. However, see section II.C. for the proposed Payer-to-Payer API requirements for transferring a patient's data from a previous payer to a new payer.

The proposed Provider Access API would allow a provider to initiate a request, for example, when the provider needs access to a patient's data prior to or during a patient visit. Both this proposed Provider Access API and the Patient Access API would facilitate the FHIR-based exchange of claims and encounter data, as well as all data classes and data elements included in a content standard adopted at 45 CFR 170.213, such as Immunizations, Procedures, and Assessment and Plan of Treatment, should the payer maintain such information. Both the Patient Access and Provider Access APIs would require payers to share information related to prior authorization requests and decisions (including related administrative and clinical documentation) for items and services (excluding drugs). As discussed in section II.A.2.a of this proposed rule, we are proposing to require that information about prior authorizations (and related administrative and clinical documentation) 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 we are formulating our proposal for at least 1 year after any status change, but 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 do 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.

We believe that sharing claims and encounter information, without provider remittances and enrollee cost-sharing information, would complement the clinical data classes and data elements included in a content standard at 45 CFR 170.213 by providing more information to support treatment and care coordination. Claims and encounter data used in conjunction with clinical data can offer a broader, more complete picture of an individual's interactions with all their providers in the healthcare system. With this proposal, we intend to help providers gain efficient access to more comprehensive data on their patients. Thus, we are proposing to require that impacted payers make available any of the applicable patient data with a date of service on or after January 1, 2016. This proposed 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 data from this timeframe via a FHIR API.

Such disclosures from payers to healthcare providers would be permitted under the HIPAA Privacy Rule as disclosures for treatment purposes, as well as disclosures required by law, which this proposed rule would be establishing if finalized. Additionally, Medicaid and CHIP agency disclosures of beneficiary data to in-network providers under this proposal would be consistent with section 1902(a)(7) of the Act and implementing regulations at 42 CFR part 431, subpart F, and 42 CFR 457.1110(b). Under these provisions, states must restrict the use or disclosure of information concerning applicants and beneficiaries to purposes directly connected with the administration of the plan. The disclosures of patient data through the Provider Access API would be directly related to the administration of the state plan because they would support the provision of services for beneficiaries, as described in 42 CFR 431.302(c). As mentioned, a provider could better manage a patient's total care when they have access to more of that patient's data because the data would provide a more in-depth medical history, enable more informed decision making, and potentially prevent the provision or ordering of duplicative services. Additionally, states must apply the safeguards described in 42 CFR 431.306 when sharing beneficiary data via the Provider Access API. We remind states that in order to meet the requirements of that regulation, they must have consistent criteria for release and use of information (which should comply with the proposed Provider Access API requirements, if finalized), in accordance with 42 CFR 431.306(a). Access to information concerning beneficiaries must be restricted to persons or agency representatives who are subject to standards of confidentiality that are comparable to that of the Medicaid agency, in accordance with 42 CFR 431.306(b). The permission requirement in § 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 proposal, because any request for beneficiary information would be from an enrolled Medicaid or CHIP provider and thus would not be from an “outside source.” A Medicaid or CHIP provider would have a provider agreement with the Medicaid or CHIP agency in order to provide Medicaid or CHIP benefits and services under its state plan. As such, Medicaid and CHIP providers are part of the state's Medicaid and CHIP program assisting the state agency in carrying out core functions of the state's Medicaid or CHIP State Plan, providing benefits and services to beneficiaries. Therefore, no additional consent from the beneficiary or personal representative would need to be obtained by the Medicaid or CHIP agency prior to sharing the individual's information with a Medicaid or CHIP provider. We note that while patient permission is not required under § 431.306(d) for the proposals we discuss here, state, or other laws may require such permission. We do not believe that any of the other requirements of 42 CFR 431.306 are relevant because they cover data release and use in contexts outside of our proposals in this section. However, we welcome comments from state Medicaid agencies and other members of the public on this topic.

There are a few notable differences between the requirements for a Patient Access API and our proposals for a Provider Access API. The biggest difference is how and why the end user would 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. For the Provider Access API proposals, the provider would request and receive access to the patient's information through their EHR, practice management system, or other technology solution for treatment purposes, including care coordination. Providers would securely access their patients' data using at least one of these systems through a FHIR API. Providers would not access patient data through their own health app; rather, the data would flow from the payer to the provider's EHR or practice management system, which would allow them to incorporate the patient data into their records. 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. Under this proposal, the provider would be able to request the additional data from the patient's payer, provided the patient has not opted out (as explained in section II.B.3.b. of this proposed rule). The payer would then be required to share the requested data no later than 1 business day after the provider initiates this request.

Finally, unlike the Patient Access API, we propose that the Provider Access API would not include provider remittances and enrollee cost-sharing information. Many payers consider cost-sharing information proprietary, and we believe that information would have limited benefit for treatment or care coordination. We note that our proposals in section II.C. of this proposed rule would exclude provider remittances and enrollee cost-sharing information from the payer to payer data exchange, and we propose the same for the Provider Access API.

In the CMS Interoperability and Patient Access final rule CMS required standards for the Patient Access API by cross reference to 45 CFR 170.215 (85 FR 25558). In this proposed rule, we are proposing to amend these cross references, as discussed in section II.F. We also propose, at the CFR citations listed in Table 2, that the Provider Access API would require adherence to the same technical standards, API documentation requirements, and standards for denial or discontinuation of access to the API. Additionally, we note that unlike for the Patient Access API, we are proposing to require the FHIR Bulk Data Access Implementation Guide at 45 CFR 170.215(a)(4). For a complete discussion of these requirements, we refer readers to the CMS Interoperability and Patient Access final rule (85 FR 25526) and to section II.F. of this proposed rule.

We acknowledge 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, if a provider does not have a provider agreement or is not enrolled (in the case of Medicaid and CHIP FFS programs) with a payer that holds their patient's data, the payer would not be required to provide patient data to that provider under this proposal, though it may be permissible or even required by other law or regulation. We recognize that this could make it more difficult for an out-of-network provider to create a comprehensive care record for a patient. We considered requiring payers to share the data with all providers, regardless of whether the provider is under contract or enrolled with the payer. However, for reasons we explain in this section of this proposed rule, we are not proposing to do so, and are instead seeking comment on various issues surrounding that possible requirement. Though we are not proposing to require it at this time, we encourage payers to share information via API with out-of-network or unenrolled providers who have a verified treatment relationship with the patient, to the extent permitted by law.

There could be privacy, security, and program integrity concerns with requiring payers to share patient information with out-of-network providers. For example, because MA organizations, Medicaid FFS programs, CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities must ensure they do not enroll or contract with providers that are on the HHS Office of the Inspector General List of Excluded Individuals/Entities (LEIE), limiting data sharing through the Provider Access API to in-network or enrolled providers can help ensure these data are not shared with providers who have already been determined by the Federal Government to present fraud or other program integrity risks. Since these risks exist, if we were to require payers to share patient information with out-of-network providers, we would also have to require payers to establish safeguards to ensure that an out-of-network provider would be a trustworthy recipient of patient information. This could create significant burden for payers who may need to expend resources towards vetting providers with whom they do not have an existing relationship.

The LEIE does not apply to QHPs, but in order to offer coverage through the FFEs, they must comply with certification rules per 45 CFR part 156, which includes requirements to prevent QHP issuers from contracting with providers known to submit fraudulent or wasteful claims. For example, § 156.810(a)(7) specifies that a QHP issuer may be decertified if, based on credible evidence, they have committed or participated in fraudulent or abusive activities, including submission of false or fraudulent data. Section 156.340 provides that a QHP issuer is responsible for its own compliance and the compliance of any of its delegated or downstream entities with all applicable Federal standards related to Exchanges. Per § 156.20, “delegated entity” means any party that enters into an agreement with a QHP issuer to provide administrative services or health care services (for example, contracted providers). Section 156.20 also defines a “downstream entity” as any party that enters into an agreement with a delegated entity or with another downstream entity to provide administrative services or health care services (for example, subcontracted providers). Thus, in order to maintain certified status, QHP issuers generally must have processes in place to avoid contracting with providers that engage in fraudulent practices. QHP issuers that also provide out-of-network coverage can make the determination of whether or not to share data with out-of-network providers using their existing processes.

As we consider imposing a requirement to share patient data with out-of-network providers through future rulemaking, we request comment on how payers do so today, the effectiveness of current processes to validate the treatment relationships between patients and providers when a contractual relationship does not exist between the provider and the payer, and what additional program integrity safeguards might be appropriate when other contractual mechanisms are not in place to ensure that patient data are provided only to qualified, trustworthy providers. We are particularly interested in the following questions: How would out-of-network providers request access to their patients' data and demonstrate that the provider has a treatment relationship with the patient? What processes and verification requirements would we need to require each payer to establish to verify the patient-provider treatment relationship? Should payers consider certain provisions in data use or data exchange agreements? If so, what could those provisions address? What are current best practices for terms of service? What other operational best practices for enabling safe data exchange with out-of-network providers should CMS consider in determining whether to propose a policy requiring this?

We emphasize that all data shared and received via this proposed data exchange would still have to be handled in a way that is consistent with all current and applicable laws and regulations, and our proposals are not intended to modify those other laws. Payers and healthcare providers that are covered entities under HIPAA are subject to the HIPAA Rules. Adherence to the HIPAA Rules would ensure that the provider 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 access authorization 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 also be state laws that require certain privacy and security protections for health information exchange. Additionally, other laws, such as the regulations that focus on confidentiality of patient records associated with substance use disorder at 42 CFR part 2 or state privacy laws, may require the payer to obtain the enrolled individual's permission to disclose certain PHI. We request comment on any other considerations regarding state privacy or other laws that may be implicated by our proposals.

We are proposing to require, at the CFR citations identified in Table 2, that impacted payers share certain patient information with in-network and enrolled providers who have a treatment relationship with the payers' patients upon request by the provider. Thus, payers would be required by regulation to make such disclosures if there is a treatment relationship with the individual. The HIPAA Privacy Rule permits a covered entity, such as a health plan, to disclose PHI of the enrolled individual to a health care provider without individual authorization for treatment purposes under 45 CFR 164.506(c)(2) or as required by law per 45 CFR 164.512(a)(1).

Our proposal would not alter any obligation for HIPAA-covered entities to follow the HIPAA Rules or other applicable law, including, but not limited to, standards regarding the use and disclosure of PHI, administrative, physical, and technical safeguards and other security provisions, and breach notification. The security framework of the proposed API, as required via reference to standards at 45 CFR 170.215, would 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 would give the provider permission to access data. The authentication protocols are those that would allow the payer to ensure that the provider that is requesting this access is who they say they are. In addition to using these required protocols, the payer would 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 this section of this proposed rule in detail. 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.

HIPAA also requires the Secretary to adopt standards for specific transactions and establish a process for updating those standards. A HIPAA transaction is an electronic transmission of information from a covered entity to carry out financial or administrative activities related to health care (for example, when a health care provider sends a claim to a health plan to request payment for medical services) for which the Secretary has adopted a standard. Under HIPAA, HHS is required to adopt standards for electronically transmitting certain health care information, including:

• Health care claims or equivalent encounter information;
• Health care electronic funds transfers and remittance advice;
• Health care claim status;
• Eligibility for a health plan;
• Enrollment and disenrollment in a health plan;
• Referrals certification and authorization;
• Coordination of benefits;
• Health plan premium payments; and
• Medicaid pharmacy subrogation (not mandated under HIPAA, but, consistent with section 1173(a)(1)(B) of the Social Security Act, a standard has been adopted for this purpose).

The Secretary has adopted a HIPAA transaction standard for transmitting claims or equivalent encounter information. Although our proposals would facilitate sharing claims data from payers to providers, the transmission would not be subject to HIPAA transaction standards because the purpose of the exchange would not be to request or issue a payment. We are also not proposing 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. Therefore, a HIPAA transaction standard is not required to be used for our proposals in this section because the Secretary has not adopted a HIPAA standard applicable to communicating claims or encounter information for a purpose other than requesting or issuing payment.

In summary, we propose that beginning January 1, 2026 (for Medicaid managed care plans and CHIP managed care entities, by the rating period 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 would be required to implement and maintain a FHIR API to exchange data with providers conformant to the standards discussed in section II.F and at the CFR citations referenced in Table 9. Individual patient data maintained by the payer with a date of service on or after January 1, 2016, must be made available via that API no later than 1 business day after the payer receives a request for data by an in-network provider, (or in the case of a Medicaid or CHIP FFS program, an enrolled Medicaid or CHIP provider).

We are proposing these requirements for the Provider Access API for MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities (excluding Non-Emergency Medical Transportation (NEMT) PAHPs, as explained in this section of this proposed rule), and QHP issuers on the FFEs at the CFR sections identified in Table 2.

For Medicaid and CHIP managed care, we propose 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. MCOs, PIHPs, and non-NEMT PAHPs would be subject to this proposed rule. We believe 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, justify their exclusion from the requirements of the Provider Access API proposed at 42 CFR 431.61(a). Specifically, we do not believe that providers have routine need for NEMT data; therefore, requiring NEMT PAHPs to implement and maintain a Provider Access API would be an undue burden. However, we propose to include NEMT PAHPs in the scope of most of the other requirements of this proposed rule that apply to all other Medicaid managed care plans listed in Table 2.

We request public comment on the proposal for impacted payers to implement and maintain a Provider Access API to provide access to specified patient information.

3. Additional Proposed Requirements for the Provider Access API

In general, the proposals discussed in this section regarding the data that payers must make available through the API, as well as the technical specifications, align with the requirements for the Patient Access API finalized in the CMS Interoperability and Patient Access final rule (85 FR 25558) and as proposed in section II.A.2. of this rule. We anticipate that this alignment would provide consistency and help payers build on the work done to comply with the requirements for the Patient Access API, outlined previously. Additional proposed 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 the Provider Access API, we are proposing to require that payers develop an attribution process to associate patients with their providers to help ensure that a payer only sends a patient's data to providers who are requesting that data and who have a treatment relationship with that patient.

We are aware that the process of attribution can have many functions for payers, including managing contracts, payments, financial reconciliation, reporting, and continuity of care. In addition, HL7 has developed a member attribution process and workflow in the Da Vinci Member Attribution List FHIR Implementation Guide (IG), which defines various terms and describes a general process by which a payer and provider can coordinate and reconcile their understanding of which patients associated with a particular payer-provider contract. This IG does not specify how the payer and provider identify these patients, but it does specify the FHIR resources (that is, data elements) which are created as an output of this process. We thus encourage payers to use processes that they may already have to attribute patients to their providers for these other purposes.

A payer may implement a process to generate a provider's current patient roster using claims data, and only permit data exchange through the Provider Access API to providers with whom those patients can be attributed via claims data. For example, payers could accept proof of an upcoming appointment to verify the provider-patient treatment relationship. We know that many providers already verify coverage with the payer before a new patient's first appointment. If an in-network provider is seeing a patient for the first time, the provider's practice can send proof of the upcoming appointment to the payer. Once confirmed, this would then allow the provider to request the patient's data in preparation for the appointment. We further note that the Argonaut Project has developed an implementation guide specifying how to use FHIR's Scheduling and Appointment resources to communicate this information. We request comments on other examples of how patients can be attributed to the providers from whom they are receiving care, especially for a new patient-provider treatment relationship. We also request comments on whether and how the payer could attribute the patient to the provider at the same time as or through the same data transaction.

CMS has implemented an attribution process in our DPC pilot for Medicare beneficiaries, which is the Medicare FFS version of the Provider Access API. The pilot project 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 which represents the patient population currently being treated at their facilities. To add a new patient, CMS requires providers to attest that they have a treatment-related purpose for adding 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 methodologies 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 proposed requirement.

Based on feedback from the industry, the HL7 Da Vinci attribution work group has developed a published Member Attribution List IG. The Da Vinci Member Attribution List IG defines the mechanisms (that is, protocols), data structures and value sets to be used for exchanging the Member Attribution List. The Member Attribution List supported by the Da Vinci Member Attribution List IG 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. DPC has been working with the Da Vinci Member Attribution List team towards compatibility with this IG. We also note that the list capability of this IG is informing updates to the Da Vinci Payer Data Exchange (PDex) IG. We encourage payers to review the information from the workgroup.

We do not wish to be overly prescriptive about how payers could generate an attribution list for providers, but it would be necessary for payers to establish a process to meet these proposed attribution requirements for the Provider Access API. Because the standards for the attribution process continue to evolve, we are not specifying how payers should identify whether a specific patient can be attributed to the requesting provider. Instead, we encourage the community to continue to collaborate on viable approaches.

We also recognize that 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 health information exchanges (HIEs). In many cases, these HIEs include patient attribution capabilities for which payers may already have a process. Once again, our goal is for payers to avoid having to develop multiple approaches to address attribution, and we encourage collaboration on potential solutions.

In summary, we propose 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 would maintain a 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 proposing these attribution requirements for MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans other than NEMT PAHPs, CHIP managed care entities, and QHP issuers on the FFEs at the CFR sections identified in Table 2.

We solicit comments on our proposal to require payers to develop processes for verifying the patient-provider treatment relationship, including any processes that may be in place today.

b. Opt Out

We are proposing that all impacted payers would be required to establish and maintain a process to allow patients or their personal representatives to opt out of having the patients' data available for providers to access through the Provider Access API. We note that this differs from our Payer-to-Payer API proposal in section II.C.3.c. of this proposed rule, under which all impacted payers would have an opt in process. Similar to the proposed attribution process, as previously discussed, we do not intend to be prescriptive regarding how this opt out process should be implemented, but payers would be required to make this opt out process available, and give all currently enrolled patients or their personal representatives a chance to opt out, before the first date on which patient information is made available via the Provider Access API. Specifically, we are proposing that impacted payers must maintain a process to allow patients or their personal representatives to opt out of data sharing, or if they have already opted out, to opt back in. The process for opting out and opting back in would have to be available before the first date on which patient information is made available via the API and at any time while the patient is enrolled with the payer. We are not proposing to require specific methods for patients to opt out, but anticipate that payers would make that process available by mobile smart device, website, and/or apps. We also anticipate that mail, fax, or telephonic methods may be necessary alternatives for some patients, which payers would have to accommodate if this policy is finalized as proposed. We invite comments on whether we should establish more explicit requirements regarding patient opt out processes.

Our proposal would require 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 encourage payers to implement processes that allow more granular controls over the opt out process, so patients can opt out of having data exchanged with individual providers or groups of providers. We are not proposing implementation of such processes as a requirement in this rulemaking, as we are concerned about the potential administrative and technical burden this may place on some payers. However, we request 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 are proposing an opt out approach because opt in models of data sharing, as we discuss in this section of this rule, have been shown to inhibit the utilization and usefulness of data sharing efforts between patients and healthcare providers. We acknowledge that there are positives and negatives to both opt in and opt out policies, and many patients may prefer to control or direct their health information via an opt in process because opt in policies require 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 intervention by the patient. We believe this 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 believe that a proposal defaulting to share 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 propose in more detail in this section of this rule, payers would be responsible for providing patient resources to ensure that patients understand the implications of the opt out option. We note that should patients choose not to opt out of data sharing, then the data we propose be made available via the Provider Access API would be available at any time to providers that have been attributed to have a treatment relationship with the patient. However, we believe our proposals, taken together, would give patients ample opportunities to change their data sharing preference as they see fit.

Opt in models can create greater administrative burden for smaller healthcare organizations, depending on where the responsibility for obtaining and updating the patient's data sharing preference is held. We note that smaller hospitals in states with opt in patient permission requirements for HIE are more likely to report regulatory barriers to data exchange compared with those in states with opt out policies, though more technologically advanced hospitals reported no difference. A report produced for ONC found that states using an opt out model were quantitatively associated with significantly higher HIE utilization and maturation. A 2016 survey found that of the 24 states that give patients a choice regarding participation in the HIE, 16 states have laws describing an opt out procedure, and eight states have enacted an opt in procedure. We note that for this report, “HIE” refers exclusively to organizations that facilitate information exchange among healthcare providers, as opposed to the act of exchanging data for other purposes.

Within the Department of Veterans Affairs (VA), the Veterans Health Administration, Office of Health Informatics, Veterans Health Information Exchange (VHIE) Program Office, leads interoperability and HIE between VA facilities and private sector providers. Until April 2020, VA operated with an opt in model. Between 2013 and 2017, the VHIE Program Office collected information on the opt in process, and in 2017 reported collecting patient permissions from only 4 percent of the enrolled veterans. Consequently, an estimated 90 percent of requests for patient information were rejected by the system for lack of permission. One-third of these were collected online while the other two-thirds were paper forms, which indicates a very high level of manual work and administrative burden. Beginning in April 2020, as authorized by section 132 of the John S. McCain III, Daniel K. Akaka, and Samuel R. Johnson VA Maintaining Internal Systems and Strengthening Integrated Outside Networks Act of 2018 (VA MISSION Act of 2018) (Pub. L. 115-182), VA changed its procedures from an opt in to an opt out model for obtaining patient permission to share data.

In the December 2020 CMS Interoperability proposed rule, we proposed an opt in patient permission model for the Provider Access API and requested comments on opt in versus opt out approaches. In response, commenters overwhelmingly supported an opt out model and cited clinical and operational hurdles associated with an opt in approach. Support for an opt out approach came from both provider associations and payers, while patient commenters did not oppose such a proposal. We also believe 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 they are defined by the Healthy People 2030 report, while protecting patients' choice to limit data sharing.

This proposed opt out option is specific to the data we are proposing payers be required to share via the Provider Access API. As discussed previously, this proposed rule would not 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, if finalized, we would encourage 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 proposals, provided such disclosure is consistent with all other applicable requirements, such as the HIPAA Rules. We also note that the HIPAA Rules permits health plans to disclose PHI, without an individual's authorization, to providers via the Provider Access API for certain permitted purposes under the HIPAA Rules, such as, for example, treatment, payment, or health care operations

We value the importance of safeguarding the quality and integrity of patient health information. We acknowledge that there may be potential program integrity risks associated with sharing patient data under both an opt in and opt out model. We believe that payers already have program integrity protocols through which they determine if a data exchange has resulted in potential fraud and coordinate investigations of any potential fraud with the relevant programmatic authorities or state laws. We expect that if payers identify any vulnerabilities, they would work to make changes to their operations to address risks that could lead to potential fraud and to limit the impact on patient information.

In summary, we propose 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 maintain a process for patients or their personal representatives to opt out of and subsequently opt into having the patient's health information available and shared via the Provider Access API. We propose 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 proposing this requirement for 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 identified in Table 2.

We request comments on our proposal for a patient opt out framework for the Provider Access API. We additionally request comments on whether patients should be able to exercise more granular controls over which data they permit the payer to share, including permitting the sharing of certain data from only specific timeframes.

c. Patient Resources Regarding the Provider Access API

To ensure that patients understand the implications of the opt out option for the Provider Access API, we are proposing to require payers to provide information to their patients about the benefits to the patient of the Provider Access API requirements, their opt out rights, and instructions both for opting out of the data exchange and for opting in after previously opting out. Payers would have to provide this information, in non-technical, simple, and easy-to-understand language, at the time of enrollment and annually. Payers would also be required to make this information available at all times, in an easily accessible location on payers' public websites. We are not proposing specific text or format of this information, but we request comments on whether there are benefits or burdens to requiring that this information be provided in a specific format or to include specified content. In particular, we are interested in comments on language regarding how patient data could be used and shared through the API. We anticipate payers would include information about patients' ability to opt out of (and opt back in to) this data sharing in their regular communications, such as annual enrollment information, privacy notices, member handbooks, or newsletters. However, we request comment on the most appropriate and effective communication channel(s) for conveying this information to patients. We also request comment on whether providing this information at the time of enrollment and annually is appropriate, or whether we should require that this information be provided directly to the patient more frequently.

We believe it is important to honor patient privacy preferences, and believe it is important for providers to have access to patient information to be able to provide treatment and coordinate care effectively. We also believe that more informed patients are more empowered patients, which we believe leads to increased engagement with their care and ultimately improved health outcomes. Offering patients educational materials about their right to opt out of data sharing via the proposed Provider Access API is thus fundamental to empowering patients with their data.

In summary, we propose 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 provide information in non-technical, simple, and easy-to-understand language to their patients about the benefits of API data exchange with their providers, their opt out rights, and instructions both for opting out of data exchange and for opting in after previously opting out. We are proposing that these payers must make this information available to currently enrolled patients before the Provider Access API is operational and shares any of their data. We are proposing that thereafter, payers provide this information at enrollment and at least annually. We are also proposing that this information be available in an easily accessible location on payers' public websites.

We are proposing this requirement for annual information for 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 identified in Table 2.

d. Provider Resources Regarding the Provider Access API

We are proposing to require payers to develop non-technical and easy-to-understand educational resources for providers about the Provider Access API. These educational resources should explain how a provider can request patient data using the payer's Provider Access API. The resources would have to include information about the process for requesting patient data from the payer using the API and how to use the payer's attribution process to associate patients with the provider. We are proposing 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 would help providers understand how they can use the API to access patient data, thus realizing the expected benefit of the proposed API.

Specifically, we propose 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 would provide educational resources in non-technical and easy-to-understand language on their websites and through other appropriate mechanisms for communicating with providers, explaining how a provider may make a request to the payer for patient data using the FHIR API. We also propose that those resources must include information about the mechanism for attributing patients to providers.

We are proposing this requirement for provider resources for 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 identified in Table 2.

We request comment on this proposal, including whether CMS should develop guidance regarding, or address in future rulemaking the specific content of these educational materials about the Provider Access API.

4. Extensions, Exemptions, and Exceptions

a. Extensions and Exemptions for Medicaid and CHIP FFS Programs

Should our proposals regarding the Provider Access API be finalized as proposed, we would strongly encourage state Medicaid and CHIP FFS programs to implement the Provider Access API as soon as possible, due to the many anticipated benefits of the API as discussed in this section. However, we also recognize that state Medicaid and CHIP FFS agencies may face certain circumstances that would not apply to other impacted payers. To address these concerns, we are proposing a process through which states may seek an extension of, and, in specific circumstances, an exemption from, the Provider Access API requirements. We propose the following:

(1) Extension

At the regulation citations identified in Table 2, we propose to provide state Medicaid FFS and CHIP FFS programs the opportunity to request a one-time extension of up to 1 year to implement the Provider Access API specified at 42 CFR 431.61(a) and 457.731(a). Some states may be unable to meet the proposed compliance date due to challenges related to securing needed funding for necessary contracting and staff resources in time to develop and implement the API requirements, depending on when the final rule is published in relation to a state's fiscal year, legislative session, budget process, and related timeline. Some states may need to initiate a public procurement process to secure contractors with the necessary skills to support a state's implementation of these proposed API policies. The timeline for an openly competed procurement process, together with the time needed to onboard the contractor and develop the API, can be lengthy for states. A state might need to hire new staff with the necessary skillset to implement this policy. The time needed to initiate the public employee hiring process, vet, hire, and onboard the new staff may make meeting the proposed compliance timeline difficult because, generally speaking, public employee hiring processes include stricter guidelines and longer time-to-hire periods than other sectors. Furthermore, states are currently responding to the effects of the COVID-19 public health emergency, and their regular operational resources are over-extended. Unwinding from the COVID-19 public health emergency is also expected to require significant IT resources, which could have an impact on future IT work. In all such situations, a state might need more time than other impacted payers to implement the Provider Access API requirements. The 1-year extension that we propose could help mitigate the challenges. We considered delaying implementation of the provisions in this proposed rule an additional year for states, but decided that it would be better to propose to have only those states that needed an extension apply, because states vary in their level of technical expertise and ability to recruit staff and secure contracts.

Should the proposal for this API be finalized as proposed, states would be permitted to submit a written application for a one-time, one-year extension as a part of their annual Advance Planning Document (APD) for Medicaid Management Information System (MMIS) operations expenditures. The state's request would have to include the following: (1) a narrative justification describing the specific reasons why the state cannot reasonably satisfy the requirement(s) by the compliance date, and why those reasons result from circumstances that are unique to the agency operating the Medicaid and/or CHIP FFS program (versus other types of impacted payers); (2) a report on completed and ongoing state implementation activities that evidence a good faith effort towards compliance; and (3) a comprehensive plan to meet the Provider Access API requirements no later than 1 year after the compliance date.

Under this proposal, CMS would approve an extension if, based on the information provided in the APD, CMS determines that the request adequately establishes a need to delay implementation, and that the state has a comprehensive plan to implement the proposed requirements no later than 1 year after the compliance date. We also solicit comments on whether our proposal would adequately address the unique circumstances that affect states and that might make timely compliance with the proposed API requirement difficult for states.

(2) Exemption

At the CFR sections identified in Table 2, we propose to permit state Medicaid FFS programs to request an exemption from the Provider Access API requirements when at least 90 percent of the state's Medicaid beneficiaries are enrolled in Medicaid managed care organizations as defined at 42 CFR 438.2. Likewise, we propose that separate CHIP FFS programs could request an exemption from the Provider Access API requirements if at least 90 percent of the state's separate CHIP beneficiaries are enrolled in CHIP managed care entities, as defined at 42 CFR 457.10. In this circumstance, the time and resources that the state would need to expend to implement the Provider Access API requirements for a small FFS population may outweigh the benefits of implementing and maintaining the API. Unlike other impacted payers, state Medicaid and CHIP FFS programs do not have a diversity of plans to balance implementation costs for those plans with low enrollment. If there is low enrollment in a state Medicaid or CHIP FFS program, there is no potential for the technology to be leveraged for additional beneficiaries. States, unlike other payers, do not maintain additional lines of business.

We acknowledge that the proposed exemption could mean that most beneficiaries enrolled with exempted Medicaid or CHIP FFS programs would not receive the full benefits of having this API available to facilitate health information sharing with providers. To address this, we propose that states that are granted an exemption would be expected to implement an alternative plan to ensure that enrolled providers will have efficient electronic access to the same information through other means, to help ensure that Medicaid or CHIP services are provided with reasonable promptness and in a manner consistent with simplicity of administration and in the best interests of those beneficiaries who are served under the FFS program.

We propose that a state could submit a written request for an exemption from the requirements for the Provider Access API as part of its annual APD for MMIS operations expenditures prior to the date by which the state would otherwise need to comply with the requirements (which may be extended by 1 year if the state receives an extension). For Medicaid exemption requests, the state would be required to include documentation that it meets the criteria for the exemption based on enrollment data from the most recent CMS “Medicaid Managed Care Enrollment and Program Characteristics” report. For a CHIP FFS exemption, the state's request would have to include enrollment data from Section 5 of the most recently accepted state submission to the CHIP Annual Report Template System (CARTS). The state would also be required to include in its request information about an alternative plan to ensure that enrolled providers will have efficient electronic access to the same information through other means while the exemption is in effect. CMS would grant the exemption if the state establishes to CMS's satisfaction that it meets the criteria for the exemption and has established such an alternative plan. We note that the same considerations for beneficiary opt out, as previously explained, would still be required.

Once an exemption has been approved, we propose that the exemption would expire if either of the following two scenarios occurs: (1) based on the 3 previous years of available, finalized Medicaid Transformed Medicaid Statistical Information System (T-MSIS) and/or CHIP CARTS managed care and FFS enrollment data, the State's managed care enrollment for 2 of the previous 3 years is below 90 percent; or (2) CMS has approved a State plan amendment, waiver, or waiver amendment that would significantly reduce the share of beneficiaries enrolled in managed care and the anticipated shift in enrollment is confirmed by available, finalized Medicaid T-MSIS and/or CHIP CARTS managed care and FFS enrollment data.

For the first scenario, CMS recognizes that there may be circumstances where a state's managed care enrollment may fluctuate slightly below the 90 percent threshold in 1 year, and yet return to above 90 percent the next year. To help reduce the possible burden on exempted states experiencing this type of temporary fluctuation in managed care enrollment, CMS would consider data from the 3 previous years of available, finalized Medicaid T-MSIS and/or CHIP CARTS managed care and FFS enrollment data. We propose that if the state's managed care enrollment for 2 of the previous 3 years is below 90 percent, the state's exemption would expire.

We propose that a state would be required to provide written notification to CMS that the state no longer qualifies for the Provider Access API exemption when data confirm that there has been a shift from managed care enrollment to FFS enrollment resulting in the State's managed care enrollment falling below the 90 percent threshold for 2 of the previous 3 years. We propose that the written notification be submitted to CMS within 90 days of the finalization of the annual Medicaid T-MSIS managed care enrollment data and/or the CARTS report for CHIP confirming that there has been the requisite shift from managed care enrollment to FFS enrollment in 2 of the 3 previous years.

For the second scenario, we recognize that there may be state plan amendments, waivers, or waiver amendments that would result in a shift from managed care enrollment to FFS enrollment. Additionally, there may be instances where anticipated enrollment shifts may not be fully realized due to other circumstances. We propose that a state would be required to provide written notification to CMS that the state no longer qualifies for the Provider Access API when data confirm that there has been a shift from managed care enrollment to FFS enrollment as anticipated in the state plan amendment or waiver approval. We propose that the written notification 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 confirming that there has been the requisite shift from managed care enrollment to FFS enrollment.

Regardless of why the exemption expires, if it expires, the state would be required to obtain CMS's approval of a timeline for compliance with the Provider Access API requirements for the state's Medicaid FFS and/or CHIP FFS population(s) within two years of the expiration of the exemption.

For Medicaid and CHIP managed care, we are not proposing an extension process because we believe that managed care plans are actively working to develop the necessary IT infrastructure to be able to comply with the existing requirements at 42 CFR parts 438 and 457 and because many of them might benefit from efficiencies resulting from the variety of plan types that they offer. Many managed care plans are part of parent organizations that maintain multiple lines of business, including Medicaid managed care plans and plans sold on the Exchanges. As discussed in the CMS Interoperability and Patient Access final rule (85 FR 25607, 25612, and 25620), work done by these organizations can benefit all lines of business and, as such, we do not believe that the proposals in this rule impose undue burden or cannot be achieved by the compliance date. We are soliciting comments on our assumptions regarding the scope of resources and ability of managed care parent organizations to achieve economies of scale when implementing the proposed API.

Further, we seek comment on whether an extension process would be warranted for certain managed care plans to provide additional time for the plan to comply with the proposed requirement at 42 CFR 431.61(a) (which cross references at 42 CFR 438.242(b)(7)) for Medicaid managed care plans) and at proposed 42 CFR 457.731(a) (which cross references at 42 CFR 457.1223(d)) for CHIP managed care entities. While we are not proposing such a process for managed care plans and entities and do not believe one is necessary, we are open to evaluating options for possible future rulemaking. Were we to adopt an extension process for these managed care plans and entities, what criteria should a managed care plan or entity meet to qualify for an extension? Should the criteria include enrollment size, plan type, or certain unique characteristics that could hinder their achievement of the proposed requirements by the proposed compliance date? We also seek comment on whether, were we to propose such a process for Medicaid managed care plans or CHIP managed care entities, the entity responsible for evaluating the criteria and exception evaluation process should be the state and whether states could implement the exception evaluation process with available resources. Consistent with the exception process proposed for QHP issuers on the FFEs at 45 CFR 156.222(c), we would expect managed care plans seeking extensions to provide, at a minimum, a narrative justification describing the reasons why a plan or entity cannot reasonably satisfy the requirements by the proposed compliance date, an explanation of the impact of non-compliance upon enrollees, an explanation of the current or proposed means of providing electronic health information to providers, and a comprehensive plan with a timeline to achieve compliance.

We request comment on the proposed extension and exemption processes.

b. Exception for QHP Issuers

For QHP issuers on the FFEs, we propose an exception to the Provider Access API proposal at the regulation citations identified in Table 2. We propose that if an issuer applying for QHP certification to be offered through an FFE believes it cannot satisfy the proposed requirements at 45 CFR 156.222(a) for the Provider Access API, the issuer would have to include as part of its QHP application a narrative justification describing the reasons why the issuer could not 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, and solutions and a timeline to achieve compliance with the requirements of this section. We propose that the FFE may grant an exception to the requirements at 45 CFR 156.222(a) for the Provider Access API if it determines that making qualified health plans of such issuer available through such FFE 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 issuer to offer qualified health plans through the FFE. This proposal would be consistent with the exception for QHP issuers on the FFEs we finalized for the Patient Access API in the CMS Interoperability and Patient Access final rule (85 FR 25552). For instance, as noted in that final rule, that exception could apply to small issuers, financially vulnerable issuers, or new entrants to the FFEs that demonstrate that deploying FHIR API technology consistent with the required interoperability standards would pose a significant barrier to the issuer's ability to provide coverage to patients, and not certifying the issuer's QHP or QHPs would result in patients having few or no plan options in certain areas. We believe that having a QHP issuer offer QHPs through an FFE generally is in the best interest of patients and would not want patients to have to go without access to QHP coverage because the issuer is unable to implement this API.

In summary, we propose to permit certain impacted payers (state Medicaid and CHIP FFS programs and QHP issuers on the FFEs) to apply for an extension, exemption, or exception, as applicable, from implementing the proposed Provider Access API. We propose that these programs would submit and be granted approval for an extension or exemption as a part of applicable established processes. We propose that submission requirements would include certain documentation identified in the regulatory citations in Table 2.

5. Provider Access API in Medicaid and CHIP

a. Federal Funding for State Medicaid and CHIP Expenditures on Implementation of the Provider Access API

Should our proposals be finalized as proposed, states operating Medicaid and CHIP programs might be able to access Federal matching funds to support their implementation of the Provider Access API. This proposed API is expected to lead to more efficient administration of the Medicaid and CHIP state plans, consistent with sections 1902(a)(4) and 2101(a) of the Act.

We would not consider state expenditures for implementing this proposal to be attributable to any covered Medicaid item or service within the definition of “medical assistance.” Thus, in Medicaid, CMS would not match these expenditures at the state's regular Federal medical assistance percentage (FMAP). However, were this proposal to be finalized as proposed, Federal financial participation (FFP) under section 1903(a)(7) of the Act, at a rate of 50 percent, for the proper and efficient administration of the Medicaid state plan, might be available for state expenditures related to implementing this proposal for their Medicaid programs. We believe that using the Provider Access API would help the state more efficiently administer its Medicaid program, by ensuring that providers could access data that could improve their ability to render Medicaid services effectively, efficiently, appropriately, and in the best interest of the patient.

States' expenditures to implement these proposed requirements could also 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, or installation of mechanized claims processing and information retrieval systems. Additionally, 75 percent enhanced FFP under section 1903(a)(3)(B) of the Act might be available for state expenditures to operate Medicaid mechanized claims processing and information retrieval systems to comply with this proposed requirement.

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. States are reminded that 42 CFR 433.112(b)(12) and 433.116(c) in part require that any system for which they are receiving enhanced FFP under section 1903(a)(3)(A)(i) or (B) of the Act align with and incorporate the ONC's Health Information Technology standards adopted at 45 CFR part 170, subpart B. The Provider Access API would complement this requirement because the API would further interoperability by using standards adopted by ONC at 45 CFR 170.215. States are also reminded that 42 CFR 433.112(b)(10) and 433.116(c) 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.

Similarly, 42 CFR 433.112(b)(13) and 433.116(c) require states to promote sharing, leverage and re-use of Medicaid technologies and systems 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 can connect to the APIs proposed in this rule would be required as part of the technical requirements at 42 CFR 431.60(d) for all proposed APIs in this rule, including the Provider Access API.

Separately, for state 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, would apply to administrative claims for developing the APIs proposed in this rule.

We note that the temporary Medicaid FMAP increase available under section 6008 of the Families First Coronavirus Response Act (Pub. L. 116-127) does not apply to administrative expenditures.

b. Medicaid Expansion CHIP Program

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 are proposing at 42 CFR 457.700(c) that for states with Medicaid expansion CHIP programs, the proposals in this rule for Medicaid would apply to those programs rather than our proposals for separate CHIP programs. Functionally, our proposals are the same; however, for clarity, we are making explicit that the Medicaid requirements at §§ 431.60, 431.61, and 431.80 would apply to those programs rather than the separate CHIP requirements at §§ 457.730, 457.731, and 457.732.

6. Statutory Authorities for Provider Access API Proposals

a. MA Organizations

For MA organizations, we are proposing 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 proposed rule, these regulations implement this requirement. 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. This proposal aligns with, and provides a means for, MA organizations to comply with that existing regulatory requirement. Our proposal for MA organizations to implement and maintain a Provider Access API would 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 proposal, which would support sharing claims, all data classes and data elements included in a content standard adopted at 45 CFR 170.213, as well as prior authorization decisions (sections II.B.2. and II.B.3. of this proposed rule) and a requirement for MA organizations to offer provider educational resources (section II.B.3.d. of this proposed rule), would 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 could make more informed decisions and coordinate care more effectively. In addition, if a patient moves from one provider to another, the new provider would 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 proposal would carry out and be consistent with the Part C statute.

This proposal would 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 could support effective and continuous patient care. This API would help MA organizations share information with providers in an effective and efficient way that would help them fulfill program requirements. A Provider Access API could increase the efficiency and simplicity of administration. It could 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 proposals would also be 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 would 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 proposal that MA organizations make available educational resources and information would 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 proposed Provider Access API would be necessary and appropriate for the MA program and consistent with existing requirements.

b. Medicaid and CHIP

Our proposed requirements in this section for Medicaid managed care plans and Medicaid FFS programs 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.

These proposals are authorized under these provisions of the Act because they would help ensure that Medicaid providers can access data that could improve their ability to render Medicaid services effectively, efficiently, and appropriately. The proposals would be 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 uses or disclosures of information that are directly connected with the administration of the Medicaid state plan. The implementing regulations for this section of the Act list purposes that CMS has determined are directly connected to Medicaid state plan administration at 42 CFR 431.302 and provide safeguards states must apply to uses and disclosures of beneficiary data at 42 CFR 431.306. CHIP programs are subject to the same requirements through a cross reference at 42 CFR 457.1110(b). Our proposal to require that the data described in this section be shared via the Provider Access API would be consistent with the requirement that states may share these data only for purposes directly connected to the administration of the Medicaid state plan, since this data sharing would be related to providing services for beneficiaries, a purpose listed in § 431.302(c). As mentioned previously, a provider could better manage a patient's total care when they have access to more of that patient's data because the data would 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 proposals could be implemented in a manner consistent with state Medicaid and CHIP agencies' requirements under 42 CFR part 431, subpart F, are discussed in section II.B.2.

Proposing to require 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, could 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. This API would 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, would enable the provider to spend more time on direct care. The proposal would support efficient and prompt delivery of care as well, which would be in beneficiaries' best interests. These proposals would also be expected to give providers better access to prior authorization decisions for care provided by other enrolled Medicaid providers, which would give a provider a more holistic view of a patient's care and reduce the likelihood of ordering duplicate or misaligned services. This could also facilitate easier and more informed decision-making by the provider and would therefore support efficient coverage decisions in the best interest of patients. The proposed Provider Access API, if finalized as proposed, would be 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, thus enabling the provider to treat more patients. These outcome and process efficiencies could 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 managed care and FFS 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 are proposing 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 proposed policy could strengthen states' abilities to fulfill these statutory obligations under Title XXI of the Act in a way that would recognize and accommodate the use of electronic information exchange in the healthcare industry today and would facilitate a significant improvement in the delivery of quality healthcare to CHIP beneficiaries.

When providers have access to patient utilization and authorization information from payers or other health IT systems, they can 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 could 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 would not be based solely on patient recall. This could 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 proposals also align with section 2101(a) of the Act in that these proposals could improve coordination between CHIP and other health coverage. For these reasons, we believe this proposal is in the best interest of the beneficiaries and within our long-established statutory authorities.

Finally, the safeguards for applicant and beneficiary information at subpart F of 42 CFR part 431 are also applicable to CHIP through a cross-reference at 42 CFR 457.1110(b). As discussed above 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. QHP Issuers on the FFEs

For QHP issuers on the FFEs, we are proposing 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. We believe the benefits would outweigh any additional burdens this might impose on issuers. By using the proposed 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 would significantly increase because some of the infrastructure necessary to implement the proposed technology has been completed to comply with the May 2020 Interoperability 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 in the interests of enrollees. Giving providers access to their patients' information supplied by QHP issuers on the FFEs would ensure that providers are better positioned to provide enrollees with seamless and coordinated care and help 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 Data Exchange on FHIR

1. Background

Research shows that the more complete a patient's record is and the more data that can be available to healthcare providers at the point of care, the better patient outcomes can be. ⁵⁷ More data lead to better-coordinated care and more informed decision-making. Healthcare payers are uniquely positioned to collect and aggregate patient data because they typically maintain a relationship with individual patients over a period of time. Whereas patients may have several providers who manage their care, they generally maintain a relationship with only one or two concurrent payers in a 1-year period and often for multiple years. However, when a patient moves from one payer to another, patients and payers can lose access to that valuable data. Data exchange among payers, specifically, sending patient data from a patient's previous payer to their new payer, is a powerful way to ensure that data follow patients through the healthcare system. Electronic data exchange between payers would support payer operations and a patient's coverage transition to a new payer efficiently and accurately, and could support care coordination and continuity of care. Sharing healthcare data between payers also helps patients build a longitudinal record that can follow them across payers.

In the CMS Interoperability and Patient Access final rule (85 FR 25565), we highlighted numerous benefits for payers to maintain a longitudinal record (that is, long-term) 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 ensure that a patient's information follows them as they move from provider to provider and payer to payer. In the final rule we finalized a requirement that certain impacted payers would be required to exchange, at a minimum, all data classes and data elements included in a content standard adopted at 45 CFR 170.213 (85 FR 25568) at a patient's request. This policy applied to MA organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs. It did not include Medicaid or CHIP FFS programs. We did not specify an API standard for payer to payer data exchange in that final rule, because, at the time, there were a variety of transmission solutions that payers could employ to meet this requirement. We encouraged impacted payers to consider using a FHIR API consistent with the larger goal of leveraging FHIR APIs to support a number of interoperability use cases for improving patient, provider, and payer access to healthcare data to reduce burden, increase efficiency, and ultimately facilitate better patient care. In addition, we signaled our intent to consider a future requirement to use FHIR APIs for payer to payer data exchange, envisioning the increasing implementation of FHIR APIs for different purposes within the industry.

Since the CMS Interoperability and Patient Access final rule was finalized in May 2020, multiple impacted payers have expressed to CMS that the lack of technical specifications for the payer to payer data exchange requirement in the final rule (85 FR 25565) is creating challenges for implementation. This lack of a standard may lead to differences in implementation across the industry, poor data quality, operational challenges, and increased administrative burden. Differences in implementation approaches may create gaps in patient health information that conflict with the intended goal of interoperable payer to payer data exchange.

In the December 2020 CMS Interoperability proposed rule, we attempted to address these challenges by proposing the use of a FHIR API for the payer to payer data exchange. We also proposed to extend the Payer-to-Payer API policies to Medicaid and CHIP FFS programs. As stated in section I.A. of this proposed rule, we are withdrawing the December 2020 CMS Interoperability proposed rule and issuing this new proposed rule that incorporates the feedback we received from stakeholders, including this proposal to address the payer to payer data exchange. We refer readers to the discussion in section I.A. outlining the overarching differences between the two proposed rules.

Moreover, in order to respond to stakeholder concerns about implementing the payer to payer data exchange requirement finalized in the CMS Interoperability and Patient Access final rule, and noting that we did not finalize the proposals outlined in the December 2020 CMS Interoperability proposed rule, we published a Federal Register notification (86 FR 70412) announcing that we would exercise enforcement discretion and not enforce the payer to payer data exchange requirements until future rulemaking was finalized. We intend this rulemaking to address those concerns about the payer to payer data exchange policy finalized in the CMS Interoperability and Patient Access final rule and subject to the enforcement discretion.

In this proposed rule, we are again proposing to require 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 payer to payer data exchange using a FHIR API, but with changes from our proposals in the December 2020 CMS Interoperability proposed rule. We are again proposing that the data exchange take place via a FHIR API at the start of coverage, but we are now taking a different approach to the standards required for the API, as further described in section II.F. of this proposed rule. We are again proposing to establish a patient opt in policy for this data exchange for all impacted payers, for the reasons explained below. Furthermore, we propose to extend the compliance deadline for the Payer-to-Payer API to January 1, 2026.

We note that our payer to payer data exchange proposals discussed below involve transactions and cooperation between payers, which in many cases may include payers that would not be impacted by our proposals. We emphasize that under our proposals, each impacted payer would be responsible only for its own side of the transaction. For instance, if our proposal would require an impacted payer to request patient data from another payer, it would 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 proposed requirements, the impacted payer would be required to share those data, regardless of whether the requesting payer is an impacted payer (which, again, may or may not be evident). In this way, non-impacted payers who implement the Payer-to-Payer API and their patients would benefit from the data exchange proposed in this proposed rule.

In this section, we talk about data exchange between payers. When we refer to a patient's new payer, we are referring to 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 are referring to the parties (two or more) that are providing coverage at the same time and responsible for exchanging data with each other as discussed further below. When we refer to the patient's previous payer, we are referring to the payer that a patient has previously had coverage with and thus the payer responsible for sending the data to the new payer. However, as discussed further in section II.C.4.b., Medicaid and CHIP FFS state agencies as well as Medicaid and CHIP managed care plans within the same state are excluded from the definition of “previous payer” in relation to data exchange with each other.

We are exploring steps for Medicare FFS to participate in Payer-to-Payer API data exchange with all interested payers and we would encourage other payers that would not be impacted by these proposals, if finalized, to do the same. If our proposals are finalized, we intend to implement the Payer-to-Payer API capability for Medicare FFS in conformance with the requirements for impacted payers, as feasible. We seek comment on whether this could be implemented as proposed for the Medicare FFS program, how we could apply each of these proposals below and if there would be any differences for implementing the Payer-to-Payer API in the Medicare FFS program as a Federal payer. We strongly encourage all payers that would not be subject to the proposed requirements to consider the value of implementing a Payer-to-Payer API as described in this proposal, so that all patients, providers, and payers in the U.S. healthcare system may ultimately experience the benefits of such data exchange.

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

CMS strongly believes that data exchange among payers is a powerful way to help patients accumulate their data over time and 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. However, given the concerns raised by stakeholders regarding the lack of technical specification in our final policy, we are now proposing to rescind 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 doing 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. In the following sections, we are proposing a new policy that would, instead, require impacted payers to implement and maintain a Payer-to-Payer API using the FHIR standard, as described later in this section. We anticipate that the proposed use of FHIR APIs would ensure greater uniformity in implementation and ultimately lead to payers having more complete information available to share with patients and providers.

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 to implement, maintain, and use API technology conformant with 45 CFR 170.215 for the Patient Access API. However we did not require the use of an API or related standards for payer to payer data exchange.

We are now building on the technical standards, base content and vocabulary standards used for the Patient Access API, as finalized in the CMS Interoperability and Patient Access final rule (85 FR 25558), for this proposed Payer-to-Payer API. The degree of overlap between the requirements for the Patient Access API (discussed in section II.A.2. of this proposed rule) and the Provider Access API (discussed in section II.B.2. of this proposed rule) should ease the API development and implementation process for payers.

The Patient Access API would provide the foundation necessary to share all data classes and data elements included in a standard adopted at 45 CFR 170.213, adjudicated claims, and encounter data as well as the patient's prior authorization requests and decisions. Because the same data classes and elements included in the standards in 45 CFR 170.213 and adjudicated claims, and encounter data are 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. As a result, we believe 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 expanded interoperability use cases.

We are also proposing to require the use of certain IGs adopted under 45 CFR 170.215 that are applicable to the Payer-to-Payer API. This includes OpenID Connect Core at 45 CFR 170.215(b) for authorization and authentication. We are proposing that the Payer-to-Payer API must include the authorization and authentication protocols at 45 CFR 170.215(b) to authenticate the identity of the payer requesting access to data through the API. This would create a standardized and trusted method for payers to determine whether the payer who is requesting the data is whom they say they are. We refer readers to section II.F. of this proposed rule for further discussion of the required and recommended standards for the Payer-to-Payer API.

We note that when exchanging data with another payer through the Payer-to-Payer API, 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 would 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 resources and time for payers to send each patient's data individually through an API. The FHIR Bulk Data Access (Flat FHIR) IG for exchanging multiple patients' data at the same time has been adopted by ONC at 45 CFR 170.215(a)(4), which is discussed further in section II.F. of this proposed rule and is a proposed required standard for the Payer-to-Payer API.

In summary, we propose 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 compliant with the same technical standards, documentation requirements, and denial or discontinuation policies as our Patient Access API requirements. In addition, we propose that the API must be conformant with the standards at 45 CFR 170.215, including support for FHIR Bulk Data Access and OpenID Connect Core as further discussed in section II.F.

We are proposing these technical specification requirements for the Payer-to-Payer API for 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 identified in Table 3.

We request comments on these proposals.

b. Payer-to-Payer API Data Content Requirements

We are proposing to require that impacted payers implement and maintain a FHIR Payer-to-Payer API to exchange all data classes and data elements included in a content standard adopted at 45 CFR 170.213, claims and encounter data (excluding provider remittances and enrollee cost-sharing information), and prior authorization requests and decisions that the payer maintains with a date of service on or after January 1, 2016.

The data we are proposing to include in the API would be consistent with the proposals discussed in sections II.A. (Patient Access API) and II.B. (Provider Access API) of this proposed rule, which would require impacted payers to share the same types of data with patients and providers via those respective FHIR APIs. We also note that much of the data included in this proposal, except for provider remittances, enrollee cost-sharing information and prior authorizations, as discussed below, would also be consistent with the requirements for the Patient Access API finalized in the CMS Interoperability and Patient Access final rule (85 FR 25559). That final rule requires that impacted payers make data available from a date of service of January 1, 2016. Therefore, payers should already be maintaining and making available patient data back to that date. Using the same data content standards across the APIs in this proposed rule would add efficiencies for payers and maximize the value of the work being done to implement APIs, reducing the overall burden for all impacted payers.

We are proposing to exclude provider remittances and enrollee cost-sharing information from Payer-to-Payer API data exchange because that information is often considered proprietary by payers. Therefore, we are not proposing to require payers to exchange those data with each other. While there could be value to patients in having provider remittances and enrollee cost-sharing information available via the Patient Access API, we believe that sharing provider remittances and enrollee cost-sharing information between payers would have only a limited beneficial impact on care. We believe that sharing claims and encounter information without the cost details would complement the data classes and data elements included in a content standard adopted at 45 CFR 170.213, by providing more information about the patient's care history to support care coordination and efficient operation.

When we refer to prior authorizations in the context of payer to payer data exchange, we propose that this would include any pending, active, denied, and expired prior authorization requests or decisions. We refer readers to section II.A. of this proposed rule where prior authorization data content for the APIs in this proposed rule is discussed in further detail. Our proposals in this section for the inclusion of prior authorization data mirror our proposals for prior authorization data in the Patient Access API and Provider Access API. We believe that it would be valuable for payers to make information about prior authorization requests and decisions available via the Payer-to-Payer API, particularly when a patient enrolls with a new payer. Prior authorization is a significant focus of this proposed rule, and information about these requests and decisions could be beneficial to patients, providers, and payers. As noted throughout, this proposed rule does not apply to any prior authorization processes or standards related to any drugs.

Currently, when a patient changes payers, information about prior authorization decisions the previous payer made or was in the process of making, about the patient's ongoing care is inconsistently sent to the new payer. While some payers will make this information available to the new payer upon request, most new payers do not request such information. Instead, most payers with a newly enrolled patient require the treating provider to request a new prior authorization, even for items or services for which a patient had a valid and current prior authorization approval under the previous payer. When this happens, the burden of repeating the prior authorization process with the new payer falls on the provider and patient, which can impede the continuity of care or delay patient care, impacting patient outcomes and complicating care coordination. In addition, it adds burden for payers, who must expend time and effort to review a potentially unnecessary and duplicative prior authorization request.

We discuss prior authorization and our proposals regarding prior authorization processes in more depth in section II.D. of this proposed rule. As part of this Payer-to-Payer API proposal, consistent with the proposals for the Patient Access API in section II.A. and the Provider Access API in section II.B. of this proposed rule, we propose to add prior authorization requests and decisions and related administrative and clinical documentation to the set of data that impacted payers must make available via the Payer-to-Payer API. We propose that this documentation would include the status of the prior authorization, the date the prior authorization was approved or denied, the date or circumstance under which the authorization ends, the items and services approved, and the quantity used to date. Furthermore, as outlined in section II.D., we propose that the specific reason why the request was denied should also be included in the case of a prior authorization denial.

We propose that impacted payers would be required to make 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 note that we are formulating our proposal for at least 1 year after any status change, but 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.

While CMS is not proposing at this time to require payers to review, consider, or honor the active prior authorization decision of a patient's former payer, CMS believes payers may gain efficiencies by doing so. In this section, we seek comment on some of the considerations around sharing prior authorization data between payers. Under our payer to payer data exchange proposal, prior authorization information would be included as part of the patient's longitudinal record received from the previous payer. The prior authorization information would thus be available for consideration as part of the patient's historical record. Should a payer consult this information, even to make a prior authorization decision under its own rules, it could, over time, reduce payer, provider, and patient burden, and possibly healthcare costs.

We understand that there is potential for a gap in prior authorization for ongoing services when changing payers, which can be challenging for patients. If a new payer consults the previous payer's prior authorization information, it could mean that the provider might not need to send a new, duplicative request to the new payer and that the new payer might not need to process that new request. Patients might not have to wait for a new prior authorization for an item or service that a provider and previous payer had already determined the patient needs. This could be particularly helpful for patients with chronic conditions and individuals with disabilities, social risk factors, and limited English proficiency who are changing payers. If a new payer reviews and considers the prior authorization decisions of a patient's previous payer, based on information the previous payer already had from the patient's providers, that might reduce delays in care and improve continuity of care. Therefore, we believe that sharing this information between payers could have a significant and positive impact on payers, providers, and patients. We are also interested in comments about whether the continuation of a prior authorization or additional data exchange could be particularly beneficial to patients with specific medical conditions.

We understand that payers may use different criteria to make prior authorization decisions. The new payer may not have insight into the criteria used by the previous payer, which could understandably make it challenging for the new payer to accept the previous payer's decision. With that in mind, we request comments for possible future rulemaking on whether prior authorizations from a previous payer should be honored by the new payer, and if so, should the prior authorizations be limited to a certain period of time based on the type of prior authorization or patient's medical condition? If so, what should that timeframe be? Should prior authorization from a previous payer be honored in certain instances regarding specific medical conditions? If so, which conditions and for what timeframe?

In summary, we propose 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 FHIR Payer-to-Payer API to make available all data classes and data elements included in a content standard adopted at 45 CFR 170.213, claims and encounter data (excluding provider remittances and enrollee cost-sharing information), and prior authorization requests and decisions (and related administrative and clinical documentation) that the payer maintains with a date of service on or after January 1, 2016.

We propose that this would include the status of the prior authorization, the date the prior authorization was approved or denied, the date or circumstance under which the prior authorization ends, the items and services approved, and the quantity used to date. If this information includes prior authorization decisions that are denied, we propose that impacted payers must include specific information about why the denial was made. We propose that impacted payers would be required to make 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 are proposing these Payer-to-Payer API data content requirements for 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 identified in Table 3.

We request comment on these proposals.

c. Identifying Previous and Concurrent Payers and Opt In

We propose that all impacted payers must develop and maintain processes to identify a patient's previous and/or concurrent payer(s) and to allow patients or their personal representatives to opt into payer to payer data exchange (both with previous and concurrent payers) prior to the start of coverage. Payers would also need similar processes for current enrollees who are continuing enrollment with their same payer to ensure those patients have the ability to opt in prior to the data being shared through the API.

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.

We use the term “start of coverage” in this section to mean when coverage begins or when the patient enrolls and benefits become effective. We note that in some cases a payer may provide coverage retroactively; that is, a payer that provides coverage starting on a date prior to enrollment (as happens in Medicaid, for example). In that case, the payer would be required to have processes to collect permission for Payer-to-Payer API data exchange and to identify a new patient's previous and/or concurrent payer(s) prior to the date the patient's enrollment is processed. In Medicaid, this would be the date the beneficiary is enrolled in the state's MMIS (or equivalent process), not the date coverage takes retroactive effect.

We emphasize that obtaining a patient's opt in permission and identifying the previous and/or concurrent payer(s) cannot delay an applicant's eligibility determination or start of coverage with any impacted payer. We note that the proposed requirement to identify a patient's previous and/or concurrent payer(s) and obtain a patient's opt in permission will 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 emphasize that payers must begin this process before the start of coverage, but 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 and/or 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 below. Using Medicaid as an example, if a state has all of 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 proposed Payer-to-Payer API requirements outlined here as expeditiously as possible post-enrollment.

We propose that payers would be required to gather information about the patient's previous and/or concurrent payer(s) that would allow them to identify and request data from those payers. This could include the payer's name and a patient ID number or similar identifier. An impacted payer would be required to allow a patient to report multiple previous and/or concurrent payers if they had (or continue to have) concurrent coverage. If that is the case, under our proposals, impacted payers would be required to request the patient's data from all previous and/or concurrent payers. We are not being prescriptive in these proposals regarding specific information to be gathered from patients, as we believe that this requirement can be implemented in multiple ways. However, we expect that payers would only collect as much information as necessary to identify the previous and/or concurrent payer(s) and make a successful request in accordance with our proposals, if finalized. For instance, we do not believe specific plan information (as opposed to the payer organization name) or dates of coverage would be necessary to effectuate our proposals. We believe that requesting additional information from patients beyond that which is necessary would impose barriers on patients' ability to take advantage of our proposed policies because they may not have that information readily available.

We request comments on which data elements would be necessary or extraneous to make that Payer-to-Payer API request.

Patients enrolled in ongoing coverage on the compliance date with an impacted payer should be given the same opportunity to have their data shared with their current, ongoing payer by previous and/or concurrent payers. To do so, impacted payers would have to give currently-enrolled patients notice and the opportunity to provide their previous and/or concurrent payer(s) information, as well as to opt in to the proposed payer to payer data exchange. Therefore, we are proposing that no later than the compliance date for the Payer-to-Payer API, impacted payers must establish and maintain a process to gather permission and identify previous and/or 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 proposed compliance date. We want to allow that option and therefore are tying our proposal to require payers to gather permission from currently-enrolled patients to the proposed compliance date, 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), rather than when a payer implements their API. That 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 in to payer to payer data exchange by that compliance date.

For new patients enrolling on or after the compliance date, we are proposing to require impacted payers to maintain a process for patients to opt in to the Payer-to-Payer API data exchange and to identify their previous and/or concurrent payer(s) prior to the start of their coverage. Below, in section II.C.4.b., we discuss the possible incorporation of these proposed requirements into state applications for Medicaid or CHIP eligibility. 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 FFE, this process should be done immediately following enrollment. We solicit comment on incorporation of the proposed requirements into the FFE QHP enrollment process as described at 45 CFR 156.265. In addition, we propose to require impacted payers to have a process for patients to opt in to this data exchange at any time after the start of coverage, or if they have already opted in, to opt out, at any time.

We are proposing an opt in approach for the data exchange through the Payer-to-Payer API for the reasons discussed below, even though, as discussed in section II.B.3.b. of this proposed rule, we believe that an opt out approach to patient data exchange generally would promote the positive impacts of data sharing to support care coordination and improved health outcomes, which could lead to greater health equity. Furthermore, systems with opt in patient permission requirements are more likely to report regulatory barriers to data exchange compared to those without. However, for a variety of legal and operational reasons, we are proposing an opt in permission policy for our payer to payer data exchange proposal. An opt in framework means that the patient or their personal representative would need to affirmatively permit the payer to share data within the proposed Payer-to-Payer API framework discussed in this section, and without that permission, the payer may not engage in the payer to payer data exchange for that patient. We note that this permission (or lack thereof) would only apply to the data exchange proposals discussed here and not to any other obligations under HIPAA or other law.

Certain operational considerations support an opt in framework for this API. As discussed, to request a patient's data from their previous and/or concurrent payer(s), a new payer must identify those payers by gathering information from the patient. While there may be other ways for payers to collect this information, we believe that patients themselves are the best source for sufficient and accurate information necessary for the payer to make the request. Patients would not be required to provide this information. However, should they choose to, providing this information would require an affirmative act from the patient, so we believe that the burden of asking a patient to opt in would not create a significant additional barrier to patient participation.

In contrast, our proposed policy for the Provider Access API would allow payers to exchange patient data with providers unless a patient has opted out. We are proposing 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 proposals to require the Provider Access API data exchange only 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. In contrast, two payers exchanging information do not have a direct relationship but would be exchanging data based on a patient's separate relationship with each payer. Therefore, it may make sense for the patient to have a larger gatekeeping role within this proposed policy.

Furthermore, specific statutory and regulatory requirements applicable to state Medicaid and CHIP programs would prevent those programs from establishing an opt out process, or from sharing information with other payers on the basis of a patient's failure to opt out of the other payer's data exchange. Specifically, 42 CFR 431.306(d), a regulation implementing section 1902(a)(7) of the Act, prohibits Medicaid programs from sharing beneficiary information with outside sources before obtaining permission to do so from the individual or family, with limited exceptions. This regulation also applies to CHIP programs under 42 CFR 457.1110(b). This regulation does not conflict with the proposed opt out policy for the Provider Access API because Medicaid and CHIP enrolled providers are not outside sources. However, other payers would typically be outside sources and thus, the regulation would apply to the data shared through the Payer-to-Payer API. For further discussion of data exchange between state Medicaid or CHIP agencies and managed care entities, see section II.C.4.b. below.

Additionally, we are proposing that the requesting payer would obtain the permission of the patient for this data exchange, not a Medicaid or CHIP program that would be sharing the data. Accordingly, the payer requesting the data would also need to follow the permission requirements applicable to Medicaid and CHIP programs so that the Medicaid and CHIP programs could share information through this API in a manner that is consistent with 42 CFR 431.306(d). Rather than creating different permission rules for different payers, which would add significant complexity to the payer to payer data exchange process, especially for Medicaid and CHIP programs, it may be preferable for all impacted payers to use an opt in process.

We request comments on our proposal for an opt in process for gathering patients' permission for payer to payer data exchange. Is there any way, such as through any regulatory changes that we should consider, either in this rulemaking or in the future, that would instead allow for an opt out process while protecting patient privacy in accordance with the considerations above? Are there any policy approaches or technical requirements that could provide all impacted payers with the assurance that they have gathered appropriate permission from patients within the statutory and regulatory framework outlined here? Are there any barriers to interoperability with an opt in approach for patient data exchange for all impacted payers that we are not considering?

We emphasize that all data maintained, used, shared, or received via this proposed Payer-to-Payer API must be maintained, used, shared, or received in a way that is consistent with all applicable laws and regulations. For example, the HIPAA Privacy Rule does not require a covered entity, such as a health plan, to obtain authorization from the enrolled individual or provide an opportunity for the individual to agree or object, in order to share PHI under 45 CFR 164.512(a)(1) if the disclosure is “required by law” as defined at 45 CFR 164.103. Our proposed requirements, if finalized, would be set forth in a regulation that requires information sharing and therefore would allow for disclosure under that HIPAA provision, without authorization. For Medicaid, as noted above, section 1902(a)(7) of the Social Security Act, and implementing regulations at 42 CFR part 431 govern the requirements for the use and disclosure of applicant and beneficiary information, and are discussed in more detail in section II.C.3.c.1 and in this section. Other laws, such as state privacy laws, may require the payer to obtain the enrolled individual's consent before disclosing certain information. We emphasize that our proposals are not intended to change any existing obligations under HIPAA, the regulations under 42 CFR part 2, or state privacy or other laws, but could and should be implemented in accordance with those rules if this proposed rule is finalized as proposed. We request comment on any considerations regarding state privacy or other laws that our proposals may implicate.

In summary, we propose 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 maintain a process to identify a new patient's previous and/or concurrent payer(s) to facilitate data exchange using the Payer-to-Payer API. As part of this process, impacted payers would be required to allow a patient to report multiple previous and/or concurrent payers if they had (or continue to have) concurrent coverage. If a patient does report multiple previous payers, impacted payers would be required to request that patient's data from all previous and/or concurrent payers.

Furthermore we propose that, prior to the start of coverage, impacted payers must establish and maintain a process to gather patient permission for payer to payer data exchange, as described in this section. That permission process would have to use an opt in framework whereby a patient or personal representative must affirmatively agree to allow that data exchange. In addition, we propose that impacted payers must 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 opt back out, at any time.

Finally, we propose to require impacted payers to establish and maintain a process to gather permission and previous and/or concurrent payer(s) information from patients who are currently enrolled on the Payer-to-Payer API compliance date. For new patients enrolling on or after that date, we are proposing to require impacted payers to maintain a process for patients to provide previous payer information and opt in to the Payer-to-Payer API data exchange prior to the start of coverage.

We are proposing the permission and previous and/or concurrent payer identification requirements for the Payer-to-Payer API for MA organizations, state Medicaid and CHIP agencies, and QHP issuers on the FFEs at the CFR sections identified in Table 3.

We request comment on these proposals.

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

We are proposing to require impacted payers to request a patient's data from their previous and/or concurrent payer(s) no later than 1 week after the start of coverage. We believe 1 week is sufficient time to allow payers to complete their process for identifying patients' previous and/or concurrent coverage and to initiate this request for data from the other payer(s). If after the start of coverage a patient opts in to the data exchange or provides previous and/or concurrent payer information, or requests data exchange for another reason, we propose that the current payer would be required to request data from the previous and/or concurrent payer(s) no later than 1 week after the payer has the necessary permission and information, or the patient makes the request. We acknowledge that the obligation is contingent on the patient supplying the necessary information about a previous and/or 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 and/or concurrent payer. This applies throughout the proposals in this section of the proposed rule.

Other than in the context of concurrent payers, we generally expect our proposal to be a one-time data exchange between a previous and new payer. Once the new payer has received the patient's data, we do not expect there to be additional information added to the patient record from the previous payer. However, we want to allow patients to request subsequent data exchange to account for any outlier situations. We are also aware that claims take time to process and may be processed after patients have transitioned to a new payer, thus creating additional data within the patient's record for some time period after the patient has transitioned payers. We considered proposing a policy where, if the patient permits, previous payers would be required to send any additional data within the required dataset to the new payer within 1 week of receiving additional data. However, keeping in mind the frequency and burden this could impose on payers, we seek comment on whether such a policy would be beneficial or overly burdensome. Would additional data be helpful for the new payer for weeks or months after enrollment? Would specific data be more pertinent than others? Would it lead to overly burdensome data exchanges that would not provide value to the new payer? We also considered whether it would be appropriate to limit that requirement to a certain period after the initial data exchange for instance within 30 or 90 days. Additionally, we considered whether to propose that impacted payers must make that data exchange within a week of receiving any data updates or whether they should only be required to on a set schedule, such as monthly or quarterly, to allow payers to streamline transactions for multiple patients. We seek comment on whether any additional data exchange would be warranted to account for data received by the previous payer after the patient's coverage ends and, if so, what the appropriate parameters would be.

We propose that impacted payers would be required to use the OpenID Connect authorization and authentication protocols at 45 CFR 170.215(b) to authenticate the identity of the requesting payer. Like our proposal for the Provider Access API, discussed in section II.B.2., to protect patient data, we want to ensure payers do not send data unless they are confident that the requesting payer is who it says it is. Because these are the same authorization and authentication protocols that are proposed for Patient Access and Provider Access APIs, we believe that payers are already familiar with this requirement for implementation.

To assure the payer receiving the request, we propose to require the requesting payer to include an attestation with the request for data affirming that the patient has enrolled with the requesting payer and has opted in to the data exchange in a manner that meets the necessary legal requirements. As explained in section II.F., we recommend the use of certain HL7 implementation guides to support the exchange of data between impacted payers for the Payer-to-Payer API. The HL7 PDex IG has been developed to ensure that both the technical and business processes of capturing and sharing a patient's permission for data exchange preferences are included in the payer to payer data request. Therefore, using the PDex IG would meet the requirements of this proposal. Because that IG is recommended and not required, impacted payers could also exchange an attestation regarding patient permission with other implementations that meet or exceed the requirements of the PDex IG.

We propose that the previous and/or concurrent payer, if an impacted payer, would be required to respond to a current payer's request, if it meets the requirements, within 1 business day of receipt. We believe 1 business day is the appropriate timeframe to complete this process to send the data, as payers need timely access to previous and/or concurrent payer data to facilitate care coordination and create a longitudinal record that could be helpful to the patient should they wish to access their information for care planning with any new provider(s) they may see. We note that this timeframe also would align with the 1 business day response time for the Patient Access API and proposed Provider Access API.

We seek comment on whether the proposed timeframes for a new payer to request patient data, and for the previous and/or concurrent payer to send these data, are appropriate or whether other timeframes would better balance the benefits and burdens. We seek comment on whether payers could accommodate a shorter period for the data request at the start of coverage, such as 1 to 3 business days, and whether payers need more than 1 business day to respond to a request. If so, what is a more appropriate timeframe for payers to respond to data requests? We believe it is important for patient data to move to the new payer as soon as possible to compile a longitudinal record, as well as obtain information on active prior authorizations.

We note that if a previous and/or concurrent payer is not an impacted payer, they would not be subject to our proposed requirements and, therefore would not be required to send data through the Payer-to-Payer API under this proposal. For example, when a patient moves from a QHP on an FFE to an employer-based plan, the employer-based plan would not be impacted by this rulemaking. The new impacted payer would not be obligated to determine whether the previous payer is an impacted payer under this proposed rule. Therefore, an impacted new payer would be required to request the data from the patient's previous and/or concurrent payer, regardless of whether the other payer is an impacted payer or not. If the previous and/or concurrent payer is not an impacted payer, they would not be subject to our proposed requirements to respond to the request. Conversely, we propose that if an impacted payer receives an appropriate request for patient data under this proposal, they would be required to respond by sending all required data under this proposal, regardless of whether the requesting payer is or is not an impacted payer (which they payer may or may not know).

In summary, we propose 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 request the appropriate data, as described earlier in this section, from any previous and/or concurrent payers through the Payer-to-Payer API, provided that the patient has permitted the data exchange as proposed in section II.C.3.c. We propose that impacted payers would be required to include an attestation with the request for data affirming that the patient has enrolled with that requesting payer and has opted in to the data exchange. We propose that impacted payers must request these data from any previous payer(s) no later than 1 week after the start of coverage or after a patient's request. If a patient who did not opt in or provide previous payer information subsequently opts in to the payer to payer data exchange and shares that previous payer information, we are proposing that the impacted payer would be required to request the patient's data from the patient's previous payer no later than 1 week after the patient opts in or provides that information.

We propose that if an impacted payer receives a request from another payer to make data available for former patients who have enrolled with the new payer or a current patient who has concurrent coverage, the impacted payer must respond by making the required data available via the Payer-to-Payer API within 1 business day of receiving the request if the requesting payer has been authenticated according to the requirements of 45 CFR 170.215(b), demonstrated that the patient has permitted the data exchange through an opt in process with the requesting payer, and disclosure of the data is not prohibited by law.

We are proposing these payer to payer data exchange timeframe requirements for MA organizations, state Medicaid and CHIP FFS agencies, and QHP issuers on the FFEs at the CFR sections identified in Table 3.

We request comment on these proposals.

e. Data Exchange Requirements for Concurrent Coverage

For individuals who have concurrent coverage with multiple payers, we propose to require impacted payers to collect 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 above). Because we believe it would be beneficial for all of a patient's current payers to maintain a longitudinal record of the care that the patient has received from all payers, we propose to require impacted payers to request the same patient data described in section II.C.3.b. from all of a patient's concurrent payers, and to send that data in response to an appropriate request. This would ensure that all of the patient's concurrent payers maintain a complete patient record and can provide all the information proposed to be required under the Patient Access API and Provider Access API.

Specifically, we are proposing to require impacted payers, within 1 week of the start of a patient's coverage, to exchange data with any concurrent payers that the patient reports. Additionally, we propose that should an impacted payer receive a request for a current patient's data from a known concurrent payer for that patient, the receiving payer must 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.

Because all payers will update patient records during the period when a patient is enrolled with those payers, we propose that when a patient has concurrent coverage with two or more payers, the impacted payers must exchange the patient's data available to every other concurrent payer at least quarterly. This proposal would create requirements for impacted payers to both request patients' data from other concurrent payers and to respond to requests from other payers to share patients' data.

Some patients may be concurrently enrolled with payers that would not be subject to our proposed requirements because they are not impacted payers. As discussed above, if a non-impacted concurrent payer does not have the capability or refuses to exchange the required data with an impacted concurrent payer through a FHIR API, the impacted payer is not required to exchange data with that non-impacted payer under this proposal and would not be required to continue to request data exchange quarterly. However, we encourage all payers to implement a Payer-to-Payer API to support data exchange with concurrent payers, even if they are not subject to our proposed requirements. We expect that this data exchange among concurrent payers would support better care coordination and more efficient operations. If a non-impacted payer requests data in conformance with the proposed requirements of this section via an API that meets the requirements proposed for the Payer-to-Payer API, an impacted payer would be required to respond, as if the requesting payer were subject to the rule. As explained above, impacted payers would not need to spend resources determining whether other payers are impacted by these proposals, but would be required to request patient data and respond to all requests that are made within the requirements of this proposed rule.

We also considered whether to propose more frequent exchange (weekly or monthly), or less frequent exchange (semi-annually or annually); however, we believe a quarterly data exchange would strike the right balance between providing accurate, timely data and payer burden. CMS believes sharing data quarterly would be frequent enough to allow time for new health data to accumulate and still be timely, but not so frequently that it causes unnecessary burden on the payers required to provide the information. We request comment on this proposal, including on the appropriate frequency for this payer to payer exchange for patients with concurrent coverage.

We note that when a patient has concurrent coverage, the payers must often communicate regularly to ensure that the proper payer is responsible for that patient's claims. Nothing in this proposed rule, including a patient not opting in to 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.

In summary, we propose 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 would be required, within 1 week of the start of a new patient's coverage, to request initial data exchange from any concurrent payers that the patient reports, and thereafter to request data exchange with those payers no less frequently than once per calendar quarter. We propose that should an impacted payer receive a request for a current patient's data from that patient's concurrent payer, the receiving payer must respond with the appropriate data within 1 business day of receiving the request. Impacted payers would be required to exchange the same data proposed in section II.C.3.b.

We are proposing these requirements for concurrent coverage data exchange for 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 identified in Table 3.

We request comment on these proposals.

f. Data Incorporation and Maintenance

We propose that information received by an impacted payer through this data exchange must be incorporated into the patient's record with the new payer. Those data would 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 API, Provider Access API and Payer-to-Payer API, if our proposals are finalized as proposed. In this way, a patient's cumulative record would follow them between payers and be available to them and their providers. While this proposal would not obligate payers to review, utilize, update, validate, or correct data received from another payer, we encourage impacted payers to do so, at least to the extent doing so might benefit the patient's ongoing care. As previously explained in the CMS Interoperability and Patient Access final rule for the payer to payer data exchange (85 FR 25568), payers could choose to indicate which data were received from a previous payer so a future receiving payer, provider, or even the patient, would know where to direct questions (such as how to address contradictory or inaccurate information), but would not be required to do so under this proposal. Regardless, all data maintained, used, shared, or received via the proposed Payer-to-Payer API would be required to be maintained, used, shared, or received in a way that is consistent with all applicable laws and regulations.

We note that our proposals would not impact any payer's data retention requirements. Specifically, we are not proposing 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 non-impacted payer that does not request information from the previous payer, after a period of time, the old payer may discard information, which would make it unavailable to the patient or other payers in the future.

However, we believe 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 believe that most payers have policies in place that would maintain patient data for at least that long, and thus, such a requirement is unnecessary and burdensome. We request comment on whether our understanding is correct and whether there is a benefit to us considering a data retention requirement in the future.

In summary, we propose 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), any information received by an impacted payer through this data exchange must be incorporated into the patient's record with the new payer.

We are proposing this requirement regarding data incorporation for 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 identified in Table 3.

g. Patient Education Requirements

Consistent with our proposals for the Provider Access API, impacted payers would be required to provide patients with educational materials in non-technical, simple, and easy-to-understand language, explaining at a minimum: the benefits of Payer-to-Payer API data exchange, their ability to opt in or withdraw a previous opt in decision, and instructions for doing so. Impacted payers would be required to provide these educational materials to patients at or before requesting permission for the Payer-to-Payer API data exchange. As discussed above, currently enrolled patients must be given the opportunity to opt in to payer to payer data exchange and to provide previous and/or concurrent payer information before the API compliance date. Our proposal would require impacted payers to provide these educational materials to those currently enrolled patients at or before requesting their opt in as well. In addition, similar materials would have to be provided annually to all covered patients in mechanisms that the payer regularly uses to communicate with patients. This information would also be required to be provided in an easily accessible location on the payer's public website. We request comment on whether it would reduce payers' burden to only be required to provide these materials annually to any patients who have not opted in and those with known concurrent payers.

We propose that impacted payers would have to provide educational materials regarding the payer to payer data exchange to all patients at or before requesting opt in and at least annually 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).

We are proposing these patient education requirements for 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 identified in Table 3.

4. Payer to Payer Data Exchange in Medicaid and CHIP

a. Inclusion of Medicaid and CHIP FFS

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). State Medicaid and CHIP FFS programs can face unique circumstances that might make it more challenging for them to meet new requirements within the same timeframe as other payers because of state budget cycles and other funding constraints, possible state legislation or regulatory requirements, contracting timeframes, required systems upgrades, and recruiting necessary staff resources. As a result, in our first phase of interoperability policies in the CMS Interoperability and Patient Access final rule (85 FR 25524), we chose to limit the burden on these programs so they could focus their attention and resources on implementing the Patient Access and Provider Directory APIs and did not make the Payer-to-Payer API policies in that rule applicable to state Medicaid and CHIP FFS programs. However, in August 2020, CMS released a letter to state health officials in which we encouraged state Medicaid and CHIP FFS programs to accommodate payer to payer data exchange requests from beneficiaries.

We are now proposing to make the proposed payer to payer data exchange policies in this proposed rule applicable to state Medicaid and CHIP FFS programs. We believe that proposing to require Medicaid and CHIP FFS programs to implement the Payer-to-Payer API data exchange policies in this proposed rule would not be as burdensome as proposing to require them to follow the non-API-based payer to payer data exchange policies that were finalized in the CMS Interoperability and Patient Access final rule (85 FR 25524) and that we are proposing to withdraw in this proposed rule. 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 their Patient Access APIs and should thus be able to leverage the work done for that API to make implementing this newly proposed API more manageable.

For state Medicaid and CHIP FFS programs, the state agency is the impacted payer that would share patient data with other impacted payers. As we discuss in more detail in section II.C.3.a. of this proposed rule, using the Payer-to-Payer API could create efficiencies for state Medicaid and CHIP programs, thereby reducing burden for these programs, and potentially leading to better coordinated patient care and improved health outcomes. We expect the proposed Payer-to-Payer API requirement to lead to more effective administration of the state plan, and to better enable Medicaid and CHIP programs to ensure care and services are provided in a manner that is consistent with their beneficiaries' best interests. Ensuring that patient data can follow Medicaid and CHIP beneficiaries as they enter these programs could potentially lead to better care coordination and continuity of care for these patients. It could also reduce burden for patients and providers. The Medicaid and CHIP FFS programs would have additional information from other payers to share via the Patient Access API and the Provider Access API. As a result, Medicaid and CHIP beneficiaries would have more readily available information to support informed decision-making, and Medicaid and CHIP providers would have more information about the care their patients are receiving. This could potentially lead to fewer duplicate tests or less time taken collecting and recollecting information about the patient during a visit. Any effort a state Medicaid or CHIP FFS program takes to evaluate the data from a patient's previous or concurrent payers could potentially allow the program to avoid wasteful, unnecessary, or duplicative action. In this way, extending this Payer-to-Payer API to state Medicaid and CHIP FFS programs could benefit these programs by helping them to operate more efficiently.

If this proposal is finalized to include state Medicaid and CHIP FFS programs, patients would continue to have access to their health information, creating a longitudinal record, as they move into and out of Medicaid or CHIP FFS. A broader range of information about patients' past care might also be able to follow them to new providers if payers have greater access to data from other payers and can make it available through the Patient Access and Provider Access APIs proposed in this proposed rule.

b. Permission and Exchange Considerations Specific to Medicaid and CHIP FFS, Medicaid Managed Care Plans, and CHIP Managed Care Entities

We know that state Medicaid or CHIP agencies regularly exchange data with their managed care plans. This Payer-to-Payer API proposal would not affect the Medicaid and CHIP programs' ability to share data as they do today. Specifically, Medicaid agencies and their contracted managed care plans may, and in some cases are required to, exchange beneficiary information with each other, as part of the operation of the Medicaid program, subject to any other applicable law. Similarly, CHIP agencies and their contracted managed care entities may exchange beneficiary data, as part of the operation of the CHIP program, subject to any other applicable law. This allows effective transitions for beneficiaries who move between managed care plans or entities or between FFS and managed care delivery/coverage systems within the same state's Medicaid or CHIP programs, and promotes the coordination and continuity of care within those programs—the very coordination that our proposals are intended to enable.

As mentioned above, Medicaid managed care plans and CHIP managed care entities are not outside sources, but are part of a state's Medicaid and/or CHIP programs as a whole. Therefore, we do not wish to impose a policy that would require an opt in for patients for state Medicaid and CHIP agencies and their managed care entities to exchange information, as they may do today. Current consent rules and requirements for exchange within a state's Medicaid and CHIP programs (such as between a managed care plan and the state Medicaid or CHIP agency or between two managed care plans contracted with the state Medicaid or CHIP agency), are not affected by our proposals. There is no requirement for a state Medicaid or CHIP agency to obtain an opt in from an individual or family member prior to providing information about a Medicaid or CHIP beneficiary to its own providers or plans, as such entities would not be an outside source as described at 42 CFR 431.306(d) (and as discussed in section II.B., related to our Provider Access API proposals). We do not intend any of our proposals to interfere with or affect this permissible information exchange. Hence, we are proposing 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. The other proposed payer to payer requirements, such as the requirement to use a FHIR API and the authorization and authentication protocols would apply. The exchange must also not be prohibited by law.

We welcome comments, specifically from states and contracted managed care entities, as to how we can establish standards for patient data exchange between state Medicaid and CHIP agencies and their contracted managed care entities without creating additional barriers or burden.

We are proposing that Medicaid and CHIP agencies, like all impacted payers, implement a process to allow currently enrolled beneficiaries a chance to opt in to payer to payer data exchange prior to the State Medicaid or CHIP agency's Payer-to-Payer API compliance date, and prior to the enrollment of new beneficiaries after that date. The opportunity for newly enrolling patients to opt in could take place through the application, or at some later point of contact with the beneficiary prior to the start of coverage, but in no instance would our proposals permit a delay in the enrollment process or a beneficiary's coverage. As discussed above, 42 CFR 431.306 lists certain requirements for sharing beneficiary data. We note that when an individual's Medicaid or CHIP enrollment has ended and another payer is requesting a former Medicaid beneficiary's information, receiving an attestation from a requesting payer that the patient has opted in to data exchange with the requesting payer, consistent with our proposals for all payers, is a permissible way for the state Medicaid or CHIP agency to obtain permission as required under 42 CFR 431.306(d). We are proposing these requirements at the CFR citations in Table 3.

States are also reminded that access to information concerning beneficiaries must be restricted to persons and agencies who are subject to standards of confidentiality that are comparable to that of the Medicaid agency, in accordance with 42 CFR 431.306(b). We do not believe that any of the other requirements of 42 CFR 431.306 are relevant because they cover data release and use in contexts outside of our proposals in this section.

We are specifically proposing that state Medicaid and CHIP agencies, rather than their managed care plans, would be responsible for obtaining the required permission. 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, the patient permission to this data exchange, as a Medicaid or CHIP beneficiary, should be obtained by the state and would apply regardless of the delivery system in which the beneficiary is enrolled. We believe that the state 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 care. We understand that this would require state Medicaid and CHIP agencies to create new processes to share a patient's opt in preference with their managed care plans and managed care entities.

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 a contracted managed care entity for the reasons outlined above. However, we are concerned that many states today do not exchange data between their Medicaid or CHIP FFS programs and managed care. We request comments on whether there are other ways we can ensure patient data is exchanged in this case in a manner that would reduce burden on states.

We are also proposing that the requirement to identify patients' previous and/or concurrent payers apply to state Medicaid and CHIP agencies rather than managed care plans or managed care entities. For the reasons described above, we believe that having the state maintain that record would allow that information to be retained regardless of any changes to the patient's Medicaid or CHIP care delivery system.

Furthermore, we understand that in many states, managed care plans may not have any contact with patients prior to their enrollment in the Medicaid or CHIP managed care plan. We believe the ideal time to allow patients to opt into payer to payer data exchange is during their application for Medicaid or CHIP. However, per 42 CFR 435.907(e)(1), states may only require information from an applicant that is necessary to make an eligibility determination. This means that while an applicant may be asked to provide their permission for the data exchange, they may not be required to respond to the question as a condition of submitting the application. Because we expect higher rates of patients providing permission when they are presented with the option at a time when they are already engaged in providing information (such as at application or plan selection), we highly encourage states to leverage any touchpoints before patients are enrolled in FFS or a managed care plan rather than expecting patients to submit permission in a separate process.

We understand that making changes to applications can be a significant administrative process and there may be other places where a state could obtain a patient's data exchange preference 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 population uses these tools to communicate with the Medicaid 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 purposes is described at 42 CFR 435.907(b)(1) 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 with that concurrent payer at that point. Furthermore, the patient permission provisions in this proposal would 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.

We request comment on the workflow and data exchanges that occur when a Medicaid or CHIP beneficiary is enrolled into a managed care plan and the feasibility of including the patient permission during the enrollment process. If not included in the application itself, is it feasible to gather permission and previous and/or concurrent payer information in a post-application questionnaire? Are there touchpoints that exist with beneficiaries after the application, but before or during enrollment (such as plan selection) that could be leveraged for this purpose? We considered proposing a policy that would require states to include optional questions to capture a patient's data exchange preference for payer to payer data exchange on their applications (as a non-required field); however, we believe that states have different processes, and a one-size-fits-all approach may not be optimal. Based on comments we receive and implementation across state Medicaid and CHIP programs, we may propose such a policy in the future.

c. Federal Funding for State Medicaid and CHIP Expenditures on Implementation of Payer to Payer Data Exchange

Should our proposals be finalized as proposed, states operating Medicaid and CHIP programs might be able to access Federal matching funds to support their implementation of the Payer-to-Payer API. This proposed API is expected to lead to more efficient administration of the Medicaid and CHIP state plans, consistent with sections 1902(a)(4) and 2101(a) of the Act.

We would not consider state expenditures for implementing this proposal to be attributable to any covered Medicaid item or service within the definition of “medical assistance.” Thus, in Medicaid, CMS would not match these expenditures at the state's regular Federal FMAP. However, were this proposal to be finalized as proposed, FFP under section 1903(a)(7) of the Act, at a rate of 50 percent, for the proper and efficient administration of the Medicaid state plan, might be available for state expenditures related to implementing this proposal for their Medicaid programs. We believe that using the Payer-to-Payer API would help the state more efficiently administer its Medicaid program, by ensuring that payers can access data that could improve care coordination for patients.

States' expenditures to implement these proposed requirements might also 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, or installation of mechanized claims processing and information retrieval systems. Additionally, 75 percent enhanced FFP under section 1903(a)(3)(B) of the Act may be available for state expenditures to operate Medicaid mechanized claims processing and information retrieval systems to comply with this proposed requirement.

States can request Medicaid enhanced FFP under section 1903(a)(3)(A)(i) or (B) of the Act through the APD process described in 45 CFR part 95, subpart F. States are reminded that 42 CFR 433.112(b)(12) and 433.116(c) in part require that any system for which they are receiving enhanced FFP under section 1903(a)(3)(A)(i) or (B) of the Act align with and incorporate the ONC's Health Information Technology standards adopted in 45 CFR part 170, subpart B. The Payer-to-Payer API complements this requirement because these APIs further interoperability by using standards adopted by ONC at 45 CFR 170.215. States are also reminded that 42 CFR 433.112(b)(10) and 42 CFR 433.116(c) explicitly support exposed APIs, meaning their 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.

Similarly, 42 CFR 433.112(b)(13) and 433.116(c) require states to promote sharing, leverage, and re-use of Medicaid technologies and systems 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 can connect to the APIs proposed in this rule would be required as part of the technical requirements at 42 CFR 431.60(d) for all proposed APIs in this rule, including the Payer-to-Payer API.

Separately, for state CHIP agencies, section 2105(c)(2)(A) of the Act and 42 CFR 457.618, limiting administrative costs to no more than ten percent of a state's total computable expenditures for a fiscal year, would apply to administrative claims for developing the APIs proposed in this rule.

We note that the temporary Medicaid FMAP increase available under section 6008 of the Families First Coronavirus Response Act (Pub. L. 116-127) does not apply to administrative expenditures.

d. Medicaid Expansion CHIP Programs

Most states have Medicaid Expansion CHIP programs, in which a state receives Federal funding to expand Medicaid eligibility to optional targeted to low-income children that meet the requirements of section 2103 of the Social Security Act. We are proposing at 42 CFR 457.700(c) that for states with Medicaid expansion CHIP programs, the proposals in this rule for Medicaid would apply to those programs rather than our proposals for separate CHIP programs. Functionally, our proposals are the same; however, for clarity, we are making explicit that the Medicaid requirements at §§ 431.60, 431.61, and 431.80 would apply to those programs rather than the separate CHIP requirements at §§ 457.730, 457.731, and 457.732.

5. Extensions, Exemptions, and Exceptions

a. Extensions and Exemptions for Medicaid and CHIP FFS Programs

Should our proposals regarding the Payer-to-Payer API be finalized as proposed, we would strongly encourage state Medicaid and CHIP FFS programs to implement the Payer-to-Payer API as soon as possible, due to the many anticipated benefits of the API as discussed in this section. However, we also recognize that state Medicaid and CHIP FFS agencies may face certain circumstances that would not apply to other impacted payers. To address these concerns, we are proposing a process through which states may seek an extension of, and, in specific circumstances, an exemption from the Payer-to-Payer API requirements. We propose the following:

(1) Extension

At the regulation citations identified in Table 3, we propose to provide state Medicaid FFS and CHIP FFS programs the opportunity to request a one-time extension of up to 1 year to implement the Payer-to-Payer API specified at 42 CFR 431.61(b) and 457.731(b). Some states may be unable to meet the proposed compliance date due to challenges related to securing needed funding for necessary contracting and staff resources in time to develop and implement the API requirements, depending on when the final rule is published in relation to a state's fiscal year, legislative session, budget process, and related timeline. Some states may need to initiate a public procurement process to secure contractors with the necessary skills to support a state's implementation of these proposed API policies. The timeline for an openly competed procurement process, together with the time needed to onboard the contractor and develop the API, can be lengthy for states. A state might need to hire new staff with the necessary skillset to implement this policy. The time needed to initiate the public employee hiring process, vet, hire, and onboard the new staff may make meeting the proposed compliance timeline difficult because, generally speaking, public employee hiring processes include stricter guidelines and longer time-to-hire periods than the other sectors. Furthermore, states are currently responding to the effects of the COVID-19 public health emergency, and their regular operational resources are over-extended. Unwinding from the COVID-19 public health emergency is also expected to require significant IT resources, which could have an impact on future IT work. In all such situations, a state might need more time than other impacted payers to implement the Payer-to-Payer API requirements. The 1-year extension that we propose could help mitigate the challenges. We considered delaying implementation of the provisions in this proposed rule an additional year for states, but decided that it would be better to propose to have only those states that needed an extension apply, because states vary in their level of technical expertise and ability to recruit staff and secure contracts.

Should the proposal for this API be finalized as proposed, states would be permitted to submit a written application for a one-time, one-year extension as part of their annual APD for MMIS operations expenditures. The state's request would have to include the following: (1) a narrative justification describing the specific reasons why the state cannot reasonably satisfy the requirement(s) by the compliance date, and why those reasons result from circumstances that are unique to the agency operating the Medicaid and/or CHIP FFS program (versus other types of impacted payers); (2) a report on completed and ongoing state implementation activities that evidence a good faith effort towards compliance; and (3) a comprehensive plan to meet the Payer-to-Payer API requirements no later than 1 year after the compliance date.

Under this proposal, CMS would approve an extension if, based on the information provided in the APD, CMS determines that the request adequately establishes a need to delay implementation, and that the state has a comprehensive plan to implement the proposed requirements no later than 1 year after the compliance date.

We also solicit comments on whether our proposal would adequately address the unique circumstances that affect states, and that might make timely compliance with the proposed API requirement difficult for states.

(2) Exemption

At the CFR sections identified in Table 3, we propose to permit state Medicaid FFS programs to request an exemption from the Payer-to-Payer API requirements when at least 90 percent of the state's Medicaid beneficiaries are enrolled in Medicaid managed care organizations as defined at 42 CFR 438.2. Likewise, we propose that separate CHIP FFS programs could request an exemption from the Payer-to-Payer API requirements if at least 90 percent of the state's separate CHIP beneficiaries are enrolled in CHIP managed care entities as defined at 42 CFR 457.10. In this circumstance, the time and resources that the state would need to expend to implement the Payer-to-Payer API requirements for a small FFS population may outweigh the benefits of implementing and maintaining the API. Unlike other impacted payers, state Medicaid and CHIP FFS programs do not have a diversity of plans to balance implementation costs for those plans with low enrollment. If there is low enrollment in a state Medicaid or CHIP FFS program, there is no potential for the technology to be leveraged for additional beneficiaries. States, unlike other payers, do not maintain additional lines of business.

We acknowledge that the proposed exemption could mean that most beneficiaries enrolled with exempted Medicaid or CHIP FFS programs would not receive the full benefits of having this API available to facilitate health information sharing with other payers. To address this, we propose that states that are granted an exemption would be expected to implement an alternative plan to ensure that other payers will have efficient electronic access to the same information through other means, to help ensure that Medicaid or CHIP services are provided with reasonable promptness and in a manner consistent with simplicity of administration and in the best interests of those beneficiaries who are served under the FFS program.

We propose that a state could submit a written request for an exemption from the requirements for the Payer-to-Payer API as part of its annual APD for MMIS operations expenditures prior to the date by which the state would otherwise need to comply with the requirements (which may be extended by 1 year if the state receives an extension). For Medicaid exemption requests, the state would be required to include documentation that it meets the criteria for the exemption based on enrollment data from the most recent CMS “Medicaid Managed Care Enrollment and Program Characteristics” report. For a CHIP FFS exemption, the state's request would have to include enrollment data from Section 5 of the most recently accepted state submission to CARTS. The state would also be required to include in its request information about an alternative plan to ensure that payers will have efficient electronic access to the same information through other means while the exemption is in effect. CMS would grant the exemption if the state establishes to CMS's satisfaction that it meets the criteria for the exemption and has established such an alternative plan. We note that the exemption would only apply to the API requirements, not the state's permission collection obligations.

Once an exemption has been approved, we propose that the exemption would expire if either of the following two scenarios occurs: (1) based on the 3 previous years of available, finalized Medicaid T-MSIS and/or CHIP CARTS managed care and FFS enrollment data, the State's managed care enrollment for 2 of the previous 3 years is below 90 percent; or (2) CMS has approved a State plan amendment, waiver, or waiver amendment that would significantly reduce the share of beneficiaries enrolled in managed care and the anticipated shift in enrollment is confirmed by available, finalized Medicaid T-MSIS and/or CHIP CARTS managed care and FFS enrollment data.

For the first scenario, CMS recognizes that there may be circumstances where a state's managed care enrollment may fluctuate slightly below the 90 percent threshold in 1 year, and yet return to above 90 percent the next year. To help reduce the possible burden on exempted states experiencing this type of temporary fluctuation in managed care enrollment, CMS would consider data from the 3 previous years of available, finalized Medicaid T-MSIS and/or CHIP CARTS managed care and FFS enrollment data. We propose that if the state's managed care enrollment for 2 of the previous 3 years is below 90 percent, the state's exemption would expire.

We propose that a state would be required to provide written notification to CMS that the state no longer qualifies for the Payer-to-Payer API exemption when data confirm that there has been a shift from managed care enrollment to FFS enrollment resulting in the State's managed care enrollment falling below the 90 percent threshold for 2 of the previous 3 years. We propose that the written notification be submitted to CMS within 90 days of the finalization of the annual Medicaid T-MSIS managed care enrollment data and/or the CARTS report for CHIP confirming that there has been the requisite shift from managed care enrollment to FFS enrollment in 2 of the 3 previous years.

For the second scenario, we recognize that there may be state plan amendments, waivers, or waiver amendments that would result in a shift from managed care enrollment to FFS enrollment. Additionally, there may be instances where anticipated enrollment shifts may not be fully realized due to other circumstances. We propose that a state would be required to provide written notification to CMS that the state no longer qualifies for the Payer-to-Payer API exemption when data confirm that there has been a shift from managed care enrollment to FFS enrollment as anticipated in the state plan amendment or waiver approval. We propose that the written notification 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 confirming that there has been the requisite shift from managed care enrollment to FFS enrollment.

Regardless of why the exemption expires, if it expires, the state would be required to obtain CMS's approval of a timeline for compliance with the Payer-to-Payer API requirements for the state's Medicaid FFS and/or CHIP FFS population(s) within two years of the expiration date of the exemption.

For Medicaid and CHIP managed care, we are not proposing an extension process because we believe that managed care plans are actively working to develop the necessary IT infrastructure to be able to comply with the existing requirements at 42 CFR parts 438 and 457 and because many of them might benefit from efficiencies resulting from the variety of plan types that they offer. Many managed care plans are part of parent organizations that maintain multiple lines of business, including Medicaid managed care plans and plans sold on the Exchanges. As discussed in the CMS Interoperability and Patient Access final rule (85 FR 25607, 25612, and 25620), work done by these organizations can benefit all lines of business and, as such, we do not believe that the proposals in this rule impose undue burden or cannot be achieved by the compliance date. We are soliciting comments on our assumptions regarding the scope of resources and ability of managed care parent organizations to achieve economies of scale when implementing the proposed API.

Further, we seek comment on whether an extension process would be warranted for certain managed care plans to provide additional time for the plan to comply with the proposed requirement at 42 CFR 431.61(b) (which cross references at 42 CFR 438.242(b)(7) for Medicaid managed care plans) and at proposed 42 CFR 457.731(b) (which cross references at 42 CFR 457.1233(d)) for CHIP managed care entities. While we are not proposing such a process for managed care plans and entities and do not believe one is necessary, we are open to evaluating options for possible future rulemaking. Were we to adopt an extension process for these managed care plans and entities, what criteria should a managed care plan or entity meet to qualify for an extension? Should the criteria include enrollment size, plan type, or certain unique characteristics that could hinder their achievement of the proposed requirements by the proposed compliance date? We also seek comment on whether, were we to propose such a process for Medicaid managed care plans or CHIP managed care entities, the entity responsible for evaluating the criteria and exception evaluation process should be the state and whether states could implement the exception evaluation process with available resources. Consistent with the exception process proposed for QHP issuers on the FFEs at 45 CFR 156.222(c), we would expect managed care plans seeking extensions to provide, at a minimum, a narrative justification describing the reasons why a plan or entity cannot reasonably satisfy the requirements by the proposed compliance date, an explanation of the impact of non-compliance upon enrollees, an explanation of the current or proposed means of providing electronic health information to payers, and a comprehensive plan with a timeline to achieve compliance.

We request comment on the proposed extension and exemption processes.

b. Exception for QHP Issuers

For QHP issuers on the FFEs, we propose an exception to the Payer-to-Payer API proposal at the regulation citations identified in Table 3. We propose that if an issuer applying for QHP certification to be offered through an FFE believes it cannot satisfy the proposed requirements at 45 CFR 156.222(b) for the Payer-to-Payer API, the issuer would have to include as part of its QHP application a narrative justification describing the reasons why the issuer could not 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 payers, and solutions and a timeline to achieve compliance with the requirements of this section. We propose that the FFE may grant an exception to the requirements at 45 CFR 156.222(b) for the Payer-to-Payer API if it determines that making qualified health plans of such issuer available through such FFE 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 issuer to offer qualified health plans through the FFE. This proposal would be consistent with the exception for QHP issuers on the FFEs we finalized for the Patient Access API in the CMS Interoperability and Patient Access final rule (85 FR 25552). For instance, as noted in that final rule, that exception could apply to small issuers, financially vulnerable issuers, or new entrants to the FFEs that demonstrate that deploying FHIR API technology consistent with the required interoperability standards would pose a significant barrier to the issuer's ability to provide coverage to patients, and not certifying the issuer's QHP or QHPs would result in patients having few or no plan options in certain areas. We believe that having a QHP issuer offer QHPs through an FFE generally is in the best interest of patients and would not want patients to have to go without access to QHP coverage because the issuer is unable to implement this API.

In summary, we propose to permit certain impacted payers (state Medicaid and CHIP FFS programs and QHP issuers on the FFEs) to apply for an extension, exemption, or exception, as applicable, from implementing the proposed Payer-to-Payer API. We propose that these programs would submit and be granted approval for an extension or exemption as a part of applicable established processes. We propose that submission requirements would include certain documentation identified in the regulatory citations in Table 3.

6. Statutory Authorities for Payer to Payer Data Exchange Proposals

a. MA Organizations

For MA organizations, we are proposing these Payer-to-Payer API requirements under our authority at section 1856(b) of the Act by which the Secretary may adopt by regulation standards to implement provisions in Part C of Title XVIII of the Act (such as section 1852(d)(1)(A)), section 1852(h) of the Act that requires MA organizations to provide their enrollees with timely access to medical records and health information insofar as MA organizations maintain such information; and section 1857(e)(1) of the Act by which the Secretary may incorporate contract terms and conditions for MA organizations that we determine are necessary, appropriate, and not inconsistent with the statute.

We note that in regulations establishing the MA program, CMS described it as a program designed to provide for regional plans that may make private plan options available to many more beneficiaries, especially those in rural areas. This was done to 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 healthcare system. The proposals throughout this proposed rule support these goals and enable the MA program to advance services for its beneficiary population in one significant way—by providing greater access to information in a way specifically to 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 one payer sharing certain claims, encounter, and clinical data, as well as prior authorization requests and decisions with another payer identified by the patient. Such exchanges of data about enrollees could facilitate continuity of care and enhance care coordination. As discussed for the Provider Access API in section II.B. of this proposed 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 proposing to require payers to share data for more than one patient at a time, we believe there are efficiencies to doing so, both for communicating information and for leveraging available technology.

Thus, the proposal for payers to share information could apply as well to data exchanges using the Payer-to-Payer API. It could 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. And it could reduce the amount of time needed to evaluate a patient's current care plan and possible implications for care continuity, which could introduce efficiencies and improve care. As discussed earlier, if a new payer is able to receive information and documentation about prior authorization requests from a previous payer, the new payer could 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 could 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, we believe that the benefits to be gained by sharing data make adoption of Payer-to-Payer API policies proposed here 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 beneficiary satisfaction, consistent with sections 1856(b) and 1857(e) of the Act.

Section 1852(h) of the Act requires MA organizations to provide their enrollees with timely access to medical records and health information insofar 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 believe that 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 proposed Payer-to-Payer API would ultimately be accessible to enrollees via the Patient Access API and would therefore improve timeliness to medical records and health information as enrollees would no longer have to spend time contacting previous payers to access their information. These data would be accessible as needed by the enrollee's current payer and would therefore support timely access.

Section 1852(d)(1)(A) 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, we believe our proposal here for MA organizations to implement and maintain a Payer-to-Payer API would facilitate exchanges of information about enrollees that are necessary for effective and continuous patient care. Under our proposal, the data received from other impacted payers would become part of the data the MA organization maintains and would therefore be available (subject to other law authorizing the disclosure) to providers via the Provider Access API discussed in section II.B. of this proposed rule; the data could then be used for treatment and coordination of care purposes.

b. Medicaid and CHIP

Our proposals in this section above 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.

We believe these proposals related to the Payer-to-Payer API are authorized by section 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, if finalized as proposed, we anticipate that it would help state Medicaid programs improve the efficiencies and simplicity of their own operations, consistent with sections 1902(a)(4) and (a)(19) of the Act. It could give Medicaid and CHIP agencies and their managed care plans access to their beneficiary's information in a standardized manner and enable the state to then make that information available to providers and to patients through the Patient Access and Provider Access API. It could also reduce the amount of time needed to evaluate a patient's current care plan and possible implications for care continuity, which could introduce efficiencies and improve care. Receiving patient information at the start of coverage would help to ensure Medicaid and CHIP agencies and those managed care plans considered impacted payers under this proposed rule could lead to more appropriate service utilization and higher beneficiary satisfaction by supporting efficient care coordination and continuity of care, which could lead to better health outcomes.

As discussed in section II.C.3.a. of this proposed rule, if a state Medicaid program has access to a previous payer's prior authorization decisions, the Medicaid program could 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 proposals, if finalized, are 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 section 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 could also better support care continuity for Medicaid beneficiaries. If states were to share information about Medicaid beneficiaries or former beneficiaries with their concurrent and next payers, they could 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 proposal could also improve the provision of Medicaid services, by potentially helping to ensure that Medicaid beneficiaries who may require coordinated services with concurrent payers could 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 uses or disclosures of information that are directly connected with the administration of the Medicaid state plan. The implementing regulations for this section of the Act list purposes that CMS has determined are directly connected to Medicaid state plan administration at 42 CFR 431.302. We believe that requiring the data described in this section to be shared via the Payer-to-Payer API would be consistent with states' requirements to provide safeguards to share these data since it is related to providing services for beneficiaries, a purpose listed in § 431.302(c). As described above in the section 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, could 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 above. When state Medicaid or CHIP agencies share medical records or any other health or enrollment information pertaining to individual beneficiaries, they must comply with 42 CFR 431.306. See discussion above about how the opt in process proposed for this API would help states comply with 42 CFR 431.306.

For Medicaid managed care plans, the proposed exchange of all data classes and data elements included in a content standard adopted at 45 CFR 170.213, adjudicated claims and encounter data, as well as the patient's prior authorization requests and decisions would 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 proposed in this rule would 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 are proposing 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. We believe the provisions in this proposed rule could strengthen our ability to fulfill these statutory obligations in a way that recognizes and accommodates using electronic information exchange in the healthcare industry today and would facilitate a significant improvement in the delivery of quality healthcare to our beneficiaries.

As with the Medicaid FFS and Medicaid managed care programs, the proposals in this section of the proposed 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 could use data from the previous payer to respond to a request for a prior authorization more effectively or accurately, because under this proposal, a new payer would have historical claims or clinical data upon which they may review a request with more background data. Access to information about new patients could enable appropriate staff within the CHIP program to coordinate care and conduct care management more effectively because they would have better data available to make decisions for planning. In many cases, patients do not remember what services they have had, what vaccines they have had, or other possibly relevant encounters that could help payers manage their care. This proposal is consistent with the goal of providing more informed and effective care coordination, which could 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 subpart F of 42 CFR part 431 are also applicable to CHIP through a cross-reference at 42 CFR 457.1110(b). As discussed above for Medicaid, CHIP agencies' data exchange through the Payer-to-Payer 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. 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. See discussion above about how the opt in process proposed for this API would help states comply with 42 CFR 431.306.

c. QHP Issuers on the FFEs

For QHP issuers on the FFEs, we are proposing 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 would allow the seamless flow of all data classes and data elements included in a standard in 45 CFR 170.213, adjudicated claims and encounter data as well as the patient's prior authorization requests and decisions, from payer to payer. We believe that 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 would reduce administrative burden and result in more timely and efficient care coordination and responses to prior authorization requests.

We believe it is in the interest of qualified individuals that QHP issuers on FFEs have systems in place to send information important to care coordination with departing enrollees, and that QHP issuers on FFEs also have systems in place to receive such information from payer to payer on behalf of new and concurrent enrollees, as appropriate and consistent with the proposals in this section. Therefore, we believe certifying health plans that make enrollees' health information available to other payers in a convenient, timely, and portable way is in the interests of qualified individuals in the state in which an FFE operates. 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 enrollee's data at one time between issuers, we encourage QHP issuers on the FFEs to use the Bulk Specification for the Payer-to-Payer API once it is available as we believe it would improve the efficiency and simplicity of data transfers between issuers by enabling the exchange of all data for all patients at once. We believe the opportunity to support an exchange of large volumes of patient data, rather than data for one patient at a time, may be cost effective for the issuers. Having patient information at the beginning of a new plan could assist the new payer in identifying patients who need care management services, which could reduce the cost of care. Taking in volumes of data would also enable the QHPs to perform analysis on the types of new patients in their plan if they choose to analyze data for existing patients as well.

D. Improving Prior Authorization Processes

1. Background

This section of the proposed rule addresses the topic of prior authorization and includes both technical and operational proposals that are intended to improve the prior authorization process for payers, providers, and patients. Here we propose to require payers to do the following: implement and maintain an API to support and streamline the prior authorization process; respond to prior authorization requests within certain timeframes; provide a clear reason for prior authorization denials; and publicly report on prior authorization approvals, denials, and appeals. The proposals in this rule would build on the foundation set out in the CMS Interoperability and Patient Access final rule (85 FR 25510) to improve health information exchange and increase interoperability in the healthcare system. These proposals were developed based on input from CMS-sponsored listening sessions and stakeholder meetings which included payers, providers, vendors, and patients, as well as reports prepared and released by HHS or its Federal advisory committees, such as the National Committee on Vital and Health Statistics (NCVHS) and the Health Information Technology Advisory Committee (HITAC).

The proposals would 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 are rendered or items provided. As discussed in section I.A.1., because the processes and standards for prior authorization applicable to drugs differ from other items and services, this proposed rule would not apply to any drugs, meaning any drugs that could be covered by the impacted payers in this proposed rule. As such, this proposed rule would not apply to outpatient drugs, drugs that may be prescribed, those that may be administered by a physician, or that may be administered in a pharmacy, or hospital. We propose a definition for this exclusion for each impacted payer in the regulation text of this proposed rule, and provide a reference to the CFR sections where these definitions would be added for MA organizations, Medicaid FFS, Medicaid Managed Care Plans, CHIP FFS, CHIP Managed Care Entities, and the QHPs on the FFEs in Table 7. Each definition explains that drugs excluded from this proposal for prior authorization for items and service requirements are defined as “any and all drugs covered by any of the impacted payers addressed in the proposed rule.”

Also, as mentioned in section I.A, Medicare FFS is not directly affected by this proposed rule. However, the Medicare FFS program is evaluating opportunities to improve automation of prior authorization processes. If our proposals are finalized, Medicare FFS would align its efforts for implementation of the requirements as feasible. We seek comment on whether this could be implemented as proposed for the Medicare FFS program, how we could apply the proposals below, and if there would be differences for implementing the PARDD API in the Medicare FFS program as a Federal payer.

We use the term prior authorization to refer to the process by which a provider must obtain approval from a payer before providing care in order to receive payment for delivering items or services. Prior authorization has an important place in the healthcare system, but the process of obtaining prior authorization can be challenging for patients, providers, and payers. Stakeholders, including payers and providers, have claimed that dissimilar payer policies, provider workflow challenges, inconsistent use of electronic standards, and other technical barriers have created 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 become a health risk for patients if inefficiencies in the process cause care to be delayed.

HHS has been studying prior authorization processes and their associated burden for several years to identify the primary issues that might need to be addressed to alleviate the burdens of these processes on patients, providers, and payers. For example, to advance the priorities of the 21st Century Cures Act (Pub. L. 114-255), specifically to reduce the burden associated with the use of EHR technology, ONC and CMS created a work group to study prior authorization and identify opportunities for potential solutions. As identified by that work group, and in the reports highlighted in this proposed rule, burdens associated with prior authorization include 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. The ONC report “Strategy on Reducing Regulatory and Administrative Burden Relating to the Use of Health IT and EHRs” fulfills the statutory requirements of section 4001 of the 21st Century Cures Act. Page eight of this report summarized the challenge with the following statement: “Payers and health IT developers have generally addressed prior authorization in an ad hoc manner, implementing unique interfaces to facilitate documentation and sharing of information that reflect their own technology considerations, lines of business, and customer-specific constraints.”

In 2018, the American Medical Association (AMA) conducted a physician survey that noted issues with prior authorization. In December 2020, the AMA released the results of a second member survey, which indicated that provider burdens related to prior authorization had not improved, but rather had gotten worse, indicating a weekly per-physician average of 41 prior authorization requests, which consume an average of 13 hours of practice time per workweek for physicians and their staff. Additionally, 40 percent of physicians employ staff to work exclusively on prior authorizations. Most physicians responding to the 2020 survey reported ongoing difficulties determining whether an item or service required authorization. Additionally, physicians reported that most prior authorizations are still done through phone calls and faxes, with only 26 percent reporting that they have an EHR system that supports electronic prior authorization for prescription medications.

The burden of prior authorization is not experienced solely by physicians; hospitals are also burdened by prior authorization processes. In a November 4, 2019 letter to the CMS Administrator, the American Hospital Association (AHA) described the ongoing impact of prior authorization on patient care, health system costs, and administrative burdens. In that letter, the AHA shared results from the previously referenced 2018 AMA survey of more than 1,000 physicians. According to the AHA, hospitals and provider offices have many full-time employees whose sole role is to manage payer prior authorization requests. According to the AHA survey, one 17-hospital system reported spending $11 million annually just to comply with health plan prior authorization requirements. Operational costs such as these are often factored into negotiated fees or charges to patients to ensure financial viability for healthcare organizations, including providers and facilities.

In 2019, CMS conducted several listening sessions with payers, providers, patients, and other industry representatives to gain insight into issues with prior authorization processes and identify potential areas for improvement. While providers and payers agreed that prior authorization provides value to the healthcare system for cost control, utilization management, and program integrity, some stakeholders explained that certain steps in prior authorization processes present an undue burden. For example, the information payers require from providers to evaluate or review a prior authorization can be inconsistent from payer to payer, and it can be difficult for providers to determine the rules for items or services that require prior authorization, or to identify what documentation is needed to obtain approval. Furthermore, documentation requirements are not standardized across payers, and access to the requirements may require the use of proprietary portals. These same types of challenges were described in ONC's 2020 Strategy on Reducing Regulatory and Administrative Burden Relating to the Use of Health IT and EHRs, which reported that “[e]ach payer has different requirements and different submission methods, and clinicians report finding it burdensome and time-consuming trying to determine whether prior authorization requirements exist for a given patient, diagnosis, insurance plan, or state.”

In March and November of 2019, two Federal advisory committees, the HITAC and NCVHS, held joint hearings with industry representatives including payers, providers, vendors, and standards development organizations to discuss persistent challenges with prior authorization workflows and standards. During these hearings, payers and providers again agreed that the solutions to the challenges with prior authorization processes are multi-faceted. Many participants suggested that improvement of prior authorization required changes in process, policy, and technology, and reiterated the need for convergence on those three elements to improve the overall process. At the November 13, 2019, NCVHS Full Committee meeting, industry participants discussed prior authorization standards and processes. The themes from panelists were consistent with the information described in this proposed rule for changes needed in technology, payer transparency with respect to prior authorization requirements, and provider workflow. At the meeting, AHIP reported the results of its 2019 fall plan survey, which included both AHIP member and non-AHIP-member plans, and noted that plans were evaluating opportunities to improve prior authorization processes. In 2020, AHIP launched a pilot of alternative prior authorization strategies with several plans. The study was completed at the end of that year, and a report was published in March 2021. In that report, AHIP wrote that an independent evaluator examined over 40,000 prior authorization transactions over a 12-month period from the participating health insurance providers (that is, payers) and conducted a survey of over 300 clinicians and practice staff who used electronic prior authorization technologies to assess the impact of electronic prior authorization on provider practices and patient care. The key findings from the study include a 69 percent reduction in median time between submitting a prior authorization request and receiving a decision. The study also found improved timeliness to care and lower provider burden from phone calls and faxes.

In early 2020, NCVHS and HITAC convened another task force, the Intersection of Clinical and Administrative Data (ICAD) Task Force. The overarching charge to the Task Force was to bring together industry experts and produce recommendations related to electronic prior authorizations. The ICAD Task Force presented its report to HITAC in November 2020. Several recommendations pertaining to the use of FHIR APIs for prior authorization were included in the ICAD Task Force report and are consistent with proposals in this proposed rule. These recommendations from HITAC and others are described in more detail in section II.F. of this proposed rule.

The first guiding principle in the ICAD report is that the patient is at the center of care and emphasis should be on process solutions that remove roadblocks to care and support the coordination of timely care while reducing burdens, improving the patient experience, and ultimately improving outcomes. Underlying the first principle are seven characteristics for the ideal state of the prior authorization processes: (1) removing burden from patients and caregivers to push the process forward; (2) price transparency; (3) shared decision-making processes between clinician and patient; (4) information about coverage and potential denials are made available to the patient and provider; (5) tools are available for all patients to lessen burden and overcome barriers related to the digital divide, access, socio-economic factors, and literacy; (6) patients are able to share data bi-directionally with third parties electronically from an application of their choice; (7) patients have the choice to use a third-party credential/authorization/consent service to support seamless access to all of their data with minimal effort.

The HITAC and NCVHS Federal advisory committee reports, as previously mentioned, describe the need for process improvements for prior authorization, which echo the input CMS received from its payer and provider stakeholder meetings and industry surveys. We believe our proposals, if finalized as proposed, would make meaningful progress to improve prior authorization processes, alleviate burdens, facilitate more equitable access to care, and support efficient operations for providers and payers.

As discussed in section I.A. of this proposed rule, in December 2020, CMS published the December 2020 CMS Interoperability proposed rule, in which we made proposals to streamline the prior authorization process. In general, payers and providers supported the intent of the proposed rule, however, they also requested that CMS include the Medicare Advantage program as an impacted payer and evaluate the implementation dates for the APIs. As stated in section I.A., we are withdrawing the December 2020 CMS Interoperability proposed rule and issuing this new proposed rule that incorporates the feedback we received from stakeholders. We understand that many readers may already be familiar with that proposed rule, and to distinguish the differences between the proposals, we refer readers to the discussion in section I.A. which outlines the overarching differences between this proposed rule and the prior proposed rule.

There are additional differences specific to proposals in this section. First, we have modified the name and description of the standards-based APIs intended to support prior authorization processes but have not changed the purpose of those APIs. In this proposed rule, we refer to two of the previously proposed APIs collectively as the Prior Authorization Requirements, Documentation, and Decision (PARDD) API. In the December 2020 CMS Interoperability proposed rule, we referred to these two APIs separately, calling them the Document Requirement Lookup Service (DRLS) API and the Prior Authorization Support (PAS) API. The proposed PARDD API functionality combines the functionality of the previously proposed DRLS and PAS APIs. Second, we are proposing to change the implementation date for many of the proposals in this section to January 1, 2026. We note that some of the Medicaid FFS fair hearings and notice proposals discussed in section II.D.6.b. would take effect before that date if this proposed rule were finalized as proposed.

2. Electronic Options for Prior Authorization

While there is a standard available for electronic prior authorization transactions, adopted by HHS under the provisions of the Health Insurance Portability and Accountability Act of 1996 (HIPAA), many payers and providers do not use this adopted standard (the X12 278 Version 5010). Instead, payers build proprietary interfaces and web portals through which providers submit their requests, and both still frequently resort to phone calls or faxes to complete the process for a response. The process may remain inefficient, burdensome, and create service issues for patients. As previously explained, providers indicate that the main hurdle is knowing which services require prior authorization, and what documentation is necessary to support that service or item. The current processes or standard do not address this barrier.

In section II.B.2. of this proposed rule, we reference the transactions for which the Secretary must adopt standards for use by HIPAA-covered entities (for example, health plans, health care clearinghouses, and certain health care providers), and list the transactions for which a standard must be adopted. The HIPAA-adopted standards for referral certifications and authorizations, also referred to as the prior authorization transaction standards (45 CFR 162.1302), are the—

• National Council for Prescription Drug Programs (NCPDP) Telecommunication Standard Implementation Guide Version D.0 for retail pharmacy drugs; and
• ASC X12 Version 5010x217 278 (X12 278) for dental, professional, and institutional requests for review and response.

While the prior authorization proposals in this proposed rule do not apply to any drugs, we reference the NCPDP standard for retail pharmacy transactions to acknowledge it as one of the two mandated standards for prior authorization adopted under HIPAA. The X12 278 standard was adopted for the prior authorization of medical items and services. Though payers are required to use the X12 278 version 5010 standard for electronic prior authorization transactions and providers are encouraged to conduct the transaction electronically, the X12 278 has not achieved a high adoption rate by covered entities. The Council for Affordable and Quality Health Care (CAQH) releases an annual report, the CAQH Index, which includes data on health plan and provider adoption of HIPAA standard transactions. In the 2019 report, among the seven transactions benchmarked, prior authorization using the X12 278 standard was the least likely to be supported by payers, practice management systems, vendors, and clearinghouse services. According to that year's report, 13 percent of the respondents indicated that they were using the adopted standard in a fully electronic way, while 54 percent responded that they were conducting electronic prior authorization using web portals, Integrated Voice Response (IVR), and other options, and 33 percent were using fully manual processes such as phone, mail, fax, and email. The 2021 report showed an incremental increase in the use of the X12 278 prior authorization standard of 26 percent. The report stated that the overall volume remained stable, but the volume of transactions conducted using the HIPAA mandated standard for prior authorizations increased, possibly due to payer portal enhancements and provider interest in moving to electronic submissions for prior authorization requests. According to the CAQH Index, reported barriers to using the HIPAA standard include “lack of vendor support for provider systems, inconsistent use of data content from the transaction, and lack of an attachment standard to submit required medical documentation.”

Enhancements to the electronic prior authorization process could support greater use of the HIPAA X12 278 standard through automation, which could also reduce the time for submission of the request and response. In the following discussion, we propose to require impacted payers to implement an HL7 FHIR API that would work in combination with the adopted HIPAA transaction standard to conduct the prior authorization process. It is important to note that we are not proposing changes to the requirement for covered entities to use the adopted HIPAA transaction standard but are proposing to require that impacted payers develop and implement an API that works together with that standard, and may support greater use of the X12 278 standard.

As previously noted, section 1104 of the Affordable Care Act amended HIPAA to also require that HHS adopt operating rules for the 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.” The NCVHS reviews potential HIPAA 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. To date, HHS has adopted operating rules for three of the HIPAA standard transactions: eligibility for a health plan and health care claim status (76 FR 40457), health care Electronic Funds Transfer (EFT), and remittance advice (77 FR 48007). In February 2020, CAQH, which develops operating rules for some of the HIPAA standards, submitted two operating rules for NCVHS review regarding HIPAA referral certification and authorization transaction. NCVHS held a hearing to discuss those operating rules in August 2020 and submitted a letter to the HHS Secretary in November 2020 recommending pilot testing to evaluate the proposed operating rules rather than immediate adoption. At this time, NCVHS has not recommended that HHS adopt operating rules for the HIPAA referral certification and authorization transaction. Should NCVHS make such a recommendation, we would evaluate the effect, if any, on the policies included in this proposed rule. Even if this rule is finalized as proposed we would continue to evaluate the impact of an NCVHS recommendation and any separate actions by HHS in that regard.

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. The approved exception allows testing of proposed modifications to HIPAA requirements—specifically for the prior authorization standard. Under this exception, the group would test a prior authorization exchange using the HL7 FHIR standard without the X12 278 standard, to determine whether this alternative standard for prior authorization could improve efficiency. HHS provides information about requests for exceptions from standards to permit testing of proposed modifications on the CMS HIPAA administrative simplification website. We note that our proposals in the following discussion are intended to work together with the adopted X12 278 standard.

3. Proposed Requirement for Payers: Implement an API for Prior Authorization Requirements, Documentation, and Decision (PARDD API)

a. Prior Authorization Requirements, Documentation, and Decision (PARDD) API

To help address prior authorization process challenges and continue following our roadmap to interoperability, we propose to require that, beginning January 1, 2026, certain payers implement and maintain a FHIR Prior Authorization Requirements, Documentation, and Decision (PARDD) API to be used by providers to facilitate the prior authorization process.

We note that in section II.A.2.a., we are proposing that payers make information about prior authorization decisions available to patients through the Patient Access API to help them be more informed decision makers and partners in their healthcare. The proposals in this section are specific to improving the prior authorization process between payers and providers using the PARDD API. These policies taken together help to facilitate a more streamlined and better-informed healthcare team in which patients, providers, and payers have access to the status of prior authorizations.

The PARDD API would streamline the prior authorization process for the provider or office staff by automating certain tasks, thereby mitigating some of the obstacles of the existing prior authorization process. The API would allow a provider to query the payer's system to determine whether a prior authorization was required for certain items and services and identify documentation requirements. The API would also automate the compilation of necessary data for populating the HIPAA-compliant prior authorization transaction and enable payers to provide the status of the prior authorization request, including whether the request has been approved or denied. Covered entities would continue to send and receive the HIPAA-compliant prior authorization transactions while using the FHIR PARDD API. In the following discussion, we propose to require certain standards and recommend several others that would support the build of this API, while maintaining compliance with the mandated HIPAA standard for prior authorization.

To implement the API, we propose to require the use of certain IGs adopted at 45 CFR 170.215. We also propose that impacted payers would use the same documentation requirements and the same discontinuation and denial of access requirements as we are proposing for the Patient Access API (discussed in section II.A.2), the Provider Access API (section II.B.2), and the Payer-to-Payer API (section II.C.3). We believe that consistency in applying these requirements to all proposed APIs would minimize the cost and burden of implementation and support payer risk mitigation strategies. Should this proposal be finalized as proposed, we would also recommend using certain HL7 FHIR Da Vinci IGs which have been developed specifically to support the functionality of the PARDD API. These include:

• The HL7 FHIR Da Vinci Coverage Requirements Discovery (CRD) Implementation Guide.
• The HL7 FHIR Da Vinci Documentation Templates and Rules (DTR) Implementation Guide.
• The HL7 FHIR Da Vinci Prior Authorization Support (PAS) Implementation Guide.

The CRD IG provides information about whether an authorization is required for certain items or services and provides transparency into the payers' prior authorization coverage rules, so the provider knows what information is necessary to support a request. The DTR IG provides the means to ensure the completion of documentation needed to demonstrate medical necessity for a proposed item or service, based on payer requirements.

The PAS IG uses the FHIR standard as 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. Under the workflow specified in the PAS IG, to meet regulatory requirements for the HIPAA standard transactions discussed previously, the FHIR interface communicates with an intermediary (for example, a clearinghouse) that converts the FHIR requests to a HIPAA-compliant X12 278 request transaction for submission to the payer. In some cases, the payer may act as the intermediary or clearinghouse and convert the request to a HIPAA-compliant X12 278 transaction. Under the workflow specified in the PAS IG, the response from the payer would then flow back through the intermediary using X12 278 and would be made available to the provider's health IT system using the FHIR standard. The response would indicate whether the payer approves (and for how long), or denies (and the reason), the prior authorization request, or request more information from the provider to support the prior authorization request. This 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. The goal is to provide information about prior authorization, where possible, in the provider's clinical workflow. We refer to section II.F. of this proposed rule for further discussion of the required and recommended standards to support the PARDD API.

To reiterate, for the reasons explained in section I.A., we are not proposing to apply the proposals for the PARDD API to any drugs.

Based on a review of Medicare FFS policies and prior authorization requirements, as well as industry pilots and demonstrations, we understand payers may have hundreds of policies that could be included in the PARDD API. The initial phase of identifying and evaluating all the policies may be a significant effort. We also recognize that payers would need to evaluate their prior authorization policies for each plan type, analyze coverage requirements, and program those requirements for the PARDD API. We acknowledge that such efforts would require staff time for evaluation, development, and testing of the API functionality. To maximize early understanding of how they could implement the recommended IGs for the PARDD API and operationalize these new processes, we encourage stakeholders to participate in the HL7 workgroups as they further refine the IGs that support prior authorization. Information about these and other workgroups may be found on the HL7 website at https://www.HL7.org.

Given the effort that would be required to implement the PARDD API, we considered proposing that the API be implemented in a phased approach. Specifically, we considered and are seeking comment on whether to require payers to make prior authorization rules and documentation requirements available through the API incrementally, beginning January 1, 2026. In this alternative, Medicaid managed care plans and CHIP managed care entities would be required to comply with the approach described (in this section of this document) by the rating period beginning on or after January 1, 2026, and QHP issuers on the FFEs for plan years beginning on or after January 1, 2026.

Under the proposal we considered, in the first phase, impacted payers would have been required to make 25 percent of their prior authorization rules and documentation requirements available through the API, prioritized by the highest number of requested items and services. We would have proposed that the first phase begin by January 1, 2026. The second phase would have required impacted payers to make available at least 50 percent of their prior authorization rules and documentation requirements, prioritized by the highest number of requested items and services. We would have proposed that this phase begin by January 1, 2027. Finally, beginning January 1, 2028, impacted payers would have been required to make available 100 percent of their prior authorization rules and documentation requirements through the API. Though this alternative approach could have provided additional time for payers to test their implementations and assess the benefits with providers, there was also a potential risk that a phased approach could have added complexity to the process for providers, rather than improving efficiency and reducing burden. If each payer's highest volume of requirements is unique, provider staff could have been required to spend considerable time alternating between the API and prior methods of researching prior authorization requirements. We opted against proposing this lengthy phased-in option because of the challenges we believe it could have created for providers continuing to navigate different implementation of payer rules. However, we request comments on this phased-in approach, our assumptions, and other potential options for an implementation strategy. For example, we request comment on whether payers would need a phased-in implementation to codify their rules and ensure that they are in a structured format (for example, quantifiable and machine-readable) for purposes of the API. If an alternative approach of this type were to be considered, how could CMS structure such an implementation strategy and timeframe without introducing additional burden? What are the operational and technical challenges involved in converting prior authorization rules into structured, machine-readable documents? Do payers have estimates of the amount of time that would be required for converting the most frequently requested prior authorizations into structured documents?

For purposes of this proposed rule, rather than pursue a phased implementation process to maximize the benefits of electronic prior authorization, we propose that payers would be required to implement the PARDD API for all prior authorization rules and requirements for items and services, excluding drugs, by 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). We do not believe it necessary to propose a phased implementation strategy because we are not certain such an approach would reduce burden on either impacted payers, or providers, and believe in some cases it could increase the burden during the initial implementation. For example, as we previously outlined, for a phased approach, in the first phase, impacted payers would have been required to make 25 percent of their prior authorization rules and documentation requirements available through the API. Because prior authorizations vary by payer, that could mean that some payers would make one set of items or services available for prior authorization via the PARDD API, and another payer would have another set of items and services available. Providers seeking to utilize the PARDD API would then have conflicting methods of prior authorization available for different types of items or services based on each payer's implementation decisions. This could be confusing, particularly during the initial rollout of a new API such as this one. We also believe that a phased approach could delay the availability of electronic prior authorization for certain items and services, which may in turn reduce the overall adoption of the PARDD API by providers who do not see their specialties and services represented in the initial rollout of the available PARDD API for items and services.

We believe current industry pilots of alternatives for electronically exchanging prior authorization rules and requirements for documentation have already successfully demonstrated that payers may be able to meet the objectives in this proposed rule to improve prior authorization processes through the proposed API. The HL7 Community Roundtable recordings provide examples of these industry pilots and implementation of the HL7 IGs. This list is not exhaustive and other organizations may have additional examples. Industry would have additional implementations in place and sufficient experience with both required and proposed IGs to be able to implement the proposals by the proposed compliance dates on or after January 1, 2026.

Even if finalized as proposed, our proposal would provide a window of several years for implementation of the PARDD API. We acknowledge that payers might elect to maintain their existing prior authorization processes until the proposed implementation date, but we would encourage them to develop short-term mechanisms to make prior authorization information more easily understandable and publicly available to providers and patients. Some payers publish their prior authorization requirements on their individual websites or make them available through proprietary portals. However, these payer-specific portals and websites may be cumbersome because they each require individual access, login, and passwords. Furthermore, a provider may require a certain amount of patient and plan data to find the relevant detail for a specific item or service to determine prior authorization requirements. These portals or website options may be viable solutions until the PARDD API is built, made widely available, and providers gain experience using the tool. We invite readers of this proposed rule to provide information about other electronic, public-facing resources and options available for providers and patients to obtain prior authorization information and whether payers should increase education about these resources.

This PARDD API proposal could help both payers and providers mitigate some of the burdens of the prior authorization process and streamline the overall process. Payers that implement and maintain the proposed PARDD API might experience process improvements, fewer unnecessary requests or follow-up inquiries, and a decrease in denials or appeals. Such improvements could contribute to burden reduction for providers by reducing manual tasks and decreasing the volume of denials or appeals made.

We acknowledge that the new functionality of the API may require changes to the payer's customer service operations and procedures for providing support to patients during and after implementation. There may be questions about the required documentation, authorizations or denials about which both staff members and patients may need additional training and resources. We encourage payers to evaluate the procedural and operational changes as part of their implementation strategy, and to make appropriate resources available when the API is launched. While there are a number of resources available to ensure that patients receive quality services when accessing new technologies in health care, we invite feedback from commenters about available resources, such as the recent White House Blueprint for an AI Bill of Rights and others.

Finally, the anticipated benefits of the PARDD API are in part contingent upon providers using health IT products that can interact with payers' APIs. In section II.E. of this proposed rule, we propose a new measure for the MIPS Promoting Interoperability performance category for MIPS eligible clinicians and the Medicare Promoting Interoperability Program for eligible hospitals and CAHs that would require healthcare providers to request a prior authorization electronically using data from certified electronic health record technology (CEHRT) using a payer's PARDD API. We request comment on additional steps CMS could take to encourage providers and health IT developers to adopt the technology necessary to access payers' PARDD APIs. In addition, we note that on January 24, 2022, ONC published an RFI titled “Electronic Prior Authorization Standards, Implementation Specifications, and Certification Criteria” (87 FR 3475) requesting comment on how updates to the ONC Health IT Certification Program could support electronic prior authorization. We continue to work with ONC on ways to facilitate the adoption of standards to streamline data exchange, support interoperability, and increase efficiencies.

In summary, we propose 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), these impacted payers would be required to implement and maintain a FHIR PARDD API using technology conformant with certain standards and implementation specifications in 45 CFR 170.215. We propose to require that the PARDD API be populated with the payer's list of covered items and services, excluding drugs, for which prior authorization is required and accompanied by any documentation requirements. We further propose that the PARDD API would be required to include functionality to determine requirements for any other data, forms, or medical record documentation required by the payer for the items or services for which the provider is seeking prior authorization and while maintaining compliance with the HIPAA standard. Finally, the PARDD API responses from the payer to the provider would be required to include information regarding payer approval (and for how long) or denial (with a specific reason) of the request, or request more information from the provider to support the prior authorization request (see discussion in section II.D.4.a.). We are proposing these requirements for the proposed PARDD API at the CFR sections identified in Table 7.

We request comment on the proposal to require implementation of a Prior Authorization Requirements, Documentation, and Decision API.

b. Federal Funding for State Medicaid and CHIP Expenditures on Implementation of the PARDD API

Should our proposals be finalized as proposed, states operating Medicaid and CHIP programs may be able to access Federal matching funds to support their implementation of the proposed PARDD API. This proposed API is expected to lead to more efficient administration of Medicaid and CHIP state plans by supporting a more efficient prior authorization process, consistent with sections 1902(a)(4) and 2101(a) of the Act.

We would not consider state expenditures for implementing this proposal to be attributable to any covered Medicaid item or service within the definition of “medical assistance.” Thus, in Medicaid, CMS would not match these expenditures at the state's regular Federal medical assistance percentage (FMAP). However, Federal financial participation (FFP) under section 1903(a)(7) of the Act, at a rate of 50 percent, for the proper and efficient administration of the Medicaid state plan, might be available for state expenditures related to implementing this proposal for their Medicaid programs. We believe that using the PARDD API would help the state more efficiently administer its Medicaid program by increasing the efficiencies in the prior authorization process. For instance, using the PARDD API would enable administrative efficiencies by improving accuracy, and by helping reduce the number of denied and appealed prior authorization decisions.

States' expenditures to implement these proposed requirements could also 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, or installation 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 this proposed requirement.

States can request Medicaid enhanced FFP under section 1903(a)(3)(A)(i) or (B) of the Act through the APD process described in 45 CFR part 95, subpart F. States are reminded that 42 CFR 433.112(b)(12) and 433.116(c) in part require that any system for which they are receiving enhanced FFP under section 1903(a)(3)(A)(i) or (B) of the Act align with and incorporate the ONC Health Information Technology standards adopted in 45 CFR part 170, subpart B. The PARDD API would complement this requirement because this API would further interoperability by using standards adopted by ONC at 45 CFR 170.215. States are also reminded that 42 CFR 433.112(b)(10) and 433.116(c) 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.

Similarly, 42 CFR 433.112(b)(13) and 433.116(c) require the states to promote sharing, leverage, and re-use of Medicaid technologies and systems 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 can connect to the APIs proposed in this rule would be required as part of the technical requirements at 42 CFR 431.60(d) for all proposed APIs in this rule, including the PARDD API.

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, would apply to administrative claims for developing the APIs proposed in this rule.

We note that the temporary Medicaid FMAP increase available under section 6008 of the Families First Coronavirus Response Act (Pub. L. 116-127) does not apply to administrative expenditures.

c. Medicaid Expansion CHIP Programs

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 are proposing at 42 CFR 457.700(c) that for states with Medicaid Expansion CHIP programs, the proposals in this rule for Medicaid would apply to those programs rather than our proposals for a separate CHIP program. Functionally, our proposals are the same; however, for clarity, we are making explicit that the Medicaid requirements at §§ 431.60, 431.61, and 431.80 would apply to those programs rather than the separate CHIP requirements at §§ 457.730, 457.731, and 457.732.

4. Requirement for Payers To Provide Status of Prior Authorization and Reason for Denial of Prior Authorizations

a. Reason for Denial of Prior Authorization

Based on the stakeholder input described in this proposed rule, we believe the prior authorization process could be improved through better communication between payers and providers. One of the opportunities for better communication is timely and specific information about the reason for denying a prior authorization. Payers deny prior authorizations for different reasons. For example, a payer might deny a prior authorization because the payer does not consider the items or services to be medically necessary, the patient may have exceeded limits on allowable covered care for a given type of item or service, or documentation to support the request was missing or inadequate. Providing an understandable reason for a denial could allow a provider to 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. As noted in the 2021 AMA provider survey, 83 percent of providers report that prior authorization process issues lead to treatment abandonment, while 93 percent reported that process issues led to delays in care. Timely and clear information from payers about the status of a prior authorization or the reason(s) for denial could help mitigate these challenges and provide necessary information for submitting additional documentation or arranging for alternative treatment.

Impacted payers currently have the capability to send information to providers about the reason a prior authorization request has been denied either electronically or through other communication methods. For denials sent using the X12 278 standard, payers must use the codes from the designated X12 code list. For responses sent through portals, via fax or other means, payers may use proprietary codes or text to provide denial reasons. Consistent use of both technology and terminology (codes) to communicate denial information could mitigate some of the operational inefficiencies for providers so that they could more consistently interpret and react to a denied prior authorization request. This proposal to send a specific denial reason is one approach to address current inefficiencies.

Specifically, we propose 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 would be required to provide a specific reason for denied prior authorization decisions, excluding prior authorization decisions for drugs, regardless of the method used to send the prior authorization request. As stated under the proposal for the PARDD API, we are also proposing that responses about a prior authorization decision sent through the PARDD API from the payer to the provider would have to include information regarding 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. We are proposing these requirements regarding prior authorization decisions for 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 identified in Table 7.

Some payers that would be subject to this proposal are also subject to existing requirements to provide notice to patients or providers, or both, with the specific reasons for denial, and this proposal builds on those existing policies.

b. Existing Program-Specific Notice Requirements for Prior Authorization Denial Information

Some payers that would be affected by this proposed rule are required by existing Federal and state laws and regulations to notify providers and patients when an adverse decision is made about a prior authorization request. As previously discussed, our proposals to impose requirements on payers to communicate certain information to providers about prior authorization requests are intended to reinforce these existing Federal and state requirements. Our proposals would not alter or replace existing requirements to provide notice to patients, providers, or both. The proposed requirement to use the PARDD API to compile necessary data and populate the X12 278 transaction response to the provider, including whether an authorization request has been approved (and for how long), denied, with a reason for the denial, or request more information from the provider to support the prior authorization request, would support current Federal and state notice requirements for certain impacted payers. Clearly communicating denial reasons, in addition to the existing program notification requirements, could increase transparency, reduce burden, and improve efficiencies for both payers and providers.

This section of this proposed rule addresses additional denial notice requirements for certain impacted payers in the MA program, as well as Medicaid, and includes information on existing Medicaid beneficiary notice and fair hearing regulations in the context of prior authorization decisions in section II.D.6.b.

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. Nothing in this proposed rule would affect existing enrollee notification requirements in 42 CFR part 438 for Medicaid managed care plans and in 42 CFR part 457 for CHIP managed care entities as these requirements would remain in full effect. This proposed rule would fill a potential gap with respect to the information communicated to providers regarding a denial of a prior authorization request. We propose 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 PARDD API workflow process or other means, would be sufficient to satisfy the current requirement for notice to providers at 42 CFR 438.210(c). Under our proposal the payer would not be required to send the response via both the PARDD API process, which includes the denial reason, and a separate, additional notice in another manner with duplicate information.

We also remind all Medicaid managed care plans and CHIP managed care entities that would be subject to this proposed rule that their existing obligations to provide these required notices to enrollees would not be changed by the proposals in this proposed rule. These payers would still have to provide a separate written notice to the enrollee as required in 42 CFR 438.210(c) and (d) and 438.404.

Under the MA program, the actions that constitute an “organization determination” at 42 CFR 422.566(b) include a prior authorization (or “pre-service”) decision, as paragraph (b)(3) refers to 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. Under existing § 422.566(b), an organization determination would include a request for prior authorization using the PARDD API under the proposed provisions at 42 CFR 422.122. Existing MA program regulations are specific 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 at 42 CFR 422.568(e) regarding written notices for enrollees for standard organization determinations require that a notice for any denial for a covered service or item under 42 CFR 422.568(d) must: (1) use approved notice language in a readable and understandable form; (2) state the specific reasons for the denial; (3) inform the enrollee of their right to a reconsideration; (4) 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 (5) comply with any other notice requirements specified by CMS. Under the rules at 42 CFR 422.572 related to timeframes and notice requirements for expedited organization determinations, an MA organization must send a written denial notice to the enrollee, and physician involved as appropriate, whenever an MA plan's determination is partially or fully adverse to the enrollee. The rules at 42 CFR 422.572(a)(1) related to expedited organization determinations state that an MA organization that approves a request for expedited determination must make its determination and notify the enrollee, and the physician involved as appropriate, of its decision whether adverse or favorable and 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. Given that a physician is often involved in requesting an expedited organization determination on behalf of an enrollee, the rules related to notices explicitly require an MA plan to notify the enrollee and the physician involved, as appropriate, of its decision, whether adverse or favorable. The content of a 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: (1) inform the enrollee of their right to a reconsideration; (2) 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 (3) comply with any other requirements specified by CMS.

Because applicable integrated plans may be either MA plans for individuals with special needs who are dually eligible for Medicare and Medicaid, or Medicaid MCOs, the regulations regarding prior authorization processes that we are proposing for MA plans and Medicaid managed care plans would apply to applicable integrated plans as well. Similar rules at 42 CFR 422.631(d) already govern denial notices issued by applicable integrated plans to their enrollees. Integrated organization determination notices must be written in plain language, available in a language and format that is accessible to the enrollee, and explain: (1) the applicable integrated plan's determination; (2) the date the determination was made; (3) the date the determination will take effect; (4) the reasons for the determination; (5) the enrollee's right to file an integrated reconsideration and the ability for someone else to file an appeal on the enrollee's behalf; (6) procedures for exercising an enrollee's rights to an integrated reconsideration; (7) the circumstances under which expedited resolution is available and how to request it; and (8) 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 proposal would not change the content requirements for these written denial notices to enrollees but would supplement these notices by requiring applicable integrated plans to notify the provider of the reason for a denial of a prior authorization request.

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 the requirements of 45 CFR 147.136(b)(2)(ii)(E) and 29 CFR 2560.503-1(g) and (j).

5. Requirements for Prior Authorization Decision Timeframes and Communications

a. Impact of Delays in Prior Authorization Decisions: Background and Overview of Current Decision Timeframes

During the CMS listening sessions and other public meetings, we heard, largely from providers, that excessive wait time for prior authorization decisions could cause delays to patient care and may create medical risks in some cases. In most examples cited, 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. A 2017 AMA study reported that 39 percent of physicians stated that for those patients whose treatment requires prior authorization, the process can delay access to care. In that same study, between 19 and 57 percent of physicians reported that for those patients whose treatment requires prior authorization, the process may lead to patients abandoning their recommended course of treatment. As described earlier, in 2019, CMS conducted outreach to external stakeholders, including payers, providers, patients, vendors, and others, through listening sessions, interviews, observational visits, RFIs, and a special email box. The goal was to obtain information about how to improve the transparency, efficiency, and standardization of the prior authorization process. We received a large volume of comments about timeframes for processing prior authorizations, where commenters expressed 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. Some commenters noted that the large variations in payer prior authorization policies for the same items and services and the difficulty of discovering these payer's policies necessitates substantial provider staff research and time, which contributes to delays in care.

In this proposed rule, we use the term “standard” prior authorization to refer to non-expedited, non-urgent requests for prior authorization and the term “expedited” prior authorization to indicate an urgent request. These terms are used, as described here, in the provisions in 42 CFR 422.568, 422.570, 422.572, and 422.631 for MA organizations and applicable integrated plans, and 42 CFR 438.210(d) for Medicaid managed care plans, and we will use these terms for all regulated payers to whom the proposed policy in this section applies.

Under existing regulations for standard prior authorization decisions, MA organizations and applicable integrated plans must make a decision and send notice of that decision as expeditiously as the enrollee's condition requires, but may not exceed 14 calendar days following receipt of the request for an item or service. Under certain circumstances, a plan may extend this 14-calendar day timeframe consistent with the rules at § 422.568(b)(1)(i) or § 422.631(d)(2)(ii). Similarly, for standard prior authorization decisions, Medicaid managed care plans and CHIP managed care entities must make a decision and send notice of that decision as expeditiously as the beneficiary's condition requires within state-established time frames, but may also not exceed 14 calendar days following receipt of the request for an item or service.

Under these programs, if a provider indicates or the payer determines that following the standard timeframe could seriously jeopardize the patient's life, health or ability to attain, maintain, or regain maximum function, the MA plan, applicable integrated plan, Medicaid managed care plan, or CHIP managed care entity must make an expedited authorization decision and provide notice as expeditiously as the beneficiary's health condition requires, but no later than 72 hours after receiving the request. (42 CFR 422.570, 422.572, 422.631(c) and (d)(2)(iv)(A), and 438.210(d)(2), and through an existing cross reference at 42 CFR 457.1230(d))

Under existing Federal regulations for these payers, the enrollee may request an extension of up to 14 additional calendar days from the standard and expedited timeframes for the payer to make a decision on a prior authorization request for an item or service. Also, the payer may initiate the extension up to 14 additional calendar days if the payer needs additional information and the extension is in the enrollee or beneficiary's interest. For example, a provider may need to submit, or a payer may need to gather, additional information by consulting with additional providers with expertise in treating a condition to enable the payer to approve a prior authorization, and such information may not be able to be collected within the standard or expedited timeframe.

Under existing Federal CHIP regulations for FFS programs, prior authorization of health services must be completed within 14 days after receiving a request for services or in accordance with existing state law regarding prior authorization of health services. This means the CHIP must decide, and send notice of that decision, within 14 calendar days of receiving the request for a medical item or service by the provider. An extension of 14 days may be permitted if the enrollee requests the extension or if the provider or health plan determines that additional information is needed. For cases in which a provider indicates, or the payer determines, that the standard timeframe of 14 days could seriously jeopardize the enrollee's life; health; or ability to attain, maintain, or regain maximum function, the CHIP managed care entity must make an expedited authorization decision and provide notice no later than 72 hours after receiving the request.

Table 4 provides a summary of current Federal requirements for prior authorization decision timeframes that apply to the payers that would be affected by this proposed rule.

b. Proposals To Address Timeframes for Decisions on Standard and Expedited Prior Authorization Requests

Given our interest in improving patient care outcomes, and ensuring that patients have more timely access to services, we are proposing to establish, improve, or shorten Federal prior authorization timeframes for certain payers to respond to requests. We acknowledge that many of the payers that would be affected by this proposed rule have different requirements for prior authorization decision notice and appeal timeframes, and we are proposing to align prior authorization decision timeframes across these payers.

We are proposing that, beginning January 1, 2026, MA organizations and applicable integrated plans, Medicaid FFS programs, and CHIP FFS programs 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. We also propose that Medicaid FFS and CHIP FFS programs must provide notice 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 time frame is established under state law.

Assuming these proposals are finalized as proposed, we believe the 7-calendar day timeframe for standard decisions could be achieved when payers implement their APIs with improved access to documentation requirements, which could support greater use of electronic prior authorization, and more efficient business processes once implemented. For MA organizations, on or after January 1, 2026, items and services covered by the proposals in 42 CFR 422.122 would be affected by this proposal if finalized; for all other items and services existing timeframes would remain applicable.

Our proposal would not change the 72-hour deadline required by current Federal regulations, or the authority for an extension of that deadline, for expedited decisions made by MA organizations, applicable integrated plans, Medicaid managed care plans, and CHIP managed care entities. In addition, we do not propose to change existing Federal timeframes for standard and expedited 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 revisions we are proposing to § 422.568(b), we propose to redesignate existing § 422.568(b)(2) related to requests for Part B drugs for MA organizations to 42 CFR 422.568(b)(3).

For MA plans and applicable integrated plans, the timeframes would continue to apply to the notice that must be provided to the enrollee, while for Medicaid managed care plans and CHIP managed care entities, existing regulation requires that notices must be provided to both the provider and to the enrollee.

We are not proposing to change timeframes for prior authorization processes for QHPs 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. As summarized in Table 4, QHPs 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. Should this rule be finalized as proposed, QHPs on the FFEs would have the same timeframe for expedited authorization decisions as the other CMS payers affected by this provision: 72 hours. We believe that the benefits for the patient of a shorter timeframe for standard prior authorization decisions would outweigh the additional burden that plans on the Exchanges 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, we note that making changes to regulations applicable to all non-grandfathered group and individual market plans or coverage for consistency with our proposed approach here would be outside the scope of this proposed rulemaking.

We are not proposing to require that impacted payers approve a request for prior authorization should that payer 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 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 an 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 proposed rule, and consider how to efficiently support provider inquiries on status should responses or timeframes be missed. However, we note that some programs, such as Medicare Advantage, have regulations which include provisions for the failure to provide timely notice of an organization determination, which constitutes an adverse decision that may be appealed.

We seek comment 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 seek comment on what operational or procedural changes payers or providers would need to make in their workflows or systems to reduce decision timeframes from 14 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). Based on comments we received in response to the December 2020 CMS Interoperability rule (85 FR 82586), many providers wish to see further improvements in the timeliness of the decision process for prior authorizations. Some commenters, including payers, believe it is possible, given advances in technology, that responses to certain types of prior authorization requests could be made within 24 hours. Some payer and provider commenters agree that shorter prior authorization decision timeframes than those in this proposed rule could help to improve patient care, reduce burden, and improve equity. We wish to learn more about the process and technology barriers which prevent payers from meeting shorter timeframes than those in this proposed rule, and request input on whether MA organizations, applicable integrated plans, Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities might be able to provide notice of standard and expedited prior authorization decisions within, for example, 5 calendar days and 48 hours, respectively, and if not, what specific issues and obstacles prevent that.

We believe that as prior authorization processes become more efficient, shorter timeframes may be possible for certain types of requests. For example, if early adopters voluntarily implement and test the proposed PARDD API, and if some impacted payers voluntarily implement process improvements in methods of provider communication, automation, and documentation submission requirements, those payers may be able to accommodate shorter timeframes for certain types of prior authorization requests. Therefore, we solicit comments on whether implementation of the PARDD API as described in this proposed rule could yield process improvements of sufficient magnitude to support shorter decision timeframe requirements for prior authorization requests as suggested by many stakeholders, including payers, providers, vendors, and other interested parties, and described in reports cited earlier. We also seek comment on anticipated operational challenges of implementing the API that might affect a payer's ability to meet the proposed timeframes. Finally, we request comment from the public 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 this proposed rule.

In summary, to address prior authorization decision timeframes, we are proposing to require, beginning January 1, 2026, that MA organizations and applicable integrated plans, Medicaid FFS programs, and CHIP FFS programs must provide notice of prior authorization decisions as expeditiously as a beneficiary's health condition requires (for CHIP FFS, alternatively stated as in accordance with the medical needs of the patient), but no later than 7 calendar days for standard requests. We are proposing that Medicaid FFS and CHIP FFS programs must provide notice of prior authorization decisions as expeditiously as a beneficiary's health condition requires (for CHIP, alternatively stated as in accordance with the medical needs of the patient) but no later than 72 hours for expedited requests unless a shorter minimum time frame is established under state law. We are proposing to require that the same maximum timeframes apply to standard authorization decisions by Medicaid managed care plans and CHIP managed care entities beginning with the rating period that starts on or after January 1, 2026. Because Medicaid managed care plans at 42 CFR 438.210(d)(2) and CHIP managed care entities at § 457.1260(c)(3) respectively must already make an expedited authorization decision and provide notice as expeditiously as the beneficiary's health condition requires but no later than 72 hours after receipt of the request for service, we are not proposing to change those specific timeframes. However, for consistency with Medicaid FFS, we propose to add “unless a shorter minimum time frame is established under State law” to 42 CFR 438.210(d)(2).

We are proposing to amend 42 CFR 438.210(d)(2)(i) to clarify that the MCO, PIHP, or PAHP must make these decisions on shorter timeframes if required by the state. These proposals for the impacted payers in this proposed rule are being made at the CFR sections identified in Table 7.

If state law imposes a shorter timeframe for these decisions, that shorter time frame would govern for Medicaid FFS, CHIP FFS, Medicaid managed care plans, and CHIP managed care entities. If our proposed regulation is finalized as proposed, and state law imposes a longer time frame, payers could comply with both the Federal and state regulations by complying with the shorter Federal time frame. State laws would not apply to MA plans, based on preemption language at 42 CFR 422.402 which states that the 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. Therefore, MA plans would not be required to comply with timeframes imposed by the states, but rather with the time frames set by this proposed rule.

We are not proposing to change any existing Federal 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 proposed for these payers to provide notice of standard determinations, we are proposing a corresponding amendment to the CFR sections identified in Table 7. Specifically, 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 does not apply to the Medicaid and CHIP managed care provisions listed in Table 7 since the provision at 42 CFR 438.210(d)(2) requires managed care plans 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.

6. Requirements for Timing of Notifications Related to Prior Authorization Decisions

This section proposes requirements for the timing of notifications sent by certain payers to patients regarding prior authorization decisions. This proposal also applies to most impacted payers. However, we are not proposing to address proposals for notifications to the QHPs on the FFEs, for the same reasons we provided in section II.D.5.b.

a. MA Organizations

MA organizations are currently required to provide notifications to enrollees of decisions regarding coverage, called organization determinations, which includes decisions regarding prior authorizations. To support more timely decisions and communication of those decisions, we propose to amend the CFR sections identified in Table 5 to require MA organizations to 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 for a medical item or service. We are also proposing to revise 42 CFR 422.568 and move the existing language at 42 CFR 422.568(b)(1)(i) and (ii) to 42 CFR 422.568(b)(2). We propose to move the language previously at 42 CFR 422.568(b)(2) to new paragraph (b)(3). We emphasize that this proposed change to the regulation text structure does not change current requirements and that this proposed 7 calendar day timeframe would remain subject to the existing requirements (currently at 42 CFR 422.568(b)(1)(i), proposed to be at 42 CFR 422.568(b)(2)) related to the limited circumstances under which an MA organization may extend the adjudication timeframe by up to 14 additional calendar days. We are not proposing to change the current 72-hour decision timeframe for expedited requests or the availability of the 14-calendar day extension to make a determination under 42 CFR 422.568 for standard requests and 42 CFR 422.572 for expedited requests.

Other than the proposal to require an MA plan to send notification of prior authorization decisions to providers electronically in section II.D.3.a. of this proposed rule, we are not proposing changes to the requirements for an MA plan to notify enrollees of decisions on organization determinations. For example, should an MA plan deny a prior authorization request, it must send written notice to the enrollee under the requirements for standard requests at 42 CFR 422.568(d) and (e) and for expedited requests at 42 CFR 422.572(e).

Consistent with policies for MA organizations, we are proposing enrollee notification requirements for the integrated organization determination process described at 42 CFR 422.631. Specifically, we propose to amend the CFR sections identified in Table 5 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 regarding coverage for a medical item or service. We are not proposing to change the current 72-hour requirement for decisions and notice on expedited requests at 42 CFR 422.631(d)(2)(iv)(A). Under our proposal, the authority for a 14-calendar day extension of the timeframe, in 42 CFR 422.631(d)(2)(ii), would remain unchanged. Also, consistent with the proposed changes to rules for other MA organizations, we are proposing to amend the CFR sections identified in Table 5 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 7-calendar day timeframe, rather than the current 14 calendar day timeframe for an integrated organization determination. These proposed changes would also apply to applicable integrated plans that are Medicaid managed care organizations (MCOs), as defined in 42 CFR 438.2, because, per 42 CFR 438.210(d)(4), 42 CFR 422.631 also applies to these Medicaid plans. These proposed amendments are consistent with changes for other Medicaid managed care plans being proposed at 42 CFR 438.210(d)(1) and (2), discussed later. As with the proposed requirements for MA organizations, our proposal is limited to the timeframes for standard determinations, and we are not proposing changes to the timeline for expedited integrated organization determinations, extensions, or the requirements for notice to enrollees.

b. Medicaid Fee-for-Service, Including Beneficiary Notice and Fair Hearings

For the Medicaid FFS program we are proposing, at the CFR sections identified in Table 5, to specify regulatory timeframes to provide notice of decisions on both expedited and standard prior authorization requests. The new requirements would apply to prior authorization decisions beginning January 1, 2026.

Under this proposal for Medicaid FFS, which would appear at 42 CFR 440.230(e)(1), notice of the state Medicaid program's decision regarding an expedited request for prior authorization would 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 time frame is established under state law. Notice of a decision on a standard request for a prior authorization would 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 time frame 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 could be extended by up to 14 calendar days. Such extensions may be justified and in the beneficiary's interest if medical evidence from outside providers is needed to support the request, or there are other circumstances identified by either the provider or the beneficiary.

Independent of this proposed 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 authorizations requests for Medicaid FFS, and expects to do so in the future. These existing Medicaid beneficiary notice and fair hearing requirements will remain in full effect without change, regardless of how or if the API proposals are finalized.

Specifically, the current Medicaid notice regulations at 42 CFR 435.917 apply to all prior authorization decisions and require a state 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.” The existing regulations do not specify a timeframe for providing notice to a beneficiary of the state decision, nor do we propose such a change to these regulations herein. When a state denies the prior authorization request in whole or in part, the beneficiary notice must include, in addition to the content described in 42 CFR 435.917, the notice content described in 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. These requirements are separate from, and independent of, the new timeline for provider notice that we are proposing at 42 CFR 440.230(e)(1).

Existing regulations at 42 CFR 431.220(a)(1) require the state to provide beneficiaries the opportunity to request a fair hearing if the state fails to act on a claim with reasonable promptness. We consider a prior authorization request a type of claim. Therefore, beneficiaries have the right to a fair hearing when the state fails to make prior authorization decisions with reasonable promptness.

Existing regulations at 42 CFR 431.220(a)(1) require that states grant Medicaid beneficiaries the opportunity for a fair hearing whenever a state takes an action as defined in 42 CFR 431.201. This definition includes “a termination, suspension of, or reduction in covered benefits or services,” which, in turn, includes any termination, suspension of, or reduction in benefits or services for which there is a current approved prior authorization. Under existing regulations at 42 CFR 431.211, a state must provide an individual at least 10 days advance notice prior to taking an action and must afford the beneficiary the right to the continuation of services pending the resolution of the state fair hearing, in accordance with 42 CFR 431.230. Therefore, the state must provide advance notice to beneficiaries of any termination, suspension of, or reduction in benefits or services for which there is a current approved prior authorization and must afford the beneficiary the right to request a fair hearing, in accordance with 42 CFR part 431, subpart E. This advance notice requirement would not be affected by any of the proposed changes in this proposed rule.

To make it explicit that existing Medicaid beneficiary notice and fair hearing rights apply to Medicaid FFS prior authorization decisions, independent of the notification timeframe proposals elsewhere in this proposed rule, we are proposing several clarifying updates to the existing regulations at 42 CFR 431.201, 431.220, and 431.917, and a new 42 CFR 440.230(e)(2). These proposed changes, if finalized as proposed, would not change Medicaid notice or fair hearing policy or operational requirements for states. Additionally, these proposed changes, if finalized as proposed, would be applicable upon the effective date of the final rule, and thus would take effect sooner than the proposed timeframes for issuing provider notice of a prior authorization decision in 42 CFR 440.230(e)(1). Finally, we note that these proposed Medicaid beneficiary notice and fair hearing regulation changes seek only to clarify, not change, existing policy. Therefore, our interpretation of how existing regulations apply to Medicaid FFS prior authorization decisions, as previously described, applies today and will continue to apply in the future, regardless of whether these changes are finalized as proposed.

We propose the following changes to clarify how existing Medicaid beneficiary notice and fair hearing regulations apply to Medicaid FFS prior authorization decisions:

• Modification of the headers in 42 CFR 435.917 to clarify that the information in this section relates broadly to eligibility, benefits, and services notices. Specifically, we propose to remove the word “eligibility” from the headers of paragraphs (a) and (b) of 42 CFR 435.917 to reflect the content of these paragraphs more accurately.
• Revision of the definition of an “action” at 42 CFR 431.201 to include termination, suspension of, or reduction in benefits or services for which there is a current approved prior authorization. We also propose to revise the definition of the term “action” to improve readability by numbering the components of the definition, rather than listing them in a single paragraph.
• Modification of 42 CFR 431.220 to add a new paragraph (a)(1)(vi) to add prior authorization decisions to the list of situations in which a state must provide the opportunity for a fair hearing in circumstances where the beneficiary believes the agency has taken an action erroneously, denied their claim for eligibility or for covered benefits or services, or issued a determination of an individual's liability, or has not acted upon the claim with reasonable promptness.
• Revision of 42 CFR 435.917(b)(2) to include, among the types of notices that need to comply with the requirements of 42 CFR 431.210, a reference to denials of, or changes in, benefits and services for beneficiaries receiving medical assistance. This would ensure that individuals receiving medical assistance who are denied benefits or services would receive a notice that includes the content at 42 CFR 431.210, which requires that notices include a clear statement of the specific reasons supporting the intended action.
• Addition of a new 42 CFR 440.230(e)(2) to specify that states must provide beneficiaries with notice of the Medicaid agency's prior authorization decisions in accordance with 42 CFR 435.917 and provide fair hearing rights, including advance notice, in accordance with 42 CFR part 431, subpart E.

We make these proposed changes at the CFR sections identified in Table 6.

Readers are reminded that the Medicaid beneficiary notice requirements at 42 CFR 435.917 and 431.210 through 431.214, including all proposed revisions and additions, such as the proposal at 42 CFR 440.320(e)(2) previously discussed, apply to the written notice provided by the state to the beneficiary. These requirements, including the provision of fair hearing rights, are long-standing and exist independently of the proposed PARDD API provisions of this proposed rule, which represents an interaction between the payer and the provider. Nor do the Medicaid beneficiary notice requirements conflict with the communication of denial reasons to the provider under the proposals in section II.D.4.a. of this proposed rule.

The current application of existing notice and fair hearing requirements to Medicaid FFS prior authorization decisions, including the proposed clarifications as previously discussed, is consistent with current regulations for notice and appeal rights for managed care prior authorization decisions. These are sometimes referred to as service authorizations or adverse benefit determinations.

In summary, our existing Medicaid beneficiary notice and fair hearing regulations apply to Medicaid FFS prior authorization decisions. We propose several revisions and additions to these regulations that would clarify, but not change, their application to Medicaid FFS prior authorization decisions. These include revisions to the definition of “action” and making explicit that prior authorization denials are subject to the same notice and fair hearing rights as other denials of services. These revisions would become applicable upon the effective date of the final rule. We are proposing these clarifications regarding the application of existing Medicaid beneficiary notice and fair hearing requirements at the CFR sections identified in Table 6. We seek comments both on our proposals and on how states currently apply these notice and fair hearing rights to prior authorization decisions.

c. Medicaid Managed Care

To implement the proposed authorization timeframes for Medicaid managed care, we also propose to revise the CFR sections identified in Table 5. Under our proposal, the new timeframes for Medicaid managed care plans to provide notice of decisions on standard (non-expedited) prior authorization requests would apply beginning with the rating period that starts on or after January 1, 2026.

We propose 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 within state-established timeframes that may not exceed 7 calendar days following the plan's receipt of the request for service. We propose to specify the standard authorization requirements by compliance date by leaving the section header “Standard authorization decisions” as 438.210(d)(1) and redesignating standard authorization timeframes as 438.210(d)(1)(i)(A) and (B). We also proposed to redesignate authorization decision timeframe extensions from § 438.210(d)(1)(i) and (ii) to § 438.210(d)(1)(ii)(A) and (B) and proposed to make slight revisions to the text for readability. 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). Section 438.404 and other regulations governing appeal rights in 42 CFR part 438, subpart F, would continue to apply. This is also consistent with how the definition of “adverse benefit determination” in 42 CFR 438.400(b) includes a Medicaid managed care plan failing to make an authorization decision within the regulatory timeframes. We note that 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 proposed rule would change these requirements. Finally, because some Medicaid MCOs are applicable integrated plans as defined in 42 CFR 438.2, our proposal related to 42 CFR 422.631(d) would apply to those plans.

We are not proposing to change the required timeframes for expedited decisions at 42 CFR 438.210(d)(2), but we are proposing to amend the CFR sections identified in Table 5 to clarify that the MCO, PIHP, or PAHP must make these decisions on shorter timeframes if the state requires shorter timeframes. However, as described previously, we are soliciting comment on the possible alternative of a shorter time frame of 48 hours maximum, and would use that information to determine if expedited decisions should be required in less time, and as expeditiously as the beneficiary's condition requires. We are not proposing any changes to the authority for a 14-day extension provided at 42 CFR 438.210(d)(2)(ii). The proposal to amend 42 CFR 438.210(d) 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).

d. CHIP Fee-for-Service and Managed Care

To implement the proposed prior authorization timeframes for CHIP, we propose to revise certain policies affecting the timing for making decisions on prior authorization requests under the CHIP Fee-for-Service and Managed Care program. These changes are summarized in Table 5. 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. 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 propose 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. We believe timely prior authorization decisions are an important beneficiary protection, and CHIP beneficiaries should be afforded the same decision timeframes as Medicaid and Medicare beneficiaries.

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 are not proposing any changes to this requirement, as it already applies to decisions related to the prior authorization of services.

Overall, we believe that the decision and notification timeframes proposed for certain impacted payers in this rule 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. We believe these proposals would make substantive improvements to the care experience for patients and lead to better health outcomes. In turn, better health outcomes would contribute to more efficient use of program resources.

We request comments on these proposals, specifically comments that would provide insight on any unintended consequences of these proposed policies to improve the decision or notification timeframes for prior authorizations.

7. Extensions, Exemptions, and Exceptions

a. Extensions and Exemptions for Medicaid and CHIP FFS Programs

Should our proposals regarding the PARDD API be finalized as proposed, we would strongly encourage state Medicaid and CHIP FFS programs to implement the PARDD API as soon as possible, due to the many anticipated benefits of the API discussed in this section. However, we also recognize that state Medicaid and CHIP FFS agencies may face certain unique circumstances that would not apply to other impacted payers. To address these concerns, we are proposing a process through which states may seek an extension of, and, in specific circumstances, an exemption from, the PARDD API requirements. We propose the following:

(1) Extension

At the regulation citations identified in Table 7, we propose to provide state Medicaid FFS and CHIP FFS programs the opportunity to request a one-time extension of up to 1 year to implement the PARDD API specified at 42 CFR 431.80(b) and 457.732(b). Some states may be unable to meet the proposed compliance date due to challenges related to securing needed funding for necessary contracting and staff resources in time to develop and implement the API requirements, depending on when the final rule is published in relation to a state's fiscal year, legislative session, budget process, and related timeline. Some states may need to initiate a public procurement process to secure contractors with the necessary skills to support a state's implementation of these proposed API policies. The timeline for an openly competed procurement process, together with the time needed to onboard the contractor and develop the API, can be lengthy for states. A state might need to hire new staff with the necessary skillset to implement this policy. The time needed to initiate the public employee hiring process, vet, hire, and onboard the new staff may make meeting the proposed compliance timeline difficult because, generally speaking, public employee hiring processes include stricter guidelines and longer time-to-hire periods than other sectors. Furthermore, states are currently responding to the effects of the COVID-19 public health emergency, and their regular operational resources are over-extended. Unwinding from the COVID-19 public health emergency is also expected to require significant IT resources, which could have an impact on future IT work. In all such situations, a state might need more time than other impacted payers to implement the PARDD API requirements. The 1-year extension that we propose could help mitigate the challenges. We considered delaying implementation of the provisions in this proposed rule an additional year for states, but decided that it would be better to propose to have only those states that needed an extension apply because states vary in their level of technical expertise and ability to recruit staff and secure contracts.

Should the proposal for this API be finalized as proposed, states would be permitted to submit a written application for a one-time, one-year extension as a part of their annual APD for MMIS operations expenditures. The state's request would have to include the following: (1) a narrative justification describing the specific reasons why the state cannot reasonably satisfy the requirement(s) by the compliance date, and why those reasons resulted from circumstances that are unique to the agency operating the Medicaid and/or CHIP FFS program (versus other types of impacted payers); (2) a report on completed and ongoing state implementation activities to evidence a good faith effort toward compliance; and (3) a comprehensive plan to meet the PARDD API requirements no later than 1 year after the compliance date.

Under this proposal, CMS would approve an extension if, based on the information provided in the APD, CMS determines that the request adequately establishes a need to delay implementation, and that the state has a comprehensive plan to implement the proposed requirements no later than 1 year after the compliance date. We also solicit comments on whether our proposal would adequately address the unique circumstances that affect states and that might make timely compliance with the proposed API requirement difficult for states.

(2) Exemption

At the CFR sections identified in Table 7, we propose to permit state Medicaid FFS programs to request an exemption from the PARDD API requirements when at least 90 percent of the state's Medicaid beneficiaries are enrolled in Medicaid managed care organizations as defined in 42 CFR 438.2. Likewise, we propose that separate CHIP FFS programs could request an exemption from the PARDD API requirements if at least 90 percent of the state's separate CHIP beneficiaries are enrolled in CHIP managed care entities as defined at 42 CFR 457.10. In this circumstance, the time and resources that the state would need to expend to implement the PARDD API requirements for a small FFS population may outweigh the benefits of implementing and maintaining the API. Unlike other impacted payers, state Medicaid and CHIP FFS programs do not have a diversity of plans to balance implementation costs for those plans with low enrollment. If there is low enrollment in a state Medicaid or CHIP FFS program, there is no potential for the technology to be leveraged for additional beneficiaries. States, unlike other payers, do not maintain additional lines of business.

We acknowledge that the proposed exemption could mean that most beneficiaries enrolled with exempted Medicaid or CHIP FFS programs, would not receive the full benefits of having this API available to facilitate the prior authorization exchange between payers and providers. To address this, we propose that states that are granted an exemption would be expected to implement an alternative plan to enable the efficient electronic exchange and accessibility of prior authorization information for those beneficiaries who are served under the FFS program and to ensure that enrolled providers will have efficient electronic access to the same information through other means, to help ensure that Medicaid or CHIP services are provided with reasonable promptness and in a manner consistent with the simplicity of administration and in the best interests of those beneficiaries who are served under the FFS program.

We propose that a state could submit a written request for an exemption from the requirements for the PARDD API as part of its annual APD for MMIS operations expenditures prior to the date by which the state would otherwise need to comply with the requirements (which may be extended by 1 year if the state receives an extension). For Medicaid exemption requests, the state would be required to include documentation that it meets the criteria for the exemption based on enrollment data from the most recent CMS “Medicaid Managed Care Enrollment and Program Characteristics” report. For a CHIP FFS exemption, the state's request would have to include enrollment data from Section 5 of the most recently accepted state submission to the CARTS. The state would also be required to include in its request, information about an alternative plan to ensure that providers will have efficient electronic access to the same information through other means while the exemption is in effect. CMS would grant the exemption if the state establishes to CMS's satisfaction that it meets the criteria for the exemption and has established such an alternative plan.

Once an exemption has been approved, we propose that the exemption would expire if either of the following two scenarios occurs: (1) based on the 3 previous years of available, finalized Medicaid T-MSIS and/or CHIP CARTS managed care and FFS enrollment data, the State's managed care enrollment for 2 of the previous 3 years is below 90 percent; or (2) CMS has approved a State plan amendment, waiver, or waiver amendment that would significantly reduce the share of beneficiaries enrolled in managed care and the anticipated shift in enrollment is confirmed by available, finalized Medicaid T-MSIS and/or CHIP CARTS managed care and FFS enrollment data.

For the first scenario, CMS recognizes that there may be circumstances where a state's managed care enrollment may fluctuate slightly below the 90 percent threshold in 1 year, and yet return to above 90 percent the next year. To help reduce the possible burden on exempted states experiencing this type of temporary fluctuation in managed care enrollment, CMS would consider data from the 3 previous years of available, finalized Medicaid T-MSIS and/or CHIP CARTS managed care and FFS enrollment data. We propose that if the state's managed care enrollment for 2 of the previous 3 years is below 90 percent, the state's exemption would expire.

We propose that a state would be required to provide written notification to CMS that the state no longer qualifies for the PARDD API exemption when data confirm that there has been a shift from managed care enrollment to FFS enrollment resulting in the State's managed care enrollment falling below the 90 percent threshold for 2 of the previous 3 years. We propose that the written notification 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 confirming that there has been the requisite shift from managed care enrollment to FFS enrollment in 2 of the 3 previous years.

For the second scenario, we recognize that there may be state plan amendments, waivers, or waiver amendments that would result in a shift from managed care enrollment to FFS enrollment. Additionally, there may be instances where anticipated enrollment shifts may not be fully realized due to certain circumstances. We propose that a state would be required to provide written notification to CMS that the state no longer qualifies for the PARDD API exemption when data confirm that there has been a shift from managed care enrollment to FFS enrollment as anticipated in the state plan amendment or waiver approval. We propose that the written notification 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 confirming that there has been the requisite shift from managed care enrollment to FFS enrollment.

Regardless of why the exemption expires, if it expires, the state would be required to obtain CMS's approval of a timeline for compliance with the PARDD API requirements for the state's Medicaid FFS and/or CHIP FFS populations within two years of the expiration date of the exemption.

For Medicaid and CHIP managed care, we are not proposing an extension process because we believe that managed care plans are actively working to develop the necessary IT infrastructure to be able to comply with the existing requirements at 42 CFR parts 438 and 457 and because many of these plans might benefit from efficiencies based on the variety of plan types that they offer. Many managed care plans are part of parent organizations that maintain multiple lines of business, including Medicaid managed care plans and plans sold on the Exchanges. As discussed in the CMS Interoperability and Patient Access final rule (85 FR 25607, 25612, and 25620), work done by these organizations can benefit all lines of business and, as such, we do not believe that the proposals in this rule impose undue burden or could not be achieved by the compliance date. We are soliciting comments on our assumptions regarding the scope of resources and ability of managed care parent organizations to achieve economies of scale when implementing the proposed API.

Further, we seek comment on whether an extension process would be warranted for certain managed care plans to provide additional time for the plan to comply with the proposed requirement at 42 CFR 438.80(b) (which cross references 42 CFR 438.242(b)(7)) for Medicaid managed care plans and at proposed 42 CFR 457.732(b) (which would cross reference 42 CFR 457.1233(d)) for CHIP managed care entities. While we are not proposing such a process for managed care plans and entities and do not believe one is necessary, we are open to evaluating options for possible future rulemaking. Were we to adopt an extension process for these managed care plans and entities, what criteria should a managed care plan or entity meet to qualify for an extension? Should the criteria include enrollment size, plan type, or certain unique plan characteristics that could hinder their achievement of the proposed requirements by the proposed compliance date? We also seek comment on whether, were we to propose such a process for Medicaid managed care plans or CHIP managed care entities, the entity responsible for evaluating the criteria and exception evaluation process should be the state and whether states could implement the exception evaluation process with available resources. Consistent with the exception process proposed for QHP issuers on the FFEs at 45 CFR 156.222(c), we would expect managed care plans seeking extensions to provide, at a minimum, a narrative justification describing the reasons why a plan or entity cannot reasonably satisfy the requirements by the proposed compliance date, an explanation of the impact of non-compliance upon enrollees, an explanation of the current or proposed means of providing electronic health information to providers, and a comprehensive plan with a timeline to achieve compliance.

We request comment on the proposed extension and exemption processes.

b. Exception for QHP Issuers

For QHP issuers on the FFEs, we propose an exception process to the PARDD API proposal at the regulation citations identified in Table 7. We propose that if an issuer applying for QHP certification to be offered through an FFE believes it cannot satisfy the proposed requirements at 45 CFR 156.223(b) for the PARDD API, the issuer would have to include as part of its QHP application a narrative justification describing the reasons why the issuer could not 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 health information to providers, and solutions and a timeline to achieve compliance with the requirements of this section. We propose that the FFE may grant an exception to the requirements at 45 CFR 156.223(b) for the PARDD API if it determines that making qualified health plans of such issuer available through such FFE 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 issuer to offer qualified health plans through the FFE. This proposal would be 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). For instance, as noted in that final rule, that exception could apply to small issuers, financially vulnerable issuers, or new entrants to the FFEs that demonstrate that deploying FHIR API technology consistent with the required interoperability standards would pose a significant barrier to the issuer's ability to provide coverage to patients, and not certifying the issuer's QHP or QHPs would result in patients having few or no plan options in certain areas. We believe that having a QHP issuer offer QHPs through an FFE generally is in the best interest of patients and would not want patients to have to go without access to QHP coverage because the issuer was unable to implement this API.

In summary, we propose to permit certain impacted payers (state Medicaid and CHIP FFS programs and QHP issuers on the FFEs) to apply for an extension, exemption, or exception, as applicable, from implementing the proposed PARDD API. We propose that these programs would submit and be granted approval for an extension or exemption as part of applicable established processes. We propose that submission requirements would include certain documentation identified in the regulatory citations in Table 7.

8. Public Reporting of Prior Authorization Metrics

We are proposing to require impacted payers to publicly report certain aggregated metrics about prior authorization by posting them directly on the payer's website or via a publicly accessible hyperlink(s). This proposed reporting would be at the organizational level for MA, the state level for Medicaid and CHIP FFS, the plan level for Medicaid and CHIP managed care, and the issuer level for QHP issuers on the FFEs. We propose these levels of reporting for each impacted payer because we believe these represent the appropriate organizational level for which aggregated data would be meaningful to a patient or provider to understand an entity's performance on timeframes for approvals, on volumes of denials and appeals for prior authorization.

For example, an MA organization will generally have multiple contracts and it is not uncommon for these organizations to have more than one contract for the same service area. Ideally, reports would present true aggregate figures, which would be at the organizational level. Medicaid and CHIP managed care would be reported at the plan level so that beneficiaries could compare and states could evaluate plans within the state. QHP issuers report on quality improvement strategies consistent with standards of section 1311(g) of the Affordable Care Act (45 CFR 156.20), which is at the issuer level, and would include information for the plans under their purview. Such reporting of prior authorization data at the issuer level would be consistent with their quality reports.

Prior authorization data would be compiled from multiple sources, on multiple measures and individuals, and compiled into aggregate data, or summary data, for purposes of public reporting and statistical analysis. Payers may use the detailed information to assess their internal performance, understand trends and determine where improvements may be necessary. At the same time, they would be able to share the aggregate data for all programs with the public. We believe the availability of such data from the payers could contribute to improvements in the prior authorization process. Should this proposed rule be finalized as proposed, we believe that, as payers create and analyze these reports, there would use the data to learn about their own performance. Additionally, we believe that the public availability of prior authorization decision data would further transparency in consumer information. When some patients are looking for a new plan, they may compare several factors including, but not limited to, access to care or authorizations, premiums, benefits, and cost sharing or coinsurance. Both access to care and transparency regarding prior authorization processes could be important considerations.

Some providers may find metrics about prior authorization approvals or appeals useful when selecting payer networks, or to be aware of the trends in performance of different payers. Providers should have access to information about how they will be able to treat their patients, and whether it will be possible to do so in a manner they believe will support value-based care and services that are appropriate and necessary for each patient's health. The legal authority for requiring such public reporting is discussed further in section II.D.10. of this proposed rule.

We propose that for each metric listed, data would be reported in aggregate for all items and services. We are not proposing that payers report on categories of items and services, but rather aggregate the information as totals or percentages of total items and services, as outlined in each proposed requirement listed in this section of this rule. Aggregate data could allow each organization to examine trends and obtain insight into their own performance. As noted elsewhere in this proposed rule, we are excluding drugs that could be covered by the impacted payers in this proposed rule. For example, this would include outpatient drugs, drugs that may be prescribed, those that may be administered by a provider, or those that may be administered in a pharmacy or hospital. We propose that impacted payers 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.

We do not propose a format for how payers would present the aggregated data in the reports, but we encourage them to consider readability, and accessibility in preparing the data for viewing and comprehension. We request comments from all stakeholders, including payers, providers, and consumers, 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.

By having access to the requirements for prior authorization of items and services, and data about prior authorization decisions, patients and providers would have a better understanding of a payer's prior authorization review and approval processes. Such information may be helpful for some patients when making decisions at the time of open enrollment, special enrollment, or plan selection throughout the year.

The first set of data to be publicly available under our proposal would reflect current practices, rather than payer behavior based on compliance with this proposed rule. However, we anticipate that, over time, data might show improvements after implementation of our proposals regarding the PARDD API and timeframes for prior authorization decisions. In addition, year-over-year comparisons could demonstrate positive, or negative, trends, which alone could be useful information for patients who are making enrollment decisions. We acknowledge that not all patients have a choice in enrolling with payers, such as with the Medicaid and CHIP FFS programs. Nonetheless, publicly available data would aid interested providers and patients to generally understand payer performance with respect to prior authorization processes for decisions, approvals, denials, and appeals.

CMS would enforce the requirements based on the existing compliance policies for the impacted payers. To facilitate the incorporation of such data more directly into a consumer-friendly comparison tool, we may propose in future rulemaking to use these data to help develop quality measures to incorporate into quality star ratings across certain payer programs, specifically for MA and QHP issuers on the FFEs.

In summary, we propose that, beginning in 2026, and by March 31 of that year, impacted payers must annually report certain aggregated prior authorization metrics from the previous year. These reports must be posted on websites or publicly available hyperlinks. We are making this proposal at the CFR sections identified in Table 7.

For Medicaid managed care, we propose to replace the current provision at the CFR sections identified in Table 7 which addresses the applicability date for the provisions in that section, with this new requirement. The current provision was added in 2016 to clarify that the previous requirements would remain in effect until the new provisions began starting with rating periods beginning on or after July 1, 2017. As several rating periods have passed since July 1, 2017, we do not believe this clarifying text is needed. Our proposal would apply to CHIP managed care entities through operation of the cross-reference to 42 CFR 438.210, which is currently in 42 CFR 457.1230(d). We propose to accomplish this by removing the current exception for complying with paragraph 42 CFR 438.210(f). As such, the prior authorization metrics policies would be applicable to CHIP managed care through the cross-reference at 42 CFR 457.1230(d) to 42 CFR 438.210.

We request comments on the proposal for reporting metrics on prior authorization, for example, on the proposed types of data to be included in the report, on the proposal to report data in aggregate by items and services, on the proposed reporting timeframe, the number of reports, and if there are any other types of data that could be useful to payers, providers, and patients. Given that use of the PARDD API would develop over time, we also request comment on the timing for adding a metric similar to those proposed for the Patient Access API in section II.A, for the total number of prior authorization requests received via the PARDD API. This information could be useful for evaluating the degree to which API-facilitated requests would grow over time.

9. “Gold-Carding” Programs for Prior Authorization

During the CMS listening sessions, we heard about the potential for additional opportunities for payers to support efficiencies in the prior authorization process, including discretion about when to require prior authorization and basing such decisions on data and provider performance. For example, prior authorization is sometimes required for certain items and services that are almost always approved. Some providers have demonstrated a consistent history of complying with all payer requirements for the submission of documentation to support a request. Some payers have implemented what they term “gold-carding” or similar programs to relax or reduce prior authorization requirements for providers that have demonstrated a consistent pattern of compliance. In such programs, providers are relieved of requirements to submit prior authorization requests based on data indicating their adherence to submission requirements, appropriate utilization of items or services, or other evidence-driven criteria. Stakeholders said that the prior authorization process could be significantly more efficient and cost-effective for all parties if these programs were more broadly implemented.

Under the MA program, MA organizations may develop and apply prior authorization policies, make prior authorization decisions, and have the discretion to implement gold-carding programs within each contracted plan. CMS uses a similar approach to gold-carding in the Medicare FFS Review Choice Demonstration for Home Health Services, under which home health agencies in demonstration states that select certain review choice options and have a review affirmation rate or claim approval rate of 90 percent or greater over 6 months are given the option to continue in the pre-claim review option or choose a selective post-payment review or spot check review process.

We believe the use of gold-carding and similar prior authorization reduction programs could help alleviate provider burden. We are also aware that some states have begun to enact gold-carding programs to address provider and patient complaints about access to healthcare services. We encourage payers to adopt gold-carding approaches that would allow prior authorization exemptions or more streamlined reviews for certain providers who have demonstrated compliance with requirements. By taking this step, payers could join CMS in helping to build an infrastructure that would allow clinicians to deliver care in a timely and value-based manner. We seek comment for consideration for future rulemaking on how to measure whether and how such gold-carding or prior authorization exemption programs could reduce provider and payer burden, and improve services to patients. In particular, we seek comment on how CMS and other payers could ensure that such programs benefit diverse populations, including individuals in rural areas, individuals with disabilities, individuals with chronic illnesses, small and minority providers, and providers who disproportionately serve minority and underserved communities.

To further encourage the adoption and establishment of gold-carding programs, we are considering including a gold-carding measure as a factor in quality ratings for MA organizations and QHPs as a way for these payers to raise their scores in the quality star ratings. We seek comment for potential future rulemaking on the incorporation of such a measure into star ratings for these organizations. We also considered proposing gold-carding as a requirement in payer's prior authorization policies and seek comment on how such programs could be structured to meet such a potential requirement.

10. Statutory Authorities To Require Improvements in Prior Authorization Processes, Decision and Notification Timeframe Proposals

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 under time limitations established by the Secretary, but not later than 72 hours of the time of receipt of the request. This proposal serves to ensure that MA organizations carry out their responsibilities under section 1852 of the Act in a consistent and standardized fashion.

In the interest of ensuring that MA organizations continue to use appropriate standards, process organization determinations in a timely manner, and provide enrollees with appropriate access to care under the authorities referenced earlier, we are proposing to require that MA organizations implement certain APIs that provide information about the coverage and documentation requirements for prior authorization, that they respond to prior authorization requests with the status of that request, and that they meet certain timeframes for making decisions on prior authorization requests.

We are proposing that MA organizations implement the PARDD API, using certain implementation specifications as discussed in section II.D.3.a. of this proposed rule. These implementation specifications would be expected to improve the overall prior authorization process by addressing deficiencies that exist in the process today with respect to providers' access to information about the prior authorization rules and documentation requirements. The PARDD API would communicate the coverage and documentation requirements for a prior authorization, indicating if an authorization is required for a specific item or service and what documentation is required to support an authorization request. The PARDD API would be 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 prior authorization and would serve the same larger purpose of ensuring access to coverage by communicating the limits and rules for covered services.

Additionally, the proposed PARDD API would be a mechanism for receiving and responding to requests for coverage determinations before the services are rendered or items furnished; therefore, the proposed requirement to adopt and use the PARDD API would be 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 PARDD API could enable the provider to compile information that could be used in the HIPAA-compliant prior authorization request through their existing workflow and receive a timely response to that request. In concert with these APIs, we propose that the payer provide the status of the request, such as whether it was approved, or denied, along with a denial reason, so that the provider would know what steps to take next—whether to request a different service for the patient, to submit additional information, or to appeal the decision. These proposals would improve patient care and reduce redundancies in administrative processes between providers and payers because they would give providers clearer instruction, both for submitting the original request and, if necessary, providing additional information. The proposed APIs have the potential to improve the efficiency of the prior authorization process because they would enable providers to submit accurate information with the request, which could reduce the number of appeals or denials, and possibly eliminate requests for additional documentation. The policies could 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 would contribute to program efficiency, and effective operations and would be in the best interest of the enrollees. The proposal to require MA organizations to make certain changes to the timeframes in which these payers provide notice for prior authorization has the potential to improve patient access to care in program operations as discussed in section II.D.5.b. of this proposed rule. The proposal could prevent some patients from abandoning care while waiting for an authorization, and it could improve efficiencies by avoiding repeat phone calls from providers who must check on the status of an authorization over the course of several days, or sometimes weeks. The proposals to improve timeframes for expedited and standard decisions is being made 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, should the rule be finalized as proposed, there may be a reduction in unnecessary repeat requests for services. More responsive timeframes would also enhance enrollee access to timely and appropriate care. A shorter timeframe for both standard and expedited decisions could reduce administrative time and expense for providers and payers, as they would spend fewer resources on follow up inquiries. Providers may be able to better direct their attention to the clinical aspects of patient care. As such, these proposals are consistent with our authorities under section 1852 of the Act which requires 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. Our proposal to require MA plans to publicly report prior authorization metrics would enable CMS to assess implementation of the policies and attempt to determine the impact of these proposals on payers and providers. Review of these metrics could help CMS and the plans understand the impact of the proposed policies, including use of the APIs, and improved decision timeframes. The data could help plans evaluate operations, implementation of new policies and the APIs and determine what changes may be appropriate.

b. Medicaid

For Medicaid, most of these proposals 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 are provided in a manner consistent with simplicity of administration and the best interests of the recipients. Some proposals are also authorized by additional sections of the Act as discussed in this section of this 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 uses or disclosures that are directly connected with the administration of the program or plan. One of the implementing regulations for this section of the Act, at 42 CFR 431.302(c) states that purposes directly connected to plan administration include providing services for beneficiaries. CHIP programs are subject to the same requirements through a cross-reference at 42 CFR 457.1110(b). Medicaid and CHIP programs must also determine which programs require safeguards to apply to uses and disclosures of beneficiary data at 42 CFR 431.306. In order to meet the requirements of that regulation, states must have consistent criteria for release and use of information (which should conform to the proposed requirements for the PARDD API, if finalized). See 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 Medicaid agency, in accordance with 42 CFR 431.306(b). The permission provision at § 431.306(d) is not relevant to the API functionality proposed in this section, in part because it pertains to a well-established administrative process conducted extensively between the enrolled providers and states currently, and the provider would not be considered an outside source. 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 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. A provider enrolled with the state must meet privacy and security standards to protect the confidentiality of patient information. When requesting approval to provide certain services from the state using the state's PARDD API as described in section II.D.3.a., the provider would be able to determine if a prior authorization is required, and what supporting documentation is necessary to obtain approval for that care.

(1) PARDD API

The proposed requirement for state Medicaid FFS programs and Medicaid managed care plans to implement the PARDD 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.3.a. of this proposed rule, the PARDD API would allow a provider to determine whether a prior authorization is required, and the documentation requirements for that prior authorization request. The PARDD API would: (1) enable providers to submit a complete prior authorization request faster and easier; (2) support more timely notice to provider and beneficiary of the disposition of the prior authorization request; and (3) permit improved scheduling of services or filing appeals, depending on the decision. The PARDD API could have 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 proposed rule.

(2) Requirement for Payers To Provide Status of Prior Authorization and Reason for Denial of Prior Authorizations

The proposals to require states and Medicaid managed care plans to provide specific information to providers about the status of prior authorization requests are expected to enable providers to plan care for their patients after submitting a prior authorization request. As discussed in section II.D.4.a. of this proposed rule, providers would receive a response to an electronic prior authorization request to indicate that the request is approved, denied, or if additional information is needed. If a prior authorization has been denied, the provider would be provided information about why, so that they can either re-submit the request with updated information, identify alternatives for the patient, or appeal the decision. These proposals would improve the timeliness, clarity, and consistency of information for providers regarding prior authorization requests, help providers determine next steps for timely patient care, and reduce payer, provider, and patient burden by eliminating the need for repeated inquiries.

(3) 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 proposed 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 proposed timeframes for making prior authorization decisions about items and services that require prior authorization in Medicaid FFS and managed care programs would help providers better manage administrative resources, make more time available for providers to render patient care, and facilitate faster access to services. We believe these proposals would make substantive improvements to the care experience for Medicaid beneficiaries and lead to better health outcomes. In turn, better health outcomes would contribute to more efficient use of Medicaid program resources.

We believe that the proposal 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 would improve the efficient operation of the Medicaid program by facilitating faster receipt of services or filing of appeals.

Our proposal to make explicit in 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 for 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. These proposed amendments are 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).

Currently, and under our proposal, 42 CFR 438.210 applies the same appeal and grievance requirements for PIHPs and PAHPs as for MCOs; for this proposal, we rely on our authority in section 1902(a)(4) of the Act to adopt these standards for PIHPs and PAHPs. This is consistent with our prior practice for adopting standards for Medicaid managed care plans (81 FR 27507).

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 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, so 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. Our proposals 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.

For Medicaid managed care plans, these proposals are also authorized by section 1932(b)(4) of the Act, which provides that each Medicaid managed care organization 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. Reducing plan response time for prior authorization decisions could enable beneficiaries to file appeals if necessary, and receive 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 proposals 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. Should this rule be finalized as proposed, and should the proposed shorter prior authorization response requirements 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 proposed 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.

(4) Public Reporting of Prior Authorization Metrics

We are also proposing to require Medicaid FFS programs and Medicaid managed care plans to publicly report certain prior authorization metrics by posting them directly on the payer's website or via publicly accessible hyperlink(s). As discussed in section II.D.8. of this proposed rule, publicly reporting these metrics could 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 proposal 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 would support the proper and efficient operation of the state Medicaid plan. Requiring Medicaid managed care plans to publicly report their prior authorization metrics would hold them accountable and enable them to monitor their own performance and identify process improvement opportunities, which could 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 proposal 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 proposal because identifying prior authorization process weaknesses or deficiencies and enabling the implementation of corrective action would help ensure that care and services are provided in a manner consistent with 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 propose 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 in an effective and efficient manner 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 propose to require implementation of the PARDD API in section II.D.3.a. of this proposed rule to improve the prior authorization process for patients, providers, and payers by addressing deficiencies and inefficiencies that exist in the current process. Today, a payer's rules about when a prior authorization is required, and what documentation requirements must be fulfilled to submit the request, are not necessarily easily accessible for providers. The process may require manual activities including phone calls, use of portals, multiple websites, and paper manuals. These inefficient procedures take time away from actual patient care. The PARDD API would enable a provider to determine if a prior authorization was required electronically, in real time, and what the documentation requirements would be regarding such request. While we expect providers would be the primary stakeholders to benefit from this proposed API, making this information available in a standardized way and permitting access through an API would also serve the requirements in section 2101(a) of the Act that CHIP ensure access to coverage and coordinated care.

The proposed PARDD API would be a mechanism for receiving and responding to requests for coverage determinations before the services were furnished; the PARDD API would streamline the initial authorization process for the payer, by sharing this information in an easily accessible way. This would also allow the provider to know what to do if a prior authorization is required for a certain service, which would improve the provider's ability to treat the patient timely. The proposed PARDD API would enable the payer to send a real time response back to a provider, based on the request for authorization. This, too, would improve the efficiency of providing services to the patient, because the request and response would be automated, and in real time. Payer use of these APIs could ensure that a provider is able to submit a request for a prior authorization with the correct and complete documentation to avoid an incorrect submission which might result in an unnecessary denial. The PARDD API would: (i) enable providers to submit a prior authorization request faster and easier, (ii) support more timely notice to provider and beneficiary of the disposition of the prior authorization request, and (iii) permit faster scheduling of services or filing appeals, depending on the decision. The PARDD 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 subpart F of 42 CFR part 431 are also applicable to CHIP through a cross-reference at 42 CFR 457.1110(b). As discussed above for Medicaid, CHIP payers' and providers' data exchange through the PARDD 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. 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.

The proposed requirement in section II.D.5.b. of this proposed rule that CHIP FFS and managed care entities meet certain timeframes to provide decisions for prior authorizations, for expedited and standard decisions would be an improvement from the current state, where there is uncertainty about expectations for when a prior authorization might be approved. The proposal 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 could be increased as barriers due to process and timeframes would be removed. Similarly, improved process improvements could reduce administrative costs for providers and payers as redundancies would be removed from the system. The proposal to improve timeliness in responding to providers and patients could 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 they improve the efficiency of the CHIP programs.

Our proposal to require CHIP FFS and CHIP managed care entities to publicly report prior authorization metrics would also support the states' oversight, evaluation, and administration responsibilities. Should the reporting provisions be finalized as proposed, CMS may occasionally view some of the CHIP's FFS and CHIP websites to check for compliance, see how data is being reported, and determine if there are any trends in prior authorization changes that could be indicative of the benefits of the proposals for prior authorization policies as discussed in section II.D.8. of this proposed rule. The data may indicate use of the APIs, improvements in prior authorization numbers, or changes in total numbers, denials, and appeals.

d. QHP Issuers on the FFEs

For QHP issuers on the FFEs, we are proposing these new requirements pursuant to 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 included here could improve the efficiency of the issuers who are certified to offer QHPs on the FFEs and improve the quality of services they provide to providers and their patients. Qualified individuals in FFEs may receive covered services more quickly, and the information may be more accurate with the use of the APIs. These proposals could improve the quality of the patient experience with their providers by increasing the efficiency in the prior authorization submission and review process. Certifying only health plans that implement FHIR APIs and adhere to the other proposals herein would be in the interests of qualified individuals in the state or states in which an FFE operates. We encourage State-based Exchanges (SBEs) to consider whether a similar requirement should be applicable to QHP issuers participating in their Exchanges.

In section II.D.3.a. of this proposed rule, we propose that QHPs issuers on the FFEs implement an API to support the prior authorization process. The PARDD API would allow QHP issuers 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 API could enable more accurate submission and subsequent processing of prior authorization requests, with the potential of improving delivery of services to patients. Similar to the other API proposals, certifying only health plans that implement FHIR APIs would be in the interests of qualified individuals in the state or states in which an FFE operates because of the opportunities for improvements in patient care, in alignment with the goals of the Affordable Care Act.

We are also proposing that QHP issuers on the FFEs provide a reason for denial when sending a response to a prior authorization request, to facilitate better communication and understanding between the provider and issuer. This could enable efficient resubmission of the prior authorization request with additional information or an appeal, which could more promptly facilitate the needed patient care.

Finally, the proposal to require QHP issuers on the FFEs to publicly report prior authorization metrics in section II.D.8. of this proposed rule would hold issuers accountable to their providers and patients, which could help these organizations improve their program administration. These data could help QHP issuers 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. Electronic Prior Authorization for the Merit-Based Incentive Payment System (MIPS) Promoting Interoperability Performance Category and the Medicare Promoting Interoperability Program

1. Background

In the December 2020 CMS Interoperability proposed rule (85 FR 82639), we requested comment on ways in which CMS can incentivize the use of electronic prior authorization solutions by healthcare providers. We sought comment on whether the Quality Payment Program (QPP) Merit-based Incentive Payment System (MIPS) for MIPS eligible clinicians or the Conditions of Participation/Conditions for Coverage requirements for eligible hospitals and other providers would be the appropriate mechanism for new or additional policies that would promote the use of prior authorization APIs. Commenters expressed support for incentivizing healthcare providers to use these processes and tools to improve prior authorization processes. They noted that provider participation and health information technology are critical to promoting the widespread adoption of electronic prior authorization solutions. CMS considered both approaches outlined in that RFI (85 FR 82639) aimed at adopting and using electronic prior authorization processes. We believe that requiring healthcare providers, including clinicians and hospitals, to use these API functions for prior authorization is critical to ensuring the success and widespread adoption of this technology.

As discussed in section II.D. of this proposed rule, the current prior authorization process needs improvement to reduce the burden associated with the process itself. According to a 2020 American Medical Association (AMA) survey, 94 percent of respondents experienced patient care delays associated with processing prior authorizations, and 79 percent indicated having at least one experience of abandoned patient care due to onerous prior authorization processes. This same survey indicated increased provider and staff burnout and expense associated with current prior authorization processes. Specifically, the data suggest that 40 percent of physician practices have staff who work exclusively on prior authorizations, and, on average, physicians and staff spend approximately two business days (16 hours) each week on prior authorizations. A 2019 study by the Altarum Institute corroborates the AMA's findings that current prior authorization processes are increasingly burdensome and may lead to poorer patient health outcomes.

As mandated by section 4001 of the 21st Century Cures Act (Pub. L. 114-255), ONC published the Strategy on Reducing Regulatory and Administrative Burden Relating to the Use of Health IT and EHRs in February 2020. This report recommended multiple strategies for reducing burden through the use of health IT tools, including to “[l]everage health IT to standardize data and processes around ordering services and related prior authorization processes.” Further, the Health Information Technology Advisory Committee's (HITAC) Intersection of Clinical and Administrative Data (ICAD) Task Force has recommended standards be established for prior authorization workflows, extension and renewal mechanisms for prior authorizations be created, and patients be included in the prior authorization process.

As described in section II.D. of this proposed rule, stakeholders who participated in listening sessions conducted by CMS, including payers, providers, patients, and other industry representatives, noted that there are aspects of prior authorization processes that may be improved. For example, the information required by payers to evaluate or review a prior authorization can be inconsistent between payers, so it can be difficult for providers to determine the rules and required documentation. Further, submitting a prior authorization request relies on multiple cumbersome submission channels, including payer-specific web-based portals, telephone calls, and fax exchange technology. This process can be duplicative for providers who must re-submit prior authorization requests when patients change payers. To pursue these recommendations and facilitate needed improvements in the prior authorization process, in section II.D. of this proposed rule, we propose requiring impacted payers to implement and maintain a PARDD API. The PARDD API aims to improve care coordination and shared decision-making by enabling enhanced electronic documentation discovery and facilitating electronic prior authorization. This is discussed in more detail in section II.D. of this proposed rule. We believe the PARDD API would reduce administrative burden, improve efficiency, and ensure patients promptly receive necessary medical items and services. However, as noted in the December 2020 CMS Interoperability proposed rule (85 FR 82639), we 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, in this proposed rule, we propose a new measure for MIPS eligible clinicians under the Promoting Interoperability performance category of MIPS, as well as for eligible hospitals and CAHs under the Medicare Promoting Interoperability Program, related to electronic prior authorization. We intend for the new measure, titled “Electronic Prior Authorization,” to be included in the Health Information Exchange (HIE) objective for the MIPS Promoting Interoperability performance category and in the HIE objective for the Medicare Promoting Interoperability Program. This measure aims to address stakeholder concerns regarding possible low provider utilization of APIs established by payers for electronic prior authorization, as described in letters from commenters in response to the December 2020 CMS Interoperability proposed rule (85 FR 82586).

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 § 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 Calendar Year (CY) 2023 Physician Fee Schedule (PFS) final rule (87 FR 70075 through 70080) for a list of the current objectives and measures for the Promoting Interoperability performance category. We determine a final score for each MIPS eligible clinician based on their performance in the MIPS performance categories and apply a payment adjustment (which can be positive, neutral, or negative) for the covered professional services they furnish based on their final score.

The Medicare Promoting Interoperability Program for eligible hospitals and CAHs are 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 do not successfully demonstrate meaningful use of CEHRT are subject to Medicare payment reductions. To demonstrate meaningful use of CEHRT, eligible hospitals and CAHs must satisfy objectives and measures as required under 42 CFR 495.24. We refer readers to the Fiscal Year (FY) 2023 Hospital Inpatient Prospective Payment System (IPPS) and Long-Term Care Hospital (LTCH) final rule (87 FR 49350) for a summary of the current objectives and measures for the Medicare Promoting Interoperability Program.

2. Electronic Prior Authorization

To support the policies in this proposed rule and maximize the potential to improve the prior authorization process for providers and patients, we are proposing to add a new measure titled “Electronic Prior Authorization” in the HIE objective of the MIPS Promoting Interoperability performance category and in the HIE objective of the Medicare Promoting Interoperability Program. We believe this measure would further enable the electronic exchange of health information to improve the quality of healthcare, 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 are proposing to require MIPS eligible clinicians to report this measure beginning with the CY 2026 performance period/CY 2028 MIPS payment year and for eligible hospitals and CAHs to report this measure beginning with the CY 2026 EHR reporting period. However, we propose that the measure will not be scored in 2026.

The proposals we are making in this section with regard to an Electronic Prior Authorization measure do not alter a covered entity's requirement to use the HIPAA transaction standards at 45 CFR 162.1302. We note that a healthcare provider may use an intermediary or clearinghouse to assemble a HIPAA-compliant X12 278 prior authorization transaction to transmit to the payer, as described in section II.D.3.a. of this proposed rule. In that section, we also note 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. The approved exception allows testing of proposed modifications to HIPAA requirements—specifically for the prior authorization standard. Under this exception, the group would test a prior authorization exchange using the HL7 FHIR standard. In this proposal for the Electronic Prior Authorization measure, the healthcare provider would use data from their CEHRT (such as patient demographics and medical information) to justify the prior authorization request. The PARDD API would automate the compilation of necessary data for populating the HIPAA-compliant prior authorization request. Additional information not contained in CEHRT may also be required for submission. This information would then be packaged into a HIPAA-compliant transaction for transmission to the payer.

We are proposing the following specifications for the Electronic Prior Authorization measure:

a. 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 PARDD 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 PARDD API because the payer does not offer an API that meets the PARDD API requirements outlined in section II.D.3.a of this proposed rule.

• Numerator: The number of unique prior authorizations in the denominator that are requested electronically from a PARDD 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 PARDD API requirements outlined in section II.D.3.a of this proposed rule during the applicable performance period.

b. For Eligible Hospitals and Critical Access Hospitals in 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 from a PARDD 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 (place of service (POS) code 21 or 23) during the EHR reporting period, excluding prior authorizations that cannot be requested using the PARDD API because the payer does not offer an API that meets the PARDD API requirements outlined in section II.D.3.a of this proposed rule.

• Numerator: The number of unique prior authorizations in the denominator that are requested electronically from a PARDD API using data from CEHRT.

• Exclusions: Any eligible hospital or CAH that:

(1) Does not order any medical items or services (excluding drugs) requiring prior authorization during the applicable EHR reporting 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 PARDD API requirements outlined in section II.D.3.a of this proposed rule during the applicable EHR reporting period.

We propose 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 are proposing 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. If the MIPS eligible clinician, 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 intend to propose a scoring methodology for the measure in future rulemaking.

We are proposing that for purposes of this measure, a prior authorization request must be made using the PARDD API to satisfy the measure. The PARDD API functionality is outlined in further detail in section II.D.3.a of this proposed rule. 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 PARDD API because the payer does not offer an API that meets the PARDD API requirements, in which case it would be excluded from the denominator. Instances where a payer offering the PARDD 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 the use of 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.A. of this proposed rule.)

We are proposing that only prior authorizations that are requested electronically from a PARDD 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.

We propose 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 this measure. We are also proposing 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 PARDD API requirements outlined in section II.D.3.a of this proposed rule (that is, non-impacted payers or impacted payers that are non-compliant with the PARDD API requirements outlined in section II.D.3.a of this proposed rule), during the applicable performance period or EHR reporting period, could claim an exclusion for this 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. Given the previously discussed limitations of the current prior authorization process, we believe that all healthcare providers (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 this measure. However, we seek public comment on the alternative we considered and whether another minimum number of prior authorization requests would be appropriate for the exclusion.

ONC recently 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. ONC may use comments received from this RFI to inform future rulemaking in the ONC Health IT Certification Program related to electronic prior authorization. Updates to certification requirements for certified health IT introduced in future rulemaking could help MIPS eligible clinicians and eligible hospitals and CAHs to conduct the actions described in these proposed measures.

We invite public comment on these proposals. Specifically, we seek comment on the following:

• Should CMS consider alternatives to the proposed numerator and denominator of the measure? Are there changes to these specifications that would reduce the implementation burden for both providers and health IT developers?
• What challenges will providers face in identifying those payers that have the PARDD API technology in order to accurately include eligible prior authorization requests in the denominator?
• What challenges will providers face in performing the actions included in the measure specifications and successfully reporting the measure if certification criteria are not available in the ONC Health IT Certification Program at the time providers are required to report the measure under the Medicare Promoting Interoperability Program or MIPS Promoting Interoperability performance category?
• With the understanding that ONC may consider policies in the ONC Health IT Certification Program that could further support this measure, are there alternate implementation timeframes that should be considered?

F. Interoperability Standards for APIs

1. Modifications to Required Standards for APIs

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 45 CFR 170.215, which includes API technical standards, including HL7® FHIR® Release 4.0.1 (at 45 CFR 170.215(a)(1)), the HL7 FHIR US Core Implementation Guide Standard for Trial Use (STU) 3.1.1 (at 45 CFR 170.215(a)(2)), the HL7 SMART Application Launch Framework IG Release 1.0.0 (at 45 CFR 170.215(a)(3)), the FHIR Bulk Data Access (Flat FHIR) version 1.0.0: STU 1 (at 45 CFR 170.215(a)(4)) and OpenID Connect Core 1.0 (at 45 CFR 170.215(b)) (85 FR 25521). When we finalized the requirement for conformance with the specifications in 45 CFR 170.215 in the CMS Interoperability and Patient Access final rule (85 FR 25521), we finalized the use of all standards at 45 CFR 170.215 in whole 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” for all API implementations may introduce additional confusion for impacted payers seeking to understand compliance requirements because not all of the standards at 45 CFR 170.215 may be applicable for specific API use cases. For example, the Bulk FHIR implementation would not be applicable to the Patient Access API. We also understand that if we were to propose a similar requirement for the API requirements proposed in this rule, each standard in 45 CFR 170.215 might not be appropriate for each set of API requirements, given the unique factors associated with each API use case.

Accordingly, to reduce complexity and provide clarity, we are proposing modifications to be more specific regarding the standards at 45 CFR 170.215 applicable to previously finalized API requirements. We are also proposing specific language regarding the standards at 45 CFR 170.215 applicable for each new set of API requirements proposed in this proposed rule.

Specifically, instead of maintaining and extending the language in the existing requirements to use “API technology conformant with 45 CFR 170.215” in our new proposals, we are proposing language which specifies the use of each standard at 45 CFR 170.215 that would apply to a given set of API requirements at the CFR citations identified in Tables 8. We further summarize the standards applicable for each set of API requirements in Table 10. We note that the exact regulation text would vary depending on which standards apply to that API. We believe this language will clarify that payers would only be required to use those specifications included at 45 CFR 170.215 that CMS has identified as necessary for each specific API, as discussed further in section II.F.3 of this proposed rule.

Regarding the standard at § 170.215(a)(2), which is currently the HL7 FHIR® US Core Implementation Guide STU 3.1.1 (US Core IG), we recognize that the information we have required or proposed to require to be made available for different API use cases may only align with a subset of profiles defined within the US Core IG. For example, in 42 CFR 422.120(b)(1), for MA plans, we require the Provider Directory API to include data concepts such as the MA plan's network of contracted provider names, addresses, and phone numbers, whereas in § 422.119(b), we require the Patient Access API to include a broader set of information, such as all clinical data, including laboratory results. While we want to ensure that FHIR Resources are profiled according to the US Core IG where applicable to support interoperability across implementations, we also want to ensure that payers do not engage in unnecessary development. We are therefore proposing that a payer is only required to use technology conformant with the US Core IG at § 170.215(a)(2) where applicable, that is, where there is a corresponding FHIR Resource in their functional API, pursuant to the data requirements for the API. If the FHIR Resource has been profiled by the US Core IG at 45 CFR 170.215(a)(2), then the payer must support the FHIR Resource according to the FHIR Resource Profile's “StructureDefinition” as specified in the standard in the US Core IG at 45 CFR 170.215(a)(2). For example, if a “Patient” FHIR Resource is used in a payer's Patient Access API, the “Patient” FHIR Resource must conform with the “US Core Patient Profile,” including all the “mandatory” and “must support” requirements as specified in the US Core IG.

We also recognize that several of the IGs recommended for use in this section of this proposed rule build on specific profiles within the US Core IG. For example, the HL7 FHIR Da Vinci Payer Data Exchange (PDex) Implementation Guide: Version STU 1.0.0. Furthermore, we recognize that the recommended IGs and subsequent versions of these IGs may use profiles in updated versions of the US Core IG. We note that payers could use updated versions of the recommended IGs that rely on newer versions of the US Core IG, as long as those updated versions meet the requirements of our policy for the use of updated standards which is described below and aligns with the procedures established by ONC under the Standards Version Advance Process (SVAP).

a. Use of Updated Standards

In the CMS Interoperability and Patient Access final rule (85 FR 25510), we explained that while we must codify a specific version of each standard, the need for continually evolving standards development has historically outpaced our ability to amend regulations. In that final rule, we established that payers implementing a Patient Access or Provider Directory API could use an updated version of a standard subject to certain conditions. Specifically, we established that an updated version of a standard could be used if the updated version of the standard is required by other applicable law, or not prohibited under other applicable law, provided that: for content and vocabulary standards other than those at 45 CFR 170.213, the Secretary has not prohibited use of the updated version of a standard for purposes of the section in which the provision is located, or 45 CFR part 170; and for standards at 45 CFR 170.213 and 170.215, the National Coordinator has approved the updated version for use in the ONC Health IT Certification Program (85 FR 25522). Finally, we established that an updated version of the standard could be used if the updated version does not disrupt an end user's ability to use a required API to access the data required for that API (85 FR 25532). We are now proposing to extend this same policy to allow the use of an updated version of a standard to the Provider Access API, Payer-to-Payer API, and PARDD API. Under this proposal, impacted payers could upgrade to newer versions of the required standards, subject only to those limiting conditions, as previously noted, at any pace they wish. However, we reiterate that when using updated standards, a payer must continue to support connectivity for end users and may only use an updated version of the standard instead of the standard specified in the applicable regulation, if it does not disrupt an end user's ability to access the data available through the API. We are proposing to allow the use of updated standards, specifications, or Implementation Guides for each of the API requirements at the CFR sections identified in Table 9. We note that any existing or proposed cross-references apply current requirements to the newly proposed APIs.

Regarding the use of updated versions of standards at 45 CFR 170.213 and 170.215, we propose that these standards may be used if the National Coordinator has approved the updated version for use in the ONC Health IT Certification Program. We note that the National Coordinator approves the use of updated versions of standards in the Certification Program under SVAP pursuant to 45 CFR 170.555, which was finalized in the ONC 21st Century 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 Certification Program to keep pace with the industry's standards development efforts.

Under the 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 under the Certification Program. ONC lists updated versions of standards that the National Coordinator has approved on its website. In addition, as part of the Interoperability Standards Advisory, ONC publishes updated versions of standards under consideration for the SVAP process. Members of the public can use this resource to review standards that may be approved under the SVAP process 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 the flexibility that may be available to utilize updated versions of the standards in §§ 170.215 and 170.213, provided these standards have been approved by the National Coordinator through the SVAP process and meet the other specified conditions for using updated standards to support compliance with the technical requirements for payer APIs. CMS emphasizes that if impacted payers choose to use updated standards, whether approved through the SVAP process or not, there should not be a disruption to an end user's ability to access the data.

We note that several updated versions of the standards currently at §§ 170.213 and 170.215 have been approved by the National Coordinator under the SVAP process,¹¹⁹ including the USCDI (Version 2), HL7 FHIR® US Core Implementation Guide (Version 4.0.0 and Version 5.0.1), the HL7 FHIR® SMART Application Launch Framework Implementation Guide (Release 2.0.0), and the HL7 FHIR® Bulk Data Access (Flat FHIR®) (v2.0.0: STU 2). As soon as the National Coordinator approves updated versions through the SVAP process; CMS considers the updated versions to have met this condition for use under our payer API requirements. Impacted payers may use these versions as long as the other conditions finalized in our regulations for the use of updated versions of the standard, implementation guide, or specification have also been met.

2. Recommended Standards To Support APIs

In the CMS Interoperability and Patient Access final rule (85 FR 25529), we noted certain IGs that are publicly available for use and provide implementation information that payers can use to meet the regulatory requirements for APIs finalized in the rule to support interoperability and avoid having to develop an approach independently, saving time and resources. Reference implementations, which are use case-specific test implementations with test data, have been developed for these IGs and allow payers to see the APIs in production and support testing and development. We explained that using the additional recommended IGs could limit payer burden and support consistent, interoperable API development and implementation. We referred payers to information about recommended IGs and related reference implementations (85 FR 25533). In this proposed rule, we are also recommending specific implementation guides, including implementation guides relevant to the new API requirements proposed in this rule, that may be used in addition to the standards we are proposing to require at 45 CFR 170.215.

In the December 2020 CMS Interoperability proposed rule, we proposed to require the use of FHIR 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, Da Vinci Coverage Requirements Discovery (CRD) IG, Documentation Templates and Rules (DTR) IG, and Prior Authorization Support (PAS) IG (85 FR 82586) to support the APIs requirements in the proposed rule. As discussed in section I.A. of this proposed rule, the December 2020 CMS Interoperability proposed rule will not be finalized, and we are withdrawing the proposals included in that rule. We also note that these FHIR IGs continue to undergo further refinement and development as part of the HL7 ballot and standard advancement process that are expected to better support the Patient Access, Provider Access, Payer-to-Payer, and PARDD APIs.

Additionally, some aspects of the HL7® FHIR® DaVinci PAS IG, notably the FHIR to X12 transactions and use of FHIR subscriptions, continue to be developed. In the case of the HL7® FHIR® DaVinci PDex US Drug Formulary IG, which was proposed to support API requirements finalized in the CMS Interoperability and Patient Access final rule, nuances involving how the data are used in different ways by payers need to be resolved, such as different co-pay and co-insurance options and subtleties when searching by brand name, ingredients, and drug name. Industry stakeholders continue to pursue production implementations to identify refinements and reconcile inconsistencies in these IGs to address targeted use cases more effectively.

After careful ongoing consideration of the IGs, as previously listed, that were proposed previously in the December 2020 CMS Interoperability proposed rule, their development cycles, and our role in advancing interoperability and supporting innovation, we believe that while these IGs will continue to play a critical role in supporting our policy, we are not ready to propose them as a requirement of our interoperability initiatives. We believe these IGs will continue to be refined over time as stakeholders have the opportunity to test and implement them, and as such, we are recommending them for use but are not proposing to require them. Specifically, we will continue to monitor and evaluate the development of the IGs and consider whether to propose them as a requirement at some future date. At this time, we are recommending the use of 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, and Da Vinci CRD IG, DTR IG, PAS IGs for the Patient Access, Provider Access, Provider Directory, Payer-to-Payer, and PARDD APIs.

We acknowledge that by not requiring the use of all of the available FHIR 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 this time, we believe it is more important not to require these IGs while they are still undergoing additional enhancements. We are recommending, but not requiring, certain IGs that were previously proposed because we want to ensure that implementers use subsequent versions of these IGs without restriction to the version available when we issue a regulation. As discussed in section II.F.1, we previously finalized a policy to allow flexibility for the use of updated versions of certain standards required for the API requirements finalized in the Patient Access and Interoperability final rule, which we have proposed to extend to the API requirements proposed in this rule. However, we understand that the subsequent versions of the recommended IGs may include substantial changes that would not be consistent with the requirement included in our flexibility provisions that the use of an updated standard must not impair access to data through the API. Therefore, we believe that if we proposed to require the recommended IGs at this time, impacted payers would not be able to use an updated version of these IGs unless we were to require the updated versions through additional rulemaking. We intend to monitor IG development and may propose to require specific IGs at some future date when there are versions available for adoption that are mature and more likely to allow for voluntary updates under our flexibility policies.

We seek comment on whether CMS should propose to require the use of these IGs for previously finalized and proposed APIs in future rulemaking and other ways that we could support innovation and interoperability. In addition, we seek comment on the process CMS should use to adopt or allow new versions of standards and implementation specifications over time, as previously discussed. CMS supports innovation and continued efforts to refine standards in a way that will leverage the most recent technological advancements.

In making these recommendations, we note that these IGs are publicly available at no cost to a user. All HL7® FHIR® IGs are developed through an industry-led, consensus-based public process. HL7® is an American National Standards Institute (ANSI)-accredited standards development organization. HL7 FHIR standards allow disparate systems with different data architectures to exchange information in a standardized way via standards-based APIs. HL7 FHIR IGs are also openly available, so that any interested party can access a HL7 FHIR IG on the HL7 website. All public comments made during the HL7 balloting process and the IG version history, are available for review. This way, all stakeholders can fully understand the lifecycle of a given IG. Using IGs developed through such a public process facilitates a transparent and cost-effective path to interoperability that ensures the IGs are informed and approved by industry participants looking to use technology to improve patient care.

A few of the recommended FHIR IGs have been developed by HL7 FHIR Accelerator programs, which bring together individuals across the industry to create and adopt IGs that are aligned with HL7, allowing new and revised requirements to have the potential to become open industry standards. Under HL7 FHIR Accelerators, industry stakeholders have facilitated the definition, design, and creation of use-case-specific reference implementations based on the HL7 FHIR platform to address value-based care initiatives. Some HL7 FHIR Accelerators, such as Da Vinci and CARIN, have created IGs that we recommend be used to meet the previously finalized and proposed requirements for the Patient Access, Provider Directory, Provider Access, and Payer to Payer APIs. The Da Vinci project was established in 2018 to help payers and providers positively impact clinical, quality, cost, and care management outcomes. The CARIN Alliance works collaboratively with Government stakeholders to overcome barriers to advancing consumer-directed exchange across the U.S.

While we are recommending the IGs proposed previously in the December 2020 CMS Interoperability proposed rule as discussed, we welcome further information about the maturity of these IGs, including considerations about further development that would be needed prior to CMS requiring the use of specific IGs.

3. Proposed Standards To Support APIs

Using IGs supports consistent implementations across the industry. Therefore, we are proposing at the CFR citations identified in Table 8 to require that impacted payers use API technology conformant with the standards at 45 CFR 170.215 that we propose as applicable for each set of API requirements. We include Table 10 to provide a clear outline of which standards we are proposing to require and which IGs we recommend for each proposed API.

III. Requests for Information

A. Request for Information: Accelerating the Adoption of Standards Related to Social Risk Factor Data

The December 2020 CMS Interoperability proposed rule (85 FR 82586) included several requests for information, including one regarding standards for social risk factor data. We received several comments requesting additional time to comment on this issue, and thus we are reissuing the request for information, with modification to add additional questions in this section.

Social determinants of health (SDOH) as defined by Healthy People 2030 are “the conditions in the environments where people are born, live, learn, work, play, worship, and age that affect a wide range of health, functioning, and quality-of-life outcomes and risks.” Social risk factors are those that can lead to unmet social needs that directly influence an individual's physical, psychosocial, and functional status. These can include homelessness, food insecurity, lack of access to transportation, and low levels of health literacy. When these are immediate and pressing needs, these social risk factors may be called unmet social needs, or health-related social needs. Understanding social risk factors and individuals' immediate unmet needs can help healthcare systems, plans, providers, and other partners target interventions to address these specific factors.

CMS recognizes that social risk factors impact patient health, utilization, and outcomes, and that these factors can have a direct impact on our healthcare system as a whole. To the extent that healthcare providers and payers have access to data on social risk factors, they are best equipped to address these factors, and thus have a positive impact on patient health. Healthcare providers in value-based payment arrangements rely on comprehensive, high-quality data to identify opportunities to improve patient care and drive value. When implemented effectively, value-based payment encourages healthcare providers to care for the whole person and address the social risk factors that are critical for patient quality of life.

As value-based payment has grown, so has provider community interest in social risk factor data. A recent study found that approximately 24 percent of hospitals and 16 percent of physician practices were screening patients for five health-related social needs (housing, food, transportation, utilities, and interpersonal safety needs). These findings suggest that healthcare providers can use these data to inform care and ensure patients get the services and support they need to address social risk factors and achieve better health outcomes.

Unfortunately, social risk factor data are often fragmented, unstandardized, out of date, and duplicative. These circumstances are a result of a lack of clear standards for capturing, recording, and exchanging these data. While the International Classification of Diseases, Tenth Revision, Clinical Modification (ICD-10-CM) psychosocial risk and economic determinant-related codes (“Z codes”) can be used to capture standardized information on social determinants of health, utilization on Medicare claims remains relatively low for a number of reasons, including a lack of financial incentives to record them and the limited number of available codes and sub-codes. If these data are not exchanged between healthcare providers caring for an individual, these providers who do not or cannot exchange these data with each other may ask the same patient similar questions, or hospitals within a single system may all collect data on the same health-related social needs in different formats. Additionally, relevant data collected without the use of standards to facilitate interoperability by community-based organizations outside the health sector can be difficult for other healthcare and social care providers to integrate and utilize. Siloed social risk factor data may increase the burden on patients, as well as healthcare providers and the healthcare system overall by creating inefficiencies in managing referrals for social services and duplicative and conflicting workflows in an already strained system. Non-interoperable information flows may impede opportunities to provide higher quality care and result in missed opportunities to address the root causes of poor health outcomes and health inequities.

As healthcare providers assume greater accountability for costs and outcomes through value-based payment, they need tools to successfully identify and address social risk factors to improve care and health outcomes. Over the last several years, standards development organizations like the Gravity Project under HL7, have sought to develop industry-wide standards to collect social determinants of health (specifically, social risk factor data), electronically represent these data, and enable exchange of person-centered data between medical providers and community-based organizations through health information technology platforms. Since the introduction of the 2015 Edition of health IT certification criteria, the Office of the National Coordinator for Health Information Technology (ONC) Health IT Certification Program has certified technology that has enabled approximately half of all office-based clinicians and nearly a third of hospitals to possess technology certified to record, change, and access the data elements of overall financial resource strain, social connection and isolation, highest level of education, and exposure to violence (intimate partner violence). In July 2021, ONC also published the United States Core Data for Interoperability version 2 (USCDI v2), which includes the new data elements of SDOH Assessment, SDOH Goals, SDOH Problems/Health Concerns, and SDOH Interventions.

CMS seeks input on barriers the healthcare industry faces to using industry standards and opportunities to accelerate adoption of data collection standards related to social risk factor data, including exchange of information with community-based organizations. CMS specifically seeks input on these topics from stakeholders in minority and underserved communities as defined by section 2(b) of Executive Order 13985, Advancing Racial Equity and Support for Underserved Communities Through the Federal Government, and from the healthcare providers and plans, systems, and networks who serve these communities. Consistent with E.O. 13985, CMS is particularly interested in understanding the perspectives, barriers, and opportunities on these questions from a broad community of provider and healthcare interested parties, including those with whom CMS works with in underserved and minority communities who currently work to identify and meet needs related to social risks which could impact health and health service access, as previously described. We are also interested in receiving comments from individuals who have been referred to services to get support and their experiences with the benefits and burdens of data sharing, as well as their responses to the other questions included in this RFI. We are additionally interested in receiving comments from community-based organizations that work in the social service field. This feedback from diverse populations, including minority and underserved communities and neighborhoods, and individuals with lived experience related to social risk factor screening and referrals can help ensure that solutions are person-centered, and that CMS and other Federal policy makers understand the needs and challenges from those individuals we seek to serve. Information of interest to CMS includes:

• What are best practices regarding frequency of collection of social risk and social needs data? What are factors to be considered around expiration, if any, of certain social needs data?
• What are best practices regarding workforce training on collecting social risk and social needs data? How could CMS best support such training?
• What are the challenges in representing and exchanging social risk and social needs data from different commonly used screening tools? How do these challenges vary across screening tools or social needs (for example, housing or food access)?
• What are the barriers to the exchange of social risk and social needs data across healthcare providers? What are key challenges related to exchange of social risk and social needs data between healthcare providers and community-based organizations? If Federal or other regulations are perceived or actual barriers, please identify the specific regulation, policy, or guidance and clarifying language that would be necessary to resolve the cited barrier. If no specific language or policy is known, please provide a citation where more information is available related to this barrier.
• What mechanisms (EHRs, Health Information Exchanges [HIEs], software, cloud-based data platforms, etc.) and/or standards are currently used to capture, exchange, and use social risk and social needs data? What challenges, if any, occur in translating, collecting, or transferring social risk factor data in these platforms to Z codes on claims?
• How can payers promote exchange of social risk and social needs data? Are there promising practices used by MA organizations, state Medicaid agencies, Medicaid managed care plans, commercial health plans, or other payers that can potentially be further leveraged in other settings?

• What specific strategies, tactics, or policies would help CMS and other Federal agencies facilitate greater standardization in the capture, recording, and exchange of social risk factor data? Are there best practices (related to contracting language, requirements in Federal programs, etc.) that could be adopted, and by which agency?

• What are the most promising efforts that exist to date in resolving the challenges previously cited in this proposed rule? Which gaps remain that are not being addressed by existing efforts?
• What privacy issues should be considered when formulating policy for collecting and exchanging social risk and social needs data? Are there certain data elements that patients may wish to exercise more control over than others?
• What are best practices that are currently addressing other challenges previously cited in this proposed rule, such as integration of social risk and social needs data into clinical workflow, adoption, and use of commonly used screening tools with associated health IT standards and value sets, and integration of social risk data and social needs data into the patient's longitudinal health record?
• Please identify potential existing, emerging, or possible new policy levers that CMS could use to better incentivize use and interoperability of social risk factor data.
• Please identify opportunities and approaches that would help CMS facilitate and inform effective infrastructure investments to address gaps and challenges for advancing the interoperability of social risk factor data.

We seek comments on these questions and issues for future consideration.

B. Electronic Exchange of Behavioral Health Information

The December 2020 CMS Interoperability proposed rule (85 FR 82586) included several requests for information, including a request for information regarding electronic data exchange among behavioral health providers (85 FR 82637). We received several comments requesting additional time to comment on this particular issue, and thus we are reissuing the request for information, with modification to add additional questions in this section of this proposed rule.

Several factors have led behavioral health providers to adopt EHRs at a significantly lower rate than other types of healthcare providers. One possible contributing factor was that the Health Information Technology for Economic and Clinical Health Act (HITECH Act), enacted as part of the American Recovery and Reinvestment Act of 2009 (Pub. L. 111-5) on February 17, 2009, made Medicare FFS and Medicaid incentive payments for the adoption and meaningful use of CEHRT available only to eligible professionals, eligible hospitals, and CAHs, so behavioral health providers that did not meet those criteria were ineligible for these incentive payments. For example, while behavioral health providers who were physicians (eligible professionals) could receive the incentive payments, other types of non-physician behavioral health providers may not have been eligible. Congress created another potential opportunity to address this issue when it enacted the Substance Use-Disorder Prevention that Promotes Opioid Recovery and Treatment for Patients and Communities Act (SUPPORT Act) (Pub. L. 115-271) on October 24, 2018. Section 6001 of the SUPPORT Act modifies an existing list of possible model opportunities the Center for Medicare & Medicaid Innovation may consider testing to include models to provide incentive payments to behavioral health providers for adopting EHRs.

Today, behavioral health providers lag behind their peers in the ability to electronically share health information across providers and with patients. ONC noted that, in 2017, only 14 percent of office-based physicians reported sending data to behavioral health providers, while 12 percent of office-based physicians reported receiving data from behavioral health providers. Other regulatory restrictions, such as 42 CFR part 2, which governs the confidentiality of substance use disorder patient records maintained by certain entities, or more restrictive state laws, can also inhibit the exchange of behavioral health information.

Understanding the time and cost of implementing an EHR system, we are interested in evaluating whether using other applications that exchange data using the FHIR APIs and do not require implementation of a full EHR system might be a way to help behavioral health providers leverage technology to exchange health data to improve care quality and coordination in a more agile fashion. Specifically, would small practices and community-based providers be able to more quickly adopt applications using API technology to exchange health information when the technology is not tied to an EHR? Would these providers be able to achieve the same care coordination goals using such applications as with a more extensive EHR implementation, or would the value be lower but still sufficient to improve care quality and care coordination?

The Substance Abuse and Mental Health Services Administration (SAMHSA) published regulations related to improved care coordination among providers that treat substance use disorders as well as protecting those patients' records (42 CFR part 2). Section 6001 of the SUPPORT Act also encourages CMS to consider ways to facilitate information sharing among behavioral health providers by adding a model opportunity to the list of possible model opportunities for consideration by the CMS Center for Medicare & Medicaid Innovation under section 1115A(b)(2)(B) of the Act. We are looking for innovative approaches to addressing the need to facilitate the electronic exchange of behavioral health information, as well as approaches to support the exchange of health information to behavioral health providers to inform care and provision of behavioral health services.

ONC has been working with other Federal agencies to consolidate input to help inform approaches HHS can take to advance behavioral healthcare delivery and coordination supported by health IT, through the development of action items and high impact projects including to support behavioral health integration consistent with the HHS Roadmap for Behavioral Health Integration. Information about projects such as Health Information Exchange and Behavioral Health Care and the Rhode Island Behavioral and Medical Information Exchange Project are available on the ONC website at https://www.healthit.gov.

Many behavioral health providers practice in community-based roles. As a result, when considering behavioral health specifically, it is valuable to consider community-based providers more broadly.

We are interested in public comments on how we might best support electronic data exchange of behavioral health information between and among behavioral health providers, other healthcare providers, and patients, as well as how we might best inform and support the movement of health data (and its consistency) to behavioral health providers for their use to inform care and treatment for individuals with behavioral health needs. Specifically, we are seeking public comments on the following questions:

• Can applications using FHIR APIs facilitate electronic data exchange between behavioral health providers and with other healthcare providers, as well as their patients, without greater EHR adoption? Is EHR adoption needed first? What opportunities do FHIR APIs provide to bridge the gap? What needs might not be addressed by using applications with more limited functionality than traditional EHRs?
• How can existing criteria under the ONC Health IT Certification Program ensure applications used by behavioral health providers enable interoperability? What updates to existing criteria, or new criteria, could better support exchange by these clinicians?
• What levers could CMS consider using to facilitate greater electronic health data exchange from and to behavioral health providers? What costs, resources, and/or burdens are associated with these options? Is there additional sub-regulatory guidance and/or technical assistance that CMS or HHS could provide that would be helpful?
• Are there particular considerations for electronic data exchange for behavioral health providers who practice independently, are community-based, or are non-traditional providers? What about rural-based behavioral health providers? How could an API-based solution help address these considerations?
• Are there state or Federal regulations or payment rules that are perceived as creating barriers to technical integration of systems within these practices? What additional policy issues, technical considerations, and operational realities should we consider when looking at ways to best facilitate the secure electronic exchange of health information that is maintained by behavioral health providers including sensitive health information?
• What are current drivers at the Federal, state, or local level that are effectively supporting greater adoption of health IT for behavioral health providers? What new regulations guidance, or other policy levers (including new authorities) could benefit community providers or include incentives for community providers to encourage greater adoption of health IT?
• What methods and approaches have stakeholders utilized to help advance health IT adoption among behavioral health providers, for instance, effective practices for braiding/blending of funds and as part of value-based models? How are stakeholders effectively strengthening system capacity, connecting to care, and creating healthy environments today?
• What levers and approaches could CMS consider using and advancing to facilitate greater electronic health data exchange from and to community-based health providers including use of relevant health IT standards and certification criteria for health IT as feasible? What costs, resources, and/or burdens are associated with these options?
• What privacy and security considerations would be the biggest barriers for community-based providers to engage in information exchange, and which could be addressed by Federal policy, which by technology, and which by process?

We seek comments on these questions and issues for future consideration.

C. Request for Information: Improving the Exchange of Information in Medicare Fee for Service

In the Medicare FFS program, the ordering provider or supplier can often be different than the rendering provider or supplier of items or services, which may contribute to challenges in the coordination of patient care and exchange of medical information needed to ensure accurate and timely payment. Unlike their physician and hospital counterparts, providers such as home health agencies, Durable Medical Equipment, Prosthetics, Orthotics, and Supplies (DMEPOS) suppliers, and ambulance providers were not included in the American Reinvestment and Recovery Act (ARRA) Health Information Technology for Economic and Clinical Health (HITECH) Act programs, so they were not eligible for the same incentive payments for health IT adoption and interoperable data exchange as other providers. Thus, some providers or suppliers continue to use the U.S. Postal Service or fax machines to send patient information, and these methods can also lead to delays in the receipt of orders, prior authorization decisions, and payments. Ideally, health IT and the electronic exchange of information would streamline information-sharing processes between ordering and rendering providers or suppliers so that any impediments are eliminated.

For example, with DMEPOS suppliers, a physician or non-physician practitioner (NPP) may order a power wheelchair and document the necessary information in the beneficiary's medical record, but the DMEPOS provider will provide the wheelchair and submit the claim for payment. For some DMEPOS items, a written order is required prior to delivery. This dynamic often necessitates significant coordination between the ordering provider or supplier and the rendering provider to exchange information before the item or service can be provided to the beneficiary so that the rendering provider has the documentation from the ordering provider or supplier that demonstrates that the furnishing of the item or service meets CMS coding, coverage, payment or documentation requirements. The rendering provider or supplier must submit documentation of the patient's medical condition to justify why a patient requires a specific item or service and/or in order to meet CMS requirements. This helps to ensure that beneficiaries are receiving medically necessary care that meets CMS requirements. This information is usually documented in the ordering provider or supplier's medical record. The rendering provider or supplier must obtain this information from the ordering provider or supplier to furnish the item, and submit a claim or prior authorization request. The timing of a beneficiary receiving a service or item could be dependent on the ordering provider or supplier sending the documentation to the rendering provider in advance, as their claims are not dependent on sending these data.

Such coordination can take time to complete and lead to delays in the receipt of necessary documentation, particularly in those instances where either one or both providers or suppliers do not use health IT to share medical information. Even in situations where both the ordering and rendering providers or suppliers do use health IT to exchange information, the compatibility of the systems may not allow for the easy and/or expeditious exchange of that information. Should prior authorization be required, disparities in health IT system data exchange capabilities could lead to delays in healthcare decision-making and potential delays in the delivery of care for patients. These delays can be more problematic in those settings where the focus of one provider is on the order and the focus of the other provider is on providing the item or service and submitting the claim for payment. This arrangement frequently places more burden on the rendering provider to obtain the necessary information and engage in multiple follow-ups—and can result in delays in the patient receiving the item or service.

The inconsistent use and lack of uniform health IT to exchange medical documentation will take time to effectively resolve. In the interim, we are interested in public comments on how Medicare FFS might best support improvements to the exchange of medical documentation between and among providers or suppliers and patients, as well as how we might best inform and support the movement of health data (and its consistency) to providers or suppliers for their use to inform care and treat beneficiaries. We are also interested in public comments on what specific changes or improvements in health IT could assist providers or suppliers in submitting medical documentation to CMS and its contractors so that claims are not denied and/or are not deemed improper payments. Specifically, we are seeking public comments on the following questions:

• How might CMS encourage more electronic exchange of medical information (for example, orders, progress notes, prior authorization requests, and/or plans of care) between providers/suppliers and with CMS and its contractors at the time an item or service is ordered? When possible, please describe specific recommendations to facilitate improved data exchange between providers or suppliers, and with CMS and its contractors, to support more efficient, timely, and accurate claims and prior authorization communications. Are there specific process changes that you believe would improve the exchange of medical documentation between ordering and rendering providers or suppliers? Are there particular policy, technical, or other needs that must be accounted for in light of the unique roles of ordering and rendering providers or suppliers?
• Are there changes necessary to health IT to account for the need for providers/suppliers (ordering and rendering) to exchange medical documentation, either to improve the process in general or to expedite processing to ensure beneficiary care is not delayed? How could existing certification criteria or updates to certification criteria under the ONC Health IT Certification program support specific exchange needs?
• What additional steps in the area of health IT and the exchange of information could CMS take to assist providers or suppliers in the claim submission process? Are there changes in technology or processes that could also reduce the number of claims re-submissions and/or improper payments?
• What levers could CMS consider using to facilitate greater collaboration and exchange of information among providers/suppliers? What costs, resources, and/or burdens are associated with this type of collaboration? Are there changes that could reduce improper payments and the administrative burden often encountered by rendering providers/suppliers who need medical record documentation from ordering providers or suppliers?
• Are there state or Federal regulations or payment rules that are perceived as creating barriers to the exchange of information between ordering and rendering providers/suppliers? What additional policy issues, technical considerations, and operational realities should we consider when looking at ways to best facilitate the secure exchange of information between providers or suppliers and with Medicare FFS?

We seek comments on these questions and issues for future consideration.

D. Request for Information: Advancing Interoperability and Improving Prior Authorization Processes for Maternal Health

The Biden-Harris Administration has prioritized addressing the nation's maternity care crisis. In April 2021, President Biden issued a Presidential Proclamation marking Black Maternal Health Week. In December 2021, Vice President Kamala Harris convened a Federal Maternal Health Day of Action, where she announced a Call to Action to improve maternal health outcomes across the United States. The Administration subsequently released the White House Blueprint for Addressing the Maternal Health Crisis in June 2022, which describes its overarching approach for the Federal Government to combat maternal mortality and morbidity. Among the Blueprint's five priorities is advancing data collection, standardization, harmonization, transparency, and research, with the Blueprint noting that data and research are foundational to achieving each of the other goals it sets.

In July 2022, CMS published its Cross-Cutting Initiative: CMS Maternity Care Action Plan, which aims to improve health outcomes and reduce disparities. CMS has identified five key gaps in maternity care related to CMS programs, which are also reflected in the White House Blueprint, and is currently taking steps to address each: (1) coverage and access to care, (2) data, (3) quality of care, (4) workforce, and (5) social supports. CMS is already playing an integral role in addressing many of the White House Blueprint's goals in concert with its own action plan. For example, in October 2022, CMS announced that more than half of all states have extended Medicaid and CHIP coverage for 12 months after pregnancy, resulting in an additional approximately 418,000 Americans across 26 states and the District of Columbia being eligible for 12 months of postpartum coverage. CMS continues to work with additional states to adopt extended postpartum coverage in Medicaid and CHIP.

The CMS Maternity Care Action Plan also expressed intentions to coordinate across programs to identify gaps and best practices. Technology can be leveraged to address known racial disparities to prenatal and postnatal care by facilitating telehealth visits or remote monitoring options. For example, research has shown leveraging technology and telehealth significantly reduced the racial disparities in blood pressure ascertainment. Some state Medicaid agencies are leveraging the enhanced Federal financial participation (FFP), available under section 1903(a)(3) of the Act and regulations at 42 CFR 433.111, to procure remote monitoring and telehealth capabilities to address this inequity and expand access to remote blood pressure monitoring, behavioral health consultations, lactation consultations, blood glucose monitoring, etc. CMS seeks comments on how we might further support these state efforts with that enhanced FFP system.

As the CMS action plan outlines, we are working to expand our data collection efforts, stratify data by key demographics to identify disparities in maternal care or outcomes, and coordinate across programs to identify gaps and best practices. In the FY 2022 IPPS final rule, we finalized Hospital Inpatient Quality Reporting (IQR) program rules that require hospitals to report the Maternal Morbidity Structural Measure. That measure assesses whether or not a hospital participates in a Statewide or National Perinatal Quality Improvement (QI) Collaborative initiative, and if so, whether it implements patient safety practices and/or bundles related to maternal morbidity from that QI Collaborative. These Collaboratives, such as the Alliance for Innovation on Maternal Health (AIM), provide implementation and data support for the adoption of evidence-based patient safety bundles. Additionally, we finalized two new electronic clinical quality measures (eCQMs) related to maternal health—one measuring severe obstetric complications and another measuring low-risk Cesarean section rates—in the FY 2023 IPPS final rule (87 FR 49181).

For state Medicaid and CHIP agencies, CMS annually identifies a core set of measures for voluntary reporting that show the quality of care and health outcomes for those programs' beneficiaries. These measures are currently voluntarily reported by states, but a subset of measures—that, is the Child Core Set and behavioral health measures in the Adult Core Set—will become mandatory for states to report beginning in 2024. We identified a core set of 9 measures in 2022 that support our maternal and perinatal health-focused efforts (the Maternity Core Set). The Maternity Core Set consists of 6 measures from the Child Core Set and 3 measures from the Adult Core Set and is used to measure and evaluate progress toward improvement of maternal and perinatal health in the Medicaid and CHIP. Data reported by states will additionally be used to conduct an equity assessment on the quality of postpartum care in Medicaid and CHIP.

In addition to measurement data, which helps us to better understand the state of maternal healthcare in our various programs, CMS also believes that a critical foundation comprised of health IT, data sharing, and interoperability underlie many opportunities to improve maternal health outcomes. CMS is now seeking information from the public on evidence-based policies we could pursue that leverage information technology to improve such outcomes.

Health IT can be used to support safe and effective maternal and child healthcare. The ONC Pediatric Health Information Technology: Developer Informational Resource is an HHS non-regulatory initiative to inform the technical and implementation specifications for health IT developers of products used by clinicians that provide healthcare for children that includes recommendations specific to maternal health. CMS invites input on stakeholder experiences with this informational resource and comments on how to advance this work.

Using common data exchange standards for human services information can also provide many benefits for supporting maternal healthcare, including, but not limited to, promoting greater information-sharing and interoperability, collaboration with other human services sectors beyond healthcare such as education and public safety, and overall improvements to systems for the effective use of technology. CMS welcomes input on technical and policy approaches that effectively link maternal human services data to health IT codes and value sets, such as ICD-10 and LOINC codes, in order to help improve interoperability across multiple systems, domains, and use cases, including the effective use of interoperable assessment instruments. CMS further welcomes input on how other health IT standards, such as FHIR, can be used to expand healthcare interoperability to integrate with human services for individual maternal health and overall population health improvement.

The USCDI version 3, published in July 2022, contains a new data class on pregnancy status, as well as other data classes and elements important for supporting maternal health, including SDOH Assessment, Diagnostic Imaging, and Vital Signs. While exchange of the USCDI version 3 dataset is neither currently required nor proposed in this proposed rule, we intend to work with both our Federal partners and industry stakeholders to encourage harmonization of data elements tied to improved maternal health outcomes.

In addition, ONC recently launched an initiative called USCDI+ to support the identification and establishment of domain, or program-specific, datasets that build on the existing USCDI dataset. USCDI+ is a service that ONC provides to Federal partners to establish, harmonize (that is, unify disparate datasets), and advance the use of interoperable datasets that extend beyond the core data in the USCDI to support agency-specific programmatic requirements. The USCDI+ initiative could advance availability of maternal health information to meet Federal partners' needs. For instance, by identifying and harmonizing data elements needed for quality reporting on maternal health measures under the Hospital IQR program. As such, we are interested in feedback from the public on the following questions:

• Are there other data elements and classes relevant to care coordination for maternal health that should be added to USCDI?

• Are there data related to maternal health that are currently not collected at scale, or not collected at all, that would be helpful for stakeholders to have access to? How could CMS support the collection of this data?

• What are key gaps in the standardization and harmonization of maternal health data? How can HHS support current efforts to address these gaps?
• How could an initiative such as USCDI+ be leveraged to harmonize maternal health data needed for care coordination, quality measurement, and other Federal programs that collect maternal health data?

In section II.D of this proposed rule, we discuss our proposals to improve prior authorizations. In addition to the impacts on patient care in general discussed in that section, we note the effects of inefficient prior authorizations on maternal health, specifically. For instance, maternal care experts have observed that some payers may utilize an intermediary, such as a radiology benefits management company, to act on their behalf to review healthcare provider requests to perform imaging. This may add an additional waiting period for a decision, potentially creating hazardous delays for pregnant women who, for example, need to obtain an ultrasound. Furthermore, requiring prior authorization for screening cervical length in patients with a prior history of preterm birth or growth ultrasound for women at risk for fetal growth restriction can place patients at risk for adverse perinatal outcomes. We are therefore interested in stakeholder feedback on the following questions:

• Should there be special considerations for the prior authorization process in maternal healthcare? For example, should the timeframes for prior authorization be expedited in cases where the prior authorization is related to prenatal and perinatal care?
• How have prior authorization processes impacted maternal healthcare for patients enrolled in CMS programs? Please include references to specific CMS program(s) in your response.
• Should prior authorizations carry over from one payer to another when a patient changes payers for the duration of the pregnancy, or at least for a period of time while the patient and their provider gather the necessary documentation to submit a new prior authorization to the new payer?
• What other special considerations should be given to data sharing for maternal health transitions?

E. Request for Information: Advancing the Trusted Exchange Framework and Common Agreement (TEFCA)

Section 4003(b) of the 21st Century Cures Act (Pub. L. 114-255), enacted in 2016, amended section 3001(c) of the Public Health Service Act (42 U.S.C. 300jj-11(c)) and required HHS to take steps to advance interoperability for the purpose of ensuring full network-to-network exchange of health information. Specifically, Congress directed the National Coordinator to “develop or support a trusted exchange framework, including a common agreement among health information networks nationally.” Since the enactment of the 21st Century Cures Act, HHS has pursued the development of TEFCA. ONC's goals for TEFCA are:

Goal 1: Establish a universal policy and technical floor for nationwide interoperability.

Goal 2: Simplify connectivity for organizations to securely exchange information to improve patient care, enhance the welfare of populations, and generate healthcare value.

Goal 3: Enable individuals to gather their healthcare information.

On January 18, 2022, ONC announced a significant TEFCA milestone by releasing the Trusted Exchange Framework and Common Agreement for Nationwide Health Information Interoperability Version 1 (Common Agreement). The Trusted Exchange Framework is a set of non-binding principles for health information exchange, and the Common Agreement is a contract that advances those principles. The Common Agreement and the Qualified Health Information Network (QHIN) Technical Framework Version 1 (QTF), which is incorporated by reference in the Common Agreement, establishes a technical infrastructure model and governing approach for different health information networks (HINs) and their users to securely share clinical information with each other, all under commonly agreed to terms. The Common Agreement is a legal contract that QHINs sign with the ONC Recognized Coordinating Entity (RCE), a private-sector entity that implements the Common Agreement and ensures QHINs comply with its terms.

The technical and policy architecture of how exchange occurs under the Common Agreement follows a network-of-networks structure, which allows for connections at different levels and is inclusive of many different types of entities at those different levels, such as HINs, care practices, hospitals, public health agencies, and Individual Access Services (IAS) Providers. QHINs connect directly to each other to facilitate nationwide interoperability, and each QHIN can connect Participants, which can connect Subparticipants. Compared to most nationwide exchange today, the Common Agreement includes an expanded set of Exchange Purposes beyond Treatment to include IAS, Payment, Health Care Operations, Public Health, and Government Benefits Determination —all built upon common technical and policy requirements to meet key needs of the U.S. healthcare system. This flexible structure allows stakeholders to participate in the way that makes the most sense for them, while supporting simplified, seamless exchange. The Common Agreement also requires strong privacy and security protections for all entities who elect to participate, including entities not covered by HIPAA. For the purposes of this RFI, we broadly refer to different modes of exchange by different stakeholders under this framework as, “enabling exchange under TEFCA.”

The QTF, which was developed and released by the RCE, describes the functional and technical requirements that a HIN must fulfill to serve as a QHIN. The QTF specifies the technical underpinnings for QHIN-to-QHIN exchange and certain other responsibilities described in the Common Agreement. The technical and functional requirements described in the QTF enable information exchange modalities, including querying and message delivery, across participating entities.

The Common Agreement and the QTF do not require HL7 FHIR-based exchange. The Common Agreement and QTF allow for the optional exchange of FHIR content using more traditional, established standards to enable the transport of that content. However, TEFCA can nonetheless be a strong catalyst for network enablement of FHIR maturation. To that end, the RCE released a 3-year FHIR Roadmap for TEFCA Exchange, which lays out a deliberate strategy to add FHIR-based exchange under the Common Agreement and the QTF in the near future.

In 2022, prospective QHINs had the opportunity to begin signing the Common Agreement and apply for designation. Following the approval of their applications, the RCE will begin onboarding and designating QHINs to exchange information. In 2023, HHS expects stakeholders across the care continuum to have increasing opportunities to enable exchange under TEFCA.

In the FY 2023 IPPS/LTCH final rule (87 FR 48780), we finalized our proposal to add a new, optional Enabling Exchange Under TEFCA measure to the Health Information Exchange Objective in the Medicare Promoting Interoperability program. This measure will provide eligible hospitals and CAHs with the opportunity to earn credit for the Health Information Exchange objective if they: (1) are a signatory to a “Framework Agreement” as that term is defined in the Common Agreement; (2) are in good standing (that is, not suspended) under that agreement; (3) enable secure, bi-directional exchange of information to occur for all unique patients discharged from the eligible hospital or CAH inpatient or emergency department (Place of Service (POS) code 21 or 23), and all unique patient records stored or maintained in the EHR for these departments; (4) and use the functions of CEHRT to support bi-directional exchange. The FY 2023 IPPS/LTCH proposed rule (87 FR 28108) also included a request for information about how TEFCA can support CMS policies and programs and how these programs can help to advance exchange under TEFCA to deliver value for stakeholders. The CY 2023 PFS proposed rule (87 FR 45860) likewise includes a nearly identical measure for MIPS eligible clinicians as part of the MIPS Promoting Interoperability Performance Category.

We believe that the ability for stakeholders to connect to an entity that connects to a QHIN, or to connect directly to a QHIN, can support and advance the payer requirements that we have proposed in this rule that would become applicable by 2026 if enacted as proposed. Specifically, such connections could support exchange of patient information with providers via the Provider Access API and support transmission of coverage and prior authorization requests from providers via the PARDD API. As requirements for use of FHIR are incorporated into the QTF, stakeholders that enable exchange under TEFCA will be better positioned to not only exchange the data we propose to require for these APIs, but also to do so in a multi-networked environment that simplifies connections between providers and payers. We similarly believe that such connections could support requirements for the Patient Access API previously finalized in the CMS Interoperability and Patient Access final rule (85 FR 25510) by enabling patients to access their information held by the payer, as well. As previously noted, TEFCA can be a strong catalyst for FHIR maturation. To the extent that TEFCA evolves in accordance with the FHIR Roadmap for TEFCA Exchange, we anticipate further opportunities for TEFCA to support information availability via FHIR API exchange requirements for payers.

We believe enabling exchange under TEFCA by payers and vendors offering health apps could provide a simplified way for vendors to access and make information available to their customers. By accessing payer-held information through a QHIN or an entity connected to a QHIN, health apps could avoid the need to develop direct connections to each individual payer. This is because such apps could connect once and enable patients to gain access to information held by any payer exchanging information under TEFCA. Furthermore, as discussed in section II.A., apps that enable exchange under TEFCA would be required to meet the Common Agreement's privacy and security requirements, which would provide assurance to payers that they meet a common standard for protecting patient data.

Enabling exchange under TEFCA by health plans could also support the proposed requirements in section II.C. of this proposed rule for a payer to payer data exchange using FHIR APIs under which payers would make beneficiary information available to other plans when patients change their coverage. Health plans that enable exchange under TEFCA could easily identify other plans that hold information about a newly covered beneficiary by querying the network and securely requesting the information that would be required to be shared under our proposed requirements for the payer to payer data exchange.

We are requesting input from the public on the ideas previously described in this section and related concepts for future exploration, as well as the following questions:

• How could the requirements of the Common Agreement and the QTF help facilitate information exchange in accordance with the final policies in the CMS Interoperability and Patient Access final rule (85 FR 25510) around making clinical and administrative information held by health plans available to patients? How could TEFCA support proposed requirements for payers under this rule related to provider data access and prior authorization processes?
• How should CMS approach incentivizing or encouraging payers to enable exchange under TEFCA? Under what conditions would it be appropriate to require this approach by payers subject to the proposed regulations in this rule and previously finalized regulations in the CMS Interoperability and Patient Access final rule (85 FR 25510)?
• What concerns do commenters have about potential requirements related to enabling exchange under TEFCA? Could such an approach increase burden for some payers? Are there other financial or technical barriers to this approach? If so, what should CMS do to reduce these barriers?

We seek comments on these questions and issues for future consideration.

V. Collection of Information Requirements

Under the Paperwork Reduction Act 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 Office of Management and Budget (OMB) for review and approval. To fairly evaluate whether an information collection should be approved by OMB, section 3506(c)(2)(A) of the Paperwork Reduction Act (PRA) of 1995 requires that we solicit comment on the following issues:

• The need for the 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 are requesting public comment on each of these issues for sections of this document that contain information collection requirements (ICRs).

A. Background

To advance our commitment to interoperability, we are proposing new requirements for certain impacted payers to implement FHIR APIs and several process improvements to help streamline the prior authorization process. The proposed FHIR APIs would permit patients, providers, and payers to access a defined set of standardized data. We additionally propose to require impacted payers to implement a FHIR Prior Authorization Requirements, Documentation, and Decision (PARDD) API to support prior authorization processes; to reduce the amount of time to process prior authorization requests and send information about decisions; and to publicly report certain metrics about patient access utilization, and prior authorization processes, among other proposals. We also propose a new requirement for a Payer-to-Payer API to ensure data can follow patients when they change payers. Finally, we propose to require reporting of certain metrics regarding the use of the existing Patient Access API. Combined, these proposals are intended to reduce burden on providers, payers, and patients and support improvements in patient care coordination.

To incentivize provider participation, specifically with the PARDD API, we are proposing a new measure for MIPS eligible clinicians under the Promoting Interoperability performance category of MIPS and for eligible hospitals and CAHs under the Medicare Promoting Interoperability Program related to electronic prior authorization beginning in 2026, but the measure would not be scored until a future date. We would propose future year scoring and the number of points associated with the measure in future rulemaking. This new measure will be included in a PRA package related to this proposed rule.

B. Wage Estimates

To derive average costs, we use data from the U.S. Bureau of Labor (BLS) Statistics' National Occupational Employment and Wage Estimates ( https://www.bls.gov/oes/current/oes_nat.htm ), and to the extent possible, align with other CMS regulatory actions. Table 11 presents the mean hourly wage, the cost of fringe benefits (calculated at 100 percent of salary), and the adjusted hourly wage.

We are adjusting the employee hourly wage estimates by a factor of 100 percent, or doubling the BLS wage estimates. This is necessarily 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. Methods of estimating these benefits and overhead costs can vary across studies. We have elected to use sources in alignment with other CMS regulations after determining that they have used similar estimates and formulas.

Consistent with our approach in the CMS Interoperability and Patient Access final rule (85 FR 25622), we determine ICRs by evaluating cost and burden at the impacted payer level, as defined and discussed in detail in that rule. Ultimately, we determined that there are 365 impacted payers that together represent the possible plans, entities, issuers, and state programs impacted by these proposals. The increase in impacted payers from the CMS Interoperability and Patient Access final rule corresponds to the average annual increase in impacted payers resulting from new market entries. The total estimated burden on these impacted payers is described in detail in each of the following ICRs and the summary table (M9) 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 5.3 million hours; assuming a total cost to impacted payers to begin at approximately $110 million in the first year, increasing to $221 million in the second and third year and going down to $142 million by the fifth and subsequent years. We describe each ICR in detail and request comment on the assumptions made in deriving these burden estimates. All burden estimates will also be described and the public will have an opportunity to comment on them in a forthcoming PRA package to accompany this proposed rule.

1. ICRs Regarding the Proposal To Require Reporting of Patient Access API Metrics to CMS (42 CFR 422.119, 431.60, 438.242, 457.730, and 457.1233 and 45 CFR 156.221)

To assess whether our policy requirements concerning the Patient Access API finalized in the CMS Interoperability and Patient Access final rule (85 FR 25558) have been implemented, we are proposing to require impacted payers to annually report certain metrics to CMS on the use of the Patient Access API. Specifically, we are proposing to collect: 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. We estimate that impacted payers would conduct two major work phases: (1) implementation, which includes defining requirements and system design (and updates) 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 would need to prepare their systems to capture the data to be transmitted to CMS.

The burden estimate related to the new proposed requirements reflects the time and effort needed to identify, collect, and disclose the information. We estimate an initial set of one-time costs associated with implementing the reporting infrastructure and an ongoing annual maintenance cost to report after the reporting infrastructure is established.

Table 12 presents our preparatory computational estimates for first-year implementation and ongoing maintenance costs. Table 12 is not the official statement of burden, which is found in Table 19, including the number of respondents and responses. Table 12 presents the preparatory calculations needed to create the official statement of burden in Table 19. We assume a two-person team of a software/web developer and a business operations specialist would spend an aggregate of 160 and 40 hours, respectively, for the first and subsequent years, at a total cost per impacted payer (rounded) up to $15,000 and $3,000, for the first and subsequent years. The aggregate burden (rounded) for 365 impacted payers would be 60,000 hours and 15,000 hours for the first and subsequent years at a cost of $5.5 million and $1 million for the first and subsequent years.

We request comment on our assumptions and approach.

2. ICRs Regarding the Provider Access API Proposal (42 CFR 422.121, 431.61, 438.242, 457.731, and 457.1233 and 45 CFR 156.221)

To promote our commitment to interoperability, we propose new requirements for a Provider Access API. This FHIR API would permit providers to receive standardized patient data to coordinate care. To estimate costs to implement the new requirements for new APIs proposed in this rule, we use the same methodology as that used in the CMS Interoperability and Patient Access final rule.

In the CMS Interoperability and Patient Access final 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 proposed rule, we assume the same major phases of work would be required, with a different level of effort during each work phase, for each of the new proposed APIs. Consistent across all newly proposed API provisions, we describe the tasks associated with the first two phases. Where we believe additional effort associated with these tasks is necessary, we describe those as relevant in subsequent ICRs, depending on how we believe they affect cost estimates. We discuss the costs for the third phase, long-term support and maintenance, and our methodology for the development of those costs in aggregate for all proposed APIs in this section.

In the initial design phase, we believe tasks would include: determining available resources (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, performing a data availability scan to determine any gaps between internal data models and the data required for the necessary HL7 FHIR resources, and mitigating any gaps discovered in the available data.

During the development and testing phase, we believe impacted payers would need to conduct the following: map existing data to the HL7 FHIR standards, allocate hardware for the necessary environments (development, testing, production), build a new FHIR-based server or leverage existing FHIR servers, determine the frequency and method by which internal data are populated on the FHIR server, build connections between the databases and the FHIR server, perform capability and security testing, and vet provider requests.

Table 13 summarizes the aggregate burden for complying with the proposed Provider Access API requirements. Here we provide illustrative points explaining the calculations within the table and the terms used for the headings. For example, row one is titled “Database Administrators and Architects.” To develop the proposed Provider Access API, each organization will require a team of database administrators, engineers, computer system analysts, etc. The team members are detailed in the rightmost column.

Continuing on the top row, “Database Administrators,” we obtained the labor cost of $97.20 per hour from the Bureau of Labor Statistics website. The $97.20 represents the mean wage for this occupational title. We assume most organizations would require 3 months of work for Database Administrators on this task. Three months is twelve weeks, or 480 hours (3 months × 4 weeks per month × 5 days a week × 8 hours per day). 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, refers to the amount of time most organizations would require to conduct this work. This totals a cost of $46,656 for each organization, which 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 also provide low and high estimates representing a range of possible time and cost across all organizations. The low estimate is half the primary estimate, which is 240 hours or 1.5 months. The high estimate is 720 hours representing 4.5 months. These numbers are found in the low and high columns (hours) of the top row. The corresponding low and high costs are multiplied by the $97.20 per hour wage. We estimate that this is a reasonable range that would include all organizations. A typical organization would take 3 months, with some organizations completing the work in less time (in as little as 1.5 months) and some organizations taking longer (up to 4.5 months).

The explanation of the top row applies to each of the ten occupational titles. The sum of the total hours and cost 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 would take a total of 2,800 hours at a cost of $270,045. We estimated the impact by organization rather than by payer since many organizations may have entities in several of the programs to which this proposed rule applies: Medicare Advantage, Medicaid, CHIP, and QHP issuers on the FFEs.

To arrive at the total cost of the rule, we multiplied the single-organization cost by 365 payers, the number of organizations hosting plans across the four 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, we estimated maintenance costs in future years after the API is established at 25 percent of the aggregate cost. This 25 percent was arrived at based on our experience with the industry. Rather than list more columns or create another table, we provide a footnote indicating that maintenance is 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 would be $24.6 million (25 percent × $98.6 million).

Although this provision would first be applicable on January 1, 2026, we believe it is reasonable that the APIs would 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 CMS Interoperability and Patient Access final rule (85 FR 25606), we estimate that the development of the APIs would require 6 to 12 months of work. Expecting that this proposed rule will be finalized by mid-year 2023, we have distributed the cost over approximately two-and-a-half calendar years to give payers the flexibility to complete the necessary work (see Table 19).

We request comment on our approach and assumptions for the cost of the Provider Access API, including whether our estimates and ranges are reasonable or should be modified.

a. API Maintenance Costs—All Proposed APIs

We discuss the costs for the third phase, long-term support and maintenance, and our methodology for the development of those costs in aggregate for all APIs discussed in this proposed rule. As relevant to the APIs discussed in sections V.C.1., 3., 4., and 8., we estimate ongoing maintenance costs for the Provider Access API, PARDD API, and Payer-to-Payer API in aggregate. This approach aligns with the strategy taken in the CMS Interoperability and Patient Access final rule (85 FR 25605), whereby the costs of the API development are split into three phases: initial design, development and testing, and long-term support and maintenance. However, unlike the CMS Interoperability and Patient Access final rule, this proposed rule assumes that maintenance costs only account for the cost associated with the technical requirements as outlined in this rule. Any changes to requirements would require additional burden, which would be discussed in future rulemaking. Throughout the Collection of Information section, we discuss the initial design, development, and testing costs per API. We next discuss the total maintenance cost for all four APIs.

As discussed in the CMS Interoperability and Patient Access final rule (85 FR 25606), once the API is established, we believe there would 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 gained in implementation and maintenance due to the fact that these proposed APIs rely on several of the same underlying foundational technical specifications and content. For example, the same baseline standards apply, including the HL7 FHIR Release 4.0.1 and complementary security and app registration protocols. Specifically, the HL7 SMART Application Launch Implementation Guide (SMART IG) 1.0.0, including mandatory support for the “SMART on FHIR” Core Capabilities. However, we do believe that maintenance costs would be higher than what we estimated for the CMS Interoperability and Patient Access final rule for the new APIs proposed in this 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 demonstrating APIs for provider access, prior authorization, and payer to payer data exchange. We estimate an annual cost averaging approximately 25 percent of the primary estimate for one-time API costs. In the Summary Table (Table 19), 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 recommended IGs across the proposed 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 request public comment on our approach and assumptions for the aggregate maintenance cost of the APIs, including whether our estimate is reasonable or should be modified.

3. ICRs Regarding the Prior Authorization Requirements, Documentation, and Decision (PARDD) API Proposal (42 CFR 422.122, 431.80, 438.242, 457.732, and 457.1233 and 45 CFR 156.223)

We propose new requirements for the implementation of a PARDD API. This API would address several major 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. Use of this proposed API would begin on January 1, 2026, for MA and Medicaid and CHIP FFS, for Medicaid managed care plans and CHIP managed care entities by the rating period beginning on or after January 1, 2026, and for QHPs on the FFEs for plan years beginning on or after January 1, 2026.

As discussed previously for the Provider Access API, to implement the proposed new requirements for the PARDD API, we estimate that impacted payers would conduct three major work phases: initial design, development and testing, and long-term support and maintenance. Furthermore, for this proposed API, we believe additional tasks are necessary to accomplish the proposed requirements, which we describe below as they affect the cost estimates. For the costs for the third phase—long-term support and maintenance—our methodology for the development of those costs in aggregate for all proposed APIs is presented in section V.C.3. of this proposed rule.

We base our estimate on feedback from industry experts on the anticipated burden of implementing the PARDD API. We believe this to be a reasonable estimate of the implementation burden on payers to develop APIs that can facilitate the prior authorization process. In addition to implementing the PARDD API, these payers would be required to send a reason for denial for prior authorization requests that are denied. As discussed in section II.D. of this proposed rule, while the PARDD API would use the HL7 FHIR standard to support its basic capabilities, covered entities must also use the adopted X12 278 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 also makes the HL7 standards, IGs, many reference implementations, and test scripts available free of charge to the healthcare and developer community. These low- or no-cost HL7 resources support our belief that payers would incur minor costs for implementing the new standards. As such, we have accounted for the necessary engineers, subject matter experts, and health informaticists in our estimates. These personnel resources would, for example, need to convert payers' prior authorization documentation 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 could interface with the provider's EHR or practice management system, create and execute mapping between the HL7 and X12 codes, and integrate the PARDD API with the payer's system.

As noted previously, although this provision would be applicable on January 1, 2026, this API would be under development before that date. Acknowledging that impacted payers would have varying technological and staffing capabilities, we estimate that the development of the API would require 6 to 12 months of work. Expecting that this proposed rule will be finalized by mid-year 2023, we have distributed the cost over approximately two-and-a-half calendar years to give payers the flexibility to complete the necessary work (see Table 19).

Table 14 presents total burden estimates for the PARDD API (initial design phase and the development and testing phase). This table presents the calculations associated with the total costs. The numbers from this table are used in the summary table (Table 19) 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, we used the medium estimate as the primary estimate.

The narrative description provided for Table 13 also applies to Table 14. 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 request public comment on our approach and assumptions for the one-time implementation cost of the PARDD API, including whether our estimates and ranges are reasonable or should be modified.

4. ICRs Regarding Proposed 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)

To increase transparency and reduce burden, we are proposing to require that impacted payers, not including QHP issuers on the FFEs, send prior authorization decisions within 72 hours for urgent requests and 7 calendar days for non-urgent requests. We are proposing that the payers would have to comply with these provisions 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).

In order to implement this policy, there would 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 15:

We request public comment on our assumptions, estimates, and approach.

5. ICRs Regarding the Proposed 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 payer networks to join, we are proposing to require that impacted payers publicly report certain plan-level prior authorization metrics on their websites or via a publicly accessible hyperlink(s). Impacted payers would be required to report aggregated data annually for the previous calendar year's data, beginning March 31, 2026.

We estimate that impacted payers would conduct two major work phases: implementation, which includes defining requirements and 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 or through a publicly accessible hyperlink(s). In the first phase, we believe impacted payers would need to define requirements concerning the types and sources of data that would 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, we believe impacted payers would need to create the reports and post them to a public web page annually.

Table 16 discusses the activities, hours, and dollar burdens for the first-year implementation and estimated annual maintenance costs. We assume a team of two staff consisting of a software and web developer with a business operations specialist.

• First-year implementation would 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 would 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.

We request public comment on this approach and our assumptions.

6. ICRs Regarding the Payer-to-Payer API Proposal (42 CFR 422.121, 431.61, 438.242, 42 CFR 457.731, and 457.1233 and 45 CFR 156.222)

To improve patient access to their health information through care coordination between health plans, as discussed in section II.C. of this proposed rule, we propose new requirements for impacted payers to implement and maintain a Payer-to-Payer API. These proposals would improve care coordination among payers by requiring payers to exchange, at a minimum, adjudicated claims and encounter data (excluding provider remittances and enrollee cost-sharing information), all data classes and data elements included in a content standard at 45 CFR 170.213, and pending and active prior authorization decisions. This exchange would be done using an HL7 FHIR Payer-to-Payer API implemented by 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 QHPs on the FFEs for plan years beginning on or after January 1, 2026). For a complete discussion of the data types proposed to be exchanged, please refer to section II.C. of this proposed rule.

As discussed for the other APIs proposed in this rule, we estimate that impacted payers would conduct three major work phases: initial design, development and testing, and long-term support and maintenance. For the Payer-to-Payer API, we believe there may be additional tasks necessary to accomplish the proposed requirements, which we describe below with respect to their impact on cost estimates. The costs for the third phase, long-term support and maintenance, and our methodology for the development of those costs in aggregate for all proposed APIs are presented in section IV.C.3. of this proposed rule.

Payers should be able to leverage the API infrastructure already accounted for in the Patient Access API finalized in the CMS Interoperability and Patient Access final rule and the Provider Access API proposal in this rule. As discussed in the CMS Interoperability and Patient Access final rule (as well as the companion 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program final rule (85 FR 25642)) and this proposed rule, payers would be using the HL7 FHIR standards for content and transport, recommended IGs to support interoperability of data sharing, as well as the same underlying standards for security, authentication, and authorization. Taken together, these standards would support the proposed Payer-to-Payer API. Thus, we believe there would be some reduced development costs to implement the Payer-to-Payer API because of efficiencies gained in implementing the same underlying standards and IGs for the other APIs proposed in this rule.

We believe there would be some costs for impacted payers to implement the proposed Payer-to-Payer API that are unique to this API. Based on input from current industry experience testing the implementation of 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 proposed required standards. As such, we have accounted for the necessary skill sets of staff required as we also believe there would be unique costs for implementing the HL7 FHIR Payer Coverage Decision Exchange (PDex) IG so that payers can exchange active and pending prior authorization decisions and related clinical documentation and forms when an enrollee or beneficiary enrolls with a new impacted payer.

Table 17 presents the total activities, hours, and dollar burdens for implementing the Payer-to-Payer API given our assumptions (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, we have the medium estimate as the primary estimate. We have included a similar narrative explanation of Table 17 as that provided for Table 13 above.

• For the primary estimate, one-time implementation efforts for the first two phases would 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 would be 334,000 hours (rounded) at the cost of $35.1 million (rounded). This corresponds to the primary estimate; the primary and high estimates are obtained by multiplying the low estimate by factors of two and three, respectively.

As noted previously, although this provision would be applicable on January 1, 2026, we believe the APIs would be under development before that date. Acknowledging that impacted payers would have varying technological and staffing capabilities, we estimate that development of the APIs would require 6 to 12 months of work. Expecting that this proposed rule will be finalized by mid-year 2023, we have distributed the cost estimates over approximately two-and-a-half calendar years to give impacted payers the flexibility to complete the work (see Table 19).

We request 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.

7. ICRs Regarding the Electronic Prior Authorization Measure for QPP MIPS 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).

As explained in section II.E. of this proposed rule, commenters to the December 2020 CMS Interoperability proposed rule (85 FR 82586) expressed support for requiring healthcare providers to use electronic prior authorization as part of the QPP MIPS for MIPS eligible clinicians, or the Conditions of Participation/Conditions for Coverage requirements for eligible hospitals, and other providers and suppliers. Commenters indicated these would be appropriate levers by which CMS should propose new or additional provisions that would require the use of APIs to enable enhanced electronic documentation discovery and facilitate electronic prior authorization.

To incentivize MIPS eligible clinicians, eligible hospitals, and CAHs to implement and use electronic prior authorization and the corresponding API, we are proposing in section II.E. of this proposed rule to add a new measure titled “Electronic Prior Authorization” 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 performance period/EHR reporting period in CY 2026.

We are proposing that MIPS eligible clinicians, eligible hospitals, and CAHs must report the Electronic Prior Authorization measure beginning with the CY 2026 performance period/EHR reporting period, but the measure would not be scored for CY 2026. For this measure, we propose that a MIPS eligible clinician, eligible hospital, or CAH must request a prior authorization electronically from a PARDD API using data from CEHRT and report a numerator and denominator or claim an exclusion if applicable.

The burden in implementing these proposed requirements consists of the following steps: creating or implementing software to capture the data, capturing the data, and reporting the measure as specified by CMS. Beyond implementation, the burden lies in maintaining compliance of the system to support all functionality, including the ability to generate accurate and timely reports. We assume the annual maintenance cost would include updates to the software to meet new reporting requirements for the QPP MIPS Promoting Interoperability performance category and the Medicare Promoting Interoperability Program on behalf of participating MIPS eligible clinicians, eligible hospitals, and CAHs. Such an update would include the ability to report the electronic prior authorization measure as required by CMS. 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, and adding new tasks. Maintenance requirements for systems both in this proposed rule and in the December 2020 CMS Interoperability proposed rule 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). Therefore, although we anticipate there would be a moderate software update to implement the provisions of this proposed rule, there would 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 healthcare providers who may be required to retain such data for compliance and regulatory reasons. To report the measure as specified by CMS, the actual added burden that the proposals in this proposed rule would impose is the burden of extracting data and preparing it in report form.

For the added burden of extracting, compiling, reviewing, and submitting data, we assume that for each report, a Medical Records Specialist would spend half a minute extracting the already-existing data at a cost of $0.39 ( 1/2 minute × $46.42 per hour). Then, 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 18.

The following items provide support and rationale for the entries in Table 18:

• The hourly burden estimates of 1/2 minute (1/120 = 0.00833 hour) for transmission of the measure to CMS are consistent with the revised estimates of burden presented in the FY 2023 IPPS/LTCH PPS final rule (87 FR 49396). 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 2023 IPPS/LTCH PPS final rule (87 FR 49393).
• The existing QPP MIPS reporting policies allow MIPS eligible clinicians to report at the individual or group level. Based on the information available from Table 122 in the CY 2023 PFS final rule (87 FR 69404, 70154), we estimate 54,770 individual or group MIPS eligible clinicians would submit data for the Promoting Interoperability performance category for the CY 2026 performance period/CY 2028 MIPS payment year. The 54,770 is the sum of the 43,117 individual clinicians expected to submit performance data to QPP MIPS, plus the 11,633 groups expected to submit performance data to QPP MIPS, plus 20 subgroups. The information collection requirements currently approved under OMB control number 0938-1314 are approved through January 31, 2025.

The FY 2023 IPPS/LTCH PPS final rule uses median hourly wages (87 FR 49393), whereas this proposed rule and the CMS Interoperability and Patient Access final rule (85 FR 25605) use mean hourly wages. For purposes of illustration, we have provided both estimates.

For eligible hospitals and CAHs the total cost is $1,740 (4,500 hospitals and CAHs × 1/2 minute × $46.20 per hour), which equals 0.002 million as listed in Table 19. This rounds to $0.0 million. Calculations using the median instead of the average are similar. This shows that the bottom-line rounded figure would not change if we used the median instead of the average. However, the entries in the COI Summary Table (M9) are $0.0 million consistent with rounding accounting, and the actual numbers are provided in the table. The costs of this provision 5 years after the finalization of the rule are provided in the Summary Table, M9.

For MIPS eligible clinicians, the total cost is $21,186 (54,770 clinicians × 1/2 minute × $46.20 per hour). Since this summary table, M9, feeds into the RIA summary table, we expressed this $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 listed in Table 19. This would round to $0.0.

D. Summary of Information Collection Burdens

The previous sections have explained the costs of individual provisions in the proposed rule. Table 19 summarizes costs for the first and subsequent years of these provisions and is based on the following assumptions:

• A publication date of mid-year 2023 for the final rule.
• The effective date for all provisions is January 1, 2026. For the Electronic Prior Authorization measure, this would be required for the QPP MIPS Promoting Interoperability performance category beginning with the 2026 performance period for MIPS eligible clinicians and the Medicare Promoting Interoperability Program starting with the 2026 EHR reporting period for eligible hospitals and CAHs. Accordingly, the COI summary Table 19 reflects costs beginning in 2027, which is year 5 relative to mid-year 2023, the expected publication date of this proposed rule. The table below summarizes the total information burden for all reporting requirements, APIs, and the reporting required under the QPP MIPS Promoting Interoperability performance category and the Medicare Promoting Interoperability Program. The last line of the table is the total cost for all impacted payers and providers, the estimated burden, and the costs per year. The text below offers highlights from our analysis.
• For the three new APIs (Provider Access, Prior Authorization Requirements, Documents, and Decisions (PARDD), and Payer-to-Payer), we assume implementation would take place uniformly over 30 months (the time from the expected publication date (mid-year 2023) for the final rule until the applicable compliance date in 2026).
• Maintenance costs for the three APIs are, as indicated in the tables of this section, assumed to be 25 percent of total costs; we believe these maintenance costs would be incurred in years 2026 and beyond.
• For provisions requiring policy updates or first-year implementation costs, we believe it is most reasonable that these first-year costs would take place in 2026, the first year the rule is in effect, and that subsequent year implementation costs, as reflected in the various tables in this section, would take place in years 2027 and beyond.
• Since the Electronic Prior Authorization measure would not be applicable until 2026, no costs are reflected from 2023 through 2025.
• Since the targeted publication date of this final rule is mid-year 2023, we treat 2023 as a half-year. For purposes of allocating software development costs, 2023 is therefore one-half the costs expected to be incurred during 2024 and 2025.
• Labor costs in Table 19 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. For example, in the first row, $94.32 equals the aggregate $5.5 million cost divided by the aggregate 58,400 hours.

We also note that Table 19 reflects the primary estimate. The full range of estimates for all provisions is presented in the RIA section of this proposed rule.

E. Conclusion

The provisions of this proposed rule could improve data sharing across stakeholders 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 request comment on our approaches for estimating cost burden and cost savings.

The requirements of this proposed rule are extensions of the requirements of the CMS Interoperability and Patient Access final rule (85 FR 22510). Therefore, the information collection requirements will be submitted to OMB for review and approval.

If you would like to provide feedback on these information collections, please submit your comments electronically as specified in the ADDRESSES section of this proposed rule. Comments must be received on/by March 13, 2023.

V. Regulatory Impact Analysis

A. Statement of Need

As described in prior sections of this proposed rule, the proposed changes to 42 CFR parts 422, 431, 435, 438, 440, and 457 and 45 CFR part 156 further support CMS' efforts to empower patients by increasing electronic access to healthcare data, while keeping that information safe and secure. The proposals in this rule build on the foundation we laid out in the CMS Interoperability and Patient Access final rule to move the healthcare system toward increased interoperability by proposing to increase the data sharing capabilities of impacted payers, encourage healthcare providers' use of new capabilities, and make health-related data more easily available to patients through standards-based technology.

If finalized, the proposals in this rule would 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 improve the electronic exchange of health-related data and streamline prior authorization processes. And these proposals could improve health information exchange and facilitate appropriate and necessary patient, provider, and payer access to health information via APIs. Our proposals related to prior authorization are also intended to improve certain administrative processes. The proposed rule would also add a new measure for eligible hospitals and CAHs under the Medicare Promoting Interoperability Program and for MIPS eligible clinicians under the QPP MIPS Promoting Interoperability performance category.

B. Overall Impact

We have examined the impacts of this proposed 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), the Regulatory Flexibility Act (RFA) (September 19, 1980, Pub. L. 96-354), section 1102(b) of the Act, section 202 of the Unfunded Mandates Reform Act of 1995 (March 22, 1995, Pub. L. 104-4), and Executive Order 13132 on Federalism (August 4, 1999).

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). 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 $100 million or more in any 1 year, or adversely and materially affecting a sector of the economy, productivity, competition, jobs, the environment, public health or safety, or state, local, or tribal governments or communities (also referred to as “economically significant”); (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) raising novel legal or policy issues arising out of legal mandates, the President's priorities, or the principles set forth in the Executive order.

A Regulatory Impact Analysis must be prepared for major rules with economically significant effects ($100 million or more in any 1 year). Based on our estimates, OMB's Office of Information and Regulatory Affairs has determined this rulemaking is “economically significant” as measured by the $100 million threshold. Accordingly, we have prepared a Regulatory Impact Analysis that, to the best of our ability, presents the costs and benefits of this proposed rulemaking.

As noted later in this section, we believe that our proposed policies, if finalized, would result in some financial burdens for impacted payers and providers as discussed in section IV. of this proposed rule. We have weighed these potential burdens against the potential benefits, and believe the potential benefits outweigh any potential costs. Based on our estimates, the total burden across all providers would be reduced by at least 206 million hours over 10 years, resulting in a total cost savings over 10 years of approximately $15 billion (see Table 24). However, for reasons discussed later in this proposed rule, these savings are neither included in the 10-year Summary Table (N8), nor in the Monetized Table (N10).

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 Regulatory Flexibility Act (RFA)). If a proposed rule may have a significant economic impact on a substantial number of small entities, then the proposed rule must discuss steps taken, including alternatives considered, to minimize the burden on small entities. The RFA does not define the terms “significant economic impact” or “substantial number.” The Small Business Administration (SBA) advises that this absence of statutory specificity allows what is “significant” or “substantial” to vary, depending on the problem that is to be addressed in rulemaking, the rule's requirements, and the preliminary assessment of the rule's impact. Nevertheless, HHS typically considers a “significant” impact to be 3 to 5 percent or more of the affected entities' costs or revenues.

For purposes of the RFA, we estimate that many impacted payers and providers are small entities, as that term is used in the RFA, either by being nonprofit organizations or by meeting the SBA definition of a small business. For purposes of the RFA, small entities include small businesses, nonprofit organizations, and small governmental jurisdictions. The North American Industry Classification System (NAICS) is used in the U.S., Canada, and Mexico to classify businesses by industry. While there is no distinction between small and large businesses among the NAICS categories, the SBA develops size standards for each NAICS category. Note that the most recent update to the NAICS codes went into effect for the 2017 reference year; the most recent size standards were adopted in 2022.

In analyzing the impact of this proposed rule, we take note that there would be a quantifiable impact for the following stakeholders.

1. Payers

Updates to systems implementing the various APIs described throughout the preamble, including any reporting requirements, would be performed by the 365 payer organizations. Throughout this section of the proposed rule, we also use the term parent organizations to refer to the impacted payers, as we did in the CMS Interoperability and Patient Access final rule (85 FR 25510), which includes the state Medicaid and CHIP agencies. The combined parent organizations administer MA, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs.

The NAICS category relevant to these proposed provisions is Direct Health and Medical Insurance Carriers, NAICS 524114, which have a $41.5 million threshold for “small size.” Seventy-five percent of payers in this category have under 500 employees, thereby meeting the definition of small businesses.

If the proposals in this rule are finalized, the 365 parent organizations, including state Medicaid and CHIP agencies, would be responsible for implementing and maintaining three new APIs, updating policies and procedures regarding timeframes for making prior authorization decisions, and reporting certain metrics either to CMS or making information available to the public. MA organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs are classified as NAICS code 524114, direct health insurance carriers. We are assuming that a significant number of these entities are not small. We note that none of the state Medicaid and CHIP agencies are considered small. MA organizations and state Medicaid managed care plans and CHIP managed care entities have many of their costs covered through capitation payments from the Federal Government to MA organizations or through state payments. Based on this discussion, there is no significant burden.

If finalized as proposed, some QHP issuers on the FFEs would be able to apply for an exception to these requirements, and certain states operating Medicaid and CHIP FFS programs would be able to apply for an extension or exemption, under which they would not be required to meet the new API provisions of the proposed rule on the proposed compliance dates, provided certain conditions are met, as discussed in sections II.B., II.C., and II.D. of this proposed rule. We acknowledge that providing additional information for the annual APD submissions and existing reports would require effort, but we do not believe there would be significant burden to these entities from the proposals in this proposed rule if an extension or exemption is approved.

a. Medicare Advantage

Each year, MA organizations submit a bid for furnishing Part A and B benefits and the entire bid amount is paid by the Government to each plan if the plan's bid is below an administratively set benchmark. If a plan's bid exceeds that benchmark, the beneficiary pays the difference in the form of a basic premium (note that a small percentage of plans bid above the benchmark, whereby enrollees pay a basic premium in addition to their Part B premium; this percentage of plans is not “significant” as defined by the RFA and is explained later in this proposed rule).

MA plans with prescription drug coverage (MA-PDs) can also offer supplemental benefits, that is, benefits not covered under Original Medicare (or under Part D). These supplemental benefits are paid for through enrollee premiums, extra Government payments, or a combination of enrollee premiums and extra Government payments. Under the statutory payment formula, if the bid submitted by an MA plan for furnishing Part A and B benefits is lower than the administratively set benchmark, the Government pays a portion of the difference to the plan in the form of a “beneficiary rebate.” The rebate must be used to provide supplemental benefits (that is, benefits not covered under Original Medicare) and/or lower beneficiary Part B or Part D premiums. Some examples of these supplemental benefits include vision, dental, hearing, fitness, and worldwide coverage of emergency and urgently needed services.

To the extent that the Government's payments to plans for the bid plus the rebate exceeds costs in Original Medicare, those additional payments put upward pressure on the Part B premium, which is paid by all Medicare beneficiaries, including those in Original Medicare who do not have the supplemental enhanced coverage available in many MA plans.

Part D plans, including MA-PD plans, submit bids and those amounts are paid to plans through a combination of Medicare funds and beneficiary premiums. In addition, for certain enrolled low-income beneficiaries, Part D plans receive Government funds to cover most premium and cost-sharing amounts that those beneficiaries would otherwise pay.

Thus, the cost of providing services by these payers is funded by a variety of Government funding and in some cases by enrollee premiums. As a result, MA and Part D plans are not expected to incur burden or losses since the private companies' costs are being supported by the Government and enrolled beneficiaries. This lack of expected burden applies to both large and small health plans.

Small entities that must comply with MA regulations, such as those in this proposed rule, are expected to include the costs of compliance in their bids, thus avoiding additional burden, since the cost of complying with any final rule is funded by payments from the Government and, if applicable, enrollee premiums.

For Direct Health and Medical Insurance Carriers, NAICS 524114, MA organizations estimate their costs for the upcoming year and submit bids and proposed plan benefit packages. 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, which is a ceiling on bid payments annually calculated from Original Medicare data; or the benchmark, 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. Table 20 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. 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 20, both the percentage of plans and the percentage of affected enrollees are decreasing, and 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 proposed 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 these provisions, which also would have an economic impact. We have explained that at least 98 percent of MA organizations bid below the benchmark. Thus, their estimated 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). It would follow that if the provisions of this proposed 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 would 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, do not meet the RFA criteria of a significant number of plans.

It is possible that if the provisions of this proposed rule would otherwise cause bids to increase, MA organizations would 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 temporarily reduce profit margins, rather than reduce supplemental benefits. The temporary claim refers to the possibility that plans will 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 don't 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 and we request comment on the assessment of this outcome in association with this proposed rule.

Based on the previously discussed considerations, the Secretary has certified that this proposed 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 for the purpose of providing and financing medical assistance to specified groups of eligible individuals. States claim Federal matching funds on a quarterly basis based on their program expenditures. Since states are not small entities under the Regulatory Flexibility Act, we need not discuss, in the Initial Regulatory Flexibility Analysis, the burden imposed on them by this proposed rule. With regard to Medicaid managed care plans and CHIP managed care entities, since managed care plans receive 100 percent capitation from the state, we generally expect that the costs associated with the provisions of this proposed rule would be included in their capitation rates and may be reasonable, appropriate, and attainable costs irrespective of whether they are a small business. Consequently, we can assert that there would be no significant impact on a significant number of these entities.

As discussed in sections II.B., II.C., and II.D. for the proposed API provisions, states operating Medicaid FFS and CHIP FFS programs could apply for an extension of 1 year to come into compliance with the requirements of this proposed rule. These same organizations may also apply for an exemption from the requirements if certain conditions are met.

c. QHP Issuers on the FFEs

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, we estimate that any issuers that would be considered small businesses are likely to be subsidiaries of larger issuers that are not small businesses (78 FR 33238) and thus do 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, we propose an exception process be available for QHPs on the FFEs, which further helps to address burden that could otherwise prohibit a QHP issuer from participating in an FFE.

2. Providers

In response to public comments on the December 2020 CMS Interoperability proposed rule (85 FR 82586), CMS is proposing a new Electronic Prior Authorization measure for MIPS eligible clinicians under the QPP MIPS Promoting Interoperability performance category, and for eligible hospitals and CAHs under the Medicare Promoting Interoperability Program. The measure would be required for reporting beginning in CY 2026.

With regard to MIPS eligible clinicians, eligible hospitals, and CAHs, a discussion of the burden placed on these entities were presented in section IV.C.8, Table 18. That table shows that the burden per individual provider is under $2.50 per year (one half-minute of labor times an hourly wage of under $50, depending on whether one uses a mean or median). Consequently, the Secretary asserts that the provisions of this proposed rule do not represent a significant burden on providers.

Based on the information provided previously, we conclude that the requirements of the RFA have been met by this proposed rule.

D. UMRA and E.O. 13132 Requirements

Section 202 of the Unfunded Mandates Reform Act of 1995 (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 2022, that threshold is approximately $165 million. This proposed rule would not impose an unfunded mandate that would result in the expenditure by state, local, and tribal governments, in the aggregate, or by the private sector, of more than $165 million in any 1 year.

Executive Order 13132 establishes certain requirements that an agency must meet when it promulgates a proposed rule (and subsequent 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 API provisions would be a requirement for state Medicaid and CHIP agencies under these proposals, the cost per beneficiary for implementation is expected to be negligible when compared with the overall cost per beneficiary. This analysis does not consider Federal matching funds provided to state Medicaid and CHIP agencies, but the conclusion is the same: there is not expected to be a significant cost impact on state entities. For Medicaid and CHIP, we do not believe that the proposals in this rule would conflict with state law, and therefore, do not anticipate any preemption of state law. As discussed in section II.D. of this proposed rule, some state laws regarding timeframes for prior authorization decisions may be different than the proposals in this proposed rule. However, an impacted payer would be able to comply with both state and Federal requirements by complying with whichever imposes the shorter timeframe. We invite states to comment on this proposed rule if they believe any proposal in this rule would conflict with state law.

E. Regulatory Review Costs

If regulations impose administrative costs on private entities, such as the time needed to read and interpret this proposed rule, we should estimate the cost associated with regulatory review. We model our estimates of this burden based on similar estimates presented in the CMS Interoperability and Patient Access final rule (85 FR 25510). There are three numbers needed to calculate this estimate:

1. Number of Staff per Entity Performing the Reading

The staff involved in such a review would vary from one parent organization to another. We believe that a good approximation for a range of staff would be a person such as a medical and health service manager or a lawyer. Using the wage information from the BLS for medical and health services managers (Code 11-9111) and lawyers (Code 23-1011) we estimate that the cost of reviewing this proposed rule is $128.71 per hour, including overhead and fringe benefits. This number was obtained by taking the average wage of a medical manager and lawyer.

2. Number of Hours of Reading

In the CMS Interoperability and Patient Access final rule, we estimated 6 hours of reading time. Therefore, we believe 10 hours would be enough time for each parent organization to review relevant portions of this proposed rule.

3. Number of Entities Reviewing the Proposed Rule

We believe the review would be done by both parent organizations that would be required to implement the proposed API provisions, and by the physician and provider specialty societies. For parent organizations, we have used an assumption of 365 parent organizations throughout this proposed rule. For physician practices, individual physician practices rely on their specialty societies to read content such as proposed rules for them. The Relative Value Scale Update Committee (RUC) has 32 members representing all specialties. This would result in 398 entities (365 Parent organizations plus 32 members of the RUC) in our estimates. We also add 100 entities (for a total of 500 entities) to account for the 66 pharmacy benefit managers and the several dozen major advocacy groups.

Thus, we estimate a one-time aggregated total review cost of $1.3 million ($128.71 times 10 hours of reading time times 500 entities times two staff per entity). We request comment on our estimate.

F. Impact of Individual Proposals

The proposed provisions of this rule all have information collection-related burden. Consequently, the impact analysis may be found in Table 19 of the Collection of Information in section IV. of this proposed rule. To facilitate a review of the provisions and estimates made in the Collection of Information, we have included Table 21, which provides the related ICRs by number and title, as well as the table numbers for which impact is presented.

Additionally, this Regulatory Impact Analysis section provides an analysis of potential savings arising from the replacement of paper approaches to prior authorization and other plan requirements with an electronic method. Although these savings are neither included in monetized tables nor in summary tables, as further discussed later in this proposed rule, we believe that these large savings are an important consideration in evaluating this proposed rule. We have identified assumptions for these analyses, and we request public comment.

Table 27 of this section, using Table 19 as a basis, provides a 10-year impact estimate. Table 27 includes impact by year, by type (parent organizations, including Medicaid and CHIP state agencies), as well as the cost burden to the Federal Government, allocations of cost by program, and payments by the Federal Government to Medicare Advantage, Medicaid, and CHIP, as well as the premium tax credits (PTC) paid to certain enrollees in the individual market.

G. Alternatives Considered

In this proposed rule, we continue to build on the efforts initiated with the CMS Interoperability and Patient Access final rule and the work we have done to advance interoperability, improve care coordination, and empower patients with access to their healthcare data. This proposed rule covers a range of policies aimed at achieving these goals. We carefully considered alternatives to the policies we are proposing in this rule, some of which were included in the December 2020 CMS Interoperability proposed rule, and on which we received public comments. Those public comments and other engagements over the year support our conclusions that none of the alternatives would adequately or immediately begin to address the critical issues related to patient access and interoperability or help to address the processes that contribute to payer, provider, and patient burden.

We now discuss the alternatives we considered to our proposed provisions and the reasons we did not select them as proposed policies.

1. Alternatives Considered for the Proposed Patient Access API Enhancements

We are proposing to require that payers make enhancements to the Patient Access API finalized in the CMS Interoperability and Patient Access final rule including proposing additional information be made available to patients through the Patient Access API, and proposing certain metrics about patient use of the Patient Access API be reported directly to CMS annually. Before proposing to require these provisions, we considered several policy alternatives.

As we discussed in the CMS Interoperability and Patient Access final rule (85 FR 25627), one alternative to the proposed updates to the Patient Access API we considered is allowing payers and providers to upload patient data directly to a patient portal, operated by a provider. However, despite the availability of patient portals, ONC reported in 2020 that only 60 percent of individuals have been offered online access to their medical records by either their healthcare provider or payer. And of the individuals that were offered access, approximately 40 percent of those viewed their record. Further, patient portals may not achieve the same interoperability goals that health apps could in order to support a patient's individual preference to manage their specific health condition or view their complete health record using supplemental data from different sources. A patient portal can only provide the data available from the organization offering the portal, and most portals are not connected to mobile applications to monitor physical activity, medication compliance, or health metrics. Portals may not be connected to the many external health apps for other services such as fitness training, meal planning for special diets, challenges, or other features available in the marketplace. Finally, providers and payers are not yet coordinating on the exchange of administrative and clinical data that we are proposing be shared in this proposed rule. For those reasons we do not believe that patient portals can fully meet patients' needs and would not be a suitable policy option to propose. We also believe that there could be additional burden associated with using portals because patients might need to use multiple portals and websites to access all of their information. Using multiple portals would require an individual to sign into each portal in order to review all of their relevant data—one for each provider or plan with which the patient is associated. A single health app may be able to compile health information about the patient from multiple sources, based on a patient's request. The patient could possibly access this information with one login, and could find the same information, as might be available from the multiple portals.

A portal is operated by a provider or payer as an entry point to a finite set of data available from an individual organization. These portals do not lend themselves as well to interoperability because they do not enable other organizations, or the patient, to provide additional data to the system. Because business models and processes pertaining to patient portals are varied across the industry, and any one patient could be associated with a number of different portals, there is no available data today with which we can evaluate the cost impacts of requiring individual portals versus the estimates for enhancing the Patient Access API.

As explained in the CMS Interoperability and Patient Access final rule (85 FR 25627), another alternative considered was to allow Health Information Exchanges (HIEs) and Health Information Networks (HINs) to serve as a central source for patients to obtain aggregated data from across their providers and payers in a single location. HIEs and HINs could provide patients with information via an HIE portal that is managed by the patient.

However, as previously described, there are reasons why patient portal access does not lend itself to interoperability or innovation, and all patients might not have access to an HIE or HIN. For the reasons described, we ultimately decided to proceed with our proposed requirements versus these alternatives.

In the December 2020 CMS Interoperability proposed rule (85 FR 82592), we proposed to require impacted payers to request a privacy policy attestation from health app developers when their health app requests to connect to the payer's Patient Access API. We proposed that the attestation would include, at a minimum, that the health app has a plain language privacy policy that is always publicly available and accessible and has been affirmatively shared with the patient prior to the patient authorizing the app to access their health information. In addition, the attestation we proposed included yes/no elements as to whether the privacy policy specifically communicates how the patient's health information could be accessed, exchanged, or used.

We considered proposing that policy again, but based on substantial public comment, we believe that this type of attestation would not benefit patients in ways that would outweigh the burden on impacted payers and that such a policy could have unintended consequences for patients. Under that proposal, a health app developer would only be attesting to the format and inclusion of certain information. There would be no attestation that the substance of the privacy policy meets specific minimum requirements or best practices. We believe that having payers inform patients that an app developer has attested to the form and format of a privacy policy could easily be misinterpreted as assurance that the substance of the privacy policy has been reviewed and found acceptable by the payer (or CMS). We are concerned that requiring such an attestation would only give the appearance of privacy and security for patients' health data, without providing additional privacy or security. Though we did not pursue this option, we continue to work with the Office for Civil Rights and the Federal Trade Commission to determine what additional types of guidance might be warranted to support consumer education with respect to privacy policies when using health apps, as well as guidance for payers when evaluating the apps available to their beneficiaries and enrollees.

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 indicated a preference for less frequent reporting, which would in turn create less burden on payers. Annual statistics on such utilization should be sufficient to accomplish our goals.

We also considered alternative effective dates for the proposed policies. For example, we considered January 1, 2024, and 2025 as possible compliance dates for the Patient Access API enhancements. However, based on the public feedback we received from the December 2020 CMS Interoperability proposed rule, we believe it is more appropriate, and less burdensome on impacted payers to propose an effective date for these policies beginning on 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), which provides for a two year implementation time frame.

2. Alternatives Considered for the Proposed Provider Access API

In this proposed rule, to better facilitate the coordination of care across the care continuum, we are proposing to require impacted payers to implement and maintain a Provider Access API. This proposed API would require payers to make available to certain providers the same types of data they would make available to patients via the enhanced Patient Access API.

Alternatively, we considered other data types that could be exchanged via the Provider Access API. We considered only requiring the exchange of all data classes and data elements included in a content standard at 45 CFR 170.213. While this would be less data to exchange and, thus, potentially less burdensome for impacted payers to implement, we believe that claims and encounter information can complement the content standard and offer a broader and more holistic understanding of a patient's interactions with the healthcare system. Furthermore, the data that we propose to be made available through the proposed Provider Access API aligns with the data that we propose to be made available to individual patients through the Patient Access API. Once the data are mapped and prepared to share via one FHIR API, these data should be available for all payer APIs to use within that organization.

We also considered having only payer claims and encounter data available to providers, understanding that providers are generally the source of clinical data. This could limit the burden on payers by requiring less data to be made available. However, even if a provider is the source for the clinical data relevant to their patient's care, a provider may not have access to clinical data from other providers a patient is seeing. As a result, and understanding payers were already preparing these data for use in other APIs, we decided a more comprehensive approach would be most beneficial to both providers and patients and aligned the proposed Provider Access API data requirements with those proposed for the Patient Access API.

We also considered including additional data elements in this proposal as well as requiring the complete set of data available from the payer's system. We had not received recommendations for such an extensive body of data and acknowledge that such a large volume of data types would require too many additional resources, and would likely not be consistent with minimum necessary provisions (unless its receipt was required by law in concert with how the data was being requested) and be overly burdensome for impacted payers at this time. As described earlier in this proposed rule, the USCDI is a standardized set of data classes and data elements adopted for nationwide, interoperable health information exchange. Because this limited set of data has been standardized, and corresponding FHIR IGs have been developed, payers can map these data and make them more easily available via an API. The HL7 workgroups in which payers and providers participate continue to work on the IGs to ensure necessary enhancements to facilitate sharing of a patient's complete record. We acknowledge that work will be ongoing for the IGs, and important questions about data segmentation, and a patient's role in potentially specifying what parts of their medical record could or should be available to which providers, need to be considered.

3. Alternatives Considered for the Proposed Payer-to-Payer API

We are proposing 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 proposal would make the same data that is being made available to patients and providers also available to other payers when an enrollee changes plans, and in that way allow patients to take their data with them as they move from one payer to another. Before proposing these policies, we considered several policy alternatives.

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. Rather, CMS 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. In this proposed rule, we had the option to maintain the previous policy and forgo the API requirement. However, since the CMS Interoperability and Patient Access final rule was finalized in May of 2020, many impacted payers indicated to CMS that the lack of technical specifications for the payer to payer data exchange requirement was creating challenges for implementation, which could have created differences in implementation across the industry, poor data quality, operational challenges, and increased administrative burden. Differences in implementation approaches could have created gaps in patient health information that would have conflicted directly with the intended goal of interoperable payer to payer data exchange.

Furthermore, for the Payer-to-Payer API, once an organization implements the other proposed APIs, there would be less additional investment necessary to implement the Payer-to-Payer API as payers would be able to leverage the infrastructure already established for the Patient Access API and Provider Access API. The HL7 Da Vinci Payer Data Exchange work group has expanded their work over the past year to include two paths to exchange claims and associated clinical data. The updated background section for the recommended implementation guide provides an explanation of how the existing resources can be tailored to meet the provisions of our proposals. Given this available infrastructure and the efficiencies of sharing standardized data via the API, we determined it was most advantageous for payers to leverage an API for this enhanced data exchange.

We also considered which data elements would be the most appropriate to require for the exchange between payers. Similar to the Provider Access API alternatives, we considered only requiring the exchange of data classes and data elements included in a content standard at 45 CFR 170.213. As we previously described, we believe that claims and encounter information can complement the content standard and potentially allow for better care coordination, as well as more efficient payer operations. We do not believe there to be significant additional burden once the data are mapped for the other proposed APIs.

4. Alternatives Considered for the Proposed PARDD API and Other Prior Authorization Proposals

We are also proposing several policies associated with the prior authorization process. First, we are proposing to require that all impacted payers implement and maintain a Prior Authorization Requirements, Documentation, and Decision (PARDD) API. We believe this API would ultimately help patients receive the items and services they need in a timely fashion. The PARDD API aims to improve care coordination by enabling enhanced communication about when a prior authorization is required, information that is required to approve a prior authorization, and facilitating electronic prior authorization. This would add efficiencies for both payers and providers, and it could improve patient care by avoiding gaps and delays in care. This API would be accessible to providers to integrate directly into their workflow while maintaining compliance with the mandatory HIPAA transaction standards.

As proposed, by January 1, 2026, impacted payers would be required to implement and maintain a FHIR PARDD API, populate the API with their list of covered items and services (excluding drugs) for which prior authorization is required, and any documentation requirements for the prior authorization. (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.) We considered proposing a phased approach for the PARDD API where payers would first make the functionality available for a specified subset of their prior authorization rules and requirements, as opposed to all of the rules and requirements for all applicable items and services at one time. We also considered requiring that payers only prepare the PARDD API for a specific set of services most commonly requiring prior authorization across payers. However, we believe this would be more burdensome in some ways. It would require providers to use different systems to find requirements for different services for each payer. If the requirements for different services were in different places, such as some information in payer portals and some through the PARDD API, providers would have to spend additional time searching for the information in multiple locations for one payer. Therefore, we believe it is ultimately less burdensome overall to require impacted payers to populate the prior authorization and documentation requirements for all covered items and services (excluding drugs) at the same time. There are several pilots underway to test the PARDD API, as well as other tools. The results are all positive for the policies that are being tested and showcased in demonstrations at conferences. However, no quantitative data have yet been shared with CMS to include with this proposed rule, but it is anticipated in the near future.

We also considered a phased timeline approach to implement these functionalities. For example, we considered first requiring implementation of the requirements and documentation functionality in 2026 and then a year later requiring implementation of the submission and decision functionality of the API. We also considered whether to propose these two capabilities as separate APIs. However, considering the enforcement discretion we exercised for the APIs finalized in the CMS Interoperability and Patient Access final rule, we believe it is more appropriate to propose compliance dates for this policy in 2026, providing payers with more time to potentially implement both functionalities at the same time.

We also considered whether we should propose to require that payers post, on a public-facing website, their list of items and services for which prior authorization is required and populate the website with their associated documentation rules as an interim step while they implement the PARDD API. However, we are aware that some payers already have this information publicly available, and we determined that this would not provide any reduced burden on payers or providers at this time. There is burden associated with updating the information on a website as the list of prior authorization items is likely to change frequently, due to the availability of new therapies. We seek comment on whether a payer website to provide additional transparency to prior authorization requirements and documentation would be beneficial in reducing the overall burden in this process.

Another alternative we considered to support prior authorization was to only use the X12 standard transaction adopted under HIPAA rather than require the implementation of a FHIR API. The X12 standard defines the content and format for the exchange of data for specific business purposes and is designed for administrative transactions between administrative systems. For prior authorization, the adopted standard is the X12 278 version 5010. The X12 standard for prior authorization does not have the functionality of the HL7 IGs to support the proposed PARDD API to make available the response from the payer in the provider's health IT system. Furthermore, the CRD, DTR, and PAS IGs combined, provide the necessary information for the provider to know the coverage and documentation requirements to submit a compliant prior authorization request for each payer. X12 is not designed to enable the use of SMART on FHIR apps connected to the provider's EHR system, nor is it designed for the scope envisioned in this proposed rule, including extraction of payer rules, a compilation of data into electronic-based questionnaires, or communication with EHRs. The adoption rate of the mandated X12 278 Version 5010 standard is low, according to data compiled annually by CAQH (described earlier in this proposed rule). By 2020, the use of the X12 278 standard for prior authorization transactions had reached 21 percent despite having been available since 2012. Background on the industry's failure to use the X12 standards is explained in more detail in section II.D.

We are proposing other provisions, including requiring certain impacted payers to ensure that prior authorization decisions are made within 72 hours of receiving an expedited request and no later than 7 days after receiving a standard request, and proposing to require impacted payers to publicly report prior authorization metrics on their websites or via a publicly accessible hyperlink(s) annually.

We considered several alternative timeframe policies before deciding to propose these policies. We considered alternative timeframes under which payers could provide a decision in less than 72 hours (for expedited decisions) and 7 days (for standard decisions). For example, we considered requiring payers to provide a decision in 48 hours for expedited requests and 3 days for standard requests. We are seeking comment on this proposal but decided not to make it an alternative proposal due to concerns over the feasibility of implementing such timeframes. We will reevaluate these timeframes at a future date once the PARDD API is in place, as we believe the PARDD, as well as the other efficiencies introduced in this proposed rule, would make shorter timeframes more feasible. Understanding the importance of providers and patients getting decisions as quickly as possible, we believe that the timeframes we propose in this rule are a significant step to help increase reliability in the prior authorization process and establish clear expectations without being overly burdensome for payers.

These timeframes allow payers to process the prior authorization decisions in a timely fashion and give providers and patients an expectation for when they can anticipate a decision and know when they can receive care. We also considered whether more than 7 days would be necessary for complex cases, for example, adding an additional decision timeframe category to include complex cases. However, we did not propose this alternative because we believe it is important for patients and providers to be able to receive a decision in a shorter timeframe. We believe 7 days is sufficient time for a payer to process prior authorization decisions.

Regarding publicly reporting prior authorization metrics, we considered requiring impacted payers to publicly report these metrics more frequently than annually, such as on a quarterly basis. However, because most patients typically shop for health insurance coverage on an annual basis, we believe updating this information annually be sufficient for making decisions. We also considered whether to allow payers to report on a selected subset of metrics, rather than taking an “all or nothing” approach. After further consideration, we believe all metrics proposed would be valuable for payers to report publicly.

We also considered reporting these metrics at the parent organization versus at the organization, plan, or issuer level for all impacted payers. After further consideration, we decided this may not be truly operational and may be too aggregated a level of reporting for some payer types to provide useful information for patients and providers. As a result, we are proposing reporting at the organization level for MA, state-level for Medicaid and CHIP FFS programs, plan-level for Medicaid and CHIP managed care, and at the issuer-level for QHP issuers on the FFEs.

G. Analysis of the Potential Impact for Savings Through Adoption of the Prior Authorization Provisions by Healthcare Providers

As described in section II.D., we are proposing new requirements related to prior authorization for impacted payers, and in section II.E. we described our proposal for measure reporting for MIPS eligible clinicians, eligible hospitals, and CAHs.

In section IV., we discussed the ICRs regarding cost estimates for reporting and the potential burden specifically for the MIPS eligible clinicians, eligible hospitals, and CAHs. In this impact analysis, we discuss the anticipated cost savings of these proposals for the broader healthcare provider population, which is inclusive of, but not limited to the MIPS eligible clinicians, hospitals, and CAHs. We believe that all healthcare providers could benefit from the proposal for impacted payers to implement the API proposals in this proposed rule and base these cost-savings estimates on that total number, with estimates described in this section of this rule, of the proportion of providers that we expect to benefit over the next 10 years. To conduct this analysis, we used available resources to create the estimates and invite comments on our assumptions, the recency of our data, and our citations.

The savings we calculate in this section V.G. of this proposed rule would be true savings, not transfers since they reflect savings in reducing the administrative costs required to process prior authorizations. However, these savings would be an indirect consequence of the proposed rule, not direct savings. This proposed 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, nor in the summary table of this proposed rule, nor in the 2016 dollar calculation. Nevertheless, the savings could be significant, and we believe should be a factor in the evaluation of this proposed rule. We request comment on this decision not to include the savings in the final summary Table 27 and related tables. Recognizing the potential policy interactions this proposed rule has with other future CMS and HHS rules, as well as Congressional actions, we request comment on how CMS might attribute savings benefits to avoid double-counting. What are the implications if the same effects were attributed to multiple regulations? For example, we note that the Medicare Advantage program is impacted by several CMS regulations, which may overlap with one another. How could CMS account for both costs and benefits from such policy intersections?

We note that we are only quantifying savings of reduced paperwork for healthcare providers. However, the improved efficiencies proposed in this rule have several consequences, which could lead to savings. A 2021 survey by the American Medical Association (AMA) lists several 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. The provisions of this proposed rule, if finalized, could be an important step in reducing these adverse health events.

The approach adopted in quantifying savings is to quantify those that we can reliably estimate and note that they are minimal savings. The proposals 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. We start the estimate with individual physicians and physician groups because we have reliable data (two multi-thousand surveys from 2006 and 2021 cited in this section of this proposed rule, which agree with each other) on (1) the number of hours per week spent on prior authorization, and (2) the proportion of hours per week spent by physicians, nurses, and clerical staff.

To then estimate reductions in spending on paperwork for prior authorization for hospitals, we assume that hospitals perform their prior authorization activities similar to individual physicians and physician groups. We make this assumption because we do not have a basis for making a more accurate assumption; that is, we do not have similar survey data 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 the 2023 Hospital Inpatient Prospective Payment Systems for Acute Care Hospitals and the Long-Term Care Hospital Prospective Payment System (FY 2023 IPPS/LTCH PPS) final rule (87 FR 48780) and the CY 2023 Hospital Outpatient Prospective Payment and Ambulatory Surgical Center Payment Systems (CY 2023 OPPS/ASC) final rule (87 FR 71748, November 23, 2022) for estimates of the number of possible organizations that could be impacted. We provide more information in this section of this proposed rule, about the estimate of the number of hospitals, 7,978, and the number of individual physicians and physician groups, 199,543.

If we assume hospitals are conducting the prior authorization process in a manner similar to physicians, then in effect we have increased the number of individual physicians and physician groups from 199,543 to 207,521 entities (199,543 individual physicians and physician groups plus 7,978 hospitals). We compute aggregate savings by first estimating the savings for a single individual physician or group physician practice and then multiplying this single savings by the number of practices. Therefore, it follows that if 199,543 individual physician and group physician practices would save money, as shown in Table 24 of this proposed rule, then 207,521 combined physician practices and hospitals would save $15.3 billion (207,521/199,543 × $14.70). When we round the updated savings to the nearest billion there is no numerical change in the savings since both $15.3 and $14.7 round to $15 billion. We believe this approach to be the clearest.

In calculating the potential savings, uncertainties arise in four areas, and the result of this illustrative analysis is that we find a minimal potential savings impact of between $10 to $20 billion over the first 10 years of implementation. 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 explain each of the four uncertainties, indicate how we approached estimation, and request public comment.

1. Assumptions on the Relative Proportion of Current Workload Hours by Staff for Prior Authorization

To estimate the savings impact, we researched estimates of the current amount of paperwork involved in prior authorization, the type and number of staff involved, the type of physician offices involved, and hours per week staff spent engaged in prior authorization processes. Our assumptions on the relative proportion of current workload hours by type of staff are based on a survey presented by Casalino et al. (2009), which gave a detailed analysis based on a validated survey instrument employed in 2006.

The Casalino et al. study is dated; therefore, several numbers in the article were updated, including hourly wages, the number of physician practices, and the hours per week spent on prior authorization. We only use this article for the relative proportions of workload by staff type. We have not found any other studies that address this data point for physician offices and similarly no studies that address this same information for hospitals. Staff type is important because, for example, the hourly wage for clerical staff is about one-half the hourly wage for nurses and about one-fifth the hourly wage for physicians; clearly then, the staff doing the paperwork can significantly affect savings.

Such a design allows us to update wages using the Bureau of Labor Statistics' (BLS) latest wages. It also allows the allocation of costs based on the staff member used in the analysis. We used the relative proportion of time spent by physicians, nurses, and clerical staff presented in this paper in our estimates since they seemed reasonable and were not discussed in any other survey reviewed. Thus, though the article by Casalino et al., is dated, it was useful for proportions of time spent on paperwork for prior authorization for the following reasons:

• Unlike many subsequent studies, the survey instrument was validated by several organizations.
• Unlike many subsequent studies, the number of physician practices surveyed was in the thousands.

• Finally, we note that several other estimates in the literature were reviewed, which, although reflecting more recent research, either did not show the basis for their calculations, showed a basis based on a very small number of people, or used a non-validated survey.

The Casalino et al. survey excluded certain physician practices, including health maintenance organizations (HMOs), but analyzed workload by staff type (doctor, nurse, clerical, administrator, lawyer, and accountant), office type (solo, 3 to 10 physicians, 10 or more physicians), and the type of medical work involved (prior authorization, formulary, claims billing, quality, etc.). Consistent with our approach, we restricted ourselves to prior authorization activities, though formulary work could possibly add to burden related to prior authorization activities.

Table 22 presents an estimate of the current average annual paperwork burden per physician office for prior authorization activities. Table 22 estimates an average annual burden per individual physician or physician group practice of 676 hours at a cost of $48,882. In reaching this estimate, we note all of the following:

• The relative hours per week for physicians, registered nurses, and clerical staff were, as previously discussed, kept the same as in the Casalino et al. article.
• The labor costs were updated to 2021, using the Bureau of Labor Statistics (BLS) mean hourly wages.

• The 20.4 hours per week estimated for prior authorization in the Casalino et al. article was reduced to 13 hours per week based on the AMA survey conducted in 2021.

• As previously discussed, we initially estimated reduced paperwork burden for individual physician and group physician practices and updated these numbers at the end of our entire analysis to include hospitals for which we do not have definitive surveys.

2. Assumptions on the Total Number of Individual and Group Physician Practices

Table 22 presents the current hour and dollar burden per physician group and individual physician office. To obtain the aggregate annual burden of prior authorizations for all physician practices, including those exclusively furnishing services to Fee for Service (FFS) enrollees, Casalino et al. (2009) multiplies the Table 22 burdens per physician group and individual physician office by the total number of individual and group physician practices. Thus, we need an estimate of the total number of individual and group physician practices.

We assume there are a total of 199,543 individual and group physician practices (of which the MIPS eligible clinician practices affected by this proposed rule are a subset). The 199,543 number was arrived at by dividing the estimated 1,596,340 individual physicians derived from Table 144 in the CY 2023 Payment Policies Under the Physician Fee Schedule (PFS) final rule (87 FR 69404, 70171) by an estimated median number of 8 physicians per practice from the Muhlestein et al. (2016) article.

3. Assumptions on the Reduction in Hours Spent on Prior Authorization as a Result of the Provisions of This Proposed Rule

Table 22 provides current hours spent on prior authorizations. To calculate potential savings, we must make an assumption on how much these hours could be reduced as a result of the provisions of this proposed rule.

Section II.D. of this proposed rule would require impacted payers to implement a PARDD API. As we described in that section, this API, if voluntarily used by an individual physician or within a physician group, could allow members of individual physician and physician group practices to discover whether a requested item or service requires prior authorization and, if so, the relevant documentation requirements. All provider office staff types, including physicians, nurses, and clerical staff, could experience reductions in the time needed to locate prior authorization rules and documentation requirements, which are currently either not readily accessible or available in many different payer-specific locations and formats. We believe that our proposal would make it possible for staff to use one system (such as their EHR or practice management system) or software application to find the prior authorization rules and documentation requirements for most impacted payers. With these rules and requirements more consistently and easily accessible, we anticipate a reduction in the need for providers to make multiple attempts at submitting complete information necessary for the payer to approve or deny a prior authorization. Consequently, a PARDD API could also reduce appeals and improper payments, but we are not addressing such savings here, as we have no real-world basis on which to make an estimate. (We also note that reduction in improper payments, though experienced as savings by certain entities, would be categorized as transfers from a society-wide perspective.)

In addition to being able to look up whether a requested item or service requires prior authorization and, if so, the relevant documentation requirements, the PARDD API can compile the necessary data elements to populate the HIPAA-compliant prior authorization transaction along with the documentation needed and receive an approval or denial decision from the payer, including any ongoing communications regarding additional information needed or other status updates. Currently, many prior authorization requests and decisions are conducted through one of several burdensome channels, including telephone, fax, or payer-specific web portals, each of which requires taking action and monitoring status across multiple and varying communication channels.

Based on this discussion we assume the following reductions. Physicians who currently (on average over all physician groups) spend 0.6 hours per week on prior authorization (Table 22) are assumed to reduce their time by 10 percent. Nurses who currently spend one day (8.3 hours) per week on prior authorization are assumed to reduce their time to half a day, a reduction of 50 percent. Clerical staff who currently spend 4 hours a week on prior authorization are assumed to reduce their time by 1 hour, a 25 percent reduction. We discuss alternate assumptions in this section of this proposed rule, after presenting the total 10-year savings. We also specifically solicit comments from stakeholders on the reasonableness of these assumptions.

Table 23 presents the total savings in paperwork for prior authorization for a single individual or group physician practice adopting the proposals of this rule. The columns of this table are explained as follows. Column (1), the total hours per year per staff type spent on prior authorization is obtained from Table 22. Column (2) presents our assumptions, as previously discussed, on reduced time by staff type. Column (3) is the product of columns (1) and (2). Column (4) is taken from Table 22. Column (5), the total reduced dollar spending per year is obtained by multiplying columns (3) and (4). The total row indicates aggregate hours and dollars saved over all staff type.

4. Assumptions on the Number of Individual and Group Physician Practices Voluntarily Adopting the Proposals of This Rule

We are not assuming that over 10 years all 199,543 individual and group physician practices would adopt the proposals of this rule. Instead we assume as follows:

• That the 54,770 MIPS eligible clinicians (individual and group) a subset of the 199,543 estimated individual and group physician practices would adopt the proposals of this rule in 2026 (the 1st year of implementation) since there are payment consequences for them not doing so.
• By 2034, 50 percent of all individual and physician practices would adopt the proposals of this rule.

We do not assume a constant increase per year but rather a gradual increase per year. We begin our assumptions with the 54,770 MIPS eligible clinicians in 2026 and end with the 99,772 (50 percent of 199,543) individual and physician group practices in 2034, expecting an exponential growth, which is characterized by a slow beginning and more rapid growth later on.

Applying these assumptions results in a $14.7 billion savings over 10 years, which are shown in Table 24. If we include hospitals by increasing the amount by 4 percent, the estimate would be $15.2 billion. The estimate rounded to the nearest billion is $15 billion.

The 4 percent increase to account for hospitals is arrived at as follows. Based on the FY 2023 IPPS/LTCH final rule (87 FR 48780) and the CY 2023 OPPS/ASC final rule (87 FR 71748) there are 3,142 Inpatient and Acute Care hospitals; 1,425 CAH hospitals; and 3,411 outpatient hospitals, or a total of 7,978 hospitals. We estimate that the hospitals represent 4 percent of the health care industry (7,978 hospitals/199,543 individual and group physician practices) of all individual and group physician practices, which we acknowledge is a rough estimate, only using a calculation of numbers. However, without additional impact studies, we propose using this as our estimate for savings opportunities.

The columns headers of Table 24 show the logic and sources of the column entries are described here:

• Column (1) gives the year, with the first year of implementation being 2026.
• Column (2) gives the total reduced hours for any individual or group physician practice adopting the proposals of this rule (Table 23).
• Column (3) gives the total reduced dollar spending for any individual or group physician practice adopting the proposals of this rule (Table 23).

• Column (4) gives the assumed percentage of individual or group physician practices adopting the proposals of this rule in any one year. In 2026 we expect 54,770/199,543 or about 27 percent of all individual and physician groups to adopt the proposals. This number gradually increases until reaching 50 percent in 2035.

• Column (5) gives the total number of individual and physician practices.
• Column (6) gives the total hours saved (millions of hours) by multiplying the hours saved per practice times the number of practices times the percentage of practices adopting the proposals of this rule.
• Column (7) gives the total dollars saved (billions) by multiplying the dollars saved per practice times the number of practices times the percentage of practices adopting the proposals of this rule.
• The sum of savings over the 10 years is indicated in the next to last row: There is a savings of 205 million hours of work on prior authorization resulting in $14.7 billion reduced cost over 10 years.
• The last row multiplies this amount by 207,521/199,543, as explained in the introductory paragraphs of this section V.G, to account for hospitals (Inpatient, Outpatient, and CAHs) assuming hospitals are subject to the same assumptions we made for individual physician groups.
• As can be seen, to the nearest billion, $15 billion is saved to physicians and hospitals over 10 years from adopting the proposals of this proposed rule.

If we assume additional savings, 10 percent, 50 percent, and 50 percent savings for physicians, nurses, and clerical staff respectively the savings over 10 years would be $17 billion (including savings to hospitals). If we assume less savings, 10 percent, 33 percent, and 33 percent savings for physicians, nurses, and clerical staff respectively the savings over 10 years would be $11 billion. Using a wide array of different assumptions, we expect an aggregate reduction of cost over 10 years of between $10 billion and $20 billion.

H. Summary of Costs

In this section, we present a 10-year summary table of costs, an analysis for Federal impacts, and the monetized table.

To analyze the cost of this proposed 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 Medicaid and CHIP state 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 25 presents the 2020 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 33 to 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. In a similar manner, we can calculate the Federal Medicaid payments using the percentages in Table 26.

Table 25 is based on the most recent projections of the CMS Office of the Actuary (OACT) for the Mid-Session Review of the President's FY 2022 Budget (MSR 2022).

We illustrate in the 2025 column that 41 percent (1−0.59 shown in the second row) of Federal Government payments go to the states for expenditures related to their Medicaid FFS programs and 59 percent (the number shown in the second row) goes to states for their Medicaid managed care programs. For state expenditures on Medicaid mechanized claims processing and information retrieval systems, the Federal Government pays states 90 percent of their expenditures on the design, development, installation, or enhancement of such systems, and 75 percent of their expenditures on the ongoing operation of such systems. For 2025, states receive an average of 65.9 percent FMAP for their managed care program costs as shown on the third row. Therefore, the percentage of costs paid in the first year by the Federal Government is 69.6 percent (75 percent × 41 percent + 65.9 percent × 59 percent) as shown in the fourth row. The calculation of the percent of costs paid in all years is done similarly except that in the first-year 90 percent is used for weighting instead of 75 percent. By applying these percentages to the total Medicaid costs, we obtain Federal costs for the program. These percentages are used to calculate the total dollars going from the Federal Government to states.

It should be noted that although the first year of implementation of this proposed rule is 2026, we expect plans to begin constructing software systems as soon as the rule is finalized in 2023.

Based on the previous discussion in this proposed rule, the next section shows the calculation of all impacts of this proposed rule by program, Government, and QHP issuers. The numerical impacts are presented in Table 27.

For Table 27:

• As explained in the connection with Table 19 in the Collection of Information section, the data in Table 27 is based on an expected publication date of the final rule is mid-year of 2023 and an effective date of January 1, 2026 for most provisions.

• The bottom-line totals in the columns of Table 19 labeled “1st year cost” through “5th Year Cost” are the totals found in the “Total Cost” column of Table 26 in rows 2023 through 2027 respectively. The totals in the column “Subsequent year costs” in Table 19 are found in the rows labeled 2028 through 2032 in the “Total Cost” column of Table 27.
• The Total Cost to Providers and Hospitals and CAHs column reflects the aggregate cost of producing reports for MIPS eligible individual providers, provider groups, hospitals, and CAHs, as found in Table 19 for years 2026 and further.
• The total 10-year cost (excluding PTC payments and savings from prior authorization) is, as shown in Table 27, $1.6 billion. This number uses the primary estimates for the API provisions. The low and high 10-year total costs are $0.8 billion and $2.3 billion, respectively.
• Cost of Proposed Rule to Payers by Program columns: We applied the percentages from Table 25 to obtain the cost of the rule to payers by program (MA, Medicaid, CHIP, and QHP issuers on the FFEs).
• Cost of Proposed Rule to Government by Program columns: We applied the percentages of payment by the Federal Government discussed in the narrative on Table 26 to obtain the cost by program.
• PTC Payments: The Government does not reimburse QHPs, either partially or totally, nor prospectively or retrospectively, for their expenses in furnishing health benefits. However, the Government does offer QHP enrollees PTC credits 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 regulatory impact analysis), increasing premiums to enrollees, or reducing non-essential health benefits. To the extent that issuers increase premiums for individual market-qualified health plans on the FFEs, there would be Federal PTC impacts. The purpose of the PTC is to assist enrollees in paying premiums. Since PTCs are only available if an individual purchases a qualified health plan on an Exchange and the individual has an income between 100 and 400 percent of the Federal Poverty Level, the PTC estimates apply only to Exchange plans. 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.

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 PTC payments are currently slightly over 50 percent of total costs.

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 Medicare Advantage and Medicaid, CHIP, and QHP enrollees.

• Remaining Cost to Payers columns: For MA organizations, and 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.

Note: The dollar savings from reduced paperwork burden for an increase in use of electronic prior authorization (Tables 22 through Table 24) is not included in Table 27.

We next explain 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 Table 28 we explain possible ways payers may manage these extra implementation costs. We emphasize that Table 28 lists possibilities. Payers would ultimately make decisions about how to defray these remaining costs based on market dynamics and internal business decisions, and 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 either in the form of higher premiums or reduced benefits that are non-essential health benefits (EHBs). CMS has seen in some cases that plans, for reasons of market competitiveness, will absorb costs rather than increase premiums or reduce benefits. The temporary claim refers to the possibility that plans will 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.

Medicaid and CHIP: Assuming roughly 71 million enrollees nationally (inclusive of 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 the June prior to the beginning of the coverage year), Medicare Advantage plans would address the reduced rebates (arising from increased bid costs due to the increased costs of this proposed 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.

I. Accounting Statement and Table

As required by OMB Circular A-4 (available at https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/circulars/A4/a-4.pdf ), we have prepared an accounting statement in Table 29 showing the classification of annualized costs associated with the provisions of this proposed rule for the 10-year period 2023 through 2032. This accounting table is based on Table 27 and includes the costs of this proposed rule to certain providers, including hospitals and CAHs, Medicare Advantage plans, Medicaid and CHIP state entities, and issuers offering QHPs on the FFEs. It does not include the potential savings (Tables 23 and 24) arising from reduced burden due to providers, hospitals, and CAHs using electronic prior authorization. Table 29 is stated in 2023 dollars reflecting the expected first half year that these provisions would begin to be implemented (primarily by building systems).

In accordance with the provisions of Executive Order 12866, this proposed rule was reviewed by OMB.

VI. Response to Comments

Because of the large number of public comments, we normally receive on Federal Register documents, we are not able to acknowledge or respond to them individually. We will consider all comments we receive by the date and time specified in the DATES section of this preamble, and, when we proceed with a subsequent document, we will respond to the comments in the preamble to that document.

Chiquita Brooks-LaSure, Administrator of the Centers for Medicare & Medicaid Services, approved this document on November 23, 2022.

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 proposes to amend 42 CFR chapter IV and the Department of Health and Human Services proposes to amend 45 CFR part 156 as set forth below:

Title 42—Public Health

PART 422—MEDICARE ADVANTAGE PROGRAM

1. The authority citation for part 422 continues to read as follows:

Authority: 42 U.S.C. 1302 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. Adding 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 is revised 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 a 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) and (8) 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 paragraphs (e) and (f) 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)(1) 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 paragraph (b)(5) and (6);

c. Revising paragraphs (c)(1) and (c)(3) introductory text;

d. Adding paragraph (c)(3)(iii);

e. Revising paragraphs (c)(4) introductory text, (c)(4)(ii)(C), and (e)(2); and

g. Adding 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:

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), and (f).

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: