# 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

> Briefs, arguments, decisions, and more.

URL: https://www.frixlaw.com/law-library/documents/fr%3A2024-00895

## Record

- **Collection:** Federal Register
- **Document type:** Rule
- **Published:** February 8, 2024
- **Citation:** 89 FR 8758

## Text

DEPARTMENT OF HEALTH AND HUMAN SERVICES
Centers for Medicare & Medicaid Services
42 CFR Parts 422, 431, 435, 438, 440, and 457
Office of the Secretary
45 CFR Part 156
[CMS-0057-F]
RIN 0938-AU87
Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Advancing Interoperability and Improving Prior Authorization Processes for Medicare Advantage Organizations, Medicaid Managed Care Plans, State Medicaid Agencies, Children's Health Insurance Program (CHIP) Agencies and CHIP Managed Care Entities, Issuers of Qualified Health Plans on the Federally-Facilitated Exchanges, Merit-Based Incentive Payment System (MIPS) Eligible Clinicians, and Eligible Hospitals and Critical Access Hospitals in the Medicare Promoting Interoperability Program

AGENCY:

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

ACTION:

Final rule.

SUMMARY:

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

DATES:

These regulations are effective on April 8, 2024.

FOR FURTHER INFORMATION CONTACT:

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

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

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

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

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

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

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

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

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

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

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

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

SUPPLEMENTARY INFORMATION:

Table of Contents

I. Background and Summary of Provisions

A. Purpose and Background

B. Summary of Major Provisions

C. Specific Terms Used in This Final Rule

D. Global Comments

II. Provisions of the Proposed Rule

A. Patient Access API

B. Provider Access API

C. Payer-to-Payer API

D. Prior Authorization API and Improving Prior Authorization Processes

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

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

G. Interoperability Standards for APIs

III. Collection of Information Requirements

IV. Regulatory Impact Analysis

I. Background, Summary of Provisions, and Terms

A. Purpose and Background

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

This rule also builds upon the policies established in the “Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Interoperability and Patient Access for MA Organization and Medicaid Managed Care Plans, State Medicaid Agencies, CHIP Agencies and CHIP Managed Care Entities, Issuers of Qualified Health Plans on the Federally-Facilitated Exchanges, and Health Care Providers” final rule (85 FR 25510, May 1, 2020) (hereinafter referred to as the “CMS Interoperability and Patient Access final rule”).

We received nearly 900 timely pieces of correspondence containing comments on the CMS Interoperability and Prior Authorization proposed rule. Some public comments were outside of the scope of the proposed rule and those out-of-scope comments are not addressed in this final rule. Summaries

of the public comments that are within the scope of the proposed rule and our responses to those public comments are addressed in the various sections of this final rule under the appropriate heading. However, in this section we address certain comments that pertain across policies or to the rule overall.

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

B. Summary of Major Provisions

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

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

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

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

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

We are also finalizing our proposals to establish certain requirements for the prior authorization process, regardless of whether the payer receives the prior authorization request through the Prior Authorization API. We are requiring that impacted payers send notices to providers when they make a prior authorization decision, including a

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

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

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

• Health Level Seven (HL7®) Fast Healthcare Interoperability Resources (FHIR®) Release 4.0.1 at 45 CFR 170.215(a)(1) (HL7 FHIR).

• HL7® FHIR® US Core Implementation Guide (IG) Standard for Trial Use (STU) 3.1.1, which expires on January 1, 2026, at 45 CFR 170.215(b)(1)(i) (US Core IG).

• HL7® SMART Application Launch Framework IG Release 1.0.0 which expires on January 1, 2026, at 45 CFR 170.215(c)(1) (SMART App Launch IG).

• FHIR® Bulk Data Access (Flat FHIR) IG v1.0.0: STU 1 at 45 CFR 170.215(d)(1) (Bulk Data Access IG).

• OpenID Connect Core 1.0, incorporating errata set 1 at 45 CFR 170.215(e)(1) (OpenID Connect Core).

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

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

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

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

Executive Order 13985 of January 20, 2021, entitled “Advancing Racial Equity and Support for Underserved Communities Through the Federal Government,” set administration policy that the “Federal Government should pursue a comprehensive approach to advancing equity for all.”
1

CMS is committed to pursuing a comprehensive approach to advancing health equity for all, and the policies in this final rule are aligned with that Executive order because they represent efforts to mitigate existing inefficiencies in policies, processes, and technology that affect many patient populations. Some patient populations are more negatively affected by existing processes than

