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

Federal RegisterFeb 8, 2024

Ask Donna

What actually matters in this document.

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.”

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.

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,

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.

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)

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

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

See

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

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.

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.

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).”

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

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.

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.

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.

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.

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.

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).

For example, 45 CFR 147.136(b)(3)(ii)(E)(

) 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.

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.

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.

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.

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)(

) (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 require payers to include data or forms that were not sent in a standardized electronic manner, such as via the Prior Authorization API. The commenters expressed concern about the feasibility for impacted payers to provide information that they received in a non-electronic or unstructured format (such as scanned documents or PDFs) and whether third-party patient apps can access or display such documentation. Instead, commenters recommended that CMS focus on requiring that discrete data elements and structured data related to prior authorizations be available to patients. While some commenters expressed that structured data may be duplicative or unnecessary, a majority of commenters indicated that including such data would not be overly burdensome for payers.

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

Response:

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

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

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

At this time, the standards for transmitting documentation and attachments via the FHIR APIs are still under development and in testing, and thus not yet in widespread use across the industry. The developing standard for exchanging attachments via FHIR APIs is the HL7® FHIR® Da Vinci Clinical Data Exchange (CDex) IG.

Version 2 of the IG completed the HL7 consensus-based process in 2023 and was published as an STU, indicating that it is being prepared for additional testing by implementers before being proposed for adoption. Without the FHIR standard, payers might implement unstructured documentation attachments within the Patient Access API in a variety of ways, which would lead to confusion and lack of interoperability. At this time, attachments exchanged via CDex are considered unstructured documentation and would not need to be made available via the Patient Access API as part of the prior authorization information. If the CDex becomes a mature standard, we may reconsider in future rulemaking whether it would be beneficial to share unstructured documentation as attachments via the Patient Access API.

Health Level Seven International (2023). Da Vinci Clinical Data Exchange. Retrieved from

https://hl7.org/fhir/us/davinci-cdex/.

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

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

Comment:

Multiple commenters suggested that the Patient Access API should include information regarding whether the requesting provider is in-network or out-of-network, by requiring payers to fully implement the X12 270/271 transaction standards for health plan eligibility benefit inquiry and responses. Another commenter recommended that CMS require payers to make available via the Patient Access API the names and contact information for the in-network provider who can furnish the appropriate service within the time and distance standards required by law. Multiple commenters

believed that patients should be able to access prior authorization information via the Patient Access API regardless of their provider. A commenter noted consideration for varying network adequacy standards and that a patient may need to seek care from an out-of-network provider. A commenter noted that Medicaid managed care plans have wide discretion for measuring provider network adequacy and that a patient's provider should be able to offer the same services for prior authorization despite their network status with the patient.

Response:

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

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

Comment:

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

Response:

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

iii. Timeline for Data Sharing

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

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

Comment:

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

Response:

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

Comment:

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

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

Response:

We appreciate commenters' perspectives regarding the feasibility of a 1 business day timeframe. Per the comments we received, the most significant barrier to the 1 business day timeframe we proposed was the proposed requirement to include unstructured documentation with prior authorization information. As discussed previously, we are not finalizing a requirement to make available unstructured prior authorization documentation via the Patient Access API. That exclusion from the data required to be made available will reduce the amount of data translation and transformation required to have data available via the Patient Access API. In addition, as discussed in section I.D., we are delaying the compliance

dates by 1 year from our proposed 2026 to 2027 in order to give impacted payers additional time to make system changes necessary to meet the requirements of this final rule. We acknowledge that this may be particularly challenging for Medicaid and CHIP agencies based on existing MMIS systems. As discussed in section II.E. of this final rule, expenditures for required changes to states' MMIS or other state systems may be eligible for enhanced Federal financial participation. That funding may be available, not just for systems and processes that directly contribute to data available via the Patient Access API, but for other systems, such as those that track prior authorization requests and decisions. We also note that the Prior Authorization API discussed in section II.D. will greatly facilitate the movement of structured prior authorization data. Payers, including Medicaid and CHIP, should consider levers for promoting its usage by their providers.

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

Comment:

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

Response:

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

Comment:

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

Response:

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

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

Comment:

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

Response:

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

Comment:

A couple of commenters requested clarification about the relationship between our Patient Access API requirements and ONC's information blocking regulations at 45 CFR part 171. Specifically, commenters questioned the implications of the

information blocking regulations if payers also meet the definition of a health information network (HIN) or HIE at 45 CFR 171.102. They questioned whether our timeline requirement is compatible with the “21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program” final rule (85 FR 25642) (ONC Cures Act final rule), which the commenter explained requires information to be made available to the patient “without delay.”

Response:

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

Office of the National Coordinator for Health Information Technology (2023, November 2). Information Blocking. Retrieved from

https://www.healthit.gov/topic/information-blocking.

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

https://www.healthit.gov/topic/information-blocking.

iv. Length of Prior Authorization Data Availability

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

Comment:

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

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

Response:

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

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

b. Interaction With HIPAA Right of Access Provisions

Previous CMS interoperability proposals have elicited numerous comments regarding the interaction between the Patient Access API and HIPAA Privacy Rule individual right of access.

Per 45 CFR 164.524, an individual patient generally has a right of access to inspect and obtain a copy of PHI about themselves in a designated record set for as long as the PHI is maintained in the designated record set by a covered entity. This includes the right to inspect or obtain a copy, or both, of the PHI. Our Patient Access API policies complement that right by requiring payers to make available—through a standards-based and interoperable FHIR API (that is, the Patient Access API)—PHI that patients already have a right to access. It is critical that individuals have access to their own health information and the ability to share it with others who are

involved in their care, particularly when it could involve care coordination between providers or prior authorization.

See

CMS Interoperability and Patient Access final rule (85 FR 25516-19) and December 2020 CMS Interoperability proposed rule (85 FR 82586).

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

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

See 42 CFR 422.119(e) for MA organizations; 42 CFR 431.60(e) for state Medicaid FFS programs, through the existing cross reference at 42 CFR 438.242(b)(5) for Medicaid managed care plans; 42 CFR 457.730(e) for state CHIP FFS programs, through the existing cross reference at 42 CFR 457.1233(d) for CHIP managed care entities; and 45 CFR 156.221(e) for QHP issuers on the FFEs.

As we discussed in the CMS Interoperability and Patient Access final rule (85 FR 25518), disagreement with the patient about the worthiness of a health app as a recipient of patient data, or even concerns about what the app might do with the requested data, are not acceptable reasons to deny an individual's request. Impacted payers may offer advice to patients on the potential risks of permitting an app or entity access to the patient data required to be made available via the Patient Access API. However, such efforts generally must stop at education and awareness or advice related to a specific app. Payers can inform the patient that the patient may not want to allow an app to access their data without a clear understanding of how that app may use their data, including how the patient's personal data would be used or sold (a possibility for apps that are not covered entities or business associates under the HIPAA Privacy Rule and the Security Standards for the Protection of Electronic Protected Health Information

[the Security Rule]). For instance, if a payer learns that a particular app has publicly known privacy or security vulnerabilities, they could inform patients who use that app to access their data of those known vulnerabilities. Per our policies finalized in the CMS Interoperability and Patient Access final rule, if a patient still wants to use the app, or does not respond to the payer's warning, the impacted payer is required to share their data via the API, absent an unacceptable security risk to the payer's own system. For more information on this ability to inform patients, see the CMS Interoperability and Patient Access final rule at 85 FR 25550. Again, the finalized policies in this rule do not affect or alter any obligations under the HIPAA Privacy and Security Rules.

See

also

the HIPAA Security Rule, 45 CFR parts 160 and 164, subparts A and C.

While FHIR itself does not define security-related functions, when used in combination with appropriate security controls (such as authentication and access control), a FHIR API can and should be implemented and maintained to comply with the HIPAA Security Rule, at 45 CFR parts 160 and 164, subparts A and C, for secure data exchange.

Furthermore, a covered entity is not liable for what happens to the PHI once the designated third party receives the information as directed by the individual.

Health Level Seven International (2022, May 28). HL7 FHIR Release 4. 6.1.0 FHIR Security. Retrieved from

http://www.hl7.org/Fhir/security.html.

Office for Civil Rights (2020, January 31). What is the liability of a covered entity in responding to an individual's access request to send the individual's PHI to a third party? Retrieved from

https://www.hhs.gov/hipaa/for-professionals/faq/2039/what-is-the-liability-of-a-covered-entity-in-responding/index.html.

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

For more information about what laws may apply to health apps, see

https://www.ftc.gov/business-guidance/resources/mobile-health-apps-interactive-tool.

See U.S.

Easy Healthcare Corp.,

Case No. 1:23-cv-3107 (N.D. Ill. 2023),

https://www.ftc.gov/legal-library/browse/cases-proceedings/202-3186-easy-healthcare-corporation-us-v; In the Matter of BetterHelp, Inc.,

FTC Dkt. No. C-4796 (July 14, 2023),

https://www.ftc.gov/legal-library/browse/cases-proceedings/2023169-betterhelp-inc-matter; U.S.

GoodRx Holdings, Inc.,

Case No. 23-cv-460 (N.D. Cal. 2023),

https://www.ftc.gov/legal-library/browse/cases-proceedings/2023090-goodrx-holdings-inc; In the Matter of Flo Health Inc.,

FTC Dkt. No. C-4747 (June 22, 2021),

https://www.ftc.gov/legal-library/browse/cases-proceedings/192-3133-flo-health-inc.

The FTC also enforces the FTC Health Breach Notification Rule (16 CFR part 318), which applies to most health apps and similar technologies that are not covered entities or business associates under HIPAA and, therefore, are not subject to the HIPAA Breach Notification Rule (45 CFR 164.400 through 164.414).

The FTC's Health Breach Notification Rule sets forth steps that entities covered by that rule must follow when there has been a breach of unsecured personal health information. Any violation of the FTC's Health Breach Notification Rule is treated as an unfair or deceptive act or practice under section 18 of the FTC Act and is subject to civil penalties of up to $50,120 per violation per day.

In 2023, the Commission brought its first enforcement actions under the Health Breach Notification Rule.

Federal Trade Commission (January 2022). Complying with FTC's Health Breach Notification Rule. Retrieved from

https://www.ftc.gov/tips-advice/business-center/guidance/complying-ftcs-health-breach-notification-rule.

See also Federal Trade Commission (2021, September 15). Statement of the Commission on Breaches by Health Apps and Other Connected Devices. Retrieved from

https://www.ftc.gov/system/files/documents/public_statements/1596364/statement_of_the_commission_on_breaches_by_health_apps_and_other_connected_devices.pdf.

16 CFR 1.98 makes inflation adjustments in the dollar amounts of civil monetary penalties provided by law within the Commission's jurisdiction.

See U.S.

Easy Healthcare Corp.,

Case No. 1:23-cv-3107 (N.D. Ill. 2023),

https://www.ftc.gov/legal-library/browse/cases-proceedings/202-3186-easy-healthcare-corporation-us-v; U.S.

GoodRx Holdings, Inc.,

Case No. 23-cv-460 (N.D. Cal. 2023),

https://www.ftc.gov/legal-library/browse/cases-proceedings/2023090-goodrx-holdings-inc.

c. Patient Access API Metrics

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

Specifically, we proposed that impacted payers annually report—

• The total number of unique patients whose data are transferred via the Patient Access API to a health app designated by the patient; and

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

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

Comment:

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

Response:

We thank commenters for their feedback.

Comment:

Commenters recommended that these metrics only be used to evaluate the effectiveness of CMS's policies and to assess whether patients are using the Patient Access API in a volume sufficient to justify the administrative burden of existing and future requirements. A commenter stated that these metrics would not reflect factors within a payer's control and recommended that CMS work with FTC to have third-party app developers directly report these metrics. Another commenter warned that these metrics may not account for patie

This text is long and has been trimmed here. Open the source document for the complete record.

This is a copy of a public record, reproduced as it was published. It is not legal advice, and it may not be the version a court would rely on. Check the official source before you cite it.