others and should realize greater benefits through the improvements these policies will provide. One of the main components of this final rule is our continued support for the individual's ability to select an app of their choice when accessing their health information. We want to ensure that members of all communities can access their health information and benefit from this technology. However, we are interested in the best ways to ensure that apps are available and accessible for individuals with disabilities, individuals with limited English proficiency, individuals with low literacy or low health literacy, and individuals with geographic, economic, or other social risk factors that may create barriers to accessing or using technology and apps.

1
Executive Order 13985, sec. 1, 86 FR 7009 (January 20, 2021).

Our goal is to ensure that these proposed policies do not exacerbate current disparities or create unintended inequities that leave some communities or populations unable to benefit from this information sharing. Further, we seek to ensure that patient privacy considerations are built into the implementation of these proposed policies by using secure technologies, such as Open Authorization/Open ID (OAuth) 2.0 and OpenID Connect Core for authentication,
2

as previously discussed in the CMS Interoperability and Patient Access final rule (85 FR 25520). While we proposed policies that we believed would address some health care inequities, we solicited comments about how to ensure that individuals from all communities and populations can actively benefit from our health care interoperability proposals.

2
Health Level Seven International. Smart App Launch Implementation Guide, OpenID and Authentication for Smart Apps. Retrieved from
https://hl7.org/fhir/smart-app-launch/.

C. Specific Terms Used in This Final Rule

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

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

Throughout this final rule, we use terms such as “patient,” “consumer,” “beneficiary,” “enrollee,” and “individual.” Every reader of this final rule is a patient who has received or will receive, medical care at some point in their life. In this final rule, we use the term “patient” as an inclusive term. We understand that, historically, we have referred in our regulations to “patients” using the other terms previously noted. However, for the policies herein, we will use additional, specific terms applicable to individuals covered under the health care programs that we administer and regulate. We also note that when we discuss patients, the term includes, where applicable, a patient's personal representative. For example, a patient or their personal representative may opt into or out of certain types of information exchange under the policies in this final rule. But when we refer to a patient's medical needs or health records, we do not include the medical needs or health records of the patient's personal representative. Per the Standards for Privacy of Individually Identifiable Health Information (Health Insurance Portability and Accountability Act (HIPAA) Privacy Rule)
3

issued under HIPAA (Pub. L. 104-191, enacted on August 21, 1996), as modified, at 45 CFR 164.502(g), and related guidance, a “personal representative” is a person authorized under state or other applicable law to act on behalf of an individual in making health care-related decisions (such as a parent, guardian, or person with a medical power of attorney).
4

Under the HIPAA Privacy Rule (45 CFR part 164, subpart E), the individual's personal representative generally may exercise the right to access the individual's protected health information (PHI). For many processes described in this final rule, a patient's personal representative could act on a patient's behalf, as permitted by the HIPAA Privacy Rule and other applicable laws.

3

See
45 CFR parts 160 and 164, subparts A and E.

4
U.S. Department of Health and Human Services. Health Information and Privacy. Retrieved from
https://www.hhs.gov/hipaa/for-professionals/faq/2069/under-hipaa-when-can-a-family-member/index.html
and
https://www.hhs.gov/hipaa/for-professionals/faq/personal-representatives-and-minors/index.html.

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

We use the term “policies that require API enhancement or development” to describe the requirements that involve technical development work to either establish a new API, such as the Provider Access or Payer-to-Payer APIs, or to enhance the functionality of an existing API, such as the addition of

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

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

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

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

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

5
Office of the National Coordinator for Health Information Technology (n.d.). Application Programming Interfaces. Retrieved from
https://www.healthit.gov/api-education-module/story_html5.html.

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

6
Health Level Seven International (2023). Guide to Using HL7 Trademarks. Retrieved from
http://www.hl7.org/legal/trademarks.cfm?ref=nav.

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

D. Global Comments

CMS received nearly 900 timely pieces of correspondence in response to the CMS Interoperability and Prior Authorization proposed rule. We summarize comments that are globally applicable to the final rule here. In this section, we address comments related to Medicare FFS implementation, the National Directory of Healthcare (NDH), final policy compliance dates, exclusion of drugs from the prior authorization policies in this final rule, the payers impacted by this final rule, the withdrawal of the “Medicaid Program; Patient Protection and Affordable Care Act; Reducing Provider and Patient Burden by Improving Prior Authorization Processes, and Promoting Patients' Electronic Access to Health Information for Medicaid Managed Care

Plans, State Medicaid Agencies, CHIP Agencies and CHIP Managed Care Entities, and Issuers of Qualified Health Plans on the Federally-Facilitated Exchanges; Health Information Technology Standards and Implementation Specifications” proposed rule (December 2020 CMS Interoperability proposed rule) (87 FR 76239), and compliance and enforcement.

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

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

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

2. Compliance Dates and Enforcement

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

States are obligated by 42 CFR 438.66(b) and (c) to have a monitoring system for all of their managed care programs, including the performance of

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

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

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

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

3. Exclusion of Drugs

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

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

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

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

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

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

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

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

Comment:
Many commenters questioned whether impacted payers are permitted to include the functionality necessary to conduct prior authorization for drugs via the Prior Authorization

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

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

7
Health Level Seven International (n.d.) Use Cases and Overview. Retrieved from
https://build.fhir.org/ig/HL7/davinci-pas/usecases.html#scope-of-work-flow.

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

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

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

4. Impacted Payers

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

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

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

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

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

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

An organization that has a risk-based contract directly with a state to provide dental benefits only to Medicaid and CHIP beneficiaries is usually a PAHP. We proposed, at 42 CFR 438.210 and 438.242 for Medicaid (applicable to separate CHIP through existing cross-references at 42 CFR 457.1230(d) and 457.1233(d)), that all PAHPs other than Non-Emergency Medical Transportation (NEMT) PAHPs, including those that cover dental benefits, would be subject to the requirements of this rule. Per 42 CFR 438.4, capitation rates, which are

required for all risk-based MCOs, PIHPs, and PAHPs, must be projected to provide for all reasonable, appropriate, and attainable costs that are required under the terms of the contract and for the operation of the managed care plan for the time period, as well as the population covered under the terms of the contract, in addition to meeting specific additional requirements at 42 CFR 438.4 through 438.7. Similarly, for separate CHIP, per 42 CFR 457.1201(c) and 457.1203(a), capitation rates are based on public or private payment rates for comparable services for comparable populations and must represent a payment amount that is adequate to allow the MCO, PIHP, or PAHP to efficiently deliver covered services to beneficiaries in a manner compliant with contractual requirements. Therefore, the concerns of upward pressure on premiums that impact participation that are applicable to SADPs offered on the FFEs are not present for Medicaid and CHIP risk-based managed care plans.

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

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

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

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

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

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

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

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

5. Withdrawal of Proposed Rule

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

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

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

6. National Directory of Healthcare

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

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

describes

a payer to payer data exchange but is based on the projected existence of a national directory of payer endpoints and governance framework. A commenter noted scalability issues that could arise without a national directory of endpoints to connect in a unified and meaningful manner.

8
Health Level Seven International (n.d.). National Directory of Healthcare Providers & Services (NDH) Implementation Guide. Retrieved from
https://build.fhir.org/ig/HL7/fhir-us-ndh/.

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

9
Office of the National Coordinator for Health Information Technology (n.d.). Trusted Exchange Framework and Common Agreement (TEFCA). Retrieved from
https://www.healthit.gov/topic/interoperability/policy/trusted-exchange-framework-and-common-agreement-tefca.

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

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

A. Patient Access API

1. Background

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

2. Enhancing the Patient Access API

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

To support the ongoing maintenance of the Patient Access API, we are requiring certain specifications and recommending certain IGs, as further discussed in this section and in section II.G. With the publication of the HTI-1 final rule, our cross references to 45 CFR 170.215 have been updated to reflect the updated citations as needed. Changes to the structure of 45 CFR 170.215 and versions of the API standards codified there are discussed further in section II.G. and reflected throughout this final rule. For the Patient Access API, impacted payers must use the following standards: HL7 FHIR Release 4.0.1 at 45 CFR 170.215(a)(1), US Core IG STU 3.1.1 at 45 CFR 170.215(b)(1)(i), SMART App Launch IG Release 1.0.0 at 45 CFR 170.215(c)(1) and OpenID Connect Core 1.0 at 45 CFR 170.215(e)(1). Impacted payers are permitted to voluntarily use updated standards, specifications, or IGs that are not yet adopted in regulation for the APIs discussed in this final rule, should certain conditions be met. For the standards at 45 CFR 170.215 required for the Patient Access API, updated versions available for use under our policy include, but are not limited to, US Core IG STU 6.1.0 and SMART App Launch IG Release 2.0.0, which have been approved for use in the ONC Health IT Certification Program.
10

We refer readers to policies finalized for the Patient Access API in the Interoperability and Patient Access final rule, as well as section II.G.2.c. of this final rule for a full discussion on using updated standards. We are also recommending payers use the HL7® FHIR® CARIN Consumer Directed Payer Data Exchange IG (CARIN IG for Blue Button) STU 2.0.0, HL7® FHIR® Da Vinci Payer Data Exchange (PDex) IG STU 2.0.0, and HL7® FHIR® Da Vinci PDex US Drug Formulary IG STU 2.0.1. We also direct readers to section II.G. of this final rule for a discussion of the standards for the Patient Access API, and Table H3 for a full list of the required standards and recommended IGs to support API implementation.

10
Office of the National Coordinator for Health Information Technology (2023, September 11).
Standards Version Advancement Process (SVAP).
Retrieved from
https://www.healthit.gov/topic/standards-version-advancement-process-svap.

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

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

Response:
We thank the commenters for their feedback and will continue to

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

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

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

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

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

11

See
45 CFR 164.524(c)(2)(i).

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

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

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

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

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

Response:
Under the HIPAA Privacy Rule, at 45 CFR 164.526, individuals have the right to have a covered entity amend PHI or a record about the individual in a designated record set for as long as the PHI is maintained in the designated record set, with certain exceptions. The Patient Access API does not require the impacted payer to

include the capability to send information from a patient to a payer. Therefore, while patients have the right under the HIPAA Privacy Rule to request that a HIPAA-covered entity (such as a provider or payer) amend their record, that functionality is out of scope for the Patient Access API.

a. Prior Authorization Information

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

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

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

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

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

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

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

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

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

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

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

Response:
We understand that data submitted for prior authorization requests via non-electronic or non-standardized modalities could require an additional step to make available through the Patient Access API. However, we also note that the burden of ingesting data from non-standard and

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

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

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

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

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

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

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

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

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

i. Compliance Dates

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

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

Conversely, multiple commenters recommended that CMS delay the proposed compliance date until the Prior Authorization API, discussed in section II.D. of this final rule, is widely adopted. Commenters stated that while the technical data standards may be mature, CMS should also consider the status of payers' data infrastructure, which may not have prior authorization information in a structured format to be shared via the Patient Access API. As discussed previously, some commenters recommended limiting the requirement to make prior authorization data available through the Patient Access API only to data contained in standardized HIPAA-compliant electronic prior authorization transactions, such as those facilitated by the Prior Authorization

API. These commenters recommended that CMS work with payers, providers, health IT developers, and consumer advocacy groups to first advance electronic prior authorization uptake before determining appropriate compliance dates. A commenter suggested CMS consider additional flexibilities and exceptions for impacted entities unable to comply with the proposed 2026 compliance dates.

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

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

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

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

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

ii. Data Content

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

(1) The prior authorization status.

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

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

(4) The items and services approved.

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

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

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

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

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

Response:
While we consider five basic statuses (pending, active, denied,

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

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

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

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

12
For example, 45 CFR 147.136(b)(3)(ii)(E)(
3
) provides that individual health insurance issuers' notifications of any adverse benefit determination must include the reason or reasons for the determination along with the denial code and its corresponding meaning, and a description of the issuer's standard, if any, that was used in denying the claim. In the case of a notice of a final internal adverse benefit determination, this description must include a discussion of the decision.

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

Response:
In this final rule, we are requiring impacted payers to provide a specific reason for a denial. We did not propose standardized denial codes or a specific set of denial reasons for payers to use. However, there is a list of standardized codes that must be used when a prior authorization decision is sent to a provider via the adopted HIPAA standard, which is maintained by the SDO X12.
13

While using those codes is not required for the Patient Access API, we strongly encourage payers and providers to evaluate the code set and make recommendations to X12 for updated or new denial codes, as appropriate. If those X12 denial codes meet the requirement for specificity, they could be used in both the HIPAA transaction and the Patient Access API.

13
X12 Standards (2022, August). Service Review Decision Reason Codes. Retrieved from
https://x12.org/codes/service-review-decision-reason-codes.

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

Response:
We did not propose to make that information available via the Patient Access API. Our educational requirements, discussed in the CMS Interoperability and Patient Access final rule (85 FR 25550-52), only cover using the Patient Access API and not the prior authorization process writ large. However, impacted payers are already required to include that information with a notice of denial.
14

For requirements to make information about the appeals process available to patients via other modalities, see further discussion in section II.D. of this final rule. Depending on the specific requirements of their program, impacted payers may be able to meet that requirement by providing notice about the appeals process via the Patient Access API.

14

See
42 CFR 422.568(e)(3) (for MA), 431.210(d) (for Medicaid), and 457.1180 (for CHIP) and 45 CFR 147.136(b)(2)(ii)(E)(
4
) (for QHP issuers on the FFEs).

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

a patient for weeks or months until claims are processed.

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

Comment:
Some commenters recommended that administrative and clinical documentation sent by the provider for prior authorization requests be included in the Patient Access API. However, multiple other commenters recommended that CMS not finalize its proposal to include supporting documentation for prior authorization requests. Some commenters specifically recommended that CMS not

[Text truncated at 120,000 characters. The full text is on the page linked above.]

---

Source: Frix Law Library, https://www.frixlaw.com/law-library/documents/fr%3A2024-00895. Public record. Not legal advice.