Justia Department Of Health And Human Services Centers For Medicare & Medicaid Services 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, 8758-8988 [2024-00895]

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, 8758-8988 [2024-00895]

Download as PDF 8758 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations FOR FURTHER INFORMATION CONTACT: 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 FederallyFacilitated Exchanges, Merit-Based Incentive Payment System (MIPS) Eligible Clinicians, and Eligible Hospitals and Critical Access Hospitals in the Medicare Promoting Interoperability Program Centers for Medicare & Medicaid Services (CMS), Department of Health and Human Services (HHS). ACTION: Final rule. AGENCY: 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 feefor-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 Federallyfacilitated 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. lotter on DSK11XQN23PROD with RULES2 SUMMARY: VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 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 PO 00000 Frm 00002 Fmt 4701 Sfmt 4700 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 FederallyFacilitated 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 E:\FR\FM\08FER2.SGM 08FER2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations lotter on DSK11XQN23PROD with RULES2 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 standardsbased 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. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 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-toPayer 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 PO 00000 Frm 00003 Fmt 4701 Sfmt 4700 8759 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 E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8760 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations 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 VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 (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 PO 00000 Frm 00004 Fmt 4701 Sfmt 4700 or after January 1, 2026, for QHP issuers on the FFEs), for all policies that require API development and enhancement. Based on commenter feedback and as noted previously, we are delaying the compliance dates in this final rule for the provisions that require API development and enhancement in 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs). Throughout this rule, we generally refer to these compliance dates as ‘‘in 2027’’ for the various payers. We believe this approximately 3-year timeline to recruit and train staff, update, or build the APIs, and update operational procedures will be sufficient to implement these policies, based on comments and public information from some payers and providers regarding similar initiatives already in progress. In addition to the 3-year implementation timeframe, we are finalizing our proposal to give state Medicaid and CHIP FFS programs an opportunity to seek an extension to the compliance dates, or an exemption from meeting certain requirements, in certain circumstances. Additionally, we are finalizing our proposal to provide an exceptions process for QHP issuers on the FFEs. We believe the approximately 3-year timeframe for implementation in the final rule will offer sufficient time for state Medicaid and CHIP FFS programs and QHP issuers on the FFEs to determine whether they can timely satisfy the API development and enhancement requirements in this final rule and to prepare the necessary documentation to request an extension, exemption, or exception, as applicable. Executive Order 13985 of January 20, 2021, entitled ‘‘Advancing Racial Equity and Support for Underserved Communities Through the Federal Government,’’ set administration policy that the ‘‘Federal Government should pursue a comprehensive approach to advancing equity for all.’’ 1 CMS is committed to pursuing a comprehensive approach to advancing health equity for all, and the policies in this final rule are aligned with that Executive order because they represent efforts to mitigate existing inefficiencies in policies, processes, and technology that affect many patient populations. Some patient populations are more negatively affected by existing processes than 1 Executive Order 13985, sec. 1, 86 FR 7009 (January 20, 2021). E:\FR\FM\08FER2.SGM 08FER2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations others and should realize greater benefits through the improvements these policies will provide. One of the main components of this final rule is our continued support for the individual’s ability to select an app of their choice when accessing their health information. We want to ensure that members of all communities can access their health information and benefit from this technology. However, we are interested in the best ways to ensure that apps are available and accessible for individuals with disabilities, individuals with limited English proficiency, individuals with low literacy or low health literacy, and individuals with geographic, economic, or other social risk factors that may create barriers to accessing or using technology and apps. Our goal is to ensure that these proposed policies do not exacerbate current disparities or create unintended inequities that leave some communities or populations unable to benefit from this information sharing. Further, we seek to ensure that patient privacy considerations are built into the implementation of these proposed policies by using secure technologies, such as Open Authorization/Open ID (OAuth) 2.0 and OpenID Connect Core for authentication,2 as previously discussed in the CMS Interoperability and Patient Access final rule (85 FR 25520). While we proposed policies that we believed would address some health care inequities, we solicited comments about how to ensure that individuals from all communities and populations can actively benefit from our health care interoperability proposals. lotter on DSK11XQN23PROD with RULES2 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 2 Health Level Seven International. Smart App Launch Implementation Guide, OpenID and Authentication for Smart Apps. Retrieved from https://hl7.org/fhir/smart-app-launch/. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 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 standalone dental plans (SADPs). Likewise, we are also excluding QHP issuers offering only QHPs in the Federallyfacilitated 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 PO 00000 Frm 00005 Fmt 4701 Sfmt 4700 8761 information exchange under the policies in this final rule. But when we refer to a patient’s medical needs or health records, we do not include the medical needs or health records of the patient’s personal representative. Per the Standards for Privacy of Individually Identifiable Health Information (Health Insurance Portability and Accountability Act (HIPAA) Privacy Rule) 3 issued under HIPAA (Pub. L. 104–191, enacted on August 21, 1996), as modified, at 45 CFR 164.502(g), and related guidance, a ‘‘personal representative’’ is a person authorized under state or other applicable law to act on behalf of an individual in making health care-related decisions (such as a parent, guardian, or person with a medical power of attorney).4 Under the HIPAA Privacy Rule (45 CFR part 164, subpart E), the individual’s personal representative generally may exercise the right to access the individual’s protected health information (PHI). For many processes described in this final rule, a patient’s personal representative could act on a patient’s behalf, as permitted by the HIPAA Privacy Rule and other applicable laws. 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 3 See 45 CFR parts 160 and 164, subparts A and E. 4 U.S. Department of Health and Human Services. Health Information and Privacy. Retrieved from https://www.hhs.gov/hipaa/for-professionals/faq/ 2069/under-hipaa-when-can-a-family-member/ index.html and https://www.hhs.gov/hipaa/forprofessionals/faq/personal-representatives-andminors/. E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8762 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations 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 VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 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 PO 00000 Frm 00006 Fmt 4701 Sfmt 4700 finance smartphone apps, which can function without being integrated into the smartphone’s operating system. Standardized, secure, transparent, and pro-competitive API technology can provide similar benefits for patients of health care services.5 Health Level 7 (HL7®) is the standards development organization (SDO) that develops the Fast Healthcare for Interoperability Resources (FHIR®) standard and IGs referenced throughout this final rule. HL7 requires the registered trademark with the first use of its name in a document, for which policies are available on its website at www.HL7.org.6 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 5 Office of the National Coordinator for Health Information Technology (n.d.). Application Programming Interfaces. Retrieved from https:// www.healthit.gov/api-education-module/story_ html5.html. 6 Health Level Seven International (2023). Guide to Using HL7 Trademarks. Retrieved from https:// www.hl7.org/legal/trademarks.cfm?ref=nav. E:\FR\FM\08FER2.SGM 08FER2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations 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. lotter on DSK11XQN23PROD with RULES2 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. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 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 PO 00000 Frm 00007 Fmt 4701 Sfmt 4700 8763 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. E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8764 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations 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 VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 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-toPayer, 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 noncompliant. Response: As explained in the proposed rule and the CMS PO 00000 Frm 00008 Fmt 4701 Sfmt 4700 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 E:\FR\FM\08FER2.SGM 08FER2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations lotter on DSK11XQN23PROD with RULES2 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 VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 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 PO 00000 Frm 00009 Fmt 4701 Sfmt 4700 8765 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 reauthorizations. 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 E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8766 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations API. A commenter also requested that CMS require all payers to include drugrelated prior authorization requirements in the Prior Authorization API to ensure prescribers have ready access to uniform policies, and patients have timely access to their medications. Another commenter recommended that CMS explain that even if prescription drugs are excluded from the requirements, the rule does not prohibit the sharing of drug prior authorization data via the Patient Access, Provider Access, and Payer-to-Payer APIs. Response: While we did not propose a requirement for prior authorization policies for drugs to be included in the Prior Authorization API, payers may add such coverage rules and requirements to their APIs; nothing in this final rule prohibits broader use of the required Prior Authorization API by impacted payers and we encourage them to do so to the extent permitted by law. The scope of the IGs for the Prior Authorization API includes prior authorization for medications covered under a medical benefit. We describe the IGs and the Prior Authorization API in further detail in section II.D.2. of this final rule. However, we note that a FHIR API cannot be used with a National Council for Prescription Drug Programs (NCPDP) SCRIPT standard because the data elements have not yet been mapped. Also, the HL7® FHIR® Da Vinci Prior Authorization Support (PAS) IG states it ‘‘SHOULD NOT be used for any medication that is covered under a prescription drug program benefit where Prior Authorization is provided by another electronic exchange process (for example, NCPCP SCRIPT).’’ 7 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 7 Health Level Seven International (n.d.) Use Cases and Overview. Retrieved from https:// build.fhir.org/ig/HL7/davinci-pas/ usecases.html#scope-of-work-flow. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 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. PO 00000 Frm 00010 Fmt 4701 Sfmt 4700 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 crossreferences 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 E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations 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 riskbased 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. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 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 PO 00000 Frm 00011 Fmt 4701 Sfmt 4700 8767 commenters expressed that the burden of prior authorization has grown since that proposed rule was published and voiced their support for finalizing our proposals. Response: We appreciate the support and believe that the proposals that we are now finalizing reflect the feedback we received from the health care industry. 6. National Directory of Healthcare On October 22, 2022, we released a Request for Information (RFI) (87 FR 61018) to solicit public comments on establishing an NDH that could serve as a ‘‘centralized data hub’’ for health care provider, facility, and entity directory information nationwide. We also received many comments to this proposed rule that discussed the possibility of an NDH, particularly to discover payers’ digital endpoints (in this case, a FHIR server’s URL or IP address) to facilitate our Payer-to-Payer API policy. Comment: Many commenters stated that the lack of a national directory makes it difficult to identify digital endpoints to facilitate payer to payer data exchange. Multiple commenters also expressed how important an NDH would be to the success of a Provider Access API, because as information on provider digital endpoints remains limited, widespread access to such a directory could advance efforts to connect payers to providers. Commenters urged CMS to establish an NDH before the API compliance dates and explained that not doing so could result in an industry-wide scramble and search for verified plan endpoints necessary for implementation. A commenter recommended that CMS establish and maintain a national payer directory that includes verified information on payers, including their API endpoints, contact information for their API project managers, and their readiness for participation in payer to payer data exchange. Another commenter stated they are currently trying to set up their own Payer-to-Payer API and encountered problems without a centralized location of payer endpoints. This led to issues identifying a new member’s previous payer and making secure connections to exchange information. A commenter cautioned that a draft version of the National Directory IG developed by the FHIR at Scale Taskforce (FAST) originally published in September 2022 8 describes 8 Health Level Seven International (n.d.). National Directory of Healthcare Providers & Services (NDH) Implementation Guide. Retrieved from https:// build.fhir.org/ig/HL7/fhir-us-ndh/. E:\FR\FM\08FER2.SGM 08FER2 8768 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations a payer to payer data exchange but is based on the projected existence of a national directory of payer endpoints and governance framework. A commenter noted scalability issues that could arise without a national directory of endpoints to connect in a unified and meaningful manner. Response: We understand that a directory of payer and provider digital endpoints would be highly beneficial to facilitate our Payer-to-Payer, Provider Access, and Prior Authorization API requirements. Without such a directory, payers would need to discover other payers’ endpoints one by one, and each payer would have to maintain a list of payers that they have previously connected with for data exchange. The Trusted Exchange Framework and Common Agreement (TEFCA) provides a directory of digital endpoints that can be used by TEFCA Participants.9 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 lotter on DSK11XQN23PROD with RULES2 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 9 Office of the National Coordinator for Health Information Technology (n.d.). Trusted Exchange Framework and Common Agreement (TEFCA). Retrieved from https://www.healthit.gov/topic/ interoperability/policy/trusted-exchangeframework-and-common-agreement-tefca. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 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 PO 00000 Frm 00012 Fmt 4701 Sfmt 4700 to, US Core IG STU 6.1.0 and SMART App Launch IG Release 2.0.0, which have been approved for use in the ONC Health IT Certification Program.10 We refer readers to policies finalized for the Patient Access API in the Interoperability and Patient Access final rule, as well as section II.G.2.c. of this final rule for a full discussion on using updated standards. We are also recommending payers use the HL7® FHIR® CARIN Consumer Directed Payer Data Exchange IG (CARIN IG for Blue Button) STU 2.0.0, HL7® FHIR® Da Vinci Payer Data Exchange (PDex) IG STU 2.0.0, and HL7® FHIR® Da Vinci PDex US Drug Formulary IG STU 2.0.1. We also direct readers to section II.G. of this final rule for a discussion of the standards for the Patient Access API, and Table H3 for a full list of the required standards and recommended IGs to support API implementation. 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 10 Office of the National Coordinator for Health Information Technology (2023, September 11). Standards Version Advancement Process (SVAP). Retrieved from https://www.healthit.gov/topic/ standards-version-advancement-process-svap. E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations 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 VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 electronically or through a health app. Nothing in this rule will require patients to use the Patient Access API to access their health information. Nor will the rule change any applicable obligation for payers to make information available in non-electronic formats, should such a requirement exist. For example, 42 CFR 435.918(a) requires Medicaid agencies to give individuals the choice whether to receive notices electronically or by mail. Similar requirements for MA organizations can be found at 42 CFR 422.2267(d)(2). Furthermore, under the HIPAA Privacy Rule, covered entities generally must provide individuals access to their PHI in the form and format requested by the individual, if it is readily producible in such form and format; or, if not, in a readable hard copy form or such other form and format as agreed to by the covered entity and the individual.11 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 11 See PO 00000 45 CFR 164.524(c)(2)(i). Frm 00013 Fmt 4701 Sfmt 4700 8769 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 programor 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 E:\FR\FM\08FER2.SGM 08FER2 8770 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations lotter on DSK11XQN23PROD with RULES2 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-thecounter (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 VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 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 PO 00000 Frm 00014 Fmt 4701 Sfmt 4700 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 nonstandardized 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 E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations 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. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 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, PO 00000 Frm 00015 Fmt 4701 Sfmt 4700 8771 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 E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8772 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations 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 VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 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. PO 00000 Frm 00016 Fmt 4701 Sfmt 4700 (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, E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations 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 VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 reason for denial would help beneficiaries dispute decisions in a more effective manner. A few commenters urged CMS to require impacted payers to disclose via the Patient Access API the specific coverage or clinical criteria upon which the impacted payer relied to issue a denial. Response: While we encourage payers to provide coverage or clinical criteria that they used to make a prior authorization decision if that information would help the patient or provider understand the prior authorization decision, many payers consider that specific information to be proprietary. In addition to potentially being proprietary, those clinical criteria may be significantly more complicated than the information we are requiring, and not easily understood by patients. Therefore, we did not propose to require that detailed clinical criteria for a prior authorization decision be shared with patients through the Patient Access API. Instead, we proposed and are finalizing that when a payer denies a prior authorization request, they must provide a specific reason for that denial through the Patient Access API. That reason may indicate which clinical criteria the patient did not meet to be approved for the items or services. We reiterate that the requirement that the specific reason for a denial be included in the Patient Access API is in addition to any other applicable requirements regarding notice of decisions, such as the requirement at 42 CFR 422.568(e) that MA organizations issue a notice containing specific content when denying a prior authorization request and similar requirements for Medicaid managed care plans at 42 CFR 438.210(c) and for health insurance issuers offering individual health insurance coverage (which includes QHP issuers on the FFEs) at 45 CFR 147.136(b)(3)(ii)(E).12 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 12 For example, 45 CFR 147.136(b)(3)(ii)(E)(3) provides that individual health insurance issuers’ notifications of any adverse benefit determination must include the reason or reasons for the determination along with the denial code and its corresponding meaning, and a description of the issuer’s standard, if any, that was used in denying the claim. In the case of a notice of a final internal adverse benefit determination, this description must include a discussion of the decision. PO 00000 Frm 00017 Fmt 4701 Sfmt 4700 8773 standardized codes that must be used when a prior authorization decision is sent to a provider via the adopted HIPAA standard, which is maintained by the SDO X12.13 While using those codes is not required for the Patient Access API, we strongly encourage payers and providers to evaluate the code set and make recommendations to X12 for updated or new denial codes, as appropriate. If those X12 denial codes meet the requirement for specificity, they could be used in both the HIPAA transaction and the Patient Access API. Comment: A few commenters urged CMS to require payers to include plain language information about appealing a prior authorization decision, including processes to request internal review and external appeal of a decision and information about consumer programs to assist with appeals. Response: We did not propose to make that information available via the Patient Access API. Our educational requirements, discussed in the CMS Interoperability and Patient Access final rule (85 FR 25550–52), only cover using the Patient Access API and not the prior authorization process writ large. However, impacted payers are already required to include that information with a notice of denial.14 For requirements to make information about the appeals process available to patients via other modalities, see further discussion in section II.D. of this final rule. Depending on the specific requirements of their program, impacted payers may be able to meet that requirement by providing notice about the appeals process via the Patient Access API. 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 13 X12 Standards (2022, August). Service Review Decision Reason Codes. Retrieved from https:// x12.org/codes/service-review-decision-reasoncodes. 14 See 42 CFR 422.568(e)(3) (for MA), 431.210(d) (for Medicaid), and 457.1180 (for CHIP) and 45 CFR 147.136(b)(2)(ii)(E)(4) (for QHP issuers on the FFEs). E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8774 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations 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 nonelectronic 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 VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 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.15 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 15 Health Level Seven International (2023). Da Vinci Clinical Data Exchange. Retrieved from https://hl7.org/fhir/us/davinci-cdex/. PO 00000 Frm 00018 Fmt 4701 Sfmt 4700 FHIR standard, payers might implement unstructured documentation attachments within the Patient Access API in a variety of ways, which would lead to confusion and lack of interoperability. At this time, attachments exchanged via CDex are considered unstructured documentation and would not need to be made available via the Patient Access API as part of the prior authorization information. If the CDex becomes a mature standard, we may reconsider in future rulemaking whether it would be beneficial to share unstructured documentation as attachments via the Patient Access API. We recognize that unstructured administrative and clinical documentation from a provider could be important to help patients understand the prior authorization process, so we encourage payers to make that information available when possible. Furthermore, the policy we are finalizing will require impacted payers to make available any documentation that a provider sends to the payer to support a prior authorization request that is received in a structured format. Since we are finalizing that only structured data be made available, and structured data are formatted in a way that makes them easily transmissible between systems, our final policy should place significantly less burden on payers than our proposal, while still giving patients access to information about their prior authorization processes. We note that some of that information may already be available via the Patient Access API as clinical data. However, we believe that there is value to patients being able to ensure that the clinical information reviewed by the payer is accurate and up to date. Therefore, it is important for payers to make available the specific clinical data that they are looking at to decide on the prior authorization request, even if that information may be elsewhere in the patient’s record. Comment: Multiple commenters suggested that the Patient Access API should include information regarding whether the requesting provider is innetwork 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 E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations 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-ofnetwork 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 outof-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. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 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 PO 00000 Frm 00019 Fmt 4701 Sfmt 4700 8775 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 E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8776 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations 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 VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 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 PO 00000 Frm 00020 Fmt 4701 Sfmt 4700 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 HIPAAcompliant 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 E:\FR\FM\08FER2.SGM 08FER2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations 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.16 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/informationblocking. lotter on DSK11XQN23PROD with RULES2 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 16 Office of the National Coordinator for Health Information Technology (2023, November 2). Information Blocking. Retrieved from https:// www.healthit.gov/topic/information-blocking. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 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 PO 00000 Frm 00021 Fmt 4701 Sfmt 4700 8777 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.17 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 17 See CMS Interoperability and Patient Access final rule (85 FR 25516–19) and December 2020 CMS Interoperability proposed rule (85 FR 82586). E:\FR\FM\08FER2.SGM 08FER2 8778 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations lotter on DSK11XQN23PROD with RULES2 involved in their care, particularly when it could involve care coordination between providers or prior authorization. Consistent with the HIPAA Privacy Rule, we believe that it behooves us to require all impacted payers to have the capability to provide individuals’ PHI via an industry standard FHIR API, so that patients can access their data through apps of their choice. We believe that, in addition to the other benefits described in this final rule, ensuring that patients can receive their PHI in a standard, interoperable format that they can use with the latest technologies will reduce instances of an individual requesting PHI in an electronic format that is not readily producible, which could reduce costs and burden for patients and payers. In the CMS Interoperability and Patient Access final rule, we established that the only reason payers could deny API access to a patient’s preferred health app is if it would present an unacceptable level of risk to the security of PHI on the payer’s system. These risks include, for example, insufficient authentication or authorization controls, poor encryption, or reverse engineering. The payer must make that determination using objective, verifiable criteria that are applied fairly and consistently across all apps and developers.18 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 18 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. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 Standards for the Protection of Electronic Protected Health Information 19 [the Security Rule]). For instance, if a payer learns that a particular app has publicly known privacy or security vulnerabilities, they could inform patients who use that app to access their data of those known vulnerabilities. Per our policies finalized in the CMS Interoperability and Patient Access final rule, if a patient still wants to use the app, or does not respond to the payer’s warning, the impacted payer is required to share their data via the API, absent an unacceptable security risk to the payer’s own system. For more information on this ability to inform patients, see the CMS Interoperability and Patient Access final rule at 85 FR 25550. Again, the finalized policies in this rule do not affect or alter any obligations under the HIPAA Privacy and Security Rules. While FHIR itself does not define security-related functions, when used in combination with appropriate security controls (such as authentication and access control), a FHIR API can and should be implemented and maintained to comply with the HIPAA Security Rule, at 45 CFR parts 160 and 164, subparts A and C, for secure data exchange.20 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.21 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 19 See also the HIPAA Security Rule, 45 CFR parts 160 and 164, subparts A and C. 20 Health Level Seven International (2022, May 28). HL7 FHIR Release 4. 6.1.0 FHIR Security. Retrieved from https://www.hl7.org/Fhir/ security.html. 21 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-inresponding/. PO 00000 Frm 00022 Fmt 4701 Sfmt 4700 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.22 For more information about what laws may apply to health apps, see https://www.ftc.gov/businessguidance/resources/mobile-health-appsinteractive-tool. The FTC also enforces the FTC Health Breach Notification Rule (16 CFR part 318), which applies to most health apps and similar technologies that are not covered entities or business associates under HIPAA and, therefore, are not subject to the HIPAA Breach Notification Rule (45 CFR 164.400 through 164.414).23 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.24 In 2023, the Commission brought its first enforcement actions under the Health Breach Notification Rule.25 22 See U.S. v. Easy Healthcare Corp., Case No. 1:23–cv–3107 (N.D. Ill. 2023), https://www.ftc.gov/ legal-library/browse/cases-proceedings/202-3186easy-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. v. GoodRx Holdings, Inc., Case No. 23–cv–460 (N.D. Cal. 2023), https://www.ftc.gov/legal-library/ browse/cases-proceedings/2023090-goodrxholdings-inc; In the Matter of Flo Health Inc., FTC Dkt. No. C–4747 (June 22, 2021), https:// www.ftc.gov/legal-library/browse/casesproceedings/192-3133-flo-health-inc. 23 Federal Trade Commission (January 2022). Complying with FTC’s Health Breach Notification Rule. Retrieved from https://www.ftc.gov/tipsadvice/business-center/guidance/complying-ftcshealth-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. 24 16 CFR 1.98 makes inflation adjustments in the dollar amounts of civil monetary penalties provided by law within the Commission’s jurisdiction. 25 See U.S. v. Easy Healthcare Corp., Case No. 1:23-cv-3107 (N.D. Ill. 2023), https://www.ftc.gov/ legal-library/browse/cases-proceedings/202-3186easy-healthcare-corporation-us-v; U.S. v. GoodRx Holdings, Inc., Case No. 23–cv–460 (N.D. Cal. 2023), https://www.ftc.gov/legal-library/browse/casesproceedings/2023090-goodrx-holdings-inc. E:\FR\FM\08FER2.SGM 08FER2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations lotter on DSK11XQN23PROD with RULES2 c. Patient Access API Metrics We proposed to require impacted payers to report metrics to CMS on an annual basis about how patients use the Patient Access API, in the form of aggregated, de-identified data. We stated that those reports would help CMS better understand whether the Patient Access API requirement is efficiently and effectively ensuring that patients have access to their health information and whether payers are providing that required information in a transparent and timely way. Additionally, we stated that aggregated usage data from every impacted payer would help us evaluate whether the Patient Access API policies are achieving the desired goals. We also stated that gathering this information would help us to provide targeted support or guidance to impacted payers, if needed, to help ensure that patients have access to their data and can use their data consistently across the impacted payer types. Specifically, we proposed that impacted payers annually report— • The total number of unique patients whose data are transferred via the Patient Access API to a health app designated by the patient; and • The total number of unique patients whose data are transferred more than once via the Patient Access API to a health app designated by the patient. Tracking multiple data transfers would indicate repeat access, showing that patients are either using multiple apps or allowing apps to update their information over the course of the year. While data transfers may not indicate to what extent patients are using apps to manage their health care, it would be a preliminary indicator of interest in the technology. Comment: A majority of commenters supported CMS’s proposal to require impacted payers to report aggregated, de-identified data metrics on how patients use the Patient Access API to CMS annually. Response: We thank commenters for their feedback. Comment: Commenters recommended that these metrics only be used to evaluate the effectiveness of CMS’s policies and to assess whether patients are using the Patient Access API in a volume sufficient to justify the administrative burden of existing and future requirements. A commenter stated that these metrics would not reflect factors within a payer’s control and recommended that CMS work with FTC to have third-party app developers directly report these metrics. Another commenter warned that these metrics may not account for patient preferences VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 for portals or other resources aside from apps. A commenter recommended that neither CMS nor state Medicaid agencies attempt to regulate or oversee the usage of third-party apps by their users. Another commenter supported the annual public reporting of Patient Access API metrics provided that this information is not made publicly available in a manner that identifies specific payers or apps. Response: We acknowledge that patient app usage is generally outside the control of payers, though education can help patients make informed decisions. We emphasize that we proposed and will be collecting these metrics, not to evaluate or compare payers, but to help us understand how patients are using apps, the effectiveness of our Patient Access API policies, and to assess potential future rulemaking. Making data available via a FHIR API gives patients a wider range of options to access their data. Ultimately, patients must decide what method of accessing their health information is most useful to them. If patients prefer to use online portals, rather than apps, that could inform future rulemaking. However, to understand how patients are accessing data made available through the API using a heath app designated by the patient, we must have access to the relevant data. We do not intend to interfere with how a patient uses a third-party app (and neither should impacted payers, including state Medicaid agencies), but to provide them options to access their data in the way that best suits them. As discussed previously, the only permissible reason to deny or discontinue an app’s access to an API is if the payer reasonably determines that the app presents an unacceptable level of risk to the security of PHI on the payer’s systems. We do not have the authority to require app developers to report usage metrics, and even if we did collect data from them, it would not provide the information that we are seeking, as developers would not know a patient’s health coverage status. For instance, a developer could tell us that an individual connected to a specific payer organization but would not be able to report whether the patient is covered under by an MA plan or QHP. Finally, as noted in the proposed rule, we do not intend to publicly publish these Patient Access metrics in a way that identifies specific payers or apps. Comment: A few commenters suggested that CMS establish an easy-touse standardized format for reporting Patient Access API metrics. PO 00000 Frm 00023 Fmt 4701 Sfmt 4700 8779 Response: We appreciate the request from commenters and are finalizing a modification to our proposed regulatory text to require reporting in a specified form and manner to ensure consistency between impacted payers. We will issue specific format and process guidance for submitting Patient Access API metrics before reporting is required. Comment: Most commenters supported CMS’s proposed metrics, as they could provide valuable information regarding Patient Access API adoption and use. Commenters voiced widespread support for the first metric to measure usage of the Patient Access API. Support for the second metric was mixed, with multiple commenters questioning its value to the API’s policy evaluation. Commenters warned that this metric would be affected by many external factors, including the user experience of the app, as opposed to acts of the payer. Another commenter stated that the second measure would not provide meaningful insight into patient use patterns, and instead suggested that CMS should solicit information about usage patterns from app developers. Response: We understand that the metric on repeat usage may not provide a high level of statistical validity, which is why we are not requiring these metrics to be reported publicly. However, it is important for CMS to understand how many patients are using the Patient Access API and whether they have simply tried it once or are invested in using health apps to manage their data. These findings will help us monitor our interoperability policies and plan for the future. We did not receive any comments that indicated that submitting either of these metrics would be a significant burden for impacted payers. We acknowledge that these metrics could be affected by a plethora of external factors outside of payers’ control. As noted previously, we are collecting these metrics to better enable us to evaluate our policies in this area. As we do not have regulatory authority over app developers, we did not propose to impose reporting requirements on them. Comment: A commenter requested that CMS explain what constitutes a ‘‘unique patient’’ so that payers can identify unique patients in the same manner, so the results are not varied. Response: We define a unique patient by the record of the individual covered by the payer’s benefits, not by the individual accessing the data. Therefore, if both a patient and their personal representative access their data, that will only be counted as usage by a E:\FR\FM\08FER2.SGM 08FER2 8780 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations lotter on DSK11XQN23PROD with RULES2 single patient for the purpose of these metrics. i. Reporting Level We proposed to require MA organizations to report these data to CMS at the organization level, state Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities to report at the state level, and QHP issuers on the FFEs to report at the issuer level. We solicited comment on whether we should require payers that administer multiple plans under a single contract to report these data to CMS at the contract level. We also solicited comment on an alternative final policy that would permit MA organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to report aggregate data at higher levels (such as the parent organization level or all plans of the same type in a program). Comment: We received comments espousing a range of opinions on the appropriate level of reporting for impacted payers. Specifically for MA organizations, multiple commenters recommended a more granular metric reporting level, noting that reporting Patient Access API metrics at the plan level would better drive plan-specific improvement efforts and be more consistent with current industry practice. Conversely, a commenter stated that organization level would simplify report preparation since some MA organizations have ten or more separate plan contracts with CMS. A commenter recommended that CMS not require reporting at the more granular contract level as any metrics based on small populations could lead to skewed data. Many commenters supported our proposed reporting levels for Patient Access API use metrics for state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs. On the other hand, a commenter recommended that payers be required to report metrics at the county level, rather than the state level. Another commenter warned that too much aggregation can make data meaningless and stated that payers should prioritize data metrics that can be acted upon effectively. Conversely, a commenter recommended that CMS allow consolidation of Patient Access API use metrics at the holding or parent company level, which would aggregate that company’s MA plans, Medicaid managed care plans, CHIP managed care entities, QHPs, and commercial plans. Another commenter suggested that CMS begin collecting VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 metrics at a more aggregated level and wait to implement more refined data segmentation as a clear use case arises. Response: Upon further consideration, we determined that contract level is the more appropriate reporting level for MA organizations. Contract-level data are aggregated data that are collected from the plan benefit packages (PBPs) offered under an individual contract; it is specific to the contract to which it corresponds. CMS already requires MA organizations to annually report some contract-level data about their organization determinations to the agency. A consistent approach of contract-level reporting in the MA program will give us useful information while limiting payer burden. By requiring contract-level reporting for these metrics, we ensure that the format of these reported data remain consistent with other data that MA organizations are required to report. There could be value to requiring MA organizations to report on a plan level in the future to get more discrete data. However, at this time, we believe that the burden of requiring MA organizations to report at the plan level, and the small sample sizes that some plans would have, outweigh the benefits of that information. We agree that requiring Medicaid managed care plans and CHIP managed care entities to report at the state level and QHP issuers on the FFEs to report at the issuer level balances the reporting burden and the meaningfulness of the data. Aggregating by holding company would provide data that are not particularly useful. Many commenters recommended that we use this information to monitor disparities in data access, which would be hindered without disaggregation between MA, Medicaid, CHIP, and QHPs. Similarly, we do not believe that additionally segmenting data into smaller geographic areas would provide useful information now, though in the future we may consider whether it would be beneficial. We note that CMS programs may assess whether to collect more detailed metrics than we are finalizing here. For instance, we may consider requiring in future rulemaking that MA plans report at a more discrete level. Similarly, should a state Medicaid or CHIP agency believe it would be beneficial, they may require additional metrics in their managed care contracts. Comment: A few commenters requested that we explain whether integrated care plans for dually eligible individuals, such as fully integrated dual eligible special needs plans (FIDE SNPs), should report consistent with MA organizations, at the contract level, PO 00000 Frm 00024 Fmt 4701 Sfmt 4700 or with Medicaid managed care plans, at the plan level. Response: An integrated care plan generally combines a dual eligible special needs plan (D–SNP), which includes FIDE SNPs and highly integrated dual eligible special needs plans (HIDE SNPs)—both as defined at 42 CFR 422.2, and a Medicaid managed care plan offered by the same parent organization. D–SNPs are a type of MA plan designed to meet the needs of individuals who are dually eligible for Medicare and Medicaid, also known as dually eligible individuals. Therefore, an MA organization will report information about Patient Access API usage by its D–SNP enrollees to CMS at the MA organization’s contract level. The affiliated Medicaid managed care plan will report information about Patient Access API usage by its enrollees to CMS at the plan level. We understand that this means an organization that offers an integrated product for dually eligible individuals (for example, a FIDE SNP), may report twice and in different ways for the same population. We do not believe this duplication outweighs the benefits of capturing the data as we proposed, but we may consider future rulemaking to separate reporting for integrated D– SNPs from the overall MA organization. ii. Annual Reporting We proposed that payers must report metrics from the previous calendar year to CMS by March 31st of each year. Under our proposal, in the first year the requirement would be applicable, payers would report CY 2025 data by March 31, 2026. A new MA organization, Medicaid managed care plan, CHIP managed care entity, or QHP issuer on the FFEs would naturally have no data to report in its first year of existence and would be required to report data following its first full calendar year subject to the Patient Access API requirement. Comment: Multiple commenters expressed support for CMS’s proposal to require payers to share patient use metrics annually starting with CY 2025 to be reported to CMS by March 31, 2026. Some commenters recommended that we delay the first year of the reporting requirement to CY 2026, which would be reported no later than March 31, 2027. Another commenter suggested that we delay the reporting deadline because a technical solution would need to be in place by the end of late 2024 to have metrics for CY 2025 to report in March 2026. Response: We note that per the CMS Interoperability and Patient Access final rule, impacted payers were required to E:\FR\FM\08FER2.SGM 08FER2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations lotter on DSK11XQN23PROD with RULES2 implement the Patient Access API no later than January 1, 2021. The metrics that we proposed were not tied to the implementation of any other proposals in the CMS Interoperability and Prior Authorization proposed rule, including adding prior authorization information to the data available via the Patient Access API. Based on this rule’s publication schedule, payers should have sufficient time to implement any necessary changes to report these metrics. Comment: A majority of commenters supported the proposed annual reporting requirement, though multiple commenters recommended that CMS consider requiring payers to report Patient Access API metrics quarterly. A commenter recommended that as the popularity for Patient Access API grows, use metrics should be reported on a quarterly basis. Commenters agreed that requiring payers to report data on API usage from the previous calendar year to CMS by March 31 provides an appropriate amount of time for payers to validate the data before submitting it to CMS. Response: After reviewing the comments, we agree that annual reporting is the appropriate frequency for these metrics. Given that we are looking to understand the overall usage of third-party apps and any patterns between payers, we do not believe that the burden of requiring payers to report these metrics quarterly would improve our understanding of whether patients are accessing the Patient Access API. We may in the future consider proposing more frequent reporting or additional metrics, but for the two metrics we are finalizing now, we do not expect that it would be beneficial to require payers to report more often than annually. iii. Public Reporting In the preamble to our proposed rule, we stated that we do not plan to publicly report these metrics at the state, plan, or issuer level, but may reference or publish aggregated and deidentified data that do not include names of specific state agencies, plans, or issuers. Comment: Some commenters recommended that CMS require payers to publicly report Patient Access API metrics, as they believe that health IT companies and developers would benefit from the information. Commenters stated that by making these metrics public, CMS can help patients and stakeholders better understand the impact of access APIs and help inform future innovations that promote patient access and future decision making. A VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 commenter recommended that CMS consider publicly reporting planreported information at the state, plan, or issuer level. Other commenters did not support CMS publicly reporting Patient Access API use metrics. Multiple commenters stated that this could provide inaccurate information and potentially reveal identifying information. A commenter cautioned that publicizing reports, particularly of the second proposed metric (the total number of patients whose data are transferred more than once to a specific third-party app), may give consumers an inaccurate portrayal of API success. Response: There may be value to publicly reporting aggregated and deidentified data to give the public a sense of Patient Access API adoption across the industry. But we agree with commenters that, absent the proper context, those data could be perceived inaccurately or misleadingly. As discussed, some commenters expressed that there is currently low health app adoption among patients regardless of the type of payer. We also understand that low patient adoption does not necessarily indicate a lack of payer readiness or compliance. Therefore, until we are confident that these data can be presented in an easy-tounderstand and meaningful way, we may publicly report aggregated and deidentified data, but will not include names of specific state agencies, plans, or issuers unless and until proposed through future rulemaking. iv. Other Metrics We requested comment on what other Patient Access API metrics we should consider requiring payers to report to CMS and/or make available to the public in future rulemaking. For instance, we solicited comments on whether payers could report aggregated demographic information, such as sex, race, age, ethnicity, and geographic data and whether that could help identify underserved populations or disparities in patient access to health data and, if so, policies that should be considered to promote equity. We also solicited comments on the potential benefits and burdens of requiring payers to report the names of all apps that patients have used to access the payers’ API each year. We considered collecting this information, or requiring payers to make it public, not for the purpose of recommending or endorsing specific apps, but to review for best practices and evaluate patient ease of use. Comment: Commenters provided many recommendations for additional Patient Access API metrics. PO 00000 Frm 00025 Fmt 4701 Sfmt 4700 8781 Response: We greatly appreciate the wide range of metric suggestions, such as indicators on demographic information, utilization, query management, successful requests, and barriers to accessing records. We will continue to research additional ways to evaluate the effectiveness of the API for consideration in future rulemaking. d. Patient Access API Amendments We proposed two minor terminology changes to the requirements finalized in the CMS Interoperability and Patient Access final rule (85 FR 25558). Unlike most of our proposals, we proposed that these amendments would take effect on the effective date of the final rule. We proposed these changes to explain terms but did not expect them to substantively change any current regulatory obligation. First, we proposed to revise the description of the clinical data impacted payers must make available via the Patient Access API. These provisions, finalized in the CMS Interoperability and Patient Access final rule, currently require payers to make available ‘‘clinical data, including laboratory results’’ (85 FR 25536–40). We proposed to revise these paragraphs to specify that the data that payers must make available are ‘‘all data classes and data elements included in a content standard at 45 CFR 170.213.’’ That citation is to a content standard maintained by ONC of clinical data classes and data elements for interoperable health information exchange. Referring explicitly in the rule text to a data set in a standard at 45 CFR 170.213 will help avoid unnecessary confusion, as this reference will more clearly identify exactly what data must be available through the Patient Access API. Furthermore, this change brings us into greater alignment with the standards promulgated by ONC and used by certified health IT developers. As versions of the USCDI evolve, there may simultaneously be multiple versions of the standard referenced at 45 CFR 170.213 (as both v1 and v3 are listed at the time of publication of this final rule). In the HTI–1 final rule, ONC finalized the adoption of USCDI v3 in 170.213 and finalized a January 1, 2026, expiration date for USCDI v1 (89 FR 1192). For the ONC Health IT Certification Program, this allows for a transition period between standards, and, during that time, health IT developers could incorporate updated standards versions within their systems and complete required certification. During such a period, when 45 CFR 170.213 includes more than one version of the USCDI standard, payers would be E:\FR\FM\08FER2.SGM 08FER2 8782 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations lotter on DSK11XQN23PROD with RULES2 allowed to use any of the thenreferenced content standards to meet the requirement to make clinical data available through the Patient Access API. If a standard has a listed expiration date (as USCDI v1 is currently listed to expire on January 1, 2026), payers would not be able to be use it after expiration. Second, we proposed to revise the language previously finalized for denial or discontinuation of a health app’s access to the API. Currently, the rules require impacted payers to make a determination to deny or discontinue access to the Patient Access API using objective, verifiable criteria that are applied fairly and consistently across all apps and developers through which ‘‘enrollees’’ or ‘‘beneficiaries’’ seek to access patient data. We proposed to change the terms ‘‘enrollees’’ and ‘‘beneficiaries’’ to ‘‘parties’’ for consistency with our proposal to apply this provision to the Provider Access, Payer-to-Payer, and Prior Authorization APIs. We stated that because parties other than patients, such as providers and payers, would be accessing these APIs, it would be more accurate to use the term ‘‘parties’’ rather than ‘‘enrollees’’ or ‘‘beneficiaries.’’ Those APIs are discussed further in sections II.B., II.C., and II.D. of this final rule. Comment: All comments we received on these technical language proposals supported our effort to keep the Patient Access API required data aligned with ONC’s standards. However, we did receive a variety of comments on the USCDI standard currently referenced at 45 CFR 170.213. Those comments are discussed in section II.G. of this final rule. A commenter requested clarification on whether payers would be required to request information from providers to fill any data classes and data elements of the standard at 45 CFR 170.213 that are missing within their records. Similarly, another commenter requested that CMS explain that the requirement to provide claims and encounter data within 1 business day applies only to information available at the time of the request. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 Response: In the CMS Interoperability and Patient Access final rule, we defined ‘‘maintain’’ to mean the payer has access to the data, control over the data, and authority to make the data available through the API (85 FR 25538). Under that existing regulation, payers are required to share data that they maintain as part of their normal operations. Nothing in this final rule will change that existing policy; payers are not required to reach out to providers or other entities to gather data that the payer does not already maintain, if it is not part of their normal operations, to share via the Patient Access API. We thank commenters for their feedback and are finalizing this proposal without modification. We note that we are not modifying the Patient Access API applicability date for MA at 42 CFR 422.119(h), for Medicaid FFS at 42 CFR 431.60(h), for CHIP FFS at 42 CFR 457.730(h), and for QHP issuers on the FFEs at 45 CFR 156.221(i) because these amendments do not substantively change any existing requirements finalized in the CMS Interoperability and Patient Access final rule. e. Medicaid Expansion CHIP Programs In the CMS Interoperability and Prior Authorization proposed rule, we discussed implementation for states with Medicaid Expansion CHIP programs (86 FR 76279). See section II.E. of this final rule for that complete discussion, including a summary of public comments received and our final action statement. f. Specific CHIP-Related Regulatory Framework For CHIP, we proposed amendments to 42 CFR 457.1233(d) that would align separate CHIP managed care API requirements with the Medicaid managed care plan API requirements, rather than with the CHIP FFS API requirements. In the CMS Interoperability and Patient Access final rule (85 FR 25559), we finalized requirements for separate CHIP managed care entities at 42 CFR 457.1233(d). API requirements for CHIP PO 00000 Frm 00026 Fmt 4701 Sfmt 4700 managed care entities were codified at 42 CFR 457.1233(d)(2) and (3) through cross-references to CHIP FFS program requirements at 42 CFR 457.730 and 457.760, respectively. On November 13, 2020, we published a final rule titled ‘‘Medicaid Program; Medicaid and Children’s Health Insurance Program (CHIP) Managed Care’’ (85 FR 72754). In that rule, we removed 42 CFR 457.1233(d)(1) through (3), and, at 42 CFR 457.1233(d), cross-referenced to Medicaid managed care regulatory requirements at 42 CFR 438.242. Therefore, the policies in the CMS Interoperability and Patient Access final rule (85 FR 25559) are applicable to separate CHIP managed care entities per 42 CFR 457.1233(d) through a cross reference to Medicaid managed care at 42 CFR 438.242. We apply the API requirements in this final rule to separate CHIP managed care entities through the existing cross reference at 42 CFR 457.1233(d) to Medicaid managed care at 42 CFR 438.242. 3. Other Requests for Comment We requested comment on a variety of topics on which we did not make specific proposals but are reviewing for future consideration. We appreciate commenters’ submissions regarding the following: • How we could and should apply these requirements to Medicare FFS and its existing prior authorization requirements and standards. • What policy levers we might have to create norms or best practices for privacy policies by health app developers. • How we could leverage ONC’s TEFCA or other HHS HIE initiatives to facilitate secure interoperable data exchange with health apps. • The availability of apps that are accessible to individuals with disabilities, availability of apps in a multitude of languages to ensure that individuals with limited English proficiency can understand the information provided, and availability of apps at appropriate literacy levels and in plain language. BILLING CODE 4150–28–P E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 VerDate Sep<11>2014 Jkt 262001 11.A.2.a. I PO 00000 Frm 00027 11.A.2.a. Fmt 4701 11.A.2.c. I I Sfmt 4700 E:\FR\FM\08FER2.SGM 11.A.2.d. 08FER2 11.A.2.d. I Adding Prior Authorization Information (Compliance date Janua 1, 2027 Time-frame for Prior Authorization Information Availability (Compliance date January 1, 2027 Reporting Patient Access API Metrics (Compliance date January 1, 2026) Revisions to the Scope of Clinical Data to be Made Available via the Patient Access API (Effective Date of the Final Rule Patient Access API Denial/ Discontinuation of Access (Effective Date of the Final Rule 42CFR 422.l 19(b) (l)(iv)(A) 42CFR 43 l .60(b)(5)(i) 42CFR 422. l 19(b)(1 )(iv) (B) 42CFR 431.60(b )(5)(ii) 42CFR 422.l 19(f) 42CFR 431.60(f) 42CFR 422.119(b )(1 )(iii) 42CFR 431.60(b )(3) 42CFR 422.l 19(e)(2) 42CFR 431.60(e)(2) Through cross reference to 42 CFR 431.60 at 42CFR 438.242 5 Through cross reference to 42 CFR 431.60 at 42CFR 438.242(b )(5) 1 1 Through cross reference to 431.60 at 42 CFR 438.242(b )(5)(iii) Through cross reference to 42 CFR 431.60 at 42CFR 438.242(b)(5) Through cross reference to 42 CFR 431.60 at 42CFR 438.242(b)(5) 42 CFR 457.730(b)(5)(i) 42 CFR 457 .730(b)(5)(ii) I 1 I 1 Through existing cross reference to 42 CFR 438.242 at existing 42 CFR 457.1233(d) 42CFR 457.730(b)(3) 42 CFR 457.730(e)(2) 45 CFR 156.22l(b)(1 )(iv)(B) I 45 CFR 156.221(f) 42CFR 457.730(f) 1 45 CFR 156.22l(b)(l)(iv)(A) 1 1 I 45 CFR 156.22 l(b )(1 )(iii) 45 CFR 156.22l(e)(2) Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations 18:23 Feb 07, 2024 TABLE Bl: PATIENT ACCESS APPLICATION PROGRAMMING INTERFACE FINAL POLICIES 8783 ER08FE24.000</GPH> 8784 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations BILLING CODE 4150–28–C lotter on DSK11XQN23PROD with RULES2 4. Final Action After considering the comments received, and for the reasons discussed in the CMS Interoperability and Prior Authorization proposed rule and our response to those comments (as summarized previously), we are finalizing our proposals with the following modifications: • Impacted payers must make information about prior authorization requests and decisions available via the Patient Access API beginning 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs), rather than in 2026. • Impacted payers are not required to share the quantity of items or services used under a prior authorization via the Patient Access API. • Impacted payers are not required to share unstructured documentation related to prior authorizations via the Patient Access API. • MA organizations must report Patient Access API metrics at the contract level rather than at the proposed organizational level. See further discussion for exact details of the final requirements for impacted payers. Specifically, we are finalizing a requirement that, beginning 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs), impacted payers must make the all of following information available about prior authorization requests and decisions (excluding for drugs) available via the Patient Access API: • The prior authorization status. • The date the prior authorization was approved or denied. • The date or circumstance under which the prior authorization ends. • The items and services approved. • If denied, a specific reason why the request was denied. • Related structured administrative and clinical documentation submitted by a provider. We are finalizing the requirement that impacted payers make this information about prior authorizations available no later than 1 business day after the payer VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 receives a prior authorization request and must update that information no later than 1 business day after any status change. This information must be available for the duration that the authorization is active and at least 1 year after the prior authorization’s last status change. We are finalizing a requirement that, beginning 2026, impacted payers must annually report Patient Access API metrics to CMS in the form of aggregated, de-identified data. Specifically, by March 31, MA organizations at the contract level, state Medicaid and CHIP FFS programs, Medicaid managed care plans and CHIP managed care entities at the state level, and QHP issuers on the FFEs at the issuer level must report the following metrics: (1) the total number of unique patients whose data are transferred via the Patient Access API to a health app designated by the patient; and (2) the total number of unique patients whose data are transferred more than once via the Patient Access API to a health app designated by the patient. Impacted payers must report the previous calendar year’s metrics to CMS by March 31 following any year that they offered that type of plan. We are finalizing, as of the effective date of this final rule, the replacement of ‘‘clinical data, including laboratory results’’ with ‘‘all data classes and data elements included in a content standard at 45 CFR 170.213’’ in the required content for the Patient Access API. We are also finalizing, as of the effective date of this final rule, to change the terms ‘‘enrollees’’ and ‘‘beneficiaries’’ to ‘‘parties’’ at 42 CFR 422.119, 431.60, and 438.62 and 45 CFR 156.221. These final policies apply to MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs at the CFR sections listed in Table B1. 5. Statutory Authorities for the Patient Access API Policies We note that we received no public comments on the statutory authorities for our Patient Access API policies. a. MA Organizations For MA organizations, we proposed these new requirements and the revisions to current requirements under our authority at sections 1856(b)(1) of the Act (to promulgate regulations implementing MA organization standards, including the requirements in section 1852(h) of the Act), and 1857(e)(1) of the Act (to add contract terms determined by the Secretary to be ‘‘necessary and appropriate’’). Section PO 00000 Frm 00028 Fmt 4701 Sfmt 4700 1856(b)(1) of the Act requires the Secretary to establish regulatory standards for MA organizations that are consistent with and carry out Part C of the Medicare statute, Title XVIII of the Act. Section 1852(h) of the Act requires that MA organizations have procedures in place to maintain accurate and timely medical records and health information regarding MA enrollees and to assure enrollees have timely access to such records and information. Our policy for the Patient Access API is to require access for enrollees to specified medical records and health information through a specific mechanism from the MA organization. The Secretary is authorized under section 1857(e)(1) of the Act to add new contract terms, including additional standards and requirements, for MA organizations that the Secretary finds necessary and appropriate and that are not inconsistent with Part C of the Medicare statute. The policies here meet this standard by addressing and facilitating access to enrollees’ medical records and health information for the reasons identified in our discussions for each policy. The policy in section II.A.2.a. of this final rule that will require MA organizations to make an enrollee’s prior authorization requests and related clinical documentation available through the Patient Access API will allow these enrollees to have access to that information in a convenient, timely, secure, and portable way, which is in enrollees’ best interests. This requirement is consistent with section 1852(h) of the Act, which requires MA organizations to assure enrollees timely access to their records and data that is maintained by MA organizations. To ensure that MA organizations meet modern-day patient expectations of transparency, efficiency, and timeliness when providing prior authorization data to enrollees, it is essential for CMS to ensure that each MA organization has a standardized system in place that offers enrollees access to their own data, including data that pertain to their prior authorizations, using existing and emerging technologies of their choice, specifically in this case, health apps. Therefore, making these data available through the Patient Access API is consistent with our programmatic authority to establish standards to implement section 1852(h) of the Act and could help patients be more informed about and active in their own care, which could potentially lead to better health outcomes. Making this information available via the Patient Access API could help patients support the prior authorization E:\FR\FM\08FER2.SGM 08FER2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations lotter on DSK11XQN23PROD with RULES2 process as well. Patients could see what information is needed and what information has been provided on their behalf to facilitate a prior authorization request. Patients could provide missing information needed by the payer to reach a decision. This could allow MA organizations to address prior authorization requests more promptly, streamlining this process, and thus simplifying prior authorization for the MA organizations. This could also improve an enrollee’s experience with the process, by facilitating more timely and potentially more successful initial prior authorization requests. This, again, supports efficient operation and timely provision of information and services. In addition, to ensure the requirements finalized in the CMS Interoperability and Patient Access final rule (85 FR 25558 through 25559) would be most effective, CMS finalized in this rule that MA organizations report specific metrics to CMS on patient use of the Patient Access API. Section 1857(e)(1) of the Act explicitly authorizes the adoption of additional reporting to CMS by MA organizations where necessary and appropriate. Here, these metrics would facilitate CMS’s oversight, evaluation, and administration of patient health data access in the Part C program and, therefore, this data collection is necessary and appropriate to adopt. In alignment with HHS’s priorities and goals, CMS is focused on putting patients at the center of their own health care and ensuring that patients have secure access to their health information. We believe these policies are critical and appropriate to ensure that MA organizations stay abreast of industry standards and continue to offer enrollees not only quality coverage but also a quality customer experience. b. Medicaid and CHIP Our finalized requirements in this section for Medicaid managed care plans and Medicaid state agencies fall generally under our authority in sections 1902(a)(4), 1902(a)(7), 1902(a)(8), and 1902(a)(19) of the Act. Section 1902(a)(4) of the Act requires that a state Medicaid plan provide such methods of administration as are found by the Secretary to be necessary for the proper and efficient operation of the state Medicaid plan. Section 1902(a)(8) of the Act requires states to ensure that Medicaid services are furnished with reasonable promptness to all eligible individuals. Section 1902(a)(19) of the Act requires states to ensure that care and services under a Medicaid state plan are provided in a manner consistent with simplicity of VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 administration and the best interests of the recipients. In addition, section 1902(a)(7) of the Act requires that states must provide safeguards that restrict the use or disclosure of information concerning Medicaid applicants and beneficiaries to purposes that are directly connected with the administration of the Medicaid state plan. The implementing regulations at 42 CFR part 431, subpart F, for section 1902(a)(7) of the Act list purposes that CMS has determined are directly connected with administration of Medicaid state plans (42 CFR 431.302) and require states to provide safeguards meeting certain requirements to restrict uses and disclosures of Medicaid beneficiary data, including requirements about releasing applicant and beneficiary information at 42 CFR 431.306. Our policy to require that the prior authorization data described in this section be shared via the Patient Access API would be consistent with the requirement at section 1902(a)(7) of the Act, providing that states may share these data only for purposes directly connected with the administration of the Medicaid state plan. The data sharing policy for the Patient Access API would be related to providing services for Medicaid beneficiaries, a purpose listed at 42 CFR 431.302(c). As mentioned previously, giving a patient access to their own health information can make them a more active participant in ensuring they receive timely and appropriate care (for example, allowing them to monitor medications or access treatment history). The finalized requirement to make information about prior authorization requests and associated documentation available through the Patient Access API is expected to allow beneficiaries to more easily obtain information about the status of prior authorization requests submitted on their behalf. Beneficiaries could potentially use that information to make more informed decisions about their health care, improve the efficiency of accessing and scheduling services, and, if needed, provide missing information that the state (or Medicaid managed care plan, if applicable) needs to reach a decision. Receiving missing information more quickly could enable more prompt responses from state Medicaid FFS programs and Medicaid managed care plans to prior authorization requests, thus facilitating more timely and successful prior authorizations. This would help states fulfill their obligations to provide care and services in a manner consistent with simplicity of administration and the best interests of the recipients and PO 00000 Frm 00029 Fmt 4701 Sfmt 4700 8785 to furnish services with reasonable promptness to all eligible individuals. Improving the prior authorization process could also help improve the efficient operation of the state plan by potentially improving the speed and consistency of prior authorizations, which could, in turn, facilitate faster access to care for beneficiaries. In these ways, these policies are authorized under section 1902(a)(4), (8), and (19) of the Act. Additionally, states must apply the safeguards described at 42 CFR 431.306 when sharing beneficiary data via the Patient Access API. We remind states that to meet the requirements of that regulation, states must have consistent criteria for release and use of information (which should comply with the finalized Patient Access API requirements), in accordance with 42 CFR 431.306(a). Access to information concerning beneficiaries must be restricted to persons who are subject to standards of confidentiality that are comparable to that of the state Medicaid agency, in accordance with 42 CFR 431.306(b). The permission requirement at 42 CFR 431.306(d), which requires that the state agency obtain permission from a family or individual, whenever possible, before responding to a request for information from an outside source, is not relevant to this policy, because any request for beneficiary information would be from Medicaid beneficiaries themselves and the apps that they are authorizing to receive their information. Beneficiaries are not ‘‘outside sources,’’ and, while apps might be outside sources, information is shared with an app through this API only if the beneficiary has verified their identity (through authentication protocols) and authorized the app to receive information. We do not believe that any of the other requirements at 42 CFR 431.306 are relevant because they cover data release and use in contexts outside of our policies in this section of the final rule. We note that while the beneficiary’s permission is not required under 42 CFR 431.306(d) for the Patient Access API we discuss here, state or other laws may require such permission. With respect to Medicaid managed care, and in addition to the general authorities cited previously mentioned regarding Medicaid programs, this policy will also help implement section 1932(b)(4) of the Act, which provides that each Medicaid MCO must establish an internal grievance procedure under which a beneficiary who is eligible for medical assistance may challenge the denial of coverage or payment for such assistance. CMS has traditionally extended requirements applicable to E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8786 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations Medicaid MCOs to other Medicaid managed care plan types as efficient and proper methods of administration under section 1902(a)(4) of the Act to ensure that Medicaid beneficiaries have the same protections, benefits, and responsibilities regardless of the type of managed care plan in which they are enrolled. Allowing beneficiaries to access the status of their denied prior authorizations within 1 business day could enable beneficiaries to file appeals timelier and receive faster resolution. Enabling beneficiaries to monitor the status of prior authorization requests submitted on their behalf is also consistent with how section 1932(c) of the Act indicates that timely access to care should be assured for beneficiaries. Knowing within 1 business day that a prior authorization has been approved could enable a beneficiary to more promptly schedule or obtain care. We also proposed to require state Medicaid agencies and Medicaid managed care plans to report Patient Access API metrics to CMS annually. These metrics will support CMS’s oversight, evaluation, and administration of the Medicaid program, as it will allow us to evaluate beneficiary access to the Patient Access API. API usage could indicate that the policy is supporting program efficiencies and ensuring access to information in a timely and efficient way and in the best interest of beneficiaries, as intended, and as is consistent with section 1902(a)(4) and (19) of the Act. Additionally, section 1902(a)(6) of the Act requires Medicaid state plans to provide that the state Medicaid agency will make such reports, in such form and containing such information, as the Secretary may from time to time require. These metrics will serve as a report to evaluate the implementation and execution of the Patient Access API. For CHIP, we finalized these requirements under the authority in section 2101(a) of the Act, which states that the purpose of Title XXI of the Act is to provide funds to states to provide child health assistance to uninsured, low-income children in an effective and efficient manner that is coordinated with other sources of health benefits coverage. This provision provides us with authority to adopt these requirements for CHIP because the finalized requirements increase patient access to their health information, which can improve the efficacy of CHIP programs, allow for more efficient communication and administration of services, and promote coordination VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 across various sources of health benefits coverage. We believe that requiring CHIP agencies, as well CHIP managed care entities, to make CHIP beneficiaries’ prior authorization data and other standardized data available through standards-based APIs will lead to these beneficiaries accessing that information in a convenient, timely, and portable way. This improved access will help to ensure that services are effectively and efficiently administered in the best interests of beneficiaries, consistent with the requirements in section 2101(a) of the Act. We believe making patient data available in this format will result in better health outcomes and patient satisfaction and improve the cost effectiveness of the entire health care system, including CHIP. These policies align with section 2101(a) of the Act in that they also will improve the efficiency of CHIP programs. For example, adding information about prior authorization requests to the Patient Access API will allow beneficiaries to easily obtain the status of prior authorization requests made on their behalf. This will in turn allow patients to make scheduling decisions and provide any missing information needed by a payer to reach a decision, which makes the prior authorization process more efficient, streamlining the prior authorization process. Additionally, the safeguards for applicant and beneficiary information at 42 CFR part 431, subpart F, are also applicable to CHIP through a crossreference at 42 CFR 457.1110(b). As discussed previously for Medicaid, giving CHIP beneficiaries access to their prior authorization statuses through the Patient Access API would be related to providing services to beneficiaries, which is described at 42 CFR 431.302(c) as a purpose directly related to state plan administration. Allowing beneficiary access to prior authorization statuses also conforms with provisions for beneficiary access to their records at 42 CFR 457.1110(e). We remind states that when they share beneficiary information through the Patient Access API, they must comply with the privacy protections at 42 CFR 457.1110 and the release of information provisions at 42 CFR 431.306. Finally, by finalizing the requirement for state CHIP agencies and CHIP managed care entities to report Patient Access API metrics to CMS annually will help states and CMS understand how this API can be used to continuously improve the effectiveness and efficiency of state CHIP operations by providing information about its use, PO 00000 Frm 00030 Fmt 4701 Sfmt 4700 which is an indication of the API’s uptake among patients, including how many only use it for a one-time setup consistent with 2107(b)(1) of the Act. The more we understand about the Patient Access API’s usage, the better we can assess that the API is leading to improved operational efficiencies and providing information to beneficiaries in a way that supports their best interests. c. Qualified Health Plan Issuers on the Federally-Facilitated Exchanges For QHP issuers on the FFEs, we finalized these new requirements under our authority at section 1311(e)(1)(B) of the Patient Protection and Affordable Care Act, as amended by the Health Care and Education Reconciliation Act of 2010 (Pub. L. 111–148, enacted March 23, 2010, and Pub. L. 111–152, enacted March 30, 2010, respectively) (collectively referred to as the Affordable Care Act) which affords the Exchanges the discretion to certify QHPs if the Exchange determines that making available such health plans through the Exchange is in the interests of qualified individuals in the state in which the Exchange operates. We believe generally that certifying only health plans that take steps to make enrollees’ prior authorization requests and related clinical documentation available through interoperable technology would ultimately lead to these enrollees having access to that information in a convenient, timely, and portable way, which is in enrollees’ best interests. Adding information about prior authorization requests to the Patient Access API would allow enrollees to easily obtain the status of prior authorization requests submitted on their behalf and use that information effectively to make more informed decisions about their health care, improve the efficiency of accessing and scheduling services, and, if needed, provide missing information needed by the issuer to reach a decision. This could allow QHP issuers on the FFEs to more promptly address prior authorization requests and would also facilitate more timely and potentially more successful initial prior authorization requests. We encourage SBEs (including SBE–FPs) to consider whether a similar requirement should be applicable to QHP issuers on SBEs. Finally, requiring QHP issuers on the FFEs to report Patient Access API metrics to CMS annually will help CMS assess the effect this API is having on enrollees and will inform how CMS could either enhance the policy or improve access or use through activities E:\FR\FM\08FER2.SGM 08FER2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations such as additional patient education. These data could help CMS understand how best to leverage this API, and patient access to it, and to ensure this requirement is being met efficiently and adding value to CMS operations, including leading to the intended efficiencies. lotter on DSK11XQN23PROD with RULES2 B. Provider Access API 1. Background In the CMS Interoperability and Patient Access final rule, we required impacted payers to implement a Patient Access API (85 FR 25558) that allows patients to access their health information through a third-party app. Patients who do so could then share their information with their provider during an appointment. For example, during a visit with a provider, a patient could share specific diagnoses, procedures, and tests accessed through the Patient Access API, to inform the discussion with their provider. In the CMS Interoperability and Patient Access proposed rule (84 FR 7610), we had sought comment on the feasibility of implementing and maintaining a FHIR API for data exchange between payers and providers and received comments strongly supporting our concept to require data availability through a Provider Access API. Some commenters stated that allowing providers to receive data, including prior authorization information, directly from payers, would make FHIR-based data exchange significantly more valuable for patients, providers, and payers. More data could be available to help providers manage a patient’s care and providers could reduce or eliminate duplicate tests. Payers might also see fewer duplicate requests for services, fewer appeals and, possibly, lower costs. In the final rule, we specifically agreed with commenters that making available information about prior authorization decisions via an API would reduce burden on providers and their staff (85 FR 25541). We also discussed the potential benefits of payers sharing patient health information directly with providers (85 FR 25555) and encouraged payers to consider an API solution that would enable direct provider access to appropriate health information to support the delivery of care. While the Patient Access API was a significant first step toward sharing individual patient health information with providers, we believe it would benefit patients if payers were required to make patient data directly available to providers via a FHIR API. In the normal course of business, many VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 providers already maintain EHRs and share data for a variety of purposes authorized by the patient and/or existing law. Therefore, in the CMS Interoperability and Prior Authorization proposed rule, we proposed to require impacted payers to implement and maintain a FHIR API that makes patient data available to providers who have a contractual relationship with the payer and a treatment relationship with the patient. The Provider Access API has the potential to allow payers to build upon their existing systems and processes to enhance access to patient data, while continuing to protect patient privacy and data security. We also proposed a patient opt out (rather than an opt in) policy that would require payers to allow patients to opt out of the Provider Access API. Finally, we proposed Provider Access API compliance dates in 2026 (by January 1, 2026, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2026, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2026, for QHP issuers on the FFEs). As mentioned in section I.A. of this final rule, these policies do not pertain to Medicare FFS. In the proposed rule, we solicited comment on whether our Provider Access API proposal could be implemented in the Medicare FFS program. We expect that a Medicare FFS implementation would generally conform to the same requirements that apply to the impacted payers under this final rule, so Medicare FFS providers and beneficiaries enrolled in Medicare FFS could also benefit from this type of data sharing. We solicited comment on whether these requirements could be implemented as proposed, how we could apply each of these proposals, and if there would be any differences implementing the Provider Access API for the Medicare FFS program as a Federal payer. CMS’s Data at the Point of Care (DPC) project is currently piloting an API that makes Medicare FFS claims and Part D data available to certain providers. However, some differences exist for Medicare FFS. For instance, provider remittances and patient cost-sharing information are not proprietary, so those data are shared in the DPC pilot; however, we proposed that impacted payers would not be required to share that information under our policies. Because the DPC API currently enables provider access to patient data and involves processes like authenticating the provider and verifying a patient treatment relationship with an attribution process, PO 00000 Frm 00031 Fmt 4701 Sfmt 4700 8787 the information gained from the DPC pilot will be useful to impacted payers as we finalize proposals in this rule. 2. Requirements for Payers: Provider Access API for Individual Patient Information In the CMS Interoperability and Patient Access final rule (85 FR 25558), we required impacted payers to make certain health information available through a Patient Access API when requested by a patient. We stated that it would be valuable for providers to have access to the same patient data, except for provider remittances and patient cost-sharing information, through a FHIR API that allows a provider to request data for an individual patient, as needed, thereby providing them with further insight into the patient’s health care. Research shows that patients achieve better outcomes when their record is more complete, and more data are available to the health care provider at the point of care.26 Making more comprehensive information available to providers could thus improve the care experience for patients. Ensuring that providers have access to relevant patient data at the point of care could also reduce the burden on patients to recall and relay information during an appointment and/or provide confirmation that the patient’s recollection of prior care is accurate. Therefore, we proposed to require impacted payers to implement and maintain a Provider Access API to make current patients’ information available to in-network or enrolled (as applicable) providers, at the provider’s request. Under our proposal, an in-network provider is any provider or health care facility that is part of a specific health plan’s network of providers with which it has a contract to furnish covered items or services. In the case of state Medicaid and CHIP FFS programs, that means any providers or health care facilities that are enrolled with the state as Medicaid or CHIP providers. We noted that this requirement would only apply to current patients. Once a patient is no longer enrolled with a payer, the payer would not need to share data with providers under our proposed policy. We explained that the Provider Access API would allow a provider to initiate a request when the provider needs access to a patient’s data, such as prior to or during a patient visit. Both the Provider Access and Patient Access 26 Office of the National Coordinator for Health Information Technology (ONC) (2019, June 4). Improved Diagnostics & Patient Outcomes. Retrieved from https://www.healthit.gov/topic/ health-it-basics/improved-diagnostics-patientoutcomes. E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8788 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations APIs would facilitate the FHIR-based exchange of claims and encounter data, all data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI), and certain information about prior authorizations maintained by the payer. We also stated that we believed that sharing claims and encounter data (without provider remittances and patient cost-sharing information) would complement the data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI) by providing more information to support treatment and care coordination. Claims and encounter data, used in conjunction with clinical and other available data, can offer a broader, more complete picture of an individual’s interactions with all their providers in the health care system. With that proposal, we intended to help providers gain efficient access to more comprehensive data on their patients. Specifically, we proposed to require impacted payers to make available any of the applicable patient data with a date of service on or after January 1, 2016, that they maintain. This timeframe for data to be included is consistent with the requirements of the Patient Access API, as finalized in the CMS Interoperability and Patient Access final rule (85 FR 25567), so payers should already be maintaining and making available the same set of data from this timeframe via a FHIR API. Finally, we explained that, unlike the Patient Access API, the Provider Access API would not include provider remittances and patient cost-sharing information. Many payers consider costsharing information proprietary and, while we do not necessarily agree with such a characterization, we believed that information would have limited benefit for treatment or care coordination and thus excluded it from the scope of data required to be accessible through the Provider Access API. We proposed that payers would be required to make available via the Patient Access and Provider Access APIs information related to prior authorization requests and decisions for items and services (excluding drugs). This information would include, as applicable: • The prior authorization status. • The date the prior authorization was approved or denied. • The date or circumstance under which the prior authorization ends. • The items and services approved; • If denied, a specific reason why the request was denied. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 • Related structured administrative and clinical documentation submitted by a provider. We proposed that information about prior authorizations be available via the Patient Access API for as long as the authorization is active, and for at least 1 year after the last status change, and that this would apply to the Provider Access API, as well. We noted in the proposed rule that this provision would be particularly relevant to denied and expired prior authorizations, to ensure that they would be available for at least a year after expiring or being denied. We did not propose to require payers to share a patient’s full prior authorization history, because that could comprise a significant amount of information that may no longer be clinically relevant. In general, our proposal for the data that payers would have to make available through the Provider Access API, as well as the technical specifications, aligned with the requirements for the Patient Access API finalized in the CMS Interoperability and Patient Access final rule (85 FR 25558) and those that were proposed for the Patient Access API in the CMS Interoperability and Prior Authorization proposed rule (87 FR 76238). However, we further explained that there are a few notable differences between the requirements for a Patient Access API and those for a Provider Access API. The biggest difference is how and why the end user will access the data. For the Patient Access API, the patient is requesting access to their own data through a health app for their own reference and use, and potentially to share the data with a provider. For the Provider Access API, we expect that a provider will request and receive access to the patient’s information through their EHR, practice management system, or other technology for treatment purposes. Providers will securely access their patients’ data through a FHIR API using at least one of these systems. Providers will not access patient data through their own health app; rather, the data will flow from the payer to the provider’s EHR or practice management system, which will allow them to incorporate the patient data into their records, should they choose to do so. For example, a provider who is preparing for an upcoming appointment may need more information about the patient than is contained in the patient’s record in their own systems. Under this proposal, the provider would be able to request the additional data from the patient’s payer. The payer would then be required to share the requested data no later than 1 business day after receiving a request from a provider who PO 00000 Frm 00032 Fmt 4701 Sfmt 4700 meets all other requirements to access the data. In the CMS Interoperability and Patient Access final rule we required standards for the Patient Access API by cross reference to 45 CFR 170.215 (85 FR 25558). We proposed to require certain standards at 45 CFR 170.215 that are applicable to the Provider Access API. We are finalizing our proposals for the Provider Access API with modifications, requiring impacted payers to use the following standards: HL7 FHIR Release 4.0.1 at 45 CFR 170.215(a)(1), US Core IG STU 3.1.1 at 45 CFR 170.215(b)(1)(i), SMART App Launch IG Release 1.0.0 at 45 CFR 170.215(c)(1), and Bulk Data Access IG v1.0.0: STU 1 at 45 CFR 170.215(d)(1). We are also recommending payers use the CARIN IG for Blue Button STU 2.0.0, PDex IG STU 2.0.0, and SMART App Launch IG Release 2.0.0 to support Backend Services Authorization. We proposed but are not finalizing to require impacted payers to use OpenID Connect Core for reasons discussed later in this section. We refer readers to Table H3 for a full list of the required standards and recommended IGs to support API implementation. We refer readers to section II.G. of this final rule for further discussion of the required and recommended technical standards for the Provider Access API. For Medicaid and CHIP managed care, we proposed that NEMT PAHPs, as defined at 42 CFR 438.9(a) and 457.1206(a) respectively, would not be subject to the requirement to establish a Provider Access API. As proposed at 42 CFR 438.242(b)(7) and by crossreference at 42 CFR 457.1233(d), all other Medicaid managed care plans and CHIP managed care entities (that is, MCOs, PIHPs, and non-NEMT PAHPs) would be subject to this final rule. We stated our belief that the unique nature and limited scope of the services provided by NEMT PAHPs, which only cover transportation and not medical care itself, justified their exclusion from the requirements of the Provider Access API. Specifically, we did not believe that providers have routine need for NEMT data; therefore, requiring NEMT PAHPs to implement and maintain a Provider Access API (and a Payer-toPayer API, as discussed in section II.C.3. of this final rule) would be an undue burden. However, we did propose that NEMT PAHPs be subject to the requirements for the Patient Access API, Prior Authorization API, and prior authorization processes. We acknowledged that it could be helpful for all providers to have access to their patients’ data regardless of contractual or enrollment relationships E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations with a patient’s payer. However, we proposed to only require impacted payers to share data with in-network or enrolled providers. We recognized that this could make it more difficult for an out-of-network provider to create or access a more comprehensive care record for a patient. We considered requiring payers to make the data available to all providers, regardless of whether the provider is under contract or enrolled with the payer. We will continue to consider a requirement to share patient data with out-of-network providers for future rulemaking. To this end, we requested comment in the proposed rule on existing processes for sharing data with out-of-network providers. Though we did not propose to require it, we encouraged payers to share information via API with out-ofnetwork or unenrolled providers to the extent permitted by law if they can verify a treatment relationship. For state Medicaid and CHIP FFS programs specifically, data sharing with out-ofnetwork and unenrolled providers would need to comply with Medicaid confidentiality rules as required by section 1902(a)(7) of the Act and implemented in our regulations at 42 CFR part 431, subpart F. We are finalizing our proposal to require impacted payers to make available to providers, via the Provider Access API, claims and encounter data (without provider remittances and patient cost-sharing information), all data classes and data elements included in a content standard at 45 CFR 170.213, and certain information about prior authorizations (excluding those for drugs). However, as with the Patient Access API policies, we are finalizing a modification to our proposal and not requiring payers to share the quantity of items or services used under a prior authorization or unstructured documentation related to a prior authorization. We are finalizing these changes to the Provider Access API policy with compliance dates in 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs), which is a year after the proposed 2026 compliance dates. Throughout this rule, we generally refer to these compliance dates as ‘‘in 2027’’ for the various payers. To support the Provider Access API implementation and maintenance, we are requiring certain standards and recommending certain IGs, as further VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 discussed later and in section II.G. of this final rule. With the publication of the HTI–1 final rule, our cross references to 45 CFR 170.215 have been updated to reflect the updated citations as needed. Changes to the structure of 45 CFR 170.215 and versions of the API standards codified there, are discussed further in section II.G. and reflected throughout this final rule. For the Provider Access API, impacted payers must use the following standards: HL7 FHIR Release 4.0.1 at 45 CFR 170.215(a)(1), US Core IG STU 3.1.1 at 45 CFR 170.215(b)(1)(i), SMART App Launch IG Release 1.0.0 at 45 CFR 170.215(c)(1), and Bulk Data Access IG v1.0.0: STU 1 at 45 CFR 170.215(d)(1). Impacted payers are permitted to use updated standards, specifications, or IGs that are not yet adopted in regulation for the APIs required in this final rule, should certain conditions be met. For the standards at 45 CFR 170.215, updated versions available for use under our policy include, but are not limited to, US Core IG STU 6.1.0, the SMART App Launch IG Release 2.0.0, and the Bulk Data Access IG v2.0.0: STU 2, which have been approved for the ONC Health IT Certification Program.27 We refer readers to section II.G.2.c. of this final rule for a full discussion on using updated standards. We also recommend payers use the CARIN IG for Blue Button STU 2.0.0, PDex IG STU 2.0.0, and SMART App Launch IG Release 2.0.0 to support Backend Services Authorization. We refer readers to Table H3 for a full list of the required standards and recommended IGs to support API implementation. a. General Comments Comment: Multiple commenters supported CMS’s proposal to require impacted payers to develop and maintain a Provider Access API and recommended that CMS finalize the proposal. Multiple commenters also noted that the API would give health care providers invaluable insights into patient care, which could lead to better quality care, reduce duplicate services, and streamline provider workflows. A commenter recommended that CMS focus its efforts on the secure exchange of data from patients to providers via the Patient Access API, which could allow the patient to be an intermediary who can choose which payer data to share with the provider. Response: We agree with commenter sentiments about the various benefits to 27 Office of the National Coordinator for Health Information Technology (ONC) (2023, September 11). Standards Version Advancement Process (SVAP). Retrieved from https://www.healthit.gov/ topic/standards-version-advancement-process-svap. PO 00000 Frm 00033 Fmt 4701 Sfmt 4700 8789 both providers and patients of providers having improved and direct access to patient data. As explained throughout this final rule, the requirements and standards for the Provider Access API will largely align with those currently in place and that we are finalizing for the Patient Access API. We anticipate that this alignment will provide consistency and help payers build on the work done to comply with the requirements for the Patient Access API. Enabling improved data sharing directly with providers, who have the clinical expertise to effectively use the data to improve patient care, is a logical next step for our API implementation requirements. b. Compliance Dates Comment: Multiple commenters supported the proposed 2026 compliance dates for the Provider Access API, as the appropriate time when the IGs will be sufficiently mature. Other commenters supported earlier compliance dates for the Provider Access API, including dates in calendar years 2024 and 2025. By contrast, multiple other commenters requested that CMS delay the implementation of the Provider Access API. Many recommended the compliance dates for the Provider Access API be at least 3 years after the issuance of the final rule to allow for provider and payer collaboration. Commenters stated this would allow payers and providers to stagger the separate implementation of the HIPAA Standards for Health Care Attachment proposed rule (87 FR 78438). A commenter stated that delaying the implementation of the Provider Access API requirement would enable the industry to develop consistent attribution methodologies and establish opt out policies. A commenter suggested that if CMS finalizes its proposal to require payers to implement Provider Access APIs and require a response within 1 business day, it should delay the compliance dates until 2027. Multiple commenters flagged that CMS does not have to require implementation on any particular calendar date, since it would not affect an enrollee’s plan benefits or premiums. A commenter specifically stated that the implementation does not need to be synchronized to the beginning of the plan benefit year for MA organizations and QHP issuers on the FFEs. A commenter sought clarification on the compliance dates as it relates to onboarding new providers to a payer’s network, in order to ensure these new providers are following all applicable regulations, laws, and testing requirements by the proposed E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8790 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations compliance dates in 2026. Multiple commenters recommended that CMS develop the Prior Authorization API before fully implementing the Provider Access API. A commenter further recommended that CMS phase in implementation of the Provider Access API. They believe CMS should allow additional time for development of the Provider Access API to maximize its utility and provided suggestions for additional capabilities to do this. Response: After consideration of public comments, we are finalizing a 1 year delay in the compliance dates, to 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs). As discussed in section I.D. of this final rule, we are delaying the compliance dates for each of our policies that require API development and enhancement (though other policies on new reporting metrics and prior authorization processes are being finalized with different compliance dates). While making data related to prior authorizations available to providers is necessary and urgent, we also understand that the policies we are finalizing will take time for payers to implement. An additional year will give payers time for a smooth rollout of this new API, as well as to onboard their providers. Payers may communicate these policies to any new providers through the same channels they currently use to communicate participation rules, coverage guidelines, and other important plan information with new providers joining their network. Because we are delaying the compliance dates, we do not believe a phased implementation is necessary, even if the additional time is used to implement functionalities for the API that we are not requiring in this final rule. We emphasize that the compliance dates are merely a deadline, and we encourage payers to meet the requirements of this rule as soon as possible to benefit their patients and providers. The additional year will also give impacted payers the requested time to establish the required attribution and opt out processes (discussed in sections II.B.3.a. and II.B.3.b. of this final rule, respectively). Finally, we decline to delay the compliance dates for this policy until after the Prior Authorization API is implemented and are finalizing the same compliance dates for all three new APIs. We agree that the purpose of the VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 Prior Authorization API is to facilitate the exchange of structured (as defined in section II.A.2.a.ii. of this final rule) prior authorization data, and therefore receiving requests electronically may expedite payers’ ability to make that information available to providers. However, even after the Prior Authorization API compliance dates, we expect that a number of prior authorizations are going to be submitted through other channels (hopefully in declining number). A provider’s access to this information should not depend on the method and process that a payer sets for providers to submit a prior authorization request. Rather, the purpose of our Provider Access API policies is that providers have access to their patients’ data (if patients do not opt out). That means that payers will need to be able to share through the required APIs any prior authorization information that is submitted in ways other than the Prior Authorization API, regardless of the compliance dates. By finalizing 2027 compliance dates, we are providing payers an additional year beyond our proposal to implement the needed functionality within their internal systems. While we acknowledge that the compliance dates may not need to be at the start of a calendar, contract, or rating year, finalizing our proposal with specific compliance dates will ultimately reduce confusion for all parties. Comment: A commenter cautioned that without information that will be contained in an anticipated ONC proposed rule, it is difficult to provide realistic timelines for making prior authorization data available. They recommended that CMS offer an additional public comment period after the publication of this separate, anticipated ONC rule to allow the industry appropriate time to review the proposed changes that would be incorporated into the provider’s workflow. Response: Regarding ONC regulations, we recognize that commenters are interested in future ONC policies which may relate to the policies in this rule. ONC issued both the HTI–1 proposed and final rules since the publication of our proposed rule. As discussed, cross references in this final rule have thus been updated accordingly. We will continue to work with ONC to explore the adoption of standards and health IT certification criteria where appropriate to streamline data exchange, support interoperability, and increase efficiencies associated with the policies in this final rule. We further note that the Unified Agenda, at the time of publication of this final rule, has been PO 00000 Frm 00034 Fmt 4701 Sfmt 4700 updated to include an entry for a proposed rule from ONC entitled ‘‘Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability’’ (RIN 0955–AA06). The description indicates that the proposed rule aims to advance interoperability, including proposals to expand certified APIs for electronic prior authorization.28 However, the policies in this rule can be finalized independently of future rulemaking by ONC and we are not providing an additional period for comment. c. Identifying Providers and Networks Comment: Multiple commenters requested clarification on the definition of ‘‘providers’’ that are eligible to use the Provider Access API. A commenter recommended that CMS permit providers who use a Type 2 National Provider Identifier (NPI) number to use the Provider Access API. Multiple commenters also believed that providers other than physicians should have access to patient data via the Provider Access API. A commenter recommended that the final rule explain whether the Provider Access API can be used by clinical laboratories. Another commenter believed that a Tax Identification Number (TIN) should be used for patient attribution purposes, rather than an NPI because it would give an opportunity for multiple providers in the same practice to access a patient’s information. Response: Providers who should have access to a patient’s data are those, whether they are an individual, a facility, or a group of providers who have come together as an Accountable Care Organization (ACO), who are appropriately licensed, provide items or services eligible for coverage by the payer, and are enrolled with the payer or in the payer’s provider network. Should a clinical laboratory, or other entity such as an ACO, meet these criteria, it would indeed be a provider who could use the Provider Access API to access patient data, assuming all other criteria outlined in this final rule are met. Multiple providers in the same practice may also be able to access a patient’s data if the practice is enrolled with a plan under a Type 2 NPI (that is, an organization’s NPI), or if those providers are part of an ACO that is 28 Office of Information and Regulatory Affairs. Executive Office of the President (2023). Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability. Retrieved from https:// www.reginfo.gov/public/do/ eAgendaViewRule?pubId=202304&RIN=0955AA06. E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations requesting data on a provider’s behalf, because all the providers in such organizations would be part of the payer’s network. Furthermore, an ACO typically has business associate agreements with the providers that comprise the ACO, that should allow them to request data on the provider’s behalf. Impacted payers may even elect to use patient rosters from such multiprovider practices or ACOs, as well as a practice’s TIN, as part of its attribution process (see section II.B.3.a. of this final rule) since the patients on these rosters could be attributed to all the providers in these organizations. Comment: Multiple commenters sought clarification on how CMS defines a payer’s network. A commenter inquired whether CMS’s intention was to only include contracted providers who have both a contractual relationship with the payer and a treatment relationship with the patient, and as to which facilities are considered contracted or out-of-network. Another commenter asked for CMS to further define ‘‘treatment relationship with the patient.’’ A different commenter sought clarification on the definition of innetwork providers for a plan that operates in multiple territories and has some providers that may be in-network for one location and out-of-network for another. A commenter further recommended that CMS consider how to allow for effective patient data transfers in more complex provider-facility relationships, meaning contracted individual and institutional providers. A commenter also recommended that CMS consider the nuances of cancer therapy networks when developing its final policies, as some payers utilize a cancer therapy network and cover services furnished by certain providers who may be considered out-of-network generally, but in-network for certain cancer treatments. Other commenters suggested that CMS explain whether impacted payers with leased networks would be subject to the in-network requirement and recommended that leased network providers not be considered in-network for purposes of the Provider Access API. One of these commenters raised the concern that requiring QHP issuers on the FFEs to share patient information with leased network providers would impose a burden on QHPs, noting that the in- and out-of-network status of these providers could depend on a plan’s benefit package. These commenters noted that these networks are often rented or leased from other payers, and that the QHP issuer that is renting the network may not have VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 control over provider contract standards. Response: We are finalizing that impacted payers will be required to make the specified patient data available to in-network or enrolled providers with whom the patient has a verified treatment relationship (determined via an attribution process, as discussed in section II.B.3.a. of this final rule), assuming the data access conforms to all other applicable laws and regulations, such as state privacy laws. As discussed elsewhere, a payer can establish a treatment relationship by determining whether the patient’s claims history, proof of an upcoming appointment, or other information (for example, hospital admission letter) demonstrates a treatment relationship with the provider. Nothing in this final rule would require the information used to verify the provider’s relationship to the patient to be shared or exchanged via the Provider Access API itself. We also remind readers that, though we are not requiring payers to share patient data with out-of-network or unenrolled providers, we encourage them to do so to the extent permitted by law if they can verify a treatment relationship. Impacted payers that operate in multiple service areas, and therefore have some providers that are in-network in a particular area but out-of-network in other areas, should treat the providers based on network status on a case-bycase basis, depending on the payer’s service area applicable to each enrollee. For example, if Providers A and B are both in-network for the plan, but Enrollee C resides in a service area where only Provider A is in-network, then the plan can treat Provider A as innetwork and Provider B as out-ofnetwork for making Enrollee C’s data available via the Provider Access API. However, we remind readers that while not required, it would still be permissible to grant access to the Provider Access API to Provider B. The fact that Provider B already has a contract with the payer would even help to mitigate the potential privacy, security, and program integrity concerns we discussed in the proposed rule. The presence of this contractual relationship is also why we agree with the commenter regarding providers who are part of a cancer therapy network. If providers are in-network for some services for a patient, then they are an in-network provider. Our goal with our Provider Access API policies is to maximize the number of providers who can use it. We acknowledge that there may be health care settings and facilities where only some of the providers are enrolled PO 00000 Frm 00035 Fmt 4701 Sfmt 4700 8791 with or have a provider agreement with the impacted payer (as applicable). Under the HIPAA Privacy Rule, covered health care providers generally may disclose certain PHI to other health care providers for treatment purposes.29 Thus, there may be cases where a provider may share relevant patient data obtained via the Provider Access API with another provider who may not be in-network or enrolled with the impacted payer. However, under our requirements, payers would only be required to share data through the Provider Access API in response to requests from in-network or enrolled providers (as applicable). Providers in a leased network are innetwork for purposes of the Provider Access API requirement because the lease effectively creates a contract with the providers in that network. By way of example, QHP issuers on the FFEs include leased network providers in the Network Adequacy template they submit as part of the annual QHP Certification application process, to the extent that a network’s providers are available to enrollees in that QHP and are treated by the issuer as providing innetwork benefits.30 In addition, per 45 CFR 156.340, QHP issuers on the FFEs are responsible for their own compliance and the compliance of any delegated 31 or downstream entities 32 with all applicable Federal standards related to Exchanges. d. Provider Adoption and Use Comment: Multiple commenters agreed with the scope of the Provider Access API, but expressed concern about potential penalties for providers who are unable to adopt technology that supports data exchange via this API. Response: We did not propose any requirements for providers to use the Provider Access API, nor did we propose penalties for providers who do not use the API. However, accessing patient data through the Provider Access API will improve providers’ ability to furnish quality care to patients. We expect that providers too 29 See 45 CFR 164.506(a). and Network Adequacy (n.d.). Essential Community Providers and Network Adequacy. Retrieved from https:// www.qhpcertification.cms.gov/s/ ECP%20and%20Network%20Adequacy. 31 A ‘‘delegated entity’’ is defined at 45 CFR 156.20 to mean any party that enters into an agreement with a QHP issuer on the FFEs to provide administrative services or health care services (for example, contracted providers). 32 A ‘‘downstream entity’’ is defined at 45 CFR 156.20 as any party that enters into an agreement with a delegated entity or with another downstream entity to provide administrative services or health care services (for example, subcontracted providers). 30 ECP E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8792 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations will see the benefit of this technology and having patient data available directly from payers. Comment: Multiple commenters flagged that providers should have access to a patient’s health information without technological or financial barriers, and that CMS should consider the costs to health centers, safety net providers, long-term and post-acute care (LTPAC) settings, and hospitals with low resources, as well as their unique needs with regard to implementing use of the Provider Access API. They believed that considering these provider types would ensure more widespread use of the API. A commenter stated that some small businesses do not have the staff or funding to set up a complex data exchange and they believed there is a need to engage them in discussions about the benefits of the health information exchange. Another commenter stated that the proposed rule did not offer any indication of available resources to help providers implement the API. A commenter recommended CMS consider investments that health centers make to ensure appropriate interoperability and access. A commenter urged CMS to track and counteract any equity issues that may manifest from operationalizing the Provider Access API. Multiple other commenters flagged that the true impact of APIs on everyday practices will not be understood until they are implemented and being used by providers, with another commenter recommending that CMS focus targeted efforts to engage provider specialties and groups who have traditionally lagged in uptake of interoperable technology. Response: We agree that technology should not be a barrier to accessing appropriate patient information and our policies are intended to make such access easier for providers. We recognize that there are care settings that lag in adoption of EHR and other health IT, and/or lack the staff or resources to make use of the Provider Access API, which could result in these care settings missing out on the benefits of data exchange. Nevertheless, making data available via a FHIR API, which ensures these data are available to any authorized system seeking to access it, will benefit settings that may not have sophisticated technological solutions. Furthermore, making these data available is a vital antecedent to increased data sharing and interoperability across the health care system. We will be closely monitoring implementation and use of the Provider Access API to assess its real-world impact on care delivery, such as the VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 possible equity concerns described by the commenters, as well as continue to work with providers to encourage and enable them to use the API, should they wish to do so. Comment: Multiple commenters recommended that CMS seek to understand the current state of health IT and the needs of end users before mandating Provider Access API implementation. A commenter stated that the health IT infrastructure across the industry is not ready to support the APIs. Another commenter representing payers, providers, and clearinghouses in both the public and private sector noted that when they surveyed their payer members on the Provider Access API implementation, 64.3 percent of payers responded it would be ‘‘very difficult or difficult’’ to implement. Response: We disagree with the commenters’ assessment that existing health IT infrastructure is not ready to support the Provider Access API. Payers are currently required to maintain a Patient Access API that enables the exchange of the same data as we are requiring to be available via the Provider Access API, with the caveat that this rule establishes new requirements to include information related to prior authorizations. The Patient Access API establishes the foundation to ensure that existing payer health IT infrastructure is indeed capable of also supporting the Provider Access API. For providers, as of October 2018, eligible professionals and hospitals collectively received over $38 billion in incentives to adopt, implement, upgrade (AIU), and demonstrate meaningful use of certified EHR technology (CEHRT) through the Medicare and Medicaid Promoting Interoperability Programs (formerly the Medicare and Medicaid EHR Incentive Programs).33 34 35 As of 2021, 78 percent of office-based physicians and 96 percent of non-Federal acute care hospitals had adopted CEHRT.36 CEHRT 33 Centers for Medicare and Medicaid Services (2018). Promoting Interoperability (PI) Program Medicare Incentive Programs. Retrieved from https://www.cms.gov/Regulations-and-Guidance/ Legislation/EHRIncentivePrograms/Downloads/ October2018_MedicareEHRIncentivePayments.pdf. 34 Centers for Medicare and Medicaid Services (2018). Promoting Interoperability (PI) Program Medicare Incentive Programs. Retrieved from https://www.cms.gov/Regulations-and-Guidance/ Legislation/EHRIncentivePrograms/Downloads/ October2018_MedicareEHRIncentivePayments.pdf. 35 Centers for Medicare and Medicaid Services (2017). MA Organization (MAO) Incentive Payments for Eligible Professionals. Retrieved from https://www.cms.gov/Regulations-and-Guidance/ Legislation/EHRIncentivePrograms/Downloads/ May2017_MAO-Report.pdf. 36 Office of the National Coordinator for Health Information Technology (ONC) (2020). National PO 00000 Frm 00036 Fmt 4701 Sfmt 4700 now incorporates functionality for standards-based FHIR APIs. We thus believe health IT developers can build on these standards-based APIs to further develop functionality in provider systems that supports access to Provider Access APIs. Comment: Multiple commenters underscored the need to establish incentives for providers to adopt the Provider Access API to offset any provider burden. Commenters cited quality measure reporting through the MIPS and CEHRT programs as possible avenues for incentives. Another commenter recommended that CMS and ONC work together to create incentives for vendors to improve EHR functionality and for providers to utilize the API, as well as provider educational resources to encourage adoption. Response: For reasons explained previously, we believe that providers will see the benefit of using the Provider Access API, but we intend to closely monitor providers’ experience, as well as consider ways to encourage use of the API in future rulemaking, if need be. We remind readers that nothing in this final rule would prohibit impacted payers themselves from incentivizing and/or requiring use of the Provider Access API. However, should they choose to implement such a policy, we remind impacted payers to carefully weigh the expected benefits against any potential new burden on providers. Comment: Multiple commenters stated that the Provider Access API may be duplicative of existing resources (for example, HIEs or HINs, multi-payer portals, or other existing mechanisms for accessing claims data). Many other commenters supported creating the ability to integrate information from the Provider Access API into the provider’s EHR system. These commenters recommended that CMS work closely with both providers and EHR vendors to ensure that integrating data from the Provider Access API is user-friendly and incorporated into the clinical workflow. They stated that that would make patient data from the Provider Access API organized and navigable. Another commenter stated that because patients often receive care from multiple health providers, they often have fragmented patient health records, which can make it difficult for providers to get a clear picture of a patient’s health history. Multiple commenters, however, expressed concerns regarding the feasibility of the Provider Access API. A Trends in Hospital and Physician Adoption of Electronic Health Records. Retrieved from https:// www.healthit.gov/data/quickstats/national-trendshospital-and-physician-adoption-electronic-healthrecords. E:\FR\FM\08FER2.SGM 08FER2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations lotter on DSK11XQN23PROD with RULES2 commenter stated that the biggest challenge to the implementation of Provider Access API is that providers generally interact with many payers and it is not feasible for provider organizations to support many one-toone connections with payers. The commenter stated that while it would be costly and risky, the urgency to implement a National Data Warehouse Exchange Hub/Clearinghouse has never been greater. Response: We understand commenters’ concern about the potential for duplication of the Provider Access API functionalities that existing resources may provide. However, not all providers currently use or have access to other resources that can access patient data.37 38 Further, the data we are requiring payers to make available under this final rule may not be available from other sources. Thus, the Provider Access API can be a valuable tool for providers, even if they currently have access to data via an HIE/HIN or other source. We anticipate that providers will find benefits to patient care from having patient data available from multiple sources. We emphasize that the responsibility for implementing and maintaining the Provider Access API falls on impacted payers, not on providers or provider organizations. Further, in this final rule, we prioritize sharing structured data elements through standardized APIs (see section II.A.2.a.ii. of this final rule). Thus, even though this final rule does not obligate providers to use the Provider Access API, we anticipate that health IT vendors will integrate data from this API for providers in a manner that is organized, navigable, and useful to providers. We encourage vendors to work with their clients so that information accessed via the Provider Access API is useful for filling in gaps in the patient record, rather than creating duplicative data, and providers can take full advantage of their benefits. Comment: Multiple commenters suggested that CMS should take steps to ensure that costs borne by EHR vendors are not passed onto providers, and that implementation is done in a manner that minimizes burden for providers. Multiple commenters also 37 Office of the National Coordinator for Health Information Technology (ONC) (2021). Electronic Health Information Exchange by Office-based Physicians. Retrieved from https:// www.healthit.gov/data/quickstats/electronic-healthinformation-exchange-office-based-physicians. 38 Office of the National Coordinator for Health Information Technology (ONC) (2023). Interoperability and Methods of Exchange among Hospitals in 2021. Retrieved from https:// www.healthit.gov/data/data-briefs/interoperabilityand-methods-exchange-among-hospitals-2021. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 recommended that CMS explicitly require payers to allow providers to use the Provider Access API at no charge and that CMS should monitor and enforce such a requirement against payers who attempt to charge providers a user fee to access the APIs. Response: Our goal is to improve care and reduce burden on patients, health care providers, and payers. We also recognize that EHR vendors, providers, and payers have costs of doing business. We strongly encourage EHR vendors to only charge reasonable fees for any initial or periodic system configurations required to access payers’ API endpoints. Furthermore, EHR vendors and payers should ensure that any fees charged per API call are necessary and reasonable based on any actual maintenance costs for that entity. We also strongly encourage payers to permit providers to use their Provider Access API at no cost to maximize usage and benefits to patient care, which would ultimately benefit the payer as well. We will continue to work with interested parties to ensure that health care providers are not unnecessarily burdened and to ensure that our regulations do not place conflicting or unnecessary burdens on entities that may be regulated by more than one Federal agency. Furthermore, EHR vendors and some impacted payers may be information blocking actors (as defined at 45 CFR 171.102) that must abide by ONC’s regulatory requirements. Specific details of the information blocking regulations and other regulations issued by ONC are outside the scope of this final rule. Additional information about ONC information blocking regulations is available from the Information Blocking page of ONC’s website: https:// www.healthit.gov/topic/informationblocking. Questions may be sent to ONC’s Health IT Feedback and Inquiry Portal at https://inquiry.healthit.gov/. Payers who are information blocking actors (as defined at 45 CFR 171.102) and have committed information blocking (as defined at 45 CFR 171.103) may be subject to civil money penalties by the HHS Office of the Inspector General (OIG). Interested parties should address questions regarding when particular practices might be considered information blocking to ONC. Finally, we did not propose to implement a prohibition against payers charging providers a user fee to access their APIs. We will closely monitor implementation of the Provider Access API and whether user fees present a significant impediment to interoperable data exchange. We will also be monitoring the frequency and type of PO 00000 Frm 00037 Fmt 4701 Sfmt 4700 8793 feedback we receive from providers, patients, and payers related to burden and cost, to determine whether other policies might be ripe for consideration in future rulemaking. See section I.D.2. of this final rule for more information about CMS’s enforcement and compliance policies. Comment: A commenter wanted to ensure that payers cannot require providers and clinical staff to use multiple different tools that might leverage the Provider Access API to treat patients. The commenter stated that providers should have autonomy to deliver care without having to add new technology that payers may require them to implement. Another commenter similarly recommended that CMS ensure payers do not increase burden on providers, stating that a significant burden would be placed on providers if their network participation gets conditioned on payer requirements to use the Provider Access API. Another commenter urged CMS to prohibit payers from placing additional contractual demands on providers, such as unrealistic turnaround times for physicians to retrieve patient information. The commenter expressed concerned that if providers cannot comply with payers’ potential new requirements, they may be forced out of network. Response: This rule does not require payers to impose requirements to use the Provider Access API on their innetwork or enrolled providers. However, both providers and patients can benefit from the improved interoperability facilitated by FHIR APIs, with providers in particular seeing the benefits of having more patient data available to them. Contractual requirements set by payers for their innetwork or enrolled providers are out of the scope of this rule. Nonetheless, if payers do choose to require providers to use the Provider Access API in some capacity, or even if they develop and require their own apps, we expect that they would do so to improve coordination with the provider and patient care, and also in a way that does not add provider burden. Comment: A commenter noted that clinical data managed by payers are often derived from claims submitted by providers, which often results in them being in a different level of detail and format than clinical data exchanged between providers. The commenter stated that when the data are made available to providers, clear communication of those differences and accurate interpretation by the receiving provider’s system is essential for enabling the provider to use the data to E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8794 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations address care gaps and make treatment decisions. The commenter added that because the data are derived from claims, which would have been submitted by many of the same providers requesting it from the payer, deduplication of the data can become more complex. They further recommended that standards for representing the provenance of data when transmitted from payers to providers be enhanced to avoid adding a reconciliation burden on providers who receive the patient data. Another commenter said that EHR vendors would need to develop a ‘‘curation function’’ that could allow providers (and patients) to select the specific data to incorporate into the patient’s record, warning that without this capability, there will be a significant amount of duplicate and junk data that will render the Provider Access API unusable. Response: We thank the commenter for the comments, and we appreciate the concerns regarding the level of detail, format, and potential duplication of data received by providers’ systems. One of the IGs we recommend for the Provider Access API is the PDex IG (see Table H3 in section II.G. of this final rule) is a set of guidelines that describes how to exchange data between payers and providers. A key PDex IG feature is the capability to include provenance records, if they exist, when exchanging data. Provenance records describe where the data came from and how they were processed. The PDex IG strongly recommends that payers create provenance records when they are not included in a data set. We also strongly recommend provenance records in cases, like those cited by the commenter, when clinical data are derived from claims. The provenance profile contains contextual information about the data, including the data’s original author(s), transmitters, and formats (including whether they are derived from a claim-related transaction). Thus, using the PDex IG can help mitigate the problem of duplicating data by including provenance information. We also strongly recommend that the data source be included at the point of record creation, so that users can appropriately understand the source and context of the data. While we acknowledge the potential complexity of deduplicating data, creating contextual provenance information could help providers’ systems identify data that already exist in the system, which can make the data actionable, rather than duplicative. In this way, payers can help providers unlock the benefits of accessing patient VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 information through the Provider Access API. Finally, nothing in this final rule obligates providers to incorporate data they access via the Provider Access API into their patient’s record, if they do not believe there is a benefit. Comment: A commenter suggested that CMS permit payers to include audit rights and penalties in their provider contracts to ensure that payers are able to monitor and regulate information access requests, as the structure of the proposed rule effectively asked payers to trust that providers who request access to patient information have a valid need to access that information. Response: Nothing in this final rule prohibits impacted payers from including additional requirements in their provider contracts and/or terms of service for requesting patient data. However, we emphasize that our requirement to provide access is limited to in-network providers who have a treatment relationship with the patient. We understand that payers need to ensure that provider requests are appropriate, so it follows that those entities would want to define roles and responsibilities through provider contracts, as these are established vehicles which delineate other payer requirements. If payers choose to implement such requirements, or a separate terms of service agreement, we strongly encourage them to balance the benefits to patients against any additional burden this would place on providers. Further, our requirements on the impacted payer will ensure that patients are informed of their data sharing options and will have the opportunity to opt out of data sharing under this policy if they do not wish for their providers to have access to their data. Any requirements that payers implement to use the Provider Access API must not conflict with the HIPAA Rules, or any other applicable law. See sections II.B.2.j. and II.B.3.b.ii. for discussions on the interaction of this final rule with the HIPAA Rules. Comment: Multiple commenters cautioned that this rule puts a large burden on payers with little burden on providers and that given the number of resources needed to implement the API, provider uptake is critical. A commenter further stated that this rule requires payers to build a new API and share information with providers without asking providers to contribute or share information with payers, which they believe will lead to a breakdown in communication between providers and payers. Response: As discussed previously, the technical requirements for the PO 00000 Frm 00038 Fmt 4701 Sfmt 4700 Provider Access API align almost identically with those already established for the Patient Access API (85 FR 25510) that impacted payers are currently required to maintain. We also emphasize that our recommended IGs will provide further clarity for payers on how to implement the APIs, thus reducing some of the implementation burden. As we discuss in section II.B.3., we are not being prescriptive as to how impacted payers implement their attribution and opt out processes, so that they can design processes that work best for them. We believe that all parties will see the benefit of improved data exchange facilitated by the Provider Access API. Because this final rule does not prohibit it, impacted payers may also decide to require providers to share certain data with them as part of their network/enrollment requirements. In fact, we understand that such requirements already exist in some situations. However, should payers implement such polices, we expect that they would do so only to the extent that it would benefit patient care and not add provider burden. We strongly encourage payers to carefully weigh any expected benefits against this potential burden. Finally, the Health IT Certification Program has already established requirements for FHIR APIs in EHR systems, which creates the capability for providers to make data available to payers via FHIR APIs. Using those APIs would allow payers to implement any requirements in a way that imposes minimal burden on providers. Comment: A commenter recommended that CMS explain whether only providers, not EHR vendors, can trigger a request for patient records. Response: We are only requiring impacted payers to make patient data available to in-network or enrolled providers. Vendors are not permitted to request data for themselves, as they are not providers and thus cannot meet the criteria for making such a request. However, an EHR vendor may request the patient data via the provider’s system at the behest of a provider who is eligible to request the data, with appropriate authentication and if consistent with other applicable law. e. Data Content Comment: Multiple commenters recommended that CMS streamline the proposed required data to limit duplicative information and potentially overwhelming providers. A commenter recommended that CMS initially focus the Provider Access API on sharing claims data before introducing other E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations types of data. Another commenter recommended that CMS consider the burden that this proposal may place on providers if they must maintain multiple versions of USCDI and whether it would even be feasible for their EHR to support this. Multiple commenters, however, suggested additional data that should be made available via the Provider Access API. Some commenters suggested that to facilitate a simpler prior authorization request process, CMS consider requiring payers to make patients’ insurance coverage information readily available to providers through the Provider Access API. A commenter recommended that patient data collected by payer-owned providers and health service companies also be included in the Provider Access API. Response: We understand the concern over duplicative information, and it is not our intention to increase provider burden. Under this final rule, we are only requiring the exchange of data that are already structured, meaning they can be received by the provider’s system in a standardized format with defined data attributes—this includes data classes and data elements in the USCDI and FHIR resources (see more discussion of how we define structured documentation in section II.A.2.a.ii. of this final rule). Most EHR systems use standardized clinical data in their systems today and, if certified under the ONC Health IT Certification Program, are also required to use the data classes and data elements in the content standard at 45 CFR 170.213 (USCDI). There are IT solutions available for providers’ EHRs or practice management systems, such as Substitutable Medical Applications, Reusable Technologies (SMART) on FHIR apps, that can make the data received via the Provider Access API actionable and avoid duplicative information. Further, for administrative ease and consistency, we are keeping the required types of data consistent (excluding provider remittances and patient cost-sharing information, as explained elsewhere in this final rule) with those required under the Patient Access API. We did not propose to include patients’ insurance coverage information, to which providers should already have access through existing channels with payers or from patients themselves. However, a Health Insurance Information data class has been added to USCDI v3, and includes the data elements Coverage Status, Coverage Type, Relationship to Subscriber, Member Identifier, Subscriber Identifier, Group Identifier, VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 and Payer Identifier.39 As payers adopt USCDI v3 (as required after January 1, 2026, under the regulations at 45 CFR 170.213), this information would be required to be available. We remind impacted payers that if there is additional information beyond that which we are requiring that they do or can share with providers, they can use the Provider Access API as a mechanism for sharing that information, as permitted by applicable law. To the extent that impacted payers maintain patient data (per the CMS Interoperability and Patient Access final rule [85 FR 25536]) collected by payerowned providers and health service companies, only the data elements specified in this final rule are included in the Provider Access API requirements. Comment: A commenter recommended that CMS support the development of content and technical standards for prior authorization decisions that can be incorporated into IGs for testing before requiring inclusion of prior authorization information in the Provider Access API. Response: Our recommended IGs (listed in Table H3) are currently in production and several versions of the IGs have been updated since publication of the proposed rule. Additionally, the recently published PDex IG STU 2.0.0 specification includes a prior authorization profile that enables payers to communicate prior authorization decisions and changes to the status of a prior authorization requests. The process for IG development is open and we encourage industry engagement in their further development via opportunities such a HL7 FHIR Connectathons. Comment: A commenter recommended that CMS require USCDI v3, since the proposed Provider Access API would not be implemented until 2026. The commenter stated that the USCDI v1 does not have digital data standards for social determinant of health (SDOH), sexual orientation and gender identity (SOGI), nor other data standards important for public health capabilities, and this could be a missed opportunity to drive national digital data standardization in this area. The commenter suggested this requirement would create a business case and drive adoption of standards and a move by industry to align. Response: At the time the proposed rule was published, USCDI v1 was the 39 Office of the National Coordinator for Health Information Technology (ONC) (2023). Health Insurance Information. Retrieved from https:// www.healthit.gov/isa/uscdi-data-class/healthinsurance-information#uscdi-v3. PO 00000 Frm 00039 Fmt 4701 Sfmt 4700 8795 only standard included at 45 CFR 170.213. The HTI–1 final rule, however, finalized that USCDI v1 expire on January 1, 2026, and also adopted USCDI v3 at 45 CFR 170.213 (89 FR 1210). Both versions will be available USCDI versions at 45 CFR 170.213 until January 1, 2026. Until this date, payers may meet the Provider Access API requirements by sharing all data classes and data elements in either USCDI v1 or v3. After January 1, 2026, payers must make available all data classes and data elements in USCDI v3. ONC accepts submissions from the public for new USCDI data classes and data elements through the USCDI ONC New Data Element and Class (ONDEC) Submission System 40 and regularly publishes updated versions of the USCDI.41 Any change in a content standard at 45 CFR 170.213 will go through notice-andcomment rulemaking. Impacted payers are permitted to voluntarily use updated standards, specifications, or IGs that are not yet adopted in regulation for the APIs discussed in this final rule, should certain conditions be met. We specifically encourage impacted payers to make all data classes and data elements available from more advanced versions of the USCDI prior to the expiration date. We refer readers to section II.G.2.c. of this final rule for a full discussion on using updated standards. Comment: A commenter noted that while there is a FHIR resource for a scheduled appointment, it is not included in USCDI v1, which means a provider cannot send an appointment even when they have implemented the latest version of USCDI. The commenter stated that adding that element would require additional EHR vendor development. Response: All data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI) for dates of service after January 1, 2016, maintained by the payer are required to be made available to the provider who requests them (assuming all other applicable requirements specified in this final rule are met). Whether or not a scheduled appointment data element is included in USCDI has no bearing on how API developers use the Scheduling 40 Office of the National Coordinator for Health Information Technology (ONC) (n.d.). USCDI ONDEC (ONC New Data Element and Class) Submission System. Retrieved from https:// www.healthit.gov/isa/ONDEC. 41 Office of the National Coordinator for Health Information Technology (ONC) (n.d.). United States Core Data for Interoperability (USCDI). Retrieved from https://www.healthit.gov/isa/united-statescore-data-interoperability-uscdi. E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8796 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations and Appointment FHIR Resources for other purposes. Comment: Multiple commenters disagreed with the proposal to require payers to include clinical documentation and forms related to a prior authorization, with one noting that this information will be duplicative of the clinical information in a person’s medical record. Another commenter stated that clinical documentation is often submitted to payers in the form of lengthy PDF documents, and sometimes by fax, making manually translating these data into FHIR challenging and infeasible to do within the proposed 1 business day timeframe. A commenter recommended that CMS explain whether payers have to convert clinical documentation submitted by providers by fax or in PDF or JPEG file formats into FHIR. A commenter recommended that CMS require the same discrete data element standards that the agency applied to the original Patient Access API to the Provider Access API, since distributing patient clinical attachments to all requesting clinicians raises concerns under the HIPAA minimum necessary standard. The commenter stated that an alternative is that providers could share clinical attachments as needed through clinician data sharing consultation and collaboration. However, a commenter recommended that CMS should include the administrative and clinical documentation requirements and require specific information for prior authorization data. Response: After reviewing the comments, we agree that the burden of requiring payers to make unstructured documentation (as explained in section II.A.2.a.ii. of this final rule) available via the Provider Access API outweighs the benefits such documentation would provide. Thus, like for the Patient Access API, we are finalizing a requirement that the Provider Access API include only structured administrative and clinical documentation related to the prior authorization requests. As with the Patient Access API, documentation received in an unstructured format does not need to be parsed and converted to structured data for the purposes of inclusion in the Provider Access API. However, if a payer does parse the unstructured documentation to store the contained data in a structured format, that structured data would then be ‘‘maintained’’ by the payer, as defined in the CMS Interoperability and Patient Access final rule (85 FR 25538). For example, a payer may receive and maintain an unstructured PDF that VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 contains lab results. If a payer maintains those lab results in a structured format, they would be required to share them under this final rule. If they are maintained in an unstructured format, they would not. We recognize that unstructured administrative and clinical documentation could be important to help providers understand certain prior authorization requirements, so we encourage payers to make that information available when possible. Furthermore, the policy we are finalizing would require payers to make available any documentation or materials that the provider sends to the payer to support a decision that are received in a structured format. Since we are finalizing that only structured documentation be made available, and structured documentation are formatted in a way that makes them easily transmissible between systems, our final policy should place significantly less burden on payers than our proposal, while still giving providers access to information about their prior authorization processes. It is important for payers to make available the specific clinical data at which they are looking to make a determination on the prior authorization request, even if that information may be elsewhere in the patient’s record. As to the commenter concerned about clinical attachments and the HIPAA Privacy Rule’s minimum necessary standard, we refer them and all readers to section II.B.3.b.ii. of this rule for more discussion about the HIPAA Rules. Comment: A commenter sought clarification on whether the data sharing requirement applies to only claims and encounter data that are available at the time of the request, reasoning that if so, it could avoid any inappropriate pressure on providers to submit claims immediately after the provision of an item or service. Response: Per the CMS Interoperability and Patient Access final rule (85 FR 25536), payers are only required to share data that they maintain as part of their normal operations. Nothing in this final rule would change that existing policy that payers are not required to reach out to providers or other entities to gather data that they do not maintain, if it is not part of their normal operations, in order to share via the Provider Access API. f. Provider Remittances and CostSharing Information Comment: Multiple commenters agreed with CMS’s proposal to not require payers to make available provider remittances and patient cost- PO 00000 Frm 00040 Fmt 4701 Sfmt 4700 sharing information, as it would likely only have a limited beneficial impact on care. A commenter stated the costrelated data currently available via from the Patient Access API are not very clear, which could lead to different implementations and increased ambiguity when implementing the Provider Access API. A commenter warned that implementers are inconsistent, with some sending Explanation of Benefits (EOB) scrubbed of the item level detail, whereas others exclude EOBs altogether and only provide clinical data. Response: Regardless of whether provider remittance information or costsharing information are truly confidential or proprietary information protected from disclosure under Federal law (which we do not address here), excluding such data from the Provider Access API is appropriate. Thus, if commenters believe that cost-sharing information would largely not be helpful information for providers to have access to, then we emphasize that sharing this information is not a requirement for the Provider Access API. We further agree with commenters that including this information in the Provider Access API will have limited benefit for treatment or care coordination. This rule does not prohibit payers from sending that information. Therefore, if a payer believes that implementing their Provider Access API in such a way that includes provider remittances and patient cost-sharing information would provide benefit or reduce burden, they are not prohibited from doing so under this rule, and may do so consistent with other applicable laws. Comment: Multiple commenters urged CMS to reconsider excluding costsharing information from the Provider Access API because providers with access to this information can make more informed decisions regarding patient care by incorporating cost into treatment plans, and in turn, maintain a good provider-patient relationship. A commenter encouraged CMS to examine standards-based, patient-facing, and real-time benefit check capabilities that can be facilitated by patient cost-sharing information. A commenter also cautioned that excluding provider remittances and cost information conflicts with the cost-sharing information needed to enable Good Faith Estimates (GFE) under the No Surprises Act (NSA), which was enacted as part of the Consolidated Appropriations Act, 2021 (CAA).42 They suggested that the rule be revised to 42 Public E:\FR\FM\08FER2.SGM Law 116–260 (December 27, 2020). 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations allow necessary cost-sharing information required under the NSA. Another commenter highlighted that providers must be able to calculate sustainable total cost of care for patients attributed to them as part of value-based payment models. Multiple commenters proposed potential solutions to facilitate the sharing of cost-sharing information. A commenter suggested that CMS consider a bi-directional exchange mandate (as opposed to one-way provider access to payer data) to cover payment and operations, in addition to treatment. A commenter suggested that it does not make sense to restrict patient costsharing information since it is available in the X12 270/271 transaction standard. The commenter stated the Provider Access API can potentially replace the need for a separate 270/271 transaction and instead incorporate the information in 270/271 transactions. Another commenter expressed that modifications could be made to the CARIN IG for Blue Button to align with the proposed requirement to remove remittances and cost-sharing data from the FHIR transaction. Response: While we appreciate the various suggestions we received; we did not propose any related policies because the primary purpose of our Provider Access API policies is to improve the exchange of data for health care treatment. We acknowledge that some providers may find cost information helpful for gaining a clearer picture of a patient’s financial situation. However, there is nothing prohibiting a provider from discussing the costs of various items or services and comparing the costs when furnished in-network and out-of-network to help a patient understand how to limit their out-ofpocket costs. Further, in-network or enrolled providers should be generally aware of the costs of various treatments, as their contracts would address payment amounts and conditions of payment for services furnished by that provider to a covered individual. We finally note that the GFE provision of the NSA relates to prospective costs, rather than cost information from past claims; that provision is beyond the scope of this final rule. Comment: A commenter stated that the CARIN IG for Blue Button will require updates to support CMS’s proposal to remove remittances and cost-sharing data from the FHIR transaction for the Provider Access API. Response: Further development is currently underway on the CARIN IG for Blue Button, which is one IG that we are recommending to support the Patient Access, Provider Access, and Payer-to- VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 Payer APIs (see Table H3 in section II.G.4. of this final rule). These developments will support exchanging information without provider remittances and patient cost-sharing information. Comment: A commenter supported CMS’s effort to establish the infrastructure needed to support payment reform and value-based care initiatives via the Provider Access API, stating that these initiatives are critical to reducing the costs of health care delivery while maximizing quality for Medicare enrollees. Multiple commenters stated, however, that the Provider Access API does not facilitate sharing the complete set of information needed by providers for participation in value-based care programs and recommended that CMS prioritize additional information, such as financial targets, spending, coordination of care payments, payer-generated attributed beneficiaries, and cost performance reporting. They believe these would allow a better exchange of value-based care payment models’ summary-level data. A commenter recommended that ONC and CMS encourage industry to prioritize APIs to exchange information that would reduce administrative burden and lead to value-based care scalability. Response: We did not propose to include cost information for value-based care, as the primary goal of the Provider Access API is to give providers both immediate and direct access to patient data in order to improve patient care. However, we remind impacted payers that they can use the API to exchange additional data, should they so choose. We agree that FHIR APIs have the potential to support participation in value-based care programs, as these initiatives are critical to reducing the costs of health care delivery while maximizing quality for patients. We will continue to explore ways to leverage FHIR APIs to achieve CMS and broader HHS priorities. The requirements in this final rule are a critical foundation for this future work. g. Prior Authorization Data Comment: Multiple commenters supported including prior authorization information in the data made available through the Provider Access API, noting that it would help future providers understand the patient’s current health status more quickly and better meet their care needs, increase transparency, and reduce burden on patients and providers. A commenter stated that adding prior authorization information to the Provider Access API will enhance PO 00000 Frm 00041 Fmt 4701 Sfmt 4700 8797 functionality and incentivize use of the API. Response: We thank commenters for their support and agree that giving providers access to the same prior authorization data as patients will have a positive impact on patient care. Comment: Multiple commenters recommended not including ‘‘the quantity of services used’’ due to delays in claims processing. A commenter recommended that CMS include just the approved number of units. Response: In response to commenter feedback to both the Provider and Patient Access API proposals, we are finalizing our proposal with the modification that ‘‘quantity of approved items or services used to date’’ will not be a required field. We refer readers to section II.A.2.a.ii. of this final rule for a full discussion of our reasoning. Comment: A commenter recommended including a standardized comment code(s) and comment description(s) for each status update sent to the provider to help with future data analysis of prior authorization improvements and tracking quality metrics. Response: While we consider five basic statuses (pending, active, denied, expired, authorization not required) to cover the general scope of a prior authorization requests and decisions, we do not intend to prescribe or delineate the exact statuses that payers must use. The requirement for the Provider Access API (and the other APIs in this rule) to include the status of the prior authorization is intended to provide information to the provider, patient, or other payer that is using the API to access this information. Therefore, compliance with the requirement is not based on using specific terms, but on providing clear information. We refer readers to section II.A.2.a.ii. of this final rule for a full discussion on prior authorization status definitions. Comment: A commenter recommended that CMS crosswalk the required types of data for the Provider Access API with the other proposed APIs to avoid duplication, such as having to include supporting documentation through the Provider Access API, even if it is available via the Prior Authorization API. Response: If the commenter is recommending that the Provider Access API make available a mutually exclusive set of data from the Prior Authorization API to avoid confusion, then we note that Prior Authorization API will not have prior authorization data from other providers. We refer readers to section II.D. of this final rule for our full E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8798 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations discussion of the Prior Authorization API requirements. We further intend to provide educational resources related to all the APIs in this final rule. We are not finalizing our proposal that related unstructured administrative and clinical documentation be included in the prior authorization data that impacted payers would have to make available to providers via the Provider Access API. Comment: A commenter recommended including the following additional data elements related to prior authorization: timestamps of any change in the status of the prior authorization; date/time received, reviewed, denied/ approved; how the decision was made; software tools/artificial intelligence (AI) tools used; and persons involved in making the prior authorization decision. Another commenter stated that prior authorization metrics should be available via the Provider Access API to give providers an aggregated view of their attributed patients’ prior authorizations. A commenter also recommended that CMS should require payers to make available through the Provider Access API contact information for the entity responsible for managing the payer’s prior authorization program. Response: While these specific additional data and functionalities may provide value to some providers at this time, we do not believe that the value outweighs the additional effort impacted payers would need to expend to add these data and functionalities to the Provider Access API. The PDex IG STU 2.0.0, which has been published since the publication of the CMS Interoperability and Prior Authorization proposed rule, states that payers using this IG shall make available pending and active prior authorization decisions and related clinical documentation and forms for items and services (not including prescription drugs), including the date the prior authorization was approved, the date the authorization ends, as well as the units and services approved and those used to date. It also requires a creation date, issued date, and specific codes relevant to the approval status.43 However, as discussed in section II.G., we are not yet ready to require this IG. We are thus prioritizing the data that are most important and useful at this time for clinical decision-making in proximity to a patient visit. To use one commenter’s example, requiring payers to provide contact information for the entity responsible for managing the payer’s prior authorization program would be duplicative, as providers who have a contractual relationship with the payer should already be aware of whom to contact regarding their prior authorization submissions. Providers can also use the Prior Authorization API to obtain this information. We remind impacted payers, however, that they may choose to include additional information if they believe it adds value to patients, providers, or themselves and their own processes. FHIR inherently provides flexibility to include additional information without reducing interoperability and the associated IGs are designed to both require and constrain specific elements identified as core to the IG’s use case. We encourage the public to engage in the HL7 balloting process 44 to provide feedback on data elements they believe would be most widely useful and applicable. Comment: A commenter recommended that sharing prior authorization information through the Provider Access API be required, even if the patient opts out. Response: We certainly agree with the benefits of providers having access to prior authorization information via an API and note that providers will have access to the Prior Authorization API. Providers will thus have access to these data for prior authorization requests that they make, regardless of whether the patient has opted out of the Provider Access API. We refer readers to section II.D.2.c. of this final rule for our discussion on patient opt out and the Prior Authorization API. Comment: A commenter urged CMS to require impacted payers to provide a statement through the Provider Access API when they are not requiring a prior authorization for an item or service. The commenter stated that this will ensure a level of transparency and paper trail between payer and provider. Response: This information will be available through the Prior Authorization API, so does not need to be included in the Provider Access API. We refer readers to section II.D. of this final rule for our full discussion of the Prior Authorization API requirements and section II.A.2.a.ii. for that of prior authorization statuses. Comment: A commenter encouraged CMS to work with impacted payers to ensure the supporting data fields of laboratory test results, clinical data, and a specific reason for a denial are standardized to ensure information is consistent across sources. They urged 43 Health Level Seven International (2020). Da Vinci payer data exchange STU 2.0.0. Retrieved from https://build.fhir.org/ig/HL7/davinci-epdx/. 44 Health Level Seven International. HL7 Balloting (n.d.). Retrieved from https:// confluence.hl7.org/display/HL7/HL7+Balloting. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 PO 00000 Frm 00042 Fmt 4701 Sfmt 4700 CMS to work with payers, providers, and patients to determine the balance of data included in the requirements and provide the needed clarification and guidance to all parties. Response: As explained in section II.B.2.e. of this final rule and in more detail in section II.A.2.a.ii. of this final rule, we are finalizing a requirement for payers to share only data that are already structured, which include laboratory test results, clinical data, and a specific reason for a prior authorization denial. We also remind readers that payers are not obligated under this rule to parse or convert documentation received in an unstructured format for the purposes of inclusion in the Provider Access API. However, they may choose to do so. We will continue to work with interested parties to ensure that all parties benefit from the data sharing requirements we are finalizing and explore possible enhancements to our policies that require API development or enhancement in future rulemaking. h. Data Availability Comment: A commenter stated that prior authorization information should be available from the entire duration of the patient’s history and not just for 1 year after the last status change because it would improve transparency in decision-making for providers. Response: Like with the Patient Access API, we believe that 1 year after the last status change is the appropriate amount of time to require payers to make historical prior authorization information available to providers. While historical information can certainly affect and be useful in improving patient care, we believe that historical claims and clinical data are more important to providers than information about prior authorizations that have expired or been denied more than a year in the past. Furthermore, our policy allows payers to make these prior authorization data available for longer than 1 year, if they believe it adds value to patients, providers, or themselves and their own processes. To inform ongoing long-term care, any active prior authorizations must be included, even if they have been in that status for more than a year. Comment: A commenter supported the payer maintaining patient health data and making available any data to the provider with a date of service on or after January 1, 2016. A commenter recommended that CMS explain whether all data included in this rule will be subject first to corporate data retention standards, then retained from January 1, 2016, to present. Another E:\FR\FM\08FER2.SGM 08FER2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations commenter sought clarification as to whether CMS’s intention is to include all data since 2016 and not only the last 5 years. Response: We remind impacted payers that the policy we are finalizing aligns with the similar one finalized in the CMS Interoperability and Patient Access final rule: 45 the data available through the Provider Access API are data with a date of service on or after January 1, 2016 maintained by the payer. By ‘‘maintained,’’ we mean data that are maintained as part of normal operations, as is currently the policy for the Patient Access API under the CMS Interoperability and Patient Access final rule. We did not propose a policy for impacted payers to make data available only from the previous 5 years in either the proposed rule or the CMS Interoperability and Patient Access final rule, nor did we receive comments specifically in favor of shortening the timeframe to 5 years. However, we also recognize that the data a payer maintains dating back to January 1, 2016, could be a substantial amount and, depending on the capabilities of the provider’s EHR or practice management system, potentially more than some providers will need. We remind providers that this final rule does not obligate them to incorporate data they access via the Provider Access API into their patient’s record. While we are finalizing our proposal to require impacted payers to make available via Provider Access API any of the applicable patient data with a date of service on or after January 1, 2016, that the payer maintains, we will closely monitor whether this timeframe is appropriate, to inform possible future rulemaking. lotter on DSK11XQN23PROD with RULES2 i. Response Timeframe for Requested Data Comment: Multiple commenters expressed their support for the proposal to require payers to share the requested patient data no later than 1 business day after the payer receives the request. A commenter stated this will enable the provision of historical health care data and may affect current care recommendations. Multiple other commenters sought clarification on whether the proposed 1 business day turnaround time for a payer to respond to a provider’s request for patient data 45 See 42 CFR 422.119(h)(1)(i) for MA organizations, 431.60(g)(1)(i) for Medicaid FFS, and 457.730(g)(1)(i) for CHIP FFS, cross reference to 42 CFR 431.60 at 42 CFR 438.242(b)(5) for Medicaid Managed Care, cross reference to 42 CFR 438.242 at 42 CFR 457.1233(d) for CHIP Managed Care, and 45 CFR 156.221(i)(1) for QHP issuers on the FFEs. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 included time for payers to complete an authentication of the provider’s identity and the provider-patient treatment relationship. Multiple commenters recommended that CMS increase the amount of time payers have to respond to providers’ data requests. Recommendations included suggestions to establish a twoday response time to balance timely access to information and reduce the operational burden and cost of the requirement. Commenters also noted that not all provider systems are FHIRenabled and that could lead to longer data exchange times. A commenter stated that because of CMS’s technical standards, specifications, and IG requirements, payers will likely need more time than one day to comply with CMS’s proposed requirements. They believe that payers may need additional time to establish technical connections and contractual terms for a first-time request from a provider. However, other commenters believed the time for payers to respond to the data request should be decreased from 1 day and that the response should come as soon as possible, to be real-time or near real-time. A commenter sought clarification from CMS as to why 1 business day is allowed for the payer to respond to a request, particularly if the initial request is being transmitted during a patient visit. The commenter continued that real-time responses should be expected from new technology. Another commenter stated having real-time data would help providers see a more complete view of a patient’s complete care history. A commenter warned that, often, providers and patients review data during a visit and that delayed access to the data could undermine efforts to promote care coordination and provider-patient engagement. A commenter also recommended that CMS consider requiring that the requested data be provided within 1 calendar day to accommodate facilities that have 24/ 7 operations, like SNFs. Response: We foresee providers needing access to the specified data in order to review them in proximity to a patient visit. Thus, we do not believe that the turnaround time should be greater than 1 business day. We specify in the regulation that a payer must make the data available through the Provider Access API no later than 1 business day after receiving a request from the provider, if all the following conditions are met: • The payer authenticates the identity of the provider that requests access and attributes the patient to the provider under the required attribution process; PO 00000 Frm 00043 Fmt 4701 Sfmt 4700 8799 • The patient does not opt out of the Provider Access API; and • Disclosure of the data is not prohibited by law. Authenticating the identity of the provider will include confirming that the requesting provider is in-network or enrolled with the payer and the attribution process will include confirming that a verified treatment relationship exists. The technical standards at 45 CFR 170.215 set requirements for identity proofing and authentication processes that must be met in order for a provider’s EHR or practice management system to connect to the Provider Access API and access a patient’s data (see section II.B.2.k. for more discussion on authorization and authentication). Those standards allow authentication to be completed within 1 business day, if not immediately, when the provider accesses their system via login. Impacted payers can also verify the patient-provider treatment relationship before the provider request. In fact, payers are permitted and highly encouraged to design their attribution processes to verify treatment relationships prospectively. We believe that the patient relationship can be verified for the vast majority of providers who will be requesting data via the Provider Access API either ahead of time or relatively quickly. However, we recognize that this may be difficult, if not impossible, for a new patient’s first visit because there will be no claims history between that patient and the provider. Thus, there might be instances where the conditions previously mention may take longer to be met for some data requests. We strongly encourage impacted payers to ensure completion of these steps in a reasonable amount of time, so the provider can make use of the data they are requesting. While we appreciate the commenters who pointed out that some providers might need the patient information as soon as possible or in real time, we also believe that requiring that standard would cause undue burden on impacted payers. We nonetheless encourage payers to make data available to requesting providers as soon as they are able. We are therefore finalizing our proposal that impacted payers respond to a provider’s request for patient data no later than 1 business day after the payer receives the request if all conditions are met. This timeframe adequately balances a provider’s need for timely data with impacted payers’ capability to make data available. Further, as discussed in detail in section II.A.2.a.ii. of this final rule, we are not E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8800 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations finalizing our proposal for impacted payers to share unstructured documentation related to prior authorizations, as sharing such documentation would currently be difficult to accomplish in 1 business day. Comment: A commenter stated that the required response time for the Provider Access API could be administratively time consuming because the process to determine whether a disclosure is permitted under applicable law is a manual process that involves research, review, and analysis to determine which laws are applicable to the requester of the information, the type of data requested, and the intended recipient. Another commenter recommended that CMS consider the extent to which payers will be burdened by connecting and testing EHRs to facilitate the Provider Access API implementation. Response: We are only requiring impacted payers to share data elements that are already structured, and are requiring certain mature IGs and standards (see Table H3 in section II.G. of this final rule) that will enable the Provider Access API to connect to thirdparty apps and/or providers’ EHRs or practice management systems. Because of this foundation, along with the 2027 compliance dates that we are finalizing, payers should have sufficient time to not only test their API connections, but also to develop internal processes and train staff to make the necessary determinations of which of the known and structured data are permitted to be shared via the Provider Access API. For instance, impacted payers may use this time to develop processes that flag certain data elements—as the payer receives them—as those that may require special permissions or are prohibited to disclose under other law. Such processes can ease any manual review and decision-making that might be necessary when a provider requests patient data. Comment: A commenter recommended that CMS make it clear that the provider must request access to patient data and attest to their treatment relationship with the patient at the time of connection. Response: While payers might utilize a process for providers to attest to a treatment relationship at the time of the data request, we did not propose, nor are we finalizing such a requirement. This is not the only way to attribute patients, but impacted payers are certainly permitted to utilize a provider attestation as part of their attribution process (discussed in section II.B.3.a. of this final rule). Our regulations do not VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 prohibit using an attestation where another law that permits disclosure requires an attestation. Comment: Multiple commenters sought clarification on whether CMS’s 1 business day proposed requirement complies with the 21st Century Cures Act (Pub. L. 114–255, Dec. 13, 2016) (Cures Act) around information sharing ‘‘without delay.’’ Response: We refer readers to section II.A.2.a.iii. of this final rule for a discussion of how our timeline requirements relate to ONC information blocking regulations. Comment: A commenter recommended that CMS require payers to notify providers once they have received a request and the specific date a provider should expect to receive information in response. Response: While we did not propose such a requirement, it would be good practice for the payer to verify that they have received the request for patient data from the provider. We expect payers to have a process for providers to track their requests. Additionally, it would benefit providers for them to receive a notification if the patient cannot be attributed to them. In the DPC pilot, participating providers have the ability to request data for a patient with whom they have no prior treatment relationship, however they will receive a response with no data if they do so. j. Interaction With HIPAA Privacy, Security, and Administrative Transaction Rules Under our policies, all data shared and received via the Provider Access API must be handled in a way that is consistent with all applicable laws and regulations. Payers and health care providers that are covered entities under the HIPAA Rules 46 are subject to the HIPAA Privacy and Security Rules.47 Adherence to both the HIPAA Privacy and Security Rules helps to ensure that the covered entity disclosing patient data through the Provider Access API has appropriate security protocols in place. These include, but are not limited to, administrative and technical safeguards, such as security management processes; 48 access 46 Under the HIPAA Rules at 45 CFR 160.103, a ‘‘covered entity’’ includes a health care provider who transmits any health information in electronic form in connection with a transaction covered by the subchapter. See also definitions of health care provider and transaction at https://www.ecfr.gov/ current/title-45/subtitle-A/subchapter-C/part-160/ subpart-A/section-160.103. 47 45 CFR parts 160 and 164, subparts A, C, and E. Department of Health and Human Services (2022). Security Rule Guidance Material. Retrieved from https://www.hhs.gov/hipaa/for-professionals/ security/guidance/?language=es. 48 See 45 CFR 164.308(a)(1). PO 00000 Frm 00044 Fmt 4701 Sfmt 4700 controls; 49 and audit controls.50 Regardless of whether a provider meets the definition of a covered entity under the HIPAA Rules at 45 CFR 160.103, there may be state laws that require certain privacy and security protections for an HIE. Additionally, other laws, such as the regulations that focus on confidentiality of substance use disorder patient records at 42 CFR part 2 or state privacy laws, may require the payer to obtain the enrolled individual’s permission to disclose certain health information. We requested comment on any other considerations regarding state privacy or other laws that may be implicated by our proposals. Commenters provided many thoughts and recommendations related to the Provider Access API’s intersection with existing privacy laws, including the HIPAA Privacy Rule. We thank the commenters for their perspectives and will use the feedback to inform future guidance, educational resources, and/or rulemaking. We remain committed to safeguarding patient information across the health care industry. Our policies provide an opportunity to engage patients in their data sharing and privacy rights while offering them the opportunity to more meaningfully engage with their care. Our policies will not alter any obligation for providers or payers to comply with applicable law, including obligations for HIPAA covered entities to follow the HIPAA Rules. Such other applicable law includes, but is not limited to, standards regarding the use and disclosure of PHI, administrative, physical, and technical safeguards and other security provisions, and breach notification. The minimum required security framework of the Provider Access API is specified in the technical standards at 45 CFR 170.215 and will allow payers to verify the requesting provider’s identity by using the required authorization and authentication protocols. Authorization refers to the process by which the payer gives the provider permission to access data. The authentication protocols are those that allow the payer to verify the identity of the requesting provider. In addition to using these required protocols, the payer will be required to share the specified data only if it can also attribute the patient to the provider 49 See 45 CFR 164.312(a). the HIPAA Rules at 45 CFR 160.103, a ‘‘covered entity’’ includes a health care provider who transmits any health information in electronic form in connection with a transaction covered by the subchapter. See also definitions of health care provider and transaction at https://www.ecfr.gov/ current/title-45/subtitle-A/subchapter-C/part-160/ subpart-A/section-160.103. 50 Under E:\FR\FM\08FER2.SGM 08FER2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations k. Technical and Standards Considerations Comment: Multiple commenters recommended that CMS detail the requirements for the Provider Access API, with many offering that the rule should describe the workflow, authorization, provider authentication, and attribution processes in more detail. They cautioned that without a standardized governance framework and legal terms, it will be unreasonable to expect payers and providers to establish connections and respond to requests within a set timeframe since they will need to negotiate bespoke agreements. Multiple commenters stated that CMS’s proposed standards and recommended IGs are insufficient for the Provider Access API. One payer cautioned that this would result in payers struggling to comply with the requirements and limited improvements to information exchange. Another commenter warned that the lack of endpoint standardization between payer and provider systems will likely create technical difficulties. A commenter stated that without requiring an IG for the Provider Access API, the data will not be standardized and might not be able to be directly incorporated into a provider’s EHR or practice management system. A commenter also noted that the IGs that CMS recommends do not include direction for how sensitive data such as behavioral health data will be shared and with what privacy guidelines. A commenter was additionally concerned that the recommended IGs are not enough to support the attribution process. Response: We refer readers to section II.G. of this final rule for further discussion regarding the required technical standards for the Provider Access API and IG maturity. Further, the IGs we are recommending, listed in Table H3, are primarily meant to help implement the APIs themselves, not to facilitate related payer processes, like segmenting sensitive data or the attribution process. We recommend that industry look to existing trust community agreements for guidance on a standardized governance framework and legal terms. These agreements include, but are not limited to TEFCA or others used by state and regional HIEs.55 We anticipate that affected entities will need to adopt new practices and methods to enable data sharing with new trading partners, including payers supporting new types of interoperability with providers. This final rule affords flexibility to define those approaches. We will continue to evaluate and consider specifications that are welladapted to meet the legal and regulatory needs for possible future guidance or rulemaking. Comment: A commenter recommended that CMS exercise caution when selecting authentication mechanism requirements for the Provider Access API and stated that allowing simpler authentication mechanisms may make it easier to incorporate into workflows. Another commenter stated that it is unclear the extent to which payers would be expected to support trust and authentication processes for individual clinicians via the OpenID Connect Core standard, versus SMART integration that could rely on organization-level authentication. They noted that without specificity on workflows for exchange 51 Health Level Seven International (2022). FHIR Security. Retrieved from https://www.hl7.org/Fhir/ security.html. 52 See 45 CFR 162.1101(a). 53 See 45 CFR 162.1101(b). 54 See 45 CFR 162.923(a). 55 Office of the National Coordinator for Health Information Technology (2023). Common Agreement for Nationwide Health Information Interoperability. Retrieved from https:// www.healthit.gov/sites/default/files/page/2023-11/ Common_Agreement_v1.1_FINAL_508_1.pdf. lotter on DSK11XQN23PROD with RULES2 using an attribution process, as discussed in section II.B.3.a. of this final rule. While FHIR itself does not define security-related functions, used in combination with appropriate security controls (such as authentication and access control), a FHIR API can and should be implemented in compliance with the HIPAA Security Rule for secure data exchange.51 Under section 1173(a) of HIPAA, the Secretary is required to adopt standards for specific financial and administrative transactions and may adopt standards for other financial and administrative transactions. Although our policies will facilitate sharing claims data from payers to providers for the purpose of helping to improve patient care, the FHIR API data transmission will not be subject to HIPAA transaction standards because the purpose of the exchange would not be to request or issue a payment.52 We also did not propose a mechanism to report health care encounters in connection with a reimbursement contract that is based on a mechanism other than charges or reimbursement rates for specific services.53 The Secretary has not adopted a HIPAA transaction standard applicable to transmitting claims or encounter information for a purpose other than requesting or issuing payment, thus HIPAA administrative simplification standards do not apply to the Provider Access API.54 VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 PO 00000 Frm 00045 Fmt 4701 Sfmt 4700 8801 and authentication, authorization, and consent processes, payers and developers will need to support the numerous permutations that could be adopted by providers to address those needs, increasing complexity and burden. The commenter acknowledged the specifications developed by the HL7® Da Vinci Project and others have begun to address technical aspects of those needs, however, they are not yet mature and, because they are technical standards, do not address needed governance agreements. Another commenter stated that while the FHIR resources in the current Patient Access APIs are mostly reusable, the mechanism for providers to access information is entirely different. The commenter discussed system authentication and access protocols (OAuth and OpenID Connect Core) that are used to enable members to use portal credentials to pull data into a third-party app. The commenter mentions that while OAuth can and should be used for server-to-server connections to enable access to a wider set of data while maintaining security practices, current APIs do not have this capability. Therefore, they believe that this modification to enable a health care provider to access data on multiple patients is a significant change and will require rebuilding the FHIR APIs available for provider access. Response: Impacted payers are required to use authorization and authentication protocols to verify the requesting provider’s identity. However, there is no single security protocol approach that will address all use cases. Additionally, within a single API, implementers may need to utilize more than one protocol to address specific population and trading partner needs. We are finalizing a modification to our proposal to not require the OpenID Connect Core for the Provider Access API. However, we are requiring impacted payers to use the SMART App Launch IG, which includes the capability to perform authentication via OAuth. However, we recognize that other methods such as Backend Services Authorization (which is included in both the SMART App Launch IG Release 2.0.0 and the Bulk Data Access IG v1.0.0), Mutual Transport Layer Security (mTLS), Unified Data Access Profiles (UDAP), or other trust community specified means may be appropriate depending on the needs. E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8802 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations The PDex IG,56 which we are recommending payers use to support the Patient Access, Provider Access, and Payer-to-Payer APIs (see Table H3 in section II.G.4. of this final rule), includes using mTLS for the purposes of authentication. We are also supporting efforts to further refine the specifications for security (that is, authentication) at scale through UDAP via the FAST Security IG and will consider recommending this specification in the future. We recognize the importance of scalable technologies needed to support secure, protected, and authorized connectivity and communication across a wide range of interested parties throughout the industry. There are several approaches available, including the ones cited by commenters, and others implemented by various trust networks operating throughout the United States today. Comment: Multiple commenters supported CMS’s proposed requirement to leverage the Bulk Data Access IG for the Provider Access API, so that if a provider has a panel of patients associated with a single payer, the payer can share those data asynchronously in one transaction. Response: We thank commenters for their support of our policies. As discussed in section II.G. of this final rule, we are finalizing our proposal for impacted payers to use the Bulk Data Access IG at 45 CFR 170.215(d)(1) to support implementation of the Provider Access API. Comment: Multiple commenters recommended that CMS limit the API to only individual data requests and that CMS not require the FHIR Bulk Data Access specification at this time, but instead consider it at a later date after it has been more thoroughly tested by HL7. Multiple commenters also stated that more work is needed on the Bulk Data Access IG before it is mandated, as it has not been adequately implemented; this makes it difficult to assess if it will be able to meet the proposed need and timelines. Multiple commenters also highlighted concerns with the technical functions of the Bulk Data Access IG and noted that large bulk downloads could pull time away from more urgent requests. The commenters recommended that payers be able to put reasonable limits on bulk data requests or that CMS should remove the bulk data transfer from the initial requirements. A commenter stated that CMS should only require impacted payers to respond to requests 56 Health Level Seven International (2020). Da Vinci Payer Data Exchange. Retrieved from https:// hl7.org/fhir/us/davinci-pdex/STU1/. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 for certain patient’s data quarterly. The commenter stated this would ensure that vendors do not set a default of daily retrievals of data that risk sharing more patient information than necessary. Multiple commenters additionally flagged that payers, especially smaller health plans, could struggle to respond to bulk requests within the 1 business day response period and that they could be faced with significant costs to implement this requirement correctly. A commenter stated concern about bulk patient attribution and requested CMS clarification and/or limitations on bulk data sharing requirements. Response: Bulk data exchange can allow payers to prioritize more urgent requests and defer bulk data requests until a later time when sufficient system resources can be allocated to create bulk data export. However, we remind payers that they are still required to comply with the 1 business day timeframe discussed in section II.B.2.i. of this final rule. We emphasize that although we are requiring impacted payers to support FHIR Bulk Data Access at 45 CFR 170.215(d)(1) under this final rule, this requirement does not obligate them to use it for every data exchange if it is not feasible. However, we agree with commenters that impacted payers have leeway to place reasonable limits on bulk data requests. At the same time, we also believe that the benefits of access to these data outweigh any potential concern that vendors will set daily retrievals of data. This is because a provider would first need to request the data for individual patients, as well as the fact that the Provider Access API is better suited to enable discrete provider use when seeing a patient, rather than ongoing patient monitoring. Comment: A commenter stated that the PDex IG could support the opt out process by adding a flag to indicate an attributed member has opted out of provider data sharing. Response: We appreciate the commenter’s suggestion and urge impacted payers to explore ways to leverage FHIR IGs for the other processes that we are requiring in this rule. l. Interaction With ONC Policies Comment: Multiple commenters made recommendations regarding how CMS can work with ONC. They recommended that CMS work with ONC to implement additional requirements as part of the ONC Health IT Certification Program for developers to implement API interfaces into CEHRT in such a way that fits with provider workflow. PO 00000 Frm 00046 Fmt 4701 Sfmt 4700 Multiple commenters also recommended that CMS partner with ONC to create guidance regarding implementation of the Provider Access API and the technical capabilities of payers, EHR vendors, and providers. A commenter further suggested that CMS work with ONC to ensure that both payers and CEHRT vendors are aligned in the technical capabilities to implement Provider Access APIs in a way that does not hamper provider workflow and negate efforts to reduce prior authorization burdens. Multiple commenters strongly encouraged CMS to work with ONC to consider how the Provider Access API could be expanded in future rulemaking to support bi-directional, real-time data exchange between payers and providers to support patient care and to automate prior authorization requests, rather than a one-way data exchange from payer to provider. A commenter stated that including such criteria could ensure compliance with the ONC Cures Act final rule information blocking policies. Response: We appreciate commenters’ support for leveraging of the ONC Health IT Certification Program to ensure APIs are implemented in a standardized fashion. We will continue to work with ONC to explore the adoption of standards and health IT certification criteria where appropriate to streamline data exchange, support interoperability, and increase efficiencies associated with the policies in this final rule, as well as to align and mutually reinforce all of our respective policies. m. Interaction With Trusted Exchange Framework and Common Agreement Comment: Multiple commenters suggested that promoting payer to provider information exchange through the TEFCA may be a better path to achieve improved data exchange, including that of large-scale data sets, between payers and providers, rather than a requirement to implement FHIR APIs. A commenter recommended that CMS should collaborate with ONC and the Recognized Coordinating Entity (RCE) 57 to determine an approach for payers to fulfill the payer to provider exchange requirement by joining the TEFCA network once responses are required for requests made as payment and operations exchange purposes, as described in the Qualified Health Information Network (QHIN)) Technical Framework (QTF).58 57 The Sequoia Project (2023). What is the RCE? Retrieved from https://rce.sequoiaproject.org/rce/. 58 The Sequoia Project (2022). Trusted Exchange Framework and Common Agreement QHIN E:\FR\FM\08FER2.SGM 08FER2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations lotter on DSK11XQN23PROD with RULES2 Response: We will continue to work closely with our ONC colleagues on our policies as they relate to TEFCA, including how it can support the exchange of large-scale datasets. As we wrote in the proposed rule (87 FR 76328), we agree that connections between QHINs can support exchange of patient information between payers and providers and could eventually provide the similar functionality to the Provider Access API. As requirements for using FHIR are incorporated into the QTF in the future,59 Participants and Subparticipants 60 will be positioned to not only exchange the same data using the same standards that we are requiring in this final rule, but to do so under the TEFCA framework. Participants under TEFCA may include those, such as payers, who have entered into a contract to participate in a QHIN. As we expect payer participation in TEFCA to become more widespread in the future, we will continue to explore how we can align policies that require API development or enhancement for payers with TEFCA to ensure Participants and Subparticipants can utilize this network infrastructure to meet these API requirements. We remind commenters that though we are finalizing our proposals for APIs to use and comply with certain standards and technical specifications, this would not preclude payers from also leveraging QHIN-to-QHIN exchange or HIEs/HINs to exchange patient data. Comment: A commenter recommended that CMS establish a consistent set of technical standards between TEFCA and the proposed APIs that are required so that the industry does not have to implement different standards depending upon the exchange partner or mechanism for exchange. Response: ONC and CMS will continue to work closely together to identify ways that TEFCA can support the payer API requirements. We further agree that use of TEFCA could help to reduce burden associated with implementation variation that may arise in developing direct connections with exchange partners. ONC and the RCE are implementing the FHIR Roadmap for TEFCA Exchange to align and accelerate adoption of FHIR across the industry.61 Technical Framework (QTF). Retrieved from https://rce.sequoiaproject.org/wp-content/uploads/ 2022/01/QTF_0122.pdf. 59 The Sequoia Project (2023). FHIR Roadmap for TEFCA Exchange Version 2.0. Retrieved from https://rce.sequoiaproject.org/wp-content/uploads/ 2023/12/FHIR-Roadmap-for-TEFCA-Exchange.pdf. 60 The Sequoia Project (2023). How Can I Participate in TEFCA? Retrieved from https:// rce.sequoiaproject.org/participate/. 61 The Sequoia Project (2023). FHIR Roadmap for TEFCA Exchange Version 2.0. Retrieved from VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 n. Federal Matching Funds for State Medicaid and CHIP FFS Expenditures on Implementation of the Provider Access API In section II.E. of this final rule, we discuss Federal matching funds for certain state Medicaid and CHIP FFS programs’ expenditures related to implementation of the Provider Access API (this was also addressed in the proposed rule at 87 FR 76264). o. Medicaid Expansion CHIP In section II.E. of this final rule, we discuss implementation for states with Medicaid Expansion CHIP programs (this was also addressed in the proposed rule at 87 FR 76264). 3. Additional Requirements for the Provider Access API Additional requirements for the Provider Access API regarding attribution, patient opt out process, patient resources, and provider resources are discussed in the sections that follow. a. Attribution Patient attribution is a method of identifying a patient-provider treatment relationship. Attribution is a critical component to ensure that patient health data are shared only with appropriate providers. For purposes of our policies, we use the term ‘‘attribution’’ as shorthand for the determination that a treatment relationship exists between the patient and provider. For the Provider Access API, we proposed to require impacted payers to maintain an attribution process to associate patients with their in-network or enrolled (as applicable) providers to ensure that a payer only sends a patient’s data to providers who have a treatment relationship with that patient. We are aware that the process of attribution can relate to many payer functions, including managing contracts, payments, financial reconciliation, reporting, and continuity of care. We thus encourage payers to use processes that they already have in place to attribute patients to their providers for these other purposes. We expect that many payers will rely primarily on claims data to establish a treatment relationship between a patient and a provider. Other payers might use existing patient rosters for individual providers or organizations, such as ACOs. For new patients, we explained that payers could accept proof of an upcoming appointment to verify the provider-patient treatment relationship. https://rce.sequoiaproject.org/wp-content/uploads/ 2023/12/FHIR-Roadmap-for-TEFCA-Exchange.pdf. PO 00000 Frm 00047 Fmt 4701 Sfmt 4700 8803 We know that many providers already verify coverage with a payer before a new patient’s first appointment. A payer could establish a process that aligns with that query, using some evidence of a scheduled appointment. Once confirmed, the provider would be able to request the patient’s data in preparation for the visit. Payers may have other existing processes that they prefer to use. We did not propose a prescriptive attribution process in order to provide payers the flexibility to use systems and processes they already have in place, where appropriate, or to develop new policies and procedures to ensure that access to a patient’s data through the Provider Access API is limited to providers who have a treatment relationship with the patient. CMS has implemented an attribution process in the DPC pilot for Medicare beneficiaries (the Medicare FFS version of the Provider Access API), which can serve as an example for impacted payers. The pilot requires HIPAA covered entities or their business associates to agree to certain terms of service before data can be sent to them.62 The current Medicare FFS terms of service require each organization to maintain a list of patients that represents the patient population currently being treated at their facilities.63 CMS requires providers to attest that they have a treatment-related purpose to add a patient to their group. This is accomplished by submitting an attestation with every request to add a patient to their roster. This pilot will continue to test methods to accurately attribute patients to their providers. The information gained from this pilot may assist the industry to develop procedures to identify providers under this requirement. In addition, HL7 has developed a HL7 Da Vinci Risk-Based Contracts Member Attribution (ATR) List IG. The ATR List IG does not specify how the payer and provider identify these patients, but defines the protocols, data structure, and value sets to be used for exchanging a Member Attribution List. The Member Attribution List typically contains: (1) plan/contract information which is the basis for the Member Attribution List, (2) patient information, (3) attributed individual provider information, (4) attributed organization information, and (5) member and subscriber coverage 62 Centers for Medicare and Medicaid Services (n.d.). Terms of Service. Data at the Point of Care. Retrieved from https://dpc.cms.gov/terms-ofservice.html. 63 Centers for Medicare and Medicaid Services (n.d.). Attestation & Attribution. Data at the Point of Care. Retrieved from https://dpc.cms.gov/ docsV1.html#attestation--attribution. E:\FR\FM\08FER2.SGM 08FER2 8804 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations lotter on DSK11XQN23PROD with RULES2 information. The DPC pilot program has been working with the Da Vinci Member Attribution List workgroup towards compatibility with that IG.64 The ATR List IG is also informing updates to the PDex IG. We encourage payers to review the information from the workgroup. We further note that the HL7 Argonaut Project, a private sector initiative that advances using FHIR, has developed an IG specifying how to use the Scheduling and Appointment FHIR Resources to communicate this information.65 We solicited comments on our proposal to require payers to maintain an attribution process to associate patients with their enrolled or innetwork (as applicable) providers to ensure that a payer only sends a patient’s data to providers who have a treatment relationship with that patient. We requested comments on other examples of how patients can be attributed to the enrolled or in-network providers from whom they are receiving care, especially for a new patientprovider treatment relationship. We also requested comments on whether and how payers could attribute the patient to the provider at the time a provider makes a request for patient data through the Patient Access API. As discussed in more detail elsewhere, we are finalizing our proposal without changes. i. General Comments on Attribution Comment: Multiple commenters expressed their support for CMS’s proposed requirement that impacted payers maintain a process to verify a provider-patient relationship. Multiple commenters also underscored the importance of developing a patient attribution system to ensure those data are shared appropriately. A commenter further stated that payers should only develop an attribution process for innetwork providers. Response: We thank commenters for their support for this proposal. We emphasize that the requirement we are finalizing—that impacted payers be required to make the specified patient data available to providers—only applies to those that are in-network or enrolled with the payer. However, we encourage payers to consider making the Provider Access API available to out-of-network providers. This rule requires that impacted payers maintain an attribution process to associate patients with their providers. Thus, if 64 Centers for Medicare and Medicaid Services (n.d.). Groups. Data at the Point of Care. Retrieved from https://dpc.cms.gov/docsV2.html#groups. 65 Health Level Seven International (2022). Argonaut Scheduling IG (Release 1.0.0). Retrieved from https://fhir.org/guides/argonaut/scheduling/. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 payers choose to make the API available to out-of-network providers, they would still need to establish an attribution process to ensure that a treatment relationship exists before making patient data available. Comment: A commenter recommended that CMS align patient attribution requirements and processes across payer types and leverage the CMS Innovation Center to identify where the process can be streamlined. A commenter also recommended that CMS permit payers to set reasonable requirements for providers to demonstrate that the provider is treating an individual, which could reduce the risk of providers making unauthorized inquiries in the system. Response: We recognize that there are multiple ways for impacted payers to verify a treatment relationship. Payers may already have a process that they want to use, so requiring a different process that deviates from an established and effective workflow may add burden. We encourage payers to work together to establish industry-wide principles and standards for patient attribution. As previously stated, payers are permitted to set requirements for providers as part of their processes, such as requiring an attestation of a treatment relationship and/or a need for the data. We agree with the commenter that such requirements should be reasonable and not overly burden providers. Comment: A commenter stated that some specialties are referred patients at a higher rate and requested that CMS take into account the additional burdens of the attribution process for providers who may only see a patient once. Another commenter suggested that the final rule should ensure that any attribution process will not negatively impact those patients who have a high number of providers. A commenter further noted the significant technological challenges of attribution and expressed concern that patients that most need their data to follow them through clinicians, systems, and payers are those that are most likely to have data discontinuity due to clinicians receiving erroneous patient data. Response: We emphasize that payers should consider all types of patients and providers when designing their attribution processes to prevent creating disparities. Making the specified data available via API may be particularly beneficial for patients experiencing data fragmentation. Establishing and maintaining an attribution process will benefit patients who may see multiple providers, so that all such a patient’s providers (assuming they are in-network PO 00000 Frm 00048 Fmt 4701 Sfmt 4700 or enrolled) can have access to necessary information. We remind readers that we are not being prescriptive on when attribution needs to take place, as long as it occurs before patient data are made available through the Provider Access API. We encourage payers to perform the attribution prior to the first visit and/or in a reasonable amount of time to determine whether there are legal restrictions on the data that may be shared and so that providers can have the opportunity to review any relevant data in proximity to the patient encounter. Comment: A commenter expressed concern regarding the attribution process for Medicaid patients, noting that developing a proactive process for providers who will see a patient would be challenging for Medicaid agencies. Another commenter stated that there should be special consideration for patients with mental health and substance use disorder issues. For example, proof of upcoming appointments can be an inadequate test of a patient-provider relationship due to high ‘‘no-show’’ or cancellation rates. A commenter also stated that verifying a provider-patient relationship will be difficult to accomplish in a single business day. Response: We understand the concerns of Medicaid agencies, including challenges in attributing new patients, and believe that proof of an upcoming appointment could sufficiently indicate the patientprovider relationship. However, impacted payers have latitude to determine when proof of an upcoming appointment can be used. For example, payers may implement a policy where providers can only successfully receive requested data if they have an upcoming appointment with the given patient within a specific number of days. Such a process can also mitigate potential ‘‘no show’’ or cancellation situations which one commenter cited. Many providers confirm appointments in the days prior to their appointment. A patient who confirms their appointment in proximity to the visit is less likely to cancel or not show. As stated previously, impacted payers must send the requested data no later than 1 business day after the payer receives a request and the following conditions are met: (1) the payer authenticates the identity of the provider and attributes the patient to that provider; (2) the patient has not opted out; and (3) disclosure of the requested information is not prohibited by law. Nothing in the rule requires payers to establish that these conditions are met in one business day; rather, data must be made available E:\FR\FM\08FER2.SGM 08FER2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations lotter on DSK11XQN23PROD with RULES2 through the Provider Access API no later than one business day after these conditions are met. We encourage payers to verify these conditions are met in advance as often as possible. If this is difficult or not possible, such as in the case of new patient visits, we strongly encourage payers to complete the attribution process in a reasonable amount of time with minimal involvement from the provider, so as not to increase burden. ii. Providers’ Role in Attribution Comment: A commenter sought clarification from CMS regarding whether the provider or the payer must maintain records of the attribution. They also asked how to account for ACO or value-based care coverage models that permit patients to choose a provider. Another commenter agreed, pointing out that most attribution processes in these coverage models are currently geared toward identifying a singular accountable primary care physician within value-based arrangements and that often, a patient’s identification of ‘‘their doctor’’ may not match results generated through automated attribution approaches. Response: This final rule imposes on impacted payers the requirement to maintain a process to attribute a patient to in-network or enrolled providers. Payers are responsible for maintaining attribution records and ensuring that only in-network or enrolled providers who have a treatment relationship with the patient (or should they choose, outof-network or unenrolled providers to whom the impacted payer has attributed a patient) have access to patient data. However, the process of attribution inherently requires provider participation in some instances. For example, when a patient has their first visit with a particular provider, we cannot expect the payer to have that information without some provider input. In other instances, payers may involve patients in their attribution processes, especially if they wish to account for providers who might not be identified via existing automated approaches. Should they do so, any such involvement should not be onerous for the patient. Comment: A commenter stated that CMS should allow payers and providers to adopt an approach that assures payers that any provider request for patient data meets the requirements of this rule, while also allowing providers to delegate the ability to request information to support staff. Another commenter sought clarification on whether physicians and their staff would be expected to operate outside of VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 their normal workflows to demonstrate a care relationship with a patient. A commenter sought clarification on whether multiple providers could be attributed to the same patient at a time. A commenter further sought clarification on whether the rendering provider is the provider who has a treatment relationship with the patient, or if the billing provider could also be attributed to the patient to request data using the Provider Access API. A commenter stated that CMS should require payers to make an attribution prior to the first visit. Response: While we are not being prescriptive in how payers should design their attribution processes; we caution that payers should not set overly onerous criteria for providers to prove their treatment relationship with a patient. Both patients and providers will benefit from the provider having access to the specified information; the attribution process should not impede this benefit. Furthermore, it is appropriate for providers to be able to delegate administrative tasks to their staff. Similar to other processes, such as submitting claims, payers should set reasonable requirements that allow staff to provide information or perform tasks on a provider’s behalf. We do not intend to overburden providers or their staff with the attribution process. As stated, we believe that payers can attribute most patients to providers via claims, which should not require providers to operate significantly outside their normal workflows to demonstrate a care relationship with a patient. Furthermore, we acknowledge that patients can (and in many cases should) be attributed to multiple providers who would be able to request access to the patient’s data. This may apply, for example, to a multi-provider practice or an ACO. Comment: Multiple commenters recommended that CMS reevaluate the attribution process as outlined in the proposed rule. Multiple commenters also stated that payers have significantly different attribution processes, and this adds burden to hospitals and SNFs. A commenter agreed that varying attribution processes across payers would increase administrative burden for providers and clinics under the proposed rule. A commenter recommended that CMS permit providers not only to attribute patients through individual requests, but also to be able to submit information in a bulk format by submitting a list of all a payers’ enrollees currently in their care. Another commenter cautioned CMS to not adopt any standard for attribution PO 00000 Frm 00049 Fmt 4701 Sfmt 4700 8805 more rigorous than the HIPAA Privacy Rule and avoid imposing burdensome requirements. Response: We emphasize that the requirement to implement an attribution process applies to impacted payers, not providers. As discussed, a payer may verify the patient treatment relationship in a variety of ways. While verification may necessitate some action by the providers, we strongly encourage payers to implement a process that is least burdensome to providers as possible. When information from providers is required, payers should allow bulk submission in order to impose the least possible burden on providers. Finally, because we did not propose to adopt any attribution standard or method at all, we are not adopting one that is more rigorous than what is required under the HIPAA Privacy Rule. iii. Attribution Process Design and Suggestions Comment: A commenter recommended that CMS establish minimum attribution criteria and a uniform claims attribution process. Multiple commenters suggested that CMS create guidance on best practices and specific ways that payers can accurately attribute patients to specific providers and when a payer can determine that a treatment relationship between a patient and provider has ended to allow flexibility in the attribution process rather. Multiple commenters also stated that payers should be able to ‘‘un-attribute’’ a patient from a provider when a treatment relationship is inactive to protect patient data. A commenter stated that it is crucial for CMS to define the timeline for which the patient attribution roster on both the payer and provider side must be updated to ensure that it is never shorter than the 30 days mandated by some states. A commenter also stated that the attribution process will be difficult because it will require two separate processes, one for new and one for established patients. A commenter further stated that payers will need to prioritize implementation of the Provider Access API, which will make developing an attribution process difficult. Response: In order to permit impacted payers the flexibility to leverage their existing processes or utilize another method that may be the least burdensome for them, we did not propose, and are not finalizing, a standardized attribution method. In the DPC pilot, for a provider to establish a treatment-related purpose for viewing patient data, they must have an existing ‘‘treatment relationship,’’ defined as a E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8806 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations processed claim with the provider’s NPI number for that patient within the past 18 months. The DPC pilot currently does not have the ability for providers to access data for patients before their first claim. As noted in the proposed rule and previously mentioned, with each roster addition or renewal, a provider must also attest that there is an active treatment relationship. We have had significant interest in our DPC pilot from providers and provider organizations that participate in the Medicare program and continue to gather information from interested parties. However, we do not have information beyond what is currently publicly available to share at this time. This DPC process is just one attribution method and we encourage payers to leverage their existing processes and develop methods that work best for them and that place the least amount of burden on providers. Nothing in this final rule would require a specific timeframe after which a treatment relationship expires. Payers are permitted to establish a period after which the treatment relationship is considered inactive and a patient could be un-attributed from a provider. However, many patients may only see a particular provider annually, which would clearly signify a continuing treatment relationship. We did not propose a requirement for providers to maintain a patient roster, though it may be required under other Federal or state regulations or under the provider’s contract with the payer. Finally, we understand that some payers may have challenges implementing an attribution process. One of the reasons we are finalizing a 2027 compliance dates rather than the proposed 2026 dates (see section I.D. of this final rule) is to give impacted payers additional time to prepare and test any new or modified process. We intend to provide more information and education on potential authentication processes prior to the compliance dates. Comment: Multiple commenters expressed concern with how difficult it is to verify the patient-provider relationship. A commenter sought clarification on the intended level of attribution for access to a member’s data. Another commenter stated their belief that the proposed attribution requirement, specifically how a ‘‘treatment relationship’’ is defined, requires further development and feedback from consumers before implementation so that they can feel in control of their data. They noted that it is not uncommon to have dozens of providers involved in a single patient’s care, nor is it uncommon to have a VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 single interaction with a specialty provider, or to have a provider consult another provider on a course of care without the patient’s knowledge. Response: Payers should be able to meet the requirement to have an attribution process by verifying the patient-provider treatment relationship in a variety of ways, as discussed in this section. Payers should consider Federal and state law, internal risk policies, and their own processes to determine what level of assurance they require to attribute a patient to a provider for the Provider Access API. Establishing specific requirements or procedures would add burden to payers who may establish different, but equally acceptable and effective, processes. We do not believe it is necessary to define a ‘‘treatment relationship’’ only for the purposes of this rule. Payers may have different definitions that may be based on Federal or state law, internal policies, or provider contracts. Therefore, an additional definition would be unnecessary, duplicative, and possibly confusing. We do note that if there is doubt about whether a patient and provider are in a treatment relationship, information from the patient could be one method of making that determination. However, we emphasize that placing burden on a patient should only be used a last resort, and only if the benefits of making data available outweigh that burden. In some cases, verifying a treatment relationship could result in providers having access to data about patients they have treated only once and whom they may not treat again. However, we believe that these providers would have little reason to request this information because they would be creating unnecessary work for themselves without benefitting patient care. Further, data from the Provider Access API is only required to be made available to in-network or enrolled providers. Such providers have already been vetted to participate in the impacted payer’s network, so it is unlikely these participating providers would seek out patient data they do not need for patient care. Finally, some impacted payers might utilize an attestation process, as suggested by some commenters, where providers must attest that they have a clinical need for any data they request. A provider requesting data that they do not need could endanger their payer network or contract status if they fraudulently attest that they are only requesting data for patient care, should the impacted payer implement such a policy. We thus believe that the benefits of the Provider Access API outweigh PO 00000 Frm 00050 Fmt 4701 Sfmt 4700 concerns that already-attributed providers will inappropriately request patient data. We look forward to working with interested parties to develop best practices for attribution processes. Comment: A commenter stated that a claims-based approach to verifying a treatment relationship is the most reliable. Conversely, another commenter stated that it was not necessary to verify a treatment relationship through claims data. They recommended using processes that show the onset or evidence of treatment like Admission, Discharge, Transfer (ADT) or Scheduling Information Unsolicited (SIU) transaction. Another commenter stated that a hospital admission letter should be enough for payers to grant the provider access to the Provider Access API for the specified patient. A commenter also encouraged payers to consider whether a provider’s signed order for treatment (on behalf of a patient) is enough to establish this relationship. A commenter highlighted that the CMS companion guide on the HIPAA-mandated eligibility transaction supporting Medicare Beneficiary Matching could serve as a model for data elements that could facilitate attribution.66 These data and the associated eligibility and benefit request essentially serve as proof of a scheduled appointment. A commenter also recommended leveraging TEFCA for the attribution process. Response: Because different approaches and standards for an attribution process continue to evolve, we did not propose to specify how payers should identify whether a specific patient can be attributed to the requesting provider. Instead, we encouraged the community to continue to collaborate on viable approaches. We agree that a claims-based approach is both reliable and puts little, if any, burden on providers. We expect that payers will also find this to be the simplest way to verify the treatment relationship because they will have a record of a treatment relationship as of the most recent date of service on a claim. We also agree that the other methods suggested could be leveraged by payers to attribute patients to providers for the Provider Access API. Comment: Multiple commenters highlighted existing resources or models that CMS could leverage to establish an attribution process. Another commenter recommended that payers be allowed to 66 Centers for Medicare and Medicaid Services (n.d.). HIPAA Eligibility Transaction System (HETS). Retrieved from https://www.cms.gov/ research-statistics-data-and-systems/cmsinformation-technology/hetshelp. E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations use the existing processes to verify treatment relationships, including the ATR List IG. Multiple commenters also stated that this IG could be updated to provide the necessary tools to support implementation of the attribution process and some recommended that CMS adopt that standard when it is mature enough for large scale implementation. Multiple commenters expressed support for HIEs and HINs as unique entities that have the capability to create and manage patient-provider attribution for the Provider Access API. The commenters provided an example from the Active Care Relationship Service (ACRS), which enables organizations to send data files that record the relationships between their providers and patients. Another commenter stated that CMS should work with HIEs to expand capabilities and create IGs and processes for patient matching, attribution, and opt out to support the Provider Access API. Response: We thank readers for their comments and will consider them for future guidance or rulemaking. As we did not propose a specific attribution method, we encourage impacted payers to consider these existing resources and models. As members of the HL7® Da Vinci Project, we will continue to monitor development of the ATR List IG. Impacted payers may already have multiple arrangements in place with providers to support data exchange, and may even participate in community, local, state, or private HIEs. These HIEs may already have a process to attribute patients to providers. To the extent it would benefit payers, we encourage them to work with HIEs and HINs to facilitate the Provider Access API. Nothing in our policies prohibits a payer from using an intermediary to aid with patient matching, data exchange, or data hygiene. Once again, our goal is to allow payers to develop the least burdensome approach to attribution, and we encourage collaboration on potential solutions. Comment: Multiple commenters requested that CMS consider implementing a national, digital patient identification standard. A commenter recommended that CMS implement a standardized patient identification framework to ensure that patient data are not inadvertently co-mingled and does not pose a threat to patient privacy and safety within the Provider Access API. Another commenter stated that an electronic standard should be developed to verify a patient relationship and appointment status. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 Multiple commenters stated the importance of making sure the CEHRT programs require that record requests can only be made when a treatment relationship is present. A commenter recommended that CMS and ONC work together to establish standards for ONC’s Health IT Certification Program. Response: A standard unique health identifier for each individual, which is in accord with numerous commenters’ recommendations, would be associated with a HIPAA standard arising at section 1173(b)(1) of the Act. We will continue to work with our Federal partners as we consider future guidance or additional rulemaking within the ambit of our authority. Comment: A commenter recommended that CMS establish a workgroup or advisory committee to establish an appropriate attribution process. Another commenter recommended that CMS monitor the state of evolving technology and maintain flexibility in its requirements as technology continues to develop. A commenter recommended CMS utilize public feedback to establish minimum criteria as proof of an authentic patient-provider relationship, because a lack of clear guidance in this area may cause disputes between payers and providers regarding the appropriate criteria for establishing proof of a relationship. Response: We intend to continue our work with industry as they develop attribution processes that do not overly burden payers, providers, or patients. Additionally, based on feedback from the public, we believe that the public would benefit from further educational resources, and we will explore avenues by which we may offer those in the future. Comment: A commenter asked whether payers can integrate an attestation of a treatment relationship with a FHIR transaction. Response: While we are not prohibiting use of a FHIR transaction as part of the attribution process, the IGs we are recommending are primarily meant to help implement the APIs themselves, not to facilitate related payer processes, like the attribution process. b. Opt Out We proposed that all impacted payers would be required to establish and maintain a process to allow patients or their personal representatives to opt out of (or if they have already opted out, to opt back in to) having the patients’ data available for providers via the Provider Access API. We noted that this differed from our Payer-to-Payer API, which was PO 00000 Frm 00051 Fmt 4701 Sfmt 4700 8807 structured as an opt in process. Similar to the attribution process, as previously discussed, we did not intend to be prescriptive regarding how this opt out process should be implemented, but payers would be required to give all patients or their personal representatives the opportunity to opt out, including those currently enrolled on the compliance dates, before making patient information available via the Provider Access API, and at any time while the patient is enrolled with the payer. We did not propose to require specific methods for patients to opt out, but anticipated that payers would make that process available by mobile app or on their website. We also anticipated that mail, fax, or telephonic methods may be necessary alternatives for some patients, which payers would have to accommodate. We invited comments on whether we should establish more explicit requirements regarding the patient opt out processes. Our proposal would require impacted payers to allow patients to opt out of the Provider Access API data exchange for all providers in that payer’s network. However, we also encouraged payers to implement processes that allow more granular controls over the opt out process, so patients can opt out of making data available to individual providers or groups of providers. We did not propose to require those more granular controls, as we were concerned about the potential administrative and technical burden this would place on some payers. However, we requested comments about the technical feasibility of implementing an opt out process that would allow patients to make providerspecific opt out decisions, and whether we should consider proposing such a requirement in future rulemaking. We appreciate commenters’ feedback to our requests, and understand concerns about the potential for administrative burden associated with providing patients with more granular controls over data sharing, as well as which specific providers can receive their data. We used the term ‘‘granular’’ broadly because we wanted to know which data elements commenters thought were most important to be able to segment out. We are committed to minimizing the burden on patients and providers as much as possible and continue to weigh the benefits of providing patients with more control over their data against the potential administrative burden on impacted payers. We appreciate the suggestions we received for how to implement a more granular opt out approach and will E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8808 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations consider these suggestions for future rulemaking. We proposed an opt out approach because, as we discussed in the proposed rule, opt in models of data sharing have been shown to inhibit the utilization and usefulness of data sharing efforts between patients and health care providers. We acknowledged that there are positives and negatives to both opt in and opt out policies, and that some patients may prefer to control or direct their health information via an opt in process, which requires affirmative permission from a patient before their data can be shared. However, patients who are less technologically savvy or have lower health literacy may be less likely to use the Patient Access API, so having an opt out policy for the Provider Access API would facilitate sharing data directly with the provider, without requiring action by the patient. We stated our belief that opt out would promote the positive impacts of data sharing between and among payers, providers, and patients to support care coordination and improved health outcomes, which could lead to greater health equity. In formulating our proposal, we carefully weighed the issues related to both opt in and opt out policies, especially as they relate to making data available to providers. We wrote that a policy defaulting to sharing data with providers, unless a patient opts out, appropriately balances the benefits of data sharing with the right of patients to control their health information. As we also detailed in the proposed rule, payers would be responsible for providing patient resources to ensure that patients understand the implications of opting out. We noted that, should patients not opt out of data sharing, then the data that would be made available via the Provider Access API would be available to in-network providers whose identity has been authenticated and to whom the patients have been attributed, meaning that the payer has verified a treatment relationship between the provider and the patient. However, we stated that our proposals, taken together, gave patients ample opportunities to change their data sharing permission as they see fit. As we explained in detail in our proposed rule (87 FR 76260), opt in models can create greater administrative burden for smaller health care organizations, depending on where the responsibility for obtaining and updating the patient’s data sharing permission is held. We also pointed to the fact that a larger health care organization that employed an opt in model, the Veterans Health VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 Administration within the VA, saw the vast majority of provider requests for patient information rejected for lack of patient permission. We additionally stated our belief that an opt out model could address equity issues by ensuring that patients from lower socioeconomic and minority groups, who are more likely to have limited health literacy, can benefit from the improved care that the Provider Access API can facilitate. We believe that data sharing as the default option for all patients enhances both personal and organizational health literacy, as these terms are defined by the Healthy People 2030 report,67 while protecting patients’ choice to limit data sharing. The ability for patients to opt out was specific to the data we proposed requiring payers to share via the Provider Access API. As discussed previously, nothing in the proposed rule would alter any other requirements under applicable privacy and security laws and regulations. If there is other authority to share patient information with respect to which a patient may not opt out, such as disclosures required by law, nothing in this proposal would change the payer’s obligation to disclose that information. However, we encouraged payers and providers to use the proposed Provider Access API as a technical solution to transmit data between payers and providers beyond the scope of these policies, provided such disclosure is consistent with all other applicable requirements, such as the requirements set out in the HIPAA Privacy Rule and the HIPAA Security Rule. We value the importance of safeguarding the quality and integrity of patient health information. We acknowledged that there may be potential program integrity risks associated with sharing patient data under both an opt in and opt out models. We expect that if payers identify any vulnerabilities, they will work to make changes to their operations to address risks that could lead to potential fraud and to limit the impact on patient information. We requested comments on our proposal for a patient opt out framework for the Provider Access API. As discussed in more detail elsewhere, we are finalizing this proposal without changes. 67 Health Literacy in Healthy People 2030 (2020). History of Health Literacy Definitions. Retrieved from https://health.gov/healthypeople/priorityareas/health-literacy-healthy-people-2030/historyhealth-literacy-definitions. PO 00000 Frm 00052 Fmt 4701 Sfmt 4700 i. General Comments on Opt Out Comment: Multiple commenters expressed support for the proposed policy to require an opt out framework for the Provider Access API. Commenters provided various rationales for their support, including that the opt out framework would enable patients to protect and control their health information while still making patient data available to providers, encourage increased data transmission, and allow patients to terminate a provider’s access to their data when the patient no longer has a treatment relationship with the provider. Multiple commenters specifically expressed their support for an opt out approach instead of an opt in approach. These commenters noted that it is less burdensome for payers and that an opt in approach would require patients to have a higher level of education or better technology and health literacy to utilize than an opt out process, which may result in fewer patients having their data exchanged via the Provider Access API under an opt in approach. Response: We appreciate the comments we received in support of our proposal to allow patients or their personal representatives to opt out of the Provider Access API if they do not wish for their data to be made available via the API requirement. We agree with the commenters that an opt out approach will enable patients or their personal representatives to better protect and control their health information while still making patient data available to providers. We remind commenters that the opt out would not necessarily allow patients or their personal representatives to terminate a provider’s access to their data when the patient no longer has a treatment relationship with the provider, because we did not propose to require a granular opt out policy (though some payers might choose to implement such a policy). However, we did note in section II.B.3.a. of this final rule that payers have latitude to determine when a patient-provider treatment relationship ends via their attribution process. Thus, regardless of the opt out granularity, payers should also use their attribution process to determine whether and when an individual provider should have access to a patient’s data via the Provider Access API. Comment: Other commenters voiced their concerns with an opt out approach but did not specifically recommend that CMS take a different approach. Multiple commenters noted that offering patients an opportunity to opt out would limit information sharing and that E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations information sharing is important to facilitate the prior authorization process. Multiple commenters also stated their belief that an opt out approach would reduce, or even remove patient control over their health information. Those commenters stated that because CMS expects most patients not to opt out, the confidentiality of this patient data will effectively not be the default. Response: For reasons we discussed in both the proposed rule and previously, the opt out approach appropriately balances the benefits of data sharing with the ability of patients to control their health information. All patients will be given the opportunity to opt out of our Provider Access API policy. We agree that this information sharing is important to improve the efficiency of the prior authorization process and to ensure that patients have timely access to the care they need. While patients may opt out of data flowing from their payer to their provider via the Provider Access API, they cannot opt out of the prior authorization process established by their payer or the communications between their provider and payer that enable that process. Comment: Multiple commenters recommended that CMS adopt an opt in approach instead of an opt out approach for the Provider Access API. Commenters provided various rationales for recommending an opt in approach, including that an opt in would give patients more control over their data and is more understandable than an opt out process. A commenter explained that while they support an opt in approach, they do not agree that it would benefit disadvantaged people (such as people with low health literacy or limited English proficiency) because patients may not understand what it means to give permission for data sharing. Multiple commenters also supported an opt in approach due to patient privacy concerns with opt out. Specifically, a commenter with concerns about sharing patients’ mental health and substance use information recommended that CMS adopt an opt in process, including a requirement for patients to provide written authorization before such information is accessible through the Provider Access API. The commenter explained that there are laws in place requiring a written authorization from a patient to disclose mental health and substance use information. Another commenter also recommended that CMS align requirements for the Provider Access API opt out approach with consent requirements under 42 CFR part 2. A VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 commenter further stated their belief that most patients would choose to opt into the Provider Access API if they are adequately informed of their rights and the potential for API data exchange. Response: We refer readers to our proposed rule for a full discussion of why we proposed an opt out patient permission framework (87 FR 76259). As discussed elsewhere, we are finalizing a requirement that impacted payers must provide patients with plain language information about the Provider Access API, including how to opt out of data sharing, in order to help maximize patient control. This requirement should ensure that patients, including those with low health literacy or limited English proficiency, are aware of their rights and have the opportunity to make an informed decision about whether or not to allow payers to share their data with their providers through the Provider Access API. We further remind readers that all data sent and received via the Provider Access API must still be handled consistent with all other applicable laws and regulations regarding disclosure of these data. For instance, rules of confidentiality for patient records associated with mental health or substance use disorder, such as 42 CFR part 2, which may require patient consent to share with providers, will still apply. ii. Interaction With HIPAA Comment: Multiple commenters stated that a process requiring patient permission for data sharing via the Provider Access API is not necessary because the HIPAA Privacy Rule permits PHI disclosure without patient permission under certain circumstances. Specifically, they reasoned that patient permission is not necessary if the PHI disclosed via the Provider Access API falls within the scope of HIPAA treatment, payment, and operations (TPO) disclosures, and recommended that CMS limit the data shared via the Provider Access API to the scope of permitted TPO disclosures. In support of their recommendation, these commenters noted that requiring an opt out process could be confusing and cumbersome to patients, negatively affect patient care, and would conflict with Federal and state laws (including the HIPAA statute). In a similar vein, commenters stated that CMS should rely on the HIPAA Privacy Rule requirements instead of requiring an opt out process, and a commenter suggested that CMS require impacted payers to include the Provider Access API exchange in their HIPAA Notices of Privacy Practices (NPP). Another commenter recommended that CMS PO 00000 Frm 00053 Fmt 4701 Sfmt 4700 8809 make it clear that payers may still share certain patient health information with providers if it falls under the scope of a TPO disclosure, even when a patient elects to opt out of data sharing. Multiple commenters recommended that CMS provide additional guidance as to whether the Provider Access API is to be used for purposes beyond treatment, and indicated that providers should be able to access payer data for other purposes permitted under the HIPAA Privacy Rule, such as payment. Response: We understand that there are those who believe that an opt out patient permission process is not necessary, given existing HIPAA Privacy Rule provisions that permit PHI disclosure without an individual’s authorization under certain circumstances. However, we emphasize that by virtue of this final rule, impacted payers would be required to disclose any PHI specified within the content standards for the Provider Access API, if the applicable requirements of this rule were met. That disclosure would be permitted under the HIPAA Privacy Rule as ‘‘uses or disclosures that are required by law,’’ 68 rather than as a permitted TPO disclosure. Required by law disclosures are limited to the relevant requirements of such law, not to the HIPAA minimum necessary standard,69 thereby ensuring that all content required by our Provider Access API policy may be disclosed. Because our policies would potentially give providers access to more than what would have been considered to be the minimum necessary PHI under the HIPAA Privacy Rule for certain purposes (for example, administrative data in the USCDI that would not be used for treatment purposes), we are requiring impacted payers to give patients or their personal representatives an opportunity to opt out so that they have some control over whether or not to share this additional data with their provider(s). We believe that patients should control their own data to the extent possible and with an opt out approach to data sharing, we are giving patients this opportunity. Where the requirements of this rule change how covered entities or their business associates may use or disclose PHI, covered entities should consider their obligations under the HIPAA Privacy Rule. We emphasize that the opt out process described here only applies to the Provider Access API policies in this final rule. That is, the requirement for impacted payers to share individual 68 See 69 See E:\FR\FM\08FER2.SGM 45 CFR 164.512(a). 45 CFR 164.502(b)(2)(v). 08FER2 lotter on DSK11XQN23PROD with RULES2 8810 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations claims and encounter data, all data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI), and certain information about prior authorizations maintained by the payer with a date of service on or after January 1, 2016, with in-network providers who have a treatment relationship with the patient. If a patient or their personal representative opts out under our policy, then the impacted payer should not share these data with a provider who requests it under this policy. However, there may be other permissible bases for payers and providers to share data, such as under the HIPAA Privacy Rule’s permitted uses and disclosures to carry out TPO. Patients or their personal representatives do not have the ability to opt out of a payer or provider using the API itself as a mechanism for sharing data under such bases for disclosure. We also note that the data that may be shared under other permissible bases, such as the TPO exception, may overlap with the data required to be shared by our Provider Access API policy. For instance, a payer may be permitted to disclose clinical data included in a content standard at 45 CFR 170.213 with a health care provider for treatment purposes under 45 CFR 164.506(c)(2). If that disclosure is permissible, a patient opting out of the Provider Access API policy in this final rule would not prohibit a payer from using the Provider Access API to make that disclosure. In addition, there may be permissible bases for sharing data outside the scope of our Provider Access API policy. As an example, payers may be permitted to disclose clinical data that is not included in a content standard at 45 CFR 170.213, such as information related to SDOH, under the TPO exception. Similarly, a patient or personal representative opting out of the Provider Access API policy in this final rule would not prohibit a payer from using the Provider Access API as the mechanism to make that permissible disclosure. Per 45 CFR 164.506(b), covered entities may create a process to obtain consent from an individual to use or disclose PHI to carry out TPO. Per 45 CFR 164.522(a), individuals also have the right to request restrictions on how a covered entity will use and disclose PHI about them for TPO. Except in limited circumstances, a covered entity is not required to agree to an individual’s request for a restriction. Where a covered entity agrees to a restriction, it is bound to it unless the restriction is subsequently terminated. We emphasize that the opt out process VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 described in this final rule is specific to the Provider Access API policy and therefore is not, on its own, a consent mechanism per 45 CFR 164.506(b) or an agreed-upon restriction per 45 CFR 164.522(a). Payers should make these nuances clear to patients in their required educational resources, so that patients understand that their PHI may still be shared in some instances, even if they or their personal representative opts out of the Provider Access API policy. iii. Interaction With Health Information Exchanges Comment: Multiple commenters noted that HIEs would be great partners for payers when implementing the Provider Access API, with one noting that they could be used to reduce the number of endpoints providers would need to query for patient information. Commenters suggested that because many providers already have connections to HIEs set up within their EHRs, HIEs could act as a conduit for the information impacted payers are required to make available. Furthermore, commenters stated that HIEs could make available patient clinical data beyond what is maintained by the payer. Response: We agree that HIEs could be helpful partners for payers when implementing the Provider Access API and nothing in this rule would prohibit an impacted payer from partnering with an HIE to meet its requirements. As a commenter noted, HIEs have extensive experience and expertise with patient matching and attribution, as well as with various consent models. We additionally agree that provider participation in an HIE can reduce the number of endpoints they would need to query for care coordination and treatment. We further encourage payers to look to HIEs or HINs as models for implementing a legal framework for data exchange. Comment: Multiple other commenters recommended that CMS both explain and reexamine its interpretation of 42 CFR 431.306(d) and 457.1110(b) to prohibit Medicaid and CHIP programs from releasing beneficiary information to outside sources without first obtaining permission from the beneficiary or their personal representative. The commenters stated that CMS’s current interpretation would effectively prohibit Medicaid agencies from participating in HIEs for Provider Access API and TPO purposes. The commenters stated that CMS should consider expanding this to include outof-network providers. PO 00000 Frm 00054 Fmt 4701 Sfmt 4700 Response: We do not agree that 42 CFR 431.306(d) and 457.1110(b) prohibit Medicaid or CHIP agencies from contracting with an entity that offers the technology to allow for digital access and transfer of a patient’s medical records, often referred to as an HIE. Section 1902(a)(7) of the Act, which our regulations at 42 CFR part 431, subpart F, implement, requires that a state’s Medicaid plan provide safeguards which restrict the use or disclosure of information concerning Medicaid applicants and beneficiaries to purposes directly connected with administration of the state plan. Our regulations at 42 CFR part 431, subpart F, set forth requirements for states to safeguard Medicaid applicants’ and beneficiaries’ information in accordance with section 1902(a)(7) of the Act, including requirements for safeguarding the information, what types of information must be safeguarded, and when and how to release otherwise safeguarded information. The same requirements also apply to separate CHIP programs through a cross reference at 42 CFR 457.1110(b). The disclosures of beneficiary data to an HIE contracted to develop and maintain the required Provider Access API would be directly related to the administration of the state plan, because sharing beneficiary data through the Provider Access API supports the provision of services for beneficiaries, as described at 42 CFR 431.302(c). Access to beneficiary data could help a provider better manage a beneficiary’s total care because the data would provide a more in-depth medical history, enable more informed decision making, and potentially prevent orders for, or the provision of, duplicative services. Further, under section 1902(a)(4) of the Act, Medicaid agencies may contract with organizations to enhance the agency’s capability for effective administration of the program. The regulation at 42 CFR 431.306(d) generally requires states to obtain permission from an individual Medicaid or CHIP applicant or beneficiary, or their personal representative, before responding to a request for information from an outside source, or disclosing that applicant’s or beneficiary’s data safeguarded under 42 CFR 431.305. There is no requirement for a state Medicaid or CHIP agency to obtain permission from an individual or family member prior to providing information about a Medicaid or CHIP beneficiary to an enrolled Medicaid or CHIP provider because enrolled providers are not outside sources as described at 42 CFR 431.306(d). Enrolled Medicaid and CHIP E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations providers are part of a state’s Medicaid and/or CHIP FFS programs because they are contracted to support the agency’s administration of its Medicaid or CHIP state plan. Specifically, an enrolled Medicaid or CHIP provider has a provider agreement with the Medicaid or CHIP agency to provide Medicaid or CHIP benefits and services under the state plan. Thus, the state Medicaid agency could share Medicaid or CHIP beneficiary information with enrolled providers for purposes directly connected to administration of the state plan, without prior permission from the Medicaid or CHIP beneficiary required by 42 CFR 431.306(d) and 457.1110(b) respectively. Similarly, state Medicaid and CHIP agencies may share Medicaid and CHIP beneficiary information with entities with which the state Medicaid or CHIP agency has contracted to support the agency’s administration of its Medicaid or CHIP state plan. Such contractors would not be considered ‘‘outside sources’’ because they are contracted to carry out functions directly related to administration of the state Medicaid or CHIP plan, such as case management and long-term services and supports for Medicaid or CHIP beneficiaries. Thus, if a state Medicaid or CHIP agency contracts with an HIE to carry out administrative functions of the state’s Medicaid or CHIP program, such as developing and maintaining the required Provider Access API, the HIE would not be considered an ‘‘outside source’’ and the state Medicaid or CHIP agency could share Medicaid or CHIP beneficiary information with the HIE for the purposes directly connected to administration of the state plan, without prior permission from the Medicaid or CHIP beneficiary required by 42 CFR 431.306(d) and 457.1110(b) respectively. In addition, to receive beneficiaries’ information from the Medicaid or CHIP agency, Medicaid or CHIP providers, plans, or contractors must be subject to standards of confidentiality comparable to those of the state Medicaid or CHIP agency in accordance with 42 CFR 431.306(b) and 457.1110(b) respectively. Furthermore, the Medicaid regulation at 42 CFR 434.6(a)(8) requires that each of the state Medicaid agency’s contracts must provide that the contractor safeguards information about beneficiaries as required by 42 CFR part 431, subpart F. Under these requirements, if a state Medicaid or CHIP agency contracted with an HIE or other entity, the contractor would be required to meet the same standards of confidentiality as the state Medicaid or CHIP agency (as set forth in section 1902(a)(7) of the Act and our VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 implementing regulations at 42 CFR part 431, subpart F), including but not limited to— • Providing safeguards that restrict the use or disclosure of information concerning applicants and beneficiaries to purposes directly connected with the administration of the plan in accordance with section 1902(a)(7) of the Act and 42 CFR 431.300 and 431.302; and • Not disclosing data to an outside source, such as providers that are not enrolled with the state Medicaid or CHIP agency, and that might be participating in an HIE, without prior permission from the individual in accordance with 42 CFR 431.306(d). iv. Opt Out Process Design Comment: Commenters provided thoughts about the implementation of the proposed opt out requirement. Multiple commenters suggested that CMS require a standardized opt out process to improve the patient and provider experience. A commenter expressed concern that the proposed implementation flexibility could be difficult for patients to navigate, while another commenter requested clarification on what opting out and opting back in means. Response: We agree that it is important to make it easy for patients or their personal representatives to opt out of data sharing. However, it is also important to give payers flexibility in how they implement the opt out process required by this rule. We recognize that payers’ approaches may vary depending on their systems, capabilities, and specific enrollee population. Requiring a specific process could impose unnecessary burden on payers. We remind readers that regardless of what process payers choose, a patient or their personal representative must have the ability to change their data sharing permission at any time. For example, if a patient or their personal representative previously opted out of having their data shared under the Provider Access API policy, they should be able to reverse this decision, effectively choosing to opt back into having their data shared under the Provider Access API policy. We additionally note that each of our policies in this final rule is targeted toward individual patients, not any family members that may be covered through the same benefits. In some cases, applicable law may allow one individual (such as a parent or guardian) to act as a personal representative for another individual covered under the same benefits (such as a minor) and could therefore opt out of data sharing under the Provider Access API for that person. No data PO 00000 Frm 00055 Fmt 4701 Sfmt 4700 8811 should be shared about any patient that has opted out (or whose personal representative has opted out), regardless of whether another patient covered under the same benefits has chosen to not opt out. We will continue to monitor implementation of the Provider Access API opt out requirement to ensure payers’ opt out processes for the Provider Access API are easy and intuitive for patients or their personal representatives to use. Comment: Commenters recommended that CMS include several additional, explicit requirements related to the Provider Access API opt out process. Multiple commenters also recommended requiring or permitting payers to incorporate the opt out process into their existing platforms and communications, including patient portals, payers’ websites, and within payers’ regular communications with patients. A commenter encouraged CMS to collaborate with interested parties to develop a single platform for patients to give permission for data sharing. Response: While we are not requiring impacted payers to incorporate their opt out processes into their existing platforms and communications, we generally expect that that would result in the least amount of burden on payers and patients. There are solutions available that could be leveraged to manage permissions across payers, such as HIEs. We encourage impacted payers to investigate a variety of options to determine the solution that is best for them and their patients. Comment: Multiple commenters made recommendations related to the accessibility of the opt out process. They recommended that CMS require impacted payers to provide options to patients for opting out of data sharing that are accessible to patients with varied technological literacy (that is, via mail, fax, and phone). A commenter recommended that opt out information be available for the Provider Access API in multiple languages to reduce disparities and barriers to patients’ understanding of the opt out process. Another commenter recommended that CMS establish clear expectations for how payers should accommodate patients who may have difficulty accessing the opt out process or that CMS should track the extent to which patients encounter difficulties with opting out of data sharing. A commenter further recommended that payers collect patients’ opt out elections at the point of treatment, so that it is clear which provider(s) have access to the patient’s data via the Provider Access API policy. Response: We agree with commenters that payers should make efforts to E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8812 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations ensure their patients or their personal representatives have the opportunity to opt out of data sharing under the Provider Access API policy and should be accommodated accordingly. These accommodations certainly include accounting for varied technology literacy and language barriers (see section II.B.3.c.ii. of this final rule for a discussion on plain language and existing requirements to make information accessible in other languages or formats). However, we do not want to be overly prescriptive to payers, as we believe they would know best how to accommodate their particular patient population. We disagree that payers should collect patient opt out elections at the point of treatment because we intend for these data to be available to the provider before patient appointments, and such practices are also outside the scope of a provider’s role. We therefore intend to monitor patient experience and payer compliance with the opt out process and will consider our observations through this monitoring for future rulemaking. Comment: Multiple commenters recommended implementing processes for payers to notify providers of patients’ election to opt out of the Provider Access API data exchange. A commenter identified some potential implementation challenges for providers, including that tracking patient permission would be challenging and that the opt out approach could create segmented data captures and multiple workflows. Another commenter flagged that CMS should not rely on physicians to educate patients on the intricacies of APIs, instead encouraging CMS to provide standardized language and guidelines to payers around how the process to opt out will be communicated to patients and the process for collecting and communicating opt outs to physicians. Response: While we are not requiring impacted payers to notify providers of their patients’ election to opt out of the Provider Access API data exchange, we agree that notification can increase the utility of the Provider Access API for providers. We remind readers that we are not requiring providers to track patient data sharing permission, educate patients about their data sharing options, or utilize the Provider Access API at all. However, we believe that giving providers access to more patient data will benefit the care that they provide, and we encourage them to adjust their workflows and work with their EHR developers to take advantage of the data availability through this new mechanism. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 Comment: A commenter noted that it will take time for payers to process opt out requests from patients or their personal representatives who choose to opt out of having their data shared after enrollment. Another commenter suggested that patients should be able to record their permission through multiple channels (for example, OAuth 2.0, portal access, and the FHIR consent profile). A commenter also stated that payers may have to design related processes to allow patients to opt in to sharing of sensitive information that adhere to state or local privacy laws. A commenter further sought guidance on whether specific consent language would be required for patients or their personal representatives to opt in and whether an opt in election may be included in the HIPAA authorization form or other enrollment materials. Response: Payers will have flexibility in how they process patient data sharing permission and the channels that patients may use to make their election. We caution, however, that any such opt out channels should be both optimally accessible to patients or their personal representatives and not onerous for them to navigate. Part of managing an opt out process will include cognizance of other laws that may restrict data sharing, such as state privacy laws. In fact, if other applicable law requires an opt in permission for data sharing, payers may integrate both the Provider Access API opt out and other permission gathering processes to simplify patients’ ability to control their data, to the extent permitted by law. Finally, regarding the commenter seeking specific consent language for opt in and clarification related to leveraging the HIPAA authorization form for this purpose, we emphasize that this final rule finalizes an opt out framework for the Provider Access API, not an opt in. We further note that compound HIPAA authorizations are generally prohibited, per 45 CFR 164.508(b)(3). v. Opt Out Timeframes Comment: Multiple commenters stated that patients or their personal representatives should be allowed to opt out at any time. Other commenters supported payers providing an option to opt out at a certain time, such as at the time of enrollment. A commenter recommended that CMS allow payers 30 days to process a patient’s request to opt out and stop sharing the patient’s data via the Provider Access API. Response: We agree that patients or their personal representatives should be able to opt out of data sharing under the Provider Access API policy at any time PO 00000 Frm 00056 Fmt 4701 Sfmt 4700 and we are requiring impacted payers to give their patients the opportunity to do so. As discussed in section II.B.3.c. of this final rule, no later than one week after the start of coverage and annually, patients will need to be given information about their opt out rights and instructions both for opting out. We remind readers that ‘‘start of coverage’’ is defined differently, as applicable, for each type of impacted payer. We refer readers to section II.C.3.c.i. of this final rule for discussion of these differences. We do not agree that the opt out option should be time-limited, as that reduces patient control over their health data. c. Patient Educational Resources Regarding the Provider Access API To help patients understand the implications of the opt out provision for the Provider Access API, we proposed to require impacted payers to disseminate certain educational resources to their patients. We proposed that those resources would include information about the benefits to the patient of API data exchange, their opt out rights, and instructions both for opting out of the data exchange and for opting in after previously opting out. We proposed that payers would have to provide this information, in nontechnical, simple, and easy-tounderstand language, before the first date on which the payer makes patient information available through the Provider Access API, at the time of enrollment and annually thereafter. We also proposed that payers would be required to make this information available at all times, in an easily accessible location on payers’ public websites. We did not propose to require this information to also be distributed to patients’ personal representatives. However, we highly encourage impacted payers to do so, especially if distributing other materials to personal representatives is typical. We also did not propose specific text or format for this information, but requested suggestions and comments on whether required content or format would be beneficial or burdensome. In particular, we sought comments on language explaining how patient data that is shared through the Provider Access API could be used. We anticipated that payers would want to include this information in their regular communications, such as annual enrollment information, privacy notices, member handbooks, or newsletters. However, we requested comment on the most appropriate and effective communication channel(s) for conveying this information to patients. We also requested comment on whether E:\FR\FM\08FER2.SGM 08FER2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations lotter on DSK11XQN23PROD with RULES2 a requirement to provide this information at the time of enrollment and annually is appropriate, or whether we should require payers to share this information more frequently. We believe it is important to honor patient privacy preferences. Offering patients educational resources about their right to opt out of the Provider Access API data sharing is thus fundamental to empowering patients with respect to their data. As discussed in more detail, we are finalizing a modification to these proposals, that impacted payers must provide this information to patients no later than one week after the start of coverage. ‘‘Start of coverage’’ is defined differently, as applicable, for each type of impacted payer and we refer readers to section II.C.3.c.i. of this final rule for discussion of these differences. i. Dissemination Comment: Multiple commenters supported the proposed requirement for payers to disseminate patient educational resources and made recommendations for communicating with, or sending information to patients. These recommendations include disseminating educational resources through existing patient portals, letters, text messages, and information posted on websites, in handbooks, and by mail. Conversely, a commenter recommended that CMS not require physical materials be sent annually to patients. The commenter recommended that payers should only send hard copies to patients who have opted out of data sharing. However, another commenter stated that separate patient resources for the Provider Access API are not necessary at all. A commenter additionally stated that many plan renewals do not actually generate patient-visible paperwork, forms, or formal documents of any sort and provided examples for how frequently sharing patient resources currently occurs. A commenter further stated that payers should have the flexibility to communicate with their members in a manner consistent with a set format and content for consistency and clarity. Response: We emphasize that impacted payers can indeed use their existing processes for producing patientfacing resources and will be permitted to send their patient education resources through the communication channels they think are most effective for reaching their patients, including emails, messages through a payer portal, or physical mail. It is not our intention to overburden payers, and thus we do want to be overly prescriptive in a way that that will unduly disrupt how they VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 currently communicate with their patients. We disagree that only patients who have opted out of data sharing should receive these resources. Under our policies, patients may choose to change their data sharing permission at any time and we thus believe that they should remain maximally informed of their choices. We are also finalizing a modification to the proposed rule regarding payer deadlines, to give payers more clarity and an appropriate amount of time to meet these requirements, as well as to align with policies we are finalizing for the Payer-to-Payer API (see section II.C.3.c.i. of this final rule). Specifically, payers will be required to provide patients, no later than one week after the start of coverage, information about the benefits of API data exchange with their providers, their opt out rights, and instructions for both for opting out of data exchange and for opting in after previously opting out. This timeframe is intended to provide a reasonable amount of time after a payer receives confirmation that a patient will be enrolled in coverage with them. As further discussed in section II.C.3.c.i., to ensure feasible timeframes, we are finalizing deadlines to account for situations when coverage starts prospectively or retroactively for MA plans and QHPs issuers on the FFEs and retroactively for Medicaid and CHIP. Comment: Multiple commenters supported our proposal to require impacted payers to provide patient education resources at enrollment and annually thereafter. A commenter stated that educational resources could also come from providers at patient interactions. Other commenters expressed that CMS’s requirements should not add burden to providers or interfere with their clinical workflow. A commenter recommended that CMS not require Medicaid agencies to provide information on the Provider Access API opt out policy more frequently than at member enrollment and annually. The commenter stated that it would be resource intensive and would require new workstreams and member outreach processes. Response: We thank commenters for their support of our proposal to require impacted payers to provide patient education resources at enrollment and annually thereafter (though we are finalizing a modification to this proposal, as explained above). We did not propose to require any role for providers, as we agree this would increase their administrative burden. We also agree with commenters that providing these resources more frequently would indeed increase PO 00000 Frm 00057 Fmt 4701 Sfmt 4700 8813 burden, which is why we did not propose for impacted payers to do so. ii. Content Comment: Multiple commenters suggested that CMS require payers to use clear and plain language and ensure the opt out policy is prominent. Response: We agree with commenters’ sentiments and thus proposed that patients should be able to easily understand the patient education resources. In response to both these comments and comments on our opt out proposals, as well as for consistency with other policies, we are finalizing this rule slightly differently from how it was proposed. We had proposed that impacted payers provide patient education resources in ‘‘non-technical, simple, and in easy-to-understand language,’’ but our finalized requirement is that they use ‘‘plain language.’’ This change is not intended to alter that the educational information be non-technical, simple, and easy-touse, but to make clear that we encourage impacted payers to follow the Federal Government’s plain language guidelines. Those guidelines were informed by the Plain Writing Act of 2010, which requires Federal agencies to use clear government communication that the public can understand and use. That statute only applies to Federal Government agencies, but the plain writing guidance 70 that has been developed for the Federal Government will be useful for impacted payers when developing educational resources for patients. We note that providing these patient educational resources is a separate requirement from the requirement to create an NPP under the HIPAA Privacy Rule.71 Comment: A commenter expressed concern about language access, while another recommended CMS set inclusivity requirements, based on a payer’s patient population, for translating into languages other than English. Multiple commenters recommended that notices about the Provider Access API be focus group tested, written in accurate but positive language (so as not to unduly discourage participation), and translated into the required threshold languages for the coverage area. 70 General Services Administration (n.d.). Federal plain language guidelines. Retrieved from https:// www.plainlanguage.gov/guidelines/. 71 Department of Health and Human Services (n.d.). Notice of Privacy Practices for Protected Health Information. Retrieved from https:// www.hhs.gov/hipaa/for-professionals/privacy/ guidance/privacy-practices-for-protected-healthinformation/. E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8814 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations Response: Impacted payers may already be required to provide plain language resources in languages other than English, per 45 CFR part 92, which requires impacted payers (as health programs or activities under that section) to provide meaningful access to individuals with limited English proficiency and accessibility requirements for individuals with disabilities. The requirements of that part apply to impacted payers, as described at 45 CFR 92.3. Additionally, this rule does not affect standards already in place for specific payers on state or Federal levels. For example, 45 CFR 156.250 requires QHP issuers on the FFEs to provide information in accordance with the accessibility standards for individuals with disabilities and individuals with limited English language proficiency at 45 CFR 155.205(c). Other impacted payers might have their own standards for accessible patient-facing resources, as well, that would not be affected by this final rule. Comment: Multiple commenters recommended, for ease of readability, that resources or notices be written at a certain grade level. Multiple commenters recommended that CMS amend the patient resources proposal to require impacted payers to write resources at a fourth-to-sixth grade reading level. Response: While we agree that these resources need to be understandable, we do not believe that it is prudent to establish a specific ‘‘grade level’’ requirement. A grade level score is based on the average length of the words and sentences. Readability formulae vary and the grade level scores for the same text can differ depending on how it is used. Furthermore, edits that are made to make text score at a lower grade level can produce choppy text that lacks cohesion. Comment: A commenter did not support the development of patient education resources that may be duplicative or confusing to patients, while another did not support the proposal for separate patient outreach and education if the data sharing under the Provider Access API is permitted under the HIPAA Privacy Rule’s TPO exception. Response: We refer readers to section II.B.3.b.ii. of this final rule for a full discussion of the HIPAA Privacy Rule’s applicability and why we are requiring an opt out policy for the Provider Access API. We believe that plain language educational resources will inform rather than confuse patients. We encourage payers to explain to patients that not opting out of data sharing VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 would not limit or negatively affect their rights under the HIPAA Privacy Rule. Rather, it is an opportunity for them to control where their data are shared under the policies of this final rule. Where the requirements of this rule change how covered entities or their business associates may use or disclose PHI, covered entities should also consider their obligations under the HIPAA Privacy Rule. Comment: Commenters recommended that CMS require additional details from payers about their opt out process for the Provider Access API. A commenter stated patients should receive detailed communications that include the potential benefits and harms of sharing versus not sharing this information, including the potential impact on quality and timeliness of care. Commenters further recommended that resources include information on privacy and security, moving data to a third-party app, and guidelines for patient-provider dialogue on consent. Response: As explained, we did not want to be overly prescriptive for the specific language used for the patient resources, but we did propose that they include patient instructions for opting out of data sharing and controlling their permission. We specifically proposed that the patient education resources include information about the benefits of API data exchange. In addition, impacted payers may, if they choose, include reasonable and objective information about any risks to data sharing. However, the purpose of the information in the educational resources, regardless of the particular content, should be to inform patients. We believe that patients educated with accurate information will realize the benefits of data sharing via the Provider Access API and most will not opt out. We agree that plain language resources should include information about privacy and security, in order to give patients an informed view of how the Provider Access API works. It is also reasonable and acceptable for payers to bundle or combine the educational resources about the Provider Access API with the educational resources about the Patient Access and Payer-to-Payer APIs, discussed in sections II.A. and II.C. of this final rule, to give patients a holistic view of how our interoperability policies work together to improve data exchange. Comment: Commenters recommended that CMS partner with ONC to develop templates and content for these educational resources, which impacted payers could use to meet this requirement. Many commenters recommended that CMS work with the PO 00000 Frm 00058 Fmt 4701 Sfmt 4700 health care community and patient advocates to develop language on the benefits and risks of data exchange. Commenters also recommended that CMS work with industry to develop and disseminate educational resources by creating a web page dedicated to interested party-specific newsletter inserts, holding CMS open door virtual forums, and using other methods to communicate regulatory and implementation updates. Response: We intend to continue working with Federal and industry partners to increase patient engagement in a way that both protects their autonomy and enables the sharing of the data to improve their health care. Based on feedback, we intend to develop additional outlines or templates for patient education resources. d. Provider Resources Regarding the Provider Access API We proposed to require impacted payers to develop non-technical and easy-to-understand resources for providers about the Provider Access API. We proposed that those resources would have to include information about the process for requesting patient data from payers via the Provider Access API and how to use the payer’s attribution process to associate patients with the provider. We proposed that impacted payers provide these resources to providers through the payer’s website and other appropriate provider communications, such as annual contract updates or handbooks. Nontechnical resources will help providers understand how they can use the API to access patient data, thus realizing the expected benefit of the proposed API. We requested comment on this proposal, including whether CMS should develop guidance regarding, or address in future rulemaking, the specific content of these educational resources about the Provider Access API. As discussed in more detail, we are finalizing this proposal, with a modification that provider resources be in plain language. i. Dissemination Comment: Multiple commenters expressed support for requiring impacted payers to make these resources easily available on a payers’ website, in contracts, and in provider handbooks. However, other commenters sought clarification on what ‘‘other appropriate provider communications’’ are and whether existing provider communication channels can be used to provide these resources. A commenter stated that it is unreasonable to expect E:\FR\FM\08FER2.SGM 08FER2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations lotter on DSK11XQN23PROD with RULES2 providers and their staff to access each payers’ website to obtain the payers’ specific resources and they do not believe this will happen in a reliable manner. Other commenters stated that the resources should be incorporated into a clinical workflow or EHRs. Response: While the provider resources must be available on the payer’s website, we are also requiring impacted payers to send those resources directly to providers through other appropriate channels. We encourage payers to use existing methods of communication by which providers expect to receive information from payers. We use the term ‘‘other appropriate provider communications’’ to provide payers with flexibility, but that term includes existing communication channels. For example, 42 CFR 422.202 requires MA organizations to provide to participating physicians written notice of rules of participation, including terms of payment, credentialing, and other rules directly related to participation decisions. The Provider Access API resources can be disseminated along with such resources.72 While payers are welcome to use the Provider Access API to make those resources available, they would have to develop an operable solution. Furthermore, if a provider needs guidance to access the Provider Access API, requiring a connection and query would not be useful. ii. Content Comment: Multiple commenters supported the proposal for impacted payers to disseminate provider-facing resources, particularly with instructions for attributing patients to a provider. Response: We appreciate commenters support for this requirement. As finalized, payers will be required to include information about the payer’s process to attribute patients to a particular provider. We also highly recommend that payers include contact information for provider assistance. To be consistent with our revision to the patient education resources policy, but also being clear that we have not altered the intent, we are finalizing regulatory text slightly different than what we had proposed, to require provider education resources in ‘‘plain language,’’ as opposed to our proposed ‘‘nontechnical, simple, and in easy-tounderstand language.’’ Comment: Multiple commenters recommended more technical education resources than we proposed because of the technical nature of API data exchange. A commenter suggested that 72 See 73 See 42 CFR 422.119(d), 431.60(d), and 457.730(d) and 45 CFR 156.221(d). 42 CFR 422.202(a)(1). VerDate Sep<11>2014 18:23 Feb 07, 2024 the resources include information about the IGs, links to the payer’s technical documentation and contact information for assistance with the Provider Access API. Another commenter warned that the educational resources need to be better defined, because they believe that the information we describe will be more appropriate for EHR vendors than providers. In fact, another commenter stated that it may be more appropriate for EHR and practice management system vendors to provide education resources that offer greater specificity about how data are integrated into provider data systems and workflows. Response: While payers will have to include instructions for accessing patient data, we disagree with the recommendation that payers include more technical documentation. We do not believe that most providers will be interested in the specific implementation details of the API, but will rely on their technology vendor. We remind payers that, per the final requirements in the CMS Interoperability and Patient Access final rule, they are required to make technical information about their Patient Access APIs available by posting directly on their website.73 We are finalizing this requirement by reference for the Provider Access, Payer-to-Payer, and Prior Authorization APIs, as well. References or links to that material would be entirely appropriate to include in the required provider resources. EHR and practice management vendors also have a role to play in educating providers about the functionality of their particular system. However, only payers will be able to offer provider specific details about their Provider Access API and the process for attributing patients. Comment: Commenters suggested that CMS require using language regarding limitations related to disclosures of sensitive conditions that are subject to 42 CFR part 2 and disclosures to minors. Response: Though we are not requiring it to be included in the provider resources, payers should adequately inform providers of what data are and are not available through the Provider Access API. Providers should be aware of what they can expect to receive in response to a request, whether that is because of the data content requirements, payer maintenance policies, or privacy limitations. Comment: Multiple commenters requested that CMS develop educational resources that impacted payers could Jkt 262001 PO 00000 Frm 00059 Fmt 4701 Sfmt 4700 8815 disseminate to their providers to ensure consistency and that providers are aware of any reporting protocols for payer non-compliance. A commenter added that these requirements and related guidance should be posted on CMS provider web pages and print publications. Multiple commenters recommended that CMS consult with Federal partners at ONC, the Health Resources and Services Administration (HRSA) and the Agency for Healthcare Research and Quality (AHRQ), and the provider community in order to understand their educational needs and how best to promote the resources. A commenter recommended that CMS provide additional guidance on the education and training efforts to provider specialties who are lagging the industry in interoperable technology adoption. Response: Based on comments we received, we intend to provide general guidelines to impacted payers about what this final rule requires to be disseminated to providers, which may include information on potential best practices. However, unlike the patientfacing educational resources described previously, we expect that provider resources could vary significantly between payers. Payers will have different processes to allow providers to request data via the Provider Access API and policies for patient attribution to explain to their providers. Therefore, there is less benefit to standardized templates or content for these resources. We provided links to resources for APIs to support payers implementing provisions of the CMS Interoperability and Patient Access final rule (85 FR 25510) 74 and we intend to identify similar resources for health care providers for this final rule. We will continue to work with our partners to ensure providers can access patient data, regardless of the technology they use. Requiring an API that can be accessed with systems other than CEHRT is a step toward that goal, and payer-developed resources should address all the ways providers could interact with the Provider Access API. 4. Extensions, Exemptions, and Exceptions See section II.E. of this final rule for a discussion of extensions and exemptions and the final policies for the Provider Access API for state Medicaid and CHIP FFS programs and exceptions for the Provider Access API for QHP 74 Centers for Medicare and Medicaid Services (n.d.). Best Practices for Payers and App Developers. Retrieved from https://www.cms.gov/ files/document/best-practices-payers-and-appdevelopersupdated21023.pdf. E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Frm 00060 Fmt 4701 11.B.2. I TT.B.3.a. I Sfmt 4725 11.B.3.b. E:\FR\FM\08FER2.SGM 11.B.3 .c. 08FER2 42CFR 422.121(a)(l) 42CFR 431.61(a)(l) 42CFR 422.12l(a)(2) 42CFR 431.6l(a)(2) Applicability of Provider Access APT to NEMT PAHPs (Compliance date Janu 1, 2027 Attribution (Compliance date January 1, 2027) NIA NIA 42CFR 422.12l(a)(3) 42CFR 431.6l(a)(3) Opt Out (Compliance date January I, 2027) 42CFR 422.121(a)(4)(i) 42CFR 431.61(a)(4)(i) 42CFR 422.121(a)(4)(ii) 42CFR 43 l.61(a)(4)(ii) 42CFR 422.121(a)(5) 42CFR 431.61(a)(5) NIA 42CFR 431.61(c)(l) NIA 42CFR 431.61(c)(2) Patient Educational Resources Regarding API (Compliance date January I, 2027) 11.B.3.d. I Provider Educational Resources Regarding API (Compliance date January 1, 2027) TT.B.4.a. I Extension for Medicaid and CIDP FFS (Effective Date of the Final Rule) 11.B.4.a. I Exemption for Medicaid and CffiP FFS (Effective Date of the Final Rule I Through cross reference to 42 CFR 431.61 at 42 CFR 438.242(b (7 Through cross reference to 42 CFR 431.61 at42 CFR 438.242 7 42 CFR438.9(b)(7) Through cross reference to 42 CFR 431.61 at42 CFR 438.242 b 7 Through cross reference to 42 CFR 431.61 at42 CFR 438.242 7 Through cross reference to 42 CFR 431.61 at42 CFR 438.242(b )(7 Through cross reference to 42 CFR 431.61 at42 CFR 438.242(b )(7 NIA NIA 42CFR 457.731(a)(l) Through existing cross reference to 42 CFR 438.242 at 42CFR 457.1233(d) 42CFR 457.73l(a)(2) 1 NIA 1 1 1 42CFR 457.73 l(a)(4)(i) Through existing cross reference to 42 CFR 438.242 at 42CFR 457.1233(d) 42CFR 457 .73 l(a)(4)(ii) 1 42CFR 457.731(c)(l) 42CFR 457.731(c)(2) 1 I I NIA I NIA 45 CFR 156.222(a)(3) FR 222(a)(4)(i) ~ 42CFR I 457.731(a)(5) 45 CFR 156.222(a)(2) NIA 42CFR 457.1206(b)(6) 42 CFR 457.731(a)(3) 45 CFR 156.222(a)(l) I 45 CFR 156.222(a)(4)(ii) 45 CFR 156.222(a)(5) NIA I NIA addressed in the proposed rule at 86 FR 76279). I Provider Access API for Individual Patient Information75 (Compliance I, 2027 date Jan Data Content (Compliance date January 1, 2027) BILLING CODE 4150–28–P PO 00000 11.B.2. I Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations Jkt 262001 11.B.2. 8816 18:23 Feb 07, 2024 issuers on the FFEs (this was also VerDate Sep<11>2014 ER08FE24.001</GPH> TABLE Cl: PROVIDER ACCESS API FINAL POLICIES lotter on DSK11XQN23PROD with RULES2 Jkt 262001 PO 00000 Frm 00061 Fmt 4701 Sfmt 4700 08FER2 8817 drugs) that the payer maintains no later than 1 business day after receiving a request from such a provider, if all the following conditions are met: • The payer authenticates the identity of the provider that requests access and attributes the patient to the provider under the required attribution process; • The patient does not opt out of the Provider Access API; and • Disclosure of the data is not prohibited by law. The required prior authorization information is: • The prior authorization status; • The date the prior authorization was approved or denied; • The date or circumstance under which the prior authorization ends; • The items and services approved; • If denied, a specific reason why the request was denied; and • Related structured administrative and clinical documentation submitted by a provider. We are finalizing that impacted payers are required to make this information about prior authorizations available no later than 1 business day after the payer receives a prior authorization request and must update that information no later than 1 business day after any status change. This information must be available for the duration that the authorization is active and at least 1 year after the prior authorization’s last status change. We are finalizing that impacted payers must establish and maintain an attribution process to associate patients with their in-network or enrolled providers to enable payer to provider data exchange via the Provider Access API. We are finalizing that, by the deadlines, impacted payers must establish and maintain a process for patients to opt out of data exchange via the Provider Access API and to change their permission at any time. We are finalizing that this process must be made available before the first date on which the payer makes patient information available via the Provider Access API, and at any time while the patient is enrolled with the payer. We are finalizing that, by the deadlines, impacted payers provide educational resources in plain language to their patients about the Provider Access API. Those resources must include information about the benefits of API data exchange with providers, patients’ opt out rights, and instructions for both opting out of data exchange and for subsequently opting in. Impacted payers must make this information available to patients before the first date on which the payer makes their E:\FR\FM\08FER2.SGM • Impacted payers must implement and maintain a Provider Access API beginning 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs) rather than in 2026. • Impacted payers are not required to use OpenID Connect Core at 45 CFR 170.215(e)(1) for the Provider Access API. • Impacted payers are not required to share the quantity of items or services used under a prior authorization via the Provider Access API. • Impacted payers are not required to share unstructured documentation related to prior authorizations via the Provider Access API. • Impacted payers are required to provide educational resources to patients no later than one week after the start of coverage, as that term is defined for each type of impacted payer, rather than at enrollment. • The educational resources that impacted payers are required to provide to patients and providers are described as ‘‘plain language’’ rather than in ‘‘nontechnical, simple, and in easy-tounderstand language.’’ See further discussion later for exact details of the final requirements for impacted payers. We are finalizing that beginning 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS Programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs), impacted payers must implement and maintain a Provider Access API that is conformant with certain technical standards, documentation requirements, and denial or discontinuation policies. Specifically, those technical standards are HL7 FHIR at 45 CFR 170.215(a)(1), US Core IG at 45 CFR 170.215(b)(1)(i), SMART App Launch IG at 45 CFR 170.215(c)(1), and Bulk Data Access IG at 45 CFR 170.215(d)(1). We are finalizing that, by the deadlines, impacted payers must make available upon request from an innetwork provider, via the Provider Access API, claims and encounter data (excluding provider remittances and patient cost-sharing information), all data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI), and certain information about prior authorizations (excluding those for Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations BILLING CODE 4150–28–C 5. Final Action After considering the comments received, and for the reasons discussed in the CMS Interoperability and Prior Authorization proposed rule and our response to those comments (as summarized previously), we are finalizing our proposal with the following modifications: 18:23 Feb 07, 2024 75 See Table H1 for which standards are required for the Provider Access API. VerDate Sep<11>2014 ER08FE24.002</GPH> NIA NIA NIA 45CFR 156.222(c) on the FFEs (Effective Date of the Final Rule NIA I Exceptions for QHP Issuers I NIA TT.B.4.b. 8818 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations information available via the Provider Access API, no later than one week after the start of coverage, and at least annually. These resources must also be available in an easily accessible location on payers’ public websites. We remind readers that ‘‘start of coverage’’ is defined differently, as applicable, for each type of impacted payer. We refer readers to section II.C.3.c.i. for discussion of these differences. We are finalizing that, by the deadlines, impacted payers must provide on their website and through other appropriate provider communications, information in plain language explaining the process for requesting patient data using the Provider Access API. The resources must include information about how to use the payers’ attribution process to associate patients with their providers. These policies apply to MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans and CHIP managed care entities (excluding NEMT PAHPs), and QHP issuers on the FFEs at the CFR sections listed in Table C1. 6. Statutory Authorities for Provider Access API We received no public comments on the statutory authorities for our Provider Access API policies. lotter on DSK11XQN23PROD with RULES2 a. Medicare Advantage Organizations For MA organizations, we are finalizing these Provider Access API requirements under our authority at sections 1856(b)(1) of the Act to promulgate regulations that adopt standards to implement provisions in Part C of Title XVIII of the Act (such as section 1852(d)(1)(A)) of the Act to adopt new terms and conditions for MA organizations that the Secretary finds ‘‘necessary and appropriate.’’ Section 1852(d)(1)(A) of the Act requires MA organizations to, as a condition of using a network of providers, make covered benefits available and accessible to enrollees in a manner that assures continuity in the provision of benefits. As noted in this section of this final rule, these regulations implement this requirement by requiring implementation of an API that will make available data to improve the provision of benefits. The Secretary also has authority under section 1857(e)(1) of the Act to add new contract terms, including additional standards and requirements, for MA organizations the Secretary finds necessary and appropriate and that are not inconsistent with Part C of the Medicare statute. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 In implementing section 1852(d)(1)(A) of the Act, we previously adopted a regulation, at 42 CFR 422.112(b), that requires MA organizations to ensure the continuity of care and integration of services through arrangements with providers that include procedures to ensure that the MA organization and the contracted providers have access to the information necessary for effective and continuous patient care. Our policy for MA organizations to implement and maintain a Provider Access API will facilitate exchanges of information about enrollees that are necessary for effective and continuous patient care, which is consistent with the requirement at section 1852(d)(1)(A) of the Act for continuing the provision of benefits. The Provider Access API policy, which will support sharing claims, all data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI), as well as certain information about prior authorizations (sections II.B.2. and II.B.3. of this final rule) and a requirement for MA organizations to offer provider educational resources (section II.B.3.d. of this final rule), will give providers tools to support continuity of care and care coordination for enrollees. Were a provider able, through a Provider Access API established by an MA organization, to gather information for their patient, the provider potentially could make more informed decisions and coordinate care more effectively. In addition, if a patient moves from one provider to another, the new provider will be able to ensure continuity of care if they are able to access relevant health information for the patient from the MA organization in an efficient and timely way. A Provider Access API could support this; thus, the policy will carry out and be consistent with the Part C statute. This policy will complement and align with MA organization obligations at 42 CFR 422.112(b)(4) by providing a means, through a Provider Access API, for the exchange of information that supports effective and continuous patient care. A Provider Access API may increase the efficiency and simplicity of administration. It will give providers access to a significant amount of their patients’ information with limited effort, and it could reduce the amount of time needed during provider visits to establish a patient’s prior history, which could introduce efficiencies and improve care. These policies are also expected to allow for better access to other providers’ prior authorization decisions, which could give a provider a more holistic view of a patient’s care PO 00000 Frm 00062 Fmt 4701 Sfmt 4700 and reduce the likelihood of ordering duplicate or misaligned services. Ultimately, we anticipate that sharing patient information will ensure that providers receive patient information in a timely manner and could lead to more appropriate service utilization and higher patient satisfaction. In addition, the policy that MA organizations make available educational resources and information will increase access to and understanding of this Provider Access API, leading to more efficient use and integration of the API as a means for providers to access patient information. Thus, the Provider Access API will be necessary and appropriate for the MA program and consistent with existing requirements. b. Medicaid and CHIP Our finalized requirements in this section for Medicaid FFS and Medicaid managed care plans fall generally under the authority in the following provisions of the statute: • Section 1902(a)(4) of the Act, which requires that a state Medicaid plan provide such methods of administration as are found by the Secretary to be necessary for the proper and efficient operation of the state Medicaid plan; • Section 1902(a)(8) of the Act, which requires states to ensure that Medicaid services are furnished with reasonable promptness to all eligible individuals; and • Section 1902(a)(19) of the Act, which requires states to ensure that care and services are provided in a manner consistent with simplicity of administration and the best interests of the recipients. The final Provider Access API policies are authorized under these provisions of the Act because they will ensure that states are able to ensure that Medicaid providers can access data that could improve their ability to render Medicaid services effectively, efficiently, and appropriately. The policies are expected to help states fulfill their obligations to operate their state plans efficiently and to ensure that Medicaid services are furnished with reasonable promptness and in a manner consistent with the best interest of the recipients. In addition, section 1902(a)(7) of the Act requires that states must provide safeguards that restrict the use or disclosure of information concerning Medicaid applicants and beneficiaries to purposes that are directly connected with the administration of the Medicaid state plan. The implementing regulations at 42 CFR part 431, subpart F, for section 1902(a)(7) of the Act list purposes that CMS has determined are E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations directly connected with administration of Medicaid state plans (42 CFR 431.302) and require states to provide safeguards meeting certain requirements to restrict uses and disclosures of Medicaid beneficiary data, including requirements for sharing applicant and beneficiary data at 42 CFR 431.306. Our finalized policy, that the data described in this section of the final rule be shared via the Provider Access API, is consistent with the requirement at section 1902(a)(7) of the Act, providing that states may share these data only for purposes directly connected with the administration of the Medicaid state plan. The Provider Access API data sharing policy is related to providing services for Medicaid beneficiaries, a purpose listed at 42 CFR 431.302(c). As mentioned previously, a provider can better manage a patient’s total care when they have access to more of that patient’s data because the data will provide a more in-depth medical history, enable more informed decision making, and potentially prevent the provision or ordering of duplicative services. More details about how the policies will be implemented in a manner consistent with state Medicaid requirements under 42 CFR part 431, subpart F, are discussed in section II.B.2. of this final rule. Requiring states to implement a Provider Access API to share data with enrolled Medicaid providers about certain claims, encounter, and clinical data, including data about prior authorization decisions, for a specific individual beneficiary, may improve states’ ability to ensure that care and services are provided in a manner consistent with simplicity of administration, and to cover services more efficiently. We remind states that ‘‘enrolled Medicaid providers’’ includes managed care plan providers, per 42 CFR 438.602(b). This Provider Access API will enable Medicaid providers to access beneficiary utilization and authorization information from the state or managed care plan(s) prior to an appointment or at the time of care, and that, in turn, should enable the provider to spend more time on direct care. The policy will support efficient and prompt delivery of care as well, which will be in beneficiaries’ best interests. These policies are also expected to give providers better access to prior authorization decisions for care provided by other enrolled Medicaid providers, which will give a provider a more holistic view of a patient’s care and reduce the likelihood of ordering duplicate or misaligned services. This may also facilitate easier and more informed decision-making by the VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 provider and should therefore support efficient coverage decisions in the best interest of patients. The Provider Access API is expected to make available a more complete picture of the patient to the provider at the point of care, which could improve the quality and efficiency of a patient visit. These outcome and process efficiencies may help states fulfill their obligations to ensure prompt access to services in a manner consistent with the best interest of beneficiaries, consistent with sections 1902(a)(8) and (19) of the Act, and the efficiencies created for providers might help the state administer its Medicaid program more efficiently, consistent with section 1902(a)(4) of the Act. These analyses apply similarly to FFS and managed care programs and delivery systems, so we are exercising our authority to adopt virtually identical regulatory requirements for a Provider Access API for both Medicaid FFS programs and Medicaid managed care plans. For CHIP, we finalized these requirements under the authority in section 2101(a) of the Act, which states that the purpose of Title XXI of the Act is to provide funds to states to provide child health assistance to uninsured, low-income children in an effective and efficient manner that is coordinated with other sources of health benefits coverage. We believe this policy will strengthen states’ abilities to fulfill these statutory obligations in a way that will recognize and accommodate using electronic information exchange in the health care industry today and will facilitate a significant improvement in the delivery of quality health care to CHIP beneficiaries. When providers have access to patient utilization and authorization information from payers or other health IT systems, they may be able to provide higher quality care. Improving the quality of care aligns with section 2101(a) of the Act, which requires states to provide CHIP services in an effective and efficient manner. The more information a provider has to make informed decisions about a patient’s care, the more likely it is that patients will receive care that best meets their needs. Additionally, providers can be more effective and efficient in their delivery of CHIP services by having direct access to patient utilization and authorization information. If a provider has information about a patient prior to or at the point of care, the provider will be able to spend more time focused on the patient, rather than on their need to collect information. In addition, the information providers do collect will not be based solely on patient recall. PO 00000 Frm 00063 Fmt 4701 Sfmt 4700 8819 This will save time, improve the quality of care, and increase the total amount of direct care provided to CHIP beneficiaries. When data are standardized, and able to be incorporated directly into the provider’s EHR or practice management system, they can be leveraged as needed at the point of care by the provider and also can be used to support coordination across providers and payers. This is inherently more efficient, and, ultimately, more cost-effective, as the information does not have to be regularly repackaged and reformatted to be shared or used in a valuable way. As such, the Provider Access API policies also align with section 2101(a) of the Act in that these proposals will improve coordination between CHIP and other health coverage. For these reasons, we believe this policy is in the best interest of the beneficiaries and within our longestablished statutory authorities. Finally, the safeguards for applicant and beneficiary information at 42 CFR part 431, subpart F, are also applicable to CHIP through a cross-reference at 42 CFR 457.1110(b). More details about how the policies could be implemented in a manner consistent with these CHIP agencies’ requirements are also discussed in section II.B.2. of this final rule. As discussed previously for Medicaid, giving CHIP providers access to attributed beneficiary data through the Provider Access API is related to providing services to beneficiaries, which is described at 42 CFR 431.302(c) as a purpose directly related to state plan administration. We remind states that when they share beneficiary information through the Provider Access API, they must comply with the privacy protections at 42 CFR 457.1110 and the release of information provisions at 42 CFR 431.306. c. Qualified Health Plan Issuers on the Federally-Facilitated Exchanges For QHP issuers on the FFEs, we are finalizing these new requirements under our authority in section 1311(e)(1)(B) of the Affordable Care Act, which affords the Exchanges the discretion to certify QHPs if an Exchange determines that making available such health plans through that Exchange is in the interests of qualified individuals in the state in which the Exchange operates. We believe the benefits will outweigh any additional burdens this might impose on issuers. By using the finalized technologies, patients could experience improved health, payers could see reduced costs of care, and providers could see better compliance with care regimens. We also do not believe that premiums will significantly increase E:\FR\FM\08FER2.SGM 08FER2 8820 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations because some of the infrastructure necessary to implement the technology has been completed to comply with the CMS Interoperability and Patient Access final rule. Furthermore, QHP issuers on the FFEs might combine investments and staff resources from other programs for implementation efforts, avoiding the need to increase premiums. We believe that certifying only health plans that make enrollees’ health information available to their providers via the Provider Access API is generally in the interests of enrollees. Giving providers access to their patients’ information supplied by QHP issuers on the FFEs will ensure that providers are better positioned to provide enrollees with seamless and coordinated care and ensure that QHP enrollees on the FFEs are not subject to duplicate testing and procedures, and delays in care and diagnosis. Access to the patient’s more complete medical information could also maximize the efficiency of an enrollee’s office visits. We encourage SBEs, including SBE–FPs, to consider whether a similar requirement should be applicable to QHP issuers participating in their Exchanges. lotter on DSK11XQN23PROD with RULES2 C. Payer-to-Payer API 1. Background Having a patient’s data follow them when they change payers can have a multitude of benefits for patient care. A payer receiving data when a new patient enrolls can better coordinate care and make more informed decisions. For instance, a payer can use the patient’s data to determine whether they have a chronic condition or is undergoing current care that needs to be maintained. If necessary, patient data can give payers the information they need to assign a case manager or help the patient find providers in their new network. Maintaining a corpus of data ensures that the patient and their providers do not lose access to recent information that may be relevant to ongoing or future care. Furthermore, because payers usually maintain a relationship with individual patients over time, they are uniquely positioned to collect and aggregate a patient’s record. Whereas patients may have several providers who manage their care, they generally maintain a relationship with only one or two concurrent payers for a full year or multiple years. However, when a patient moves from one payer to another, both parties may lose access to that valuable data. Data exchange among payers, specifically, sending patient data from a patient’s previous payer to their new one, is a powerful way to ensure that VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 data follow patients through the health care system and improve care continuity. Electronic data exchange between payers will support payer operations and a patient’s coverage transition to a new payer efficiently and accurately. Sharing health care data between payers also helps care coordination, care continuity, and allows patients to maintain access to their record over time. In the CMS Interoperability and Patient Access final rule (85 FR 25565), we highlighted numerous benefits of payers maintaining a longitudinal (meaning, long-term) record of their current patients’ health information. If payers are at the center of the exchange, they can make information available to patients and their providers and can help a patient’s information follow them as they move from provider to provider and payer to payer. In the CMS Interoperability and Prior Authorization proposed rule, we proposed and, in this rule are now finalizing regulations that require impacted payers (MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs) to implement and maintain a FHIR API to facilitate payer to payer data exchange. We are finalizing that proposal to require impacted payers to build a Payer-to-Payer API, with certain standards (as further described in section II.F.), that will facilitate patient data exchange at the start of coverage and with concurrent payers. We proposed, and are finalizing, a patient opt in policy for this data exchange. We proposed compliance dates in 2026 for the Payer-to-Payer API (by January 1, 2026, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2026, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2026, for QHP issuers on the FFEs). However, in response to comments we are finalizing a modification to that proposal for the Payer-to-Payer API to establish compliance dates in 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs). Throughout this rule, we generally refer to these compliance dates as ‘‘in 2027’’ for the various payers. In addition, and also in response to comments, we are finalizing a modification to our proposal to only PO 00000 Frm 00064 Fmt 4701 Sfmt 4700 require impacted payers to exchange data with a date of service within 5 years of the exchange request. To support the implementation and maintenance of the Payer-to-Payer API, we are requiring certain standards and recommending certain IGs, as further discussed and in section II.G. With the publication of the HTI–1 final rule, our cross references to 45 CFR 170.215 have been updated to reflect the updated citations as needed. Changes to the structure of 45 CFR 170.215 and versions of the API standards codified there are discussed further in section II.G. and reflected throughout this final rule. For the Payer-to-Payer API, impacted payers must use the following standards: HL7 FHIR Release 4.0.1 at 45 CFR 170.215(a)(1), US Core IG STU 3.1.1 at 45 CFR 170.215(b)(1)(i), and Bulk Data Access IG v1.0.0: STU 1 at 45 CFR 170.215(d)(1). Impacted payers are permitted to use updated standards, specifications, or IGs that are not yet adopted in regulation for the APIs required in this final rule, should certain conditions be met. For the standards at 45 CFR 170.215, updated versions available for use under our policy include, but are not limited to, US Core IG STU 6.1.0 and the Bulk Data Access IG v2.0.0: STU 2, which have been approved for the ONC Health IT Certification Program.76 We refer readers to policies finalized for the Patient Access API in the Interoperability and Patient Access final rule, as well as section II.G.2.c. of this final rule for a full discussion on using updated standards. We also recommend payers use the CARIN IG for Blue Button STU 2.0.0, PDex IG STU 2.0.0, and SMART App Launch IG Release 2.0.0 to support Backend Services Authorization. We refer readers to Table H3 for a full list of the required standards and recommended IGs to support API implementation. In this section, we talk about data exchange between payers. When we refer to a patient’s new payer, we mean the payer that a patient is newly enrolled with and the party responsible for requesting and receiving the patient’s data. When we refer to the patient’s concurrent payers, we signify the parties (two or more) that are providing coverage at the same time and are responsible for exchanging data with each other as discussed further in section II.C.3.c. When we refer to the patient’s previous payer, we denote the payer that a patient has previously had 76 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. E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations coverage with and thus the payer responsible for sending the data to the new payer. Our payer to payer data exchange requirements discussed in this section involve transactions and cooperation between payers, which may include payers that are not subject to the requirements in this rule. We emphasize that each impacted payer is responsible only for its own side of the transaction. For instance, when an impacted payer is required to request patient data from another payer, it will have to do so regardless of whether the other payer is an impacted payer (a status that may or may not be evident to the requesting payer). Similarly, if an impacted payer receives a request for patient data that meets all the requirements, the impacted payer must share those data, regardless of whether the requesting payer is an impacted payer (which, again, may or may not be evident to the payer sharing the data). In this way, payers not subject to this regulation that implement a Payer-to-Payer API (or other IT functionality to request or receive information through the impacted payer’s API) and their patients can also benefit from the data exchange. We are exploring steps for Medicare FFS to participate in payer to payer data exchange and we encourage other payers that are not subject to these requirements to do the same. We intend to implement the Payer-to-Payer API capabilities for Medicare FFS in conformance with the requirements for impacted payers, as feasible. In the proposed rule, we sought comment on whether our proposals could be implemented as proposed for the Medicare FFS program, how we could apply each of the proposals, and whether there would be any differences for implementing the Payer-to-Payer API in the Medicare FFS program as a Federal payer. We summarize the comments received and our responses in section I.D. of this final rule. We strongly encourage all payers that are not subject to the requirements of this rule to consider the value of implementing a Payer-to-Payer API, so that all patients, providers, and payers in the U.S. health care system may experience the benefits of such data exchange. Comment: Many commenters supported our proposal to require data exchange via a Payer-to-Payer API. Commenters stressed the benefits to patients of maintaining an ongoing record when they change payers, which could result in better patient outcomes, especially for patients with chronic conditions. Commenters agreed that this API would improve interoperability, VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 data exchange, and reduce administrative burden. Multiple commenters stated that the Payer-toPayer API would be especially helpful to patients with concurrent coverage. A commenter stated that the assignment of primary care physicians could also be facilitated by the Payer-to-Payer API and that this could reduce care disruptions when changing payers. Another commenter acknowledged that investments made in payer to payer data exchange would benefit broader multipayer alignment efforts, which are a key priority for improving quality, access, and value in health care. Another commenter stated that exchanging patient data from previous and concurrent payers would eliminate duplicative medical record requests from payers requiring providers to reapprove medical necessity, retry step therapy requirements, and reauthorize treatments. Response: We appreciate commenters validating our statements in the proposed rule regarding the benefits of payer to payer data exchange. We agree that the benefits of payer to payer data exchange include both ensuring care continuity and that patients, providers, and future payers do not lose access to important health information. We are finalizing, with modification, the Payerto-Payer API proposals as discussed in this section. Comment: Multiple commenters opposed finalizing our Payer-to-Payer API proposals. They disagreed with our justification that payers should be the maintainers of a patient’s longitudinal data. Another commenter cautioned that, as proposed, the Payer-to-Payer API would require payers to share a large amount of unnecessary data, which would make it difficult to effectively coordinate care. Instead, they suggested that by leveraging the Patient Access API, patients should have the responsibility to maintain their patient data using an app, or other solution of their choice. A commenter recommended that CMS separate the goal of creating longitudinal consumer health records from the goal of supporting consumer transitions between payers. Response: After reviewing comments, we agree that patients are in the best position to manage their health information, especially with the growing ecosystem of health apps and the availability of standardized Patient Access APIs. Some HIEs and health apps (which may also be TEFCA Participants and Subparticipants) may be able to gather data from payers, providers, and other sources to create a more comprehensive patient record than PO 00000 Frm 00065 Fmt 4701 Sfmt 4700 8821 could be maintained by a payer. However, payers are uniquely positioned to collect and aggregate patient data, especially during coverage transitions. As we noted, patients may have several providers who manage their care, but they generally maintain a relationship with only one or two concurrent payers for a full year or multiple years. A payer to payer data exchange can facilitate care continuity by providing access to information about past treatments when a patient is moving from one payer to another. For example, that information could show payers that a patient has already demonstrated medical necessity or engaged in step therapy, which could ease the approval of a prior authorization request. Ensuring that payers have timely access to newly enrolled patients’ data upon a patient transitioning payers can have a multitude of benefits for patient care leading to better-coordinated care, more informed decision-making, and minimize disruption in ongoing care. Therefore, to mitigate potential burden on impacted payers, while still establishing the Payer-to-Payer API as a means to support the creation and availability of a longitudinal record, as discussed, we are finalizing a modification to our proposal to only require payers to exchange data with a date of service within 5 years of the request. That modification means that payers will not be responsible for exchanging and maintaining a patient’s entire health history dating to January 1, 2016. Comment: Multiple commenters did not support the proposed Payer-to-Payer API and suggested alternatives to gain the intended benefits. A commenter noted that there are many industry solutions already being developed to facilitate the coordination of benefits between payers and recommended CMS continue to monitor and enable technical innovation in this area. Another commenter cautioned CMS to not view FHIR as the sole solution to interoperability and patient data exchange challenges. The commenter noted that as proposed, payers would experience challenges if FHIR failed to reach widespread adoption and maturity. Another commenter stated that requiring the FHIR standard eliminates choice and leads to bias and further stated that other options may be better suited for a payer. Response: We thank the commenters for their suggestions, but FHIR APIs are the standard that the industry indicated has the greatest maturity and hence has been adopted by ONC. A variety of solutions will not lead to E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8822 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations interoperability across the healthcare system. While payers already have processes in place for coordinating benefits, that coordination does not extend to transitions of care between payers, such as maintaining prior authorizations. Data exchange between payers can ensure that valuable patient information is not lost, such as prior authorization requests and approvals, which could make that transition more seamless. Requiring FHIR will get the healthcare industry to a more interoperable state, as that standard supports health data exchange in a standard, structured, but flexible format that can continue to advance and mature. Impacted payers are already required to use the FHIR standard for the Patient Access and Provider Directory APIs, and this final rule is meant to build on this existing policy. Also, we are extending the compliance dates for the Payer-to-Payer API to 2027. This delay to the compliance dates versus our proposal allows for additional time for implementation and IGs to be refined and matured to support the policies in this final rule. Comment: Multiple commenters expressed concern regarding payer access to patient data. They worried that this could lead to patient risk profiling, increased prior authorization requirements, increased premiums and limits on coverage and access to care. They recommended that CMS prohibit impacted payers from using information sent from a previous payer to discriminate against a patient. A commenter stated that CMS should implement safeguards to ensure that the payer to payer data exchange does not encourage payers to make care decisions based on the patient’s record. The commenter recommended that CMS explain that the provider is the director of medical care, and payers support the patient’s care through payment and coverage of services. They suggested that large-scale consumer data exchange should be consumer-mediated and result in meaningful access to comprehensive data for care coordination among payers. Response: We agree with the commenters that patient information should not be used in an inappropriate manner. We remind payers that section 1852(b) of the Act states that an MA plan may not deny, limit, or condition the coverage or provision of benefits based on any health status-related factor described in section 2702(a)(1) of the Public Health Service Act.77 Section 2705(a)(1) of the Public Health Service Act, which applies to QHP issuers on the FFEs, prohibits discrimination against individuals based on their health status-related factors. Similarly, section 2102(b)(1)(B)(ii) of the Act prohibits CHIP programs from denying eligibility for children with preexisting conditions. Finally, the overarching regulations at 45 CFR part 92 implementing section 1557 of the Affordable Care Act prohibit discrimination under any health program or activity receiving Federal financial assistance on the basis of race, color, national origin, sex, age, or disability. Comment: Multiple commenters suggested that implementation of a Payer-to-Payer API may increase provider burden with unintended downstream effects. A commenter discussed how the Payer-to-Payer API could lead to a negative impact on providers who may be required to ingest large amounts of data if payers maintain a longitudinal record back to January 1, 2016, that is also shared via the Provider Access API. Response: Our modification to require impacted payers to exchange only 5 years of data via the Payer-to-Payer API will mitigate this possible issue for providers. By circumscribing the data to be exchanged by payers to only more recent data, providers are less likely to receive distant and irrelevant historical data via the Provider Access API. We acknowledge that not all of a patient’s health information is going to be equally relevant to a particular provider. Therefore, providers should look for clinically relevant information and work with their EHR vendors on solutions to easily display the information most relevant to their practice. We discuss this issue is greater depth in section II.B.2.c. Comment: A commenter questioned the utility of the Payer-to-Payer API if payers other than impacted payers do not voluntarily adopt the technology and processes to share data. Response: We appreciate commenters supporting Payer to Payer adoption by payers other than impacted payers. We strongly encourage all payers not subject to these provisions to consider the value of implementing a Payer-to-Payer API, so that all patients, providers, and payers in the U.S. health care system may ultimately experience the benefits of such data exchange. Even though not every payer may participate in it, our Payer-to-Payer API policy can benefit the millions of Americans covered by 77 Section 2702 of the Public Health Service Act referenced in section 1852(b) of the Act refers to what is now codified as section 2705 of the Public Health Service Act. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 PO 00000 Frm 00066 Fmt 4701 Sfmt 4700 impacted payers. We specifically encourage impacted payers that have other lines of business to adopt the policies in this final rule for their commercial plans that are not subject to the requirements of this rule. Comment: A commenter recommended that CMS work with ONC and industry stakeholders to develop a longer-term FHIR roadmap, including patient-centric data homes that efficiently and effectively collect, storage, and integrate information from across the health system on behalf of a patient. Another commenter recommended that CMS work with the DoD and the VA to implement Payer-toPayer APIs. Response: We appreciate the support for our Payer-to-Payer API policies and will continue to work with other Federal agencies to improve interoperability across the health care system. Comment: Many commenters recommended delaying the Payer-toPayer API compliance dates to give payers more time to design, develop, test and implement their systems. Some commenters recommended a January 1, 2027, compliance date, and another commenter recommended 4 years after the publication of the final rule, to give industry time to align on a standardized implementation approach. A few commenters suggested CMS delay compliance dates until IGs are mature enough to adopt as required standards, or to allow payers to adopt Payer-toPayer API on a voluntary or pilot basis. Some commenters suggested CMS set rolling compliance dates and the Payerto-Payer API should be prioritized after the Prior Authorization API. Several commenters specifically recommended that CMS to delay the compliance dates for state Medicaid agencies to implement a consistent solution at enrollment. A commenter requested that CMS accelerate the compliance dates to 2024. Another commenter urged CMS to consider the added cost and burden for payers to meet the proposed compliance dates. Response: Because we understand that the payer implementation process is significant, after reviewing the comments, we are finalizing a modification to our proposal for the Payer-to-Payer API, to establish compliance dates in 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs). However, as discussed in E:\FR\FM\08FER2.SGM 08FER2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations lotter on DSK11XQN23PROD with RULES2 section I.D.2., we decline to delay beyond that because of the importance of payer to payer data exchange. Establishing regulatory compliance dates will provide greater urgency to test and mature the evolving technical standards and IGs. When we proposed to require the relevant IGs in our December 2020 CMS Interoperability proposed rule, we received many comments that those standards were not mature enough to feasibly implement at that time. In response, we proposed in this rulemaking to only recommend (rather than require) the IGs for standardized implementation. After consideration of the comments we received in response to the CMS Interoperability and Prior Authorization proposed rule, we are finalizing those IGs as recommendations because it is prudent to move forward to attain the policy goals of the Payer-to-Payer API, even while those standards are being developed to achieve true interoperability. Moving to a 2027 compliance dates will give the industry an extra year to refine those IGs and for payers to implement their technical solutions. With regard to the requests for additional time for Medicaid programs specifically, we refer readers to section II.E.2.a. of this final rule where we finalize our proposals to create a process for Medicaid and CHIP FFS programs to request and be granted an extension to the compliance dates for the Payer-toPayer API. 2. Proposal To Rescind the CMS Interoperability and Patient Access Final Rule Payer to Payer Data Exchange Policy We strongly believe that data exchange among payers is a powerful way to improve information sharing that would allow patients and providers to have more complete access to health information, which can help to promote better patient care. Patients may wish for their health information to follow with them when they change payers, in part so that they can track the services they have received, and to ensure that a new payer has information to better assist with continuity of that care. However, given the concerns raised by stakeholders regarding the lack of technical specification in our previously finalized policy, we proposed to rescind the payer to payer data exchange policy finalized in the CMS Interoperability and Patient Access rule (85 FR 25568) at 42 CFR 422.119(f)(1) and 438.62(b)(1)(vi) and (vii) and 45 CFR 156.221(f)(1). We did so to prevent industry from developing multiple systems, and to help payers avoid the VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 costs of developing non-standardized, non-API systems, and the challenges associated with those systems. We proposed a new policy that would, instead, require impacted payers to implement and maintain a Payer-toPayer API using the FHIR standard. We stated that using FHIR APIs would ensure greater uniformity and ultimately lead to payers having more complete information available to share with patients and providers. Comment: Commenters supported CMS’s proposal to rescind and replace the Payer-to-Payer API requirements finalized in the CMS Interoperability and Patient Access rule (85 FR 25568). They agreed that the proposals would help standardize data exchange and avoid developing duplicative systems. Multiple commenters strongly supported the newly proposed FHIR API approach and noted that this API would leverage the same standards as the Patient Access and Provider Access APIs. A commenter highlighted how CMS’s proposal to replace the payer to payer data exchange addressed a key concern held by the industry about the lack of specificity in the previous policy. Another commenter stated that they welcomed the elimination of provider remittances and cost-sharing information from the required data content. Response: We appreciate commenters support and are finalizing our rescission of the previous policy. We note that we are correcting a technical error in this final rule for the Payer-to-Payer API requirements in Medicaid managed care. When we proposed to remove the requirement at 42 CFR 438.62(b)(1)(vi) and (vii) and instead use a cross reference to 42 CFR 431.61(b)(1) at § 438.242(b)(7), we inadvertently neglected to properly revise 42 CFR 438.9 to continue excluding NEMT PAHPs from the Payerto-Payer API requirements. When the payer to payer data exchange requirements were finalized in the CMS Interoperability and Patient Access rule (85 FR 25568) at § 438.62(b)(1)(vi) and (vii), NEMT PAHPs were automatically excluded as 42 CFR 438.62 is not applicable to NEMT PAHPs. However, by moving the Payer-to-Payer API requirements to § 438.242(b)(7), the requirements would apply to NEMT PAHPs (at 42 CFR 438.9(b)(7)). As we explained when we proposed to exclude NEMT PAHPs from the Provider Access API (87 FR 76258), we believed that the unique nature and limited scope of the services provided by NEMT PAHPs, in that they only cover transportation and not medical care itself, justified their exclusion from the requirements of the PO 00000 Frm 00067 Fmt 4701 Sfmt 4700 8823 Provider Access API. Similarly, we do not believe that other payers have a routine need for NEMT data; therefore, requiring NEMT PAHPs to implement and maintain a Payer-to-Payer API would be an undue burden on them. It would also be a burden on other Medicaid payers concurrently covering a patient to receive NEMT data quarterly as required at 42 CFR 431.61(b)(5). To correct this oversight, we are finalizing 42 CFR 438.9(b)(7) to exclude the requirement at § 438.242(b)(7), which is to comply with § 431.61(a) and (b). Comment: A commenter supported our proposal to rescind the previous requirements but urged us not to finalize our new Payer-to-Payer API proposals, because many of the technical standards are still undergoing development and refinement and operational processes have not been established by payers. The commenter suggested that CMS should consider establishing a voluntary payer to payer data exchange policy. Response: We acknowledge that any new requirement is going to have operational challenges that need to be resolved. Technical standards have substantially developed over the past 3 years since we issued the December 2020 CMS Interoperability proposed rule (85 FR 82586). We refer readers to sections II.G.3.a. and II.G.3.b. of this rule for additional discussion on enhancements to both the required and recommended IGs published since the publication of the CMS Interoperability and Prior Authorization proposed rule. For example, the recently published PDex IG STU 2.0.0 specification now includes a Prior Authorization profile that enables payers to communicate prior authorization requests and decisions. We are extending our compliance dates for the Payer-to-Payer API from our proposed 2026 to 2027 in order to provide additional time for stakeholders, and specifically payers, to address those barriers to implementation. 3. Payer to Payer Data Exchange on FHIR a. Payer-to-Payer API Technical Standards In the CMS Interoperability and Patient Access final rule we finalized a requirement that impacted payers must implement, maintain, and use a Patient Access API conformant with 45 CFR 170.215. However, we did not require payers to use an API or specific standards for payer to payer data exchange in that final rule. In the CMS Interoperability and Prior Authorization proposed rule, we E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8824 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations proposed an API-based payer to payer data exchange utilizing standards and technology similar to that of the Patient Access API. The degree of overlap between the requirements for the Patient Access API (discussed in section II.A.2. of the proposed rule) and the Provider Access API (discussed in section II.B.2. of the proposed rule) should ease the development and implementation of the Payer-to-Payer API for payers. The Patient Access API will provide the foundation to share adjudicated claims and encounter data, all data classes and data elements included in a standard adopted at 45 CFR 170.213 (USCDI), as well as certain information about prior authorizations. Because, as of January 1, 2021, the same adjudicated claims and encounter data, and all data classes and data elements included in the standard at 45 CFR 170.213 are already required for the Patient Access API, payers should have already formatted these categories of data and prepared their systems to share these standardized data via a FHIR API. As a result, payers have already devoted the development resources to stand up a FHIR API infrastructure when they implemented the Patient Access API, which could be adapted for additional interoperability use cases. We proposed that, beginning January 1, 2026 (for Medicaid managed care plans and CHIP managed care entities, by the rating period beginning on or after January 1, 2026, and for QHP issuers on the FFEs, for plan years beginning on or after January 1, 2026), impacted payers must implement and maintain a Payer-to-Payer API that is conformant with the same technical standards, documentation requirements, and denial or discontinuation policies as the Patient Access API. We proposed to require certain standards adopted under 45 CFR 170.215 that are applicable to the Payerto-Payer API. We are finalizing our proposals for the Payer-to-Payer API with modifications, requiring impacted payers to use the following standards: HL7 FHIR Release 4.0.1 at 45 CFR 170.215(a)(1), US Core IG at 45 CFR 170.215(b)(1)(i), and Bulk Data Access IG at 45 CFR 170.215(d)(1). We also recommend payers use the CARIN IG for Blue Button STU 2.0.0, PDex IG STU 2.0.0, and SMART App Launch IG Release 2.0.0 to support Backend Services Authorization. We proposed but are not finalizing to require impacted payers to use SMART App Launch IG and OpenID Connect Core for reasons discussed later in this section. We refer readers to Table H3 for a full list of the required standards and recommended IGs to support API VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 implementation. We refer readers to section II.G. of this final rule for further discussion of the required and recommended technical standards for the Payer-to-Payer API. One operational difference between the Patient Access and Payer-to-Payer APIs is that payers may find it more efficient to share data for multiple patients at a time. It is likely that impacted payers with a fixed enrollment period will have many patients’ data to share at one time, especially if other payers share that enrollment period (such as QHPs offered on an FFE). In such a situation, it could require significant time and resources for payers to send each patient’s data individually through an API. The Bulk Data Access IG for exchanging multiple patients’ data at once has been adopted by ONC at 45 CFR 170.215(d)(1), which is discussed further in section II.F. of this final rule and is a standard we proposed to require for the Payer-to-Payer API. We requested comments on these proposals. We received multiple comments regarding technical implementation challenges and the maturity of the recommended IGs, which are addressed in section II.G. of this final rule. Here we respond to the comments specific to the standards and IGs for implementing the Payer-to-Payer API. Comment: Multiple commenters stated their support for the proposed FHIR standard and recommended IGs for the Payer-to-Payer API. Multiple commenters stated that the FHIR standard will ultimately prevent issues with data sharing across payers and allow information to be shared accurately and timely. Many commenters gave their support for our proposal that the Payer-to-Payer API must be conformant with the standards at 45 CFR 170.215, including support for the Bulk Data Access IG and OpenID Connect Core. Some commenters agreed with not requiring payers to use the CARIN IG for Blue Button or HL7 Da Vinci IGs. Additionally, other commenters explained that universally implementing FHIR would define how health care information is shared, but will have no impact on how data are collected or stored. Multiple commenters stated their support for requiring Payer-to-Payer APIs to use the same standards as the other interoperability APIs. A commenter stated that leveraging the same standards and IGs will support efficient implementation. Another commenter stated that the lack of standards has been one of the barriers to achieving data fluidity between payers. PO 00000 Frm 00068 Fmt 4701 Sfmt 4700 Response: We thank commenters for their support of the proposed standards and recommended IGs for the Payer-toPayer API and agree that the using standards will support more efficient data sharing. Requiring impacted payers to use the same standards and IGs will support consistent implementation and improve interoperability across health care. We note that for the Payer-to-Payer API, we are finalizing a modification to our proposal by not requiring the SMART App Launch IG at 45 CFR 170.215(c) and OpenID Connect Core at 45 CFR 170.215(e)(1), as discussed further in section II.C.3.d.iii. of this final rule. Protocols requiring user level credentials managed by the payer, such as those used with OpenID Connect Core, are generally not appropriate for business-to-business data exchanges like the Payer-to-Payer API where a particular individual may not be directly initiating the exchange. Comment: Some commenters who supported the proposal that the Payerto-Payer API must be conformant with FHIR at 45 CFR 170.215(a)(1) identified concerns with implementation. Multiple commenters agreed with the approach to require the FHIR standard for Payerto-Payer APIs, but some commenters noted that the standard has not been widely demonstrated in production by industry stakeholders. A commenter stated that payers will need to create workflows to process exchanges, incorporate received data into local records, and troubleshoot any issues. A commenter recommended that CMS allow 1 to 2 years to implement new standards depending on complexity. The commenter encouraged data transfer standards be backward compatible. Response: We agree that implementing new standards takes time and appreciate the commenter recommending we allow 1 to 2 years. However, technology and standards are ever evolving and will never remain static for the period it would take the entire industry to implement. To address comments about the time necessary for implementation, we are delaying the compliance dates for the Payer-to-Payer API to 2027, which will give implementers approximately 3 years from the publication of this final rule. Public comment has broadly indicated that the proposed standards will be sufficiently mature for implementation by that deadline. We will continue working with HL7, the FHIR accelerators, and industry stakeholders to define, to participate in and convene testing events, and to develop and maintain the specifications, which moves them towards greater E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations maturity. Specifically, the PDex IG has been tested, implemented, and based on industry standard consensus, is ready for use. We acknowledge that the standards discussed in this rule will continue to mature to enhance functionality and meet additional use cases. We expect that future rulemaking by CMS and ONC will be necessary to keep pace with the latest technical innovations. While the technology may never be ‘‘done,’’ commenters indicated that the standards available today are sufficiently mature to facilitate 2027 compliance dates for the policies in this final rule that require API development or enhancement. We acknowledge that, as with any standard, potential compatibility issues could arise through the further development of those specifications. We discuss IG maturity further in section II.G.3.b. of this final rule. These standards are subject to a standards development process where changes are reviewed and compatibility is an important consideration, increasingly so with the level of adoption and use. As the IGs mature, the number of potential compatibility issues between versions is expected to decrease. Comment: Multiple commenters recommended that CMS name specific IG versions and standards as a baseline for the Payer-to-Payer API and create a formal standard version advancement process similar to the ONC Standards Version Advancement Process (SVAP). A commenter noted that an established SVAP would give the industry and HL7 the opportunity to continue refining and testing standards and IGs to ensure consistent implementation. A commenter recommended that CMS ensure that the applicable Payer-toPayer API technical standards remain current as new versions become available. Multiple commenters specifically stated their concern for endpoint compatibility and recommended that CMS create required standards so that payers do not need to make one-off modifications to accommodate slightly different APIs. Response: In the proposed rule, we stated that we believed the approach of recommending, but not requiring, specific versions of the IGs would provide directional guidance without locking implementers into the versions of the recommended IGs available at the time of the proposed rule. To not recommend any specific IGs would have meant a more diverse set of proprietary solutions with little to no interoperability. Our recommendations have allowed the IG authors and community to receive feedback from real-world use and to further mature VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 and refine the IGs. Certification and testing of these APIs could help avoid implementation variation and will consider ways for CMS to support such testing in the future. In addition, by using the recommended IGs, implementers can ensure that their APIs are compatible and conformant to the requirements. As the standards continue to mature, we will consider whether to propose requiring additional IGs through rulemaking. Comment: A commenter stated that the proposed IGs are dependent on an outdated network authentication protocol and recommended using the HL7® FHIR® Da Vinci Health Record Exchange (HRex) IG, which leverages UDAP for authentication. Another commenter simply recommended utilizing UDAP for authentication. Another commenter recommended CMS modify the standards and IGs to adequately capture the Payer-to-Payer API requirements. The commenter stated that CMS should support the development of content and technical standards for prior authorization decisions that can be incorporated into the appropriate IGs for testing. Response: We acknowledge that there is no single security protocol approach that will address all use cases. Additionally, within a single API, implementers may need to utilize more than one protocol to address specific population and trading partner needs. As discussed in section II.C.3.d.iii. of this final rule, we are finalizing a modification to our proposal to not require the OpenID Connect Core and SMART App Launch IG standards for the Payer-to-Payer API. We recognize that methods such as SMART Backend Services (which is included in the SMART App Launch IG v2), mTLS, UDAP, or other trust community specified means may be appropriate depending on the needs. We refer readers to Table H3 in this final rule for an updated finalized list of all required and recommended IGs for the Payer-toPayer API. We will continue to work with ONC to advance the versions of the standards that ONC adopts at 45 CFR 170.215. We will continue to monitor the development UDAP and other trust community specified solutions that could support the Payer-to-Payer API authentication process. We also note that ONC has adopted SMART Release 2.0.0 at 45 CFR 170.215(c)(2) and while we are not requiring the SMART App Launch IG for the Payer-to-Payer API, we do recommend using SMART Backend Services. Comment: A commenter expressed support for maturing the PDex IG and noted that the IG still needs more testing PO 00000 Frm 00069 Fmt 4701 Sfmt 4700 8825 for specific use cases. Another commenter suggested that CMS not finalize the Payer-to-Payer API until it works with HL7 to diminish the costs with the PDex IG. The commenter noted that in the PDex IG, the patient would be responsible for manually executing the data exchange using a third-party app and then transmitting that information to a new payer. Another commenter stated that the IGs identified for the payer to payer data exchange include the capability for two methods (member-mediated and memberdirected), which would cause confusion and redundancy. The commenter stated that the member-directed solution would potentially give the new payer access to financial information meant to be available only to the patient. Response: The PDex IG provides multiple data exchange methods. One method allows a member to directly authorize data being sent to a third party. While this method could be utilized for payer to payer interactions, it is not the primary method defined by the PDex IG for that use case. For the Payer-to-Payer API use case, the PDex IG provides guidance for supporting exchanges that do not require direct member engagement. The PDex IG STU 2.0.0, which is being recommended for the Payer-to-Payer API in this rule, can facilitate on the payer to payer exchange by defining a means for the requesting payer to send a record of the patient’s opt in to retrieve data from the other payer. This method does not require patient action through OAuth and is the method we recommend for payer to payer data exchanges. While we recognize that the PDex IG utilizes mTLS for payer authentication, we are not requiring that protocol and recognize that other methods, such as SMART Backend Services, UDAP, or other trust community specified means, may be appropriate and easier to implement at scale. Payers will be able to choose the protocols or combination of protocols they deem appropriate as long as they meet the applicable security and privacy requirements. Comment: Multiple commenters had concerns regarding FHIR due to the lack of mature HL7 FHIR IGs and recommended that CMS instead advance payer to payer data exchange by leveraging the TEFCA QHINs. A few commenters recommended that CMS address the need for a legal governance framework for payer to payer data exchange. A commenter recommended that CMS work with ONC and the TEFCA RCE to incorporate the payer to payer data exchange use case into TEFCA’s planned support for payment and operations exchange. The E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8826 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations commenter also recommended that CMS allow payers to comply with the Payerto-Payer API requirements by participating in TEFCA. Response: We agree with the commenter that TEFCA can provide an efficient vehicle to query, send, and receive standardized electronic health information (EHI) from a broad array of participants enabling payer to payer data exchange. While standards and IGs for using FHIR within a network like TEFCA are still maturing, the FHIR Roadmap for TEFCA Exchange outlines the path for implementation. In addition, ONC and the RCE are currently developing the requirements in Common Agreement Version 2.0 for FHIR-based exchange under TEFCA across Exchange Purposes, including for Payment and Operations. ONC is aiming to publish Common Agreement Version 2.0 in the first quarter of 2024. To the extent that the requirements of this rule can be met through TEFCA exchange by the compliance dates, payers are permitted to do so. However, as there are methods for exchanging data under TEFCA that do not comply with the standards requirements we are finalizing (such as exchanging information using a method other than a FHIR API), participation in TEFCA, including exchanging the required data, does not necessarily mean that the payer is meeting the requirements of this rule. We note that payer to payer data exchange is legally required under this final rule and as such, legal agreements are not required. However, we understand that some payers may still request legal agreements. CMS is also working closely with ONC to explore how TEFCA could potentially be leveraged to support scalable governance for payer to payer exchange. Comment: Multiple commenters expressed support for CMS requiring the Bulk Data Access IG. A commenter stated that this IG was designed to exchange population level data to allow payers and providers to analyze care using the tools of ‘‘big data’’ analytics and for bulk information exchange between payers and providers for populations covered under value-based arrangements. A commenter stated it is critical to pace mandates with the development and adoption of standards and that the Bulk Data Access IG is not finalized or adopted by HHS. Another commenter stated that while the Bulk Data Access IG is the correct specification for transferring large amounts of data between two payers, the IG is still evolving. A commenter highlighted that the Bulk Data Access IG will require additional development efforts for their organizations since it is VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 new. Another commenter stated that the Bulk Data Access IG does not include aspects that are relevant to the Payer-toPayer API. Response: In the ONC Cures Act final rule HHS adopted the Bulk Data Access IG at 45 CFR 170.215(d)(1). In the CMS Interoperability and Patient Access final rule (85 FR 25510), we finalized a requirement to implement, maintain, and use API technology conformant with the standards at 45 CFR 170.215, which includes the Bulk Data Access IG. In this final rule, we are finalizing standards applicable for each API. Bulk data exchanges are usually used for system-to-system use cases and allow large volumes of information on a group of individuals to be shared in one exchange, which could be useful for sharing data between payers. Therefore, we feel that the Bulk Data Access IG is relevant for the Payer-to-Payer API and is being finalized as proposed. Comment: Multiple commenters recommended blockchain based technologies be used for the payer to payer data exchange. A commenter recommended that CMS support and evaluate blockchain-based technologies for the payer to payer data exchange and recommended that there needs to be confidence in the ability of blockchainbased technologies to leverage APIs for associated data movement. Another commenter recommended that CMS retain regulatory flexibility to enable future data exchange opportunities, including the potential for permissioned on-chain PHI access rather than an API call and response model. Response: We acknowledge that there are a range of technologies that may facilitate interoperability. In conjunction with ONC, we are working to establish standards that result from the work of SDOs and have been generally agreed upon by the industry through consensus-based processes. Blockchain technologies do not meet those criteria at this time, but we will continue to monitor evolving technologies and their possible benefits for interoperability. In the meantime, we are not prohibiting payers from using blockchain technology if they are doing so in a way that meets their legal requirements. Comment: Some commenters stated that payers, especially state Medicaid and CHIP agencies, would need technical assistance with implementing the Payer-to-Payer API. Multiple commenters stated that payers could use HIEs to implement the Payer-to-Payer API requirements, including the opt in process, which would reduce the burden on payers. PO 00000 Frm 00070 Fmt 4701 Sfmt 4700 Response: CMS has hosted, and intends to host in the future, CMS and HL7 FHIR Connectathons, which are free for stakeholders to attend, as well as provide educational webinars providing overviews of the technical requirements set forth in the interoperability rules. Additional public resources also exist through HL7, such as HL7 FHIR Connectathons, HL7 website resources and HL7 FHIR workgroup meetings. We understand that some payers may have implementation challenges and one of the reasons we are finalizing 2027 compliance dates is to give impacted payers additional time to prepare and test any new processes they may need to implement. To the extent that it reduces burden, we encourage payers to partner with HIEs or HINs, especially those operating under TEFCA, to facilitate payer to payer data exchange, subject any other applicable laws governing privacy and disclosure of these data. Some HIEs may already have the technical framework to manage patient consent or engage in standardized data exchange via FHIR APIs in ways that existing payer systems do not. Nothing in this rule would prohibit an impacted payer from partnering with an HIE to meet its requirements. For instance, as HIEs may have access to clinical data from providers that payers do not, some impacted payers may want to contract with an HIE to host their required API, either as their repository for clinical data, or as an intermediary with the payer’s own systems. The HIE could then augment payer data with other clinical data they have access to in order to enhance the data available to via the Patient Access, Provider Access, and Payer-to-Payer APIs, subject to other applicable law. Comment: A commenter cautioned that CMS’s proposals could result in each payer building their own API, and each payer pulling data from every other payer within a state. A commenter stated that it is not feasible for every clearinghouse to maintain so many nonstandard connections, and to do so would be costly and risky. The commenter stressed the urgency to implement a National Data Warehouse Exchange Hub/Clearinghouse. Response: Impacted payers will not have to maintain non-standard connections for this payer to payer data exchange, as we are requiring impacted payers to use a FHIR API to support interoperable implementations. We are requiring impacted payers to use the same standards specifically so that connections between payers do not need to be ‘‘hard coded’’ but can rely on the E:\FR\FM\08FER2.SGM 08FER2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations same technical standards to connect to any other payer’s endpoint. There is no requirement to use a clearinghouse, but to the extent it could benefit payers, we encourage them to leverage HIEs or HINs. Comment: A commenter recommended that CMS resolve the technological infrastructure dependencies by further investing in the HL7 FAST Accelerator and ONC’s work to facilitate patient matching and support implementation of the HL7 FAST Accelerator solutions to enable scaled exchange through FHIR APIs. Another commenter recommended that CMS collaborate with ONC to encourage industry adoption of the solutions outlined by the HL7 FAST Accelerator, at minimum, identity resolution, security, and directory for the Payer-toPayer API. Response: We will continue to work closely with ONC on the FAST Accelerator and will seek to leverage any appropriate solutions being developed as part of this work. We are also committed to continuing to work with HL7, the Accelerators, and interested parties within the industry in defining, participating in, and convening testing events, as well as developing and maintaining the specifications, thereby moving them toward greater maturity and will adopt solutions as appropriate to our use cases as they mature. b. Payer-to-Payer API Data Content Requirements lotter on DSK11XQN23PROD with RULES2 i. Data Content We proposed to require impacted payers to implement and maintain a Payer-to-Payer API to exchange claims and encounter data (excluding provider remittances and patient cost-sharing information), all data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI), and certain information about prior authorizations that the payer maintains with a date of service on or after January 1, 2016. As stated in the proposed rule (87 FR 76255), this set of data is consistent with requirements for the Patient Access API finalized in the CMS Interoperability and Patient Access final rule (85 FR 2555) and our proposals for the Patient Access and Provider Access APIs. Using the same data content standards across the APIs in this final rule adds efficiencies for payers and maximizes the value of the work that has already been done, reducing the overall burden for impacted payers. In response to comments, we are finalizing our proposal, with modifications. We are modifying the VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 data content by excluding data related to denied prior authorizations. In addition, we are also finalizing a modification by only requiring impacted payers to exchange data with a date of service within 5 years of the request. Comment: Many commenters expressed that using the same January 1, 2016, start date for the set of data that must be exchanged via the Payer-toPayer API would include significant historical data that are unlikely to be relevant to a patient’s current health status and ongoing care. Those commenters urged us to establish a rolling period of time to the date of the exchange for the data content that must be shared. Some commenters pointed out that the technical and operational level of effort to integrate a patient’s full history would impose significant data storage and archival costs on payers. Some commenters disagreed with CMS’s justification for the proposal that payers were the appropriate maintainer of a patient’s complete health history and suggested that while payers had a role to play, patient apps could be a more efficient, effective and reliable method to meet that objective. Response: While we continue to support and emphasize the benefits of payer to payer data exchange, we also recognize the burden of exchanging and storing large amounts of complex patient data. There are two main benefits for Payer-to-Payer API data exchange: to facilitate care continuity when a patient changes payers and to maintain the patient’s record so that relevant information is not lost. After consideration of the comments, we agree that requiring impacted payers to exchange a patient’s entire history back to the proposed January 1, 2016, date would impose a significant burden on payers to integrate and maintain those data. In effort to balance the benefits we described in the proposed rule, which were supported by commenters, and the burden that some commenters raised, we are finalizing a modification to our proposal to limit the payer to payer data exchange to only the previous 5 years of data. As described previously, solutions are emerging in the marketplace for Personal Health Records (PHR) that are better suited to keeping patient records for an indefinite period than payers, which might themselves maintain limited clinical data. ONC defines a PHR as an electronic application through which patients can maintain and manage their health information (and that of others for whom they are authorized) in a private, secure, and PO 00000 Frm 00071 Fmt 4701 Sfmt 4700 8827 confidential environment.78 For instance, health apps can create a longitudinal record by gathering data both from payers via the Patient Access API, and providers’ CEHRT. Even so, it is still important for patient care and continuity for a patient’s new payer to receive and maintain some recent historical record of the patient’s care. When a patient changes payers, only the information that the current payer maintains would be available via the Patient Access, Provider Access and Payer-to-Payer APIs. As payers and providers will have a more robust infrastructure for data exchange (including via the FHIR APIs required in this final rule), they are better suited to enable data exchange to providers and between payers than a patient would be with their PHR. A patient could supplement information that their payer maintains with information from their PHR, but should not have the primary responsibility for ensuring the technical capability to send their records. For continuity of ongoing care, we expect that the more recent data are, the more relevant they generally would be. Therefore, it is important to establish a period of time that is reasonably likely to include information relevant to foreseeable care after a patient changes payers. While many commenters suggested shortening the timeframe for data to be exchanged, we did not receive comments suggesting a specific period. Five years balances the needs to manage care continuity and establish a patient record with their new payer while not being overly burdensome on payers to exchange and maintain a large amount of data that may not be relevant. Being able to keep the most recent 5 years of data when transitioning between payers will cover the vast majority of a patient’s ongoing and future healthcare needs. Even for patients with chronic conditions, data older than 5 years are unlikely to have significant relevance or value when more recent information is available. This amount of data sharing strikes the right balance of limiting the burden to payers, while still reaping the benefits of care coordination and continuity and allowing patients to maintain a significant amount of data with their current payer. However, we disagree with commenters who suggested limiting the data exchange to a shorter period to focus only on current health conditions and ongoing care. We do not want to 78 Office of the National Coordinator for Health Information Technology (2016, May 2). Frequently Asked Questions. Retrieved from https:// www.healthit.gov/faq/what-personal-health-record. E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8828 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations narrow the scope of data to be exchanged to focus simply on care continuity. Health information that is not relevant at the time a patient changes payers may later be important for the patient or their providers to have access to. Beyond the care continuity justification for payer to payer data exchange, making a reasonable amount of patient data available, even if it is not the patient’s full record, is still an important goal of this policy. For these reasons, and to better balance the burden on payers and benefit to patients, we are finalizing a modification to our proposal to only require the most recent 5 years of data be exchanged between impacted payers. We will monitor the Payer-to-Payer API implementation and usage to determine whether to extend this timeframe in the future. For some patients, those 5 years of data may still comprise a significant quantity. However, the data content requirements for the Payer-to-Payer API are built on structured data standards, such as the data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI), which should be easily ingested using the recommended IGs. The exception to that structured data is administrative and clinical documentation submitted by providers related to prior authorization requests and decisions, as discussed later in this section of this final rule. We encourage impacted payers to review the PDex IG for guidance on ingesting patient data in a structured manner that creates a useable patient record.79 We also note that CMS will continue to work closely with ONC and other Federal agencies to improve data interoperability through initiatives such as the USCDI+. Comment: Multiple commenters recommended narrowing the scope of data that would be exchanged via the Payer-to-Payer API. Some commenters suggested that CMS narrow the scope of information required to be exchanged to specific data that would facilitate a change in coverage. Other commenters recommended that CMS only require a minimum set of information necessary to facilitate a patient’s transition and improve care coordination. Some commenters recommended that CMS work with industry stakeholders to determine a subset of key coverage, clinical, demographic, claims, and encounter information to share via the payer to payer data exchange to support 79 Health Level Seven International (2023, October 28). Da Vinci Payer Data Exchange. Retrieved from https://build.fhir.org/ig/HL7/ davinci-epdx/. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 coverage transitions. Another commenter expressed that the data exchange should be limited to claims data and prior authorization decisions. Response: We disagree with the view that the information sent via a Payer-toPayer API should be limited to a minimum set of data that would facilitate transition between payers and continuity of ongoing care. While care continuity is one purpose of the Payerto-Payer API, there are use cases that benefit from additional information being sent. Specifically, we proposed to include claims, encounter data and clinical data to maintain the availability of those data for the Patient Access and Provider Access APIs after a patient changes payers. We acknowledge that a patient’s historical data may not be directly relevant to a patient’s care at the time of transition. However, that does not mean that a patient or provider would never have a reason to access those data. While the payer to payer data exchange has its use cases, the Patient Access and Provider Access APIs have additional use cases. Therefore, it is important to consider not just how a payer would use data received from a previous payer, but how patients and providers may use it as well. A patient should not lose access to their recent claims, encounter, or clinical data from their payer because they are not strictly necessary to facilitate the transition to a new payer. As discussed, we are finalizing a modification to our proposal to limit the data to be sent to that with a date of service within 5 years of the request. Comment: Multiple commenters provided recommendations regarding clinical data to be exchanged. Some commenters stated that clinical information is not stored in a sharable format for the Payer-to-Payer API. Specifically, a commenter discussed how current technology cannot adequately parse through large, nonstandardized files. The commenter noted that clinical information sent by providers to payers is not received, structured, or stored in a way to be shared, as the X12 275 transaction standard for healthcare claims attachments has not been finalized (though a standard has been proposed in the HIPAA Standards for Healthcare Attachments proposed rule (87 FR 78438)). In addition, a commenter recommended that CMS work with ONC to implement a requirement that providers share comprehensive clinical data in a FHIR enabled format with patients and payers. Another commenter recommended that CMS remove the requirement that impacted payers share all clinical information in PO 00000 Frm 00072 Fmt 4701 Sfmt 4700 USCDI and focus on the clinical information that has been received in standard, electronic structured format related to prior authorization. A commenter asked CMS to explain whether impacted payers only need to make available via the API the USCDI data classes and data elements that they currently maintain. Response: We acknowledge that not all information that we are requiring to be made available through the Payer-toPayer API will be stored and maintained in a structured data format within the payers’ systems. However, the benefits of ensuring that a patient’s data follow them to a subsequent payer outweigh the burden of exchanging that information. In many circumstances, clinical information can be significantly more informative than claims or encounter information. For example, claims for laboratory tests will not provide the actual results of those laboratory tests, which is more important than simply knowing that laboratory tests were done without knowing what the results were. However, we know that many payers do not maintain clinical data, or only maintain specific sets of clinical data and therefore claims and encounter information can fill gaps that would otherwise be missing. Our data content requirements for the Payer-to-Payer API are built on the existing requirements for the Patient Access API. The set of clinical information that we have required to be available via the Patient Access API since January 1, 2021, is defined by the USCDI standard at 45 CFR 170.213. As discussed in section II.A.2.d. of this final rule, for clarity we are changing the regulatory text to point directly to the USCDI standard at 45 CFR 170.213 for the Patient Access API, as well as the new Provider Access and Payer-to-Payer APIs. Therefore, to the extent a payer maintains those data, the data classes and data elements in USCDI should already be in payers’ systems in a form that makes them available via a FHIR API. Because payers should already have experience making that set of information available, there should not be a significant burden to make the same underlying data available through multiple APIs. Henceforth, with our revisions to directly reference the content standard at 45 CFR 170.213, the Patient Access, Provider Access, and Payer-to-Payer APIs will all be required to include all data classes and data elements within that content standard that are maintained by the payer. We are not adding any requirements in this final rule that would require payers to parse and convert E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations unstructured files into structured data, either for their own records or to share via the APIs. We also expect that as standards are adopted across the industry, an increasing percentage of clinical data will be stored and transmitted in structured formats, which is a result we encourage. We note, however, that unstructured administrative and clinical documentation submitted by a provider to support a prior authorization request (excluding those for drugs and those that were denied) are required to be sent through the Payer-to-Payer API. Comment: A commenter recommended that the patient’s choice whether to opt into the Payer-to-Payer API be part of the data exchanged. Response: That piece of information is required as part of the attestation of patient opt in and is discussed in more detail in section II.C.3.d.iv. of this final rule. If a patient does not opt in, there would be no payer to payer data exchange under these requirements. Comment: A commenter recommended that CMS reduce the quantity of data that needs to be exchanged by not requiring that denied claims be exchanged between payers. Response: While some denied claims may be extraneous (such as a claim denied because it is a duplicate), they may contain important information about a patient that would be beneficial to their record. A claim, even if it is denied, can indicate that a patient received items or services, even if the claim was not paid. Denied claims are also included in the information that is currently required to be available via the Patient Access API (85 FR 25532). We did not propose, nor are we finalizing, to exclude denied claims from the Payer-to-Payer API (or the Provider Access API). However, as discussed in section II.C.3.b.iii., we are excluding denied prior authorization requests from the set of information that must be exchanged between payers. Unlike claims, a denied prior authorization request does not indicate that the patient actually received items or services and therefore an exclusion is justified, as discussed. Comment: Multiple commenters stated that payers have already formatted the necessary data elements and prepared their systems to share the standardized data through other FHIR APIs. A commenter noted that this infrastructure can be adapted for expanded interoperability use cases, such as the Payer-to-Payer API. However, another commenter believed that barriers to implementing FHIR APIs exist in the way of process siloes in payer organizations. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 Response: We appreciate the confirmation that payers have already formatted the necessary data elements to be shared through other FHIR APIs, particularly the Patient Access API. We agree that infrastructure can be adapted for this Payer-to-Payer API and are requiring the same data classes and data elements already required for the Patient Access API. Payers have already formatted these data elements and prepared their systems to share these standardized data via a FHIR API. We note that the Payer-to-Payer API data content requirement also includes both structured and unstructured administrative and clinical documentation submitted by providers related to prior authorizations, of which the unstructured documentation is not required to be shared through the Patient Access and Provider Access APIs. We also agree that payers have already devoted the development resources to standing up a FHIR API infrastructure when they implemented the Patient Access API, which could be adapted for expanded interoperability use cases. Using the recommended IGs will reduce implementation barriers and we encourage payers to get involved in the HL7 FHIR workgroups and to collaborate with other payer organizations on these API implementations. In addition, we are delaying the compliance dates to 2027 rather than the proposed 2026 not just to give payers time to implement the technical requirements, but also to address any internal business process changes that may be necessary. ii. Provider Remittances and Patient Cost-Sharing We proposed to exclude provider remittances and patient cost-sharing information from the Payer-to-Payer API because that information is often considered proprietary by payers. While there could be value to patients having provider remittances and patient costsharing information available via the Patient Access API, exchanging those data between payers would have only a limited beneficial impact on care. We believed that information about provider remittances and patient costsharing under another payer would have no impact on a payer’s ability to ensure care continuity when a patient changes payers. Furthermore, there are existing processes for coordinating payment when a patient has concurrent payers that we did not wish to affect. Sharing claims and encounter information, even without these cost details, would complement the data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI), by PO 00000 Frm 00073 Fmt 4701 Sfmt 4700 8829 providing more information about the patient’s care history to support care coordination and efficient operation. Comment: Multiple commenters supported the exclusion of provider remittances and patient cost-sharing information from the data shared through the payer to payer data exchange. However, a few commenters noted that this policy could create additional development work if payers need to segment data elements to make provider remittances and patient costsharing information available via the Patient Access API, but not the Payerto-Payer API (or Provider Access API). Response: We acknowledge that segmenting data could create additional burden for payers. However, as discussed in the proposed rule, we proposed to not require provider remittances and patient cost-sharing information be included in the data shared via the Payer-to-Payer API because payers may consider that information proprietary. We agree that cost information would have limited benefits to care continuity when a patient changes payers. However, as our policy to exclude that information is intended to protect the payer’s proprietary information, we are not prohibiting payers from sending it. Therefore, if a payer believes that implementing their Payer-to-Payer API in such a way that includes provider remittances and patient cost-sharing information would reduce burden, they are not prohibited from doing so. iii. Prior Authorization Data We refer readers to section II.A.2.a. of this final rule where we discuss in more detail how prior authorization data must be available through the Patient Access API—and therefore through the other APIs as well. Our proposals to include prior authorization data in the Payer-toPayer API mirrored our proposals to include prior authorization data in the Patient Access and Provider Access APIs. We stated that it would be valuable for payers to make certain information about prior authorizations available via the Payer-to-Payer API, particularly when a patient enrolls with a new payer. Prior authorization data can inform a payer about ongoing treatments. Payers can use that information to determine whether a new patient needs a new prior authorization, and, if so, whether the information from the previous payer is sufficient for them to issue a decision without additional work by the patient or provider. Prior authorization is a significant focus of this final rule as a whole, and information about these requests and decisions could be beneficial to E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8830 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations patients, providers, and payers. As discussed in more detail in section I.D., this final rule does not apply to any prior authorization processes or standards related to any drugs. We discuss prior authorization and prior authorization processes in more depth in section II.D. of this final rule. We proposed to add certain information about prior authorizations to the set of data that impacted payers must make available via the Payer-to-Payer API upon request from another payer. We proposed that the information must include: • The status of the prior authorization; • The date the prior authorization was approved; • The date or circumstance under which the authorization ends; • The items and services approved; • The quantity used to date; and • Related administrative and clinical documentation. Comment: Many commenters generally supported including prior authorization information in the Payerto-Payer API and stated that this would increase transparency, improve care coordination, and reduce burden on providers, patients, and payers. Commenters stated that including prior authorization data in the Payer-to-Payer API would protect beneficiaries’ access to necessary items and services since information on prior authorization is not always transferred when beneficiaries switch coverage today. A commenter stated that prior authorization information would enable the new payer to provide continuous coverage for existing treatments and highlighted that this is especially important for patients receiving cancer treatment and specific medications after progressing through step therapies. Multiple commenters expressed support for sharing historical data to increase payer knowledge of previous patient prior authorization decisions and health care data, and to encourage continuity of care. Response: We appreciate commenters concurring on the importance of previous payers sharing authorization data. The prior authorization process is a priority area for us to reduce patient and provider burden. Comment: Multiple commenters recommended that some types of prior authorization data should be excluded from the Payer-to-Payer API. A few commenters suggested that CMS not require impacted payers to include information about prior authorizations without fully understanding how payers could use that information. Commenters specifically recommended that CMS VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 exclude information about previously denied prior authorizations. A commenter noted that this might be used to limit care for patients, even if they meet the new payer’s criteria for the same service. Conversely, another commenter noted that there is some benefit to patients and providers having a basic history of denied prior authorization requests. Response: After considering the comments we received, we are removing the requirement to include denied prior authorization decisions in the Payer-toPayer API. However, we note that supporting clinical information associated with such decision may be available under the requirement to share all data classes and data elements included in the data content standard at 45 CFR 170.213 (USCDI) that are maintained by the payer. As discussed previously, we are focusing on the aspects of payer to payer data exchange that relate to care continuity when a patient changes payers. Because a previously denied prior authorization decision generally would not reflect ongoing treatment, and thus the information may not support care continuity, the value of including such information would likely be outweighed by the drawbacks of doing so. A denied prior authorization decision does not provide information about the patient’s ongoing care because it does not show that patients received any items or services. If a patient did receive those items or services despite the denial of coverage, that information would have to be gathered from elsewhere (such as clinical data), regardless of whether the payer receives information about the denied prior authorization decision. However, we emphasize that denied prior authorization decisions are required to be shared via the Patient Access and Provider Access APIs because the benefits to those parties of accessing that information can be significant, especially for resubmitting requests or appealing decisions. However, this information could be used in ways that would negatively impact a patient’s care or coverage. For example, information about a denied prior authorization decision could potentially create bias in future prior authorization decisions with the new payer, and patients could experience challenges to obtain coverage for a given service. Even if a previously denied prior authorization does not in fact create bias with the new payer, some patients may fear that result, which could lead to fewer patients opting in to payer to payer data exchange. Comment: Several commenters recommended not including the PO 00000 Frm 00074 Fmt 4701 Sfmt 4700 quantity of services used to date due to the concern that health plan claims data updates are often delayed and, therefore, may not be a reliable source to track the number of authorized services used to date. A commenter recommended that CMS require only the authorized units of items and services for a specific prior authorization, rather than the items and services used under the authorization. Response: Upon reviewing comments, we agree with the many commenters who pointed out that the authorized services used to date under a prior authorization may be more confusing than useful for patients and providers. We heard that the quantity used to date would only be available based on claims that have been submitted and adjudicated for those items or services. Because there can be a significant lag between the items or services being provided and the claim being adjudicated, the information available through the APIs could be out-of-date and inaccurate. Therefore, we are finalizing a modification to our proposal that will not require payers to share the number of items or services used under the authorization. We are also finalizing a modification to our proposals that this information does not need to be included in the Patient Access API (discussed in section II.A.2.a.ii. of this final rule) or the Provider Access API (discussed in section II.B.2.g. of this final rule). Comment: Several commenters encouraged CMS to include unstructured documentation and forms that were submitted as part of a prior authorization request. Some payers commented that making that documentation available via the Payerto-Payer API will facilitate their ability to make prior authorization decisions for a new patients without requesting duplicative information be submitted. Commenters stated that unlike in the Patient Access and Provider Access APIs, sharing supporting documentation through the Payer-to-Payer API could allow the new payer to use that information to make decisions about subsequent prior authorizations, if required. A few commenters held the opposing view that CMS should not finalize requirements to include clinical documentation and forms with prior authorization information via the Payerto-Payer API. Response: We are finalizing a modification to our proposal for the Patient Access and Provider Access APIs to remove the proposed requirement to make available unstructured administrative and clinical documentation. We have concluded that E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations for these APIs, the burden outweighs the benefit. However, that is not the case for the Payer-to-Payer API. One of the goals of this regulation and the Payer-to-Payer API requirement is to promote greater continuity of care when patients change payers, especially regarding prior authorization. In order for payers to ease that transition, they need as much relevant data related to recent and ongoing care as possible. For instance, current data can allow a payer to authorize coverage for ongoing treatment, without requiring repeat testing or needing a provider to resubmit clinical information that the provider has already submitted to a previous payer. In addition, the concerns regarding payers’ ability to quickly make the unstructured administrative and clinical documentation available, via the Patient Access and Provider Access APIs, do not apply to the Payer-to-Payer API. Under our Patient Access and Provider Access API policies, payers have 1 business day from the time they receive the prior authorization request or there is another status update to make prior authorization information available. For the Payer-to-Payer API, absent a specific patient request, typically payers only have to exchange data at the time a patient changes payers, or quarterly for concurrent payers. Therefore, unless a prior authorization request is submitted within the last days of coverage, payers will have a longer timeframe to ensure that unstructured documentation is included in the patient’s record and can be transferred to another payer when the need or requirement to transfer data through the Payer-to-Payer API arises. Furthermore, the concern about a patient app or provider’s EHR not being able to read and display unstructured documentation does not apply to payers, which regularly receive unstructured administrative and clinical documentation with prior authorization requests. Comment: A commenter suggested that given the complexity and variation across prior authorizations, any pertinent data from peer-to-peer reviews should be included in Payer-to-Payer API exchange. Response: Based on comments and conversations with payers, we understand that many payers consider the specific criteria they use to make prior authorization decisions to be proprietary information. In addition, because payers have different criteria, information about internal peer reviews of prior authorization requests from another payer has only limited usefulness. Therefore, we are not requiring payers to exchange any VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 documentation that the payer itself generates regarding a peer-to-peer review of a prior authorization request. But we are requiring impacted payers exchange structured and unstructured administrative and clinical documentation submitted by providers related to prior authorizations to assist care continuity and allow payers to make their own decisions based on the patient’s specific needs without requiring duplicative submissions from a provider. iv. Duration of Prior Authorization Data to be Exchanged We proposed that impacted payers would be required to make certain information about prior authorizations available via the Payer-to-Payer API for the duration that the authorization is active and for at least 1 year after the prior authorization’s last status change. We proposed to require the availability of prior authorization information for at least 1 year after any status change across the Patient Access, Provider Access and Payer-to-Payer APIs, so that information from denied and expired prior authorizations would not be lost when they were not approved or no longer active. Comment: Many commenters supported CMS’s proposal that certain information about prior authorizations be available for the duration of an active authorization and for at least 1 year after the last status change. Some commenters were in favor of retaining a patient’s historical prior authorization data indefinitely. Another commenter requested clarification on how the proposal to make prior authorization data available for at least 1 year would align with the requirement that impacted payers make available patient data with a date of service on or after January 1, 2016. Response: As discussed previously, we are finalizing a modification to our proposal that will not require denied prior authorization requests to be shared via the Payer-to-Payer API at all. Such information must be shared through the Patient Access and Provider Access APIs beginning in 2027 (see sections II.A.2.ii. and II.B.2.g. of this final rule for more information). We note that the requirement to share patient data with a data of service on or after January 1, 2016, comes from the CMS Interoperability and Patient Access final rule, which required claims, encounter information and certain clinical data to be made available via the Patient Access API. Prior authorization information was not included in that rule, and therefore, we do not have reason to believe that payers are generally PO 00000 Frm 00075 Fmt 4701 Sfmt 4700 8831 maintaining prior authorization data back to that date. In addition, the obligation to share encounter, claims, or other information from within 5 years of the request is contingent on the payer maintaining those data; for payers that are not required to maintain records past a certain point or that do not have internal policies for retaining records past a certain time period, the data may not be available to be shared through the Patient Access API. As discussed in the proposed rule, the availability of claims and clinical data are more important to patient care than information about prior authorizations that have expired. Claims and encounter data indicate items and services that the patient actually received in the course of their care. Information from a prior authorization indicates whether certain items and services were approved for coverage, and often the basis for that decision. While active or recent prior authorization information is important because it can indicate current or recent medical necessity, such information cannot be inferred from prior authorizations that have been expired for more than 1 year as they would not indicate any sort of ongoing care. Claims and clinical data maintained by the previous payer that are related to the treatment that occurred under an expired prior authorization would replace the need for the expired prior authorization decision itself. While claims and clinical data associated with an expired prior authorization can indicate the type of care received, as discussed earlier in this section, the value to a new payer of prior authorizations that were not acted upon, meaning they do not have a claim or any clinical data associated with them and are not associated with any past treatment or active care for the patient, is outweighed by the potential drawbacks of including such information. We also considered comments summarized previously and also discussed in sections II.A. and II.B. of this final rule regarding the inclusion of these data in the Patient Access and Provider Access APIs. While some API content differences may be beneficial or practical (such as the exclusion of provider remittances and patient costsharing information), we are keeping the API requirements as similar as possible to reduce burden by standardizing data content. We emphasize that for ongoing long-term care, any active prior authorizations must be included, even if they have been in that status for more than 1 year. Furthermore, our policy allows payers to make these prior authorization data available for longer E:\FR\FM\08FER2.SGM 08FER2 8832 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations lotter on DSK11XQN23PROD with RULES2 than 1 year, if they believe it adds value to patients, providers, themselves or future payers. v. Considering Prior Authorizations From Another Payer While we did not propose to require payers to review, consider, or honor the active prior authorization decision of a patient’s former payer, payers may gain efficiencies by doing so. We sought comment on the benefits, burdens and considerations of imposing such a requirement. However, we did not make any proposals and therefore are not finalizing any policies in this area. We do note that since we published the proposed rule, the Medicare Program; Contract Year 2024 Policy and Technical Changes to the Medicare Advantage Program, Medicare Prescription Drug Benefit Program, Medicare Cost Plan Program, and Programs of All-Inclusive Care for the Elderly final rule (CY 2024 MA and Part D final rule) was issued, which requires MA coordinated care plans to provide a minimum 90-day transition period when an enrollee switches to a new MA organization, during which the new MA organization may not require prior authorization for an active course of treatment. Comment: A commenter requested clarification about the relationship between this final rule and the provision for MA plans at 42 CFR 422.112(b)(8)(i)(B) added by the CY 2024 MA and Part D final rule. That rule requires MA coordinated care plans to provide a minimum 90-day transition period when an enrollee switches to a new MA organization during which the new MA organization may not require prior authorization for an active course of treatment. Response: The requirements at 42 CFR 422.112(b)(8) adopted in that recent final rule apply to Part A and B benefits covered by an MA plan. An ‘‘active course of treatment’’ is defined at 42 CFR 422.112(b)(8)(ii) as a course of treatment in which a patient is actively seeing a provider and following a ‘‘course of treatment,’’ which is defined as a prescribed order or ordered course of treatment for a specific individual with a specific condition, outlined and decided upon ahead of time with the patient and provider. A patient can have an active course of treatment to which 42 CFR 422.112(b)(8) will apply that did not require prior authorization by their previous payer. Per 42 CFR 422.112(b)(8)(i)(B), MA organizations offering coordinated care plans must have, as part of their arrangements with contracted providers, policies for using prior authorization VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 that provide for a minimum 90-day transition period for any active course(s) of treatment when an enrollee has enrolled in an MA coordinated care plan, even if the course of treatment was for a service that commenced with an out-of-network provider. Further, the MA plan cannot deny coverage of such active courses of treatment on the basis that the active course of treatment did not receive prior authorization (or was furnished by an out-of-network provider) but may review the services furnished against the MA plan’s coverage criteria when determining payment. This includes enrollees who are new to an MA plan, an enrollee switching from Traditional Medicare to MA, or enrollees new to Medicare and enrolling in an MA plan for the first time. In that final rule, we explained how we expect any active course of treatment to be documented in the enrollee’s medical records so that the enrollee, provider, and MA plan can track an active course of treatment to avoid disputes over the scope of the new requirement. Therefore, an active course of treatment should be included in the data exchanged between impacted payers, regardless of whether a previous payer required a prior authorization. Under this final rule, the data content that must be shared via the Payer-toPayer API includes the claims and encounter data (excluding provider remittances and cost-sharing data), all data classes and data elements included in a content standard at 45 CFR 170.213 and certain information about prior authorizations maintained by the payer with a date of service within 5 years of the request. Almost any active course would be represented within that dataset. Any active course of treatment covered by 42 CFR 422.112(b)(8)(i)(B) will thereby become part of the patient’s record with their new payer. It is important, especially in light of 42 CFR 422.112(b)(8), that MA enrollees are aware that their active course of treatment is being honored and for how long. That will allow MA enrollees in plans subject to this new requirement, and their providers, to plan for a new prior authorization request, if necessary. Although this particular need for access to information about active courses of treatment is unique to MA enrollees in MA coordinated care plans, the data exchange and Payer-to-Payer API requirements outlined here are applicable to any impacted payer. While we encourage other payers to honor an active course of treatment similar to the requirements of 42 CFR 422.112(b)(8) for MA coordinated care plans, we have not PO 00000 Frm 00076 Fmt 4701 Sfmt 4700 proposed to require that of any payers not covered by that rule. c. Identifying Previous and Concurrent Payers and Opt In i. Process Timing We proposed that all impacted payers develop and maintain processes to identify a patient’s previous/concurrent payer(s) and to allow patients or their personal representatives to opt into the payer to payer data exchange (both with previous and concurrent payers) prior to the start of coverage. Additionally, we proposed that impacted payers would be required to establish similar processes for current patients prior to the compliance dates, to ensure those patients have the ability to opt in and have their data shared through the API. We are finalizing a modification to this proposal, as discussed, to establish a deadline for these processes at 1 week after the start of coverage (as that term is defined for each program). We emphasized in the proposed rule that obtaining a patient’s opt in permission and identifying the previous/concurrent payer(s) could not delay an applicant’s eligibility determination or start of coverage with any impacted payer. We noted that the proposed requirement to identify a patient’s previous/concurrent payer(s) and obtain a patient’s opt in may not always be feasible before the start of coverage, for instance, if a patient does not provide enough information to identify their previous payer. We emphasized that payers must begin this process before the start of coverage, but realize that it may take longer than enrollment. In that case, the impacted payer would be required to continue to engage with the patient to gather their permission and identify any previous/ concurrent payer(s). Only once the impacted payer has received permission and identified those other payers would they be required to request patient data, as outlined in sections II.C.3.c.ii. and II.C.3.c.iv. of this final rule. Using Medicaid as an example, if a state has all the information necessary to determine an individual’s eligibility before it has identified the previous payer, the state must determine the individual’s eligibility and enroll the individual in Medicaid coverage, if determined eligible, while continuing to follow the Payer-to-Payer API requirements as expeditiously as possible post-enrollment. For new patients enrolling on or after the compliance dates, we proposed to require impacted payers to maintain a process for patients to opt into the Payer-to-Payer API data exchange and to E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations identify their previous/concurrent payer(s) prior to the start of their coverage. In section II.C.4.b. of this final rule, we discuss the possible incorporation of these requirements into state applications for Medicaid or CHIP eligibility. In the proposed rule, we stated that making this process available to patients during the enrollment process, or immediately thereafter, would allow the proposed data exchange to take place as quickly as possible once the patient is enrolled with the new payer. For example, where there may not be communication during the enrollment process such as during the QHP enrollment on the FFEs, this process should be done immediately following enrollment. We solicited comment on incorporating the proposed requirements into the FFE QHP enrollment process as described at 45 CFR 156.265. Concurrent coverage means that an individual has coverage provided by two or more payers at the same time. This could include, for example, individuals dually eligible for Medicare and Medicaid who are enrolled in both an MA plan and a Medicaid managed care plan. Another example of concurrent coverage is when different services are covered by different Medicaid managed care plans for the same Medicaid beneficiary. Several payer deadlines in this rule are based on a patient’s ‘‘start of coverage.’’ For example, we proposed (and are finalizing) a requirement for impacted payers to request previous and concurrent payer information and a patient’s opt in for Payer-to-Payer API data exchange (discussed in section II.C.3.c.iv. of this final rule) no later than 1 week after the start of coverage. Throughout the preamble, we are using the term ‘‘start of coverage’’ to mean when coverage begins or, if coverage begins retroactively, to refer to a later milestone, depending on the payer type. However, to ensure feasible timeframes for new patients after the compliance dates, we are finalizing deadlines based on whether coverage starts prospectively or retroactively. Where coverage starts prospectively, the deadline will be based on the coverage start date (also known as the coverage effective date). In the case of retroactive coverage, to avoid a deadline in the past, the deadline for the payer to provide the required information about the Payer-to-Payer API, request identifying information about previous/ concurrent payer(s), and an opt in will be based on the date that the payer gets patient information and makes the patient’s coverage effective. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 Because the enrollment and coverage initiation processes for each program differ in their specifics, in regulation text, the concept of ‘‘start of coverage’’ is described differently for each type of impacted payer. That is, the regulatory text uses different, program-appropriate terminology for each impacted payer. For MA organizations, the ‘‘start of coverage’’ generally means the effective date of coverage, as used at 42 CFR 422.68. In some instances, an individual’s enrollment may be accepted by CMS with a retroactive effective date of coverage, as discussed in the Medicare Managed Care Manual, Chapter 2, section 60.4.80 In those cases, the ‘‘start of coverage’’ would be the date that the individual’s enrollment is accepted by CMS.81 Effectively, this means that the ‘‘start of coverage’’ is whichever is the later of those two dates—the effective date of coverage or the date that the individual’s enrollment is accepted by CMS. For example, an MA organization that receives an enrollment request from an individual that is accepted by CMS in January for a February 1 effective date of coverage, would have 1 week from February 1 to complete the applicable requirements. An MA organization that receives an enrollment request from an individual in January that is accepted by CMS on February 7 for a retroactive February 1 effective date of coverage, would have 1 week from February 7 (not February 1) to complete the applicable requirements as finalized in this rule. For Medicaid, a beneficiary’s coverage is generally retroactive 3 months from the date that they are enrolled in Medicaid. For CHIP, retroactive coverage varies among states. Therefore, for Medicaid and CHIP FFS and managed care, the ‘‘start of coverage’’ is simply the date the beneficiary is enrolled in the state’s MMIS (or equivalent process), not the date coverage takes retroactive effect. For QHP issuers on the FFEs, the start of coverage is generally the enrollee’s QHP coverage start date. In some cases, a payer may provide coverage retroactively, that is, a payer provides coverage starting on a date prior to enrollment, for instance due to the birth, adoption, or foster care placement of a new child. In that case, the ‘‘start of coverage’’ would be the effectuation of 80 Centers for Medicare and Medicaid Services (2011, August 19). Medicare Managed Care Manual. Retrieved from https://www.cms.gov/files/ document/cy-2024-ma-enrollment-anddisenrollment-guidance.pdf. 81 See also Medicare Managed Care Manual, Chapter 2, section 40.4.2. for similar enrollee notification requirements tied to the date that the individual’s enrollment is accepted by CMS. PO 00000 Frm 00077 Fmt 4701 Sfmt 4700 8833 coverage, as described at 45 CFR 155.400(e)(1)(iii). Effectively, this means the ‘‘start of coverage’’ is whichever is the later of those two dates—either the coverage start date or the effectuation of coverage. We refer to the coverage start date as the first date for which the enrollee has coverage and the term ‘‘effectuation of coverage’’ to refer to the date that the payer takes the steps to implement coverage, even if that coverage starts retroactively. For example, an FFE QHP issuer that receives enrollee information during an annual open enrollment period for a consumer whose coverage will start on January 1 of the following year would have 1 week from the enrollee’s coverage start date of January 1 to complete applicable requirements. An issuer that receives information and effectuates coverage on March 6 for an enrollee whose coverage starts retroactively on February 1 would have a week from the enrollee’s effectuation date, March 6 (not February 1), to complete the applicable requirements. Comment: Multiple commenters expressed concern regarding processes for opting in and collecting previous/ concurrent payer data occurring at the start of coverage, noting logistical challenges to collecting data at the time of a patient’s enrollment, including document format and regulatory challenges to updating existing enrollment forms. Multiple commenters provided recommendations regarding actions for payers to take at the time of enrollment to facilitate collecting this information, such as defining specific data and updating enrollment forms. In addition, multiple commenters stated that payers should be permitted to collect a patient’s opt in after enrollment. A commenter specifically recommended that collection should be allowed during the first month of active enrollment. Some commenters urged CMS to not require payers to collect data at enrollment to support the Payerto-Payer API, and instead to allow outreach to patients after enrollment through existing tools, such as payer portals. Another commenter stated that requesting that information at the time of the patient’s application would allow them to incorporate the process into their existing data collection processes. A commenter noted that the inability to opt in after the enrollment start date could result in low participation rates. Another commenter supported allowing patients to opt into data sharing during the open enrollment period. A commenter supported allowing a payer to collect a patient’s opt in prior to the compliance dates for state Medicaid and CHIP agencies and prior to enrollment E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8834 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations of new beneficiaries after the compliance dates. Response: We note that the terms used in the preamble and regulation text of our proposed rule were different. Our discussions in the proposed rule referred to ‘‘prior to the start of coverage,’’ which we explained in preamble and fully discussed throughout the proposed rule, but the proposed regulation text used the phrase ‘‘at enrollment’’ (except for QHP issuers on the FFEs where we used ‘‘no later than the effectuation of enrollment’’). We did not propose that new payers collect previous payer information at the time of enrollment. We stated that payers must begin the process of collecting the previous payer information and opt in prior to the start of coverage, but that it may take longer than the enrollment process. We are modifying the regulatory text to identify the start of coverage (rather than enrollment) as the milestone that tolls these requirements, consistent with the preamble discussion in the proposed rule. However, in response to public comments, we are finalizing a modification to our proposal by extending the deadline for both requesting identifying information about a patient’s previous/concurrent payer(s) and seeking opt in from the patient to 1 week after the start of coverage, with certain differences among payers. For MA organizations, we are modifying the deadline to no later than 1 week after the coverage start date or no later than 1 week after receiving acceptance of enrollment from CMS, whichever is later. In the case of Medicaid and CHIP FFS, we are modifying both deadlines to refer to 1 week after enrollment, to avoid confusion related to the retroactive eligibility rules in Medicaid. For QHP issuers on the FFEs, we are modifying the requirement to no later than 1 week after the after the coverage start date or no later than 1 week after the effectuation of coverage, whichever is later. Commenters were clear that establishing the start of coverage as the deadline for these actions would result in logistical challenges and compliance would be difficult for impacted payers. We understand that while some types of impacted payers, such as MA organizations, may have contact with patients before the start of coverage, in other cases, payers do not. Furthermore, while we are recommending that state Medicaid and CHIP agencies incorporate these requirements into their applications for coverage, states would have few other options for communicating with patients before enrollment (which is how ‘‘start of VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 coverage’’ is captured in the regulation text for Medicaid and CHIP). We emphasize that payers must begin the process of collecting the previous/ concurrent payer information and opt in no later than 1 week after the start of coverage but understand that it may not be completed within that timeframe. We believe it is important to gather this information from patients as soon as possible when a patient enrolls with a new payer in order to facilitate the timely exchange of patient data. Patients may take additional time to respond or follow-up may be required. Impacted payers are encouraged to make a reasonable effort to engage with patients to gather their permission and identify any previous/concurrent payer(s). We rely on payers to develop reasonable processes to follow up with patients, and recommend payers follow-up one time before determining that the patient is choosing not to opt in. Though not required, we encourage payers to build into their request process a method for patients to indicate that they do not want to provide the requested information, so that payers need not follow up with them. We note that the patient education requirements, discussed in section II.C.3.g. of this final rule, will provide patients annual reminders of the payer to payer exchange functionality. Under this final rule, patients must be able to opt in or withdraw permission at any time. The opt in and identifying previous/ concurrent payers processes could include using existing portals to gather this information from patients, as we are not being prescriptive on how each payer implements this process. We also encourage stakeholders to participate in HL7 FHIR workgroups to collaborate with other industry stakeholders on identifying best practices and identifying possible processes. ii. Gathering Previous and Concurrent Payer Information We proposed that impacted payers would be required to gather information about patients’ previous/concurrent payer(s) that would allow them to identify and request data from those payers. That could include the payer’s name and a patient ID number or similar identifier. Under our proposal, an impacted payer would be required to allow a patient to report multiple previous/concurrent payers if they had (or continue to have) concurrent coverage. In this circumstance, we proposed that impacted payers would be required to request the patient’s data from all previous/concurrent payers. Comment: Multiple commenters expressed concern with the lack of a PO 00000 Frm 00078 Fmt 4701 Sfmt 4700 standardized process to identify a patient’s previous/concurrent payer(s) and recommended that CMS either establish a policy to identify the payers, provide technical assistance on how to crosswalk unique identifiers, or standardize elements of the process. A commenter highlighted that the lack of clarity on how payers are to identify a patient’s previous/concurrent payer makes the Payer-to-Payer API difficult to operationalize and would likely introduce errors. Multiple commenters recommended additional changes to the enrollment process to support data exchange via the Payer-to-Payer API. A few commenters recommended that CMS work with stakeholders to develop a specific process to collect this information. A commenter urged CMS to reinforce to payers that they should make the processes as easy as possible for patients by leveraging touchpoints that the patient would already be engaged in to enroll and initiate new coverage. Response: Because the requirements for a Payer-to-Payer API and the need to collect information about previous or concurrent coverage for patients crosses many payer programs with variation between enrollment processes, we determined that being prescriptive on a specific process would cause more implementation burden than necessary. In response to comments, we are finalizing a modification to our proposal to require payers to request previous and concurrent payer information no later than 1 week after the start of coverage. As discussed previously, payers might not have contact with patients before enrollment. Therefore, this modification will allow additional time for payers and broaden the range of options for payers to align with their current processes. Initial implementation may be challenging; however, it is important that patients’ data are shared as they transition care to a new payer, because the benefits for patients outweigh the upfront implementation burden. Leaving the process open for payers to implement in the least burdensome, most practical way to gather the information from patients makes the most sense. Gathering previous payer information and an opportunity for the patient to opt in ideally should take place through an already established point of contact with the patient. Leveraging established points of contact will reduce patient burden and help impacted payers meet the deadline of no later than 1 week after the start of coverage. In particular, payers often have existing processes to identify concurrent payers to facilitate E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations coordination of coverage and Medicare Secondary Payer/Third Party Liability administration. For instance, per 42 CFR 422.108, MA organizations are required to identify payers that are primary to Medicare and coordinate its benefits to Medicare enrollees with those primary payers. State Medicaid programs are required to collect sufficient information to enable the state to pursue claims against such third parties when making an eligibility determination or redetermination per section 1902(a)(25) of the Act (for beneficiaries enrolled in managed care, states generally make this the responsibility of the MCO with state oversight). That requirement also applies to state CHIP programs by cross reference at section 2107(e)(1)(B) of the Act. Nothing in this rule would prevent payers from using that information for both that purpose and to identify concurrent payers for Payer-to-Payer API data exchange. However, patients would still need to opt in for payers to proceed with requesting patient data via the Payer-to-Payer API. Comment: A few commenters requested clarification on whether the definition of ‘‘previous payer’’ is limited to the immediately previous payer or to previous payers within a specific time period, such as within the last 5 years. Response: The minimum requirement is only to request information from the immediately previous payer, however if a patient does report multiple previous payers, impacted payers are required to request that patient’s data from any previous/concurrent payers (identified to or known by the impacted payer) within the required 5-year period. We are finalizing that policy because patients may have been enrolled with payers that are not subject to the requirements of this rule. Therefore, allowing patients to have their impacted payers request data from payers other than their immediately previous payer within the 5-year timeframe could maintain as much of their record as possible. Comment: A commenter suggested that CMS include a process for new payers to inquire whether the previous payer supported the Payer-to-Payer API described in this regulation, such as a monitored email address, and that some type of consequence for non-compliance should be levied. Response: In section I.D. of this final rule we discuss an NDH that could serve as a centralized place for payers to find other payers’ digital endpoints and identify payers that support the Payerto-Payer API. Without an NDH or similar source of information, payers would likely be required to contact the previous payer directly to determine if VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 they support the Payer-to-Payer API. We are also exploring other solutions, such as using TEFCA, that could be leveraged to determine if the previous payer supports the Payer-to-Payer API. We have addressed program enforcement and compliance mechanisms in section I.D.2. of this final rule, as well, and appreciate public interest in mechanisms for provider and patient appeals and complaints, oversight, and assurance of compliance. Comment: A commenter noted that a payer’s ability to request data from a previous payer would be dependent on the patient providing accurate information about the previous payer. The commenter expressed concern regarding the accuracy of this information and the effort required for necessary follow-up. Response: As discussed previously, we acknowledge that the obligation to exchange data is contingent on patients supplying the necessary information about previous/concurrent payers. An impacted payer cannot comply with these requirements if the patient has not provided timely or accurate information about their previous/concurrent payer. We emphasize that payers must request this information no later than 1 week after the start of coverage, but that it may take longer than that to obtain information from the patient. If the patient does not respond or additional information is necessary, the impacted payer must make reasonable efforts to obtain their response to the opt in request and to identify any previous/ concurrent payer(s). Comment: Several commenters suggested data elements that would be necessary or extraneous to make that Payer-to-Payer API request. Multiple commenters encouraged including the patient’s name, patient’s previous/ concurrent payer name, member ID, date of birth, physical address, and phone number in a payer’s data request to a previous payer. Multiple commenters urged payers not to require patients to provide the specific plan name, which may be long and unintuitive and because patients may have switched plans over time with that payer. A commenter expressed security concerns with exchanging Social Security numbers (SSNs) and suggested that their use be as limited as possible. Another commenter suggested that patients should be encouraged to provide the dates coverage started and ended or information about up to three recent services covered by the previous plan and those dates of service. Response: We agree with commenters that demographic information such as patient’s name, member ID, date of PO 00000 Frm 00079 Fmt 4701 Sfmt 4700 8835 birth, physical address and phone number are appropriate pieces of information to identify patients. We also agree that SSNs should be used to identify patients only when necessary (and permissible by law) due to that identifier’s sensitivity. While start and end dates of coverage may be useful in some instances, patients are unlikely to know or remember those exact dates, nor are they likely easy to find. Therefore, we discourage their use for identifying patients. Asking a patient to provide information about recent services covered by the previous payer could be burdensome to a patient. Patients are unlikely to have that information without gathering it from their previous payer. Therefore, there are less burdensome ways to effectuate this process, such as by using the data elements mentioned previously. Payers should implement these requirements in such a way that accomplishes the goal of identifying patients’ previous/ concurrent payer(s) with the least burden on patients. The data elements that a payer may need to identify a patient and match that patient to their record are included in the required and recommended standards for the Payer-to-Payer API. Specifically, the required US Core IG and the recommended PDex IG have ‘‘Must Support’’ fields (meaning that the system must be able to support those data elements) that could be used for identifying a patient, such as patient name, addresses, birth sex, gender, birth date, member and subscriber identifiers, and group number. Requesting payers should use those fields to identify the patient whose data they are requesting. If the information provided is insufficient to make a match, or it matches with more than one member, an error should be returned. Payers will need to use a combination of data elements to support patient matching, as they do today with any data exchange. We also will continue to work with ONC and share information on their patient matching research/initiatives here: https://www.healthit.gov/topic/ interoperability/standards-andtechnology/patient-identity-and-patientrecord-matching. We encourage payers to leverage the appropriate patient matching data elements of the IGs and we will continue to work on ONC on their patient matching research and initiatives.82 82 Office of the National Coordinator for Health Information Technology (2022, September 8). Patient Identity and Patient Record Matching. Retrieved from https://www.healthit.gov/topic/ interoperability/standards-and-technology/patientidentity-and-patient-record-matching. E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8836 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations Comment: A commenter suggested the need for a national Health Plan ID (HPID) to identify a patient’s previous/ concurrent payers. The commenter requested that CMS re-work and re-issue required standards for a national HPID. A commenter also stated that the process would benefit from establishing technical standards to ensure that all payers are using the same data elements to verify a patient’s payer(s). Response: We acknowledge industry’s interest in a national standard for a payer identifier. We are aware that there are a few alternative standards used in transactions today, which are located on member ID cards and maintained in payer systems. For example, the Payer ID, used in Electronic Data Interchange (EDI) transactions, is a unique ID assigned to insurance companies to enable them to communicate with each other to verify eligibility, coverage, benefits and submit claims. CMS also maintains a Plan ID for all QHPs on the FFEs, which are 14 alphanumeric characters. Until and unless a national standard is adopted, industry may wish to collaborate with the SDOs on an appropriate payer identifier for the APIs. Comment: Several commenters raised the concern that for QHPs, the X12 834 transaction standard for health plan enrollment and disenrollment from the FFEs does not currently carry previous payer information, complete information on concurrent payers, member IDs, or opt in needed to support the payer to payer data exchange during QHP enrollment. A commenter also raised concerns about situations where a patient begins the QHP enrollment process but does make the binder payment, and therefore ultimately does not effectuate their coverage. Response: Requiring payers to gather this information could result in a more streamlined approach than incorporating it into the X12 834 transaction standard enrollment process, given that FFEs are not otherwise required to use or retain the information. However, as discussed previously, we are finalizing a modification to our proposal to account for the timing of QHP coverage effectuation relative to plan selection, which impacts when a QHP can reasonably obtain information from an enrollee. Specifically, QHP issuers on the FFEs will be required to provide enrollees or their personal representatives with an opportunity to opt into the QHP issuer’s Payer-to-Payer API data exchange no later than 1 week after the coverage start date or the effectuation of coverage, whichever is later. This timeframe accounts for the VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 date on which an issuer has confirmation that an individual will be enrolled in QHP coverage with the issuer, by receiving the binder payment that is required to effectuate coverage per 45 CFR 155.400(e), as well as instances in which coverage takes effect retroactively. iii. Currently Enrolled Patients We proposed that no later than the compliance dates for the Payer-to-Payer API, impacted payers must establish and maintain a process to gather permission and identify previous/ concurrent payer(s) from all patients who are currently enrolled. Some payers may want to have a soft launch, rolling implementation, or pilot for their Payer-to-Payer API before the compliance dates. We therefore tied our proposal to require impacted payers to gather permission from currently enrolled patients to the proposed 2026 compliance dates, rather than when a payer implements its API. We stated that this would allow payers to sequentially target specific plans, populations, or enrollee categories for operational rollout, as long as all currently enrolled patients are given the opportunity to opt into the payer to payer data exchange by the compliance dates. We received no comments on this proposal. In alignment with the modified compliance dates discussed throughout this final rule, the requirements to request currently enrolled patients’ opt in permission and previous/concurrent payer information will be tied to the 2027 compliance dates we are finalizing for the Payer-toPayer API. iv. Opt In We proposed an opt in approach for the data exchange through the Payer-toPayer API. We stated that an opt in framework means that the patient or their personal representative would need to affirmatively permit a payer to share data, and without that permission, the payer could not engage in the proposed payer to payer data exchange for that patient. We noted that this permission (or lack thereof) would apply only to the data exchange we proposed and would not satisfy any other obligations required under the HIPAA Privacy Rule or other law. Additionally, we stated that we believed patients themselves are the best source for sufficient and accurate information necessary for the payer to make the request. Should a patient choose to provide this information, it would require an affirmative act from the patient, so we stated that the burden of PO 00000 Frm 00080 Fmt 4701 Sfmt 4700 asking a patient to opt in would not create a significant additional barrier to patient participation. We also proposed to require impacted payers to have a process for patients to opt into this data exchange at any time after the start of coverage, or if they have already opted in, to withdraw that permission at any time. As discussed in section II.C.4.c. of this final rule, this opt in requirement does not apply to data exchanges between a state Medicaid or CHIP program and its contracted managed care plans or entities. We also proposed that states, through their Medicaid and CHIP programs, would be responsible for collecting a patient’s choice to opt into the payer to payer data exchange, rather than their contracted managed care plans. We explained that a Medicaid or CHIP beneficiary may switch between FFS and managed care delivery systems within the same state’s Medicaid or CHIP program, but despite these shifts, an eligible beneficiary remains a beneficiary of the state program. States may also change the managed care plans that they contract with. Thus, we proposed that the patient permission for this data exchange, as a Medicaid or CHIP beneficiary, would be obtained by the state and would apply regardless of the delivery system in which the beneficiary is enrolled. In contrast, our policy for the Provider Access API will allow payers to exchange patient data with providers unless a patient has opted out. We proposed an opt out policy for the Provider Access API, in part, based on the existence of a treatment relationship between the patient and provider, a contractual relationship between the payer and the provider, and a coverage relationship between the payer and patient. Specifically, our policy to only require the Provider Access API data exchange with providers in the payer’s network and require a process to attribute a patient to that provider before data can be exchanged creates a level of assurance for the payer that it is sending patient data to an appropriate party. Two payers exchanging information may not have a direct relationship, but would be exchanging data based on a patient’s separate relationship with each payer. Therefore, in the proposed rule, we stated that it would make sense for the patient to have a larger gatekeeping role for the Payer-to-Payer API. Comment: Many commenters expressed support for the proposed policy to require patients to opt into the Payer-to-Payer API. Commenters provided various rationales for their E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations support. Multiple commenters stated that the opt in approach would give patients greater access to and control over their information. Other commenters appreciated that the opt in approach protects patient privacy. Some commenters noted that the opt in approach would be easy for a payer to implement when a patient is a new beneficiary or enrollee because the payer’s relationship with the patient is new and active and the payer can request a patient’s opt in at the same time as the payer requests the patient’s previous/concurrent payer information. A commenter noted that the Payer-toPayer API is particularly well suited for an opt in approach because it is usually a one-time or time limited exchange (unless concurrent payers are involved). Response: We appreciate commenters feedback in support of an opt in policy and are finalizing this policy as proposed. Comment: Some commenters voiced concerns about an opt in approach. Multiple commenters expressed concern that an opt in approach will result in lower rates of patient participation in the payer to payer data exchange. Multiple commenters recommended that CMS adopt an opt out approach for the Payer-to-Payer API instead of an opt in approach. Primarily, commenters agreed that an opt out framework would lead to more patient participation and more data available for the new payer, any new network providers, and patients themselves. A commenter was concerned that patients may be confused by the opt in process and recommended providing clear directions to patients detailing how and when patients can opt into data sharing. Response: We agree that an opt in approach often results in fewer data exchanges than an opt out policy. However, increased data exchange is not necessarily the goal of our policy unto itself, but a process to facilitate improved care. We believe that patients, as they are the owners of their data, should have control over who has access to their data, especially when the two parties exchanging patient data do not have a direct relationship with each other, as in the case with payer to payer exchange versus the Provider Access API where the payer and provider have a network contract. However, we know that the more data available, the more informed decisions about care can be. Patients should see value in having their data exchanged between their previous/ current payer(s) and their new payer. As discussed in section II.C.3.g. of this final rule, impacted payers will be required to provide plain language information to patients informing them of the benefits VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 of payer to payer data exchange and directions for opting in. Comment: A commenter recommended that CMS better explain the length of time that an opt in election is valid. Response: The patient’s opt in election is valid indefinitely with that payer unless the patient decides to withdraw their permission at a later time. Comment: Multiple commenters requested clarification on the implications of a patient choosing not to opt into the data exchange via the Payerto-Payer API. Specifically, a commenter agreed that the information proposed for the Payer-to-Payer API can be shared only if the patient opts in, however, requested clarification on how payers could meet obligations to exchange these patients’ data for other purposes. Response: Patients have a choice about whether they want their data shared under this policy as they transition between payers. If a patient chooses not to opt into the data sharing, data will not be exchanged between payers under the requirements in this final rule. However, payers may exchange information without a patient’s authorization for other purposes, such as benefit coordination in the case of concurrent payers, or for other permissible reasons under the HIPAA Privacy Rule. There is nothing in this rule that would prohibit payers from using the Payer-to-Payer API as the mechanism for data exchange permissible under other authority, even if the patient has not opted into the payer to payer data exchange policy in this final rule. Comment: Multiple commenters submitted responses relating the Payerto-Payer API data exchange to the HIPAA Privacy Rule exception for TPO disclosures, which do not require patient authorization. Some commenters stated that the information CMS proposed to require be made available falls under the scope of that exception and therefore opt in should not be required. Other commenters believe that some of the data (such as prior authorization information) would fall under that exception, but other data (such as claims information) would not. A few commenters suggested that CMS should reduce the scope of the data exchange to allow disclosure under the TPO exception. Furthermore, commenters stated that it may confuse and upset patients who have opted out of sharing their data via the Payer-toPayer API, but whose PHI may otherwise be disclosed under the HIPAA Privacy Rule. PO 00000 Frm 00081 Fmt 4701 Sfmt 4700 8837 Response: We emphasize that our final requirements are not intended to change any existing obligations under the HIPAA Privacy, Security, and Breach Notification regulations, the regulations under 42 CFR part 2, or state privacy or other laws, but can and should be implemented in accordance with those rules. To make a blanket determination that the Payer-to-Payer API exchange that we are requiring always constitutes a TPO disclosure would go beyond the scope of this rule and could overstate and conflict with existing HIPAA Privacy Rule requirements and guidance. Making such a determination could have unintended effects on covered entities’ ability to disclose PHI. Instead, for the reasons explained previously, it is appropriate to require patients to opt in for payer to payer data exchange. Our payer to payer data exchange requirements are disclosures permitted under the HIPAA Privacy Rule as ‘‘uses or disclosures that are required by law,’’ as defined at 45 CFR 164.103, rather than as a permitted TPO disclosure. ‘‘Required by law’’ disclosures are limited to the relevant requirements of such law, not to the HIPAA minimum necessary standard, thereby ensuring that all content required by our Payerto-Payer API policy may be disclosed. In addition, the data exchange must not be prohibited by other law, such as restrictions on patient records related to substance use disorder at 42 CFR part 2 or state privacy laws. We emphasize that the opt in process described here applies only to the payer to payer data exchange in this final rule. That is, it applies only to the requirement for impacted payers to share individual claims and encounter data (excluding provider remittances and cost-sharing data), all data classes and data elements included in a content standard at 45 CFR 170.213 and certain information about prior authorizations maintained by the payer with a date of service within 5 years of the request by a patient’s new or concurrent payer. Similar to the discussion in section II.B.3.b.ii. regarding Provider Access API, a patient’s choice not to opt into the payer to payer data exchange does not prohibit the payer from using the Payer-to-Payer API to exchange patient data under another permissible authority. For instance, there may be other permissible bases for payers to share data, without a patient’s authorization, such as under the HIPAA Privacy Rule’s permitted uses and disclosures to carry out treatment, payment, or health care operations. Patients do not have the ability to opt E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8838 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations out of a payer using the API itself as a mechanism for sharing data under such bases for disclosure. We urge payers to inform their patients of this possibility in the educational resources discussed in section II.C.3.g. However, we also note that the HIPAA Privacy Rule, at 45 CFR 164.520, has specific notice requirements for covered entities to send to individuals. Payers should make clear the differences between the payer to payer data exchange, which requires patients to opt in, and other permissible disclosures, which may not require authorization. We also note that the data that may be shared under other permissible bases, such as the TPO exception, may overlap with the data required to be shared by our Payer-to-Payer API policy. For instance, a payer may be permitted to disclose PHI to another covered entity to coordinate benefits or determine costsharing amounts for the covered entity’s payment purposes under 45 CFR 164.506(c)(3). If that disclosure is permissible, a patient declining to opt into the payer to payer exchange policy in this final rule would not prohibit a payer from using the Payer-to-Payer API to make that disclosure. In fact, we encourage payers to leverage the Payerto-Payer API as a standardized mode of transmitting this information. Payers may leverage a variety of solutions for exchanging coverage data today and moving to a standard-based API across the industry could benefit payers by reducing the types of connections they must maintain to communicate with other payers. Per 45 CFR 164.506(b), covered entities may create a process to obtain consent from an individual to use or disclose PHI to carry out treatment, payment, or health care operations. Per 45 CFR 164.522(a), individuals also have the right to request restrictions on how a covered entity will use and disclose PHI about them for TPO. Except in limited circumstances, a covered entity is not required to agree to an individual’s request for a restriction. Where covered entities agree to a restriction, it is bound to the restriction to which it agrees unless the restriction is subsequently terminated. We emphasize that the opt in process described in this final rule is specific to the Payer-to-Payer API policy and is therefore not, on its own, a consent mechanism per 45 CFR 164.506(b) or an agreed-upon restriction per 45 CFR 164.522(a). These nuances are necessary for patients to understand that their personal health information may still be shared in some instances, even if they do not opt into the payer to payer data VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 exchange. Where the requirements of this rule change how covered entities or their business associates may use or disclose PHI, covered entities should consider their obligations under the HIPAA Privacy Rule. Comment: A commenter recommended that CMS assist states with implementing opt in processes. Another commenter explained that the feasibility of an opt in approach depends on how it would be implemented. A different commenter recommended that CMS to work with stakeholders to develop a standard approach for how an opt in requirement will work when the patient is not the primary insurance holder, noting that a standard approach is necessary to reduce confusion and ensure that patient information is protected. Response: We agree that the feasibility of an opt in approach depends on how it is implemented, which is why we are leaving the actual implementation process up to the payers. We expect that payers will implement the most viable processes for themselves. Each of our policies in this final rule is targeted toward individual patients, not any family members that may be covered through the same benefits. We note that in some cases, applicable law may allow one individual (such as a parent or guardian) to act as a personal representative for another individual covered under the same benefits (such as a minor) and could therefore opt into the payer to payer data exchange for that individual. Regardless, the opt in is patient-specific and a payer must make the data request based on the individual’s permission and the previous/concurrent payer should respond in kind with the individual patient’s record. No data should be shared about any patient that has not opted in (or whose personal representative has not opted in), regardless of whether another patient covered under the same benefits has opted in. Comment: Multiple commenters weighed in on whether patients’ opt in should be collected electronically and specifically recommended that payers collect the opt in via a patient portal or mobile device. A commenter explained that payers do not have the means to collect patients’ opt in via multiple methods. A different commenter noted that payers should collect opt in data electronically. Another commenter stated that patients should not be required to use a patient portal or mobile device app to opt into data sharing. A commenter also requested guidance on how to collect permission from patients who require assistance PO 00000 Frm 00082 Fmt 4701 Sfmt 4700 enrolling or registering for the patient portal. Another commenter noted the importance of equitable access to patient data and highlighted the current usage of patient portals as a method to authenticate patients’ identities and obtain their opt in permission. They recommended a centralized identity service for patient authentication, verification, or consent for patients who cannot, or prefer not to, access the patient portals. A commenter recommended that CMS provide a centralized security verification through CMS. The commenter noted that a centralized security certification validation would relieve burden on payers to manage connectivity with other payers and provide assurances around self-signed certificates. Response: We are finalizing that all impacted payers must develop and maintain processes to identify a patient’s previous/concurrent payer(s) and to allow patients or their personal representatives to opt into the payer to payer data exchange (both with previous and concurrent payers) no later than 1 week after the start of coverage. As finalized in this rule, each new payer will be responsible for gathering permission through an opt in process before requesting data from any previous or concurrent payer. If payers believe that a patient portal or mobile smart device with appropriate security protections is the best way to gather opt in, it is permissible to use those methods. We are not being prescriptive about the process or procedures used by impacted payers for the required opt in process. However, we strongly recommend that there be a way for patients to record their permission telephonically or otherwise if they do not have internet access or do not want to sign up for an electronic portal. We agree that equitable access to patient data is of the utmost importance and emphasize that the Payer-to-Payer API requirements are intended to allow for other solutions besides patient portals for authentication, verification, or consent. For those patients who require assistance, a personal representative would be allowed to assist. However, we do note that 45 CFR part 92 requires impacted payers (as health programs or activities under that section) to provide meaningful access to individuals with limited English proficiency and accessibility requirements for individuals with disabilities. The requirements of that part apply to impacted payers, as described at 45 CFR 92.3. We also are working closely with ONC on how the Individual Access Services exchange under TEFCA could E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations support patient access to their data on the network, which could include via payer APIs. We appreciate the suggestion of a centralized security process and will consider our authority in this area. Comment: Multiple commenters generally supported the proposed requirement for payers to implement procedures to allow patients to withdraw permission for the payer to payer data exchange after initially opting in. Several commenters requested clarification from CMS on what action payers must take in such instances. Specifically, multiple commenters recommended that CMS explain whether payers are expected to delete data that have already been received through the Payer-to-Payer API if a patient withdraws their opt in permission after the data exchange has occurred. Another commenter recommended that CMS explain whether patients with concurrent payers will be able to withdraw their opt in permission to stop the quarterly concurrent payer data exchange. Response: Our opt in policy is only prospective. If a patient opts in, their impacted payers would be required to exchange data via the Payer-to-Payer API, if all other requirements are met. If that patient subsequently withdraws permission, payers will not need to take any additional steps with regard to patient data that have already been received from another payer. Specifically, there is no requirement in our regulations to delete those data from their records. We acknowledge that it may not be possible in all cases to clearly delineate which entity created each part of the patient record and trying to do so would put a burden on payers without benefit to patients. Payers are permitted to identify the previous or concurrent payer as the source of data, but are not required to do so. If a patient withdraws their permission for the payer to payer data exchange after first opting in, the payer will not be permitted to request that patient’s data from another payer, including a concurrent payer, unless the patient subsequently opts in again. As discussed previously, payers may exchange information for other purposes not related to the policies described herein, such as for benefit coordination in the case of concurrent payers or other permissible purposes under the HIPAA Privacy Rule, and may still use the Payer-to-Payer API as the mechanism to exchange data for those purposes, even if a patient has not opted in. Comment: Multiple commenters made recommendations related to CMS monitoring and oversight of the opt in VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 approach. A commenter suggested that CMS conduct oversight to ensure that payers implement the opt in process and provide appropriate messaging to patients. A commenter recommended that CMS require payers to submit data on the number of patients who opted into the data exchange and how they were educated to do so. The commenter stated that this would help CMS understand if the API is meeting its intended goals. Another commenter recommended that CMS consider including Payer-to-Payer API claims in the Healthcare Effectiveness Data and Information Set (HEDIS) measure. Another commenter recommended that CMS monitor the percentage of patients that do not opt into these data exchanges via the Payer-to-Payer API and assess whether those patients are concentrated in certain populations and whether there are equity issues that CMS should address in the future. Response: We did not propose to require impacted payers to report any metrics regarding the number of patients who opt into data sharing, but we appreciate the recommendation and will consider it for future rulemaking. We note that the specifications of HEDIS measures are out of scope for this rule. We received comments on many of our proposals about the need for specific compliance and enforcement efforts pertaining to each API and we address these comments in section I.D. of this final rule. Oversight and compliance procedures and processes vary among these CMS programs and may have different implications based on a payer’s status in the program, previous compliance actions, and corrective action plans. Comment: Multiple commenters supported our proposal to require state Medicaid and CHIP programs to collect patients’ permission for payer to payer data exchange in lieu of their contracted managed care plans and managed care entities. Commenters stated that Medicaid and CHIP agencies are in the best position to collect information from all beneficiaries during eligibility and enrollment. However, commenters warned that if sister agencies within the state perform eligibility and enrollment processes, there would be additional coordination required to collect patients’ permission. Response: We agree with commenters that state Medicaid and CHIP agencies are the logical entity to hold Medicaid and CHIP beneficiaries’ permission for payer to payer data exchange. We note that MCOs, PIHPs, and PAHPs are still responsible for collecting previous/ concurrent payer information and requesting the data exchange. However, PO 00000 Frm 00083 Fmt 4701 Sfmt 4700 8839 nothing in this rule would prevent a Medicaid or CHIP agency from collecting that information and passing it along to their MCOs. We also acknowledge the specific difficulties that states may face to implement the requirements of this rule and refer readers to section II.E. of this final rule for discussion about available extensions and Federal funding for IT expenditures related to these requirements. d. Requesting Data Exchange From a Patient’s Previous/Concurrent Payer(s) and Responding to Such a Request i. Timeframe for Requesting Data We proposed to require impacted payers to request a patient’s data from their previous/concurrent payer(s) no later than 1 week after the start of coverage, as defined previously. We stated that 1 week should be sufficient time for payers to complete their process for identifying patients’ previous/concurrent coverage and to request data from the other payer(s). We proposed that if, after the start of coverage, a patient opts into the data exchange or provides previous/ concurrent payer information or requests a payer to payer data exchange for another reason, then the current payer would be required to request data from the previous/concurrent payer(s) no later than 1 week after the payer received the previous/concurrent payer information and the patient has opted in, or the patient makes the request. We acknowledge that the obligation to request data is contingent on the patient supplying the necessary information about a previous/concurrent payer to enable the new payer to conduct the required exchange. An impacted payer cannot comply with these requirements if the patient has not provided timely or accurate information about their previous/concurrent payer. In that case, payers are required to make reasonable efforts to gather this information from patients. For example, we recommend payers follow-up one time before determining that the patient has not opted in. We are finalizing a modification to the proposed regulatory text to clearly establish that the 1-week timeframe for requesting patient data begins when the impacted payer has sufficient identifying information about previous/concurrent payers and the patient has opted in. Comment: Many commenters supported our proposal to require impacted payers to request data from a patient’s previous payer no later than 1 week after the start of coverage or obtaining previous/concurrent payer E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8840 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations information and opt in permission from the patient. Other commenters suggested a variety of alternative timeframes for payers to request patient data from previous/concurrent payers. A few commenters recommended that CMS allow 2 weeks after the start of coverage to request the data. Other commenters recommended that CMS extend the timeframe for a data exchange to be within 30 or 90 days after enrollment to allow payers time to confirm the patient’s information, especially during peak volumes such as open enrollment. A commenter highlighted that a 90-day timeframe would allow time for the previous payer to process outstanding claims. Conversely, other commenters recommended a 3-day timeframe for a new payer to request the patient’s data from their previous payer to expediate the data exchange. Response: We continue to believe that 1 week is the appropriate period to require payers to make a request for patient data after they have sufficient identifying information about the previous/concurrent payer and the patient has opted in. The longer the period between the time a patient enrolls with a new payer and that payer receives patient data, the less relevant those data could be. This is particularly true for patients who have chronic conditions or ongoing treatment for lifethreatening conditions. For these patients, it is more important that their new payer get information as soon as possible. If necessary, additional information can be exchanged as it becomes available. See our discussion in section II.C.3.d.i. of this final rule regarding optional additional data exchanges between previous and new payers. For instance, the CY 2024 MA and Part D final rule requires MA coordinated care plans to provide a minimum 90-day transition period when an enrollee switches to a new MA plan. During that time, the new MA organization may not require prior authorization for an active course of treatment. Establishing a 90-day timeline for payer to payer exchange could largely negate the utility of the data to comply with that requirement. Even a shorter period, such as 2 weeks or 30 days, could require patients to provide separate information about active courses of treatment, which would add burden to patients rather than reducing it. Regardless of whether impacted payers are subject to that rule, it is important to exchange data quickly so that patients can maintain a continuity of care. However, we also determined that our proposed data request deadline was no VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 longer feasible with the modified deadline for requesting previous/ concurrent payer information and the patient’s opt in to be no later than 1 week after the start of coverage. Therefore, we are also finalizing a modification to our proposal to require impacted payers to request data from a patient’s previous/concurrent payer(s) no later than 1 week after the payer has sufficient identifying information and the patient has opted in, or within 1 week of a patient’s request. We encourage payers to request these data as expeditiously as possible. Specifically in regard to periods of peak volume for payers, we encourage payers to use the Bulk Data Access IG to send bulk requests and responses for multiple patients at once. As discussed in section II.G. of this final rule, we are finalizing our proposal to require payers to implement the Bulk Data Access IG for the Payer-to-Payer API for this very purpose. Comment: Multiple commenters suggested that CMS explain the meaning of within 1 week of the start of coverage. A commenter highlighted how Medicaid policy requires that they grant eligibility retroactively up to 3 months and recommended that the data request within 1 week of the start of coverage be based on the date that the eligibility update is received into their MMIS, not the effective date of coverage, which could be 3 months prior. Another commenter recommended that only QHP policies that have been effectuated with a binder payment be subject to the payer to payer data transfer requirement, which should leave 1 week after the date that benefits begin for the new payer to request the data transfer. Response: As noted previously, we are changing the deadlines for payers to request information from other payers by tying them more closely to the date when the payer has sufficient information about a patient’s previous and concurrent payers and the patient has opted in. As such, the data request deadline is no longer linked to the start of coverage or enrollment. Further, as explained previously, the term ‘‘start of coverage,’’ as used in the preamble to this rule, means when coverage begins or when the patient enrolls, as applicable. For cases when there may be retroactive coverage, such as in Medicaid, the payer will be required to seek a patient’s opt in for Payer-to-Payer API data exchange and to request information about a new patient’s previous/concurrent payer(s) no later than 1 week after the patient’s enrollment. In Medicaid, the patient’s ‘‘enrollment’’ is the date the beneficiary is enrolled in the state’s MMIS (or PO 00000 Frm 00084 Fmt 4701 Sfmt 4700 equivalent process), not the date that coverage takes retroactive effect. For that reason, the regulation text in Medicaid FFS reflects this by referring to ‘‘enrollment’’ instead of ‘‘start of coverage.’’ Comment: Multiple commenters requested clarification that timing requirements are flexible to the extent reasonable and necessary to verify that privacy and security requirements are met. A commenter emphasized that this timeframe could only be followed if it begins after the member has provided sufficient information as determined by the impacted payer to identify a concurrent payer (for example, payer name, member enrollment number, group number). Response: We agree that the timeframe for sending a request only begins when a payer has sufficient information to send a request to another payer and the patient whose data are being requested has opted in. We are finalizing that the request must be made no later than 1 week after the payer has sufficient identifying information and the patient has opted in. We note that, as discussed previously, payers have an obligation to request that information from their patients no later than 1 week after the start of coverage, as that term is defined previously specific to each impacted payer type. Comment: A commenter suggested that if payer endpoints are not publicly available or accurate information on a previous payer is not available, payers should only be required to make reasonable efforts to complete the data exchange. Response: Existing requirements require payers to make technical documentation about their API, including digital endpoint information, on a publicly accessible section of their website.83 In section I.D. of this rule we discuss an NDH that could serve as a centralized place for impacted payers to find other payers’ digital endpoints. Commenters indicated that such a directory would significantly improve the process for requesting patient data. Payers are required to request patient information from previous and concurrent payers if the conditions in the rule are met, and we encourage payers to make a reasonable effort to locate information about a patient’s 83 See 42 CFR 422.119(d) for MA organizations, 42 CFR 431.60(d) for Medicaid FFS, 42 CFR 438.242(b)(5) for Medicaid managed care, 42 CFR 457.730(d) for CHIP FFS, 42 CFR 457.1233(d) for CHIP managed care, and 45 CFR 156.221(d) for QHP issuers on the FFEs. These requirements are cross referenced in the regulations requiring impacted payers to apply the same technical specifications to all the APIs required under this final rule. E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations previous payer. If a payer is unable to obtain a valid endpoint or accurate information for a previous or concurrent payer, we recommend they document the efforts they took to gather the information from the other payer. Doing so could establish a record for future oversight, or in case of a dispute, that the payer made a reasonable effort to comply with the requirements of this rule and the patient’s desire for their data to be exchanged. As discussed, payers are not responsible for determining whether the patient’s previous payer is an impacted payer, but are required to request previous/ concurrent payer information from the patient and to make the data request to the other payer. We encourage payers that are not subject to the requirements in this rule to participate in the Payerto-Payer API exchange in order to allow their patients to benefit from this policy. However, a payer not subject to this regulation may not have a FHIR API or want to exchange the required information, which would be outside of the impacted payer’s control. Comment: Multiple commenters flagged that impacted payers will need time to establish the necessary technology linkages, data use agreements, and security protocols to exchange information with another payer in a manner compliant with the HIPAA standard transaction and code set requirements. A commenter noted that the data exchange would take longer than 1 week if a payer needs to set up a new connection, as feeds may differ. Response: We understand that a functional technological connection with other payers to meet the requirements for the Payer-to-Payer API policy can and sometimes will take more than a week to complete. However, there is no applicable HIPAA standard transaction or code set for the payer to payer data exchange we are finalizing in this final rule. The required standards are those being established in this final rule. Giving impacted payers sufficient time to coordinate with other payers to establish the capability to exchange data is one rationale for delaying the compliance dates from the proposed 2026 to 2027. We expect that payers will use that additional time not only to build the requisite API technology, but to coordinate with other payers to establish those linkages. We encourage payers to establish connections and perform testing with other payers before the compliance dates for the Payer-to-Payer API to ensure that the data exchange will work as expected. Payers should also set up a testing or sandbox instance of their VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 Payer-to-Payer API as early as possible for other payers to test against. We also encourage payers to establish data use agreements and register with each other’s APIs prior to the compliance dates in order to facilitate exchange as quickly as possible after the compliance dates. We expect that those technological and legal requirements will be most burdensome when one payer connects with another for the first time. Subsequent exchanges should rely on that same foundation, and it should not be necessary to repeat those steps. Finally, we suggest payers prioritize other payers that they are most likely to exchange with, such as those that overlap with their geographical coverage area. ii. Additional Data Exchange In the proposed rule, we solicited comments on whether additional data exchanges would be warranted to account for data received or processed by the previous payer after the patient’s coverage ends and, if so, what the appropriate parameters would be. Outside the context of concurrent payers, we generally expect our policy to require a one-time data exchange between a previous and new payer. Once the new payer has received the patient’s data from the previous payer, we do not generally expect there to be additional exchanges with the previous payer. However, we want to allow patients to request subsequent data exchanges to account for any outlier situations. We are also aware that claims take time to process and may be processed after patients have enrolled with a new payer, thus creating additional data within the patient’s record for some time period after the patient has changed payers. We considered proposing a policy where, if the patient opts in, a previous payers would be required to send any additional data within the required dataset to the new payer no later than 1 week of receiving the additional data. However, keeping in mind the burden this could impose on payers, we sought comment on such a policy. We sought comment on whether additional data could be helpful for the new payer in the weeks or months after enrollment, and which specific data could be most pertinent, or whether additional data exchange would be overly burdensome and not provide value to the new payer. We asked whether it would be appropriate to limit such a requirement to send updated data to a certain period after the initial data exchange, for instance within 30 or 90 days. Additionally, we asked whether impacted payers should be required to PO 00000 Frm 00085 Fmt 4701 Sfmt 4700 8841 make an additional data exchange within a week of receiving any new data or on a set cadence, such as monthly or quarterly, to allow payers to streamline transactions for multiple patients. Comment: We received varying comments around additional data exchanges with multiple commenters supporting a one-time additional data exchange to promote continuity of care. Some commenters thought it would not be feasible to share additional data within 1 week of each update but supported a single exchange at 30-, 60or 90-days after the patient has moved to a new payer. A commenter stated it would be difficult to track when additional data need to be sent after the initial exchange. Response: We agree that it could be helpful for payers to supplement the data exchange required under this rule, to account for any claims or data that are received after the initial data are sent to the new payer. While we are not requiring it, we encourage payers to do so in order to pass along a complete patient record. Likewise, we encourage the new payer to send an additional request for data within 90 days of receiving the initial data response. The previous impacted payer would be required to respond to such a request. iii. Authorization and Authentication Protocols We proposed that impacted payers would be required to use the OpenID Connect Core authorization and authentication protocols at 45 CFR 170.215(e)(1) to authenticate the identity of the requesting payer. We wanted to ensure payers would not have to send data unless they are confident that the requesting payer is identified. The ONC Cures Act final rule adopted content and vocabulary standards to provide the foundation needed and were finalized for use in the CMS Interoperability and Prior Authorization final rule to support implementation of the policies (85 FR 25521–25522). Thus, we proposed OpenID Connect Core in effort to align standards across API implementations. Comment: Multiple commenters sought clarification on the general authentication and authorization process and flagged that requiring OpenID Connect Core will not be sufficient for the Payer-to-Payer API. A commenter recommended that CMS consider UDAP or the PDex IG, which uses a SMART framework instead. Another commenter flagged that the OpenID Connect Core standard requires a log-in, whereas the proposal suggested that payers are required to provide these APIs without a user login or credential. E:\FR\FM\08FER2.SGM 08FER2 8842 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations lotter on DSK11XQN23PROD with RULES2 A commenter highlighted that the Bulk Data Access IG requirement relies on portal credentials and user logins created by the individuals to be linked to their identity in the payer system. Response: Upon consideration, we agree that it would not be appropriate to require OpenID Connect Core for the Payer-to-Payer API. OpenID Connect Core is a means to identify individuals and because the Payer-to-Payer API is a business-to-business interaction, OpenID Connect Core is not adequate to meet this use case. Although OpenID Connect Core can be utilized for the Payer-to-Payer API, it is not a scalable approach because it requires user credentials. For similar reasons, we are finalizing a modification to our proposal to not require OpenID Connect Core for the Provider Access, Payer-to-Payer and Prior Authorization APIs.84 The SMART App Launch IG can also provide a method for authentication within the Payer-to-Payer API; though we note that we are not finalizing our proposal to require that IG, it remains available to payers as an option. However, as part of the Payer-to-Payer API, payers still need to authenticate bi-directionally using industry best practices to ensure that patient data are only shared appropriately. We refer readers to Table H3 in section II.G. for an updated listed of required and recommended standards and IGs. We also advise that the Bulk Data Access IG, which is a required IG for the Payer-to-Payer API, contains a ‘‘SHOULD’’ (that is, strongly recommended) conformance statement to use SMART Backend Services. We also note that SMART Release 2.0.0, which has since been adopted in the HTI–1 final rule at 45 CFR 170.215(c)(2) includes SMART backend services. Though in this final rule we are requiring impacted payers to support the Bulk Data Access IG in their Provider Access and Payer-to-Payer APIs, this requirement does not obligate them to use it for every data exchange if it is not necessary. Comment: A commenter recommended that CMS collaborate with industry stakeholders to identify best practices for user authentication and authorization with the Payer-toPayer API. Another commenter highlighted that guidance on how to trust and verify inbound data requests 84 In the proposed rule, that requirement was included for MA organizations at 42 CFR 422.121(b)(1)(i), for Medicaid FFS at 42 CFR 431.61(b)(1)(i), for CHIP FFS at 42 CFR 457.731(b)(1)(i), for Medicaid managed care plans through cross reference at 42 CFR 438.242(b)(7), for CHIP managed care entities through cross reference at 42 CFR 457.1233(d), and for QHP issuers on the FFEs at 45 CFR 156.222(b)(1)(i). VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 via the Payer-to-Payer API will be essential. Response: We will continue to collaborate with industry stakeholders through HL7 FHIR workgroups and through HL7 FHIR Connectathons as the standards to support the Payer-to-Payer API continue to be refined to support these final policies. We also will continue to work closely with ONC on the required authentication and authorization standards under 45 CFR 170.215. While we are not specifically requiring an IG or method be used for authentication and authorization, as part of the Payer-to-Payer API payers still need to authenticate the other payer they are exchanging data with. iv. Attestation We proposed to require the requesting impacted payer to include an attestation with the request for data affirming that the patient (1) is enrolled with the requesting payer and (2) has opted into the data exchange in a manner that meets the applicable legal requirements. As explained in section II.G. of this final rule, we recommended certain HL7 FHIR IGs to support the data exchange between payers. The recommended PDex IG has been developed to include both the technical and business processes of capturing and sharing a patient’s permission for data exchange with the payer to payer data request. Because that IG is recommended and not required, impacted payers could also exchange an attestation regarding patient permission with other implementations, which could meet or exceed the requirements of the PDex IG. Comment: Multiple commenters supported the attestation proposals for the Payer-to-Payer API. Multiple commenters provided recommendations for processes to share patients’ data sharing permission. Multiple commenters suggested processes for payers to verify that a patient opted into data sharing with another payer before giving that payer access to patient data. A commenter requested clarification on whether patients must opt in for each subsequent payer. A commenter recommended that patients’ data sharing permission be shared with secondary and tertiary payers. Commenters requested clarification on which payer (the requestor or requestee) is responsible for obtaining patients’ permission. A commenter highlighted that an attestation process will not resolve the risks of incorrectly matching data to the patient. Another commenter asked whether FHIR can be used to send the attestation. Another commenter requested clarification on using standards and IGs to facilitate the opt in PO 00000 Frm 00086 Fmt 4701 Sfmt 4700 process. A commenter sought guidance on where a patient’s opt in would be indicated on the electronic transmission and how they could verify that the payer provided educational information to the patient. Response: We appreciate the recommendations for sharing a patient’s opt in but leave that exact process up to payers. The impacted payer requesting the data from the previous/concurrent payer is responsible for obtaining the patient’s opt in and must include an attestation with that request for data affirming that the patient (1) is enrolled with the requesting payer and (2) has opted into the data exchange in a manner that meets the necessary legal requirements. Patients would have to opt in for each subsequent payer to request their data from a previous/ concurrent payer. The purpose of the attestation is not to match the data to the patient, but to affirm that the patient has enrolled with the requesting payer and has opted into the data exchange in a manner that meets the necessary legal requirements. We highly recommend using the IGs discussed in further detail in section II.G. of this final rule to support the Payer-to-Payer API. The latest published version of the PDex IG (STU 2.0.0) includes a means for a payer to communicate that the member has opted in—through a FHIR Consent resource—when requesting data from another payer. An attestation or verification that the requesting payer provided educational information to the patient is not required to be sent with the request. Comment: A commenter recommended that CMS more clearly explain the Payer-to-Payer API process to ensure that prospective or potential payers are not requesting a patient’s data. Another commenter suggested that an attestation from another payer is not sufficient proof to demonstrate a patient’s decision to opt in and suggested that some assignment of legal liability be considered for the requesting payer, as it might assuage these concerns. Response: A prospective or potential payer should not request a patient’s data under this rule. Under this rule, a payer must attest that the patient is enrolled with that payer as part of its request for the patient’s data from a previous/ concurrent payer. We emphasize that the impacted payers must implement an authentication process (discussed previously) that verifies the requesting payer’s identity as a legitimate health care coverage entity. If an entity includes a fraudulent attestation that the patient is enrolled with the payer and has opted in to payer to payer data E:\FR\FM\08FER2.SGM 08FER2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations lotter on DSK11XQN23PROD with RULES2 exchange in its request for patient data, that entity could be subject to criminal or civil penalties. v. Timeframe for Responding to a Request We proposed that impacted payers that are previous/concurrent payers would be required to respond to a current payer’s request, if specified conditions are met, within 1 business day of receiving the request. We explained that 1 business day would be the appropriate timeframe to complete this process to send the data, as new payers need timely access to previous/ concurrent payer data to facilitate care coordination and make the information available to providers within their new network. We noted that this timeframe also would align with the 1 business day response time for the Patient Access and Provider Access APIs. We sought comment on whether the proposed timeframes for the previous/ concurrent payer to send these data, are appropriate or whether other timeframes would better balance the benefits and burdens. We sought comment on whether payers need more than 1 business day to respond to a request and sought comments on what might be a more appropriate timeframe if commenters thought a different timeframe was warranted. We explained that it is important for patient data to move to the new payer as soon as possible to send their patient record and to ensure care continuity. Comment: Multiple commenters expressed support for the 1 business day response time for the Payer-to-Payer API. A commenter recommended a modification that data should be available within 1 calendar day. Another commenter stated that the purpose of standardized API data exchange is to have real-time data availability. A commenter requested that CMS provide at least 24 hours for data from the Prior Authorization API to be available via the Payer-to-Payer API. Some commenters expressed general concern with our proposed response timeframe and suggested that payers may become overwhelmed, especially during open enrollment periods. A commenter expressed concern that the proposed timeframe does not consider the degree of manual effort required to ensure compliance with applicable state laws and regulations regarding health privacy and confidentiality. Multiple commenters recommended that CMS require a response time of 2 business days for the Payer-to-Payer API and another suggested 3 business days. Response: After reviewing the comments, we believe that keeping the VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 response timeframe at 1 business day is appropriate. This expedient data exchange will support care continuity and still allow time for the processes for payers to appropriately send patient data. We note that this timeframe also aligns with the finalized 1 business day response time for the Patient Access and Provider Access APIs. We acknowledge that some periods may have increased data exchange requests, such as during open enrollment period, and note that the purpose of the required Bulk Data Access IG is to efficiently exchange large volumes of data for multiple individuals and can be utilized for both requesting and sending data. The data content we are finalizing that must be included in the payer to payer data exchange is generally the same as the current requirements for the Patient Access API, notwithstanding the addition of prior authorization information. Claims and encounter data and all data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI) are structured data, which will help payers identify particular items that are subject to additional privacy requirements. We are also finalizing 2027 compliance dates, in part, to give payers additional time to develop internal processes and train staff. That includes processes make the necessary determinations as to which data are permitted to be shared via the Payer-to-Payer API. For instance, payers may use this time to develop processes that flag certain data elements with metadata—as the payer receives them— if they require special permissions or are prohibited to disclose under other law. We highly encourage payers to engage in this process as they receive data to ease any manual review and decision-making that might be necessary when a payer requests patient data. Comment: A commenter recommended that CMS address the need for a legal governance framework for the payer to payer data exchange because the technical standards proposed would not enable the requesting payer to substantiate the patient’s authorization. The commenter stated the need to provide legal assurances that the payer requesting a patient’s records has obtained appropriate authorization to request the records and without a standardized governance framework, payers would struggle to fulfill the requirement to respond within 1 business day of receiving a request. Response: We understand the importance of legal assurance between payers to ensure the patient has provided appropriate authorization before sharing data across payers. The PO 00000 Frm 00087 Fmt 4701 Sfmt 4700 8843 recommended PDex IG STU 2.0.0, which has since been published since the publication of the CMS Interoperability and Prior Authorization proposed rule, includes both the technical and business processes to capture and share a patient’s permission as part of the payer to payer data request. We believe 1 business day is sufficient to fulfill the request for data exchange because the IG is a means for payers to electronically send a record of the patient’s permission to receive data from the other payer. We are also working closely with ONC as to how TEFCA could support scalable governance for payer to payer data exchange. We reiterate that we are requiring that the new payer provide an attestation with the request for data affirming that the patient has enrolled with that requesting payer and has opted into the data exchange. vi. Payers Not Subject to This Regulation If a previous/concurrent payer is not an impacted payer, they are not subject to our final requirements and, therefore, are not required to send or request data through the Payer-to-Payer API. For example, an employer-based commercial plan would not be subject to this rulemaking. If the previous/ concurrent payer is not an impacted payer, they are not subject to our requirements to respond to the request. A new or concurrent impacted payer is not obligated to determine whether the previous/concurrent payer is an impacted payer under this final rule or to limit its requests for a patient’s data (or its responses to requests for a patient’s data) to only impacted payers. Therefore, we proposed that an impacted new payer would be required to request the data from the patient’s previous/concurrent payer, regardless of whether the other payer is an impacted payer. Conversely, we proposed that if an impacted payer receives a request for patient data that meets the requirements of this rule, they would be required to respond by making available the required data through their Payer-toPayer API, regardless of whether the requesting payer is an impacted payer (which the payer may or may not know). If a payer not subject to this regulation does not have the capability or refuses to exchange the required data with an impacted payer or is willing to exchange the data but is unable or unwilling to do so through a FHIR API, the impacted payer will not be required to exchange data with that payer. Payers that have not implemented the Payer-to-Payer API would not have accessible digital endpoints to make the required request. E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8844 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations We emphasized in the proposed rule that impacted payers would not need to spend resources determining whether other payers are subject to this rulemaking, but would be required to request patient data, if possible, and respond to all requests that are made within the requirements. However, we encourage all payers to implement a Payer-to-Payer API to support data exchange with other payers, even if they are not subject to our final requirements to support care coordination and more efficient operations. Comment: Multiple commenters flagged concerns regarding interoperability with payers not subject to this regulation. A commenter stated that it is unclear what value would be derived from the investment if there is no response or reciprocation from payers not subject to this regulation. Another commenter noted that payers need to build a connectivity system with other payers, including payers not subject to this regulation. Response: We disagree that the burden of connecting with a payer not subject to this regulation that has implemented a Payer-to-Payer API in conformance with our requirements is any different than connecting with an impacted payer. Regardless of whether they are covered by an impacted payer, there is value in maintaining a patient’s data and exchanging those data when a patient transitions to a new payer or between concurrent payers. Furthermore, requiring impacted payers to exchange data only with other impacted payers would require impacted payers to expend effort to determine whether the other payer is an impacted payer. That effort can be eliminated by simply treating any payer as a possible exchange partner. Furthermore, not requiring impacted payers to exchange data with payers not subject to this regulation would mean that there would be no incentive for those payers to adopt the requirements of payer to payer data exchange. In addition, impacted payers are not required to exchange data outside of the process finalized in this final rule, including using a standards-based API. If a payer not subject to this regulation requests data in a format that is not compatible with the Payer-to-Payer API and specific data formatting, content and vocabulary standards established in regulation, impacted payers will not be required to send data via a different method, unless other law requires them to do so. We understand that impacted payers may have additional difficulty ascertaining that another payer is not subject to this regulation (or not VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 compliant), as that payer would not have digital endpoints to discover. Payers are required to take reasonable steps to determine whether they can exchange data with the other payer. We encourage payers to contact the previous payer directly to determine whether they support the Payer-to-Payer API. Other solutions could also be explored to help payers determine whether the previous payer supports the Payer-to-Payer API, such as using TEFCA. In section I.D. of this final rule we discuss an NDH that could serve as a centralized place for payers to find other payers’ digital endpoints and identify payers that support the Payerto-Payer API. Once a payer knows that another payer is not capable of payer to payer data exchange, they would not be required to inquire every time they receive a new patient who identifies that previous payer. However, it would be prudent to occasionally (such as annually) check whether the other payer has implemented a Payer-to-Payer API and is now capable of data exchange. e. Ongoing Data Exchange Requirements for Concurrent Coverage i. Concurrent Coverage Data Exchange For individuals who have concurrent coverage with multiple payers, we proposed to require impacted payers to collect identifying information about any concurrent payer(s) from patients before the start of coverage with the impacted payer (consistent with how ‘‘start of coverage’’ is explained previously). Because we believed it would be beneficial for all of a patient’s current payers to maintain a complete record of the care that the patient has received, we proposed to require impacted payers to request the same patient data described in section II.C.3.b. of this final rule from all of a patient’s concurrent payers, and to send those data in response to a request that meets all the requirements of this final rule. We stated that this would ensure that the patient’s concurrent impacted payers maintain a complete patient record and can provide all the information proposed to be required under the Patient Access and Provider Access APIs. Specifically, we proposed to require impacted payers, no later than 1 week after the start of a patient’s coverage,85 to request data from any concurrent payers that the patient reports. Because all payers will update patient records while a patient is enrolled with those payers, we proposed that when a patient has concurrent coverage with two or 85 For QHP issuers on the FFEs, no later than 1 week after the effectuation of enrollment. PO 00000 Frm 00088 Fmt 4701 Sfmt 4700 more payers, the impacted payers would be required to exchange with every other concurrent payer, at least quarterly. We proposed that should an impacted payer receive a request for a current patient’s data from a concurrent payer for that patient, the receiving payer would have to respond with the appropriate data within 1 business day of receiving the request. Operationally, this proposed exchange would function the same as the data exchange with a patient’s previous payer. We also proposed that any impacted payer that receives patient data from another payer under these regulations must incorporate those data into the recipient payer’s records about the patient. The required data content we proposed are the same claims and encounter data (excluding provider remittances and cost-sharing information), all data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI), and certain information about prior authorizations that the payer maintains with a date of service on or after January 1, 2016. We stated that that proposal would require impacted payers to both request patients’ data from other concurrent payers and to respond to requests from other payers to share patients’ data. Comment: A commenter recommended that we only require concurrent payers making quarterly data transmissions to send data that have been updated since the last data exchange. The commenter stated that this would reduce burden by allowing them to exchange a smaller set of data that can more easily be integrated into their patient records. Response: We agree that this is a reasonable solution to reduce burden. We are finalizing a modification to our proposal to allow concurrent payers to agree to exclude from ongoing quarterly data exchange any data that were previously transferred to or originally received from the other concurrent payer. We leave it to payers to determine the best process to effectuate this option, as it is intended to reduce payer burden. If exchanging only new data would increase burden on payers versus exchanging all patient data, they are not required to do so. Ultimately, the exchange should result in both concurrent payers having a complete set of patient data to support patient care and care coordination. Comment: A commenter suggested that CMS require payers to clearly document, in the payer systems, which payer is primary, and which is secondary to ensure providers receive accurate and timely coordination of benefit information. E:\FR\FM\08FER2.SGM 08FER2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations lotter on DSK11XQN23PROD with RULES2 Response: Coordination of benefits is an established process (though the exact process may vary by payer and jurisdiction) that we specifically did not propose to affect. As discussed previously, if payers find it beneficial to use the Payer-to-Payer API for purposes other than the data exchange finalized in this rule, such as coordinating coverage, they are welcome to do so. To the extent that such coordination information would benefit patients or providers by being available via the Patient Access and Provider Access APIs, we encourage payers to do so. Comment: Several commenters expressed opinions on the appropriate timeframe for payers to request data from another concurrent payer and for payers to respond to such a request. Multiple commenters stated their general support for timely information exchange between concurrent payers to help minimize unnecessary administrative paperwork and other inefficiencies. Several commenters supported our proposed timeframes. Other commenters suggested that payers have up to 30 days to request patient information. A commenter stated that the data should be available within 1 calendar day instead of 1 business day. A commenter recommended CMS allow at least 3–5 business days for a response. Response: There should be no procedural or technical difference between requesting data from a previous payer or a concurrent payer, other than the requirement that concurrent payers engage in ongoing quarterly exchange. Similarly, responding to such a request should be the same process, using the same FHIR standards. Therefore, we believe it is prudent to establish the same timeframes for the initial requests to and all responses from concurrent payers as for previous payers. Therefore, we are finalizing that for concurrent payers, the initial request for data must be made no later than 1 week after the payer has sufficient identifying information about concurrent payers and the patient has opted in and quarterly thereafter. We are finalizing our proposal that impacted payers must respond within 1 business day to a request for patient data from a concurrent payer that meets all the requirements of this final rule. ii. Concurrent Payer Exchange Timeframe We also considered whether to propose more frequent exchanges (weekly or monthly), or less frequent exchanges (semi-annually or annually) for the required data exchanges between concurrent payers; however, we VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 explained in the proposed rule that we believed a quarterly data exchange would strike the right balance between providing accurate, timely data and payer burden. We believed that sharing data quarterly would be frequent enough to allow new health data to accumulate and still be timely, but not so frequent that it causes unnecessary burden on the payers. We requested comment on this proposal, including on the appropriate frequency for this payer to payer exchange for patients with concurrent coverage. Comment: A significant majority of commenters supported our proposal to require quarterly data exchange between concurrent payers because it would facilitate care coordination. Some commenters suggested that a more frequent data exchange could benefit patients. Some commenters noted that even quarterly data exchange may miss key clinical events that would be useful for care coordination and recommended that the data exchange should take place monthly. On the other hand, a few commenters stated that impacted payers should only request additional data from concurrent payers when initiated by a member. Response: We agree with the majority of commenters that a quarterly cadence appropriately balances the benefits and burdens on payers. Payers may make arrangements with each other to exchange information more frequently, if they believe it would benefit their mutual patients. The burden of initiating the exchange should not fall on the patient, especially at times when they are dealing with specific health issues that would most benefit from care coordination. As some commenters recommended more frequent data exchange, we will consider whether to propose amendments to this policy in future rulemaking after the industry has experience meeting the requirements of this final rule. We note that when a patient has concurrent coverage, the payers must communicate regularly to ensure that the proper payer is responsible for that patient’s claims. Nothing in this final rule, including a patient not opting into the Payer-to-Payer API data exchange, is intended to alter payers’ ability to exchange data as they do today for that purpose, in accordance with applicable law. f. Data Incorporation and Maintenance i. Data Incorporation We proposed that data received by an impacted payer through this data exchange must be incorporated into the patient’s record with the new payer. We PO 00000 Frm 00089 Fmt 4701 Sfmt 4700 8845 stated that those data could then be part of the patient’s record maintained by the new payer and should be included as appropriate in the data available through the Patient Access, Provider Access, and Payer-to-Payer APIs. In this way, a patient’s data could follow them between payers and be available to them and their providers. We stated that this proposal would not obligate payers to review, utilize, update, validate, or correct data received from another payer, but we encouraged impacted payers to do so, at least to the extent it might benefit the patient’s ongoing care. We explained that payers could choose to indicate which data were received from a previous payer so a payer, provider, or the patient looking at the record, would know where to direct questions (such as how to address contradictory or inaccurate information), but would not be required to do. Regardless, all data received, maintained, used, or shared via the proposed Payer-to-Payer API would be required to be received, maintained, used, or shared in a way that is consistent with all applicable laws and regulations. Comment: Multiple commenters supported our proposal to require payers to incorporate data they receive from other payers via the Payer-to-Payer API into their own patient records in order to ensure that a patient’s record is not lost. Other commenters stated that they do not believe that payers are the appropriate holders of a patient’s full medical record and that providers or patients themselves should be the maintainers of those data. Response: We agree that in some cases a payer is not the best entity to hold a patient’s longitudinal record and that there is other technology available for patients to download their data, for example, using the Patient Access API, and to store it independently of their payer. As discussed previously, we are finalizing a policy that limits the payer to payer data exchange to data with a date of service within 5 years of the request. After considering public comments, we determined that a 5-year period balances the benefits of new payers having access to recent patient data and the patient not losing recent information against the burden of integrating and maintaining historical data that may or may not be useful to care. For patients who want to maintain their own information in a PHR, they have that option through the Patient Access API. While in some cases, a patient may have a provider that can and will aggregate their records from each other provider that the patient E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8846 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations sees, we do not believe this is a common scenario, as it would require a significant amount of work by the provider. As discussed, because payers receive claims or encounter data from each provider that sees a patient, they typically possess the most complete historical patient record. Requiring a payer to send a patient’s data to their new payer will ensure that recent information that could be important for care continuity is not lost. Comment: A commenter cautioned that CMS should not assume that the information received from a previous payer is whole and/or correct. The commenter noted that the difference in health plans’ level of diligence could cause some discrepancies in patient coverage. Another commenter suggested that payers would be incentivized to send incorrect information to another payer rather than correcting the patient’s record. Response: We acknowledge that any set of patient data may have errors or omissions. However, we do not believe that the appropriate response to this issue is to discard data when a patient moves between payers. As stated, we do not wish to burden payers to proactively verify patient records when they receive them from another payer. However, under the HIPAA Privacy Rule, at 45 CFR 164.526, individuals generally have the right to have a covered entity amend PHI or a record about the individual in a designated record set for as long as the PHI is maintained in the designated record set, with certain exceptions. That right exists regardless of whether the covered entity created the PHI itself or received it from elsewhere. That requirement is consistent with our policy, as it does not require proactive verification, but must be addressed upon request by an individual. We also do not believe that there is any risk of payers intentionally proliferating inaccurate information. There is no reason for a payer to maintain inaccurate records with the ultimate goal of passing that information to another payer when the patient leaves their coverage. Finally, payers are only responsible for maintaining their own records, including that which has been received from another payer. If there is an error to be corrected in data received from a previous payer, neither the patient nor their payer will need to contact the previous payer to correct it and have the patient’s record resent. A patient’s current payer is required, by the HIPAA right to amend and correct data in its records, even if that incorrect information was initially received from a previous payer. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 Comment: A few commenters recommended that all the APIs should support optional provenance resources that could be added by either the sender or the receiver to indicate the source of data. A commenter recommended that instead of CMS recommending payers to note where the data originated, CMS instead propose that specific provenance resources be required to indicate which data came from a previous payer, which could also be included in subsequent data exchanges. Response: When incorporating the data from an old or concurrent payer, payers are free to indicate the provenance of that information, which would then be included in the data available through the Patient Access or Provider Access APIs. As discussed in section II.G., we are recommending, but not requiring, the PDex IG for the Payerto-Payer API. The PDex IG requires provenance information be included in outbound FHIR transactions and that a payer receiving such a transaction must incorporate any included provenance information. There is also a ‘‘SHOULD’’ recommendation within the IG that payers create provenance records when the provenance is not included in a data set (for example, when it was received through non-FHIR mechanisms). We highly recommend that payers use the IG for several reasons, including that it would help address this issue and help payers, providers, and patients understand the source of data. We will consider whether to propose to require provenance information through future rulemaking. Comment: Multiple commenters highlighted that our Payer-to-Payer API policy would require extensive data translation and de-duplication. They suggested that CMS encourage payers to work with HIEs to determine the best solutions to avoid data duplications and associated errors. A commenter expressed concern regarding the potential for duplicate data to be transmitted throughout the health care system. Response: We appreciate commenters’ suggestions that there are existing marketplace solutions to address some of the concerns about data duplication. We understand the concern over duplicative information. There are IT solutions, such as EHR vendors and HIEs, available that can make the data actionable and help payers avoid receiving duplicative information via the Payer-to-Payer API. To the extent it would benefit payers, we encourage them to work with HIEs and HINs to facilitate payer to payer data exchange. We note that nothing in our policies prohibits a payer from using an PO 00000 Frm 00090 Fmt 4701 Sfmt 4700 intermediary to aid with various functions, such as patient matching, data exchange, or data hygiene. Comment: A commenter stated that they believe data acquired via Payer-toPayer APIs should be dated with the original date of service to prevent duplication in future Patient Access or Provider Access API requests, if a patient or provider already had that information from the previous payer. Response: We agree that it is important to maintain the fidelity of data received via the Payer-to-Payer API. While creating additional metadata is recommended to be able to track where the data came from and when it was acquired, payers should not be changing the underlying data itself. For example, the ‘‘date of service’’ or ‘‘date claim processed’’ should not be updated to the date that the new payer receives the record of the claim from a previous payer. Comment: A commenter stated claims are not typically considered ‘‘patient records’’ and suggested CMS define the ‘‘patient record’’ into which information from a previous/concurrent payer must be incorporated. Response: We do not need to define ‘‘patient record’’ as we are defining the set of data that must be shared between payers, that is, claims and encounter data (excluding provider remittances and patient cost-sharing information), all data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI), and certain information about prior authorizations maintained by the payer with a date of service within 5 years of the request by a patient’s new or concurrent payer. Furthermore, we have defined maintain in the Interoperability and Patient Access final rule ‘‘to mean the payer has access to the data, control over the data, and authority to make the data available through the API’’ (85 FR 255380). Payers must incorporate patient data into the appropriate place where they maintain that type of information that they generate while covering a patient. We understand that payers will store that information in a variety of ways, depending on their own data infrastructure. Comment: A commenter requested clarification as to how payers should integrate data into a patient’s records if the data from their previous payer includes information from other individuals who were on the same coverage plan (for example, a family health plan). Response: Each of our policies in this final rule are tailored toward individual patients, not any family members that may be covered through the same E:\FR\FM\08FER2.SGM 08FER2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations lotter on DSK11XQN23PROD with RULES2 benefits. In some cases, applicable law may allow one individual (such as a parent or guardian) to act as a personal representative for another individual covered under the same benefits (such as a minor) and could therefore opt into the Payer-to-Payer API data exchange for that individual. Regardless, the opt in is patient-specific and a payer must make the data request based on the individual permission and the previous/ concurrent payer should respond in kind with the individual patient’s record. No data should be shared about any patient that has not opted in, regardless of whether another patient covered under the same benefits has opted in. Comment: A commenter cautioned that when a new payer takes on another payer’s information, this may cause a significant amount of risk for patients as they may get billed for services that are not approved under their new payer. Response: We are not requiring impacted payers to honor another payer’s prior authorization decision, nor do our final rules require reprocessing claims submitted to previous payers. If payers believe that sending these data will be confusing for patients, they should include information in their educational resources that makes clear what the data exchange is and is not used for. ii. Data Retention In the proposed rule, we noted that our proposals would not impact any payer’s data retention requirements. Specifically, we did not propose to require impacted payers to maintain data for unenrolled patients any longer or differently than they do today under current law, regulation, or policy. We understand that if a patient is uninsured or moves to a payer not subject to this regulation that does not request information from the previous payer, after a period of time, the previous payer may discard information, which would make it unavailable to the patient or other payers in the future. We acknowledged that imposing requirements that would require payers to alter their data retention policies based on the actions of other payers would be a significant burden that would outweigh the benefits of such a policy. We considered proposing a minimum period during which a payer must maintain patient records after disenrollment, such as 1 or 2 years. However, we stated that most payers have policies in place that would maintain patient data for at least that long, and thus, such a requirement would be unnecessary and duplicative. We requested comment on whether our VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 understanding is correct and whether there is a benefit to considering a data retention requirement in the future. Comment: Multiple commenters supported our decision not to propose or establish a data retention requirement for patient records that would be different or longer than that required by current laws, regulations, and policies. Other commenters recommended that CMS set a minimum data retention timeframe. A commenter suggested that a payer should have to retain data until they are requested by a subsequent payer or after a minimum period of years, whichever occurs first. Other commenters recommended data be maintained for 5 or 10 years after a patient is unenrolled. Some commenters requested further guidance regarding the time for which impacted payers should maintain the data received from previous/concurrent payers. Response: We do not believe that additional data retention requirements are necessary at this time, as we do not wish to change or create conflict with existing rules. For example, under 42 CFR 422.504(d), 438.3(u), and 457.1201(q), MA organizations, Medicaid managed care plans, and CHIP managed care entities, respectively, must retain records for at least 10 years. Similarly, most states require 5–10 years of data retention. Nothing in this final rule would extend existing data retention requirements or create an obligation for perpetual maintenance. We emphasize that once a payer receives patient data from another payer, it becomes part of the patient’s record and should be treated the same as data in the patient record created by the current payer. There should be no difference for data retention or data availability, as well as the same obligation to update or correct the data. The only difference is that payers may attach provenance information designating where the data originated. Comment: A commenter noted that a patient’s previous payer should not be required to respond to requests from the patient’s current payer more than 90 days after the patient has disenrolled from the previous payer. Response: We disagree with setting a 90-day limit on the initiation of a payer to payer data exchange by a patient’s new payer. Patients should have access to their data for a significantly longer period than that. Some patients may not learn about payer to payer exchange for more than 90 days after the start of coverage. Others may move to payers that are not subject to this rule and do not have a Payer-to-Payer API or become uninsured for a period before moving back to an impacted payer. However, we PO 00000 Frm 00091 Fmt 4701 Sfmt 4700 8847 do expect that a significant majority of the payer to payer data exchanges will be near the beginning of a patients’ new coverage, particularly if the required patient educational resources clearly present the option at or shortly after enrollment. Impacted payers are required to exchange the data they maintain on a patient, with a date of service within 5 years of the request. We note that we discuss the timeframe for data retention in this section, for which we are not changing any regulation or requirement. We may consider, in future rulemaking, establishing a time period for the data to be available via Payer-toPayer API, but such a timeframe would likely be a matter of years, not days or months. g. Patient Education Resources Consistent with our proposals for the Provider Access API, we proposed that impacted payers (excluding including Medicaid managed care plans and CHIP managed care entities) would be required to provide patients with educational resources in non-technical, simple, and easy-to-understand language, explaining at a minimum: the benefits of the Payer-to-Payer API data exchange, patients’ ability to opt in or withdraw their permission, and instructions for doing so. We proposed that state Medicaid and CHIP programs would provide this information to beneficiaries to be consistent with our proposal that states would be responsible for collecting beneficiaries’ permission for payer to payer exchange. We proposed that those impacted payers would be required to provide these educational resources to patients at or before requesting permission for the Payer-to-Payer API data exchange. As discussed previously, currently enrolled patients must be given the opportunity to opt into the payer to payer data exchange and to provide previous/ concurrent payer information before the API compliance dates. We proposed that impacted payers would be required to provide these educational resources to those currently enrolled patients at or before requesting their opt in as well. In addition, we proposed that similar resources would have to be provided annually to all covered patients in mechanisms that the payer regularly uses to communicate with patients. Impacted payers would also be required to post these resources in an easily accessible location on the payer’s public website. We requested comment on whether it would reduce payers’ burden to only be required to provide these resources annually to any patients who have not opted in and those with known concurrent payers. E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8848 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations Because we are finalizing a modification to our proposal and establishing Payer-to-Payer API compliance dates in 2027 this requirement to provide educational resources is also being moved from the proposed 2026. Comment: Multiple commenters expressed support for CMS’s proposed requirements related to resources to educate patients about the benefits of data exchange between payers, the patient’s right to opt in and to withdraw their permission, and instructions for doing so. Multiple commenters supported CMS’s proposals to require that patient educational resources be in non-technical, simple, and easy to understand language. A commenter noted health literacy is the single largest barrier to health care access for those with coverage. A commenter recommended that CMS amend the patient resources requirements to require impacted payers to write resources at the fourth to sixth grade reading level. Response: We are slightly modifying the final regulation text to require that this information be provided in ‘‘plain language’’ instead of using the longer, more cumbersome phrase ‘‘nontechnical, simple, and easy-tounderstand language.’’ This modification does not change the meaning of the requirement that the educational information be nontechnical and easy-to-use, but is intended to be more straightforward and to encourage impacted payers to follow the Federal Government’s plain language guidelines. Those guidelines were informed by the Plain Writing Act of 2010, which requires Federal agencies use clear government communication that the public can understand and use. That statute applies only to Federal Government agencies, but we believe that the plain writing guidance developed for the Federal Government will be useful for impacted payers when developing educational resources for patients. We also encourage payers to review and utilize the health literacy resources that the AHRQ makes available on their website.86 We do not believe that it is prudent to establish a specific ‘‘grade level’’ requirement. A grade level score is based on the average length of the words and sentences. Readability formulae vary and the grade level scores for the same text can differ depending on how 86 Agency for Healthcare Research and Quality (2023, May). Patient Education and Engagement. Retrieved from https://www.ahrq.gov/healthliteracy/patient-education/. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 it is used. Furthermore, edits that are done to make text score at a lower grade level can produce choppy text that lacks cohesion. However, we do note that 45 CFR part 92 requires impacted payers (such as health programs or activities under that section) to provide meaningful access to individuals with limited English proficiency and accessibility requirements for individuals with disabilities. The requirements of that part apply to impacted payers, as described at 45 CFR 92.3. Comment: Multiple commenters recommended that CMS develop resources, such as standardized language, tools, and delivery models, that payers could customize to ensure a consistent message to patients on what will be a confusing and complicated topic. A commenter noted that if CMS led the development, then the educational resources and programs for the Payer-to-Payer API could be standardized across carriers, FFS program administrators, and enrollment administrators to support consistent messaging and improve engagement with the API. Response: In an effort to assist payers in meeting these requirements, we intend to provide templates or outlines for educational resources after this final rule is published and in time for payers to review and use prior to the compliance dates. However, we do not expect those resources to be fully sufficient to meet the requirements of this rule without additional content and customization by payers to include their specific processes for patients to opt in or withdraw their permission. To the extent possible, we encourage payers to collaborate on standardized resources to ensure consistent messaging to patients, regardless of the payer with whom they are enrolled. However, we also expect each payer to have to customize their resources with their own information and opt in process. Comment: A commenter suggested that it would benefit both patients and providers for us to allow third parties, such as an HIE or HIN, to provide educational resources to patients on the payer’s behalf. The commenter stated that if multiple payers use the same third-party resources, it could simplify the solution across the industry. Response: Nothing in this rule will prevent a payer from working with a third party to develop the educational resources discussed here or from using subcontractors or downstream entities to the extent that program-specific laws permit that. As discussed in this section, payers may use an HIE or HIN to facilitate the Payer-to-Payer API PO 00000 Frm 00092 Fmt 4701 Sfmt 4700 exchange. However, we encourage payers to make it clear that any resources disseminated to patients under this requirement are from the payer. Patients are unlikely to devote attention to resources they receive from entities with which they are not familiar. While we expect that patients would recognize the name, logo, and other markings of official correspondence from their payer, they are unlikely to recognize their payer’s partners. Therefore, while a third party may develop (and send on the payer’s behalf) the required educational resources, we strongly recommend that these resources be clearly branded as communications from the patient’s payer. Comment: Multiple commenters highlighted the need to educate patients specifically on the opt in framework. Specifically, these commenters encouraged CMS to ensure that those educational resources are easy for patients to find. Some commenters recommended including that information in the patient’s enrollment resources, while others disagreed and believe that that information may be easily missed within the larger quantity of information. A commenter recommended that in addition to payers, Federal agencies should play a role in patient education regarding data sharing. Another commenter recommended that CMS engage in testing patient education and opt in notifications before the compliance dates. Response: We agree that it is particularly important for patients to understand what they are opting in to. The educational information should highlight the benefits of API-based data exchange and explain patients’ permission rights. Additionally, we emphasize that that information should be communicated in a way that is conspicuous and makes clear to patients that this policy provides them rights as consumers. However, each payer has different processes and modalities for communicating with patients and we do not want to be prescriptive in a way that may add unintended and unnecessary burden to payers. As stated previously, we are committed to providing outlines or templates for these educational resources. In developing those resources, we will prioritize using plain language for patients. In addition, we have stated that Medicare FFS intends to conform to the requirements of this rule, which includes patient educational resources. Beyond that, we will consider what role CMS may play in patient education. However, we know that E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations patients have a relationship with their payers and expect to receive various communications from their payer relating to their coverage. Therefore, patients are more likely to consider educational resources that come directly from their payer. Further, these educational resources will need to include instructions for how patients can opt into Payer-to-Payer API data exchange and withdraw their permission; such instructions will need to be tailored to the specific procedures for each payer. While additional education from Federal agencies may supplement information from payers, it is not a substitute. Comment: Multiple commenters recommended that CMS limit the dissemination of annual Payer-to-Payer API educational resources to only those patients who have not opted in and those with known concurrent payers. A commenter recommended that making patient educational resources available on a payer’s website should be sufficient and CMS should not require payers to send that information on an annual basis. Response: While we understand that there may be additional burden to send all patients educational resources annually, we believe that such a requirement is necessary. As discussed previously, in section II.C.3.c.iv. of this final rule, patients must have the opportunity to withdraw their permission for payer to payer exchange at any time. While we generally expect exchange between a previous and new payer to be a one-time transaction, we do allow for the possibility of additional data exchanges, as discussed in section II.C.3.d.ii. of this final rule. Therefore, the opportunity to withdraw permission needs to be offered to all patients at any time. In order to be aware of this right, patients need to be informed of it. Payers are already required to send information to patients annually and including information about payer to payer data exchange should not be a significant burden to include with those resources. We do not believe that it would serve patients to have resources and information about the Payer-toPayer API data exchanges and the patients’ rights to opt into and out of those data exchanges available only on a payer’s website. That would require patients to affirmatively seek out that information on their own, or to stumble across it by chance. Comment: Multiple commenters encouraged CMS to use community outreach and education campaigns to encourage patients to opt into sharing their data via the Payer-to-Payer API. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 Response: We will look into opportunities to educate patients on opting into data sharing. As mentioned previously, we are committed to providing outlines or templates for these educational resources. In developing those resources, we will prioritize patient comprehension. Beyond that, we will consider what role CMS may play in patient education. 4. Payer to Payer Data Exchange in Medicaid and CHIP a. Inclusion of Medicaid and CHIP Feefor-Service As discussed in the CMS Interoperability and Prior Authorization proposed rule (87 FR 76267), we did not require state Medicaid and CHIP FFS programs to comply with the payer to payer data exchange policies in the CMS Interoperability and Patient Access final rule (85 FR 25568). We proposed to make the payer to payer data exchange policies in this rule applicable to state Medicaid and CHIP FFS programs. We stated that requiring state Medicaid and CHIP FFS programs to implement the Payer-to-Payer API data exchange in this rule would not be as burdensome as the non-API-based payer to payer data exchange that was finalized in the CMS Interoperability and Patient Access final rule (85 FR 25524), which we are now rescinding. That is because this new API would be leveraging the same data and technical standards as the Patient Access API. State programs should have already implemented Patient Access APIs and should thus be able to leverage the work done for that API to make implementing this new API more manageable. Additionally, in the proposed rule we discussed the various benefits that the Payer-to-Payer API could produce for state Medicaid and CHIP programs, including creating efficiencies, reducing burden, and improving health outcomes (87 FR 76276). Comment: Commenters supported applying the proposed requirements to Medicaid and CHIP FFS and agreed that such a policy would benefit Medicaid and CHIP beneficiaries who are covered by FFS by improving care coordination and continuity of care. Other commenters stated that the Payer-toPayer API would reduce burden on patients and providers and allow state Medicaid agencies to operate more efficiently. Response: We appreciate the support for including state Medicaid and CHIP FFS as impacted payers and are finalizing that proposal. Comment: A commenter questioned the expected value of the Payer-to-Payer PO 00000 Frm 00093 Fmt 4701 Sfmt 4700 8849 API to state Medicaid agencies and the return on investment for the time and effort to implement systems. Response: Data exchange from one payer to another as patients transition between payers is a powerful way to support care coordination and continuity of care during coverage transitions, particularly in the Medicaid program where patients often churn in and out of the program and between payers. Electronic data exchange between payers would support payer operations and a patient’s coverage transition to a new payer efficiently and accurately. b. Medicaid and CHIP—Seeking Permission Using an Opt In Approach in the Payer-to-Payer API We proposed that state Medicaid and CHIP agencies, like other impacted payers, establish a process to allow beneficiaries to opt into the payer to payer data exchange. We stated that an opt in framework means that the beneficiary or their personal representative would need to affirmatively permit state Medicaid and CHIP agencies to share their data, and without first obtaining that permission, the agency could not engage in the payer to payer data exchange for that beneficiary. In contrast, we proposed an opt out policy for the Provider Access API, in part, based on the existence of a treatment relationship between the beneficiary and provider. Specifically, our policy to only require the Provider Access API data exchange with enrolled Medicaid and CHIP providers and require a process to attribute a patient to that provider before data can be exchanged creates a level of assurance for the Medicaid or CHIP agency that it is sending patient data to an appropriate party. Two payers exchanging information may not have a direct relationship but would be exchanging data based on a patient’s separate relationship with each payer. Therefore, in the proposed rule, we stated that it would make sense for the patient to have a larger gatekeeping role and be required to provide affirmative permission for the Payer-to-Payer API data exchange. We proposed that state Medicaid and CHIP agencies, rather than their managed care plans or managed care entities, would be responsible for obtaining the required permission. We also proposed that the requirement to identify patients’ previous/concurrent payers would apply to state Medicaid and CHIP agencies rather than managed care plans or managed care entities. For clarity and consistency with existing Medicaid and CHIP rules, we also E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8850 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations proposed that a patient’s permission would not be necessary to exchange data between a state Medicaid or CHIP agency and its contracted managed care plans or entities. We explained in the proposed rule that the opportunity for newly enrolling patients to opt in could take place through a single streamlined application, or at some later point of contact with the beneficiary prior to enrollment, but in no instance would our proposals permit a delay in the enrollment process or a beneficiary’s coverage. We sought comments, specifically from states and contracted managed care plans and entities, how we could establish standards for patient data exchange for state Medicaid and CHIP agencies and their contracted managed care plans and entities without creating additional barriers or burden. We requested comment on the workflow and data exchanges that occur when a Medicaid or CHIP beneficiary is enrolled into a managed care plan or entity and the feasibility of sending patient permission during the enrollment process. We considered proposing that the Payer-to-Payer API requirements would not apply for beneficiaries moving between or with concurrent coverage with a state Medicaid or CHIP agency and its contracted Medicaid or CHIP (as applicable) managed care plan or entity for the reasons outlined previously. However, we are concerned that many states today do not exchange data between their Medicaid or CHIP FFS programs and managed care programs. We requested comments on whether there are other ways we can ensure patient data are exchanged in this case in a manner that would reduce burden on states. Comment: Multiple commenters recommended that CMS reexamine whether its interpretation of 42 CFR 431.306(d) and 457.1110(b) would prohibit Medicaid agencies from participating in HIEs. A commenter encouraged CMS to explain whether requirements at 42 CFR 431.306(d) and 457.1110(b) prohibits Medicaid and CHIP programs from sharing beneficiary information with HIEs for the purposes of the Payer-to-Payer API. The commenters advocated for CMS to make a change to privacy regulations to support an opt out model consistent with industry standards. Multiple commenters that agreed with the proposal specifically recommended that state Medicaid and CHIP agencies leverage current solutions by HIEs and HINs to implement the proposed opt in requirement. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 Response: We do not agree that 42 CFR 431.306(d) and 457.1110(b) prohibit Medicaid or CHIP agencies from contracting with an entity that offers the technology to allow for digital access and transfer of a patient’s medical records, often referred to as an HIE. Section 1902(a)(7) of the Social Security Act (the Act), which our regulations at 42 CFR part 431, subpart F, implement, requires that a state’s Medicaid plan provide safeguards that restrict the use or disclosure of information concerning Medicaid applicants and beneficiaries to purposes directly connected with administration of the state plan. Our regulations at 42 CFR part 431, subpart F, set forth requirements for states to safeguard Medicaid applicants’ and beneficiaries’ information in accordance with section 1902(a)(7) of the Act, including requirements for safeguarding the information, what types of information must be safeguarded, and when and how to release otherwise safeguarded information. The same requirements also apply to separate CHIPs through a cross reference at 42 CFR 457.1110(b). The disclosures of beneficiary data to an HIE contracted to implement and maintain the required Payer-to-Payer API would be directly related to the administration of the state plan because sharing beneficiary data through the Payer-to-Payer API supports the provision of services for beneficiaries, as described at 42 CFR 431.302(c). States that share information about Medicaid beneficiaries or former beneficiaries with their concurrent and new payers support opportunities for improved care coordination, reduce time needed to evaluate beneficiaries’ current care plans, their health risks, and their health conditions at the time they enroll with the Medicaid program, or another payer. Further, under section 1902(a)(4) of the Act, Medicaid agencies may contract with organizations to enhance the agency’s capability for effective administration of the program. The regulation at 42 CFR 431.306(d) generally requires states to obtain permission from an individual Medicaid applicant or beneficiary, or their personal representative, before responding to a request for information from an outside source to disclose that applicant’s or beneficiary’s data safeguarded under 42 CFR 431.305. State Medicaid and CHIP agencies may share Medicaid and CHIP beneficiary information with entities with which the agency has contracted to support the administration of its Medicaid or CHIP state plan. Such contractors would not be considered ‘‘outside sources’’ PO 00000 Frm 00094 Fmt 4701 Sfmt 4700 because they are contracted to carry out functions directly related to administration of the state Medicaid or CHIP plan. Thus, if a Medicaid or CHIP agency contracts with an HIE to carry out administrative functions of the state’s Medicaid or CHIP program, including implementing and maintaining the required Payer-to-Payer API, the HIE would not be considered an ‘‘outside source’’ and the state Medicaid or CHIP agency could share Medicaid or CHIP beneficiary information with the HIE for purposes directly connected to administration of the state plan without prior permission from the Medicaid or CHIP beneficiary required by 42 CFR 431.306(d) and 457.1110(b), respectively. Regardless, whether a Medicaid or CHIP agency contracts with an HIE to develop and maintain the required Payer-to-Payer API, the Medicaid or CHIP agency is responsible for ensuring the contracted entity implements a Payer-to-Payer API that meets all regulatory requirements, which includes that an individual or their representative has provided permission (opted in) prior to their information being shared with other payers via the Payer-to-Payer API. In addition, to receive beneficiaries’ information from the Medicaid or CHIP agency, Medicaid or CHIP providers, plans, or contractors must be subject to standards of confidentiality comparable to those of the state Medicaid and CHIP agency in accordance with 42 CFR 431.306(b) and 457.1110(b) respectively. Furthermore, Medicaid regulation at 42 CFR 434.6(a)(8) requires that each of the state Medicaid agency’s contracts must provide that the contractor safeguards information about beneficiaries as required by 42 CFR part 431, subpart F. Under these requirements, if a state Medicaid or CHIP agency contracted with an HIE or other entity, the contractor would be required to meet the same standards of confidentiality as the state Medicaid agency (as set forth in section 1902(a)(7) of the Act and our implementing regulations at 42 CFR part 431, subpart F), including but not limited to: • Providing safeguards that restrict the use or disclosure of information concerning applicants and beneficiaries to purposes directly connected with the administration of the plan in accordance with section 1902(a)(7) of the Act and 42 CFR 431.300 and 431.302; and • Not disclosing data to an outside source, such as non-Medicaid or nonCHIP payers with whom the HIE might exchange data, without prior permission from the individual in accordance with 42 CFR 431.306(d). E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations We did not propose any changes to Medicaid or CHIP confidentiality regulations at 42 CFR part 431, subpart F, and 42 CFR 457.1110(b), but we appreciate the comment and will consider it for any future rulemaking. Comment: A commenter stated that an opt in process implemented within its system would not authorize another payer (particularly payers not subject to this regulation) to release patient information to the commenter or for the commenter to release a patient’s data to a patient’s subsequent payer. Response: All data received, maintained, used, or shared via this proposed Payer-to-Payer API must be received, maintained, used, or shared in a way that is consistent with all applicable laws and regulations. As discussed previously, our regulation for Medicaid at 42 CFR 431.306 (incorporated via cross reference for CHIP at 42 CFR 457.1110(b)) sets forth certain requirements for release of Medicaid and CHIP applicant and beneficiary data. Consistent with our proposal, we are finalizing that when another payer (including a payer not subject to this final rule) is requesting a former Medicaid or CHIP beneficiary’s information from the state Medicaid or CHIP agency, an attestation from a requesting payer that the patient or their representative has opted into data exchange with the requesting payer (that is, given permission for the Medicaid or CHIP agency to share the beneficiary’s data) is sufficient to meet the requirements at 42 CFR 431.306 and 457.111(b) to allow the state Medicaid or CHIP agency to respond to the data request, though such permission must be received prior to the state Medicaid or CHIP agency sharing any beneficiary data. For more information about how the HIPAA Privacy Rule interacts with Payer-to-Payer API, see section II.C.3.c.iv. Comment: Multiple commenters agreed with the proposal for state Medicaid and CHIP agencies to collect and manage patient decisions to opt into the payer to payer data exchange when beneficiaries are enrolled in Medicaid or CHIP managed care. Multiple commenters agreed that collecting a beneficiary’s choice to opt into the payer to payer data exchanges as part of existing Medicaid and CHIP eligibility and enrollment processes would be the most effective and technically feasible approach for most states operating managed care programs in Medicaid and CHIP and would streamline the process for beneficiaries. Response: For many reasons, we agree that the state Medicaid or CHIP program is the appropriate custodian of the VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 patient’s permission record, rather than the particular managed care plan or managed care entity through which a patient receives Medicaid or CHIP covered services. A Medicaid or CHIP beneficiary may switch between FFS and managed care delivery systems within the same state’s Medicaid or CHIP program. Despite these shifts, an eligible beneficiary remains a beneficiary of the state program. States may also change the Medicaid or CHIP managed care plans or entities with which they contract. Thus, a Medicaid or CHIP beneficiary’s opt into the payer to payer data exchange, should be obtained by the state and will apply regardless of the delivery system in which the beneficiary is enrolled. Furthermore, we understand that in many states, managed care plans may not have any contact with beneficiaries prior to their enrollment in the Medicaid managed care plan or CHIP managed care entity. We believe the ideal time to allow patients to opt into the payer to payer data exchange is during their application for Medicaid or CHIP. As stated previously, obtaining a patient’s opt in permission and identifying the previous/concurrent payer(s) cannot delay an applicant’s eligibility determination or start of coverage. If a state has all the information necessary to determine an individual’s eligibility before it obtains the individual’s permission for the payer to payer data exchange, the state must determine the individual’s eligibility and enroll the individual in Medicaid or CHIP coverage, if determined eligible, while continuing to follow the Payer-to-Payer API requirements as expeditiously as possible post-enrollment. Because we expect higher rates of patients to opt in when they are presented with the option at a point when they are already providing information (such as at application or plan selection), we highly encourage states to leverage any touchpoints before patients are enrolled in Medicaid or CHIP rather than expecting patients to opt in through a separate process. We are finalizing our proposal to require the state to establish a process for obtaining opt into the payer to payer data exchange prior to the state Medicaid or CHIP agency’s Payer-toPayer API compliance dates, and prior to the enrollment of new beneficiaries after that date, and that the state Medicaid and CHIP agencies will be responsible for obtaining the required permission. To the extent that doing so is consistent with Federal Medicaid and CHIP requirements, including those at PO 00000 Frm 00095 Fmt 4701 Sfmt 4700 8851 section 1902(a)(7) of the Act and implementing regulations at 42 CFR part 431, subpart F, and applied to separate CHIPs through a cross reference at 42 CFR 457.1110(b), Medicaid and CHIP agencies are welcome to contract with HIEs or HINs, especially those operating under TEFCA, to facilitate payer to payer data exchange. Some HIEs may already have the technical framework to manage patient consent or engage in standardized data exchange via FHIR APIs in ways that Medicaid or CHIP agencies’ systems do not. Nothing in this rule would prohibit a Medicaid or CHIP agency from partnering with an HIE to meet its requirements, but Medicaid and CHIP agencies must continue to comply with all other Federal requirements applicable to the operation of Medicaid and CHIP. Comment: Multiple commenters expressed concerns about state Medicaid and CHIP agencies’ resources to collect and manage patient decisions to opt into the exchange of their data via the Payer-to-Payer API. A commenter stated that it may need to build separate functionality to support implementation of the opt in requirement if it is unable to support the requirement within the state’s existing eligibility system. A commenter noted that it will require significant work to implement an opt in process in states and territories where the Medicaid agency does not complete eligibility and enrollment processes and recommended that CMS ensure an appropriate implementation timeline in these instances. A commenter suggested that CMS work with states to implement a consistent solution to avoid inconsistencies in what data are collected and how to address the concern about resources. Another commenter specifically expressed that the process to identify a previous/ concurrent payer would be challenging for Medicaid. Response: We understand and appreciate that state Medicaid and CHIP agencies will need to create new processes to request a patient’s permission to exchange data and identifying information about their previous/concurrent payer(s), and then to share that information with their managed care plans and managed care entities. States have different eligibility and enrollment processes, and a onesize-fits all approach may not be optimal. We are not being prescriptive on this process, as we want each program to implement the requirements in the least burdensome, most efficient way for them. We also understand that making changes to applications can be a significant administrative process, and E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8852 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations for states where Medicaid or CHIP eligibility is determined by a state or regional agency other than the Medicaid or CHIP agency, there will be additional administrative steps to implementation. We are extending our compliance dates for the Payer-to-Payer API from our proposed 2026 to 2027 in order to provide adequate time for payers to implement these requirements. Further, there may be other places where a state could obtain a patient’s data exchange permission for the Payer-to-Payer API data exchange. For instance, a state could leverage an online portal or app, if beneficiaries frequently use those pathways for other purposes, such as reporting a change in circumstance or providing information for eligibility renewal. However, the option should be equally available for all beneficiaries and if only a small portion of the Medicaid or CHIP population uses these tools to communicate with the Medicaid or CHIP agency, that subset would be self-selected for greater technology literacy and taking this approach could exacerbate inequality. We note that the single streamlined application, which for Medicaid and CHIP purposes is described at 42 CFR 435.907(b)(1) and 457.330, respectively, and is also used for applications through the FFEs, includes questions about concurrent coverage information. We also expect that some states that do not use the single streamlined application already ask for this information for Coordination of Benefits and Third-Party Liability purposes. We believe that it would generally make sense to gather permission for payer to payer data exchange at the point the state collects concurrent payer information. We note that the patient permission provisions in this rule will apply only to the payer to payer data exchange discussed here and would not affect states’ ability to perform Coordination of Benefits or Third-Party Liability activities as they do today. Comment: Multiple commenters stated that CMS should ensure that regulatory language clearly makes the opt in requirement applicable to Medicaid managed care plans. Response: We intentionally did not include regulatory text requiring Medicaid managed care plans and CHIP managed care entities to meet the requirement to collect patient permission for payer to payer data exchange. As discussed in section II.C.4.b. of this final rule, we are finalizing that requirement for state Medicaid and CHIP agencies because we believe that they are the proper entity to VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 hold a patient’s opt in decision. State Medicaid and CHIP agencies may work with their managed care plans and entities to gather that information, but ultimately the requirement to gather and maintain that information is the responsibility of the state Medicaid or CHIP agency. As proposed and discussed in section II.E.2.a. of this final rule, we are finalizing that the responsibility to collect patient permission for the Payer-to-Payer API data exchange is not eligible for exemption from the API requirements. Therefore, even if a state receives an exemption from the Payer-to-Payer API, it is still responsible for collecting and maintaining a record of patient opt in permission for this data exchange. We note that we are also finalizing that state Medicaid and CHIP programs, rather than their managed care organizations, are responsible for providing educational resources at the time of requesting permission for payer to payer data exchange and for collecting identifying information about patients’ previous/concurrent payer(s). Comment: A commenter requested clarification on whether a patient’s opt in permission is required to share data between impacted payers within the same state Medicaid program. Another commenter asked us to explain what types of managed care plans are included in this statement (for example, MCOs, PIHPs, PAHPs, Primary Care Case Managers (PCCMs), integrated plans for patients dually eligible for Medicare and Medicaid). Response: As we explained in the preamble to the proposed rule (87 FR 76238), we know that state Medicaid or CHIP agencies regularly exchange data with their managed care plans and entities. We do not intend the opt in requirements for the Payer-to-Payer API to interfere with or affect this permissible exchange. Medicaid managed care plans, and CHIP managed care entities are not outside sources as described at 42 CFR 431.306(d), but are part of a state’s Medicaid and/or CHIP programs as a whole, because these entities are contracted to support the agency’s administration of its Medicaid or CHIP state plan. Specifically, Medicaid managed care plans and CHIP managed care entities are contracted with the Medicaid state agency to deliver Medicaid program health care services to beneficiaries under the state plan. Hence, we are finalizing our proposal that if a Medicaid or CHIP agency is exchanging information per our Payerto-Payer API proposals with a managed PO 00000 Frm 00096 Fmt 4701 Sfmt 4700 care plan or managed care entity with which they have a contract, the requirement to obtain patient opt in would not apply. We consider any plan and entity that has a contract with the state Medicaid or CHIP agency to deliver Medicaid program health care services to beneficiaries under the state plan, including state Medicaid agency contracts with D–SNPs under 42 CFR 422.107, to be part of the state’s Medicaid or CHIP programs, regardless of the coverage model. We note that this policy and opt in requirement to share data between impacted payers would not replace regulatory requirements as described at 42 CFR part 422, including as they relate to integrated D–SNPs. We note that permissible data exchange only covers data that facilitate that plan’s contracted services. For instance, it would be inappropriate to share patient data with a managed care plan or entity other than the one with which the patient is enrolled. The other Payer-to-Payer API requirements, such as the requirement to use a FHIR API and the authorization and authentication protocols would apply to data exchange required in this final rule between state Medicaid and CHIP agencies and their managed care plans or managed care entities. The exchange must also not be prohibited by other law. c. Federal Matching Funds for State Medicaid and CHIP Expenditures on Implementation of Payer to Payer Data Exchange In section II.E. of this final rule, we discuss Federal matching funds for certain state Medicaid and CHIP FFS programs’ expenditures related to implementation of the payer to payer data exchange (this was also addressed in the proposed rule at 87 FR 76278). d. Medicaid Expansion CHIP In section II.E. of this final rule, we discuss implementation for states with Medicaid Expansion CHIP programs (this was also addressed in the proposed rule at 86 FR 76279). 5. Extensions, Exemptions, and Exceptions See section II.E. of this final rule for a discussion of extensions and exemptions and the final policies for the Payer-to-Payer API for state Medicaid and CHIP FFS programs and exceptions for the Payer-to-Payer API for QHP issuers on the FFEs (this was also addressed in the proposed rule at 86 FR 76279). BILLING CODE 4150–28–P E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 VerDate Sep<11>2014 TABLE D1: PAYER TO PAYER DATA EXCHANGE FINAL POLICIES Jkt 262001 11.C.3.c. PO 00000 11.C.3.c. Frm 00097 11.C.3.d. Fmt 4701 Sfmt 4725 11.C.3.b. E:\FR\FM\08FER2.SGM 11.C.3.f. 11.C.3.e. 08FER2 11.C.3.g. Technical Standards (Compliance date January 1, 2027) 42CFR 422.121(b)(l) 42CFR 431.61(b)(l) Through cross reference to 42 CFR 431.61(b)(l) at42 CFR 438.242(b)(7) 42CFR 457.731(b)(l) Through existing cross reference to 42 CFR 438.242 at 42CFR 457.1233(d Opt In (Compliance date January 1, 2027) I Identify Previous and Concurrent Payers (Compliance date January 1, 2027 I Data Exchange Requirement (Compliance date January 1, 2027) I Accessible Content andAPI Requirements (Compliance date Janu 1,2027 Data Incorporation (Compliance date January 1, 2027) 42CFR 422.121 (b )(2) 42CFR 431.61(b)(2) NIA 42CFR 457.73 l(b )(2) NIA 42CFR 422.121(b )(3) 42CFR 43 l.61(b )(3) NIA 42CFR 457.73 l(b )(3) NIA 42CFR 422.121(b)(4) and (5) 42CFR 431.61(b)(4) and (5) 42CFR 457.73 l(b )(4) and (5) 42CFR 422.121(b)(4)(ii) 42CFR 43 l.61(b )(4)(ii) Through cross reference to 42 CFR 431.61(b)(4) and (5) at 42 CFR 438.242(b)(7) Through cross reference to 42 CFR 43 l.61(b)(4)(ii) at 42 CFR 438.242(b)(7) Through existing cross reference to 42 CFR 438.242 at 42CFR 457.1233(d) 42CFR 422.121(b )(4)(v) 42CFR 431.61(b)(4)(v) Concurrent Coverage Data Exchange Requirements (Compliance date January 1, 2027) 42CFR 422.121(b)(6) 42CFR 431.61(b)(6) I Patient Educational 42CFR 422.121(b)(7) 42CFR 431.61(b)(7) I I I ER08FE24.003</GPH> Through cross reference to 42 CFR 431.61(b)(7) at42 CFR 438.242(b )(7) 1 42 CFR 457.73 l(b )(4)(v) I 45 CFR 156.222(b)(2) 1 1 Through existing cross reference to 42 CFR 438.242 at 42CFR 457.1233(d 45 CFR 156.222(b)(3) 45CFR 156.222(b)(4) and (5) 1 42 CFR 457.73 l(b)(6) 42CFR 457.73 l(b )(7) 1 1 42CFR 457.73 l(b)(4)(ii) 1 45 CFR 156.222(b)(1) 1 45 CFR 156.222(b)(4)(ii) 45 CFR 156.222(b)(4)(v) 45 CFR 156.222(b)(6) 45 CFR 156.222(b)(7) 8853 Resources Regarding API (Compliance date January 1, 2027) Through cross reference to 42 CFR 431.61(b)(4)(v) at42 CFR 438.242~}{7 Through cross reference to 42 CFR 431.61(b)(6) at42 CFR 438.242(b )(7) 1 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations 18:23 Feb 07, 2024 11.C.3.a. lotter on DSK11XQN23PROD with RULES2 8854 Jkt 262001 PO 00000 Frm 00098 Fmt 4701 Sfmt 4700 E:\FR\FM\08FER2.SGM 08FER2 ER08FE24.004</GPH> 11.C.5. 11.C.5. I Extension for Medicaid and CHIP FFS (Effective Date of the Final Rule Exemption for Medicaid and CHIP FFS (Effective Date of Final Rule I Exceptions for QHP Issuers on the FFEs (Effective Date of the Final Rule I NIA 42 CFR 457.73 l(c)(l) I NIA I NIA NIA 42CFR 457.73 l(c)(2) NIA NIA NIA NIA NIA 42 CFR 431.6l(c)(l) I NIA NIA 42CFR 431.6l(c)(2) NIA NIA 1 1 1 45 CFR 156.222(c) Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations 18:23 Feb 07, 2024 BILLING CODE 4150–28–C VerDate Sep<11>2014 11.C.5. Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations lotter on DSK11XQN23PROD with RULES2 6. Final Action After considering the comments received, and for the reasons discussed in the CMS Interoperability and Prior Authorization proposed rule and our response to those comments (as summarized previously), we are finalizing our proposal with the following modifications: • Impacted payers must implement and maintain a Payer-to-Payer API beginning in 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs) rather than in 2026. • Impacted payers are not required to share the quantity of items or services used under a prior authorization via the Payer-to-Payer API. • The data exchange between a previous payer and a new payer is limited to data with a date of service within the previous 5 years. • Impacted payers are required to request patients’ permission for payer to payer data exchange and identifying information about patients’ previous/ concurrent payers no later than 1 week after the start of coverage, as that term is defined for each type of impacted payer, rather than at enrollment. See further discussion for the exact details of the final requirements for impacted payers. We are finalizing the rescission of the payer to payer data exchange policy previously finalized in the CMS Interoperability and Patient Access rule (85 FR 25568) at 42 CFR 422.119(f)(1) and 438.62(b)(1)(vi) and (vii) and 45 CFR 156.221(f)(1). We are finalizing a requirement that, beginning in 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs), impacted payers must implement and maintain a Payer-toPayer API that is conformant with certain technical standards, documentation requirements, and denial or discontinuation policies. Specifically, those technical standards are HL7 FHIR R4 at 45 CFR 170.215(a)(1), US Core IG at 45 CFR 170.215(b)(1)(i), and Bulk Data Access IG at 45 CFR 170.215(d)(1). We are also finalizing a requirement that, by the deadlines, impacted payers VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 (except Medicaid managed care plans and CHIP managed care entities) must establish and maintain a process to gather patient permission for payer to payer data exchange no later than 1 week after the start of coverage. We are finalizing an opt in framework whereby a patient or personal representative must affirmatively agree to allow that data exchange. Impacted payers must also have a process for patients to change their permission at any time. We are finalizing a requirement that, by the deadlines, impacted payers must establish and maintain a process to identify a patient’s previous/concurrent payer(s) no later than 1 week after the start of coverage. As part of this process, impacted payers are required to allow a patient to report multiple previous/ concurrent payers if they had (or continue to have) concurrent coverage. If a patient does report multiple previous payers, impacted payers are required to request that patient’s data from all previous/concurrent payers. If a patient does not respond or additional information is necessary, the impacted payer must make reasonable efforts to engage with the enrollee to collect this information. We are also finalizing a requirement that, no later than the compliance dates, impacted payers must establish and maintain a process to gather permission and previous/concurrent payer(s) information from patients who are already enrolled. We are finalizing a requirement that, by the deadlines, impacted payers must request a patient’s data from a patient’s previous/concurrent payer(s) no later than 1 week after the payer has sufficient identifying information and the patient has opted in. Impacted payers must also request data from a patient’s previous/concurrent payers(s) within 1 week of that patient’s request to do so. Impacted payers must include an attestation with this request for data affirming that the patient is enrolled with the requesting payer and has opted into the data exchange in a manner that meets the legal requirements. Additionally, we are finalizing a requirement that, by the deadlines, when an impacted payer has sufficient identifying information and the patient has opted in, they must request data from any concurrent payers at least quarterly. Impacted payers who receive a request for a patient’s data from a known concurrent payer must respond with the required data within 1 business day of receiving the request. We are finalizing a requirement that, by the deadlines, upon receiving a request that meets the legal requirements, impacted payers must PO 00000 Frm 00099 Fmt 4701 Sfmt 4700 8855 make any of the required information that they maintain available to new payers no later than 1 business day after receiving the request. We are finalizing a requirement that, by the deadlines, impacted payers must make available via the Payer-to-Payer API, by request from payer that meets certain requirements, claims and encounter data (excluding provider remittances and patient cost-sharing information), all data classes and data elements included in a content standard at 45 CFR 170.213, and certain information about prior authorization requests and decisions (excluding those for drugs and those that were denied) that the payer maintains with a date of service within 5 years of the request. The required information is— • The prior authorization status; • The date the prior authorization was approved; • The date or circumstance under which the prior authorization ends; • The items and services approved; and • Structured and unstructured administrative and clinical documentation submitted by a provider. We are finalizing a requirement that impacted payers are required to make this information about prior authorizations available for the duration that the authorization is active and for at least 1 year after the prior authorization’s last status change. We are finalizing a requirement that, by the deadlines, information received by an impacted payer through the payer to payer data exchange must be incorporated into the payer’s patient record. We are finalizing a requirement that, by the deadlines, impacted payers (except Medicaid managed care plans and CHIP managed care entities) must provide educational resources to their patients about the Payer-to-Payer API in plain language. These resources must include information about the benefits of Payer-to-Payer API data exchange, the patient’s ability to opt in or withdraw that permission, and instructions for doing so. Impacted payers must make this information available to patients when requesting the opt in decision. Thereafter, impacted payers must provide this information to patients annually, in mechanisms the payer ordinarily uses to communicate with patients. These resources must also be available in an easily accessible location on payers’ public websites. These final policies apply to MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities (excluding NEMT PAHPs), and QHP E:\FR\FM\08FER2.SGM 08FER2 8856 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations issuers on the FFEs at the CFR sections listed in Table D1. 7. Statutory Authorities for Payer to Payer Data Exchange Proposals We note that we received no public comments on the statutory authorities for our Payer-to-Payer API policies. lotter on DSK11XQN23PROD with RULES2 a. MA Organizations For MA organizations, we are finalizing these Payer-to-Payer API requirements under our authority at section 1856(b) of the Act to adopt by regulation standards consistent with and to carry out Part C of Title XVIII of the Act (such as section 1852(d)(1)(A) of the Act). In addition, section 1857(e)(1) of the Act authorizes the Secretary to adopt contract terms and conditions for MA organizations that are necessary, appropriate, and not inconsistent with the statute. In total, the regulations we are adopting in this final rule for MA organizations and MA plans are necessary and appropriate because they address and facilitate continued access to enrollees’ medical records and health information when they change payers, which will support consistent and appropriate coordination of coverage when enrollees have concurrent payers and will support coordination of care and continuation of active courses of treatment when enrollees change payers. In regulations establishing the MA program,87 CMS described it as a program designed to: provide for private plan options available to Medicare beneficiaries, especially those in rural areas, enrich the range of benefit choices, provide incentives to plans and add specialized plans to coordinate and manage care in ways that comprehensively serve those with complex and disabling diseases and conditions, use competition to improve service and benefits, invest in preventive care, hold costs down in ways that attract enrollees, and advance the goal of improving quality and increasing efficiency in the overall health care system. This final rule supports these goals and enables the MA program to advance services for its enrollees by providing greater access to information in a way that will improve care management for payers, providers, and the patient. Section 1856(b) of the Act requires the Secretary to establish regulatory standards for MA organizations and plans that are consistent with, and carry out, Part C of the Medicare statute, Title 87 Medicare Program: Establishment of the Medicare Advantage Program, 70 FR 4588 (January 28, 2005) (to be codified at 42 CFR part 417). VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 XVIII of the Act. The Payer-to-Payer API proposals support MA organizations sharing certain claims, encounter, and clinical data, as well as prior authorization requests and decisions, with another payer that, as identified by the enrollee, has or does cover the enrollee. Such exchanges of data about patients could facilitate continuity of care and enhance care coordination. As discussed for the Provider Access API in section II.B. of this final rule, allowing payers to share health information for one or more patients at once could increase efficiency and simplicity of administration. Though we are not requiring payers to share data for more than one patient at a time, there are efficiencies to doing so, both for communicating information and for leveraging available technology. Further, providing MA organizations with additional data about their enrollees through these data exchanges will increase the scope of data that the MA organizations must make available to enrollees through the Patient Access API. It will give payers access to all their enrollees’ information with limited effort and enable the payer to then make that information available to providers and to enrollees through the Provider Access and Patient Access APIs. It may reduce the amount of time needed to evaluate a patient’s current care plan and possible implications for care continuity, which may introduce efficiencies and improve care. As discussed earlier, if a new payer receives information and documentation about prior authorization requests from a previous payer, the new payer can review this information and determine that a new prior authorization may not be necessary for an item or service that was previously approved. Instead, the same care may be continued, reducing burden on both payers and providers, and improving patient care. While the statutory provisions governing the MA program do not explicitly address sharing data with other payers that cover or have covered an enrollee, the benefits to be gained by sharing data make adoption of Payer-to-Payer API policies necessary and appropriate for the MA program. Further, requiring use of the API and the specifications for the data to be shared provides a step toward greater interoperability among payers. Ultimately, using the Payer-to-Payer API is anticipated to ensure that payers receive patient information in a timely manner, which could lead to more appropriate service utilization and higher patient satisfaction. Such goals are consistent with the MA statute. Section 1852(h) of the Act requires MA organizations to provide their PO 00000 Frm 00100 Fmt 4701 Sfmt 4700 enrollees with timely access to medical records and health information as far as MA organizations maintain such information. As technology evolves to allow for faster, more efficient methods of information transfer, so do expectations as to what is generally considered ‘‘timely.’’ Currently, consumers across public and private sectors have become increasingly accustomed to accessing a broad range of personal records, such as bank statements, credit scores, and voter registrations, immediately through electronic means and with updates received in near real-time. Thus, we to align our standards with current demands, we must take steps for MA enrollees to have immediate, electronic access to their health information and plan information. The information exchanged via the Payer-to-Payer API will ultimately be accessible to enrollees via the Patient Access API and will therefore improve timeliness to medical records and health information as enrollees will no longer have to spend time contacting previous payers to access their information. These data will be accessible as needed by the enrollee’s current payer and would therefore support timely access. Section 1852(d)(1)(A) of the Act requires MA organizations to, as a condition of using a network of providers, make covered benefits available and accessible to enrollees in a manner which assures continuity in the provision of benefits. In implementing section 1852(d)(1)(A) of the Act, we adopted a regulation, at 42 CFR 422.112(b), that requires MA organizations to ensure the continuity of care and integration of services through arrangements with providers that include procedures to ensure that the MA organization and the contracted providers have access to the information necessary for effective and continuous patient care. Consistent with section 1852(d)(1)(A) of the Act, the final requirement here for MA organizations to implement and maintain a Payer-toPayer API will facilitate exchanges of information about enrollees that are necessary for effective and continuous patient care. Under this final rule, the data received from other impacted payers will become part of the data the MA organization maintains and will therefore be available (subject to other law authorizing the disclosure) to providers via the Provider Access API discussed in section II.B. of this final rule; the data could then be used for treatment and coordination of care purposes. The finalized policies in this rule are necessary, appropriate, and consistent E:\FR\FM\08FER2.SGM 08FER2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations lotter on DSK11XQN23PROD with RULES2 with Part C of Title XVIII of the Act. Overall, establishing these regulatory requirements for MA organizations will improve enrollee’s quality of care by ensuring that they do not lose their patient records when they change payers. b. Medicaid and Children’s Health Insurance Program Our provisions in this section fall generally under our authority in the following provisions of the Act. • Section 1902(a)(4) of the Act, which requires that a state Medicaid plan provide such methods of administration as are found by the Secretary to be necessary for the proper and efficient operation of the state Medicaid plan. • Section 1902(a)(8) of the Act, which requires states to ensure that Medicaid services are furnished with reasonable promptness to all eligible individuals. • Section 1902(a)(19) of the Act, which requires states to ensure that care and services are provided in a manner consistent with simplicity of administration and the best interests of the recipients. The final requirements related to the Payer-to-Payer API are authorized by sections 1902(a)(4), (a)(8), and (a)(19) of the Act for the following reasons. First, because the Payer-to-Payer API is designed to enable efficient exchange of data between payers, we anticipate that it will help state Medicaid programs improve the efficiencies and simplicity of their own operations under a Medicaid state plan, consistent with sections 1902(a)(4) and (a)(19) of the Act. It will give Medicaid agencies and their managed care plans access to their beneficiaries’ information in a standardized manner and enable states to then make that information available to providers and patients through the Patient Access and Provider Access APIs. It may also reduce the amount of time needed to evaluate a patient’s current care plan and have possible implications for care continuity, which may introduce efficiencies and improve care. Receiving patient information at the start of coverage will lead to more appropriate service utilization and higher beneficiary satisfaction by Medicaid agencies and those managed care plans considered impacted payers under this final rule by supporting efficient care coordination and continuity of care, which could lead to better health outcomes. As discussed in section II.C.3.b. of this final rule, when a state Medicaid program has access to a previous payer’s prior authorization decisions, the Medicaid program may choose to accept the existing decision and support VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 continued patient care without requiring a new prior authorization or duplicate tests. This information exchange might also improve care continuity for beneficiaries who have concurrent coverage in addition to Medicaid by improving the coordination of health coverage they receive, reducing gaps, or duplication of coverage. Our final rule is expected to help states and managed care plans furnish Medicaid services with reasonable promptness and in a manner consistent with beneficiaries’ best interests, consistent with sections 1902(a)(8) and (a)(19) of the Act. A significant portion of Medicaid beneficiaries experience coverage changes and churn in a given year.88 Therefore, exchanging this information with a beneficiary’s next payer may also better support care continuity for Medicaid beneficiaries. When states share information about Medicaid beneficiaries or former beneficiaries with their concurrent and next payers, they can support opportunities for improved care coordination for Medicaid beneficiaries and former beneficiaries. Exchanging information about Medicaid beneficiaries and former beneficiaries between payers might also reduce the amount of time needed to evaluate beneficiaries’ current care plans, their health risks, and their health conditions at the time they enroll with the Medicaid program, as well as with another payer. This information exchange might be of particular value to improve care continuity for beneficiaries who might churn into and out of Medicaid coverage. The final rule may also improve the provision of Medicaid services, by potentially helping to ensure that Medicaid beneficiaries who may require coordinated services with concurrent payers can be identified and provided case management services, reduce duplication of services, and improve the coordination of care, as appropriate. In addition, section 1902(a)(7) of the Act requires that states must provide safeguards that restrict the use or disclosure of information concerning Medicaid applicants and beneficiaries to purposes that are directly connected with the administration of the Medicaid 88 Churning occurs when people lose Medicaid coverage and then re-enroll within a short period of time. Medicaid beneficiaries frequently experience churning. See U.S. Department of Health and Human Services, Assistant Secretary for Planning and Evaluation (2021, April 12). Medicaid churning and continuity of care: Evidence and policy considerations before and after the COVID– 19 pandemic (issued April 12, 2021). Available at: https://aspe.hhs.gov/reports/medicaid-churningcontinuity-care. PO 00000 Frm 00101 Fmt 4701 Sfmt 4700 8857 state plan. The implementing regulations at 42 CFR part 431, subpart F, for section 1902(a)(7) of the Act list purposes that CMS has determined are directly connected with administration of Medicaid state plans (42 CFR 431.302) and require states to provide safeguards meeting certain requirements to restrict uses and disclosures of Medicaid beneficiary data, including requirements about releasing applicant and beneficiary information at 42 CFR 431.306. Requiring the data described in this section to be shared via the Payer-toPayer API is consistent with states’ requirements to provide safeguards meeting certain requirements to share these data since it is related to providing services for beneficiaries, a purpose listed at 42 CFR 431.302(c). As described previously in sections II.A.5.b. and II.B.6.b. of this final rule related to authority under sections 1902(a)(8) and 1902(a)(19) of the Act, states that share information about Medicaid beneficiaries or former beneficiaries with their concurrent and next payers, may support opportunities for improved care coordination, reduction in the amount of time needed to evaluate beneficiaries’ current care plans, their health risks, and their health conditions at the time they enroll with the Medicaid program, as well as with another payer. This information exchange might be of particular value to improve care continuity for beneficiaries who churn into and out of Medicaid coverage, described in more detail previously. When state Medicaid agencies share medical records or any other health or enrollment information pertaining to individual beneficiaries, they must comply with the requirements of 42 CFR part 431, subpart F, including 42 CFR 431.306. For Medicaid managed care, and in addition to the general authorities cited previously regarding Medicaid programs, the finalized exchange of adjudicated claims and encounter data, all data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI), and certain information about prior authorizations maintained by the payer with a date of service within 5 years of the request by a patient’s new or concurrent payer will greatly enhance an MCO’s, PIHP’s, or PAHP’s ability to fulfill its obligations under 42 CFR 438.208(b), which require them to: implement procedures to deliver care to and coordinate services including ensuring that each enrollee has an ongoing source of appropriate care; coordinate services between settings of care, among Medicaid programs, and with community and E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8858 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations social support providers; make a best effort to conduct an initial screening of each enrollee’s needs; and share with the state or other MCOs, PIHPs, and PAHPs serving the enrollee the results of any identification and assessment of that enrollee’s needs to prevent duplication of those activities. The data provided via the Payer-to-Payer API in this final rule will give managed care plans the information needed to perform these required functions much more easily, thus enhancing the effectiveness of the care coordination, and helping enrollees receive the most appropriate care in an effective and timely manner. For CHIP, we finalized these requirements under our authority in section 2101(a) of the Act, which states that the purpose of Title XXI of the Act is to provide funds to states to provide child health assistance to uninsured, low-income children in an effective and efficient manner that is coordinated with other sources of health benefits coverage. The provisions in this final rule can strengthen our ability to fulfill these statutory obligations in a way that recognizes and accommodates using electronic information exchange in the health care industry today and will facilitate a significant improvement in the delivery of quality health care to our beneficiaries. As with the Medicaid FFS and Medicaid managed care programs, the provisions in this section of the final rule for CHIP FFS and CHIP managed care entities require using a Payer-toPayer API to exchange claims, encounter, clinical and prior authorization data at a beneficiary’s request, or any time a beneficiary changes payers, using a FHIR API. The current payer can use data from the previous payer to respond to a request for a prior authorization more effectively or accurately, because under this final rule, a new payer will have historical claims or clinical data upon which they may review a request with more background data. Access to information about new patients will enable appropriate staff within the CHIP program to coordinate care and conduct care management more effectively because they will have better data available to make decisions for planning. In many cases, patients do not remember what services they have had, or other possibly relevant encounters that could help payers manage their care. This final rule is consistent with the goal of providing more informed and effective care coordination, which will help to ensure that CHIP services are provided in a way that supports quality care, which aligns with section 2101(a) of the Act. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 Finally, the safeguards for applicant and beneficiary information at 42 CFR part 431, subpart F, are also applicable to CHIP through a cross reference at 42 CFR 457.1110(b). As discussed previously for Medicaid, CHIP agencies’ data exchange through the Payer-toPayer API is related to providing services to beneficiaries, which is described at 42 CFR 431.302(c) as a purpose directly related to state plan administration. We remind states that when they share medical records or any other health or enrollment information pertaining to individual beneficiaries, they must comply with the privacy protections at 42 CFR 457.1110 and the release of information provisions at 42 CFR 431.306. c. Qualified Health Plan Issuers on the Federally-Facilitated Exchanges For QHP issuers on the FFEs, we finalized these new requirements under our authority in section 1311(e)(1)(B) of the Affordable Care Act, which affords the Exchanges the discretion to certify QHPs if the Exchange determines that making available such health plans through the Exchange is in the interests of qualified individuals in the state in which the Exchange operates. Requiring QHP issuers on the FFEs to implement and maintain a Payer-toPayer API will allow the seamless flow from payer to payer of adjudicated claims, and encounter data, all data classes and data elements included in a standard at 45 CFR 170.213 (USCDI), and certain information about prior authorizations, that are maintained by the payer with a date of service within 5 years of the request by a patient’s new or concurrent payer. Ensuring a means for an enrollee’s new issuer to electronically obtain the enrollee’s claims, encounter, and other data, as well as prior authorization information with corresponding medical records, from the previous issuer will reduce administrative burden and result in more timely and efficient care coordination and responses to prior authorization requests. We believe that it is in the interest of qualified individuals that QHP issuers on the FFEs have systems in place to send information important to care coordination to a departing enrollee’s new payer, and that QHP issuers on FFEs also have systems in place to receive such information from other payers on behalf of new and concurrent enrollees, as appropriate and consistent with the provisions in this section. Having patient information at the beginning of a new plan may assist the new payer in identifying patients who need care management services, which PO 00000 Frm 00102 Fmt 4701 Sfmt 4700 could reduce the cost of care. We encourage SBEs to consider whether a similar requirement should be applicable to QHP issuers participating in their Exchange. Though we are not requiring the exchange of all enrollees’ data at one time between impacted payers, we encourage QHP issuers on the FFEs to use the Bulk Data Access IG for the Payer-to-Payer API once it is available, as it will improve the efficiency and simplicity of data transfers between issuers by enabling the exchange of all data for all patients at once. The opportunity to support the exchange of data from multiple patient records at once, rather than data for one patient at a time, may be cost effective for the issuers. D. Prior Authorization API and Improving Prior Authorization Processes 1. Background This section of the final rule addresses the topic of prior authorization and includes both technical and operational requirements intended to improve the prior authorization process for payers, providers, and patients. Here, we finalize our proposals for payers to implement and maintain an API to support and streamline prior authorization processes; respond to prior authorization requests within certain timeframes; provide a specific reason for prior authorization denials; and publicly report on prior authorization approvals, denials, and appeals. In the CMS Interoperability and Prior Authorization proposed rule (87 FR 76286) we provided a comprehensive review of the work HHS conducted regarding prior authorization processes and their associated burden to identify the primary issues that needed to be addressed to alleviate the burdens of these processes on patients, providers, and payers. We cited studies from ONC 89 which highlighted the burdens associated with prior authorization including difficulty determining payerspecific requirements for items and services that require prior authorization; inefficient use of provider and staff time processing prior authorization requests and information (sending and receiving) through fax, telephone, and web portals; 89 Office of the National Coordinator for Health Information Technology (2020). Strategy on Reducing Burden Relating to the Use of Health IT and EHRs. Retrieved from https://www.healthit.gov/ topic/usability-and-provider-burden/strategyreducing-burden-relating-use-health-it-and-ehrs. E:\FR\FM\08FER2.SGM 08FER2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations lotter on DSK11XQN23PROD with RULES2 and unpredictable wait times to receive payer decisions. We referenced American Medical Association (AMA) physician surveys from 2018, 2020, and 2022 90 which noted issues with prior authorization, and we used these studies to estimate the costs and savings for this final rule. Please see the CMS Interoperability and Prior Authorization proposed rule (87 FR 76286–76287) for the detailed context of these industry surveys as well as the reports from the 2019 meetings of the two Federal advisory committees, the Health Information Technology Advisory Committee (HITAC) 91 and the National Committee on Vital and Health Statistics (NCVHS),92 which conducted joint hearings to discuss persistent challenges with prior authorization workflows and standards; and the follow up 2020 task force on the Intersection of Clinical and Administrative Data (ICAD) Task Force at 87 FR 76287. We use the term prior authorization to refer to the process by which a provider must obtain approval from a payer before providing certain covered items and services to receive payment for delivering those items or services to a covered individual. As we stated in the CMS Interoperability and Prior Authorization proposed rule, prior authorization has an important place in the health care system, but the process of obtaining prior authorization can be challenging for patients, providers, and payers. Interested parties, including payers and providers, say that dissimilar payer policies, inconsistent use of electronic standards, and other technical barriers have created provider workflow challenges and an environment in which the prior authorization process is a primary source of burden for both providers and payers, a major source of burnout for providers, and can create a health risk for patients if inefficiencies in the process cause delays in medically necessary care. The prior authorization policies in this final rule apply to any formal decision-making process through which impacted payers render an approval or denial determination in response to prior authorization requests 90 American Medical Association (2022). AMA prior authorization (PA) physician survey. Retrieved from https://www.ama-assn.org/system/ files/prior-authorization-survey.pdf. 91 Office of the National Coordinator for Health Information Technology (2023). Health Information Technology Advisory Committee (HITAC). Retrieved from https://www.healthit.gov/topic/ federal-advisory-committees/health-informationtechnology-advisory-committee-hitac-history. 92 National Committee on Vital and Health Statistics (2022). Charter. Retrieved from https:// ncvhs.hhs.gov/about/charter/. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 based on the payer’s coverage guidelines and policies before services or items are rendered or provided. As discussed in section I.D. of this final rule, we exclude drugs from the provisions in this section, meaning any drugs that could be covered by the impacted payers affected by these provisions. Thus, the policies herein do not apply to prescription drugs that may be self-administered, administered by a provider, or that may be dispensed or administered in a pharmacy or hospital, or OTC drugs that may be covered by an impacted payer. We include a definition of drugs for purposes of this exclusion for each impacted payer in the CFR where applicable to provisions for implementation of the Prior Authorization API. For MA organizations, the definition of drugs also includes any products that constitute a Part D drug, as defined by 42 CFR 423.100, and are covered under the Medicare Part D benefit by MA–PDs; this part of the definition specific to MA organizations provides a clear dividing line for MA–PD plans that must comply with this new rule. However, payers may voluntarily incorporate their business rules for prior authorizations for drugs using the Prior Authorization API now being finalized in this rule. As noted in section I.D., although Medicare FFS is not directly affected by this final rule, we will evaluate opportunities to improve automation of prior authorization processes in the Medicare FFS program as feasible. We received nearly 900 letters in response to the CMS Interoperability and Prior Authorization proposed rule, with hundreds of individual comments specific to the importance of the topic of prior authorization and the critical timing of addressing this issue. Most of the comments were relevant to the proposals and others were out of scope. The majority of commenters supported our proposals which are intended to mitigate longstanding issues with prior authorization processes and many commenters stressed the importance of finalizing the policies in this final rule as soon as practicable to resolve patient access to care issues. Some commenters identified concerns with the timing of compliance for the policies (too soon or too late), with prior authorization decision timeframes (too short or too long), and with reporting of metrics (too little or too much). We carefully reviewed each comment and considered the input to inform the policies now being described in this final rule. To be fully responsive to the public comment process, yet avoid creating an overwhelming final rule, we have consolidated input from all of the PO 00000 Frm 00103 Fmt 4701 Sfmt 4700 8859 comments and summarized the contents with our responses for each provision. We value the diverse commentary provided by all interested parties as the volume and scope helped shape our approach to these final policies which advance our commitment to interoperability, burden reduction, process improvement for prior authorization, and transparent rulemaking. Comments that were out of scope for this final rule are not addressed here. Comment: Multiple commenters stated that, while prior authorizations may improve the safety or efficiency of care in some circumstances, they can lead to negative effects for patients and providers. A commenter suggested that CMS implement a broader set of changes to prior authorization processes to correct current abuses, specifically noting that improving the speed of prior authorizations without addressing the content of prior authorization requests will not improve outcomes of inappropriate use of prior authorizations. Another commenter recommended that CMS further evaluate prior authorization burdens and make additional proposals. Response: We appreciate that there are still concerns about the general use of prior authorization in the health care system. However, prior authorization continues to have a place in the health care system and can support functions such as utilization management, costeffective care delivery, patient safety, and preventing unnecessary treatment. The policies we are finalizing in this rule are intended to improve the transparency and efficiency of the process. Regarding suggestions for us to implement broader policy changes for prior authorization, we acknowledge that Federal policies alone cannot control all payer specific processes or patient health outcomes. Policies must be applied with good medical judgment and review, and we reiterate that we, in the administration of its programs 93 and implementation of programmatic authority, continue to evaluate opportunities for future rulemaking to alleviate burdens, mitigate harm, and improve patient care. For example, in the CY 2024 MA and Part D final rule (88 FR 22120), we finalized several provisions to ensure that utilization management tools, including prior authorization requirements, are used in ways that ensure timely and appropriate access to medically necessary care for 93 CMS’s oversight and administration authority and roles for MA, Medicaid, CHIP, and the FFEs vary with each program. E:\FR\FM\08FER2.SGM 08FER2 8860 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations lotter on DSK11XQN23PROD with RULES2 beneficiaries enrolled in MA plans.94 Specifically, we explained current rules related to acceptable coverage criteria for basic benefits that require MA organizations to comply with national coverage determinations (NCDs), local coverage determinations (LCDs), and general coverage and benefit conditions included in Traditional Medicare regulations. In addition, under new regulations adopted in that final rule, when coverage criteria are not fully established, MA organizations may create internal coverage criteria based on current evidence in widely used treatment guidelines or clinical literature made publicly available to us, enrollees, and providers. The CY 2024 MA and Part D final rule also streamlines prior authorization requirements, including adding continuity of care requirements and reducing disruptions for beneficiaries. First, we finalized that prior authorization policies for coordinated care plans may only be used to confirm the presence of diagnoses or other medical criteria that are the basis for coverage determinations and/or ensure that an item or service is medically necessary based on standards specified in that final rule (see 42 CFR 422.138(b)). Second, we finalized that for MA coordinated care plans,95 an approval granted through prior authorization processes must be valid for as long as medically necessary to avoid disruptions in care in accordance with applicable coverage criteria, the patient’s medical history, and the treating provider’s recommendation, and that plans provide a minimum 90day transition period when an enrollee who is currently undergoing an active course of treatment switches to a new MA plan or is new to MA (see 42 CFR 422.112(b)(8)). Finally, to ensure prior authorization and other utilization management policies are consistent with CMS rules, we finalized a requirement that all MA plans that use utilization management policies must establish a Utilization Management Committee to review all utilization management policies, including prior authorization, annually and ensure they are consistent with regulatory standards for MA plan coverage, including 94 National Archives (2022, December 27). Federal Register. Retrieved from https:// www.federalregister.gov/documents/2022/12/27/ 2022-26956/medicare-program-contract-year-2024policy-and-technical-changes-to-the-medicareadvantage-program. 95 An MA coordinated care plan is a plan that includes a network of providers that are under contract or arrangement with the organization to deliver the benefit package approved by CMS; this includes MA plans that are HMOs, PPOs, and MA plans for special needs individuals. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 compliance with current, Traditional Medicare’s NCDs and LCDs (see 42 CFR 422.137). a. Compliance Dates We proposed compliance dates for most impacted payers in 2026 (by January 1, 2026, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2026, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2026, for QHP issuers on the FFEs). There was one exception for some of the Medicaid FFS fair hearing and notice requirements, as discussed in the CMS Interoperability and Prior Authorization proposed rule (87 FR 76299 and 76300), which would take effect upon the effective date of this final rule. Based on commenter feedback, we are extending the compliance dates for the Prior Authorization API for all impacted payers consistent with the compliance dates for the Provider Access and Payerto-Payer APIs to 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs). Throughout this rule, we generally refer to these compliance dates as ‘‘in 2027’’ for the various payers. The prior authorization business process improvements, or those provisions that do not require API development or enhancement, including the requirement to communicate a specific reason for a denial, reduced decision timeframes for standard and expedited prior authorization decisions, and public reporting of certain prior authorization metrics are being finalized as proposed with a compliance dates in 2026 (by January 1, 2026, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2026, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2026, for QHP issuers on the FFEs). Throughout this rule, we generally refer to these compliance dates as ‘‘in 2026’’ for the various payers. We received comments on the compliance dates for both the Prior Authorization API and process improvement proposals that do not require API development or enhancement. Overall compliance timeline comments are addressed in greater detail in section I.B. of this final rule. In this section, we discuss PO 00000 Frm 00104 Fmt 4701 Sfmt 4700 comments more specifically related to the Prior Authorization API and process improvement policies. Comment: Multiple commenters recommended that CMS require the shortened prior authorization decision timeframes earlier than 2026, with some noting that payers, specifically MA organizations, already have the technological capability to implement these new decision timeframes in 2024. These commenters did not provide additional context for the reference to technological capabilities. Other commenters recommended that CMS should require compliance with all requirements that are not contingent on implementation of the Prior Authorization API by January 2025 (for example, decision timeframes, providing specific denial reasons, and reporting of metrics). Commenters said payers should not have trouble adapting their processes to meet the requirements related to decision timeframes and communication with patients and providers by that date, and that patients and providers should not have to wait any longer to benefit from the proposals in this rule. Other commenters cited reasons for implementing the Prior Authorization API proposal as soon as possible or in 2024 or 2025, such as to ensure that bidirectional flow of electronic prior authorization information is fully operational by January 1, 2026 and to protect patients from delays in, and restricted access to, cancer care. Other commenters indicated that transitioning to use the API-facilitated process for prior authorization will require significant development and implementation efforts. A commenter explained that developers would need 12 to 18 months following publication of the final rule to design, develop, test, and release updated software. The commenter went on to state that payers would likely need this same amount of time following publication of the final rule to build their specific coverage and prior authorization criteria and rules into the system for each of their impacted health plans for the Prior Authorization API. This commenter explained that providers and payers will also need time to work together to reconcile variances in the FHIR implementations to ensure that they can engage in accurate exchange of prior authorization information. Response: We appreciate the comments in support of the proposed compliance dates in 2026 for the business process improvement provisions of the CMS Interoperability and Prior Authorization proposed rule that do not require API development or E:\FR\FM\08FER2.SGM 08FER2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations lotter on DSK11XQN23PROD with RULES2 enhancement, specifically the requirement to communicate a specific reason for a denial, reduced decision timeframes for standard and expedited prior authorization decisions, and public reporting of certain prior authorization metrics. We are finalizing those compliance dates for those new requirements in this final rule. We agree that those prior authorization process improvements will initiate burden reductions and support both payers and providers. Although there are several early implementations and pilots of the Prior Authorization API in place today, it is important to take into account the capabilities of all payer types and sizes to implement the requirements of the Prior Authorization API, including internal resource allocation for implementation and testing. All payers must identify relevant prior authorization coverage criteria and rules and program these criteria and rules into the appropriate format for the API in accordance with the IG. Subsequent programming and testing for the questionnaires within the API must take place to ensure functionality. To accommodate these development efforts, CMS is finalizing 2027 compliance dates for the Prior Authorization API. The compliance timeframe should enable the industry to establish a strong technical framework to support the development and scalability of the API-based solution. We anticipate that this timeframe will provide more time for development and testing to enable the integration of the Prior Authorization API between payers, providers, and EHR developers. Additional time for the API implementation also supports state efforts to process the extraordinarily high volume of renewals and other eligibility and enrollment actions that need to be conducted following the end of the Medicaid continuous enrollment condition at section 6008(b)(3) of the Families First Coronavirus Response Act (FFCRA),96 which has consumed both staff and technical resources. 96 As described in prior CMS guidance, states have up to 12 months to initiate, and 14 months to complete, a renewal for all individuals enrolled in Medicaid, CHIP, and the Basic Health Program (BHP) following the end of the Medicaid continuous enrollment condition that ended on March 31, 2023—this process has commonly been referred to as the ‘‘unwinding period.’’ For more details see CMS (2023, January 27). State Health Official letter #23–002. Retrieved from https:// www.medicaid.gov/sites/default/files/2023-08/ sho23002.pdf. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 2. Requirement Tto Implement an API for Prior Authorization a. Prior Authorization API To help address prior authorization process challenges and continue our roadmap to interoperability, we proposed that certain payers implement and maintain a PARDD API to be used by providers to facilitate the prior authorization process. As we explained in section I.B. of this final rule, for consistency with the naming conventions of the other APIs, we have elected to finalize the name of this API to the Prior Authorization API rather than the PARDD API. The purpose of the API is to support the full prior authorization process, as described in the CMS Interoperability and Prior Authorization proposed rule. We believe this revised name best reflects that purpose in this final rule. In this section, we are finalizing policies to improve the prior authorization process between payers and providers using a Prior Authorization API. The purpose of the API is to streamline the process and ensure that payers use technology to provide more useful information about when and how to obtain a prior authorization and the status of an approved or denied prior authorization. In the CMS Interoperability and Prior Authorization proposed rule, we discussed the anticipated benefits of the Prior Authorization API and explained how this API would automate certain tasks, thereby mitigating some of the obstacles of the existing process. We stated that the API would allow a provider to query the payer’s system to determine whether prior authorization was required for certain items and services and identify documentation requirements. The Prior Authorization API would send the prior authorization request from the provider’s EHR or practice management system to the payer. In this final rule, we are finalizing the requirement to use certain standards and making recommendations to use certain IGs to support development of the FHIR API. Use of the Prior Authorization API will enable automation for the prior authorization request and response within the clinical workflow of the provider. The IGs and relevant standards, which are discussed in section II.G. of this final rule, serve as the instructional manuals for the functional capability of the API. When operational, the API enables a provider to submit a request about a medical item or service, determine if additional information is required, submit that information, and additionally assemble the necessary information to submit a PO 00000 Frm 00105 Fmt 4701 Sfmt 4700 8861 prior authorization request. The response from the payer must indicate whether the payer approves (and for how long) or denies the prior authorization request or requests more information from the provider to support the request. To support the implementation and maintenance of the Prior Authorization API, we are requiring certain standards and recommending certain IGs, as discussed elsewhere and in section II.G. of this final rule. With the publication of the HTI–1 final rule (89 FR 1192), our cross references to 45 CFR 170.215 have been updated to reflect the updated citations as needed. Changes to the structure of 45 CFR 170.215 and versions of the API standards codified there are discussed further in section II.G. of this final rule and reflected throughout this final rule. For the Prior Authorization API, impacted payers must use the following standards: HL7 FHIR Release 4.0.1 at 45 CFR 170.215(a)(1), US Core IG STU 3.1.1 at 45 CFR 170.215(b)(1)(i), and SMART App Launch IG Release 1.0.0 at 45 CFR 170.215(c)(1). Impacted payers are permitted to voluntarily use updated standards, specifications, or IGs that are not yet adopted in regulation for the APIs discussed in this final rule, should certain conditions be met. For the standards at 45 CFR 170.215 required for the Prior Authorization API, updated versions available for use under our policy include, but are not limited to, US Core IG STU 6.1.0 and the SMART App Launch IG Release 2.0.0, which have been approved for use in the ONC Health IT Certification Program.97 We refer readers to section II.G.2.c. of this final rule for a full discussion on using updated standards. We are also recommending payers use the CRD IG STU 2.0.1, HL7® FHIR® Da Vinci Documentation Templates and Rules (DTR) IG STU 2.0.0, and PAS IG STU 2.0.1. We refer readers to Table H3 for a full list of the required standards and recommended IGs to support API implementation. Comment: Many commenters supported the proposal to require impacted payers to implement and maintain a Prior Authorization API to improve automation of the prior authorization process. Many commenters stated that the API has the potential to support the needed transition to electronic prior authorization. Commenters also stated that the Prior Authorization API would 97 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. E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8862 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations reduce the burden for providers and speed up the prior authorization process for patients to improve care and access treatment options. A commenter stated that the API would offer much-needed transparency for rural providers around the prior authorization process. Other commenters stated that the API would potentially replace old ways of conducting the prior authorization process and give way to new ways of conducting prior authorization and explained that the prior authorization provisions laid out in the CMS Interoperability and Prior Authorization proposed rule could provide a good return on investment for payers. Multiple commenters supported CMS’s efforts to implement a standardized API that makes payers’ prior authorization and other documentation requirements electronically accessible to providers and that supports a more streamlined prior authorization request and response process. Multiple commenters believe this change will offer many benefits for patients and providers, including increasing access to care for patients and increasing providers’ understanding of prior authorization requirements by providing upfront information about which services require prior authorization and what type of documentation is required to support approval of a prior authorization request; and increasing automation in the submission, receipt, and processing of requests, which could support more timely responses. Commenters also stated that this automation will help decrease administrative costs and that the Prior Authorization API would improve the efficiency of providing services to patients due to the request and response being automated and in real-time, as well as the quality of patient care. A large group of commenters expressed their support for the proposed requirement for payers to implement the Prior Authorization API because it will make their physical therapy businesses more efficient and allow them to focus on treating patients. Response: We agree that these policies will serve to mitigate some of the burdens that exist in the prior authorization process today. This is the reason we are finalizing a modification to the compliance dates. Our proposal did not include a requirement for the Prior Authorization API to provide realtime processing of the prior authorization request, but we agree that incorporating a level of automation and facilitating electronic prior authorization processing could improve processing timelines in the future. Though we anticipate that some of the VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 responses or decisions potentially may be made in real-time, other decisions will continue to necessitate review and evaluation by clinical staff. The complete automation of a complex process such as prior authorization is an ongoing process of continuous improvement. Comment: Multiple commenters stated that the Prior Authorization API would not do enough to resolve existing issues surrounding prior authorization burden and turnaround times. A commenter stated that the amount of data to be transmitted and used by payers and providers through the API is burdensome and impractical. This commenter wrote that the continued transmission of medical information from non-FHIR systems (for example, administrative transactions) will require payers to translate such information into a format that is useable for the Prior Authorization API, which would only shift the manual prior authorization burden, not alleviate it. The commenter stated it is important to maintain industry flexibility around prior authorization to continue industry innovation in interactive decisionmaking processes with providers to ensure the best care experience possible for patients. Multiple commenters expressed concern that the required implementation of the Prior Authorization API might increase the burden for both providers and payers. A commenter expressed concerns that what time may be saved through the API may end up being redirected to maintain the API, field questions from patients and providers, and support external development when requests are incomplete, which may even require a dedicated team to answer provider questions throughout the electronic prior authorization lifecycle. This commenter provided insight into their experience with their current online portal and provider submissions of prior authorizations, and continued reliance on electronic faxes. A commenter expressed concerns that the maintenance of the API will also place significant burdens on payers to translate all coverage criteria to questions suitable for the electronic prior authorization process and to keep such information up to date. Another commenter also stated that the work involved in identifying all policies and authorization processes that would be included in the Prior Authorization API will be a significant effort as it will require significant resources, staff, and time. Response: We acknowledge concerns about the new technology and processes associated with the Prior Authorization PO 00000 Frm 00106 Fmt 4701 Sfmt 4700 API, including implementation challenges, potential conflicts with existing workflows, and increased workload for initially implementing the Prior Authorization API. Payers will need to identify the policies, conduct the analysis, and do the necessary programming for the next few years. Providers will also experience an initial implementation and data collection burden associated with translating records into FHIR-compatible formats. It is in part based on these considerations that we decided to modify our proposed compliance dates so that the impacted payers and providers alike will have sufficient time to conduct testing on the newly structured prior authorization process. We disagree with commenters who indicated that the Prior Authorization API would not do enough to resolve existing issues surrounding prior authorization burden and turnaround times, and with those who were concerned that the transmission of medical information from systems would shift the prior authorization burden to manual processes rather than alleviate it. The benefits of using an electronic prior authorization process improve the manual and burdensome process used today. Making the prior authorization process electronic will reduce the time and burden associated with the current process, allowing providers to put time back into direct patient care, and ultimately will reduce provider burnout. Once the Prior Authorization API is in place and a provider can connect to a payer’s system using that API, the manual effort for both payers and providers should decrease because clinical and administrative staff will be able to leverage the technology to conduct a more streamlined process for submitting prior authorization requests. Payers should be able to shift resources to review the requests more efficiently. While payers may have their policies documented, these are not in any standard formats, nor are they readable in any structured way. Providers must often download documents from different portals and then interpret them individually. The API will centralize and automate this process for both payers and providers. Further, we have included several significant policies that do not require API development or enhancement in this final rule, one of which relates to shortening the deadline by which impacted payers must respond to prior authorization requests from providers. The policies being finalized in this rule have been developed over time with input from providers, payers, and patients to address the technical E:\FR\FM\08FER2.SGM 08FER2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations lotter on DSK11XQN23PROD with RULES2 and operational issues described to us as the most significant issues in the prior authorization process. b. FHIR Implementation Guides In the CMS Interoperability and Prior Authorization proposed rule, we proposed to require the use of certain technical specifications (that is, IGs adopted as implementation standards) adopted at 45 CFR 170.215 (87 FR 76239). We also proposed that the same documentation requirements and discontinuation and denial of access standards as we proposed for the Patient Access API (discussed in section II.A.2. of this rule), the Provider Access API (discussed in section II.B.2. of this rule), and the Payer-to-Payer API (discussed in section II.C.3. of this rule) would apply to the Prior Authorization API. Additionally, for the Prior Authorization API, we specifically recommended using certain FHIR IGs that have been developed to support the functionality of the Prior Authorization API. These IGs are as follows: • The CRD IG • The DTR IG • The PAS IG These three IGs are designed to be used by the payer, or implementer, to develop and implement the Prior Authorization API. The IGs undergo regular development and testing to support implementation and use of the Prior Authorization API and to improve the API’s functionality in support of an improved prior authorization process. Technical information and website access are provided in section II.G. of this final rule. The first IG recommended for use to develop the Prior Authorization API is the CRD IG. As described on the HL7 web page, the CRD IG defines a workflow to allow payers to provide information about coverage requirements to providers through their clinical systems.98 Use of this IG improves the transparency of specific coverage rules specific to the patient and the provider based on the payer’s prior authorization policies, and, when implemented, provides decision support to providers when they are ordering services. This is the first stage of the process for determining whether authorization is required for certain items or services. The CRD IG provides the functionality to enable the API to inform the provider if a prior authorization is required, and information about the payers’ prior 98 Health Level Seven International (2024, January 8). Da Vinci—Coverage Requirements Discovery. Retrieved from https://www.hl7.org/fhir/ us/davinci-crd/. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 authorization coverage rules, so the provider knows what information is necessary to support a request. The functionality of the CRD may return a decision to the provider if there is sufficient information and the payer supports early determinations. The second IG recommended for use by payers to develop the Prior Authorization API is the DTR IG. On the HL7 IG web page, the description explains how this IG specifies how payer rules can be executed in a provider context to ensure that documentation requirements are met.99 This IG is a companion to the CRD IG. Its purpose is to automate the process of assembling documentation to support a prior authorization request for a specific payer. The instructions will allow the provider to download questionnaires and populate them automatically with information from the EHR or other systems for the completion of documentation requirements needed to demonstrate medical necessity for a proposed item or service, based on payer rules. The DTR IG enables the return of completed templates with specific FHIR resources identified as required to support the medical necessity of the service or item that is being requested for a prior authorization. This process replaces the need to manually request, gather, and submit documentation. The third IG recommended for the Prior Authorization API is the PAS IG. On the HL7 web page, the description explains that the PAS IG enables direct transmission of prior authorization requests (and can request/receive immediate authorization) from within EHR systems using the FHIR standard and that it can create the mapping between FHIR and HIPAA compliant X12 transactions.100 The PAS IG ensures that the API takes the information from the CRD and DTR and allows provider systems to send (and payer systems to receive) requests using FHIR. Providers and payers can still meet separate regulatory requirements, where required, to use the X12 278 transaction standard for prior authorization(s) to transport the prior authorization request and response. The PAS IG is the basis for: (1) assembling the information necessary to substantiate the clinical need for a particular treatment; and (2) submitting the assembled information 99 Health Level Seven International (2023, November 7). Da Vinci—Documentation Templates and Rules. Retrieved from https://www.hl7.org/fhir/ us/davinci-dtr/. 100 Health Level Seven International (2023, December 1). Da Vinci—Documentation Templates and Rules. Retrieved from https://www.hl7.org/fhir/ us/davinci-pas/. PO 00000 Frm 00107 Fmt 4701 Sfmt 4700 8863 and prior authorization request to an intermediary before it is sent to the intended recipient. As these IGs have been expanded and improved, the workgroup has enhanced the graphic display depicting the workflow and made it available on the HL7 website.101 Most importantly, use of the instructions from the IG and the API provides the necessary information about the status of the prior authorization request—the response indicates whether the payer approves (and for how long) or denies (and the reason) the prior authorization request, or requests more information from the provider to support the prior authorization request. The PAS IG also defines capabilities around the management of prior authorization requests, including checking on the status of a previously submitted request, revising a previously submitted request, and canceling a request. Section II.G. of this final rule provides additional discussion of both the required and recommended standards and IGs to support the Prior Authorization API. Comments regarding requiring versus recommending the IGs, maturity of the IGs, and technical implementation challenges are addressed in section II.G. of this final rule. For example, commenters recommended that the FHIR IGs should be required rather than recommended, as merely recommending the IGs would lead to an additional burden for both payers and providers as they may use varied implementations of the required APIs that would ultimately reduce interoperability. We also received multiple comments about technical implementation challenges and the maturity of the recommended IGs. Technical comments such as these are addressed in section II.G. Here we respond to the comments specific to the standards and IGs for implementation of the Prior Authorization API. Comment: Multiple commenters recommended that CMS and HL7 ensure the recommended CRD, DTR, and PAS IGs are fully tested before the effective date of the final rule, as the IGs have not been adequately or widely tested in realtime clinical settings. The commenter noted that these IGs have data elements and processes that are listed as optional despite their utility for automation. Another commenter cautioned that the IGs have several data elements and processes that are optional, which means payers could meet decision requirements with vague responses, 101 Health Level Seven International (2023, November 20). Da Vinci Coverage Requirements: Technical Background. Retrieved from https:// build.fhir.org/ig/HL7/davinci-crd/background.html. E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8864 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations hence jeopardizing CMS’s prior authorization reform goal. Multiple commenters supported using the PAS IG and stated that the IG is well-positioned to support the development of the proposed Prior Authorization API. A commenter noted that many of the proposed requirements are covered in the PAS IG STU 2.0.0, which is targeted for publication in calendar year 2023. The commenter continued by stating that based on functional requirements, additional updates can be made to the IG to ensure it fully supports the proposed Prior Authorization API once finalized in preparation for compliance in 2026. However, other commenters expressed some concerns about recommending these IGs. Multiple commenters noted that hospitals and insurers may need to use more than one technology solution to participate and track activity using the Prior Authorization API. A commenter expressed concern with the proposed IGs, which seem to require fast responses, within 5 seconds, and encouraged CMS to monitor technical standards as they are developed to avoid excessive burdens that the agency did not intend to create. Response: CMS is recommending the three IGs to implement the Prior Authorization API. These IGs, the CRD, DTR, and PAS IGs, were created to be used together to provide implementation flexibility. Several optional or ‘‘situational’’ elements were included in these guides as a means to connect them in a single workflow while allowing for the decoupling of these processes where necessary. For example, the CRD IG might be used to develop an API specific to prior authorization coverage requirements, and a separate API, linked to that one, built using the DTR IG. Some hospitals and providers will need more than one technology solution to connect to the payer’s Prior Authorization API endpoint based on the architectures and systems of the provider organization. Impacted payers and providers may have separate and unconnected systems that address coverage and eligibility, documentation, and prior authorization. Since publication of the CMS Interoperability and Prior Authorization proposed rule, updated versions of the CRD, DTR, and PAS IGs have all been published. We refer readers to Table H3 for the required standards and recommended IGs to support API implementation. In response to the specific comment about implementation strategies, we refer implementers to the HL7 Da Vinci workgroups for technical guidance; however, we understand that payers VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 may need to pull multiple technology solutions together to meet the overall Prior Authorization API requirements. Concerning the response time of 5 seconds, which is near real-time, we anticipate that most systems can accommodate this communication exchange when the information is available. The PAS IG has a recommended synchronous response time of 15 seconds. Instructions are available in the IG for how systems should respond in a timeframe with the best possible information. For further technical details, we encourage interested parties to reach out to the appropriate HL7 workgroups. Comment: Multiple commenters stated that there are potential technological challenges for the implementation of the Prior Authorization API. A commenter noted that the proposed rule does not specify what technology hospitals need to support or implement the API, nor what technology is needed to track participation or be required to participate in the API once finalized. This commenter noted that providers will be using the Prior Authorization API without any meaningful testing. Another commenter noted that they currently offer providers an option to submit electronic prior authorizations through an online portal, but utilization is low as most providers still favor fax as their preferred method to send prior authorizations, and portal prior authorizations often require corrections to incorrect data entries. Multiple commenters said CMS should do more to support the implementation of the Prior Authorization API. A commenter supported regulatory efforts to require payers to build APIs to automate prior authorization, but questioned whether the CMS Interoperability and Prior Authorization proposed rule goes far enough to accomplish that goal. Another commenter noted that the Prior Authorization API will require payers, providers, and vendors to connect but noted that multiple infrastructure challenges will have to be resolved to ensure API implementation success and cited the work of the HL7 FAST Accelerator to identify and address scalability issues to avoid duplication of efforts, including security and authentication. Response: The regulations we are finalizing in this rule require impacted payers to implement a Prior Authorization API, and providers are encouraged to use the technology in their CEHRT to take advantage of the improvements in prior authorization processes that will be available through PO 00000 Frm 00108 Fmt 4701 Sfmt 4700 use of the Prior Authorization API. As we noted in the proposed rule, HL7 launched an implementation division in 2021, specifically to provide support for implementers, including education and technical support. This division will provide payers, providers, and vendors with access to information about the types of technology and software that will address implementation, education, and testing of the standards, IGs, and APIs. Furthermore, the HL7 workgroups, which are open to the public, continue to be the best resources to learn about implementation. We will continue to work with associations, developers, and HL7 on identifying or supporting the development of appropriate resources for education. The HL7 FAST Accelerator is addressing the scalability issues of the FHIR standard through its work on security and the directory IGs. We and ONC participate in the HL7 FAST Accelerator and will monitor progress on the IGs being developed by that project. The policies in this final rule are an important component of the overall CMS strategic plan to reduce burden, advance interoperability, and improve patient care. This rule finalizes significant changes to improve the patient experience and alleviate some of the administrative burden by applying policies which address both technical and process barriers. These policies represent foundational regulatory steps toward addressing the longstanding challenges of prior authorization. Comment: A commenter, writing from the provider perspective, stated that the Prior Authorization API would complicate clinical and administrative workflows by requiring some combination of staff time and additional technological advances and recommended the FHIR API be combined with the HIPAA transaction standard. Response: We do not agree that using the Prior Authorization API will complicate clinical work. Rather, time will be saved across all personnel tasks, including researching the requirements for prior authorization across multiple payers, entering information into systems, submitting requests, processing approvals, or determining next steps if a denial is received. The Prior Authorization API is capable of conducting the prior authorization request as a FHIR only data exchange, or in combination with the HIPAA transaction standard. Comment: Multiple commenters urged CMS to name the CDex IG as one of the recommended IGs to use in support of the Prior Authorization API E:\FR\FM\08FER2.SGM 08FER2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations and stated that it is a critical part of burden reduction and plays an important role in supporting FHIR prior authorization transactions as proposed. To support the attachments for the Patient Access, Provider Access, and Payer-to-Payer APIs, as well as the supporting documentation requirements for the Prior Authorization API, this IG provides the instructions to enable the exchange of structured documents 102— meaning those which could be read and interpreted by a computer. This functionality to attach documents to support a prior authorization is currently missing from the other FHIR IGs and standards. A commenter stated that the PAS IG could support existing Federal and state requirements to exchange attachments if implementers also added the functionality of using the CDex IG. Use of this IG would further support efficiencies in the prior authorization process. Response: We are aware that early adopters have begun testing with the CDex IG for attachments to advance additional use cases for the Prior Authorization API. This final rule does not address standards for attachments and does not prohibit using the CDex IG or other attachment standards. lotter on DSK11XQN23PROD with RULES2 c. Implementation, Automation, and Other General Considerations for the Prior Authorization API and Processes We proposed and are finalizing requirements for impacted payers to implement a Prior Authorization API to improve the prior authorization process. The policy would require use of new standards for some impacted payers and some changes in procedures. We received comments on the use of new standards, technology, and automation with considerations for implementation and have grouped them here. Comment: A commenter stated that they support the proposed requirements for the Prior Authorization API; however, they believe much more needs to be done to achieve the CMS objectives for this policy. Multiple commenters shared potential concerns and challenges with the implementation of a Prior Authorization API. A commenter wrote that the Prior Authorization API use case will not work without provider participation, as the API requires bidirectional exchange 102 General comparison of structured versus unstructured documents: Structured documents are organized and fit into spreadsheets and relational databases. Structured documents often contain numbers and fit into columns and rows and are easily searchable. Examples are ICD-codes, Star Ratings, and other discrete data elements. Unstructured documents include traditional business files, word processing documents, presentations, notes, and PDFs. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 between impacted payers and providers. A commenter expressed concern regarding the resource development needed for providers and noted this needs to be more widely understood before the implementation of the Prior Authorization API. The commenter recommended CMS work with interested parties to ensure practices can utilize and leverage this API. The commenter encouraged CMS to work with ONC to extend the applicability of the Prior Authorization API requirements to providers and EHR vendors to ensure technical readiness and enable greater adoption of the Prior Authorization API and electronic prior authorization. A commenter suggested that CMS require plans to provide to each contracted physician, upon request and regardless of their use of the API, the references to the clinical research evidence that underlie medical policy determinations when they approve or deny a service. The commenter noted that some physicians may not be able to adopt these systems by the compliance dates. Response: We are finalizing compliance dates in 2027 for payers to implement the Prior Authorization API which should provide sufficient time for payers to implement the APIs, collaborate with EHR vendors to support appropriate connections for their providers, and develop outreach materials. Ongoing pilots demonstrate that payers and providers can implement the necessary infrastructure by those compliance dates. While providers are not required by this final rule to use the Prior Authorization API, in section II.F. of this final rule we are incentivizing providers to use this API by finalizing new electronic prior authorization measures for MIPS eligible clinicians under the MIPS Promoting Interoperability performance category and for eligible hospitals and CAHs under the Medicare Promoting Interoperability Program. To promote Prior Authorization API adoption, implementation, and use among MIPS eligible clinicians, eligible hospitals, and CAHs, we are adding a new measure titled ‘‘Electronic Prior Authorization’’ under the HIE objective in the MIPS Promoting Interoperability performance category and the Medicare Promoting Interoperability Program, beginning with the calendar year (CY) 2027 performance period/2029 MIPS payment year and CY 2027 EHR reporting period. There could be many benefits for providers for improvements in the prior authorization process, and we encourage all providers to evaluate whether use of the Prior Authorization PO 00000 Frm 00109 Fmt 4701 Sfmt 4700 8865 API could benefit their practices. Payers should also encourage providers in their network to use the Prior Authorization API, given that it could be timesaving for both parties, and we anticipate that many payers will begin education and awareness campaigns as more pilots are launched and/or payer APIs are readied for testing. We are monitoring the activities of existing pilots and receiving positive reports from participants. ONC may consider developing and making available additional criteria for EHR certification for electronic prior authorization in future rulemaking. We did not propose to specifically require payers to make available the references to the clinical research evidence that underlie medical policy determinations when they approve or deny a service, but we did propose that when an impacted payer denies a prior authorization request, the payer must include a specific reason for that denial in a notice to the provider who requested the prior authorization. See section II.D.3. regarding that proposal and the final policy. While we do not oversee contract provisions between payers and providers, the CY 2024 MA and Part D final rule (88 FR 22120) 103 finalized a new requirement at 42 CFR 422.101(b)(6) for MA plans to make certain information about their internal coverage policies publicly accessible, including a list of the evidence considered in developing the internal coverage criteria; that final rule also limits using internal coverage criteria for Part A and Part B benefits to when coverage criteria are not fully established in Medicare statute, regulation, NCD, or LCD. We anticipate this information, along with the requirement that MA plans provide a reason for denying a request for prior authorization (at 42 CFR 422.122 as adopted here and currently in existing 42 CFR 422.568(e)) will address the commenter’s concern about access to clinical research and evidence supporting denials of coverage in the MA program. In addition, the CY 2024 MA and Part D final rule adopted a new regulation, at 42 CFR 422.137, that requires a Utilization Management Committee to annually review the policies and procedures for all utilization management, including prior 103 See 88 FR 22120 through 22345 (April 12, 2023). Medicare Program; Contract Year 2024 Policy and Technical Changes to the Medicare Advantage Program, Medicare Prescription Drug Benefit Program, Medicare Cost Plan Program, and Programs of All-Inclusive Care for the Elderly. Retrieved from https://www.federalregister.gov/ documents/2023/04/12/2023-07115/medicareprogram-contract-year-2024-policy-and-technicalchanges-to-the-medicare-advantage-program. E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8866 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations authorization, used by the MA plan, and a new regulation at 42 CFR 422.138 that limits how prior authorization may be used by certain MA plans. Per 42 CFR 422.138, coordinated care MA plans (for example, Health Maintenance Organization [HMO], Preferred Provider Organization [PPO], and point-of-service [POS] plans) may only use prior authorization to confirm the presence of diagnoses or other medical criteria that are the basis for coverage determinations for the specific item or service and to ensure that the requested item or service is medically necessary (for Part A and B benefits) or clinically appropriate (for supplemental benefits). Finally, we remind readers that MA regulations at 42 CFR 422.202(b) and 422.136(a) require MA organizations to provide education and outreach about utilization management policies and engage in consultation with contracted providers. Comment: Multiple commenters discussed automating prior authorizations, and many were in support of automation, providing technological suggestions for automation of the prior authorization process. A commenter stated that, for prior authorization forms, specific clinical questions require answer formats that are easily understood and automated by a computer. Another commenter described how payers might automate the prior authorization process by utilizing existing matrices to create algorithms that would be able to review a large proportion of their prior authorization requests. A commenter noted that deep learning AI methods for submitted clinical data could be used to inform the review and electronic prior authorization approval process to expedite a decision that simulates a consensus of expert human judgment. Multiple commenters recommended that CMS explore automating service ‘‘bundle’’ prior authorizations for instances where one episode of care needs multiple prior authorizations (for example, a knee replacement surgery), as this would help ease administrative burden and reduce delays in patient care. Response: We are closely following the level of interest in the types of automation that might be brought to bear on the prior authorization process, particularly around the infrastructure for communications, and the innovative thinking shared in the public comments. While CMS did not directly address using AI for purposes of implementing the prior authorization policies, or any provisions of this final rule, we encourage innovation that is secure; includes medical professional judgment VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 for coverage decisions being considered; reduces unnecessary administrative burden for patients, providers, and payers; and involves oversight by an overarching governance structure for responsible use, including transparency, evaluation, and ongoing monitoring. We also reiterate that impacted payers must comply with Federal and state policies and the requirements of the standards and recommended IGs in implementing these APIs. We encourage these and other individuals to participate in the HL7 IG development groups to share these ideas with the drafters of the IGs to further refine their functionality. Comment: Multiple commenters recommended that CMS include additional requirements for payers. A commenter recommended that CMS require payers to offer their electronic prior authorization system at no cost to providers. Multiple commenters stated that health plans should be required to provide a web-based interface for providers and patients with a standardized, easy-to-use web page with an up-to-date database that quickly indicates whether prior authorization is required. The commenter stated that this web page should include prior authorization rules and medical policies. A commenter requested that the required response to the query on the online database include the following data points: transaction ID, group or member ID, date of service, prior authorization required, instructions, and a medical policy link. A commenter recommended that, in the case of a technical glitch with the prior authorization process, insurance plans should develop a backup system. Response: We did not specifically address whether payers could charge providers for use of or access to the Prior Authorization API. We would encourage payers not to charge additional costs beyond those that may exist to conduct prior authorization business functions today, including the costs of conducting transactions. We do not anticipate that fees would be charged for use of the API or other services required by this final rule, but are aware that payers will be funding their own development and vendor related costs. Concerning the specific functionalities commenters requested be available through portals, online systems, or the API, such as easy-to-use web pages with an up-to-date database that quickly indicates whether prior authorization is required or what the medical policies are, we reiterate that payers are required to implement a Prior Authorization API that allows a provider to query a payer’s system to PO 00000 Frm 00110 Fmt 4701 Sfmt 4700 determine whether a prior authorization is required, to identify documentation requirements, and to receive information about whether a specific prior authorization request has been approved or denied. As part of fulfilling these required functions, information about the policies and how they have been developed may be available, but we understand that the level of additional information and detail about the development of prior authorization and coverage policies could vary by payer. There may be other connected systems and resources available with information about the medical policies that are associated with the Prior Authorization API to which the provider will be able to refer to understand how decisions are being made for certain items and services. Furthermore, under existing Federal and state laws, such as the HIPAA Privacy and Security Rules, administrative, technical, and physical safeguards policies and procedures must be in place to ensure that systems have effective backup controls to protect access to patient data during planned and unplanned downtime. We would expect impacted payers to already have such procedures in place for reliable backup systems. Comment: Multiple commenters noted that payers will have to digitize their prior authorization policies to meet the Prior Authorization API requirements, which will be difficult and time-consuming. Multiple commenters noted that payers may be concerned that if a significant amount of their providers do not adopt the new prior authorization API process, the payer will not receive the full benefit of their investment. Response: We acknowledge that payers will have to digitize their prior authorization policies to meet the API requirements. Several organizations have implemented the Prior Authorization API as pilot projects or as part of the Da Vinci Exception Project, and we are aware that implementation of the API requires a significant investment of resources. We also recognize that the full benefit of the API will be achieved when providers use the API to request information about prior authorization requirements and change existing workflow patterns. The changes for both payers and providers will maximize the return on investment from the new electronic exchange. We encourage other impacted payers to engage with these early implementers to learn from their experience and to begin evaluating their policies to understand the level of effort that will be required within their organizations. To support E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations the analysis, implementation, and testing, we are also finalizing compliance dates that are a year later than we proposed to provide additional time for the necessary work to implement the Prior Authorization API and to conduct outreach and education to the provider community. Comment: A commenter recommended that CMS include a Prior Authorization API opt out policy and another commenter recommended that CMS explain providers’ responsibilities related to communicating patients’ right to opt out of the Prior Authorization API and their responsibility to notify the payer of that decision. Response: Prior authorization is an administrative process between a payer and provider that is conducted almost completely electronically today with no direct burden on the patient. We would anticipate that an individual who wishes to obtain medical services expediently might wish for their provider to use the most efficient resource available to them. The opt out/ opt in rules that we are finalizing in this rule are for the Provider Access and Payer-to-Payer APIs’ data exchange requirements, discussed in sections II.B. and II.C., and do not apply to the Prior Authorization API. While this final rule does require impacted payers to develop and implement the Prior Authorization API, this rule does not require providers to use the API. As discussed in section II.F., this final rule does include policies regarding using the Prior Authorization API for the Promoting Interoperability performance category of MIPS and the Medicare Promoting Interoperability Program. As many providers are currently conducting these processes through EHRs in the office, with the patient present, we would encourage providers to explain any activity to the patient, as is being done for any electronic transaction, including electronic prescribing, lab orders, and scheduling. We also anticipate that providers would want to use a process in which their EHR or other medical record systems are capable of connecting with the APIs and exchanging certain data and documents using FHIR standards. At a minimum, the Prior Authorization API will provide a means for providers to identify the prior authorization requirements for the impacted payers, which will save time and burden associated with having to research those requirements manually. We do not believe it is necessary to add a new opt out process for patients regarding prior authorization. These are administrative tasks already in place in provider offices. We reiterate that VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 providers are not required by this rule to use the Prior Authorization API. Comment: Multiple commenters discussed prior authorization criteria and specifically referenced the CY 2024 MA and Part D final rule for the enhancements it provides for prior authorization requirements. A commenter requested that CMS require payers to make their prior authorization criteria public in advance of the publication of this final rule and to ensure that physicians with expertise in the services are involved in their development. Other commenters requested that CMS ensure that prior authorization criteria be peer-reviewed. A commenter wrote that the Prior Authorization API will increase transparency into payer prior authorization criteria, and another noted that using an electronic data exchange could improve the accuracy of prior authorization determinations. A few commenters wrote that the solution to prior authorizations must include both an expedited prior authorization process as well as appropriate clinical decisionmaking, particularly with treatment guidelines supported by clinical evidence. Another commenter stated that the Prior Authorization API could specifically speed up the process of prior authorization for key treatments of gynecologic cancers. Commenters noted that the increased transparency will include better timing for responses and accuracy for treatment protocols subject to prior authorization. Response: We agree that if the API can enhance provider understanding of the requirements for requesting a prior authorization, a provider’s ability to submit a complete and accurate request electronically will be improved and the manual intervention needed to collect additional information reduced. This transparency in requirements and criteria should improve communication between payers and providers during the prior authorization process, which is a core element of the functionality of the Prior Authorization API. We also appreciate comments suggesting that prior authorization criteria should be peer-reviewed and include appropriate clinical decision-making information with treatment guidelines that are supported by clinical evidence. Use of such clinical evidence is helpful to reviewers when creating care treatment plans and evaluating prior authorization requests. We have also heard from many payer organizations that aligning with clinical guidelines is part of their process when establishing prior authorization criteria and we encourage this practice for all payers. We did not make specific proposals related to PO 00000 Frm 00111 Fmt 4701 Sfmt 4700 8867 developing prior authorization criteria, but acknowledge the value of such clinical involvement. We also note that the provisions in this final rule on prior authorization will work with several of the utilization management and prior authorization policies in the CY 2024 MA and Part D final rule to further CMS’s overall goals of improving prior authorization processes to serve the needs of payers, providers, and patients. We encourage readers to review that rule as well (88 FR 22120) to have a greater understanding of the limits on how MA organizations may use and implement prior authorization. Comment: Multiple commenters discussed the need for APIs to be integrated with EHR systems. A commenter expressed concern that current EHR systems will not be set up to accommodate the requirements of this rule. Another commenter noted that an obstacle to the effective implementation of the Prior Authorization API is the lack of standardized coding and structured data in provider EHRs to support adjudication of a prior authorization request. The commenter stated that it will be important for EHR clinical data to be standardized to successfully adjudicate prior authorization requests through API interfaces. Response: We appreciate comments about standardization and the need for providers and EHR system vendors to address consistency in the coding of medical records for interoperable data exchange. Such comments do not reflect a technical readiness issue for the Prior Authorization API or the standards but rather an industry readiness to meet the requirements to enable and automate prior authorization processes. Over the next few years, both provider management systems, as well as certified EHRs, will advance in their use of standards, data exchange, and connectivity. Implementation of a content standard at 42 CFR 170.213 (USCDI) for all data classes and data elements will support communication about medical records will reduce the variation in medical record coding, increase structured data, and support the ability for interoperable data exchange. The IGs that support the Prior Authorization API provide the framework for exchanging standard information between the payer and provider systems. We note that ONC previously sought comment on how updates to the ONC Health IT Certification Program could support electronic prior authorization through an RFI titled ‘‘Electronic Prior Authorization Standards, E:\FR\FM\08FER2.SGM 08FER2 8868 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations lotter on DSK11XQN23PROD with RULES2 Implementation Specifications, and Certification Criteria’’ (87 FR 3475), which appeared in the January 24, 2022, issue of the Federal Register. The Unified Agenda, current at the time of this final rule’s publication, includes an entry for a proposed rule from ONC entitled ‘‘Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability’’ (RIN 0955–AA06). The description indicates that this proposed rule aims to advance interoperability, including proposals to expand the use of certified APIs for electronic prior authorization.104 Comment: A few commenters recommended that CMS work with states to resolve conflicts between this rule and existing state regulations. A commenter noted that Arizona has recently enacted legislation and published guidance establishing a uniform prior authorization request form. The commenter expressed concern that potentially conflicting policies would create confusion and operational process challenges for QHP issuers on the FFEs and providers. Response: We are aware that many states are also attempting to improve prior authorization processes and have read the Arizona legislation HB 2621 from 2022 105 regarding using standard paper forms and electronic portals. We do not believe there is a conflict between those requirements and this final rule as the Prior Authorization API required by this final rule can support the various state required standardized forms for electronic submission of the prior authorization request. The AMA also provides a list of other state legislation designed to improve prior authorization processes, many of which support or enhance the provisions in this final rule, for example, by supporting the establishment of an electronic prior authorization process.106 Should a conflict present between state and Federal requirements, the general rule is that the regulated entity must comply with both requirements unless compliance with 104 Office of Information and Regulatory Affairs, Office of Management and Budget, Executive Office of the President. Reginfo.gov. Retrieved from https://www.reginfo.gov/public/do/ eAgendaViewRule?pubId=202304&RIN=0955AA06. 105 Office of the Director Arizona Department of Insurance and Financial Institutions (2022, January 3). Regulatory Bulletin 2022–01(INS). Retrieved from https://difi.az.gov/sites/default/files/ Prior%20Authorization %20Bulletin%20with%20forms%202022-01.pdf. 106 American Medical Association (2022). 2022 Prior Authorization (PA) State Law Chart. Retrieved from https://fixpriorauth.org/sites/default/files/ 2022-12/2022%20Prior%20 Authorization%20State%20Law%20Chart.pdf. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 one makes compliance with the other impossible; in such a situation, Federal law generally preempts state law in the absence of statutory direction otherwise. d. Implementation Timing Considerations In the proposed rule (87 FR 76290), we stated that we had considered proposing that the Prior Authorization API be implemented in a phased approach. However, we explained that we did not think a phased implementation strategy would reduce the burden on impacted payers or providers, but rather could increase burden during the initial implementation. We also explained that a phased approach could delay the availability of electronic prior authorization for certain items and services, which could in turn reduce the overall adoption of the Prior Authorization API by providers who do not see their specialties and services represented in the initial rollout of the available Prior Authorization API. We sought comment on whether to require payers to make prior authorization rules and documentation requirements available through the API incrementally, beginning in 2026. Additional comments and responses regarding the timing and deadlines for compliance with the Prior Authorization API and those policies that do not require API development or enhancement are discussed in sections I.B. and II.D.1. Comment: Some commenters supported a phased implementation of the Prior Authorization API to allow impacted payers sufficient time to build the API and recommended processes that would use the IGs in a staggered fashion rather than implementing the entire process for prior authorizations. Other commenters recommended a phased implementation based on the following order for the IGs: CRD IG first, DTR IG second, and PAS IG third. A commenter stated there are already states making plans to implement an electronic prior authorization process and suggested that a staggered approach could help to avoid unnecessary variation in implementations. A commenter stated that if CMS does not provide an explanation of terminology (such as ‘‘documentation’’) and specify IGs and common standards on time for the Prior Authorization API there may need to be a staggered approach for implementing the API. A commenter agreed with CMS’s observation that a phased implementation approach would still result in having to request and process prior authorization requests in at least two different manners for a provider working with the same PO 00000 Frm 00112 Fmt 4701 Sfmt 4700 impacted payer, which makes little sense given the difficulties in the current state to even get the HIPAA Referral Certification and Prior Authorization transaction adopted under HIPAA Administrative Simplification. Multiple commenters recommended a 3-year timeframe for phased implementation based on the specific/common services approach. A commenter recommended that instead of using a percentage criterion, CMS should use a 3-year timeframe with year 1 requiring authorization rules, year 2 adding rules to different specialty facilities, and year 3 adding the Prior Authorization API to specific services and care sectors. Response: As stated at the beginning of this section, we are finalizing a modification to our proposed compliance dates for the Prior Authorization API in 2027. We continue to believe, for the reasons outlined in the CMS Interoperability and Prior Authorization proposed rule and in our responses to comments on this issue, that mandating a phased approach is not necessary. Payers may choose to implement the IGs in a phased approach within their operations, as long as the API is fully functional by the compliance date. Each payer will evaluate the scope of work required to program their prior authorization requirements, build the rules and questionnaires, and develop appropriate testing. For those payers with extensive prior authorization requirements and less structured documentation policies for different benefit packages, the scope will be more significant. However, a phased approach will not change the scope of this work; the IGs provide the road map or instructions for implementation. Use of these guides will help payers determine the scope and level of effort required for the work that must be completed for system changes, as well as operational changes for their organizations. Comment: Multiple commenters stated the phased approach may result in inconsistent implementation and/or fragmentation when it comes to leveraging the Prior Authorization API, as different payers and providers may be at different stages of implementation. Multiple commenters stated that a phased approach could reduce adoption of Prior Authorization API by providers, particularly if certain items or services are listed in the initial rollout and others are not. A commenter noted that the slow and delayed rollout of the Prior Authorization API is unlikely to result in standardized, streamlined, electronic prior authorization experiences for physicians, clinicians, providers, and E:\FR\FM\08FER2.SGM 08FER2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations health IT vendors. Therefore, multiple commenters supported the full implementation of Prior Authorization API on January 1, 2026. Response: We thank commenters for affirming that a phased approach could result in inconsistent and fragmented implementation of the Prior Authorization API and reiterate that the decision to provide an additional year for implementation for all impacted payers was made to ensure that the organizations would have sufficient time for training, development, testing, and outreach to providers. lotter on DSK11XQN23PROD with RULES2 e. Existing Prior Authorization Standards: HIPAA Exceptions for Testing New Standards In the CMS Interoperability and Prior Authorization proposed rule, we explained that the X12 278 transaction standard (Version 5010) and NCPDP D.0 are the current standards for electronic prior authorization transactions, adopted by HHS under provisions of HIPAA. Many payers and providers do not use the HIPAA transaction standards, and instead use proprietary payer interfaces and web portals through which providers submit their requests, as well as phone calls or faxes to complete the process for a response. The prior authorization process remains inefficient and burdensome and creates service issues for patients. We provided findings from industry surveys and HHS reports about gaps in the current processes and standards for prior authorization. The Council for Affordable and Quality Health Care (CAQH) Committee on Operating Rules for Information Exchange (CORE) annual report, the CAQH CORE Index, includes data on health plan and provider use of HIPAA standard transactions, and as noted in the proposed rule (at 87 FR 76288), shows that prior authorization using the X12 278 transaction standard was the least likely to be supported by payers, practice management systems, vendors, and clearinghouse services.107 The 2021 report 108 showed an incremental increase in using the X12 278 transaction standard for prior authorization of 26 percent. CAQH 107 Council for Affordable and Quality Health Care (2019). 2019 CAQH Index: Conducting Electronic Business Transactions: Why Greater Harmonization Across the Industry is Needed. Retrieved from https://www.caqh.org/sites/default/ files/explorations/index/report/2019-caqhindex.pdf?token=SP6YxT4u. 108 Council for Affordable and Quality Health Care (2021). 2021 CAQH Index: Working Together: Advances in Automation During Unprecedented Times. Retrieved from https://www.caqh.org/sites/ default/files/explorations/index/2021-caqhindex.pdf. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 CORE published its 2022 report 109 in November 2022 with data showing that while medical plans’ adoption of the X12 278 transaction standard increased by two percentage points (to 28 percent), it was still low as compared to the other HIPAA transactions. We received many comments about the adopted HIPAA transaction standard and its intersection with the proposed rule and address applicable comments here. The provisions of this final rule will provide enhancements to the electronic prior authorization process overall. We are finalizing our proposal to require impacted payers to implement a Prior Authorization API that can provide the necessary data to support a payer’s use of electronic prior authorization processes. In the proposed rule, we referenced section 1104 of the Affordable Care Act, which amended HIPAA to require that HHS adopt operating rules for HIPAA standard transactions. ‘‘Operating rules’’ are defined at 45 CFR 162.103 as the ‘‘necessary business rules and guidelines for the electronic exchange of information that are not defined by a standard, or its implementation specifications as adopted for purposes of HIPAA Administrative Simplification.’’ Operating rules have not been adopted for the X12 278 transaction standard. The NCVHS reviews operating rules and advises the Secretary as to whether HHS should adopt them (section 1173(g) of the Act). The Secretary adopts operating rules through regulation in accordance with section 1173(g)(4) of the Act. In June 2022, CAQH CORE submitted revised and new operating rules to NCVHS for consideration. In June 2023, NCVHS sent a letter to HHS recommending adoption of revised operating rules for Eligibility & Benefits, Claim Status, and Payment & Remittance Advice transaction standards, as well as a Connectivity operating rule. In that letter, NCVHS recommended that HHS not adopt the proposed CAQH CORE Attachments Prior Authorization Infrastructure operating rule or the CAQH CORE Attachments Health Care Claims Infrastructure operating rule. NCVHS wrote that ‘‘[t]he need for these operating rules should be considered only after publication of a final rule adopting a health care attachments 109 Council for Affordable and Quality Health Care (2022). 2022 CAQH Index: A Decade of Progress. Retrieved from https://www.caqh.org/ sites/default/files/2022-caqh-indexreport%20FINAL%20SPREAD%20VERSION.pdf. PO 00000 Frm 00113 Fmt 4701 Sfmt 4700 8869 transaction standard under HIPAA.’’ 110 Should a future proposal or recommendation for adoption be submitted to HHS, we would evaluate the effect, if any, on the policies included in this final rule. After the publication of this final rule, CMS will continue to evaluate the impact of any NCVHS recommendation and any separate actions by HHS in that regard. We also noted in the CMS Interoperability and Prior Authorization proposed rule (87 FR 76289), that in March 2021, HHS approved an application 111 from an industry group of payers, providers, and vendors for an exception under 45 CFR 162.940 from the HIPAA transaction standards to allow testing of an alternative to the adopted HIPAA standard for prior authorization.112 The purpose of this exception is to test an automated exchange of a prior authorization request and response using only the FHIR standard and the FHIR IGs recommended in the proposed rule and included in this final rule. Under this exception, participants are testing the prior authorization exchange using a FHIR-to-FHIR exchange using the FHIR standard without using the X12 278 transaction standard. Preliminary findings suggest that this alternative standard can be used successfully to conduct the prior authorization request and response as end-to-end FHIR in a cost-effective, efficient way. Payer and provider groups have presented these preliminary findings in public forums. HHS provides information about requests for exceptions from standards to permit testing of proposed modifications on the HIPAA administrative simplification website.113 110 National Committee on Vital and Health Statistics (2023, June 30). NCVHS Recommendations on Updated and New CAQH CORE Operating Rules to Support Adopted HIPAA Standards. Retrieved from https://ncvhs.hhs.gov/ wp-content/uploads/2023/07/RecommendationLetter-Updated-and-New-CAQH-CORE-OperatingRules-June-30-2023_Redacted-508.pdf. 111 Da Vinci Project (2021, May 26). Da Vinci HIPAA Exception. Retrieved from https:// confluence.hl7.org/display/DVP/ Da+Vinci+HIPAA+Exception. 112 HHS provides information about requests for exceptions from standards to permit testing of proposed modifications on the HIPAA administrative simplification website. Centers for Medicare and Medicaid Services (2023, September 6). Go-to-Guidance, Guidance Letters. Retrieved from https://www.cms.gov/Regulations-andGuidance/Administrative-Simplification/ Subregulatory-Guidance/Go-to-Guidance-GuidanceLetters. 113 HHS website with information about § 164.940 (Exceptions Process and Guidance Letters): HHS provides information about requests for exceptions from standards to permit testing of proposed modifications on the HIPAA administrative E:\FR\FM\08FER2.SGM Continued 08FER2 lotter on DSK11XQN23PROD with RULES2 8870 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations Comment: Multiple commenters made statements about the HIPAA exceptions process (45 CFR 162.940) and described various burdens associated with it, including the application process, lack of clarity for the evaluation criteria, and the time for approval. Commenters noted the current exceptions process may serve as a barrier for the industry to take advantage of the opportunity to move interoperability forward and urged CMS to make it less burdensome to accelerate opportunities for entities to beta test new standards and approaches to more efficient data exchange. A commenter recommended that CMS work with HHS or other agencies to improve the HIPAA exceptions process such that it is less onerous and more flexible to facilitate innovation. Another commenter strongly urged CMS to eliminate the requirement for payers to request an exception to any of the HIPAA transaction and code standards. This commenter stated that Da Vinci member exceptions should be discontinued, and CMS should work with other government entities as needed to eliminate the requirement to obtain an exception from the HIPAA standard for organizations seeking to directly exchange data using the FHIR standard without X12 translation. A commenter requested that HHS develop an administrative process or ‘‘onramp’’ for states to request a HIPAA exception for this specific transaction that individual states could utilize at their discretion. Response: The opportunity to apply for an exception to test an alternative to an adopted standard is established in the HIPAA statute and implemented in regulation at 45 CFR 162.940. Although we appreciate these comments regarding the HIPAA exceptions process, they are out of scope of this rule. Comment: Many commenters stated that the CMS Interoperability and Prior Authorization proposed rule failed to address the limitations of the X12 278 transaction standard. Many others noted that current industry use of the X12 278 transaction standard is very low, noting it is complex and outdated, and thus mandating the conversion of FHIR to the X12 278 transaction standard serves no real value beyond compliance. A commenter discussed how the CAQH CORE Index report consistently reports that full automation for X12 standards for prior authorization lags far behind payment-related use cases. A simplification website. Centers for Medicare and Medicaid Services (2023, September 6). Go-toGuidance, Guidance Letters. Retrieved from https:// www.cms.gov/Regulations-and-Guidance/ Administrative-Simplification/SubregulatoryGuidance/Go-to-Guidance-Guidance-Letters. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 commenter noted that because of the low use of the X12 278 transaction standard, entities would have to develop an implementation process to complete a FHIR exchange just to convert it to an X12 278 transaction standard. Another commenter noted the industry will continue to have interoperability challenges around the Prior Authorization API capability due to a lack of uniformity if existing issues with the X12 278 transaction standard are not addressed. Multiple commenters requested that CMS consider certain flexibilities in implementation. A commenter recommended that CMS consider a floor versus ceiling approach in which the X12 standard is seen as the floor and a standard FHIR approach using the PAS IG is the ceiling. Multiple commenters recommended that CMS provide a waiver for the X12 278 transaction standard for payers that can implement end-to-end FHIR data exchange. A commenter requested that CMS grant such payers a safe harbor that provides an automatic waiver of the X12 278 transaction standard requirement. A commenter noted these waivers would preferably be automatic or minimally burdensome to obtain. Another commenter recommended CMS allow for exceptions to the requirement of converting Prior Authorization API messages to the X12 278 transaction standard in scenarios where there is no need for the receiving entity to pass along the prior authorization transaction to another system. A commenter sought guidance on whether CMS will consider payers that are not currently covered under the HIPAA administrative simplification exception of having prior authorizations sent through the PAS phase of the Prior Authorization API, translated into and out of the X12 278 transaction standard for an exception. A commenter requested clarification on whether CMS proposed that the Prior Authorization API can be used to transform the provision of a health care attachment into a valid X12 278 transaction standard for meeting HIPAA requirements or is suggesting that the Prior Authorization API provides an alternative basis to the proposed X12 278 transaction standard. Response: We appreciate stakeholder interest in using the FHIR standard to implement the Prior Authorization API. Unless an impacted payer is included in the current Da Vinci pilot to test an exception to the HIPAA transaction, that payer may be required to use the adopted HIPAA standard when implementing the API. Information on the Da Vinci pilot is available on the PO 00000 Frm 00114 Fmt 4701 Sfmt 4700 HL7 Da Vinci website.114 The participants in the pilot are testing the prior authorization API over 3 years and will report to HHS at the end of that time on such metrics as response time, ability to exchange supporting clinical information, integration into the provider’s workflow, reducing total provider/staff time to obtain prior authorization, flexibility of the standard, ability to provide a timely response, and more. The Prior Authorization API can support the submission of a prior authorization request itself, or provide data that can support the HIPAAcompliant X12 278 transaction standard, if used, for prior authorizations, which is then sent as a separate transmission between the providers and payers, either through a clearinghouse or through the provider’s practice management system. HL7 provides detailed workflows and graphical depictions of the API and the HIPAA transaction process.115 Finally, this final rule does not address health care attachments. Comment: A commenter noted that the lack of requirements for specific data elements with the X12 278 transaction standard for prior authorizations limits the value of that transaction standard and would affect the adoption of the API because providers would lack an efficient way to identify what critical information to include in a prior authorization request. Multiple commenters expressed concern regarding the functionality of the proposal to use the X12 278 transaction standard with the API, and another commenter noted that the X12 275 transaction standard for health care claims attachments does not allow for using FHIR, which creates concerns about the implementation of the Prior Authorization API. Another commenter stated that certain CAQH CORE operating rules to support HIPAA transactions were submitted to NCVHS for review and recommendation to HHS in 2023. These operating rules were specific to certain HIPAA transactions and included required documentation requirements. The commenter noted that the operating rules do not name an API documentation requirement, which is key to locating data in various formats. Finally, another commenter noted that the X12 and FHIR standards 114 Da Vinci Project (2021, May 26). Da Vinci HIPAA Exception. Retrieved from https:// confluence.hl7.org/display/DVP/ Da+Vinci+HIPAA+Exception. 115 Health Level Seven International (2023, December 1). Da Vinci Prior Authorization Support (PAS) FHIR: Use Cases and Overview. Retrieved from https://build.fhir.org/ig/HL7/davinci-pas/ usecases.html. E:\FR\FM\08FER2.SGM 08FER2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations do not currently share compatible coding for all the information that would need to be translated. Response: We appreciate the concerns commenters expressed regarding the ability to use the adopted X12 prior authorization transaction with the Prior Authorization API. Code mapping between the X12 standard and the FHIR IGs contains X12 standard proprietary information and will require a license for its use to support the X12 transaction. This mapping is available on the X12 website through the Glass online viewer 116 as HL7 does not publish an X12 mapping artifact. We also note that we did not propose in this rulemaking that the X12 275 transaction standard be required for use with the Prior Authorization API. That transaction was proposed for use in the HIPAA Standards for Health Care Attachments proposed rule (87 FR 78438),117 which has not yet been finalized. We reiterate that there are no operating rule requirements in the HIPAA Administrative Simplification rules (45 CFR part 162) applicable to the API required for use in this final rule, or, at this time, to the required HIPAAcompliant X12 278 transaction standard. Comment: Multiple commenters expressed support to CMS for proposing an electronic Prior Authorization API that uses the FHIR standard and IGs in addition to the adopted X12 278 transaction standard to conduct electronic prior authorization. Response: We appreciate commenter support for the policy that utilizes both FHIR and X12 transaction standards. The FHIR standard and IGs will be used to implement the Prior Authorization API while supporting compliance with the HIPAA administrative transaction standard. Comment: Multiple commenters requested support for their organizations that are ready and willing to exchange data using FHIR data and process standards instead of X12 standards. Other commenters recommended that CMS recognize FHIR data and process standards as a permitted option for standard transactions (that is, adopted in place of the X12 standards). These commenters noted that FHIR has increasingly become the de facto standard in health 116 X12. X12 (2023). Retrieved from www.X12.org. Archives (2022, December 21). Administrative Simplification: Adoption of Standards for Health Care Attachments Transactions and Electronic Signatures, and Modification to Referral Certification and Authorization Transaction Standard. Retrieved from https://www.federalregister.gov/documents/2022/ 12/21/2022-27437/administrative-simplificationadoption-of-standards-for-health-care-attachmentstransactions-and. lotter on DSK11XQN23PROD with RULES2 117 National VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 care since it was mandated as a standard in the implementation of the Cures Act. To further accelerate the FHIR standard and exchange of data via FHIR, commenters recommended that CMS work with other government entities to eliminate the need for the HIPAA exception requirement for organizations seeking to exchange data via FHIR directly without X12 transaction standard translation. Some commenters stressed the costs involved in having to comply with both a new set of standards and maintain a system for an outdated standard they were not using and for which they had already developed workarounds. Others suggested that CMS support both X12 and FHIR to meet market needs and innovation. The SDOs supported this approach, noting that the FHIR IG is written in such a way that if the requirement to use the HIPAA standard is removed, the structure is in place for a FHIR-only transaction. Response: We appreciate industry interest in moving towards using the FHIR standard and reiterate that the HIPAA standards are adopted by HHS. HIPAA covered entities may consider submitting comments regarding updates to those standards to the Secretary of HHS for consideration. Comment: Multiple commenters emphasized the importance of exploring the integration of real-time electronic prior authorization transactions into workflows as these could reduce payer costs. A commenter noted that this was also recommended in the 2020 ONC report: ‘‘Strategy on Reducing Regulatory and Administrative Burden Relating to the Use of Health IT and EHRs.’’ A commenter noted these could be used for medical services and medications that do not typically require large amounts of supporting documentation. Another commenter recommended that CMS adopt policies that support integration of electronic prior authorization into physicians’ practice workflows such as direct financial support for investments in compliant IT platforms, allowing physicians to access insurer APIs as they work towards full capability, and supporting flexible sources of documentation for prior authorization requests within the established framework. A commenter recommended the electronic prior authorization system be universal across all payers with information displayed in real-time, with no cost to clinicians or health systems. The commenter stated that research showed that switching to realtime electronic prior authorization could save more money and reduce the time a provider takes to complete a PO 00000 Frm 00115 Fmt 4701 Sfmt 4700 8871 transaction by 15 minutes on average. The commenter stated that improving prior authorization processes would benefit every actor in this transaction. Another commenter expressed the importance for CMS to acknowledge that real-time prior authorization should be the goal and that the standards and technology currently exist to implement real-time prior authorization for certain use cases. A commenter recommended that payers implement real-time determination by January 1, 2026, for Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs. Response: Many commenters discussed the potential the Prior Authorization API and policies in this final rule have for payers to make realtime decisions, particularly when integrated into both the payer and provider workflows; however, we did not propose a real-time decision requirement and are not finalizing such a requirement in this final rule. Though we anticipate that some of the responses or decisions may be made in real-time, we anticipate others will continue to necessitate review and evaluation by clinical staff. We agree that the automation of a complex process such as prior authorization will require continuous improvement. Furthermore, some cases will require manual review because of their complexity. Nonetheless, the overarching improvements in automation will be an improvement in what exists today. f. Federal Matching Funds for State Medicaid and CHIP Fee-for-Service Programs’ Expenditures on Implementation of the Prior Authorization API In section II.E. of this final rule, we discuss Federal matching funds for certain state Medicaid and CHIP FFS programs’ expenditures related to implementation of the Prior Authorization API (this was also addressed in the proposed rule at 87 FR 76291 and 76292). g. Medicaid Expansion CHIP In section II.E. of this final rule, we discuss implementation for states with Medicaid Expansion CHIP programs (this was also addressed in the proposed rule at 87 FR 76292). 3. Requirement for Payers To Provide Reason for Denial of Prior Authorizations and Notifications Throughout the Interoperability and Prior Authorization proposed rule at 87 FR 76292, we described opportunities for improvement with the prior authorization process, specifically E:\FR\FM\08FER2.SGM 08FER2 8872 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations lotter on DSK11XQN23PROD with RULES2 where better communication between payers and providers could mitigate confusion about the status of a prior authorization, particularly if it was not approved. This section addresses issues about the proposed and final policy for communication about prior authorization denials and existing requirements for notifications from impacted payers. a. Background on Providing a Reason for Denial of Prior Authorization Payers deny prior authorizations for different reasons, including because the payer does not consider the items or services to be medically necessary, the patient exceeded limits on allowable covered care for a given type of item or service, or documentation to support the request was missing or inadequate. When a payer provides a specific reason for a denial, a provider can take appropriate actions such as resubmitting the request with updated information, identifying alternatives for the patient, appealing the decision, or communicating the decision to the patient to enable the patient to consider other options or to appeal as well. Today, impacted payers send denials either electronically or through the mail, and the information provided varies substantially between payers. For denials sent using the X12 278 transaction standard, payers must use the codes from the external code set maintained by X12. For responses sent through portals, fax, or other means, payers may use proprietary codes or text to communicate denial reasons. The process is inefficient and unsatisfactory; and in general, providers do not have consistent direction on the next steps for a denied authorization. Our proposal for impacted payers to send a specific denial reason was one approach to address current inefficiencies. We proposed, and are finalizing in this final rule, that, beginning in 2026, impacted payers must provide a specific reason for denied prior authorization decisions, regardless of the method used to send the prior authorization request. As with all policies in this final rule, this provision does not apply to prior authorization decisions for drugs. This final policy is an effort to improve the communication about denials from an impacted payer in response to a request for a prior authorization through existing mechanisms, such as electronic portals, telephone calls, email, standard transactions, or other means. b. Denial Reason and Denial/Decision Codes Some payers subject to this requirement to provide a specific reason VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 for denied prior authorization decisions will also remain subject to existing requirements to provide notice to patients, providers, or both, with the specific reasons for the denial. In addition, for certain payers impacted by this final rule, existing communication requirements related to coverage decisions, notices of coverage decisions, and appeal processes, remain in effect for coverage decisions that are made as part of a prior authorization denial or approval. These requirements are not changed under this final rule. For example, before an MA plan may issue a prior authorization denial (or any other organization determination that is a denial) based on medical necessity, the decision must be reviewed by a physician or other appropriate health care professional with expertise in the field of medicine or health care that is appropriate for the services being requested, including knowledge of Medicare coverage criteria, per 42 CFR 422.566(d); this will apply to any denial of a prior authorization request, regardless of whether the Prior Authorization API has been used to request, check the status of, or communicate the decision on the prior authorization. Nothing in this final rule limits the scope of the MA regulation at 42 CFR 422.566(d) and it continues to apply to any prior authorization request and decision that is also subject to the policies being finalized in this final rule. Comment: Some commenters recommended that CMS define and provide examples for terms such as ‘‘approval,’’ ‘‘denial,’’ and ‘‘specific reason’’ concerning prior authorization denials in the final rule. Response: We are not adding regulatory definitions for these terms in this rule, as these terms are clear, frequently used in many contexts, and commonly used. For this final rule, these terms mean the following: • Approvals are when the payer authorizes coverage of items or services for which prior authorization has been requested. • Denials are the refusal by a payer to approve the prior authorization for a health care item or service. Denials, or rejection of a prior authorization, may result because the service was not considered medically necessary under the payer’s medical guidelines or the provider did not provide complete or accurate documentation to support the request. • A specific reason for denial could include reference to the specific plan provisions on which the denial is based; information about or a citation to coverage criteria; how documentation PO 00000 Frm 00116 Fmt 4701 Sfmt 4700 did not support a plan of care for the therapy or service; a narrative explanation of why the request was denied, and specifically, why the service is not deemed necessary or that claim history demonstrated that the patient had already received a similar service or item. Comment: Multiple commenters expressed their support for CMS’s proposal to require impacted payers to provide specific reasons for prior authorization denials, regardless of the mechanism used to submit the prior authorization request. Multiple commenters also specifically expressed support for requiring impacted payers to provide the reasons for denial as part of the information included in the Prior Authorization and Patient Access APIs. Similarly, commenters expressed support for CMS’s proposal to require impacted payers, particularly MA organizations, to give providers specific reasons for their prior authorization denials. Many commenters supported the proposal to require payers to include in the Prior Authorization API specific information about prior authorization requests, including the determination of approval (and for how long), determination of denial (with a specific reason), and a request for more information from a provider. Response: We appreciate the general support for the proposal to improve this aspect of the prior authorization process, specifically communication about prior authorization decisions and information about denials. Comment: Multiple commenters noted that requiring a reason for denials and public reporting of prior authorization metrics could help providers, patients, policymakers, and other interested parties understand the prior authorization process better. These commenters asserted that this increased transparency could improve providers’ submissions of prior authorization requests, ensure prior authorizations are based on the best medical evidence and guidelines, and allow patients to be better informed regarding their health care purchasing decisions. Response: We appreciate the many other comments we received in support of the proposals to require a reason for denials and public reporting and discuss other comments specific to those provisions later in this section. Specifically, we concur that the transparency of information will support communication between payers, providers, and patients. Comment: Multiple commenters recommended that CMS be more specific about which prior authorization decision information payers should E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations include as well as how they should provide this information. Specifically, multiple commenters recommended that CMS further specify the level of detail that impacted payers must provide about their reasons for denial. Other commenters recommended that the information payers provide regarding reasons for prior authorization denials include the policy on which the decision was based and the requirements for coverage assessed, including the standards used to determine medical necessity. The commenters recommended that CMS require that the reason for denial provided by payers include the clinical rationale and patient-specific evidence supporting the denial decision (that is, which specific criteria the patient did not meet). A commenter recommended that CMS require payers to provide the following with each prior authorization decision: whether the prior authorization adjudication was automatically adjudicated; whether statistical methods such as AI, machine learning, or other algorithms were used; and whether a human decision-maker was involved and the name and credentials of the employee. This commenter noted algorithms should be publicly accessible so that they can be examined for implicit bias. Another commenter recommended that CMS require impacted payers to provide a clinical rationale for prior authorization denials according to the national medical specialty society guidelines for peer-reviewed clinical literature. Multiple commenters recommended that CMS specify that impacted health plans must provide all the prior authorization decision and denial information in a form that is understandable and outlines specific steps for the provider, including any additional information the provider needs to provide to further support the request, a list of covered alternative treatments, and details regarding their right to appeal and the process for appeals. Response: In this final rule, we are requiring impacted payers to provide a specific reason to the provider when denying a prior authorization. The volume of comments in this area, as in other areas of these proposals, was indicative of the challenges providers face in obtaining specific information about prior authorization decisions and denials, and that payers face in providing adequate detail for the decisions they give back to a provider about a prior authorization denial, such that the provider can take appropriate action. The CMS Interoperability and VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 Prior Authorization proposed rule and this final rule do not directly address how prior authorization decisions are made, such as using AI, statistical methods, requirements for clinical decisions, or other algorithms, which are out of scope of this specific rulemaking. However, prior authorization decisions involving AI or other algorithmic systems must still comply with applicable requirements, including requirements around clinical decision-making and the finalized policy requiring communication of the specific reason for denial. This rule intends to ensure that payers provide better communication about denials than has been available to date. There are existing programmatic rules for some of the impacted payers that also address the content of a denial decision. MA organizations 118 are required to provide the specific reasons for the denial to their enrollees when an item or service is denied, along with certain other information (such as the ability to appeal the decision and how). CMS provides a standard form for MA organization use, which captures a specific and detailed explanation of why the medical services were denied, including a description of the applicable coverage rule or applicable plan policy (for example, Evidence of Coverage provision) upon which the action was based, and a specific explanation about what information is needed to approve coverage if applicable. For Medicaid managed care prior authorization decisions, 42 CFR 438.210(b) requires the MCO, PIHP, or PAHP contract with the state to include provisions requiring the Medicaid managed care plan to consult with the requesting provider when appropriate and that any decision to deny a service authorization request or to authorize a service in an amount, duration, or scope that is less than requested, be made by an individual who has appropriate expertise in addressing the enrollee’s medical, behavioral health, or long-term services and supports needs. The regulation at 42 CFR 438.210(c) requires notice (albeit not necessarily written notice) to the provider of the Medicaid managed care plan’s denial of a service authorization request, or decision to authorize a service in an amount, duration, or scope that is less than requested. For Medicaid FFS, 42 CFR 435.917(a) requires state Medicaid agencies to provide the beneficiary with timely and adequate written notice of any decision regarding the beneficiary’s prior authorization request, as any such decision would cause a ‘‘denial or change in benefits 118 See PO 00000 42 CFR 422.568(e). Frm 00117 Fmt 4701 Sfmt 4700 8873 and services.’’ 119 When a state denies the prior authorization request in whole or in part, the beneficiary notice must include, in addition to the content described at 42 CFR 435.917, the notice content described at 42 CFR part 431, subpart E, including the requirement at 42 CFR 431.210 that notices contain a clear statement of the specific reasons supporting the intended action. Notices must be written in plain language and be accessible to individuals who have limited English proficiency and individuals with disabilities consistent with 42 CFR 435.905(b). These existing provisions, which include a requirement for enrollees to be provided written notice about an adverse decision, could be useful examples for the level of specificity that could be given to a provider, including the applicable medical necessity criteria. Likewise, for CHIP managed care entities’ prior authorization decisions, 42 CFR 457.1230(d) cross references to 42 CFR 438.210 to apply Medicaid managed care plans’ prior authorization decision requirements to CHIP managed care entities. Additionally, for QHP issuers on the FFEs, 45 CFR 147.136(b)(2)(ii)(E) and 29 CFR 2560.503–1(g) and (j) require group health plans and issuers of group and individual health insurance coverage to provide notice to individuals, in a culturally and linguistically appropriate manner, of adverse benefit determination or final internal adverse benefit determination and specifies information that this notice must include, such as a description of the plan’s or issuer’s standard, if any, that was used in denying the claim. When denial information is sent to a provider by any communication method, including existing notices, the content of a denial should be sufficiently specific to enable a provider to understand why a prior authorization has been denied and what actions must be taken to re-submit or appeal. This requirement would improve the current processes and reduce manual effort and costs. When implemented, the Prior Authorization API could mitigate some denials by providing information about the documentation and information or data necessary to support a prior authorization request for the service or item. Comment: Multiple commenters recommended that CMS work with X12 and other appropriate industry organizations to update the X12 278 Service Decision Reason Code Set with additional codes for scenarios not yet covered by the existing code set or for 119 See E:\FR\FM\08FER2.SGM 42 CFR 435.917(a). 08FER2 lotter on DSK11XQN23PROD with RULES2 8874 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations use of the X12 Service Decision Reason Codes as the code set for communicating reasons for the denial. The X12 Service Decision Reason Code List is a code set maintained by X12 used by HIPAA covered entities with the HIPAA standard transaction for electronic prior authorization decisions. A commenter supported using denial codes under the condition that CMS continue to work with SDOs, NCVHS, and other relevant organizations to expand the denial reasons and add support for more specific options. Another commenter requested clarification on whether the specific reason for the denial requirement must be met by using the X12 code list of denial reasons. The commenter added that this code list allows varying interpretations which would result in ambiguity. Other commenters recommended that CMS establish a clearly defined standardized set of specific reasons for the denial and require payers to use them for communicating prior authorization decisions for all items and services. A commenter recommended that CMS align the FHIR Certification Action Codes and the X12 Service Decision Reason Codes. Another commenter stated that the HCR 03 Decision Reason Code is an optional field in the X12 278 transaction standard and recommended that CMS refer to ‘‘denial reasons’’ as ‘‘decision reason codes.’’ Response: We confirm that the X12 Service Decision Reason Code List is a code set maintained by X12 for electronic prior authorization decisions. Updates to this code set must be requested through the X12 code maintenance workgroup. We strongly encourage both impacted payers and providers to evaluate the X12 Decision Reason Code List and make recommendations to X12 for necessary updated or new codes as appropriate. We encourage interested organizations and SDOs to continue their collaboration efforts on crosswalks needed for the IGs supporting the Prior Authorization API and maintenance of code sets that could be used with the API. We decline to change the terminology in this final rule from ‘‘reason for the denial’’ to ‘‘decision reasons’’ or ‘‘decision reason codes.’’ The obligation under this final rule for impacted payers to provide a specific reason for the denial of a prior authorization request goes beyond using a single code set and means that payers must provide sufficient detail in the denial response to enable the provider to know what action to take as the follow-up to the denial to obtain VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 coverage—that is whether to appeal, submit additional documentation, or identify alternative treatment options. Impacted payers may send additional information through the API which could provide additional clarity. Finally, though the Medicare FFS program has a list of decision reason codes in use for its program, and these could be considered for inclusion in the X12 code set, we did not propose these for use by all payers as part of this policy. However, the industry could submit similar text to X12 as additions to that external code set. We affirm that all denial reasons must be specific. Comment: Multiple commenters shared concerns about and made recommendations related to MA organizations’ utilization management policies as these pertain to the denial of prior authorizations. Response: This rulemaking does not address requirements or limitations for all utilization management guidelines or policies used by MA organizations. This rulemaking adopts certain procedural and timing requirements for prior authorizations and several API requirements for MA organizations and other impacted payers, including implementation of a Prior Authorization API, new reporting to CMS, and new requirements to provide to the applicable provider a specific reason for the denial of a request for prior authorization. However, in separate rulemaking for MA organizations, we addressed standards and requirements for how MA organizations develop and use clinical criteria and prior authorization policies to help ensure MA beneficiaries receive the same medically necessary care they would receive under Traditional Medicare in the CY 2024 MA and Part D final rule (88 FR 22120).120 We recommend interested readers review the CY 2024 MA and Part D final rule for more information on these other requirements for MA organizations. Comment: Many commenters described challenges with denials, including the burdens they faced when attempting to appeal those denials on behalf of their patients and delays created in access to care when they did not have information about the reason for the denial, and therefore little information to include in the response back to the payer. Multiple commenters wrote that requiring impacted payers to provide reasons for prior authorization denials would have positive impacts on the health care system. Multiple commenters stated that this requirement 120 See also 42 CFR 422.101(b)(6), 422.112(b)(8), 422.137, and 422.138. PO 00000 Frm 00118 Fmt 4701 Sfmt 4700 would facilitate better transparency and communication between providers and payers. Commenters noted that this requirement would: (1) allow providers to better communicate the reason for denial and reasons for potential treatment plan changes to their patients; (2) provide patients with more insight into how decisions are made relating to access to care; (3) decrease the number of arbitrary prior authorization denials and minimize the number of denials that are overturned on appeal; and 4) reduce unnecessary delays in patient care. Response: We appreciate the many letters from commenters indicating support for the provisions of this rule and including in those letters descriptions of the process challenges that they believe could be mitigated by the policies being finalized. We concur with the information in many of the letters that the requirement to provide the specific reason for the denial in a response to the provider has the potential to improve communication between payers and providers for the prior authorization process. c. Existing Notice Requirements To Communicate Prior Authorization Denial Information—By Program Some of the impacted payers are required by existing Federal and state laws and regulations to notify providers or patients when the payer makes an adverse decision on a prior authorization request. Our proposals to impose requirements on payers to communicate certain information to providers about prior authorization denials were intended to reinforce and supplement existing Federal and state requirements and do not alter or replace existing requirements to provide notice to patients, providers, or both. Further, the requirements include implementation of a Prior Authorization API that can provide responses about whether an authorization request has been approved (and for how long) or denied, a specific reason for the denial, or request more information from the provider to support the prior authorization. Communicating denial reasons with specific information, in addition to the existing program notification requirements, will increase transparency, reduce burden, and improve efficiencies for both payers and providers. The API requirements have compliance dates in 2027. i. Denial Notice Requirements This section of the final rule addresses denial notice requirements which will remain in place for MA organizations, CHIP FFS, Medicaid E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations managed care plans, and CHIP managed care entities. Under the MA program, the actions that constitute an ‘‘organization determination’’ include a prior authorization decision (as well as a decision in response to a voluntary preservice request for a decision on coverage), as it is defined as including an MA organization’s refusal to provide or pay for services, in whole or in part, including the type or level of services that the enrollee believes should be furnished or arranged by the MA organization as well as other types of decisions about coverage and payment.121 Existing MA program regulations impose requirements as to the form and content of the written notice to enrollees in the event of a partial or full denial. For example, existing regulations regarding written notices for enrollees for standard organization determinations require that notice for any denial by the plan of coverage of an otherwise covered service or item must— • Use approved notice language in a readable and understandable form; • State the specific reasons for the denial; • Inform the enrollee of their right to a reconsideration; • Describe both the standard and expedited reconsideration processes, including the enrollee’s right to, and conditions for, obtaining an expedited reconsideration and the rest of the appeal process; and • Comply with any other notice requirements specified by CMS.122 Under existing requirements,123 if the MA organization expedites an organization determination, the MA organization must notify the enrollee (or the enrollee’s representative) and the physician involved, as appropriate, of its decision, whether adverse or favorable, as expeditiously as the enrollee’s health condition requires, but no later than 72 hours after receiving the request. Either an enrollee or a physician, regardless of whether the physician is affiliated with the MA organization, may request that an MA organization expedite an organization determination.124 The notice of expedited determination must state the specific reasons for the determination in understandable language and if the determination is not completely favorable to the enrollee, the notice must also— 121 See 42 CFR 422.566(b). 42 CFR 422.568(e). 123 See 42 CFR 422.572. 124 See 42 CFR 422.570. • Inform the enrollee of their right to a reconsideration; • Describe both the standard and expedited reconsideration processes, including the enrollee’s right to request, and conditions for obtaining an expedited reconsideration, and the rest of the appeal process; and • Comply with any other requirements specified by CMS as to the content of the notice.125 Because applicable integrated plans (D–SNPs that have exclusively aligned enrollment with an affiliated Medicaid MCO) are a type of MA plan, the regulations regarding prior authorization processes that we are finalizing apply to them. The final rule revises the specific timeframes for prior authorization decisions by applicable integrated plans. Applicable integrated plans cover both Medicaid long term services and supports and MA benefits in ten states. Existing requirements already govern denial notices issued by applicable integrated plans to their enrollees and are similar to the Medicaid managed care and MA rules described in the prior paragraphs.126 Integrated organization determination notices must be written in plain language, available in a language and format that is accessible to the enrollee, and explain— • The applicable integrated plan’s determination; • The date the determination was made; • The date the determination will take effect; • The reasons for the determination; • The enrollee’s right to file an integrated reconsideration and the ability for someone else to file an appeal on the enrollee’s behalf; • Procedures for exercising an enrollee’s rights to an integrated reconsideration; • The circumstances under which expedited resolution is available and how to request it; and • If applicable, the enrollee’s rights to have benefits continue pending the resolution of the integrated appeal process. As with the notices required from MA plans, our finalized policies do not change the content requirements for these written denial notices to enrollees but will supplement these notices by requiring applicable integrated plans to notify the provider of the reason for a denial of a prior authorization request. For Medicaid managed care plans and CHIP managed care entities, existing regulations at 42 CFR 438.210(c) require 122 See VerDate Sep<11>2014 18:23 Feb 07, 2024 125 See 126 See Jkt 262001 PO 00000 42 CFR 422.572. 42 CFR 422.631. Frm 00119 Fmt 4701 Sfmt 4700 8875 notice to the provider without specifying the format or method, while 42 CFR 438.210(c) and 438.404(a) require written notice to the enrollee of an adverse benefit determination. In addition, 42 CFR 438.210(c) requires notice (albeit not necessarily written notice) to the provider as well of the Medicaid managed care plan’s denial of a service authorization request or decision to authorize a service in an amount, duration, or scope that is less than requested. CHIP managed care entities are required to comply with similar standards at 42 CFR 457.1230(d) (referencing 42 CFR 438.210) and 457.1260(c) (referencing 42 CFR 438.404). Nothing in this final rule will limit the existing enrollee notification requirements at 42 CFR part 438 for Medicaid managed care plans and at 42 CFR part 457 for CHIP managed care entities as these requirements will remain in full effect. This final rule fills a potential gap concerning the information communicated to providers regarding a denial of a prior authorization request. We proposed and are finalizing that the response— whether the authorization request has been approved (and for how long), denied (with the reason for the denial), or a request for more information to support the prior authorization—if transmitted to providers via the Prior Authorization API workflow process or other means, will be sufficient to satisfy the current requirement for notice to providers at 42 CFR 438.210(c) and 457.1230(d). We are finalizing a slight modification to the regulatory language to use ‘‘the date or circumstance under which the authorization ends’’ instead of ‘‘how long’’ as the scope of information that must be provided by the payer. The payer will not be required to send the response to the provider via both the Prior Authorization API (which is required to furnish certain information, including denial reason) and a separate, additional manner (for example, separate written notice or phone call) with duplicate information. However, given that providers are not required to use the Prior Authorization API, the payer must ensure that the response to the provider with the reason for the denial must be furnished to the provider through some means. We also remind all Medicaid managed care plans and CHIP managed care entities subject to this final rule that their existing obligations to provide these required notices to patients are not changed by the final policies in this rule. These payers will still have to E:\FR\FM\08FER2.SGM 08FER2 8876 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations lotter on DSK11XQN23PROD with RULES2 provide a separate written notice to the enrollee. QHP issuers on the FFEs that offer individual health insurance must provide the specific reason for an adverse benefit determination, which includes denial of prior authorization.127 Furthermore, plans and issuers must ensure that notice is made to individuals in a culturally and linguistically appropriate manner that complies with existing requirements.128 Finally, impacted payers may be required to provide this information in languages other than English, which requires impacted payers (as health programs or activities under that section) to provide meaningful access to individuals with limited English proficiency and accessibility requirements for individuals with disabilities.129 ii. Notice and Payer Communications We received comments on the current processes for notice and payer communications and summarize those and our responses here. Generally, such processes exist for MA organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs. Comment: Multiple commenters expressed frustration with the variation of prior authorization requirements across MA plans, inconsistencies in access to care and coverage, and painful interactions during lengthy peer-to-peer review of medical necessity assessments with MA organizations. A commenter expressed support for the proposal in the CY 2024 MA and Part D proposed rule (87 FR 79452) to prohibit MA plans from diverting a patient to a different level of care than recommended by the patient’s physician when the patient otherwise meets all the clinical criteria appropriate for the setting requested by the physician. Commenters noted these factors have contributed to a more complicated prior authorization process, extended wait times, duplicate or inaccurate prior authorization denials and post-claim denials, and a shifting focus from patient care. Multiple commenters recommended CMS implement increased oversight policies to address MA’s challenging prior authorization landscape. Multiple commenters recommended that CMS continue to oversee MA plans’ use of prior authorization and advance policies that ensure that MA enrollees have the same access to covered services as those 127 See 45 CFR 147.136(b)(3)(ii)(E). CFR 147.136(b)(2)(ii)(E) and 29 CFR 2560.503–1(g) and (j). 129 See 45 CFR 92.3 and 92.101. 128 See VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 enrolled in Traditional Medicare and that MA organizations cannot use more stringent criteria than Traditional Medicare. Response: As finalized in the CY 2024 MA and Part D final rule, 42 CFR 422.138 provides that coordinated care plan prior authorization policies may only be used to confirm the presence of diagnoses or other medical criteria and/ or ensure that an item or service is medically necessary. Second, the CY 2024 MA and Part D final rule requires coordinated care plans to provide a minimum 90-day transition period when an enrollee currently undergoing treatment switches to a new MA plan, during which the new MA plan may not require prior authorization for the active course of treatment (42 CFR 422.112(b)(8)(ii)(B)). Third, to ensure prior authorization is being used appropriately, we are requiring all MA plans that use utilization management policies (like prior authorization) to establish a Utilization Management Committee to review policies annually and ensure consistency with Traditional Medicare’s NCDs, LCDs, and guidelines; compliance with limits on how prior authorization can be used; compliance with other MA regulations on determining medical necessity (42 CFR 422.101(c)); and consultation with network providers (42 CFR 422.202(b) and 422.137). Finally, to address concerns that the CY 2024 MA and Part D proposed rule did not sufficiently define the expected duration of ‘‘course of treatment,’’ a newly adopted regulation at 42 CFR 422.112(b)(8) requires that a coordinated care MA plan’s approval of a prior authorization request for a course of treatment must be valid for as long as medically necessary to avoid disruptions in care in accordance with applicable coverage criteria, the patient’s medical history, and the treating provider’s recommendation. The CY 2024 MA and Part D final rule and this final rule taken together provide significant guardrails for prior authorization in the MA program and support a more streamlined process, which will ultimately lead to reduced burden in health care. Comment: A commenter was concerned that without specific guidance for MA plans regarding certain benefits, the proposed rule will negatively impact the already existing barriers to electronic exchange of information between MA organizations and religious nonmedical health care institution (RNHCI) providers. This commenter supported the concept of the Prior Authorization API because it makes possible the electronic exchange PO 00000 Frm 00120 Fmt 4701 Sfmt 4700 of certain prior authorization information between payers and providers, which RNHCIs have long desired. However, the organization was concerned about the requirement at 42 CFR 422.122(b) because of concerns about its applicability to nonmedical benefits. This commenter proposed amendments to the regulatory text regarding the obligation to accept and exchange information. Response: The requirements proposed at 42 CFR 422.122(b) apply to all covered Medicare services, including covered items and services furnished by a RNHCI, and all MA supplemental benefits covered by an MA plan, excluding all drugs, as defined at 42 CFR 422.119(b)(1)(v). See section I.D. for more information about the exclusion of drugs from the scope of the prior authorization policies in this rule. We are finalizing that the prior authorization requirements adopted in this final rule supplement and do not replace requirements in other applicable laws, including existing requirements for MA plans, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs regarding decisions made on requests for prior authorization of covered benefits. For additional explanation on the continued applicability of existing standards in this final rule, we are adding paragraph (b)(5) to 42 CFR 422.122 to explain that prior authorization decisions made under 42 CFR 422.122 must meet all other applicable MA requirements in subpart M of part 422, such as the adjudication timeframes and notice requirements. Under existing standards for Medicaid managed care plans, all prior authorization decisions by Medicaid managed care plans must comply with 42 CFR 438.210 as well as notice requirements at 42 CFR 438.404. 4. Requirements for Prior Authorization Decision Timeframes and Communications a. Impact of Delays in Prior Authorization Decisions: Background of Decision Timeframes As discussed in the CMS Interoperability and Prior Authorization proposed rule (87 FR 76294), CMS learned through listening sessions and other public meetings that excessive wait time for prior authorization decisions could cause delays to patient care and create medical risks in some cases. Providers face delays for the approval of the initial request, or, secondarily, for the resolution of a request ‘‘in process,’’ often meaning the payer is reviewing requested documentation. In 2019, CMS E:\FR\FM\08FER2.SGM 08FER2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations conducted outreach to external entities (87 FR 76294) and received many comments about timeframes for processing prior authorizations, where commenters explained that the process of securing approvals for prior authorization directly affects patient care by delaying access to services, including transfers between hospitals and post-acute care facilities, treatment, medication, and supplies. Commenters believed that these delays occur partly because payers have different policies and review processes, do not use available technologies consistently, and continue to rely on manual systems such as phone, fax, and mail, which are more labor-intensive. lotter on DSK11XQN23PROD with RULES2 b. Standard and Expedited Prior Authorization Requests and Decision Timeframes In the CMS Interoperability and Prior Authorization proposed rule we used the terms standard and expedited prior authorizations to refer to two types of prior authorizations for which we are now finalizing our policies—in this final rule, we affirm that the term ‘‘standard’’ prior authorization refers to non-expedited, non-urgent requests and the term ‘‘expedited’’ prior authorization indicates an urgent request. These terms continue to be used in CMS regulations.130 We received a few comments on these terms and respond to those here. Comment: Multiple commenters stated that there was a lack of clarity and guidance on the definition of a standard versus an expedited prior authorization. A commenter recommended that CMS create additional specificity around what ‘‘expedited’’ means, especially for mental health and substance use disorder conditions. Another commenter stated that what one provider may deem an expedited request may not be considered one by the payer. A commenter noted that the lack of a standard definition leads to discrepancies on what a payer considers ‘‘urgent’’ and sometimes leaves some discretion up to the provider. This lack of standardization can adversely affect a patient. If a payer has a stricter definition of what constitutes an expedited prior authorization, this could lead to the patient waiting up to 7 days for a decision and delay access to care further if prior authorization is denied. Commenters stated that CMS should release guidance on definitions 130 See 42 CFR 422.568, 422.570, 422.572, and 422.631 for MA organizations and applicable integrated plans and 42 CFR 438.210(d) and 438.404 for Medicaid managed care plans. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 of these terms to facilitate more alignment for payers and strengthen patient access by minimizing variation between network standards on what is considered ‘‘urgent’’ versus ‘‘normal.’’ Another commenter requested that CMS provide clarification on timeframes in emergencies and if emergency care would override prior authorization rules. Response: We decline to create a new definition for standard and expedited, as the definitions for standard and expedited requests provide a foundation upon which both payers and providers can rely for making professional judgments. These terms are used in the provisions at 42 CFR 422.568, 422.570, 422.572, and 422.631 for MA organizations and applicable integrated plans. Similar terms are used at 42 CFR 438.210(d) for Medicaid managed care plans, at 42 CFR 457.1230(d) for CHIP managed care entities (87 FR 76294), and we are adding requirements at 42 CR 440.230 for Medicaid FFS and at 42 CFR 457.495 for CHIP FFS to meet these timelines—specifically, as expeditiously as a beneficiary’s health condition requires, that may not exceed either 7 calendar days or 72 hours after receiving the request for standard or expedited requests respectively. A standard for when expedited determinations are required currently exists for MA organizations at 42 CFR 422.566(a), which requires MA organizations to have an expedited procedure for situations in which applying the standard procedure could seriously jeopardize the enrollee’s life, health, or ability to regain maximum function.131 This long-standing medical exigency standard is familiar to MA plans and providers and affords sufficient guidance on when an expedited decision is necessary. There is adequate guidance on these standards for the MA appeals and organization determination deadlines already. For Medicaid managed care and (by cross reference) CHIP managed care, 42 CFR 438.210(d)(2)(i) specifies an expedited authorization is required when ‘‘following the standard timeframe could seriously jeopardize the enrollee’s life or health or ability to attain, maintain, or regain maximum function.’’ Standard prior authorization requests are used when the enrollee’s life or health or ability to attain, maintain, or regain maximum function are not seriously jeopardized by the managed care plan using the longer, standard authorization timeframes. These policies are intended to ensure that impacted payers, including Medicaid 131 See PO 00000 42 CFR 422.570 and 422.572. Frm 00121 Fmt 4701 Sfmt 4700 8877 FFS, Medicaid managed care plans, and CHIP managed care entities will evaluate expedited prior authorization review procedures that will minimize patient risk. We confirm that MA plans, Medicaid managed care plans, and CHIP managed care entities are prohibited from applying prior authorization requirements to evaluation and stabilization services for emergency medical conditions.132 Comment: A commenter asserted that eliminating the need for a provider to reach out to a payer and notify them of a request that requires an expedited response would reduce a provider’s administrative burden and further the efficiency of the prior authorization process. The commenter recommended CMS request that payers be required to have systems that enable providers to electronically differentiate between standard and expedited prior authorization requests. Response: While this final rule addresses several important prior authorization processes, it does not specifically dictate all payer operational procedures. Existing regulations in the applicable programs covered by this final rule may address the circumstances under which a payer must make a coverage decision, such as a prior authorization request on an expedited basis. For example, under the MA rules at 42 CFR 422.570, an enrollee or a physician (regardless of whether the physician is affiliated with the MA organization) may request that an MA organization expedite an organization determination involving a request for an item or service. The MA organization must promptly decide whether to expedite an organization determination. Under the rules at 42 CFR 422.570(c)(2), if a request is made by an enrollee, the MA organization must provide an expedited determination if it determines that applying the standard timeframe for making a determination could seriously jeopardize the life or health of the enrollee or the enrollee’s ability to regain maximum function. If a request for an expedited decision is made or supported by a physician, the MA organization must provide an expedited determination if the physician indicates that applying the standard timeframe for making a determination could seriously jeopardize the life or health of the enrollee or the enrollee’s ability to regain maximum function. The existing medical exigency standard related to expedited requests will continue to 132 See sections 1852(d), 1932(b)(2), and 2103(f)(3) of the Act and 42 CFR 422.113, 438.114, and 457.1228. E:\FR\FM\08FER2.SGM 08FER2 8878 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations apply to organization determinations that involve prior authorization. The recommended PAS IG may not currently have the instructions to provide the capability to differentiate between standard and expedited prior authorization requests. However, this data element could be a helpful addition for the next version, and interested parties are encouraged to discuss this at an HL7 workgroup meeting. There may be other means through the payer’s Prior Authorization API to determine how an indicator for the type of prior authorization request might be incorporated. The current version of FHIR includes a required data element to indicate the urgency of a request. In FHIR technical terminology, this required data element is named ‘‘claim.priority.’’ However, there is no equivalent value in the HIPAA X12 278 transaction standard or the X12 external code lists because that data element is not required in that standard. The PAS IG does not provide any mapping to X12. For those entities conducting the end-to-end FHIR exchange, the information about expedited and standard prior authorization requests is available to them through the FHIR claim.priority data element. As noted, the X12 278 transaction standard does not include this information because the current version of the X12 278 transaction standard for prior authorizations does not support this concept. An alternative to using the claim.priority data element when using the X12 278 transaction standard for expedited requests would be to include a service date, to indicate urgency. lotter on DSK11XQN23PROD with RULES2 c. Decision Timeframes for Standard and Expedited Prior Authorization Requests To improve patient care outcomes and ensure that patients have more timely access to services, we are finalizing our proposals to create, improve, or shorten prior authorization timeframes for certain payers to respond to prior authorization requests for covered items and services, excluding drugs. Specifically, we are finalizing that these timeframes would be 72 hours for expedited requests, unless a shorter minimum timeframe is established under applicable state law,133 and 7 calendar days for standard requests with the possibility of an extension to up to 14 days in certain circumstances. We 133 The final policies adopted here for state Medicaid and CHIP FFS programs and Medicaid managed care plans and CHIP managed care entities at 42 CFR 438.210 and 457.495(d)(2), respectively, include that a state may set a shorter timeframe for these decisions. However, such state authority does not apply to MA plans operating in these states. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 acknowledged that some of the payers affected by this final rule had different requirements for prior authorization decision notice and appeal timeframes, and we are aligning the prior authorization decision timeframes across those payers except for QHPs on the FFEs, as further discussed. For some payers, the existing regulation already uses the timeframe we are adopting in this final rule for standard or expedited requests for prior authorization; those regulations will continue to apply while amendments to adopt the new timeframes for other payers will apply to their prior authorization decisions, beginning in 2026. In the CMS Interoperability and Prior Authorization proposed rule (87 FR 76295), we provided a chart identifying which regulations we proposed to modify the decision timeframes for standard prior authorization decisions made by MA organizations and applicable integrated plans, CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities.134 Table E1 at the end of this section provides the final Federal requirements for prior authorization decision timeframes that will apply to each payer beginning in 2026. We did not propose to change any existing timeframes that might apply to expedited authorization decisions made by any of the impacted payers, especially given that many of these payers already apply a 72-hour maximum timeframe for such requests. To ensure consistency and correctly describe the new timeframes being finalized for these payers to provide notice of standard determinations, we proposed and are finalizing certain conforming amendments to the CFR sections listed in Table E2. QHPs are not included in the policy on timeframes for the reasons described at the end of this section. Note that these timeframes do not apply to any drugs, as discussed in section I.D. of this final rule. We proposed that beginning January 1, 2026, MA organizations and applicable integrated plans must provide notice of prior authorization decisions as expeditiously as a patient’s health condition requires, but no later than 7 calendar days for standard requests. For MA organizations, on or after January 1, 2026, prior authorization requests for items and services covered by the finalized requirements at 42 CFR 422.122 will be affected by this final rule; for all other items and services, existing timeframes 134 See 42 CFR 422.570, 422.572, 422.631(c) and (d)(2)(iv)(A), 438.210(d)(2), and 457.1230(d). PO 00000 Frm 00122 Fmt 4701 Sfmt 4700 under the MA regulations for other preservice requests for an organization determination would remain applicable. These deadlines are reflected in amendments to 42 CFR 422.568(b)(1) (for MA plans) and 422.631(d)(2)(i) (for applicable integrated plans). We proposed and are finalizing conforming amendments to certain regulations that reference or describe the timeframes that are being amended in this final rule. Specifically, we proposed and are finalizing an amendment to the MA program regulation at 42 CFR 422.570; the revision replaces references to the specific length of the timeframe for standard decisions with a general reference to 42 CFR 422.568 which we are also amending to include the new timeframe(s) for prior authorization decisions for items and services. In addition, this final rule does not change existing Federal timeframes for expedited and standard determinations on requests for Part B drugs for MA organizations and applicable integrated plans; current regulations require notice to the enrollee as expeditiously as the enrollee’s health condition requires, but no later than 72 hours after receiving the request for a standard determination and as expeditiously as the enrollee’s health condition requires, but no later than 24 hours after receiving an expedited request.135 Due to the finalized revisions to 42 CFR 422.568(b), we are redesignating existing 42 CFR 422.568(b)(2) related to requests for Part B drugs for MA organizations to 42 CFR 422.568(b)(3). Furthermore, an MA plan must automatically transfer a request to the standard timeframe if the MA plan denies a request for an expedited organization determination or an applicable integrated plan denies a request for an expedited integrated organization determination.136 This step to automatically transfer expedited requests to the standard timeframe is consistent with Medicaid and CHIP managed care provisions listed in Tables E2, E3, and E4. As there are no existing CMS regulations imposing timeframes for state Medicaid FFS programs to provide notice of prior authorization decisions, in the proposed rule we specified that these programs must provide notice of such decisions as expeditiously as a patient’s health condition requires, but no later than 72 hours for expedited requests and 7 calendar days for 135 See 42 CFR 422.568(b)(3), 422.572(a)(2), and 422.631(a). 136 See 42 CFR 422.570(d)(1) and 422.631(d)(2)(iv). E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations standard requests unless a shorter minimum timeframe is established under state law. For CHIP FFS, existing regulations require states to provide prior authorizations within 14 days or according to existing state law, in accordance with the medical needs of the beneficiary. Also, a possible extension of up to 14 days may be permitted if the beneficiary requests the extension or if the physician or health plan determines that additional information is needed.137 To align with Medicaid, we are finalizing for CHIP FFS that beginning in 2026, states must provide notice of prior authorization decisions in accordance with the medical needs of the beneficiary, but no later than 7 calendar days after receiving the request for a standard determination and by no later than 72 hours after receiving the request for an expedited determination. For Medicaid managed care plans and CHIP managed care entities, we proposed, and are now finalizing, to change the maximum permitted timeframe for the payer to send notices of prior authorization decisions as expeditiously as a patient’s health condition requires, but no later than 7 calendar days for standard requests beginning with the first rating period that starts on or after January 1, 2026. We are also finalizing requirements for Medicaid managed care plans and CHIP managed care entities concerning the timeframes for prior authorization of services (under 42 CFR 438.210 and 457.1230) but not the timeframes for issuing notices of other adverse benefit determinations and appeals under 42 CFR 438.404(c)(1) and (2) and 457.1260. The provisions at 42 CFR 438.210(d)(2)(i) and 457.1230(d) require Medicaid managed care plans and CHIP managed care entities to make an expedited authorization decision no later than 72 hours after receipt of the request if the provider requesting the authorization indicates that following the standard timeframe could seriously jeopardize the beneficiary’s life or health or ability to attain, maintain, or regain maximum function. If Medicaid managed care plans or CHIP managed care entities deny an expedited request, that request becomes standard and must be reviewed within 7 days. State law or managed care plan contracts may impose a shorter timeframe for these decisions in Medicaid and CHIP; the shorter timeframe would govern for state Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP 137 See 42 CFR 457.495(d). VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 managed care entities, as applicable.138 If state law imposes a longer timeframe, payers must comply with Federal regulations within the shorter Federal timeframe—which will automatically make them compliant with their state regulations. For this reason, we are adding to the Medicaid managed care regulations at 42 CFR 438.210(d)(2)(i) and (d)(1), respectively, and CHIP managed care regulations at 42 CFR 457.1230(d), respectively, that the decision must be made as expeditiously as the enrollee’s condition requires but no later than 72 hours in the case of expedited requests or 7 calendar days in the case of standard requests unless a shorter minimum timeframe is established under state law. State laws do not apply to MA plans, based on the preemption provision in section 1856(b) of the Act and at 42 CFR 422.402, which provides that the Federal standards established for MA plans supersede any state law or regulation, other than state licensing laws or state laws relating to plan solvency, with respect to the MA plans that are offered by MA organizations. This final rule does not change the 72hour timeframe required by current Federal regulations, or the authority for an extension of that timeframe, for expedited decisions made by MA organizations and applicable integrated plans, Medicaid managed care plans, and CHIP managed care entities. For the reasons discussed in the CMS Interoperability and Prior Authorization proposed rule, we are not requiring that impacted payers approve a request for prior authorization if that payer did not meet the required standard or expedited decision timeframe (87 FR 76297). If a payer fails to meet the timeline for approval or other decision, providers should contact the payer to obtain the status of the request and determine if supporting documentation is needed to complete the processing of the authorization or if there are other reasons for the delay in a decision. Some programs, such as the MA program (and including applicable integrated plans) and the Medicaid and CHIP managed care programs, have regulations that include provisions for the failure to provide timely notice of an organization determination; generally, such a failure to meet the timeframe constitutes an adverse decision that may be appealed.139 The final rule does not change timeframes for prior authorization 138 In addition, States may, by contract, require applicable integrated plans to use shorter decision timeframes. See 42 CFR 422.629(c). 139 See 42 CFR 422.568(f), 422.631(d)(1)(ii), 438.404(c)(5), and 457.1260(b)(3). PO 00000 Frm 00123 Fmt 4701 Sfmt 4700 8879 processes for QHP issuers on the FFEs, in part because existing regulations at 45 CFR 147.136 establish internal claims and appeals processes, external review processes, and pre-service claims requirements for all non-grandfathered group and individual market plans or coverage. Specifically, individual health insurance issuers are required to meet minimum internal claims and appeals standards.140 The current regulations for group health plans and group and individual market health insurance issuers adequately protect patient interests. QHP issuers on the FFEs are required to provide notification of a plan’s benefit determination within 15 days for standard authorization decisions and within 72 hours for expedited requests, which is consistent with the other CMS payers affected by this provision. We requested comments on the timeframe proposals and provide the summarized comments and responses here. Comment: Multiple commenters disagreed with the proposal to exclude QHP issuers on the FFEs from prior authorization shortened decision timeframe requirements and recommended that CMS reconsider the exclusion of these payers. Some commenters expressed concern that excluding QHP issuers on the FFEs from shorter prior authorization decision timeframe requirements would result in a negative effect on patient care. Commenters asserted that patients under these plans should be entitled to the same protections as others under this regulation. A commenter stated that they did not believe that shortening a QHP issuer on the FFEs’ decision timeframe from the current 15-day response time for standard requests to 7 days would pose an undue burden. Another commenter encouraged CMS to work to align prior authorization notification requirements across all impacted payers as this could avoid confusion amongst patients and providers regarding whether a patient is covered by a QHP. Multiple commenters wrote that CMS should include QHP issuers on the FFEs in regulations requiring even shorter prior authorization decision timeframes: 24 hours for urgent or expedited requests and 72 hours for standard requests. A commenter recommended CMS impose a standard of 24 hours for expedited requests and 48 hours for standard requests and specified that this standard should apply to all payers, including those on the Exchanges. However, multiple commenters supported the 140 See E:\FR\FM\08FER2.SGM 45 CFR 147.136(b)(3). 08FER2 lotter on DSK11XQN23PROD with RULES2 8880 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations proposal to leave in place the current prior authorization decision timeframes applicable to QHP issuers on the FFEs. These commenters raised general concerns about payer burden due to expedited timeframes and agreed specifically that applying expedited timeframes to QHP issuers on the FFEs could harm consumers by reducing participation by QHP issuers on the FFEs. A commenter recommended that timeframes be measured with business days as opposed to calendar days. Response: We discussed in the CMS Interoperability and Prior Authorization proposed rule the reasons why we did not propose to change timeframes for prior authorization processes for QHP issuers on the FFEs. We did not propose and are not finalizing, any changes to prior authorization timeframes for QHP issuers on the FFEs, in part because existing regulations at 45 CFR 147.136 establish internal claims and appeals processes, external review processes, and pre-service claims requirements for all non-grandfathered group and individual market plans or coverage. Specifically, individual health insurance issuers are required to meet minimum internal claims and appeals standards.141 We believe the current standard adequately protects patient interests. QHP issuers on the FFEs are required to provide notification of a plan’s benefit determination within 15 days for standard authorization decisions and within 72 hours for expedited requests; thus, QHP issuers on the FFEs have the same timeframe for expedited authorization decisions as other impacted payers in this final rule. For reasons discussed in this section, we are not finalizing any timeframes shorter than 72 hours for expedited requests for any impacted payers at this time. Additionally, the benefits for the patient of a shorter timeframe for standard prior authorization decisions should outweigh the additional burden that QHP issuers on the FFEs might experience, as compared to offExchange plans. Aligning timeframe requirements for prior authorization decisions across individual and group market plans would reduce the burden of compliance for QHP issuers on the FFEs for the proposed prior authorization requirements while continuing to protect consumer interests. Finally, making changes to regulations applicable to all nongrandfathered group and individual market plans or coverage for consistency with the proposed approach was outside the scope of the proposed rulemaking. While we are finalizing this rule as 141 See CFR 147.136(b)(3). VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 proposed, the prior authorization information that this final rule requires QHP issuers on the FFEs to publicly report per 45 CFR 156.223(c) will help provide insight into prior authorization timelines and practices that may support further improvements in the future. Comment: Multiple commenters supported the revised standard prior authorization decision timeframe of 7 calendar days, and many commenters supported the 72-hour decision timeframe for expedited prior authorization requests. Additionally, a commenter requested clarification on whether the 7-day standard decision timeframe would be calendar days or business days. A commenter recommended counting the turnaround time in business days rather than calendar days because processing prior authorization requests requires careful evaluation by payers and a review process that is dependent on working days as opposed to calendar days. Defining the turnaround timeframe by calendar days limits the time needed by payers to accurately reach a decision and is further reduced during holidays. This commenter suggested providing a timeframe that aligns with the number of working hours a payer has to evaluate a request and suggested CMS provide 7 business days. The commenter indicated that such an approach aligns with turnaround times for HIPAA transactions and would therefore prevent confusion over using both calendar days and business days. Another commenter recommended that the proposed standard be reduced from 7 days to 72 hours, stating that tracking timelines using hours instead of days will preclude any confusion or ambiguity regarding calendar days or business days. Response: We reiterate that current regulations are specific to using hours for expedited requests and we are not modifying the terminology for that requirement of 72 hours for expedited requests. For example, if a prior authorization request is submitted at 1:00 a.m. on Sunday, a response within 72 hours would mean by 1:00 a.m. on Wednesday. The regulations do not contemplate delays based on business hours or business days. For standard prior authorization requests, the current regulations (that is, before the amendments made by this final rule) for MA plans and Medicaid and CHIP managed care programs use the term ‘‘calendar days,’’ in recognition of health care services being agnostic of business days. The amendment we proposed and are finalizing for standard prior authorization decisions is ‘‘7 PO 00000 Frm 00124 Fmt 4701 Sfmt 4700 calendar days.’’ This final rule applies to the business process of the prior authorization request and decision, and not the transmission of the HIPAA standards when used for the request. Comment: Multiple commenters recommended having shorter decision timeframes that are less than 7 calendar days for standard prior authorization requests, ranging from 5 days, 72 hours, 48 hours, and 24 hours. Some commenters also suggested that decisions be made in real-time. In general, commenters recommended that CMS create faster prior authorization response timelines to improve the patient experience and access to care. Response: We are finalizing a requirement that prior authorization decisions be rendered as expeditiously as the patient’s condition requires, but no later than 7 calendar days requires impacted payers to render their decision based on patient-specific information within 7 calendar days (or shorter if otherwise required via contract or state law) being the maximum. Further, as discussed in the proposed rule, we did not propose to change timeframes for prior authorization processes for QHP issuers on the FFEs, in part because existing regulations at 45 CFR 147.136 establish internal claims and appeals processes, external review processes, and we believe the current standard adequately protects patient interests.142 We will continue to review these comments and the supporting information to determine how we might incorporate such policies in future rulemaking as part of our ongoing mission to improve the patient and provider experience. Comment: Another commenter indicated that timely approvals for discharge to an appropriate setting of care are paramount to delivering highquality care. The commenter explained that inappropriate and lengthy delays in payer responses to requests for transfers to post-acute care settings put patient care at risk. Specifically, the commenter explained that in nine percent of cases, the delay is caused by an untimely response from a payer. The commenter stated that while that percentage may seem low, it accounted for over 20,500 patient encounters across the commenter’s system in 2022. Response: We agree that timely response to such requests can impact patient care, and thus we are finalizing policies to reduce prior authorization decision timeframes. We also encourage payers to review their procedures for this and other similar cases to determine where process improvements would be 142 See E:\FR\FM\08FER2.SGM 87 FR 76297. 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations appropriate to prevent such delays within their own organizations and provider relationships. Comment: A commenter stated that ensuring appropriate review timeframes to make decisions for patients is critical to avoiding mistakes in care and that accelerated review timeframes increase the risk of failed or non-optimal therapies. A commenter wanted CMS to maintain the current 14-day decision timeframes for standard requests in Medicaid managed care. Another commenter suggested that CMS remove the proposal to shorten prior authorization turnaround timeframes until the Prior Authorization API is implemented and the agency can reevaluate whether the policy is necessary and then re-issue a proposal. Multiple commenters had concerns about shortening the prior authorization timeframes. Several state commenters expressed concern that they will neither have the staffing capacity nor the operational efficiencies to implement the prior authorization timeframes by the compliance date. Some commenters noted that state legislative approval will be needed to increase state staffing or adjust vendor contracts, requiring additional time to implement. Some commenters also noted that states will need to evaluate and overhaul their entire prior authorization processes to attain the operational efficiencies needed to achieve the shortened decision timeframes. Response: We thank the commenters for their concerns about accuracy in making decisions about prior authorizations, but that utilization management techniques and other professional safeguards are in place to mitigate such concerns. As we stated in the CMS Interoperability and Prior Authorization proposed rule, shorter prior authorization timeframes will improve patient care, reduce burden, and improve equity (87 FR 76297). The volume and substance of other comments support our proposals to shorten certain existing timeframes, and thus we are finalizing our proposal as described in this final rule. When the Prior Authorization API is implemented in 2027, this resource should further improve efficiencies in the process. We recognize the unique challenges some state commenters shared concerning the practical ability to implement the new prior authorization timeframes in state Medicaid and CHIP FFS by January 1, 2026. We understand that states often require longer timeframes to create new positions, adjust procurement arrangements, and rework system processes. We are willing to work with state Medicaid and CHIP FFS programs VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 that may be unable to meet the new compliance date for the prior authorization timeframes. States should contact their Medicaid state lead or CHIP project officer before April 1, 2025, to discuss their extenuating circumstances. Any flexibility granted to a state Medicaid or CHIP FFS program for the implementation of the new prior authorization decision timeframe requirements will be temporary and limited to the unique circumstances of the program. Comment: A commenter stated that providers and health plans have multiple exchanges of information back and forth, including additional medical documentation and patient-specific information before a final determination. The commenter noted that the currently proposed decision timeframes do not account for these situations as most requests often require additional information from providers. The commenter also stated that these requirements, in combination with a lack of required information about the data content, could unintentionally increase the number of denials. Multiple commenters stated that shorter timeframes would mean an increase in staff and administrative resources and that without enough time there could be an increase in denials. Response: We also acknowledge that additional staff resources may be necessary. Firstly, the Prior Authorization API could mitigate communication and staffing issues, once it is fully implemented, but acknowledge that additional staff may be necessary during the implementation process. Also, the focus on process improvement overall may lead to improved efficiencies as payers address opportunities to reduce inefficiencies and meet the requirements of the final rule. Furthermore, the requirement to provide a specific reason for denials, regardless of the method of the prior authorization, should also support improvements in communication between health plans and providers. By making the documentation requirements clearer through the API, providers should submit more complete and appropriate documentation in the first submission, thus enabling quicker processing and fewer denials. Additionally, for Medicaid managed care plans at 42 CFR 438.210(d)(1) and for CHIP managed care entities through an existing cross reference at 42 CFR 457.1230(d), we are finalizing (with slight redesignations from current regulations) a provision that permits standard authorization decisions to have an extension of up to 14 additional calendar days (to the 7-calendar day PO 00000 Frm 00125 Fmt 4701 Sfmt 4700 8881 timeframe) if the enrollee or the provider requests the extension or if the managed care plan justifies a need for additional information and how the extension is in the enrollee’s interest. Medicaid managed care plans have been able to utilize a 14-calendar day extension since 42 CFR 438.210(d)(1) was first promulgated in 2001 (66 FR 43670). We believe this provides sufficient time for managed care plans and providers to complete the needed information exchange and enable the managed care plan to render its decision. Similarly for CHIP FFS, we are finalizing our policy at 42 CFR 457.495 to allow for a possible extension of up to 14 days if the enrollee requests the extension or if the physician or health plan determines that additional information is needed to furnish a prior authorization decision. Comment: A commenter suggested that CMS convene a multi-stakeholder panel of health professionals and payer representatives to determine an appropriate timeframe for prior authorizations. Response: We do not agree that a multi-stakeholder panel of health professionals and payer representatives is necessary to determine an appropriate timeframe for prior authorizations. CMS has conducted surveys and listening sessions for nearly a decade, as have professional associations. Results are consistent for challenges of timeframes, with the consensus that this issue must be addressed. While some states have additional requirements for decision timeframes, they are not the same across the country. This final rule establishes policies for most of the programs over which CMS has authority to provide consistent and aligned structure for providers and payer communications on this important matter. To continue the conversation with another panel would further delay implementing these important changes that provide the opportunity for improving access to care and ensure that the industry collaborates on a solution to a critical problem that has widespread consensus. CMS will evaluate these reduced timeframes over time to see if future changes are needed, and may at that time conduct additional stakeholder meetings, but at this time we do not believe this is a necessary step to finalizing this policy, which will reduce timeframes and improve prior authorization processes across impacted payers. Comment: Multiple commenters requested clarification regarding the consequences and the available appeals process if payers do not meet decision timeframes. For example, a commenter E:\FR\FM\08FER2.SGM 08FER2 8882 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations lotter on DSK11XQN23PROD with RULES2 stated that for cancer treatments, there should be no extensions unless a peerto-peer review is needed, and if so, it should only be for 48 hours from the original request. Another commenter stated that policies should be implemented for payer oversight and dispute resolutions like targeted audits and penalties for violations. Multiple commenters highlighted that if decision timeframes are not met there should be a presumption of coverage for standard and pre-service determinations for providers and expedited appeal rights. A commenter noted that payers should be required to provide more information for denials when they do not meet decision timeframes and there should be civil monetary penalties on entities that demonstrate a statistical pattern of unnecessary documentation requests. Response: We agree that data will be useful for oversight activities. The impacted payers are subject to the oversight and enforcement of the respective programs, in accordance with annual reporting, certification, and/or auditing. We have addressed program enforcement and compliance mechanisms in response to other similar comments in section I.D.2. of this final rule. For Medicaid managed care, 42 CFR 438.66(a) through (c) requires states to have a monitoring system for all of their managed care programs that addresses all aspects of the program and requires that data collected from these monitoring activities are used to improve program performance. Further, 42 CFR 438.66(e) requires states to complete an annual report on the performance of each of its managed care programs, submit that report to CMS, and post it on the state’s website. CMS reviews these reports and can take enforcement action when needed. Along with the metrics published under 42 CFR 438.210(f), we will have broad visibility into the timeliness of Medicaid managed care plans’ prior authorization decisions. For QHP issuers on the FFEs, penalties associated with failure to comply with deadlines or other provisions of 45 CFR 147.136 are generally within the purview of state VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 regulators.143 The AMA published a summary of some state initiatives regarding prior authorization practices.144 For the reasons discussed in the CMS Interoperability and Prior Authorization proposed rule at 87 FR 76297, we are not requiring that impacted payers approve a request for prior authorization if that payer did not meet the required standard or expedited decision timeframe. If a payer fails to meet the timeline for approval or other decision, providers should contact the payer to obtain the status of the request and determine if supporting documentation is needed to complete the processing of the authorization or if there are other reasons for the delay in a decision. We do not believe it is practical to require payers to default to approval for prior authorization requests for which a timely response has not been provided. Therefore, impacted payers may choose to evaluate process improvements to meet the proposed timeframes and API in this final rule, and consider how to efficiently support provider inquiries on status should responses or timeframes be missed. Some programs, such as the MA program (and including applicable integrated plans) and the Medicaid and CHIP managed care programs, have regulations that include provisions for the failure to provide timely notice of an organization determination; generally, such a failure to meet the deadline constitutes an adverse decision on the prior authorization request that may be appealed.145 d. Operational Topics We solicited comments on what administrative, regulatory, technical, 143 Except to the extent that a state has deferred to CMS as the primary enforcer of these provisions or a state has entered into a Collaborative Enforcement Agreement (CEA) with CMS whereby the state attempts to obtain voluntary compliance but if unsuccessful, defers to CMS to handle enforcement. 144 American Medical Association (2023, May 10). Bills in 30 states show momentum to fix prior authorization. Retrieved from https://www.amaassn.org/practice-management/prior-authorization/ bills-30-states-show-momentum-fix-priorauthorization. 145 See 42 CFR 422.568(f), 422.631(d)(1)(ii), 438.404(c)(5), and 457.1260(b)(3). PO 00000 Frm 00126 Fmt 4701 Sfmt 4700 governance, operational, and workflow solutions would need to be addressed, for and by payers, to comply with the proposed timeframes for handling prior authorization review and approval activities. We also solicited comments on what operational or procedural changes payers or providers would need to make in their workflows or systems to reduce decision timeframes from 14 calendar days to 7 calendar days (for standard prior authorization requests) and from 72 hours to 1 day or 24 hours (for expedited prior authorization requests). We indicated that we wished to learn more about barriers that prevent payers from meeting shorter timeframes than those we proposed and requested input on whether MA organizations and applicable integrated plans, state Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities could provide notice of standard and expedited prior authorization decisions within shorter timeframes (for example, 5 calendar days and 48 hours, respectively), and if not, what issues and obstacles prevent that. We solicited comments on whether implementation of the Prior Authorization API could yield process improvements to support shorter decision timeframe requirements for prior authorization requests and on anticipated operational challenges of implementing the API that might affect a payer’s ability to meet the proposed timeframes. Finally, we requested comments regarding the costs, benefits, and operational impact on providers and payers, as well as the impact on patients, of making and communicating prior authorization decisions on a shorter timeframe than those in the proposed rule. We received a substantial number of comments on these topics which will be useful as we consider future policies and guidance on these issues. These policies for the impacted payers are being finalized in this final rule in the CFR sections listed in Table E4. BILLING CODE 4150–28–P E:\FR\FM\08FER2.SGM 08FER2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations 8883 TABLE El: PRIOR AUTHORIZATION DECISION TIMEFRAMES FOR IMPACTED PAYERS BEGINNING IN 2026 (EXCLUDING DRUGS) MA Organizations and Applicable Integrated Plans As expeditiously as the enrollee's health condition requires, but no later than 72 hours after receiving the request.* 42 CFR 422.572(a) 42 CFR 422.63 l(d)(2)(iv) As expeditiously as the enrollee's health condition requires but no later than 7 calendar days after receiving the request for the standard organization determination* and standard integrated organization decision. 42 CFR 422.568(b )(1) 42 CFR 422.631 (d)(2)(i)(B) Medicaid Managed Care Plans As expeditiously as the As expeditiously as the enrollee's condition requires and enrollee's health condition within State established timeframes that may not exceed requires and no later than 72 7 calendar days after receiving the request for service. 42 CFR 438.210(d)(l) hours after receipt of the request for service. 42 CFR438.210 d 2 As expeditiously as the enrollee's condition requires but As expeditiously as the CHIP Managed enrollee's health condition no later than 7 calendar days after receiving the request Care Entities for service, unless a shorter minimum time frame is requires but no later than 72 established under state law. hours after receipt of the request for service, unless a 42 CFR 457.1230(d) shorter minimum time frame is established under state law. 42 CFR457.1230 d As expeditiously as a beneficiary's health condition As expeditiously as a Medicaid FFS beneficiary's health condition requires, but in no case later than 7 calendar days after receiving the request, unless a shorter minimum requires, but in no case later timeframe is established under state law. than 72 hours after receiving 42 CFR 440.230(e)(l)(i) the request, unless a shorter minimum time frame is established under state law. 42 CFR 440.230 e 1 ii CHIPFFS In accordance with the medical needs of the patient, but In accordance with the no later than 7 calendar days after receiving the request medical needs of the patient, but no later than 72 hours for a standard determination. after receiving the request for 42 CFR 457.495(d)(l) an expedited determination. 42 CFR457.495 d 1 QHP Issuers on the A reasonable period of time appropriate to the medical As soon as possible, taking FFEs circumstances but not later than 15 days after receipt of into account the medical the claim. exigencies, but not later than 45 CFR 147.136(b)(3)(i) 72 hours after receipt of the claim. 45 CFR 147.136 b 3 i *Applicable integrated plans may have shorter timeframes as required by a state (42 CFR 422.629(c) allows states to implement shorter timeframes ). VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 PO 00000 Frm 00127 Fmt 4701 Sfmt 4700 E:\FR\FM\08FER2.SGM 08FER2 ER08FE24.005</GPH> lotter on DSK11XQN23PROD with RULES2 BILLING CODE 4150–28–C 8884 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations lotter on DSK11XQN23PROD with RULES2 The timeframe for standard prior authorization requests and expedited organization determinations for certain programs may be extended for either 14 or 15 146 days for reasons specified and permitted under existing or new policies. The specific citations are provided here for reference. • Medicaid FFS at 42 CFR 440.230(e)(1)(i). Timeframes for prior authorization decisions under the Medicaid FFS program have been newly established with this final rule. The timeframe for standard authorization decisions can be extended by up to 14 calendar days if the beneficiary or provider requests an extension or if the state agency determines that additional information from the provider is needed to make a decision. • MA expedited organization determinations at 42 CFR 422.572(b) and MA standard organization determinations at 42 CFR 422.568(b)(1)(i). Extensions are permitted for expedited and standard integrated organization determinations by applicable integrated plans (see 42 CFR 422.631(d)(2)(ii)). • Medicaid managed care plan expedited authorization decisions at 42 CFR 438.210(d)(2)(ii) and Medicaid managed care plan standard authorization decisions at 42 CFR 438.210(d)(1)(ii). Extensions are permitted for expedited and standard prior authorization requests by up to 14 calendar days under certain circumstances. • QHP issuers on the FFEs are permitted additional time on expedited requests under certain circumstances when a claimant does not provide sufficient information. See 29 CFR 2560.503–1(f)(2)(i). Limited extensions of the timeframe for standard requests are also allowed under certain circumstances. See 29 CFR 2560.503– 1(f)(2)(iii)(A). 5. Requirements for Timing of Notifications Related to Prior Authorization Decisions This section outlines the regulatory amendments adopted in this rule as applicable based on other laws for the timing of notifications sent by certain payers to patients regarding prior authorization decisions. These requirements also apply to most impacted payers. However, we did not address notifications from the QHP issuers on the FFEs for the same reasons we explained in section II.D.4. of this final rule. 146 QHP issuers on the FFEs follow 29 CFR 2560.503–1(f)(2)(iii)(A) for certain extensions. See 29 CFR 2560.503–1(f)(2)(iii)(A). VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 a. Medicare Advantage Organizations MA organizations are currently required to provide notifications to enrollees of decisions regarding coverage, called organization determinations, which include decisions regarding prior authorizations. To support more timely decisions and communication of those decisions, we proposed to amend 42 CFR 422.568(b)(1) to require MA organizations to notify the enrollee of its prior authorization determination as expeditiously as the enrollee’s health condition requires, but no later than 7 calendar days after the organization receives the request for a standard organization determination for a medical item or service subject to the prior authorization rules at 42 CFR 422.122. We also proposed to move the existing language at 42 CFR 422.568(b)(1)(i) and (ii) (regarding extensions of the adjudication timeframe for standard organization determinations) to 42 CFR 422.568(b)(2). We proposed to move the language previously at 42 CFR 422.568(b)(2) to a new paragraph (b)(3). We emphasized that this change to the regulation text structure would not change current requirements and that the proposed new 7-calendar day timeframe would remain subject to the existing standards and limits (currently at 42 CFR 422.568(b)(1)(i), proposed to be at 42 CFR 422.568(b)(2)) related to when an MA organization may extend the adjudication timeframe by up to 14 additional calendar days. For additional explanation on the continued applicability of existing standards, in this final rule, we are adding paragraph (a)(3) to 42 CFR 422.122 to explain that prior authorization decisions made under 42 CFR 422.122 must meet all other applicable requirements in subpart M of part 422, such as the adjudication timeframes and notice requirements. In this final rule we are also adding explanatory language to the beginning of paragraph (b)(1)(i) of 42 CFR 422.568; specifically, we are adding the phrase ‘‘For a service or item not subject to the prior authorization rules at § 422.122’’ to the beginning of the sentence to be clear that those requests not subject to the prior authorization rules at 42 CFR 422.122 will be adjudicated under the existing 14calendar day timeframe, such as a request for a supplemental benefit that involves an OTC drug or a pre-service request made by an enrollee who is seeking an advance determination on an item or service that is not subject to prior authorization under the rules at 42 CFR 422.122. In contrast, 42 CFR PO 00000 Frm 00128 Fmt 4701 Sfmt 4700 422.568(b)(1)(ii) sets forth the 7calendar day timeframe for those requests for a service or item that are subject to the prior authorization rules at 42 CFR 422.122. We proposed similar amendments to the integrated organization determination requirements at 42 CFR 422.631 for applicable integrated plans. We are making in this final rule explanatory revisions to the regulation text at 42 CFR 422.631 consistent with the revisions made at 42 CFR 422.568 and amended 42 CFR 422.631(d)(2)(i)(B) to state that when a provider makes a request for an item or service, the applicable integrated plan must notify the enrollee of its determination as expeditiously as the enrollee’s health condition requires, but no later than 7 calendar days after the organization receives the request for a standard preservice organization determination that is subject to 42 CFR 422.122. We also proposed an amendment to 42 CFR 422.631(d)(2)(iv)(B) to state that when an applicable integrated plan denies a request for an expedited determination and automatically transfers the request to the standard timeframe, it must make its determination within the applicable timeframe established at 42 CFR 422.631(d)(2)(i)(B). This means that for prior authorization requests within the scope of 42 CFR 422.122, the 7-calendar day timeframe applies, rather than the current 14-calendar day timeframe for an integrated organization determination. These changes also apply to applicable integrated plans that are MCOs as defined at 42 CFR 438.2, because per 42 CFR 438.210(d)(4), 42 CFR 422.631 also applies to these Medicaid plans. These amendments are consistent with changes for other Medicaid managed care plans being finalized at 42 CFR 438.210(d)(1) and (2). Concerning MA organizations (including applicable integrated plans), our proposal was limited to the timeframes for standard determinations involving prior authorization, and there are no changes to the timeline for expedited integrated organization determinations, extensions, or the requirements for notice to enrollees. Comment: A commenter urged CMS to require that any failure by an MA plan or applicable integrated plan to provide notice of an organization determination within the same timeframes (and without having requested an extension) constitute a deemed denial for which the provider may request a reconsideration by an independent reviewer. Response: We acknowledge this commenter’s concern about the failure of MA plans to provide notice within E:\FR\FM\08FER2.SGM 08FER2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations lotter on DSK11XQN23PROD with RULES2 the required timeframes. Under the existing MA rules, a failure to meet the deadline by which an organization determination, including a request for prior authorization, constitutes a denial that can be appealed to the next level (reconsideration by the MA organization). See 42 CFR 422.568(f) and 422.631(d)(1)(ii). The MA program regulations (42 CFR 422.592 through 422.596 and 422.634) provide for review by an Independent Review Entity (IRE) after an MA organization’s adverse reconsidered organization determination, including where the MA organization fails to issue a reconsidered organization determination in a timely fashion. We did not propose, and are therefore not finalizing here, an amendment to those rules to escalate prior authorization denials to the IRE. However, the existing regulations at 42 CFR 422.590(h)(1) and 422.629(k)(4) provide that for reconsiderations by MA plans and applicable integrated plans, the individuals who make the reconsideration determination must not have been involved in the organization determination. We also reiterate that providers should follow up on the status of a request with the payer. Failure to respond to a request for the status of the pending prior authorization request does not constitute a denial (unless the lack of response continues beyond the deadline for response) but may indicate other issues in the process such that an appeal may not be necessary. We acknowledge that issues in communication between payers and providers may continue to exist, and encourage providers to notify payers or CMS of any patterns for poor communication and untimely issuance of prior authorization decisions. b. Medicaid Fee-for-Service, Including Beneficiary Notice and Fair Hearings For the Medicaid FFS program, we proposed, in the CFR sections listed in Table E2, regulatory timeframes to provide notice of decisions on both expedited and standard prior authorization requests. We stated that the new requirements would apply to prior authorization decisions beginning January 1, 2026. We are finalizing that policy in this final rule. Under the new requirement for Medicaid FFS, which appears at 42 CFR 440.230(e)(1), notice of the state Medicaid program’s decision regarding an expedited request for prior authorization will have to be communicated as expeditiously as a beneficiary’s health condition requires, but no later than 72 hours after receiving a provider’s request for an VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 expedited determination, unless a shorter minimum timeframe is established under state law. Notice of a decision on a standard request for prior authorization will have to be communicated to the requesting provider as expeditiously as a beneficiary’s health condition requires, but no later than 7 calendar days after receiving the request, unless a shorter minimum timeframe is established under state law. If the state determines that it needs additional information from a provider to make a decision, or if the beneficiary or provider requests an extension, the proposed decisionmaking and communication timeframe for a standard request may be extended by up to 14 calendar days if the beneficiary or provider requests an extension, or if the state agency determines that additional information from the provider is needed to make a decision. Such extensions may be justified and in the beneficiary’s interest if medical evidence from outside providers is needed to support the request, or if there are other circumstances identified by either the provider or the beneficiary. Independent of this final rule’s API proposals and their application to Medicaid prior authorization requests, Medicaid has longstanding beneficiary notice and fair hearing regulations. CMS has interpreted these existing regulations to apply to prior authorization requests for Medicaid FFS and will continue to do so in the future. These existing Medicaid beneficiary notice and fair hearing requirements will remain in full effect without change, in concert with other provisions of this final rule, including the Prior Authorization API. As discussed in detail in the proposed rule (87 FR 76299 and 76300), the current Medicaid notice and fair hearing regulations at 42 CFR 435.917 and 42 CFR part 431, subpart E, apply to all prior authorization decisions. Therefore, states are required to— • Provide the beneficiary with timely and adequate written notice of any decision regarding the beneficiary’s prior authorization request; • Include the content described at 42 CFR 435.917 and at 42 CFR part 431, subpart E, including information about the beneficiary’s right to request a fair hearing to appeal the partial or total denial, in the beneficiary notice when a state denies the prior authorization request in whole or in part; • Provide beneficiaries the opportunity to request a fair hearing if the state fails to act on a claim, which includes prior authorization requests, with reasonable promptness; and PO 00000 Frm 00129 Fmt 4701 Sfmt 4700 8885 • Provide at least 10-day advance notice to beneficiaries of any termination, suspension of, or reduction in benefits or services for which there is a current approved prior authorization, including information regarding the beneficiary’s right to request a fair hearing. These notice and fair hearing requirements are not affected by any of the changes made elsewhere in this final rule. As noted in the CMS Interoperability and Prior Authorization proposed rule, the Medicaid notice requirements are separate from and independent of, the new timeline for provider notice that is finalized at 42 CFR 440.230(e)(1). To make it explicit that existing Medicaid beneficiary notice and fair hearing rights apply to Medicaid FFS prior authorization decisions, we proposed several updates to the existing regulations at 42 CFR 431.201, 431.220, and 435.917, and a new 42 CFR 440.230(e)(2). The proposed changes are intended to further explain, but not change, Medicaid notice or fair hearing policy or operational requirements for states. We proposed and are finalizing, with one exception discussed below, that the changes referenced in this paragraph take effect on the effective date of the final rule. Please see 87 FR 76300 for the detailed text. The regulations and amendments are listed in Table E3. The proposed changes for 42 CFR 431.201 included replacing the term ‘‘beneficiary’’ with ‘‘enrollee’’ in the revised definition of ‘‘Action.’’ This change was proposed in error, and the preamble to the CMS Interoperability and Prior Authorization proposed rule did not discuss the potential impact of changing ‘‘beneficiary’’ to ‘‘enrollee’’ on the definition of ‘‘Action.’’ In this final rule, we are reverting to the term ‘‘beneficiary’’ in the definition of ‘‘Action’’ at 42 CFR 431.201, consistent with the current definition and with our stated intent in the proposed rule that the changes would not change Medicaid notice or fair hearing policy or operational requirements for states. We received comments on fair hearings and provide those and our responses here. Comment: Multiple commenters expressed support for our proposal to further explain the application of Medicaid notice and fair hearing requirements to Medicaid FFS prior authorization decisions and recommended that the proposed changes be codified. A few commenters noted that states already apply notice and fair hearing requirements to Medicaid FFS prior authorizations. E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8886 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations Multiple commenters noted that Medicaid agencies already have provider hearing rights for prior authorization decisions in place. Response: We appreciate commenters’ support for the proposed updates to the Medicaid notice and fair hearing regulations, which we are finalizing as proposed. Comment: A few commenters noted that patients should receive equitable fair hearing rights for their prior authorizations, regardless of whether they are enrolled in a Medicaid FFS or a managed care plan. A few commenters expressed support for the proposed changes which would explain that Medicaid FFS notice and fair hearing requirements are consistent with current regulations for notice and appeal rights for managed care prior authorization decisions. Response: We agree that comparable and aligned notice and fair hearing rights should apply across delivery systems. As discussed in the CMS Interoperability and Prior Authorization proposed rule, we have historically interpreted the existing Medicaid notice and fair hearing regulations to apply to prior authorization requests for Medicaid FFS. Given the alignment between these state-level requirements and the managed care plan-level requirements, equitable notice and appeal rights have been and will continue to be available to Medicaid FFS and managed care beneficiaries and that the updates, which we are finalizing as proposed, will further strengthen the existing alignment between delivery systems regarding notices and fair hearings/appeals. Comment: A commenter stated that there needs to be more clarification in the rule that existing Medicaid beneficiary notice and fair hearing rights apply to prior authorization decisions for Medicaid FFS beneficiaries. Another commenter recommended CMS mandate more details on the hearing process to ensure that a hearing can be conducted expeditiously and objectively. A commenter recommended that the language in the regulation be strengthened to explicitly state that failure to act on a request for prior authorization will give rise to notice and hearing rights. Response: The updates we are making to these regulations, which we are finalizing as proposed, provide additional details regarding how Medicaid beneficiary notice and fair hearing rights apply to prior authorization decisions for Medicaid FFS beneficiaries. These changes provide further detail about, but do not change, the current application of these VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 regulations to Medicaid FFS prior authorization decisions. Therefore, the existing requirements for the fair hearing process at 42 CFR part 431, subpart E, apply to Medicaid FFS prior authorization fair hearings. These include a requirement that fair hearings must be conducted by an impartial person who was not directly involved in the initial decision (42 CFR 431.240(a)(3)) and requirements for when the state must take final administrative action on a fair hearing request (42 CFR 431.244(f)). These regulations also require the state to provide notice to a beneficiary (42 CFR 431.206(c)(2)) whenever a hearing is required in accordance with 42 CFR 431.220(a), which includes when the state fails to act upon a claim, including a prior authorization decision, with reasonable promptness. Comment: A commenter recommended that CMS expand on proposed 42 CFR 440.230(e)(2) to require written notice of a prior authorization decision be provided to the provider as well as the beneficiary. Response: The Medicaid notice and fair hearing provisions at 42 CFR 435.917 and 42 CFR part 431, subpart E, which are cross referenced at 42 CFR 440.230(e)(2), apply to applicants and beneficiaries, not providers. Therefore, we decline this recommendation and will finalize 42 CFR 440.230(e)(2) as proposed. There are separate requirements regarding provider notification of prior authorization decisions. As stated in this final rule, we are finalizing requirements for payers to provide a specific reason for denials, as well as the status of a prior authorization, either through the Prior Authorization API as specified, or through existing processes. When providing a status for a prior authorization, the response must indicate whether the payer approves (and for how long) or denies (and the reason) the prior authorization request, or the payer may request more information from the provider to support the prior authorization request. Comment: A commenter raised concerns about whether and how notice and appeal rights can be provided electronically and noted that lowerincome consumers may have inconsistent access to electronic communications. This commenter recommended that HHS continue to require a redundant written notice for all important Medicaid notices, including those related to prior authorization. Response: The provision of electronic notices to Medicaid applicants and beneficiaries is addressed at 42 CFR PO 00000 Frm 00130 Fmt 4701 Sfmt 4700 435.918. Individuals must be provided a choice to receive notices in electronic format or by regular mail and have the option to request that all electronic notices also be provided by regular mail. Changes to 42 CFR 435.918 are outside the scope of this rule. The Medicaid notice requirements, which include the provision of fair hearing rights, will continue to apply unchanged when APIbased notifications begin. Therefore, low-income beneficiaries enrolled in Medicaid will continue to receive notices by mail, electronically, or both, even after the API-based notifications begin. Comment: A commenter expressed that CMS’s proposal to make explicit the requirement for a fair hearing to appeal prior authorization non-compliance is inadequate to address prevalent and profitable wrongful denials of prior authorization. This commenter stated that very few patients can appeal wrongful denials and rarely do appeal and noted that medical practices aren’t compensated for prior authorizations or appeals, which harms patients as well. Response: Fair hearings are an important part of a beneficiary’s due process rights. While fair hearings cannot directly prevent inappropriate denials of prior authorization requests, they do provide a pathway for a beneficiary to remedy an inappropriate prior authorization denial, termination, or reduction and provide data to states to help them identify problems with the prior authorization process. We believe that improvements in the process overall will occur by using the API once that is in place, as providers will have additional information on which to base the submission of an initial prior authorization request. c. Medicaid Managed Care For Medicaid managed care, we proposed new timeframes for notice of decisions on standard (non-expedited) prior authorization requests which would apply beginning with the rating period that starts on or after January 1, 2026, and proposed to revise 42 CFR 438.210(d)(1) and (2) to accomplish this. Specifically, we proposed to revise 42 CFR 438.210(d)(1) to reflect that, beginning with the rating period that starts on or after January 1, 2026, managed care plans must provide notice of standard authorization decisions as expeditiously as the enrollee’s health condition requires and within stateestablished timeframes that may not exceed 7 calendar days following the plan’s receipt of the request for service. Our proposed amendment provided that for rating periods that begin before January 1, 2026, the current rule would E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations remain in effect. We proposed to specify the standard authorization requirements by the compliance dates by leaving the section header ‘‘Standard authorization decisions’’ as 42 CFR 438.210(d)(1) and redesignating standard authorization timeframes as 42 CFR 438.210(d)(1)(i)(A) and (B). We also proposed to move the current regulation text on extending the prior authorization decision timeframe from 42 CFR 438.210(d)(1)(i) and (ii) to 42 CFR 438.210(d)(1)(ii)(A) and (B) and proposed to make slight revisions to the text for readability. We explained that our proposal would not change the current provisions for how failure to issue a decision within the required timeframe constitutes an adverse benefit determination that can be appealed under 42 CFR 438.404(c)(5). The regulations at 42 CFR 438.404 and other regulations governing appeal rights at 42 CFR part 438, subpart F, would continue to apply and we did not propose to amend those regulations. We note that 42 CFR 438.404(c)(3) through (6) provide that certain adverse benefit determinations must be issued on the timing specified at 42 CFR 422.210(d); the new timeframes proposed (and finalized) in this rulemaking will apply to those specific adverse benefit determinations. In addition, under current regulations at 42 CFR 438.3(s)(1) and (6) and 438.210(d)(3), Medicaid managed care plans must also comply with the requirements in section 1927 of the Act regarding coverage and prior authorization of covered outpatient drugs; nothing in this rulemaking would change these requirements. Finally, because some Medicaid MCOs are applicable integrated plans as defined at 42 CFR 438.2, our proposal related to 42 CFR 422.631(d) applied to those plans. We received a few comments on this subject and provide our responses to those here. Comment: A commenter agreed with the proposal to provide notice of decisions for standard prior authorization requests within state established timeframes not exceeding 7 calendar days, and another commenter disagreed with the proposal to shorten the maximum amount of time for Medicaid managed care plans to respond with a decision from 14 to 7 days. Another commenter proposed that the standard should be 24 hours or less for standard requests. A commenter stated that Medicaid and CHIP managed care programs already have requirements to issue prior authorization decisions within a certain timeframe established by the state and that those standards provide adequate protection for enrollees and providers. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 Response: As we stated in the proposed rule, and based on CMS and other industry studies on the impact of delays to patient health or access to care from extended authorizations, reducing standard prior authorization decision timeframes from 14 calendar days to 7 calendar days should improve patient care outcomes and ensure that patients have more timely access to services (87 FR 76296). d. CHIP Fee-for-Service and Managed Care To implement the proposed prior authorization timeframes for CHIP, we proposed to revise certain policies affecting the timing for making decisions on prior authorization requests under the CHIP FFS and managed care programs. These changes are listed in Table E2. We proposed that beginning on January 1, 2026, decisions related to prior authorization of health services would be required to be completed in accordance with the medical needs of the patient, but no later than 7 calendar days after receiving the request for a standard determination and 72 hours after receiving the request for an expedited determination, unless an alternative option is preferred by industry based on public comments. Further, we stated that if a beneficiary requests an extension of a prior authorization review, or if the provider or health plan determines that additional information is needed for such review, an extension of up to 14 calendar days may be granted. We proposed to remove the option for states to follow existing state law regarding prior authorization of health services, requiring states to instead follow these updated timeframes. However, if state laws are more stringent than our proposal, states would be allowed to apply and enforce those shorter timeframes for prior authorization responses. Timely prior authorization decisions are important patient protections, and CHIP patients should be afforded the same decision timeframes as Medicaid and Medicare patients. Existing CHIP regulations at 42 CFR 457.1130(b) require a state to ensure that a beneficiary has an opportunity for external review of health services matters, including a delay, denial, reduction, suspension, or termination of health services, in whole or in part, including a determination about the type or level of service. Under this regulation, CHIP beneficiaries must have an opportunity for external review of prior authorization decisions. We did not propose any changes to this requirement, as it already applies to PO 00000 Frm 00131 Fmt 4701 Sfmt 4700 8887 decisions related to the prior authorization of services. In the CMS Interoperability and Prior Authorization proposed rule we explained that overall, we believed that the decision and notification timeframes proposed for certain impacted payers would help ensure that prior authorization processes do not inappropriately delay patient access to necessary services. Introducing prior authorization decision timeframes that are the same across these impacted payers for items and services that require prior authorization would also help providers better organize and manage administrative resources and thus may make more time available for providers to render patient-centered care. Currently, CHIP managed care program regulations reference the Medicaid managed care regulations for the timelines and requirements for CHIP managed care entities as to prior authorization decisions and notices as well as appeal processes. We explained in the proposed rule that the proposal to amend 42 CFR 438.210(d) for timeframes would also apply to standard and expedited decisions made by CHIP managed care entities because of the cross reference to 42 CFR 438.210 in current 42 CFR 457.1230(d). We did not propose to change the required timeframes for expedited decisions at 42 CFR 438.210(d)(2), but we proposed to amend 42 CFR 438.210(d)(2)(i) to explain that the MCO, PIHP, or PAHP must make these decisions on shorter timeframes if the state requires shorter timeframes. We did not propose any changes to the authority for a 14calendar day decision timeframe provided at 42 CFR 438.210(d)(2)(ii). We received the following comments related to CHIP FFS and managed care and include our responses to those comments here. Comment: A commenter disagreed with CMS’s proposal to shorten the maximum amount of time for CHIP FFS and managed care to respond with a decision from 14 to 7 days. The commenter proposed that the standard should be 24 hours or less. Another commenter recommended CMS provide equal protection for children enrolled in CHIP FFS against unnecessary delays in accessing necessary services due to prior authorization procedures. The commenter also recommended that state CHIP agencies follow the same rules as state Medicaid agencies, including specific timelines for prior authorization responses for outpatient prescription drugs. Another commenter expressed their support for aligning the beneficiary protections in CHIP and Medicaid E:\FR\FM\08FER2.SGM 08FER2 8888 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations managed care and recommended CMS maintain 42 CFR 457.1230(d) as proposed, applying 42 CFR 438.210 to CHIP managed care entities with the proposed shorter timelines for responses to standard requests for prior authorization, characterizing these as stronger beneficiary protections. Response: Though we anticipate the Prior Authorization API will introduce additional efficiencies into the prior authorization process, we are uncertain that such a truncated standard decision timeframe would be possible until we have completed further data collection and analysis after the implementation of the API. The recommendation concerning CHIP prior authorization decision timeframes for outpatient prescription drugs is outside the scope of the final rule. We agree with comments that recommend CHIP prior authorization decision timeframes be in alignment with Medicaid. We are finalizing the proposals to adopt the timeframes we proposed for responses by MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities to prior authorization requests. We are not requiring that impacted payers approve a request for prior authorization if that payer fails to meet the required standard or expedited decision timeframe. If a payer fails to meet the timeline for approval or other decision, providers should contact the payer to obtain the status of the request and determine if supporting documentation is needed to complete the processing of the authorization or if there are other reasons for the delay in a decision. The 72-hour requirement for expedited requests is measured in hours, whereas the 7-day requirement for standard requests is measured in calendar days. In the case of expedited and standard requests, the timeframes are 72 hours and 7 days, respectively, unless a shorter minimum timeframe is established under state law. Tables E2 and E3 provide a list of some, but not all of the final policies for decision notification timelines for the impacted payers. The full list of final policies and citations is included in Table E4 at the end of this section. We included these tables for ease of reference for the narrative on the discussion of notifications and timeframes. Table E3 is specific to the Medicaid FFS notice and fair hearings provisions, which provide an important service to beneficiaries and providers alike. This rule finalizes modifications to those provisions, and this table and accompanying narrative provide the reader with citations to new and existing provisions. TABLE E2: NEW OR MODIFIED PRIOR AUTHORIZATION NOTIFICATION REQUIREMENTS FOR MEDICARE ADVANTAGE ORGANIZATIONS, STATE MEDICAID AND CHIP FEE-FOR-SERVICE, MEDICAID MANAGED CARE PLANS, AND CHIP MANAGED CARE ENTITIES MA Organizations Notification Requirement to Enrollees 42 CFR 422.568(b)(l) Applicable Integrated Plans Applicable Integrated Plans Medicaid FFS Notification Requirement to Enrollees - Standard Decision Notification Requirement to Enrollees - Expedited Decision Notice to Providers of Decisions on Expedited and Standard Prior Authorization Re uests Standard Prior Authorization Decision Notification 42 CFR 422.63 l(d)(2)(i)(B) Expedited Prior Authorization Decision Notification Prior Authorization Decisions 42 CFR 438.210(d)(2)(i) lotter on DSK11XQN23PROD with RULES2 CHIPFFS VerDate Sep<11>2014 18:23 Feb 07, 2024 Prior Authorization Decisions Jkt 262001 PO 00000 Frm 00132 Fmt 4701 Sfmt 4725 42 CFR 440.230(e)(l) 42 CFR 438.210(d)(l)(i) Through cross reference to 42 CFR438.210 at42 CFR 457.1230 d 42 CFR 457.495(d)(l) E:\FR\FM\08FER2.SGM 08FER2 ER08FE24.006</GPH> Medicaid Managed Care Plans Medicaid Managed Care Plans CHIP Managed Care Entities 42 CFR 422.63 l(d)(2)(iv) Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations 8889 TABLE E3: FINAL MEDICAID FFS PRIOR AUTHORIZATION BENEFICIARY NOTICE AND FAIR HEARING REGULATORY AND AMENDATORY CHANGES Medicaid FFS Revise Defmition of Action Medicaid FFS Addition of Prior Authorization Decision to Situations for Fair Hearin Add a Notice of Denial or Change in Benefits or Services to Notices Beneficiary Notice of Prior Authorization Decision and Fair Hearin Ri ts Medicaid FFS 6. Extensions, Exemptions, and Exceptions See section II.E. of this final rule for a discussion of extensions and exemptions and the final policies for the Prior Authorization API for state Medicaid and CHIP FFS programs and exceptions for the Prior Authorization API for QHP issuers on the FFEs (this was also addressed in the proposed rule at 87 FR 76279). 7. Public Reporting Requirements for Prior Authorization Metrics In the CMS Interoperability and Prior Authorization proposed rule we discussed the importance of accountability for payer prior authorization practices and proposed that certain data be made publicly available for patients and providers to better understand the types of items and services which required prior authorization and how each payer performed over time for approvals and denials. We are finalizing our proposal to require impacted payers to report certain aggregated metrics about prior authorization by posting them on the payer’s website. This requirement underscores the importance of transparency and accountability in the health care system. Public disclosure of the items and services which are subject to prior authorization, as well as organizational performance, offers useful information to providers, patients, and other interested parties. Performance data could allow for objective evaluation of the efficiency of prior authorization practices of each organization, and it enables payers to assess trends, identify areas for improvement, and work towards continuous process improvement while maintaining necessary quality checks for quality and appropriateness of care. We are finalizing as proposed that state Medicaid and CHIP FFS programs VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 will report at the state level, Medicaid managed care plans and CHIP managed care entities will report at the plan level, and QHP issuers on the FFEs will report at the issuer level. We are finalizing a modification to our proposal for reporting to be at the organization level to require that reporting be at the contract level for MA organizations as discussed in this section (section II.D.7. of this final rule). Additionally, we explain that integrated plans will report items and services covered by MA organizations at the MA contract level and items and services covered by Medicaid managed care plans at the plan level as the separate requirements for MA organizations and Medicaid managed care plans will apply under the respective contracts. We described how payers might use the information for process improvements and performance analysis in the proposed rule (87 FR 76304). For example, an impacted payer could use these data to examine its performance trends. In addition, we explained how providing this information publicly would benefit patients (who could use the information when selecting among plan or organization options) and providers (in when and whether to contract with an impacted payer). The legal authority for requiring such public reporting is discussed in section II.D.10. of this final rule. We are finalizing our proposal that for each metric listed, data would be reported in aggregate for all items and services. We received many comments on the proposed public reporting of metrics, the timing, and the level of reporting. The suggestions were detailed and represented diverse issues and concerns from interested parties about prior authorization challenges and potential uses for the data. CMS will use the comments received as CMS considers future policy development. We intend to support transparency and PO 00000 Frm 00133 Fmt 4701 Sfmt 4700 42 CFR431.220(a)(l)(vi) 42 CFR435.917(b)(2) 42 CFR 440.230(e)(2) accountability and enable patients to access data that are meaningful and easy to use for decision-making and understanding the prior authorization processes. The metrics we are finalizing represent the most significant issues for both patients and providers identified over the past decade on a national level, including the CMS listening sessions referenced at the beginning of this section. Furthermore, payers can supplement the information they report with additional metrics on prior authorization. We may consider additional reporting options in the future. We reiterate that the prior authorization reporting metrics are on medical items and services, excluding drugs covered by the impacted payers. We are finalizing the requirement for impacted payers to make reports available annually on all of the following: • A list of all items and services that require prior authorization. • The percentage of standard prior authorization requests that were approved, aggregated for all items and services. • The percentage of standard prior authorization requests that were denied, aggregated for all items and services. • The percentage of standard prior authorization requests that were approved after appeal, aggregated for all items and services. • The percentage of prior authorization requests for which the timeframe for review was extended, and the request was approved, aggregated for all items and services. • The percentage of expedited prior authorization requests that were approved, aggregated for all items and services. • The percentage of expedited prior authorization requests that were denied, aggregated for all items and services. • The average and median time that elapsed between the submission of a E:\FR\FM\08FER2.SGM 08FER2 ER08FE24.007</GPH> Modification to Headers Medicaid FFS lotter on DSK11XQN23PROD with RULES2 42 CFR 435.917(a) 42 CFR435.917 42 CFR431.201 Medicaid FFS 8890 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations lotter on DSK11XQN23PROD with RULES2 request and a determination by the payer, plan, or issuer, for standard prior authorizations, aggregated for all items and services. • The average and median time that elapsed between the submission of a request and a decision by the payer, plan, or issuer, for expedited prior authorizations, aggregated for all items and services. a. Reporting Prior Authorization Metrics As described previously, we proposed to require impacted payers to report certain metrics to support a level of accountability for the requirements in this final rule. As discussed previously, public disclosure of information for each audience—patients, providers, and the general public—supports the intent of this final rule to improve the prior authorization process, patient care, and burden reduction. Comment: Many commenters supported CMS’s efforts to promote transparency through public reporting of these aggregated metrics. These commenters believe such reporting will increase transparency from payers related to the volume of prior authorizations. For example, a commenter wrote to encourage CMS to propose in future rulemaking to use the prior authorization data the agency would collect from impacted payers to help develop quality measures to incorporate into quality ratings across certain payer programs, specifically for MA organizations. This would ensure that such data are incorporated more directly into a consumer-friendly comparison tool so that payers’ prior authorization practices are available to physicians and practitioners, including gastroenterologists, to ensure transparency and accountability in the prior authorization process. Multiple commenters stated that reporting metrics could be informative to providers in the context of what they submit to payers for prior authorization requests, as the data might provide insights about the types of services that are approved or denied. A commenter noted that prior authorization metrics could be useful to patients as they decide which health plans to select, and another commenter appreciated that CMS’s proposal aimed to strike a balance between data reporting burden and providing meaningful data to consumers and providers. Another commenter supported reporting prior authorization metrics on the payer’s website by March 31, 2026. Some commenters believed that CMS should require public reporting of the metrics sooner than proposed, and multiple commenters recommended that CMS VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 require the public reporting requirement immediately upon finalizing the rule. Response: We thank commenters for their support of our proposed prior authorization reporting metrics, including those commenters who recommended that CMS consider additional future uses for the data for other program purposes and require compliance as soon as the rule is finalized. We agree that payers have the data available now, as they are currently conducting the prior authorization process, and that the data would provide a baseline for reporting. As proposed and finalized, CMS is not collecting these data, but instead requiring impacted payers to post such data on the payer’s website. We encourage payers to consider developing and posting reports of these metrics at the earliest date feasible. We are finalizing the requirements for public reporting as well as the compliance dates in 2026, as proposed. Comment: Multiple commenters recommended that CMS require payers to report prior authorization data at a more granular level. Specifically, multiple commenters recommended that CMS require MA organizations to report prior authorization metrics at the plan level or state level. Commenters stated that the organization level for MA organizations was a higher level of aggregation than the plan level for Medicaid managed care plans and CHIP managed care entities and therefore would not present the same level of detail. Those commenters pointed out that MA organization metrics reported at the organization level would not be useful to consumers choosing plans in their area. Other commenters suggested more discrete reporting levels, including county level, specialty/benefit level, or service level. Response: Upon further consideration and taking the comments into account, we determined that contract level is the more appropriate reporting level for MA organizations. MA organizations generally have multiple plans under the same contract as it is common throughout the industry to offer a variety of plans within a service area. Contract-level data are aggregated data that are collected from the plan benefit packages (PBPs) (that is, the various MA plans) offered under an individual contract; these data are specific to the contract to which they correspond. CMS already requires MA organizations to report some contract-level data about their organization determinations to the agency on an annual basis and Star Ratings are assigned at the contract level. While this particular provision does not require MA organizations to PO 00000 Frm 00134 Fmt 4701 Sfmt 4700 submit data to CMS, a consistent approach of contract-level reporting in the MA program will give consumers useful information while limiting plan burden. By requiring contract-level reporting for these data, we ensure that the format of this reported data remains consistent with that of other similar data that MA organizations are required to report. We agree that requiring Medicaid managed care plans and CHIP managed care entities to report at the plan level will allow beneficiaries and states to compare plans within the state. Requiring QHP issuers on the FFEs to report at the issuer level, aggregating plans under their purview, is consistent with their reporting on quality improvement strategies as described in section 1311(g) of the Affordable Care Act (45 CFR 156.1130), which provides consistency with other QHP reporting requirements. While we understand the desire from some commenters to increase the level of granularity for reporting, we have concerns about data overload, patient understanding, and usability of the data. For example, reporting at the specialty level and service level could be overwhelming because of the volume of information presented. A patient might not be able to relate to the data and would not refer to the reports as intended. There can and should be both transparency and accountability in the information that is presented to the public and we will continue to explore opportunities to strike the appropriate balance with impacted payers. We are finalizing a modification to our proposal for MA organizations to report at the contract level. We are finalizing, as proposed, that state Medicaid and CHIP FFS programs will report at the state level, Medicaid managed care plans and CHIP managed care entities will report at the plan level, and QHP issuers on the FFEs will report at the issuer level. We may assess whether to collect more detailed metrics than we are finalizing here in program-specific rulemaking in the future. For instance, we may consider requiring in future rulemaking that MA plans report at a more discrete level. Similarly, should a state Medicaid or CHIP agency believe it would be beneficial to require more detailed data, the state may require additional metrics in its managed care contracts. Comment: A commenter requested clarification on whether integrated care plans for dually eligible individuals, such as FIDE SNPs, should report these data consistent with MA organizations, at the contract level, or consistent with E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations Medicaid managed care plans, at the plan level. Response: Integrated care plans generally combine D–SNPs, which include FIDE SNPs and HIDE SNPs— both as defined at 42 CFR 422.2—and Medicaid managed care plans offered by the same parent organization. D–SNPs are a type of MA plan designed to meet the needs of individuals who are dually eligible for Medicare and Medicaid, also known as dually eligible individuals. In these arrangements, there is an MA organization with a contract with CMS for the MA D–SNP and an organization with a contact with the state for the Medicaid managed care plan. For items and services that require prior authorization under an integrated plan’s MA benefit package, data must be reported in a manner consistent with the requirements for MA organizations, which we are finalizing at the contract level. In the case of integrated care, the affiliated Medicaid managed care plan will report prior authorizations of items and services covered under the plan’s Medicaid benefit package at the plan level. Where there is not a clear delineation between whether items or services are covered under Medicare or Medicaid (for example, home health services), we will accept any reasonable methodology for attributing the prior authorization reporting to one payer versus the other. Comment: Multiple commenters recommended a more phased-in approach to the reporting of prior authorization metrics. A commenter stated that while prior authorization metrics should not be publicly reported until after the electronic FHIR APIs have been implemented, the prior authorization metrics should still be reported to CMS beginning March 2026. A commenter recommended that CMS begin to phase in reporting requirements before the 2026 implementation period (for example, require payers to report some, but not all, metrics soon after the rule is finalized) to help identify any issues with the reporting process so that they can be addressed timely. Response: We disagree that a phasedin approach to reporting metrics is necessary given that payers already conduct prior authorization processes and likely already track data for many of the metrics for their usual business operations. We are finalizing compliance dates in 2026, as stated previously. We agree that reporting prior authorization metrics conducted using the Prior Authorization API will not be reported until after the Prior Authorization API has been implemented, and that the technology could be capable of supporting VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 automated reporting on its use. The metrics to be included in the reports beginning in March 2026 will be based on an impacted payer’s current prior authorization processes, in advance of implementation of the Prior Authorization API. Reporting information about performance data in advance of implementation could provide valuable data in the years postimplementation. Comment: Multiple commenters expressed concerns about how the prior authorization metrics could be used by payers in inappropriate or harmful ways to providers. A commenter flagged that the publicly reported metrics could lead to plans ‘‘self-selecting’’ patients by implementing other burdensome prior authorization processes to avoid approving services, which could lead to patients who need those services enrolling in other plans. Another commenter recommended that CMS address steps it will take to protect against adverse selection. This commenter urged CMS to consider how it will mitigate unintended consequences that may occur as competing payers decide to analyze each other’s data once it becomes public. The commenter wrote that CMS should make clear that any such practices would be against the spirit and intent of the reporting requirements. Response: We acknowledge concerns by a few commenters that prior authorization policies and information on the publicly reported metrics could technically be used inappropriately for improper decision-making purposes or other reasons. Public reporting does not in and of itself create such behavior. However, we believe requiring that public availability of prior authorization metrics will have the opposite effect; that is, payers will use the data to try to improve their performance to improve their competitive standing in a program. In addition, there are some safeguards in place to help address the concerns raised by commenters about inappropriate efforts to discourage enrollment by individuals who need certain covered services. Medicaid managed care regulations also provide significant patient protections for access to covered services at 42 CFR 438.206 through 438.210. For example, 42 CFR 438.210(a) requires states’ contracts with Medicaid managed care plans to identify, define, and specify the amount, duration, and scope of each service covered by the plan and such amount, duration, and scope must be no less than that furnished to Medicaid FFS beneficiaries. Existing regulations at 42 CFR 438.66 require states to have a PO 00000 Frm 00135 Fmt 4701 Sfmt 4700 8891 monitoring system that addresses all aspects of each Medicaid managed care program and to use the data collected from their monitoring activities to improve the performance of their managed care program, including at a minimum enrollment and disenrollment trends in each managed care plan. Additionally, 42 CFR 438.66(e) requires states to submit to CMS a report on each of their Medicaid managed care programs that provides information on and an assessment of the operation of the managed care program. Further, section 1852(b)(1) of the Act prohibits discrimination by MA organizations on the basis of health status-related factors and directs that CMS may not approve an MA plan if CMS determines that the design of the plan and its benefits are likely to substantially discourage enrollment by certain MA eligible individuals. In addition, MA organizations must comply with applicable Federal civil rights laws that prohibit discrimination on the basis of race, color, national origin, sex, age, or disability, including section 1557 of the Affordable Care Act, Title VI of the Civil Rights Act of 1964, section 504 of the Rehabilitation Act of 1973, and the Age Discrimination Act of 1975. The regulation at 42 CFR 422.110 provides that an MA organization may not deny, limit, or condition the coverage or furnishing of benefits to individuals eligible to enroll in an MA plan offered by the organization on the basis of any factor that is related to health status. MA organizations discouraging or preventing enrollment in an MA plan by beneficiaries by implementing burdensome prior authorization processes to avoid approving services would be prohibited by 42 CFR 422.110. CMS relies on the MA anti-discrimination provision; the agency’s authority under section 1856(b) of the Act to adopt standards for MA organizations; and the agency’s authority under section 1857(e) of the Act to add terms and conditions that are necessary, appropriate, and not inconsistent with the Medicare statute. CMS does not collect detailed information on prior authorization policies as part of the bid. However, CMS will continue to monitor for potential discrimination by plans through prior authorization and other utilization management programs in our review of complaints received from beneficiaries and providers and will take action, as necessary. CMS may also consider future sub-regulatory guidance based on a review of complaints. We also believe that MA and other managed care plans will use the published data to drive performance E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8892 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations improvement to facilitate provider network development and that providers will use the prior authorization metrics to evaluate managed care plans and make decisions on whether to join or remain part of a plan’s network. Comment: A commenter recommended that if CMS intends to require public reporting in the final rule, CMS should explain how the data would benefit interested parties and conduct education and outreach to prevent confusion or misinterpretation of data. Multiple commenters stated their hesitation to require public reporting of prior authorization data without understanding the purpose of the reporting, and another recommended that CMS reevaluate the need and value of payers reporting the prior authorization metrics versus its costs and resource burden. Multiple commenters highlighted the significant new administrative burden that reporting prior authorization metrics would cause. Other commenters recommended that CMS remove the proposed requirement for payers to publicly report prior authorization metrics. Response: We are aware that payers have many reporting requirements for state and Federal programs and that preparing these public disclosures may require additional effort. Payers also provide educational resources to patients and providers for enrollment, directories, and other health care reminders—all to explain benefits and services and improve the health care experience. We are finalizing policies in this final rule to address longstanding, important process challenges related to prior authorization. Reporting on these metrics, including, for example, the services that require prior authorizations, the number of denials, those approved, and those overturned after appeal, will give the patients and providers a better understanding of payer performance in those categories— and over time—of the changes in performance in those categories. These data will demonstrate the intended impact of these policies. Public reporting is one of the most universal, effective means to demonstrate improvement or change. This public reporting has value because it can provide a benchmark for patients or providers to understand, at a high level, the volume of services a payer approves or denies, the types of services it authorizes, or changes in those decisions over time. Not all patients will use or necessarily understand all of the data, but it may help support the beginning of a conversation between VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 either the patient and the payer, or the patient and the provider. We anticipate payers will identify the most appropriate locations on their website for the information to be public. We additionally note that the Medicare FFS program currently publicly reports prior authorization metrics on its website and invites payers to reference the presentation of those metrics as they develop their public reporting strategy.147 Comment: A commenter recommended that a voluntary consensus SDO should develop standardized codes that could be used to document prior authorization denial reasons. Then, CMS could revise the metrics to include information on the reason for denial to provide a more complete picture of a plan’s prior authorization process. Response: As discussed previously in the section on providing a reason for denial, the standard codes for denial reasons are an external code set maintained by X12, which is a voluntary SDO. Any organization or individual interested in providing updates to this code set may do so by submitting a request to X12. At this time, we are not requiring payers to publicly report the reason for denial in these reporting metrics; that information is only provided to the requesting provider and the patient. Comment: Another commenter recommended that state Medicaid agency reporting requirements be changed to begin 1 year following the implementation of the APIs (by March 31 of each year). Another commenter stated that the proposed metrics do not align with the data elements required to be reported for appeal for the Managed Care Annual Care Program Report (MCPAR) that states are required to report. The commenter stated that alignment is necessary to assess the impact of an MCO, PHIP, or PAHP’s prior authorization determinations on beneficiary access to requested services. Response: We disagree that any payer should begin their reporting period substantially after any other payer, as all payers already have data to support their prior authorization activities. Even if a state Medicaid agency were granted an exception or extension, their prior authorization processes are already in effect and they have data regarding their current prior authorization activities. The final action statement in this 147 Centers for Medicare and Medicaid Services (2023, September 15). Prior Authorization and PreClaim Review Initiatives. Retrieved from https:// www.cms.gov/data-research/monitoring-programs/ medicare-fee-service-compliance-programs/priorauthorization-and-pre-claim-review-initiatives. PO 00000 Frm 00136 Fmt 4701 Sfmt 4700 section of the final rule includes the compliance dates and reporting requirements for impacted payers, which remains March 31, 2026, for reporting data for the prior year. Concerning the MCPAR, alignment is neither necessary nor feasible. The MCPAR collects information specifically on appeals, and we are requiring information specifically on prior authorization. While it is true that a denied prior authorization could generate an appeal, that is not relevant to these two reporting vehicles. We may revise the data collected in the MCPAR in the future and will use the existing data from the MCPAR and this reporting to inform any such revisions. Comment: Multiple commenters recommended that CMS develop standard guidance or IGs for payers to have a set format and consistent calculation of the metrics. A commenter flagged that the lack of guidance on report formatting could lead to a wide variation across impacted payers. Another commenter stated that CMS should issue the guidance and allow adequate time for impacted payers and vendors to make the appropriate modification to their system before public reporting begins. A commenter sought clarification as to whether the public reporting of prior authorization metrics would only apply to prior authorization requests that are received on or after the compliance dates. Another commenter recommended that rule language specify the data required, ensure the data are placed prominently on the payers’ websites, and indicate the cadence at which payers must refresh the publicly reported data. Many other commenters suggested various dissemination mechanisms for the prior authorization metrics. A commenter stated that they support an active distribution method for the prior authorization metrics, like a newsletter. Another commenter recommended that prior authorization metrics be available to be downloaded in Excel and PDF. Response: The Medicare FFS program currently publicly reports prior authorization metrics on its website and invites payers to reference the presentation of those metrics as they develop their public reporting strategy. We will consider what additional support we can provide to impacted payers before the compliance date of the final rule regarding recommended content and format for use in their public reports. The requirement for data in the first report for prior authorization metrics to include information about prior authorization activity for the prior year will provide a baseline for impacted payers as well as the public. E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations The reporting requirement applies to prior authorization requests that were received the year before the compliance date. Comment: Multiple commenters recommended that CMS report the required prior authorization information on the CMS website. A commenter stated that this will enable easy retrieval of data by physicians and patients, especially for plan comparison. Another commenter stated that CMS should also make sure it publishes this information on pages of its website that correlate to a particular payer. A commenter stated that CMS should report on the impact prior authorization has on the quality of care patients receive, potential delays in care, and associated cost savings due to the prior authorization process. The commenter suggested that reporting these data can help policymakers, researchers, providers, and patients make more informed decisions about the prior authorization process, ensuring that patient care remains central. Multiple commenters recommended that instead of payers publicly reporting metrics, there should be confidential reporting to CMS so it can track outliers and avoid misleading patients on data that are not comparable across plans. Another commenter recommended that CMS consider confidential payer reporting to CMS until the Prior Authorization API experiences significant uptake by providers. Response: We considered requiring that payers submit their reports to a central website for publication. However, as we explained in the CMS Interoperability and Prior Authorization proposed rule (87 FR 76347), we did not select this alternative because we believe patients likely would view their health plan and payer as the resource for information about their plan. While CMS does provide comparative data for plans in certain programs (for example, the MA program) and may use such information in future public reports, we are not finalizing such an approach in this rule. Patients should be able to find information about their plan or payer from those websites to minimize burden and confusion. For Medicaid and CHIP, patients generally associate their coverage with their state or managed care plan, not CMS. While having the prior authorization data posted on each payer’s website is the most appropriate place, we also encourage state Medicaid agencies to include the data on their websites (which are required by 42 CFR 438.10(c)(3)) to improve the value of information available to their patients. Similarly, MA patients look to their MA organization websites for information VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 and resources about those plans and their performance. Payers must already include significant patient resource information on their websites, and CMS will conduct outreach to payers, patients, and providers to help provide guidance on best practices about the website locations for such public reporting of prior authorization information. In our oversight role, we may begin to look at data after the compliance date to evaluate compliance with these new reporting requirements. CMS may consider additional reporting requirements as well as publication of comparative information in the future. Comment: Multiple commenters stated it would be helpful for additional context to explain metrics in the event of an outlier, such as explaining denial or approval rates for services-related data. Multiple commenters suggested including the total number of requests approved/denied, rather than only aggregate percentages. A commenter stated that they also would like to see specific data for common services to show a direct comparison across different payers and plans as certain prior authorization requests are more complex than others. Multiple commenters stated that service-specific reporting will aid in identifying services for which there is a high rate of approval and for which prior authorization requirements may no longer be necessary, or for identifying critical services or items being routinely denied. A commenter recommended CMS require payers to provide more detailed information by item or service including Healthcare Common Procedure Coding System (HCPCS) code, Current Procedural Terminology (CPT) code, and International Classification of Diseases, Tenth Revision (ICD–10) code. Other suggestions included requiring payers to report disaggregated data by diagnosis, race and ethnicity, gender, and age. A commenter warned that without itemand service-level reporting, it will be impossible for CMS and the public to understand some data and to hold impacted payers accountable for excessive denials and delays in responding to prior authorization requests. Other commenters recommended CMS require payers to report data with setting-specific data or by type of provider (for example, physician, short-term care, long-term care, rehabilitation, psychiatric, and skilled nursing services). A commenter stated that only with this setting level of specificity will patients and providers be able to assess which services are routinely denied, appealed, and overturned in favor of patients and PO 00000 Frm 00137 Fmt 4701 Sfmt 4700 8893 providers. Another commenter warned that segmentation by the provider should encompass short-term acute care, long-term care, rehabilitation, psychiatric, and skilled nursing services to allow consumers, providers, and regulators to gain a better understanding of prior authorization processes and where there is a need for improvement. A commenter recommended that CMS should require metrics be broken down at the Health Care Provider Taxonomy code set Level II, Classification, which is a code set used in HIPAA standard transactions. Another commenter recommended that the metrics be reported by the payer based on service type, site of care, and whether the service is inpatient or outpatient. Another commenter wanted CMS to compare the metrics for MA organization plans to Medicare FFS and commercial health plans. Response: Service-specific and demographic reporting may be very useful to the impacted payers in evaluating their programs and expect that they use such data today and will continue to do so as they implement the policies of this final rule. While we agree that there could be many more reporting requirements, and at more granular levels, and data are an important tool for different evaluation purposes, reporting should serve its intended purposes and not become a burden to the users. Too much data can also become overwhelming. We anticipate patient and provider feedback following implementation and will review opportunities after that time. We agree that it would be appropriate to compare the metrics for all payers several years after the policies of this final rule have been implemented to determine its impact on the prior authorization barriers and burdens. However, commercial plans other than QHPs on the FFEs are not subject to the provisions of this rule, and CMS does not have access to performance data for those organizations. If states are collecting such data, they might be able to analyze the data at the state level. b. Publication of Prior Authorization Metrics We requested comments on how the information might be displayed on payer websites in a useful and meaningful manner for patients and providers, including which data would be most useful. The summarized comments and our responses follow. Comment: Multiple commenters recommended that the prior authorization metrics be presented in a readable and accessible format, particularly for individuals with E:\FR\FM\08FER2.SGM 08FER2 8894 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations disabilities, individuals with limited or low health and data literacy, and individuals with limited English proficiency. Other commenters recommended that CMS require plans to write publicly reported data at a sixth grade reading level, conduct consumerfocused testing on data readability, and provide translations in multiple languages. Multiple commenters recommended that CMS should require payers to provide access to prior authorization data in multiple languages (based on the most common languages in a community) and in a format that is comprehensible to the average consumer. A commenter recommended CMS should make the reported payer data patient-friendly and public to enable comparison of metrics. Response: We appreciate commenter suggestions that payer data be ‘‘patientfriendly,’’ easy to understand, and in an accessible format. We may consider how best to provide guidance to encourage impacted payers to develop their reports with these factors in mind, as the intent of these public reports is to ensure that individuals can use and interpret the information. lotter on DSK11XQN23PROD with RULES2 c. Types of Prior Authorization Metrics Impacted payers are required to post a general set of prior authorization metrics on their public websites to support process improvement, as well as patient and provider insight into trends for different payers. While the data will not be submitted to CMS at this time, it will be available for public VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 review and evaluation and may be informative as experience with the new policies evolves. Comment: Some commenters wrote that CMS should include more data on use of the Prior Authorization API. A commenter suggested certain metrics be considered for adoption: the number of requests initiated using the Prior Authorization API, average response time for requests not requiring a prior authorization, the number of requests initiated using the Prior Authorization API requiring a prior authorization, the number of requests initiated using the Prior Authorization API requiring a prior authorization that had all of the required documentation available automatically, the percentage of Prior Authorization API requests requiring a prior authorization with all required documentation available processed automatically, the number of requests initiated using the Prior Authorization API requiring a prior authorization that were unable to automatically supply required documentation, and a list of all SMART on FHIR app/EHR combinations or equivalent technology used for Prior Authorization API requests at provider organizations. A commenter encouraged CMS to consider breaking reporting out by prior authorization transactions supported by a FHIR API transaction and those otherwise conducted. Response: The intended goal of publicly reporting these metrics is to help providers and patients gain insights into the payers’ prior PO 00000 Frm 00138 Fmt 4701 Sfmt 4700 authorization practices and performance, and to assist payers in evaluating their prior authorization practices. While the performance and utilization of the Prior Authorization API is valuable information for assessing the adoption and use of the API itself, it may not adequately represent the full scope of a payer’s prior authorization practices. As noted in a prior response, we may consider issuing guidance before the compliance date with more specifics on the recommended format and content; however, the lack of regulations or guidance on the format and content does not prevent payers from including additional information that could be of value to patients and providers. 8. ‘‘Gold-Carding’’ Programs for Prior Authorization We solicited comments on the potential for gold-carding or prior authorization exemption programs and how they might reduce provider and payer burden and improve services to patients. We also solicited comments on the incorporation of such a measure into Star Ratings for these organizations. We received several comments on this topic and appreciate the input. Since no policies were proposed, we are not finalizing policies in this area at this time. We thank commenters for their feedback and will consider all comments for possible future rulemaking. BILLING CODE 4150–28–P E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 VerDate Sep<11>2014 TABLE E4: IMPROVING PRIOR AUTHORIZATION PROCESSES FINAL POLICIES 11.D.3.a. I 11.D.3.b. I Jkt 262001 I PO 00000 Frm 00139 Fmt 4701 Sfmt 4725 11.D.4.c. I E:\FR\FM\08FER2.SGM Prior Authorization API (Compliance date January 1, 2027) Information About the Status of Prior Authorization (Compliance date Januarv 1, 2027 Denial Reason for Prior Authorization (Compliance date Januarv 1, 2026) Standard Prior Authorization Decision Timeframe (Compliance date January 1, 2026) 08FER2 42CFR 422.122(b) NIA 42CFR 431.80(b) 42CFR 422.122(b)(4) NIA 42CFR 431.80(b )(4) 42CFR 422.122(a) 42CFR 422.122(a) 42CFR 431.80(a) 42CFR 422.568(b )(1) 42CFR 422.63 l(d)(2) (i)(B) 42CFR 440.230(e)(1 )(i ) No change to existing rules on the timing. 42CFR 422.63 l(d)(2) (iv) 42CFR 440.230(e)(1 )(i i) NIA NIA 42CFR 431.80(c)(l) Through cross reference to 42 CFR431.80(b) at42 CFR 438.242(b)(7) Through cross reference to 42 CFR 431.80(b) at42 CFR 438.242(b)(7) 42CFR 457.732(b) Through cross reference to 42 CFR 431.80(a) at42 CFR 438.242(b)(8 42CFR 438.210(d)(l) 42 CFR 1 457.732(a) Through existing 145 CFR cross reference 156.223(b) to 42 CFR 438.242 at 42 CFR 457.1233(d) 45CFR 156.223(b) (4) 42CFR 457.732(b)(4) 45 CFR 1 156.223(a) I 42CFR 457.495(d)(l) Through existing cross reference to 42 CFR 438.210 at 42 CFR 457.1230(d) 42CFR 438.210(d)(2) 42CFR 457.495(d)(l) NIA NIA 42CFR 457.732(d)(l) NIA I NIA I 11.D.4.c. 11.D.6. Expedited Prior Authorization Decision Timeframe (Compliance date Janu 1, 2026 I Extension for State Medicaid and CHIP FFS (Effective Date of the Final Rule I I NIA NIA Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations 18:23 Feb 07, 2024 11.D.2.a. 8895 ER08FE24.008</GPH> lotter on DSK11XQN23PROD with RULES2 8896 Jkt 262001 I PO 00000 Frm 00140 Fmt 4701 Sfmt 4700 E:\FR\FM\08FER2.SGM 08FER2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations 18:23 Feb 07, 2024 BILLING CODE 4150–28–C VerDate Sep<11>2014 ER08FE24.009</GPH> Exemption for 42CFR I NIA I NIA 42 CFR I NIA I NIA I 431.80(c)(2) I NIA 1 457.732(d)(2) State Medicaid and CHIP FFS (Effective Date of the Final Rule 45 CFR 11.D.6. I Exceptions for NIA NIA NIA NIA NIA NIA 1 156.223(d) QHP Issuers on the FFEs (Effective Date of the Final Rule 11.D.7. I Public Reporting 42CFR 42CFR 42CFR 42CFR 42CFR Through existing 145 CFR 422.122(c) 422.122(c) 440.230(e)(3) 438.210(f) 457.732(c) cross reference 156.223(c) for Prior Authorization to 42 CFR Metrics 438.210 at 42 (Compliance date CFR March 31, 2026) 457.1230(d) 11.D.7. 42CFR 42CFR NIA 42CFR NIA 45 CFR I Prior 1 156.223(c) 422.122(c) 422.122(c) 438.210(f) Authorization Metrics Compliance Date (Compliance date March 31, 2026 *This table contains new regulatory citations and cross references to the new regulatory citations only. Tables E2 and E3 contain additional prior authorization requirements that are reflected in amendments to previously existing regulations. For information on existing regulations that support these new policies, please review the preamble in each of the sections listed in this table. 11.D.6. Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations lotter on DSK11XQN23PROD with RULES2 9. Final Action After considering the comments received, and for the reasons discussed in the CMS Interoperability and Prior Authorization proposed rule and our response to those comments (as summarized previously), we are finalizing our proposals with the following modifications: • Impacted payers must implement and maintain a Prior Authorization API beginning 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs) rather than in 2026. • MA organizations must report prior authorization metrics at the contract level rather than at the proposed organization level. See further discussion for exact details of the final requirements for impacted payers. We are finalizing that, beginning 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs), impacted payers must implement and maintain a Prior Authorization API that is compliant with certain technical standards, documentation requirements, and denial or discontinuation policies. Specifically, those technical standards are HL7 FHIR at 45 CFR 170.215(a)(1), US Core IG at 45 CFR 170.215(b)(1)(i), and SMART App Launch IG at 45 CFR 170.215(c)(1). We are finalizing that, by the compliance dates, impacted payers must implement a Prior Authorization API that: • Is populated with the payer’s list of covered items and services (excluding drugs) that require prior authorization; • Can identify all documentation required for approval of any items or services that require prior authorization; • Supports a HIPAA-compliant prior authorization request and response; and • Communicates whether the payer approves the prior authorization request (and the date or circumstance under which the authorization ends), denies the prior authorization request (with a specific reason), or requests more information. We are finalizing that, beginning 2026 (by January 1, 2026, for MA organizations and state Medicaid and VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 CHIP FFS programs; by the rating period beginning on or after January 1, 2026, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2026, for QHP issuers on the FFEs), impacted payers’ must provide a specific reason for a denial within their decision timeframe regardless of the method that was used to send the prior authorization request or decision. We are finalizing that, beginning in 2026, MA organizations, including applicable integrated plans, state Medicaid and CHIP FFS programs, and Medicaid managed care plans and CHIP managed care entities must provide notice to providers and patients of prior authorization decisions as expeditiously as a patient’s health condition requires, but no later than 7 calendar days for standard requests, unless a shorter minimum timeframe is established under applicable state law. We are finalizing that, beginning in 2026, MA organizations, including applicable integrated plans, and state Medicaid and CHIP FFS programs, must provide notice to providers and patients of prior authorization decisions as expeditiously as a patient’s health condition requires, but no later than 72 hours for expedited requests, unless a shorter minimum timeframe is established under applicable state law. That requirement already exists for Medicaid managed care plans and CHIP managed care entities, but for consistency with Medicaid FFS, we are finalizing that those payers must also send notices to patients and comply with a shorter timeframe, if established by state. In response to public comments, CMS will work with state Medicaid and CHIP FFS programs that may be unable to meet the new prior authorization decision timeframes compliance date in 2026. States should contact their Medicaid state lead or CHIP project officer before April 1, 2025, to discuss their extenuating circumstances. Any flexibility granted to a state Medicaid or CHIP FFS program for the implementation of the new prior authorization decision timeframes requirements will be temporary and limited to the unique circumstances of the program. We are finalizing that, as of the effective date of this final rule, existing Medicaid beneficiary notice and fair hearing regulations apply to Medicaid FFS prior authorization decisions. We are finalizing that, beginning in 2026, impacted payers must annually report certain aggregated prior authorization metrics. Specifically, by March 31, MA organizations at the PO 00000 Frm 00141 Fmt 4701 Sfmt 4700 8897 contract level, state Medicaid and CHIP FFS programs at the state level, Medicaid managed care plans and CHIP managed care entities at the plan level, and QHP issuers on the FFEs at the issuer level must post the required metrics on their websites. Impacted payers must publicly report the previous calendar year’s metrics by March 31 following any year that they offered that type of plan. These policies apply to MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs at the CFR sections listed in Table E4. 10. Statutory Authorities To Require Improvements in Prior Authorization Processes, Decision and Notification Timeframe Policies We did not receive any public comments on the statutory authorities for the Prior Authorization API and prior authorization process policies discussed in this section. a. Medicare Advantage Section 1856(b) of the Act directs the Secretary to establish regulatory standards for MA organizations that are consistent with, and carry out, Part C of the Medicare statute, including the provisions in section 1852 of the Act. Section 1852(a) and (d) of the Act provide for MA plans to cover medically necessary Part A and Part B benefits, including by making benefits available and accessible with reasonable promptness. Section 1852(c)(1)(G) of the Act requires that MA organizations disclose to their enrollees any rules regarding prior authorization or other review requirements that could result in nonpayment. Section 1852(g)(1)(A) of the Act requires an MA plan to have a procedure for making determinations about whether an enrollee is entitled to receive a health service, how much the enrollee is required to pay for such service, and to provide an enrollee with a written notice if the plan denies coverage. Section 1852(g)(1)(A) of the Act also requires that coverage determinations be made on a timely basis. Section 1852(g)(3)(B)(iii) of the Act requires that the organization notify the enrollee (and physician involved, as appropriate) of an expedited determination (and reconsideration) under time limitations established by the Secretary, but not later than 72 hours after the time of receipt of the request. The prior authorization requirements in this final rule ensure that MA organizations carry out their responsibilities under section 1852 of the Act in a consistent and standardized E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8898 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations fashion and in compliance with standards that carry out and serve the purposes of the MA program. Under the authorities referenced previously, we are finalizing certain requirements for MA organizations. These requirements are to ensure that MA organizations provide enrollees with appropriate access to care and information by using certain standards, technologies, and business processes. The requirements include implementing certain APIs that provide information about the coverage and documentation requirements for prior authorization, responding to prior authorization requests with the status of that request, and meeting certain timeframes for making decisions on prior authorization requests. We are requiring that MA organizations implement the Prior Authorization API using certain implementation specifications as discussed in section II.G. of this final rule. These implementation specifications are expected to improve the overall prior authorization process by addressing deficiencies that exist in the process today concerning providers’ access to information about the prior authorization rules and documentation requirements. The Prior Authorization API will communicate the coverage and documentation requirements for prior authorization, indicating if authorization is required for a specific item or service and what documentation is required to support an authorization request. Use of the Prior Authorization API is consistent with the disclosure obligation on MA organizations in section 1852(c)(1)(G) of the Act by disclosing to providers the same information that generally must be provided to enrollees about which covered benefits are subject to prior authorization and serves the same larger purpose of ensuring access to coverage by communicating the limits and rules for covered services. Additionally, the Prior Authorization API is a mechanism for receiving and responding to requests for coverage determinations before the services are rendered or items furnished; therefore, the requirement to adopt and use the Prior Authorization API is an additional standard for implementing and complying with section 1852(g) of the Act regarding an MA organization’s obligation to make coverage determinations. The Prior Authorization API will enable the provider to submit a HIPAA-compliant prior authorization request through their existing workflow and receive a timely response to that request. In concert with these APIs, we are requiring the payer to provide the VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 status of the request, such as whether it was approved or denied, along with a specific denial reason, so that the provider knows what steps to take next—whether to request a different service for the patient, to submit additional information, or to appeal the decision. These final requirements will improve patient care and reduce redundancies in administrative processes between providers and payers because they give providers clearer instructions, both for submitting the original request and, if necessary, providing additional information. The required API has the potential to improve the efficiency of the prior authorization process because it enables providers to submit accurate information with the request, which could reduce the number of appeals or denials, and possibly eliminate requests for additional documentation. We expect the prior authorization policies in this final rule to improve timely access to care for beneficiaries by mitigating delays that sometimes occur when a provider is trying to determine coverage requirements or does not know what documents to submit to obtain approval for a service. Improvements in the timeliness of payer operations and provider services will contribute to program efficiency, and effective operations and will be in the best interest of the enrollees. The requirement for MA organizations to make certain changes to the timeframes in which they provide notice for prior authorization has the potential to improve patient access to care in program operations as discussed in section II.D.5. of this final rule. This could prevent some patients from abandoning care while waiting for authorization, and it could improve efficiencies by avoiding repeat phone calls from providers who must check on the status of authorization over several days, or sometimes weeks. We finalized requirements to improve some timeframes for expedited and standard decisions under the premise that these changes are overdue, feasible, and would benefit patients and providers. Furthermore, by establishing more certainty in the process for providers, there may be a reduction in unnecessary repeat requests for services. More responsive timeframes will also enhance enrollee access to timely and appropriate care. A shorter timeframe for both standard and expedited decisions may reduce administrative time and expense for providers and payers, as they would spend fewer resources on follow-up inquiries. As such, these requirements are consistent PO 00000 Frm 00142 Fmt 4701 Sfmt 4700 with our authorities to adopt standards to carry out and implement the requirements in section 1852 of the Act for MA organizations to have a procedure for making timely determinations and to make benefits available and accessible with reasonable promptness. Finally, section 1857(e)(1) of the Act explicitly authorizes the adoption of additional reporting requirements by MA organizations where necessary and appropriate. The requirement for MA plans to publicly report prior authorization metrics will enable CMS to assess the implementation of the policies and attempt to determine the impact of these new requirements on payers and providers. A review of these metrics may help CMS and the plans understand the impact of the requirements, including the impact of using the APIs and improved decision timeframes. The data may also help plans evaluate operations, implement new policies and the API, and determine what changes may be appropriate. b. Medicaid For Medicaid, most of the requirements finalized in this section are authorized by sections 1902(a)(4), (8), and (19) of the Act. Section 1902(a)(4) of the Act requires that a state Medicaid plan provide such methods of administration as are found by the Secretary to be necessary for the proper and efficient operation of the state Medicaid plan, section 1902(a)(8) of the Act requires states to ensure that Medicaid services are furnished with reasonable promptness to all eligible individuals, and section 1902(a)(19) of the Act requires states to ensure that care and services under a Medicaid state plan are provided in a manner consistent with the simplicity of administration and the best interests of the recipients. Some requirements finalized in this section are also authorized by additional sections of the Act as discussed in this section of the final rule. Additionally, section 1902(a)(7) of the Act requires that states must provide safeguards that restrict the use or disclosure of information concerning Medicaid applicants and beneficiaries to purposes that are directly connected with the administration of the program or plan. The implementing regulations at 42 CFR part 431, subpart F, for this section 1902(a)(7) of the Act list purposes that CMS has determined are directly connected with the administration of Medicaid state plans (42 CFR 431.302) and require states to provide safeguards meeting certain E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations requirements to restrict uses and disclosures of Medicaid beneficiary data. CHIP programs are subject to the same requirements through a cross reference at 42 CFR 457.1110(b). Our finalized policy that the data described in this section be shared via the Prior Authorization API is consistent with the requirement at section 1902(a)(7) of the Act, providing that states may share these data only for purposes directly connected with the administration of the Medicaid state plan. This data sharing policy for the Prior Authorization API is related to providing services for beneficiaries, a purpose listed at 42 CFR 431.302(c). The services include those for which the state requires that a provider submit a prior authorization request, and thus needs to communicate about that prior authorization with other providers enrolled with or authorized by the state to provide care to its beneficiaries. Prior authorization can be an integral part of the Medicaid program and facilitates access to care as well as provider payment processes. We remind states that to meet the requirements of the regulations at 42 CFR part 431, subpart F, states must have consistent criteria for the release and use of information (which should comply with the proposed Prior Authorization API requirements), in accordance with 42 CFR 431.306(a). Access to information concerning beneficiaries must be restricted to persons who are subject to standards of confidentiality that are comparable to that of the state Medicaid agency, in accordance with 42 CFR 431.306(b). Similar to the Provider Access API discussed previously, the permission requirement at 42 CFR 431.306(d), which requires that the state agency obtain permission from a family or individual, whenever possible, before responding to a request for information from an outside source, is not relevant to the Prior Authorization API, because any request for beneficiary information would be from an enrolled Medicaid or CHIP provider and thus would not be from an outside source. While the beneficiary’s permission is not required under 42 CFR 431.306(d) for the Prior Authorization API, state or other laws may require such permission. When requesting approval to provide certain services from the state using the state’s Prior Authorization API as described in section II.D.2.a. of this final rule, the provider will be able to determine if prior authorization is required and what supporting documentation is necessary to obtain approval for that care. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 i. Prior Authorization API The requirement for state Medicaid FFS programs and Medicaid managed care plans to implement the Prior Authorization API is expected to improve the efficiency and timeliness of the prior authorization process for Medicaid beneficiaries, providers, state Medicaid agencies, and Medicaid managed care plans by addressing inefficiencies that might exist in the process today. As discussed in section II.D.2.a. of this final rule, the Prior Authorization API will allow a provider to determine whether a prior authorization is required and the documentation requirements for that prior authorization request. The Prior Authorization API will: • Enable providers to submit a complete prior authorization request faster and easier; • Support more timely notice to the provider and beneficiary of the disposition of the prior authorization request; and • Permit improved scheduling of services or filing appeals, depending on the decision. The Prior Authorization API has the potential to improve the prior authorization process by making it more efficient, including by reducing the number of denials and appeals, or even by eliminating requests for additional documentation, as noted elsewhere in this final rule. ii. Requirement for Payers To Provide Specific Reason for Denial of Prior Authorizations Based on the provisions of this final rule, states and Medicaid managed care plans must provide specific information to providers about the status of prior authorization requests to enable providers to plan care for their patients after submitting a prior authorization request. As discussed in section II.D.3. of this final rule, when providers receive a response to a prior authorization request, the payer will typically indicate whether the request is approved, or denied, or if additional information is needed. If prior authorization has been denied, the payer must give the provider the specific reason for the denial; that information may be used by the provider to decide next steps, such as re-submitting the request with updated information, identifying alternative treatments for the patient, or appealing the decision. These requirements will improve the timeliness, clarity, and consistency of information for providers regarding prior authorization requests; help providers determine the next steps for timely patient care; and reduce PO 00000 Frm 00143 Fmt 4701 Sfmt 4700 8899 payer, provider, and patient burden by eliminating the need for repeated inquiries. iii. Requirements for Prior Authorization Decision Timeframes, Notifications Related to Prior Authorization Decision Timeframes, and Amendments to Existing Medicaid Fair Hearings and Appeals Regulations As discussed in section II.D.5. of this final rule, delayed prior authorization decisions may directly affect patient care by delaying access to treatment, services, and supplies, as well as transfers between hospitals and postacute care facilities. The required timeframes for making prior authorization decisions about items and services that require prior authorization in Medicaid FFS and managed care programs will help providers better manage administrative resources, make more time available for providers to render patient care, and facilitate faster access to services. These requirements should make substantive improvements to the care experience for Medicaid beneficiaries and lead to better health outcomes. In turn, better health outcomes will contribute to more efficient use of Medicaid program resources. The requirement to shorten the maximum amount of time for a Medicaid managed care plan to make a prior authorization decision from 14 calendar days to 7 calendar days will improve the efficient operation of the Medicaid program by facilitating faster receipt of services or filing of appeals. Our amendment to explicitly state in the regulation text that current notice and fair hearing requirements apply to Medicaid FFS prior authorization decisions is authorized under section 1902(a)(3) of the Act. Section 1902(a)(3) of the Act requires that a Medicaid state plan provide an opportunity for a fair hearing to any individual whose claim for medical assistance under the plan is denied or is not acted upon with reasonable promptness. This is also supported by the 14th Amendment to the United States Constitution and case law on due process, specifically, Goldberg v. Kelly, 397 U.S. 254 (1970). States must establish timely notice and fair hearing processes meeting due process standards under Goldberg v. Kelly, as incorporated into existing Medicaid fair hearing regulations at 42 CFR part 431, subpart E, see 42 CFR 431.205(d). Additionally, section 1902(a)(17) of the Act requires state Medicaid plans to include reasonable standards for determining the extent of medical assistance under the plan that are E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8900 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations consistent with the objectives of Title XIX of the Act. As set forth at 42 CFR 440.230, the standards that states establish under section 1902(a)(17) of the Act could include appropriate limits on a service based on such criteria as medical necessity or on utilization control procedures, as long as each service is sufficient in amount, duration, and scope to reasonably achieve its purpose. Items and services covered under Title XIX benefit authorities are subject to 42 CFR 440.230, unless statute or regulation expressly provides for an exception or waiver. This would include covered items and services described in sections 1905(a), 1915(c), 1915(i), 1915(j), 1915(k), 1915(l), 1937, and 1945 of the Act, and any other authorities as established by Congress. The standards that states establish under section 1902(a)(17) of the Act and 42 CFR 440.230 could include prior authorization requirements. The requirements to establish timeframes for prior authorization decisions are authorized under section 1902(a)(17) of the Act because they would be expected to help ensure that states make prior authorization decisions in a manner that is consistent with the requirements in section 1902(a)(4), (a)(8), and (a)(19) of the Act, thus helping to ensure that states’ standards for determining the extent of medical assistance under the plan are consistent with the objectives of Title XIX. Section 1932(b)(4) of the Act provides that each Medicaid MCO must establish an internal grievance procedure whereby a beneficiary who is eligible for medical assistance may challenge the denial of coverage or payment for such assistance. CMS has implemented requirements for those procedures at 42 CFR 438.210, which applies the same appeal and grievance requirements for PIHPs and PAHPs as for Medicaid MCOs. We rely on our authority in section 1902(a)(4) of the Act to adopt standards for PIHPs and PAHPs that mirror requirements for MCOs. This is consistent with our prior practice for adopting standards for Medicaid managed care plans (81 FR 27507). We rely on the same authority here to revise the procedures under which Medicaid managed care plans may make prior authorization decisions about coverage and provide those decisions to providers and enrollees. Reducing plan response time for prior authorization decisions may enable beneficiaries to file appeals if necessary and receive a resolution to those appeals sooner. The earlier an appeal is filed, and the disposition known, the sooner the provider and beneficiary can determine VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 whether to request a state fair hearing or to identify treatment alternatives, if necessary. The prior authorization requirements in this rule are also consistent with how section 1932(c)(2)(A)(i) of the Act requires MCO contracts to contain a provision for an annual external quality review of quality outcomes and access to and timeliness of covered services. If the shorter prior authorization response requirements successfully improve workflow and processes that facilitate timely access to services, improvements to the care experience for patients, and better health outcomes, the results should be visible in external reviews. This requirement reflects the importance and potential advantages of timely access for beneficiaries to covered services through more efficient processing of prior authorization requests as proposed in this rule. the implementation of corrective action as well as helping beneficiaries select a Medicaid managed care plan that best meets their needs may improve the promptness with which services are provided to beneficiaries. Section 1902(a)(19) of the Act authorizes this requirement because identifying prior authorization process weaknesses or deficiencies and enabling the implementation of corrective action will help ensure that care and services are provided in a manner consistent with the simplicity of administration. Additionally, implementation of corrective action to improve prior authorization processes, helping beneficiaries select a managed care plan that best meets their needs, and helping providers make informed decisions on which Medicaid managed care plan networks to join is in the best interest of beneficiaries. iv. Public Reporting of Prior Authorization Metrics We are also requiring Medicaid FFS programs and Medicaid managed care plans to publicly report certain prior authorization metrics by posting them on the payer’s website. As discussed in section II.D.7. of this final rule, publicly reporting these metrics may support more timely access to services by identifying prior authorization process weaknesses or deficiencies and enabling the implementation of corrective action, and for managed care programs, helping beneficiaries select Medicaid managed care plans that best meet their needs and helping some Medicaid providers make informed decisions on which Medicaid managed care plan networks to join. Section 1902(a)(4) of the Act authorizes this requirement because enabling more timely access to services by identifying prior authorization deficiencies and facilitating the implementation of corrective action to improve the prior authorization process will support the proper and efficient operation of the state Medicaid plan. Requiring Medicaid managed care plans to publicly report their prior authorization metrics will hold them accountable and enable them to monitor their performance and identify process improvement opportunities, which may be an integral part of implementing a quality assessment and improvement strategy more easily. This is consistent with the requirements for quality strategies for managed care programs at section 1932(c)(1)(A)(i) of the Act. Section 1902(a)(8) of the Act authorizes this requirement because identifying prior authorization process weaknesses or deficiencies and enabling c. CHIP For CHIP, we finalized these requirements under the authority of section 2101(a) of the Act, which sets forth that the purpose of Title XXI is to provide funds to states to provide child health assistance to uninsured, lowincome children effectively and efficiently that is coordinated with other sources of health benefits coverage. This provision authorizes us to adopt these requirements for CHIP to obtain access to program data for analysis. Such analysis supports improvements in the efficacy of CHIP programs and more efficient administration of services. As discussed previously, we are requiring the implementation of the Prior Authorization API in section II.D.2.a. of this final rule to improve the prior authorization process for patients, providers, and payers by addressing deficiencies and inefficiencies that exist currently. Today, a payer’s rules about when prior authorization is required and what documentation requirements must be fulfilled to submit the request are not necessarily easily accessible for providers. The Prior Authorization API will enable a provider to determine if a prior authorization is required electronically, in real-time and what the documentation requirements are regarding such requests. While we expect providers to be the primary beneficiaries of this API, making this information available in a standardized way and permitting access through an API will also serve the requirements in section 2101(a) of the Act that CHIP ensures access to coverage and coordinated care. The Prior Authorization API is a mechanism for receiving and responding to requests for coverage PO 00000 Frm 00144 Fmt 4701 Sfmt 4700 E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations determinations before the services are furnished; this API will streamline the initial authorization process for the payer by sharing this information in an easily accessible way. The API will also allow the provider to know what to do if prior authorization is required for a certain service, which will improve the provider’s ability to treat the patient timely. The Prior Authorization API enables the payer to send a real-time response back to a provider, based on the request for authorization. This, too, will improve the efficiency of providing services to the patient because the request and response are automated and in real-time. We expect payers’ use of this API to ensure that a provider can submit a request for prior authorization with the correct and complete documentation to avoid an incorrect submission which might result in an unnecessary denial. The Prior Authorization API will: (1) enable providers to submit a prior authorization request faster and easier; (2) support more timely notice to the provider and beneficiary of the disposition of the prior authorization request; and (3) permit faster scheduling of services or filing appeals, depending on the decision. The Prior Authorization API has the potential to improve the prior authorization process by making it more efficient, including limiting the number of denials and appeals, or even eliminating requests for additional documentation, as noted elsewhere. The safeguards for beneficiary information at 42 CFR part 431, subpart F, are also applicable to CHIP through a cross reference at 42 CFR 457.1110(b). As discussed previously for Medicaid, CHIP payers’ and providers’ data exchange through the Prior Authorization API is related to providing services to beneficiaries, which is described at 42 CFR 431.302(c) as a purpose directly related to state plan administration. We remind states that when they share medical records or any other health or enrollment information about individual beneficiaries, they must comply with the privacy protections at 42 CFR 457.1110 and the release of information provisions at 42 CFR 431.306. The requirement in section II.D.5. of this final rule that CHIP FFS and CHIP managed care entities meet certain timeframes to provide decisions for prior authorizations for expedited and standard decisions is an improvement from the current state, where there is uncertainty about expectations for when a prior authorization might be approved. This requirement is intended to establish more certainty in the prior authorization process for providers and VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 improve access to appropriate care for all patients, particularly those with chronic conditions or complicated health risks. Health parity may be increased as barriers due to process and timeframes will be removed. Similarly, improved process improvements may reduce administrative costs for providers and payers as redundancies will be removed from the system. We expect the requirement to improve timeliness in responding to providers and patients to support process improvements for the state and managed care programs and is consistent with our authorities under section 2101(a) of the Act in that it improves the efficiency of the CHIP programs. The policy to require CHIP FFS and CHIP managed care entities to publicly report prior authorization metrics will also support the states’ oversight, evaluation, and administration responsibilities. CMS may occasionally view some of the CHIP’s FFS and managed care websites to check for compliance, see how data are being reported, and determine if any trends in prior authorization changes could be indicative of the benefits of the prior authorization policies as discussed in section II.D.7. of this final rule. The data may indicate the use of the APIs, improvements in prior authorization numbers, or changes in total numbers, denials, and appeals. d. Qualified Health Plan Issuers on the Federally-Facilitated Exchanges For QHP issuers on the FFEs, we finalized the requirements in this section under the authority of section 1311(e)(1)(B) of the Affordable Care Act, which affords the Exchanges the discretion to certify QHPs if the Exchange determines that making available such health plans through the Exchange is in the interests of qualified individuals in the state in which the Exchange operates. The policies finalized here may improve the efficiency of the issuers that are certified to offer QHPs on the FFEs and improve the quality of services they provide to providers and their patients by increasing the efficiency in the prior authorization submission and review process. In section II.D.2.a. of this final rule, we are requiring that QHP issuers on the FFEs implement an API to support the prior authorization process. The Prior Authorization API will allow QHP issuers on the FFEs to communicate requirements for prior authorization more efficiently and enable providers to similarly operate more efficiently to determine when a prior authorization is needed and locate the documentation PO 00000 Frm 00145 Fmt 4701 Sfmt 4700 8901 requirements. The Prior Authorization API may enable more accurate submission and subsequent processing of prior authorization requests, with the potential of improving the delivery of services to patients. Qualified individuals enrolled in QHPs on the FFEs may receive covered services more quickly using the API. Similar to the other APIs, we believe that certifying only health plans that implement the Prior Authorization API and adhere to the other requirements described in this section of the preamble is in the interests of qualified individuals in the state or states in which a QHP issuer on the FFEs operates because of the opportunities for improvements in patient care, in alignment with the goals of the Affordable Care Act. We encourage SBEs to consider whether a similar requirement should apply to QHP issuers participating in their Exchanges. We are also requiring that QHP issuers on the FFEs provide a specific reason for denial when sending a response to a prior authorization request, to facilitate better communication and understanding between the provider and issuer. This may enable efficient and successful resubmission of the previously denied prior authorization request, which may more promptly facilitate the needed patient care. Finally, the requirement for QHP issuers on the FFEs to publicly report prior authorization metrics in section II.D.7. of this final rule will hold issuers accountable to their providers and patients, which could help these organizations improve their program administration. These data may help QHP issuers on the FFEs evaluate their processes and determine if there are better ways to leverage the APIs, including the quality and sufficiency of the coverage and documentation information included in the APIs. E. Extensions, Exemptions, and Exceptions and Federal Matching Funds for Medicaid and CHIP 1. Background The CMS Interoperability and Prior Authorization proposed rule discussed extensions, exemptions, and exceptions for state Medicaid and CHIP FFS Programs and QHP issuers on the FFEs, Federal funding available to states, and applicability to state Medicaid expansion programs for CHIP populations. As stated in the Provider Access, Payer-to-Payer, and Prior Authorization API sections of this final rule we are consolidated in one section the requirements for applying for an E:\FR\FM\08FER2.SGM 08FER2 8902 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations extension, exemption, or exception. Here we discuss those proposals, provide responses to the comments received regarding the proposals, and include the final policies. lotter on DSK11XQN23PROD with RULES2 2. Extensions, Exemptions, and Exceptions a. Extensions and Exemptions for State Medicaid and CHIP Fee-for Service In the proposed rule we explained that state Medicaid and CHIP FFS agencies face certain unique financing and operational circumstances that would not apply to other impacted payers. For example, some states would need legislative approval to initiate a public procurement process to secure contractors, particularly those with the necessary skills to support a state’s implementation of the policies that require API development or enhancement. The timeline for an openly competed procurement process, together with the time needed to onboard contractors to develop the APIs can be lengthy for states (87 FR 76302). We described the issues impacting the state Medicaid and CHIP FFS programs in the proposed rule for the Provider Access (87 FR 76261), Payer-to-Payer (87 FR 76279), and Prior Authorization (87 FR 76302) APIs. However, we also stated that if our proposals regarding these APIs were finalized, we would strongly encourage state Medicaid and CHIP FFS programs to implement them as soon as possible, because of the anticipated benefits for the impacted payers, patients, and providers. Therefore, to address implementation concerns for state Medicaid and CHIP FFS programs, we proposed a process through which states could seek an extension to, and, in specific circumstances, an exemption from, the requirements to implement and maintain Provider Access, Payer-toPayer, and Prior Authorization APIs. We also proposed that states could request a one-time, 1-year extension through their annual Advance Planning Document (APD) for Medicaid Management Information System (MMIS) operations expenditures. We also proposed to permit state Medicaid FFS programs to request an exemption from any or all of these three API requirements when at least 90 percent of the state’s Medicaid beneficiaries are enrolled in Medicaid MCOs as defined at 42 CFR 438.2. Similarly, we proposed that separate state CHIP FFS programs could request an exemption from the API requirements if at least 90 percent of the state’s separate CHIP beneficiaries are enrolled in CHIP MCOs as defined at 42 CFR 457.10. We proposed that VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 states could apply for an exemption by submitting a written request for the exemption as part of the annual APD for MMIS operations expenditures. CMS approves project plans and enhanced FFP for Medicaid Enterprise Systems (MES) using the APD process. CHIP waiver requests and expenditures for systems are managed at CMS in the operations division responsible for management of APDs. Guidance on the application process is available through each state’s Regional Office contact. As discussed in section II.C.4.b. of this final rule, we proposed and are finalizing, that for the payer to payer data exchange, state Medicaid and CHIP programs, rather than their managed care plans or managed care entities, will be responsible for obtaining beneficiaries’ permission, providing educational resources at the time of requesting permission, and identifying patients’ previous/concurrent payers, including for beneficiaries covered under managed care (87 FR 76280). Therefore, we also proposed that an exemption would not apply to those requirements, but only the API requirements, because it would prevent Medicaid managed care plans and CHIP managed care entities from meeting their obligations. For Medicaid managed care plans and CHIP managed care entities, we did not propose an extension process because we believe that these managed care plans are actively working to develop the necessary IT infrastructure to be able to comply with the requirements at 42 CFR 438.272(d)(5) and 42 CFR part 457. Many of these plans might benefit from efficiencies based on all of the plan types that they offer. For example, many of these managed care plans with Medicaid and CHIP beneficiaries are part of a larger organization serving MA and Marketplace populations. These larger organizations often provide the technical and operational capacity that would enable implementation of the APIs across all lines of business. We believe this would be a practical and efficient use of resources to service all enrollees. Additionally, because the majority of Medicaid beneficiaries receive all or some of their benefits in a managed care delivery system, these plans should be held to the implementation times finalized in this rule to support the intended policy goals. Please see 87 FR 76263 for the supporting narrative in the proposed rule. Comment: Multiple commenters expressed support for the proposed Medicaid and CHIP FFS extension policy and urged CMS to finalize this flexibility regarding compliance with PO 00000 Frm 00146 Fmt 4701 Sfmt 4700 the Provider Access, Payer-to-Payer, and Prior Authorization APIs. Multiple commenters highlighted extenuating circumstances that state Medicaid and CHIP agencies may face, especially related to the conclusion of the COVID– 19 public health emergency (PHE), and the resulting impact on IT and personnel resources. Multiple commenters submitted comments about which APIs should be included in the extensions, exemptions, and exceptions proposals and some recommended that CMS extend these flexibilities to all APIs included in the rule. A commenter recommended that CMS provide clarity regarding the exemption and extension provisions for the Patient Access API requirements. Response: We acknowledge that states will be conducting long-term efforts to return to normal Medicaid and CHIP operations after the end of the COVID– 19 PHE and the continuous enrollment condition under section 6008(b)(3) of the FFCRA. These efforts will continue through 2024, and many of these states have ongoing system development initiatives that require integration with MES and modules. Some states must work within their state legislative budget request cycle, as well as the Federal request cycle for requesting and obtaining funds for updates to their systems or new contracts. We reiterate that this final rule requires impacted payers to implement and maintain Provider Access, Payer-toPayer, and Prior Authorization APIs. Impacted payers should have already implemented or begun implementation of the Patient Access and Provider Directory APIs as required in the CMS Interoperability and Patient Access final rule, except for those organizations that have approved exceptions, as applicable.148 149 We did not propose a new Patient Access API, but rather additional data requirements for that API, and reporting requirements for use metrics. We did not propose any new 148 In the CMS Interoperability and Patient Access final rule, we finalized that Patient Access API provisions would be effective beginning January 1, 2021. We announced a 6-month enforcement discretion exercised as a result of the PHE until July 1, 2021. 149 For example, 45 CFR 156.221(h) permits the FFE to grant an exception on an annual basis to the requirements in paragraphs (a) through (g) of that section for an FFE QHP if the Exchange determines that making their health plan(s) available through the Exchange is in the interests of qualified individuals in the State or States in which such Exchange operates, and the QHP issuer submits a narrative justification describing the reasons why it cannot reasonably satisfy the requirements for the applicable plan year, the impact of non-compliance upon enrollees, the current or proposed means of providing health information to enrollees, and solutions and a timeline to achieve compliance with the requirements of this section. E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations extensions, exemptions, or exceptions for the Patient Access API in the proposed rule and are not adding policies of that nature in the final rule. Comment: Multiple commenters expressed concern regarding the proposed state Medicaid and CHIP FFS extension policies, specifically citing the importance of the impact of these policies on Medicaid enrollees, and on the need for provider adoption to truly achieve the burden reduction goals of the proposed rule for patients, payers, hospitals, and providers. A commenter recommended that CMS not allow certain payers to have extensions because this could affect provider adoption of the necessary technology. Another commenter expressed appreciation of CMS for the proposal to allow extensions but stated that they believe provider adoption is going to be the most important factor in achieving burden reduction. The commenter emphasized the importance of having a certain percentage of their prior authorizations be electronic so that there is a return on investment from the changes necessary (for example, workflow changes, training, IT changes). The commenter stated that if payers are not held to the requirements in the rule, it could be perceived as a disincentive to providers to invest in the necessary technology. Response: We thank commenters for confirmation that payers must be held accountable for implementation of the APIs, and that provider adoption of certain APIs is going to be an important factor in achieving burden reduction— particularly the Prior Authorization API. Participation by both payers and providers in some of the API provisions of this final rule will be important to ensure widespread adoption of the APIs. Because we also believe that provider participation is important for the Prior Authorization API, we are finalizing a modification to our proposal to adopt new Electronic Prior Authorization measures to incentivize providers (specifically, MIPS eligible clinicians, eligible hospitals, and CAHs) to use the Prior Authorization API under MIPS and the Medicare Promoting Interoperability Program as discussed in section II.F. of this rule. We also reiterate that while these extensions and exemptions apply to the new API provisions of this final rule, other policies must still meet the compliance dates established in this final rule. These include the prior authorization information to be included in the Patient Access API; information required under the finalized prior authorization process, such as providing a specific reason for denial, and revised VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 timeframes for issuing prior authorization decisions. We encourage states to communicate their implementation plans about the policies in this final rule (including those to which an extension or exemption may apply) to network and enrolled providers. Such communication may help providers prepare for changes in procedures or notify their vendors to make appropriate system changes on a similar schedule. Comment: A commenter said that the exemption for the APIs was a concern because it creates an unfair, two-tiered system that may leave people with disabilities behind; these people already face high barriers to care due to administrative burdens and uncertainties caused by prior authorization. The commenter wrote that the proposed exemption process will leave some FFS Medicaid populations—groups that include a disproportionate share of people with disabilities—without comparable access to any benefits derived from streamlining the prior authorization process with the Patient Access, Provider Access, and Payer-to-Payer APIs. The commenter noted the potential challenges of developing and maintaining the necessary data infrastructure for a relatively small FFS population, but wrote that in many states, people receiving Home and Community-Based Services (HCBS) through waivers that are carved out of managed care, may be individuals who would fall under the proposed API exemption and would fail to benefit from the streamlined prior authorization process in this regulation. Another commenter requested clarification on whether and how CMS considered health equity when proposing exemptions for some state Medicaid and CHIP programs. Other commenters expressed disagreement with the proposed exemptions and stated that these exemption proposals should be withdrawn, to make the APIs available to every Medicaid beneficiary. A commenter noted that states with managed care populations close to the proposed threshold for exemption may be incentivized to pressure beneficiaries into managed care to qualify for the exemption. Response: We agree that it is important to consider access and equity issues, and the risk of a two-tiered system that may impose barriers to care. CMS will only grant a state an exemption from the Provider Access, Payer-to-Payer, and Prior Authorization APIs if the state establishes an alternative plan to enable the electronic exchange and accessibility of the PO 00000 Frm 00147 Fmt 4701 Sfmt 4700 8903 required information that would otherwise be shared through the API. For example, CMS will only grant a state an exemption from the Provider Access API requirement if the state has established an alternative plan to ensure that enrolled providers have efficient electronic access to the same required data content about their patients through other means while the approved exemption is in effect. Similarly, states would be expected to use efficient means for electronic prior authorization that would reduce burden for providers and improve access to information about the requirements for when prior authorization is required for items and services or what documentation is required in advance. In light of requirements for the accessibility of this information, states implementing an alternative plan will be required to provide this information to all patients and providers in plain language and to offer auxiliary aids and services to ensure effective communications with individuals with disabilities. Comment: Multiple commenters recommended that CMS include managed care plans in the proposed flexibilities (for extensions and exemptions) and some commenters said that each state should be able to decide whether to allow an extension to managed care plans. A commenter noted that managed care plans have greater resources than state Medicaid and CHIP FFS programs and would be able to meet the rule requirements on time. On the other hand, a commenter recommended that state Medicaid agencies offer managed care plans a 1year extension. Response: We acknowledge commenters who recommended that CMS provide the opportunity for an extension or exemption to Medicaid managed care plans and CHIP managed care entities to align with our approach throughout the rule to apply most policies to both state Medicaid and CHIP FFS programs and Medicaid managed care plans and CHIP managed care entities. However, we reiterate that the purpose of the extension policy for state Medicaid and CHIP FFS programs is to provide states that are making a good faith effort with additional time to work through lengthy and complex state procurement processes, to secure the necessary funding, personnel, and technical resources to successfully implement the requirements. The purpose of the exemption policy for state Medicaid and CHIP FFS programs is to accommodate the different enrollment models that are now in effect for each state and provide consideration E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8904 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations for states with relatively small FFS populations. In response to these and many other comments requesting additional time for payers to implement the Provider Access, Payer-to-Payer, and Prior Authorization APIs, we are extending the compliance dates for the policies in this final rule that require API development or enhancement to 2027. This allows all impacted payers an additional year to meet these requirements, compared to our initial proposal to implement the requirements in 2026. We are finalizing the state Medicaid and CHIP FFS extension and exemption policies as proposed without extending this option to other payers in the Medicaid program, such as Medicaid managed care plans. We do not agree with commenters who suggested that each state be able to decide separately to allow an extension to managed care plans because the purpose of this final rule is to encourage adoption of these policies as soon as is practicable. As we have noted, Medicaid managed care plans are often owned and operated by larger private organizations, also subject to this final rule, and likely have the resources and capabilities to implement these policies and can efficiently leverage the work they do to build APIs across their Medicaid, MA, and Marketplace lines of business. We do not want to encourage a system where fewer Medicaid beneficiaries have access to the benefits of the policies in this final rule versus those with other types of coverage. Comment: Multiple commenters provided recommendations regarding additional payers and plan types that should be eligible to benefit from the extensions, exemptions, and exceptions proposals. Multiple commenters recommended that CMS extend these flexibilities to all impacted payers. For example, a commenter recommended that HHS consider permitting state Medicaid and CHIP agencies that have a direct relationship with patients and providers to be eligible for extensions, exemptions, or exceptions. Another commenter recommended that CMS create an exception process for state Medicaid agencies in states or territories with HIEs that would give participating providers the same data as the Provider Access API. Some Medicaid agencies report concerns about duplication with these HIEs, as this would be an inefficient use of resources, could confuse providers, and may inhibit efforts to expand HIEs. A commenter wrote that CMS should create an exception process for Medicaid agencies in states or territories with robust HIEs that provide access to the same data. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 Another commenter recommended that CMS consider exception and extension criteria for plans where the proposed timelines and requirements would jeopardize their ability to operate. Response: We thank all commenters for their input regarding extensions, exemptions, and exceptions for all payers. We are finalizing the extensions and exemptions policies as proposed for state Medicaid and CHIP FFS programs without extending them to additional payers because state Medicaid and CHIP FFS programs face certain unique challenges. As noted previously, unlike other impacted payers, state Medicaid and CHIP FFS programs do not have many discrete health care plans, and therefore cannot balance implementation costs across plans with low enrollment and those with higher enrollment. As stated at the beginning of this section, many states have complex procurement and staffing/recruitment challenges which do not apply to nongovernmental organizations. We acknowledge HIEs could be helpful partners for payers when implementing these APIs. Nothing in this rule would prohibit a state from partnering with an HIE to meet its requirements. Further discussion regarding HIEs can be found in sections II.B.3.b.iii. and II.C.3.a. of this final rule. Comment: Some commenters recommended that CMS include extensions and/or exemptions in the proposal for MA organizations, Special Needs Plans (SNPs), D–SNPs, or Institutional Special Needs Plans (I– SNPs).150 A commenter wrote that CMS should also permit extensions and exemptions for MA organizations offering integrated D–SNPs, especially if CMS does not finalize a phased-in approach to implementation. The commenter wrote that some of these payers are facing the challenge of unwinding current flexibilities implemented due to the PHE and are also facing significant requirements in coming years as finalized in the CY 2024 MA and Part D final rule (88 FR 22120). Another commenter asked that CMS consider whether there may be appropriate circumstances where it would be permissible for very small MA organizations, such as SNPs or I–SNPs to seek a one-time extension to the compliance dates. Response: We did not propose extensions or exemptions for MA organizations or Medicaid managed care plans, including plans that integrate 150 We note for readers that MA organizations offer MA plans, which include SNPs (including the specific types of SNPs mentioned by commenters— D–SNPs and I–SNPs), so we address these comments together. PO 00000 Frm 00148 Fmt 4701 Sfmt 4700 managed care Medicare and Medicaid benefits (for example, D–SNPs or applicable integrated plans). We have provided explanations for excluding Medicaid managed care plans in previous responses. We believe that most MA organizations are supported by entities with an operational and technical infrastructure that can support the API requirements because these organizations can leverage existing staff and vendor resources from implementation of the Patient Access and Provider Directory APIs. Further, MA organizations should have the operational infrastructure to analyze and implement the requirements for the new APIs based on that expertise. Finally, because we did not propose extensions or exemptions for MA organizations in the proposed rule, we cannot finalize such a policy for these entities in this rule. Comment: Some commenters recommended that CMS grant exemptions for states that are already implementing electronic prior authorization solutions or state-level policies that conflict with the proposed Prior Authorization API requirements. Response: The option for states to apply for an exemption exists to alleviate burden for states with small FFS populations and that have established an alternative plan to ensure that enrolled providers have efficient electronic access to the same information through other means while the exemption is in effect. We will not grant exemptions for situations where state law conflicts with the final rule. The final rule pre-empts any conflicting state law. Comment: Multiple commenters recommended that CMS consider allowing states to obtain two 1-year extensions. A commenter stated that an additional, 1-year extension would allow states to better meet the proposed requirements. Another commenter noted that states face certain challenges that may be out of their control and prolong implementation. Response: After consideration of comments received and for the reasons outlined in our response to these comments, we are extending the compliance dates for all of the polices that require API development or enhancement finalized in this rule to begin January 1, 2027, which will allow for additional time for the FHIR standard and IGs to continue to be refined and advanced to support all of the policies in this final rule. This applies to the compliance dates for the Provider Access, Payer-to-Payer, and Prior Authorization APIs. State Medicaid and CHIP FFS programs will E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations be eligible to apply for up to a 1-year extension as proposed. Comment: Multiple commenters expressed support for CMS’s proposal regarding exemptions for state Medicaid and CHIP FFS programs and recommended that CMS finalize these proposed flexibilities regarding implementation of the Provider Access, Payer-to-Payer, and Prior Authorization APIs. A commenter indicated that in reviewing exemption requests and the compliance dates in the proposed rule, as well as other information system projects that are in development, their plans to implement a comprehensive systems integration platform that would integrate the MES would necessitate the option for an exemption. This commenter indicated that the project was particularly urgent due to the end of system support for another legacy system. Another commenter recommended that CMS use a flexible interpretation for the exemption process and noted that it would not be reasonable to require a state to build out APIs for a Federal Emergency Services Program (FESP), explaining that some agencies report having a high number of FFS enrollees in an FESP, such that less than 90 percent of their members are technically enrolled in managed care. Response: We appreciate the support for the proposed exemption process, as well as for the simultaneous encouragement for payers to secure the necessary resources to implement the technology for the prior authorization and other APIs being finalized in this rule. We also confirm that the policy in this final rule does not apply to FESPs, and that other payers are not being considered eligible for exemptions, extensions, or exceptions at this time. Comment: A commenter noted that states with managed care populations close to the proposed threshold for exemption may be incentivized to pressure beneficiaries into managed care to qualify for the exemption. A commenter stated that larger states qualifying for an exemption will have a total number of FFS beneficiaries that is greater than the total Medicaid population of smaller states that would not qualify for the exemption. Response: CMS needs to balance the benefits to small populations of beneficiaries with the burden of new operations and costs being placed on states. CMS will not approve exemptions unless a state has established an alternative plan to ensure that enrolled providers have efficient electronic access to the same information, including prior authorization information, through other means while the exemption is in VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 effect, or that states are providing efficient electronic access to other payers. Additionally, state agencies with an approved exemption will be required to meet the policies that do not require API development or enhancement for their FFS populations (that is, the reduced prior authorization decision timeframes, providing a specific reason for a denial, and reporting prior authorization metrics). These policies, to the extent they will mitigate barriers to care or support improvements in the transparency of information between the states and providers, are part of the overall scope for this final rule to address challenges with prior authorization. Concerning the methodology states use to apply and be approved for an exemption, we believe we have provided a threshold where a state could appropriately claim an exemption without taking actions that would inappropriately influence the enrollment process or individual enrollee’s enrollment decisions. States’ use of enrollment brokers for choice counseling and enrollment processing also protects enrollees from undue pressure during the enrollment process. We remind states of the enrollee protections specified at 42 CFR 438.54 and 457.1210 for Medicaid and CHIP managed care enrollment respectively, as well as disenrollment rights specified at 42 CFR 438.56(c) and 457.1212, respectively. Comment: A commenter urged CMS to use a flexible interpretation for the exemption process for the API requirements for Medicaid agencies with at least 90 percent of their members enrolled in managed care, noting that some states have a high number of FFS beneficiaries in an FESP that are only covered for emergency care. The commenter stated that it would not be reasonable to require a state to build out APIs for beneficiaries and programs that cover such a narrow scope of services. Response: We appreciate the commenter highlighting that some states may have larger populations in FFS where beneficiaries are not receiving comprehensive benefits and thus may experience only limited value from the APIs. Our intent with establishing this condition for exemption approval is that no FFS population will experience diminished health care delivery or information exchange capabilities as a result of an approved exemption. The exemption intends to alleviate the cost burden of implementing the API provisions on state Medicaid and/or CHIP agencies with small FFS populations, regardless of the scope of their benefit package. We remind states PO 00000 Frm 00149 Fmt 4701 Sfmt 4700 8905 that CMS will grant an exemption if the state establishes to CMS’s satisfaction that the state meets the criteria for the exemption and has established an alternative plan to ensure that enrolled providers have efficient electronic access to the same information through other means while the exemption is in effect, including patient information and prior authorization information. b. Exception for Qualified Health Plan Issuers on the Federally-Facilitated Exchanges For QHP issuers on the FFEs, we proposed an exception process to the Provider Access, Payer-to-Payer, and Prior Authorization APIs for issuers applying for QHP certification that cannot satisfy the proposed requirements. To apply for an exception, we proposed that an issuer must include as part of its QHP application a narrative justification describing the reasons why it cannot reasonably satisfy the requirements for the applicable plan year, the effect of non-compliance upon providers and enrollees, the current or proposed means of providing the required information to providers or other payers, and solutions and a timeline to achieve compliance with the requirements (87 FR 76304). We reiterate in this final rule that QHP issuers on the FFEs submit a new application each year and that this information will be part of the annual QHP Certification application submission. Thus, should the size, financial condition, or capabilities of the QHP issuer change such that it believes it can implement one or more of the APIs, that information would be included in the application. We received a few comments on the proposals for exceptions for QHPs. Comment: Multiple commenters expressed support for the proposed exception process for QHP issuers on the FFEs, highlighting the need for this policy and recommending that CMS finalize the proposal to allow exceptions for QHP issuers on the FFEs regarding compliance with all proposed APIs. Response: We appreciate the support for the policy that QHPs be permitted an exception for the policies that require API development or enhancement in cases where the FFE determines that making such QHPs available is in the interests of qualified individuals in the state or states in which the FFE operates, and an exception would be warranted to permit the QHP issuer to offer QHPs through the FFE. This policy and the exceptions per 45 CFR 156.222(c) are consistent with the exception for QHP issuers on the FFEs E:\FR\FM\08FER2.SGM 08FER2 8906 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations lotter on DSK11XQN23PROD with RULES2 that we finalized for the Patient Access API in the CMS Interoperability and Patient Access final rule (85 FR 25552). We believe that having a QHP issuer offer QHPs through an FFE generally is in the best interest of patients; we would not want patients to have to go without access to QHP coverage because an issuer is unable to implement these APIs. Comment: Multiple commenters expressed concern regarding the proposed exception process for QHP issuers on the FFEs. Commenters specifically highlighted the ability for a QHP issuer to be certified, even with an exception to these requirements. A commenter recommended that CMS limit using exceptions for QHP issuers on the FFEs for the Provider Access API, and another commenter recommended that CMS explain that QHP issuers on the FFEs must eventually comply with the proposed requirements. A commenter expressed concern that if QHP issuers on the FFEs can be certified without complying with the regulation, then there would not be an incentive for compliance. A commenter stated that the proposal does not make sense given the financial position of QHP issuers on the FFEs and their ability to afford costsaving technology. The commenter recommended that any exception be conditioned on ‘‘no profit taking’’ by a health plan and limited executive compensation plans until the plan can comply. Additionally, the commenter stated that CMS had not offered a reasonable proposal for criteria to qualify a QHP issuer to be exempt from the proposed API requirements. Response: We understand concerns from commenters about permitting delayed implementation of requirements to promote access to information and expedited decisionmaking. However, given the comments in support of the proposed exceptions process and our interest in ensuring a variety of coverage options for FFE enrollees, we are finalizing this exception as proposed. While some issuers are in a position to implement the updates that this rule requires, a wide range of issuers participate in the VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 FFEs and vary in terms of when they will have available resources to adopt these new requirements. Per applicable rules at 45 CFR 156.221(h), 156.222(c), and 156.223(d), we have been and will continue granting exceptions to QHP issuers on the FFEs on an annual basis, and use information that issuers submit as part of the QHP certification process to track their progress. We will implement the exceptions processes per 45 CFR 156.222(c), and 45 CFR 156.223(d), based on our experience to date with implementing the existing exception per 45 CFR 156.221(h) that is available to QHP issuers on the FFEs that cannot satisfy the requirements per 45 CFR 156.221(a) through (g) to implement and maintain the Patient Access API for the applicable plan year. When determining whether a QHP issuer on an FFE may qualify for an exception to the current requirement to provide a Patient Access API, we take into consideration the content that the issuer submits per the requirement at 45 CFR 156.221(h), including the impact of non-compliance upon enrollees, the current or proposed means of providing health information to enrollees, and solutions and a timeline to achieve compliance with the requirements of this section. This information allows us to assess whether a QHP issuer has a plan in place to mitigate harm or inconvenience to enrollees by ensuring they can access necessary information, as well as a plan to fully implement the requirements as soon as possible. Information that issuers submit during the QHP certification process also allows us to develop a knowledge base of API development capacity for issuers based on size and other circumstances, which can inform future decisions about whether to allow exceptions. We expect to build on this knowledge base as we implement the exceptions processes per 45 CFR 156.222(c) and 156.223(d), and as part of our updates to the QHP certification process in the coming years to reflect this rule’s new requirements, we will continue to work closely with issuers and other stakeholders to ensure that our implementation balances the PO 00000 Frm 00150 Fmt 4701 Sfmt 4700 importance of access to information with robust QHP issuer participation on the FFEs. Finally, QHP issuer applications for plan years 2023 and 2024 indicated that most issuers were compliant with the requirement to provide a Patient Access API. Further, issuers that sought an exception under 45 CFR 156.221(h) generally explained in their justifications that they planned to become compliant with the API requirements mid-way through the upcoming plan year, or shortly after the start of the plan year. This high level of compliance suggests that the availability of an exception does not discourage or de-incentivize issuers’ implementation of these standards. We agree that the intent of our final policies is for all impacted payers to provide patients with the benefits of the Provider Access, Payer-to-Payer, and Prior Authorization APIs as soon as they are financially and operationally able. For example, for each of the API provisions for which an exemption is available, we have indicated that if the payer cannot implement the API and is seeking an exemption, it must offer alternative options to the providers to support the intent of the policies; such programs would generally improve the exchange of patient data between payers for care management or access to information for patients, and to improve the prior authorization process for providers and payers. We believe that by requiring alternatives to the APIs during the exemption, payers will investigate options to implement the APIs because, in the long term, these will be more efficient and financially viable than maintaining current manual processes. Table F1 shows the impacted payers that are eligible to apply for an extension, exemption, or exception for the Provider Access, Payer-to-Payer, and/or Prior Authorization APIs required in this final rule. Tables C1, D1, and E4 found in sections II.B., II.C., and II.D. of this final rule include the regulatory citations for the extensions, exemptions, and exceptions for each impacted payer. E:\FR\FM\08FER2.SGM 08FER2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations 8907 TABLE Fl: IMPACTED PAYERS ELIGIBLE TO APPLY FOR EXTENSIONS, EXEMPTIONS, OR EXCEPTIONS BY APPLICATION PROGRAMMING INTERFACE IN THE CMS INTEROPERABILITY AND PRIOR AUTHORIZATION FINAL RULE Eligible for Exemption Eligible for Exception • Medicaid FFS program with :::: • QHP issuers on the 90% inMCOs FFEs CHIP FFS program y with :::: • 90% inMCOs NEMTPAHP* • Payer-to-Payer API • Medicaid FFS • Medicaid FFS program with :::: • QHP issuers on the 90% inMCOs FFEs program CHIP FFS program CHIP FFS program with :::: 90% • • inMCOs Prior Authorization • Medicaid FFS state • Medicaid FFS program with :::: • QHP issuers on the API program 90% inMCOs FFEs CHIP FFS program CHIP FFS state agency with :::: • • 90% inMCOs *NEMT PAHPs are not subject to the Provider Access and Payer-to-Payer API requirements and do not need to apply to CMS for this exemption. Eligible for Extension • Medicaid FFS program • CHIP FFS program lotter on DSK11XQN23PROD with RULES2 3. Federal Matching Funds for State Medicaid and CHIP Expenditures on Implementation of the Provider Access, Payer-to-Payer, and Prior Authorization APIs We explained in the proposed rule for each of the APIs, we would anticipate that states operating Medicaid and CHIP programs would be able to access Federal matching funds to support their implementation of the APIs— specifically, the Provider Access, Payerto-Payer, and Prior Authorization APIs. We expect these APIs to lead to more efficient administration of Medicaid and CHIP state plans by supporting more efficient data exchange and prior authorization processes, consistent with sections 1902(a)(4) and 2101(a) of the Act, respectively. We do not consider state expenditures for implementing the Provider Access, Payer-to-Payer, or Prior Authorization APIs to be attributable to any covered Medicaid item or service within the definition of ‘‘medical assistance.’’ Thus, in Medicaid, CMS will not match these expenditures at the state’s regular Federal Medical Assistance Percentage (FMAP). However, FFP at a rate of 50 percent could be available for state expenditures related to implementing these APIs for Medicaid programs under section 1903(a)(7) of the Act (for the proper and efficient administration of the Medicaid state plan). The three APIs should, over time, help the state more efficiently administer its Medicaid program by supporting data exchange with providers and other payers and improving efficiencies in the prior authorization process. As we stated in VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 the proposed rule, sharing certain data through the Provider Access API with participating providers could improve the quality of care for patients, using the Payer-to-Payer API may help patients manage their information across payers to support patient care, and using the Prior Authorization API will enable administrative efficiencies by reducing delays in the prior authorization process overall, and by helping reduce the number of denied and appealed prior authorization decisions. States’ expenditures to implement the proposed requirements could be eligible for 90 percent enhanced FFP under section 1903(a)(3)(A)(i) of the Act if the expenditures can be attributed to the design, development, and installation (DDI) of mechanized claims processing and information retrieval systems. Additionally, 75 percent enhanced FFP, under section 1903(a)(3)(B) of the Act, could be available for state expenditures to operate Medicaid mechanized claims processing and information retrieval systems to comply with the finalized API requirements. States can request Medicaid enhanced FFP under section 1903(a)(3)(A)(i) or (B) of the Act through the APD process described at 45 CFR part 95, subpart F. Additionally, 42 CFR 433.112(b)(12) and 433.116(c) require that any system for which states are receiving enhanced FFP under section 1903(a)(3)(A)(i) or (B) of the Act align with and incorporate the ONC Health IT standards adopted at 45 CFR part 170, subpart B. The APIs complement this requirement because they further interoperability by using standards adopted by ONC at 45 CFR PO 00000 Frm 00151 Fmt 4701 Sfmt 4700 170.215.151 States must comply with 42 CFR 433.112(b)(10) and 433.116(c) to explicitly support exposed APIs, meaning the API’s functions are visible to others to enable the creation of a software program or application, as a condition of receiving enhanced FFP under section 1903(a)(3)(A)(i) or (B) of the Act. We note that FHIR is an opensource standard that can meet the requirements at 42 CFR 433.112(b)(10) and 433.116(c) if implemented by following our regulations, particularly the technical, documentation and denial or discontinuation requirements at 42 CFR 431.60. Finally, 42 CFR 433.112(b)(13) and 433.116(c) require states to promote sharing, leverage, and re-use of Medicaid technologies and systems within and among states as a condition of receiving enhanced FFP under section 1903(a)(3)(A)(i) or (B) of the Act. CMS interprets that requirement to apply to technical documentation associated with a technology or system, such as technical documentation for connecting to a state’s APIs. Making the needed technical documentation publicly available so that systems that need to do so can connect to the APIs finalized in this rule is required as part of the technical requirements at 42 CFR 431.60(d) for all APIs, including the Provider Access, Payer-to-Payer, and Prior Authorization APIs. 151 Centers for Medicare and Medicaid Services (2020). SHO # 20–003 RE: Implementation of the CMS Interoperability and Patient Access Final Rule and Compliance with the ONC 21st Century Cures Act Final Rule. Retrieved from https:// www.medicaid.gov/federal-policy-guidance/ downloads/sho20003.pdf. E:\FR\FM\08FER2.SGM 08FER2 ER08FE24.010</GPH> API Provider Access API 8908 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations lotter on DSK11XQN23PROD with RULES2 Separately, for CHIP agencies, section 2105(c)(2)(A) of the Act and 42 CFR 457.618, limiting administrative costs to no more than 10 percent of a state’s total computable expenditures for a fiscal year (FY), will apply to administrative claims for developing the APIs finalized in this rule. Comment: Multiple commenters expressed appreciation for the inclusion of language that states may be eligible for enhanced FFP to support implementation of the Provider Access, Payer-to-Payer, and Prior Authorization APIs in this final rule. While these commenters expressed support for this option, others asked CMS to explain whether enhanced FFP is also available to implement the Patient Access API requirements. Response: Many states have already requested enhanced Federal matching funds for their expenditures on implementation of the Patient Access API required in the CMS Interoperability and Patient Access final rule. Additionally, enhanced funding under section 1903(a)(3)(A)(i) of the Act may be available for certain expenditures to design, develop, and install the enhancements to the Patient Access API finalized in this rule, in addition to expenditures related to the Provider Access, Payer-to-Payer, and Prior Authorization APIs. CMS encourages states to seek enhanced FFP where it might be applicable for states’ expenditures on work needed to meet state Medicaid and CHIP agencies’ requirements under this rule and looks forward to reviewing any APDs submitted by states. Instructions for submitting the APDs are available on the Medicaid website 152 under the topic of ‘‘Medicaid State Plan Amendments’’ with information about what categories of costs may be included in the requests, such as HIE connection/interface costs. The information on the categories that are included in these requests can be found in the State Medicaid Manual (SMM), Chapter 11, sections 265 & 276,153 the State Medicaid Director Letter (SMDL) 16–004, ‘‘Mechanized Claims Processing and Information Retrieval Systems-Enhanced Funding,’’ 154 and the State Health 152 Code of Federal Regulations (amended 2016, June 2). Retrieved from 45 CFR 95.610, Submissions of advance planning documents. 153 Centers for Medicare and Medicaid Services. The State Medicaid Manual (SMM), Chapter 11, sections 265 & 276. Retrieved from https:// www.cms.gov/regulations-and-guidance/guidance/ manuals/paper-based-manuals-items/cms021927. 154 Centers for Medicare and Medicaid Services (2016, March 31). State Medicaid Director letter #16–004. Retrieved from https:// www.medicaid.gov/sites/default/files/federalpolicy-guidance/downloads/SMD16004.pdf. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 Official (SHO) #20–003, ‘‘Implementation of the CMS Interoperability and Patient Access final rule.’’ 155 Comment: A commenter recommended that states receive a 90 percent Federal match to support implementation of these requirements. Another commenter urged CMS to explain in the final rule, or additional guidance, whether all, or likely all, of the required state investment to develop these APIs, would qualify for enhanced Federal matching to establish and operate API systems. Response: States’ expenditures to implement the proposed requirements for each of the APIs may be eligible for 90 percent enhanced FFP if the expenditures can be attributed to the DDI for those APIs that benefit the Medicaid program. CMS determines on a case-by-case basis when states’ APDs requesting this 90 percent FFP are approvable, consistent with the requirements at 42 CFR part 433, subpart C, and 45 CFR part 95, subpart F. States should work with their MES State Officers for further guidance specific to their programs. Comment: A commenter recommended that CMS clarify that the Federal funding resources available for states meeting the Prior Authorization API requirement can also include passthrough payments to providers to obtain and utilize interoperable EHR technology for these purposes. This commenter also expressed concern that the proposed rule did not offer any indication of available resources for providers, but they appreciate CMS’s clarification of available Federal resources available to states for implementing the Prior Authorization API requirement. Another commenter said that states should be granted flexibility for Federal funding sources to expand the number of SNF providers able to utilize the new Provider Access API. Response: We encourage states to apply for Federal funding to support their planning, development, and implementation of state systems including the Provider Access, Payer-toPayer, and Prior Authorization APIs, because these APIs will enable more providers to engage in data exchange with state systems to improve patient care. As previously noted, enhanced Federal Medicaid funding at the 90 percent rate may be available for the DDI and at the 75 percent rate for the 155 Centers for Medicare and Medicaid Services (2020, August 14). State Health Official letter #20– 003. Retrieved from https://www.medicaid.gov/ sites/default/files/2020-08/sho20003_0.pdf. PO 00000 Frm 00152 Fmt 4701 Sfmt 4700 operation of these API initiatives that benefit the Medicaid program. These enhanced Federal matching funds, as outlined at 42 CFR 433.112 (DDI) and 433.116 (operation), are available for state expenditures on Medicaid state systems only, and not available for other state or provider expenditures on provider-only systems to support providers’ or other entities’ efforts to implement APIs. Similarly, Federal matching funds at 50 percent under section 1903(a)(7) of the Act might be available to support Medicaid state specific activities for the required provisions. However, none of these funds are available for funding to providers, as these are designated to support state-specific initiatives. 4. Medicaid Expansion CHIP Most states have Medicaid expansion CHIP programs, in which a state receives Federal funding to expand Medicaid eligibility to optional targeted low-income children that meet the requirements of section 2103 of the Social Security Act. We proposed and are now finalizing our policy at 42 CFR 457.700(c), that for states with Medicaid Expansion CHIP programs, the final requirements as proposed for Medicaid will apply to those programs rather than separate provisions for the CHIP program. In this final rule, we make explicit that the Medicaid requirements at §§ 431.60, 431.61, and 431.80 apply to the Medicaid expansion CHIP programs rather than the separate CHIP requirements at §§ 457.730, 457.731, and 457.732. Comment: A commenter stated that most states have operating Medicaid expansion CHIP programs and that the provisions outlined in the proposed rule would apply to most states. Response: We agree with this commenter and as stated, are confirming that Medicaid requirements apply equally to Medicaid expansion CHIP programs. 5. Final Action After consideration of the comments received, and for the reasons discussed in the CMS Interoperability and Prior Authorization proposed rule and our responses to those comments (as summarized), we are finalizing our proposal to allow for state Medicaid and CHIP FFS programs and QHP issuers on the FFEs to apply for certain extensions, exemptions, or exceptions for the Provider Access, Payer-to-Payer and/or Prior Authorization APIs. We are also finalizing our proposal regarding Medicaid Expansion CHIP programs. We are finalizing the policy to allow state Medicaid and CHIP FFS programs E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations to apply for an extension to the deadline from the requirements to implement the Provider Access, Payer-to-Payer, and/or Prior Authorization APIs. Specifically, we are finalizing that states may request a one-time, 1-year extension as part of their annual APD for MMIS operations expenditures before the compliance dates. The written extension request must include the following: (1) a narrative justification describing the specific reasons why the state cannot satisfy the requirement(s) by the compliance dates, and why those reasons result from circumstances that are unique to the agency operating the Medicaid and/or CHIP FFS program; (2) a report on completed and ongoing state activities that evidence a good faith effort toward compliance; and (3) a comprehensive plan to meet the requirements no later than 1 year after the compliance date. CMS will grant an extension if the state establishes, to CMS’s satisfaction, that the request adequately establishes a need to delay implementation; and that the state has a comprehensive plan to meet the requirements no later than 1 year after the compliance date. We are finalizing a policy to allow state Medicaid and CHIP FFS programs to apply for an exemption from the requirements of the Provider Access, Payer-to-Payer, and/or Prior Authorization APIs when at least 90 percent of the state’s Medicaid beneficiaries are enrolled in Medicaid MCOs or when at least 90 percent of the state’s separate CHIP beneficiaries are enrolled in CHIP MCOs. We are finalizing that the requirements for the Payer-to-Payer API to obtain beneficiaries’ permission, provide educational resources at the time of requesting permission, and identify patients’ previous/concurrent payers, including for beneficiaries covered under managed care are not eligible for the exemption. Specifically, we are finalizing the policy that a state may request an exemption, as part of their annual APD for MMIS operations expenditures before the compliance date (which may be extended by 1 year if the state receives an extension). The exemption request must include documentation showing that the state meets the threshold criterion based on enrollment data from the most recent CMS ‘‘Medicaid Managed Care Enrollment and Program Characteristics’’ (for a Medicaid FFS exemption) or enrollment data from section 5 of the most recently accepted state submission to CHIP Annual Report Template System (CARTS). The state must also include an alternative plan to VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 ensure that providers have efficient electronic access to the same information through other means while the exemption is in effect. CMS will grant the exemption if the state establishes, to CMS’s satisfaction, that the state meets the criteria for the exemption, including an alternative plan to ensure efficient electronic access to the same information through other means while the exemption is in effect. We are finalizing that an exemption will expire under two scenarios. First, an exemption will expire if, based on the 3 previous years of available, finalized Medicaid Transformed Medicaid Statistical Information System (T–MSIS) and/or CHIP CARTS enrollment data, the State’s MCO enrollment for 2 of the previous 3 years is below 90 percent. Second, an exemption will expire if CMS approves a state plan amendment, waiver, or waiver amendment that would significantly reduce the percentage of beneficiaries enrolled in managed care and the anticipated shift in enrollment is confirmed by the first available, finalized Medicaid T–MSIS and/or CHIP CARTS enrollment data. We are finalizing that states must provide written notification to CMS if they no longer qualify for an approved exemption. Written notification must be submitted to CMS within 90 days of the finalization of the first annual Medicaid T–MSIS managed care enrollment data and/or the CARTS report for CHIP demonstrating the enrollment shift to below 90 percent in managed care. States must obtain CMS approval of a timeline for compliance with the API requirements for Medicaid FFS and/or CHIP FFS within 2 years of the expiration of the exemption. For additional context, please refer to the proposed rule (87 FR 76263). In addition, we are finalizing that for states with Medicaid expansion CHIPs, the requirements for Medicaid will apply to those programs rather than-the provisions for separate CHIPs. We are finalizing that an issuer applying for QHP certification may apply for an exception from requirements of the Provider Access, Payer-to-Payer, and/or Prior Authorization APIs. The issuer must include, as part of its QHP application, a narrative justification describing the reasons why the issuer cannot reasonably satisfy the requirements for the applicable plan year, the impact of non-compliance upon providers and enrollees, the current or proposed means of providing health information to providers or other payers, and solutions and a timeline to achieve compliance with the requirements. An PO 00000 Frm 00153 Fmt 4701 Sfmt 4700 8909 FFE may grant an exception to the requirements if it determines that making that issuer’s QHPs available through the FFE is in the interests of qualified individuals in the state or states in which the FFE operates, and an exception is warranted to permit the issuer to offer QHPs through the FFE. These final policies apply to state Medicaid and CHIP FFS programs and QHP issuers on the FFEs at the CFR sections listed in Tables C1, D1, and E4. F. Electronic Prior Authorization Measures for the Merit-Based Incentive Payment System Promoting Interoperability Performance Category and the Medicare Promoting Interoperability Program 1. Background As discussed in detail in section II.D. of this final rule, the current prior authorization process needs improvement to reduce the burden associated with the process itself. To facilitate those needed improvements in the prior authorization process, we are requiring impacted payers to implement and maintain a Prior Authorization API. The Prior Authorization API aims to improve care coordination and shared decision-making by enabling enhanced electronic documentation discovery and facilitating electronic prior authorization. We believe the Prior Authorization API will reduce administrative burden, improve efficiency, and ensure patients promptly receive necessary medical items and services. We also recognize that efficiencies from payer implementation of these APIs will only be realized if they are utilized by requesting providers to complete prior authorization requests. Therefore, we proposed a new measure for MIPS eligible clinicians (as defined at 42 CFR 414.1305) under the MIPS Promoting Interoperability performance category, as well as for eligible hospitals and CAHs under the Medicare Promoting Interoperability Program, related to electronic prior authorization and the Prior Authorization API (87 FR 76312– 76314). We proposed the new measures, titled ‘‘Electronic Prior Authorization,’’ to be included in the HIE objective for the MIPS Promoting Interoperability performance category and in the HIE objective for the Medicare Promoting Interoperability Program. The Electronic Prior Authorization measure aims to address concerns, specifically from commenters in response to the December 2020 Interoperability proposed rule (85 FR 82586), that few providers would use the Prior E:\FR\FM\08FER2.SGM 08FER2 8910 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations Authorization API established by impacted payers. MIPS is authorized under section 1848(q) of the Act. As described in sections 1848(q)(2) and (5) of the Act, we evaluate the performance of MIPS eligible clinicians in four performance categories, which we refer to as the quality, cost, improvement activities, and Promoting Interoperability performance categories. Under 42 CFR 414.1375(b)(2), MIPS eligible clinicians must report on objectives and measures as specified by CMS for the Promoting Interoperability performance category. We refer readers to the CY 2024 Physician Fee Schedule (PFS) final rule (88 FR 79357–79362) for a list of the current objectives and measures required for the MIPS Promoting Interoperability performance category.156 We determine a final score for each MIPS eligible clinician based on their performance in the MIPS performance categories during a MIPS performance period for a year. Based on the MIPS eligible clinician’s final score, we calculate a MIPS payment adjustment (which can be positive, neutral, or negative) that applies for the covered professional services they furnish in the MIPS payment year which occurs 2 years later. The Medicare Promoting Interoperability Program for eligible hospitals and CAHs is authorized in part under sections 1886(b)(3)(B)(ix) and 1814(l)(4) of the Act. Under these statutory provisions, eligible hospitals and CAHs that are not meaningful EHR users are subject to Medicare payment reductions. To be considered a meaningful EHR user (as defined under 42 CFR 495.4), the eligible hospital or CAH must demonstrate meaningful use of CEHRT by satisfying objectives and measures as required under 42 CFR 495.24. We refer readers to the FY 2024 Hospital Inpatient Prospective Payment System (IPPS) and Long-Term Care Hospital (LTCH) final rule (88 FR 59269–59277) for a summary of the currently adopted objectives and measures for the Medicare Promoting Interoperability Program. lotter on DSK11XQN23PROD with RULES2 2. Electronic Prior Authorization To support the policies in this final rule and maximize the potential to improve the prior authorization process for providers and patients, we proposed 156 In the proposed rule (87 FR 76312), we referred readers to the CY 2023 PFS final rule (87 FR 70075–70080) for the then-current list of objectives and measures. We have updated this final rule to refer to the CY 2024 PFS final rule which includes the most recent objectives and measures, including changes effective for the CY 2024 MIPS performance period. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 to add new measures, titled ‘‘Electronic Prior Authorization,’’ under the HIE objective of the MIPS Promoting Interoperability performance category and under the HIE objective of the Medicare Promoting Interoperability Program. These measures support the electronic exchange of health information to improve the quality of health care, such as promoting care coordination, as described in section 1848(o)(2)(A)(ii) of the Act with respect to MIPS eligible clinicians, and section 1886(n)(3)(A)(ii) of the Act with respect to eligible hospitals and CAHs. We proposed that for purposes of the Electronic Prior Authorization measures, a prior authorization request must be made using the Prior Authorization API to satisfy the measure, unless the MIPS eligible clinician, eligible hospital, or CAH could claim an applicable exclusion. As discussed in more detail in the proposed rule (87 FR 76313) and further in this section II.F., we proposed that MIPS eligible clinicians, eligible hospitals, and CAHs would report the number of prior authorizations requested electronically via the Prior Authorization API using data from their CEHRT as a numerator and denominator, unless they could claim an applicable exclusion. We proposed that beginning with the CY 2026 performance period/CY 2028 MIPS payment year for MIPS eligible clinicians and the CY 2026 EHR reporting period for eligible hospitals and CAHs, a MIPS eligible clinician, eligible hospital, or CAH that fails to report the measure or claim an exclusion would not satisfy the MIPS Promoting Interoperability performance category or Medicare Promoting Interoperability Program reporting requirements. For the CY 2026 performance period/CY 2028 MIPS payment year for MIPS eligible clinicians and the CY 2026 EHR reporting period for eligible hospitals and CAHs, we proposed that the Electronic Prior Authorization measure would not be scored and would not affect the total score for the MIPS Promoting Interoperability performance category or the Medicare Promoting Interoperability Program. In other words, for CY 2026, a MIPS eligible clinician, eligible hospital, or CAH would be required to report a numerator of at least one for the measure or claim an exclusion, but the measure would not be scored. We proposed that, if the MIPS eligible clinician or eligible hospital or CAH does not report a numerator of at least one for the measure or claim an exclusion, they PO 00000 Frm 00154 Fmt 4701 Sfmt 4700 would receive a zero score for the MIPS Promoting Interoperability performance category or the Medicare Promoting Interoperability Program, respectively. We noted that we intend to propose a scoring methodology for the measure in future rulemaking. First, we are finalizing that MIPS eligible clinicians report the Electronic Prior Authorization measure beginning with the CY 2027 performance period/ 2029 MIPS payment year (rather than the CY 2026 performance period/2028 MIPS payment year), and that eligible hospitals and CAHs report the Electronic Prior Authorization measure beginning with the CY 2027 EHR reporting period (rather than the CY 2026 EHR reporting period). We believe that this modification to our proposed policy for the Electronic Prior Authorization measures will allow more time for MIPS eligible clinicians, eligible hospitals, and CAHs to adjust to the new electronic prior authorization workflow using the Prior Authorization API. Second, we are finalizing the Electronic Prior Authorization measure with a modification such that it is structured as an attestation (yes/no) measure, instead of a numerator and denominator measure as originally proposed, for both MIPS eligible clinicians and eligible hospitals and CAHs. As an attestation measure, MIPS eligible clinicians, eligible hospitals, and CAHs will report a ‘‘yes’’ or ‘‘no’’ response or report an applicable exclusion for the Electronic Prior Authorization measure. Instead of reporting how many times the MIPS eligible clinician, eligible hospital, or CAH requested prior authorization electronically via the Prior Authorization API in a numerator and all prior authorizations in a denominator as proposed (87 FR 76313), the MIPS eligible clinician, eligible hospital, or CAH will either submit an attestation (yes/no) regarding whether they used the Prior Authorization API to submit at least one prior authorization request electronically or claim an applicable exclusion to report the modified Electronic Prior Authorization measures. We are modifying the proposed reporting methodology to align with the modification to the measure specifications we are finalizing, specifically reporting this measure as an attestation yes/no response instead of a numerator and denominator. We believe that this modification to our proposed policy for the Electronic Prior Authorization measures will reduce burden by not requiring MIPS eligible clinicians, eligible hospitals, and CAHs to calculate and report a numerator and E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations denominator for the Electronic Prior Authorization measure. Additionally, we are finalizing that the measures will not be scored (that is, not assigned points for completion or failure). Instead, if a MIPS eligible clinician, eligible hospital, or CAH fails to report the measure as specified, they would not meet the minimum reporting requirements, not be considered a meaningful EHR user, and fail the Medicare Promoting Interoperability Program or the MIPS Promoting Interoperability performance category. A failure in the Medicare Promoting Interoperability Program would result in a downward payment adjustment for eligible hospitals or CAHs (unless the eligible hospital or CAH receives a hardship exception). A failure in the Promoting Interoperability performance category would result in the MIPS eligible clinician receiving a score of zero for the performance category, which is currently worth 25 percent of their final score for MIPS. This is consistent with our original proposal that failure to report a numerator of at least one for the measure, or claim an exclusion, warrants a zero score for the MIPS Promoting Interoperability performance category and failure to meet Medicare Promoting Interoperability Program reporting requirements (87 FR 76313). For the MIPS Promoting Interoperability performance category, satisfactory performance on this measure can be demonstrated only by reporting a ‘‘yes’’ response on the attestation or claiming an applicable exclusion. A ‘‘no’’ response on the attestation will result in the MIPS eligible clinician failing to meet the minimum reporting requirements, therefore not being considered a meaningful EHR user for MIPS, as set forth in section 1848(o)(2)(A) of the Act and defined at 42 CFR 414.1305, for the MIPS payment year (42 CFR414.1305). MIPS eligible clinicians that do not report a ‘‘yes’’ response or claim an applicable exclusion for the Electronic Prior Authorization measure as specified (that is, they do not submit the measure or claim an exclusion or report a ‘‘no’’ response) will not earn a score for the MIPS Promoting Interoperability performance category (a score of zero for the category). A MIPS eligible clinician’s score in the Promoting Interoperability performance category is generally worth 25 percent of their total final score for MIPS.157 We note that to report a ‘‘yes,’’ the action of the measure must occur during the selected performance period 158 or EHR reporting period,159 as per the measure specifications defined below. For the Medicare Promoting Interoperability Program, only a ‘‘yes’’ response on the attestation, or claiming an applicable exclusion, will fulfill the minimum requirements of this measure. A ‘‘no’’ response will result in the eligible hospital or CAH failing to meet the measure, and therefore failing to meet minimum program reporting requirements, thus not being considered a meaningful EHR user for an EHR reporting period, as defined in section 1886(n)(3) of the Act.160 Eligible hospitals and CAHs that do not meet the minimum program reporting requirements are subject to a downward payment adjustment (unless the eligible hospital or CAH receives a hardship exception). The following is a summary of the comments we received on our proposals and our responses. Comment: Multiple commenters expressed support for our proposal to add the Electronic Prior Authorization measure under the MIPS Promoting Interoperability performance category for MIPS eligible clinicians and the Medicare Promoting Interoperability Program for eligible hospitals and CAHs to incentivize use of the Prior Authorization API among providers. Multiple commenters agreed that it is appropriate to place the proposed Electronic Prior Authorization measure under the HIE objective for both the MIPS Promoting Interoperability performance category and the Medicare Promoting Interoperability Program. Multiple commenters noted that the Electronic Prior Authorization measure would incentivize MIPS eligible clinicians, eligible hospitals, and CAHs to use the Prior Authorization API capabilities to automate the prior authorization process, which could lead to more timely delivery of care. A commenter stated that this proposal would help ensure that providers utilize the Prior Authorization and Provider Access APIs’ technology, in addition to promoting interoperability and the electronic exchange of health information. Response: We thank commenters for their feedback and support of the proposed Electronic Prior Authorization measure under the MIPS Promoting Interoperability performance category and the Medicare Promoting Interoperability Program. We agree that the Electronic Prior Authorization 158 See 42 CFR 414.1320. 42 CFR 495.40(b)(2)(i). 160 See 42 CFR 495.4; 495.24(f)(1)(i)(A). 159 See 157 See 42 CFR 414.1375(a); 414.1380(c)(1). VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 PO 00000 Frm 00155 Fmt 4701 Sfmt 4700 8911 measure will help incentivize MIPS eligible clinicians, eligible hospitals, and CAHs to use the Prior Authorization API to automate the prior authorization process, which could lead to more timely delivery of care. Comment: Multiple commenters encouraged CMS to continue to explore additional and alternative opportunities to foster API adoption and utilization of electronic prior authorization tools, as well as incentivize the adoption of the Prior Authorization API across the industry and include a broader set of providers outside of these incentive programs. Commenters suggested expanding the Electronic Prior Authorization measure to other programs to reach additional provider populations, such as the Medicare Shared Savings Program (MSSP) and Alternative Payment Models (APMs). A commenter also recommended implementing a pilot program as part of CMS’s Primary Care First (PCF) model. A commenter recommended that CMS should work in partnership with ONC to implement incentives that encourage further adoption of electronic prior authorization. Another commenter supported further development of performance measures to encourage interoperability enhancements and API uptake. A commenter recommended that CMS engage with various associations to encourage further adoption. A commenter supported industry-wide adoption of electronic prior authorization processes but suggested that only requiring impacted payers to build APIs would not lead to broad adoption. A commenter stated that CMS should use every available option to influence and incentivize adoption of these standards within the health care industry if it intends to mandate that impacted payers participate. Commenters also acknowledged that the provider community is an important, interested group in the drive to enable widespread interoperability. Response: We thank the commenters for their support and additional recommendations on how we can incentivize using the Prior Authorization API. We will continue to monitor and assess opportunities we can leverage to encourage API implementation uptake. Additionally, we will continue to collaboratively work with ONC to identify ways to incentivize the adoption of electronic prior authorization. We believe that establishing the Electronic Prior Authorization measure is a viable method to begin fostering the adoption and utilization of the Prior Authorization API by MIPS eligible E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8912 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations clinicians, eligible hospitals, and CAHs in these initiatives. We note that nothing in the Prior Authorization API proposal we are finalizing would prohibit providers that are not subject to MIPS or the Medicare Promoting Interoperability Program from using the API for electronic prior authorization as well. Where permitted under applicable law and relevant program requirements, we encourage providers who are not included in these programs to leverage the Prior Authorization APIs to gain the intended benefits, such as improving efficiency and reducing the administrative burden of prior authorization processes. We agree that requiring impacted payers to build the APIs would not lead to broad adoption. However, we believe that establishing the Electronic Prior Authorization measure under both MIPS and the Medicare Promoting Interoperability Program will help promote the implementation and use of the Prior Authorization API by MIPS eligible clinicians, eligible hospitals, and CAHs. In order for the industry to realize the efficiencies of the Prior Authorization API and achieve the goals set forth in this final rule, it is essential that both impacted payers and providers adopt and use a Prior Authorization API. Comment: Multiple commenters opposed adoption of the proposed Electronic Prior Authorization measure stating that the measure would be inefficient and burdensome, citing challenges with additional workflow requirements, increased provider burden, and financial burden. A commenter stated that it would potentially leave providers unfairly penalized. Several commenters noted that the burden of reporting outweighs the benefits of use and that hospital IT resources are already overloaded and limited. Other commenters noted that mandating the Electronic Prior Authorization measure could further increase provider burden and detract from patient care, directing MIPS eligible clinicians, eligible hospitals, and CAHs’ attention away from patients. A commenter stated that the Electronic Prior Authorization measure proposal is unlikely to provide significant relief to providers (that is, MIPS eligible clinicians, eligible hospitals, and CAHs). Another commenter stated that payers should compensate providers fairly for the cost of each prior authorization for the implementation of costly and burdensome electronic prior authorization requirements. This commenter stated that each prior authorization is a net financial loss for practices. Another commenter VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 recommended that the Electronic Prior Authorization measure should remain optional until a time when the benefit, both monetarily and in reduced administrative burden, can be quantified for a calculated return on investment. Response: We appreciate the feedback provided by commenters and note that we believe the benefit of the Prior Authorization API will outweigh the burden of implementation. We refer readers to the Collection of Information (COI) requirements in section III. of this final rule regarding burden and the regulatory impact analysis (RIA) we conducted in section IV. of this final rule for the additional information on the cost calculations of this Electronic Prior Authorization measure for MIPS eligible clinicians reporting for the MIPS Promoting Interoperability performance category and for eligible hospitals and CAHs reporting for the Medicare Promoting Interoperability Program. We acknowledge that there is an initial implementation and data collection burden associated with the Electronic Prior Authorization measure. However, we believe that the benefits of using an electronic prior authorization process outweigh the burdensome manual process used today. We believe that making the prior authorization process electronic will improve the time and burden associated with the current process, allowing providers to put time back into direct patient care, and ultimately will reduce provider burnout. We emphasize that we are implementing requirements for both impacted payers and providers (that is, MIPS eligible clinicians, eligible hospitals, and CAHs) to help streamline the prior authorization process because both payers and providers have a role to play in this process and the solution cannot be one-sided. As discussed further in this section, in order to address concerns regarding the burden of the Electronic Prior Authorization measure on MIPS eligible clinicians, eligible hospitals, and CAHs, we are modifying the measure to be an attestation (yes/no) measure rather than a numerator and denominator measure. Therefore, data collection to report a numerator and denominator for the Electronic Prior Authorization measure is no longer required. Comment: A commenter cautioned that the Electronic Prior Authorization measure for the MIPS Promoting Interoperability performance category would reflect data regarding a different population than other MIPS measures, stating that other measures in MIPS are designed to capture information about the Medicare beneficiary population PO 00000 Frm 00156 Fmt 4701 Sfmt 4700 specifically. The commenter stated that this would make these measures difficult to compare. Another commenter stated that the Electronic Prior Authorization measure proposed for the MIPS Promoting Interoperability performance category does not apply to Medicare FFS, which results in misalignment. Response: We thank the commenters for their feedback. First, we disagree that the Electronic Prior Authorization measure will reflect data regarding a different population than other MIPS measures. We note that all of the MIPS Promoting Interoperability performance category measures are based on using CEHRT, utilizing data that are captured in the CEHRT, and require submission of applicable data, regardless of payer. The Electronic Prior Authorization measure is consistent with other measures reported under the MIPS Promoting Interoperability performance category. Second, although Medicare FFS is not an impacted payer, we refer readers to section I.D.1. of this final rule where we discuss CMS’s intent to align Medicare FFS to the requirements of this final rule, as applicable. Although, generally, the policies in this final rule do not directly pertain to Medicare FFS, we want to ensure that Medicare beneficiaries, as well as other individuals, can benefit from these policies, regardless of their coverage, delivery system, or payer. Comment: A commenter stated that, if CMS does move forward with the proposed Electronic Prior Authorization measure for the MIPS Promoting Interoperability performance category, CMS should consider exempting small, rural, and underserved practices from reporting the Electronic Prior Authorization measure, which would redistribute the Promoting Interoperability performance category’s weight to other performance categories. A few commenters suggested that the inclusion of the Electronic Prior Authorization measure would have a disproportionately adverse effect on small business entities, federally recognized American Indian and Alaska Native-Tribal communities, psychiatric practices, and other specialties and could contribute to the electronic divide. Response: We thank commenters for their feedback and would like to note that there are a number of situations in which MIPS eligible clinicians may qualify for reweighting of the MIPS Promoting Interoperability performance category. This includes policies implemented in our regulations at 42 CFR part 414, subpart O, including 42 E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations CFR 414.1380(c)(2), if they have a special status (defined at 42 CFR 414.1305), are a qualifying clinician type, or have a CMS-approved significant hardship or other exception application. For example, MIPS eligible clinicians in small practices (fifteen or fewer MIPS eligible clinicians) may have the MIPS Promoting Interoperability performance category reassigned a weight of zero percent automatically in the event the MIPS eligible clinician in a small practice (as verified by CMS on an annual basis) does not submit any data for any of the measures in that category as provided at 42 CFR 414.1380(c)(2)(i)(C)(9), and therefore would not be required to meet the MIPS Promoting Interoperability performance category’s requirements including reporting on this Electronic Prior Authorization measure (86 FR 65485–65487). If the MIPS Promoting Interoperability performance category is reweighted to zero percent as provided at 42 CFR 414.1380(c)(2)(i), the category’s 25 percent weight will be redistributed to the remaining MIPS performance categories in accordance with 42 CFR 414.1380(c)(2)(ii). Comment: Multiple commenters opposed the proposed addition of the Electronic Prior Authorization measure. Commenters believed that the finalization of the Electronic Prior Authorization measure would not be necessary because MIPS eligible clinicians, eligible hospitals, and CAHs would be prompted to voluntarily adopt and use the Prior Authorization API if the API achieves the goal of streamlining the prior authorization process, which likely would reduce provider burden, improve prior authorization processing time, and enable more timely access to care. Multiple commenters expressed that they do not believe that the proposed Electronic Prior Authorization measure would address concerns about low provider utilization of APIs, especially for small, rural providers, due to cost, limited bandwidth, and lack of dedicated health IT staff. A commenter expressed that they do not believe that the inclusion of the Electronic Prior Authorization measure would be a sufficient incentive for MIPS eligible clinicians, eligible hospitals, and CAHs to overcome the costs associated with the transaction. Some commenters stated that, as electronic prior authorization becomes more common and affordable, providers would be incentivized to adopt this process, which promises to free up resources and allow providers to spend more time on patient care. A commenter stated that VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 providers will be naturally incentivized to engage in electronic prior authorization processes if the processes lower costs, carry a minimal burden, do not cause unreasonable delays in care, and lead to care that is in their patients’ best interests. Another commenter stated that the proposal to add a measure on conducting electronic prior authorization for items or services using the Prior Authorization API is not sufficient to encourage robust use of the Prior Authorization API by providers and stated that the proposals will be a one-sided mandate on impacted payers. Response: We appreciate the commenters’ feedback and are glad to hear that providers likely would be naturally incentivized and prompted to voluntarily adopt and use the Prior Authorization API if the API achieves the goal of streamlining the prior authorization process, which we believe it will. However, based on experience with adoption of other similar new EHR technology, we believe there needs to be an initial drive to encourage all parties involved (payers and providers) to develop, implement, and use the new Prior Authorization API to support widespread adoption, thus reaping the benefits of burden reduction through the electronic prior authorization processes. We understand and agree that the Electronic Prior Authorization measure itself may not be enough to address concerns about low provider utilization of APIs, particularly for small and rural providers. However, we believe the improvement and benefits in the prior authorization processes resulting from using the Prior Authorization API, specifically, may encourage such providers to adopt the API to help streamline existing paper-based or portal-based processes. We acknowledge that small, rural providers may have limited bandwidth and fewer dedicated IT staff. We note that implementing an electronic prior authorization process could free up resources and allow providers to spend more time on patient care, which can be a challenge for small, rural providers. We also note that MIPS eligible clinicians in small practices (fifteen or fewer MIPS eligible clinicians) may have the MIPS Promoting Interoperability performance category reassigned a weight of zero percent automatically in the event the MIPS eligible clinician in a small practice (as verified by CMS on an annual basis) does not submit any data for any of the measures in that category as provided at 42 CFR 414.1380(c)(2)(i)(C)(9), and therefore would not be required to meet the category’s requirements including reporting on this Electronic Prior PO 00000 Frm 00157 Fmt 4701 Sfmt 4700 8913 Authorization measure (86 FR 65485– 65487). We believe that using electronic prior authorization processes will benefit small, rural providers, and small practices in underserved communities who are able to implement and maintain the Prior Authorization API in their processes with by saving time, faster turnaround on prior authorization requests, and, in turn, improved patient satisfaction. Comment: A commenter requested that CMS calculate the additional cost of compliance with the MIPS requirements generally and consider what benefit MIPS reporting offers when practices already have a great interest in lowering their expenses related to prior authorization. Response: We appreciate the commenter’s feedback regarding cost of the Electronic Prior Authorization measure and refer readers to the RIA we conducted in section IV. of this final rule for the additional information on the cost calculations of this Electronic Prior Authorization measure for MIPS eligible clinicians reporting for the MIPS Promoting Interoperability performance category and for hospitals and CAHs reporting for the Medicare Promoting Interoperability Program. We note that the cost of compliance and benefits of reporting for MIPS as a whole are outside the scope of this rule. We will continue to evaluate use of the Prior Authorization API and assess whether the Electronic Prior Authorization measure has achieved its goal of promoting widespread Prior Authorization API adoption. Comment: Multiple commenters acknowledged that the proposed Electronic Prior Authorization measure is not directed toward the impacted payers. A commenter stated that CMS should collect prior authorization data from payers to measure their performance rather than from providers. Another commenter noted that the electronic prior authorization proposal does not assess any financial costs against payers to discourage their overuse of prior authorizations. Response: We thank the commenters for their feedback and acknowledge that this Electronic Prior Authorization measure is not intended to incentivize payers to use the Prior Authorization API. For more information about the Prior Authorization API requirements for payers, we refer readers to section II.D. of this final rule. To reiterate, the success of the Prior Authorization API is dependent upon both payers and providers using the Prior Authorization API. We want to stress the importance of both payers and providers using the Prior Authorization E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8914 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations API to ensure that all parties can experience the maximum benefits of engaging in the electronic prior authorization process. Thus, we recognize the importance of not only requiring impacted payers to build, implement, and maintain the API, but also to drive MIPS eligible clinicians, eligible hospitals, and CAHs to use it. We agree that collecting prior authorization data from payers is important and provides accountability for using prior authorization processes. As such, we are finalizing our proposal to require payers to publicly report certain prior authorization metrics. We refer readers to section II.D. of this final rule for further information on these requirements for impacted payers. We note that prior authorization is an established administrative process used by payers to help control costs and ensure payment accuracy by verifying that an item or service is medically necessary, meets coverage criteria, and is consistent with standards of care before the item or service is provided. The policies we are finalizing are not intended to discourage the use of prior authorization, nor do they impose direct financial repercussions for using prior authorization by payers. The policies we are finalizing in this final rule are intended to streamline the existing prior authorization process. Comment: Multiple commenters noted that the adoption of the Electronic Prior Authorization measure contradicts CMS’s goal of reducing provider burden and urged CMS not to replace one type of administrative burden with another. Another commenter cautioned that the proposed Electronic Prior Authorization measure is not suitable for a quality improvement program given that the focus is on technological capability. A commenter stated that measures related to prior authorization conflict with the goal of MIPS to improve quality of health care, stating there is no evidence to indicate that prior authorization improves outcomes. Response: We disagree that the Electronic Prior Authorization measure conflicts with our goals and believe the policies we are finalizing in this rule are necessary to support a more efficient prior authorization process in the future. We believe this measure is entirely suitable for MIPS since the goal of MIPS is to provide financial incentives to clinicians that provide high-value and high-quality care to Medicare patients. MIPS supports care improvements by focusing on better patient outcomes and decreasing clinician burden. We believe that electronic prior authorization aligns with these goals, as it streamlines a VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 historically burdensome process to allow providers to spend more time focused on improving patient outcomes instead of administratively burdensome processes. We also believe that the Electronic Prior Authorization measure fits within the goals of the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category by enhancing the meaningful use of CEHRT. For the MIPS Promoting Interoperability performance category, section 1848(q)(2)(B)(iv) of the Act requires MIPS eligible clinicians to report on specified measures and activities demonstrating that they meet the requirements established under section 1848(o)(2) of the Act for determining whether the MIPS eligible clinician is a meaningful EHR user. For the Medicare Promoting Interoperability Program, section 1886(n) of the Act similarly requires eligible hospitals and CAHs to demonstrate that they meet requirements established under section 1886(n)(3)(A) (which align with section 1848(o)(2)(A) of the Act) for determining whether the eligible hospital or CAH is a meaningful EHR user. Electronic exchange of information to improve health care and care coordination is a central statutory requirement for both the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category. We proposed this measure under sections 1848(o)(2)(A)(ii) and 1886(n)(3)(A)(ii) of the Act for MIPS and the Medicare Promoting Interoperability Program, respectively, because we believed, and continue to believe, this measure will further enable the electronic exchange of health information to improve the quality of health care (87 FR 76312). More specifically, we believe the proposed Electronic Prior Authorization measure, which we are finalizing with modifications, is fundamental to determining whether a MIPS eligible clinician, eligible hospital, or CAH meets criterion two of being a meaningful EHR user: demonstrating that their CEHRT is connected in a manner that provides for the electronic exchange of health information to improve the quality of health care, such as promoting care coordination (sections 1848(o)(2)(A)(ii) and 1886(n)(3)(A)(ii) of the Act). We believe the Electronic Prior Authorization measure is another means by which MIPS eligible clinicians, eligible hospitals, and CAHs, can use their health IT to timely and efficiently share key health information with payers to obtain prior authorizations promptly and thereby provide necessary health care to their patients PO 00000 Frm 00158 Fmt 4701 Sfmt 4700 expeditiously. Therefore, we believe the Electronic Prior Authorization measure does meet the intended goal of these programs to promote interoperability and electronically exchange health information. Comment: Multiple commenters opposed the Electronic Prior Authorization measure stating that prior authorizations are a harmful practice that result in delays and denials of necessary care which can worsen a patient’s condition. Several commenters shared concerns about payer prior authorization policies themselves. A commenter stated that prior authorizations lower the costs for payers but raise the overall cost of care by delaying care and shifting costs to providers and patients, thus worsening clinical outcomes which necessitates the escalation of more expensive care. Response: We would like to thank commenters for their feedback regarding payers’ prior authorization processes and the burden placed on patients and providers. We understand that some commenters expressed concerns about prior authorization itself, regardless of whether it could be completed electronically, and whether or not these existing prior authorization requirements support improved outcomes. We note that the existence and use of prior authorization processes is outside the scope of this rule. Our policies are limited to streamlining this already existing process. The policies we are finalizing in this rule are not intended to encourage or discourage the prior authorization requirements that payers already have; these policies are intended to increase the efficiency of these existing requirements and processes by encouraging use of electronic methods. We understand that the existing prior authorization process can be burdensome, and thus believe the policies we are finalizing in this rule are necessary to support a more efficient prior authorization process in the future. We received many comments on the December 2020 CMS Interoperability proposed rule, which has since been withdrawn, and in response to the CMS Interoperability and Prior Authorization proposed rule that indicated that prior authorization processes could be improved by electronic, interoperable data exchange. Those comments have informed the policies we are finalizing in this rule. Comment: Multiple commenters stated that the Electronic Prior Authorization measure should not penalize LTCHs and Inpatient Rehabilitation Facilities (IRFs) for E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations failing to use EHRs. Another commenter expressed that practices have many different technical and infrastructure capabilities; therefore, they recommended that CMS consider ways to further engage and support all provider types—especially safety-net, small/independent, and/or rural health providers—to adopt and use the Prior Authorization API. The commenter continued by stating that they are concerned that these providers are at risk of being left behind. Likewise, the commenter stated that CMS should also explore ways to expand provider incentives to reach broadly across the health care system to encourage widespread adoption of the Prior Authorization API. Another commenter recommended that CMS include all health care providers as recipients of the benefits of the final rule, whether they are recipients of Meaningful Use dollars or are participants in MIPS. The commenter continued by providing a possible scenario in which payers further delay decisions of excluded providers in favor of meeting the requirements for providers included under the provisions of the rule. Response: We note that LTCHs and IRFs are not included in the definition of an eligible hospital or CAH (42 CFR 495.4 definitions, 75 FR 44327) and therefore would not be required to report the Electronic Prior Authorization measure under the Medicare Promoting Interoperability Program.161 We also understand that different practices have different technical and infrastructure capabilities. To the extent that these facilities or any provider type ordering items or services requiring prior authorizations have access to appropriate health IT and the Prior Authorization API and are otherwise permitted to use the Prior Authorization API, we encourage them to use this technology for their own benefit. Our proposals for the Prior Authorization API technology and functionality do not limit its use to participants under the MIPS Promoting Interoperability performance category and the Medicare Promoting Interoperability Program. We will continue to look for ways to encourage API implementation uptake and ways to incentivize the adoption of electronic prior authorization across additional programs and provider types, especially 161 Centers for Medicare and Medicaid Services (2023, September 6). Medicare Promoting Interoperability Program: Eligibility Hospital Information. Retrieved from https://www.cms.gov/ Regulations-and-Guidance/Legislation/ EHRIncentivePrograms/Eligibility-#BOOKMARK2. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 safety-net, small/independent, and rural health providers. Additionally, we appreciate the comment regarding possible scenarios in which impacted payers further delay decisions on prior authorizations from providers not participating in MIPS or the Medicare Promoting Interoperability Program or not using the Prior Authorization API. However, to mitigate this, we are finalizing certain prior authorization decision timeframes for all impacted payers. We refer readers to section II.D. of this final rule for more information on the prior authorization decision timeframe provisions. Comment: A commenter suggested that instead of developing the Electronic Prior Authorization measure, CMS should engage in stringent oversight to ensure that impacted payers are not only developing and implementing a Prior Authorization API but are also implementing all of the provisions of this final rule. The commenter also suggested that CMS should release additional information on how it will enforce the proposed requirements contained in the CMS Interoperability and Prior Authorization proposed rule to ensure compliance. Response: As explained in the proposed rule, and in the CMS Interoperability and Patient Access final rule, each program oversees compliance under existing program authorities and responsibilities. These compliance processes vary among programs and may have different implications based on a payer’s status in the program, previous compliance actions, and corrective action. Patients and providers should submit an inquiry or complaint to the appropriate program, depending on their coverage as described in section I.D.2. of this final rule. Compliance questions or complaints about compliance may be sent to the respective program contact at the website or email address provided there. Compliance will be tracked through specific methods managed by the programs. While these compliance efforts will help payer compliance, as we have stated repeatedly throughout this section, it is imperative that both payers and providers come together to use the Prior Authorization API to ensure that all parties can experience the maximum benefits of engaging in the electronic prior authorization process. Thus, we recognize the importance of not only requiring impacted payers to build the Prior Authorization API, but also to incentivize MIPS eligible clinicians, eligible hospitals, and CAHs to use it through the finalization of this Electronic Prior Authorization measure. PO 00000 Frm 00159 Fmt 4701 Sfmt 4700 8915 Comment: A commenter stated that CMS lacks a legitimate justification for imposing the new Electronic Prior Authorization measure, as it does not align with the legal requirements under section 1848(q) of the Act. The commenter sought clarification on how the proposed measure complies with the governing regulations. Response: We have authority under section 1848(q)(2)(A)(iv) and (B)(iv) of the Act, which requires that we assess MIPS eligible clinicians’ performance with respect to their meaningful use of CEHRT in accordance with the requirements established in section 1848(o)(2) of the Act. We also have authority under section 1848(q)(2)(B)(iv) of the Act to create new measures under the MIPS Promoting Interoperability performance category as well as for determining whether an eligible professional is a meaningful EHR user in accordance with the requirements established in section 1848(o)(2) of the Act. Connecting to the API technology identified in the Electronic Prior Authorization measure helps to facilitate bi-directional data exchange electronically and can significantly reduce the burden associated with the prior authorization processes for providers using data from CEHRT when accessing the Prior Authorization API. This type of function demonstrates meaningful use of CEHRT and is therefore appropriate in assessing whether a MIPS eligible clinician is a meaningful EHR user under section 1848(o)(2)(A) of the Act. Comment: A commenter requested that CMS use its authority to permit payers to include quality measures tied to use of the APIs in the provider contracts. Response: We appreciate the commenter’s recommendation. However, we leave this decision— whether payers require measures like this for their providers and how they work with their providers on using the Prior Authorization API—up to the discretion of the payers. a. Measure Specifications In the proposed rule (87 FR 76313), we proposed the following specifications for the Electronic Prior Authorization measure: 162 162 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.’’ E:\FR\FM\08FER2.SGM 08FER2 8916 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations 1. For MIPS Eligible Clinicians Under the MIPS Promoting Interoperability Performance Category—Electronic Prior Authorization • Measure Description: For at least one medical item or service (excluding drugs) ordered by the MIPS eligible clinician during the performance period, the prior authorization is requested electronically from a Prior Authorization API using data from CEHRT. The MIPS eligible clinician would be required to report a numerator and denominator for the measure or (if applicable) report an exclusion: • Denominator: The number of unique prior authorizations requested for medical items and services (excluding drugs) ordered by the MIPS eligible clinician during the performance period, excluding prior authorizations that cannot be requested using the Prior Authorization API because the payer does not offer an API that meets the Prior Authorization API requirements outlined in section II.D.3.a. of the CMS Interoperability and Prior Authorization proposed rule. • Numerator: The number of unique prior authorizations in the denominator that are requested electronically from a Prior Authorization API using data from CEHRT. • Exclusion: Any MIPS eligible clinician who: (1) Does not order any medical items or services (excluding drugs) requiring prior authorization during the applicable performance period; or (2) Only orders medical items or services (excluding drugs) requiring prior authorization from a payer that does not offer an API that meets the Prior Authorization API requirements outlined in section II.D.3.a. of the CMS Interoperability and Prior Authorization proposed rule during the applicable performance period. lotter on DSK11XQN23PROD with RULES2 2. For Eligible Hospitals and Critical Access Hospitals Under the Medicare Promoting Interoperability Program— Electronic Prior Authorization • Measure Description: For at least one hospital discharge and medical item or service (excluding drugs) ordered during the EHR reporting period, the prior authorization is requested electronically via a Prior Authorization API using data from CEHRT. The eligible hospital or CAH would be required to report a numerator and denominator for the measure or (if applicable) report an exclusion: • Denominator: The number of unique prior authorizations requested for medical items and services VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 (excluding drugs) ordered for patients discharged from the eligible hospital or CAH inpatient or emergency department (POS code 21 or 23) during the EHR reporting period, excluding prior authorizations that cannot be requested using the Prior Authorization API because the payer does not offer an API that meets the Prior Authorization API requirements outlined in section II.D.3.a. of the proposed rule. • Numerator: The number of unique prior authorizations in the denominator that are requested electronically from a Prior Authorization API using data from CEHRT. • Exclusions: Any eligible hospital or CAH that— ++ Does not order any medical items or services (excluding drugs) requiring prior authorization during the applicable EHR reporting; or ++ Only orders medical items or services (excluding drugs) requiring prior authorization from a payer that does not offer an API that meets the Prior Authorization API requirements outlined in section II.D.3.a. of the proposed rule during the applicable EHR reporting period. Comment: Multiple commenters expressed support for CMS’s proposal regarding the proposed Electronic Prior Authorization measure’s numerator and denominator criteria. Specifically, a commenter agreed with the numerator being the number of unique prior authorizations that are requested electronically via a Prior Authorization API using data from CEHRT if the Electronic Prior Authorization measure includes electronic prior authorizations from commercial payers. A commenter recommended that CMS ask for the percentage of prior authorization requests that are not being completed through the Prior Authorization API. Another commenter supported CMS’s proposal to include prior authorization requests that are made using fax, mail, or portal in the denominator of the Electronic Prior Authorization measure unless the prior authorization cannot be requested using the Prior Authorization API because the payer does not offer an API that meets the Prior Authorization API requirements, in which case it would be excluded from the denominator. A commenter expressed support for CMS progressing the proposed Electronic Prior Authorization measure to a performance-based measure in future years. Response: We thank the commenters for their feedback and appreciate their support for the numerator and denominator criteria for the Electronic Prior Authorization measure for the MIPS Promoting Interoperability PO 00000 Frm 00160 Fmt 4701 Sfmt 4700 performance category and the Medicare Promoting Interoperability Program. We agree that requiring participants to report a numerator and denominator for the measure would ultimately give us the most insight into the degree of adoption and use of the Prior Authorization API. However, after consideration of comments received, and as discussed in more detail later in this section, we are modifying the specifications of the Electronic Prior Authorization measure to require an attestation (yes/no), in lieu of reporting data for a numerator and denominator as proposed, for this measure beginning with the CY 2027 performance period/ 2029 MIPS payment year for MIPS and the CY 2027 EHR reporting period for the Medicare Promoting Interoperability Program. Comment: A commenter suggested that CMS explore different mechanisms for tracking electronic prior authorization requests. A few commenters also noted that tracking these data elements should be the responsibility of payers, as they would have this information more easily accessible. Another commenter stated that CMS needs to determine an approach to measure the usage of electronic prior authorization tools that does not require collecting information about the availability of corresponding APIs or functionality. Another commenter stated that measuring the success of these policies should not be punitive for providers and that the metrics of success should exist for all stakeholders. Multiple commenters urged CMS to work with the provider community, as well as other stakeholders, on various aspects of the Electronic Prior Authorization measure as well as other prior authorization reforms to identify ways to incentivize provider uptake without creating unnecessary provider burden and determine how to engage providers in the testing and development of the proposed Electronic Prior Authorization measure. Another commenter noted that the technology supporting electronic prior authorization must be widely available and demonstrated to be effectively integrated into EHR workflows through real-world testing prior to requiring MIPS eligible clinicians, eligible hospitals, and CAHs to report on use of the Prior Authorization API for the Electronic Prior Authorization measure. A commenter suggested that CMS should require payers to provide these data on electronic prior authorization, rather than place increasing demands on providers. E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations Response: We thank the commenters for their recommendations. We will consider exploring additional mechanisms for tracking electronic prior authorization requests in future rulemaking. We believe that tracking the use of electronic prior authorization processes by impacted payers and providers (that is, MIPS eligible clinicians, eligible hospitals, and CAHs) is important to ensure widespread implementation and use of the Prior Authorization API by both user groups. In this context, we view the Electronic Prior Authorization measure not merely as a way to track performance or success. Instead, we view this measure as a way for MIPS eligible clinicians, eligible hospitals, and CAHs to adopt and use the electronic Prior Authorization APIs implemented by payers. As we have noted previously, payers impacted by this rule are required to implement and maintain the Prior Authorization API. To fully recognize the benefits and efficiencies of payer implementation of this API, we need to encourage providers to use said API to complete prior authorization requests. While we are encouraged by commenters’ statements that the benefits of the Prior Authorization API are enough to encourage providers to use it, we also believe that accessing this API using data from CEHRT demonstrates meaningful use of CEHRT that can improve patient care under sections 1848(o)(2)(A) and 1886(n)(3)(A) of the Act, and thus believe this measure is appropriate to incentivize providers to adopt and use this technology. We refer readers to section II.D. of this rule where we discuss in further detail the metrics impacted payers will be required to report on electronic prior authorizations. We note that we do not currently use established workgroups to test and develop measures for the Medicare Promoting Interoperability Program or the MIPS Promoting Interoperability performance category outside of our annual call for measures.163 We do work with members of the provider community in HL7 workgroups to obtain their feedback during the development and testing phases of the IGs that support the Prior Authorization API, as well as during discussions around technical workflow. We encourage providers to engage in the HL7 FHIR workgroup meetings to get involved in the standards development 163 Centers for Medicare and Medicaid Services. (2023, September 6). Annual Call For Measures. Retrieved from https://www.cms.gov/Regulationsand-Guidance/Legislation/EHRIncentivePrograms/ CallForMeasures. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 and implementation discussions for specific use cases. The IGs are also tested during Connectathons and throughout the IG development lifecycle and refined based on testing and implementation feedback. We have also previously reviewed public comments received on the Reducing Burden and Improving Electronic Information Exchange of Prior Authorizations RFI (85 FR 82639) and December 2020 CMS Interoperability proposed rule (85 FR 82586) regarding ways in which we could incentivize and encourage provider use of the electronic Prior Authorization API and used that feedback to develop our policies outlined in this final rule. Comment: Multiple commenters expressed their disapproval of the proposed Electronic Prior Authorization measure’s numerator and denominator criteria. Numerous commenters stated that the Electronic Prior Authorization measure as proposed would create significant data collection and reporting burden on MIPS eligible clinicians, eligible hospitals, CAHs, and support staff. Many commenters specifically identified the excessive burden with calculating the denominator. Multiple commenters expressed concern regarding identifying which prior authorization requests meet the denominator requirements of the proposed Electronic Prior Authorization measure (for example, which payers offer a Prior Authorization API or how a provider will be able to determine the number of prior authorization requests that should be counted in the denominator) making this measure particularly burdensome, contributing to provider burnout, and causing further delays in care. A commenter sought clarification on whether CMS is considering alternatives to the proposed numerator and denominator measure criteria and requested changes to these specifications that would reduce the implementation burden for both providers and health IT developers. Some commenters expressed concern regarding compliance and documentation for the proposed Electronic Prior Authorization measure. Commenters stated that providers submit prior authorizations in a variety of modalities and noted it will be hard to track all prior authorizations submitted. Other commenters expressed similar concerns given that data surrounding prior authorizations are captured outside of an EHR, which would make the data collection process extremely burdensome. Several commenters urged CMS not to implement the Electronic Prior Authorization measure as proposed due PO 00000 Frm 00161 Fmt 4701 Sfmt 4700 8917 to these concerns or consider ways the measure could be implemented without increasing provider burden. A commenter recommended that CMS continue to evaluate the numerator and denominator proposals and adjust the requirements based on real-world testing. Another commenter questioned why CMS would create a numerator/ denominator measure that is not automatically calculated by EHRs. The commenter continued by stating that several EHR vendors will likely not have the capability to assist in tracking prior authorization requests for reporting purposes. Another commenter disagreed with the proposed measure criteria to collect information on the total number of prior authorization requests submitted by the Prior Authorization API versus other request methods given that collecting these data does nothing to improve patient clinical outcomes. Therefore, multiple commenters recommended that CMS should use an attestation (yes/no) measure and remove the proposed numerator/denominator criteria. Response: We appreciate the commenters sharing their concerns regarding the burden associated with calculating a numerator and denominator as proposed for the Electronic Prior Authorization measure. Generally, we proposed that to report these measures, MIPS eligible clinicians, eligible hospitals, and CAHs must use data from their CEHRT to request prior authorization from a payer for at least one medical item or service (excluding drugs), and, for eligible hospitals and CAHs, one hospital discharge and medical item or service that they ordered via the Prior Authorization API (87 FR 76313). However, we recognize that the challenge of consistently calculating a numerator and denominator for these proposed measures across providers increases if providers are accessing the Prior Authorization API in different ways. We further recognize that it would be challenging for MIPS eligible clinicians, eligible hospitals, and CAHs to report a numerator and denominator for these measures as we proposed until such time as the ONC Health IT Certification Program establishes health IT certification criteria to support standardized exchange via the Prior Authorization API and adopts updated certification criteria supporting numerator and denominator calculation. We acknowledge that modifying the Electronic Prior Authorization measure to be attestation-based would substantially reduce the reporting burden placed on MIPS eligible clinicians, eligible hospitals, and CAHs. E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8918 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations With an attestation-based yes/no measure, those providers would be required to report a yes/no response, rather than a numerator and denominator, to indicate whether they used a Prior Authorization API to submit at least one electronic prior authorization during the applicable performance period/MIPS payment year or EHR reporting period. After consideration of this feedback, and as discussed in more detail later in this section, we are modifying the Electronic Prior Authorization measure to be an attestation measure, meaning that MIPS eligible clinicians, eligible hospitals, and CAHs will report a yes/no response for the measure. We will continue to explore ways to move toward numerator and denominator reporting for future years of the measure, particularly should ONC Health IT Certification Program criteria be made available to support certification of EHRs to the capability associated with tracking prior authorizations requested electronically via the Prior Authorization API using data from CEHRT. Comment: A commenter stated that the Electronic Prior Authorization measure should not be restricted only to items and services but should also include drugs to provide consistency across prior authorization needs. Response: As discussed earlier in this final rule, the Prior Authorization API requirements we have finalized for impacted payers are limited to medical items and services (excluding drugs). Therefore, for consistency, we are aligning using the API for the Electronic Prior Authorization measure to limit it to evaluating using a Prior Authorization API for medical items and services authorization requests only. We refer readers to section II.D. for additional information on the Prior Authorization API requirements for impacted payers and the exclusion of drugs. Comment: A commenter stated that industry would need to review and endorse the specification criteria prior to requiring the Electronic Prior Authorization measure. Response: We thank commenters for this suggestion; however, we must note that there is no requirement for industry to review or endorse measures in either the MIPS Promoting Interoperability performance category or the Medicare Promoting Interoperability Program. We welcome comments from any interested parties through public comment during rulemaking, and also during the annual call for measures for the MIPS Promoting Interoperability performance category and the Medicare Promoting Interoperability Program, every summer. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 Comment: Multiple commenters expressed concern that MIPS eligible clinicians, eligible hospitals, and CAHs will not have the necessary health IT to support the Prior Authorization API and therefore will not be able to report the proposed Electronic Prior Authorization measure by the proposed implementation year of CY 2026. Multiple commenters urged CMS to delay mandating the proposed Electronic Prior Authorization measure until adequate standards and specifications are available to support electronic prior authorization, the Prior Authorization API is implemented, and workflow is established. A commenter stated that providers should have the flexibility to stage their adoption, as recognized in the Electronic Prior Authorization measure proposal, to support a smooth transition from the current, manual process to a fully electronic workflow. Another commenter suggested that CMS needs to provide eligible hospitals with adequate time to convert their current processes into an electronic prior authorization process prior to implementing the Electronic Prior Authorization measure under the Medicare Promoting Interoperability Program. The commenter expressed their concern that this transition to a new electronic process will allow cases to fall through the cracks. Response: We thank the commenters for their feedback. After reviewing comments for both the Prior Authorization API and for using that API in this Electronic Prior Authorization measure, we reconsidered our proposal and agree that provision of additional time for implementation would be beneficial. As previously discussed, we understand that there may be challenges with the availability of health IT to calculate a measure numerator and denominator consistently for the Electronic Prior Authorization measures as we originally proposed. We also believe the functionality of the Prior Authorization API should be in place and used by hospitals and providers prior to requiring a numerator and denominator be reported. We will continue to work with ONC to explore the adoption of standards and health IT certification criteria where appropriate to streamline data exchange, support interoperability, and increase efficiencies associated with the policies in this final rule. As noted previously, the Unified Agenda, current at the time of this final rule’s publication, includes an entry for a proposed rule from ONC (RIN 0955– AA06). The description indicates that PO 00000 Frm 00162 Fmt 4701 Sfmt 4700 that proposed rule aims to advance interoperability, including proposals to expand the use of certified APIs for electronic prior authorization.164 As previously discussed, we are finalizing the Electronic Prior Authorization measure with modification, to delay implementation for a year later than originally proposed, beginning with CY 2027 performance period/2029 MIPS payment year for MIPS eligible clinicians in the MIPS Promoting Interoperability performance category, and beginning with the CY 2027 EHR reporting period for eligible hospitals and CAHs under the Medicare Promoting Interoperability. This modification also aligns with the finalized compliance dates in 2027 for the Prior Authorization API. Also, as previously discussed, we are finalizing the Electronic Prior Authorization measure with modification as an attestation (yes/no) measure, instead of requiring reporting of data for a numerator and denominator. We believe this modification will minimize data collection and reporting burden for this measure. Comment: Many commenters recommended that the Electronic Prior Authorization measure be an attestation (yes/no) measure to mitigate provider burden if CMS moves forward with the proposed measure. Some commenters stated that they are not opposed to the Electronic Prior Authorization measure and appreciated CMS not scoring it initially. However, a commenter noted there may be implementation challenges due to eligible hospitals and CAHs still recovering from the PHE and not having enough resources to implement. Another commenter suggested that the Electronic Prior Authorization measure remain unscored indefinitely. The commenter noted that the Prior Authorization API still being in the pilot testing phase is an additional challenge. Another commenter expressed their appreciation for the implementation timeline of the Electronic Prior Authorization measures stating that it would allow for technical implementation, provider implementation, and education. Multiple commenters were displeased with the proposed scoring methodology for the Electronic Prior Authorization measure. Multiple commenters recommended that CMS consider making the Electronic Prior 164 Office of Information and Regulatory Affairs (2023, November). Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability. Retrieved from https://www.reginfo.gov/public/do/ eAgendaViewRule?pubId=202304&RIN=0955AA06. E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations Authorization measure voluntary or award bonus points for the proposed Electronic Prior Authorization measure rather than including the measure in the composite score. A commenter stated that an attestation (yes/no) measure would align the proposed Electronic Prior Authorization measure with the other measures within the HIE objective. Response: We appreciate the commenters’ concerns and recommendations on ways to ease burden by making the Electronic Prior Authorization measure an attestation (yes/no) measure. We agree and acknowledge that it would significantly reduce the reporting burden for MIPS eligible clinicians, eligible hospitals, and CAHs if we did not require a numerator and denominator to be calculated, and instead require only a ‘‘yes’’ or ‘‘no’’ response be reported to indicate whether the Prior Authorization API was used for at least one prior authorization during the applicable performance period/MIPS payment year or EHR reporting period. After consideration of this feedback, and as discussed in more detail elsewhere in this section, we are modifying the proposed Electronic Prior Authorization measure to be reported as an attestation (yes/no) measure. We appreciate the commenters’ recommendations for scoring this measure, such as not scoring the measure or only assigning bonus points. However, we respectfully disagree with these approaches. First, we did not propose to score this measure by assigning points (for example, between 10 and 30 points for successful completion as provided at 42 CFR 414.1380(b)(4)(ii) for MIPS). However, we did propose that a MIPS eligible clinician, eligible hospital, or CAH would ‘‘receive a zero score for the MIPS Promoting Interoperability performance category or the Medicare Promoting Interoperability Program’’ if they did not ‘‘report a numerator of a least one for the measure or claim an exclusion’’ (87 FR 76313). In other words, we proposed that if a MIPS eligible clinician, eligible hospital, or CAH failed to request at least one prior authorization electronically via the Prior Authorization API using data from their CEHRT, as would be required to report a numerator under the originally proposed measure specifications (attesting ‘‘no’’ to the measure), or claim an applicable exclusion, then they would not meet the minimum reporting requirements, not be considered a meaningful EHR user, and fail the Medicare Promoting Interoperability Program or the Promoting Interoperability performance category. A VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 failure in the Medicare Promoting Interoperability Program would result in a downward payment adjustment for eligible hospitals or CAHs (unless the eligible hospital or CAH receives a hardship exception). A failure in the MIPS Promoting Interoperability performance category would result in the MIPS eligible clinician receiving a score of zero for the performance category, which is currently worth 25 percent of their final score for MIPS. Second, we clarify our rationale for proposing this scoring policy of zero for this measure, which we are finalizing with modification to align with the attestation-based measure specifications we are finalizing in this section. Fundamentally, a MIPS eligible clinician, eligible hospital, or CAH must demonstrate it is a meaningful EHR user by meeting three statutory criteria set forth in sections 1848(o)(2)(A) and 1886(n)(3)(A) of the Act, to earn a score for the MIPS Promoting Interoperability performance category (section 1848(q)(2)(B)(iv) of the Act) or avoid a downward payment adjustment for the Medicare Promoting Interoperability Program. We proposed this measure under sections 1848(o)(2)(A)(ii) and 1886(n)(3)(A)(ii) of the Act for MIPS and Medicare Promoting Interoperability Program, respectively, because we believed, and continue to believe, this measure would further enable the electronic exchange of health information to improve the quality of health care (87 FR 76312). More specifically, we believe the proposed Electronic Prior Authorization measure, which we are finalizing with modification, is fundamental to determining whether a MIPS eligible clinician, eligible hospital, or CAH meets criterion two of being a meaningful EHR user: demonstrating that their CEHRT is connected in a manner that provides for the electronic exchange of health information to improve the quality of health care, such as promoting care coordination (sections 1848(o)(2)(A)(ii) and 1886(n)(3)(A)(ii) of the Act). A MIPS eligible clinician, eligible hospital, or CAH using the Prior Authorization API to request at least one prior authorization electronically for, or claiming an applicable exclusion from, reporting this measure, fundamentally demonstrates that they are a meaningful EHR user. Therefore, we believe that failure to report the Electronic Prior Authorization measure as specified, or to claim an applicable exclusion, demonstrates they are not a meaningful EHR user and warrants the MIPS eligible clinician, eligible hospital, or CAH receiving a score of zero for the PO 00000 Frm 00163 Fmt 4701 Sfmt 4700 8919 MIPS Promoting Interoperability performance category or Medicare Promoting Interoperability Program. After consideration of public comments we received, we are finalizing a modification to our proposal that the Electronic Prior Authorization measure will require MIPS eligible clinicians, eligible hospitals, and CAHs to report a numerator and denominator, and instead, require that MIPS eligible clinicians, eligible hospitals, and CAHs attest ‘‘yes’’ or ‘‘no’’ to having performed at least one electronic prior authorization using the Prior Authorization API, or claim an applicable exclusion. We are also finalizing that, if a MIPS eligible clinician, eligible hospital, or CAH attests ‘‘no’’ or fails to claim an applicable exclusion for this measure, then they will receive a zero score for the MIPS Promoting Interoperability performance category (currently worth 25 percent of their final score for MIPS) or fail to meet Medicare Promoting Interoperability Program reporting requirements. To allow for additional implementation time, we are finalizing inclusion of the Electronic Prior Authorization measure in the MIPS Promoting Interoperability performance category beginning with the CY 2027 performance period/2029 MIPS payment year and in the Medicare Promoting Interoperability program beginning with the CY 2027 EHR reporting period. Comment: Some commenters expressed concerns that providers may be unfavorably evaluated or unfairly penalized for infrastructure and system issues or lack of capabilities and not the providers’ willingness or desire to conduct electronic prior authorizations. A commenter requested clarification on the proposed measure exclusion criteria applying only to medical items and services (excluding drugs) requiring prior authorization from a payer that does not offer a Prior Authorization API, questioning whether this exclusion would lead to unintended consequences. Response: We recognize that these capabilities may not yet be widely adopted in some settings, and that successful implementation of these capabilities may vary across providers and systems. We note that we are finalizing that the Electronic Prior Authorization measure would be reported as an attestation (yes/no) measure, as opposed to the proposed numerator and denominator, which should reduce some of the initial implementation challenges. We are also finalizing that the measure would first be reportable beginning with the CY E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8920 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations 2027 performance period/2029 MIPS payment year and CY 2027 EHR reporting period. This delayed implementation will give both providers (that is, MIPS eligible clinicians, eligible hospitals, and CAHs) and payers time to implement these changes to workflows and establish integrations prior to the measure reporting being required. We believe electronic prior authorization capabilities represent an important investment that will benefit providers, patients, and other health care system entities. We note that some payers do not fall under the definition of impacted payers in this final rule. Therefore, we are finalizing the measure’s exclusion criterion (excluding MIPS eligible clinicians, eligible hospitals, and CAHs that only order medical items or services [excluding drugs] requiring prior authorization from a payer that does not offer an API that meets the Prior Authorization API requirements finalized in this final rule) because we do not want to penalize MIPS eligible clinicians, eligible hospitals, or CAHs for ordering medical items or services (excluding drugs) from payers that do not have the API functionality for reasons such as not being an impacted payer. Comment: A commenter stated that they oppose measures that could negatively impact a MIPS eligible clinician’s score, such as the current allor-nothing scoring methodology used to score the MIPS Promoting Interoperability performance category. Another commenter stated their belief that the proposed rule lacks detail on how the Electronic Prior Authorization measure will be scored and tied into the broader scoring of the Medicare Promoting Interoperability Program for eligible hospitals and CAHs. Response: We note that the overall scoring methodology for MIPS Promoting Interoperability performance category is not being changed with the addition of the Electronic Prior Authorization measure, nor the scoring methodology for the HIE measure itself. As discussed previously in this section, we believe that failure to report the Electronic Prior Authorization measure as specified, or to claim an applicable exclusion, demonstrates that the MIPS eligible clinicians is not a meaningful EHR user and warrants the MIPS eligible clinician receive a score of zero for the MIPS Promoting Interoperability performance category. While we understand that the all-or-nothing approach requires MIPS eligible clinicians to report and attest to all requirements, we note that requiring the Electronic Prior Authorization measure is in alignment with our scoring policies VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 and methodologies. Our regulation at 42 CFR 414.1375(b) provides that, to earn a score for the MIPS Promoting Interoperability performance category, the MIPS eligible clinician must report on objectives and associated measures as specified by CMS. For additional information on overall MIPS scoring policies and MIPS Promoting Interoperability performance category scoring policies, we refer readers to our regulations at 42 CFR 414.1375 (governing the requirements for the MIPS Promoting Interoperability performance category), 42 CFR 414.1380 (governing scoring for MIPS), as well as Table 46: Scoring Methodology for the Performance Period in CY 2024 for the Promoting Interoperability performance category in the CY 2024 PFS final rule (88 FR 52587). For information on the overall scoring methodology currently used to calculate MIPS final scores, we refer readers to the MIPS Final Score Methodology section in the CY 2024 PFS final rule (88 FR 52591). To be considered a meaningful EHR user, fulfill the minimum reporting requirements, and avoid a downward payment adjustment, the Medicare Promoting Interoperability Program requires that eligible hospitals and CAHs meet, by reporting on or attesting to, all objectives and measures selected by CMS. Failure to meet the minimum reporting requirements results in failure of the Medicare Promoting Interoperability Program, subjecting the eligible hospital or CAH to a downward payment adjustment (unless the eligible hospital or CAH receives a hardship exception). b. Prior Authorization API Functionality In the proposed rule (87 FR 76313), we proposed that a prior authorization request must be made using the Prior Authorization API to satisfy the Electronic Prior Authorization measure. The Prior Authorization API functionality is outlined in further detail in section II.D.2. of this final rule. We proposed that prior authorization requests that are made using fax, mail, or portal would be included in the denominator of the measure unless the prior authorization cannot be requested using the Prior Authorization API because the payer does not offer an API that meets the Prior Authorization API requirements, in which case any such prior authorization request would be excluded from the denominator. Instances where a payer offering the Prior Authorization API specifically requests a mailed or faxed prior authorization would be included in the denominator. Prior authorization requests that are made using fax, mail, PO 00000 Frm 00164 Fmt 4701 Sfmt 4700 or portal would not be included in the numerator of the measure because these methods would not incentivize using the standards-based API functionality as intended by the measure. Prior authorizations for any and all drugs would be excluded from both the numerator and denominator of the measure. (For a more detailed discussion of the exclusion of drugs, see section I.C. of this final rule.) We proposed that only prior authorizations that are requested electronically via a Prior Authorization API using data from CEHRT would be included in the numerator. Using the API to query documentation requirements alone, and not to request the prior authorization, would not count in the numerator or denominator. To satisfy the Electronic Prior Authorization measure, the health care provider uses data from their CEHRT (such as patient demographics and medical information) to justify the prior authorization request. The Prior Authorization API then automates the HIPAA-compliant prior authorization request. Additional information not contained in CEHRT may also be required for submission. Comment: Multiple commenters urged CMS to delay mandating the proposed Electronic Prior Authorization measure until adequate standards and specifications are available to support electronic prior authorization and until the Prior Authorization API workflow is established. A commenter urged CMS to evaluate whether sufficient implementation guidance exists to support automating data retrieval before moving to require the Electronic Prior Authorization measure in future years. Some commenters noted that CMS must ensure that the desired standards outlined in the Electronic Prior Authorization measure specification are achievable. Another commenter recommended that CMS make all IGs required for payers so the burden is not placed on providers to figure out something that will be incredibly difficult and resource-intensive to do. Another commenter recommended that CMS or ONC should issue an IG to ensure there is standardization of implementation across payers. The commenter stated that IGs could reduce payer variability in the creation of the Prior Authorization API. Another commenter sought clarification on how it will be feasible for CEHRT to implement an API-based prior authorization functionality to support performance measurement if payers are not required to adhere to standardized IGs. The commenter stated that for this to occur seamlessly CEHRT standards E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations would need to be updated appropriately. Response: We thank the commenters for sharing their recommendations. We are working with HL7, the HL7 FHIR accelerator workgroups, and interested parties within the standards development industry to move the IGs towards greater maturity by defining technical specifications, participating in and convening testing events for them, and developing and maintaining the technical specifications. Electronic prior authorization using a FHIR API has been implemented and is in production, proving sufficient implementation guidance exists. We agree that IGs help to ensure standardization of implementation across the industry. In section II.G. of this final rule, we outline the required standards and technical specifications necessary to build the Prior Authorization API and to ensure that implementation is consistent across all impacted payers and providers to avoid unnecessary duplication of efforts. We have also recommended certain IGs to help providers and payers meet that requirement. These IGs are developed using a consensus process involving many members of the payer and provider communities. They aid in the implementation process of the APIs. We anticipate that payers will use the recommended IGs so that most, if not all, providers benefit from a standardized approach to accessing patient data with all payers with whom they contract. Our approach in the proposed rule of recommending, but not requiring, the specific IGs for each API implementation was to provide directional guidance with flexibility to the industry without locking implementers into the versions available at the time of the proposed rule. As industry moves forward with implementation of these policies and use of these standards, industry can continue to harmonize on common approaches that work, eventually culminating in a required set of specifications when ready. Comment: A commenter recommended that CMS explain that the electronic prior authorization workflow does not necessarily need to be completed by the provider and that such workflows do not necessarily need to be included in CEHRT. The commenter recommended that CMS emphasize that only using data from CEHRT as part of the process for requesting prior authorization via a payer’s Prior Authorization API is sufficient to meet the Electronic Prior Authorization measure. Another commenter suggested that CMS should consider not limiting the Electronic Prior Authorization VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 measure to only data relevant to a prior authorization that is obtained from an EHR as relevant prior authorization data may not be limited to the provider’s EHR alone. A commenter stated that certain health insurance data, clinical data, and other administrative data subject to follow-up requests or initial submissions may exist in non-EHR systems in use. The commenter stated that this further underscores the premise that any health IT developer wishing its health IT to be certified must support all USCDI in its health IT. The commenter stated that USCDI as a driver to enable standards-based exchange is increasingly less relevant and, instead, the various IGs would indicate what participating systems should support. A commenter requested clarification on the expectations for incorporating such workflows into the Medicare Promoting Interoperability Program. The commenter sought clarification on whether eligible hospitals are expected to begin to share prior authorization information via the integrations with HINs to meet the bi-directional HIE measure. Multiple commenters encouraged the use of HIEs to connect impacted payers and providers to facilitate electronic prior authorization. A commenter stated that HIEs could provide support for continuing to connect providers and payers, including for the purposes of prior authorization. Another commenter recommended that CMS should include an optional, alternative measure that allows MIPS eligible clinicians, eligible hospitals, and CAHs to claim a Promoting Interoperability credit by attesting to using a HIE/HIN to request a prior authorization. Another commenter recommended that CMS create a health IT activity as part of the HIE Objective for mapping to a Prior Authorization API that is measured by the transmission of at least one prior authorization through the Prior Authorization API. Response: We did not propose, and are not finalizing, details of a specific workflow, or by whom, that must be completed to report the Electronic Prior Authorization measure beyond specifying that data from CEHRT must be used for the transaction with a Prior Authorization API. CMS recognizes that, under the Electronic Prior Authorization measure that we are finalizing in this rule, MIPS eligible clinicians, eligible hospitals, and CAHs may utilize different workflows to submit an electronic prior authorization request. As noted, the Unified Agenda, current at the time of publication of this final rule, includes an entry for a proposed rule PO 00000 Frm 00165 Fmt 4701 Sfmt 4700 8921 from ONC entitled ‘‘Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability’’ (RIN 0955–AA06). The description for this proposed rulemaking notes that this rule aims to advance interoperability through proposals for the expanded use of certified APIs for electronic prior authorization, among other proposals.165 We plan to continue to explore how potential future updates to the ONC Health IT Certification Program can support our policies and will address any updates to our requirements related to these future updates to the ONC Health IT Certification Program criteria if finalized, in future rulemaking. In reference to the USCDI, we note that health IT modules may be certified to only one or a few certification criteria that do not reference the USCDI standard, and therefore are not all required to support USCDI. With regard to workflows, there is no requirement under the MIPS Promoting Interoperability performance category or the Medicare Promoting Interoperability Program that a specific individual person must request prior authorization electronically via the Prior Authorization API to meet requirements of the Electronic Prior Authorization measure. Instead, it can be someone who legally can enter information into the medical record in accordance with applicable laws and professional guidelines. Regarding the measure’s specifications, we emphasize that data must come from the CEHRT, as use of CEHRT is a required element of both the MIPS Promoting Interoperability performance category and the Medicare Promoting Interoperability Program. However, additional data outside of CEHRT may also be used in addition to support the interaction with a Prior Authorization API. Regarding the USCDI, we note that this standard is referenced in many of the IGs recommended for these use cases, however, the relative utility, in the abstract, of USCDI as a standard adopted for use in certified health IT and cross referenced in certain ONC Health IT Certification Program criteria is outside the scope of this final rule. We also note that we did not propose and are not finalizing a requirement under the MIPS Promoting 165 Office of Information and Regulatory Affairs (2023, November). Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability. Retrieved from https://www.reginfo.gov/public/do/ eAgendaViewRule?pubId=202304&RIN=0955AA06. E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8922 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations Interoperability performance category or the Medicare Promoting Interoperability Program to share prior authorization information via the integrations with HINs to meet the Bi-Directional HIE measure. Additionally, we thank commenters for their recommendations on additional measures to promote electronic prior authorization. CMS reiterates that to meet the requirements of the Electronic Prior Authorization measure, the electronic prior authorization must use a Prior Authorization API as finalized in this rule. CMS agrees that using HIEs and other HINs could help to facilitate sharing of prior authorization information. Nothing in the Electronic Prior Authorization measures we are finalizing would restrict using such networks as long as the payer’s Prior Authorization API is used for the electronic prior authorization. Comment: A commenter sought clarification on whether a provider must implement capabilities to connect to all parts of the Prior Authorization API for full automation of the electronic prior authorization processing in order to claim numerator credit. Another commenter questioned whether a provider meets the numerator criteria if they use the Prior Authorization API that does not meet all the capabilities outlined in the recommended HL7 Da Vinci CRD, DTR, and PAS IGs. Another commenter requested clarification regarding whether a MIPS eligible clinician using the Prior Authorization API to submit a prior authorization request is not required to use all capabilities (that is, CRD, DTR, and PAS) in order to meet the numerator qualification, but rather that, at a minimum, the PAS IG request is used. Response: We thank the commenters for their feedback and note that we are finalizing this measure with modification to no longer require MIPS eligible clinicians, eligible hospitals, and CAHs to report a numerator and denominator for the measure. Instead, we are finalizing this measure to require MIPS eligible clinicians, eligible hospitals, and CAHs to attest a ‘‘yes’’ or ‘‘no’’ response for the measure or claim an applicable exclusion. In order to attest ‘‘yes,’’ for at least one medical item or service (excluding drugs) and, for eligible hospitals and CAHs, for one hospital discharge ordered during the performance period or EHR reporting period, a prior authorization request must be submitted to a payer using a Prior Authorization API. We note that to report a ‘‘yes,’’ the action of the measure must occur during the selected VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 performance period 166 or EHR reporting period,167 as per the measure specification. The Prior Authorization API is discussed in more detail in section II.D. of this final rule, and we note that the submission of the prior authorization request itself is described through the recommended PAS IG. Comment: Some commenters stated that certain EHR systems are more sophisticated than others and could track Prior Authorization API activity, while other hospitals and providers lack this technology. A commenter sought clarification on how a provider can use their EHR to identify situations where the prior authorization cannot be requested via a payer’s Prior Authorization API for the purposes of performance measurement. A commenter stated that some provider systems do not support one or more payer APIs due to slight differences in structure, interpretation, or both, which could result in the provider being penalized due to an EHR system’s lack of capability and not the provider’s lack of desire to use the Prior Authorization API. A commenter noted that the Electronic Prior Authorization measure would be counterproductive to ONC’s strategy of reducing burden related to using health IT and EHRs and that there should be near-zero reporting burden. Multiple commenters noted that there will be technical and financial challenges with adopting an electronic prior authorization process. Some commenters recommended that CMS should provide financial and technical assistance/training to providers to adopt and implement the technology requirements. The commenter noted that some provider types, such as physical therapists, are ineligible to participate in the Medicare and Medicaid EHR Incentive Programs and have received little guidance on using EHR systems. A commenter stated that CMS should acknowledge the significant financial and administrative risk providers face when purchasing EHR systems in the context of MIPS. A commenter noted that many health IT vendors currently charge separately for electronic prior authorization functionality and the cost associated with purchasing these functionalities has been a substantial barrier to adoption for many small and independent practices, as well as rural hospitals. Some commenters noted the financial burden associated with using APIs and that practices must first be able to affordably adopt this technology 166 See 167 See PO 00000 42 CFR 414.1320. 42 CFR 495.40(b)(2)(i). Frm 00166 Fmt 4701 Sfmt 4700 before a new requirement is established for its use. Response: We acknowledge there will be variability in EHR technology capabilities to track Prior Authorization API activity. As noted previously, for this reason and to reduce reporting burden, we are finalizing the Electronic Prior Authorization measure as an attestation (yes/no) measure. As noted, ONC has sought comment on how updates to the ONC Health IT Certification Program could support electronic prior authorization (87 FR 3475). We also note that the Unified Agenda, current at the time of publication of this final rule, has been updated to include an entry for a proposed rule from ONC (RIN 0955– AA06) that includes proposals for the expanded use of certified APIs for electronic prior authorization.168 We will monitor these developments in order to inform updates to the Electronic Prior Authorization measure in the future, for instance, requiring reporting of a numerator and denominator. While we acknowledge there may be costs associated with implementing functionality needed to interact with a payer’s Prior Authorization API, as well as add-on costs charged by health IT vendors for adding these features, we believe that the benefits of the technology outweigh the costs. We also remind readers that this attestation (yes/ no) measure would not be included under the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category until the CY 2027 performance period/2029 MIPS payment year and CY 2027 EHR reporting period. We believe extending the inclusion of the Electronic Prior Authorization measure to the CY 2027 performance period/ 2029 MIPS payment year for MIPS eligible clinicians and the CY 2027 EHR reporting period for eligible hospitals and CAHs will allow participants in these programs to work with health IT vendors to adopt and implement functionality that can facilitate the actions needed to satisfy the Electronic Prior Authorization measure. As far as technical assistance, CMS does host CMS and HL7 FHIR Connectathons, which are free for interested parties to attend, as well as provides educational webinars with overviews of the technical requirements 168 Office of Information and Regulatory Affairs (2023, November). Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability. Retrieved from https://www.reginfo.gov/public/do/ eAgendaViewRule?pubId=202304&RIN=0955AA06. E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations in the CMS Interoperability and Patient Access final rule and proposed requirements in the CMS Interoperability and Prior Authorization proposed rule. Additional public resources also exist through HL7, such as HL7 FHIR Connectathons, HL7 website resources, and HL7 FHIR workgroup meetings. CMS believes that using the EHR systems, and training for staff using them, is up to each practice or hospital system to ensure occurs. CMS also is aware that the initial incentive programs (that is, the Medicare and Medicaid EHR Incentive Programs) supported EHR adoption for only certain provider types and the challenges that brings for certain provider types that were not originally eligible for this funding. CMS continues to evaluate ways to support providers that may lag in health IT adoption. Comment: A commenter requested that CMS establish requirements for impacted payers to publish their API endpoints for the Prior Authorization API or provide information on where to find the APIs and make information concerning how to connect to them conspicuously available for third-party app developers and for providers through their public websites similar to what is asked of certified health IT developers of API functions as a part of their basis of CEHRT under 45 CFR 170.315(g)(10). Response: We understand that a directory of impacted payers’ digital endpoints would be highly beneficial to facilitate the Prior Authorization API. Without such a directory, payers would need to discover other payers’ endpoints one by one, and each payer would have to maintain a list of payers with whom they have previously connected. Therefore, we are committing to exploring an NDH that contains payers’ digital endpoints before the 2027 compliance dates for the Prior Authorization API, which could allow providers to easily access those APIs and thereby facilitate electronic prior authorization, as discussed in this final rule. Further details about the NDH structure, requirements, and timing will be released if and when they become available. Comment: A commenter discussed the X12 standards and expressed that they do not believe that the inclusion of the Electronic Prior Authorization measure would be a sufficient incentive for MIPS eligible clinicians, eligible hospitals, and CAHs to overcome the costs associated with the transaction. Multiple commenters recommended that CMS should include the usage of the X12 278 standard in the numerator of the proposed measures. A commenter VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 noted organizations that have standardized usage of the X12 standard may find this effective and efficient. The commenter stated that requiring these groups to transition to the Prior Authorization API to meet the measure requirements would be disruptive and burdensome. Another commenter recommended CMS use a single standard if CMS would like to incorporate the Electronic Prior Authorization measure. A commenter also recommended that CMS provide guidance on the role of HIPAA administrative transaction standards. Response: We thank the commenters for their feedback; however, we do not agree that the X12 278 standard is appropriate for the numerator of the proposed Electronic Prior Authorization measure because of its persistent and historically low utilization. While the CAQH efficiency index report is more reflective of payer and vendor uptake of the HIPAA standards, it does include some provider information.169 In the last four reporting years, the utilization of the X12 278 transaction has not exceeded 21 percent. Comments from reporting submitters (for the CAQH Index) indicate that providers do not use the X12 278 because it does not include the data elements they need for complete processing, and many payers are still not supporting it. Thus, to consider using that standard as the numerator, knowing the utilization rates are low, would not seem appropriate. We believe the benefit of moving towards a standardized electronic prior authorization process that leverages FHIR outweighs the initial implementation cost and burden of the transition. We will continue coordinating with colleagues across CMS and other Federal agencies on all ways that that HIPAA administrative transaction standards could impact our policies. We also note that we are finalizing a modification to our proposal to no longer require reporting of a numerator and denominator for this measure, as discussed in more detail throughout this section. c. Measure Exclusions In the proposed rule (87 FR 76314), we proposed that MIPS eligible clinicians, eligible hospitals, or CAHs that do not order any medical items or services (excluding drugs) requiring prior authorization during the applicable performance period or EHR reporting period could claim an 169 Coalition for Affordable Quality Healthcare (2022). The CAQH Index Report. Retrieved from https://https://www.caqh.org/insights/caqh-indexreport. PO 00000 Frm 00167 Fmt 4701 Sfmt 4700 8923 exclusion for the Electronic Prior Authorization measure. We also proposed that MIPS eligible clinicians, eligible hospitals, or CAHs that only order medical items or services (excluding drugs) requiring prior authorization from a payer that does not offer an API that meets the Prior Authorization API requirements outlined in section II.D.2. of this final rule (that is, payers not subject to this regulation or impacted payers that are non-compliant with the Prior Authorization API requirements outlined in section II.D.2. of this final rule), during the applicable performance period/MIPS payment year or EHR reporting period, could claim an exclusion for the Electronic Prior Authorization measure. As an alternative to this proposal, we considered whether MIPS eligible clinicians, eligible hospitals, and CAHs that request a small number of prior authorizations, such as five prior authorizations during the performance period/EHR reporting period, should also be able to claim the exclusion. We sought public comment on the alternative we considered and whether another minimum number of prior authorization requests would be appropriate for the exclusion. Given the previously discussed limitations of the current prior authorization process, we believe that all MIPS eligible clinicians, eligible hospitals, and CAHs (as well as their patients and the payers they request prior authorization from) would benefit from using the electronic process described here, regardless of how often they request prior authorization. Therefore, we believe that no minimum number of prior authorization requests, other than zero, would be a reasonable threshold for claiming an exclusion for the Electronic Prior Authorization measure. Comment: A few commenters stated that if a payer insists on faxing or other means of communication, CMS should consider treating this scenario as the basis for exclusion from the Electronic Prior Authorization measure versus still having authorizations impacted by such a requirement of a payer included in the denominator. A commenter stated that some practitioners do not have enough prior authorization requests or the necessary technology to support electronic prior authorization, and suggested the exclusion should be based on not only quantity but also on technical capability of those who do not submit a high volume of prior authorization requests. The commenter encouraged CMS to consider alternative exclusion criteria, such as the technical E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8924 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations capability of those who do not submit a high volume of prior authorization requests. The commenter continued by stating that CMS should not penalize providers for failing to use EHRs for this purpose of electronic prior authorization if they either do not have enough requests or if the technology they use does not support this capability. Response: We appreciate commenters’ recommendations and feedback that some providers may not have enough prior authorization requests or the necessary technology to support electronic prior authorization. We believe that all MIPS eligible clinicians, eligible hospitals, and CAHs (as well as their patients and the impacted payers they request prior authorization from) would benefit from using the electronic prior authorization process described in this final rule. We also note that the modified version of the Electronic Prior Authorization measure being finalized in this rule only requires reporting of ‘‘at least one’’ medical item or service (excluding drugs) ordered during the performance period/MIPS payment year or EHR reporting period. We believe this is achievable for all MIPS eligible clinicians, eligible hospitals, and CAHs who make any prior authorization requests in a given year. For those who do not have any prior authorization requests, we are finalizing our exclusion as proposed. MIPS eligible clinicians, eligible hospitals, and CAHs who do not order any medical items or services (excluding drugs) requiring prior authorization during the applicable performance period/MIPS payment year or EHR reporting period would be able to report that they qualify for the exclusion for the Electronic Prior Authorization measure. We acknowledge that EHR technology may not consistently support interactions with the Prior Authorization APIs at this time, and as discussed in further detail elsewhere in this section, we will continue to work with ONC on potential ONC Health IT Certification Program criteria that would support the Electronic Prior Authorization measure. For this reason, we are finalizing this measure for the MIPS Promoting Interoperability performance category beginning with the CY 2027 performance period/2029 MIPS payment year and for the Medicare Promoting Interoperability Program beginning with the CY 2027 EHR reporting period. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 d. Office of the National Coordinator for Health Information Technology Health IT Certification Program As described previously, ONC previously sought comment through an RFI titled ‘‘Electronic Prior Authorization Standards, Implementation Specifications, and Certification Criteria’’ (87 FR 3475), which appeared in the January 24, 2022, issue of the Federal Register, on how updates to the ONC Health IT Certification Program could support electronic prior authorization. Since then, the Unified Agenda has been updated to include a proposed rule from ONC (RIN 0955–AA06) that aims to advance interoperability through proposals for the expanded use of certified APIs for electronic prior authorization, among other proposals.170 We plan to continue to explore how potential updates to the ONC Health IT Certification Program could support our policies and will address any updates to our requirements related to future updates to the ONC Health IT Certification Program, if finalized, in future rulemaking. e. Other Considerations We invited public comment on considerations and alternatives related to the Electronic Prior Authorization measure. For example, we sought comment on the proposed numerator and denominator of the Electronic Prior Authorization measure or any changes to the specifications that would reduce the implementation burden for both impacted providers (MIPS eligible clinicians, eligible hospitals, and CAHs) and health IT developers. We also sought comment on challenges that MIPS eligible clinicians, eligible hospitals, and CAHs might face in identifying those payers that have the Prior Authorization API technology to accurately include eligible prior authorization requests in the denominator. Additionally, we sought comment on challenges MIPS eligible clinicians, eligible hospitals, and CAHs could face in performing the actions included in the Electronic Prior Authorization measure specifications if certification criteria are not available in the ONC Health IT Certification Program at the time MIPS eligible clinicians, eligible hospitals, and CAHs are required to report the Electronic Prior Authorization measure under the 170 Office of Information and Regulatory Affairs (2023, November). Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability. Retrieved from https://www.reginfo.gov/public/do/ eAgendaViewRule?pubId=202304&RIN=0955AA06. PO 00000 Frm 00168 Fmt 4701 Sfmt 4700 Medicare Promoting Interoperability Program or MIPS Promoting Interoperability performance category. We received many comments in response to our request for comment. We thank commenters for their feedback as we consider any future rulemaking, including collaboration with ONC as appropriate. Comment: Multiple commenters opposed the proposed Electronic Prior Authorization measure because of the lack of health IT certification criteria to ensure EHRs communicate with payers through Prior Authorization API. Multiple commenters expressed concern about the inclusion of the Electronic Prior Authorization measure due to possible technical challenges and the lack of health IT that has the capacity to support electronic prior authorization. Multiple commenters encouraged CMS to focus on ensuring that the proposed APIs are implemented and supported by CEHRT to make sure they are successfully implemented within the provider’s workflow rather than developing a measure related to electronic prior authorization. Several commenters noted that ONC has not established health IT certification criteria to support electronic prior authorization in such technologies. Multiple commenters suggested various alternative timeframes for CMS to consider. A commenter recommended that CMS require payers to make the Prior Authorization API available to providers no later than 12 months following the publication of this final rule. Another commenter suggested a compliance date 12 months after the implementation of the Prior Authorization API or 36 months following publication of this final rule, whichever is later. Another commenter requested that CMS consider reopening the comment period for this rule following the publication of the HTI–1 proposed rule (88 FR 23746). The commenter stated that CMS should give industry 24 months from the reopening of the comment period to create specifications, perform development, complete certification testing, and execute client deployments. Another commenter recommended that CMS suspend the proposed Electronic Prior Authorization measure until payers implement and maintain the Prior Authorization API as specified in this rule and the Prior Authorization API is in effect for at least 3 years. Multiple commenters were concerned that providers will not be guaranteed access to the Prior Authorization API if health IT developers are not required to incorporate the functionality into CEHRT and therefore should not be held E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations accountable for using the Prior Authorization API nor reporting on the proposed Electronic Prior Authorization measure. A commenter recommended that CMS and ONC work in collaboration to leverage technologies, such as electronic prior authorization tools. Another commenter urged CMS to work with ONC to establish ONC Health IT Certification Program criteria to require providers and EHR vendors to adopt the IGs associated with electronic prior authorization. Commenters stated that it is unreasonable to measure utilization by MIPS eligible clinicians, eligible hospitals, and CAHs of electronic prior authorization processes for incentive payments until the ONC Health IT Certification Program requires CEHRT to include the functionality necessary for health IT systems to communicate through a Prior Authorization API. Another commenter stated that CMS should postpone implementation of the Electronic Prior Authorization measure until both the ONC Health IT Certification Program and HIPAA attachment standards are updated. Another commenter stated that the proposed Electronic Prior Authorization measure would subject MIPS eligible clinicians, eligible hospitals, and CAHs to be reliant upon untested technology and tie their performance to such technology. A commenter emphasized the importance of industry adoption and noted that the API will have minimal value if EHR vendors do not build the necessary connections to allow clinicians to access it and if clinicians are not incentivized to adopt. To mitigate this, the commenter recommended that CMS require EHR vendors to provide bidirectional patient data access via an API so payers can better leverage digital patient information and automate prior authorization requests. Another commenter recommended that CMS ensure that the proposed Electronic Prior Authorization measure is supported by technology used by all of the impacted users. Several commenters stated that providers should not be subject to punitive action if they do not implement the Prior Authorization API requirements and should not be evaluated on electronic prior authorization utilization for payment purposes until EHRs are required to provide this functionality by the ONC Health IT Certification Program. Response: We appreciate the comments received on this request for comments. As noted, the Unified Agenda, current at the time of publication of this final rule, includes an entry for a proposed rule from ONC VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 (RIN 0955–AA06) that aims to advance interoperability through proposals for the expanded use of certified APIs for electronic prior authorization.171 We will work with ONC to ensure that any future updates to the ONC Health IT Certification Program around electronic prior authorization will improve health care providers’ capabilities to interact with the Prior Authorization APIs established by impacted payers, as well as further support health care providers’ ability to complete the action specified in the Electronic Prior Authorization measure we are finalizing. We will provide further guidance in future rulemaking about how any updates made by ONC to the ONC Health IT Certification program related to electronic prior authorization relate to the requirements of the Medicare Promoting Interoperability Program and Promoting Interoperability performance category of MIPS. We note that CMS does not have authority to regulate EHR vendors directly; however, we collaborate with ONC regarding certification criteria for health IT that are included in the voluntary ONC Health IT Certification Program and referenced in CMS program requirements. In the interim, we note that MIPS eligible clinicians, eligible hospitals, and CAHs are required to use CEHRT for the measure as a means to capture clinical information as structured data and to use such structured data for the prior authorization. This function of gathering structured data from CEHRTs is achievable today without additional CEHRT criteria. The request for prior authorization through the Prior Authorization API could be accomplished through the use of additional technology to complement CEHRT depending on implementation preference. We note that MIPS eligible clinicians, eligible hospitals, and CAHs can report on the measure, saying ‘‘yes’’ they submitted a prior authorization request electronically using the Prior Authorization API with data from CEHRT, without needing additional certification criterion in the ONC Health IT Certification Program. We also note that in December 2022, HHS proposed to adopt a standard for attachments in the HIPAA Standards for Health Care Attachments proposed rule (87 FR 78438). That proposed rule has not yet been finalized. At this time there 171 Office of Information and Regulatory Affairs (2023, November). Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability. Retrieved from https://www.reginfo.gov/public/do/ eAgendaViewRule?pubId=202304&RIN=0955AA06. PO 00000 Frm 00169 Fmt 4701 Sfmt 4700 8925 are no operating rule requirements applicable to the APIs required for use in this final rule, or to the HIPAA X12 278 transaction standard. We appreciate commenters’ recommendations regarding implementation timelines, such as making the Prior Authorization API available to providers no later than 12 months or 36 months following the publication of this final rule. We note that, after consideration of comments received and discussed in more detail elsewhere in the rule, we are finalizing our proposal with the modification to have MIPS eligible clinicians report the Electronic Prior Authorization measure beginning with the CY 2027 performance period/2029 MIPS payment year and eligible hospitals and CAHs report the Electronic Prior Authorization measure beginning with the CY 2027 EHR reporting period. We also acknowledge that a commenter recommended suspending the Electronic Prior Authorization measure until payers implement the Prior Authorization API as specified in this rule and use it for some time period. However, we believe finalization of this Electronic Prior Authorization measure encourages all parties involved (payers and providers) to develop, implement, and use the new Prior Authorization API to drive widespread adoption, thus reaping the benefits of burden reduction through electronic prior authorization processes. The Prior Authorization API needs parties on both ends of a request to be using the API in order for the API to be beneficial to everyone involved. Comment: Multiple commenters recommended that ONC conduct oversight of CEHRT products to determine if the products do or do not successfully support electronic prior authorization, and then publicize CEHRT products that fail ONC review on the Certified Health IT Product List (CHPL) so providers can avoid products that will not support the new electronic prior authorization requirements. The commenter recommended that ONC work with professional associations to educate providers about their oversight and reporting process. Response: There is not a dedicated certification criterion related to electronic prior authorization in the ONC Health IT Certification Program at this time. However, as noted previously, ONC previously sought comment on how updates to the ONC Health IT Certification Program could support electronic prior authorization (87 FR 3475). We also note that the Unified Agenda, current at the time of publication of this final rule, includes an entry for a proposed rule from ONC E:\FR\FM\08FER2.SGM 08FER2 8926 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations (RIN 0955–AA06), which describes planned proposals for the expanded use of certified APIs for electronic prior authorization.172 We note that the Electronic Prior Authorization measure requires using data from CEHRT, and the Prior Authorization API can be implemented without regard to any changes ONC may propose for the ONC Health IT Certification Program. While ONC oversight and enforcement authority is beyond the scope of this final rule, we note that health IT products certified to all certification criteria are subject to oversight mechanisms within the ONC Health IT Certification Program. For more information about the oversight elements within the ONC Health IT Certification Program, readers should visit the ONC website at https:// www.healthit.gov/topic/certificationehrs/oversight-and-surveillance. Regarding the CHPL (https:// chpl.healthit.gov/), we note this resource includes listings of those health IT products that have successfully certified to health IT certification criteria under the Certification Program. Comment: Multiple commenters recommended that CMS and ONC outline a roadmap for electronic prior authorization adoption that leverages the ONC Health IT Certification Program. A commenter recommended that the roadmap should include details from the ONC Cures Act final rule (85 FR 25642) and these requirements. Another commenter stated that an established path to electronic prior authorization will avoid delays and confusion. Response: We appreciate commenters’ feedback. CMS will consider developing a roadmap for electronic prior authorization adoption in collaboration with ONC. We will collaborate with ONC to incorporate any future policies for the ONC Health IT Certification Program as part of a comprehensive approach to ensuring electronic prior authorization is conducted in a standardized fashion across parties. lotter on DSK11XQN23PROD with RULES2 3. Final Action After consideration of the comments received and for the reasons discussed in the CMS Interoperability and Prior Authorization proposed rule and our response to those comments (as summarized previously), we are 172 Office of Information and Regulatory Affairs (2023, November). Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability. Retrieved from https://www.reginfo.gov/public/do/ eAgendaViewRule?pubId=202304&RIN=0955AA06. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 finalizing our proposal with the following modifications: • The ‘‘Electronic Prior Authorization’’ measure will be reported as an attestation (yes/no) measure, instead of reporting a numerator and denominator, regarding whether the MIPS eligible clinician, eligible hospital, or CAH submitted at least one prior authorization request electronically via a Prior Authorization API using data from CEHRT during the performance period/EHR reporting period, as further specified below. • MIPS eligible clinicians will report the ‘‘Electronic Prior Authorization’’ measure for the MIPS Promoting Interoperability performance category beginning with the CY 2027 performance period/2029 MIPS payment year and eligible hospitals and CAHs participating under the Medicare Promoting Interoperability Program will report the measure beginning with the CY 2027 EHR reporting period. See further discussion below for exact details of the final requirements for MIPS eligible clinicians, eligible hospitals, and CAHs. We are finalizing the following specifications for the Electronic Prior Authorization measures: 1. For MIPS Eligible Clinicians Under the MIPS Promoting Interoperability Performance Category—Electronic Prior Authorization • Measure Description: For at least one medical item or service (excluding drugs) ordered by the MIPS eligible clinician during the performance period, the prior authorization is requested electronically via a Prior Authorization API using data from CEHRT. • Reporting Requirements: Yes/No response. To successfully report this measure, MIPS eligible clinicians must attest ‘‘yes’’ to requesting prior authorization electronically via a Prior Authorization API using data from CEHRT for at least one medical item or service (excluding drugs) ordered by the MIPS eligible clinician during the performance period or (if applicable) report an exclusion. • Exclusion: Any MIPS eligible clinician who— ++ Does not order any medical items or services (excluding drugs) requiring prior authorization during the applicable performance period; or ++ Only orders medical items or services (excluding drugs) requiring prior authorization from a payer that does not offer an API that meets the Prior Authorization API requirements outlined in section II.D.2. of this final PO 00000 Frm 00170 Fmt 4701 Sfmt 4700 rule during the applicable performance period. 2. For Eligible Hospitals and Critical Access Hospitals Under the Medicare Promoting Interoperability Program— Electronic Prior Authorization • Measure Description: For at least one hospital discharge and medical item or service (excluding drugs) ordered during the EHR reporting period, the prior authorization is requested electronically via a Prior Authorization API using data from CEHRT. • Reporting Requirements: Yes/No response. To meet this measure, the eligible hospital or CAH must attest ‘‘yes’’ to requesting a prior authorization electronically via a Prior Authorization API using data from CEHRT for at least one hospital discharge and medical item or service (excluding drugs) ordered during the EHR reporting period or (if applicable) report an applicable exclusion. • Exclusions: Any eligible hospital or CAH that— ++ Does not order any medical items or services (excluding drugs) requiring prior authorization during the EHR reporting period. ++ Only orders medical items or services (excluding drugs) requiring prior authorization from a payer that does not offer an API that meets the Prior Authorization API requirements outlined in section II.D.2. of this final rule during the applicable EHR reporting period. We intend to reevaluate the Electronic Prior Authorization measure criteria and reporting structure of this measure in future years as the Prior Authorization API becomes more widely adopted and if additional certification criteria become available for CEHRT to determine whether a numerator/ denominator reporting structure would be more appropriate at that time. We would address those issues in future rulemaking. We are finalizing our proposal that the Electronic Prior Authorization measure will not be assigned points for the CY 2027 performance period/2029 MIPS payment year for MIPS eligible clinicians, and the CY 2027 EHR reporting period for eligible hospitals and CAHs. Instead, if a MIPS eligible clinician, eligible hospital, or CAH fails to report the measure as specified, they would not meet the minimum reporting requirements, not be considered a meaningful EHR user, and fail the Medicare Promoting Interoperability Program or the MIPS Promoting Interoperability performance category. A failure to meet the minimum reporting E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations requirements of the Medicare Promoting Interoperability Program would result in a downward payment adjustment for eligible hospitals or CAHs (unless the eligible hospital or CAH receives a hardship exception). A failure in the Promoting Interoperability performance category would result in the MIPS eligible clinician receiving a score of zero for the performance category, which is currently worth 25 percent of their final score for MIPS. For the MIPS Promoting Interoperability performance category, satisfactory performance on this measure can be demonstrated only by reporting a ‘‘yes’’ response on the attestation or claiming an applicable exclusion. A ‘‘no’’ response on the attestation will result in the MIPS eligible clinician failing to meet the minimum reporting requirements, therefore not being considered a meaningful EHR user for MIPS, as set forth in section 1848(o)(2)(A) of the Act and defined at 42 CFR 414.1305, for the MIPS payment year (42 CFR 414.1305). MIPS eligible clinicians that do not report a ‘‘yes’’ response or claim an applicable exclusion for the Electronic Prior Authorization measure as specified (that is, they do not submit the measure or claim an exclusion or report a ‘‘no’’ response) will not earn a score for the MIPS Promoting Interoperability performance category (a score of zero for the category). A MIPS eligible clinician’s score in the Promoting Interoperability performance category is generally worth 25 percent of their total final score for MIPS (42 CFR 414.1375(a); 414.1380(c)(1)). We note that to report a ‘‘yes,’’ the action of the measure must occur during the selected performance period 173 or EHR reporting period,174 as per the measure specification defined below. For the Medicare Promoting Interoperability Program, only a ‘‘yes’’ response on the attestation, or claiming an applicable exclusion, will fulfill the minimum requirements of this measure. A ‘‘no’’ response will result in the eligible hospital or CAH failing to meet the measure, and therefore failing to meet minimum program reporting requirements, thus not being considered a meaningful EHR user for an EHR reporting period, as defined in section 1886(n)(3) of the Act.175 Eligible hospitals and CAHs that do not meet the minimum program requirements are subject to a downward payment 173 See 42 CFR 414.1320. 42 CFR 495.40(b)(2)(i). 175 See 42 CFR 495.4 and 495.24(f)(1)(i)(A). 174 See VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 adjustment (unless the eligible hospital or CAH receives a hardship exception). G. Interoperability Standards for APIs 1. Background In the CMS Interoperability and Patient Access final rule (85 FR 25510), we finalized a requirement to implement, maintain, and use API technology conformant with the API technical standards at 45 CFR 170.215, which at the time included (85 FR 25521): • Health Level Seven (HL7®) Fast Healthcare Interoperability Resources (FHIR®) Release 4.0.1 • HL7® FHIR® US Core Implementation Guide (IG) Standard for Trial Use (STU) 3.1.1 • HL7® SMART Application Launch Framework IG Release 1.0.0, including mandatory support for the ‘‘SMART Core Capabilities’’ • FHIR® Bulk Data Access (Flat FHIR) IG (v1.0.0: STU 1), including mandatory support for the ‘‘group-export’’ ‘‘OperationDefinition’’ • OpenID Connect Core 1.0, incorporating errata set 1 When we finalized the requirement for conformance with the specifications at 45 CFR 170.215 in the CMS Interoperability and Patient Access final rule, we required impacted payers to comply with all standards at 45 CFR 170.215 for each of the APIs finalized in that rule. However, we understand that the existing requirements for payers to ‘‘use API technology conformant with 45 CFR 170.215’’ (85 CFR 25632) for each API may introduce confusion to the compliance requirements, because not all the standards at 45 CFR 170.215 may be applicable for each specific API.176 Accordingly, to provide clarity, in the CMS Interoperability and Prior Authorization proposed rule, we outlined modifications to be more specific regarding which standards at 45 CFR 170.215 are applicable to each API (87 FR 76314–21). Specifically, instead of the existing requirements to use ‘‘API technology conformant with 45 CFR 170.215,’’ we proposed that each standard at 45 CFR 170.215 would apply to a given set of APIs. The specific CFR citations were listed in Table 8 of the proposed rule (87 FR 76318). We are now finalizing those requirements, with modifications to some of the specific API requirements. We are finalizing that 176 See 42 CFR 422.119 (Access to and exchange of health data and plan information), 431.60 (Beneficiary access to and exchange of data), and 457.730 (Beneficiary access to exchange of data) and 45 CFR 156.221 (Access to and exchange of health data and plan information). PO 00000 Frm 00171 Fmt 4701 Sfmt 4700 8927 impacted payers will only be required to use those specifications at 45 CFR 170.215 that are listed in Table H3 as necessary for the Patient Access, Provider Access, Provider Directory, Payer-to-Payer, and Prior Authorization APIs. We are also finalizing our proposal to allow impacted payers to use updated standards, specifications, or IGs for each of these APIs. Finally, we are reiterating our recommendations to use the IGs listed in Table H3. We discuss these policies in detail elsewhere in the final rule. 2. Modifications to Required Standards for APIs We proposed specific standards at 45 CFR 170.215 that would apply to each API. In the proposed rule, we listed the standards applicable to each API in Table 10 (87 FR 76320). Since the publication of the CMS Interoperability and Prior Authorization proposed rule, ONC has published the HTI–1 final rule which reorganized the structure of 45 CFR 170.215 to delineate the purpose and scope more clearly for each type of standard or implementation specification (89 FR 1283). We note that the HTI–1 final rule adopted updated versions of several standards at 45 CFR 170.215, which now includes: • Health Level Seven (HL7) Fast Healthcare Interoperability Resources (FHIR) Release 4.0.1 at 45 CFR 170.215(a)(1) (HL7 FHIR); • HL7 FHIR US Core IG Standard for Trial Use (STU) 3.1.1, which expires on January 1, 2026, at 45 CFR 170.215(b)(1)(i); • HL7 FHIR US Core IG STU 6.1.0 at 45 CFR 170.215(b)(1)(ii) (US Core IG), • HL7 SMART Application Launch Framework IG Release 1.0.0, which expires on January 1, 2026, at 45 CFR 170.215(c)(1); • HL7 SMART App Launch IG Release 2.0.0 at 45 CFR 170.215(c)(2) (SMART App Launch IG); • FHIR Bulk Data Access (Flat FHIR) IG (v1.0.0: STU 1) at 45 CFR 170.215(d)(1) (Bulk Data Access IG); and • OpenID Connect Core 1.0, incorporating errata set 1 at 45 CFR 170.215(e)(1) (OpenID Connect Core). We refer readers to the HTI–1 proposed and final rule for additional information (FR 1284 through 1295). The specific standards at 45 CFR 170.215 that we identified in our proposed rule were restructured by HTI–1 and moved to new locations at 45 CFR 170.215. In addition, in several cases ONC adopted new versions of the same standards proposed in the CMS Interoperability and Prior Authorization proposed rule. Specifically, ONC finalized US Core IG STU 6.1.0 (at 45 E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8928 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations CFR 170.215(b)(1)(ii)) and the SMART App Launch IG Release 2.0.0 (at 45 CFR 170.215(c)(2)). Additionally, ONC has finalized expiration dates for the US Core IG STU 3.1.1 (at 45 CFR 170.215(b)(1)(i)) and the SMART App Launch Framework IG Release 1.0.0 (at 45 CFR 170.215(c)(1)) to indicate when a version of a standard may no longer be used for the ONC Health IT Certification Program. While we did not propose to require those updated versions, we emphasize that impacted payers are permitted to use them based on our policy to allow updated versions of required standards, as discussed. We intend to align with the updated versions finalized at 45 CFR 170.215 through future rulemaking prior to our API compliance dates. We are finalizing our proposals to identify specific required standards at 45 CFR 170.215 that are applicable to each of the APIs, with modifications. The finalized requirements include any additional mandatory support requirements listed, such as for both the SMART App Launch IG at 45 CFR 170.215(c) and Bulk Data Access IG at 45 CFR 170.215(d). We are crossreferencing the new locations for these standards at 45 CFR 170.215 finalized by ONC in the HTI–1 final rule. Table H3 lists the required versions of each standard and their citation. Throughout this preamble we refer to the current structure of 45 CFR 170.215 as updated by the HTI–1 final rule. For the Patient Access API, we are finalizing the required standards as proposed with modifications to incorporate the expiration dates ONC adopted at 45 CFR 170.215(b)(1)(i) and (c)(1). For the Provider Directory API, we are finalizing our proposal with modifications to incorporate the expiration date ONC adopted at 45 CFR 170.215(b)(1)(i), and to remove the SMART App Launch IG at 45 CFR 170.215(c)(1) and OpenID Connect Core at 45 CFR 170.215(e), which were erroneously included in the proposed rule. We refer readers to the footnote in Table H3 for additional information. For the Provider Access API, we are finalizing our proposal with the modification to not require OpenID Connect Core at 45 CFR 170.215(e) and with modifications to incorporate the expiration dates ONC adopted at 45 CFR 170.215(b)(1)(i) and (c)(1). For the Payer-to-Payer API, we are finalizing our proposal with modifications to not require the SMART App Launch IG at 45 CFR 170.215(c) and OpenID Connect Core at 45 CFR 170.215(e), and to incorporate the expiration date ONC adopted at 45 CFR 170.215(b)(1)(i). For the Prior Authorization API, we are VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 finalizing our proposal with modifications to not require OpenID Connect Core at 45 CFR 170.215(e) and to incorporate expiration dates ONC adopted at 45 CFR 170.215(b)(1)(i) and (c)(1). Payers will be required to comply with the applicable specifications that we have identified for the Patient Access, Provider Access, Provider Directory, Payer-to-Payer, and Prior Authorization APIs as listed in Table H3. The exact regulation text for each API will vary depending on which standards apply to that API. These updates particularize the specifications at 45 CFR 170.215 that are required for each API. We received comments on these proposals and discuss details of the modifications. a. HL7 FHIR and Technical Readiness Comment: Multiple commenters expressed support for CMS’s proposal to specify technical standards for each API and recommended that CMS finalize the proposal. A commenter expressed appreciation for CMS’s efforts to explain the technical requirements for each API and agreed with the proposal to add more specific language regarding which standards apply to which API. Multiple commenters also supported CMS’s proposal to require payers to use the FHIR standard to facilitate information exchange and promote interoperability. Multiple commenters stated that FHIR APIs help connect patients, providers, and payers to the correct information. A commenter stated that FHIR-based standards maximize the chance for innovation and the proposed revision provides technical clarity to payers. Another commenter stated that utilizing the FHIR standard continues to advance the use of transparent, widely available standards and helps to facilitate electronic information exchange, while another stated that the FHIR-based IGs support the provider team’s workflow and enable them to better understand patient-specific benefits. Response: We appreciate commenters support for using the FHIR standard and FHIR APIs to improve information exchange and agree with the commenters’ assessments that these will advance interoperability. Comment: Multiple commenters expressed concern about mandating the FHIR standard. Multiple commenters expressed concern regarding the maturity of the proposed standards, specifications, and recommended IGs. Multiple commenters stated that it would be inadvisable to specify technical requirements at this time given that the technical standards and IGs have not fully matured. Multiple PO 00000 Frm 00172 Fmt 4701 Sfmt 4700 commenters recommended that CMS, along with ONC, take steps to adequately and inclusively develop technical standards and relevant IGs to full maturity as a baseline of industry consistency, ensuring standards are tested and transparently evaluated prior to mandated adoption. Another commenter encouraged CMS to maintain flexibility in the agency’s ongoing data exchange activities to ensure the success of interoperability programs. Another commenter urged CMS to ensure careful consideration of what technical standards to require in the future. Another commenter suggested that requiring all entities to use the FHIR standard may be burdensome. The commenter stated that CMS has not proposed any alternatives and that adoption of the FHIR standard may not be feasible for small entities and asked questions such as what will happen if small businesses are not able to convert to FHIR. A commenter cautioned CMS not to view the FHIR standard as the sole solution to interoperability and patient data exchange challenges. The commenter noted that as currently proposed, the Patient Access API would experience challenges if the FHIR standard failed to reach widespread adoption and maturity. A commenter stated that the HL7 Da Vinci IGs that support the Patient Access API have not yet reached sufficient maturity for widespread adoption. The commenter stated that using the FHIR standard, agnostic of a particular IG, will give industry stakeholders greater flexibility to pilot different approaches and build consensus without the risk of distortions that could result from mandatory adoption of immature specifications. Response: We thank commenters for providing their thoughts regarding the FHIR standard. However, we disagree that FHIR is not mature. The primary components of the FHIR standard are mature, as are the standards we are requiring in this rule, such as the US Core IG. We acknowledge that the FHIR resource profiles included in the IGs we recommend are of varying levels of maturity, but we believe they are sufficiently mature for industry to start implementing them. We refer readers to our discussion on IG maturity in section II.G.3.b. of this final rule. The FHIR standard will help move the health care industry toward a more interoperable state, and we believe that it supports transmission of health data in a standard, structured, but flexible format as FHIR specifications continue to advance and mature. HHS has already adopted standards for FHIR APIs at 45 E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations CFR 170.215, as finalized in the ONC Cures Act final rule, and therefore we did not propose any alternatives (85 FR 25521). We disagree that the HL7 Da Vinci IGs that support the Patient Access API have not yet reached sufficient maturity for widespread adoption as they have already been successfully implemented and are being used today. Since 2021 impacted payers have been required to implement and maintain a standards-based Patient Access API that uses FHIR and other technical standards at 45 CFR 170.215, as finalized in the CMS Interoperability and Patient Access final rule (85 FR 25558). We are delaying the compliance date for policies that require API enhancement or development to 2027, which will allow additional time for the recommended FHIR IGs to be refined to support the policies in this final rule. We believe the adoption of the FHIR standard is feasible for all the APIs finalized in this rule, especially with the additional implementation time. Comment: Multiple commenters appreciated CMS’s efforts to move industry towards interoperability and expressed support for CMS’s proposals to promote electronic data exchange among patients, providers, and payers via APIs leveraging technical standards and IGs. Multiple commenters supported using FHIR-based standards to facilitate data transport across the industry and that FHIR-based exchange is technically feasible for both payers and providers to adopt and implement. A commenter stated that the FHIR standard and IGs promote a level of consistency in terms of format, structure, and vocabulary, as well as allow for a variety of interoperability paradigms that best suit the interaction requirements between providers, payers, and patients. A commenter supported using USCDI data classes and data elements in addition to claims and encounter data when exchanging patient information. Multiple commenters expressed support for CMS’s proposals to use standards-based APIs and stated that the industry-wide adoption of uniform standards will help enhance interoperability and minimize complexity. Multiple commenters stated that having an established technical infrastructure to support the development and adoption of the new APIs outlined in this rule is crucial to prevent added administration burden, complexity, and variability in implementation. Response: We agree with the commenters’ assessments and thank them for their support of our policies. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 Comment: A commenter requested that CMS define a more prescriptive designated data set for claims and encounter data akin to USCDI. The commenter continued by stating that CMS should explicitly call out the Common Payer Consumer Data Set (CPCDS), which would ensure a more uniform implementation and ensure that patients, providers, and payers can use those capabilities in a way that the rule intended. Another commenter suggested a realignment of the purpose and use of USCDI as a library of data types, classes, and specifications from which interoperability requirements can be drawn. Response: While altering the design and structure of the USCDI are out of scope for this rule, we will continue to work with ONC to expand and build upon the USCDI. For instance, we have worked with ONC on the USCDI+ initiative, which aims to harmonize data sets that extend beyond the USCDI for additional use cases. While USCDI is one category of data required to be exchanged via the APIs, we understand that the USCDI is limited in scope and that additional data and standards will be necessary to implement these APIs. For instance, the recommended HL7® FHIR® CARIN Consumer Directed Payer Data Exchange IG (CARIN IG for Blue Button) (87 FR 76316), which was itself informed by and includes mappings to CPCDS. Comment: A commenter noted that the implementation of the APIs is contingent on compliant technical solutions being available in the marketplace. Another commenter stated that the lack of specificity in API requirements gives payers significant latitude to determine what data elements they want to include in their APIs and under what circumstances, which will not promote widespread interoperability. Another commenter stated that technical standardization and payer participation are the only ways that these proposals could be effective. The commenter stated if the responsibility is not shared across stakeholders, CMS will simply shift more burden onto providers. Another commenter stated that variance in API implementation could require providers to need significant assistance from health IT vendors to navigate these systems, which would eliminate any efficiencies CMS expected to derive from the new interoperability requirements. Another commenter noted a frequent problem with the implementation of technical processes is variation from system-to-system and interpretation differences since guidance is not universally PO 00000 Frm 00173 Fmt 4701 Sfmt 4700 8929 communicated to developers who need the information. Similarly, a commenter noted that these technical API standards may require providers to hire additional staff to implement them. Response: The industry already has significant adoption of the FHIR standard for several use cases and there are solutions available today to FHIRenable existing systems. Additionally, many of the IGs recommended in this rule have already been implemented by multiple implementers at some level. We anticipate more solutions will be available in the marketplace ahead of the API compliance dates in 2027. We acknowledge that using marketplace technical solutions may ease implementation. We understand that there is still a learning curve with respect to the FHIR-based standards and IGs and that entities may need to hire and train staff. We appreciate these perspectives and acknowledge that standards are what promote interoperability. The adoption of the FHIR standard and the IGs promote interoperability by enabling the secure exchange of health information across disparate systems. The FHIR APIs provide the framework for this exchange. Regarding concerns for the lack of specificity in the API requirements, we acknowledge that we are only recommending rather than requiring several IGs because they continue to evolve and are not adopted by HHS at 45 CFR 170.215. As these IGs continue to mature, we will consider proposing to require them through future rulemaking. The IGs provide the exchange of the essential data elements, such as patient demographics, clinical information, prior authorization requests, and other data to ensure the necessary information is shared between payers and providers. We acknowledge that implementation and testing will take time and welcome ongoing feedback through the programs and standards workgroups. Comment: Multiple commenters expressed concern regarding the proposed technical standards and IG provisions outlined in the proposed rule. Multiple commenters noted that technical challenges around health information exchange could persist despite these proposals and that the technical standards lack the specificity and flexibility to properly support the interoperable exchange of data. Response: We received many comments regarding our approach in the proposed rule of recommending, rather than requiring, specific IGs. We believe that this approach optimally balances the need for us to provide directional guidance without locking implementers E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8930 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations into the versions of the recommended IGs that were available at the time of the proposed rule. As these IGs mature, industry can continue to harmonize on common approaches that work, eventually culminating in a required set of specifications, which, when ready, could be proposed through future CMS rulemaking. If we chose not to recommend specific IGs, this lack of direction would mean a more diverse set of proprietary solutions, resulting in little to no interoperability. Comment: A commenter stated that there is transformative effort and overall risk in requiring the Patient Access, Provider Access, and Payer-to-Payer APIs to be implemented around the same time. A commenter noted that the attachments standard is not mature and that could hinder non-structured data exchange such as in CMS’s proposals to require prior authorization documentation in the Patient Access, Provider Access, and Payer-to-Payer APIs. The commenter noted there is a risk in needing necessary endpoint connections and the functionality to convert documents between FHIR exchanges to be established by payers, providers, and health IT vendors for the purpose of data exchange. The commenter recommended that CMS first require the APIs and then add the exchange of attachments a few years later. Response: For the Patient Access, Provider Access, and Payer-to-Payer APIs, we are requiring impacted payers to share claims and encounter data, all data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI), and certain information about prior authorizations. Many of the data classes and data elements are already required for the Patient Access API, which means that payers have already formatted these data and prepared their systems to share via a FHIR API. We thus believe that payers can concurrently implement the APIs in this final rule. We agree that standards for transmitting documentation and attachments via the FHIR APIs are still under development and in testing, and thus not yet in widespread use across the industry. Further, as elaborated in sections II.A. and II.B. of this final rule, we agree that the burden of requiring impacted payers to make unstructured documentation available via the Patient Access and Provider Access APIs outweighs the benefits such documentation would provide. However, as discussed in section II.C., for the Payer-to-Payer API we are finalizing a requirement to exchange structured and unstructured VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 administrative and clinical documentation submitted by providers related to prior authorization requests and decisions. Comment: Multiple commenters encouraged CMS to work with ONC to ensure relevant technical standards and related IGs are sufficiently mature and reflect the proper content and policies to allow seamless data transfers between payers and providers. Another commenter urged CMS to work in partnership with ONC to establish a clear pathway for the required IGs including: (1) the ability to advance IG versions outside the regulatory cycle; (2) adequate time for industry to understand and adopt new IG versions; and (3) limiting options, so as not to disrupt interoperability. Response: As previously mentioned in this section, the primary components of the FHIR standard are mature, as are the standards we are requiring in this rule. We acknowledge that the FHIR resource profiles included in the IGs we recommend are of varying levels of maturity, we believe they are sufficiently mature for industry to start implementing them. We refer readers to our discussion on IG maturity in section II.G.3.b. of this final rule. We will continue to closely coordinate our policies with ONC to ensure that they are mutually reinforcing. We are also finalizing our proposal to allow payers to use updated standards, specifications, or IGs for each API, as long as certain conditions are met, including that the updated version does not disrupt an end user’s ability access the data required for that API. Comment: A few commenters shared concerns with the lack of a mandatory testing system, as well as lack of available test data, staging environments, sandboxes, and other mechanisms to help developers test their APIs. A commenter suggested CMS conduct usage validity testing of the payers’ APIs throughout the development and deployment process of the APIs to track and mitigate any risks associated with missing or incorrect data. The commenter requested that CMS delay the enforcement timeline to accommodate these critical prerequisites. Likewise, another commenter recommended that CMS postpone publication of the final rule until it can require both the technical standards and IGs to prevent nonstandard implementation across the industry. The commenter recommended that CMS work with the HL7 Da Vinci workgroup and ONC to ensure the APIs and associated standards are tested for complex use cases and to scale. Another commenter recommended CMS define PO 00000 Frm 00174 Fmt 4701 Sfmt 4700 or promote conformity to the ONC Inferno Framework. Another commenter recommended that CMS should establish a mandatory testing system like the ONC Cypress testing tool for the proposed APIs and data standards requirements. Multiple commenters noted that testing should be conducted in a variety of clinical settings, including small, independent, and rural practices, and with all end users to ensure that the technical standards and IGs are effective, adaptable, and efficient. A commenter highlighted that it is critical that any solution be fully developed and tested prior to wide-scale industry rollout and required usage to ensure the best return on the investment of industry resources. The commenter stated that this process should include careful consideration of the transactions’ scalability, privacy guardrails, and ability to complete administrative tasks in a real-world setting. Other commenters recommended that CMS establish additional pilot testing programs to ensure industry readiness before the compliance dates. Response: We agree that testing is an important part of the implementation process and will continue to support industry efforts to do so, including coordinating with ONC and HL7, including the DaVinci Accelerator, on such efforts. We will also continue to engage with ONC to determine whether the Inferno Framework 177 could be utilized in the future. HL7’s IG testing process includes privacy and security testing. Also, FAST,178 which is an initiative started by ONC, identifies FHIR scalability gaps, defines solutions to address current barriers, and identifies needed infrastructure for scalable FHIR solutions. Real-world testing can only be accomplished if payers choose to pilot an implementation during the testing phase, which CMS cannot require participation in. However, we are not delaying publication of this final rule, as we understand that industry requires a firm commitment from the Federal Government to the adoption and recommendation of standards. Based on comments received, and as discussed throughout this final rule, we are delaying the compliance dates for all the policies that require API development and enhancement to 2027, which will 177 Office of the National Coordinator for Health Information Technology (n.d.). Inferno. Retrieved from https://inferno.healthit.gov/. 178 Health Level Seven International (2023, October 13). FHIR at Scale Taskforce (FAST). Retrieved from https://confluence.hl7.org/display/ FAST. E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations allow additional time for FHIR specifications to continue to be refined and advanced to support the policies in this final rule. We also appreciate the multiple comments received on the importance of testing and the provision of examples, such as the ONC Cypress testing tool, which is an open-source tool used in the ONC Health IT Certification Program to ensure certified health IT accurately calculates electronic clinical quality measures (eCQMs). We will continue to collaborate with ONC and DaVinci on testing the APIs and with HL7 on communication and outreach to payers, developers, and providers. Comment: Multiple commenters urged CMS to closely track and participate in the standards development process to ensure that all perspectives are considered, such as providers, payers, and other applicable end users. Multiple other commenters urged CMS and ONC to provide funding to HL7 FHIR Accelerators and task forces. A commenter expressed their desire for CMS to increase opportunities for greater stakeholder participation in the standards development process. Another commenter recommended that CMS release a formal assessment of the status of technology development in support of the new requirements to demonstrate that the technology is fully developed and implementable. Response: We are an active participant in the standards development process through various workgroups and FHIR Accelerators. A few of the recommended IGs have been developed by HL7 FHIR Accelerator programs, which bring together individuals across the industry to create and adopt IGs in alignment with HL7, which allows new and revised requirements to become open industry standards. Under HL7 FHIR Accelerators, interested parties within the industry have defined, designed, and created use-case-specific implementations of FHIR to address value-based care initiatives. Some HL7 FHIR Accelerators, such as Da Vinci and CARIN, have created IGs that we recommend be used for the Patient Access, Provider Directory, Provider Access, Payer-to-Payer, and Prior Authorization APIs. We also provide contract support to supplement existing work led by the SDOs and FHIR Accelerators. Further, we cohost an annual FHIR Connectathon testing event with HL7 and encourage diverse stakeholder participation from payers, providers and patient advocates. HL7 has developed a FHIR Maturity Model VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 (FMM) 179 that defines thresholds of standards maturity as part of their standards development and publication process. HL7 requires a specific maturity level for parts of the standards development and publication process. We also note that ONC publishes an Interoperability Standards Assessment (ISA).180 The latest published 2023 version provides information on the HL7 standards that are required or recommended in this rule. Comment: A commenter urged CMS to pay close attention to principles that focus on assessing provider impact, measuring success in achieving stated goals, and monitoring standards development and use. The commenter stated that these principles can help guide CMS and developers to better respond to provider needs. Another commenter urged CMS to ensure that the technical standards meet provider and patient needs and accurately embody CMS’s goals to improve care and reduce provider burden. Response: We will continue to assess standards development and use as an active participant in the HL7 community and FHIR workgroups. We also encourage stakeholders to participate and contribute to the work of the SDOs in the standards development and evolution, because broad engagement would support the improvement of interoperable standards. Comment: A commenter recommended continued Federal support of ongoing standards development and data interoperability work, including financial and technical support, for SDOs such as the HL7 Da Vinci Workgroup, FAST, and other applicable workgroups. Some commenters encouraged CMS to advance the FAST initiatives to address the ongoing challenges of patient matching, identity management, security and authentication, and access to the necessary digital endpoints. Another commenter expressed support for incentives and investment in FHIRbased pilots and technology, stating that this would move the industry towards FHIR APIs for real-time information exchange. Response: We agree and intend to continue our support for and participation in various standards development activities. As noted 179 Health Level Seven International (n.d.). Version Management Policy. Retrieved from https:// hl7.org/fhir/R4/versions.html#maturity. 180 Office of the National Coordinator for Health Information Technology (2023). 2023 Interoperability Standards Advisory Retrieved from https://www.healthit.gov/sites/isa/files/inline-files/ 2023%20ReferenceM.A20Edition_ISA_508.pdf. PO 00000 Frm 00175 Fmt 4701 Sfmt 4700 8931 previously, we provide contract support to supplement existing work led by the SDOs and FHIR Accelerators. We believe that the policies that we are finalizing are a crucial step in moving the industry towards real-time information exchange. Comment: A commenter stated that to assist providers in making informed decisions, CMS should apply the same ‘‘discrete data element standards’’ the agency applied to the original Patient Access API to the new prior authorization data added to the Patient Access, Provider Access, and Payer-toPayer APIs. Another commenter requested that CMS consider synchronizing the required technical standards for those three APIs given that the APIs are functionally identical. The commenter stated that having a single standardized API for the three different access types (patient, provider, and payer) would provide three key benefits: (1) simplifies the technical approach for initial rollout and any future changes; (2) allows Medicaid programs to focus on challenges that these APIs pose; and (3) reduces end user confusion since end users will see the same data shared through the APIs. A commenter requested that CMS continue to standardize and harmonize API requirements to reduce potential burden for providers and confusion for consumers. Another commenter stated that these requirements should be consistent across all stakeholders. Response: Each of the APIs in this rule will require sharing only structured documentation, except for the Payer-toPayer API, which includes unstructured administrative and clinical documentation submitted by a provider to support a prior authorization request. We intentionally based the requirements for the Provider Access and Payer-toPayer APIs on the content requirements for the Patient Access API, to facilitate reuse, since payers have already formatted these data elements and prepared their systems to share these standardized data via a FHIR API. Payers already devoted the development resources to build a FHIR API infrastructure when they implemented the Patient Access API, which can be adapted for additional interoperability use cases. While the data we are requiring to be shared via these APIs would be nearly identical, they have different use cases, thus necessitating separate API regulatory requirements. We also encourage payers to reuse infrastructure for all the APIs. Payers may implement the API functionality by using one or multiple APIs, depending on their approach, as long as all E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8932 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations requirements are met for each of the APIs. Comment: Multiple commenters recommended that CMS align the technical standards provisions outlined in this rule with the HIPAA Standards for Health Care Attachments proposed rule (87 FR 78438). A commenter recommended that CMS work with ONC to do so. Another commenter stated that they support both rules and urged CMS to ensure that there are no duplicative efforts. Another commenter recommended removing the prior authorization provisions outlined in the HIPAA Standards for Health Care Attachments proposed rule and moving forward with finalizing FHIR-based standards and transactions. Another commenter encouraged CMS to work with ONC to align any prior authorization proposals with HHS’s proposal to establish a national standard for electronic attachments. Response: Requirements to use certain HIPAA transaction standards for prior authorization were proposed in the HIPAA Standards for Health Care Attachments proposed rule. These are related policies, and we will ensure a path toward implementation that will allow payers and providers to comply with both. However, because that rule has not been finalized, we cannot comment on how the standards would align with the policies in this rule. If finalized, in that final rule we would discuss the impact of those policies and any opportunities to align with our policies in this final rule. We will also continue to work with ONC on alignment between standards in this rule, and other standards adopted across CMS. Comment: Multiple commenters recommended that CMS institute financial incentives for market suppliers, providers, and payers to participate in the testing and development of technical standards, IGs, and applicable processes. The commenter stated that one of the primary challenges of standards development and testing is a lack of financial and regulatory incentives for stakeholders to participate, which then slows down testing. Multiple commenters cautioned CMS to consider the cost of establishing the proposed API infrastructure. Another commenter noted that implementation will require integration between the newly acquired API functionality and the existing data sources, which includes exporting data from current systems to be imported and stored within a FHIR-compliant repository so that it can be presented via the API to the user. Multiple commenters requested that CMS VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 provide technical assistance and resources to help the industry implement the APIs and meet all the technical standards and requirements outlined in this rule. Another commenter requested that CMS engage with stakeholders to develop resources and technical assistance to help industry operationalize and meet the proposed technical standards and API requirements outlined in the rule and any other parallel agency efforts. Response: At this time, we lack statutory authority to provide financial incentives to participate in the testing and development of technical standards, IGs, and applicable processes. While we do not currently provide funding for IT infrastructure development costs (except for Medicaid agencies, as discussed in section II.E. of this final rule), we do provide educational webinars providing overviews of the technical requirements in the interoperability rules. Additional public resources also exist through HL7, such as their Connectathons, HL7 website resources, and HL7 FHIR workgroup meetings that are generally available. We also cohost an annual Connectathon with HL7, which is free for stakeholders to attend. Ultimately, each payer is responsible for ensuring that their users are trained on their systems. Comment: A commenter stated that a frequent problem is that there is not a well-established or monitored mechanism for an implementer to contact a payer about implementation issues or implementation questions. The commenter stated that this is an important missing piece to making widespread implementation viable. The commenter reflected on the experience of third-party apps engaging with payers to implement the existing Patient Access API. They stated that third-party apps struggle with finding someone to fix issues, answer questions, approve their registrations, and address other barriers to implementation they experienced. Multiple commenters stated that to support the proposed APIs, provider and payer endpoints must be included in a national directory, available to support endpoint discovery, before the compliance dates of the Provider Access, Payer-to-Payer, and Prior Authorization APIs. A commenter stated that a CMS NDH should be initiated to help find provider and payer endpoints. Another commenter stated that the lack of an authoritative central directory could create a significant gap in the ability for industry to move many critical interoperability initiatives forward. Another commenter stated the proposed technical standards for APIs is PO 00000 Frm 00176 Fmt 4701 Sfmt 4700 a helpful step to greater interoperability; however, CMS failed to properly account for the complexity of this implementation. The commenter recommended that CMS should implement a national directory so that each plan and provider must maintain only one incoming/outgoing connection. Response: We acknowledge commenter concerns that there is not a monitored mechanism for contacting a payer about implementation issues or implementation questions. We thank the commenters for their concern that the lack of an authoritative central directory is a gap in the ability to move forward with interoperability initiatives. We do understand that a directory of payer and provider digital endpoints would be highly beneficial to facilitate our Payerto-Payer, Provider Access, and Prior Authorization APIs policies, and as discussed in section I.D. of this final rule we are committing to exploring an NDH that contains payers’ digital endpoints in support of the Payer-toPayer API and providers’ digital endpoints. We will also explore including payer contact information, including whom to contact regarding API implementation issues or questions, in any NDH we propose. Comment: A commenter stated that adding standard data classes and data elements around high-priority use cases is an effective strategy to make data more accessible to consumers. The commenter noted that the Provider Directory and Patient Access APIs can serve as a base for the other proposed APIs. The commenter provided recommendations to help CMS achieve this goal such as establishing operational standards to help developers, requiring payers to register app developers and grant authorization to production access without regard to out-of-band consent standards payers choose to implement, and establishing stronger requirements for payers to make this information available. The commenter also recommended that (1) CMS require impacted payers to establish sandbox environments; (2) CMS impose a reasonable time standard to mitigate implementation delays; (3) CMS require impacted payers to perform conformance tests and report results to the public; and (4) CMS require that impacted payers’ technical documentation for the Patient Access API notes what USCDI data are made available. Another commenter recommended that CMS should develop a roadmap in partnership with the private sector for all the technical use cases outlined in the proposed rule. Response: We appreciate the additional suggestions, however, many E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations of those were not proposed and therefore, we cannot include such provisions in the final rule. We also understand the value of a sandbox environment and acknowledge the value of payers establishing sandbox environments for implementers to test; however, we realize there are industry costs to doing so. Comment: Multiple commenters encouraged CMS to consider alternative approaches to achieving data exchange. A commenter recommended that CMS consider other types of interoperability technology beyond APIs and request/ response data exchange, which can lead to multiple copies of data. The commenter suggested CMS consider services that provide virtual real-time data updates. Another commenter recommended that CMS work with ONC to develop a future-looking approach to allow consumers to direct the sharing of claims data with third-party entities via a national exchange platform. A commenter recommended that CMS, ONC, and HL7 work together to build the infrastructure for a standard for ADT data. Response: While we appreciate the commenters who asked us to consider services that provide virtual real-time data updates and we recognize the importance of needing the patient information as soon as possible or in real time, we also believe that requiring that at this time would cause undue burden on impacted payers. We nonetheless encourage payers to make data available to requesting providers as soon as they are able. We understand the concern over duplicative information, and it is not our intention to increase provider burden sharing data through the APIs referenced in this final rule. There are IT solutions available for providers’ EHRs or practice management systems, such as SMART on FHIR apps, which can make the data received via the APIs actionable and avoid duplicative information. We also note that standards for ADT data are outside the scope of this final rule. Comment: A commenter highlighted that health IT challenges can sometimes be larger than they appear. The commenter stated that regulatory requirements can be tailored to coincide with health IT functionalities that are currently available to support organizations in accomplishing interoperability in a more affordable way. Response: We thank the commenter for their input and will continue to closely coordinate with industry to decrease implementation burden wherever possible. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 Comment: A commenter urged CMS not to finalize the interoperability proposals until stakeholders have had a chance to review and comment on ONC’s HTI–1 proposed rule, which was still under review at the Office of Management and Budget (OMB) at the time of publication of the CMS Interoperability and Prior Authorization proposed rule. Response: We recognize that commenters are interested in ONC policies that relate to the policies in the proposed rule. ONC has since published the HTI–1 final rule. While related, these rules address separate areas of CMS and ONC authority. We are not finalizing any modifications from the proposed rule based on HTI–1 other than updating our regulatory citations and incorporating expiration dates ONC has finalized for particular standards at 45 CFR 170.215. Therefore, we did not offer an additional comment period. Comment: Multiple commenters expressed appreciation for CMS not requiring health IT certification for the interoperability requirements outlined in this proposed rule. A commenter stated that establishing certification criteria based on the current HL7 Da Vinci IGs is premature. The commenter noted that providers must use data from CEHRT for the electronic prior authorization measure, which will serve as a spur for adoption of certified health IT. Another commenter noted that some of the proposed APIs require multiple health IT systems to interact and support a complex workflow and stated that establishing a certification approach using functional capabilities would be challenging, and encouraged CMS to engage with providers and payers to gather information to establish a well-defined and scalable set of guidelines and capabilities. Opposite to that, a commenter recommended that CMS work with ONC to incorporate new standards and requirements for API use by EHR vendors as certification criteria in the ONC Health IT Certification Program. Response: We did not propose and are not finalizing any other requirements related to certification under the ONC Health IT Certification Program in this final rule. However, we note that the Unified Agenda, at the time of this final rule’s publication, includes an entry for a proposed rule from ONC (RIN 0955– AA06).181 The description indicates that 181 Office of Information and Regulatory Affairs (n.d.). Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability. Retrieved from https://www.reginfo.gov/public/do/ eAgendaViewRule?pubId=202304&RIN=0955AA06. PO 00000 Frm 00177 Fmt 4701 Sfmt 4700 8933 that proposed rule aims to advance interoperability, including proposals to expand the use of certified APIs for electronic prior authorization. We plan to continue to explore how potential updates to the ONC Health IT Certification Program could support our policies and will address any updates to our requirements related to the Certification Program in future rulemaking. Comment: A commenter recommended that CMS should establish a consistent set of technical standards between the TEFCA and CMS-required APIs so that the industry does not have to implement multiple different standards depending upon the exchange partner or mechanism for exchange. Response: We refer readers to section II.B. of this final rule for a discussion on the interaction between policies that require API development or enhancement and TEFCA. Comment: A commenter recommended CMS consider a policy requiring third-party payers, benefit managers, and any other party conducting utilization management to accept and respond to standard electronic prior authorization transactions for pharmacy benefits that use a nationally recognized format, such as the NCPDP SCRIPT standard. Similarly, another commenter stated that CMS should encourage health IT vendors and developers to provide retail pharmacies with technical IT infrastructure to bridge the gap between pharmacy claim systems and medical benefit claims systems and noted that many retail pharmacies only utilize the NCPDP standards and do not have the capability to enroll as DME suppliers and submit claims using X12 transactions. Another commenter recommended that CMS explore the need to designate an electronic transaction standard for drugs covered under a medical benefit. Response: We appreciate stakeholders’ interest in pharmacy standards and bridging the gap between pharmacy and medical benefit systems and we recognize the need to do so in the future. However, as noted in section I.D.3., standards for data exchange for any pharmacy claims and drugs covered under medical benefits are excluded from our policies and out of scope for this rule. Comment: A commenter stated that under the ONC Health IT Certification Program, APIs must be registered within 15 days (45 CFR 170.315(g)(10)). However, the commenter stated that CMS did not impose any registration requirements for the proposed payer E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8934 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations APIs. The commenter recommended that CMS should consider imposing a reasonable registration period for APIs to address delays reported by CARIN members throughout the onboarding and authorization process to acquire test accounts, sandbox access to test API connections, and troubleshooting support. Response: We did not propose registration deadlines as a requirement for payer APIs in the same fashion as the health IT certification criterion at 45 CFR 170.315(g)(10), such that Health IT Modules certified to 45 CFR 170.315(g)(10) must register patientfacing applications within 15 days (per associated requirements at 45 CFR 170.404(b)); however, we acknowledge that such requirements can help to support the usability of APIs. We may further explore how to incorporate registration deadlines into our API requirements in future rulemaking. Comment: A commenter recommended setting an implementation date before January 1, 2026, and mandating HL7 FHIR Release 4.0.1. The commenter also recommended operational enhancements for payers such as payers allowing longer lifespans on access tokens, payers not imposing unsupported security and authentication workflows, and payers supporting test accounts and synthetic data in production environments. The commenter noted that these recommendations would dramatically improve access to data from available open APIs while setting standards for payers and their interoperability vendors to follow. Response: HL7 FHIR Release 4.0.1 has already been adopted by HHS in the ONC Cures Act final rule at 45 CFR 170.215 (85 FR 25521). We will continue to work with payers on testing and implementation of their interoperability APIs through FHIR Connectathons and encourage stakeholders to participate in FHIR workgroups. We will explore additional enhancements through future rulemaking. Comment: A commenter recommended using the most recently approved HL7 Da Vinci IG that supports HL7 FHIR Release 4.0.1. The commenter stated that the SMART App Launch IG does not support HL7 FHIR Release 4.0.1. Response: We thank the commenter for their recommendation, but we disagree that the SMART App Launch IG does not support HL7 FHIR Release 4.0.1, as the SMART App Launch IG is built on top of the FHIR Release 4.0.1 specification itself. The SMART App VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 Launch IG specifies a number of capabilities, including user authentication and authorization, backend service authentication, application launch, and context sharing, that systems can use to interact within the FHIR R4 standard. Comment: A commenter sought clarification on the use case for the Bulk Data Access IG for the Patient Access API, since one of the biggest challenges for EHR vendors today is determining how to handle inbound data exchanged via the FHIR standard. Response: We did not propose, nor are we finalizing, a requirement to require the Bulk Data Access IG for the Patient Access API. b. Additional Implementation Guide Discussion In the proposed rule, we discussed that several of the recommended IGs, such as HL7® FHIR® Da Vinci Payer Data Exchange (PDex) IG, build on specific profiles within the US Core IG (87 FR 7615). Following the publication of the HTI–1 final rule, at 45 CFR 170.215(b)(1) there are two adopted versions of the US Core IG: the US Core IG STU 3.1.1 (at 45 CFR 170.215(b)(1)(i)), until this standard expires on January 1, 2026, and the US Core IG STU 6.1.0 (at 45 CFR 170.215(b)(1)(ii)). We only proposed to require US Core STU 3.1.1 because it was the only version adopted at the time of the proposed rule. However, we recognize that some of the recommended IGs (and subsequent versions) may use profiles added in US Core IG STU 6.1.0. Payers can use updated versions of the recommended IGs that rely on newer versions of the US Core IG, if those updated versions meet our existing requirements finalized in the CMS Interoperability and Patient Access final rule (85 FR 25532), as discussed further below. Specifically, in the proposed rule, we recognized that the data content for each API may only require a subset of the profiles defined within the US Core IG and gave examples (87 FR 76314– 76315). While we want to ensure that implementers’ systems create FHIR resources conformant to the US Core IG, where applicable, to support interoperability across implementations, we also do not want to require payers to engage in unnecessary development. Therefore, we proposed and are finalizing that impacted payers are only required to use technology conformant with the US Core IG, where applicable (that is, where there is a corresponding FHIR resource to the data content requirements for the API). If a FHIR resource is part of the required data PO 00000 Frm 00178 Fmt 4701 Sfmt 4700 content and has been profiled by the US Core IG, then the payer must support the FHIR resource according to the FHIR resource profile’s ‘‘Structure Definition’’ in the US Core IG. For example, because the ‘‘Patient’’ FHIR resource is required in the Patient Access API, the ‘‘Patient’’ FHIR resource must conform with the ‘‘US Core Patient Profile,’’ including all the ‘‘mandatory’’ and ‘‘must support’’ requirements specified in the US Core IG. c. Using Updated Versions of Required Standards In the CMS Interoperability and Patient Access final rule (85 FR 25510), we established that impacted payers could use an updated version of a required standard for the Patient Access or Provider Directory APIs under certain conditions. Payers may use updated versions of standards at 45 CFR 170.213 and 170.215 if the following conditions are met: (1) the National Coordinator has approved the updated version for use in the ONC Health IT Certification Program, (2) the updated version of the standard does not disrupt an end user’s ability to access the required data via that API, and (3) the updated standard is not prohibited by law (85 FR 25522). Payers may use an updated version if required by other applicable law. We proposed to extend this policy to allow payers to use updated versions of a standard to the Provider Access, Payerto-Payer, and Prior Authorization APIs. Under that proposal, impacted payers could upgrade to newer versions of the required standards, subject to those limiting conditions (87 FR 76315). One of those conditions for using updated versions of the standards at 45 CFR 170.213 and 170.215 is that the National Coordinator has approved the updated version for use in the ONC Health IT Certification Program. The National Coordinator approves updated versions of standards in the ONC Health IT Certification Program through SVAP, pursuant to 45 CFR 170.555, which was finalized in the ONC Cures Act final rule as a Maintenance of Certification flexibility included in the real-world testing Condition of Certification (85 FR 25775). This flexibility permits health IT developers to voluntarily use, in certain certified Health IT Modules, newer versions of adopted standards so long as specific conditions are met, providing a predictable and timely approach within the ONC Health IT Certification Program to keep pace with the industry’s standards development efforts. Under SVAP, after a standard has been adopted through notice and comment rulemaking, ONC engages in E:\FR\FM\08FER2.SGM 08FER2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations lotter on DSK11XQN23PROD with RULES2 an open and transparent process to timely ascertain whether a more recent version of an adopted standard or implementation specification should be approved by the National Coordinator for developers’ voluntary use in the ONC Health IT Certification Program. ONC publishes updated versions of standards under consideration for SVAP and lists the updated versions of standards that the National Coordinator has approved as part of the Interoperability Standards Advisory on HealthIT.gov.182 Members of the public can use this resource to review standards that may be approved through SVAP in the future, as well as provide input on which updated versions should be approved. We encourage impacted payers to review these resources to better understand how updated versions of the standards at 45 CFR 170.213 and 170.215 may be approved by the National Coordinator through SVAP and become available for payers to use in their APIs, provided other specified conditions for using updated standards are met. Several updated versions of the standards currently at 45 CFR 170.213 and 170.215 have been approved by the National Coordinator through SVAP,183 including USCDI v2 and v3; US Core IG STU 4.0.0, 5.0.1, and 6.1.0; SMART App Launch IG Release 2.0.0; and Bulk Data Access IG v2.0.0: STU 2. As soon as the National Coordinator approves updated versions through SVAP, we consider the updated versions to have met this condition for use by impacted payers for our API requirements. We emphasize that if impacted payers choose to use updated standards, it must not disrupt an end user’s ability to access the required data. We are finalizing this proposal, as proposed. Comment: Multiple commenters expressed support for CMS’s proposal to allow flexibility for payers to use updated versions of certain standards and specifications required for APIs in the proposed rule. A commenter expressed support for aligning standards between the Patient Access, Provider Access, and Payer-to-Payer APIs, as this ensures data compatibility between use cases. Another commenter stated that the standards and specifications at 45 CFR 170.215 are more advanced and better aligned with present efforts to 182 Office of the National Coordinator for Health Information Technology (n.d.). SVAP. Retrieved from https://www.healthit.gov/isa/standardsversion-advancement-process. 183 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. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 streamline prior authorization workflows by leveraging HL7’s FAST work. Another commenter stated that these standards support widespread interoperability, ease implementation, and minimize complexity and costs. A commenter expressed strong support for CMS’s efforts to promote portability of patients’ EHI between providers and payers to assure continuity of care by further building on the common standards platform of FHIR APIs using USCDI, where applicable. Multiple commenters expressed support for the continued alignment between CMS and ONC regarding updates to technical standards and specifications through the rulemaking process. Response: We acknowledge and thank commenters for their support of our policies. Comment: A commenter stated that CMS’s approach to mandating technical standards by referencing specific standards in regulation is novel for health information exchange. The commenter stated that prior data exchanges, such as the HIPAA standard transactions or the machine-readable files, have everything defined in the named specifications and not defined by reference to another standard in regulation. The commenter stated that having standards specified elsewhere allows for the referenced standards to be changed which would then have the cascading effect of requiring changes in all the APIs on the timeframe of the standard change for the APIs to remain conformant. The commenter disagreed with this regulatory approach and stated that it is better to have each API specified separately and to be selfcontained (that is, not having referenced standards). The commenter stated that this way individual APIs could be evaluated for change on their own merits, as standards in the HIPAA Standards for Health Care Attachments proposed rule are currently being evaluated with the potential change in the version for the X12 278 transaction standard for attachments under HIPAA (version 6020) or for the X12 837 transaction standard for claims, and the X12 835 transaction standard for remittance advice being recommended by X12 for consideration to X12 8020 transaction standard for plan premium payments, or the recommended upgrade of three other X12 transactions to version 8030, including claim status, health plan enrollment, and health plan premium payments. Response: We appreciate the commenter’s concerns regarding the timing of updates to required standards via reference to other regulations. We intend to collaborate with ONC to PO 00000 Frm 00179 Fmt 4701 Sfmt 4700 8935 ensure updates to standards are deployed with reasonable timeframes and sufficient advance notice for payers to make any required updates to their APIs. Aligning with the HHS-adopted API standards and associated implementation specifications at 45 CFR 170.215 is important to ensure consistency. We are finalizing the versions of the required standards that were at 45 CFR 170.215 at the time of this proposed rule. However, ONC has since finalized the HTI–1 final rule (89 FR 1192), which adopted updated versions of certain standards including the US Core IG STU 6.1.0 (at 45 CFR 170.215(b)(1)(ii)) and the SMART App Launch IG Release 2.0.0 (at 45 CFR 170.215(c)(2)). Additionally, ONC has finalized expiration dates for the US Core IG STU 3.1.1 (at 45 CFR 170.215 (b)(1)(i)) and the SMART App Launch Framework IG Release 1.0.0 (at 45 CFR 170. 215(c)) to indicate when a version of a standard may no longer be used. We intend to align with the updated versions finalized at 45 CFR 170.215 through future rulemaking prior to the API compliance dates. While we did not propose to require those updated versions, we emphasize that impacted payers are permitted to use them based on our policy to allow updated versions of required standards, as discussed below. The update and review process for HIPAA transaction standards follows a statutory review process but does not include the same testing and balloting process we require for the standards and IGs. Furthermore, the HL7 standards and IGs adopted by ONC may be updated for use in the ONC Health IT Certification Program through the SVAP. We rely on this flexibility in our update policy by allowing payers to use versions of standards at 45 CFR 170.213 and 170.215 that have been approved by the National Coordinator, enabling a nimble approach to industry testing and innovation. This does not currently exist under the HIPAA standard transaction reference model process. Comment: Multiple commenters recommended that CMS update the clinical data requirements to USCDI v2. The commenters also recommended that CMS give guidance on if and when USCDI v3 and v4 may be required. The commenters noted that use of these updated standards would advance health equity and public health work. A commenter strongly recommended that impacted payers incorporate data elements identified in a newer version of the USCDI, specifically USCDI v3, instead of the proposed USCDI v1. The commenter noted that USCDI v1 does not constitute an elaborated list of data E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8936 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations elements compared to the most recent versions, which incorporate elements that play a critical role in electronic data exchange. Another commenter requested CMS and ONC provide guidance regarding using newer versions of USCDI and associated US Core IG. The commenter noted that this guidance will be helpful when multiple versions of the USCDI are available for use, so all third-party app developers have clear expectations and understanding regarding what data they need to be able to share and receive. Response: As discussed in section II.A.2.d., we are finalizing a change to the required data content for the Patient Access, Provider Access and Payer-toPayer APIs to a standard listed at 45 CFR 170.213. At the time of the CMS Interoperability and Prior Authorization proposed rule, USCDI v1 was the only version of the USCDI adopted at 45 CFR 170.213. However, ONC has since published the HTI–1 final rule, which establishes a January 1, 2026, expiration date for USCDI v1 and adopts USCDI v3 at 45 CFR 170.213. After January 1, 2026, USCDI v3 would be the only version specified at 45 CFR 170.213 that has not expired (89 FR 1192). In this way, the required version of the USCDI for the APIs in this final rule will advance in alignment with versions adopted by ONC in 45 CFR 170.213. When more than one version of USCDI is adopted at 45 CFR 170.213 and have not expired, payers may conform to either version. As stated previously in this section, we are also finalizing our proposal that an updated version of a standard could be used if it is required by other law, or if ONC has approved the updated version for use in the ONC Health IT Certification Program, users are able to access the required data via the API, and it is not prohibited by other law. In order to identify updated standards that have been approved for use in the ONC Health IT Certification Program, payers can review the standards approved through the SVAP on ONC’s website https://www.healthit.gov/isa/standardsversion-advancement-process, as well as standards that are being considered for approval through SVAP (new standards for SVAP are approved annually). We note that USCDI v2 was approved in the 2022 SVAP cycle, while USCDI v3 was approved as part of the 2023 SVAP cycle.184 We also note that several updated versions of the US Core IG subsequent to the required US Core IG STU 3.1.1 have been approved by the National Coordinator through the SVAP and are available for payers to use under this policy, including US Core IG STU 4.0.0, 5.0.1, and 6.1.0.185 The US Core IG is updated annually to reflect changes to the USCDI, and each US Core IG version is built to a specific version of the USCDI. For instance, US Core IG STU 3.1.1 is built to USCDI v1 and the US Core IG STU 6.1.0 is built to USCDI v3. As the recommended IGs continue to be refined and advance, they may reference different versions of the US Core IG based on updated versions of the USCDI. Implementers are encouraged to adopt the newer versions of the recommended IGs as they are published. Consistent with our final policies to allow payers to use updated standards at 42 CFR 170.215 if they have been approved by the National Coordinator for use in the ONC Health IT Certification Program and other conditions, implementers may use updated versions of US Core referenced to the specifications in recommended IGs. HL7 and the FHIR Accelerators are aware of these concerns and are working on an approach to enable greater version support for IGs. Comment: Multiple commenters supported flexibility to use updated standards, such as ONC’s SVAP for certified health IT developers, to allow payers to use the most current recognized versions of vocabulary standards and interoperability standards or specifications used in the certification. A commenter stated that CMS should only require new versions of standards, specifications, and IGs after testing and adequate time for implementation. Another commenter stated that the mechanism to allow implementers to advance versions of standards in this rule as long as using an updated standard does not impair access to data through the API can be used for any or all IGs used to support these APIs or related auxiliary processes (for example, patient attribution). Response: We appreciate the support for this policy. The standards we are requiring in this final rule are those that we believe are sufficiently mature. We intend for future rulemaking to operate similarly. As stated, payers can implement the latest versions of the required standards and IGs as long as they meet the specified conditions, such as not impairing access to data through the API. 184 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. 185 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. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 PO 00000 Frm 00180 Fmt 4701 Sfmt 4700 Comment: Multiple commenters stated that use of specific FHIR-based standards, specifications, and IG versions should align with those approved by ONC through SVAP. A commenter stated that CMS requirements and adoption timelines should remain coordinated with ONC’s progression. The commenter suggested that CMS use a more general reference to the ONC Health IT Certification Program and SVAP. Another commenter stated that ONC will be providing a more current set of standards and specification versions soon through ONC Health IT Certification Program updates. The commenter stated that it is imperative that CMS require developed APIs to conform to the most recently approved SVAP standards within 12 months of approval. The commenter also recommended that CMS coordinate with ONC to include more standards and IGs in the SVAP to align with the rule. The commenter also recommended that CMS include a transition period (for example, 12 months). Response: We appreciate the commenters feedback and remind readers that under this final rule, in addition to our coordination with ONC, payers are permitted to voluntary use updated standards provided it does not disrupt an end user’s ability to access the data available through the API. In addition, implementers may advance to those standard versions approved by the ONC through SVAP. We decline at this time to set a timeline by which we would require impacted payers to use the updated version of the standard rather than the adopted version of the standard. We believe the voluntary nature of the SVAP supports a transitional period— also a request from commenters—by allowing for a flexible implementation of standards versions between regulatory cycles during which ONC revises the adopted version to the latest update for each standard. We will continue to engage with patients, providers, payers, health IT developers, and our Federal partners to ensure that this approach balances the need to advance standards with the need for flexible transition periods for updates. We will also continue to work with ONC in their efforts to support HHS and the health care industry through the advancement and adoption of interoperable standards and implementation specifications for a wide range of health IT use cases. We support innovation and continued efforts to refine standards in a way that will leverage the most recent technological advancements. Thus, we also sought comment on the process we E:\FR\FM\08FER2.SGM 08FER2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations should use to adopt or allow new versions of standards and implementation specifications over time. We received many comments in response to our request for comment and will consider this feedback for future rulemaking and guidance. We are finalizing the proposal to allow payers to use an updated standards, specifications, or IGs if required by law, or if the updated standard, specification, or IG is approved for use in the ONC Health IT Certification Program, do not disrupt an end user’s ability to access the required data, and is not prohibited by law for each of the APIs at the CFR sections listed in Table H2. lotter on DSK11XQN23PROD with RULES2 3. Recommended Standards To Support APIs In the CMS Interoperability and Patient Access final rule (85 FR 25529), we noted that there are publicly available IGs that provide implementation information that impacted payers can use to meet the regulatory requirements for these APIs. Using those IGs supports interoperability and allows impacted payers to avoid developing an approach independently, which could save time and resources. In this final rule, we are recommending specific IGs that are relevant to each of the APIs, which may be used in addition to the required standards at 45 CFR 170.215. In the December 2020 CMS Interoperability proposed rule, we proposed to require impacted payers to use certain IGs, including the CARIN IG for Blue Button®, HL7® FHIR® Da Vinci PDex IG, HL7® FHIR® Da Vinci PDex U.S. Drug Formulary IG, HL7® FHIR® Da Vinci PDex Plan Net IG, HL7® FHIR® Da Vinci Coverage Requirements Discovery (CRD) IG, HL7® FHIR® Da Vinci Documentation Templates and Rules (DTR) IG, and HL7® FHIR® Da Vinci Prior Authorization Support (PAS) IG (85 FR 82586) to support the APIs in that proposed rule. As discussed in section I.A. of this final rule, we are withdrawing the December 2020 CMS Interoperability proposed rule. We also noted that these IGs continue to be developed and refined through the HL7 ballot and standard advancement process to better support the Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization APIs. a. Recommending vs. Requiring Implementation Guides In the CMS Interoperability and Prior Authorization proposed rule, we proposed to recommend CARIN for Blue Button, PDex, PDex U.S. Drug Formulary, PDex Plan Net, CRD, DTR, and PAS IGs for specific APIs, as listed VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 in Table 10 of the proposed rule (87 FR 76320). We also solicited comments on whether CMS should propose to require these recommended IGs in future rulemaking and other ways that we could support innovation and interoperability. We emphasize that while we are not requiring payers to use the recommended IGs listed in Table H3, we may propose requiring payers to use these and other IGs in future rulemaking, should they reach sufficient maturity. After careful consideration of the versions of the IGs that were available at the time of the proposed rule, we determined that we were not ready to propose them as requirements. We stated that we believed these IGs would continue to be refined over time as interested parties have opportunities to test and implement them, and as such, we chose to recommend them rather than require them. Specifically, we stated we would continue to monitor and evaluate the IG development and consider whether to propose them as a requirement at some future date. In this final rule, we are finalizing our recommendation to use the CARIN for Blue Button, PDex, PDex U.S. Drug Formulary, PDex Plan Net, CRD, DTR, and PAS IGs for the Patient Access, Provider Access, Provider Directory, Payer-to-Payer, and Prior Authorization APIs, as applicable and listed in Table H3. We also note that several of the recommended IGs have had updated versions published since the CMS Interoperability and Prior Authorization proposed rule. Thus, we have updated Table H3 accordingly to represent the most recent published versions of the recommended IGs. Because these are only recommended IGs, we do not codify version updates through rulemaking. We acknowledge that by recommending rather than requiring certain IGs, there is potential for implementation variation that could limit interoperability and ultimately lead to rework for implementers if requirements are introduced later. However, we concluded at the time of the proposed rule that it was more important to not require the IG versions available at that time due to the maturity of the versions available. We recommended, but did not propose to require, these IGs because we wanted to ensure that implementers can use subsequent versions of these IGs without being restricted to the version available when we issued the notice of proposed rulemaking. As discussed in section II.G.2.c. of this final rule, we are finalizing a provision to allow payers the flexibility to use updated versions of PO 00000 Frm 00181 Fmt 4701 Sfmt 4700 8937 certain standards required for the APIs in this final rule. In the CMS Interoperability and Prior Authorization proposed rule (87 FR 76316), we acknowledged that subsequent versions of the recommended IGs may include substantial changes that would not be consistent with the requirement that an updated standard must not impair access to data through the API. We intend to monitor IG development and may propose to require specific IGs at a future date and/or allow for voluntary updates under our flexibility policies. We received comments on our decision to recommend, rather than require the listed IGs in the proposed rule. Comment: Multiple commenters appreciated CMS’s decision to recommend rather than require the CARIN for Blue Button, PDex, PDex U.S. Drug Formulary, PDex Plan Net, CRD, DTR, and PAS IGs. A commenter supported CMS’s decision to recommend instead of requiring IGs given that some of the standards and IGs are not yet mature enough for industry adoption. Another commenter appreciated CMS’s decision to recommend rather than require IGs due to the interplay between this rule and the HIPAA Standards for Health Care Attachments proposed rule. Response: We thank commenters for their support of our decision to recommend certain IGs in the proposed rule, which we believe balanced the need to provide guidance and flexibility to industry as standards advance. Comment: Multiple other commenters supported the recommended IGs, but noted concern that these IGs do not have enough outside involvement in the development phase, which could result in gaps in workflows. However, the commenters noted that they are confident that the HL7 Accelerator workgroups will provide the necessary maturity if given sufficient time. Response: These standards development activities do have outside parties involved throughout the standards development process. We encourage all interested parties, especially those who already have the experience implementing the APIs, to engage with the process. HL7 and the Accelerators welcome and solicit feedback for all of their IGs and specifications. Meeting participation is largely open to the public, and one does not have to be a member to participate in testing events and many other standards development activities. Comment: Multiple commenters disagreed with CMS’s decision to recommend rather than require the IGs and expressed concern for CMS’s decision to not require certain IGs, with E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8938 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations one concerned that not requiring the IGs will impact the level of interoperability necessary to support data exchange. Commenters urged CMS to consider the potential for implementation variation in APIs and limit industry-wide interoperability. Multiple commenters expressed that it is important that adherence to IG requirements is required, not just encouraged, to ensure the industry adopts these to obtain the benefits of the near real-time Prior Authorization API transactions. Another commenter recommended that CMS adopt and require IGs as quickly as possible. The commenters stated that without IGs, there is a risk that early work done by health IT developers and the health care community will have to be refactored or restarted to meet the IG guidelines. A commenter stated that CMS should act swiftly to encourage the creation of more appropriate IGs and recommended that CMS work with payers to create electronic systems and interfaces that are consistent and easy to use. Another commenter stated that not requiring certain IGs is not in line with the interoperability goals and prior authorization initiatives outlined in this rule to obligate providers to report on their adoption of this technology if that technology will not be uniformly adopted and implemented between different payers. A commenter stated that it is critical that all data contributors be held to the same set of rules and required to adopt the same standards and IGs. To ameliorate this, the commenter recommended that the IGs be required rather than recommended, and that a mere recommendation may result in more burden and duplicative work. A commenter stated that because CMS is not requiring certain IGs, it is unfair and contrary to the goals of these interoperability and prior authorization initiatives to obligate MIPS eligible clinicians, eligible hospitals, and CAHs to report on their adoption of this technology when that technology will not be uniformly adopted and implemented between different payers. Multiple commenters recommended that CMS require impacted payers to use the CARIN for Blue Button, HL7® FHIR® Da Vinci Patient Coverage Decisions Exchange (PCDE), PDex, PDex U.S. Drug Formulary, PDex Plan Net, CRD, DTR, and PAS IGs while allowing for adaptability and advancement of those IGs over time. A commenter stated that requiring certain IGs would move payers toward standardized data exchange. A commenter noted that most of the IGs have been around for several years, and most have been tested in VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 multiple Connectathons, pilot projects, and in production environments. The commenter believes having consistent, well-understood data fields with clear meaning that everyone uses the same way is a key element of any API or any successful data exchange. The commenter stated that using standard IGs would move industry toward interoperable data exchange. Response: We received a significant number of comments on both sides regarding requiring IGs and not requiring IGs, which indicates that there is not broad agreement across the industry. In the proposed rule, we sought to strike a balance by requiring the standards and IGs adopted at 45 CFR 170.215 in alignment with ONC and recommending additional IGs for each API implementation. We acknowledge that by not requiring all the available IGs, there is potential for implementation variation in these APIs that could limit interoperability and ultimately lead to re-work for implementers if requirements are introduced later. However, at the time of the proposed rule, we believed it was more important not to require these IGs while they were still undergoing additional enhancements. We disagree with the concern that our decision to not propose to require certain IGs is unfair and contrary to the goals of these interoperability and prior authorization initiatives of this final rule. The required standards at 45 CFR 170.215 mean that impacted payers must implement these APIs using the FHIR standard, which will advance interoperability. We continue to strongly recommend using the other recommended IGs listed in Table H3. As stated previously, we also believe that the approach in the proposed rule of recommending, but not requiring, the specific IGs and versions provided directional guidance with flexibility to the industry in order to allow for additional improvements to be made without locking implementers into versions of the IGs available at the time of the proposed rule. Under the recommendations in the proposed rule, as these IGs progress, industry could continue to harmonize on common approaches that work, eventually culminating in a required set of specifications when ready through updates to CMS policy. To not identify any specific IGs would have meant a more diverse set of proprietary solutions with little to no interoperability. Our recommendations provide direction to implementers. Comment: A commenter stated that the development and maintenance of standards and IGs are an extension of PO 00000 Frm 00182 Fmt 4701 Sfmt 4700 Federal policy that does not go through the rulemaking process. They noted that it is critical that this development and maintenance process be consensusbased, fair, transparent, and open to all stakeholders. The commenter continued by stating that the IG creation process is currently driven by a limited number of volunteers that do not broadly represent the industry, which results in IG resource and profile versioning issues. The commenter stated that CMS should ensure there is no fee to fully participate in the process for the regulatorily required exchanges and relying on an American National Standards Institute (ANSI)-accredited process to develop the IGs would improve the approach. Response: We acknowledge that standards and IGs are not developed through the rulemaking process. Rather, standards and IGs go through the rulemaking process if and when they are proposed to be adopted. We also appreciate that commenters are invested in the quality of the IGs and the SDO, and affirm, as we stated in the CMS Interoperability and Patient Access final rule (85 FR 25540), that development and maintenance of standards are the purview of SDOs, and that interested parties, including Federal agencies, participate in that process. Stakeholders have the opportunity for review and comment on the standards both at the time they are being developed, as well as during the proposed rule comment period. HL7 is an ANSI-accredited 186 SDO, and Da Vinci is an accelerator workgroup under the umbrella of HL7 and operates under the same rules of all ANSI accredited SDOs in the manner in which they obtain consensus on standards. Furthermore, HL7 standards are free and open-source, and documentation is available to anyone to ensure that all developers can equally access information. Using these freely available materials will reduce the development burden for both payers and app developers and facilitate industry-wide interoperability. Similarly, participation in online working meetings and providing feedback as part of the standards development process is free, and diverse organizational representation is critical to the quality of the standards and IGs. Thus, we encourage as many organizations as possible with a stake in the development and quality of these guides to participate. HHS uses different authorities to adopt and require standards that are developed and 186 ANSI oversees standards and conformance of processes for all SDOs. See American National Standards Institute (2023). ANSI. Retrieved from https://ansi.org/. E:\FR\FM\08FER2.SGM 08FER2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations lotter on DSK11XQN23PROD with RULES2 maintained by organizations such as HL7 using the processes described previously. For instance, ONC has adopted the standards and implementation specifications at 45 CFR 170.215 cross-referenced in this final rule under the authority of section 3004 of the Public Health Service Act. Comment: A commenter suggested CMS emphasize that using the IGs is not limited to literal use, but also interpretive use to model interactions within the respective health IT configuration in a way that is illustrative rather than prescriptive. Response: IGs contain both SHALL and SHOULD statements, which respectively indicate whether health IT systems must meet certain requirements to conform to the IG or are just strongly recommended to. While implementers will be required to conform with the required IGs we are finalizing, we remind readers that the recommended IGs can be implemented as they see fit as long as they meet the requirements of the API. b. Implementation Guide Maturity In the proposed rule, we welcomed further information about the maturity of the recommended IGs, including considerations about further development that may be needed prior to us proposing to require the IGs we recommended (87 FR 76317). Comment: Multiple commenters expressed concern regarding the maturity, scalability, and real-world testing of the IGs recommended in the proposed rule. Multiple commenters were concerned that there may be compatibility issues between the current and future versions of the IGs given that the IG versions are not currently finalized. A commenter stated that slight variations in API implementation could significantly increase burden placed on the provider community. A commenter recommended that CMS and ONC issue guidance on what could be expected in the IG guidelines to inform early work and to encourage as much fidelity to these IGs as possible. Response: We are committed to continuing to work with HL7, the Accelerators, and interested parties within the industry to define, participate in, and convene testing events, as well as developing and maintaining the specifications, thereby moving them toward greater maturity. We acknowledge that, as with any standard, potential compatibility issues could arise throughout development. These standards are subject to a standards development process where changes are reviewed and compatibility is an important consideration, VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 increasing with the level of use and adoption. As IGs mature, the number of potential compatibility issues between versions is expected to decrease. Likewise, as IGs continue through the standards development process, they will be enhanced to address areas of variance among payers that are barriers to interoperability. We determined that it was important to recommend these IGs to move the industry and provide direction towards a common set of specifications, as opposed to not including these recommendations, which would lead to a greater number of variations and cause a greater burden. Comment: A commenter recommended that CMS explain that support for SMART Backend Services specification is also required with the Bulk Data Access IG. Another commenter stated that significant limitations exist for the Bulk Data Access IG and OpenID Connect Core standard. The commenter noted that it is unknown when the Bulk Data Access IG will be ready for implementation and use on a large scale. Response: The Bulk Data Access IG v1.0.0: STU 1 includes the option for SMART Backend Services specification to enable system-to-system authentication and authorization of backend services. The Backend Services specification that was included in Bulk Data Access IG v1.0.0: STU 1 was moved to SMART App Launch IG Release 2.0.0. Therefore, we strongly recommend that the SMART Backend Services specification of the SMART App Launch IG Release 2.0.0 be supported and thus have included this recommendation for both the Provider Access and Payer-to-Payer APIs in Table H3. We acknowledge that not all connections may use backend services, but when such services are available, payers may wish to use the HL7 SMART Framework. More recent versions of the SMART App Launch IG specification, starting with Release 2.0.0, incorporate the SMART Backend Services, which ONC has adopted in the HTI–1 final rule at 45 CFR 170.215(c). We further remind readers that though we are requiring impacted payers to support Bulk Data Access IG for the Provider Access and Payer-to-Payer APIs in this final rule (Table H3), payers are free to set their own criteria for using bulk data exchange. Comment: A commenter recommended that CMS delay API implementation until the recommended IGs are ready to be required. The commenter noted that the proposed APIs are not feasible without standardized adoption and expressed concern that the necessary IGs to PO 00000 Frm 00183 Fmt 4701 Sfmt 4700 8939 implement the APIs are not mature, tested, or ready to scale. A commenter suggested that CMS should work with interested parties across the health IT community to propose and finalize IGs that are not mature prior to mandating their use. Response: We remind readers that we are finalizing 2027 compliance dates for the policies that require API development and enhancement partly to allow industry additional time to implement the needed functionality within their internal systems. By requiring some IGs and recommending others, we believe that we achieved the appropriate balance between moving industry forward, while allowing flexibility for continued development of IGs that were not sufficiently mature at the time of the proposed rule to propose to require. Comment: A commenter encouraged CMS to take on an active role in the continued development and testing of the HL7 Da Vinci IGs. The commenter recommended that CMS review and release a formal assessment of the technology development no later than July 1, 2024. Response: We are a member of HL7 and monitor their activities by attending the HL7 Da Vinci workgroups, providing contract support for the development of the IGs, and tracking the ballot process. Through these efforts, we are continuously engaged in IG development and maintenance. We thank commenters for their suggestion but note that the request to release a formal assessment of technology development no later than July 1, 2024, is out of scope for this final rule. Comment: Multiple commenters urged CMS to identify a baseline or ‘‘floor’’ version of the technical standards and IGs, and multiple other commenters recommended CMS develop a formal standards advancement process, like the SVAP, to give industry the opportunity to continue refining, testing, and deploying new versions. Multiple commenters noted that requiring an updated version of an IG as a baseline requirement must be done officially through government regulation. Another commenter recommended CMS develop a strategy or a process to decide which version of IGs or standards should be required. A commenter believed that all interested parties should agree upon IGs for each of the APIs. The commenter stated that in the final rule, CMS should identify the requirements, including IGs, for all interested parties. Another commenter recommended that CMS explain the functionalities of specific E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8940 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations IGs they would like applied to each of the APIs. Multiple commenters urged CMS to work with interested parties to identify a limited number of IGs to require so industry is not overwhelmed with too many IGs. Moreover, multiple commenters expressed concern about requiring more than one IG for specific API implementations and requested that CMS only require one IG. A commenter noted they support clear and unambiguous standards to achieve true interoperability. Response: The required standards and recommended IGs for each of the APIs are listed in Table H3 and represent the minimum expected of impacted payers. The FHIR IGs have been developed to fulfill a specific purpose and therefore requiring more than one IG for a specific API is appropriate. Specifically, the IGs we are recommending all have individual purposes and we are only recommending those relevant to each API as listed in Table H3. We also remind interested parties that the IGs go through a consensus-based process and participation in the online meetings and providing feedback is free, thus, we encourage as many organizations as possible with an investment in the development and quality of these guides to participate. Comment: Multiple commenters recommended that CMS explain how technical standards and IGs will be mapped to specific API functionalities. Response: We refer readers to Table H3 for an outline of which standards and IGs pertain to which APIs. We also remind readers that our recommended IGs can support the required standards for the specific API we are recommending them for. Comment: Multiple commenters expressed support for work done by the CARIN Alliance, which provides a method for all payers to make submitted and processed claims data available to patients and has sufficient maturity to ensure a successful implementation. Multiple commenters requested that CMS consider mandating the CARIN IG for Blue Button. A commenter stated that otherwise, stakeholders will have to support multiple IGs, which adds burden and increases technology complexity making development and implementation challenging. Multiple commenters expressed support for clear and unambiguous standards. A commenter stated the CARIN IG for Blue Button already produces an EOB for in-patient, out-patient, professional, pharmacy, dental, and vision services through a set of FHIR profiles. The commenter noted that these same profiles could provide the required non- VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 financial view of the EOBs to meet the requirements outlined in this proposed rule by using the ‘‘Summary View’’ returned by FHIR’s summary parameter search. Response: We agree about the importance of the CARIN Alliance’s work. However, for reasons explained in section II.G.3.a. of this final rule, we did not propose to require several IGs which are listed in Table H3 as Recommended IGs, including the CARIN IG for Blue Button. Regarding the recommendation to leverage the non-financial view of a CARIN IG for Blue Button, we note that in order to do this, the CARIN IG for Blue Button would need to be updated, or other guidance provided to support this requirement, and that the data be made available through the appropriate API. Work is currently underway in CARIN and in coordination with HL7 Da Vinci PDex workgroup to define this guidance. Comment: A commenter noted that a September 2021 Frequently Asked Questions (FAQ) 187 document published by CMS states that payers would be compliant with the Patient Access API requirements if they used the CMS-recommended IG (CARIN for Blue Button IG v1.1.0: STU 1) to build their APIs, but that that IG version does not enable the inclusion of dental or vision claims, which were added in the most recent version. Multiple commenters supported guidance or rulemaking to support oral and vision claims using the CARIN IG for Blue Button v2.0.0: STU 2 version. A commenter recommended that CMS reaffirm that impacted payers would be compliant with the requirements for the Patient Access and Provider Access, and Payer-to-Payer APIs if they follow the CMS recommended IGs. The commenter also recommended that CMS further explain that the absence of dental and vision claims information in the proposed APIs would not result in payer noncompliance given that the recommended CARIN IG for Blue Button does not include dental and vision claims. Response: At the time the proposed rule was drafted, the CARIN IG for Blue Button v1.1.0: STU 1 was the latest published version for use. Since then, CARIN IG for Blue Button v2.0.0: STU 2 was released, which indeed includes dental and vision (vision as part of the professional and non-clinician profile). We are therefore modifying our recommendation listed in Table H3 to 187 Health Informatics and Interoperability Group (2021). Patient Access API FAQ. Retrieved from https://www.cms.gov/priorities/key-initiatives/ burden-reduction/faqs/patient-access-api. PO 00000 Frm 00184 Fmt 4701 Sfmt 4700 ‘‘HL7 FHIR Consumer Directed Payer Data Exchange (CARIN IG for Blue Button) IG v2.0.0: STU 2.’’ In addition to the required standards listed in Table H3, if impacted payers use the recommended IGs also listed in Table H3 for the APIs and follow the IGs to specification to build their APIs, they would be conformant with the technical requirements. Comment: A commenter expressed support for exchanging data via FHIR APIs and noted that the PDex IG STU 2.0.0 includes a prior authorization profile to share prior authorization information, but this profile is not yet published. However, another commenter noted that the HL7 Da Vinci PDex workgroup is actively completing an initial set of updates to the PDex IG to facilitate sharing prior authorization information and that the workgroup will make any necessary revisions to support the provisions outlined in the proposed rule to include any related administrative and clinical documentation. Another commenter was concerned that some of the proposed data elements for prior authorization have not yet been profiled within FHIR IGs. A commenter stated that payers should already have familiarity with the PDex IG as it was recommended as part of the Patient Access API. The commenter continued that using the PDex IG to support the new set of information will also reduce burden. Response: The recently published PDex IG STU 2.0.0 specification 188 does include a Prior Authorization profile that enables payers to communicate prior authorization decisions and changes to the status of a prior authorization requests. Based on feedback and developments in the industry, in addition to the required IGs and previously recommended IGs, we are now recommending the PDex IG STU 2.0.0. for the Patient Access, Provider Access, and Payer-to-Payer APIs, as listed in Table H3. We are delaying the compliance dates for the APIs finalized in this rule to 2027, which allows for additional time for the FHIR standard and IGs to continue to be refined and advanced to support all of the policies in this final rule. Comment: A commenter noted that the proposed rule suggested that the Provider Directory API finalized in the CMS Interoperability and Patient Access final rule will be conformant with the PDex Plan Net IG STU 1.1.0. A commenter stated their belief in 188 Health Level Seven International (2020). Da Vinci Payer Data Exchange. Retrieved from https:// hl7.org/fhir/us/davinci-pdex/STU1/. E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations standards-based methods for the electronic transmission of health information. The commenter continued that successful standards-based conveyance of digital health care information relies on clear and unambiguous standards that apply across the industry. The commenter stated that the PDex Plan Net IG meets this requirement. Response: We agree with commenters on the utility of the PDex Plan Net IG, and are thus recommending its use for the Provider Directory API. Comment: Multiple commenters recommended CMS and HL7 ensure the CRD, DTR, and PAS IGs are fully tested prior to the effective date of the final rule, as the IGs have not been adequately or widely tested in real-time clinical settings. A commenter expressed concern with required versus situational data elements in the current versions of the recommended IGs outlined in the proposed rule. The commenter noted that the CRD, DTR, and PAS IGs have data elements and processes that are listed as optional despite their utility for automation. Another commenter provided the example that the CRD IG does not require the return of documentation templates and rules, so the provider would be required to initiate a separate transaction to determine the requirements for a prior authorization. Additionally, this commenter stated that the CRD IG allows for hyperlinks to be returned to the provider. The commenter stated that this means that a valid response to a coverage requirements discovery request can be a hyperlink to a third-party prior authorization vendor where the provider would have to initiate a prior authorization request through a provider portal and drop to a manual process outside of their EHR and practice management system. Response: The HL7 Da Vinci IGs that we recommend specifically for the Prior Authorization API are the CRD, DTR, and PAS IGs. These were created as three distinct IGs that were loosely coupled instead of created as a single IG in order to provide implementation flexibility and the ability to disconnect the processes where necessary. A number of optional or ‘‘situational’’ elements are included in these guides to connect them into a single workflow where needed. While we value the specificity of other comments regarding the functions of the IGs, such as hyperlinks and connecting to external portals, these are the purview of the HL7 Implementation division. We will work with HL7 and implementers to VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 coordinate appropriate support for such questions prior to the compliance dates. Comment: A commenter stated that it was their understanding that the HL7 Da Vinci PCDE IG was developed with minimal payer input. The commenter stated that there may be a need for additional time for impacted payers to understand and implement the IG. Furthermore, the commenter expressed concern that the PCDE IG only addresses the movement of data between the provider and payer and does not address the back-end systems that will need to ingest and process new information for continuity of care. The commenter urged CMS to continue exploring other opportunities to promote data exchange. The commenter acknowledged that there are many industry solutions being developed to facilitate the coordination of benefits between providers. The commenter stated that these options could prove to be better solutions for the industry in the future and recommended that CMS continue to monitor and enable technical innovation in this area. A commenter noted that CMS has included two mentions of the PCDE IG. They stated that there is one reference in the preamble of the proposed rule (87 FR 76336); however, in the preamble ‘‘Payer Coverage Decision Exchange’’ is followed by a parenthetical reference to ‘‘PDex.’’ The commenter stated that the PCDE IG was also listed in Table 10 (87 FR 76321), though, there are no additional or substantive mentions of the PCDE IG in the proposed rule. The commenter believes that it is possible the mention of the PCDE IG was unintentional. Response: We acknowledge that the PDex IG has expanded to include prior authorization data and development of PCDE IG is not currently active. Thus, while we acknowledge the drafting error the commenter previously noted, we are no longer recommending the PCDE IG for the Payer-to-Payer API. Comment: A commenter suggested that CMS consider recommending the HL7® FHIR® Member Attribution (ATR) List IG, which is currently in the publication process. The commenter stated this IG focuses on attribution lists for risk-based contracts and it could serve as an exchange standard for all payers. Response: While we did not include the ATR List IG as one of recommendations listed in Table H3, we note that industry expects that the next version will be published well before the compliance dates for API development and enhancement policies in this final rule. Payers are permitted to use the ATR List IG, and we will PO 00000 Frm 00185 Fmt 4701 Sfmt 4700 8941 explore including it, either as a recommendation or requirement, in future rulemaking. Comment: Multiple commenters recommended that CMS consider leveraging the HL7 FHIR Da Vinci Reducing Clinician Burden (RCB) IGs. A commenter shared that revisions to the RCB IGs are underway to make prior authorization documentation supporting medical necessity, which is assembled by the ordering provider, available to the performing provider. The updated IG is currently titled FHIR Orders Exchange (FOE), and updates should be balloted in the September 2023 SVAP cycle. Another commenter stated that they believe RCB IGs would help industry work towards future readiness for a certified Health IT Module(s) to be included within the ONC Health IT Certification Program. Response: We thank commenters for their suggestions and will consider them for future rulemaking. Comment: A commenter stated that the HL7® FHIR® Da Vinci Clinical Data Exchange (CDex) IG would enable providers to obtain additional information that may have been missing or not yet available on the initial order request. Response: Though we neither proposed nor recommended the CDex IG, we recognize that the CDex IG is being developed to exchange attachments via the Prior Authorization API. Impacted payers are permitted to use the CDex IG and are encouraged to participate in the ongoing testing as the IG is further developed. Though HL7 has included the ability to exchange attachments in its suite of IGs, and this would be available for use voluntarily, this final rule does not address health care attachments. We will consider either requiring or recommending the CDex IG in future rulemaking. Comment: A commenter recommended using the HL7 Da Vinci DTR IG to specify how payers codify their rules in clinical quality language for real-time determination. Response: We are currently recommending the DTR IG for the Prior Authorization API. We will continue to monitor and evaluate the development of the recommended IGs listed in Table H3 and consider whether to propose them as a requirement at some future date. c. Authentication and Authorization Comment: Multiple commenters encouraged CMS to work with HL7 to integrate the UDAP into the IGs created by HL7. A commenter stated that a security framework based on a tiered OAuth security specification is required E:\FR\FM\08FER2.SGM 08FER2 8942 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations lotter on DSK11XQN23PROD with RULES2 to enable the scalable exchange within trust frameworks. The commenter stated that industry will not be able to implement at scale based on how the standards were proposed and suggested CMS focus on making sure this work is in place prior to making the APIs in the proposed rule mandatory. In addition, the commenter stated that the HL7 Da Vinci PDex IG depends on mTLS to establish the identity of each of the organizations involved in the exchange while other payer-to-provider and payer-to-patient exchanges rely on OAuth and the SMART framework. Response: We thank the commenters for their responses and understand their concerns. As discussed in section II.B. of this final rule, we are currently supporting efforts to define the specifications for authentication at scale through UDAP via the FAST Security IG and mTLS through the PDex IG. We acknowledge that authentication and authorization via user credentials, using means such as OpenID Connect Core and OAuth 2.0, is a requirement for APIs in which individually identifiable user access is necessary, such as the Patient Access API. In order to use OpenID Connect Core, each user would need to have credentials with the payer (or delegated authentication/ authorization entity) to access the API. Thus, we are maintaining OpenID Connect Core 1.0 as a required standard for the Patient Access API. We recognize that while protocols involving specific user credentials as managed by a payer could be used for the Provider Access and Prior Authorization APIs, other protocols, such as SMART Backend Services, mTLS, UDAP, or other trust communityspecified means, may be easier to VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 implement at scale. Likewise, protocols requiring user level credentials, managed by the payer, are generally not appropriate for business-to-business data exchanges like the Payer-to-Payer API where an individual may not be directly initiating the exchange. Therefore, upon further consideration of our proposals, we are not finalizing OpenID Connect Core (at 45 CFR 170.215(b)) as either a required or recommended standard for the Provider Access, Payer-to-Payer, and Prior Authorization APIs. We are recommending SMART Backend Services Authorization for both the Provider Access and the Payer-toPayer APIs. However, payers will be able to choose the protocols or combination of protocols they deem appropriate as long as they meet appropriate security and privacy requirements. We acknowledge that payers will likely use different protocols, which could represent a barrier to enabling data exchange at scale. Specifications such as UDAP and the tiered OAuth profile is an available option for payers and may enable data exchange in a scalable way by providing dynamic client registration and delegated authentication potentially within and across trust communities. We appreciate the comments, will continue to monitor the progress of UDAP development and implementation, and will consider including it in future rulemaking. Comment: A commenter stated that the HL7® FHIR® Da Vinci Health Record Exchange (HRex) IG Coverage Profile allows for UDAP, which may be viable solution for authentication. The commenter stated that the HL7 FAST STU 1 Security IG should be considered PO 00000 Frm 00186 Fmt 4701 Sfmt 4700 foundational in the future for all IGs that require registration, authentication, and authorization. Additionally, the commenter suggested that CMS should explain that requiring handwritten signatures continues to be appropriate when the impacted payer deems it necessary. The commenter recommended that CMS should support industry discussions and actions toward UDAP alignment across IGs, when and where appropriate. Response: We recognize that methods including, but not limited to UDAP, may be appropriate depending on the payer’s specific needs and the API. We believe that appropriate security controls can be implemented without requiring handwritten signatures, unless required by other applicable law. We continue to monitor the progress of IG development and remind readers that this final rule does not restrict payers from using other IGs (assuming they are not an earlier version than we specify). We will continue to monitor IG development and consider requiring or recommending additional IGs in future rulemaking. 4. Required Standards and Recommended Implementation Guides To Support APIs Using standards and IGs supports consistent implementations across the industry. In Table H1 of this final rule, we list the CFR citations that require impacted payers to use API technology conformant with the standards and specifications outlined in this section of the rule. We also include Table H3 to provide a clear outline of which standards we require and which IGs we recommend for each API. BILLING CODE 4150–01–P E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 VerDate Sep<11>2014 Jkt 262001 PO 00000 II.G.2. Frm 00187 II.G.2. I I Fmt 4701 Sfmt 4725 E:\FR\FM\08FER2.SGM II.G.2. I II.G.2. I II.G.2. I 08FER2 Patient Access API (Effective date of the final rule) Provider Access API (Compliance date January 1, 2027) Provider Directory API (Effective date of the final rule) Payer-to-Payer API (Compliance data January 1, 2027) Prior Authorization API (Compliance date January 1, 2027 42 CFR422.119(c)(l) 42 CFR 422.12l(a)(l) Through cross reference to 42 CFR422.119(c) at 42 CFR 422.120(a) 42 CFR 422.121(b)(l) 42 CFR 422.122(b) 42 CFR 431.60(c)(l) 42CFR 431.61(a)(l) Through cross reference to 42 CFR 431.60 at 42 CFR 438.242(b)(5) Through cross reference to 42 CFR 431.61(a) at 42 CFR 438.242(b )(7) Through cross reference to 42 CFR 431.60( c) at 42 CFR 431.70(a) 42CFR 431.61(b)(l) Through cross reference to 42 CFR 431.70 at 42 CFR 438.242(b)(6) Through cross reference to 42 CFR 431.61(b)(l) at 42 CFR 438.242(b)(7) 42 CFR 431.80(b) Through cross reference to 42 CFR 431.80(b) at 42 CFR 438.242(b )(7) 42 CFR 457.730(c)(l) Through existing cross reference to 42 CFR 438.242 at 42CFR 457.1233(d) 42CFR 457.731(a)(l) Through cross reference to 42 CFR 457.730(c) at 42 CFR457.760(a 42CFR 457.731(b)(l) I 42 CFR 457.732(b) I I I 1 45 CFR 156.221(c)(l) 1 45 CFR 156.222(a)(l) IN/A 1 45 CFR 156.222(b)(l) I 45 CFR 156.223(b) Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations 18:23 Feb 07, 2024 TABLE Hl: USE OF INTEROPERABILITY STANDARDS FOR REQUIRED APis 8943 ER08FE24.011</GPH> lotter on DSK11XQN23PROD with RULES2 8944 VerDate Sep<11>2014 I PO 00000 II.G.2. I II.G.2. I II.G.2. I Frm 00188 Jkt 262001 II.G.2. Fmt 4701 Sfmt 4725 E:\FR\FM\08FER2.SGM 08FER2 ER08FE24.012</GPH> Patient Access API (Effective date of the final rule) Provider Access API (Compliance date January 1, 2027) 42CFR 422.l 19(c)(4) Through cross reference to 42 CFR 422.l 19(c)(4) at 42CFR 422.12l(a)(l) Provider Through cross Directory API reference to 42 (Effective date of CFR the final rule) 422.119(c)(4) at 42CFR 422.120(a) Payer-to-Payer Through cross API reference to 42 (Compliance date CFR January I, 2027) 422.l 19(c)(4) at 42CFR 422.12l(b)(l) Through cross reference to 42 CFR 431.60 at 42 CFR 438.242(b)(5) Through cross reference to 42 CFR 43 l.6l(a) at 42 CFR 438.242(b)(7) Through cross reference to 42 CFR 457.730(c)(4) at42 CFR 457.73 l(a)(l) Through cross reference to 42 CFR 43 l.60(c)(4) at42 CFR 43 l.70(a) Through cross reference to 42 CFR 431. 70 at 42 CFR 438.242(b)(6) Through cross reference to 42 CFR 457.730(c)(4) at42 CFR 457.760(a) Through cross reference to 42 CFR 43 l.60(c)(4) at42 CFR 431.6l(b)(l) Through cross reference to 42 CFR 431.6l(b)(l) at 42 CFR 438.242(b)(7) Through cross reference to 42 CFR 457.730(c)(4) at42 CFR 457.73 l(b)(l) Through cross reference to 45 CFR 156.22l(c)(4) at 45 CFR 156.222(b)(l) Through cross reference to 42 CFR 43 l.60(c)(4) at42 CFR 43 l.80(b) Through cross reference to 42 CFR 43 l.80(b) at 42 CFR 438.242(b )(7) Through cross reference to 42 CFR 457.730(c)(4) at42 CFR 457.732(b) Through cross reference to 45 CFR 156.22l(c)(4) at 45 CFR 156.223(b) 42 CFR 43 l.60(c)(4) Through cross reference to 42 CFR 43 l.60(c)(4) at42 CFR 431.6l(a)(l) 42 CFR457.730(c)(4) Through existing cross 45 CFR 156.22l(c)(4) reference to 42 CFR 438.242 at 42 CFR 457.1233(d) Through cross reference to 45 CFR 156.22l(c)(4) at 45 CFR 156.222(a)(l) I I INIA I II.G.2. I Prior Authorization API (Compliance date January I, 2027) Through cross reference to 42 CFR 422.l 19(c)(4) at 42CFR 422.122(b Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations 18:23 Feb 07, 2024 TABLE H2: USE OF UPDATED STANDARDS FOR THE REQUIRED APis Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations 8945 TABLE H3: REQUIRED STANDARDS AND RECOMMENDED IMPLEMENTATION GUIDES TO SUPPORT API IMPLEMENTATION API Patient Access API Required Standards* 45 CFR l 70.215(a)(l) HL7 FHIR Release 4.0.1 45 CFR l 70.215(b)(l)(i) HL7 FHIR US Core IG STU 3.1.1.*** 45 CFR 170.215(c)(l) HL7 SMART Application Launch Framework IG Release 1.0.0. *** 45 CFR l 70.215(e)(l) OpenlD Connect Core 1.0, incorporating errata set 1 Provider Access API 45 CFR l 70.215(a)(l) HL7 FHIR Release 4.0.1 45 CFR l 70.215(b)(l)(i) HL7 FHIR US Core IG STU 3.1.1.*** 45 CFR 170.215(c)(l) HL7 SMART Application Launch Framework IG Release 1.0.0. *** 45 CFR l 70.215(d)(l) FHIR Bulk Data Access (Flat FHIR) IG (vl.0.0: STU 1) Provider Directory API** 45 CFR l 70.215(a)(l) HL7 FHIR Release 4.0.1 Payer-to-Payer API 45 CFR l 70.215(a)(l) HL7 FHIR Release 4.0.l 45 CFR l 70.215(b)(l)(i) HL7 FHIR US CoreIG STU 3.1.1.*** 45 CFR l 70.215(b)(l)(i) HL7 FHIR US Core IG STU 3.1.1.*** 45 CFR l 70.215(d)(l) FHIR Bulk Data Access (Flat FHIR) IG (vl.0.0: STU 1) Prior Authorization API 45 CFR l 70.215(a)(l) HL7 FHIR Release 4.0.l 45 CFR 170.215(b)(1 )(i) HL 7 FHIR US Core JG STU 3.1.1.*** 45 CFR 170.215(c)(l) HL7 SMART Application Launch Framework IG Release 1.0.0. *** Recommended Implementation Guides HL 7 FHIR CARIN Consumer Directed Payer Data Exchange (CARIN 1G for Blue Button®) IG STU 2.0.0. URL: htm ://hl7 .org/fhir/us/carin-bb/histon:.html. HL 7 FHIR Da Vinci Payer Data Exchange (PDex) IG STU 2.0.0. URL: htm:/1h17 .org{fhir/us/davinci-ndex/histon:.htm I. HL 7 FHIR Da Vinci - Payer Data Exchange (PDex) US Drug Formulary IG STU 2.0.1. URL: htm://hl7.org{thir/us/Davincidrug-formulan:/histon:.html. HL 7 FHIR CARIN Consumer Directed Payer Data Exchange (CARIN 1G for Blue Button®) IG STU 2.0.0. URL: h!tQ ://hl7 .org/thir/us/carin-bb/histon:.html. HL 7 FHIR Da Vinci Payer Data Exchange (PDex) 1G STU 2.0.0. URL: htto://hl7 .org/thir/us/davinci-ndex/histon:.html. 45 CFR l 70.215(c)(2) HL 7 SMART App Launch IG, Release 2.0.0 to support Backend Services Authorization. URL: htms ://hl7 .org/thir/smart-aill:l-launch/STU2/backendservices.hotml HL 7 FHIR Da Vinci Payer Data Exchange (PDex) Plan Net 1G STU 1.1.0. URL: htt12://www.hl7.org/thir/us/davinci-12dex-12lannet/histon:,html. HL 7 FHIR Consumer Directed Payer Data Exchange (CARIN IG for Blue Button®) 1G STU 2.0.0. URL: htm :/1h17 .org/fhir/us/carin-bb/histon:.html. HL 7 FHIR Da Vinci Payer Data Exchange (PDex) 1G STU 2.0.0. URL: htm://hl7 .org/thir/us/davinci-ndex/histon:.html. 45 CFR 170.215(c)(2) HL7 SMART App Launch IG, Release 2.0.0 to support Backend Services Authorization. URL: https://hl7.org/thir/smart-aoo-launch/STU2/backend-services.html HL 7 FHIR Da Vinci - Coverage Requirements Discovery (CRD) JG STU 2.0.1. URL: httrJ://hl7 .org{fhir/us/davincicrd/histon:,htm I. HL 7 FHIR Da Vinci - Documentation Templates and Rules (DTR) IG STU 2.0.0. URL: httn://hl7.org/fhir/us/davinci-dtr/histoa.html. *We have made modifications to the required standards listed in this table from what was originally listed in Table 10 of the CMS Interoperability and Prior Authorization proposed rule (87 FR 76320). **We have removed the references to 45 CFR 170.215(c) SMART App Launch JG and 45 CFR 170.215(e) OpenTD Connect Core for the Provider Directory API that were mistakenly included in the proposed rule. Security protocols related to user authentication and authorization are excluded from the requirements for the Provider Directory APT (for MA organizations at 42 CFR 422.120 (a), for Medicaid at 42 CFR 43 l.70(a), and for CHIP at 42 CFR 457.760(a)). For more information see the discussion in the CMS Interoperability and Patient Access final rule at 85 FR 25560. *** In the HTI-1 final rule, ONC finalized expiration dates for several of these required standards to indicate when a version of a standard may no longer be used (89 FR 1192). We intend to align with updated versions finalized at 45 CFR 170.215 through future rulemaking prior to the API compliance dates. BILLING CODE 4150–01–C VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 PO 00000 Frm 00189 Fmt 4701 Sfmt 4700 E:\FR\FM\08FER2.SGM 08FER2 ER08FE24.013</GPH> lotter on DSK11XQN23PROD with RULES2 HL7 FHIR Da Vinci Prior Authorization Support (PAS) JG STU 2.0.1. URL: httn://hl7 .orn/fhir/us/davinci-nas/historv .html. 8946 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations 5. Final Action After considering the comments received, and for the reasons discussed in the CMS Interoperability and Prior Authorization proposed rule (87 FR 76238) and our response to those comments (as summarized previously), we are finalizing our proposals regarding interoperability standards for the Patient Access, Provider Access, Provider Directory, Payer-to-Payer, and Prior Authorization APIs. We are finalizing greater specificity for the standards at 45 CFR 170.215 that are applicable to each API, with some modifications. Specifically, impacted payers will only be required to use the applicable standards and specifications that we have identified as necessary for the Patient Access, Provider Access, Provider Directory, Payer-to-Payer, and Prior Authorization APIs. Those standards are listed as ‘‘required’’ in Table H3. We are also finalizing a modification to incorporate the expiration dates ONC adopted at 45 CFR 170.215(b)(1)(i) and (c)(1) since the CMS Interoperability and Prior Authorization proposed rule was published. We are finalizing our proposal to allow impacted payers to use updated standards, specifications, or IGs for each of these APIs, under the following conditions: the updated version of the standard is required by other applicable law; or (1) the updated version of the standard is not prohibited under other applicable law, (2) the National Coordinator has approved the updated version for use in the ONC Health IT Certification Program, and (3) the updated version does not disrupt an end user’s ability to access the data required to be available through the API. We note that for the required standards at 45 CFR 170.215, several updated versions have been approved by the National Coordinator for use in the ONC Health IT Certification Program,189 including, lotter on DSK11XQN23PROD with RULES2 189 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. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 but not limited to, the US Core IG STU 6.1.0, the SMART App Launch IG Release 2.0.0, and the Bulk Data Access IG (v2.0.0: STU 2). Finally, we are recommending specific IGs, listed as ‘‘recommended’’ in Table H3, which we encourage payers to use in addition to the required standards at 45 CFR 170.215. III. Collection of Information Requirements Under the Paperwork Reduction Act (PRA) of 1995, we are required to provide 60-day notice in the Federal Register and solicit public comment before a collection of information requirement is submitted to the OMB for review and approval. To fairly evaluate whether an information collection should be approved by OMB, section 3506(c)(2)(A) of the PRA of 1995 requires that we solicit comment on the following issues: • The need for information collection and its usefulness in carrying out the proper functions of our agency. • The accuracy of our estimate of the information collection burden. • The quality, utility, and clarity of the information to be collected. • Recommendations to minimize the information collection burden on the affected public, including automated collection techniques. We requested public comment on areas of this document that contain information collection requirements (ICRs). A. Background Payers and providers should be able to take advantage of new technologies that improve their ability to exchange information efficiently, enhance operations, and streamline processes to benefit patient care. Payers should share prior authorization rules in more transparent ways to enable providers to meet their requirements, and thereby, avoid care delays. To continue advancements in our commitment to interoperability, we are finalizing our proposals for certain impacted payers to implement FHIR APIs and make other PO 00000 Frm 00190 Fmt 4701 Sfmt 4700 process improvements to help streamline prior authorizations and improve data exchange between payers, providers, and patients. Impacted payers will be required to report metrics for the information about how often patients use the Patient Access API and about prior authorization processes to assess implementation of our policies. The final rule includes provisions that will reduce the amount of time to process prior authorization requests and improvements for communications about denied prior authorizations. Combined, these provisions should reduce the burden on providers, payers, and patients and enhance patient care coordination. To incentivize provider use of the Prior Authorization API, we are finalizing a policy to add a new measure for MIPS eligible clinicians under the MIPS Promoting Interoperability performance category and for eligible hospitals and CAHs under the Medicare Promoting Interoperability Program. Beginning with the CY 2027 performance period/2029 MIPS payment year (rather than the CY 2026 performance period/2028 MIPS payment year), we are finalizing this measure as an attestation (yes/no response); we intend to propose a scoring methodology for the measure in future rulemaking. This new measure will be included in a PRA package related to this final rule. B. Wage Estimates To derive average costs, we used data from the U.S. Bureau of Labor (BLS) Statistics’ National Occupational Employment and Wage Estimates 190 and aligned our analysis with other CMS regulatory actions. Table J1 presents the mean hourly wage, the cost of fringe benefits and overhead (calculated at 100 percent of salary), and the adjusted hourly wage. 190 U.S. Bureau of Labor Statistics (2021, March 31). May 2020 National Occupational Employment and Wage Estimates. Retrieved from https:// www.bls.gov/oes/2020/may/oes_nat.htm. E:\FR\FM\08FER2.SGM 08FER2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations 8947 TABLE Jl: HOURLY WAGE ESTIMATES 13-1000 $37.66 $37.66 $75.32 Clerical Office and Administrative Su 43-3000 $20.38 $20.38 $40.76 Com uter and Information Anal sts 15-1210 $48.40 $48.40 $96.80 Com uter and Information S stems Mana ers 11-3021 $77.76 $77.76 $155.52 Com uter S stems Anal sts 15-1211 $47.61 $47.61 $95.22 Database Administrators and Architects 15-1245 $48.60 $48.60 $97.20 Desi ners, All Other 27-1029 $34.30 $34.30 $68.60 En ineers, All Other 17-2199 $51.47 $51.47 $102.94 General and O erations Mana ers 11-1021 $60.45 $60.45 $120.90 Medical Records S ecialists 29-2098* $23.21 $23.21 $46.42 Re istered Nurses 29-1141 $38.47 $38.47 $76.94 0 erations Research Anal sts 15-2031 $44.37 $44.37 $88.74 Ph sicians, All Other 29-1228 $105.22 $105.22 $210.44 Software and Web Develo ers 15-1250 $52.86 $52.86 $105.72 Technical Writers 27-3042 $37.78 $37.78 $75.56 *Table J1 reports mean hourly wages. For Medical Record Specialists, the median wage is $21.20 ($42.40 when multiplied by two to reflect fringe benefits and overhead). This median will be used in ICR #8 to provide an alternate aggregate estimate, which, after rounding, does not differ from the estimate using the mean. C. Information Collection Requirements Consistent with our approach in the CMS Interoperability and Patient Access final rule (85 FR 25622), we determined ICRs by evaluating cost and burden at the impacted payer level. We determined that 365 impacted payers together represent the possible plans, entities, issuers, and state programs impacted by these proposals. The increase in impacted payers from the first CMS Interoperability and Patient Access final rule (85 FR 25510) corresponds to the average annual increase in impacted payers for new market entries. The total estimated burden on these impacted payers is described in detail in the following ICRs and Table J9 at the end of this section. We estimated the total number of burden hours across all impacted payers in the first year of implementation at 6.9 million hours; assuming a total cost to impacted payers to begin at approximately $182 million in the first and second years, increasing to $199 million in the third year and decreasing VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 to $142 million by the fourth and subsequent years. We requested comments on each ICR described in the proposed rule (87 FR 76330), and on the assumptions made in deriving these burden estimates. We received a few comments on the burden of the proposals and acknowledge those comments with responses later in this section. Since we did not receive specific data to include to modify estimates, no revisions have been made. 1. Information Collection Requirements Regarding Reporting of Patient Access API Metrics to the Centers for Medicare and Medicaid Services (42 CFR 422.119, 431.60, 438.242, 457.730, and 457.1233 and 45 CFR 156.221) CMS does not currently collect data on using the Patient Access API and does not have industry data on the extent to which patients are requesting to download their data from their payer into an app. We are finalizing the requirement that impacted payers annually report certain metrics to CMS about usage of the Patient Access API. Specifically, we will collect the total number of unique patients whose data are transferred via the Patient Access API to a health app designated by the patient; and the total number of unique patients whose data are transferred more than once via the Patient Access API to a health app designated by the patient. We estimate that impacted payers will conduct two major work phases: (1) PO 00000 Frm 00191 Fmt 4701 Sfmt 4700 implementation, which includes defining requirements and system design to generate and compile reports; and (2) maintenance, which we define as including the compilation and transmission of annual reports to CMS. During the implementation phase, impacted payers will need to prepare their systems to capture the data to be transmitted to CMS. The burden estimate related to the requirements reflects the time and effort needed to identify, collect, and disclose the information. The costs include an initial set of one-time costs associated with implementing the reporting infrastructure and ongoing annual maintenance costs to report after the reporting infrastructure has been established. Table J2 includes our computational estimates for first-year implementation and ongoing maintenance costs and was used to develop the official statement of burden found in Table J9. In finalizing these calculations, we assumed a twoperson team of software/web developers and a business operations specialist spending an aggregate of 160 and 40 hours, respectively, for the first and subsequent years, at a total cost per impacted payer (rounded) of $15,000 and $3,000. The aggregate burden (rounded) for 365 impacted payers will be 60,000 hours and 15,000 hours for the first and subsequent years at a cost of $5.5 million and $1 million. E:\FR\FM\08FER2.SGM 08FER2 ER08FE24.014</GPH> lotter on DSK11XQN23PROD with RULES2 We adjusted the employee hourly wage estimates by a factor of 100 percent or doubling of the BLS wage estimates. This is a rough adjustment because fringe benefits and overhead costs vary significantly across employers based on the age of employees, location, years of employment, education, vocations, and other factors. 8948 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations TABLE J2: AGGREGATE BURDEN FOR COMPLYING WITH THE PATIENT ACCESS API REPORTING REQUIREMENTS We did not receive comments specific to the estimates for the Patient Access API metrics reporting. lotter on DSK11XQN23PROD with RULES2 2. Information Collection Requirements Regarding the Provider Access API (42 CFR 422.121, 431.61, 438.242, 457.731, and 457.1233 and 45 CFR 156.221) Research shows that patients achieve better outcomes when their medical records are more complete and there are more data available to the health care provider at the point of care.192 Making comprehensive information available to providers could thus improve the care experience for patients. Ensuring that providers have access to relevant patient data could also reduce the burden on patients to recall and relay information during an appointment and provide confirmation that the patient’s recollection of prior care is accurate. This has not always been possible in a disconnected health care system. However, interoperable standards and technology now make it possible for providers to access more patient data for a more comprehensive view of their patients’ health history and status. We are finalizing the Provider Access API requirements as described in section II.B.2. of this final rule which permits providers to receive standardized patient data to coordinate care. Cost estimates for this API were developed based on the methodology finalized in the CMS Interoperability and Patient Access final rule (85 FR 25510). In that rule, we estimated that impacted payers would conduct three major work phases: initial design, development and testing, and long-term support and maintenance (85 FR 25605). In this final rule, we assume the same major phases of work will take place for each of the 191 U.S. Bureau of Labor Statistics (2021, March 31). May 2020 National Occupational Employment and Wage Estimates. Retrieved from https:// www.bls.gov/oes/2020/may/oes_nat.htm. 192 Office of the National Coordinator for Health Information Technology (2019, June 4). Improved Diagnostics & Patient Outcomes. Retrieved from https://www.healthit.gov/topic/health-it-basics/ improved-diagnostics-patient-outcomes. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 new APIs, with a different level of effort during each work phase. In the initial design phase, tasks include determining available resources (for example, personnel, hardware, cloud storage space, etc.), assessing whether to use in-house or contracted resources to facilitate an API connection, convening a team to scope, build, test, and maintain the API, gap analysis, and gap mitigation. During the development and testing phase, impacted payers will conduct mapping of existing data to the FHIR standards, hardware allocation for the necessary environments (development, testing, production), building a new FHIR-based server or leveraging existing FHIR servers, determining the frequency and method by which internal data are populated on the FHIR server, building connections between the databases and the FHIR server, performing capability and security testing, and vetting provider requests. Table J3 summarizes the aggregate burden for complying with the Provider Access API requirements. We provide illustrative points to explain the calculations within the table and the terms used for the headings. The occupational categories on the left side of the table include the titles of the types of labor categories who will perform the work, for example, Database Administrators and Architects, Engineers, and Computer System Analysts. On the top row, under the label ‘‘Database Administrators,’’ the labor cost of $97.20 per hour was obtained from the BLS. The $97.20 represents the mean wage for this occupational title. The calculations in Table J3 reflect time over the period of the project. We estimate that a Database Administrator might spend 480 hours in total to complete this task. The 480 hours are found in the column titled ‘‘Primary Hours.’’ The word primary, as used in the CMS Interoperability and Patient Access final rule (85 FR 25510), refers to the amount of time most PO 00000 Frm 00192 Fmt 4701 Sfmt 4700 organizations would require for this work. The total cost of $46,656 for each organization is obtained by multiplying the 480 hours by the $97.20 per hour wage. This $46,656 is found in the column labeled ‘‘Total Cost, Primary.’’ We provide low and high estimates representing a range of possible time and costs across all organizations. The low estimate is half the primary estimate, which is 240 hours. The high estimate is 720 hours. These numbers are found in the low and high columns (hours) of the top row. The corresponding low and high costs are obtained by multiplying the low and high estimates of hours by the $97.20 per hour wage. This is a reasonable range that captures the amount of time and cost all organizations may spend on completing this work. The explanation provided for the top row applies to each of the ten occupational titles. The sum of the total hours and costs provides a typical organization’s total cost. This number is found in the ‘‘Totals for a Single Impacted Payer’’ row. As depicted, the typical organization might take a total of 2,800 hours at a cost of $270,045. We estimate the impact by organization rather than by payer since many organizations may have entities in several of the programs to which this final rule applies: MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs. To arrive at the total cost of the final rule, we multiplied the single organization cost by 365 payers—that is, the number of organizations hosting plans across the programs. For example, the total primary hourly burden of the rule is 1,022,000 (365 organizations × 2,800 for a single organization). Similar to the methodology used in the CMS Interoperability and Patient Access final rule (85 FR 25510), we estimate maintenance costs for future years after the API is established at 25 percent of the aggregate cost. We arrived E:\FR\FM\08FER2.SGM 08FER2 ER08FE24.015</GPH> *This table contains computations used for creating Table J9; they are not definitive statements of burden. Table J9 is the official collection of information statement of burden, including the number ofrespondents and responses. Please see the BLS for the wage estimates used. 191 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations at 25 percent based on our experience with the industry. Rather than list more columns or create another table, we provide a footnote indicating that maintenance is estimated to be 25 percent of the cost. For example, the primary aggregate burden over all 365 organizations is $98.6 million, implying 8949 that the annual maintenance costs are expected to be $24.6 million (25 percent × $98.6 million). TABLE J3: AGGREGATE BURDEN FOR COMPLYING WITH THE PROVIDER ACCESS API REQUIREMENTS *Estimated burden is the total burden of implementation. The burden is apportioned over 36 months in Table J9. Annual maintenance costs are 25 percent of total implementation costs. The timefrarne of36 months represents the lag between the publication of the final rule and the compliance date for the APl of January I, 2027. *This table contains preparatory computations used for creating Table J9; they are not definitive statements of burden. Table J9 is the officiaJ COi statement of burden, including the number ofrespondents and responses. This is the same format used in the CMS Interoperability and Patient Access final rule. Although compliance with this provision will be required on January 1, 2027, we believe it is reasonable to assume that this API will have to be under development before this date to conduct testing and ensure compliance. Acknowledging that impacted payers will have varying technological and staffing capabilities, as we did in the first CMS Interoperability and Patient Access final rule (85 FR 25606), we are finalizing our estimate that the development of this API will require 1,400 to 4,200 hours of work. We have distributed the cost over 3 calendar years to give impacted payers the flexibility to complete the necessary work (see Table J9). Comment: A few commenters disagreed with CMS’s calculations for the total burden regarding hours and costs across all impacted payers and stated that the estimates are significantly understated. These commenters stated that they were not confident that the proposed rule captured the true cost of transitioning to the technical standards. Response: We acknowledge comments about our calculations capturing the costs of transitioning to the technical standards, however, the commenters who made these statements did not include any supporting data which we could analyze or include in the final rule. We are aware of and have included available information in our estimates and analysis to address connections, testing, security, and onboarding of third parties, to accommodate the potential costs and burden for each API VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 implementation. Additionally, we believe our estimates are the best possible, without additional information, and reasonable assumptions of staff and time, with ranges to account for low and high costs. We welcome continued input from payers and developers based on implementation of the Patient Access and Provider Directory APIs from the CMS Interoperability and Patient Access final rule, as well as the requirements finalized in this final rule. Such information will also be informative for purposes of future rulemaking. Comment: A commenter noted that it is unrealistic for CMS to expect that the industry can obtain the resources necessary to comply with the provisions outlined in the proposed rule within the current budget year when the requirements will not be finalized until the final rule is issued. The commenter recommended that CMS revise the compliance dates of these provisions to be 36 months after issuance of the final rule and scheduled on a date other than the end of a calendar year. Response: We have acknowledged the constraints on both budget cycles for certain impacted payers such as state Medicaid and CHIP agencies, as well as the technical complexities of implementation, and are finalizing a compliance date in 2027 for policies in this final rule that require API development or enhancement. As explicitly noted previously, the hours of work needed to build the API as indicated in Table J3, acknowledges that PO 00000 Frm 00193 Fmt 4701 Sfmt 4700 impacted payers will have varying technological and staffing capabilities. a. API Maintenance Costs—All APIs The third phase for implementation is long-term support and maintenance. Here we discuss our methodology for the development of the costs in aggregate for all APIs outlined in this final rule. As relevant to the APIs discussed in sections III.C.2., 3., and 6. of this final rule, we estimate ongoing maintenance costs for the Provider Access, Payer-to-Payer, and Prior Authorization APIs, in aggregate. The costs of the API development are split into three phases: initial design, development and testing, and long-term support and maintenance. We assume that maintenance costs only account for the cost associated with the technical requirements as outlined in this rule. Any changes to requirements would add burden, which would be discussed in future rulemaking. Throughout this section, we discuss the initial design, development, and testing costs per API. This final rule addresses the total maintenance cost for all three APIs. As discussed in the first CMS Interoperability and Patient Access final rule (85 FR 25606), once the API is established, there will be an annual cost to maintain the FHIR server, including the cost of maintaining the necessary patient data and performing capability and security testing. We believe there are efficiencies to be gained in implementation and maintenance since the APIs rely on several of the same underlying foundational technical E:\FR\FM\08FER2.SGM 08FER2 ER08FE24.016</GPH> lotter on DSK11XQN23PROD with RULES2 *Note: Table J3 (as other tables in this section) reflects calculations by spreadsheet; therefore, minor inconsistencies are due to rounding. 8950 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations specifications and content. For example, the same standards will be used to implement the new APIs as were used to implement the Patient Access and Provider Directory APIs, including FHIR and complementary security and app registration protocols. We also believe that maintenance costs will be higher than what we estimated for the CMS Interoperability and Patient Access final rule for the new APIs in this final rule, as our estimates also account for new data mapping needs, standards upgrades, additional data storage, system testing, initial bug fixes, fixedcost license renewals, contracting costs, and ongoing staff education and training. To account for these maintenance costs, we based our estimates on input from industry experience piloting and testing APIs for provider access, prior authorization, and payer to payer data exchange. We estimated an annual cost averaging approximately 25 percent of the primary estimate for one-time API costs. In Table J9, we account for this maintenance cost separately for each API (at 25 percent of the one-time API cost). As discussed previously, the overlap in some of the recommended IGs across the APIs should result in shared efficiency that we believe supports the assumption that maintenance should be accounted for in aggregate and is presented in this section as such. We requested public comment on our approach and assumptions for the aggregate maintenance cost of the APIs, including whether our estimate was reasonable or should be modified, and did not receive specific comments on the aggregate maintenance costs. lotter on DSK11XQN23PROD with RULES2 3. Information Collection Requirements Regarding the Prior Authorization API (42 CFR 422.122, 431.80, 438.242, 457.732, and 457.1233 and 45 CFR 156.223) This API addresses ongoing challenges of the prior authorization process, including identifying whether a prior authorization is required for an item or service; identifying the payer documentation requirements for prior authorization; compiling the necessary data elements to populate the HIPAAcompliant prior authorization transactions; and enabling payers to VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 provide a specific response regarding the status of the prior authorization, including information about the reason for denial. We are finalizing the requirement for impacted payers to implement and maintain a Prior Authorization API in this final rule. Use of the Prior Authorization API will begin 2027 (by January 1, 2027, for MA organizations and Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs). As discussed previously, with respect to the Provider Access API, we estimate that impacted payers will need to conduct three major work phases to implement the requirements for the Prior Authorization API: initial design, development and testing, and long-term support and maintenance. Furthermore, for the Prior Authorization API, additional tasks are necessary to accomplish the requirements. For the costs for the third phase—long-term support and maintenance—our methodology for the development of those costs in aggregate for all APIs is presented in section III.D. of this final rule. We based our estimate on feedback from industry experts on the anticipated burden of implementing the Prior Authorization API and on current pilots. We continue to believe the estimates to be reasonable regarding the implementation burdens on impacted payers to develop APIs that can facilitate the prior authorization process. In addition to implementing this API, impacted payers will be required to send a specific reason for prior authorization requests that are denied. As discussed in section II.D. of this final rule, while the Prior Authorization API will use the FHIR standard to support its basic capabilities, covered entities must also use the adopted X12 278 transaction standard and remain HIPAA-compliant. Given the added complexity of accounting for the HIPAA standards, we have accounted for the multiple skill sets required and licensing costs for accessing the X12 standards in developing the burden estimates. The recommended HL7 IGs are freely PO 00000 Frm 00194 Fmt 4701 Sfmt 4700 available, as HL7 provides access to all IGs as open-source materials. This makes the HL7 standards, IGs, reference implementations, and test scripts available free of charge to the health care and developer community but requires usage and possibly transaction costs for the X12 standards. We have accounted for the necessary engineers, subject matter experts, and health informaticists in our estimates. These personnel resources will need to convert payers’ prior authorization rules into computable, structured formats, create provider questionnaires regarding whether a patient had a medical necessity for a medical item or service, create formats that can interface with the provider’s EHR or practice management system, create and execute mapping between the HL7 and X12 codes, and integrate the Prior Authorization API with external systems or servers. Though this provision will be effective on January 1, 2027, this API will be under development before that date. Acknowledging that impacted payers have varying technological and staffing capabilities, we estimate that the development of the API will require 5,440 to 16,320 hours of work. In Table J9, we have distributed the cost over approximately 3 calendar years to give impacted payers the flexibility to complete the necessary work. Table J4 presents total burden estimates for the Prior Authorization API (initial design, followed by development and testing). This table presents the calculations associated with the total costs. The numbers from this table are used in Table J9 to present costs per year for 3 years. Based on the same assumptions as those included in the CMS Interoperability and Patient Access final rule (85 FR 25510), we used the medium estimate as the primary estimate. The narrative description provided for Table J3 also applies to Table J4. Both tables estimate API costs for 365 organizations and indicate follow-up annual maintenance costs by analyzing costs for a single payer using a team spanning approximately ten occupational titles. BILLING CODE 4150–28–P E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Jkt 262001 Frm 00195 Fmt 4701 Sfmt 4700 08FER2 $69,984 ** This total is based on our estimate of365 entities between the MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs. NOTES: + Estimated burden is the total burden of implementation. This burden is apportioned over 36 months in Table J9. Annual maintenance costs are 25 percent of total implementation costs. ++ Tables J2 through JS contain preparatory computations used for creating Table J9; they are not definitive statements of burden. Table J9 is the official COI statement of burden, including the number ofrespondents and responses. 8951 implementation cost of the Prior Authorization API, including whether E:\FR\FM\08FER2.SGM We requested public comment on our approach and assumptions for the PO 00000 ER08FE24.017</GPH> r and Information Systems Managers Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations 18:23 Feb 07, 2024 BILLING CODE 4150–28–C VerDate Sep<11>2014 TABLE J4: TOTAL BURDEN ESTIMATES FOR IMPACTED PAYERS FOR THE PRIOR AUTHORIZATION API* 8952 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations for answers can delay the pursuit of alternatives. To increase transparency and reduce burden, we are finalizing our proposal to require that certain impacted payers, not including QHP issuers on the FFEs, send prior authorization decisions within 72 hours for expedited requests and 7 calendar days for standard requests. Impacted payers will have to comply with these provisions beginning January 1, 2026. We note that Medicaid managed care plans and CHIP managed care entities will have to comply with these our estimates and ranges are reasonable or should be modified. We did not receive any comments on this section. 4. Information Collection Requirements Regarding Requirements To Send Prior Authorization Decisions Within Certain Timeframes (42 CFR 422.568, 422.570, 422.631, 438.210, 440.230, 457.495, and 457.1230) Patients need to have timely access to care, and providers need to receive timely responses to their requests for authorization to requests for services for their patients, particularly when waiting provisions by the rating period beginning on or after January 1, 2026. To implement this policy, there will be up-front costs for impacted payers to update their policies and procedures. We anticipate this burden per payer is 8 hours of work by a general and operations manager to update the policies and procedures, reflecting two half-days of work at a per-entity cost of $967. Therefore, the total burden for all 365 impacted payers is 2,920 hours of work at a first-year cost of $0.4 million (rounded). These calculations are summarized in Table J5. TABLE JS: FIRST-YEAR COST TO UPDATE POLICIES AND PROCEDURES TO SEND PRIOR AUTHORIZATION DECISIONS WITHIN CERTAIN TIMEFRAMES ~ 1 \ ! •,•I•, = " ,' ~ 1 ~ ' • ' l 111111111111m1m_______._ . . . . . ~~~~iJTu!,1111111111111 ~-~BD'liJI *Tables J2 through JS contain preparatory computations used for creating Table J9; they are not definitive statements of burden. Table J9 is the official COI statement of burden including the number ofrespondents and responses. We requested public comment on our assumptions, estimates, and approach but received no comments on this proposal and therefore are finalizing these estimates without modification. 5. Information Collection Requirements Regarding the Requirement for Public Reporting of Prior Authorization Metrics (42 CFR 422.122, 438.210, 440.230, 457.732, and 457.1230 and 45 CFR 156.223) To support transparency for patients to understand prior authorization processes, provide some assistance in choosing health coverage, and for providers when selecting or evaluating payer networks we are finalizing our proposal to require that impacted payers publicly report certain prior authorization metrics on their websites. Impacted payers will be required to report aggregated data annually for the previous calendar year’s data, beginning March 31, 2026. We estimate that impacted payers will conduct two major work phases: implementation, which includes defining requirements, system design, and updates to generate and compile reports; and maintenance, including an annual compilation of reports and public reporting of metrics on a website. In the first phase, impacted payers will need to define requirements concerning the types and sources of data that need to be compiled regarding prior authorization activities and data, build the capability for a system to generate reports, and update or create a public web page to post the data. In the second phase, impacted payers will need to create the reports and post them to a public web page annually. Table J6 itemizes the activities, hours, and dollar burdens for the first-year implementation and estimated annual maintenance costs. We assumed a team of two staff consisting of a software and web developer with a business operations specialist. • First-year implementation will impose a burden of 320 hours for the first year and 120 hours for subsequent years, at the cost of $30,000 and $9,000 (rounded), for the first and subsequent years, respectively. • The aggregate burden of the firstyear implementation across 365 impacted payers will be 117,000 hours and 44,000 hours (rounded) for the first and subsequent years, respectively, at a cost of $10.8 million and $3.3 million (rounded) for the first and subsequent years. *This table contains preparatory computations used for creating Table J9; they are not definitive statements of burden. Table J9 is the official COI statement of burden including the number ofrespondents and responses. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 PO 00000 Frm 00196 Fmt 4701 Sfmt 4725 E:\FR\FM\08FER2.SGM 08FER2 ER08FE24.018</GPH> ER08FE24.019</GPH> lotter on DSK11XQN23PROD with RULES2 TABLE J6: AGGREGATE BURDEN FOR COMPLYING WITH PUBLIC REPORTING OF PRIOR AUTHORIZATION METRICS Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations 6. Information Collection Requirements Regarding the Payer-to-Payer API Implementation (42 CFR 422.121, 431.61, 438.242, 42 CFR 457.731, and 457.1233 and 45 CFR 156.222) Patients may wish to carry certain health information with them when they change payers, in part so that they can track the services they have received, and to ensure that a new payer has information about their past health history for purposes of managing their care with new or current providers. We are finalizing the requirements for impacted payers to implement and maintain a Payer-to-Payer API as described in section II.C. of this final rule. These provisions will improve care coordination among payers by requiring payers to exchange, at a minimum, adjudicated claims and encounter data (excluding provider remittances and patient cost-sharing information), all data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI), and certain information about prior authorizations. This exchange will be required via a Payer-to-Payer API beginning in 2027 (by January 1, 2027, for MA organizations and Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs). As discussed for the other APIs in this rule, impacted payers will conduct three major work phases: initial design, development and testing, and long-term support and maintenance. There will be some costs for impacted payers to implement the Payer-to-Payer API that are unique to this API. There could be costs to test and integrate the Payer-to-Payer API with payer systems, albeit potentially lower costs than those estimated for the Provider Access API. We estimate the one-time implementation costs at about one-third the cost of a full de novo Provider Access API implementation based on input from developers who have implemented and piloted prototype APIs using the required standards. We accounted for the necessary skill sets of staff required as we also believe there will be unique costs for implementing the PDex IG so that payers can exchange active and pending prior authorization 8953 decisions and related documentation and forms when an enrollee or beneficiary enrolls with a new impacted payer. Table J7 presents the total activities, hours, and dollar burdens for implementing the Payer-to-Payer API given our assumptions on the initial design phase and the development and testing phase. Based on the same assumptions as those published in the CMS Interoperability and Patient Access final rule (85 FR 25510), we have the medium estimate as the primary estimate. We provide the following narrative explanation of Table J7: • For the primary estimate, one-time implementation efforts for the first two phases will require, on average, a total of 916 hours per organization at an average cost of $96,072 per organization. • The aggregate burden of the onetime implementation costs across 365 impacted payers will be 334,000 hours (rounded) at the cost of $35.1 million (rounded). This corresponds to the primary estimate; the low and high estimates are obtained by multiplying the primary estimate by factors of onehalf and one and one-half, respectively. TABLE J7: TOTAL BURDEN ESTIMATES FOR THE PAYER-TO-PAYERAPI* General and Operations Mana ers Computer and Information Anal sts Software and Web 11-1021 $120.90 48 96 144 $5,803 $11,606 $17,410 11-3021 $96.80 43 86 129 $4,162 $8,325 $12,487 Though this provision will be effective on January 1, 2027, the API will be under development before that date. Acknowledging that impacted payers will have varying technological and staffing capabilities, the development of the API will require 458 to 1,374 hours of work. In Table J9, we have distributed the cost estimates over 3 calendar years to give impacted payers the flexibility to complete the work. We requested public comment on our approach and assumptions for the cost of the Payer-to-Payer API, including whether our estimates and ranges are reasonable or should be modified, and received none. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 7. Information Collection Requirements Regarding the Electronic Prior Authorization Measure for Merit-Based Incentive Payment System and the Medicare Promoting Interoperability Program The estimates in this section have been submitted to OMB in a PRA package (OMB control number 0938– 1278). The burden associated with the proposed requirement for eligible hospitals and CAHs to report the Electronic Prior Authorization measure for the Medicare Promoting Interoperability Program will be captured in the next revision to the PRA PO 00000 Frm 00197 Fmt 4701 Sfmt 4700 package currently approved under OMB control number 0938–1278 (CMS– 10552). As explained in section II.F. of this final rule, in response to the December 2020 CMS Interoperability proposed rule (85 FR 82586), commenters indicated that provider reporting would be an appropriate lever by which CMS could encourage using the APIs to enable enhanced electronic documentation discovery and facilitate electronic prior authorization. Thus, to encourage MIPS eligible clinicians, eligible hospitals, and CAHs to implement and use electronic prior authorization and the corresponding E:\FR\FM\08FER2.SGM 08FER2 ER08FE24.020</GPH> lotter on DSK11XQN23PROD with RULES2 *Estimated burden is the total burden of implementation. 8954 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations lotter on DSK11XQN23PROD with RULES2 API, we proposed to add a new measure, called the Electronic Prior Authorization measure, for MIPS eligible clinicians under the MIPS Promoting Interoperability performance category and for eligible hospitals and CAHs under the Medicare Promoting Interoperability Program. After consideration of public comments, we have modified the Electronic Prior Authorization measure requirements which are further described and addressed in section II.F. of this final rule. We are finalizing that MIPS eligible clinicians would report the Electronic Prior Authorization measure beginning with the CY 2027 performance period/ 2029 MIPS payment year (rather than the CY 2026 performance period/2028 MIPS payment year) and that eligible hospitals and CAHs would report the Electronic Prior Authorization measure beginning with the CY 2027 EHR reporting period (rather than the CY 2026 EHR reporting period). For the CY 2027 performance period/2029 MIPS payment year for MIPS eligible clinicians and the CY 2027 EHR reporting period for eligible hospitals and CAHs, we are finalizing with a modification that the Electronic Prior Authorization measure be structured as an attestation (yes/no), instead of a numerator and denominator measure as originally proposed for both MIPS eligible clinicians, and eligible hospitals and CAHs. As an attestation measure, MIPS eligible clinicians, eligible hospitals, and CAHs are required to report a ‘‘yes’’ or ‘‘no’’ response or report an applicable exclusion, for the Electronic Prior Authorization measure. Additionally, we are finalizing that this measure will not be assigned points. For the MIPS Promoting Interoperability performance category, satisfactory performance on this measure can be demonstrated only by reporting a ‘‘yes’’ response or claiming VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 an applicable exclusion. A ‘‘no’’ response will result in the MIPS eligible clinician failing to meet the minimum reporting requirements, and therefore not being considered a meaningful EHR user for MIPS, as set forth in section 1848(o)(2)(A) of the Act and defined in 42 CFR 414.1305, for the MIPS payment year. MIPS eligible clinicians who do not report a ‘‘yes’’ response or claim an applicable exclusion for the Electronic Prior Authorization measure as specified (that is, they do not submit the measure or report a ‘‘no’’ response on the attestation without claiming an applicable exclusion) will not earn a score for the MIPS Promoting Interoperability performance category (a score of zero for the category). A MIPS eligible clinician’s score in the Promoting Interoperability performance category is generally worth 25 percent of their total final score for MIPS (42 CFR 414.1375(a); 414.1380(c)(1)). For the Medicare Promoting Interoperability Program, only a ‘‘yes’’ response on the attestation, or claiming an applicable exclusion, will fulfill the minimum requirements of this measure. A ‘‘no’’ response will result in the eligible hospital or CAH failing to meet the minimum program requirements, and therefore would not be considered a meaningful user of CEHRT, as defined in section 1886(n)(3) of the Act for an EHR reporting period (42 CFR 495.24(f)(1)(i)(A)). Eligible hospitals and CAHs that do not meet the minimum program requirements are subject to a downward payment adjustment. The burden in implementing these requirements consists of reporting an attestation (a ‘‘yes’’ or ‘‘no’’ response) or claiming an exclusion. In the RIA, section IV. of this final rule, we estimate burden based on the effort it takes to report a response for the measure. This estimated burden to report would be the same whether it is to report a ‘‘yes or no’’ response or to report a numerator PO 00000 Frm 00198 Fmt 4701 Sfmt 4700 and denominator as initially proposed. Therefore, modifying the measure to be reported as an attestation does not change the overall cost estimates included in the RIA for this provision. System maintenance is an umbrella term that includes all activities needed to keep a system running. The two main components of system maintenance are preventive and corrective maintenance, which include software tasks such as fixing bugs, updating data sources, deleting old software tasks, adding new tasks, testing, and verification. Maintenance requirements for systems were estimated at 25 percent of total software creation costs, reflecting updates and bug fixes, as well as deletion and creation of software tasks (85 FR 82649). There will be a moderate software update to implement the provisions of this final rule, and there will be no added burden over and above the burden of maintaining already existing software. The data for the reports on prior authorizations and related claims should already be stored in the system software of health care providers who may be required to retain such data for compliance and regulatory reasons. To report the Electronic Prior Authorization attestation (yes/no) measure as specified by CMS, the provisions in this rule should not impose a significant burden of denoting the information in the system. For the added burden of extracting, compiling, reviewing, and submitting the attestation, we assume that for each report, a Medical Records Specialist will spend about half a minute (0.0083 hours) extracting the already-existing data at a cost of $0.39 (1/120 hour (1⁄2 minute) × $46.42 per hour). To obtain the aggregate burden, we multiply by the number of entities. This is done separately for eligible hospitals and CAHs, and MIPS eligible clinicians in Table J8. E:\FR\FM\08FER2.SGM 08FER2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations 8955 TABLE J8: AGGREGATE ESTIMATES FOR THE ELECTRONIC PRIOR AUTHORIZATION MEASURE Number of Entities Mean Hourly Wage for a Medical Records S ecialist Hourly Burden Per Entity 4,500 54,770 $46.42 $46.42 1/120 Hour (1/2 minute) 0.00833 Hour 1/120 Hour (1/2 minute) 0.00833 Hour The following items provide support and rationale for the entries in Table J8: • The hourly burden estimates of 1⁄2 minute (1/120 = 0.00833 hour) for transmission of the Electronic Prior Authorization attestation (yes/no) response to CMS are consistent with the revised estimates of burden presented in the FY 2024 IPPS/LTCH proposed rule (88 FR 27204). The hourly burden estimates for the Electronic Prior Authorization measure are based on the collection of burden estimates calculated for the Query of Prescription Drug Monitoring Program measure. • The estimate of 4,500 hospitals (including eligible hospitals and CAHs) is consistent with the revised estimates presented in the FY 2024 IPPS/LTCH final rule (88 FR 27205). • The existing MIPS reporting policies allow MIPS eligible clinicians to report at the individual or group level. As noted in the CY 2024 PFS proposed rule (88 FR 52666), CMS did not propose any submission changes for the MIPS Promoting Interoperability performance category and therefore refers to previous rules for respondent and burden estimates. In Table 132 of the CY 2023 PFS final rule (87 FR 70163), the estimated number of respondents submitting MIPS Promoting Interoperability performance data was based on 2021 participation data collected during the PHE for the COVID–19 pandemic. We anticipate that participation will change over the next 10 years and volumes will rebound to pre-pandemic numbers. We determined that the respondent estimates in Table 122 of the CY 2023 PFS proposed rule (87 FR 46370) are more representational of what we anticipate participation will look like when the Prior Authorization API and associated Electronic Prior Authorization measure provisions are implemented given that these estimates are based on pre-pandemic participation data from CY 2019. Therefore, we VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 maintain that an estimated 54,770 individual or group MIPS eligible clinicians will submit an attestation for the Electronic Prior Authorization measure under the MIPS Promoting Interoperability performance category for the CY 2027 performance period/ 2029 MIPS payment year. The 54,770 is the sum of the 43,117 individual MIPS eligible clinicians, 11,633 groups, and 20 subgroups estimated to submit MIPS Promoting Interoperability performance data. The ICRs currently approved under OMB control number 0938–1314 are approved through January 31, 2025. • The FY 2024 IPPS/LTCH proposed rule uses mean hourly wage estimates (88 FR 27204), consistent with this final rule and the CMS Interoperability and Patient Access final rule (85 FR 25605). For purposes of clarification, we have provided both mean and median estimates. ++ For eligible hospitals and CAHs, the total cost is $1,741 (4,500 hospitals and CAHs × 1⁄2 minute × $46.42 per hour), which equals $0.002 million as shown in Table J9. This rounds to $0.0 million. Calculations using the median instead of the average after rounding are identical. This shows that the bottomline rounded figure would not change if we used the median instead of the average. The entries in Table J9 are rounded numbers while the actual dollar amounts are provided in Table J8. ++ For MIPS eligible clinicians, the total cost is $21,186 (54,770 clinicians × 1⁄2 minute × $46.42 per hour). Since Table J9 relates to Table K6 in the RIA, we expressed the $21,186 using RIA accounting standards, which require rounding to the nearest tenth of a million. It follows that $21,186 is equivalent to $0.021 million, as shown in Table J9. This value is rounded to $0.0 in the RIA. Comment: A commenter stated the calculation for the aggregate estimates for the Electronic Prior Authorization PO 00000 Frm 00199 Fmt 4701 Sfmt 4700 measure costs is unreasonable and lacks a reasonable basis. This commenter stated there is no way for an employee to run a report in half a minute, as logging into the computer system with two-factor authentication alone can take 1 to 2 minutes. The commenter stated getting to the report in the EHR can take 1⁄2 to 1 minute and running a large report can easily take 1⁄2 to 2 minutes. The report then needs to be verified and transmitted. The commenter stated instead of half a minute, the process is closer to 5 to 10 minutes. Another commenter stated that the analysis does not account for the payer burden of connecting and testing with all EHRs and practice management systems, specifically the high costs and time commitments. The commenter requested CMS’s clarification on whether payers are only required to share with EHR systems certified under the ONC Health IT Certification Program. Response: We appreciate concerns about the timing for reporting but respectfully disagree, particularly because we have modified the reporting specifications for the Electronic Prior Authorization measure. We are finalizing this measure with modifications such that, beginning with the CY 2027 performance period/2029 MIPS payment year and the CY 2027 EHR reporting period, a MIPS eligible clinician, eligible hospital, or CAH will report a ‘‘yes’’ or ‘‘no’’ response for the Electronic Prior Authorization measure or claim an exclusion, instead of a numerator and denominator measure as originally proposed. If the MIPS eligible clinician, eligible hospital, or CAH does not report a ‘‘yes’’ response for the Electronic Prior Authorization measure or claim an exclusion, they will receive a zero score for the MIPS Promoting Interoperability performance category or the Medicare Promoting Interoperability E:\FR\FM\08FER2.SGM 08FER2 ER08FE24.021</GPH> lotter on DSK11XQN23PROD with RULES2 *The table estimates use mean hourly wages for a medical records specialist for the Medicare Promoting Interoperability Program and MIPS. Table J9 records this as $0.0 million consistent with RIA accounting rules. 8956 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations lotter on DSK11XQN23PROD with RULES2 Program, respectively. We are finalizing reporting of the Electronic Prior Authorization measure as an attestation (yes/no) measure beginning with the CY 2027 performance period/2029 MIPS payment year and the CY 2027 EHR reporting period. With these modifications, completing and reporting the attestation for the Electronic Prior Authorization measure will not take 10 minutes, but significantly less time to enter into the reporting system. We are explicitly describing time spent reporting the Electronic Prior Authorization measure in this final rule, and half a minute is more representational for reporting a single attestation measure. The entire reporting process for these programs may take longer to complete, for example, 5-to-10 minutes. The amount of time it takes to report data to CMS is dependent on whether the person reporting the data needs to establish their account credentials, the amount of data being reported, and the method through which the data is being submitted. However, this calculation does not intend to calculate the amount of time it takes to conduct the entire process or report all performance data, rather it is solely evaluating the estimated amount of time a person would spend on VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 reporting the Electronic Prior Authorization measure. We also acknowledge this commenter’s concern about the basis for the aggregate estimates for the Electronic Prior Authorization measure. However, this commenter did not provide additional data to which we could compare our estimates. Furthermore, we disagree with the commenter as we used information from other interested parties as well as studies to determine that the cost savings will be substantial after a period of years because of the improvements in the prior authorization process for reducing manual effort and delays in services. We did not receive any other comments on this section of the rule. After consideration of public comments, we are finalizing the estimates without modification. D. Summary of Information Collection Burdens We have explained the costs of individual provisions in this section. Table J9 summarizes costs for the first and subsequent years of these provisions and is based on the following assumptions: • Modified compliance dates for the policies in this final rule that require PO 00000 Frm 00200 Fmt 4701 Sfmt 4700 API development or enhancement, Medicare Promoting Interoperability Program, and MIPS Promoting Interoperability performance category until the CY 2027 performance period/ 2029 MIPS payment year or CY 2027 EHR reporting period to give 3 years (36 months) for appropriate implementation activities. • Maintenance costs for the three APIs are, as indicated in the tables of this section, assumed to be 25 percent of total costs; these maintenance costs will be incurred in CY 2027 and subsequent years. • Certain provisions will be effective in January 2026; thus, no costs are reflected from 2023 through 2025. However, for the building of the API systems, we assume impacted payers will be performing these updates in CY 2024 through 2026 to be prepared for the CY 2027 compliance date. • Labor costs in Table J9 are either BLS wages when a single staff member is involved or a weighted average representing a team effort, which is obtained by dividing the aggregate cost by the aggregate hours. • Table J9 reflects the primary estimate. The full range of estimates for all provisions is presented in the RIA section of this final rule. BILLING CODE 4150–28–P E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 365 160 $94.32 58,400 Patient Access API Metrics Reporting, subsequent year costs (1) 365 40 $75.32 14,600 Provider Access API, Development (2) 365 2,800 $96.44 1,022,000 Frm 00201 Provider Access API, Maintenance (2) 365 700 96.44 255,500 Prior Authorization API, Develooment (3) 365 10,880 $105.19 3,971,200 Prior Authorization API, Maintenance Update Policies for Communicating Denials for Prior Authorization and Timeframes for Prior Authorization Decisions (3) 365 2,720 $105.19 992,800 (4) 365 8 $120.90 2,920 $0.4 Public Reoorting of Prior Authorization Metrics, 1st Year (5) 365 320 $92.42 116,800 $10.8 Public Reoorting of Prior Authorization Metrics, subseauent vears (5) 365 120 $75.32 43,800 Paver-to-Paver API, Develooment (6) 365 916 $104.88 334,340 Paver-to-Paver APT, Maintenance Attestation for MIPS Promoting Interoperability, MIPS eligible clinicians Attestation for Medicare Promoting Interoperability Program, Eligible Hospitals, and CAHs (6) 365 229 $104.88 83,585 54,770 0.0083 $46.42 456 Fmt 4701 (1) PO 00000 Jkt 262001 Patient Access API Metrics Reporting, 1st year Cost Sfmt 4700 E:\FR\FM\08FER2.SGM 08FER2 * The number of responses per respondent is uniformly 1 and therefore omitted. NOTES: (1) 42 CFR 422.119, 431.60, 438.242, 457.730, and 457.1233 and 45 CFR 156.221. (2) 42 CFR 422.121, 431.61, 438.242, 457.731, and 457.1233 and 45 CFR 156.222. (3) 42 CFR 422.122, 431.80, 438.242, 457.732, 457.1233, 422.122, 431.80, 438.242, 457.732, and 457.1233 and 45 CFR 156.223. (4) 42 CFR 422.566, 422.568, 422.570, 422.631, 438.210, 440.230, 457.495, and 457.1230. (5) 42 CFR 422.122, 438.210, 440.230, 457.732, and 457.1233 and 45 CFR 156.223. (6) 42 CFR 422.121, 431.61, 438.242, 457.731, and 457.1233 and 45 CFR 156.22. $5.5 $32.5 I $24.6 l $104.4 l $3.3 l $8.8 $11.6 $11.6 I l $137.8 $137.8 $11.6 $1.1 $32.5 $32.5 $137.8 l I I $0.021 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations 18:23 Feb 07, 2024 BILLING CODE 4150–28–C VerDate Sep<11>2014 TABLE J9: SUMMARY OF ANNUAL INFORMATION BURDEN FOR ALL PROVISIONS* 8957 ER08FE24.022</GPH> 8958 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations E. Conclusion The provisions of this final rule are expected to improve data sharing across impacted payers and providers by facilitating access, receipt, and exchange of patient data. We are committed to providing patients, providers, and payers with timely access to patient health information. We requested comments on our approaches for estimating cost burden and cost savings and received a few comments which have been incorporated herein. The requirements of this final rule are extensions of the requirements of the CMS Interoperability and Patient Access final rule (85 FR 22510). Therefore, the ICRs have been submitted to OMB for review and approval. lotter on DSK11XQN23PROD with RULES2 IV. Regulatory Impact Analysis A. Statement of Need As described in prior sections of this final rule, the changes to 42 CFR parts 422, 431, 435, 438, 440, and 457 and 45 CFR part 156 further support CMS’s efforts to empower patients by increasing electronic access to health care data, while keeping that information safe and secure. The provisions in this final rule build on the foundation we laid out in the CMS Interoperability and Patient Access final rule to move the health care system toward increased interoperability by enabling better data sharing capabilities of impacted payers, encouraging health care providers’ use of new capabilities, and making health-related data more easily available to patients through standards-based technology. The provisions in this final rule place new requirements on MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to further improve the electronic exchange of health-related data and streamline prior authorization processes. We believe these provisions will improve health information exchange and facilitate appropriate patient, provider, and payer access to health information via APIs, while the policies related to prior authorization should improve certain administrative processes. The final rule also adds a new attestation measure for eligible hospitals and CAHs under the Medicare Promoting Interoperability Program and for MIPS eligible clinicians under the MIPS Promoting Interoperability performance category. B. Overall Impact We examined the impacts of this final rule as required by Executive Order 12866 on Regulatory Planning and VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 Review (September 30, 1993), Executive Order 13563 on Improving Regulation and Regulatory Review (January 18, 2011), Executive Order 14094, entitled ‘‘Modernizing Regulatory Review’’ (April 6, 2023), the Regulatory Flexibility Act (RFA) (September 19, 1980, Pub. L. 96–354), Executive Order 13272 on Proper Consideration of Small Entities in Agency Rulemaking (August 13, 2002), section 1102(b) of the Act, section 202 of the Unfunded Mandates Reform Act of 1995 (UMRA) (March 22, 1995, Pub. L. 104–4), and Executive Order 13132 on Federalism (August 4, 1999) and the Congressional Review Act (5 U.S.C. 804(2)). Executive Orders 12866 and 13563 direct agencies to assess all costs and benefits of available regulatory alternatives and, if regulation is necessary, to select regulatory approaches that maximize net benefits (including potential economic, environmental, public health, and safety effects, distributive impacts, and equity). Executive Order 14094, entitled ‘‘Modernizing Regulatory Review,’’ amends section 3(f)(1) of Executive Order 12866 (Regulatory Planning and Review). The amended section 3(f) of Executive Order 12866 defines a ‘‘significant regulatory action’’ as an action that is likely to result in a rule: (1) having an annual effect on the economy of $200 million or more in any 1 year (adjusted every 3 years by the Administrator of the Office of Information and Regulatory Affairs (OIRA) for changes in gross domestic product), or adversely affect in a material way the economy, a sector of the economy, productivity, competition, jobs, the environment, public health or safety, or state, local, territorial, or tribal governments or communities; (2) creating a serious inconsistency or otherwise interfering with an action taken or planned by another agency; (3) materially altering the budgetary impacts of entitlement grants, user fees, or loan programs or the rights and obligations of recipients thereof; or (4) raise legal or policy issues for which centralized review would meaningfully further the President’s priorities or the principles set forth in this Executive order, as specifically authorized in a timely manner by the Administrator of OIRA in each case. Based on our estimates, OMB’s OIRA has determined this rulemaking to be significant per section 3(f)(1) as measured by having an annual effect of $200 million in at least 1 year, and hence is also a major rule under Subtitle E of the Small Business Regulatory Enforcement Fairness Act of 1996 (also known as the Congressional Review PO 00000 Frm 00202 Fmt 4701 Sfmt 4700 Act). Accordingly, we have prepared an RIA that, to the best of our ability, presents the costs and benefits of this final rule. These provisions will result in some financial burden for impacted payers and certain providers as discussed in section III. of this final rule. In the proposed rule, we weighed the potential burdens against the potential benefits and believe the benefits outweigh the costs (87 FR 76340). Based on our estimates, the total burden across all providers would be reduced by at least 220 million hours over 10 years, resulting in a total cost savings of at least $16 billion over 10 years as seen in Table K6. We did not include these savings in the 10-year Summary Table (Table K9), nor in the Monetized Table (Table K11), as explained later on in this section of the final rule. Comment: Some commenters disagreed with CMS’s calculated cost to implement the provisions outlined in the proposed rule and expressed that the actual cost will be much higher than estimated. A commenter stated that they fail to see how the estimated total burden across all providers would be reduced by the proposed rule’s estimates of 206 million hours resulting in the total cost saving of $15 billion that CMS asserted in the proposed rule. Response: While we appreciate that commenters do not concur with the cost estimates, we used the best available data to us at the time we developed the rule and made related assumptions about the reduction in hours for clerical, nursing, and provider staff as a result of the final policies. We are re-stating our assessments of those assumptions and calculations in this final rule. Though commenters and implementers did not submit new data for consideration, we did make a slight revision in the total cost savings to say ‘‘at least $16 billion’’ which includes adjustments of where some of the savings would occur. The potential savings are significant, and we firmly believe that the policies in this final rule will streamline operations, improve efficiencies, and pave the way for substantial changes in the way staff use technology to exchange data and conduct business, particularly for prior authorization. We welcome tangible data from commenters which we could use for comparative analysis of costs and savings. Comment: A commenter raised concerns with the impact analysis and cost calculations CMS included in the proposed rule, taking issue with CMS using data that includes the cost of all prior authorizations, which includes prescription drugs (accounting for 70 percent of prior authorizations), to E:\FR\FM\08FER2.SGM 08FER2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations calculate the savings potential of the proposed rule, as the policies do not apply to all prior authorizations. The commenter stated that accurate calculations would likely reveal that the rule as proposed is too costly to implement unless CMS modifies it to include prior authorization for prescription drugs, as well as all health plans. Response: We emphasize that this rule does not apply to prescription drugs that may be self-administered, administered by a provider, or that may be dispensed or administered in a pharmacy or hospital, or OTC drugs. We explicitly note that estimates do not include all prior authorizations and that formulary prior authorizations are excluded from our calculation of savings. In addition, this rule does not apply to all health plans and services, but rather to certain impacted payers, including MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs. We welcome alternative data to support further analysis and will continue to collect information as the final rule is implemented. C. Regulatory Flexibility Act Executive Order 13272 requires that HHS thoroughly review rules to assess and take appropriate account of their potential impact on small businesses, small governmental jurisdictions, and small organizations (as mandated by the RFA). HHS considers a ‘‘significant’’ impact to be 3 to 5 percent or more of the affected entities’ costs or revenues. For background on the RFA references in the proposed rule, please see 87 FR 76340. We confirm our analysis of the impacted entities as described in section IV.C. of this final rule. lotter on DSK11XQN23PROD with RULES2 1. Payers The 365 payer organizations will perform updates to systems to implement the required APIs and prepare for reporting requirements. As VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 in the proposed rule, we use the term parent organizations in this final rule to refer to the impacted payers (87 FR 76238). The combined parent organizations administer MA plans, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs. The North American Industry Classification System (NAICS) category relevant to these provisions is Direct Health and Medical Insurance Carriers, NAICS 524114, which has a $47.0 million threshold for small size. 75 percent of payers in this category have under 500 employees, thereby meeting the definition of small businesses. The 365 parent organizations, including state Medicaid and CHIP agencies, are responsible for implementing and maintaining three new APIs, updating policies and procedures to accommodate revised timeframes for making prior authorization decisions, and reporting certain metrics either to CMS or making information available to the public. We determined that state Medicaid and CHIP agencies, as well as many MA organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs are not considered small entities. Furthermore, MA organizations and Medicaid managed care plans and CHIP managed care entities have many of their costs covered through capitation payments from the Federal Government, and thus we conclude there is no significant burden on small entities in this final rule. We are finalizing the provisions that require API development or enhancement as proposed. We also note that some QHP issuers on the FFEs will be able to apply for an exception to these requirements, and certain states operating Medicaid and CHIP FFS programs will be able to apply for an extension or exemption, under which they will not be required to meet the new provisions of this final rule that require API development or PO 00000 Frm 00203 Fmt 4701 Sfmt 4700 8959 enhancement on the compliance dates, provided certain conditions are met, as discussed in section II.E. further mitigating potential burden for those payers. a. Medicare Advantage On an annual basis, MA organizations estimate their costs for the upcoming year and submit bids and proposed plan benefit packages to CMS. Upon approval, the plan commits to providing the proposed benefits, and CMS commits to paying the plan either the full amount of the bid, if the bid is below the benchmark (a ceiling on bid payments annually calculated from Original Medicare data); or the benchmark amount, if the bid amount is greater than the benchmark. Thus, there is a cost to plans to bid above the benchmark that is not funded by government payments. Additionally, if an MA organization bids above the benchmark for any of its plans, section 1854 of the Act requires the MA organization to charge enrollees a premium for that amount. In the proposed rule, we provided a further explanation regarding MA organizations’ bids and government payment processes for MA plans and MA plans with prescription drug coverage (MA–PDs) and refer readers to that discussion for additional detail (87 FR 76341). Table K1 reports the percentage of MA organizations bidding above the benchmark, along with the percentage of affected enrollees in recent years. This table reports aggregates of proprietary bid data collected by the Office of the Actuary (OACT). The CMS threshold for what constitutes a substantial number of small entities for purposes of the RFA is 3 to 5 percent. As shown in Table K1, both the percentage of plans and the percentage of affected enrollees are below this 3 to 5 percent threshold. Consequently, we conclude that the number of plans bidding above the benchmark is not substantial for purposes of the RFA. E:\FR\FM\08FER2.SGM 08FER2 8960 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations TABLE Kl: PERCENTAGE OF PLANS BIDDING ABOVE BENCHMARK BY YEAR 100 66 30 12 2,108,026 1,167,779 328,621 101,297 The preceding analysis shows that meeting the direct costs of this final rule does not have a significant economic impact on a substantial number of small entities as required by the RFA. There are certain indirect consequences of the final policies, which will also have an economic impact. We explained that at least 98 percent of MA organizations bid below the benchmark. Thus, we estimate that their projected costs for providing services to Medicare beneficiaries for the coming year are fully paid by the Federal Government. However, the government additionally pays the plan a ‘‘beneficiary rebate’’ amount that is an amount equal to a percentage (between 50 and 70 percent, depending on a plan’s quality rating) multiplied by the amount by which the benchmark exceeds the bid. The rebate is used to provide additional benefits to enrollees in the form of reduced cost-sharing or other supplemental benefits or to lower the Part B or Part D premiums for enrollees (supplemental benefits may also partially be paid by enrollee premiums). If the provisions of this final rule cause the MA organization’s bids to increase and if the benchmark remains unchanged or increases by less than the bid does, the result will be a reduced rebate and, possibly fewer supplemental benefits, or higher premiums for the health plans’ enrollees. However, as noted previously, the number of plans bidding above the benchmark to whom this burden applies does not meet the RFA criteria of a significant number of plans. It is possible that if the provisions of this final rule cause bids to increase, MA organizations will reduce their profit margins, rather than substantially change their benefit packages. This may be in part due to market forces; a plan lowering supplemental benefits even for 1 year may lose enrollees to competing plans that offer these supplemental benefits. Thus, it can be advantageous to the plan to reduce profit margins, rather VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 4,270 4,837 5,298 5,660 231,754,722 259,609,169 288,151,395 313,317,522 than reduce supplemental benefits. With this, plans would balance competitive pressures with profit targets immediately following a new regulation. As the regulations are typically finalized within a few months of the bid submission deadline, plans may have more time to enact strategies that do not require large benefit changes in subsequent years, such as negotiations for supplemental benefit offerings. However, it may be inappropriate to consider the relevant regulatory impacts (and thus the profit considerations) as temporary because the issuance of a series of regulations sustains the effects.193 As a result, changes in benefits packages may be plausible. We did not receive any comments on this section of the RIA regarding small entities, nor on our assumptions about the impact or the general summary of the structure for MA bids. We are therefore finalizing this analysis as is. Based on the previously discussed considerations, the Secretary has certified that this final rule will not have a significant impact on a substantial number of small entities. b. Medicaid and CHIP Title XIX of the Act established the Medicaid program as a Federal-state partnership to provide and finance medical assistance to specified groups of eligible individuals. States claim Federal matching funds quarterly based on their program expenditures. Since states are not small entities under the RFA, we need not discuss the burden imposed on them by this final rule. Medicaid managed care plans and CHIP managed care entities receive 100 193 See similar discussion in previous regulatory analyses: Contract Year 2023 Policy and Technical Changes to the Medicare Advantage and Medicare Prescription Drug Benefit Programs, 87 FR 27704 (May 9, 2022). Retrieved from https:// www.federalregister.gov/d/2022-09375; and Changes to the Medicare Advantage and the Medicare Prescription Drug Benefit Program for Contract Year 2021 and 2022, 87 FR 22290 (April 14, 2022). Retrieved from https:// www.federalregister.gov/d/2022-07642. PO 00000 Frm 00204 Fmt 4701 Sfmt 4700 2.30% 1.40% 0.60% 0.21% 0.90% 0.40% 0.10% 0.03% percent capitation from the state; we expect that the projected costs associated with the provisions of this final rule will be included in their capitation rates. Consequently, we assert that there will be no substantial impact on a significant number of these entities. As discussed in section II.E. of this final rule for the provisions that require API development or enhancement, states operating Medicaid and CHIP FFS programs may apply for an extension of 1 year to come into compliance with the requirements of this final rule. These same organizations may also apply for an exemption from the requirements if certain conditions are met. Comments pertaining to the Medicaid and CHIP explanation of Federal matching funds are addressed in that section of this final rule, as are those related to the extension and exemption processes. c. Qualified Health Plan Issuers on the Federally-Facilitated Exchanges Few, if any, QHP issuers on the FFEs are small enough to fall below the size thresholds for a small business established by the SBA. Consistent with previous CMS analysis in the SHOP/ QHP final rule (78 FR 33233), we estimated that any issuers considered small businesses would likely be subsidiaries of larger issuers that would not be considered small businesses (78 FR 33238), and thus would not share the same burdens as an independent small business. Therefore, even though QHP issuers do not receive Federal reimbursement for the costs of providing care, we do not conclude that there would be a significant small entity burden for these issuers. In addition, an exception process is available to QHP issuers on the FFEs, which could further help to address regulatory burden that could otherwise prohibit a QHP issuer from participating in an FFE. We did not receive any comments specific to the QHP summary section of this RFA. Comments related to the E:\FR\FM\08FER2.SGM 08FER2 ER08FE24.023</GPH> lotter on DSK11XQN23PROD with RULES2 2020 2021 2022 2023 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations exception process for QHPs are addressed in section II.E. lotter on DSK11XQN23PROD with RULES2 2. Providers In response to public comments on the December 2020 CMS Interoperability proposed rule (85 FR 82586), CMS proposed a new Electronic Prior Authorization measure for MIPS eligible clinicians under the MIPS Promoting Interoperability performance category, and for eligible hospitals and CAHs under the Medicare Promoting Interoperability Program. CMS proposed that the Electronic Prior Authorization measure would be required for MIPS eligible clinicians beginning with the CY 2026 performance period/2028 MIPS payment year and for eligible hospitals and CAHs beginning with the CY 2026 EHR reporting year. However, after consideration of substantial feedback from commenters described in section II.F. of this final rule, we are finalizing a modification to the Electronic Prior Authorization measure proposal. Rather than requiring MIPS eligible clinicians, eligible hospitals, and CAHs to report a numerator and denominator for the Electronic Prior Authorization measure, we are finalizing the measure structured as an attestation (yes/no) measure for both MIPS eligible clinicians, and eligible hospitals and CAHs. As an attestation measure, MIPS eligible clinicians, eligible hospitals, and CAHs will report a ‘‘yes’’ or ‘‘no’’ response or report an applicable exclusion for the Electronic Prior Authorization measure. Additionally, we are finalizing that this measure will not be assigned points. For the MIPS Promoting Interoperability performance category, satisfactory performance on this measure can be demonstrated only by reporting a ‘‘yes’’ response or claiming an applicable exclusion. A ‘‘no’’ response will result in the MIPS eligible clinician failing to meet the minimum reporting requirements, and therefore not being considered a meaningful EHR user for MIPS, as set forth in section 1848(o)(2)(A) of the Act and defined at 42 CFR 414.1305, for the MIPS payment year. MIPS eligible clinicians that do not report a ‘‘yes’’ response or claim an applicable exclusion for the Electronic Prior Authorization measure as specified (that is, they do not submit the measure or report a ‘‘no’’ response on the attestation without claiming an applicable exclusion) will not earn a score for the MIPS Promoting Interoperability performance category (a score of zero for the category). A MIPS eligible clinician’s score in the Promoting Interoperability performance category is generally worth 25 percent of VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 their total final score for MIPS (42 CFR 414.1375(a); 414.1380(c)(1)). For the Medicare Promoting Interoperability Program, only a ‘‘yes’’ response on the attestation, or claim of an applicable exclusion, will fulfill the minimum requirements of this measure. A ‘‘no’’ response will result in the eligible hospital or CAH failing to meet the minimum program requirements, therefore not being considered a meaningful user of CEHRT, as defined in section 1886(n)(3) of the Act for an EHR reporting period (42 CFR 495.24(f)(1)(i)(A)). Eligible hospitals and CAHs that do not meet the minimum program requirements are subject to a downward payment adjustment. With regard to MIPS eligible clinicians, eligible hospitals, and CAHs, a discussion of the burden is provided in section III., and supporting data are shown in Table J8. As noted previously, we modified the provision for the Electronic Prior Authorization measure in this final rule based on comments indicating that the denominator calculation would impose a significant burden on providers. We have calculated the burden per individual provider at under $2.50 per year (1⁄2 minute of labor times an hourly wage of under $50). Based on all information provided herein, we conclude that the requirements of the RFA have been met by this final rule. We did not receive comments on this subject in the RFA. The modification to the Electronic Prior Authorization measure was not determined to have a significant financial effect on this RIA because there is no need to re-calculate the numerator and denominator and the information will be reported as an attestation. We are finalizing this section as is. D. Unfunded Mandates Reform Act and Executive Order 13132 Requirements Section 202 of the UMRA also requires that agencies assess anticipated costs and benefits before issuing any rule whose mandates require spending in any 1 year of $100 million in 1995 dollars, updated annually for inflation. In 2023, that threshold is approximately $177 million. This final rule will not impose an unfunded mandate that results in the expenditure by state, local, and tribal governments, in the aggregate, or by the private sector, of more than $177 million in any 1 year. Executive Order 13132 establishes certain requirements that an agency must meet when it publishes a final rule that imposes substantial direct costs on state and local governments, preempts state law, or otherwise has federalism PO 00000 Frm 00205 Fmt 4701 Sfmt 4700 8961 implications. As previously outlined, while the provisions that require API development or enhancement will be a requirement for state Medicaid and CHIP agencies as described in this final rule, the cost per beneficiary for implementation is expected to be negligible when compared with the overall cost per beneficiary. The analysis we conducted did not consider Federal matching funds provided to state Medicaid and CHIP agencies, and the conclusion was the same: there is not expected to be a significant cost impact on state entities. For Medicaid and CHIP, we are unaware of any provisions in this final rule that conflict with state law, and no commenters raised a pre-emption issue other than the timeframe issue discussed later in this section. Therefore, we do not anticipate any preemption of state law. As discussed in section II.D. of this final rule, some state laws regarding timeframes for prior authorization decisions may be different than the provisions in this final rule. However, an impacted payer will be able to comply with both state and Federal requirements by complying with whichever imposes the shorter timeframe. We invited states to comment on the proposed rule if they believed that any proposal in this rule would conflict with state law. We received a few comments from states and other organizations regarding the preemption of state law regarding timeframes and addressed these comments regarding prior authorization decision timeframes and compliance with state law in section II.D. of this final rule. As noted previously in this section, we considered whether the provisions in this final rule imposed substantial costs on state or local governments, preempted state law, or had federalism implications and concluded that the rule does not. Therefore, the requirements of Executive Order 13132 are not applicable. E. Regulatory Review Costs If regulations impose administrative costs on private entities, such as the time needed to read and interpret this final rule, we are required to estimate the cost associated with regulatory review. We modeled our estimates of this burden based on similar estimates presented in the CMS Interoperability and Patient Access final rule (85 FR 25510). In the proposed rule, we cited three numbers that were needed to calculate this estimate: (1) number of staff per entity performing the reading; (2) number of hours of reading; and (3) number of entities reviewing the final E:\FR\FM\08FER2.SGM 08FER2 8962 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations rule. We estimated a one-time aggregated total review cost of $1.3 million ($128.71 × 10 hours of reading time × 500 entities × two staff per entity). We requested comments on our estimate and assumptions. However, we did not receive any comments. For further details on this matter, refer to the proposed rule at 87 FR 76343. Therefore, we are finalizing the analysis as presented. F. Impact of Individual Proposals The provisions of this final rule all have information collection-related burdens. This information is provided in Table J9 in section III. of this final rule. Table K2 provides a list of the ICRs by number and title, as well as the table numbers in which we provided an impact assessment. TABLE K2: CROSS-REFERENCES TO IMPACTS IN THE INFORMATION COLLECTION REQUIREMENTS OF THIS FINAL RULE Prior Authorization API Table Electronic Prior Authorization Measure Eli ible Hos itals, CAHs, and MIPS eli ible clinicians Provision 3-Year Anal sis of Cost Im act of Provisions Additionally, this RIA section provides an analysis of expected savings to providers arising from the replacement of paper documents related to prior authorization and other plan requirements with EHRs. Although these savings are neither included in the Monetized Table (Table K11) nor in the Summary Table (Table K9), we believe that these large savings are an important consideration in understanding this final rule. We have identified our assumptions for savings at the end of this section. Comment: Several commenters sought clarification regarding CMS’s analysis of how the proposed rule would impact industry. Commenters stated that the discussion of the costs and benefits of the proposed rule was not specific enough and disagreed with CMS’s claim that the benefits of the provisions are greater than the costs. Additionally, a commenter noted that the costs estimated in the proposed rule vastly underestimate the true cost of implementing and complying with the provisions. The commenters provided recommendations on certain concepts and ideas that CMS should take into consideration when assessing the regulatory impact of this rule. A few commenters expressed concerns over the calculations associated with prior authorization. For example, one commenter noted that CMS failed to account for the increase in prior authorization burden since the publication of the Casalino report in 2009. Another commenter noted that VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 CMS failed to include a 2.5 percent fee for electronic prior authorization transactions and the costs healthcare providers expect to incur. A commenter agreed that some upfront costs would be incurred but noted that new burdens and costs would be imposed on payers, which must be considered. Another commenter noted that there is little to no quantitative or qualitative data to justify CMS’s approach to calculating cost and savings associated with the provisions in this rule. Several commenters recommended that CMS work with payers and providers to develop protocols to help identify specific cost savings and efficiencies from automating the prior authorization process. Response: CMS bases the impact analysis on data we can obtain from past research and other available information. During development of the proposed rule, we made certain assumptions about implementation and development costs. However, based on the number of pilots in the launch phase, we are optimistic that we will have additional data following implementation. To the extent feasible, we encourage industry to share data with us, which would be subject to all requested confidentiality and proprietary protections afforded under the Freedom of Information Act.194 We will look for opportunities to engage 194 Office of Information Policy, U.S. Department of Justice (n.d.). Freedom of Information Act Homepage. Retrieved from https://www.foia.gov/. PO 00000 Frm 00206 Fmt 4701 Sfmt 4700 Table J4 Table JS Table J6 Table J7 Table J8 Table J9 with impacted entities to identify both cost savings and expenditures based on automation of prior authorization processes which would support the publication of the findings. Comment: A commenter noted that it is unrealistic for CMS to expect that industry can obtain the resources necessary to comply with these policies within the current budget year when the requirements will not be finalized until the final rule is issued. The commenter recommended that CMS revise the compliance dates for these provisions to be 36 months after issuance of the final rule and scheduled on a date other than the end of a calendar year. Another commenter recommended that CMS reconsider the proposed timeline of certain provisions in the rule given the critiques on the RIA and consider reshaping this rule into a roadmap with milestones along the journey that would signal that a new requirement was ready for implementation. A commenter recommended that CMS adjust the RIA to account for changes in the FHIRbased standards and recommended IGs. Response: We appreciate concerns about implementation costs and timing, as they pertain to this impact analysis, for states which are dependent on state fiscal timelines for approvals and procurements. We also remind readers that some impacted payers may be eligible to apply for extensions, exceptions, and exemptions under certain circumstances, as described in section II.E. of this final rule. We believe that the finalized extensions, E:\FR\FM\08FER2.SGM 08FER2 ER08FE24.024</GPH> lotter on DSK11XQN23PROD with RULES2 2 3 4 5 6 7 Summa lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations exceptions, and exemptions will adequately address any contingencies faced by individual payers and other affected entities. Finally, as stated in section I.D. of this final rule, we are finalizing compliance dates in 2027 for the policies in this final rule that require API development or enhancement, in recognition of the need for analysis, procurement, training, testing, and development. We appreciate the commenter’s feedback on updating our impact analyses to account for changes to the FHIR standards, specifications, and IGs. However, we disagree that updates to standards, specifications, and IGs should be accounted for in the impact analysis. Changes to standards, specifications, and IGs do not have any bearing on the calculation of an impact analysis. We acknowledge that it will be important for implementers to remain engaged in the HL7 workgroups and implementation forums. We are requiring entities to use certain IGs specified in this final rule and the ONC Cures Act final rule (85 FR 25642); those standards will remain consistent. Should there be updates to any of those standards or IGs, changes will be made available to implementers through SVAP, as they are tested and approved by ONC. Industry is strongly encouraged to participate in that process to ensure awareness and readiness, but we do not believe that the changes or process for those changes is of significance for the impact analysis. Finally, as discussed earlier in this final rule, some commenters wrote regarding the potential costs that might be passed on to providers from EHR vendors or payers for use of the APIs, in the form of user fees. We recognize that EHR vendors, providers, and payers have costs of doing business, particularly for the development and implementation of the APIs, as described in this RIA. We strongly encourage EHR vendors to only charge reasonable fees for any initial or periodic system configurations required to access payers’ API endpoints. We did not include information regarding user fees for APIs in this impact analysis because of the lack of available data on the costs incurred between payers, developers, EHRs and providers. However, we are committed to monitoring and evaluating the expanding landscape of API usage and will consider opportunities to provide future guidance on this topic, to ensure that we can provide comprehensive and up-to-date information for our industry partners. The Summary Table (Table K9) of this section, using Table J9 as a basis, provides a 10-year impact estimate. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 Table K9 includes impact by year, by type (parent organizations, including state Medicaid and CHIP agencies), as well as the cost burden to the Federal Government, allocations of cost by program, and payments by the Federal Government to MA organizations, Medicaid, and CHIP, as well as the premium tax credits (PTCs) paid to certain enrollees in the individual market. G. Alternatives Considered We stated in the proposed rule that we are continuing to build on the efforts initiated with the CMS Interoperability and Patient Access final rule (85 FR 25510) and the work we have done to advance interoperability, improve care coordination, and empower patients with access to their data. This final rule covers several provisions aimed at achieving these goals. We described alternatives to our proposals in the proposed rule and the reasons we did not select them as proposed provisions. The details for each of those alternatives and the rationale behind not including them are available in the proposed rule at 87 FR 76344. 1. Alternatives Considered for the Patient Access API Enhancements We are finalizing modifications to our proposals to require payers to make enhancements to the Patient Access API, which was finalized in the CMS Interoperability and Patient Access final rule (85 FR 25510). We are requiring payers to make additional information available to patients through the Patient Access API and to report certain metrics about patient use of the Patient Access API to CMS annually. We considered several policy alternatives for the Patient Access API. These are described in the proposed rule at 87 FR 76344, and relevant comments regarding the Patient Access API are addressed in section II.A. of this final rule. Regarding reporting Patient Access API metrics, we considered requiring impacted payers to publicly report these metrics more frequently than annually. For example, we considered a quarterly requirement. Public comments on the December 2020 CMS Interoperability proposed rule (85 FR 82586) indicated a preference for less frequent reporting to reduce burden on payers. Annual statistics on such utilization should be sufficient to accomplish our goal of understanding patient utilization of the API. Comments regarding reporting on Patient Access API metrics are addressed in section II.A. of this final rule. The quantitative effect of quarterly reporting will likely not change the PO 00000 Frm 00207 Fmt 4701 Sfmt 4700 8963 bottom line of $1.6 billion cost over 10 years shown in Table K9. However, we acknowledge it may change marginally to $1.7 billion. As shown in the various tables of section III. of this final rule, the annual cost of reporting is estimated at $3.2 million based on hours of work required by a business operations specialist. If we required quarterly reporting this would quadruple the estimate or add about $10 million annually—or a little under $100 million over 10 years. This would raise the $1.558 billion cost to at most $1.658 which, when rounded, would be either $1.6 or $1.7 billion. We also considered earlier compliance dates for the proposed enhancements to the Patient Access API. In the proposed rule, we stated it would be more appropriate, and less burdensome on impacted payers to propose compliance dates for these provisions in 2026 (by January 1, 2026, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2026, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2026, for QHP issuers on the FFEs), which would have provided a 2-year implementation timeframe. However, based on public comments, we are finalizing a compliance dates in 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs) for the policies in this final rule that require API development or enhancement. Additional information regarding the updated compliance dates for the APIs is available in sections I.D., II.A., II.B., II.C., and II.D. of this final rule. Had we implemented the rule a year earlier, the aggregate $1.6 billion over 10 years would change to $1.7 billion over 10 years. The total cost for creating the various APIs would not change; rather, they would be apportioned over 2 years rather than 3 years. However, if we required compliance a year earlier, then the maintenance costs of $142 million per year would begin in year 3 rather than in year 4. This would add an extra $142 million per year of cost raising the aggregate 10-year cost of $1.55 billion to $1.69 billion or $1.7 billion after rounding. E:\FR\FM\08FER2.SGM 08FER2 8964 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations 2. Alternatives Considered for the Provider Access API To better facilitate the coordination of care across the health care continuum, we are finalizing our proposal to require impacted payers to implement and maintain a Provider Access API. This API will require payers to make available to certain providers the same types of data they make available to patients via the enhanced Patient Access API. As noted in the proposed rule at, we considered other data types that could be exchanged via the Provider Access API and considered only requiring the exchange of all data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI) (87 FR 76345). While this would have required that less data be exchanged and, thus, be less burdensome for impacted payers to implement, we believed that claims and encounter information would complement the content standard and offer a broader and more holistic understanding of a patient’s interactions with the health care system. Furthermore, the data that we proposed to be made available through the Provider Access API aligns with the data that we proposed to be made available to individual patients through the Patient Access API. We also considered including additional data elements as required for the Provider Access API, requiring a complete set of data available from the payer’s system. However, we did not receive such suggestions from industry, including patients, and such a large volume of data types might have been overwhelming for providers, would have been an excessive cost, and would likely not have met minimum necessary provisions. A more robust description of the alternatives and our rationale for not selecting those are set out in the proposed rule (87 FR 76346). We did not receive comments specifically on the alternatives considered in this section. Other comments regarding the Provider Access API are addressed in section II.B. of this final rule. lotter on DSK11XQN23PROD with RULES2 3. Alternatives Considered for the Payerto-Payer API We are finalizing our proposal to require impacted payers to implement and maintain a Payer-to-Payer API that makes certain data available to other payers via a FHIR API. This provision will make the same data that is being made available to patients and providers also available to other payers when a patient changes plans. This will allow patients to take their data with them as they move from one payer to another. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 Before finalizing this provision, we considered several alternative provisions which we described in detail in the proposed rule (87 FR 76346). For example, in the CMS Interoperability and Patient Access final rule, we finalized a policy to require payers to exchange data with other payers but did not require a specific mechanism for the payer to payer data exchange to occur. Rather, we required impacted payers to receive data in whatever format it was sent and accept data in the form and format it was received, which ultimately complicated implementation by requiring payers to accept data in different formats. The cost to implement these various formats cannot be calculated because there are endless possibilities and combinations of ways the data could have been exchanged under the previously finalized policy. Unlike the policy finalized in the CMS Interoperability and Patient Access final rule, the use of an API would reduce the amount of implementation cost needed for this data exchange. Importantly, for the Payer-to-Payer API, once an organization implements the other APIs of this final rule, less additional investment will be necessary to implement the payer to payer data exchange, as payers would be able to leverage the infrastructure already established for the Patient Access and Provider Access APIs. The updated background information for the recommended IGs is found in section II.G. and explains how the existing resources can be tailored to meet the provisions set out in this final rule. Given this available infrastructure and the efficiencies of sharing standardized data via the API, we determined it was most advantageous for payers to implement an API for this enhanced data exchange. We did not receive any comments on this section, but comments specific to the proposal for the Payer-to-Payer API are addressed in section II.C. of this final rule. 4. Alternatives Considered for the Prior Authorization API and Other Prior Authorization Process Requirements We are finalizing our proposals for several important policies to improve the prior authorization process, which we described in the proposed rule (87 FR 76346). Our final policy to require that all impacted payers implement and maintain a Prior Authorization API will ultimately help patients receive the items and services they need in a timely fashion, and support streamlined communication between providers and payers. The Prior Authorization API aims to improve care coordination by PO 00000 Frm 00208 Fmt 4701 Sfmt 4700 providing more structured information about when a prior authorization is required, information that is required to approve a prior authorization, and facilitating electronic prior authorization. The API will be accessible to providers to integrate directly into their workflow while maintaining compliance with the mandatory HIPAA transaction standard. The standards and IGs that support the development of this API are already being tested and piloted with some success between providers and payers, and we believe as enhancements to the IGs are made over the next few years, more organizations will see the benefit for their programs. As noted previously, we described our considerations for a phased approach, or partial implementation of the API over time, and explained why we did not propose those options. We did not receive comments in support of a partial implementation in part because of the risk that such an option might result in inconsistent implementations and increase burden for providers. As indicated, though quantitative data from current prior authorization pilots have been shared informally with the public, it has not yet been submitted to CMS for use in official evaluations or analysis. CMS anticipates receipt of the pilot results in CY 2024. Though we do not have specific data, we believe the quantitative effects of a phased in implementation option would be negligible. The total cost of developing the Prior Authorization API would not change; however, such an approach could mean delaying the 25 percent maintenance costs by 1 or 2 years, as well as the overall benefits of the API. We are finalizing our requirement that impacted payers publish certain data about their performance on prior authorization, on a public website, and though we considered options for this reporting, we believe in the first few years of program implementation it will be important to gather feedback from payers, providers and patients as to the usability of the information being made available before modifying the requirement. As explained in section II.D. of this final rule, CMS is committed to working with impacted entities on best practices for reporting. We considered using only the X12 278 transaction standard adopted under HIPAA rather than requiring the implementation of a FHIR API to support the Prior Authorization API. While the adopted X12 278 transaction standard defines the content and format for the exchange of data for prior authorization, it does not have the E:\FR\FM\08FER2.SGM 08FER2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations functionality of the FHIR standard or IGs to support the requirements of the Prior Authorization API. This includes the ability to accommodate all of a payers’ business rules, indicate which supporting documents are required, create a questionnaire, and conduct an end-to-end transaction via FHIR for realtime responses. We received confirmation through many comments that the X12 standard is not designed to enable using SMART on FHIR apps connected to the provider’s EHR system, nor is it designed for the scope envisioned in this rule, including extraction of payer rules, a compilation of data into electronic-based questionnaires, or communication with EHRs. The substantive comments on this subject are addressed in section II.D. of this final rule. We are finalizing the operational, non-technical provisions related to prior authorization processes, including requirements for certain impacted payers to respond to expedited prior authorization requests within 72 hours, and to standard prior authorization requests within 7 calendar days. We received many comments suggesting that the response timeframes be shortened because of the potential impact on patient care, and those comments are addressed in section II.D. of this final rule. Understanding the importance of providers and patients getting decisions as quickly as possible, we believe that the timeframes outlined in the proposed rule are a significant step to help increase reliability in the prior authorization process and establish clear expectations without being overly burdensome for payers. lotter on DSK11XQN23PROD with RULES2 H. Savings Through the Adoption of the Prior Authorization Provisions by Health Care Providers 1. Overview As described in section II.D. of this final rule, we have finalized new requirements related to prior authorization for impacted payers, and in section II.F. of this final rule, we described a new Electronic Prior Authorization measure and the associated reporting requirements for MIPS eligible clinicians, eligible hospitals, and CAHs. In section III.C. of this final rule, we discussed the ICRs regarding cost estimates for reporting and the potential burden specifically for the MIPS eligible VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 clinicians, eligible hospitals, and CAHs. Here we address the anticipated cost savings of these provisions for the broader health care provider population, which is inclusive of, but not limited to the MIPS eligible clinicians, eligible hospitals, and CAHs. We believe that all health care providers can benefit from the provisions for impacted payers to implement the APIs in this final rule and base these cost-savings estimates over 10 years. We use the estimated total number of providers, with estimates described in this section of the final rule. To conduct this analysis, we used available resources and invited comments on our assumptions, the data, and our citations. The savings estimated in this final rule are true savings, not transfers, since they reflect savings in reducing the administrative costs required to process prior authorizations. However, these savings will be an indirect consequence of the final rule, not direct savings. This final rule supports efforts to significantly reduce time spent on manual activities. In general, it is only appropriate to claim that a regulatory provision’s benefits are greater than its costs after a substantive and preferably quantitative, assessment of the preexisting market failure and the provisions’ suitability for addressing it. As a result of data limitations and other analytic challenges preventing such an assessment, the illustrative savings estimates are neither included in the Monetized Table (Table K11) nor the Summary Table (Table K9) of this final rule. Nevertheless, the savings could be significant, and we believe should be a factor in the industry’s assessment of this final rule. In the proposed rule, we requested comments on how CMS might attribute savings benefits to avoid double-counting, and how CMS could account for both costs and benefits from policy interactions but did not receive specific comments in response. We are only quantifying savings of reduced paperwork for health care providers. However, the improved efficiencies outlined in this rule have potential positive consequences, which could lead to savings. Several surveys by the AMA cited in section II.D. of this final rule, list adverse qualitative consequences of the current paper-based prior authorization system, including life-threatening adverse medical events, missed, or abandoned treatments, PO 00000 Frm 00209 Fmt 4701 Sfmt 4700 8965 hospitalization, and permanent bodily damage, however, we do not have specific data related to outcomes. 2. Methodology for Savings Analysis The approach adopted in quantifying savings is to quantify those that we can reliably estimate and note that they are minimal savings. The provisions of this rule potentially affect individual physicians, physician groups, hospitals, and CAHs. However, for purposes of quantification, we initially estimate a reduced paperwork burden for individual physicians and physician groups, which shows a savings of several billion dollars over 10 years. We base the estimate on the number of hours per week spent on prior authorization, using information about individual physicians and physician groups from survey data we believe to be reliable (three surveys of several thousand groups from 2006, 2021, and 2022 cited in this section of the final rule). To calculate our estimates, we used the same physician information and made certain assumptions of its applicability to hospitals. The purpose of using this comprehensive provider information from three different periods was that no other comprehensive data set was available to identify savings from reduced paperwork. Our initial estimate was for savings of several billion dollars for individual physicians and physician groups. To estimate reductions in spending on paperwork for prior authorization for hospitals, we assumed that hospitals perform similar prior authorization activities to individual physicians and physician groups. We made this assumption because we do not have a basis for making a more accurate assumption; that is, we do not have survey data of similar quality for hospitals on the number of hours per week spent on prior authorization and the proportion of hours per week spent by physicians, nurses, and clerical staff. To support the assumptions on potential benefits for hospital prior authorization, we rely on data from previously published rules. To avoid repetition of numbers and sources we summarize all updates in this final rule, along with the estimates of the proposed rule, subtotals, and sources in Table K3. Throughout this section, numbers without specified sources, come from this table. BILLING CODE 4150–28–P E:\FR\FM\08FER2.SGM 08FER2 8966 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations TABLE K3. NUMBERS AND SOURCES USED IN SAVINGS CALCULATIONS Acute Care Hospital 3,150 Critical Access Hospital (CAH) 1,350 Outpatient Hospital 3,411 Individual MIPS Eligible Clinicians 43,117 Groups (MIPS Eligible Clinicians .... with MVP Subgroups 11,633 Median Number of Clinicians per Practice 8 CY 2023 PFS proposed rule (87 FR46370-TABLE 122 CY 2023 PFS proposed rule (87 FR46370-TABLE 122 20 Estimated Ph sician Grou s* 199 543 Total Hours per Week 13 Muhlestein, D. and Smith, N., 2016. Physician Consolidation: Rapid Movement from Small to Large Group Practices, 2013-15. Health Affairs, 35(9), pp.16381642. doi/10.1377/hlthaff.2016.0130. NIA 2021, American Medical Association (AMA) Prior Authorization (PA) Physician Survey accessible at https:llwww.documentcloud.orgld ocumentsl23710821-ama-202 lrior-authorization-surve -results 43,117 Source Unchanged 11,633 Source Unchanged 20 Source Unchanged 8 Source Unchanged 199 543 142 NIA 2022, AMA PA Physician Survey accessible at https:llwww.amaassn.orglsystem/fileslpriorauthorization-survey.pdf NOTES: *Total number of clinicians divided by the median number of clinicians per practice. (1) An increase of71 in total hospitals from the estimate in the FY 2024 proposed rules. (2) A 7. 7 percent increase in total hours spent on prior authorizations per week. To calculate the burden and savings for the final rule, we are using the data from the FY 2024 IPPS/LTCH proposed rule (88 FR 27205), FY 2024 OPPS proposed rule (88 FR 49552), and CY 2023 PFS proposed rule (87 FR 46370) rather than the CY 2023 PFS final rule (87 FR 69404) or CY 2024 PFS final rule (88 FR 78818), as these sources more accurately reflect the anticipated number of hospitals and providers impacted by our provisions beginning on January 1, 2027. We believe these sources are more reflective of the eligible hospitals and CAHs who will participate in the Medicare Promoting Interoperability Program and the MIPS eligible clinicians participating in the MIPS Promoting Interoperability performance category over time. We elected to use MIPS eligible clinician participation data from the CY 2023 PFS proposed rule, rather than the CY 2023 VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 PFS final rule or CY 2024 PFS final rule, to estimate the number of MIPS eligible clinicians reporting MIPS Promoting Interoperability data to CMS because the 45 percent reduction in the estimated number of individual MIPS eligible clinicians reporting MIPS Promoting Interoperability data between the CY 2023 PFS proposed rule (based on CY 2019 participation data) and the CY 2023 PFS final rule (based on CY 2021 participation data) appear to be lower due to the effects of the COVID–19 PHE. Likewise, the number of individual MIPS eligible clinicians reporting MIPS Promoting Interoperability data as estimated in the CY 2024 PFS final rule (based on CY 2022 participation data) remain impacted by the COVID–19 PHE,195 which formally ended on May 195 U.S. Department of Health and Human Services (2023, May 9). Fact Sheet: End of the COVID–19 Public Health Emergency. Retrieved from www.hhs.gov. https://www.hhs.gov/about/ PO 00000 Frm 00210 Fmt 4701 Sfmt 4700 11, 2023. We do not believe this reduction in MIPS eligible clinicians reporting MIPS Promoting Interoperability data will be persistent and believe it is reasonable that participation numbers in future years may revert to their former levels (before the COVID–19 PHE). Additionally, we modified another assumption for this final rule, acknowledging an increase in hours spent on prior authorization from 13 hours per week spent on prior authorization in 2021 to 14 hours per week spent on prior authorization in 2022. We did so using AMA survey data results which we believe are more reasonable. This change in data encouraged us to update our estimations accordingly. To account for these changes, and to avoid injecting our own subjective news/2023/05/09/fact-sheet-end-of-the-covid-19public-health-emergency.html. E:\FR\FM\08FER2.SGM 08FER2 ER08FE24.025</GPH> lotter on DSK11XQN23PROD with RULES2 BILLING CODE 4150–28–C Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations biases on the changes, we have included calculations using both years of the AMA prior authorization survey data. The two total savings estimates are based on the AMA prior authorization survey data, one using 2021 survey data and the other using 2022 survey data, which differed by about 10 percent. Both resulted in estimated savings of several billion dollars over 10 years. The amount and effect of these changes as well as the deviation from the proposed rule estimates are set out below. Additionally, given that estimates for MIPS eligible clinicians reporting MIPS Promoting Interoperability data in the CY 2023 PFS final rule were based on CY 2021 participation data collected during the COVID–19 PHE, we are using data published in the CY 2023 PFS proposed rule as cited in Table K3 for our calculations. We believe that this is reasonable because the MIPS eligible clinician estimates from the CY 2023 PFS proposed rule are based on prepandemic participation data from CY 2019. As noted previously, we do not believe the reductions in participation in the MIPS Promoting Interoperability performance category will continue long term. We believe it reasonable to assume that participation numbers will continue to increase, at a minimum, by the compliance dates for the policies that require API development or enhancement (beginning on January 1, 2027). 3. Physicians and Hospitals The approach presented in the proposed rule, and finalized here, computes aggregate savings for physician or group physician practices by first estimating the savings for a single individual physician or group physician practice based on supporting surveys, and then multiplying this single savings by the number of practices. Using the updated numbers from Table K3 results in savings of at least $15.8 billion over 10 years for individual and physician groups. We assume hospitals are conducting the prior authorization process in a manner similar to physicians. Thus, the individual physician and group physician practices would save at least $15.8 billion over 10 years, as shown in Table K6, and the combined physician practices and hospitals (207,515 practices consisting of 199,543 individual physician and group physician practices plus 7,972 hospitals and CAHs) would save at least $16.5 billion (207,515/199,543 × $15.8 billion). To the nearest billion, both $15.8 and $16.5 round to $16 billion. The numerical savings are the same whether we include or exclude hospitals. 4. Base Estimates of Paperwork Savings to Providers In calculating the potential savings, uncertainties arise in four areas. The result of this illustrative analysis is that we find a minimal potential savings point estimate of $15 billion (using 2021 AMA prior authorization survey data) and $16 billion (using 2022 AMA prior authorization survey data) over 10 years. To provide credibility to this savings analysis we have, where we lacked better data, underestimated any unknown quantities with minimal estimates and additionally studied the effect of a range of estimates. In the next few paragraphs, we summarize the four uncertainties and indicate how we approached the estimation. We refer readers to a more detailed discussion of these assumptions in the proposed rule (87 FR 76348). We received one comment on 8967 the quantitative estimate for providers and have responded to that comment elsewhere in the final rule. However, because no additional data was provided, we are not changing general assumptions in this final rule, except that we are updating numbers based on Table K3. a. Assumptions on the Relative Proportion of Current Workload Hours and Costs by Staff for Prior Authorization • For labor costs, we used the mean hourly wages from the BLS. • For total hours spent per week on prior authorization by staff overall we use the latest 2022 AMA survey (Table K3) rather than the estimate used in the proposed rule, which was based on the 2021 AMA prior authorization survey. • For the estimates of the current proportions by the staff of paperwork involved in prior authorization processes, the type of staff involved, and the type of physician offices, we used numbers in a survey presented by Casalino et al. (2009),196 which gave a detailed analysis based on a validated survey instrument employed in 2006. By dividing, for each staff type, the total prior authorization time spent per week across all physician practices, over the total prior authorization time spent across all practices and all staff types, we obtained the proportion of time each staff type spent per week on prior authorization. These proportions were applied to the updated total time per week spent on prior authorization as given in Table K3. The updated results are presented in Table K4 which shows that individual and group physician practices annually used, on average, at least 728 hours per year at a cost of at least $52,642 on prior authorization. NOTE: The $52,642 represents a 7.7 percent increase over the estimate in the proposed rule. This 7.7 percent increase arises from the corresponding 7.7 percent increase in total hours spent per week (Table K3). Since the sole 2022 estimate affecting this table is using 14 hours versus 13 hours it follows that had we used 13 hours the total cost per individual and group physician practice per year is 13/14 hours x $52,642 = $48,882 as stated in the proposed rule. 196 Casalino, L.P., Nicholson, S., Gans, D., Hammons, T., Morra, D., Karrison, T., & Levinson, VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 W. (May 2009). What Does It Cost Physician Practices to Interact with Health Insurance Plans? PO 00000 Frm 00211 Fmt 4701 Sfmt 4725 Health Affairs, 28(4): w533–w543. doi: 10.1377/ hlthaff.28.4.w533. E:\FR\FM\08FER2.SGM 08FER2 ER08FE24.026</GPH> lotter on DSK11XQN23PROD with RULES2 TABLE K4: TOTAL ANNUAL CURRENT COST OF PRIOR AUTHORIZATION PAPERWORK FOR INDIVIDUAL PHYSICIANS AND GROUP PRACTICES 8968 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations Here, we provide information on the row on registered nurses for demonstration purposes. Registered nurses are estimated to spend at least 9 hours per week on prior authorization, and hence, spend 467.5 hours per year (9 hours per week × 52 weeks per year). By multiplying the 467.5 hours per year spent on prior authorization by the mean wages per hour for registered nurses, $76.94, obtained from the BLS, we obtain an aggregate annual cost of $35,969 for registered nurses dealing with prior authorization. The other rows are interpreted following the same process. b. Assumptions on the Total Number of Individual and Group Physician Practices Table K4 presents the current hour and dollar burden for a single physician group and single physician office. To obtain the aggregate annual burden of prior authorizations for all physician practices, we use the data in Table K3, which includes a reference to 199,543 total individual and group physician practices. This number is used to inform Table K6 which represents a 10-year summary of annual costs. c. Assumptions on the Reduction in Hours Spent on Prior Authorization as a Result of the Provisions of This Final Rule Table K4 provides current hours spent on prior authorizations. To calculate potential savings, we assume how much these hours will be reduced as a result of the provisions of this final rule. A detailed discussion driving our assumptions was presented in the proposed rule (87 FR 76350). Based on the provisions in this final rule, we assume that physicians, nurses, and clerical staff will reduce the time they spend on prior authorization by 10 percent, 50 percent, and 25 percent respectively. Having received no comments on our estimates, we have retained these estimates for purposes of the final calculations. The savings, updated with the numbers from Table K3, is presented in Table K5. The narrative following Table K5 presents the total 10-year savings with different reduction assumptions; however, these different reduction assumptions do not materially change the range of estimates. TABLE KS: TOTAL SAVINGS FOR A SINGLE INDIVIDUAL AND GROUP PHYSICIAN PRACTICE ADOPTING THE PROVISIONS OF THIS FINAL RULE NOTE: A 7.7 percent increase in the proposed rule amount due to a 7.7 percent increase in total hours on prior authorization activities. The 2021 and 2022 estimates did not affect the assumed percent reduction in hours, 10 percent, 50 percent, 25 percent. It follows that ifwe multiply the $21,025 by 13/14 the estimated hours of prior authorization in 2021 divided by the estimated hours spent of prior authorization in 2022, we arrive at the $19,524 estimate presented in the proposed rule. d. Assumptions on the Number of Individual and Group Physician Practices Adopting the Provisions of This Final Rule As in the proposed rule, we are not assuming that over 10 years all 199,543 individual and group physician practices would adopt the provisions VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 outlined in this final rule. Instead, we assume the following: • Because of the payment consequences for not adopting the provisions of this final rule, we assume all 54,770 MIPS eligible clinicians (individual and group), a subset of the 199,543 estimated individual and group physician practices, would adopt the provisions in this rule in CY 2027 (the first year for payer compliance). This assumption of compliance by all MIPS eligible clinicians (individual and group) in the first year of payer compliance is consistent with the assumptions in the proposed rule (87 FR 76351). • As in the proposed rule, by 2036, we assume 50 percent of all individual and physician practices will adopt the provisions of this final rule. The reasons for this assumption are fully discussed in the proposed rule (87 FR 76351). However, we acknowledge that 78 percent of providers have adopted EHRs, in part to meet ONC PO 00000 Frm 00212 Fmt 4701 Sfmt 4700 requirements.197 Therefore, this estimate of 50 percent is already an underestimate of the percent of individual and physician practices who would adopt and benefit from the provisions of this rule. • We do not assume a constant increase per year but rather a gradual increase per year, starting with the participation of 54,770 MIPS eligible clinicians in 2027 and growing exponentially to 99,772 (50 percent of 199,543) individual and physician group practices in 2036. Applying these assumptions, based on the 2022 estimates results (as shown in 197 Office of the National Coordinator for Health Information Technology (n.d.). National Trends in Hospital and Physician Adoption of Electronic Health Records. Retrieved from https:// www.healthit.gov/data/quickstats/national-trendshospital-and-physician-adoption-electronic-healthrecords#:∼:text=Office%20 of%20the%20National%20 Coordinator,IT%20Quick%2DStat%20% 2361.&text=As%20of%202021%2C%20 nearly%204,%25)%20adopted%20 a%20certified%20EHR. E:\FR\FM\08FER2.SGM 08FER2 ER08FE24.027</GPH> lotter on DSK11XQN23PROD with RULES2 To provide an explanation of Table K4, we use registered nurses as an example. registered nurses spend 467.5 hours per year on prior authorization (see Table K3). If we assume that registered nurses, as a result of the finalized provisions of this rule, reduce the number of hours per week by 50 percent (about half a day, or 4 hours, per week) then they would save 233.7 hours per year (50 percent × 467.5 hours). Multiplying the hours saved, 233.7 hours, by the mean hourly wage for registered nurses, $76.94, the annual aggregate savings per physician practice is $17,984. The other rows may be interpreted similarly. 8969 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations Table K6), is at least a $15.8 billion ($15,829.3 million) savings over 10 years for individual and group physician practices. If we include hospitals by increasing the amount by 4 percent, the estimate would be at least $16.5 billion ($16,461.7 million). The estimate rounded to the nearest billion is at least $16 billion. Had we used the 2021 estimates we would obtain $15 billion in savings. This $16 billion revised estimate differs from the $15 billion estimate presented in the proposed rule is due to the change noted in Table K3: a 7.7 percent increase in hours per week spent on prior authorization (14 hours in 2022 versus 13 hours in 2021 based on the AMA survey). This result is consistent with comments from industry who thought our estimates were too low regarding the impact of prior authorization on practices and hospitals. After adjusting for this change estimate, and as noted in Tables K4 and K5, we obtain the additional savings potential. Note that the range of savings based on different assumptions of savings per staff, $13 to $20 billion over 10 years, still includes the estimate of $15 billion as noted in the proposed rule. TABLE K6: TOTAL HOURS (MILLIONS) AND DOLLARS (MILLIONS) SAVED OVER 10 YEARS AS A RESULT OF PHYSICIAN GROUPS AND HOSPITALS ADOPTING PROPOSALS OF THIS FINAL RULE 294 294 294 294 294 294 294 294 294 21,026 21,026 21,026 21,026 21,026 21,026 21,026 21,026 21,026 21 026 The headers of Table K6 show the logic and sources of the column entries. The reduced hours per year per practice spent on prior authorization for 2027 is calculated as shown here: 16.1 million hours equals 294 hours per year per practice × 199,543 practices × 27.45 percent participation. Similarly, the dollar savings per year per practice resulting from reduced time spent on prior authorization, $21,026, obtained from Table K5, when multiplied by 27.45 percent of all 199,543 group and physician practices yields $1.2 billion ($1,151.6 million) reduced dollar spending in 2027. By summing the reduced hours and dollars per year we obtain an aggregate reduction of at least 220.97 million hours and at least $15.8 billion ($15,829.3 million) in reduced spending on paperwork activities. Finally, by adding 4 percent of these numbers to account for hospitals, we obtain a total annual reduction of at least 229.27 million hours and at least a $16.5 billion ($16,461.7 million) reduction. As in the proposed rule, we obtained a range of estimates by varying the VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 27.45% 29.34% 31.36% 33.52% 35.83% 38.30% 40.94% 43.76% 199,543 199,543 199,543 199,543 199,543 199,543 199,543 199,543 199,543 199 543 assumptions of Table K5 which assume that physicians, nurses, and clerical staff save 10, 50, and 25 percent respectively. If we assume that all staff types uniformly reduce hours spent by 33 percent, then dollar spending is reduced by $13.2 billion without hospitals to $13.7 billion with hospitals factored in over 10 years. If we assume that all staff types uniformly reduce hours spent by 50 percent, then dollar spending is reduced by about $19.8 billion without hospitals to $20.6 billion with hospitals factored in. Thus, the range of savings, $10 billion to $20 billion presented in the proposed rule, is slightly narrowed in this final rule to $13 to $20 billion, including providers and hospitals. I. Summary of Costs to the Federal Government In this section, we present a 10-year Summary Table of costs (Table K9), an analysis of Federal impacts, and the Monetized Table (Table K11). To analyze the cost of this final rule to the Federal Government, we utilize a method of allocating costs by program PO 00000 Frm 00213 Fmt 4701 Sfmt 4700 16.1 17.2 18.4 19.6 21.0 22.4 24.0 25.6 27.4 1,151.6 1,231.0 1,315.8 1,406.5 1,503.4 1,607.0 1,717.7 1,836.1 1,962.6 2,097.8 (MA, Medicaid, CHIP, and QHP issuers on the FFEs). As the cost is shared by the 365 parent organizations, including state Medicaid and CHIP agencies, there is no readily available way to allocate costs per parent organization across programs since the percentage of each parent organization’s expenditures on the different programs is not publicly available. To address this, we utilize the same method used in the CMS Interoperability and Patient Access final rule (85 FR 25612). In that final rule, we used the public CMS Medical Loss Ratio (MLR) files, which break out total premiums among the various programs. The advantages and disadvantages of such an approach are fully discussed in that rule. Table K7 presents the 2021 MLR data of premiums by program and the resulting percentages by program. We use these percentages to allocate costs by program. This allocation of cost by program forms a basis to calculate the Federal Government’s cost for the proposed provisions of this rule. E:\FR\FM\08FER2.SGM 08FER2 ER08FE24.028</GPH> lotter on DSK11XQN23PROD with RULES2 2027 2028 2029 2030 2031 2032 2033 2034 2035 8970 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations TABLE K7: ALLOCATION OF PREMIUM BY PROGRAM 167 102 Individual Market Plans To calculate Federal costs for MA organizations, we use the CMS internal data used to produce the CMS Trustees’ Report. This internal data indicates that 32.99% 20.13% the Trust Fund will pay about 34 percent of plan costs over the next 10 years. The remaining costs (for the 98 to 99 percent of plans bidding below the benchmark) are borne by the plans. Similarly, we can calculate the Federal Medicaid payments using the percentages in Table K8. TABLE KS: PERCENT OF COST INCURRED BY THE FEDERAL GOVERNMENT FOR MEDICAID SPENDING lotter on DSK11XQN23PROD with RULES2 56.50% 57.80% 71.81% * Data obtamed from CMS OACT. 56.80% 58.10% 65.40% 57.30% 58.50% 65.55% 57.60% 58.80% 65.67% 57.30% 58.40% 65.49% 57.60% 58.70% 65.61% 57.90% 59.00% 65.74% 58.50% 59.50% 65.93% 58.80% 59.80% 66.06% 59.00% 6000% 66.15% Table K8 is based on the most recent projections of the CMS OACT for the FY 2024 Budget. We illustrate the interpretation of the column by explaining the items in the 2025 column. The number at the bottom of the column, 65.40 percent, answers the question ‘‘What proportion of the interoperability systems costs for Medicaid is the Federal Government expected to pay?’’ There are two components to this calculation. The first is the share of Medicaid managed care. Those costs are directly paid by the MCOs, which in turn would be expected to raise administrative costs for those plans. The Federal share of that is: Federal Medical Assistance Percentage (FMAP) 198 × the managed care (MC) share of Medicaid; for 2025, this is 58.10 percent × 56.80 percent. The second is the share of the FFS program costs. The FFS program side of Medicaid would have higher administrative costs. The Federal share of this would be 90 percent in year 1 and 75 percent after year 1. For 2025, this is equal to 75 percent × (1–56.8 percent). The sum of these two components, 58.10 percent × 56.80 percent + 75 percent × (1¥56.8 percent), equals 65.40 percent as shown in the bottom row. When we multiply, in Table K9, the total annual cost of interoperability for Medicaid by 65.40 percent we obtain the amount the Federal Government is expected to pay BILLING CODE 4150–28–P 198 Federal Medical spending is determined by the amount that states spend. The Federal share for most health care services is determined by the FMAP. The FMAP is based on a formula that provides higher reimbursement to states with lower per capita incomes relative to the national average. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 PO 00000 Frm 00214 Fmt 4701 Sfmt 4700 for the interoperability system costs for Medicaid. It should be noted that although the compliance dates for policies in this final rule that do not require API development or enhancement are in 2026, and the compliance dates for policies that require API development or enhancement are in 2027. We expect plans to begin constructing software systems for the provisions that require API development or enhancement upon publication of this final rule. Based on the discussion presented in Tables K7 and K8, Table K9 presents the calculation of all numerical impacts of this final rule by program, government, and QHP issuers on the FFEs. E:\FR\FM\08FER2.SGM 08FER2 ER08FE24.029</GPH> ER08FE24.030</GPH> Managed Care* share of Medicaid Federal share of Medicaid Managed Care* Weiizhted cost bv vear lotter on DSK11XQN23PROD with RULES2 Jkt 262001 72 72 72 72 72 72 PO 00000 Frm 00215 Fmt 4701 Sfmt 4700 08FER2 8971 Authorization measure for MIPS and the Medicare Promoting Interoperability Program and compliance dates in 2026 E:\FR\FM\08FER2.SGM section, the data in Table K9 is based on 2027 compliance dates for policies that require API development or enhancement and the Electronic Prior 2025 2026 2027 2028 2029 2030 2031 2032 2033 182 199 142 142 142 142 142 142 142 0 0 0.013 0.013 0.013 0.013 0.013 0.013 0.013 182 199 142 142 142 142 142 142 142 85 85 93 67 67 67 67 67 67 67 60 60 66 47 47 47 47 47 47 47 37 37 40 29 29 29 29 29 29 29 87 97 104 73 29 29 32 23 23 23 23 22 22 22 43 39 43 31 31 31 31 31 31 31 26 26 28 20 20 20 20 21 21 21 56 56 61 44 44 44 44 44 44 44 17 21 23 16 16 16 16 16 16 16 37 37 40 29 29 29 29 29 29 29 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations BILLING CODE 4150–28–C 18:23 Feb 07, 2024 For Table K9: • As explained in connection with Table J9 in the Collection of Information VerDate Sep<11>2014 ER08FE24.031</GPH> TABLE K9: 10-YEAR TOTALS OF THIS FINAL RULE BY YEAR, PAYER, PROGRAM, PROVIDERS, HOSPITALS, AND CRITICAL ACCESS HOSPITALS AND TO THE FEDERAL GOVERNMENT (MILLIONS$) 8972 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations lotter on DSK11XQN23PROD with RULES2 for the policies that do not require API development or enhancement. • The bottom-line totals in the columns of Table J9 labeled ‘‘1st Year Cost’’ through ‘‘4th Year Cost’’ are the totals found in the ‘‘Total Cost’’ column of Table K9 in rows 2024 through 2027 respectively. The totals in the column ‘‘4th and Subsequent Year Costs’’ in Table J9 are found in the rows labeled 2028 through 2033 in the ‘‘Total Cost’’ column of Table K9. • The Total Cost to MIPS Eligible Clinicians, Eligible Hospitals and CAHs column reflects the aggregate cost of producing reports for MIPS eligible clinicians (including individual clinicians and groups), eligible hospitals, and CAHs, as found in Table J9 for years 2027 and further. • The total 10-year cost (excluding PTC payments and savings from prior authorization) is, as shown in Table K9, $1.6 billion. This number uses the primary estimates for the provisions that require API development or enhancement. The low and high 10-year total costs are $0.8 billion and $2.3 billion, respectively. • The Cost of Final Rule to Payers by Program columns: We applied the percentages from Table K7 to obtain the cost of the rule to payers by program (MA, Medicaid, CHIP, and QHP issuers on the FFEs). • The Cost of Final Rule to Government by Program columns: For the QHP issuers on the FFEs, the government does not pay anything. For managed care the Government pays approximately 34 percent (the exact amount varying slightly from year to year and was obtained from projections by OACT). For Medicaid, we applied the percentages of payment by the Federal Government discussed in the narrative in Table K8 to obtain the cost by program. • PTC Payments: The Government does not reimburse QHP issuers on the FFEs, neither prospectively nor retrospectively, for their expenses in VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 furnishing health benefits. However, the government offers QHP enrollees PTCs to help cover the cost of premiums for the plans. QHP issuers on the FFEs have the option to deal with increased costs by either temporarily absorbing them (for purposes of market competitiveness—see, however, a caveat elsewhere in this RIA), increasing premiums to enrollees, or reducing nonessential health benefits. To the extent that issuers increase premiums for individual market QHPs on the FFEs, there would be Federal PTC impacts. The purpose of the PTC is to assist enrollees in paying premiums. Because PTC is available only if an individual purchases a QHP on an Exchange and the individual generally has a household income between 100 and 400 percent of the Federal Poverty Level, the PTC estimates apply only to Exchange plans. Note, the Inflation Reduction Act of 2022 (IRA) 199 extended the expanded PTC eligibility provision set forth in the American Rescue Plan Act of 2021 (ARP) through the 2025 plan year. In the PTC estimate, we have accounted for the fact that some issuers have both Exchange and non-Exchange plans, and some issuers have only nonExchange plans. We reflected these assumptions with global adjustments, so we believe the estimates are reasonable in aggregate. Specifically, the methodology to estimate the PTC impact of the projected expense burden is consistent with the method used to estimate the PTC impact in the CMS Interoperability and Patient Access final rule (85 FR 25612). Within the FFE states, the estimated expense burden would impact premium rates in the individual market and is spread across both Exchange and non-Exchange plans. PTCs are only paid in the Exchanges and are calculated as a function of the second lowest-cost silver plan and the 199 H.R. 5376—117th Congress (2021–2022): Inflation Reduction Act of 2022 (2022, August 16). Retrieved from https://www.congress.gov/bill/ 117th-congress/house-bill/5376. PO 00000 Frm 00216 Fmt 4701 Sfmt 4700 eligible individual’s household income. The estimate of these impacts uses the assumption that the industry would increase the second lowest-cost silver plan premium rate in the same amount as the overall premium rate increase. This assumption allows the application of the overall rate increase to the projected PTC payments in the FFE states to estimate the impact on PTC payments. • The total cost to the government is the sum of payments related to each program. This payment is a transfer from the Government to payers for MA and Medicaid, CHIP, and QHP enrollees. • For MA organizations, Medicaid and CHIP, the remaining costs are the difference between the total cost to payers and what the Federal Government pays. For the individual market, the remaining costs to payers would be the total cost absorbed by the payers and not passed on through premium increases. Since the PTC is paid on behalf of individuals and not the payers, it therefore does not reduce the expenses of the payers. The dollar savings from reduced paperwork burden for an increase in using electronic prior authorization (Tables K4 and K5) is not included in Table K9. Table K10 describes how the various plans (and states) would bear the costs remaining after federal payments. We follow the same methodology and discussion presented in the CMS Interoperability and Patient Access final rule (85 FR 25612). In the table we explain the possible ways payers may manage extra implementation costs. We emphasize that Table K10 only includes possibilities. The impacted payers would make decisions about how to defray these remaining costs based on market dynamics and internal business decisions; we have no uniform way of predicting what these actual behaviors and responses will be. E:\FR\FM\08FER2.SGM 08FER2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations 8973 TABLE Kl0: HOW PAYERS COULD DEFRAY REMAINING COSTS QHP Issuers Medicaid/CHIP Medicare Advantage (MA) There are two primary alternatives available to QHPs: An issuer may increase its premium rates or it may decide to absorb the costs. The decision any particular issuer makes will depend on how that issuer considers each of the following issues when they are setting their rates. i) Competition, ii) Regulatory requirements, iii) Expected claims costs, iv) Expected non-benefit expenses, v) Profit margins. Some QHP issuers may request an exception from the fmal provisions that re uire API develo ment. State Medicaid and CHIP agencies would bear the cost (under a dollar per beneficiary relative to the annual expenditures of several thousand dollars per beneficiary). Medicaid managed care plans and CHIP managed care entities are fully capitated but may have to defer first year costs if they obtain an exception or extension. Under certain circumstances, states operating Medicaid and CHIP FFS programs can request an extension or an exemption from the final provisions that re uire API develo ment. MA organizations in their June-submitted bids would address the reduced rebates (arising from increased bid costs due to the increased costs of this final rule being included in the bid) by either: ( 1) temporarily absorbing costs by reducing profit margins; (see, however, a caveat elsewhere in this RIA); (2) reducing supplemental benefits paid for by the rebates; or (3) raising enrollee cost-sharing (or reducing additional, rebate-funded benefits). Tax deferment and amortization as applicable ameliorates cost. Capital costs are spread over the entire parent organization enrollees. New plans are allowed to enter with initial ne ative mar ins with the ex ectation that the will stabilize over the first few ears. • Individual Market Plans: Individual market plans have the option of absorbing costs or passing costs to enrollees in the form of higher premiums. In some cases, for reasons of market competitiveness, plans may absorb the increased costs rather than increase premiums. • Medicaid and CHIP: Assuming roughly 71 million patients enrolled nationally (inclusive of state Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities), Medicaid and CHIP would see an added cost of under a dollar per beneficiary per year; this contrasts with a total cost per beneficiary per year for the Medicaid and CHIP programs of several thousand dollars.200 • Medicare Advantage: In their bids (submitted in the month of June prior to the beginning of the coverage year), MA plans would address the reduced rebates (arising from increased bid costs due to the increased costs of this final rule being included in the bid) by either: temporarily absorbing costs by reducing profit margins, reducing the supplemental benefits paid for by the rebates, or raising enrollee cost-sharing or premium. We believe many plans, for competitive reasons, would choose to retain a zero-dollar premium increase and either absorb losses for 1 year or reduce rebate-funded supplemental benefits. We received no comments specific to Table K10 or the methods impacted payers will use to deal with the costs of this rule and are therefore finalizing it as is. J. Accounting Statement and Table As required by OMB Circular A–4 (available at https:// www.whitehouse.gov/wp-content/ uploads/legacy_drupal_files/omb/ circulars/A4/a-4.pdf), the following table, Table K11, summarizes the classification of annualized costs associated with the provisions of this final rule for the 10 years, 2024 through 2033. This accounting table is based on Table K9 and includes the costs of this final rule to certain providers, including hospitals and CAHs, MA organizations, state Medicaid and CHIP programs, and QHP issuers on the FFEs. It does not include the potential savings from Table K6 arising from reduced burden due to providers, hospitals, and CAHs using electronic prior authorization. Minor discrepancies in totals reflect use of underlying spreadsheets, rather than intermediate rounded amounts. Table K11 is stated in 2023 dollars, with expected compliance dates in 2027 for the provisions of this final rule that require API development or enhancement. 200 Centers for Medicare and Medicaid Services Newsroom (2020, January 30). Medicaid Facts and VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 Figures | CMS. Retrieved from https:// PO 00000 Frm 00217 Fmt 4701 Sfmt 4725 www.cms.gov/newsroom/fact-sheets/medicaidfacts-and-figures. E:\FR\FM\08FER2.SGM 08FER2 ER08FE24.032</GPH> ER08FE24.033</GPH> lotter on DSK11XQN23PROD with RULES2 TABLE Kll: MONETIZED ACCOUNTING TABLE (MILLIONS$) 8974 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations In accordance with the provisions of Executive Order 12866, this final rule was reviewed by OMB. Chiquita Brooks-LaSure, Administrator of the Centers for Medicare & Medicaid Services, approved this document on January 12, 2024. List of Subjects Administrative practice and procedure, Health facilities, Health maintenance organizations (HMO), Medicare, Penalties, Privacy, Reporting and recordkeeping requirements. 42 CFR Part 431 Grant programs—health, Health facilities, Medicaid, Privacy, Reporting and recordkeeping requirements, State fair hearings. 42 CFR Part 435 Aid to Families with Dependent Children, Grant programs—health, Medicaid, Notices, Reporting and recordkeeping requirements, Supplemental Security Income (SSI), Wages. 42 CFR Part 438 Grant programs—health, Medicaid, Reporting and recordkeeping requirements. 42 CFR Part 440 Grant programs—health, Medicaid. 42 CFR Part 457 Administrative practice and procedure, Grant programs—health, Health insurance, Reporting and recordkeeping requirements. lotter on DSK11XQN23PROD with RULES2 45 CFR Part 156 Administrative practice and procedure, Advertising, Brokers, Conflict of interests, Consumer protection, Grant programs—health, Grants administration, Health care, Health insurance, Health maintenance organizations (HMO), Health records, Hospitals, Indians, Individuals with disabilities, Intergovernmental relations, Loan programs—health, Medicaid, Organization and functions (Government agencies), Prescription drugs, Public assistance programs, Reporting and recordkeeping requirements, Technical assistance, Women, Youth. For the reasons set forth in the preamble, the Centers for Medicare & Medicaid Services amends 42 CFR chapter IV and the Department of Health and Human Services amends 45 CFR part 156 as set forth below: 18:23 Feb 07, 2024 PART 422—MEDICARE ADVANTAGE PROGRAM 1. The authority citation for part 422 continues to read as follows: ■ Authority: 42 U.S.C. 1302, 1306, 1395w–22 through 1395w–28, and 1395hh. 2. Section 422.119 is amended by— a. In paragraph (b)(1)(ii), removing the word ‘‘and’’ at the end of the paragraph; ■ b. Revising paragraph (b)(1)(iii); ■ c. Adding paragraphs (b)(1)(iv) and (v); and ■ d. Revising paragraphs (c)(1), (c)(4)(ii)(C), (e)(2), (f), and (h). The revisions and additions read as follows: ■ ■ 42 CFR Part 422 VerDate Sep<11>2014 TITLE 42—PUBLIC HEALTH Jkt 262001 § 422.119 Access to and exchange of health data and plan information. * * * * * (b) * * * (1) * * * (iii) All data classes and data elements included in a content standard in 45 CFR 170.213 that are maintained by the MA organization no later than 1 business day after the MA organization receives the data; and (iv) Beginning January 1, 2027, the information in paragraph (b)(1)(iv)(A) of this section about prior authorizations for items and services (excluding drugs, as defined in paragraph (b)(1)(v) of this section), according to the timelines in paragraph (b)(1)(iv)(B) of this section. (A) The prior authorization request and decision, including all of the following, as applicable: (1) The prior authorization status. (2) The date the prior authorization was approved or denied. (3) The date or circumstance under which the prior authorization ends. (4) The items and services approved. (5) If denied, a specific reason why the request was denied. (6) Related structured administrative and clinical documentation submitted by a provider. (B) The information in paragraph (b)(1)(iv)(A) of this section must— (1) Be accessible no later than 1 business day after the MA organization receives a prior authorization request; (2) Be updated no later than 1 business day after any status change; and (3) Continue to be accessible for the duration that the authorization is active and at least 1 year after the prior authorization’s last status change. (v) Drugs are defined for the purposes of paragraph (b)(1)(iv) of this section as any and all drugs covered by the MA organization, including any products that constitute a Part D drug, as defined PO 00000 Frm 00218 Fmt 4701 Sfmt 4700 by § 423.100 of this chapter, and are covered under the Medicare Part D benefit. * * * * * (c) * * * (1) Must implement and maintain API technology conformant with 45 CFR 170.215(a)(1), (b)(1)(i), (c)(1), and (e)(1); * * * * * (4) * * * (ii) * * * (C) Using the updated version of the standard, implementation guide, or specification does not disrupt an end user’s ability to access the data specified in paragraph (b) of this section or §§ 422.120, 422.121, and 422.122 through the required APIs. * * * * * (e) * * * (2) Makes this determination using objective, verifiable criteria that are applied fairly and consistently across all apps and developers through which parties seek to access electronic health information, as defined in 45 CFR 171.102, including but not limited to, criteria that rely on automated monitoring and risk mitigation tools. (f) Reporting on Patient Access API usage. Beginning in 2026, by March 31 following any calendar year that it offers an MA plan, an MA organization must report to CMS the following metrics, in the form of aggregated, de-identified data, for the previous calendar year at the contract level in the form and manner specified by the Secretary: (1) The total number of unique enrollees whose data are transferred via the Patient Access API to a health app designated by the enrollee. (2) The total number of unique enrollees whose data are transferred more than once via the Patient Access API to a health app designated by the enrollee. * * * * * (h) Applicability. An MA organization must comply with the requirements of this section beginning in paragraphs (a) through (e) and (g) of this section beginning January 1, 2021, unless otherwise specified, and with the requirements in paragraph (f) of this section beginning in 2026, with regard to data: (1) With a date of service on or after January 1, 2016; and (2) That are maintained by the MA organization. ■ 3. Section 422.121 is added to read as follows: § 422.121 Access to and exchange of health data for providers and payers. (a) Application programming interface to support data exchange from E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations payers to providers—Provider Access API. Beginning January 1, 2027, an MA organization must do the following: (1) API requirements. Implement and maintain an application programming interface (API) conformant with all of the following: (i) Section 422.119(c)(2) through (4), (d), and (e). (ii) The standards in 45 CFR 170.215(a)(1), (b)(1)(i), (c)(1), and (d)(1). (2) Provider access. Make the data specified at § 422.119(b) with a date of service on or after January 1, 2016, excluding provider remittances and enrollee cost-sharing information, that are maintained by the MA organization available to in-network providers via the API required in paragraph (a)(1) of this section no later than 1 business day after receiving a request from such a provider, if all the following conditions are met: (i) The MA organization authenticates the identity of the provider that requests access and attributes the enrollee to the provider under the attribution process described in paragraph (a)(3) of this section. (ii) The enrollee does not opt out as described in paragraph (a)(4) of this section. (iii) Disclosure of the data is not prohibited by other applicable law. (3) Attribution. Establish and maintain a process to associate enrollees with their in-network providers to enable data exchange via the Provider Access API. (4) Opt out and patient educational resources. (i) Establish and maintain a process to allow an enrollee or the enrollee’s personal representative to opt out of the data exchange described in paragraph (a)(2) of this section and to change their permission at any time. That process must be available before the first date on which the MA organization makes enrollee information available via the Provider Access API and at any time while the enrollee is enrolled with the MA organization. (ii) Provide information to enrollees in plain language about the benefits of API data exchange with their providers, their opt out rights, and instructions both for opting out of data exchange and for subsequently opting in, as follows: (A) Before the first date on which the MA organization makes enrollee information available through the Provider Access API. (B) No later than 1 week after the coverage start date or no later than 1 week after receiving acceptance of enrollment from CMS, whichever is later. (C) At least annually. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 (D) In an easily accessible location on its public website. (5) Provider resources. Provide on its website and through other appropriate provider communications, information in plain language explaining the process for requesting enrollee data using the Provider Access API required in paragraph (a)(1) of this section. The resources must include information about how to use the MA organization’s attribution process to associate enrollees with their providers. (b) Application programming interface to support data exchange between payers—Payer-to-Payer API. Beginning January 1, 2027, an MA organization must do the following: (1) API requirements. Implement and maintain an API conformant with all of the following: (i) Section 422.119(c)(2) through (4), (d), and (e). (ii) The standards in 45 CFR 170.215(a)(1), (b)(1)(i), and (d)(1). (2) Opt in. Establish and maintain a process to allow enrollees or their personal representatives to opt into the MA organization’s payer to payer data exchange with the enrollee’s previous payer(s), described in paragraphs (b)(4) and (5) of this section, and with concurrent payer(s), described in paragraph (b)(6) of this section, and to change their permission at any time. (i) The opt in process must be offered as follows: (A) To current enrollees, no later than the compliance date. (B) To new enrollees, no later than 1 week after the coverage start date or no later than 1 week after receiving acceptance of enrollment from CMS, whichever is later. (ii) If an enrollee does not respond or additional information is necessary, the MA organization must make reasonable efforts to engage with the enrollee to collect this information. (3) Identify previous and concurrent payers. Establish and maintain a process to identify a new enrollee’s previous and concurrent payer(s) to facilitate the Payer-to-Payer API data exchange. The information request process must start as follows: (i) For current enrollees, no later than the compliance date. (ii) For new enrollees, no later than 1 week after the coverage start date or no later than 1 week after receiving acceptance of enrollment from CMS, whichever is later. (iii) If an enrollee does not respond or additional information is necessary, the MA organization must make reasonable efforts to engage with the enrollee to collect this information. PO 00000 Frm 00219 Fmt 4701 Sfmt 4700 8975 (4) Exchange request requirements. Exchange enrollee data with other payers, consistent with the following requirements: (i) The MA organization must request the data listed in paragraph (b)(4)(ii) of this section through the enrollee’s previous payers’ API, if all the following conditions are met: (A) The enrollee has opted in, as described in paragraph (b)(2) of this section. (B) The exchange is not prohibited by other applicable law. (ii) The data to be requested are all of the following with a date of service within 5 years before the request: (A) Data specified in § 422.119(b) excluding the following: (1) Provider remittances and enrollee cost-sharing information. (2) Denied prior authorizations. (B) Unstructured administrative and clinical documentation submitted by a provider related to prior authorizations. (iii) The MA organization must include an attestation with this request affirming that the enrollee is enrolled with the MA organization and has opted into the data exchange. (iv) The MA organization must complete this request as follows: (A) No later than 1 week after the payer has sufficient identifying information about previous payers and the enrollee has opted in. (B) At an enrollee’s request, within 1 week of the request. (v) The MA organization must receive, through the API required in paragraph (b)(1) of this section, and incorporate into its records about the enrollee, any data made available by other payers in response to the request. (5) Exchange response requirements. Make available the data specified in paragraph (b)(4)(ii) of this section that are maintained by the MA organization to other payers via the API required in paragraph (b)(1) of this section within 1 business day of receiving a request, if all the following conditions are met: (i) The payer that requests access has its identity authenticated and includes an attestation with the request that the patient is enrolled with the payer and has opted into the data exchange. (ii) Disclosure of the data is not prohibited by other applicable law. (6) Concurrent coverage data exchange requirements. When an enrollee has provided sufficient identifying information about concurrent payers and has opted in as described in paragraph (b)(2) of this section, an MA organization must do the following, through the API required in paragraph (b)(1) of this section: (i) Request the enrollee’s data from all known concurrent payers as described E:\FR\FM\08FER2.SGM 08FER2 8976 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations in paragraph (b)(4) of this section, and at least quarterly thereafter while the enrollee is enrolled with both payers. (ii) Respond as described in paragraph (b)(5) of this section within 1 business day of a request from any concurrent payers. If agreed upon with the requesting payer, the MA organization may exclude any data that were previously sent to or originally received from the concurrent payer. (7) Patient educational resources. Provide information to enrollees in plain language, explaining at a minimum: the benefits of Payer-to-Payer API data exchange, their ability to opt in or withdraw that permission, and instructions for doing so. The MA organization must provide the following resources: (i) When requesting an enrollee’s permission for Payer-to-Payer API data exchange, as described in paragraph (b)(2) of this section. (ii) At least annually, in appropriate mechanisms through which it ordinarily communicates with current enrollees. (iii) In an easily accessible location on its public website. ■ 4. Section 422.122 is added to read as follows: lotter on DSK11XQN23PROD with RULES2 § 422.122 Prior authorization requirements. (a) Communicating a reason for denial. Beginning January 1, 2026, if the MA organization denies a prior authorization request (excluding request for coverage of drugs as defined in § 422.119(b)(1)(v)), in accordance with the timeframes established in §§ 422.568(b)(1) and 422.572(a)(1), the response to the provider must include a specific reason for the denial, regardless of the method used to communicate that information. (b) Prior Authorization Application Programming Interface (API). Beginning January 1, 2027, an MA organization must implement and maintain an API conformant with § 422.119(c)(2) through (4), (d), and (e), and the standards in 45 CFR 170.215(a)(1), (b)(1)(i), and (c)(1) that— (1) Is populated with the MA organization’s list of covered items and services (excluding drugs, as defined in § 422.119(b)(1)(v)) that require prior authorization; (2) Can identify all documentation required by the MA organization for approval of any items or services that require prior authorization; (3) Supports a Health Insurance Portability and Accountability Act (HIPAA)-compliant prior authorization request and response, as described in 45 CFR part 162; and VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 (4) Communicates the following information about prior authorization requests: (i) Whether the MA organization— (A) Approves the prior authorization request (and the date or circumstance under which the authorization ends); (B) Denies the prior authorization request; or (C) Requests more information. (ii) If the MA organization denies the prior authorization request, it must include a specific reason for the denial. (5) In addition to the requirements of this section, an MA organization using prior authorization polices or making prior authorization decisions must meet all other applicable requirements under this part, including § 422.138 and the requirements in subpart M of this part. (c) Publicly reporting prior authorization metrics. Beginning in 2026, following each calendar year that it offers an MA plan, an MA organization must report prior authorization data, excluding data on drugs as defined in § 422.119(b)(1)(v), at the MA contract level by March 31. The MA organization must make the following data from the previous calendar year publicly accessible by posting them on its website: (1) A list of all items and services that require prior authorization. (2) The percentage of standard prior authorization requests that were approved, aggregated for all items and services. (3) The percentage of standard prior authorization requests that were denied, aggregated for all items and services. (4) The percentage of standard prior authorization requests that were approved after appeal, aggregated for all items and services. (5) The percentage of prior authorization requests for which the timeframe for review was extended, and the request was approved, aggregated for all items and services. (6) The percentage of expedited prior authorization requests that were approved, aggregated for all items and services. (7) The percentage of expedited prior authorization requests that were denied, aggregated for all items and services. (8) The average and median time that elapsed between the submission of a request and a determination by the MA plan, for standard prior authorizations, aggregated for all items and services. (9) The average and median time that elapsed between the submission of a request and a decision by the MA plan for expedited prior authorizations, aggregated for all items and services. ■ 5. Section 422.568 is amended by— PO 00000 Frm 00220 Fmt 4701 Sfmt 4700 a. Revising paragraph (b)(1); b. Redesignating paragraph (b)(2) as paragraph (b)(3); ■ c. Adding new paragraph (b)(2); and ■ d. In newly redesignated paragraph (b)(3), removing the phrase ‘‘under the provisions in paragraph (b)(1)(i) of this section’’ and adding in its place the phrase ‘‘under the provisions in paragraph (b)(2) of this section.’’ The revision and addition read as follows: ■ ■ § 422.568 Standard timeframes and notice requirements for organization determinations. * * * * * (b) * * * (1) Requests for service or item. Except as provided in paragraph (b)(2) of this section, when a party has made a request for an item or service, the MA organization must notify the enrollee of its determination as expeditiously as the enrollee’s health condition requires but no later than either of the following: (i) For a service or item not subject to the prior authorization rules in § 422.122, 14 calendar days after receiving the request for the standard organization determination. (ii) Beginning on or after January 1, 2026, for a service or item subject to the prior authorization rules in § 422.122, 7 calendar days after receiving the request for the standard organization determination. (2) Extensions; requests for service or item—(i) Extension of timeframe on a request for service or item. The MA organization may extend the timeframe by up to 14 calendar days under any of the following circumstances: (A) The enrollee requests the extension. (B) The extension is justified and in the enrollee’s interest due to the need for additional medical evidence from a noncontract provider that may change an MA organization’s decision to deny an item or service. (C) The extension is justified due to extraordinary, exigent, or other nonroutine circumstances and is in the enrollee’s interest. (ii) Notice of extension. (A) When the MA organization extends the timeframe, it must— (1) Notify the enrollee in writing of the reasons for the delay; and (2) Inform the enrollee of the right to file an expedited grievance if the enrollee disagrees with the MA organization’s decision to grant an extension. (B) The MA organization must notify the enrollee of its determination as expeditiously as the enrollee’s health E:\FR\FM\08FER2.SGM 08FER2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations Authority: 42 U.S.C. 1302. condition requires, but no later than upon expiration of the extension. * * * * * § 422.570 [Amended] 6. Section 422.570 is amended in paragraph (d)(1) by removing the phrase ‘‘request to the standard timeframe and make the determination within the 72hour or 14-day timeframe, as applicable, established’’ and adding in its place the phrase ‘‘request to a standard organization determination and make the determination within the applicable timeframe, established’’. ■ 7. Section 422.631 is amended by revising paragraphs (d)(2)(i)(B), (d)(2)(iv)(B)(1), and (d)(2)(iv)(B)(2)(i) to read as follows: ■ § 422.631 Integrated organization determinations. lotter on DSK11XQN23PROD with RULES2 * * * * * (d) * * * (2) * * * (i) * * * (B) Except as described in paragraph (d)(2)(i)(A) of this section, the applicable integrated plan must send a notice of its integrated organization determination as expeditiously as the enrollee’s health condition requires but no later than either of the following: (1) For a service or item not subject to the prior authorization rules in § 422.122, 14 calendar days after receiving the request for the standard integrated organization determination. (2) Beginning on or after January 1, 2026, for a service or item subject to the prior authorization rules in § 422.122, 7 calendar days after receiving the request for the standard integrated organization determination. * * * * * (iv) * * * (B) * * * (1) Automatically transfer a request to the standard timeframe and make the determination within the applicable timeframe established in paragraph (d)(2)(i)(B) of this section for a standard integrated organization determination. The timeframe begins the day the applicable integrated plan receives the request for expedited integrated organization determination. (2) * * * (i) Explains that the applicable integrated plan will process the request using the timeframe for standard integrated organization determinations; * * * * * PART 431—STATE ORGANIZATION AND GENERAL ADMINISTRATION 8. The authority citation for part 431 continues to read as follows: ■ VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 9. Section 431.60 is amended by— a. Revising paragraph (b)(3); b. Adding paragraphs (b)(5) and (6); c. Revising paragraphs (c)(1), (c)(4)(ii)(C), and (e)(2); ■ d. Removing paragraph (g); ■ e. Redesignating paragraph (f) as paragraph (g); and ■ f. Adding new paragraph (f) and paragraph (h). The revisions and addition read as follows: ■ ■ ■ ■ § 431.60 Beneficiary access to and exchange of data. * * * * * (b) * * * (3) All data classes and data elements included in a content standard in 45 CFR 170.213 that are maintained by the State no later than 1 business day after the State receives the data; and * * * * * (5) Beginning January 1, 2027, the information in paragraph (b)(5)(i) of this section about prior authorizations for items and services (excluding drugs as defined in paragraph (b)(6) of this section), according to the timelines in paragraph (b)(5)(ii) of this section. (i) The prior authorization request and decision, including all of the following, as applicable: (A) The prior authorization status. (B) The date the prior authorization was approved or denied. (C) The date or circumstance under which the prior authorization ends. (D) The items and services approved. (E) If denied, a specific reason why the request was denied. (F) Related structured administrative and clinical documentation submitted by a provider. (ii) The information in paragraph (b)(5)(i) of this section must— (A) Be accessible no later than 1 business day after the State receives a prior authorization request; (B) Be updated no later than 1 business day after any status change; and (C) Continue to be accessible for the duration that the authorization is active and at least 1 year after the prior authorization’s last status change. (6) Drugs are defined for the purposes of paragraph (b)(5) of this section as any and all drugs covered by the State. * * * * * (c) * * * (1) Must implement and maintain API technology conformant with 45 CFR 170.215(a)(1), (b)(1)(i), (c)(1), and (e)(1); * * * * * (4) * * * (ii) * * * PO 00000 Frm 00221 Fmt 4701 Sfmt 4700 8977 (C) Using the updated version of the standard, implementation guide, or specification does not disrupt an end user’s ability to access the data specified in paragraph (b) of this section or §§ 431.61, 431.70, and 431.80, through the required APIs. * * * * * (e) * * * (2) Makes this determination using objective, verifiable criteria that are applied fairly and consistently across all apps and developers through which parties seek to access electronic health information, as defined in 45 CFR 171.102, including but not limited to criteria that rely on automated monitoring and risk mitigation tools. * * * * * (f) Reporting on Patient Access API usage. Beginning in 2026, by March 31 of each year, a State must report to CMS the following metrics, in the form of aggregated, de-identified data, for the previous calendar year at the State level in the form and manner specified by the Secretary: (1) The total number of unique beneficiaries whose data are transferred via the Patient Access API to a health app designated by the beneficiary; and (2) The total number of unique beneficiaries whose data are transferred more than once via the Patient Access API to a health app designated by the beneficiary. * * * * * (h) Applicability. A State must comply with the requirements in paragraphs (a) through (e) and (g) of this section beginning January 1, 2021, and with the requirements in paragraph (f) of this section beginning in 2026, with regard to data: (1) With a date of service on or after January 1, 2016; and (2) That are maintained by the State. ■ 10. Section 431.61 is added to read as follows: § 431.61 Access to and exchange of health data for providers and payers. (a) Application programming interface to support data exchange from payers to providers—Provider Access API. Beginning January 1, 2027, unless granted an extension or exemption under paragraph (c) of this section, a State must do the following: (1) API requirements. Implement and maintain an application programming interface (API) conformant with all of the following: (i) Section 431.60(c)(2) through (4), (d), and (e). (ii) The standards in 45 CFR 170.215(a)(1), (b)(1)(i), (c)(1), and (d)(1). (2) Provider access. Make the data specified in § 431.60(b) with a date of E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8978 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations service on or after January 1, 2016, excluding provider remittances and beneficiary cost-sharing information, that are maintained by the State available to enrolled Medicaid providers via the API required in paragraph (a)(1) of this section no later than 1 business day after receiving a request from such a provider, if all the following conditions are met: (i) The State authenticates the identity of the provider that requests access and attributes the beneficiary to the provider under the attribution process described in paragraph (a)(3) of this section. (ii) The beneficiary does not opt out as described in paragraph (a)(4) of this section. (iii) Disclosure of the data is not prohibited by other applicable law. (3) Attribution. Establish and maintain a process to associate beneficiaries with their enrolled Medicaid providers to enable data exchange via the Provider Access API. (4) Opt out and patient educational resources. (i) Establish and maintain a process to allow a beneficiary or the beneficiary’s personal representative to opt out of the data exchange described in paragraph (a)(2) of this section and to change their permission at any time. That process must be available before the first date on which the State makes beneficiary information available via the Provider Access API and at any time while the beneficiary is enrolled with the State. (ii) Provide information to beneficiaries in plain language about the benefits of API data exchange with their providers, their opt out rights, and instructions both for opting out of data exchange and for subsequently opting in, as follows: (A) Before the first date on which the State makes beneficiary information available through the Provider Access API. (B) No later than 1 week after enrollment. (C) At least annually. (D) In an easily accessible location on its public website. (5) Provider resources. Provide on its website and through other appropriate provider communications, information in plain language explaining the process for requesting beneficiary data using the Provider Access API required in paragraph (a)(1) of this section. The resources must include information about how to use the State’s attribution process to associate beneficiaries with their providers. (b) Application programming interface to support data exchange between payers—Payer-to-Payer API. Beginning January 1, 2027, unless VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 granted an extension or exemption under paragraph (c) of this section, a State must do the following: (1) API requirements. Implement and maintain an API conformant with all of the following: (i) Section 431.60(c)(2) through (4), (d), and (e). (ii) The standards in 45 CFR 170.215(a)(1), (b)(1)(i), and (d)(1). (2) Opt in. Establish and maintain a process to allow beneficiaries or their personal representatives to opt into the State’s payer to payer data exchange with the beneficiary’s previous payer(s), described in paragraphs (b)(4) and (5) of this section, and with concurrent payer(s), described in paragraph (b)(6) of this section, and to change their permission at any time. (i) The opt in process must be offered as follows: (A) To current beneficiaries, no later than the compliance date. (B) To new beneficiaries, no later than 1 week after enrollment. (ii) If a beneficiary has coverage through any Medicaid MCO, prepaid inpatient health plan (PIHP), or prepaid ambulatory health plan (PAHP) within the same State while enrolled in Medicaid, the State must share their opt in permission with those MCO, PIHP, or PAHP to allow the Payer-to-Payer API data exchange described in this section. (iii) If a beneficiary does not respond or additional information is necessary, the State must make reasonable efforts to engage with the beneficiary to collect this information. (3) Identify previous and concurrent payers. Establish and maintain a process to identify a new beneficiary’s previous and concurrent payer(s) to facilitate the Payer-to-Payer API data exchange. The information request process must start as follows: (i) For current beneficiaries, no later than the compliance date. (ii) For new beneficiaries, no later than 1 week after enrollment. (iii) If a beneficiary does not respond or additional information is necessary, the State must make reasonable efforts to engage with the beneficiary to collect this information. (4) Exchange request requirements. Exchange beneficiary data with other payers, consistent with the following requirements: (i) The State must request the data specified in paragraph (b)(4)(ii) of this section through the beneficiary’s previous payers’ API, if all the following conditions are met: (A) The beneficiary has opted in, as described in paragraph (b)(2) of this section, except for data exchanges between a State Medicaid agency and its PO 00000 Frm 00222 Fmt 4701 Sfmt 4700 contracted MCOs, PIHPs, or PAHPs, which do not require a beneficiary to opt in. (B) The exchange is not prohibited by other applicable law. (ii) The data to be requested are all of the following with a date of service within 5 years before the request: (A) Data specified in § 431.60(b), excluding the following: (1) Provider remittances and enrollee cost-sharing information. (2) Denied prior authorizations. (B) Unstructured administrative and clinical documentation submitted by a provider related to prior authorizations. (iii) The State must include an attestation with this request affirming that the beneficiary is enrolled with the State and has opted into the data exchange. (iv) The State must complete this request as follows: (A) No later than 1 week after the payer has sufficient identifying information about previous payers and the beneficiary has opted in. (B) At a beneficiary’s request, within 1 week of the request. (v) The State must receive, through the API required in paragraph (b)(1) of this section, and incorporate into its records about the beneficiary, any data made available by other payers in response to the request. (5) Exchange response requirements. Make available the data specified in paragraph (b)(4)(ii) of this section that are maintained by the State to other payers via the API required in paragraph (b)(1) of this section within 1 business day of receiving a request, if all the following conditions are met: (i) The payer that requests access has its identity authenticated and includes an attestation with the request that the patient is enrolled with the payer and has opted into the data exchange. (ii) Disclosure of the data is not prohibited by other applicable law. (6) Concurrent coverage data exchange requirements. When a beneficiary has provided sufficient identifying information about concurrent payers and has opted in as described in paragraph (b)(2) of this section, a State must do the following, through the API required in paragraph (b)(1) of this section: (i) Request the beneficiary’s data from all known concurrent payers as described in paragraph (b)(4) of this section, and at least quarterly thereafter while the beneficiary is enrolled with both payers. (ii) Respond as described in paragraph (b)(5) of this section within 1 business day of a request from any concurrent payers. If agreed upon with the E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations requesting payer, the State may exclude any data that were previously sent to or originally received from the concurrent payer. (7) Patient educational resources. Provide information to applicants or beneficiaries in plain language, explaining at a minimum: the benefits of Payer-to-Payer API data exchange, their ability to opt in or withdraw that permission, and instructions for doing so. The State must provide the following resources: (i) When requesting a beneficiary’s permission for Payer-to-Payer API data exchange, as described in paragraph (b)(2) of this section. (ii) At least annually, in appropriate mechanisms through which it ordinarily communicates with current beneficiaries. (iii) In an easily accessible location on its public website. (c) Extensions and exemptions—(1) Extension. (i) A State may submit a written application to request a onetime, 1-year extension of the requirements in paragraph (a) or (b) of this section (or paragraphs (a) and (b)) for its Medicaid fee-for-service (FFS) program. The written application must be submitted as part of the State’s annual Advance Planning Document (APD) for Medicaid Management Information System (MMIS) operations expenditures described in part 433, subpart C, of this chapter, and approved before the compliance date for the requirements to which the State is seeking an extension. It must include all the following: (A) A narrative justification describing the specific reasons why the State cannot satisfy the requirement(s) by the compliance date and why those reasons result from circumstances that are unique to the agency operating the Medicaid FFS program. (B) A report on completed and ongoing State activities that evidence a good faith effort towards compliance. (C) A comprehensive plan to meet the requirements no later than 1 year after the compliance date. (ii) CMS grants the State’s request if it determines, based on the information provided, that— (A) The request adequately establishes a need to delay implementation; and (B) The State has a comprehensive plan to meet the requirements no later than 1 year after the compliance date. (2) Exemption. (i) A State operating a Medicaid program in which at least 90 percent of the State’s Medicaid beneficiaries are enrolled in Medicaid managed care organizations, as defined in § 438.2 of this chapter, may request an exemption for its FFS program from VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 either or both of the following requirement(s): (A) Paragraph (a) of this section. (B) Paragraphs (b)(1) and (3) through (7) of this section. (ii) The State’s exemption request must: (A) Be submitted in writing as part of a State’s annual APD for MMIS operations expenditures before the compliance date for the requirements to which the State is seeking an exemption. (B) Include both of the following: (1) Documentation that the State meets the threshold for the exemption, based on enrollment data from the most recent CMS ‘‘Medicaid Managed Care Enrollment and Program Characteristics’’ (or successor) report. (2) An alternative plan to ensure that enrolled providers will have efficient electronic access to the same information through other means while the exemption is in effect. (iii) CMS grants the exemption if the State establishes to CMS’s satisfaction that the State— (A) Meets the threshold for the exemption; and (B) Has established an alternative plan to ensure that enrolled providers will have efficient electronic access to the same information through other means while the exemption is in effect. (iv) The State’s exemption expires if either— (A) Based on the 3 previous years of available, finalized Medicaid Transformed Medicaid Statistical Information System (T–MSIS) managed care and FFS enrollment data, the State’s managed care enrollment for 2 of the previous 3 years is below 90 percent; or (B)(1) CMS has approved a State plan amendment, waiver, or waiver amendment that would significantly reduce the percentage of beneficiaries enrolled in managed care; and (2) The anticipated shift in enrollment is confirmed by the first available, finalized Medicaid T–MSIS managed care and FFS enrollment data. (v) If a State’s exemption expires under paragraph (c)(2)(iv) of this section, the State is required to do both of the following— (A) Submit written notification to CMS that the State no longer qualifies for the exemption within 90 days of the finalization of annual Medicaid T–MSIS managed care enrollment data that demonstrates that there has been the requisite shift from managed care enrollment to FFS enrollment resulting in the State’s managed care enrollment falling below the 90 percent threshold. (B) Obtain CMS approval of a timeline for compliance with the requirements in PO 00000 Frm 00223 Fmt 4701 Sfmt 4700 8979 paragraph (a) or (b) (or paragraph0s (a) and (b)) of this section within 2 years of the expiration of the exemption. ■ 11. Section 431.80 is added to subpart B to read as follows: § 431.80 Prior authorization requirements. (a) Communicating a reason for denial. Beginning January 1, 2026, if the State denies a prior authorization request (excluding a request for coverage of drugs as defined in § 431.60(b)(6)), in accordance with the timeframes established in § 440.230(e)(1) of this chapter, the response to the provider must include a specific reason for the denial, regardless of the method used to communicate that information. (b) Prior Authorization Application Programming Interface (API). Unless granted an extension or exemption under paragraph (c) of this section, beginning January 1, 2027, a State must implement and maintain an API conformant with § 431.60(c)(2) through (4), (d), and (e), and the standards in 45 CFR 170.215(a)(1), (b)(1)(i), and (c)(1) that— (1) Is populated with the State’s list of covered items and services (excluding drugs, as defined in § 431.60(b)(6)) that require prior authorization; (2) Can identify all documentation required by the State for approval of any items or services that require prior authorization; (3) Supports a HIPAA-compliant prior authorization request and response, as described in 45 CFR part 162; and (4) Communicates the following information about prior authorization requests: (i) Whether the State— (A) Approves the prior authorization request (and the date or circumstance under which the authorization ends); (B) Denies the prior authorization request; or (C) Requests more information. (ii) If the State denies the prior authorization request, it must include a specific reason for the denial. (c) Extensions and exemptions—(1) Extension. (i) A State may submit a written application to request a onetime, 1-year extension of the requirements in paragraph (b) of this section for its Medicaid FFS program. The written application must be submitted as part of the State’s annual APD for MMIS operations expenditures described in part 433, subpart C, of this chapter; and approved before the compliance date in paragraph (b) of this section. It must include all the following: (A) A narrative justification describing the specific reasons why the E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8980 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations State cannot satisfy the requirement(s) by the compliance date and why those reasons result from circumstances that are unique to the agency operating the Medicaid FFS program. (B) A report on completed and ongoing State activities that evidence a good faith effort towards compliance. (C) A comprehensive plan to meet the requirements no later than 1 year after the compliance date. (ii) CMS grants the State’s request if it determines, based on the information provided, that— (A) The request adequately establishes a need to delay implementation; and (B) The State has a comprehensive plan to meet the requirements no later than 1 year after the compliance date. (2) Exemption. (i) A State operating a Medicaid program in which at least 90 percent of the State’s Medicaid beneficiaries are enrolled in Medicaid managed care organizations, as defined in § 438.2 of this chapter, may request an exemption for its FFS program from the requirements in paragraph (b) of this section. (ii) The State’s exemption request must: (A) Be submitted in writing as part of a State’s annual APD for MMIS operations expenditures before the compliance date in paragraph (b) of this section. (B) The State’s request must include both of the following: (1) Documentation that the State meets the threshold for the exemption, based on enrollment data from the most recent CMS ‘‘Medicaid Managed Care Enrollment and Program Characteristics’’ (or successor) report. (2) An alternative plan to ensure that enrolled providers will have efficient electronic access to the same information through other means while the exemption is in effect. (iii) CMS grants the exemption if the State establishes to CMS’s satisfaction that the State— (A) Meets the threshold for the exemption; and (B) Has established an alternative plan to ensure that enrolled providers will have efficient electronic access to the same information through other means while the exemption is in effect. (iv) The State’s exemption expires if either— (A) Based on the 3 previous years of available, finalized Medicaid Transformed Medicaid Statistical Information System (T–MSIS) managed care and FFS enrollment data, the State’s managed care enrollment for 2 of the previous 3 years is below 90 percent; or (B)(1) CMS has approved a State plan amendment, waiver, or waiver VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 amendment that would significantly reduce the percentage of beneficiaries enrolled in managed care; and (2) The anticipated shift in enrollment is confirmed by the first available, finalized Medicaid T–MSIS managed care and FFS enrollment data. (v) If a State’s exemption expires under paragraph (c)(2)(iv) of this section, the State is required to do both of the following— (A) Submit written notification to CMS that the State no longer qualifies for the exemption within 90 days of the finalization of annual Medicaid T–MSIS managed care enrollment data that demonstrates that there has been the requisite shift from managed care enrollment to FFS enrollment resulting in the State’s managed care enrollment falling below the 90 percent threshold. (B) Obtain CMS approval of a timeline for compliance with the requirements in paragraph (b) of this section within 2 years of the expiration of the exemption. ■ 12. Section 431.201 is amended by revising the definition of ‘‘Action’’ to read as follows: § 431.201 Definitions. * * * * * Action means one of the following: (1) A termination, suspension of, or reduction in covered benefits or services, including benefits or services for which there is a current approved prior authorization; (2) A termination, suspension of, or reduction in Medicaid eligibility, or an increase in beneficiary liability, including a determination that a beneficiary must incur a greater amount of medical expenses to establish income eligibility in accordance with § 435.121(e)(4) or § 435.831 of this chapter; (3) A determination that a beneficiary is subject to an increase in premiums or cost-sharing charges under subpart A of part 447 of this chapter; or (4) A determination by a skilled nursing facility or nursing facility to transfer or discharge a resident and an adverse determination by a State regarding the preadmission screening and resident review requirements of section 1919(e)(7) of the Act. * * * * * ■ 13. Section 431.220 is amended by— ■ a. In paragraph (a)(1)(iv), removing the term ‘‘or’’ from the end of the paragraph; ■ b. In paragraph (a)(1)(v), removing the period from the end of the paragraph and adding in its place ‘‘; or’’; and ■ c. Adding paragraph (a)(1)(vi). The addition reads as follows: § 431.220 When a hearing is required. (a) * * * PO 00000 Frm 00224 Fmt 4701 Sfmt 4700 (1) * * * (vi) A prior authorization decision. * * * * * PART 435—ELIGIBILITY IN THE STATES, DISTRICT OF COLUMBIA, THE NORTHERN MARIANA ISLANDS, AND AMERICAN SAMOA 14. The authority citation for part 435 continues to read as follows: ■ Authority: 42 U.S.C. 1302. 15. Section 435.917 is amended by— a. Revising the headings of paragraphs (a) and (b); and ■ b. Revising paragraph (b)(2). The revisions read as follows: ■ ■ § 435.917 Notice of agency’s decision concerning eligibility, benefits, or services. (a) Notice of determinations. * * * (b) Content of notice—* * * (2) Notice of adverse action. Notice of adverse action including denial, termination, or suspension of eligibility or change in benefits or services. Any notice of denial, termination, or suspension of Medicaid eligibility, or, in the case of beneficiaries receiving medical assistance, denial of or change in benefits or services must be consistent with § 431.210 of this chapter. * * * * * PART 438—MANAGED CARE 16. The authority citation for part 438 continues to read as follows: ■ Authority: 42 U.S.C. 1302. 17. Section 438.9 is amended by revising paragraph (b)(7) to read as follows: ■ § 438.9 Provisions that apply to nonemergency medical transportation PAHPs. * * * * * (b) * * * (7) The PAHP standards in §§ 438.206(b)(1), 438.210, 438.214, 438.224, 438.230, and 438.242, excluding the requirement in § 438.242(b)(7), to comply with § 431.61(a) and (b) of this chapter. * * * * * § 438.62 [Amended] 18. Section 438.62 is amended by removing paragraphs (b)(1)(vi) and (vii). ■ 19. Section 438.210 is amended by— ■ a. Revising paragraphs (d)(1) and (d)(2)(i); ■ b. Redesignating paragraph (f) as paragraph (g); and ■ c. Adding new paragraph (f). The addition and revision read as follows: ■ E:\FR\FM\08FER2.SGM 08FER2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations § 438.210 services. Coverage and authorization of lotter on DSK11XQN23PROD with RULES2 * * * * * (d) * * * (1) Standard authorization decisions. (i) For standard authorization decisions, provide notice as expeditiously as the enrollee’s condition requires and: (A) For rating periods that start before January 1, 2026, within state established time frames that may not exceed 14 calendar days after receiving the request for service. (B) For rating periods that start on or after January 1, 2026, within state established time frames that may not exceed 7 calendar days after receiving the request for service. (ii) Standard authorization decisions may have an extension to the timeframes in paragraph (d)(1)(i) of this section up to 14 additional calendar days if— (A) The enrollee or the provider requests the extension; or (B) The MCO, PIHP, or PAHP justifies (to the State agency upon request) a need for additional information and how the extension is in the enrollee’s interest. (2) * * * (i) For cases in which a provider indicates, or the MCO, PIHP, or PAHP determines, that following the standard timeframe could seriously jeopardize the enrollee’s life or health or ability to attain, maintain, or regain maximum function, the MCO, PIHP, or PAHP must make an expedited authorization decision and provide notice as expeditiously as the enrollee’s health condition requires and no later than 72 hours after receipt of the request for service. * * * * * (f) Publicly reporting prior authorization metrics. Beginning January 1, 2026, following each calendar year it has a contract with a State Medicaid agency, the MCO, PIHP, or PAHP must report prior authorization data, excluding data on any and all drugs covered by the MCO, PIHP, or PAHP, at the plan level by March 31. The MCO, PIHP, or PAHP must make the following data from the previous calendar year publicly accessible by posting them on its website: (1) A list of all items and services that require prior authorization. (2) The percentage of standard prior authorization requests that were approved, aggregated for all items and services. (3) The percentage of standard prior authorization requests that were denied, aggregated for all items and services. (4) The percentage of standard prior authorization requests that were VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 approved after appeal, aggregated for all items and services. (5) The percentage of prior authorization requests for which the timeframe for review was extended, and the request was approved, aggregated for all items and services. (6) The percentage of expedited prior authorization requests that were approved, aggregated for all items and services. (7) The percentage of expedited prior authorization requests that were denied, aggregated for all items and services. (8) The average and median time that elapsed between the submission of a request and a determination by the MCO, PIHP or PAHP, for standard prior authorizations, aggregated for all items and services. (9) The average and median time that elapsed between the submission of a request and a decision by the MCO, PIHP or PAHP, for expedited prior authorizations, aggregated for all items and services. * * * * * ■ 20. Section 438.242 is amended by revising paragraph (b)(5) and adding paragraphs (b)(7) through (9) to read as follows: § 438.242 Health information systems. * * * * * (b) * * * (5) Subject to paragraph (b)(8) of this section, implement and maintain a Patient Access Application Programming Interface (API) required in § 431.60 of this chapter as if such requirements applied directly to the MCO, PIHP, or PAHP and: (i) Include all encounter data, including encounter data from any network providers the MCO, PIHP, or PAHP is compensating based on capitation payments and adjudicated claims and encounter data from any subcontractors. (ii) Exclude covered outpatient drugs as defined in section 1927(k)(2) of the Act. (iii) Report metrics specified in § 431.60(f) of this chapter at the plan level. * * * * * (7) By the rating period beginning on or after January 1, 2027, comply with §§ 431.61(a), (b)(1) and (4) through (6), and (b)(7)(ii) and (iii) and 431.80(b) of this chapter as if such requirements applied directly to the MCO, PIHP, or PAHP (8) By the rating period beginning on or after January 1, 2026, comply with § 431.80(a) of this chapter as if such requirements applied directly to the MCO, PIHP, or PAHP according to the decision timeframes in § 438.210(d). PO 00000 Frm 00225 Fmt 4701 Sfmt 4700 8981 (9) The following timeframes apply to paragraph (b)(5) of this section: (i) Except for the requirements in § 431.60(b)(5), (g), and (h) of this chapter, comply with the requirements of § 431.60 of this chapter by January 1, 2021. (ii) Comply with the requirements in § 431.60(b)(5) and (g) of this chapter by the rating period beginning on or after January 1, 2026. (iii) Beginning in 2026, by March 31 following any year the MCO, PIHP, or PAHP operates, comply with the reporting requirements in § 431.60(h) of this chapter for the previous calendar year’s data, in the form of aggregated, de-identified metrics, at the plan level. * * * * * PART 440—SERVICES: GENERAL PROVISIONS 21. The authority citation for part 440 continues to read as follows: ■ Authority: 42 U.S.C. 1302. 22. Section 440.230 is amended by adding paragraph (e) to read as follows: ■ § 440.230 Sufficiency of amount, duration, and scope. * * * * * (e) For prior authorization requests for items and services (excluding drugs, as defined in § 431.60(b)(6) of this chapter), the State Medicaid agency must— (1) Beginning January 1, 2026, make prior authorization decisions within the following timeframes: (i) For a standard determination, as expeditiously as a beneficiary’s health condition requires, but in no case later than 7 calendar days after receiving the request, unless a shorter minimum timeframe is established under State law. The timeframe for standard authorization decisions can be extended by up to 14 calendar days if the beneficiary or provider requests an extension, or if the State agency determines that additional information from the provider is needed to make a decision. (ii) For an expedited determination, as expeditiously as a beneficiary’s health condition requires, but in no case later than 72 hours after receiving the request, unless a shorter minimum timeframe is established under State law. (2) Provide the beneficiary with notice of the agency’s prior authorization decision in accordance with § 435.917 of this chapter and provide fair hearing rights, including advance notice, in accordance with part 431, subpart E, of this chapter. E:\FR\FM\08FER2.SGM 08FER2 8982 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations (3) Beginning in 2026, annually report prior authorization data, excluding data on drugs, as defined in § 431.60(b)(6) of this chapter, at the State level by March 31. The State must make the following data from the previous calendar year publicly accessible by posting them on its website: (i) A list of all items and services that require prior authorization. (ii) The percentage of standard prior authorization requests that were approved, aggregated for all items and services. (iii) The percentage of standard prior authorization requests that were denied, aggregated for all items and services. (iv) The percentage of standard prior authorization requests that were approved after appeal, aggregated for all items and services. (v) The percentage of prior authorization requests for which the timeframe for review was extended, and the request was approved, aggregated for all items and services. (vi) The percentage of expedited prior authorization requests that were approved, aggregated for all items and services. (vii) The percentage of expedited prior authorization requests that were denied, aggregated for all items and services. (viii) The average and median time that elapsed between the submission of a request and a determination by the State Medicaid agency, for standard prior authorizations, aggregated for all items and services. (ix) The average and median time that elapsed between the submission of a request and a decision by the State Medicaid agency for expedited prior authorizations, aggregated for all items and services. PART 457—ALLOTMENTS AND GRANTS TO STATES 23. The authority citation for part 457 continues to read as follows: ■ Authority: 42 U.S.C. 1302. 24. Section 457.495 is amended by revising paragraph (d) to read as follows: ■ § 457.495 State assurance of access to care and procedures to assure quality and appropriateness of care. lotter on DSK11XQN23PROD with RULES2 * * * * * (d) That decisions related to the prior authorization of health services are completed as follows: (1) Before January 1, 2026. (i) In accordance with the medical needs of the patient, within 14 days after receipt of a request for services. A possible extension of up to 14 days may be VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 permitted if the enrollee requests the extension or if the physician or health plan determines that additional information is needed; or (ii) In accordance with existing State law regarding prior authorization of health services. (2) On or after January 1, 2026. (i) In accordance with the medical needs of the enrollee, but no later than 7 calendar days after receiving the request for a standard determination and by no later than 72 hours after receiving the request for an expedited determination. A possible extension of up to 14 days may be permitted if the enrollee requests the extension or if the physician or health plan determines the additional information is needed; or (ii) In accordance with existing State law regarding prior authorization of health services. (3) Enrollee notification. Provide the enrollee with— (i) Notice of the State’s prior authorization decision; and (ii) Information on the enrollee’s right to a review process, in accordance with § 457.1180. ■ 25. Section 457.700 is amended by revising paragraph (c) to read as follows: § 457.700 Basis, scope, and applicability. * * * * * (c) Applicability. The requirements of this subpart apply to separate child health programs and Medicaid expansion programs, except that §§ 457.730, 457.731, and 457.732 do not apply to Medicaid expansion programs. Separate child health programs that provide benefits exclusively through managed care entities may meet the requirements of §§ 457.730, 457.731, and 457.732 by requiring the managed care entities to meet the requirements of § 457.1233(d). ■ 26. Section 457.730 is amended by— ■ a. Revising paragraph (b)(3); ■ b. Adding paragraphs (b)(5) and (6); ■ c. Revising paragraphs (c)(1), (c)(4)(ii)(C), and (e)(2); ■ d. Removing paragraph (g); ■ e. Redesignating paragraph (f) as paragraph (g); and ■ f. Adding new paragraph (f) and paragraph (h). The revisions and additions read as follows: § 457.730 Beneficiary access to and exchange of data. * * * * * (b) * * * (3) All data classes and data elements included in a content standard in 45 CFR 170.213 that are maintained by the State no later than 1 business day after the State receives the data; and * * * * * PO 00000 Frm 00226 Fmt 4701 Sfmt 4700 (5) Beginning January 1, 2027, the information in paragraph (b)(5)(i) of this section about prior authorizations for items and services (excluding drugs as defined in paragraph (b)(6) of this section), according to the timelines in paragraph (b)(5)(ii) of this section. (i) The prior authorization request and decision, including all of the following, as applicable: (A) The prior authorization status. (B) The date the prior authorization was approved or denied. (C) The date or circumstance under which the prior authorization ends. (D) The items and services approved. (E) If denied, a specific reason why the request was denied. (F) Related structured administrative and clinical documentation submitted by a provider. (ii) The information in paragraph (b)(5)(i) of this section must— (A) Be accessible no later than 1 business day after the State receives a prior authorization request; (B) Be updated no later than 1 business day after any status change; and (C) Continue to be accessible for the duration that the authorization is active and at least 1 year after the prior authorization’s last status change. (6) Drugs are defined for the purposes of paragraph (b)(5) of this section as any and all drugs covered by the State. (c) * * * (1) Must implement and maintain API technology conformant with 45 CFR 170.215(a)(1), (b)(1)(i), (c)(1), and (e)(1); * * * * * (4) * * * (ii) * * * (C) Using the updated version of the standard, implementation guide, or specification does not disrupt an end user’s ability to access the data specified in paragraph (b) of this section or §§ 457.731, 457.732, and 457.760 through the required APIs. * * * * * (e) * * * (2) Makes this determination using objective, verifiable criteria that are applied fairly and consistently across all apps and developers through which parties seek to access electronic health information, as defined in 45 CFR 171.102, including but not limited to criteria that rely on automated monitoring and risk mitigation tools. * * * * * (f) Reporting on Patient Access API usage. Beginning in 2026, by March 31 of each year, a State must report to CMS the following metrics, in the form of aggregated, de-identified data, for the previous calendar year at the State level E:\FR\FM\08FER2.SGM 08FER2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations in the form and manner specified by the Secretary: (1) The total number of unique beneficiaries whose data are transferred via the Patient Access API to a health app designated by the beneficiary; and (2) The total number of unique beneficiaries whose data are transferred more than once via the Patient Access API to a health app designated by the beneficiary. * * * * * (h) Applicability. A State must comply with the requirements in paragraphs (a) through (e) and (g) of this section beginning January 1, 2021, and with the requirements in paragraph (f) of this section beginning in 2026, with regard to data: (1) With a date of service on or after January 1, 2016; and (2) That are maintained by the State. ■ 27. Section 457.731 is added to read as follows: lotter on DSK11XQN23PROD with RULES2 § 457.731 Access to and exchange of health data for providers and payers. (a) Application programming interface to support data exchange from payers to providers—Provider Access API. Beginning January 1, 2027, unless granted an extension or exemption under paragraph (c) of this section, a State must do the following: (1) API requirements. Implement and maintain an application programming interface (API) conformant with all of the following: (i) Section 457.730(c)(2) through (4), (d), and (e). (ii) The standards in 45 CFR 170.215(a)(1), (b)(1)(i), (c)(1), and (d)(1). (2) Provider access. Make the data specified in § 457.730(b) with a date of service on or after January 1, 2016, excluding provider remittances and beneficiary cost-sharing information, that are maintained by the State, available to enrolled CHIP providers via the API required in paragraph (a)(1) of this section no later than 1 business day after receiving a request from such a provider, if all the following conditions are met: (i) The State authenticates the identity of the provider that requests access and attributes the beneficiary to the provider under the attribution process described in paragraph (a)(3) of this section. (ii) The beneficiary does not opt out as described in paragraph (a)(4) of this section. (iii) Disclosure of the data is not prohibited by other applicable law. (3) Attribution. Establish and maintain a process to associate beneficiaries with their enrolled CHIP providers to enable data exchange via the Provider Access API. VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 (4) Opt out and patient educational resources. (i) Establish and maintain a process to allow a beneficiary or the beneficiary’s personal representative to opt out of the data exchange described in paragraph (a)(2) of this section and to change their permission at any time. That process must be available before the first date on which the State makes beneficiary information available via the Provider Access API and at any time while the beneficiary is enrolled with the State. (ii) Provide information to beneficiaries in plain language about the benefits of API data exchange with their providers, their opt out rights, and instructions both for opting out of data exchange and for subsequently opting in, as follows: (A) Before the first date on which the State makes beneficiary information available through the Provider Access API. (B) No later than 1 week after enrollment. (C) At least annually. (D) In an easily accessible location on its public website. (5) Provider resources. Provide on its website and through other appropriate provider communications, information in plain language explaining the process for requesting beneficiary data using the Provider Access API required in paragraph (a)(1) of this section. The resources must include information about how to use the State’s attribution process to associate beneficiaries with their providers. (b) Application programming interface to support data exchange between payers—Payer-to-Payer API. Beginning January 1, 2027, unless granted an extension or exemption under paragraph (c) of this section a State must do the following: (1) API requirements. Implement and maintain an API conformant with all of the following: (i) Section 457.730(c)(2) through (4), (d), and (e). (ii) The standards in 45 CFR 170.215(a)(1), (b)(1)(i), and (d)(1). (2) Opt in. Establish and maintain a process to allow beneficiaries or their personal representatives to opt into the State’s payer to payer data exchange with the beneficiary’s previous payer(s), described in paragraphs (b)(4) and (5) of this section, and with concurrent payer(s), described in paragraph (b)(6) of this section, and to change their permission at any time. (i) The opt in process must be offered as follows: (A) To current beneficiaries, no later than the compliance date. PO 00000 Frm 00227 Fmt 4701 Sfmt 4700 8983 (B) To new beneficiaries, no later than 1 week after enrollment. (ii) If a beneficiary has coverage through any CHIP managed care entities within the same State while enrolled in CHIP, the State must share their opt in permission with those managed care entities to allow the Payer-to-Payer API data exchange described in this section. (iii) If a beneficiary does not respond or additional information is necessary, the State must make reasonable efforts to engage with the beneficiary to collect this information. (3) Identify previous and concurrent payers. Establish and maintain a process to identify a new beneficiary’s previous and concurrent payer(s) to facilitate the Payer-to-Payer API data exchange. The information request process must start as follows: (i) For current beneficiaries, no later than the compliance date. (ii) For new beneficiaries, no later than 1 week after enrollment. (iii) If a beneficiary does not respond or additional information is necessary, the State must make reasonable efforts to engage with the beneficiary to collect this information. (4) Exchange request requirements. Exchange beneficiary data with other payers, consistent with the following requirements: (i) The State must request the data specified in paragraph (b)(4)(ii) of this section through the beneficiary’s previous payers’ API, if all the following conditions are met: (A) The beneficiary has opted in, as described in paragraph (b)(2) of this section, except for data exchanges between a State CHIP agency and its contracted managed care entities, which do not require a beneficiary to opt in. (B) The exchange is not prohibited by other applicable law. (ii) The data to be requested are all of the following with a date of service within 5 years before the request: (A) Data specified in § 457.730(b), excluding the following: (1) Provider remittances and enrollee cost-sharing information. (2) Denied prior authorizations. (B) Unstructured administrative and clinical documentation submitted by a provider related to prior authorizations. (iii) The State must include an attestation with this request affirming that the beneficiary is enrolled with the State and has opted into the data exchange. (iv) The State must complete this request as follows: (A) No later than 1 week after the payer has sufficient identifying information about previous payers and the beneficiary has opted in. E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 8984 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations (B) At a beneficiary’s request, within 1 week of the request. (v) The State must receive, through the API required in paragraph (b)(1) of this section, and incorporate into its records about the beneficiary, any data made available by other payers in response to the request. (5) Exchange response requirements. Make available the data specified in paragraph (b)(4)(ii) of this section that are maintained by the State to other payers via the API required in paragraph (b)(1) of this section within 1 business day of receiving a request, if all the following conditions are met: (i) The payer that requests access has its identity authenticated and includes an attestation with the request that the patient is enrolled with the payer and has opted into the data exchange. (ii) Disclosure of the data is not prohibited by other applicable law. (6) Concurrent coverage data exchange requirements. When a beneficiary has provided sufficient identifying information about concurrent payers and has opted in as described in paragraph (b)(2) of this section, a State must do the following, through the API required in paragraph (b)(1) of this section: (i) Request the beneficiary’s data from all known concurrent payers as described in paragraph (b)(4) of this section, and at least quarterly thereafter while the beneficiary is enrolled with both payers. (ii) Respond as described in paragraph (b)(5) of this section within 1 business day of a request from any concurrent payers. If agreed upon with the requesting payer, the State may exclude any data that were previously sent to or originally received from the concurrent payer. (7) Patient educational resources. Provide information to applicants or beneficiaries in plain language, explaining at a minimum: the benefits of Payer-to-Payer API data exchange, their ability to opt in or withdraw that permission, and instructions for doing so. The State must provide the following resources: (i) When requesting a beneficiary’s permission for Payer-to-Payer API data exchange, as described in paragraph (b)(2) of this section. (ii) At least annually, in appropriate mechanisms through which it ordinarily communicates with current beneficiaries. (iii) In an easily accessible location on its public website. (c) Extensions and exemptions—(1) Extension. (i) A State may submit a written application to request a onetime, 1-year extension of the VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 requirements in paragraph (a) or (b) (or paragraphs (a) and (b)) of this section for its CHIP fee-for-service program. The written application must be submitted as part of the State’s annual Advance Planning Document (APD) for Medicaid Management Information System (MMIS) operations expenditures, as described in part 433, subpart C, of this chapter, and approved before the compliance date for the requirements to which the State is seeking an extension. It must include all the following: (A) A narrative justification describing the specific reasons why the State cannot satisfy the requirement(s) by the compliance date and why those reasons result from circumstances that are unique to the agency operating the CHIP fee-for service program. (B) A report on completed and ongoing State activities that evidence a good faith effort towards compliance. (C) A comprehensive plan to meet the requirements no later than 1 year after the compliance date. (ii) CMS grants the State’s request if it determines, based on the information provided, that— (A) The request adequately establishes a need to delay implementation; and (B) The State has a comprehensive plan to meet the requirements no later than 1 year after the compliance date. (2) Exemption. (i) A State operating a separate CHIP in which at least 90 percent of the State’s CHIP beneficiaries are enrolled in CHIP managed care organizations, as defined in § 457.10, may request an exemption for its fee-forservice program from either or both of the following requirements: (A) Paragraph (a) of this section. (B) Paragraphs (b)(1) and (3) through (7) of this section. (ii) The State’s exemption request must: (A) Be submitted in writing as part of a State’s annual APD for MMIS operations expenditures before the compliance date for the requirements to which the State is seeking an exemption. (B) Include both of the following: (1) Documentation that the State meets the threshold for the exemption, based on enrollment data from section 5 of the most recently accepted CHIP Annual Report Template System (CARTS). (2) An alternative plan to ensure that enrolled providers will have efficient electronic access to the same information through other means while the exemption is in effect. (iii) CMS grants the exemption if the State establishes to CMS’s satisfaction that the State— (A) Meets the threshold for the exemption; and PO 00000 Frm 00228 Fmt 4701 Sfmt 4700 (B) Has established an alternative plan to ensure that enrolled providers will have efficient electronic access to the same information through other means while the exemption is in effect. (iv) The State’s exemption expires if either— (A) Based on the 3 previous years of available, finalized CHIP CARTS managed care and fee-for-service enrollment data, the State’s managed care enrollment for 2 of the previous 3 years is below 90 percent; or (B)(1) CMS has approved a State plan amendment, waiver, or waiver amendment that would significantly reduce the percentage of beneficiaries enrolled in managed care; and (2) The anticipated shift in enrollment is confirmed by the first available, finalized CARTS managed care and feefor-service enrollment data. (v) If a State’s exemption expires under paragraph (c)(2)(iv) of this section, the State is required to do both of the following: (A) Submit written notification to CMS that the State no longer qualifies for the exemption within 90 days of the finalization of annual CARTS managed care enrollment data that demonstrates that there has been the requisite shift from managed care enrollment to feefor-service enrollment resulting in the State’s managed care enrollment falling below the 90 percent threshold. (B) Obtain CMS approval of a timeline for compliance with the requirements in paragraph (a) or (b) (or paragraphs (a) and (b)) of this section within 2 years of the expiration of the exemption. ■ 28. Section 457.732 is added to read as follows: § 457.732 Prior authorization requirements. (a) Communicating a reason for denial. Beginning January 1, 2026, if the State denies a prior authorization request (excluding a request for coverage of drugs as defined in § 457.730(b)(6)), in accordance with the timeframes established in § 457.495(d), the response to the provider must include a specific reason for the denial, regardless of the method used to communicate that information. (b) Prior Authorization Application Programming Interface (API). Unless granted an extension or exemption under paragraph (d) of this section, beginning January 1, 2027, a State must implement and maintain an API conformant with § 457.730(c)(2) through (4), (d), and (e), and the standards in 45 CFR 170.215(a)(1), (b)(1)(i), and (c)(1) that— (1) Is populated with the State’s list of covered items and services (excluding E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations drugs as defined in § 457.730(b)(6)) that require prior authorization; (2) Can identify all documentation required by the State for approval of any items or services that require prior authorization; (3) Supports a HIPAA-compliant prior authorization request and response, as described in 45 CFR part 162; and (4) Communicates the following information about prior authorization requests: (i) Whether the State— (A) Approves the prior authorization request (and the date or circumstance under which the authorization ends); (B) Denies the prior authorization request; or (C) Requests more information. (ii) If the State denies the prior authorization request, it must include a specific reason for the denial. (c) Publicly reporting prior authorization metrics. Beginning in 2026, a State must annually report prior authorization data, excluding data on drugs as defined in § 457.730(b)(6), at the State level by March 31. The State must make the following data from the previous calendar year publicly accessible by posting them on its website: (1) A list of all items and services that require prior authorization. (2) The percentage of standard prior authorization requests that were approved, aggregated for all items and services. (3) The percentage of standard prior authorization requests that were denied, aggregated for all items and services. (4) The percentage of standard prior authorization requests that were approved after appeal, aggregated for all items and services. (5) The percentage of prior authorization requests for which the timeframe for review was extended, and the request was approved, aggregated for all items and services. (6) The percentage of expedited prior authorization requests that were approved, aggregated for all items and services. (7) The percentage of expedited prior authorization requests that were denied, aggregated for all items and services. (8) The average and median time that elapsed between the submission of a request and a determination by the State, for standard prior authorizations, aggregated for all items and services. (9) The average and median time that elapsed between the submission of a request and a decision by the State for expedited prior authorizations, aggregated for all items and services. (d) Extensions and exemptions—(1) Extension. (i) A State may submit a VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 written application to request a onetime, 1-year extension of the requirements in paragraph (b) of this section for its CHIP fee-for-service program. The written application must be submitted and approved as part of the State’s annual Advance Planning Document (APD) for Medicaid Management Information System (MMIS) operations expenditures described in part 433, subpart C, of this chapter, and approved before the compliance date in paragraph (b) of this section. It must include all the following: (A) A narrative justification describing the specific reasons why the State cannot satisfy the requirement(s) by the compliance date and why those reasons result from circumstances that are unique to the agency operating the CHIP fee-for service program; (B) A report on completed and ongoing State activities that evidence a good faith effort toward compliance. (C) A comprehensive plan to meet the requirements no later than 1 year after the compliance date. (ii) CMS grants the State’s request if it determines, based on the information provided, that— (A) The request adequately establishes a need to delay implementation; and (B) The State has a comprehensive plan to meet the requirements no later than 1 year after the compliance date. (2) Exemption. (i) A State operating a separate CHIP in which at least 90 percent of the State’s CHIP beneficiaries are enrolled in CHIP managed care organizations, as defined in § 457.10, may request an exemption for its fee-forservice program from the requirements in paragraph (b) of this section. (ii) The State’s exemption request must: (A) Be submitted in writing as part of a State’s annual APD for MMIS operations expenditures before the compliance date in paragraph (b) of this section. (B) Include both of the following: (1) Documentation that the State meets the threshold for the exemption, based on enrollment data from section 5 of the most recently accepted CARTS. (2) An alternative plan to ensure that enrolled providers will have efficient electronic access to the same information through other means while the exemption is in effect. (iii) CMS grants the exemption if the State establishes to CMS’s satisfaction that the State— (A) Meets the threshold for the exemption; and (B) Has established an alternative plan to ensure that its enrolled providers will have efficient electronic access to the PO 00000 Frm 00229 Fmt 4701 Sfmt 4700 8985 same information through other means while the exemption is in effect. (iv) The State’s exemption expires if either— (A) Based on the 3 previous years of available, finalized CHIP CARTS managed care and fee-for-service enrollment data, the State’s managed care enrollment for 2 of the previous 3 years is below 90 percent; or (B)(1) CMS has approved a State plan amendment, waiver, or waiver amendment that would significantly reduce the percentage of beneficiaries enrolled in managed care; and (2) The anticipated shift in enrollment is confirmed by the first available, finalized CARTS managed care and feefor-service enrollment data. (v) If a State’s exemption expires under paragraph (d)(2)(iv) of this section, the State is required to do both of the following: (A) Submit written notification to CMS that the State no longer qualifies for the exemption within 90 days of the finalization of annual CARTS managed care enrollment data that demonstrates that there has been the requisite shift from managed care enrollment to feefor-service enrollment resulting in the State’s managed care enrollment falling below the 90 percent threshold. (B) Obtain CMS approval of a timeline for compliance with the requirements in paragraph (b) of this section within 2 years of the expiration of the exemption. ■ 29. Section 457.1206 is amended by revising paragraph (b)(6) to read as follows: § 457.1206 Non-emergency medical transportation PAHPs. * * * * * (b) * * * (6) The PAHP standards in § 438.206(b)(1) of this chapter, as crossreferenced by §§ 457.1230(a) and (d) and 457.1233(a), (b), and (d), excluding the requirement in § 438.242(b)(7) of this chapter to comply with § 431.61(a) of this chapter. * * * * * ■ 30. Section 457.1230 is amended by revising paragraph (d) to read as follows: § 457.1230 Access standards. * * * * * (d) Coverage and authorization of services. The State must ensure, through its contracts, that each MCO, PIHP, or PAHP complies with the coverage and authorization of services requirements in accordance with the terms of § 438.210 of this chapter, except that the following do not apply: E:\FR\FM\08FER2.SGM 08FER2 8986 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations (1) Section 438.210(a)(5) of this chapter (related to medical necessity standard). (2) Section 438.210(b)(2)(iii) of this chapter (related to authorizing long term services and supports (LTSS)). TITLE 45—Public Welfare PART 156–HEALTH INSURANCE ISSUER STANDARDS UNDER THE AFFORDABLE CARE ACT, INCLUDING STANDARDS RELATED TO EXCHANGES 31. The authority citation for part 156 continues to read as follows: ■ Authority: 42 U.S.C. 18021–18024, 18031– 18032, 18041–18042, 18044, 18054, 18061, 18063, 18071, 18082, and 26 U.S.C. 36B. 32. Section 156.221 is amended by— a. In paragraph (b)(1)(ii), removing the word ‘‘and’’ at the end of the paragraph; ■ b. Revising paragraph (b)(1)(iii); ■ c. Adding paragraphs (b)(1)(iv) and (v); and ■ d. Revising paragraphs (c)(1), (c)(4)(ii)(C), (e)(2), (f), and (i). The revisions and addition read as follows: ■ ■ § 156.221 Access to and exchange of health data and plan information. lotter on DSK11XQN23PROD with RULES2 * * * * * (b) * * * (1) * * * (iii) All data classes and data elements included in a content standard in 45 CFR 170.213 that are maintained by the Qualified Health Plan (QHP) issuer no later than 1 business day after the QHP issuer receives the data; and (iv) For plan years beginning on or after January 1, 2027, the information in paragraph (b)(1)(iv)(A) of this section about prior authorizations for items and services (excluding drugs, as defined in paragraph (b)(1)(v) of this section), according to the timelines in paragraph (b)(1)(iv)(B) of this section. (A) The prior authorization request and decision, including all of the following, as applicable: (1) The prior authorization status. (2) The date the prior authorization was approved or denied. (3) The date or circumstance under which the prior authorization ends. (4) The items and services approved. (5) If denied, a specific reason why the request was denied. (6) Related structured administrative and clinical documentation submitted by a provider. (B) The information in paragraph (b)(1)(iv)(A) of this section must— (1) Be accessible no later than 1 business day after the QHP issuer receives a prior authorization request; VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 (2) Be updated no later than 1 business day after any status change; and (3) Continue to be accessible for the duration that the authorization is active and at least 1 year after the prior authorization’s last status change. (v) Drugs are defined for the purposes of paragraph (b)(1)(iv) of this section as any and all drugs covered by the QHP issuer. * * * * * (c) * * * (1) Must implement and maintain API technology conformant with 45 CFR 170.215(a)(1), (b)(1)(i), (c)(1), and (e)(1); * * * * * (4) * * * (ii) * * * (C) Using the updated version of the standard, implementation guide, or specification does not disrupt an end user’s ability to access the data specified in paragraph (b) of this section or §§ 156.221, 156.222, and 156.223 through the required APIs. * * * * * (e) * * * (2) Makes this determination using objective, verifiable criteria that are applied fairly and consistently across all apps and developers through which parties seek to access electronic health information, as defined in 45 CFR 171.102, including but not limited to criteria that rely on automated monitoring and risk mitigation tools. (f) Reporting on Patient Access API usage. Beginning in 2026, by March 31 following any calendar year that it offers a QHP on a Federally-facilitated Exchange, a QHP issuer must report to CMS the following metrics, in the form of aggregated, de-identified data, for the previous calendar year at the issuer level in the form and manner specified by the Secretary: (1) The total number of unique enrollees whose data are transferred via the Patient Access API to a health app designated by the enrollee. (2) The total number of unique enrollees whose data are transferred more than once via the Patient Access API to a health app designated by the enrollee. * * * * * (i) Applicability. A QHP issuer on an individual market Federally-facilitated Exchange, not including QHP issuers offering only stand-alone dental plans, must comply with the requirements in paragraphs (a) through (e) and (g) of this section beginning with plan years beginning on or after January 1, 2021, and with the requirements in paragraph (f) of this section beginning in 2026, with regard to data: PO 00000 Frm 00230 Fmt 4701 Sfmt 4700 (1) With a date of service on or after January 1, 2016; and (2) That are maintained by the QHP issuer for enrollees in QHPs. ■ 33. Section 156.222 is added to read as follows: § 156.222 Access to and exchange of health data for providers and payers. (a) Application programming interface to support data exchange from payers to providers—Provider Access API. Unless granted an exception under paragraph (c) of this section, for plan years beginning on or after January 1, 2027, QHP issuers on a Federallyfacilitated Exchange must do the following: (1) API requirements. Implement and maintain an application programming interface (API) conformant with all of the following: (i) Section 156.221(c)(2) through (4), (d), and (e). (ii) The standards in 45 CFR 170.215(a)(1), (b)(1)(i), (c)(1), and (d)(1). (2) Provider access. Make the data specified in § 156.221(b) with a date of service on or after January 1, 2016, excluding provider remittances and enrollee cost-sharing information, that are maintained by the QHP issuer to available in-network providers via the API required in paragraph (a)(1) of this section no later than 1 business day after receiving a request from such a provider, if all the following conditions are met: (i) The QHP issuer authenticates the identity of the provider that requests access and attributes the enrollee to the provider under the attribution process described in paragraph (a)(3) of this section. (ii) The enrollee does not opt out as described in paragraph (a)(4) of this section. (iii) Disclosure of the data is not prohibited by other applicable law. (3) Attribution. Establish and maintain a process to associate enrollees with their in-network providers to enable data exchange via the Provider Access API. (4) Opt out and patient educational resources. (i) Establish and maintain a process to allow an enrollee or the enrollee’s personal representative to opt out of data exchange described in paragraph (a)(2) of this section and to change their permission at any time. That process must be available before the first date on which the QHP issuer makes enrollee information available via the Provider Access API and at any time while the enrollee is enrolled with the QHP issuer. (ii) Provide information to enrollees in plain language about the benefits of E:\FR\FM\08FER2.SGM 08FER2 lotter on DSK11XQN23PROD with RULES2 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations API data exchange with their providers, their opt out rights, and instructions both for opting out of data exchange and for subsequently opting in, as follows: (A) Before the first date on which the QHP issuer makes enrollee information available through the Provider Access API. (B) No later than 1 week after the after the coverage start date or no later than 1 week after the effectuation of coverage, whichever is later. (C) At least annually. (D) In an easily accessible location on its public website. (5) Provider resources. Provide on its website and through other appropriate provider communications, information in plain language explaining the process for requesting enrollee data using the Provider Access API required in paragraph (a)(1) of this section. The resources must include information about how to use the QHP issuer’s attribution process to associate enrollees with their providers. (b) Application programming interface to support data exchange between payers—Payer-to-Payer API. Unless granted an exception under paragraph (c) of this section, for plan years beginning on or after January 1, 2027, QHP issuers on a Federallyfacilitated Exchange must do the following: (1) API requirements. Implement and maintain an API conformant with all of the following: (i) Section 156.221(c)(2) through (4), (d), and (e). (ii) The standards in 45 CFR 170.215(a)(1), (b)(1)(i), and (d)(1). (2) Opt in. Establish and maintain a process to allow enrollees or their personal representatives to opt into the QHP issuer’s payer to payer data exchange with the enrollee’s previous payer(s), described in paragraphs (b)(4) and (5) of this section, and with concurrent payer(s), described in paragraph (b)(6) of this section, and to change their permission at any time. (i) The opt in process must be offered as follows: (A) To current enrollees, no later than the compliance date. (B) To new enrollees, no later than 1 week after the coverage start date or no later than 1 week after the effectuation of coverage, whichever is later. (ii) If an enrollee does not respond or additional information is necessary, the QHP issuer must make reasonable efforts to engage with the enrollee to collect this information. (3) Identify previous and concurrent payers. Establish and maintain a process to identify a new enrollee’s previous and concurrent payer(s) to facilitate the VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 Payer-to-Payer API data exchange. The information request process must start as follows: (i) For current enrollees, no later than the compliance date. (ii) For new enrollees, no later than 1 week after the coverage start date or no later than 1 week after the effectuation of coverage, whichever is later. (iii) If an enrollee does not respond or additional information is necessary, the QHP issuer must make reasonable efforts to engage with the enrollee to collect this information. (4) Exchange request requirements. Exchange enrollee data with other payers, consistent with the following requirements: (i) The QHP issuer must request the data specified in paragraph (b)(4)(ii) of this section through the enrollee’s previous payers’ API, if all the following conditions are met: (A) The enrollee has opted in, as described in paragraph (b)(2) of this section. (B) The exchange is not prohibited by other applicable law. (ii) The data to be requested are all of the following with a date of service within 5 years before the request: (A) Data specified in § 156.221(b) excluding the following: (1) Provider remittances and enrollee cost-sharing information. (2) Denied prior authorizations. (B) Unstructured administrative and clinical documentation submitted by a provider related to prior authorizations. (iii) The QHP issuer must include an attestation with this request affirming that the enrollee is enrolled with the QHP issuer and has opted into the data exchange. (iv) The QHP issuer must complete this request as follows: (A) No later than 1 week after the payer has sufficient identifying information about previous payers and the enrollee has opted in. (B) At an enrollee’s request, within 1 week of the request. (v) The QHP issuer must receive, through the API required in paragraph (b)(1) of this section, and incorporate into its records about the enrollee, any data made available by other payers in response to the request. (5) Exchange response requirements. Make available the data specified in paragraph (b)(4)(ii) of this section that are maintained by the QHP issuer to other payers via the API required in paragraph (b)(1) of this section within 1 business day of receiving a request, if all the following conditions are met: (i) The payer that requests access has its identity authenticated and includes an attestation with the request that the PO 00000 Frm 00231 Fmt 4701 Sfmt 4700 8987 patient is enrolled with the payer and has opted into the data exchange. (ii) Disclosure of the data is not prohibited by other applicable law. (6) Concurrent coverage data exchange requirements. When an enrollee has provided sufficient identifying information about concurrent payers and has opted in as described in paragraph (b)(2) of this section, a QHP issuer on a Federallyfacilitated Exchange must do the following, through the API required in paragraph (b)(1) of this section: (i) Request the enrollee’s data from all known concurrent payers as described in paragraph (b)(4) of this section, and at least quarterly thereafter while the enrollee is enrolled with both payers. (ii) Respond as described in paragraph (b)(5) of this section within 1 business day of a request from any concurrent payers. If agreed upon with the requesting payer, the QHP issuer may exclude any data that were previously sent to or originally received from the concurrent payer. (7) Patient educational resources. Provide information to enrollees in plain language, explaining at a minimum: the benefits of Payer-to-Payer API data exchange, their ability to opt in or withdraw that permission, and instructions for doing so. The QHP issuer must provide the following resources: (i) When requesting an enrollee’s permission for Payer-to-Payer API data exchange, as described in paragraph (b)(2) of this section. (ii) At least annually, in appropriate mechanisms through which it ordinarily communicates with current enrollees. (iii) In an easily accessible location on its public website. (c) Exception. (1) If a plan applying for QHP certification to be offered through a Federally-facilitated Exchange believes it cannot satisfy the requirements in paragraph (a) or (b) (or paragraphs (a) and (b)) of this section, the issuer must include a narrative justification in its QHP application that describes all of the following: (i) The reasons why the issuer cannot reasonably satisfy the requirements for the applicable plan year. (ii) The impact of non-compliance upon providers and enrollees. (iii) The current or proposed means of providing health information to payers. (iv) Solutions and a timeline to achieve compliance with the requirements in paragraph (a) or (b) of this section (or paragraphs (a) and (b)). (2) The Federally-facilitated Exchange may grant an exception to the requirements in paragraph (a) or (b) (or paragraphs (a) and (b)) of this section if E:\FR\FM\08FER2.SGM 08FER2 8988 Federal Register / Vol. 89, No. 27 / Thursday, February 8, 2024 / Rules and Regulations the Exchange determines that making QHPs of such issuer available through such Exchange is in the interests of qualified individuals in the State or States in which such Exchange operates, and an exception is warranted to permit the issuer to offer QHPs through the FFE. ■ 34. Section 156.223 is added to read as follows: § 156.223 Prior authorization requirements. lotter on DSK11XQN23PROD with RULES2 (a) Communicating a reason for denial. Beginning January 1, 2026, if the QHP issuer denies a prior authorization request (excluding a request for coverage of drugs as defined in § 156.221(b)(1)(v)), the response to the provider must include a specific reason for the denial, regardless of the method used to communicate that information. (b) Prior Authorization Application Programming Interface (API). Unless granted an exception under paragraph (d) of this section, for plan years beginning on or after January 1, 2027, a QHP issuer on a Federally-facilitated Exchange must implement and maintain an API conformant with § 156.221(c)(2) through (4), (d), and (e), and the standards in 45 CFR 170.215(a)(1), (b)(1)(i), and (c)(1) that— (1) Is populated with the QHP issuer’s list of covered items and services (excluding drugs as defined in § 156.221(b)(1)(v)) that require prior authorization; (2) Can identify all documentation required by the QHP issuer for approval of any items or services that require prior authorization; (3) Supports a HIPAA-compliant prior authorization request and response, as described in 45 CFR part 162; and (4) Communicates the following information about prior authorization requests: (i) Whether the QHP issuer— VerDate Sep<11>2014 18:23 Feb 07, 2024 Jkt 262001 (A) Approves the prior authorization request (and the date or circumstance under which the authorization ends); (B) Denies the prior authorization request; or (C) Requests more information. (ii) If the QHP issuer denies the prior authorization request, it must include a specific reason for the denial. (c) Publicly reporting prior authorization metrics. Beginning in 2026, following each year it offers a QHP on a Federally-facilitated Exchange, a QHP issuer must report prior authorization data, excluding data on drugs as defined in § 156.221(b)(1)(v), at the issuer level by March 31. The QHP issuer must make the following data from the previous calendar year publicly accessible by posting them on its website: (1) A list of all items and services that require prior authorization. (2) The percentage of standard prior authorization requests that were approved, aggregated for all items and services. (3) The percentage of standard prior authorization requests that were denied, aggregated for all items and services. (4) The percentage of standard prior authorization requests that were approved after appeal, aggregated for all items and services. (5) The percentage of prior authorization requests for which the timeframe for review was extended, and the request was approved, aggregated for all items and services. (6) The percentage of expedited prior authorization requests that were approved, aggregated for all items and services. (7) The percentage of expedited prior authorization requests that were denied, aggregated for all items and services. (8) The average and median time that elapsed between the submission of a PO 00000 Frm 00232 Fmt 4701 Sfmt 9990 request and a determination by the QHP issuer, for standard prior authorizations, aggregated for all items and services. (9) The average and median time that elapsed between the submission of a request and a decision by the QHP issuer for expedited prior authorizations, aggregated for all items and services. (d) Exception. (1) If a plan applying for QHP certification to be offered through a Federally-facilitated Exchange believes it cannot satisfy the requirements in paragraph (b) of this section, the issuer must include a narrative justification in its QHP application that describes all of the following: (i) The reasons why the issuer cannot reasonably satisfy the requirements for the applicable plan year. (ii) The impact of non-compliance upon providers and enrollees. (iii) The current or proposed means of providing health information to providers. (iv) Solutions and a timeline to achieve compliance with the requirements in paragraph (b) of this section. (2) The Federally-facilitated Exchange (FFE) may grant an exception to the requirements in paragraph (b) of this section if the Exchange determines that making QHPs of such issuer available through such Exchange is in the interests of qualified individuals in the State or States in which such Exchange operates and an exception is warranted to permit the issuer to offer QHPs through the FFE. Xavier Becerra, Secretary, Department of Health and Human Services. [FR Doc. 2024–00895 Filed 1–18–24; 4:15 pm] BILLING CODE 4150–28–P E:\FR\FM\08FER2.SGM 08FER2

Agencies

[Federal Register Volume 89, Number 27 (Thursday, February 8, 2024)]
[Rules and Regulations]
[Pages 8758-8988]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 2024-00895]

[[Page 8757]]

Vol. 89

Thursday,

No. 27

February 8, 2024

Part II

Department of Health and Human Services

-----------------------------------------------------------------------

Centers for Medicare & Medicaid Services

-----------------------------------------------------------------------

42 Parts 422, 431, 435, et al.

45 Part 156

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; Final Rule

Federal Register / Vol. 89 , No. 27 / Thursday, February 8, 2024 /
Rules and Regulations

[[Page 8758]]

-----------------------------------------------------------------------

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

[[Page 8759]]

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[supreg]) International Fast Healthcare
Interoperability Resources (FHIR[supreg]) 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

[[Page 8760]]

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[supreg]) Fast Healthcare
Interoperability Resources (FHIR[supreg]) Release 4.0.1 at 45 CFR
170.215(a)(1) (HL7 FHIR).
HL7[supreg] FHIR[supreg] 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[supreg] 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[supreg] Bulk Data Access (Flat FHIR) IG v1.0.0: STU 1
at 45 CFR 170.215(d)(1) (Bulk Data Access IG).
OpenID Connect Core 1.0, incorporating errata set 1 at 45
CFR 170.215(e)(1) (OpenID Connect Core).
We refer readers to the HTI-1 final rule for further information
(89 FR 1192). More detail about the required standards can be found in
section II.G. and Table H3. We are also strongly recommending that
payers use specific IGs to supplement the required standards at 45 CFR
170.215. Additionally, we are finalizing our proposal to allow payers
to voluntarily use updated versions of the standards, specifications,
or IGs for each of these APIs prior to the adoption of updated versions
in regulation, subject to certain conditions and provided the updated
standard does not disrupt an end user's ability to access the data
available through the API. We are also finalizing terminology changes
related to the Patient Access API (in section II.A.2.d. of this final
rule). These policies will take effect on the effective date of the
final rule.
We are finalizing, as proposed, some clarifications to existing
Medicaid beneficiary notice and fair hearing regulations that apply to
Medicaid prior authorization decisions. Because these are
clarifications and improvements to existing regulations, as we
proposed, Medicaid agencies will have to comply with these policies
upon the effective date of a final rule.
In our proposed rule, we proposed compliance dates in 2026 (by
January 1, 2026, for MA organizations and state Medicaid and CHIP FFS
programs; by the rating period beginning on or after January 1, 2026,
for Medicaid managed care plans and CHIP managed care entities; and for
plan years beginning on or after January 1, 2026, for QHP issuers on
the FFEs), for all policies that require API development and
enhancement. Based on commenter feedback and as noted previously, we
are delaying the compliance dates in this final rule for the provisions
that require API development and enhancement in 2027 (by January 1,
2027, for MA organizations and state Medicaid and CHIP FFS programs; by
the rating period beginning on or after January 1, 2027, for Medicaid
managed care plans and CHIP managed care entities; and for plan years
beginning on or after January 1, 2027, for QHP issuers on the FFEs).
Throughout this rule, we generally refer to these compliance dates as
``in 2027'' for the various payers.
We believe this approximately 3-year timeline to recruit and train
staff, update, or build the APIs, and update operational procedures
will be sufficient to implement these policies, based on comments and
public information from some payers and providers regarding similar
initiatives already in progress. In addition to the 3-year
implementation timeframe, we are finalizing our proposal to give state
Medicaid and CHIP FFS programs an opportunity to seek an extension to
the compliance dates, or an exemption from meeting certain
requirements, in certain circumstances. Additionally, we are finalizing
our proposal to provide an exceptions process for QHP issuers on the
FFEs. We believe the approximately 3-year timeframe for implementation
in the final rule will offer sufficient time for state Medicaid and
CHIP FFS programs and QHP issuers on the FFEs to determine whether they
can timely satisfy the API development and enhancement requirements in
this final rule and to prepare the necessary documentation to request
an extension, exemption, or exception, as applicable.
Executive Order 13985 of January 20, 2021, entitled ``Advancing
Racial Equity and Support for Underserved Communities Through the
Federal Government,'' set administration policy that the ``Federal
Government should pursue a comprehensive approach to advancing equity
for all.'' \1\ CMS is committed to pursuing a comprehensive approach to
advancing health equity for all, and the policies in this final rule
are aligned with that Executive order because they represent efforts to
mitigate existing inefficiencies in policies, processes, and technology
that affect many patient populations. Some patient populations are more
negatively affected by existing processes than

[[Page 8761]]

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

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

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

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

C. Specific Terms Used in This Final Rule

Our policies emphasize improving health information exchange and
facilitating appropriate and necessary patient, provider, and payer
access to information in health records. We also include several
policies intended to reduce payer, provider, and patient burden by
improving prior authorization processes and helping patients remain at
the center of their care. Prior authorization refers to the process
through which a health care provider, such as an individual clinician,
acute care hospital, ambulatory surgical center, or clinic, obtains
approval from a payer before providing care. Payers establish prior
authorization requirements to help control costs and ensure payment
accuracy by verifying that an item or service is medically necessary,
meets coverage criteria, and, for some payers, is consistent with
standards of care before the item or service is provided. A prior
authorization is made up of two parts--a request from a provider and a
decision by a payer. We refer to the provider's workflow and associated
information and documentation as the ``prior authorization request''
and the payer's processes and associated information and documentation
as the ``prior authorization decision.''
For purposes of this final rule, references to QHP issuers on the
FFEs exclude issuers offering only stand-alone dental plans (SADPs).
Likewise, we are also excluding QHP issuers offering only QHPs in the
Federally-facilitated Small Business Health Options Program Exchanges
(FF-SHOPs) from the provisions of this final rule, as we believe that
the standards could be overly burdensome for both SADP and Small
Business Health Options Program (SHOP) issuers. We are finalizing an
exceptions process for QHP issuers on the FFEs from the API
requirements; the grant of an exception is conditioned upon our annual
approval of a narrative justification, as further detailed in section
II.E. of this final rule. For the purposes of this final rule, FFEs
include FFEs in states that perform plan management functions. State-
based Exchanges on the Federal Platform (SBE-FPs) are not FFEs, even
though patients in those states enroll in coverage through
HealthCare.gov. Hence, QHP issuers in SBE-FPs will not be subject to
the requirements in this final rule. We encourage SBE-FPs and State-
based Exchanges operating their own platforms (SBEs) to consider
adopting similar requirements for QHPs on their Exchanges.
Throughout this final rule, we use terms such as ``patient,''
``consumer,'' ``beneficiary,'' ``enrollee,'' and ``individual.'' Every
reader of this final rule is a patient who has received or will
receive, medical care at some point in their life. In this final rule,
we use the term ``patient'' as an inclusive term. We understand that,
historically, we have referred in our regulations to ``patients'' using
the other terms previously noted. However, for the policies herein, we
will use additional, specific terms applicable to individuals covered
under the health care programs that we administer and regulate. We also
note that when we discuss patients, the term includes, where
applicable, a patient's personal representative. For example, a patient
or their personal representative may opt into or out of certain types
of information exchange under the policies in this final rule. But when
we refer to a patient's medical needs or health records, we do not
include the medical needs or health records of the patient's personal
representative. Per the Standards for Privacy of Individually
Identifiable Health Information (Health Insurance Portability and
Accountability Act (HIPAA) Privacy Rule) \3\ issued under HIPAA (Pub.
L. 104-191, enacted on August 21, 1996), as modified, at 45 CFR
164.502(g), and related guidance, a ``personal representative'' is a
person authorized under state or other applicable law to act on behalf
of an individual in making health care-related decisions (such as a
parent, guardian, or person with a medical power of attorney).\4\ Under
the HIPAA Privacy Rule (45 CFR part 164, subpart E), the individual's
personal representative generally may exercise the right to access the
individual's protected health information (PHI). For many processes
described in this final rule, a patient's personal representative could
act on a patient's behalf, as permitted by the HIPAA Privacy Rule and
other applicable laws.
---------------------------------------------------------------------------

\3\ See 45 CFR parts 160 and 164, subparts A and E.
\4\ U.S. Department of Health and Human Services. Health
Information and Privacy. Retrieved from https://www.hhs.gov/hipaa/for-professionals/faq/2069/under-hipaa-when-can-a-family-member/ and https://www.hhs.gov/hipaa/for-professionals/faq/personal-representatives-and-minors/.
---------------------------------------------------------------------------

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

[[Page 8762]]

prior authorization data to the Patient Access API. We are finalizing
these policies with compliance dates in 2027. As discussed throughout
this rule, we are finalizing a modification to our proposal for certain
requirements by establishing compliance dates in 2027, rather than in
2026, as we proposed. Specifically, those policies include adding prior
authorization information to the Patient Access API, implementing the
Provider Access API (including a process for patients to opt out and
disseminating educational resources to patients and providers),
implementing the Payer-to-Payer API (including processes for gathering
previous/concurrent payer information and for patients to opt in, and
disseminating educational resources to patients), and implementing the
Prior Authorization API. We are not including in the group of
``policies that require API enhancement or development'' terminology
changes for the Patient Access API, reporting Patient Access API
metrics, changes to prior authorization processes, reporting prior
authorization metrics, Medicaid notice and fair hearings changes, the
MIPS and Medicare Promoting Interoperability measures, and updated
standards. An explanation of why we are establishing these deadlines
for each policy is found in section I.D.2. of this final rule and
throughout this rule.
We use the term ``items and services'' when discussing prior
authorization in this final rule. Unless otherwise stated, the policies
for prior authorization APIs and processes do not apply to drugs of any
type, meaning any drugs that could be covered by the impacted payers in
this final rule (for example, prescription drugs that may be self-
administered, administered by a provider, or that may be dispensed or
administered in a pharmacy or hospital), because the processes and
standards for prior authorization of drugs differ from the other
``items and services'' included in our final policies. In the CMS
Interoperability and Patient Access final rule, we finalized policies
that require payers to send claims data related to prescription and
other drug claims via a Patient Access API, and we are finalizing
certain provisions related to claims data in this final rule. For
example, Medicare Advantage Prescription Drug (MA-PD) plans that cover
Part A, Part B, and Part D benefits, as well as supplemental benefits,
are required to provide access to information about all those covered
benefits through the Patient Access API at 42 CFR 422.119(b).
Prescription and other drug information is part of a patient's record
and giving patients, providers, and payers access to claims data for
prescription and other drugs can offer valuable insights into a
patient's health care, provide benefits for care coordination, and help
avoid potentially harmful drug interactions. We acknowledge that there
are existing laws and regulations that may apply to prior authorization
of drugs for the impacted payers in this final rule. Thus, while the
claims data included in this final rule and existing policies do
include prescription and other drug claims, our policies in this final
rule related to prior authorization do not include standards or
policies for any drugs (as previously described), including covered
outpatient drugs under Medicaid, and Medicare Part B or Part D drugs
covered by an MA (including an MA-PD) plan.
Additionally, we use the terms ``provider'' and ``supplier'' as
inclusive terms composed of individuals, organizations, and
institutions that provide or furnish health services, such as
clinicians (that is, physicians and other practitioners), hospitals,
skilled nursing facilities (SNF), home health agencies, hospice
settings, laboratories, suppliers of durable medical equipment,
prosthetics, orthotics, and supplies (DMEPOS), community-based
organizations, as appropriate in the context used. When specifically
discussing policies related to the Medicare Promoting Interoperability
Program and the Promoting Interoperability performance category of
MIPS, we refer to MIPS eligible clinicians, eligible hospitals, and
CAHs.
Throughout this final rule, we finalize API provisions in which we
refer to the API functionality as a single API, though we acknowledge
that payers may implement this functionality by using one or multiple
APIs. For example, while we refer to the Patient Access API (discussed
in section II.A. of this final rule) as a single API to describe the
functionality, payers may achieve the same functionality with one or
multiple APIs, depending on the implementation approach.
An API is a set of commands, functions, protocols, or tools
published by one software developer (``A'') that enables other software
developers to create programs (applications or ``apps'') that can
interact with A's software without needing to know the internal
workings of A's software while maintaining data security and patient
privacy (if properly implemented). This is how API technology enables
the seamless user experiences, which are familiar in other aspects of
patients' daily lives, such as travel and personal finance smartphone
apps, which can function without being integrated into the smartphone's
operating system. Standardized, secure, transparent, and pro-
competitive API technology can provide similar benefits for patients of
health care services.\5\
---------------------------------------------------------------------------

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

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

\6\ Health Level Seven International (2023). Guide to Using HL7
Trademarks. Retrieved from https://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

[[Page 8763]]

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.

[[Page 8764]]

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

[[Page 8765]]

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">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

[[Page 8766]]

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[supreg] FHIR[supreg] Da Vinci Prior Authorization Support (PAS) IG
states it ``SHOULD NOT be used for any medication that is covered under
a prescription drug program benefit where Prior Authorization is
provided by another electronic exchange process (for example, NCPCP
SCRIPT).'' \7\
---------------------------------------------------------------------------

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

We confirm that nothing would prohibit an impacted payer from
sharing the same information about prior authorizations for drugs that
they are required to share for items and services via the Patient
Access, Provider Access, and Payer-to-Payer APIs, if they choose.
Comment: A commenter sought clarification on whether the prior
authorization requirements would apply to supplies dispensed at a
pharmacy, such as diabetic test strips. This commenter stated that an
API would likely not provide any additional benefit or improve the
timeliness of a decision and might increase handling timeframes while
the API is in the early stages of use. This commenter recommended that
pharmacy dispensable supplies maintain their current timeframes for
coverage decisions. Another commenter recommended that CMS require
impacted payers to include durable medical equipment (DME) administered
under the DME benefit in the Prior Authorization API. Another commenter
sought clarification on whether therapeutic devices are excluded from
the Prior Authorization API requirements.
Response: Supplies, including those dispensed at a pharmacy and
DME, that are considered medical benefits and are not prescription
drugs, are subject to the prior authorization requirements of this
final rule. Payers will be required to include these supplies in their
APIs, to the extent they are covered as a medical benefit and require
prior authorization. DME, for example, includes continuous glucose
monitors, test strips, lancets, orthotics, wheelchairs, and other
devices. All prior authorizations covered as a medical benefit,
including those for DME, supplies dispensed at a pharmacy, or
therapeutic devices, must still meet the timeframe requirements
established in this final rule, regardless of whether the request is
made through an API or other means, as described in section II.D.4.
However, for MA-PDs, this final rule excludes the entire scope of
``Part D drugs,'' as defined at 42 CFR 423.100, from the scope of the
prior authorization requirements; therefore, certain supplies that are
included in the definition of Part D drugs at 42 CFR 423.100 are not
subject to the prior authorization requirements adopted here.
4. Impacted Payers
As stated previously, certain portions of this final rule apply to
MA organizations, state Medicaid FFS programs, state CHIP FFS programs,
Medicaid managed care plans, CHIP managed care entities, and QHP
issuers on the FFEs. We received numerous comments regarding
applicability to the payers impacted by the rule and summarize these
comments and responses.
Comment: Many commenters supported CMS's proposed categories of
impacted payers for this rule. Specifically, commenters supported the
inclusion of Medicaid and CHIP FFS, which were excluded from the payer
to payer data exchange requirements in the CMS Interoperability and
Patient Access final rule, and MA plans, which were excluded in the
December 2020 CMS Interoperability proposed rule. Commenters noted that
the benefits of interoperable data exchange will only accrue if there
is widespread adoption by payers across the health care system.
Response: We appreciate the support for the proposed types of
impacted payers and agree that the more payers that implement the
requirements of this final rule, the greater the beneficial impact will
be on patients.
Comment: A commenter requested clarification as to whether dental
plans that provide coverage to MA enrollees or Medicaid beneficiaries
are impacted payers and encouraged CMS to exclude those plans, akin to
the exclusion of QHP issuers on the FFEs offering only SADPs. Another
commenter specifically encouraged CMS not to exclude SADPs and to
include dental plans for MA and Medicaid or CHIP managed care.
Response: We did not propose new interoperability or prior
authorization standards on SADPs on the FFEs because they have
relatively lower enrollment and premium intake compared to individual
market medical QHPs. Requiring those plans to comply with the
requirements in this final rule could result in those issuers no longer
participating in the FFEs, which would not be in the best interest of
enrollees. These plans are therefore outside the scope of this final
rule. We appreciate input from commenters who view prior authorization
and interoperability as important for SADP enrollees and will continue
to monitor this issue and work with stakeholders to understand how to
best meet patient needs while considering the potential burden on
payers.
For Medicare beneficiaries enrolled in MA plans, when dental
coverage is a supplemental benefit covered by the MA plans, it is
offered by the MA organization, directly or through contract
arrangements the MA organization uses to provide the MA supplemental
benefit. Regardless of the mechanism, the dental coverage is part of
the MA plan itself and offered under the MA organization's contract and
bid with CMS, not a separate plan. MA organizations can project
expenditures to comply with the policies in this final rule to
incorporate into their overall operational costs when setting premiums.
An organization that has a risk-based contract directly with a
state to provide dental benefits only to Medicaid and CHIP
beneficiaries is usually a PAHP. We proposed, at 42 CFR 438.210 and
438.242 for Medicaid (applicable to separate CHIP through existing
cross-references at 42 CFR 457.1230(d) and 457.1233(d)), that all PAHPs
other than Non-Emergency Medical Transportation (NEMT) PAHPs, including
those that cover dental benefits, would be subject to the requirements
of this rule. Per 42 CFR 438.4, capitation rates, which are

[[Page 8767]]

required for all risk-based MCOs, PIHPs, and PAHPs, must be projected
to provide for all reasonable, appropriate, and attainable costs that
are required under the terms of the contract and for the operation of
the managed care plan for the time period, as well as the population
covered under the terms of the contract, in addition to meeting
specific additional requirements at 42 CFR 438.4 through 438.7.
Similarly, for separate CHIP, per 42 CFR 457.1201(c) and 457.1203(a),
capitation rates are based on public or private payment rates for
comparable services for comparable populations and must represent a
payment amount that is adequate to allow the MCO, PIHP, or PAHP to
efficiently deliver covered services to beneficiaries in a manner
compliant with contractual requirements. Therefore, the concerns of
upward pressure on premiums that impact participation that are
applicable to SADPs offered on the FFEs are not present for Medicaid
and CHIP risk-based managed care plans.
Comment: A commenter suggested that CMS define the term ``payer''
to encompass health insurance issuers and group health plans subject to
the Public Health Service Act. Multiple commenters expressed their
concern that private payers, commercial plans, and employer-sponsored
plans would not be subject to the rule requirements. A commenter
expressed concern regarding the 150 million Americans who are in
employer-sponsored coverage, who may not have access to the benefits of
the proposed rule.
Another commenter suggested that CMS could use its authority over
the public sector Consolidated Omnibus Budget Reconciliation Act
(COBRA) group health plans to extend interoperability requirements to
those payers.
Response: We appreciate commenters supporting implementation of the
policies by private payers, commercial plans, and employer-sponsored
plans. However, we proposed to impose these requirements under our
authority to regulate issuers in the Exchanges that CMS operates, which
does not apply to health insurance issuers and group health plans
outside the FFEs. There is nothing prohibiting those payers from
implementing the provisions in this final rule voluntarily, as long as
there are no conflicts with other Federal or state laws, and we do
encourage those plans to voluntarily meet the requirements of this
final rule to allow patients they cover to have the same interoperable
access to their data as impacted payers are required to provide.
Title XXII of the Public Health Service (PHS) Act applies COBRA
requirements to group health plans that are sponsored by state or local
government employers. They are sometimes referred to as ``public
sector'' COBRA to distinguish them from the Employee Retirement Income
Security Act of 1974 (ERISA) and Internal Revenue Code requirements
that apply to private employers. We did not make any proposals
regarding public sector COBRA plans, so they are not included as
impacted payers in this final rule, but we will consider whether we can
and should propose similar interoperability requirements on such plans
in future rulemaking.
Comment: A commenter sought clarification regarding why CMS
exempted SHOP issuers from the proposed rule.
Response: As discussed in the proposed rule, we proposed to exclude
QHP issuers offering only QHPs in the FF-SHOPs. We believe that the
proposed standards would be overly burdensome for both SADP and SHOP
issuers. Requiring issuers offering only SADPs and issuers offering
only QHPs in the FF-SHOPs, which have relatively lower enrollment and
premium intake compared to individual market medical QHPs, to comply
with our proposals, could result in those issuers no longer
participating in the FFEs, which would not be in the best interest of
the enrollees.
Comment: Multiple commenters recommended that CMS work with ONC and
other Federal agencies, such as the Veterans Administration (VA), the
U.S. Department of Defense (DoD), and other government payers, to bring
additional data into the interoperability universe.
Response: We continue to work with ONC and agencies across the
Federal Government to move toward a fully interoperable health care
system. We are committed to sharing any insights and best practices
from our experience working with impacted payers with other agencies
that provide health care coverage to inform their own interoperability
goals. These are independent agencies over which HHS has no authority.
5. Withdrawal of Proposed Rule
In the CMS Interoperability and Prior Authorization proposed rule,
we explained that we were withdrawing the December 2020 CMS
Interoperability proposed rule (87 FR 76239). We received multiple
comments in support of this decision.
Comment: Commenters supported our withdrawal of the December 2020
CMS Interoperability proposed rule. Several commenters expressed that
the burden of prior authorization has grown since that proposed rule
was published and voiced their support for finalizing our proposals.
Response: We appreciate the support and believe that the proposals
that we are now finalizing reflect the feedback we received from the
health care industry.
6. National Directory of Healthcare
On October 22, 2022, we released a Request for Information (RFI)
(87 FR 61018) to solicit public comments on establishing an NDH that
could serve as a ``centralized data hub'' for health care provider,
facility, and entity directory information nationwide. We also received
many comments to this proposed rule that discussed the possibility of
an NDH, particularly to discover payers' digital endpoints (in this
case, a FHIR server's URL or IP address) to facilitate our Payer-to-
Payer API policy.
Comment: Many commenters stated that the lack of a national
directory makes it difficult to identify digital endpoints to
facilitate payer to payer data exchange. Multiple commenters also
expressed how important an NDH would be to the success of a Provider
Access API, because as information on provider digital endpoints
remains limited, widespread access to such a directory could advance
efforts to connect payers to providers. Commenters urged CMS to
establish an NDH before the API compliance dates and explained that not
doing so could result in an industry-wide scramble and search for
verified plan endpoints necessary for implementation. A commenter
recommended that CMS establish and maintain a national payer directory
that includes verified information on payers, including their API
endpoints, contact information for their API project managers, and
their readiness for participation in payer to payer data exchange.
Another commenter stated they are currently trying to set up their own
Payer-to-Payer API and encountered problems without a centralized
location of payer endpoints. This led to issues identifying a new
member's previous payer and making secure connections to exchange
information. A commenter cautioned that a draft version of the National
Directory IG developed by the FHIR at Scale Taskforce (FAST) originally
published in September 2022 \8\ describes

[[Page 8768]]

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

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

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

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

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

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

A. Patient Access API

1. Background
In the CMS Interoperability and Patient Access final rule (85 FR
25558), in order to give patients access to their own health
information in a way most meaningful and useful to them, we required
impacted payers to share, via FHIR APIs, certain information including
patient claims, encounter data, and a set of clinical data that
patients can access via health apps. Claims and encounter data, used in
conjunction with clinical data, can offer a broad picture of an
individual's health care experience. Patients tend to receive care from
multiple providers, leading to fragmented patient health records where
various pieces of an individual's record are locked in disparate,
siloed data systems. With patient data scattered across these
disconnected systems, it can be challenging for providers to get a
clear picture of the patient's care history, and patients may forget or
be unable to provide critical information to their provider. This lack
of comprehensive patient data can impede care coordination efforts and
access to appropriate care.
2. Enhancing the Patient Access API
In the CMS Interoperability and Patient Access final rule (85 FR
25558-25559), we adopted regulations that require certain payers,
specifically MA organizations (at 42 CFR 422.119), state Medicaid and
CHIP FFS programs (at 42 CFR 431.60 and 457.730), Medicaid managed care
plans (at 42 CFR 438.242(b)(5)), CHIP managed care entities (at 42 CFR
457.1233(d)), and QHP issuers on the FFEs (at 45 CFR 156.221), to
implement and maintain APIs that permit patients to use health apps to
access specified data. The Patient Access API must make available, at a
minimum, adjudicated claims (including provider remittances and patient
cost-sharing); encounters with capitated providers; and clinical data,
including laboratory results, with a date of service on or after
January 1, 2016, as maintained by the payer. Payers must make those
data available via the Patient Access API no later than 1 business day
after a claim is adjudicated or encounter or clinical data are
received. In the CMS Interoperability and Prior Authorization proposed
rule, we proposed various changes to enhance the Patient Access API
that are discussed further elsewhere. We also received comments about
the Patient Access API more generally, which we summarize and respond
to in this section.
To support the ongoing maintenance of the Patient Access API, we
are requiring certain specifications and recommending certain IGs, as
further discussed in this section and in section II.G. With the
publication of the HTI-1 final rule, our cross references to 45 CFR
170.215 have been updated to reflect the updated citations as needed.
Changes to the structure of 45 CFR 170.215 and versions of the API
standards codified there are discussed further in section II.G. and
reflected throughout this final rule. For the Patient Access API,
impacted payers must use the following standards: HL7 FHIR Release
4.0.1 at 45 CFR 170.215(a)(1), US Core IG STU 3.1.1 at 45 CFR
170.215(b)(1)(i), SMART App Launch IG Release 1.0.0 at 45 CFR
170.215(c)(1) and OpenID Connect Core 1.0 at 45 CFR 170.215(e)(1).
Impacted payers are permitted to voluntarily use updated standards,
specifications, or IGs that are not yet adopted in regulation for the
APIs discussed in this final rule, should certain conditions be met.
For the standards at 45 CFR 170.215 required for the Patient Access
API, updated versions available for use under our policy include, but
are not limited to, US Core IG STU 6.1.0 and SMART App Launch IG
Release 2.0.0, which have been approved for use in the ONC Health IT
Certification Program.\10\ We refer readers to policies finalized for
the Patient Access API in the Interoperability and Patient Access final
rule, as well as section II.G.2.c. of this final rule for a full
discussion on using updated standards. We are also recommending payers
use the HL7[supreg] FHIR[supreg] CARIN Consumer Directed Payer Data
Exchange IG (CARIN IG for Blue Button) STU 2.0.0, HL7[supreg]
FHIR[supreg] Da Vinci Payer Data Exchange (PDex) IG STU 2.0.0, and
HL7[supreg] FHIR[supreg] Da Vinci PDex US Drug Formulary IG STU 2.0.1.
We also direct readers to section II.G. of this final rule for a
discussion of the standards for the Patient Access API, and Table H3
for a full list of the required standards and recommended IGs to
support API implementation.
---------------------------------------------------------------------------

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

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

[[Page 8769]]

look for ways to drive adoption and use of the Patient Access API to
benefit patients. We agree that requiring a standard API will unlock
potential for developers to create patient-friendly apps.
Comment: Other commenters stated that they do not believe the
Patient Access API will be a dominant means for accessing health care
data because patients may get similar or better information elsewhere.
Commenters stated that they have not seen significant uptake of health
apps since the implementation of the Patient Access API. Commenters
relayed that while they believe in the potential for the Patient Access
API to improve the utility and portability of patient medical
information, they have not seen robust utilization of these tools,
possibly because many payers have their own portals. Some commenters
believe that their members prefer to speak with a customer service
representative, for instance, to discuss the status of their claims.
Some payers noted that although they currently have a low rate of
members using apps, they anticipated higher utilization as younger
cohorts, who are more familiar with how smartphone apps can benefit
their care, reach the age of Medicare eligibility.
A commenter flagged that the Patient Access API could result in
administrative costs being spread over a smaller than expected user
base due to its low utilization. They recommended that CMS continue to
monitor the utilization of the proposed APIs as it considers new
functionalities and requirements.
Multiple commenters expressed concerns that certain patients may
not be able to access the Patient Access API due to a variety of
factors (for example, limited access to technology/internet, software,
or apps or low digital literacy), and they encouraged CMS to consider
how it can help patients with limited digital or broadband access to
have equitable access to necessary coverage information. Stating that
some patients may not have access to the appropriate software or app,
multiple commenters recommended that CMS require states and other
entities to continue to provide written notices instead of relying on
electronic communication via the Patient Access API. Commenters also
recommended that CMS continue to monitor the Patient Access API usage
and closely track any potential disparities in access due to social
determinants of health (SDOH) or differences in digital literacy.
Response: We understand that some patients cannot or may not want
to access their health information electronically or through a health
app. Nothing in this rule will require patients to use the Patient
Access API to access their health information. Nor will the rule change
any applicable obligation for payers to make information available in
non-electronic formats, should such a requirement exist. For example,
42 CFR 435.918(a) requires Medicaid agencies to give individuals the
choice whether to receive notices electronically or by mail. Similar
requirements for MA organizations can be found at 42 CFR
422.2267(d)(2). Furthermore, under the HIPAA Privacy Rule, covered
entities generally must provide individuals access to their PHI in the
form and format requested by the individual, if it is readily
producible in such form and format; or, if not, in a readable hard copy
form or such other form and format as agreed to by the covered entity
and the individual.\11\
---------------------------------------------------------------------------

\11\ See 45 CFR 164.524(c)(2)(i).
---------------------------------------------------------------------------

However, making available digital tools, such as standardized APIs
and health apps that can access them, aligns with how many people
interact with other industries today, such as banking and e-commerce.
Making health information similarly available and interoperable
broadens patients' options for accessing their records. While many
patients may be satisfied using their payer's portal, and we do not
wish to take that option away from them, using proprietary systems and
data formats has led to a health care system where patient data are
fragmented and often difficult to exchange between parties. Entities
such as HIEs, health apps, and TEFCA Participants and Subparticipants
may be able to gather data from payers, providers, and other sources to
create a more comprehensive patient record than could be maintained by
the payer alone. Advances in nationwide data sharing, such as payers'
Patient Access APIs, connections across HIEs, and exchange enabled by
TEFCA, can facilitate secure and reliable access to these data sources.
That is the reason that CMS and HHS are invested in establishing open
standards and requirements for payers and providers to use standardized
technology. While many patients are most familiar with their payer's
portal, until the Patient Access API provisions went into effect on
January 1, 2021, their options may have been limited. We also
anticipate that adoption will take time as patients learn about their
options and choose methods for accessing their health information that
work best for them.
Comment: Multiple commenters recommended that CMS ensure that the
Patient Access API allow caregivers and dependents to have access where
patients have provided consent. A commenter urged CMS to explain how an
individual can ensure caregivers have access to their health
information via the Patient Access API. Another commenter recommended
that CMS explain that representatives should be included in all
relevant communication and considered as payers develop the API.
Response: Per the HIPAA Privacy Rule at 45 CFR 164.502(g), a
personal representative is a person authorized under state or other
applicable law to act on behalf of the individual in making health care
related decisions (such as a parent, guardian, or person with a medical
power of attorney). With limited exceptions, a personal representative
is treated as the individual for purposes of the HIPAA Privacy Rule.
Similarly, our existing Patient Access API policies (at 42 CFR
422.119(a) and (b)(1), 431.60(a) and (b), and 457.730(a) and (b) and 45
CFR 156.221(a) and (b)) explicitly apply to patients' personal
representatives.
Payers likely have different processes and policies for designating
someone as a personal representative under the HIPAA Privacy Rule and
also may be subject to similar state laws. Nothing in this rule will
require a change to those processes. Therefore, patients and personal
representatives should contact their payer for the steps to ensure
appropriate access to information via the Patient Access API. We do not
explicitly require impacted payers to send to their patients' personal
representatives the required educational resources. However, payers are
required to post those resources on their public websites and to convey
them via other appropriate mechanisms through which they ordinarily
communicate with current patients. If payers send other resources to
personal representatives on a patient's behalf, then educational
resources should be sent to them as well. In addition, there may be
program- or state-specific requirements to transmit such resources to a
patient's personal representative.
Comment: A few commenters recommended that CMS require payers to
update patient information that they are told is incorrect by a patient
or provider.
Response: Under the HIPAA Privacy Rule, at 45 CFR 164.526,
individuals have the right to have a covered entity amend PHI or a
record about the individual in a designated record set for as long as
the PHI is maintained in the designated record set, with certain
exceptions. The Patient Access API does not require the impacted payer
to

[[Page 8770]]

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

[[Page 8771]]

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

[[Page 8772]]

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,

[[Page 8773]]

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[supreg] FHIR[supreg] Da Vinci
Coverage Requirements Discovery (CRD) IG, which is the part of the
Prior Authorization API that allows a provider to query whether a payer
requires prior authorization before they will cover a specific item or
service for a specific patient. Similar queries made through other
channels, or submissions that are rejected for being unnecessary, need
not be made available through the Patient Access API unless the request
creates a record in the patient's data maintained by the payer. Though
not required, impacted payers would be welcome to make that information
available.
Comment: Multiple commenters supported our proposal that the
Patient Access API enhance transparency by including a specific reason
for denial. Commenters stated that including a reason for denial would
help beneficiaries dispute decisions in a more effective manner. A few
commenters urged CMS to require impacted payers to disclose via the
Patient Access API the specific coverage or clinical criteria upon
which the impacted payer relied to issue a denial.
Response: While we encourage payers to provide coverage or clinical
criteria that they used to make a prior authorization decision if that
information would help the patient or provider understand the prior
authorization decision, many payers consider that specific information
to be proprietary. In addition to potentially being proprietary, those
clinical criteria may be significantly more complicated than the
information we are requiring, and not easily understood by patients.
Therefore, we did not propose to require that detailed clinical
criteria for a prior authorization decision be shared with patients
through the Patient Access API. Instead, we proposed and are finalizing
that when a payer denies a prior authorization request, they must
provide a specific reason for that denial through the Patient Access
API. That reason may indicate which clinical criteria the patient did
not meet to be approved for the items or services. We reiterate that
the requirement that the specific reason for a denial be included in
the Patient Access API is in addition to any other applicable
requirements regarding notice of decisions, such as the requirement at
42 CFR 422.568(e) that MA organizations issue a notice containing
specific content when denying a prior authorization request and similar
requirements for Medicaid managed care plans at 42 CFR 438.210(c) and
for health insurance issuers offering individual health insurance
coverage (which includes QHP issuers on the FFEs) at 45 CFR
147.136(b)(3)(ii)(E).\12\
---------------------------------------------------------------------------

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

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

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

Comment: A few commenters urged CMS to require payers to include
plain language information about appealing a prior authorization
decision, including processes to request internal review and external
appeal of a decision and information about consumer programs to assist
with appeals.
Response: We did not propose to make that information available via
the Patient Access API. Our educational requirements, discussed in the
CMS Interoperability and Patient Access final rule (85 FR 25550-52),
only cover using the Patient Access API and not the prior authorization
process writ large. However, impacted payers are already required to
include that information with a notice of denial.\14\ For requirements
to make information about the appeals process available to patients via
other modalities, see further discussion in section II.D. of this final
rule. Depending on the specific requirements of their program, impacted
payers may be able to meet that requirement by providing notice about
the appeals process via the Patient Access API.
---------------------------------------------------------------------------

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

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

[[Page 8774]]

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[supreg] FHIR[supreg] Da Vinci Clinical Data Exchange (CDex) IG.\15\
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.
---------------------------------------------------------------------------

\15\ 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

[[Page 8775]]

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

[[Page 8776]]

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

[[Page 8777]]

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.\16\
---------------------------------------------------------------------------

\16\ 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.\17\ 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

[[Page 8778]]

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

\17\ 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.\18\
---------------------------------------------------------------------------

\18\ 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 \19\ [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.
---------------------------------------------------------------------------

\19\ 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.\20\ 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.\21\
---------------------------------------------------------------------------

\20\ Health Level Seven International (2022, May 28). HL7 FHIR
Release 4. 6.1.0 FHIR Security. Retrieved from https://www.hl7.org/Fhir/security.html.
\21\ 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/.
---------------------------------------------------------------------------

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.\22\ For more information about what laws may apply to health
apps, see https://www.ftc.gov/business-guidance/resources/mobile-health-apps-interactive-tool.
---------------------------------------------------------------------------

\22\ See U.S. v. 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. v. 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).\23\ 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.\24\ In 2023, the Commission brought its first
enforcement actions under the Health Breach Notification Rule.\25\
---------------------------------------------------------------------------

\23\ 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.
\24\ 16 CFR 1.98 makes inflation adjustments in the dollar
amounts of civil monetary penalties provided by law within the
Commission's jurisdiction.
\25\ See U.S. v. 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. v.
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.

---------------------------------------------------------------------------

[[Page 8779]]

c. Patient Access API Metrics
We proposed to require impacted payers to report metrics to CMS on
an annual basis about how patients use the Patient Access API, in the
form of aggregated, de-identified data. We stated that those reports
would help CMS better understand whether the Patient Access API
requirement is efficiently and effectively ensuring that patients have
access to their health information and whether payers are providing
that required information in a transparent and timely way.
Additionally, we stated that aggregated usage data from every impacted
payer would help us evaluate whether the Patient Access API policies
are achieving the desired goals. We also stated that gathering this
information would help us to provide targeted support or guidance to
impacted payers, if needed, to help ensure that patients have access to
their data and can use their data consistently across the impacted
payer types.
Specifically, we proposed that impacted payers annually report--
The total number of unique patients whose data are
transferred via the Patient Access API to a health app designated by
the patient; and
The total number of unique patients whose data are
transferred more than once via the Patient Access API to a health app
designated by the patient.
Tracking multiple data transfers would indicate repeat access,
showing that patients are either using multiple apps or allowing apps
to update their information over the course of the year. While data
transfers may not indicate to what extent patients are using apps to
manage their health care, it would be a preliminary indicator of
interest in the technology.
Comment: A majority of commenters supported CMS's proposal to
require impacted payers to report aggregated, de-identified data
metrics on how patients use the Patient Access API to CMS annually.
Response: We thank commenters for their feedback.
Comment: Commenters recommended that these metrics only be used to
evaluate the effectiveness of CMS's policies and to assess whether
patients are using the Patient Access API in a volume sufficient to
justify the administrative burden of existing and future requirements.
A commenter stated that these metrics would not reflect factors within
a payer's control and recommended that CMS work with FTC to have third-
party app developers directly report these metrics. Another commenter
warned that these metrics may not account for patient preferences for
portals or other resources aside from apps. A commenter recommended
that neither CMS nor state Medicaid agencies attempt to regulate or
oversee the usage of third-party apps by their users. Another commenter
supported the annual public reporting of Patient Access API metrics
provided that this information is not made publicly available in a
manner that identifies specific payers or apps.
Response: We acknowledge that patient app usage is generally
outside the control of payers, though education can help patients make
informed decisions. We emphasize that we proposed and will be
collecting these metrics, not to evaluate or compare payers, but to
help us understand how patients are using apps, the effectiveness of
our Patient Access API policies, and to assess potential future
rulemaking.
Making data available via a FHIR API gives patients a wider range
of options to access their data. Ultimately, patients must decide what
method of accessing their health information is most useful to them. If
patients prefer to use online portals, rather than apps, that could
inform future rulemaking. However, to understand how patients are
accessing data made available through the API using a heath app
designated by the patient, we must have access to the relevant data. We
do not intend to interfere with how a patient uses a third-party app
(and neither should impacted payers, including state Medicaid
agencies), but to provide them options to access their data in the way
that best suits them. As discussed previously, the only permissible
reason to deny or discontinue an app's access to an API is if the payer
reasonably determines that the app presents an unacceptable level of
risk to the security of PHI on the payer's systems.
We do not have the authority to require app developers to report
usage metrics, and even if we did collect data from them, it would not
provide the information that we are seeking, as developers would not
know a patient's health coverage status. For instance, a developer
could tell us that an individual connected to a specific payer
organization but would not be able to report whether the patient is
covered under by an MA plan or QHP. Finally, as noted in the proposed
rule, we do not intend to publicly publish these Patient Access metrics
in a way that identifies specific payers or apps.
Comment: A few commenters suggested that CMS establish an easy-to-
use standardized format for reporting Patient Access API metrics.
Response: We appreciate the request from commenters and are
finalizing a modification to our proposed regulatory text to require
reporting in a specified form and manner to ensure consistency between
impacted payers. We will issue specific format and process guidance for
submitting Patient Access API metrics before reporting is required.
Comment: Most commenters supported CMS's proposed metrics, as they
could provide valuable information regarding Patient Access API
adoption and use.
Commenters voiced widespread support for the first metric to
measure usage of the Patient Access API. Support for the second metric
was mixed, with multiple commenters questioning its value to the API's
policy evaluation. Commenters warned that this metric would be affected
by many external factors, including the user experience of the app, as
opposed to acts of the payer. Another commenter stated that the second
measure would not provide meaningful insight into patient use patterns,
and instead suggested that CMS should solicit information about usage
patterns from app developers.
Response: We understand that the metric on repeat usage may not
provide a high level of statistical validity, which is why we are not
requiring these metrics to be reported publicly. However, it is
important for CMS to understand how many patients are using the Patient
Access API and whether they have simply tried it once or are invested
in using health apps to manage their data. These findings will help us
monitor our interoperability policies and plan for the future. We did
not receive any comments that indicated that submitting either of these
metrics would be a significant burden for impacted payers.
We acknowledge that these metrics could be affected by a plethora
of external factors outside of payers' control. As noted previously, we
are collecting these metrics to better enable us to evaluate our
policies in this area. As we do not have regulatory authority over app
developers, we did not propose to impose reporting requirements on
them.
Comment: A commenter requested that CMS explain what constitutes a
``unique patient'' so that payers can identify unique patients in the
same manner, so the results are not varied.
Response: We define a unique patient by the record of the
individual covered by the payer's benefits, not by the individual
accessing the data. Therefore, if both a patient and their personal
representative access their data, that will only be counted as usage by
a

[[Page 8780]]

single patient for the purpose of these metrics.
i. Reporting Level
We proposed to require MA organizations to report these data to CMS
at the organization level, state Medicaid and CHIP FFS programs,
Medicaid managed care plans, and CHIP managed care entities to report
at the state level, and QHP issuers on the FFEs to report at the issuer
level. We solicited comment on whether we should require payers that
administer multiple plans under a single contract to report these data
to CMS at the contract level. We also solicited comment on an
alternative final policy that would permit MA organizations, Medicaid
managed care plans, CHIP managed care entities, and QHP issuers on the
FFEs to report aggregate data at higher levels (such as the parent
organization level or all plans of the same type in a program).
Comment: We received comments espousing a range of opinions on the
appropriate level of reporting for impacted payers.
Specifically for MA organizations, multiple commenters recommended
a more granular metric reporting level, noting that reporting Patient
Access API metrics at the plan level would better drive plan-specific
improvement efforts and be more consistent with current industry
practice. Conversely, a commenter stated that organization level would
simplify report preparation since some MA organizations have ten or
more separate plan contracts with CMS. A commenter recommended that CMS
not require reporting at the more granular contract level as any
metrics based on small populations could lead to skewed data.
Many commenters supported our proposed reporting levels for Patient
Access API use metrics for state Medicaid and CHIP FFS programs,
Medicaid managed care plans, CHIP managed care entities, and QHP
issuers on the FFEs.
On the other hand, a commenter recommended that payers be required
to report metrics at the county level, rather than the state level.
Another commenter warned that too much aggregation can make data
meaningless and stated that payers should prioritize data metrics that
can be acted upon effectively. Conversely, a commenter recommended that
CMS allow consolidation of Patient Access API use metrics at the
holding or parent company level, which would aggregate that company's
MA plans, Medicaid managed care plans, CHIP managed care entities,
QHPs, and commercial plans. Another commenter suggested that CMS begin
collecting metrics at a more aggregated level and wait to implement
more refined data segmentation as a clear use case arises.
Response: Upon further consideration, we determined that contract
level is the more appropriate reporting level for MA organizations.
Contract-level data are aggregated data that are collected from the
plan benefit packages (PBPs) offered under an individual contract; it
is specific to the contract to which it corresponds. CMS already
requires MA organizations to annually report some contract-level data
about their organization determinations to the agency. A consistent
approach of contract-level reporting in the MA program will give us
useful information while limiting payer burden. By requiring contract-
level reporting for these metrics, we ensure that the format of these
reported data remain consistent with other data that MA organizations
are required to report. There could be value to requiring MA
organizations to report on a plan level in the future to get more
discrete data. However, at this time, we believe that the burden of
requiring MA organizations to report at the plan level, and the small
sample sizes that some plans would have, outweigh the benefits of that
information.
We agree that requiring Medicaid managed care plans and CHIP
managed care entities to report at the state level and QHP issuers on
the FFEs to report at the issuer level balances the reporting burden
and the meaningfulness of the data. Aggregating by holding company
would provide data that are not particularly useful. Many commenters
recommended that we use this information to monitor disparities in data
access, which would be hindered without disaggregation between MA,
Medicaid, CHIP, and QHPs. Similarly, we do not believe that
additionally segmenting data into smaller geographic areas would
provide useful information now, though in the future we may consider
whether it would be beneficial.
We note that CMS programs may assess whether to collect more
detailed metrics than we are finalizing here. For instance, we may
consider requiring in future rulemaking that MA plans report at a more
discrete level. Similarly, should a state Medicaid or CHIP agency
believe it would be beneficial, they may require additional metrics in
their managed care contracts.
Comment: A few commenters requested that we explain whether
integrated care plans for dually eligible individuals, such as fully
integrated dual eligible special needs plans (FIDE SNPs), should report
consistent with MA organizations, at the contract level, or with
Medicaid managed care plans, at the plan level.
Response: An integrated care plan generally combines a dual
eligible special needs plan (D-SNP), which includes FIDE SNPs and
highly integrated dual eligible special needs plans (HIDE SNPs)--both
as defined at 42 CFR 422.2, and a Medicaid managed care plan offered by
the same parent organization. D-SNPs are a type of MA plan designed to
meet the needs of individuals who are dually eligible for Medicare and
Medicaid, also known as dually eligible individuals. Therefore, an MA
organization will report information about Patient Access API usage by
its D-SNP enrollees to CMS at the MA organization's contract level. The
affiliated Medicaid managed care plan will report information about
Patient Access API usage by its enrollees to CMS at the plan level.
We understand that this means an organization that offers an
integrated product for dually eligible individuals (for example, a FIDE
SNP), may report twice and in different ways for the same population.
We do not believe this duplication outweighs the benefits of capturing
the data as we proposed, but we may consider future rulemaking to
separate reporting for integrated D-SNPs from the overall MA
organization.
ii. Annual Reporting
We proposed that payers must report metrics from the previous
calendar year to CMS by March 31st of each year. Under our proposal, in
the first year the requirement would be applicable, payers would report
CY 2025 data by March 31, 2026. A new MA organization, Medicaid managed
care plan, CHIP managed care entity, or QHP issuer on the FFEs would
naturally have no data to report in its first year of existence and
would be required to report data following its first full calendar year
subject to the Patient Access API requirement.
Comment: Multiple commenters expressed support for CMS's proposal
to require payers to share patient use metrics annually starting with
CY 2025 to be reported to CMS by March 31, 2026. Some commenters
recommended that we delay the first year of the reporting requirement
to CY 2026, which would be reported no later than March 31, 2027.
Another commenter suggested that we delay the reporting deadline
because a technical solution would need to be in place by the end of
late 2024 to have metrics for CY 2025 to report in March 2026.
Response: We note that per the CMS Interoperability and Patient
Access final rule, impacted payers were required to

[[Page 8781]]

implement the Patient Access API no later than January 1, 2021. The
metrics that we proposed were not tied to the implementation of any
other proposals in the CMS Interoperability and Prior Authorization
proposed rule, including adding prior authorization information to the
data available via the Patient Access API. Based on this rule's
publication schedule, payers should have sufficient time to implement
any necessary changes to report these metrics.
Comment: A majority of commenters supported the proposed annual
reporting requirement, though multiple commenters recommended that CMS
consider requiring payers to report Patient Access API metrics
quarterly. A commenter recommended that as the popularity for Patient
Access API grows, use metrics should be reported on a quarterly basis.
Commenters agreed that requiring payers to report data on API usage
from the previous calendar year to CMS by March 31 provides an
appropriate amount of time for payers to validate the data before
submitting it to CMS.
Response: After reviewing the comments, we agree that annual
reporting is the appropriate frequency for these metrics. Given that we
are looking to understand the overall usage of third-party apps and any
patterns between payers, we do not believe that the burden of requiring
payers to report these metrics quarterly would improve our
understanding of whether patients are accessing the Patient Access API.
We may in the future consider proposing more frequent reporting or
additional metrics, but for the two metrics we are finalizing now, we
do not expect that it would be beneficial to require payers to report
more often than annually.
iii. Public Reporting
In the preamble to our proposed rule, we stated that we do not plan
to publicly report these metrics at the state, plan, or issuer level,
but may reference or publish aggregated and de-identified data that do
not include names of specific state agencies, plans, or issuers.
Comment: Some commenters recommended that CMS require payers to
publicly report Patient Access API metrics, as they believe that health
IT companies and developers would benefit from the information.
Commenters stated that by making these metrics public, CMS can help
patients and stakeholders better understand the impact of access APIs
and help inform future innovations that promote patient access and
future decision making. A commenter recommended that CMS consider
publicly reporting plan-reported information at the state, plan, or
issuer level.
Other commenters did not support CMS publicly reporting Patient
Access API use metrics. Multiple commenters stated that this could
provide inaccurate information and potentially reveal identifying
information. A commenter cautioned that publicizing reports,
particularly of the second proposed metric (the total number of
patients whose data are transferred more than once to a specific third-
party app), may give consumers an inaccurate portrayal of API success.
Response: There may be value to publicly reporting aggregated and
de-identified data to give the public a sense of Patient Access API
adoption across the industry. But we agree with commenters that, absent
the proper context, those data could be perceived inaccurately or
misleadingly. As discussed, some commenters expressed that there is
currently low health app adoption among patients regardless of the type
of payer. We also understand that low patient adoption does not
necessarily indicate a lack of payer readiness or compliance.
Therefore, until we are confident that these data can be presented in
an easy-to-understand and meaningful way, we may publicly report
aggregated and de-identified data, but will not include names of
specific state agencies, plans, or issuers unless and until proposed
through future rulemaking.
iv. Other Metrics
We requested comment on what other Patient Access API metrics we
should consider requiring payers to report to CMS and/or make available
to the public in future rulemaking. For instance, we solicited comments
on whether payers could report aggregated demographic information, such
as sex, race, age, ethnicity, and geographic data and whether that
could help identify underserved populations or disparities in patient
access to health data and, if so, policies that should be considered to
promote equity. We also solicited comments on the potential benefits
and burdens of requiring payers to report the names of all apps that
patients have used to access the payers' API each year. We considered
collecting this information, or requiring payers to make it public, not
for the purpose of recommending or endorsing specific apps, but to
review for best practices and evaluate patient ease of use.
Comment: Commenters provided many recommendations for additional
Patient Access API metrics.
Response: We greatly appreciate the wide range of metric
suggestions, such as indicators on demographic information,
utilization, query management, successful requests, and barriers to
accessing records. We will continue to research additional ways to
evaluate the effectiveness of the API for consideration in future
rulemaking.
d. Patient Access API Amendments
We proposed two minor terminology changes to the requirements
finalized in the CMS Interoperability and Patient Access final rule (85
FR 25558). Unlike most of our proposals, we proposed that these
amendments would take effect on the effective date of the final rule.
We proposed these changes to explain terms but did not expect them to
substantively change any current regulatory obligation.
First, we proposed to revise the description of the clinical data
impacted payers must make available via the Patient Access API. These
provisions, finalized in the CMS Interoperability and Patient Access
final rule, currently require payers to make available ``clinical data,
including laboratory results'' (85 FR 25536-40). We proposed to revise
these paragraphs to specify that the data that payers must make
available are ``all data classes and data elements included in a
content standard at 45 CFR 170.213.'' That citation is to a content
standard maintained by ONC of clinical data classes and data elements
for interoperable health information exchange. Referring explicitly in
the rule text to a data set in a standard at 45 CFR 170.213 will help
avoid unnecessary confusion, as this reference will more clearly
identify exactly what data must be available through the Patient Access
API. Furthermore, this change brings us into greater alignment with the
standards promulgated by ONC and used by certified health IT
developers.
As versions of the USCDI evolve, there may simultaneously be
multiple versions of the standard referenced at 45 CFR 170.213 (as both
v1 and v3 are listed at the time of publication of this final rule). In
the HTI-1 final rule, ONC finalized the adoption of USCDI v3 in 170.213
and finalized a January 1, 2026, expiration date for USCDI v1 (89 FR
1192). For the ONC Health IT Certification Program, this allows for a
transition period between standards, and, during that time, health IT
developers could incorporate updated standards versions within their
systems and complete required certification. During such a period, when
45 CFR 170.213 includes more than one version of the USCDI standard,
payers would be

[[Page 8782]]

allowed to use any of the then-referenced content standards to meet the
requirement to make clinical data available through the Patient Access
API. If a standard has a listed expiration date (as USCDI v1 is
currently listed to expire on January 1, 2026), payers would not be
able to be use it after expiration.
Second, we proposed to revise the language previously finalized for
denial or discontinuation of a health app's access to the API.
Currently, the rules require impacted payers to make a determination to
deny or discontinue access to the Patient Access API using objective,
verifiable criteria that are applied fairly and consistently across all
apps and developers through which ``enrollees'' or ``beneficiaries''
seek to access patient data. We proposed to change the terms
``enrollees'' and ``beneficiaries'' to ``parties'' for consistency with
our proposal to apply this provision to the Provider Access, Payer-to-
Payer, and Prior Authorization APIs. We stated that because parties
other than patients, such as providers and payers, would be accessing
these APIs, it would be more accurate to use the term ``parties''
rather than ``enrollees'' or ``beneficiaries.'' Those APIs are
discussed further in sections II.B., II.C., and II.D. of this final
rule.
Comment: All comments we received on these technical language
proposals supported our effort to keep the Patient Access API required
data aligned with ONC's standards. However, we did receive a variety of
comments on the USCDI standard currently referenced at 45 CFR 170.213.
Those comments are discussed in section II.G. of this final rule.
A commenter requested clarification on whether payers would be
required to request information from providers to fill any data classes
and data elements of the standard at 45 CFR 170.213 that are missing
within their records. Similarly, another commenter requested that CMS
explain that the requirement to provide claims and encounter data
within 1 business day applies only to information available at the time
of the request.
Response: In the CMS Interoperability and Patient Access final
rule, we defined ``maintain'' to mean the payer has access to the data,
control over the data, and authority to make the data available through
the API (85 FR 25538). Under that existing regulation, payers are
required to share data that they maintain as part of their normal
operations. Nothing in this final rule will change that existing
policy; payers are not required to reach out to providers or other
entities to gather data that the payer does not already maintain, if it
is not part of their normal operations, to share via the Patient Access
API. We thank commenters for their feedback and are finalizing this
proposal without modification.
We note that we are not modifying the Patient Access API
applicability date for MA at 42 CFR 422.119(h), for Medicaid FFS at 42
CFR 431.60(h), for CHIP FFS at 42 CFR 457.730(h), and for QHP issuers
on the FFEs at 45 CFR 156.221(i) because these amendments do not
substantively change any existing requirements finalized in the CMS
Interoperability and Patient Access final rule.
e. Medicaid Expansion CHIP Programs
In the CMS Interoperability and Prior Authorization proposed rule,
we discussed implementation for states with Medicaid Expansion CHIP
programs (86 FR 76279). See section II.E. of this final rule for that
complete discussion, including a summary of public comments received
and our final action statement.
f. Specific CHIP-Related Regulatory Framework
For CHIP, we proposed amendments to 42 CFR 457.1233(d) that would
align separate CHIP managed care API requirements with the Medicaid
managed care plan API requirements, rather than with the CHIP FFS API
requirements. In the CMS Interoperability and Patient Access final rule
(85 FR 25559), we finalized requirements for separate CHIP managed care
entities at 42 CFR 457.1233(d). API requirements for CHIP managed care
entities were codified at 42 CFR 457.1233(d)(2) and (3) through cross-
references to CHIP FFS program requirements at 42 CFR 457.730 and
457.760, respectively. On November 13, 2020, we published a final rule
titled ``Medicaid Program; Medicaid and Children's Health Insurance
Program (CHIP) Managed Care'' (85 FR 72754). In that rule, we removed
42 CFR 457.1233(d)(1) through (3), and, at 42 CFR 457.1233(d), cross-
referenced to Medicaid managed care regulatory requirements at 42 CFR
438.242. Therefore, the policies in the CMS Interoperability and
Patient Access final rule (85 FR 25559) are applicable to separate CHIP
managed care entities per 42 CFR 457.1233(d) through a cross reference
to Medicaid managed care at 42 CFR 438.242. We apply the API
requirements in this final rule to separate CHIP managed care entities
through the existing cross reference at 42 CFR 457.1233(d) to Medicaid
managed care at 42 CFR 438.242.
3. Other Requests for Comment
We requested comment on a variety of topics on which we did not
make specific proposals but are reviewing for future consideration. We
appreciate commenters' submissions regarding the following:
How we could and should apply these requirements to
Medicare FFS and its existing prior authorization requirements and
standards.
What policy levers we might have to create norms or best
practices for privacy policies by health app developers.
How we could leverage ONC's TEFCA or other HHS HIE
initiatives to facilitate secure interoperable data exchange with
health apps.
The availability of apps that are accessible to
individuals with disabilities, availability of apps in a multitude of
languages to ensure that individuals with limited English proficiency
can understand the information provided, and availability of apps at
appropriate literacy levels and in plain language.
BILLING CODE 4150-28-P

[[Page 8783]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.000

[[Page 8784]]

BILLING CODE 4150-28-C
4. Final Action
After considering the comments received, and for the reasons
discussed in the CMS Interoperability and Prior Authorization proposed
rule and our response to those comments (as summarized previously), we
are finalizing our proposals with the following modifications:
Impacted payers must make information about prior
authorization requests and decisions available via the Patient Access
API beginning 2027 (by January 1, 2027, for MA organizations and state
Medicaid and CHIP FFS programs; by the rating period beginning on or
after January 1, 2027, for Medicaid managed care plans and CHIP managed
care entities; and for plan years beginning on or after January 1,
2027, for QHP issuers on the FFEs), rather than in 2026.
Impacted payers are not required to share the quantity of
items or services used under a prior authorization via the Patient
Access API.
Impacted payers are not required to share unstructured
documentation related to prior authorizations via the Patient Access
API.
MA organizations must report Patient Access API metrics at
the contract level rather than at the proposed organizational level.
See further discussion for exact details of the final requirements
for impacted payers.
Specifically, we are finalizing a requirement that, beginning 2027
(by January 1, 2027, for MA organizations and state Medicaid and CHIP
FFS programs; by the rating period beginning on or after January 1,
2027, for Medicaid managed care plans and CHIP managed care entities;
and for plan years beginning on or after January 1, 2027, for QHP
issuers on the FFEs), impacted payers must make the all of following
information available about prior authorization requests and decisions
(excluding for drugs) available via the Patient Access API:
The prior authorization status.
The date the prior authorization was approved or denied.
The date or circumstance under which the prior
authorization ends.
The items and services approved.
If denied, a specific reason why the request was denied.
Related structured administrative and clinical
documentation submitted by a provider.
We are finalizing the requirement that impacted payers make this
information about prior authorizations available no later than 1
business day after the payer receives a prior authorization request and
must update that information no later than 1 business day after any
status change. This information must be available for the duration that
the authorization is active and at least 1 year after the prior
authorization's last status change.
We are finalizing a requirement that, beginning 2026, impacted
payers must annually report Patient Access API metrics to CMS in the
form of aggregated, de-identified data. Specifically, by March 31, MA
organizations at the contract level, state Medicaid and CHIP FFS
programs, Medicaid managed care plans and CHIP managed care entities at
the state level, and QHP issuers on the FFEs at the issuer level must
report the following metrics: (1) the total number of unique patients
whose data are transferred via the Patient Access API to a health app
designated by the patient; and (2) the total number of unique patients
whose data are transferred more than once via the Patient Access API to
a health app designated by the patient. Impacted payers must report the
previous calendar year's metrics to CMS by March 31 following any year
that they offered that type of plan.
We are finalizing, as of the effective date of this final rule, the
replacement of ``clinical data, including laboratory results'' with
``all data classes and data elements included in a content standard at
45 CFR 170.213'' in the required content for the Patient Access API. We
are also finalizing, as of the effective date of this final rule, to
change the terms ``enrollees'' and ``beneficiaries'' to ``parties'' at
42 CFR 422.119, 431.60, and 438.62 and 45 CFR 156.221.
These final policies apply to MA organizations, state Medicaid and
CHIP FFS programs, Medicaid managed care plans, CHIP managed care
entities, and QHP issuers on the FFEs at the CFR sections listed in
Table B1.
5. Statutory Authorities for the Patient Access API Policies
We note that we received no public comments on the statutory
authorities for our Patient Access API policies.
a. MA Organizations
For MA organizations, we proposed these new requirements and the
revisions to current requirements under our authority at sections
1856(b)(1) of the Act (to promulgate regulations implementing MA
organization standards, including the requirements in section 1852(h)
of the Act), and 1857(e)(1) of the Act (to add contract terms
determined by the Secretary to be ``necessary and appropriate'').
Section 1856(b)(1) of the Act requires the Secretary to establish
regulatory standards for MA organizations that are consistent with and
carry out Part C of the Medicare statute, Title XVIII of the Act.
Section 1852(h) of the Act requires that MA organizations have
procedures in place to maintain accurate and timely medical records and
health information regarding MA enrollees and to assure enrollees have
timely access to such records and information. Our policy for the
Patient Access API is to require access for enrollees to specified
medical records and health information through a specific mechanism
from the MA organization. The Secretary is authorized under section
1857(e)(1) of the Act to add new contract terms, including additional
standards and requirements, for MA organizations that the Secretary
finds necessary and appropriate and that are not inconsistent with Part
C of the Medicare statute. The policies here meet this standard by
addressing and facilitating access to enrollees' medical records and
health information for the reasons identified in our discussions for
each policy.
The policy in section II.A.2.a. of this final rule that will
require MA organizations to make an enrollee's prior authorization
requests and related clinical documentation available through the
Patient Access API will allow these enrollees to have access to that
information in a convenient, timely, secure, and portable way, which is
in enrollees' best interests. This requirement is consistent with
section 1852(h) of the Act, which requires MA organizations to assure
enrollees timely access to their records and data that is maintained by
MA organizations. To ensure that MA organizations meet modern-day
patient expectations of transparency, efficiency, and timeliness when
providing prior authorization data to enrollees, it is essential for
CMS to ensure that each MA organization has a standardized system in
place that offers enrollees access to their own data, including data
that pertain to their prior authorizations, using existing and emerging
technologies of their choice, specifically in this case, health apps.
Therefore, making these data available through the Patient Access API
is consistent with our programmatic authority to establish standards to
implement section 1852(h) of the Act and could help patients be more
informed about and active in their own care, which could potentially
lead to better health outcomes.
Making this information available via the Patient Access API could
help patients support the prior authorization

[[Page 8785]]

process as well. Patients could see what information is needed and what
information has been provided on their behalf to facilitate a prior
authorization request. Patients could provide missing information
needed by the payer to reach a decision. This could allow MA
organizations to address prior authorization requests more promptly,
streamlining this process, and thus simplifying prior authorization for
the MA organizations. This could also improve an enrollee's experience
with the process, by facilitating more timely and potentially more
successful initial prior authorization requests. This, again, supports
efficient operation and timely provision of information and services.
In addition, to ensure the requirements finalized in the CMS
Interoperability and Patient Access final rule (85 FR 25558 through
25559) would be most effective, CMS finalized in this rule that MA
organizations report specific metrics to CMS on patient use of the
Patient Access API. Section 1857(e)(1) of the Act explicitly authorizes
the adoption of additional reporting to CMS by MA organizations where
necessary and appropriate. Here, these metrics would facilitate CMS's
oversight, evaluation, and administration of patient health data access
in the Part C program and, therefore, this data collection is necessary
and appropriate to adopt.
In alignment with HHS's priorities and goals, CMS is focused on
putting patients at the center of their own health care and ensuring
that patients have secure access to their health information. We
believe these policies are critical and appropriate to ensure that MA
organizations stay abreast of industry standards and continue to offer
enrollees not only quality coverage but also a quality customer
experience.
b. Medicaid and CHIP
Our finalized requirements in this section for Medicaid managed
care plans and Medicaid state agencies fall generally under our
authority in sections 1902(a)(4), 1902(a)(7), 1902(a)(8), and
1902(a)(19) of the Act. Section 1902(a)(4) of the Act requires that a
state Medicaid plan provide such methods of administration as are found
by the Secretary to be necessary for the proper and efficient operation
of the state Medicaid plan. Section 1902(a)(8) of the Act requires
states to ensure that Medicaid services are furnished with reasonable
promptness to all eligible individuals. Section 1902(a)(19) of the Act
requires states to ensure that care and services under a Medicaid state
plan are provided in a manner consistent with simplicity of
administration and the best interests of the recipients.
In addition, section 1902(a)(7) of the Act requires that states
must provide safeguards that restrict the use or disclosure of
information concerning Medicaid applicants and beneficiaries to
purposes that are directly connected with the administration of the
Medicaid state plan. The implementing regulations at 42 CFR part 431,
subpart F, for section 1902(a)(7) of the Act list purposes that CMS has
determined are directly connected with administration of Medicaid state
plans (42 CFR 431.302) and require states to provide safeguards meeting
certain requirements to restrict uses and disclosures of Medicaid
beneficiary data, including requirements about releasing applicant and
beneficiary information at 42 CFR 431.306.
Our policy to require that the prior authorization data described
in this section be shared via the Patient Access API would be
consistent with the requirement at section 1902(a)(7) of the Act,
providing that states may share these data only for purposes directly
connected with the administration of the Medicaid state plan. The data
sharing policy for the Patient Access API would be related to providing
services for Medicaid beneficiaries, a purpose listed at 42 CFR
431.302(c). As mentioned previously, giving a patient access to their
own health information can make them a more active participant in
ensuring they receive timely and appropriate care (for example,
allowing them to monitor medications or access treatment history).
The finalized requirement to make information about prior
authorization requests and associated documentation available through
the Patient Access API is expected to allow beneficiaries to more
easily obtain information about the status of prior authorization
requests submitted on their behalf. Beneficiaries could potentially use
that information to make more informed decisions about their health
care, improve the efficiency of accessing and scheduling services, and,
if needed, provide missing information that the state (or Medicaid
managed care plan, if applicable) needs to reach a decision. Receiving
missing information more quickly could enable more prompt responses
from state Medicaid FFS programs and Medicaid managed care plans to
prior authorization requests, thus facilitating more timely and
successful prior authorizations. This would help states fulfill their
obligations to provide care and services in a manner consistent with
simplicity of administration and the best interests of the recipients
and to furnish services with reasonable promptness to all eligible
individuals. Improving the prior authorization process could also help
improve the efficient operation of the state plan by potentially
improving the speed and consistency of prior authorizations, which
could, in turn, facilitate faster access to care for beneficiaries. In
these ways, these policies are authorized under section 1902(a)(4),
(8), and (19) of the Act.
Additionally, states must apply the safeguards described at 42 CFR
431.306 when sharing beneficiary data via the Patient Access API. We
remind states that to meet the requirements of that regulation, states
must have consistent criteria for release and use of information (which
should comply with the finalized Patient Access API requirements), in
accordance with 42 CFR 431.306(a). Access to information concerning
beneficiaries must be restricted to persons who are subject to
standards of confidentiality that are comparable to that of the state
Medicaid agency, in accordance with 42 CFR 431.306(b). The permission
requirement at 42 CFR 431.306(d), which requires that the state agency
obtain permission from a family or individual, whenever possible,
before responding to a request for information from an outside source,
is not relevant to this policy, because any request for beneficiary
information would be from Medicaid beneficiaries themselves and the
apps that they are authorizing to receive their information.
Beneficiaries are not ``outside sources,'' and, while apps might be
outside sources, information is shared with an app through this API
only if the beneficiary has verified their identity (through
authentication protocols) and authorized the app to receive
information. We do not believe that any of the other requirements at 42
CFR 431.306 are relevant because they cover data release and use in
contexts outside of our policies in this section of the final rule. We
note that while the beneficiary's permission is not required under 42
CFR 431.306(d) for the Patient Access API we discuss here, state or
other laws may require such permission.
With respect to Medicaid managed care, and in addition to the
general authorities cited previously mentioned regarding Medicaid
programs, this policy will also help implement section 1932(b)(4) of
the Act, which provides that each Medicaid MCO must establish an
internal grievance procedure under which a beneficiary who is eligible
for medical assistance may challenge the denial of coverage or payment
for such assistance. CMS has traditionally extended requirements
applicable to

[[Page 8786]]

Medicaid MCOs to other Medicaid managed care plan types as efficient
and proper methods of administration under section 1902(a)(4) of the
Act to ensure that Medicaid beneficiaries have the same protections,
benefits, and responsibilities regardless of the type of managed care
plan in which they are enrolled. Allowing beneficiaries to access the
status of their denied prior authorizations within 1 business day could
enable beneficiaries to file appeals timelier and receive faster
resolution. Enabling beneficiaries to monitor the status of prior
authorization requests submitted on their behalf is also consistent
with how section 1932(c) of the Act indicates that timely access to
care should be assured for beneficiaries. Knowing within 1 business day
that a prior authorization has been approved could enable a beneficiary
to more promptly schedule or obtain care.
We also proposed to require state Medicaid agencies and Medicaid
managed care plans to report Patient Access API metrics to CMS
annually. These metrics will support CMS's oversight, evaluation, and
administration of the Medicaid program, as it will allow us to evaluate
beneficiary access to the Patient Access API. API usage could indicate
that the policy is supporting program efficiencies and ensuring access
to information in a timely and efficient way and in the best interest
of beneficiaries, as intended, and as is consistent with section
1902(a)(4) and (19) of the Act. Additionally, section 1902(a)(6) of the
Act requires Medicaid state plans to provide that the state Medicaid
agency will make such reports, in such form and containing such
information, as the Secretary may from time to time require. These
metrics will serve as a report to evaluate the implementation and
execution of the Patient Access API.
For CHIP, we finalized these requirements under the authority in
section 2101(a) of the Act, which states that the purpose of Title XXI
of the Act is to provide funds to states to provide child health
assistance to uninsured, low-income children in an effective and
efficient manner that is coordinated with other sources of health
benefits coverage. This provision provides us with authority to adopt
these requirements for CHIP because the finalized requirements increase
patient access to their health information, which can improve the
efficacy of CHIP programs, allow for more efficient communication and
administration of services, and promote coordination across various
sources of health benefits coverage.
We believe that requiring CHIP agencies, as well CHIP managed care
entities, to make CHIP beneficiaries' prior authorization data and
other standardized data available through standards-based APIs will
lead to these beneficiaries accessing that information in a convenient,
timely, and portable way. This improved access will help to ensure that
services are effectively and efficiently administered in the best
interests of beneficiaries, consistent with the requirements in section
2101(a) of the Act. We believe making patient data available in this
format will result in better health outcomes and patient satisfaction
and improve the cost effectiveness of the entire health care system,
including CHIP.
These policies align with section 2101(a) of the Act in that they
also will improve the efficiency of CHIP programs. For example, adding
information about prior authorization requests to the Patient Access
API will allow beneficiaries to easily obtain the status of prior
authorization requests made on their behalf. This will in turn allow
patients to make scheduling decisions and provide any missing
information needed by a payer to reach a decision, which makes the
prior authorization process more efficient, streamlining the prior
authorization process.
Additionally, the safeguards for applicant and beneficiary
information at 42 CFR part 431, subpart F, are also applicable to CHIP
through a cross-reference at 42 CFR 457.1110(b). As discussed
previously for Medicaid, giving CHIP beneficiaries access to their
prior authorization statuses through the Patient Access API would be
related to providing services to beneficiaries, which is described at
42 CFR 431.302(c) as a purpose directly related to state plan
administration. Allowing beneficiary access to prior authorization
statuses also conforms with provisions for beneficiary access to their
records at 42 CFR 457.1110(e). We remind states that when they share
beneficiary information through the Patient Access API, they must
comply with the privacy protections at 42 CFR 457.1110 and the release
of information provisions at 42 CFR 431.306.
Finally, by finalizing the requirement for state CHIP agencies and
CHIP managed care entities to report Patient Access API metrics to CMS
annually will help states and CMS understand how this API can be used
to continuously improve the effectiveness and efficiency of state CHIP
operations by providing information about its use, which is an
indication of the API's uptake among patients, including how many only
use it for a one-time setup consistent with 2107(b)(1) of the Act. The
more we understand about the Patient Access API's usage, the better we
can assess that the API is leading to improved operational efficiencies
and providing information to beneficiaries in a way that supports their
best interests.
c. Qualified Health Plan Issuers on the Federally-Facilitated Exchanges
For QHP issuers on the FFEs, we finalized these new requirements
under our authority at section 1311(e)(1)(B) of the Patient Protection
and Affordable Care Act, as amended by the Health Care and Education
Reconciliation Act of 2010 (Pub. L. 111-148, enacted March 23, 2010,
and Pub. L. 111-152, enacted March 30, 2010, respectively)
(collectively referred to as the Affordable Care Act) which affords the
Exchanges the discretion to certify QHPs if the Exchange determines
that making available such health plans through the Exchange is in the
interests of qualified individuals in the state in which the Exchange
operates.
We believe generally that certifying only health plans that take
steps to make enrollees' prior authorization requests and related
clinical documentation available through interoperable technology would
ultimately lead to these enrollees having access to that information in
a convenient, timely, and portable way, which is in enrollees' best
interests. Adding information about prior authorization requests to the
Patient Access API would allow enrollees to easily obtain the status of
prior authorization requests submitted on their behalf and use that
information effectively to make more informed decisions about their
health care, improve the efficiency of accessing and scheduling
services, and, if needed, provide missing information needed by the
issuer to reach a decision. This could allow QHP issuers on the FFEs to
more promptly address prior authorization requests and would also
facilitate more timely and potentially more successful initial prior
authorization requests. We encourage SBEs (including SBE-FPs) to
consider whether a similar requirement should be applicable to QHP
issuers on SBEs.
Finally, requiring QHP issuers on the FFEs to report Patient Access
API metrics to CMS annually will help CMS assess the effect this API is
having on enrollees and will inform how CMS could either enhance the
policy or improve access or use through activities

[[Page 8787]]

such as additional patient education. These data could help CMS
understand how best to leverage this API, and patient access to it, and
to ensure this requirement is being met efficiently and adding value to
CMS operations, including leading to the intended efficiencies.

B. Provider Access API

1. Background
In the CMS Interoperability and Patient Access final rule, we
required impacted payers to implement a Patient Access API (85 FR
25558) that allows patients to access their health information through
a third-party app. Patients who do so could then share their
information with their provider during an appointment. For example,
during a visit with a provider, a patient could share specific
diagnoses, procedures, and tests accessed through the Patient Access
API, to inform the discussion with their provider.
In the CMS Interoperability and Patient Access proposed rule (84 FR
7610), we had sought comment on the feasibility of implementing and
maintaining a FHIR API for data exchange between payers and providers
and received comments strongly supporting our concept to require data
availability through a Provider Access API. Some commenters stated that
allowing providers to receive data, including prior authorization
information, directly from payers, would make FHIR-based data exchange
significantly more valuable for patients, providers, and payers. More
data could be available to help providers manage a patient's care and
providers could reduce or eliminate duplicate tests. Payers might also
see fewer duplicate requests for services, fewer appeals and, possibly,
lower costs. In the final rule, we specifically agreed with commenters
that making available information about prior authorization decisions
via an API would reduce burden on providers and their staff (85 FR
25541). We also discussed the potential benefits of payers sharing
patient health information directly with providers (85 FR 25555) and
encouraged payers to consider an API solution that would enable direct
provider access to appropriate health information to support the
delivery of care.
While the Patient Access API was a significant first step toward
sharing individual patient health information with providers, we
believe it would benefit patients if payers were required to make
patient data directly available to providers via a FHIR API. In the
normal course of business, many providers already maintain EHRs and
share data for a variety of purposes authorized by the patient and/or
existing law. Therefore, in the CMS Interoperability and Prior
Authorization proposed rule, we proposed to require impacted payers to
implement and maintain a FHIR API that makes patient data available to
providers who have a contractual relationship with the payer and a
treatment relationship with the patient. The Provider Access API has
the potential to allow payers to build upon their existing systems and
processes to enhance access to patient data, while continuing to
protect patient privacy and data security.
We also proposed a patient opt out (rather than an opt in) policy
that would require payers to allow patients to opt out of the Provider
Access API. Finally, we proposed Provider Access API compliance dates
in 2026 (by January 1, 2026, for MA organizations and state Medicaid
and CHIP FFS programs; by the rating period beginning on or after
January 1, 2026, for Medicaid managed care plans and CHIP managed care
entities; and for plan years beginning on or after January 1, 2026, for
QHP issuers on the FFEs).
As mentioned in section I.A. of this final rule, these policies do
not pertain to Medicare FFS. In the proposed rule, we solicited comment
on whether our Provider Access API proposal could be implemented in the
Medicare FFS program. We expect that a Medicare FFS implementation
would generally conform to the same requirements that apply to the
impacted payers under this final rule, so Medicare FFS providers and
beneficiaries enrolled in Medicare FFS could also benefit from this
type of data sharing. We solicited comment on whether these
requirements could be implemented as proposed, how we could apply each
of these proposals, and if there would be any differences implementing
the Provider Access API for the Medicare FFS program as a Federal
payer. CMS's Data at the Point of Care (DPC) project is currently
piloting an API that makes Medicare FFS claims and Part D data
available to certain providers. However, some differences exist for
Medicare FFS. For instance, provider remittances and patient cost-
sharing information are not proprietary, so those data are shared in
the DPC pilot; however, we proposed that impacted payers would not be
required to share that information under our policies. Because the DPC
API currently enables provider access to patient data and involves
processes like authenticating the provider and verifying a patient
treatment relationship with an attribution process, the information
gained from the DPC pilot will be useful to impacted payers as we
finalize proposals in this rule.
2. Requirements for Payers: Provider Access API for Individual Patient
Information
In the CMS Interoperability and Patient Access final rule (85 FR
25558), we required impacted payers to make certain health information
available through a Patient Access API when requested by a patient. We
stated that it would be valuable for providers to have access to the
same patient data, except for provider remittances and patient cost-
sharing information, through a FHIR API that allows a provider to
request data for an individual patient, as needed, thereby providing
them with further insight into the patient's health care. Research
shows that patients achieve better outcomes when their record is more
complete, and more data are available to the health care provider at
the point of care.\26\ Making more comprehensive information available
to providers could thus improve the care experience for patients.
Ensuring that providers have access to relevant patient data at the
point of care could also reduce the burden on patients to recall and
relay information during an appointment and/or provide confirmation
that the patient's recollection of prior care is accurate.
---------------------------------------------------------------------------

\26\ Office of the National Coordinator for Health Information
Technology (ONC) (2019, June 4). Improved Diagnostics & Patient
Outcomes. Retrieved from https://www.healthit.gov/topic/health-it-basics/improved-diagnostics-patient-outcomes.
---------------------------------------------------------------------------

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

[[Page 8788]]

APIs would facilitate the FHIR-based exchange of claims and encounter
data, all data classes and data elements included in a content standard
at 45 CFR 170.213 (USCDI), and certain information about prior
authorizations maintained by the payer.
We also stated that we believed that sharing claims and encounter
data (without provider remittances and patient cost-sharing
information) would complement the data classes and data elements
included in a content standard at 45 CFR 170.213 (USCDI) by providing
more information to support treatment and care coordination. Claims and
encounter data, used in conjunction with clinical and other available
data, can offer a broader, more complete picture of an individual's
interactions with all their providers in the health care system. With
that proposal, we intended to help providers gain efficient access to
more comprehensive data on their patients. Specifically, we proposed to
require impacted payers to make available any of the applicable patient
data with a date of service on or after January 1, 2016, that they
maintain. This timeframe for data to be included is consistent with the
requirements of the Patient Access API, as finalized in the CMS
Interoperability and Patient Access final rule (85 FR 25567), so payers
should already be maintaining and making available the same set of data
from this timeframe via a FHIR API.
Finally, we explained that, unlike the Patient Access API, the
Provider Access API would not include provider remittances and patient
cost-sharing information. Many payers consider cost-sharing information
proprietary and, while we do not necessarily agree with such a
characterization, we believed that information would have limited
benefit for treatment or care coordination and thus excluded it from
the scope of data required to be accessible through the Provider Access
API.
We proposed that payers would be required to make available via the
Patient Access and Provider Access APIs information related to prior
authorization requests and decisions for items and services (excluding
drugs). This information would include, as applicable:
The prior authorization status.
The date the prior authorization was approved or denied.
The date or circumstance under which the prior
authorization ends.
The items and services approved;
If denied, a specific reason why the request was denied.
Related structured administrative and clinical
documentation submitted by a provider.
We proposed that information about prior authorizations be
available via the Patient Access API for as long as the authorization
is active, and for at least 1 year after the last status change, and
that this would apply to the Provider Access API, as well. We noted in
the proposed rule that this provision would be particularly relevant to
denied and expired prior authorizations, to ensure that they would be
available for at least a year after expiring or being denied. We did
not propose to require payers to share a patient's full prior
authorization history, because that could comprise a significant amount
of information that may no longer be clinically relevant.
In general, our proposal for the data that payers would have to
make available through the Provider Access API, as well as the
technical specifications, aligned with the requirements for the Patient
Access API finalized in the CMS Interoperability and Patient Access
final rule (85 FR 25558) and those that were proposed for the Patient
Access API in the CMS Interoperability and Prior Authorization proposed
rule (87 FR 76238).
However, we further explained that there are a few notable
differences between the requirements for a Patient Access API and those
for a Provider Access API. The biggest difference is how and why the
end user will access the data. For the Patient Access API, the patient
is requesting access to their own data through a health app for their
own reference and use, and potentially to share the data with a
provider. For the Provider Access API, we expect that a provider will
request and receive access to the patient's information through their
EHR, practice management system, or other technology for treatment
purposes. Providers will securely access their patients' data through a
FHIR API using at least one of these systems. Providers will not access
patient data through their own health app; rather, the data will flow
from the payer to the provider's EHR or practice management system,
which will allow them to incorporate the patient data into their
records, should they choose to do so. For example, a provider who is
preparing for an upcoming appointment may need more information about
the patient than is contained in the patient's record in their own
systems. Under this proposal, the provider would be able to request the
additional data from the patient's payer. The payer would then be
required to share the requested data no later than 1 business day after
receiving a request from a provider who meets all other requirements to
access the data.
In the CMS Interoperability and Patient Access final rule we
required standards for the Patient Access API by cross reference to 45
CFR 170.215 (85 FR 25558). We proposed to require certain standards at
45 CFR 170.215 that are applicable to the Provider Access API. We are
finalizing our proposals for the Provider Access API with
modifications, requiring impacted payers to use the following
standards: HL7 FHIR Release 4.0.1 at 45 CFR 170.215(a)(1), US Core IG
STU 3.1.1 at 45 CFR 170.215(b)(1)(i), SMART App Launch IG Release 1.0.0
at 45 CFR 170.215(c)(1), and Bulk Data Access IG v1.0.0: STU 1 at 45
CFR 170.215(d)(1). We are also recommending payers use the CARIN IG for
Blue Button STU 2.0.0, PDex IG STU 2.0.0, and SMART App Launch IG
Release 2.0.0 to support Backend Services Authorization. We proposed
but are not finalizing to require impacted payers to use OpenID Connect
Core for reasons discussed later in this section. We refer readers to
Table H3 for a full list of the required standards and recommended IGs
to support API implementation. We refer readers to section II.G. of
this final rule for further discussion of the required and recommended
technical standards for the Provider Access API.
For Medicaid and CHIP managed care, we proposed that NEMT PAHPs, as
defined at 42 CFR 438.9(a) and 457.1206(a) respectively, would not be
subject to the requirement to establish a Provider Access API. As
proposed at 42 CFR 438.242(b)(7) and by cross-reference at 42 CFR
457.1233(d), all other Medicaid managed care plans and CHIP managed
care entities (that is, MCOs, PIHPs, and non-NEMT PAHPs) would be
subject to this final rule. We stated our belief that the unique nature
and limited scope of the services provided by NEMT PAHPs, which only
cover transportation and not medical care itself, justified their
exclusion from the requirements of the Provider Access API.
Specifically, we did not believe that providers have routine need for
NEMT data; therefore, requiring NEMT PAHPs to implement and maintain a
Provider Access API (and a Payer-to-Payer API, as discussed in section
II.C.3. of this final rule) would be an undue burden. However, we did
propose that NEMT PAHPs be subject to the requirements for the Patient
Access API, Prior Authorization API, and prior authorization processes.
We acknowledged that it could be helpful for all providers to have
access to their patients' data regardless of contractual or enrollment
relationships

[[Page 8789]]

with a patient's payer. However, we proposed to only require impacted
payers to share data with in-network or enrolled providers. We
recognized that this could make it more difficult for an out-of-network
provider to create or access a more comprehensive care record for a
patient. We considered requiring payers to make the data available to
all providers, regardless of whether the provider is under contract or
enrolled with the payer. We will continue to consider a requirement to
share patient data with out-of-network providers for future rulemaking.
To this end, we requested comment in the proposed rule on existing
processes for sharing data with out-of-network providers. Though we did
not propose to require it, we encouraged payers to share information
via API with out-of-network or unenrolled providers to the extent
permitted by law if they can verify a treatment relationship. For state
Medicaid and CHIP FFS programs specifically, data sharing with out-of-
network and unenrolled providers would need to comply with Medicaid
confidentiality rules as required by section 1902(a)(7) of the Act and
implemented in our regulations at 42 CFR part 431, subpart F.
We are finalizing our proposal to require impacted payers to make
available to providers, via the Provider Access API, claims and
encounter data (without provider remittances and patient cost-sharing
information), all data classes and data elements included in a content
standard at 45 CFR 170.213, and certain information about prior
authorizations (excluding those for drugs). However, as with the
Patient Access API policies, we are finalizing a modification to our
proposal and not requiring payers to share the quantity of items or
services used under a prior authorization or unstructured documentation
related to a prior authorization. We are finalizing these changes to
the Provider Access API policy with compliance dates in 2027 (by
January 1, 2027, for MA organizations and state Medicaid and CHIP FFS
programs; by the rating period beginning on or after January 1, 2027,
for Medicaid managed care plans and CHIP managed care entities; and for
plan years beginning on or after January 1, 2027, for QHP issuers on
the FFEs), which is a year after the proposed 2026 compliance dates.
Throughout this rule, we generally refer to these compliance dates as
``in 2027'' for the various payers.
To support the Provider Access API implementation and maintenance,
we are requiring certain standards and recommending certain IGs, as
further discussed later and in section II.G. of this final rule. With
the publication of the HTI-1 final rule, our cross references to 45 CFR
170.215 have been updated to reflect the updated citations as needed.
Changes to the structure of 45 CFR 170.215 and versions of the API
standards codified there, are discussed further in section II.G. and
reflected throughout this final rule. For the Provider Access API,
impacted payers must use the following standards: HL7 FHIR Release
4.0.1 at 45 CFR 170.215(a)(1), US Core IG STU 3.1.1 at 45 CFR
170.215(b)(1)(i), SMART App Launch IG Release 1.0.0 at 45 CFR
170.215(c)(1), and Bulk Data Access IG v1.0.0: STU 1 at 45 CFR
170.215(d)(1). Impacted payers are permitted to use updated standards,
specifications, or IGs that are not yet adopted in regulation for the
APIs required in this final rule, should certain conditions be met. For
the standards at 45 CFR 170.215, updated versions available for use
under our policy include, but are not limited to, US Core IG STU 6.1.0,
the SMART App Launch IG Release 2.0.0, and the Bulk Data Access IG
v2.0.0: STU 2, which have been approved for the ONC Health IT
Certification Program.\27\ We refer readers to section II.G.2.c. of
this final rule for a full discussion on using updated standards. We
also recommend payers use the CARIN IG for Blue Button STU 2.0.0, PDex
IG STU 2.0.0, and SMART App Launch IG Release 2.0.0 to support Backend
Services Authorization. We refer readers to Table H3 for a full list of
the required standards and recommended IGs to support API
implementation.
---------------------------------------------------------------------------

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

a. General Comments
Comment: Multiple commenters supported CMS's proposal to require
impacted payers to develop and maintain a Provider Access API and
recommended that CMS finalize the proposal. Multiple commenters also
noted that the API would give health care providers invaluable insights
into patient care, which could lead to better quality care, reduce
duplicate services, and streamline provider workflows. A commenter
recommended that CMS focus its efforts on the secure exchange of data
from patients to providers via the Patient Access API, which could
allow the patient to be an intermediary who can choose which payer data
to share with the provider.
Response: We agree with commenter sentiments about the various
benefits to both providers and patients of providers having improved
and direct access to patient data. As explained throughout this final
rule, the requirements and standards for the Provider Access API will
largely align with those currently in place and that we are finalizing
for the Patient Access API. We anticipate that this alignment will
provide consistency and help payers build on the work done to comply
with the requirements for the Patient Access API. Enabling improved
data sharing directly with providers, who have the clinical expertise
to effectively use the data to improve patient care, is a logical next
step for our API implementation requirements.
b. Compliance Dates
Comment: Multiple commenters supported the proposed 2026 compliance
dates for the Provider Access API, as the appropriate time when the IGs
will be sufficiently mature. Other commenters supported earlier
compliance dates for the Provider Access API, including dates in
calendar years 2024 and 2025.
By contrast, multiple other commenters requested that CMS delay the
implementation of the Provider Access API. Many recommended the
compliance dates for the Provider Access API be at least 3 years after
the issuance of the final rule to allow for provider and payer
collaboration. Commenters stated this would allow payers and providers
to stagger the separate implementation of the HIPAA Standards for
Health Care Attachment proposed rule (87 FR 78438). A commenter stated
that delaying the implementation of the Provider Access API requirement
would enable the industry to develop consistent attribution
methodologies and establish opt out policies. A commenter suggested
that if CMS finalizes its proposal to require payers to implement
Provider Access APIs and require a response within 1 business day, it
should delay the compliance dates until 2027.
Multiple commenters flagged that CMS does not have to require
implementation on any particular calendar date, since it would not
affect an enrollee's plan benefits or premiums. A commenter
specifically stated that the implementation does not need to be
synchronized to the beginning of the plan benefit year for MA
organizations and QHP issuers on the FFEs.
A commenter sought clarification on the compliance dates as it
relates to onboarding new providers to a payer's network, in order to
ensure these new providers are following all applicable regulations,
laws, and testing requirements by the proposed

[[Page 8790]]

compliance dates in 2026. Multiple commenters recommended that CMS
develop the Prior Authorization API before fully implementing the
Provider Access API. A commenter further recommended that CMS phase in
implementation of the Provider Access API. They believe CMS should
allow additional time for development of the Provider Access API to
maximize its utility and provided suggestions for additional
capabilities to do this.
Response: After consideration of public comments, we are finalizing
a 1 year delay in the compliance dates, to 2027 (by January 1, 2027,
for MA organizations and state Medicaid and CHIP FFS programs; by the
rating period beginning on or after January 1, 2027, for Medicaid
managed care plans and CHIP managed care entities; and for plan years
beginning on or after January 1, 2027, for QHP issuers on the FFEs). As
discussed in section I.D. of this final rule, we are delaying the
compliance dates for each of our policies that require API development
and enhancement (though other policies on new reporting metrics and
prior authorization processes are being finalized with different
compliance dates). While making data related to prior authorizations
available to providers is necessary and urgent, we also understand that
the policies we are finalizing will take time for payers to implement.
An additional year will give payers time for a smooth rollout of this
new API, as well as to onboard their providers. Payers may communicate
these policies to any new providers through the same channels they
currently use to communicate participation rules, coverage guidelines,
and other important plan information with new providers joining their
network. Because we are delaying the compliance dates, we do not
believe a phased implementation is necessary, even if the additional
time is used to implement functionalities for the API that we are not
requiring in this final rule. We emphasize that the compliance dates
are merely a deadline, and we encourage payers to meet the requirements
of this rule as soon as possible to benefit their patients and
providers. The additional year will also give impacted payers the
requested time to establish the required attribution and opt out
processes (discussed in sections II.B.3.a. and II.B.3.b. of this final
rule, respectively).
Finally, we decline to delay the compliance dates for this policy
until after the Prior Authorization API is implemented and are
finalizing the same compliance dates for all three new APIs. We agree
that the purpose of the Prior Authorization API is to facilitate the
exchange of structured (as defined in section II.A.2.a.ii. of this
final rule) prior authorization data, and therefore receiving requests
electronically may expedite payers' ability to make that information
available to providers. However, even after the Prior Authorization API
compliance dates, we expect that a number of prior authorizations are
going to be submitted through other channels (hopefully in declining
number). A provider's access to this information should not depend on
the method and process that a payer sets for providers to submit a
prior authorization request. Rather, the purpose of our Provider Access
API policies is that providers have access to their patients' data (if
patients do not opt out). That means that payers will need to be able
to share through the required APIs any prior authorization information
that is submitted in ways other than the Prior Authorization API,
regardless of the compliance dates. By finalizing 2027 compliance
dates, we are providing payers an additional year beyond our proposal
to implement the needed functionality within their internal systems.
While we acknowledge that the compliance dates may not need to be at
the start of a calendar, contract, or rating year, finalizing our
proposal with specific compliance dates will ultimately reduce
confusion for all parties.
Comment: A commenter cautioned that without information that will
be contained in an anticipated ONC proposed rule, it is difficult to
provide realistic timelines for making prior authorization data
available. They recommended that CMS offer an additional public comment
period after the publication of this separate, anticipated ONC rule to
allow the industry appropriate time to review the proposed changes that
would be incorporated into the provider's workflow.
Response: Regarding ONC regulations, we recognize that commenters
are interested in future ONC policies which may relate to the policies
in this rule. ONC issued both the HTI-1 proposed and final rules since
the publication of our proposed rule. As discussed, cross references in
this final rule have thus been updated accordingly. We will continue to
work with ONC to explore the adoption of standards and health IT
certification criteria where appropriate to streamline data exchange,
support interoperability, and increase efficiencies associated with the
policies in this final rule. We further note that the Unified Agenda,
at the time of publication of this final rule, has been updated to
include an entry for a proposed rule from ONC entitled ``Health Data,
Technology, and Interoperability: Patient Engagement, Information
Sharing, and Public Health Interoperability'' (RIN 0955-AA06). The
description indicates that the proposed rule aims to advance
interoperability, including proposals to expand certified APIs for
electronic prior authorization.\28\ However, the policies in this rule
can be finalized independently of future rulemaking by ONC and we are
not providing an additional period for comment.
---------------------------------------------------------------------------

\28\ Office of Information and Regulatory Affairs. Executive
Office of the President (2023). Health Data, Technology, and
Interoperability: Patient Engagement, Information Sharing, and
Public Health Interoperability. Retrieved from https://www.reginfo.gov/public/do/eAgendaViewRule?pubId=202304&RIN=0955-AA06.
---------------------------------------------------------------------------

c. Identifying Providers and Networks
Comment: Multiple commenters requested clarification on the
definition of ``providers'' that are eligible to use the Provider
Access API. A commenter recommended that CMS permit providers who use a
Type 2 National Provider Identifier (NPI) number to use the Provider
Access API. Multiple commenters also believed that providers other than
physicians should have access to patient data via the Provider Access
API. A commenter recommended that the final rule explain whether the
Provider Access API can be used by clinical laboratories. Another
commenter believed that a Tax Identification Number (TIN) should be
used for patient attribution purposes, rather than an NPI because it
would give an opportunity for multiple providers in the same practice
to access a patient's information.
Response: Providers who should have access to a patient's data are
those, whether they are an individual, a facility, or a group of
providers who have come together as an Accountable Care Organization
(ACO), who are appropriately licensed, provide items or services
eligible for coverage by the payer, and are enrolled with the payer or
in the payer's provider network. Should a clinical laboratory, or other
entity such as an ACO, meet these criteria, it would indeed be a
provider who could use the Provider Access API to access patient data,
assuming all other criteria outlined in this final rule are met.
Multiple providers in the same practice may also be able to access a
patient's data if the practice is enrolled with a plan under a Type 2
NPI (that is, an organization's NPI), or if those providers are part of
an ACO that is

[[Page 8791]]

requesting data on a provider's behalf, because all the providers in
such organizations would be part of the payer's network. Furthermore,
an ACO typically has business associate agreements with the providers
that comprise the ACO, that should allow them to request data on the
provider's behalf. Impacted payers may even elect to use patient
rosters from such multi-provider practices or ACOs, as well as a
practice's TIN, as part of its attribution process (see section
II.B.3.a. of this final rule) since the patients on these rosters could
be attributed to all the providers in these organizations.
Comment: Multiple commenters sought clarification on how CMS
defines a payer's network. A commenter inquired whether CMS's intention
was to only include contracted providers who have both a contractual
relationship with the payer and a treatment relationship with the
patient, and as to which facilities are considered contracted or out-
of-network. Another commenter asked for CMS to further define
``treatment relationship with the patient.'' A different commenter
sought clarification on the definition of in-network providers for a
plan that operates in multiple territories and has some providers that
may be in-network for one location and out-of-network for another.
A commenter further recommended that CMS consider how to allow for
effective patient data transfers in more complex provider-facility
relationships, meaning contracted individual and institutional
providers. A commenter also recommended that CMS consider the nuances
of cancer therapy networks when developing its final policies, as some
payers utilize a cancer therapy network and cover services furnished by
certain providers who may be considered out-of-network generally, but
in-network for certain cancer treatments.
Other commenters suggested that CMS explain whether impacted payers
with leased networks would be subject to the in-network requirement and
recommended that leased network providers not be considered in-network
for purposes of the Provider Access API. One of these commenters raised
the concern that requiring QHP issuers on the FFEs to share patient
information with leased network providers would impose a burden on
QHPs, noting that the in- and out-of-network status of these providers
could depend on a plan's benefit package. These commenters noted that
these networks are often rented or leased from other payers, and that
the QHP issuer that is renting the network may not have control over
provider contract standards.
Response: We are finalizing that impacted payers will be required
to make the specified patient data available to in-network or enrolled
providers with whom the patient has a verified treatment relationship
(determined via an attribution process, as discussed in section
II.B.3.a. of this final rule), assuming the data access conforms to all
other applicable laws and regulations, such as state privacy laws. As
discussed elsewhere, a payer can establish a treatment relationship by
determining whether the patient's claims history, proof of an upcoming
appointment, or other information (for example, hospital admission
letter) demonstrates a treatment relationship with the provider.
Nothing in this final rule would require the information used to verify
the provider's relationship to the patient to be shared or exchanged
via the Provider Access API itself. We also remind readers that, though
we are not requiring payers to share patient data with out-of-network
or unenrolled providers, we encourage them to do so to the extent
permitted by law if they can verify a treatment relationship.
Impacted payers that operate in multiple service areas, and
therefore have some providers that are in-network in a particular area
but out-of-network in other areas, should treat the providers based on
network status on a case-by-case basis, depending on the payer's
service area applicable to each enrollee. For example, if Providers A
and B are both in-network for the plan, but Enrollee C resides in a
service area where only Provider A is in-network, then the plan can
treat Provider A as in-network and Provider B as out-of-network for
making Enrollee C's data available via the Provider Access API.
However, we remind readers that while not required, it would still be
permissible to grant access to the Provider Access API to Provider B.
The fact that Provider B already has a contract with the payer would
even help to mitigate the potential privacy, security, and program
integrity concerns we discussed in the proposed rule. The presence of
this contractual relationship is also why we agree with the commenter
regarding providers who are part of a cancer therapy network. If
providers are in-network for some services for a patient, then they are
an in-network provider. Our goal with our Provider Access API policies
is to maximize the number of providers who can use it.
We acknowledge that there may be health care settings and
facilities where only some of the providers are enrolled with or have a
provider agreement with the impacted payer (as applicable). Under the
HIPAA Privacy Rule, covered health care providers generally may
disclose certain PHI to other health care providers for treatment
purposes.\29\ Thus, there may be cases where a provider may share
relevant patient data obtained via the Provider Access API with another
provider who may not be in-network or enrolled with the impacted payer.
However, under our requirements, payers would only be required to share
data through the Provider Access API in response to requests from in-
network or enrolled providers (as applicable).
---------------------------------------------------------------------------

\29\ See 45 CFR 164.506(a).
---------------------------------------------------------------------------

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

\30\ ECP and Network Adequacy (n.d.). Essential Community
Providers and Network Adequacy. Retrieved from https://www.qhpcertification.cms.gov/s/ECP%20and%20Network%20Adequacy.
\31\ A ``delegated entity'' is defined at 45 CFR 156.20 to mean
any party that enters into an agreement with a QHP issuer on the
FFEs to provide administrative services or health care services (for
example, contracted providers).
\32\ A ``downstream entity'' is defined at 45 CFR 156.20 as any
party that enters into an agreement with a delegated entity or with
another downstream entity to provide administrative services or
health care services (for example, subcontracted providers).
---------------------------------------------------------------------------

d. Provider Adoption and Use
Comment: Multiple commenters agreed with the scope of the Provider
Access API, but expressed concern about potential penalties for
providers who are unable to adopt technology that supports data
exchange via this API.
Response: We did not propose any requirements for providers to use
the Provider Access API, nor did we propose penalties for providers who
do not use the API. However, accessing patient data through the
Provider Access API will improve providers' ability to furnish quality
care to patients. We expect that providers too

[[Page 8792]]

will see the benefit of this technology and having patient data
available directly from payers.
Comment: Multiple commenters flagged that providers should have
access to a patient's health information without technological or
financial barriers, and that CMS should consider the costs to health
centers, safety net providers, long-term and post-acute care (LTPAC)
settings, and hospitals with low resources, as well as their unique
needs with regard to implementing use of the Provider Access API. They
believed that considering these provider types would ensure more
widespread use of the API. A commenter stated that some small
businesses do not have the staff or funding to set up a complex data
exchange and they believed there is a need to engage them in
discussions about the benefits of the health information exchange.
Another commenter stated that the proposed rule did not offer any
indication of available resources to help providers implement the API.
A commenter recommended CMS consider investments that health centers
make to ensure appropriate interoperability and access.
A commenter urged CMS to track and counteract any equity issues
that may manifest from operationalizing the Provider Access API.
Multiple other commenters flagged that the true impact of APIs on
everyday practices will not be understood until they are implemented
and being used by providers, with another commenter recommending that
CMS focus targeted efforts to engage provider specialties and groups
who have traditionally lagged in uptake of interoperable technology.
Response: We agree that technology should not be a barrier to
accessing appropriate patient information and our policies are intended
to make such access easier for providers. We recognize that there are
care settings that lag in adoption of EHR and other health IT, and/or
lack the staff or resources to make use of the Provider Access API,
which could result in these care settings missing out on the benefits
of data exchange. Nevertheless, making data available via a FHIR API,
which ensures these data are available to any authorized system seeking
to access it, will benefit settings that may not have sophisticated
technological solutions. Furthermore, making these data available is a
vital antecedent to increased data sharing and interoperability across
the health care system. We will be closely monitoring implementation
and use of the Provider Access API to assess its real-world impact on
care delivery, such as the possible equity concerns described by the
commenters, as well as continue to work with providers to encourage and
enable them to use the API, should they wish to do so.
Comment: Multiple commenters recommended that CMS seek to
understand the current state of health IT and the needs of end users
before mandating Provider Access API implementation. A commenter stated
that the health IT infrastructure across the industry is not ready to
support the APIs. Another commenter representing payers, providers, and
clearinghouses in both the public and private sector noted that when
they surveyed their payer members on the Provider Access API
implementation, 64.3 percent of payers responded it would be ``very
difficult or difficult'' to implement.
Response: We disagree with the commenters' assessment that existing
health IT infrastructure is not ready to support the Provider Access
API. Payers are currently required to maintain a Patient Access API
that enables the exchange of the same data as we are requiring to be
available via the Provider Access API, with the caveat that this rule
establishes new requirements to include information related to prior
authorizations. The Patient Access API establishes the foundation to
ensure that existing payer health IT infrastructure is indeed capable
of also supporting the Provider Access API. For providers, as of
October 2018, eligible professionals and hospitals collectively
received over $38 billion in incentives to adopt, implement, upgrade
(AIU), and demonstrate meaningful use of certified EHR technology
(CEHRT) through the Medicare and Medicaid Promoting Interoperability
Programs (formerly the Medicare and Medicaid EHR Incentive
Programs).^{33 34 35} As of 2021, 78 percent of office-based
physicians and 96 percent of non-Federal acute care hospitals had
adopted CEHRT.\36\ CEHRT now incorporates functionality for standards-
based FHIR APIs. We thus believe health IT developers can build on
these standards-based APIs to further develop functionality in provider
systems that supports access to Provider Access APIs.
---------------------------------------------------------------------------

\33\ Centers for Medicare and Medicaid Services (2018).
Promoting Interoperability (PI) Program Medicare Incentive Programs.
Retrieved from https://www.cms.gov/Regulations-and-Guidance/Legislation/EHRIncentivePrograms/Downloads/October2018_MedicareEHRIncentivePayments.pdf.
\34\ Centers for Medicare and Medicaid Services (2018).
Promoting Interoperability (PI) Program Medicare Incentive Programs.
Retrieved from https://www.cms.gov/Regulations-and-Guidance/Legislation/EHRIncentivePrograms/Downloads/October2018_MedicareEHRIncentivePayments.pdf.
\35\ Centers for Medicare and Medicaid Services (2017). MA
Organization (MAO) Incentive Payments for Eligible Professionals.
Retrieved from https://www.cms.gov/Regulations-and-Guidance/Legislation/EHRIncentivePrograms/Downloads/May2017_MAO-Report.pdf.
\36\ Office of the National Coordinator for Health Information
Technology (ONC) (2020). National Trends in Hospital and Physician
Adoption of Electronic Health Records. Retrieved from https://www.healthit.gov/data/quickstats/national-trends-hospital-and-physician-adoption-electronic-health-records.
---------------------------------------------------------------------------

Comment: Multiple commenters underscored the need to establish
incentives for providers to adopt the Provider Access API to offset any
provider burden. Commenters cited quality measure reporting through the
MIPS and CEHRT programs as possible avenues for incentives. Another
commenter recommended that CMS and ONC work together to create
incentives for vendors to improve EHR functionality and for providers
to utilize the API, as well as provider educational resources to
encourage adoption.
Response: For reasons explained previously, we believe that
providers will see the benefit of using the Provider Access API, but we
intend to closely monitor providers' experience, as well as consider
ways to encourage use of the API in future rulemaking, if need be. We
remind readers that nothing in this final rule would prohibit impacted
payers themselves from incentivizing and/or requiring use of the
Provider Access API. However, should they choose to implement such a
policy, we remind impacted payers to carefully weigh the expected
benefits against any potential new burden on providers.
Comment: Multiple commenters stated that the Provider Access API
may be duplicative of existing resources (for example, HIEs or HINs,
multi-payer portals, or other existing mechanisms for accessing claims
data). Many other commenters supported creating the ability to
integrate information from the Provider Access API into the provider's
EHR system. These commenters recommended that CMS work closely with
both providers and EHR vendors to ensure that integrating data from the
Provider Access API is user-friendly and incorporated into the clinical
workflow. They stated that that would make patient data from the
Provider Access API organized and navigable. Another commenter stated
that because patients often receive care from multiple health
providers, they often have fragmented patient health records, which can
make it difficult for providers to get a clear picture of a patient's
health history.
Multiple commenters, however, expressed concerns regarding the
feasibility of the Provider Access API. A

[[Page 8793]]

commenter stated that the biggest challenge to the implementation of
Provider Access API is that providers generally interact with many
payers and it is not feasible for provider organizations to support
many one-to-one connections with payers. The commenter stated that
while it would be costly and risky, the urgency to implement a National
Data Warehouse Exchange Hub/Clearinghouse has never been greater.
Response: We understand commenters' concern about the potential for
duplication of the Provider Access API functionalities that existing
resources may provide. However, not all providers currently use or have
access to other resources that can access patient data.^{37 38}
Further, the data we are requiring payers to make available under this
final rule may not be available from other sources. Thus, the Provider
Access API can be a valuable tool for providers, even if they currently
have access to data via an HIE/HIN or other source. We anticipate that
providers will find benefits to patient care from having patient data
available from multiple sources.
---------------------------------------------------------------------------

\37\ Office of the National Coordinator for Health Information
Technology (ONC) (2021). Electronic Health Information Exchange by
Office-based Physicians. Retrieved from https://www.healthit.gov/data/quickstats/electronic-health-information-exchange-office-based-physicians.
\38\ Office of the National Coordinator for Health Information
Technology (ONC) (2023). Interoperability and Methods of Exchange
among Hospitals in 2021. Retrieved from https://www.healthit.gov/data/data-briefs/interoperability-and-methods-exchange-among-hospitals-2021.
---------------------------------------------------------------------------

We emphasize that the responsibility for implementing and
maintaining the Provider Access API falls on impacted payers, not on
providers or provider organizations. Further, in this final rule, we
prioritize sharing structured data elements through standardized APIs
(see section II.A.2.a.ii. of this final rule). Thus, even though this
final rule does not obligate providers to use the Provider Access API,
we anticipate that health IT vendors will integrate data from this API
for providers in a manner that is organized, navigable, and useful to
providers. We encourage vendors to work with their clients so that
information accessed via the Provider Access API is useful for filling
in gaps in the patient record, rather than creating duplicative data,
and providers can take full advantage of their benefits.
Comment: Multiple commenters suggested that CMS should take steps
to ensure that costs borne by EHR vendors are not passed onto
providers, and that implementation is done in a manner that minimizes
burden for providers. Multiple commenters also recommended that CMS
explicitly require payers to allow providers to use the Provider Access
API at no charge and that CMS should monitor and enforce such a
requirement against payers who attempt to charge providers a user fee
to access the APIs.
Response: Our goal is to improve care and reduce burden on
patients, health care providers, and payers. We also recognize that EHR
vendors, providers, and payers have costs of doing business. We
strongly encourage EHR vendors to only charge reasonable fees for any
initial or periodic system configurations required to access payers'
API endpoints. Furthermore, EHR vendors and payers should ensure that
any fees charged per API call are necessary and reasonable based on any
actual maintenance costs for that entity. We also strongly encourage
payers to permit providers to use their Provider Access API at no cost
to maximize usage and benefits to patient care, which would ultimately
benefit the payer as well. We will continue to work with interested
parties to ensure that health care providers are not unnecessarily
burdened and to ensure that our regulations do not place conflicting or
unnecessary burdens on entities that may be regulated by more than one
Federal agency.
Furthermore, EHR vendors and some impacted payers may be
information blocking actors (as defined at 45 CFR 171.102) that must
abide by ONC's regulatory requirements. Specific details of the
information blocking regulations and other regulations issued by ONC
are outside the scope of this final rule. Additional information about
ONC information blocking regulations is available from the Information
Blocking page of ONC's website: https://www.healthit.gov/topic/information-blocking. Questions may be sent to ONC's Health IT Feedback
and Inquiry Portal at https://inquiry.healthit.gov/. Payers who are
information blocking actors (as defined at 45 CFR 171.102) and have
committed information blocking (as defined at 45 CFR 171.103) may be
subject to civil money penalties by the HHS Office of the Inspector
General (OIG). Interested parties should address questions regarding
when particular practices might be considered information blocking to
ONC.
Finally, we did not propose to implement a prohibition against
payers charging providers a user fee to access their APIs. We will
closely monitor implementation of the Provider Access API and whether
user fees present a significant impediment to interoperable data
exchange. We will also be monitoring the frequency and type of feedback
we receive from providers, patients, and payers related to burden and
cost, to determine whether other policies might be ripe for
consideration in future rulemaking. See section I.D.2. of this final
rule for more information about CMS's enforcement and compliance
policies.
Comment: A commenter wanted to ensure that payers cannot require
providers and clinical staff to use multiple different tools that might
leverage the Provider Access API to treat patients. The commenter
stated that providers should have autonomy to deliver care without
having to add new technology that payers may require them to implement.
Another commenter similarly recommended that CMS ensure payers do not
increase burden on providers, stating that a significant burden would
be placed on providers if their network participation gets conditioned
on payer requirements to use the Provider Access API. Another commenter
urged CMS to prohibit payers from placing additional contractual
demands on providers, such as unrealistic turnaround times for
physicians to retrieve patient information. The commenter expressed
concerned that if providers cannot comply with payers' potential new
requirements, they may be forced out of network.
Response: This rule does not require payers to impose requirements
to use the Provider Access API on their in-network or enrolled
providers. However, both providers and patients can benefit from the
improved interoperability facilitated by FHIR APIs, with providers in
particular seeing the benefits of having more patient data available to
them. Contractual requirements set by payers for their in-network or
enrolled providers are out of the scope of this rule. Nonetheless, if
payers do choose to require providers to use the Provider Access API in
some capacity, or even if they develop and require their own apps, we
expect that they would do so to improve coordination with the provider
and patient care, and also in a way that does not add provider burden.
Comment: A commenter noted that clinical data managed by payers are
often derived from claims submitted by providers, which often results
in them being in a different level of detail and format than clinical
data exchanged between providers. The commenter stated that when the
data are made available to providers, clear communication of those
differences and accurate interpretation by the receiving provider's
system is essential for enabling the provider to use the data to

[[Page 8794]]

address care gaps and make treatment decisions. The commenter added
that because the data are derived from claims, which would have been
submitted by many of the same providers requesting it from the payer,
deduplication of the data can become more complex. They further
recommended that standards for representing the provenance of data when
transmitted from payers to providers be enhanced to avoid adding a
reconciliation burden on providers who receive the patient data.
Another commenter said that EHR vendors would need to develop a
``curation function'' that could allow providers (and patients) to
select the specific data to incorporate into the patient's record,
warning that without this capability, there will be a significant
amount of duplicate and junk data that will render the Provider Access
API unusable.
Response: We thank the commenter for the comments, and we
appreciate the concerns regarding the level of detail, format, and
potential duplication of data received by providers' systems. One of
the IGs we recommend for the Provider Access API is the PDex IG (see
Table H3 in section II.G. of this final rule) is a set of guidelines
that describes how to exchange data between payers and providers. A key
PDex IG feature is the capability to include provenance records, if
they exist, when exchanging data. Provenance records describe where the
data came from and how they were processed. The PDex IG strongly
recommends that payers create provenance records when they are not
included in a data set. We also strongly recommend provenance records
in cases, like those cited by the commenter, when clinical data are
derived from claims. The provenance profile contains contextual
information about the data, including the data's original author(s),
transmitters, and formats (including whether they are derived from a
claim-related transaction). Thus, using the PDex IG can help mitigate
the problem of duplicating data by including provenance information. We
also strongly recommend that the data source be included at the point
of record creation, so that users can appropriately understand the
source and context of the data. While we acknowledge the potential
complexity of deduplicating data, creating contextual provenance
information could help providers' systems identify data that already
exist in the system, which can make the data actionable, rather than
duplicative. In this way, payers can help providers unlock the benefits
of accessing patient information through the Provider Access API.
Finally, nothing in this final rule obligates providers to incorporate
data they access via the Provider Access API into their patient's
record, if they do not believe there is a benefit.
Comment: A commenter suggested that CMS permit payers to include
audit rights and penalties in their provider contracts to ensure that
payers are able to monitor and regulate information access requests, as
the structure of the proposed rule effectively asked payers to trust
that providers who request access to patient information have a valid
need to access that information.
Response: Nothing in this final rule prohibits impacted payers from
including additional requirements in their provider contracts and/or
terms of service for requesting patient data. However, we emphasize
that our requirement to provide access is limited to in-network
providers who have a treatment relationship with the patient. We
understand that payers need to ensure that provider requests are
appropriate, so it follows that those entities would want to define
roles and responsibilities through provider contracts, as these are
established vehicles which delineate other payer requirements. If
payers choose to implement such requirements, or a separate terms of
service agreement, we strongly encourage them to balance the benefits
to patients against any additional burden this would place on
providers. Further, our requirements on the impacted payer will ensure
that patients are informed of their data sharing options and will have
the opportunity to opt out of data sharing under this policy if they do
not wish for their providers to have access to their data. Any
requirements that payers implement to use the Provider Access API must
not conflict with the HIPAA Rules, or any other applicable law. See
sections II.B.2.j. and II.B.3.b.ii. for discussions on the interaction
of this final rule with the HIPAA Rules.
Comment: Multiple commenters cautioned that this rule puts a large
burden on payers with little burden on providers and that given the
number of resources needed to implement the API, provider uptake is
critical. A commenter further stated that this rule requires payers to
build a new API and share information with providers without asking
providers to contribute or share information with payers, which they
believe will lead to a breakdown in communication between providers and
payers.
Response: As discussed previously, the technical requirements for
the Provider Access API align almost identically with those already
established for the Patient Access API (85 FR 25510) that impacted
payers are currently required to maintain. We also emphasize that our
recommended IGs will provide further clarity for payers on how to
implement the APIs, thus reducing some of the implementation burden. As
we discuss in section II.B.3., we are not being prescriptive as to how
impacted payers implement their attribution and opt out processes, so
that they can design processes that work best for them. We believe that
all parties will see the benefit of improved data exchange facilitated
by the Provider Access API. Because this final rule does not prohibit
it, impacted payers may also decide to require providers to share
certain data with them as part of their network/enrollment
requirements. In fact, we understand that such requirements already
exist in some situations. However, should payers implement such
polices, we expect that they would do so only to the extent that it
would benefit patient care and not add provider burden. We strongly
encourage payers to carefully weigh any expected benefits against this
potential burden. Finally, the Health IT Certification Program has
already established requirements for FHIR APIs in EHR systems, which
creates the capability for providers to make data available to payers
via FHIR APIs. Using those APIs would allow payers to implement any
requirements in a way that imposes minimal burden on providers.
Comment: A commenter recommended that CMS explain whether only
providers, not EHR vendors, can trigger a request for patient records.
Response: We are only requiring impacted payers to make patient
data available to in-network or enrolled providers. Vendors are not
permitted to request data for themselves, as they are not providers and
thus cannot meet the criteria for making such a request. However, an
EHR vendor may request the patient data via the provider's system at
the behest of a provider who is eligible to request the data, with
appropriate authentication and if consistent with other applicable law.
e. Data Content
Comment: Multiple commenters recommended that CMS streamline the
proposed required data to limit duplicative information and potentially
overwhelming providers. A commenter recommended that CMS initially
focus the Provider Access API on sharing claims data before introducing
other

[[Page 8795]]

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

\39\ Office of the National Coordinator for Health Information
Technology (ONC) (2023). Health Insurance Information. Retrieved
from https://www.healthit.gov/isa/uscdi-data-class/health-insurance-information#uscdi-v3.
---------------------------------------------------------------------------

We remind impacted payers that if there is additional information
beyond that which we are requiring that they do or can share with
providers, they can use the Provider Access API as a mechanism for
sharing that information, as permitted by applicable law. To the extent
that impacted payers maintain patient data (per the CMS
Interoperability and Patient Access final rule [85 FR 25536]) collected
by payer-owned providers and health service companies, only the data
elements specified in this final rule are included in the Provider
Access API requirements.
Comment: A commenter recommended that CMS support the development
of content and technical standards for prior authorization decisions
that can be incorporated into IGs for testing before requiring
inclusion of prior authorization information in the Provider Access
API.
Response: Our recommended IGs (listed in Table H3) are currently in
production and several versions of the IGs have been updated since
publication of the proposed rule. Additionally, the recently published
PDex IG STU 2.0.0 specification includes a prior authorization profile
that enables payers to communicate prior authorization decisions and
changes to the status of a prior authorization requests. The process
for IG development is open and we encourage industry engagement in
their further development via opportunities such a HL7 FHIR
Connectathons.
Comment: A commenter recommended that CMS require USCDI v3, since
the proposed Provider Access API would not be implemented until 2026.
The commenter stated that the USCDI v1 does not have digital data
standards for social determinant of health (SDOH), sexual orientation
and gender identity (SOGI), nor other data standards important for
public health capabilities, and this could be a missed opportunity to
drive national digital data standardization in this area. The commenter
suggested this requirement would create a business case and drive
adoption of standards and a move by industry to align.
Response: At the time the proposed rule was published, USCDI v1 was
the only standard included at 45 CFR 170.213. The HTI-1 final rule,
however, finalized that USCDI v1 expire on January 1, 2026, and also
adopted USCDI v3 at 45 CFR 170.213 (89 FR 1210). Both versions will be
available USCDI versions at 45 CFR 170.213 until January 1, 2026. Until
this date, payers may meet the Provider Access API requirements by
sharing all data classes and data elements in either USCDI v1 or v3.
After January 1, 2026, payers must make available all data classes and
data elements in USCDI v3. ONC accepts submissions from the public for
new USCDI data classes and data elements through the USCDI ONC New Data
Element and Class (ONDEC) Submission System \40\ and regularly
publishes updated versions of the USCDI.\41\ Any change in a content
standard at 45 CFR 170.213 will go through notice-and-comment
rulemaking. Impacted payers are permitted to voluntarily use updated
standards, specifications, or IGs that are not yet adopted in
regulation for the APIs discussed in this final rule, should certain
conditions be met. We specifically encourage impacted payers to make
all data classes and data elements available from more advanced
versions of the USCDI prior to the expiration date. We refer readers to
section II.G.2.c. of this final rule for a full discussion on using
updated standards.
---------------------------------------------------------------------------

\40\ Office of the National Coordinator for Health Information
Technology (ONC) (n.d.). USCDI ONDEC (ONC New Data Element and
Class) Submission System. Retrieved from https://www.healthit.gov/isa/ONDEC.
\41\ Office of the National Coordinator for Health Information
Technology (ONC) (n.d.). United States Core Data for
Interoperability (USCDI). Retrieved from https://www.healthit.gov/isa/united-states-core-data-interoperability-uscdi.
---------------------------------------------------------------------------

Comment: A commenter noted that while there is a FHIR resource for
a scheduled appointment, it is not included in USCDI v1, which means a
provider cannot send an appointment even when they have implemented the
latest version of USCDI. The commenter stated that adding that element
would require additional EHR vendor development.
Response: All data classes and data elements included in a content
standard at 45 CFR 170.213 (USCDI) for dates of service after January
1, 2016, maintained by the payer are required to be made available to
the provider who requests them (assuming all other applicable
requirements specified in this final rule are met). Whether or not a
scheduled appointment data element is included in USCDI has no bearing
on how API developers use the Scheduling

[[Page 8796]]

and Appointment FHIR Resources for other purposes.
Comment: Multiple commenters disagreed with the proposal to require
payers to include clinical documentation and forms related to a prior
authorization, with one noting that this information will be
duplicative of the clinical information in a person's medical record.
Another commenter stated that clinical documentation is often submitted
to payers in the form of lengthy PDF documents, and sometimes by fax,
making manually translating these data into FHIR challenging and
infeasible to do within the proposed 1 business day timeframe. A
commenter recommended that CMS explain whether payers have to convert
clinical documentation submitted by providers by fax or in PDF or JPEG
file formats into FHIR. A commenter recommended that CMS require the
same discrete data element standards that the agency applied to the
original Patient Access API to the Provider Access API, since
distributing patient clinical attachments to all requesting clinicians
raises concerns under the HIPAA minimum necessary standard. The
commenter stated that an alternative is that providers could share
clinical attachments as needed through clinician data sharing
consultation and collaboration. However, a commenter recommended that
CMS should include the administrative and clinical documentation
requirements and require specific information for prior authorization
data.
Response: After reviewing the comments, we agree that the burden of
requiring payers to make unstructured documentation (as explained in
section II.A.2.a.ii. of this final rule) available via the Provider
Access API outweighs the benefits such documentation would provide.
Thus, like for the Patient Access API, we are finalizing a requirement
that the Provider Access API include only structured administrative and
clinical documentation related to the prior authorization requests.
As with the Patient Access API, documentation received in an
unstructured format does not need to be parsed and converted to
structured data for the purposes of inclusion in the Provider Access
API. However, if a payer does parse the unstructured documentation to
store the contained data in a structured format, that structured data
would then be ``maintained'' by the payer, as defined in the CMS
Interoperability and Patient Access final rule (85 FR 25538). For
example, a payer may receive and maintain an unstructured PDF that
contains lab results. If a payer maintains those lab results in a
structured format, they would be required to share them under this
final rule. If they are maintained in an unstructured format, they
would not.
We recognize that unstructured administrative and clinical
documentation could be important to help providers understand certain
prior authorization requirements, so we encourage payers to make that
information available when possible. Furthermore, the policy we are
finalizing would require payers to make available any documentation or
materials that the provider sends to the payer to support a decision
that are received in a structured format. Since we are finalizing that
only structured documentation be made available, and structured
documentation are formatted in a way that makes them easily
transmissible between systems, our final policy should place
significantly less burden on payers than our proposal, while still
giving providers access to information about their prior authorization
processes.
It is important for payers to make available the specific clinical
data at which they are looking to make a determination on the prior
authorization request, even if that information may be elsewhere in the
patient's record. As to the commenter concerned about clinical
attachments and the HIPAA Privacy Rule's minimum necessary standard, we
refer them and all readers to section II.B.3.b.ii. of this rule for
more discussion about the HIPAA Rules.
Comment: A commenter sought clarification on whether the data
sharing requirement applies to only claims and encounter data that are
available at the time of the request, reasoning that if so, it could
avoid any inappropriate pressure on providers to submit claims
immediately after the provision of an item or service.
Response: Per the CMS Interoperability and Patient Access final
rule (85 FR 25536), payers are only required to share data that they
maintain as part of their normal operations. Nothing in this final rule
would change that existing policy that payers are not required to reach
out to providers or other entities to gather data that they do not
maintain, if it is not part of their normal operations, in order to
share via the Provider Access API.
f. Provider Remittances and Cost-Sharing Information
Comment: Multiple commenters agreed with CMS's proposal to not
require payers to make available provider remittances and patient cost-
sharing information, as it would likely only have a limited beneficial
impact on care. A commenter stated the cost-related data currently
available via from the Patient Access API are not very clear, which
could lead to different implementations and increased ambiguity when
implementing the Provider Access API. A commenter warned that
implementers are inconsistent, with some sending Explanation of
Benefits (EOB) scrubbed of the item level detail, whereas others
exclude EOBs altogether and only provide clinical data.
Response: Regardless of whether provider remittance information or
cost-sharing information are truly confidential or proprietary
information protected from disclosure under Federal law (which we do
not address here), excluding such data from the Provider Access API is
appropriate. Thus, if commenters believe that cost-sharing information
would largely not be helpful information for providers to have access
to, then we emphasize that sharing this information is not a
requirement for the Provider Access API. We further agree with
commenters that including this information in the Provider Access API
will have limited benefit for treatment or care coordination. This rule
does not prohibit payers from sending that information. Therefore, if a
payer believes that implementing their Provider Access API in such a
way that includes provider remittances and patient cost-sharing
information would provide benefit or reduce burden, they are not
prohibited from doing so under this rule, and may do so consistent with
other applicable laws.
Comment: Multiple commenters urged CMS to reconsider excluding
cost-sharing information from the Provider Access API because providers
with access to this information can make more informed decisions
regarding patient care by incorporating cost into treatment plans, and
in turn, maintain a good provider-patient relationship. A commenter
encouraged CMS to examine standards-based, patient-facing, and real-
time benefit check capabilities that can be facilitated by patient
cost-sharing information. A commenter also cautioned that excluding
provider remittances and cost information conflicts with the cost-
sharing information needed to enable Good Faith Estimates (GFE) under
the No Surprises Act (NSA), which was enacted as part of the
Consolidated Appropriations Act, 2021 (CAA).\42\ They suggested that
the rule be revised to

[[Page 8797]]

allow necessary cost-sharing information required under the NSA.
Another commenter highlighted that providers must be able to calculate
sustainable total cost of care for patients attributed to them as part
of value-based payment models.
---------------------------------------------------------------------------

\42\ Public Law 116-260 (December 27, 2020).
---------------------------------------------------------------------------

Multiple commenters proposed potential solutions to facilitate the
sharing of cost-sharing information. A commenter suggested that CMS
consider a bi-directional exchange mandate (as opposed to one-way
provider access to payer data) to cover payment and operations, in
addition to treatment. A commenter suggested that it does not make
sense to restrict patient cost-sharing information since it is
available in the X12 270/271 transaction standard. The commenter stated
the Provider Access API can potentially replace the need for a separate
270/271 transaction and instead incorporate the information in 270/271
transactions. Another commenter expressed that modifications could be
made to the CARIN IG for Blue Button to align with the proposed
requirement to remove remittances and cost-sharing data from the FHIR
transaction.
Response: While we appreciate the various suggestions we received;
we did not propose any related policies because the primary purpose of
our Provider Access API policies is to improve the exchange of data for
health care treatment. We acknowledge that some providers may find cost
information helpful for gaining a clearer picture of a patient's
financial situation. However, there is nothing prohibiting a provider
from discussing the costs of various items or services and comparing
the costs when furnished in-network and out-of-network to help a
patient understand how to limit their out-of-pocket costs. Further, in-
network or enrolled providers should be generally aware of the costs of
various treatments, as their contracts would address payment amounts
and conditions of payment for services furnished by that provider to a
covered individual. We finally note that the GFE provision of the NSA
relates to prospective costs, rather than cost information from past
claims; that provision is beyond the scope of this final rule.
Comment: A commenter stated that the CARIN IG for Blue Button will
require updates to support CMS's proposal to remove remittances and
cost-sharing data from the FHIR transaction for the Provider Access
API.
Response: Further development is currently underway on the CARIN IG
for Blue Button, which is one IG that we are recommending to support
the Patient Access, Provider Access, and Payer-to-Payer APIs (see Table
H3 in section II.G.4. of this final rule). These developments will
support exchanging information without provider remittances and patient
cost-sharing information.
Comment: A commenter supported CMS's effort to establish the
infrastructure needed to support payment reform and value-based care
initiatives via the Provider Access API, stating that these initiatives
are critical to reducing the costs of health care delivery while
maximizing quality for Medicare enrollees. Multiple commenters stated,
however, that the Provider Access API does not facilitate sharing the
complete set of information needed by providers for participation in
value-based care programs and recommended that CMS prioritize
additional information, such as financial targets, spending,
coordination of care payments, payer-generated attributed
beneficiaries, and cost performance reporting. They believe these would
allow a better exchange of value-based care payment models' summary-
level data. A commenter recommended that ONC and CMS encourage industry
to prioritize APIs to exchange information that would reduce
administrative burden and lead to value-based care scalability.
Response: We did not propose to include cost information for value-
based care, as the primary goal of the Provider Access API is to give
providers both immediate and direct access to patient data in order to
improve patient care. However, we remind impacted payers that they can
use the API to exchange additional data, should they so choose. We
agree that FHIR APIs have the potential to support participation in
value-based care programs, as these initiatives are critical to
reducing the costs of health care delivery while maximizing quality for
patients. We will continue to explore ways to leverage FHIR APIs to
achieve CMS and broader HHS priorities. The requirements in this final
rule are a critical foundation for this future work.
g. Prior Authorization Data
Comment: Multiple commenters supported including prior
authorization information in the data made available through the
Provider Access API, noting that it would help future providers
understand the patient's current health status more quickly and better
meet their care needs, increase transparency, and reduce burden on
patients and providers. A commenter stated that adding prior
authorization information to the Provider Access API will enhance
functionality and incentivize use of the API.
Response: We thank commenters for their support and agree that
giving providers access to the same prior authorization data as
patients will have a positive impact on patient care.
Comment: Multiple commenters recommended not including ``the
quantity of services used'' due to delays in claims processing. A
commenter recommended that CMS include just the approved number of
units.
Response: In response to commenter feedback to both the Provider
and Patient Access API proposals, we are finalizing our proposal with
the modification that ``quantity of approved items or services used to
date'' will not be a required field. We refer readers to section
II.A.2.a.ii. of this final rule for a full discussion of our reasoning.
Comment: A commenter recommended including a standardized comment
code(s) and comment description(s) for each status update sent to the
provider to help with future data analysis of prior authorization
improvements and tracking quality metrics.
Response: While we consider five basic statuses (pending, active,
denied, expired, authorization not required) to cover the general scope
of a prior authorization requests and decisions, we do not intend to
prescribe or delineate the exact statuses that payers must use. The
requirement for the Provider Access API (and the other APIs in this
rule) to include the status of the prior authorization is intended to
provide information to the provider, patient, or other payer that is
using the API to access this information. Therefore, compliance with
the requirement is not based on using specific terms, but on providing
clear information. We refer readers to section II.A.2.a.ii. of this
final rule for a full discussion on prior authorization status
definitions.
Comment: A commenter recommended that CMS crosswalk the required
types of data for the Provider Access API with the other proposed APIs
to avoid duplication, such as having to include supporting
documentation through the Provider Access API, even if it is available
via the Prior Authorization API.
Response: If the commenter is recommending that the Provider Access
API make available a mutually exclusive set of data from the Prior
Authorization API to avoid confusion, then we note that Prior
Authorization API will not have prior authorization data from other
providers. We refer readers to section II.D. of this final rule for our
full

[[Page 8798]]

discussion of the Prior Authorization API requirements. We further
intend to provide educational resources related to all the APIs in this
final rule. We are not finalizing our proposal that related
unstructured administrative and clinical documentation be included in
the prior authorization data that impacted payers would have to make
available to providers via the Provider Access API.
Comment: A commenter recommended including the following additional
data elements related to prior authorization: timestamps of any change
in the status of the prior authorization; date/time received, reviewed,
denied/approved; how the decision was made; software tools/artificial
intelligence (AI) tools used; and persons involved in making the prior
authorization decision. Another commenter stated that prior
authorization metrics should be available via the Provider Access API
to give providers an aggregated view of their attributed patients'
prior authorizations. A commenter also recommended that CMS should
require payers to make available through the Provider Access API
contact information for the entity responsible for managing the payer's
prior authorization program.
Response: While these specific additional data and functionalities
may provide value to some providers at this time, we do not believe
that the value outweighs the additional effort impacted payers would
need to expend to add these data and functionalities to the Provider
Access API. The PDex IG STU 2.0.0, which has been published since the
publication of the CMS Interoperability and Prior Authorization
proposed rule, states that payers using this IG shall make available
pending and active prior authorization decisions and related clinical
documentation and forms for items and services (not including
prescription drugs), including the date the prior authorization was
approved, the date the authorization ends, as well as the units and
services approved and those used to date. It also requires a creation
date, issued date, and specific codes relevant to the approval
status.\43\ However, as discussed in section II.G., we are not yet
ready to require this IG. We are thus prioritizing the data that are
most important and useful at this time for clinical decision-making in
proximity to a patient visit. To use one commenter's example, requiring
payers to provide contact information for the entity responsible for
managing the payer's prior authorization program would be duplicative,
as providers who have a contractual relationship with the payer should
already be aware of whom to contact regarding their prior authorization
submissions. Providers can also use the Prior Authorization API to
obtain this information. We remind impacted payers, however, that they
may choose to include additional information if they believe it adds
value to patients, providers, or themselves and their own processes.
FHIR inherently provides flexibility to include additional information
without reducing interoperability and the associated IGs are designed
to both require and constrain specific elements identified as core to
the IG's use case. We encourage the public to engage in the HL7
balloting process \44\ to provide feedback on data elements they
believe would be most widely useful and applicable.
---------------------------------------------------------------------------

\43\ Health Level Seven International (2020). Da Vinci payer
data exchange STU 2.0.0. Retrieved from https://build.fhir.org/ig/HL7/davinci-epdx/.
\44\ Health Level Seven International. HL7 Balloting (n.d.).
Retrieved from https://confluence.hl7.org/display/HL7/HL7+Balloting.
---------------------------------------------------------------------------

Comment: A commenter recommended that sharing prior authorization
information through the Provider Access API be required, even if the
patient opts out.
Response: We certainly agree with the benefits of providers having
access to prior authorization information via an API and note that
providers will have access to the Prior Authorization API. Providers
will thus have access to these data for prior authorization requests
that they make, regardless of whether the patient has opted out of the
Provider Access API. We refer readers to section II.D.2.c. of this
final rule for our discussion on patient opt out and the Prior
Authorization API.
Comment: A commenter urged CMS to require impacted payers to
provide a statement through the Provider Access API when they are not
requiring a prior authorization for an item or service. The commenter
stated that this will ensure a level of transparency and paper trail
between payer and provider.
Response: This information will be available through the Prior
Authorization API, so does not need to be included in the Provider
Access API. We refer readers to section II.D. of this final rule for
our full discussion of the Prior Authorization API requirements and
section II.A.2.a.ii. for that of prior authorization statuses.
Comment: A commenter encouraged CMS to work with impacted payers to
ensure the supporting data fields of laboratory test results, clinical
data, and a specific reason for a denial are standardized to ensure
information is consistent across sources. They urged CMS to work with
payers, providers, and patients to determine the balance of data
included in the requirements and provide the needed clarification and
guidance to all parties.
Response: As explained in section II.B.2.e. of this final rule and
in more detail in section II.A.2.a.ii. of this final rule, we are
finalizing a requirement for payers to share only data that are already
structured, which include laboratory test results, clinical data, and a
specific reason for a prior authorization denial. We also remind
readers that payers are not obligated under this rule to parse or
convert documentation received in an unstructured format for the
purposes of inclusion in the Provider Access API. However, they may
choose to do so. We will continue to work with interested parties to
ensure that all parties benefit from the data sharing requirements we
are finalizing and explore possible enhancements to our policies that
require API development or enhancement in future rulemaking.
h. Data Availability
Comment: A commenter stated that prior authorization information
should be available from the entire duration of the patient's history
and not just for 1 year after the last status change because it would
improve transparency in decision-making for providers.
Response: Like with the Patient Access API, we believe that 1 year
after the last status change is the appropriate amount of time to
require payers to make historical prior authorization information
available to providers. While historical information can certainly
affect and be useful in improving patient care, we believe that
historical claims and clinical data are more important to providers
than information about prior authorizations that have expired or been
denied more than a year in the past. Furthermore, our policy allows
payers to make these prior authorization data available for longer than
1 year, if they believe it adds value to patients, providers, or
themselves and their own processes. To inform ongoing long-term care,
any active prior authorizations must be included, even if they have
been in that status for more than a year.
Comment: A commenter supported the payer maintaining patient health
data and making available any data to the provider with a date of
service on or after January 1, 2016. A commenter recommended that CMS
explain whether all data included in this rule will be subject first to
corporate data retention standards, then retained from January 1, 2016,
to present. Another

[[Page 8799]]

commenter sought clarification as to whether CMS's intention is to
include all data since 2016 and not only the last 5 years.
Response: We remind impacted payers that the policy we are
finalizing aligns with the similar one finalized in the CMS
Interoperability and Patient Access final rule: \45\ the data available
through the Provider Access API are data with a date of service on or
after January 1, 2016 maintained by the payer. By ``maintained,'' we
mean data that are maintained as part of normal operations, as is
currently the policy for the Patient Access API under the CMS
Interoperability and Patient Access final rule.
---------------------------------------------------------------------------

\45\ See 42 CFR 422.119(h)(1)(i) for MA organizations,
431.60(g)(1)(i) for Medicaid FFS, and 457.730(g)(1)(i) for CHIP FFS,
cross reference to 42 CFR 431.60 at 42 CFR 438.242(b)(5) for
Medicaid Managed Care, cross reference to 42 CFR 438.242 at 42 CFR
457.1233(d) for CHIP Managed Care, and 45 CFR 156.221(i)(1) for QHP
issuers on the FFEs.
---------------------------------------------------------------------------

We did not propose a policy for impacted payers to make data
available only from the previous 5 years in either the proposed rule or
the CMS Interoperability and Patient Access final rule, nor did we
receive comments specifically in favor of shortening the timeframe to 5
years. However, we also recognize that the data a payer maintains
dating back to January 1, 2016, could be a substantial amount and,
depending on the capabilities of the provider's EHR or practice
management system, potentially more than some providers will need. We
remind providers that this final rule does not obligate them to
incorporate data they access via the Provider Access API into their
patient's record. While we are finalizing our proposal to require
impacted payers to make available via Provider Access API any of the
applicable patient data with a date of service on or after January 1,
2016, that the payer maintains, we will closely monitor whether this
timeframe is appropriate, to inform possible future rulemaking.
i. Response Timeframe for Requested Data
Comment: Multiple commenters expressed their support for the
proposal to require payers to share the requested patient data no later
than 1 business day after the payer receives the request. A commenter
stated this will enable the provision of historical health care data
and may affect current care recommendations. Multiple other commenters
sought clarification on whether the proposed 1 business day turnaround
time for a payer to respond to a provider's request for patient data
included time for payers to complete an authentication of the
provider's identity and the provider-patient treatment relationship.
Multiple commenters recommended that CMS increase the amount of
time payers have to respond to providers' data requests.
Recommendations included suggestions to establish a two-day response
time to balance timely access to information and reduce the operational
burden and cost of the requirement. Commenters also noted that not all
provider systems are FHIR-enabled and that could lead to longer data
exchange times. A commenter stated that because of CMS's technical
standards, specifications, and IG requirements, payers will likely need
more time than one day to comply with CMS's proposed requirements. They
believe that payers may need additional time to establish technical
connections and contractual terms for a first-time request from a
provider.
However, other commenters believed the time for payers to respond
to the data request should be decreased from 1 day and that the
response should come as soon as possible, to be real-time or near real-
time. A commenter sought clarification from CMS as to why 1 business
day is allowed for the payer to respond to a request, particularly if
the initial request is being transmitted during a patient visit. The
commenter continued that real-time responses should be expected from
new technology. Another commenter stated having real-time data would
help providers see a more complete view of a patient's complete care
history. A commenter warned that, often, providers and patients review
data during a visit and that delayed access to the data could undermine
efforts to promote care coordination and provider-patient engagement. A
commenter also recommended that CMS consider requiring that the
requested data be provided within 1 calendar day to accommodate
facilities that have 24/7 operations, like SNFs.
Response: We foresee providers needing access to the specified data
in order to review them in proximity to a patient visit. Thus, we do
not believe that the turnaround time should be greater than 1 business
day. We specify in the regulation that a payer must make the data
available through the Provider Access API no later than 1 business day
after receiving a request from the provider, if all the following
conditions are met:
The payer authenticates the identity of the provider that
requests access and attributes the patient to the provider under the
required attribution process;
The patient does not opt out of the Provider Access API;
and
Disclosure of the data is not prohibited by law.
Authenticating the identity of the provider will include confirming
that the requesting provider is in-network or enrolled with the payer
and the attribution process will include confirming that a verified
treatment relationship exists. The technical standards at 45 CFR
170.215 set requirements for identity proofing and authentication
processes that must be met in order for a provider's EHR or practice
management system to connect to the Provider Access API and access a
patient's data (see section II.B.2.k. for more discussion on
authorization and authentication). Those standards allow authentication
to be completed within 1 business day, if not immediately, when the
provider accesses their system via login. Impacted payers can also
verify the patient-provider treatment relationship before the provider
request. In fact, payers are permitted and highly encouraged to design
their attribution processes to verify treatment relationships
prospectively. We believe that the patient relationship can be verified
for the vast majority of providers who will be requesting data via the
Provider Access API either ahead of time or relatively quickly.
However, we recognize that this may be difficult, if not impossible,
for a new patient's first visit because there will be no claims history
between that patient and the provider. Thus, there might be instances
where the conditions previously mention may take longer to be met for
some data requests. We strongly encourage impacted payers to ensure
completion of these steps in a reasonable amount of time, so the
provider can make use of the data they are requesting.
While we appreciate the commenters who pointed out that some
providers might need the patient information as soon as possible or in
real time, we also believe that requiring that standard would cause
undue burden on impacted payers. We nonetheless encourage payers to
make data available to requesting providers as soon as they are able.
We are therefore finalizing our proposal that impacted payers
respond to a provider's request for patient data no later than 1
business day after the payer receives the request if all conditions are
met. This timeframe adequately balances a provider's need for timely
data with impacted payers' capability to make data available. Further,
as discussed in detail in section II.A.2.a.ii. of this final rule, we
are not

[[Page 8800]]

finalizing our proposal for impacted payers to share unstructured
documentation related to prior authorizations, as sharing such
documentation would currently be difficult to accomplish in 1 business
day.
Comment: A commenter stated that the required response time for the
Provider Access API could be administratively time consuming because
the process to determine whether a disclosure is permitted under
applicable law is a manual process that involves research, review, and
analysis to determine which laws are applicable to the requester of the
information, the type of data requested, and the intended recipient.
Another commenter recommended that CMS consider the extent to which
payers will be burdened by connecting and testing EHRs to facilitate
the Provider Access API implementation.
Response: We are only requiring impacted payers to share data
elements that are already structured, and are requiring certain mature
IGs and standards (see Table H3 in section II.G. of this final rule)
that will enable the Provider Access API to connect to third-party apps
and/or providers' EHRs or practice management systems. Because of this
foundation, along with the 2027 compliance dates that we are
finalizing, payers should have sufficient time to not only test their
API connections, but also to develop internal processes and train staff
to make the necessary determinations of which of the known and
structured data are permitted to be shared via the Provider Access API.
For instance, impacted payers may use this time to develop processes
that flag certain data elements--as the payer receives them--as those
that may require special permissions or are prohibited to disclose
under other law. Such processes can ease any manual review and
decision-making that might be necessary when a provider requests
patient data.
Comment: A commenter recommended that CMS make it clear that the
provider must request access to patient data and attest to their
treatment relationship with the patient at the time of connection.
Response: While payers might utilize a process for providers to
attest to a treatment relationship at the time of the data request, we
did not propose, nor are we finalizing such a requirement. This is not
the only way to attribute patients, but impacted payers are certainly
permitted to utilize a provider attestation as part of their
attribution process (discussed in section II.B.3.a. of this final
rule). Our regulations do not prohibit using an attestation where
another law that permits disclosure requires an attestation.
Comment: Multiple commenters sought clarification on whether CMS's
1 business day proposed requirement complies with the 21st Century
Cures Act (Pub. L. 114-255, Dec. 13, 2016) (Cures Act) around
information sharing ``without delay.''
Response: We refer readers to section II.A.2.a.iii. of this final
rule for a discussion of how our timeline requirements relate to ONC
information blocking regulations.
Comment: A commenter recommended that CMS require payers to notify
providers once they have received a request and the specific date a
provider should expect to receive information in response.
Response: While we did not propose such a requirement, it would be
good practice for the payer to verify that they have received the
request for patient data from the provider. We expect payers to have a
process for providers to track their requests. Additionally, it would
benefit providers for them to receive a notification if the patient
cannot be attributed to them. In the DPC pilot, participating providers
have the ability to request data for a patient with whom they have no
prior treatment relationship, however they will receive a response with
no data if they do so.
j. Interaction With HIPAA Privacy, Security, and Administrative
Transaction Rules
Under our policies, all data shared and received via the Provider
Access API must be handled in a way that is consistent with all
applicable laws and regulations. Payers and health care providers that
are covered entities under the HIPAA Rules \46\ are subject to the
HIPAA Privacy and Security Rules.\47\ Adherence to both the HIPAA
Privacy and Security Rules helps to ensure that the covered entity
disclosing patient data through the Provider Access API has appropriate
security protocols in place. These include, but are not limited to,
administrative and technical safeguards, such as security management
processes; \48\ access controls; \49\ and audit controls.\50\
Regardless of whether a provider meets the definition of a covered
entity under the HIPAA Rules at 45 CFR 160.103, there may be state laws
that require certain privacy and security protections for an HIE.
Additionally, other laws, such as the regulations that focus on
confidentiality of substance use disorder patient records at 42 CFR
part 2 or state privacy laws, may require the payer to obtain the
enrolled individual's permission to disclose certain health
information. We requested comment on any other considerations regarding
state privacy or other laws that may be implicated by our proposals.
---------------------------------------------------------------------------

\46\ Under the HIPAA Rules at 45 CFR 160.103, a ``covered
entity'' includes a health care provider who transmits any health
information in electronic form in connection with a transaction
covered by the subchapter. See also definitions of health care
provider and transaction at https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-160/subpart-A/section-160.103.
\47\ 45 CFR parts 160 and 164, subparts A, C, and E. Department
of Health and Human Services (2022). Security Rule Guidance
Material. Retrieved from https://www.hhs.gov/hipaa/for-professionals/security/guidance/?language=es.
\48\ See 45 CFR 164.308(a)(1).
\49\ See 45 CFR 164.312(a).
\50\ Under the HIPAA Rules at 45 CFR 160.103, a ``covered
entity'' includes a health care provider who transmits any health
information in electronic form in connection with a transaction
covered by the subchapter. See also definitions of health care
provider and transaction at https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-160/subpart-A/section-160.103.
---------------------------------------------------------------------------

Commenters provided many thoughts and recommendations related to
the Provider Access API's intersection with existing privacy laws,
including the HIPAA Privacy Rule. We thank the commenters for their
perspectives and will use the feedback to inform future guidance,
educational resources, and/or rulemaking. We remain committed to
safeguarding patient information across the health care industry. Our
policies provide an opportunity to engage patients in their data
sharing and privacy rights while offering them the opportunity to more
meaningfully engage with their care.
Our policies will not alter any obligation for providers or payers
to comply with applicable law, including obligations for HIPAA covered
entities to follow the HIPAA Rules. Such other applicable law includes,
but is not limited to, standards regarding the use and disclosure of
PHI, administrative, physical, and technical safeguards and other
security provisions, and breach notification. The minimum required
security framework of the Provider Access API is specified in the
technical standards at 45 CFR 170.215 and will allow payers to verify
the requesting provider's identity by using the required authorization
and authentication protocols. Authorization refers to the process by
which the payer gives the provider permission to access data. The
authentication protocols are those that allow the payer to verify the
identity of the requesting provider. In addition to using these
required protocols, the payer will be required to share the specified
data only if it can also attribute the patient to the provider

[[Page 8801]]

using an attribution process, as discussed in section II.B.3.a. of this
final rule. While FHIR itself does not define security-related
functions, used in combination with appropriate security controls (such
as authentication and access control), a FHIR API can and should be
implemented in compliance with the HIPAA Security Rule for secure data
exchange.\51\
---------------------------------------------------------------------------

\51\ Health Level Seven International (2022). FHIR Security.
Retrieved from https://www.hl7.org/Fhir/security.html.
---------------------------------------------------------------------------

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

\52\ See 45 CFR 162.1101(a).
\53\ See 45 CFR 162.1101(b).
\54\ See 45 CFR 162.923(a).
---------------------------------------------------------------------------

k. Technical and Standards Considerations
Comment: Multiple commenters recommended that CMS detail the
requirements for the Provider Access API, with many offering that the
rule should describe the workflow, authorization, provider
authentication, and attribution processes in more detail. They
cautioned that without a standardized governance framework and legal
terms, it will be unreasonable to expect payers and providers to
establish connections and respond to requests within a set timeframe
since they will need to negotiate bespoke agreements.
Multiple commenters stated that CMS's proposed standards and
recommended IGs are insufficient for the Provider Access API. One payer
cautioned that this would result in payers struggling to comply with
the requirements and limited improvements to information exchange.
Another commenter warned that the lack of endpoint standardization
between payer and provider systems will likely create technical
difficulties. A commenter stated that without requiring an IG for the
Provider Access API, the data will not be standardized and might not be
able to be directly incorporated into a provider's EHR or practice
management system. A commenter also noted that the IGs that CMS
recommends do not include direction for how sensitive data such as
behavioral health data will be shared and with what privacy guidelines.
A commenter was additionally concerned that the recommended IGs are not
enough to support the attribution process.
Response: We refer readers to section II.G. of this final rule for
further discussion regarding the required technical standards for the
Provider Access API and IG maturity. Further, the IGs we are
recommending, listed in Table H3, are primarily meant to help implement
the APIs themselves, not to facilitate related payer processes, like
segmenting sensitive data or the attribution process. We recommend that
industry look to existing trust community agreements for guidance on a
standardized governance framework and legal terms. These agreements
include, but are not limited to TEFCA or others used by state and
regional HIEs.\55\ We anticipate that affected entities will need to
adopt new practices and methods to enable data sharing with new trading
partners, including payers supporting new types of interoperability
with providers. This final rule affords flexibility to define those
approaches. We will continue to evaluate and consider specifications
that are well-adapted to meet the legal and regulatory needs for
possible future guidance or rulemaking.
---------------------------------------------------------------------------

\55\ Office of the National Coordinator for Health Information
Technology (2023). Common Agreement for Nationwide Health
Information Interoperability. Retrieved from https://www.healthit.gov/sites/default/files/page/2023-11/Common_Agreement_v1.1_FINAL_508_1.pdf.
---------------------------------------------------------------------------

Comment: A commenter recommended that CMS exercise caution when
selecting authentication mechanism requirements for the Provider Access
API and stated that allowing simpler authentication mechanisms may make
it easier to incorporate into workflows. Another commenter stated that
it is unclear the extent to which payers would be expected to support
trust and authentication processes for individual clinicians via the
OpenID Connect Core standard, versus SMART integration that could rely
on organization-level authentication. They noted that without
specificity on workflows for exchange and authentication,
authorization, and consent processes, payers and developers will need
to support the numerous permutations that could be adopted by providers
to address those needs, increasing complexity and burden. The commenter
acknowledged the specifications developed by the HL7[supreg] Da Vinci
Project and others have begun to address technical aspects of those
needs, however, they are not yet mature and, because they are technical
standards, do not address needed governance agreements.
Another commenter stated that while the FHIR resources in the
current Patient Access APIs are mostly reusable, the mechanism for
providers to access information is entirely different. The commenter
discussed system authentication and access protocols (OAuth and OpenID
Connect Core) that are used to enable members to use portal credentials
to pull data into a third-party app. The commenter mentions that while
OAuth can and should be used for server-to-server connections to enable
access to a wider set of data while maintaining security practices,
current APIs do not have this capability. Therefore, they believe that
this modification to enable a health care provider to access data on
multiple patients is a significant change and will require rebuilding
the FHIR APIs available for provider access.
Response: Impacted payers are required to use authorization and
authentication protocols to verify the requesting provider's identity.
However, there is no single security protocol approach that will
address all use cases. Additionally, within a single API, implementers
may need to utilize more than one protocol to address specific
population and trading partner needs. We are finalizing a modification
to our proposal to not require the OpenID Connect Core for the Provider
Access API. However, we are requiring impacted payers to use the SMART
App Launch IG, which includes the capability to perform authentication
via OAuth. However, we recognize that other methods such as Backend
Services Authorization (which is included in both the SMART App Launch
IG Release 2.0.0 and the Bulk Data Access IG v1.0.0), Mutual Transport
Layer Security (mTLS), Unified Data Access Profiles (UDAP), or other
trust community specified means may be appropriate depending on the
needs.

[[Page 8802]]

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

\56\ Health Level Seven International (2020). Da Vinci Payer
Data Exchange. Retrieved from https://hl7.org/fhir/us/davinci-pdex/STU1/.
---------------------------------------------------------------------------

Comment: Multiple commenters supported CMS's proposed requirement
to leverage the Bulk Data Access IG for the Provider Access API, so
that if a provider has a panel of patients associated with a single
payer, the payer can share those data asynchronously in one
transaction.
Response: We thank commenters for their support of our policies. As
discussed in section II.G. of this final rule, we are finalizing our
proposal for impacted payers to use the Bulk Data Access IG at 45 CFR
170.215(d)(1) to support implementation of the Provider Access API.
Comment: Multiple commenters recommended that CMS limit the API to
only individual data requests and that CMS not require the FHIR Bulk
Data Access specification at this time, but instead consider it at a
later date after it has been more thoroughly tested by HL7. Multiple
commenters also stated that more work is needed on the Bulk Data Access
IG before it is mandated, as it has not been adequately implemented;
this makes it difficult to assess if it will be able to meet the
proposed need and timelines.
Multiple commenters also highlighted concerns with the technical
functions of the Bulk Data Access IG and noted that large bulk
downloads could pull time away from more urgent requests. The
commenters recommended that payers be able to put reasonable limits on
bulk data requests or that CMS should remove the bulk data transfer
from the initial requirements. A commenter stated that CMS should only
require impacted payers to respond to requests for certain patient's
data quarterly. The commenter stated this would ensure that vendors do
not set a default of daily retrievals of data that risk sharing more
patient information than necessary.
Multiple commenters additionally flagged that payers, especially
smaller health plans, could struggle to respond to bulk requests within
the 1 business day response period and that they could be faced with
significant costs to implement this requirement correctly. A commenter
stated concern about bulk patient attribution and requested CMS
clarification and/or limitations on bulk data sharing requirements.
Response: Bulk data exchange can allow payers to prioritize more
urgent requests and defer bulk data requests until a later time when
sufficient system resources can be allocated to create bulk data
export. However, we remind payers that they are still required to
comply with the 1 business day timeframe discussed in section II.B.2.i.
of this final rule. We emphasize that although we are requiring
impacted payers to support FHIR Bulk Data Access at 45 CFR
170.215(d)(1) under this final rule, this requirement does not obligate
them to use it for every data exchange if it is not feasible. However,
we agree with commenters that impacted payers have leeway to place
reasonable limits on bulk data requests. At the same time, we also
believe that the benefits of access to these data outweigh any
potential concern that vendors will set daily retrievals of data. This
is because a provider would first need to request the data for
individual patients, as well as the fact that the Provider Access API
is better suited to enable discrete provider use when seeing a patient,
rather than ongoing patient monitoring.
Comment: A commenter stated that the PDex IG could support the opt
out process by adding a flag to indicate an attributed member has opted
out of provider data sharing.
Response: We appreciate the commenter's suggestion and urge
impacted payers to explore ways to leverage FHIR IGs for the other
processes that we are requiring in this rule.
l. Interaction With ONC Policies
Comment: Multiple commenters made recommendations regarding how CMS
can work with ONC. They recommended that CMS work with ONC to implement
additional requirements as part of the ONC Health IT Certification
Program for developers to implement API interfaces into CEHRT in such a
way that fits with provider workflow.
Multiple commenters also recommended that CMS partner with ONC to
create guidance regarding implementation of the Provider Access API and
the technical capabilities of payers, EHR vendors, and providers. A
commenter further suggested that CMS work with ONC to ensure that both
payers and CEHRT vendors are aligned in the technical capabilities to
implement Provider Access APIs in a way that does not hamper provider
workflow and negate efforts to reduce prior authorization burdens.
Multiple commenters strongly encouraged CMS to work with ONC to
consider how the Provider Access API could be expanded in future
rulemaking to support bi-directional, real-time data exchange between
payers and providers to support patient care and to automate prior
authorization requests, rather than a one-way data exchange from payer
to provider. A commenter stated that including such criteria could
ensure compliance with the ONC Cures Act final rule information
blocking policies.
Response: We appreciate commenters' support for leveraging of the
ONC Health IT Certification Program to ensure APIs are implemented in a
standardized fashion. We will continue to work with ONC to explore the
adoption of standards and health IT certification criteria where
appropriate to streamline data exchange, support interoperability, and
increase efficiencies associated with the policies in this final rule,
as well as to align and mutually reinforce all of our respective
policies.
m. Interaction With Trusted Exchange Framework and Common Agreement
Comment: Multiple commenters suggested that promoting payer to
provider information exchange through the TEFCA may be a better path to
achieve improved data exchange, including that of large-scale data
sets, between payers and providers, rather than a requirement to
implement FHIR APIs. A commenter recommended that CMS should
collaborate with ONC and the Recognized Coordinating Entity (RCE) \57\
to determine an approach for payers to fulfill the payer to provider
exchange requirement by joining the TEFCA network once responses are
required for requests made as payment and operations exchange purposes,
as described in the Qualified Health Information Network (QHIN))
Technical Framework (QTF).\58\
---------------------------------------------------------------------------

\57\ The Sequoia Project (2023). What is the RCE? Retrieved from
https://rce.sequoiaproject.org/rce/.
\58\ The Sequoia Project (2022). Trusted Exchange Framework and
Common Agreement QHIN Technical Framework (QTF). Retrieved from
https://rce.sequoiaproject.org/wp-content/uploads/2022/01/QTF_0122.pdf.

---------------------------------------------------------------------------

[[Page 8803]]

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

\59\ The Sequoia Project (2023). FHIR Roadmap for TEFCA Exchange
Version 2.0. Retrieved from https://rce.sequoiaproject.org/wp-content/uploads/2023/12/FHIR-Roadmap-for-TEFCA-Exchange.pdf.
\60\ The Sequoia Project (2023). How Can I Participate in TEFCA?
Retrieved from https://rce.sequoiaproject.org/participate/.
---------------------------------------------------------------------------

We remind commenters that though we are finalizing our proposals
for APIs to use and comply with certain standards and technical
specifications, this would not preclude payers from also leveraging
QHIN-to-QHIN exchange or HIEs/HINs to exchange patient data.
Comment: A commenter recommended that CMS establish a consistent
set of technical standards between TEFCA and the proposed APIs that are
required so that the industry does not have to implement different
standards depending upon the exchange partner or mechanism for
exchange.
Response: ONC and CMS will continue to work closely together to
identify ways that TEFCA can support the payer API requirements. We
further agree that use of TEFCA could help to reduce burden associated
with implementation variation that may arise in developing direct
connections with exchange partners. ONC and the RCE are implementing
the FHIR Roadmap for TEFCA Exchange to align and accelerate adoption of
FHIR across the industry.\61\
---------------------------------------------------------------------------

\61\ The Sequoia Project (2023). FHIR Roadmap for TEFCA Exchange
Version 2.0. Retrieved from https://rce.sequoiaproject.org/wp-content/uploads/2023/12/FHIR-Roadmap-for-TEFCA-Exchange.pdf.
---------------------------------------------------------------------------

n. Federal Matching Funds for State Medicaid and CHIP FFS Expenditures
on Implementation of the Provider Access API
In section II.E. of this final rule, we discuss Federal matching
funds for certain state Medicaid and CHIP FFS programs' expenditures
related to implementation of the Provider Access API (this was also
addressed in the proposed rule at 87 FR 76264).
o. Medicaid Expansion CHIP
In section II.E. of this final rule, we discuss implementation for
states with Medicaid Expansion CHIP programs (this was also addressed
in the proposed rule at 87 FR 76264).
3. Additional Requirements for the Provider Access API
Additional requirements for the Provider Access API regarding
attribution, patient opt out process, patient resources, and provider
resources are discussed in the sections that follow.
a. Attribution
Patient attribution is a method of identifying a patient-provider
treatment relationship. Attribution is a critical component to ensure
that patient health data are shared only with appropriate providers.
For purposes of our policies, we use the term ``attribution'' as
shorthand for the determination that a treatment relationship exists
between the patient and provider. For the Provider Access API, we
proposed to require impacted payers to maintain an attribution process
to associate patients with their in-network or enrolled (as applicable)
providers to ensure that a payer only sends a patient's data to
providers who have a treatment relationship with that patient.
We are aware that the process of attribution can relate to many
payer functions, including managing contracts, payments, financial
reconciliation, reporting, and continuity of care. We thus encourage
payers to use processes that they already have in place to attribute
patients to their providers for these other purposes.
We expect that many payers will rely primarily on claims data to
establish a treatment relationship between a patient and a provider.
Other payers might use existing patient rosters for individual
providers or organizations, such as ACOs. For new patients, we
explained that payers could accept proof of an upcoming appointment to
verify the provider-patient treatment relationship. We know that many
providers already verify coverage with a payer before a new patient's
first appointment. A payer could establish a process that aligns with
that query, using some evidence of a scheduled appointment. Once
confirmed, the provider would be able to request the patient's data in
preparation for the visit. Payers may have other existing processes
that they prefer to use. We did not propose a prescriptive attribution
process in order to provide payers the flexibility to use systems and
processes they already have in place, where appropriate, or to develop
new policies and procedures to ensure that access to a patient's data
through the Provider Access API is limited to providers who have a
treatment relationship with the patient.
CMS has implemented an attribution process in the DPC pilot for
Medicare beneficiaries (the Medicare FFS version of the Provider Access
API), which can serve as an example for impacted payers. The pilot
requires HIPAA covered entities or their business associates to agree
to certain terms of service before data can be sent to them.\62\ The
current Medicare FFS terms of service require each organization to
maintain a list of patients that represents the patient population
currently being treated at their facilities.\63\ CMS requires providers
to attest that they have a treatment-related purpose to add a patient
to their group. This is accomplished by submitting an attestation with
every request to add a patient to their roster. This pilot will
continue to test methods to accurately attribute patients to their
providers. The information gained from this pilot may assist the
industry to develop procedures to identify providers under this
requirement.
---------------------------------------------------------------------------

\62\ Centers for Medicare and Medicaid Services (n.d.). Terms of
Service. Data at the Point of Care. Retrieved from https://dpc.cms.gov/terms-of-service.html.
\63\ Centers for Medicare and Medicaid Services (n.d.).
Attestation & Attribution. Data at the Point of Care. Retrieved from
https://dpc.cms.gov/docsV1.html#attestation--attribution.
---------------------------------------------------------------------------

In addition, HL7 has developed a HL7 Da Vinci Risk-Based Contracts
Member Attribution (ATR) List IG. The ATR List IG does not specify how
the payer and provider identify these patients, but defines the
protocols, data structure, and value sets to be used for exchanging a
Member Attribution List. The Member Attribution List typically
contains: (1) plan/contract information which is the basis for the
Member Attribution List, (2) patient information, (3) attributed
individual provider information, (4) attributed organization
information, and (5) member and subscriber coverage

[[Page 8804]]

information. The DPC pilot program has been working with the Da Vinci
Member Attribution List workgroup towards compatibility with that
IG.\64\ The ATR List IG is also informing updates to the PDex IG. We
encourage payers to review the information from the workgroup. We
further note that the HL7 Argonaut Project, a private sector initiative
that advances using FHIR, has developed an IG specifying how to use the
Scheduling and Appointment FHIR Resources to communicate this
information.\65\
---------------------------------------------------------------------------

\64\ Centers for Medicare and Medicaid Services (n.d.). Groups.
Data at the Point of Care. Retrieved from https://dpc.cms.gov/docsV2.html#groups.
\65\ Health Level Seven International (2022). Argonaut
Scheduling IG (Release 1.0.0). Retrieved from https://fhir.org/guides/argonaut/scheduling/.
---------------------------------------------------------------------------

We solicited comments on our proposal to require payers to maintain
an attribution process to associate patients with their enrolled or in-
network (as applicable) providers to ensure that a payer only sends a
patient's data to providers who have a treatment relationship with that
patient. We requested comments on other examples of how patients can be
attributed to the enrolled or in-network providers from whom they are
receiving care, especially for a new patient-provider treatment
relationship. We also requested comments on whether and how payers
could attribute the patient to the provider at the time a provider
makes a request for patient data through the Patient Access API.
As discussed in more detail elsewhere, we are finalizing our
proposal without changes.
i. General Comments on Attribution
Comment: Multiple commenters expressed their support for CMS's
proposed requirement that impacted payers maintain a process to verify
a provider-patient relationship. Multiple commenters also underscored
the importance of developing a patient attribution system to ensure
those data are shared appropriately. A commenter further stated that
payers should only develop an attribution process for in-network
providers.
Response: We thank commenters for their support for this proposal.
We emphasize that the requirement we are finalizing--that impacted
payers be required to make the specified patient data available to
providers--only applies to those that are in-network or enrolled with
the payer. However, we encourage payers to consider making the Provider
Access API available to out-of-network providers. This rule requires
that impacted payers maintain an attribution process to associate
patients with their providers. Thus, if payers choose to make the API
available to out-of-network providers, they would still need to
establish an attribution process to ensure that a treatment
relationship exists before making patient data available.
Comment: A commenter recommended that CMS align patient attribution
requirements and processes across payer types and leverage the CMS
Innovation Center to identify where the process can be streamlined. A
commenter also recommended that CMS permit payers to set reasonable
requirements for providers to demonstrate that the provider is treating
an individual, which could reduce the risk of providers making
unauthorized inquiries in the system.
Response: We recognize that there are multiple ways for impacted
payers to verify a treatment relationship. Payers may already have a
process that they want to use, so requiring a different process that
deviates from an established and effective workflow may add burden. We
encourage payers to work together to establish industry-wide principles
and standards for patient attribution. As previously stated, payers are
permitted to set requirements for providers as part of their processes,
such as requiring an attestation of a treatment relationship and/or a
need for the data. We agree with the commenter that such requirements
should be reasonable and not overly burden providers.
Comment: A commenter stated that some specialties are referred
patients at a higher rate and requested that CMS take into account the
additional burdens of the attribution process for providers who may
only see a patient once. Another commenter suggested that the final
rule should ensure that any attribution process will not negatively
impact those patients who have a high number of providers. A commenter
further noted the significant technological challenges of attribution
and expressed concern that patients that most need their data to follow
them through clinicians, systems, and payers are those that are most
likely to have data discontinuity due to clinicians receiving erroneous
patient data.
Response: We emphasize that payers should consider all types of
patients and providers when designing their attribution processes to
prevent creating disparities. Making the specified data available via
API may be particularly beneficial for patients experiencing data
fragmentation. Establishing and maintaining an attribution process will
benefit patients who may see multiple providers, so that all such a
patient's providers (assuming they are in-network or enrolled) can have
access to necessary information. We remind readers that we are not
being prescriptive on when attribution needs to take place, as long as
it occurs before patient data are made available through the Provider
Access API. We encourage payers to perform the attribution prior to the
first visit and/or in a reasonable amount of time to determine whether
there are legal restrictions on the data that may be shared and so that
providers can have the opportunity to review any relevant data in
proximity to the patient encounter.
Comment: A commenter expressed concern regarding the attribution
process for Medicaid patients, noting that developing a proactive
process for providers who will see a patient would be challenging for
Medicaid agencies. Another commenter stated that there should be
special consideration for patients with mental health and substance use
disorder issues. For example, proof of upcoming appointments can be an
inadequate test of a patient-provider relationship due to high ``no-
show'' or cancellation rates. A commenter also stated that verifying a
provider-patient relationship will be difficult to accomplish in a
single business day.
Response: We understand the concerns of Medicaid agencies,
including challenges in attributing new patients, and believe that
proof of an upcoming appointment could sufficiently indicate the
patient-provider relationship. However, impacted payers have latitude
to determine when proof of an upcoming appointment can be used. For
example, payers may implement a policy where providers can only
successfully receive requested data if they have an upcoming
appointment with the given patient within a specific number of days.
Such a process can also mitigate potential ``no show'' or cancellation
situations which one commenter cited. Many providers confirm
appointments in the days prior to their appointment. A patient who
confirms their appointment in proximity to the visit is less likely to
cancel or not show. As stated previously, impacted payers must send the
requested data no later than 1 business day after the payer receives a
request and the following conditions are met: (1) the payer
authenticates the identity of the provider and attributes the patient
to that provider; (2) the patient has not opted out; and (3) disclosure
of the requested information is not prohibited by law. Nothing in the
rule requires payers to establish that these conditions are met in one
business day; rather, data must be made available

[[Page 8805]]

through the Provider Access API no later than one business day after
these conditions are met. We encourage payers to verify these
conditions are met in advance as often as possible. If this is
difficult or not possible, such as in the case of new patient visits,
we strongly encourage payers to complete the attribution process in a
reasonable amount of time with minimal involvement from the provider,
so as not to increase burden.
ii. Providers' Role in Attribution
Comment: A commenter sought clarification from CMS regarding
whether the provider or the payer must maintain records of the
attribution. They also asked how to account for ACO or value-based care
coverage models that permit patients to choose a provider. Another
commenter agreed, pointing out that most attribution processes in these
coverage models are currently geared toward identifying a singular
accountable primary care physician within value-based arrangements and
that often, a patient's identification of ``their doctor'' may not
match results generated through automated attribution approaches.
Response: This final rule imposes on impacted payers the
requirement to maintain a process to attribute a patient to in-network
or enrolled providers. Payers are responsible for maintaining
attribution records and ensuring that only in-network or enrolled
providers who have a treatment relationship with the patient (or should
they choose, out-of-network or unenrolled providers to whom the
impacted payer has attributed a patient) have access to patient data.
However, the process of attribution inherently requires provider
participation in some instances. For example, when a patient has their
first visit with a particular provider, we cannot expect the payer to
have that information without some provider input. In other instances,
payers may involve patients in their attribution processes, especially
if they wish to account for providers who might not be identified via
existing automated approaches. Should they do so, any such involvement
should not be onerous for the patient.
Comment: A commenter stated that CMS should allow payers and
providers to adopt an approach that assures payers that any provider
request for patient data meets the requirements of this rule, while
also allowing providers to delegate the ability to request information
to support staff. Another commenter sought clarification on whether
physicians and their staff would be expected to operate outside of
their normal workflows to demonstrate a care relationship with a
patient. A commenter sought clarification on whether multiple providers
could be attributed to the same patient at a time. A commenter further
sought clarification on whether the rendering provider is the provider
who has a treatment relationship with the patient, or if the billing
provider could also be attributed to the patient to request data using
the Provider Access API. A commenter stated that CMS should require
payers to make an attribution prior to the first visit.
Response: While we are not being prescriptive in how payers should
design their attribution processes; we caution that payers should not
set overly onerous criteria for providers to prove their treatment
relationship with a patient. Both patients and providers will benefit
from the provider having access to the specified information; the
attribution process should not impede this benefit. Furthermore, it is
appropriate for providers to be able to delegate administrative tasks
to their staff. Similar to other processes, such as submitting claims,
payers should set reasonable requirements that allow staff to provide
information or perform tasks on a provider's behalf.
We do not intend to overburden providers or their staff with the
attribution process. As stated, we believe that payers can attribute
most patients to providers via claims, which should not require
providers to operate significantly outside their normal workflows to
demonstrate a care relationship with a patient. Furthermore, we
acknowledge that patients can (and in many cases should) be attributed
to multiple providers who would be able to request access to the
patient's data. This may apply, for example, to a multi-provider
practice or an ACO.
Comment: Multiple commenters recommended that CMS reevaluate the
attribution process as outlined in the proposed rule. Multiple
commenters also stated that payers have significantly different
attribution processes, and this adds burden to hospitals and SNFs. A
commenter agreed that varying attribution processes across payers would
increase administrative burden for providers and clinics under the
proposed rule. A commenter recommended that CMS permit providers not
only to attribute patients through individual requests, but also to be
able to submit information in a bulk format by submitting a list of all
a payers' enrollees currently in their care. Another commenter
cautioned CMS to not adopt any standard for attribution more rigorous
than the HIPAA Privacy Rule and avoid imposing burdensome requirements.
Response: We emphasize that the requirement to implement an
attribution process applies to impacted payers, not providers. As
discussed, a payer may verify the patient treatment relationship in a
variety of ways. While verification may necessitate some action by the
providers, we strongly encourage payers to implement a process that is
least burdensome to providers as possible. When information from
providers is required, payers should allow bulk submission in order to
impose the least possible burden on providers. Finally, because we did
not propose to adopt any attribution standard or method at all, we are
not adopting one that is more rigorous than what is required under the
HIPAA Privacy Rule.
iii. Attribution Process Design and Suggestions
Comment: A commenter recommended that CMS establish minimum
attribution criteria and a uniform claims attribution process. Multiple
commenters suggested that CMS create guidance on best practices and
specific ways that payers can accurately attribute patients to specific
providers and when a payer can determine that a treatment relationship
between a patient and provider has ended to allow flexibility in the
attribution process rather. Multiple commenters also stated that payers
should be able to ``un-attribute'' a patient from a provider when a
treatment relationship is inactive to protect patient data. A commenter
stated that it is crucial for CMS to define the timeline for which the
patient attribution roster on both the payer and provider side must be
updated to ensure that it is never shorter than the 30 days mandated by
some states. A commenter also stated that the attribution process will
be difficult because it will require two separate processes, one for
new and one for established patients. A commenter further stated that
payers will need to prioritize implementation of the Provider Access
API, which will make developing an attribution process difficult.
Response: In order to permit impacted payers the flexibility to
leverage their existing processes or utilize another method that may be
the least burdensome for them, we did not propose, and are not
finalizing, a standardized attribution method. In the DPC pilot, for a
provider to establish a treatment-related purpose for viewing patient
data, they must have an existing ``treatment relationship,'' defined as
a

[[Page 8806]]

processed claim with the provider's NPI number for that patient within
the past 18 months. The DPC pilot currently does not have the ability
for providers to access data for patients before their first claim. As
noted in the proposed rule and previously mentioned, with each roster
addition or renewal, a provider must also attest that there is an
active treatment relationship. We have had significant interest in our
DPC pilot from providers and provider organizations that participate in
the Medicare program and continue to gather information from interested
parties. However, we do not have information beyond what is currently
publicly available to share at this time.
This DPC process is just one attribution method and we encourage
payers to leverage their existing processes and develop methods that
work best for them and that place the least amount of burden on
providers. Nothing in this final rule would require a specific
timeframe after which a treatment relationship expires. Payers are
permitted to establish a period after which the treatment relationship
is considered inactive and a patient could be un-attributed from a
provider. However, many patients may only see a particular provider
annually, which would clearly signify a continuing treatment
relationship. We did not propose a requirement for providers to
maintain a patient roster, though it may be required under other
Federal or state regulations or under the provider's contract with the
payer.
Finally, we understand that some payers may have challenges
implementing an attribution process. One of the reasons we are
finalizing a 2027 compliance dates rather than the proposed 2026 dates
(see section I.D. of this final rule) is to give impacted payers
additional time to prepare and test any new or modified process. We
intend to provide more information and education on potential
authentication processes prior to the compliance dates.
Comment: Multiple commenters expressed concern with how difficult
it is to verify the patient-provider relationship. A commenter sought
clarification on the intended level of attribution for access to a
member's data. Another commenter stated their belief that the proposed
attribution requirement, specifically how a ``treatment relationship''
is defined, requires further development and feedback from consumers
before implementation so that they can feel in control of their data.
They noted that it is not uncommon to have dozens of providers involved
in a single patient's care, nor is it uncommon to have a single
interaction with a specialty provider, or to have a provider consult
another provider on a course of care without the patient's knowledge.
Response: Payers should be able to meet the requirement to have an
attribution process by verifying the patient-provider treatment
relationship in a variety of ways, as discussed in this section. Payers
should consider Federal and state law, internal risk policies, and
their own processes to determine what level of assurance they require
to attribute a patient to a provider for the Provider Access API.
Establishing specific requirements or procedures would add burden to
payers who may establish different, but equally acceptable and
effective, processes.
We do not believe it is necessary to define a ``treatment
relationship'' only for the purposes of this rule. Payers may have
different definitions that may be based on Federal or state law,
internal policies, or provider contracts. Therefore, an additional
definition would be unnecessary, duplicative, and possibly confusing.
We do note that if there is doubt about whether a patient and provider
are in a treatment relationship, information from the patient could be
one method of making that determination. However, we emphasize that
placing burden on a patient should only be used a last resort, and only
if the benefits of making data available outweigh that burden.
In some cases, verifying a treatment relationship could result in
providers having access to data about patients they have treated only
once and whom they may not treat again. However, we believe that these
providers would have little reason to request this information because
they would be creating unnecessary work for themselves without
benefitting patient care. Further, data from the Provider Access API is
only required to be made available to in-network or enrolled providers.
Such providers have already been vetted to participate in the impacted
payer's network, so it is unlikely these participating providers would
seek out patient data they do not need for patient care. Finally, some
impacted payers might utilize an attestation process, as suggested by
some commenters, where providers must attest that they have a clinical
need for any data they request. A provider requesting data that they do
not need could endanger their payer network or contract status if they
fraudulently attest that they are only requesting data for patient
care, should the impacted payer implement such a policy. We thus
believe that the benefits of the Provider Access API outweigh concerns
that already-attributed providers will inappropriately request patient
data. We look forward to working with interested parties to develop
best practices for attribution processes.
Comment: A commenter stated that a claims-based approach to
verifying a treatment relationship is the most reliable. Conversely,
another commenter stated that it was not necessary to verify a
treatment relationship through claims data. They recommended using
processes that show the onset or evidence of treatment like Admission,
Discharge, Transfer (ADT) or Scheduling Information Unsolicited (SIU)
transaction. Another commenter stated that a hospital admission letter
should be enough for payers to grant the provider access to the
Provider Access API for the specified patient. A commenter also
encouraged payers to consider whether a provider's signed order for
treatment (on behalf of a patient) is enough to establish this
relationship. A commenter highlighted that the CMS companion guide on
the HIPAA-mandated eligibility transaction supporting Medicare
Beneficiary Matching could serve as a model for data elements that
could facilitate attribution.\66\ These data and the associated
eligibility and benefit request essentially serve as proof of a
scheduled appointment. A commenter also recommended leveraging TEFCA
for the attribution process.
---------------------------------------------------------------------------

\66\ Centers for Medicare and Medicaid Services (n.d.). HIPAA
Eligibility Transaction System (HETS). Retrieved from https://www.cms.gov/research-statistics-data-and-systems/cms-information-technology/hetshelp.
---------------------------------------------------------------------------

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

[[Page 8807]]

use the existing processes to verify treatment relationships, including
the ATR List IG. Multiple commenters also stated that this IG could be
updated to provide the necessary tools to support implementation of the
attribution process and some recommended that CMS adopt that standard
when it is mature enough for large scale implementation.
Multiple commenters expressed support for HIEs and HINs as unique
entities that have the capability to create and manage patient-provider
attribution for the Provider Access API. The commenters provided an
example from the Active Care Relationship Service (ACRS), which enables
organizations to send data files that record the relationships between
their providers and patients. Another commenter stated that CMS should
work with HIEs to expand capabilities and create IGs and processes for
patient matching, attribution, and opt out to support the Provider
Access API.
Response: We thank readers for their comments and will consider
them for future guidance or rulemaking. As we did not propose a
specific attribution method, we encourage impacted payers to consider
these existing resources and models. As members of the HL7[supreg] Da
Vinci Project, we will continue to monitor development of the ATR List
IG.
Impacted payers may already have multiple arrangements in place
with providers to support data exchange, and may even participate in
community, local, state, or private HIEs. These HIEs may already have a
process to attribute patients to providers. To the extent it would
benefit payers, we encourage them to work with HIEs and HINs to
facilitate the Provider Access API. Nothing in our policies prohibits a
payer from using an intermediary to aid with patient matching, data
exchange, or data hygiene. Once again, our goal is to allow payers to
develop the least burdensome approach to attribution, and we encourage
collaboration on potential solutions.
Comment: Multiple commenters requested that CMS consider
implementing a national, digital patient identification standard. A
commenter recommended that CMS implement a standardized patient
identification framework to ensure that patient data are not
inadvertently co-mingled and does not pose a threat to patient privacy
and safety within the Provider Access API. Another commenter stated
that an electronic standard should be developed to verify a patient
relationship and appointment status.
Multiple commenters stated the importance of making sure the CEHRT
programs require that record requests can only be made when a treatment
relationship is present. A commenter recommended that CMS and ONC work
together to establish standards for ONC's Health IT Certification
Program.
Response: A standard unique health identifier for each individual,
which is in accord with numerous commenters' recommendations, would be
associated with a HIPAA standard arising at section 1173(b)(1) of the
Act. We will continue to work with our Federal partners as we consider
future guidance or additional rulemaking within the ambit of our
authority.
Comment: A commenter recommended that CMS establish a workgroup or
advisory committee to establish an appropriate attribution process.
Another commenter recommended that CMS monitor the state of evolving
technology and maintain flexibility in its requirements as technology
continues to develop.
A commenter recommended CMS utilize public feedback to establish
minimum criteria as proof of an authentic patient-provider
relationship, because a lack of clear guidance in this area may cause
disputes between payers and providers regarding the appropriate
criteria for establishing proof of a relationship.
Response: We intend to continue our work with industry as they
develop attribution processes that do not overly burden payers,
providers, or patients. Additionally, based on feedback from the
public, we believe that the public would benefit from further
educational resources, and we will explore avenues by which we may
offer those in the future.
Comment: A commenter asked whether payers can integrate an
attestation of a treatment relationship with a FHIR transaction.
Response: While we are not prohibiting use of a FHIR transaction as
part of the attribution process, the IGs we are recommending are
primarily meant to help implement the APIs themselves, not to
facilitate related payer processes, like the attribution process.
b. Opt Out
We proposed that all impacted payers would be required to establish
and maintain a process to allow patients or their personal
representatives to opt out of (or if they have already opted out, to
opt back in to) having the patients' data available for providers via
the Provider Access API. We noted that this differed from our Payer-to-
Payer API, which was structured as an opt in process. Similar to the
attribution process, as previously discussed, we did not intend to be
prescriptive regarding how this opt out process should be implemented,
but payers would be required to give all patients or their personal
representatives the opportunity to opt out, including those currently
enrolled on the compliance dates, before making patient information
available via the Provider Access API, and at any time while the
patient is enrolled with the payer.
We did not propose to require specific methods for patients to opt
out, but anticipated that payers would make that process available by
mobile app or on their website. We also anticipated that mail, fax, or
telephonic methods may be necessary alternatives for some patients,
which payers would have to accommodate. We invited comments on whether
we should establish more explicit requirements regarding the patient
opt out processes.
Our proposal would require impacted payers to allow patients to opt
out of the Provider Access API data exchange for all providers in that
payer's network. However, we also encouraged payers to implement
processes that allow more granular controls over the opt out process,
so patients can opt out of making data available to individual
providers or groups of providers. We did not propose to require those
more granular controls, as we were concerned about the potential
administrative and technical burden this would place on some payers.
However, we requested comments about the technical feasibility of
implementing an opt out process that would allow patients to make
provider-specific opt out decisions, and whether we should consider
proposing such a requirement in future rulemaking.
We appreciate commenters' feedback to our requests, and understand
concerns about the potential for administrative burden associated with
providing patients with more granular controls over data sharing, as
well as which specific providers can receive their data. We used the
term ``granular'' broadly because we wanted to know which data elements
commenters thought were most important to be able to segment out. We
are committed to minimizing the burden on patients and providers as
much as possible and continue to weigh the benefits of providing
patients with more control over their data against the potential
administrative burden on impacted payers. We appreciate the suggestions
we received for how to implement a more granular opt out approach and
will

[[Page 8808]]

consider these suggestions for future rulemaking.
We proposed an opt out approach because, as we discussed in the
proposed rule, opt in models of data sharing have been shown to inhibit
the utilization and usefulness of data sharing efforts between patients
and health care providers. We acknowledged that there are positives and
negatives to both opt in and opt out policies, and that some patients
may prefer to control or direct their health information via an opt in
process, which requires affirmative permission from a patient before
their data can be shared. However, patients who are less
technologically savvy or have lower health literacy may be less likely
to use the Patient Access API, so having an opt out policy for the
Provider Access API would facilitate sharing data directly with the
provider, without requiring action by the patient. We stated our belief
that opt out would promote the positive impacts of data sharing between
and among payers, providers, and patients to support care coordination
and improved health outcomes, which could lead to greater health
equity. In formulating our proposal, we carefully weighed the issues
related to both opt in and opt out policies, especially as they relate
to making data available to providers. We wrote that a policy
defaulting to sharing data with providers, unless a patient opts out,
appropriately balances the benefits of data sharing with the right of
patients to control their health information. As we also detailed in
the proposed rule, payers would be responsible for providing patient
resources to ensure that patients understand the implications of opting
out. We noted that, should patients not opt out of data sharing, then
the data that would be made available via the Provider Access API would
be available to in-network providers whose identity has been
authenticated and to whom the patients have been attributed, meaning
that the payer has verified a treatment relationship between the
provider and the patient. However, we stated that our proposals, taken
together, gave patients ample opportunities to change their data
sharing permission as they see fit.
As we explained in detail in our proposed rule (87 FR 76260), opt
in models can create greater administrative burden for smaller health
care organizations, depending on where the responsibility for obtaining
and updating the patient's data sharing permission is held. We also
pointed to the fact that a larger health care organization that
employed an opt in model, the Veterans Health Administration within the
VA, saw the vast majority of provider requests for patient information
rejected for lack of patient permission.
We additionally stated our belief that an opt out model could
address equity issues by ensuring that patients from lower
socioeconomic and minority groups, who are more likely to have limited
health literacy, can benefit from the improved care that the Provider
Access API can facilitate. We believe that data sharing as the default
option for all patients enhances both personal and organizational
health literacy, as these terms are defined by the Healthy People 2030
report,\67\ while protecting patients' choice to limit data sharing.
---------------------------------------------------------------------------

\67\ Health Literacy in Healthy People 2030 (2020). History of
Health Literacy Definitions. Retrieved from https://health.gov/healthypeople/priority-areas/health-literacy-healthy-people-2030/history-health-literacy-definitions.
---------------------------------------------------------------------------

The ability for patients to opt out was specific to the data we
proposed requiring payers to share via the Provider Access API. As
discussed previously, nothing in the proposed rule would alter any
other requirements under applicable privacy and security laws and
regulations. If there is other authority to share patient information
with respect to which a patient may not opt out, such as disclosures
required by law, nothing in this proposal would change the payer's
obligation to disclose that information. However, we encouraged payers
and providers to use the proposed Provider Access API as a technical
solution to transmit data between payers and providers beyond the scope
of these policies, provided such disclosure is consistent with all
other applicable requirements, such as the requirements set out in the
HIPAA Privacy Rule and the HIPAA Security Rule.
We value the importance of safeguarding the quality and integrity
of patient health information. We acknowledged that there may be
potential program integrity risks associated with sharing patient data
under both an opt in and opt out models. We expect that if payers
identify any vulnerabilities, they will work to make changes to their
operations to address risks that could lead to potential fraud and to
limit the impact on patient information.
We requested comments on our proposal for a patient opt out
framework for the Provider Access API. As discussed in more detail
elsewhere, we are finalizing this proposal without changes.
i. General Comments on Opt Out
Comment: Multiple commenters expressed support for the proposed
policy to require an opt out framework for the Provider Access API.
Commenters provided various rationales for their support, including
that the opt out framework would enable patients to protect and control
their health information while still making patient data available to
providers, encourage increased data transmission, and allow patients to
terminate a provider's access to their data when the patient no longer
has a treatment relationship with the provider.
Multiple commenters specifically expressed their support for an opt
out approach instead of an opt in approach. These commenters noted that
it is less burdensome for payers and that an opt in approach would
require patients to have a higher level of education or better
technology and health literacy to utilize than an opt out process,
which may result in fewer patients having their data exchanged via the
Provider Access API under an opt in approach.
Response: We appreciate the comments we received in support of our
proposal to allow patients or their personal representatives to opt out
of the Provider Access API if they do not wish for their data to be
made available via the API requirement. We agree with the commenters
that an opt out approach will enable patients or their personal
representatives to better protect and control their health information
while still making patient data available to providers. We remind
commenters that the opt out would not necessarily allow patients or
their personal representatives to terminate a provider's access to
their data when the patient no longer has a treatment relationship with
the provider, because we did not propose to require a granular opt out
policy (though some payers might choose to implement such a policy).
However, we did note in section II.B.3.a. of this final rule that
payers have latitude to determine when a patient-provider treatment
relationship ends via their attribution process. Thus, regardless of
the opt out granularity, payers should also use their attribution
process to determine whether and when an individual provider should
have access to a patient's data via the Provider Access API.
Comment: Other commenters voiced their concerns with an opt out
approach but did not specifically recommend that CMS take a different
approach. Multiple commenters noted that offering patients an
opportunity to opt out would limit information sharing and that

[[Page 8809]]

information sharing is important to facilitate the prior authorization
process. Multiple commenters also stated their belief that an opt out
approach would reduce, or even remove patient control over their health
information. Those commenters stated that because CMS expects most
patients not to opt out, the confidentiality of this patient data will
effectively not be the default.
Response: For reasons we discussed in both the proposed rule and
previously, the opt out approach appropriately balances the benefits of
data sharing with the ability of patients to control their health
information. All patients will be given the opportunity to opt out of
our Provider Access API policy. We agree that this information sharing
is important to improve the efficiency of the prior authorization
process and to ensure that patients have timely access to the care they
need. While patients may opt out of data flowing from their payer to
their provider via the Provider Access API, they cannot opt out of the
prior authorization process established by their payer or the
communications between their provider and payer that enable that
process.
Comment: Multiple commenters recommended that CMS adopt an opt in
approach instead of an opt out approach for the Provider Access API.
Commenters provided various rationales for recommending an opt in
approach, including that an opt in would give patients more control
over their data and is more understandable than an opt out process. A
commenter explained that while they support an opt in approach, they do
not agree that it would benefit disadvantaged people (such as people
with low health literacy or limited English proficiency) because
patients may not understand what it means to give permission for data
sharing. Multiple commenters also supported an opt in approach due to
patient privacy concerns with opt out. Specifically, a commenter with
concerns about sharing patients' mental health and substance use
information recommended that CMS adopt an opt in process, including a
requirement for patients to provide written authorization before such
information is accessible through the Provider Access API. The
commenter explained that there are laws in place requiring a written
authorization from a patient to disclose mental health and substance
use information. Another commenter also recommended that CMS align
requirements for the Provider Access API opt out approach with consent
requirements under 42 CFR part 2. A commenter further stated their
belief that most patients would choose to opt into the Provider Access
API if they are adequately informed of their rights and the potential
for API data exchange.
Response: We refer readers to our proposed rule for a full
discussion of why we proposed an opt out patient permission framework
(87 FR 76259). As discussed elsewhere, we are finalizing a requirement
that impacted payers must provide patients with plain language
information about the Provider Access API, including how to opt out of
data sharing, in order to help maximize patient control. This
requirement should ensure that patients, including those with low
health literacy or limited English proficiency, are aware of their
rights and have the opportunity to make an informed decision about
whether or not to allow payers to share their data with their providers
through the Provider Access API. We further remind readers that all
data sent and received via the Provider Access API must still be
handled consistent with all other applicable laws and regulations
regarding disclosure of these data. For instance, rules of
confidentiality for patient records associated with mental health or
substance use disorder, such as 42 CFR part 2, which may require
patient consent to share with providers, will still apply.
ii. Interaction With HIPAA
Comment: Multiple commenters stated that a process requiring
patient permission for data sharing via the Provider Access API is not
necessary because the HIPAA Privacy Rule permits PHI disclosure without
patient permission under certain circumstances. Specifically, they
reasoned that patient permission is not necessary if the PHI disclosed
via the Provider Access API falls within the scope of HIPAA treatment,
payment, and operations (TPO) disclosures, and recommended that CMS
limit the data shared via the Provider Access API to the scope of
permitted TPO disclosures. In support of their recommendation, these
commenters noted that requiring an opt out process could be confusing
and cumbersome to patients, negatively affect patient care, and would
conflict with Federal and state laws (including the HIPAA statute). In
a similar vein, commenters stated that CMS should rely on the HIPAA
Privacy Rule requirements instead of requiring an opt out process, and
a commenter suggested that CMS require impacted payers to include the
Provider Access API exchange in their HIPAA Notices of Privacy
Practices (NPP). Another commenter recommended that CMS make it clear
that payers may still share certain patient health information with
providers if it falls under the scope of a TPO disclosure, even when a
patient elects to opt out of data sharing. Multiple commenters
recommended that CMS provide additional guidance as to whether the
Provider Access API is to be used for purposes beyond treatment, and
indicated that providers should be able to access payer data for other
purposes permitted under the HIPAA Privacy Rule, such as payment.
Response: We understand that there are those who believe that an
opt out patient permission process is not necessary, given existing
HIPAA Privacy Rule provisions that permit PHI disclosure without an
individual's authorization under certain circumstances. However, we
emphasize that by virtue of this final rule, impacted payers would be
required to disclose any PHI specified within the content standards for
the Provider Access API, if the applicable requirements of this rule
were met. That disclosure would be permitted under the HIPAA Privacy
Rule as ``uses or disclosures that are required by law,'' \68\ rather
than as a permitted TPO disclosure. Required by law disclosures are
limited to the relevant requirements of such law, not to the HIPAA
minimum necessary standard,\69\ thereby ensuring that all content
required by our Provider Access API policy may be disclosed. Because
our policies would potentially give providers access to more than what
would have been considered to be the minimum necessary PHI under the
HIPAA Privacy Rule for certain purposes (for example, administrative
data in the USCDI that would not be used for treatment purposes), we
are requiring impacted payers to give patients or their personal
representatives an opportunity to opt out so that they have some
control over whether or not to share this additional data with their
provider(s). We believe that patients should control their own data to
the extent possible and with an opt out approach to data sharing, we
are giving patients this opportunity. Where the requirements of this
rule change how covered entities or their business associates may use
or disclose PHI, covered entities should consider their obligations
under the HIPAA Privacy Rule.
---------------------------------------------------------------------------

\68\ See 45 CFR 164.512(a).
\69\ See 45 CFR 164.502(b)(2)(v).
---------------------------------------------------------------------------

We emphasize that the opt out process described here only applies
to the Provider Access API policies in this final rule. That is, the
requirement for impacted payers to share individual

[[Page 8810]]

claims and encounter data, all data classes and data elements included
in a content standard at 45 CFR 170.213 (USCDI), and certain
information about prior authorizations maintained by the payer with a
date of service on or after January 1, 2016, with in-network providers
who have a treatment relationship with the patient. If a patient or
their personal representative opts out under our policy, then the
impacted payer should not share these data with a provider who requests
it under this policy. However, there may be other permissible bases for
payers and providers to share data, such as under the HIPAA Privacy
Rule's permitted uses and disclosures to carry out TPO. Patients or
their personal representatives do not have the ability to opt out of a
payer or provider using the API itself as a mechanism for sharing data
under such bases for disclosure.
We also note that the data that may be shared under other
permissible bases, such as the TPO exception, may overlap with the data
required to be shared by our Provider Access API policy. For instance,
a payer may be permitted to disclose clinical data included in a
content standard at 45 CFR 170.213 with a health care provider for
treatment purposes under 45 CFR 164.506(c)(2). If that disclosure is
permissible, a patient opting out of the Provider Access API policy in
this final rule would not prohibit a payer from using the Provider
Access API to make that disclosure. In addition, there may be
permissible bases for sharing data outside the scope of our Provider
Access API policy. As an example, payers may be permitted to disclose
clinical data that is not included in a content standard at 45 CFR
170.213, such as information related to SDOH, under the TPO exception.
Similarly, a patient or personal representative opting out of the
Provider Access API policy in this final rule would not prohibit a
payer from using the Provider Access API as the mechanism to make that
permissible disclosure.
Per 45 CFR 164.506(b), covered entities may create a process to
obtain consent from an individual to use or disclose PHI to carry out
TPO. Per 45 CFR 164.522(a), individuals also have the right to request
restrictions on how a covered entity will use and disclose PHI about
them for TPO. Except in limited circumstances, a covered entity is not
required to agree to an individual's request for a restriction. Where a
covered entity agrees to a restriction, it is bound to it unless the
restriction is subsequently terminated. We emphasize that the opt out
process described in this final rule is specific to the Provider Access
API policy and therefore is not, on its own, a consent mechanism per 45
CFR 164.506(b) or an agreed-upon restriction per 45 CFR 164.522(a).
Payers should make these nuances clear to patients in their
required educational resources, so that patients understand that their
PHI may still be shared in some instances, even if they or their
personal representative opts out of the Provider Access API policy.
iii. Interaction With Health Information Exchanges
Comment: Multiple commenters noted that HIEs would be great
partners for payers when implementing the Provider Access API, with one
noting that they could be used to reduce the number of endpoints
providers would need to query for patient information. Commenters
suggested that because many providers already have connections to HIEs
set up within their EHRs, HIEs could act as a conduit for the
information impacted payers are required to make available.
Furthermore, commenters stated that HIEs could make available patient
clinical data beyond what is maintained by the payer.
Response: We agree that HIEs could be helpful partners for payers
when implementing the Provider Access API and nothing in this rule
would prohibit an impacted payer from partnering with an HIE to meet
its requirements. As a commenter noted, HIEs have extensive experience
and expertise with patient matching and attribution, as well as with
various consent models. We additionally agree that provider
participation in an HIE can reduce the number of endpoints they would
need to query for care coordination and treatment. We further encourage
payers to look to HIEs or HINs as models for implementing a legal
framework for data exchange.
Comment: Multiple other commenters recommended that CMS both
explain and reexamine its interpretation of 42 CFR 431.306(d) and
457.1110(b) to prohibit Medicaid and CHIP programs from releasing
beneficiary information to outside sources without first obtaining
permission from the beneficiary or their personal representative. The
commenters stated that CMS's current interpretation would effectively
prohibit Medicaid agencies from participating in HIEs for Provider
Access API and TPO purposes. The commenters stated that CMS should
consider expanding this to include out-of-network providers.
Response: We do not agree that 42 CFR 431.306(d) and 457.1110(b)
prohibit Medicaid or CHIP agencies from contracting with an entity that
offers the technology to allow for digital access and transfer of a
patient's medical records, often referred to as an HIE. Section
1902(a)(7) of the Act, which our regulations at 42 CFR part 431,
subpart F, implement, requires that a state's Medicaid plan provide
safeguards which restrict the use or disclosure of information
concerning Medicaid applicants and beneficiaries to purposes directly
connected with administration of the state plan. Our regulations at 42
CFR part 431, subpart F, set forth requirements for states to safeguard
Medicaid applicants' and beneficiaries' information in accordance with
section 1902(a)(7) of the Act, including requirements for safeguarding
the information, what types of information must be safeguarded, and
when and how to release otherwise safeguarded information. The same
requirements also apply to separate CHIP programs through a cross
reference at 42 CFR 457.1110(b). The disclosures of beneficiary data to
an HIE contracted to develop and maintain the required Provider Access
API would be directly related to the administration of the state plan,
because sharing beneficiary data through the Provider Access API
supports the provision of services for beneficiaries, as described at
42 CFR 431.302(c). Access to beneficiary data could help a provider
better manage a beneficiary's total care because the data would provide
a more in-depth medical history, enable more informed decision making,
and potentially prevent orders for, or the provision of, duplicative
services. Further, under section 1902(a)(4) of the Act, Medicaid
agencies may contract with organizations to enhance the agency's
capability for effective administration of the program.
The regulation at 42 CFR 431.306(d) generally requires states to
obtain permission from an individual Medicaid or CHIP applicant or
beneficiary, or their personal representative, before responding to a
request for information from an outside source, or disclosing that
applicant's or beneficiary's data safeguarded under 42 CFR 431.305.
There is no requirement for a state Medicaid or CHIP agency to obtain
permission from an individual or family member prior to providing
information about a Medicaid or CHIP beneficiary to an enrolled
Medicaid or CHIP provider because enrolled providers are not outside
sources as described at 42 CFR 431.306(d). Enrolled Medicaid and CHIP

[[Page 8811]]

providers are part of a state's Medicaid and/or CHIP FFS programs
because they are contracted to support the agency's administration of
its Medicaid or CHIP state plan. Specifically, an enrolled Medicaid or
CHIP provider has a provider agreement with the Medicaid or CHIP agency
to provide Medicaid or CHIP benefits and services under the state plan.
Thus, the state Medicaid agency could share Medicaid or CHIP
beneficiary information with enrolled providers for purposes directly
connected to administration of the state plan, without prior permission
from the Medicaid or CHIP beneficiary required by 42 CFR 431.306(d) and
457.1110(b) respectively.
Similarly, state Medicaid and CHIP agencies may share Medicaid and
CHIP beneficiary information with entities with which the state
Medicaid or CHIP agency has contracted to support the agency's
administration of its Medicaid or CHIP state plan. Such contractors
would not be considered ``outside sources'' because they are contracted
to carry out functions directly related to administration of the state
Medicaid or CHIP plan, such as case management and long-term services
and supports for Medicaid or CHIP beneficiaries. Thus, if a state
Medicaid or CHIP agency contracts with an HIE to carry out
administrative functions of the state's Medicaid or CHIP program, such
as developing and maintaining the required Provider Access API, the HIE
would not be considered an ``outside source'' and the state Medicaid or
CHIP agency could share Medicaid or CHIP beneficiary information with
the HIE for the purposes directly connected to administration of the
state plan, without prior permission from the Medicaid or CHIP
beneficiary required by 42 CFR 431.306(d) and 457.1110(b) respectively.
In addition, to receive beneficiaries' information from the
Medicaid or CHIP agency, Medicaid or CHIP providers, plans, or
contractors must be subject to standards of confidentiality comparable
to those of the state Medicaid or CHIP agency in accordance with 42 CFR
431.306(b) and 457.1110(b) respectively. Furthermore, the Medicaid
regulation at 42 CFR 434.6(a)(8) requires that each of the state
Medicaid agency's contracts must provide that the contractor safeguards
information about beneficiaries as required by 42 CFR part 431, subpart
F. Under these requirements, if a state Medicaid or CHIP agency
contracted with an HIE or other entity, the contractor would be
required to meet the same standards of confidentiality as the state
Medicaid or CHIP agency (as set forth in section 1902(a)(7) of the Act
and our implementing regulations at 42 CFR part 431, subpart F),
including but not limited to--
Providing safeguards that restrict the use or disclosure
of information concerning applicants and beneficiaries to purposes
directly connected with the administration of the plan in accordance
with section 1902(a)(7) of the Act and 42 CFR 431.300 and 431.302; and
Not disclosing data to an outside source, such as
providers that are not enrolled with the state Medicaid or CHIP agency,
and that might be participating in an HIE, without prior permission
from the individual in accordance with 42 CFR 431.306(d).
iv. Opt Out Process Design
Comment: Commenters provided thoughts about the implementation of
the proposed opt out requirement. Multiple commenters suggested that
CMS require a standardized opt out process to improve the patient and
provider experience. A commenter expressed concern that the proposed
implementation flexibility could be difficult for patients to navigate,
while another commenter requested clarification on what opting out and
opting back in means.
Response: We agree that it is important to make it easy for
patients or their personal representatives to opt out of data sharing.
However, it is also important to give payers flexibility in how they
implement the opt out process required by this rule. We recognize that
payers' approaches may vary depending on their systems, capabilities,
and specific enrollee population. Requiring a specific process could
impose unnecessary burden on payers. We remind readers that regardless
of what process payers choose, a patient or their personal
representative must have the ability to change their data sharing
permission at any time. For example, if a patient or their personal
representative previously opted out of having their data shared under
the Provider Access API policy, they should be able to reverse this
decision, effectively choosing to opt back into having their data
shared under the Provider Access API policy. We additionally note that
each of our policies in this final rule is targeted toward individual
patients, not any family members that may be covered through the same
benefits. In some cases, applicable law may allow one individual (such
as a parent or guardian) to act as a personal representative for
another individual covered under the same benefits (such as a minor)
and could therefore opt out of data sharing under the Provider Access
API for that person. No data should be shared about any patient that
has opted out (or whose personal representative has opted out),
regardless of whether another patient covered under the same benefits
has chosen to not opt out. We will continue to monitor implementation
of the Provider Access API opt out requirement to ensure payers' opt
out processes for the Provider Access API are easy and intuitive for
patients or their personal representatives to use.
Comment: Commenters recommended that CMS include several
additional, explicit requirements related to the Provider Access API
opt out process. Multiple commenters also recommended requiring or
permitting payers to incorporate the opt out process into their
existing platforms and communications, including patient portals,
payers' websites, and within payers' regular communications with
patients. A commenter encouraged CMS to collaborate with interested
parties to develop a single platform for patients to give permission
for data sharing.
Response: While we are not requiring impacted payers to incorporate
their opt out processes into their existing platforms and
communications, we generally expect that that would result in the least
amount of burden on payers and patients. There are solutions available
that could be leveraged to manage permissions across payers, such as
HIEs. We encourage impacted payers to investigate a variety of options
to determine the solution that is best for them and their patients.
Comment: Multiple commenters made recommendations related to the
accessibility of the opt out process. They recommended that CMS require
impacted payers to provide options to patients for opting out of data
sharing that are accessible to patients with varied technological
literacy (that is, via mail, fax, and phone). A commenter recommended
that opt out information be available for the Provider Access API in
multiple languages to reduce disparities and barriers to patients'
understanding of the opt out process. Another commenter recommended
that CMS establish clear expectations for how payers should accommodate
patients who may have difficulty accessing the opt out process or that
CMS should track the extent to which patients encounter difficulties
with opting out of data sharing. A commenter further recommended that
payers collect patients' opt out elections at the point of treatment,
so that it is clear which provider(s) have access to the patient's data
via the Provider Access API policy.
Response: We agree with commenters that payers should make efforts
to

[[Page 8812]]

ensure their patients or their personal representatives have the
opportunity to opt out of data sharing under the Provider Access API
policy and should be accommodated accordingly. These accommodations
certainly include accounting for varied technology literacy and
language barriers (see section II.B.3.c.ii. of this final rule for a
discussion on plain language and existing requirements to make
information accessible in other languages or formats). However, we do
not want to be overly prescriptive to payers, as we believe they would
know best how to accommodate their particular patient population. We
disagree that payers should collect patient opt out elections at the
point of treatment because we intend for these data to be available to
the provider before patient appointments, and such practices are also
outside the scope of a provider's role. We therefore intend to monitor
patient experience and payer compliance with the opt out process and
will consider our observations through this monitoring for future
rulemaking.
Comment: Multiple commenters recommended implementing processes for
payers to notify providers of patients' election to opt out of the
Provider Access API data exchange. A commenter identified some
potential implementation challenges for providers, including that
tracking patient permission would be challenging and that the opt out
approach could create segmented data captures and multiple workflows.
Another commenter flagged that CMS should not rely on physicians to
educate patients on the intricacies of APIs, instead encouraging CMS to
provide standardized language and guidelines to payers around how the
process to opt out will be communicated to patients and the process for
collecting and communicating opt outs to physicians.
Response: While we are not requiring impacted payers to notify
providers of their patients' election to opt out of the Provider Access
API data exchange, we agree that notification can increase the utility
of the Provider Access API for providers. We remind readers that we are
not requiring providers to track patient data sharing permission,
educate patients about their data sharing options, or utilize the
Provider Access API at all. However, we believe that giving providers
access to more patient data will benefit the care that they provide,
and we encourage them to adjust their workflows and work with their EHR
developers to take advantage of the data availability through this new
mechanism.
Comment: A commenter noted that it will take time for payers to
process opt out requests from patients or their personal
representatives who choose to opt out of having their data shared after
enrollment. Another commenter suggested that patients should be able to
record their permission through multiple channels (for example, OAuth
2.0, portal access, and the FHIR consent profile). A commenter also
stated that payers may have to design related processes to allow
patients to opt in to sharing of sensitive information that adhere to
state or local privacy laws. A commenter further sought guidance on
whether specific consent language would be required for patients or
their personal representatives to opt in and whether an opt in election
may be included in the HIPAA authorization form or other enrollment
materials.
Response: Payers will have flexibility in how they process patient
data sharing permission and the channels that patients may use to make
their election. We caution, however, that any such opt out channels
should be both optimally accessible to patients or their personal
representatives and not onerous for them to navigate. Part of managing
an opt out process will include cognizance of other laws that may
restrict data sharing, such as state privacy laws. In fact, if other
applicable law requires an opt in permission for data sharing, payers
may integrate both the Provider Access API opt out and other permission
gathering processes to simplify patients' ability to control their
data, to the extent permitted by law. Finally, regarding the commenter
seeking specific consent language for opt in and clarification related
to leveraging the HIPAA authorization form for this purpose, we
emphasize that this final rule finalizes an opt out framework for the
Provider Access API, not an opt in. We further note that compound HIPAA
authorizations are generally prohibited, per 45 CFR 164.508(b)(3).
v. Opt Out Timeframes
Comment: Multiple commenters stated that patients or their personal
representatives should be allowed to opt out at any time. Other
commenters supported payers providing an option to opt out at a certain
time, such as at the time of enrollment. A commenter recommended that
CMS allow payers 30 days to process a patient's request to opt out and
stop sharing the patient's data via the Provider Access API.
Response: We agree that patients or their personal representatives
should be able to opt out of data sharing under the Provider Access API
policy at any time and we are requiring impacted payers to give their
patients the opportunity to do so. As discussed in section II.B.3.c. of
this final rule, no later than one week after the start of coverage and
annually, patients will need to be given information about their opt
out rights and instructions both for opting out. We remind readers that
``start of coverage'' is defined differently, as applicable, for each
type of impacted payer. We refer readers to section II.C.3.c.i. of this
final rule for discussion of these differences. We do not agree that
the opt out option should be time-limited, as that reduces patient
control over their health data.
c. Patient Educational Resources Regarding the Provider Access API
To help patients understand the implications of the opt out
provision for the Provider Access API, we proposed to require impacted
payers to disseminate certain educational resources to their patients.
We proposed that those resources would include information about the
benefits to the patient of API data exchange, their opt out rights, and
instructions both for opting out of the data exchange and for opting in
after previously opting out. We proposed that payers would have to
provide this information, in non-technical, simple, and easy-to-
understand language, before the first date on which the payer makes
patient information available through the Provider Access API, at the
time of enrollment and annually thereafter. We also proposed that
payers would be required to make this information available at all
times, in an easily accessible location on payers' public websites. We
did not propose to require this information to also be distributed to
patients' personal representatives. However, we highly encourage
impacted payers to do so, especially if distributing other materials to
personal representatives is typical. We also did not propose specific
text or format for this information, but requested suggestions and
comments on whether required content or format would be beneficial or
burdensome. In particular, we sought comments on language explaining
how patient data that is shared through the Provider Access API could
be used. We anticipated that payers would want to include this
information in their regular communications, such as annual enrollment
information, privacy notices, member handbooks, or newsletters.
However, we requested comment on the most appropriate and effective
communication channel(s) for conveying this information to patients. We
also requested comment on whether

[[Page 8813]]

a requirement to provide this information at the time of enrollment and
annually is appropriate, or whether we should require payers to share
this information more frequently.
We believe it is important to honor patient privacy preferences.
Offering patients educational resources about their right to opt out of
the Provider Access API data sharing is thus fundamental to empowering
patients with respect to their data.
As discussed in more detail, we are finalizing a modification to
these proposals, that impacted payers must provide this information to
patients no later than one week after the start of coverage. ``Start of
coverage'' is defined differently, as applicable, for each type of
impacted payer and we refer readers to section II.C.3.c.i. of this
final rule for discussion of these differences.
i. Dissemination
Comment: Multiple commenters supported the proposed requirement for
payers to disseminate patient educational resources and made
recommendations for communicating with, or sending information to
patients. These recommendations include disseminating educational
resources through existing patient portals, letters, text messages, and
information posted on websites, in handbooks, and by mail.
Conversely, a commenter recommended that CMS not require physical
materials be sent annually to patients. The commenter recommended that
payers should only send hard copies to patients who have opted out of
data sharing. However, another commenter stated that separate patient
resources for the Provider Access API are not necessary at all. A
commenter additionally stated that many plan renewals do not actually
generate patient-visible paperwork, forms, or formal documents of any
sort and provided examples for how frequently sharing patient resources
currently occurs. A commenter further stated that payers should have
the flexibility to communicate with their members in a manner
consistent with a set format and content for consistency and clarity.
Response: We emphasize that impacted payers can indeed use their
existing processes for producing patient-facing resources and will be
permitted to send their patient education resources through the
communication channels they think are most effective for reaching their
patients, including emails, messages through a payer portal, or
physical mail. It is not our intention to overburden payers, and thus
we do want to be overly prescriptive in a way that that will unduly
disrupt how they currently communicate with their patients. We disagree
that only patients who have opted out of data sharing should receive
these resources. Under our policies, patients may choose to change
their data sharing permission at any time and we thus believe that they
should remain maximally informed of their choices.
We are also finalizing a modification to the proposed rule
regarding payer deadlines, to give payers more clarity and an
appropriate amount of time to meet these requirements, as well as to
align with policies we are finalizing for the Payer-to-Payer API (see
section II.C.3.c.i. of this final rule). Specifically, payers will be
required to provide patients, no later than one week after the start of
coverage, information about the benefits of API data exchange with
their providers, their opt out rights, and instructions for both for
opting out of data exchange and for opting in after previously opting
out. This timeframe is intended to provide a reasonable amount of time
after a payer receives confirmation that a patient will be enrolled in
coverage with them. As further discussed in section II.C.3.c.i., to
ensure feasible timeframes, we are finalizing deadlines to account for
situations when coverage starts prospectively or retroactively for MA
plans and QHPs issuers on the FFEs and retroactively for Medicaid and
CHIP.
Comment: Multiple commenters supported our proposal to require
impacted payers to provide patient education resources at enrollment
and annually thereafter. A commenter stated that educational resources
could also come from providers at patient interactions. Other
commenters expressed that CMS's requirements should not add burden to
providers or interfere with their clinical workflow. A commenter
recommended that CMS not require Medicaid agencies to provide
information on the Provider Access API opt out policy more frequently
than at member enrollment and annually. The commenter stated that it
would be resource intensive and would require new workstreams and
member outreach processes.
Response: We thank commenters for their support of our proposal to
require impacted payers to provide patient education resources at
enrollment and annually thereafter (though we are finalizing a
modification to this proposal, as explained above). We did not propose
to require any role for providers, as we agree this would increase
their administrative burden. We also agree with commenters that
providing these resources more frequently would indeed increase burden,
which is why we did not propose for impacted payers to do so.
ii. Content
Comment: Multiple commenters suggested that CMS require payers to
use clear and plain language and ensure the opt out policy is
prominent.
Response: We agree with commenters' sentiments and thus proposed
that patients should be able to easily understand the patient education
resources. In response to both these comments and comments on our opt
out proposals, as well as for consistency with other policies, we are
finalizing this rule slightly differently from how it was proposed. We
had proposed that impacted payers provide patient education resources
in ``non-technical, simple, and in easy-to-understand language,'' but
our finalized requirement is that they use ``plain language.'' This
change is not intended to alter that the educational information be
non-technical, simple, and easy-to-use, but to make clear that we
encourage impacted payers to follow the Federal Government's plain
language guidelines. Those guidelines were informed by the Plain
Writing Act of 2010, which requires Federal agencies to use clear
government communication that the public can understand and use. That
statute only applies to Federal Government agencies, but the plain
writing guidance \70\ that has been developed for the Federal
Government will be useful for impacted payers when developing
educational resources for patients. We note that providing these
patient educational resources is a separate requirement from the
requirement to create an NPP under the HIPAA Privacy Rule.\71\
---------------------------------------------------------------------------

\70\ General Services Administration (n.d.). Federal plain
language guidelines. Retrieved from https://www.plainlanguage.gov/guidelines/.
\71\ Department of Health and Human Services (n.d.). Notice of
Privacy Practices for Protected Health Information. Retrieved from
https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/privacy-practices-for-protected-health-information/.
---------------------------------------------------------------------------

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

[[Page 8814]]

Response: Impacted payers may already be required to provide plain
language resources in languages other than English, per 45 CFR part 92,
which requires impacted payers (as health programs or activities under
that section) to provide meaningful access to individuals with limited
English proficiency and accessibility requirements for individuals with
disabilities. The requirements of that part apply to impacted payers,
as described at 45 CFR 92.3.
Additionally, this rule does not affect standards already in place
for specific payers on state or Federal levels. For example, 45 CFR
156.250 requires QHP issuers on the FFEs to provide information in
accordance with the accessibility standards for individuals with
disabilities and individuals with limited English language proficiency
at 45 CFR 155.205(c). Other impacted payers might have their own
standards for accessible patient-facing resources, as well, that would
not be affected by this final rule.
Comment: Multiple commenters recommended, for ease of readability,
that resources or notices be written at a certain grade level. Multiple
commenters recommended that CMS amend the patient resources proposal to
require impacted payers to write resources at a fourth-to-sixth grade
reading level.
Response: While we agree that these resources need to be
understandable, we do not believe that it is prudent to establish a
specific ``grade level'' requirement. A grade level score is based on
the average length of the words and sentences. Readability formulae
vary and the grade level scores for the same text can differ depending
on how it is used. Furthermore, edits that are made to make text score
at a lower grade level can produce choppy text that lacks cohesion.
Comment: A commenter did not support the development of patient
education resources that may be duplicative or confusing to patients,
while another did not support the proposal for separate patient
outreach and education if the data sharing under the Provider Access
API is permitted under the HIPAA Privacy Rule's TPO exception.
Response: We refer readers to section II.B.3.b.ii. of this final
rule for a full discussion of the HIPAA Privacy Rule's applicability
and why we are requiring an opt out policy for the Provider Access API.
We believe that plain language educational resources will inform rather
than confuse patients. We encourage payers to explain to patients that
not opting out of data sharing would not limit or negatively affect
their rights under the HIPAA Privacy Rule. Rather, it is an opportunity
for them to control where their data are shared under the policies of
this final rule. Where the requirements of this rule change how covered
entities or their business associates may use or disclose PHI, covered
entities should also consider their obligations under the HIPAA Privacy
Rule.
Comment: Commenters recommended that CMS require additional details
from payers about their opt out process for the Provider Access API. A
commenter stated patients should receive detailed communications that
include the potential benefits and harms of sharing versus not sharing
this information, including the potential impact on quality and
timeliness of care. Commenters further recommended that resources
include information on privacy and security, moving data to a third-
party app, and guidelines for patient-provider dialogue on consent.
Response: As explained, we did not want to be overly prescriptive
for the specific language used for the patient resources, but we did
propose that they include patient instructions for opting out of data
sharing and controlling their permission. We specifically proposed that
the patient education resources include information about the benefits
of API data exchange. In addition, impacted payers may, if they choose,
include reasonable and objective information about any risks to data
sharing. However, the purpose of the information in the educational
resources, regardless of the particular content, should be to inform
patients. We believe that patients educated with accurate information
will realize the benefits of data sharing via the Provider Access API
and most will not opt out.
We agree that plain language resources should include information
about privacy and security, in order to give patients an informed view
of how the Provider Access API works. It is also reasonable and
acceptable for payers to bundle or combine the educational resources
about the Provider Access API with the educational resources about the
Patient Access and Payer-to-Payer APIs, discussed in sections II.A. and
II.C. of this final rule, to give patients a holistic view of how our
interoperability policies work together to improve data exchange.
Comment: Commenters recommended that CMS partner with ONC to
develop templates and content for these educational resources, which
impacted payers could use to meet this requirement. Many commenters
recommended that CMS work with the health care community and patient
advocates to develop language on the benefits and risks of data
exchange. Commenters also recommended that CMS work with industry to
develop and disseminate educational resources by creating a web page
dedicated to interested party-specific newsletter inserts, holding CMS
open door virtual forums, and using other methods to communicate
regulatory and implementation updates.
Response: We intend to continue working with Federal and industry
partners to increase patient engagement in a way that both protects
their autonomy and enables the sharing of the data to improve their
health care. Based on feedback, we intend to develop additional
outlines or templates for patient education resources.
d. Provider Resources Regarding the Provider Access API
We proposed to require impacted payers to develop non-technical and
easy-to-understand resources for providers about the Provider Access
API. We proposed that those resources would have to include information
about the process for requesting patient data from payers via the
Provider Access API and how to use the payer's attribution process to
associate patients with the provider. We proposed that impacted payers
provide these resources to providers through the payer's website and
other appropriate provider communications, such as annual contract
updates or handbooks. Non-technical resources will help providers
understand how they can use the API to access patient data, thus
realizing the expected benefit of the proposed API. We requested
comment on this proposal, including whether CMS should develop guidance
regarding, or address in future rulemaking, the specific content of
these educational resources about the Provider Access API.
As discussed in more detail, we are finalizing this proposal, with
a modification that provider resources be in plain language.
i. Dissemination
Comment: Multiple commenters expressed support for requiring
impacted payers to make these resources easily available on a payers'
website, in contracts, and in provider handbooks. However, other
commenters sought clarification on what ``other appropriate provider
communications'' are and whether existing provider communication
channels can be used to provide these resources. A commenter stated
that it is unreasonable to expect

[[Page 8815]]

providers and their staff to access each payers' website to obtain the
payers' specific resources and they do not believe this will happen in
a reliable manner. Other commenters stated that the resources should be
incorporated into a clinical workflow or EHRs.
Response: While the provider resources must be available on the
payer's website, we are also requiring impacted payers to send those
resources directly to providers through other appropriate channels. We
encourage payers to use existing methods of communication by which
providers expect to receive information from payers. We use the term
``other appropriate provider communications'' to provide payers with
flexibility, but that term includes existing communication channels.
For example, 42 CFR 422.202 requires MA organizations to provide to
participating physicians written notice of rules of participation,
including terms of payment, credentialing, and other rules directly
related to participation decisions. The Provider Access API resources
can be disseminated along with such resources.\72\ While payers are
welcome to use the Provider Access API to make those resources
available, they would have to develop an operable solution.
Furthermore, if a provider needs guidance to access the Provider Access
API, requiring a connection and query would not be useful.
---------------------------------------------------------------------------

\72\ See 42 CFR 422.202(a)(1).
---------------------------------------------------------------------------

ii. Content
Comment: Multiple commenters supported the proposal for impacted
payers to disseminate provider-facing resources, particularly with
instructions for attributing patients to a provider.
Response: We appreciate commenters support for this requirement. As
finalized, payers will be required to include information about the
payer's process to attribute patients to a particular provider. We also
highly recommend that payers include contact information for provider
assistance. To be consistent with our revision to the patient education
resources policy, but also being clear that we have not altered the
intent, we are finalizing regulatory text slightly different than what
we had proposed, to require provider education resources in ``plain
language,'' as opposed to our proposed ``non-technical, simple, and in
easy-to-understand language.''
Comment: Multiple commenters recommended more technical education
resources than we proposed because of the technical nature of API data
exchange. A commenter suggested that the resources include information
about the IGs, links to the payer's technical documentation and contact
information for assistance with the Provider Access API. Another
commenter warned that the educational resources need to be better
defined, because they believe that the information we describe will be
more appropriate for EHR vendors than providers. In fact, another
commenter stated that it may be more appropriate for EHR and practice
management system vendors to provide education resources that offer
greater specificity about how data are integrated into provider data
systems and workflows.
Response: While payers will have to include instructions for
accessing patient data, we disagree with the recommendation that payers
include more technical documentation. We do not believe that most
providers will be interested in the specific implementation details of
the API, but will rely on their technology vendor. We remind payers
that, per the final requirements in the CMS Interoperability and
Patient Access final rule, they are required to make technical
information about their Patient Access APIs available by posting
directly on their website.\73\ We are finalizing this requirement by
reference for the Provider Access, Payer-to-Payer, and Prior
Authorization APIs, as well. References or links to that material would
be entirely appropriate to include in the required provider resources.
EHR and practice management vendors also have a role to play in
educating providers about the functionality of their particular system.
However, only payers will be able to offer provider specific details
about their Provider Access API and the process for attributing
patients.
---------------------------------------------------------------------------

\73\ See 42 CFR 422.119(d), 431.60(d), and 457.730(d) and 45 CFR
156.221(d).
---------------------------------------------------------------------------

Comment: Commenters suggested that CMS require using language
regarding limitations related to disclosures of sensitive conditions
that are subject to 42 CFR part 2 and disclosures to minors.
Response: Though we are not requiring it to be included in the
provider resources, payers should adequately inform providers of what
data are and are not available through the Provider Access API.
Providers should be aware of what they can expect to receive in
response to a request, whether that is because of the data content
requirements, payer maintenance policies, or privacy limitations.
Comment: Multiple commenters requested that CMS develop educational
resources that impacted payers could disseminate to their providers to
ensure consistency and that providers are aware of any reporting
protocols for payer non-compliance. A commenter added that these
requirements and related guidance should be posted on CMS provider web
pages and print publications. Multiple commenters recommended that CMS
consult with Federal partners at ONC, the Health Resources and Services
Administration (HRSA) and the Agency for Healthcare Research and
Quality (AHRQ), and the provider community in order to understand their
educational needs and how best to promote the resources. A commenter
recommended that CMS provide additional guidance on the education and
training efforts to provider specialties who are lagging the industry
in interoperable technology adoption.
Response: Based on comments we received, we intend to provide
general guidelines to impacted payers about what this final rule
requires to be disseminated to providers, which may include information
on potential best practices. However, unlike the patient-facing
educational resources described previously, we expect that provider
resources could vary significantly between payers. Payers will have
different processes to allow providers to request data via the Provider
Access API and policies for patient attribution to explain to their
providers. Therefore, there is less benefit to standardized templates
or content for these resources. We provided links to resources for APIs
to support payers implementing provisions of the CMS Interoperability
and Patient Access final rule (85 FR 25510) \74\ and we intend to
identify similar resources for health care providers for this final
rule. We will continue to work with our partners to ensure providers
can access patient data, regardless of the technology they use.
Requiring an API that can be accessed with systems other than CEHRT is
a step toward that goal, and payer-developed resources should address
all the ways providers could interact with the Provider Access API.
---------------------------------------------------------------------------

\74\ Centers for Medicare and Medicaid Services (n.d.). Best
Practices for Payers and App Developers. Retrieved from https://www.cms.gov/files/document/best-practices-payers-and-app-developersupdated21023.pdf.
---------------------------------------------------------------------------

4. Extensions, Exemptions, and Exceptions
See section II.E. of this final rule for a discussion of extensions
and exemptions and the final policies for the Provider Access API for
state Medicaid and CHIP FFS programs and exceptions for the Provider
Access API for QHP

[[Page 8816]]

issuers on the FFEs (this was also addressed in the proposed rule at 86
FR 76279).
BILLING CODE 4150-28-P
[GRAPHIC] [TIFF OMITTED] TR08FE24.001

[[Page 8817]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.002

BILLING CODE 4150-28-C
5. Final Action
After considering the comments received, and for the reasons
discussed in the CMS Interoperability and Prior Authorization proposed
rule and our response to those comments (as summarized previously), we
are finalizing our proposal with the following modifications:
---------------------------------------------------------------------------

\75\ See Table H1 for which standards are required for the
Provider Access API.
---------------------------------------------------------------------------

Impacted payers must implement and maintain a Provider
Access API beginning 2027 (by January 1, 2027, for MA organizations and
state Medicaid and CHIP FFS programs; by the rating period beginning on
or after January 1, 2027, for Medicaid managed care plans and CHIP
managed care entities; and for plan years beginning on or after January
1, 2027, for QHP issuers on the FFEs) rather than in 2026.
Impacted payers are not required to use OpenID Connect
Core at 45 CFR 170.215(e)(1) for the Provider Access API.
Impacted payers are not required to share the quantity of
items or services used under a prior authorization via the Provider
Access API.
Impacted payers are not required to share unstructured
documentation related to prior authorizations via the Provider Access
API.
Impacted payers are required to provide educational
resources to patients no later than one week after the start of
coverage, as that term is defined for each type of impacted payer,
rather than at enrollment.
The educational resources that impacted payers are
required to provide to patients and providers are described as ``plain
language'' rather than in ``non-technical, simple, and in easy-to-
understand language.''
See further discussion later for exact details of the final
requirements for impacted payers.
We are finalizing that beginning 2027 (by January 1, 2027, for MA
organizations and state Medicaid and CHIP FFS Programs; by the rating
period beginning on or after January 1, 2027, for Medicaid managed care
plans and CHIP managed care entities; and for plan years beginning on
or after January 1, 2027, for QHP issuers on the FFEs), impacted payers
must implement and maintain a Provider Access API that is conformant
with certain technical standards, documentation requirements, and
denial or discontinuation policies. Specifically, those technical
standards are HL7 FHIR at 45 CFR 170.215(a)(1), US Core IG at 45 CFR
170.215(b)(1)(i), SMART App Launch IG at 45 CFR 170.215(c)(1), and Bulk
Data Access IG at 45 CFR 170.215(d)(1).
We are finalizing that, by the deadlines, impacted payers must make
available upon request from an in-network provider, via the Provider
Access API, claims and encounter data (excluding provider remittances
and patient cost-sharing information), all data classes and data
elements included in a content standard at 45 CFR 170.213 (USCDI), and
certain information about prior authorizations (excluding those for
drugs) that the payer maintains no later than 1 business day after
receiving a request from such a provider, if all the following
conditions are met:
The payer authenticates the identity of the provider that
requests access and attributes the patient to the provider under the
required attribution process;
The patient does not opt out of the Provider Access API;
and
Disclosure of the data is not prohibited by law.
The required prior authorization information is:
The prior authorization status;
The date the prior authorization was approved or denied;
The date or circumstance under which the prior
authorization ends;
The items and services approved;
If denied, a specific reason why the request was denied;
and
Related structured administrative and clinical
documentation submitted by a provider.
We are finalizing that impacted payers are required to make this
information about prior authorizations available no later than 1
business day after the payer receives a prior authorization request and
must update that information no later than 1 business day after any
status change. This information must be available for the duration that
the authorization is active and at least 1 year after the prior
authorization's last status change.
We are finalizing that impacted payers must establish and maintain
an attribution process to associate patients with their in-network or
enrolled providers to enable payer to provider data exchange via the
Provider Access API.
We are finalizing that, by the deadlines, impacted payers must
establish and maintain a process for patients to opt out of data
exchange via the Provider Access API and to change their permission at
any time. We are finalizing that this process must be made available
before the first date on which the payer makes patient information
available via the Provider Access API, and at any time while the
patient is enrolled with the payer.
We are finalizing that, by the deadlines, impacted payers provide
educational resources in plain language to their patients about the
Provider Access API. Those resources must include information about the
benefits of API data exchange with providers, patients' opt out rights,
and instructions for both opting out of data exchange and for
subsequently opting in. Impacted payers must make this information
available to patients before the first date on which the payer makes
their

[[Page 8818]]

information available via the Provider Access API, no later than one
week after the start of coverage, and at least annually. These
resources must also be available in an easily accessible location on
payers' public websites. We remind readers that ``start of coverage''
is defined differently, as applicable, for each type of impacted payer.
We refer readers to section II.C.3.c.i. for discussion of these
differences.
We are finalizing that, by the deadlines, impacted payers must
provide on their website and through other appropriate provider
communications, information in plain language explaining the process
for requesting patient data using the Provider Access API. The
resources must include information about how to use the payers'
attribution process to associate patients with their providers.
These policies apply to MA organizations, state Medicaid and CHIP
FFS programs, Medicaid managed care plans and CHIP managed care
entities (excluding NEMT PAHPs), and QHP issuers on the FFEs at the CFR
sections listed in Table C1.
6. Statutory Authorities for Provider Access API
We received no public comments on the statutory authorities for our
Provider Access API policies.
a. Medicare Advantage Organizations
For MA organizations, we are finalizing these Provider Access API
requirements under our authority at sections 1856(b)(1) of the Act to
promulgate regulations that adopt standards to implement provisions in
Part C of Title XVIII of the Act (such as section 1852(d)(1)(A)) of the
Act to adopt new terms and conditions for MA organizations that the
Secretary finds ``necessary and appropriate.'' Section 1852(d)(1)(A) of
the Act requires MA organizations to, as a condition of using a network
of providers, make covered benefits available and accessible to
enrollees in a manner that assures continuity in the provision of
benefits. As noted in this section of this final rule, these
regulations implement this requirement by requiring implementation of
an API that will make available data to improve the provision of
benefits. The Secretary also has authority under section 1857(e)(1) of
the Act to add new contract terms, including additional standards and
requirements, for MA organizations the Secretary finds necessary and
appropriate and that are not inconsistent with Part C of the Medicare
statute.
In implementing section 1852(d)(1)(A) of the Act, we previously
adopted a regulation, at 42 CFR 422.112(b), that requires MA
organizations to ensure the continuity of care and integration of
services through arrangements with providers that include procedures to
ensure that the MA organization and the contracted providers have
access to the information necessary for effective and continuous
patient care. Our policy for MA organizations to implement and maintain
a Provider Access API will facilitate exchanges of information about
enrollees that are necessary for effective and continuous patient care,
which is consistent with the requirement at section 1852(d)(1)(A) of
the Act for continuing the provision of benefits. The Provider Access
API policy, which will support sharing claims, all data classes and
data elements included in a content standard at 45 CFR 170.213 (USCDI),
as well as certain information about prior authorizations (sections
II.B.2. and II.B.3. of this final rule) and a requirement for MA
organizations to offer provider educational resources (section
II.B.3.d. of this final rule), will give providers tools to support
continuity of care and care coordination for enrollees. Were a provider
able, through a Provider Access API established by an MA organization,
to gather information for their patient, the provider potentially could
make more informed decisions and coordinate care more effectively. In
addition, if a patient moves from one provider to another, the new
provider will be able to ensure continuity of care if they are able to
access relevant health information for the patient from the MA
organization in an efficient and timely way. A Provider Access API
could support this; thus, the policy will carry out and be consistent
with the Part C statute.
This policy will complement and align with MA organization
obligations at 42 CFR 422.112(b)(4) by providing a means, through a
Provider Access API, for the exchange of information that supports
effective and continuous patient care. A Provider Access API may
increase the efficiency and simplicity of administration. It will give
providers access to a significant amount of their patients' information
with limited effort, and it could reduce the amount of time needed
during provider visits to establish a patient's prior history, which
could introduce efficiencies and improve care. These policies are also
expected to allow for better access to other providers' prior
authorization decisions, which could give a provider a more holistic
view of a patient's care and reduce the likelihood of ordering
duplicate or misaligned services. Ultimately, we anticipate that
sharing patient information will ensure that providers receive patient
information in a timely manner and could lead to more appropriate
service utilization and higher patient satisfaction. In addition, the
policy that MA organizations make available educational resources and
information will increase access to and understanding of this Provider
Access API, leading to more efficient use and integration of the API as
a means for providers to access patient information. Thus, the Provider
Access API will be necessary and appropriate for the MA program and
consistent with existing requirements.
b. Medicaid and CHIP
Our finalized requirements in this section for Medicaid FFS and
Medicaid managed care plans fall generally under the authority in the
following provisions of the statute:
Section 1902(a)(4) of the Act, which requires that a state
Medicaid plan provide such methods of administration as are found by
the Secretary to be necessary for the proper and efficient operation of
the state Medicaid plan;
Section 1902(a)(8) of the Act, which requires states to
ensure that Medicaid services are furnished with reasonable promptness
to all eligible individuals; and
Section 1902(a)(19) of the Act, which requires states to
ensure that care and services are provided in a manner consistent with
simplicity of administration and the best interests of the recipients.
The final Provider Access API policies are authorized under these
provisions of the Act because they will ensure that states are able to
ensure that Medicaid providers can access data that could improve their
ability to render Medicaid services effectively, efficiently, and
appropriately. The policies are expected to help states fulfill their
obligations to operate their state plans efficiently and to ensure that
Medicaid services are furnished with reasonable promptness and in a
manner consistent with the best interest of the recipients.
In addition, section 1902(a)(7) of the Act requires that states
must provide safeguards that restrict the use or disclosure of
information concerning Medicaid applicants and beneficiaries to
purposes that are directly connected with the administration of the
Medicaid state plan. The implementing regulations at 42 CFR part 431,
subpart F, for section 1902(a)(7) of the Act list purposes that CMS has
determined are

[[Page 8819]]

directly connected with administration of Medicaid state plans (42 CFR
431.302) and require states to provide safeguards meeting certain
requirements to restrict uses and disclosures of Medicaid beneficiary
data, including requirements for sharing applicant and beneficiary data
at 42 CFR 431.306.
Our finalized policy, that the data described in this section of
the final rule be shared via the Provider Access API, is consistent
with the requirement at section 1902(a)(7) of the Act, providing that
states may share these data only for purposes directly connected with
the administration of the Medicaid state plan. The Provider Access API
data sharing policy is related to providing services for Medicaid
beneficiaries, a purpose listed at 42 CFR 431.302(c). As mentioned
previously, a provider can better manage a patient's total care when
they have access to more of that patient's data because the data will
provide a more in-depth medical history, enable more informed decision
making, and potentially prevent the provision or ordering of
duplicative services. More details about how the policies will be
implemented in a manner consistent with state Medicaid requirements
under 42 CFR part 431, subpart F, are discussed in section II.B.2. of
this final rule.
Requiring states to implement a Provider Access API to share data
with enrolled Medicaid providers about certain claims, encounter, and
clinical data, including data about prior authorization decisions, for
a specific individual beneficiary, may improve states' ability to
ensure that care and services are provided in a manner consistent with
simplicity of administration, and to cover services more efficiently.
We remind states that ``enrolled Medicaid providers'' includes managed
care plan providers, per 42 CFR 438.602(b). This Provider Access API
will enable Medicaid providers to access beneficiary utilization and
authorization information from the state or managed care plan(s) prior
to an appointment or at the time of care, and that, in turn, should
enable the provider to spend more time on direct care. The policy will
support efficient and prompt delivery of care as well, which will be in
beneficiaries' best interests. These policies are also expected to give
providers better access to prior authorization decisions for care
provided by other enrolled Medicaid providers, which will give a
provider a more holistic view of a patient's care and reduce the
likelihood of ordering duplicate or misaligned services. This may also
facilitate easier and more informed decision-making by the provider and
should therefore support efficient coverage decisions in the best
interest of patients. The Provider Access API is expected to make
available a more complete picture of the patient to the provider at the
point of care, which could improve the quality and efficiency of a
patient visit. These outcome and process efficiencies may help states
fulfill their obligations to ensure prompt access to services in a
manner consistent with the best interest of beneficiaries, consistent
with sections 1902(a)(8) and (19) of the Act, and the efficiencies
created for providers might help the state administer its Medicaid
program more efficiently, consistent with section 1902(a)(4) of the
Act. These analyses apply similarly to FFS and managed care programs
and delivery systems, so we are exercising our authority to adopt
virtually identical regulatory requirements for a Provider Access API
for both Medicaid FFS programs and Medicaid managed care plans.
For CHIP, we finalized these requirements under the authority in
section 2101(a) of the Act, which states that the purpose of Title XXI
of the Act is to provide funds to states to provide child health
assistance to uninsured, low-income children in an effective and
efficient manner that is coordinated with other sources of health
benefits coverage. We believe this policy will strengthen states'
abilities to fulfill these statutory obligations in a way that will
recognize and accommodate using electronic information exchange in the
health care industry today and will facilitate a significant
improvement in the delivery of quality health care to CHIP
beneficiaries.
When providers have access to patient utilization and authorization
information from payers or other health IT systems, they may be able to
provide higher quality care. Improving the quality of care aligns with
section 2101(a) of the Act, which requires states to provide CHIP
services in an effective and efficient manner. The more information a
provider has to make informed decisions about a patient's care, the
more likely it is that patients will receive care that best meets their
needs. Additionally, providers can be more effective and efficient in
their delivery of CHIP services by having direct access to patient
utilization and authorization information. If a provider has
information about a patient prior to or at the point of care, the
provider will be able to spend more time focused on the patient, rather
than on their need to collect information. In addition, the information
providers do collect will not be based solely on patient recall. This
will save time, improve the quality of care, and increase the total
amount of direct care provided to CHIP beneficiaries. When data are
standardized, and able to be incorporated directly into the provider's
EHR or practice management system, they can be leveraged as needed at
the point of care by the provider and also can be used to support
coordination across providers and payers. This is inherently more
efficient, and, ultimately, more cost-effective, as the information
does not have to be regularly repackaged and reformatted to be shared
or used in a valuable way. As such, the Provider Access API policies
also align with section 2101(a) of the Act in that these proposals will
improve coordination between CHIP and other health coverage. For these
reasons, we believe this policy is in the best interest of the
beneficiaries and within our long-established statutory authorities.
Finally, the safeguards for applicant and beneficiary information
at 42 CFR part 431, subpart F, are also applicable to CHIP through a
cross-reference at 42 CFR 457.1110(b). More details about how the
policies could be implemented in a manner consistent with these CHIP
agencies' requirements are also discussed in section II.B.2. of this
final rule. As discussed previously for Medicaid, giving CHIP providers
access to attributed beneficiary data through the Provider Access API
is related to providing services to beneficiaries, which is described
at 42 CFR 431.302(c) as a purpose directly related to state plan
administration. We remind states that when they share beneficiary
information through the Provider Access API, they must comply with the
privacy protections at 42 CFR 457.1110 and the release of information
provisions at 42 CFR 431.306.
c. Qualified Health Plan Issuers on the Federally-Facilitated Exchanges
For QHP issuers on the FFEs, we are finalizing these new
requirements under our authority in section 1311(e)(1)(B) of the
Affordable Care Act, which affords the Exchanges the discretion to
certify QHPs if an Exchange determines that making available such
health plans through that Exchange is in the interests of qualified
individuals in the state in which the Exchange operates. We believe the
benefits will outweigh any additional burdens this might impose on
issuers. By using the finalized technologies, patients could experience
improved health, payers could see reduced costs of care, and providers
could see better compliance with care regimens. We also do not believe
that premiums will significantly increase

[[Page 8820]]

because some of the infrastructure necessary to implement the
technology has been completed to comply with the CMS Interoperability
and Patient Access final rule. Furthermore, QHP issuers on the FFEs
might combine investments and staff resources from other programs for
implementation efforts, avoiding the need to increase premiums.
We believe that certifying only health plans that make enrollees'
health information available to their providers via the Provider Access
API is generally in the interests of enrollees. Giving providers access
to their patients' information supplied by QHP issuers on the FFEs will
ensure that providers are better positioned to provide enrollees with
seamless and coordinated care and ensure that QHP enrollees on the FFEs
are not subject to duplicate testing and procedures, and delays in care
and diagnosis. Access to the patient's more complete medical
information could also maximize the efficiency of an enrollee's office
visits. We encourage SBEs, including SBE-FPs, to consider whether a
similar requirement should be applicable to QHP issuers participating
in their Exchanges.

C. Payer-to-Payer API

1. Background
Having a patient's data follow them when they change payers can
have a multitude of benefits for patient care. A payer receiving data
when a new patient enrolls can better coordinate care and make more
informed decisions. For instance, a payer can use the patient's data to
determine whether they have a chronic condition or is undergoing
current care that needs to be maintained. If necessary, patient data
can give payers the information they need to assign a case manager or
help the patient find providers in their new network. Maintaining a
corpus of data ensures that the patient and their providers do not lose
access to recent information that may be relevant to ongoing or future
care.
Furthermore, because payers usually maintain a relationship with
individual patients over time, they are uniquely positioned to collect
and aggregate a patient's record. Whereas patients may have several
providers who manage their care, they generally maintain a relationship
with only one or two concurrent payers for a full year or multiple
years. However, when a patient moves from one payer to another, both
parties may lose access to that valuable data. Data exchange among
payers, specifically, sending patient data from a patient's previous
payer to their new one, is a powerful way to ensure that data follow
patients through the health care system and improve care continuity.
Electronic data exchange between payers will support payer operations
and a patient's coverage transition to a new payer efficiently and
accurately. Sharing health care data between payers also helps care
coordination, care continuity, and allows patients to maintain access
to their record over time.
In the CMS Interoperability and Patient Access final rule (85 FR
25565), we highlighted numerous benefits of payers maintaining a
longitudinal (meaning, long-term) record of their current patients'
health information. If payers are at the center of the exchange, they
can make information available to patients and their providers and can
help a patient's information follow them as they move from provider to
provider and payer to payer.
In the CMS Interoperability and Prior Authorization proposed rule,
we proposed and, in this rule are now finalizing regulations that
require impacted payers (MA organizations, state Medicaid and CHIP FFS
programs, Medicaid managed care plans, CHIP managed care entities, and
QHP issuers on the FFEs) to implement and maintain a FHIR API to
facilitate payer to payer data exchange. We are finalizing that
proposal to require impacted payers to build a Payer-to-Payer API, with
certain standards (as further described in section II.F.), that will
facilitate patient data exchange at the start of coverage and with
concurrent payers. We proposed, and are finalizing, a patient opt in
policy for this data exchange. We proposed compliance dates in 2026 for
the Payer-to-Payer API (by January 1, 2026, for MA organizations and
state Medicaid and CHIP FFS programs; by the rating period beginning on
or after January 1, 2026, for Medicaid managed care plans and CHIP
managed care entities; and for plan years beginning on or after January
1, 2026, for QHP issuers on the FFEs). However, in response to comments
we are finalizing a modification to that proposal for the Payer-to-
Payer API to establish compliance dates in 2027 (by January 1, 2027,
for MA organizations and state Medicaid and CHIP FFS programs; by the
rating period beginning on or after January 1, 2027, for Medicaid
managed care plans and CHIP managed care entities; and for plan years
beginning on or after January 1, 2027, for QHP issuers on the FFEs).
Throughout this rule, we generally refer to these compliance dates as
``in 2027'' for the various payers. In addition, and also in response
to comments, we are finalizing a modification to our proposal to only
require impacted payers to exchange data with a date of service within
5 years of the exchange request.
To support the implementation and maintenance of the Payer-to-Payer
API, we are requiring certain standards and recommending certain IGs,
as further discussed and in section II.G. With the publication of the
HTI-1 final rule, our cross references to 45 CFR 170.215 have been
updated to reflect the updated citations as needed. Changes to the
structure of 45 CFR 170.215 and versions of the API standards codified
there are discussed further in section II.G. and reflected throughout
this final rule. For the Payer-to-Payer API, impacted payers must use
the following standards: HL7 FHIR Release 4.0.1 at 45 CFR
170.215(a)(1), US Core IG STU 3.1.1 at 45 CFR 170.215(b)(1)(i), and
Bulk Data Access IG v1.0.0: STU 1 at 45 CFR 170.215(d)(1). Impacted
payers are permitted to use updated standards, specifications, or IGs
that are not yet adopted in regulation for the APIs required in this
final rule, should certain conditions be met. For the standards at 45
CFR 170.215, updated versions available for use under our policy
include, but are not limited to, US Core IG STU 6.1.0 and the Bulk Data
Access IG v2.0.0: STU 2, which have been approved for the ONC Health IT
Certification Program.\76\ We refer readers to policies finalized for
the Patient Access API in the Interoperability and Patient Access final
rule, as well as section II.G.2.c. of this final rule for a full
discussion on using updated standards. We also recommend payers use the
CARIN IG for Blue Button STU 2.0.0, PDex IG STU 2.0.0, and SMART App
Launch IG Release 2.0.0 to support Backend Services Authorization. We
refer readers to Table H3 for a full list of the required standards and
recommended IGs to support API implementation.
---------------------------------------------------------------------------

\76\ 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.
---------------------------------------------------------------------------

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

[[Page 8821]]

coverage with and thus the payer responsible for sending the data to
the new payer.
Our payer to payer data exchange requirements discussed in this
section involve transactions and cooperation between payers, which may
include payers that are not subject to the requirements in this rule.
We emphasize that each impacted payer is responsible only for its own
side of the transaction. For instance, when an impacted payer is
required to request patient data from another payer, it will have to do
so regardless of whether the other payer is an impacted payer (a status
that may or may not be evident to the requesting payer). Similarly, if
an impacted payer receives a request for patient data that meets all
the requirements, the impacted payer must share those data, regardless
of whether the requesting payer is an impacted payer (which, again, may
or may not be evident to the payer sharing the data). In this way,
payers not subject to this regulation that implement a Payer-to-Payer
API (or other IT functionality to request or receive information
through the impacted payer's API) and their patients can also benefit
from the data exchange.
We are exploring steps for Medicare FFS to participate in payer to
payer data exchange and we encourage other payers that are not subject
to these requirements to do the same. We intend to implement the Payer-
to-Payer API capabilities for Medicare FFS in conformance with the
requirements for impacted payers, as feasible. In the proposed rule, we
sought comment on whether our proposals could be implemented as
proposed for the Medicare FFS program, how we could apply each of the
proposals, and whether there would be any differences for implementing
the Payer-to-Payer API in the Medicare FFS program as a Federal payer.
We summarize the comments received and our responses in section I.D. of
this final rule. We strongly encourage all payers that are not subject
to the requirements of this rule to consider the value of implementing
a Payer-to-Payer API, so that all patients, providers, and payers in
the U.S. health care system may experience the benefits of such data
exchange.
Comment: Many commenters supported our proposal to require data
exchange via a Payer-to-Payer API. Commenters stressed the benefits to
patients of maintaining an ongoing record when they change payers,
which could result in better patient outcomes, especially for patients
with chronic conditions. Commenters agreed that this API would improve
interoperability, data exchange, and reduce administrative burden.
Multiple commenters stated that the Payer-to-Payer API would be
especially helpful to patients with concurrent coverage. A commenter
stated that the assignment of primary care physicians could also be
facilitated by the Payer-to-Payer API and that this could reduce care
disruptions when changing payers. Another commenter acknowledged that
investments made in payer to payer data exchange would benefit broader
multi-payer alignment efforts, which are a key priority for improving
quality, access, and value in health care. Another commenter stated
that exchanging patient data from previous and concurrent payers would
eliminate duplicative medical record requests from payers requiring
providers to reapprove medical necessity, retry step therapy
requirements, and reauthorize treatments.
Response: We appreciate commenters validating our statements in the
proposed rule regarding the benefits of payer to payer data exchange.
We agree that the benefits of payer to payer data exchange include both
ensuring care continuity and that patients, providers, and future
payers do not lose access to important health information. We are
finalizing, with modification, the Payer-to-Payer API proposals as
discussed in this section.
Comment: Multiple commenters opposed finalizing our Payer-to-Payer
API proposals. They disagreed with our justification that payers should
be the maintainers of a patient's longitudinal data. Another commenter
cautioned that, as proposed, the Payer-to-Payer API would require
payers to share a large amount of unnecessary data, which would make it
difficult to effectively coordinate care. Instead, they suggested that
by leveraging the Patient Access API, patients should have the
responsibility to maintain their patient data using an app, or other
solution of their choice. A commenter recommended that CMS separate the
goal of creating longitudinal consumer health records from the goal of
supporting consumer transitions between payers.
Response: After reviewing comments, we agree that patients are in
the best position to manage their health information, especially with
the growing ecosystem of health apps and the availability of
standardized Patient Access APIs. Some HIEs and health apps (which may
also be TEFCA Participants and Subparticipants) may be able to gather
data from payers, providers, and other sources to create a more
comprehensive patient record than could be maintained by a payer.
However, payers are uniquely positioned to collect and aggregate
patient data, especially during coverage transitions. As we noted,
patients may have several providers who manage their care, but they
generally maintain a relationship with only one or two concurrent
payers for a full year or multiple years. A payer to payer data
exchange can facilitate care continuity by providing access to
information about past treatments when a patient is moving from one
payer to another. For example, that information could show payers that
a patient has already demonstrated medical necessity or engaged in step
therapy, which could ease the approval of a prior authorization
request. Ensuring that payers have timely access to newly enrolled
patients' data upon a patient transitioning payers can have a multitude
of benefits for patient care leading to better-coordinated care, more
informed decision-making, and minimize disruption in ongoing care.
Therefore, to mitigate potential burden on impacted payers, while still
establishing the Payer-to-Payer API as a means to support the creation
and availability of a longitudinal record, as discussed, we are
finalizing a modification to our proposal to only require payers to
exchange data with a date of service within 5 years of the request.
That modification means that payers will not be responsible for
exchanging and maintaining a patient's entire health history dating to
January 1, 2016.
Comment: Multiple commenters did not support the proposed Payer-to-
Payer API and suggested alternatives to gain the intended benefits. A
commenter noted that there are many industry solutions already being
developed to facilitate the coordination of benefits between payers and
recommended CMS continue to monitor and enable technical innovation in
this area. Another commenter cautioned CMS to not view FHIR as the sole
solution to interoperability and patient data exchange challenges. The
commenter noted that as proposed, payers would experience challenges if
FHIR failed to reach widespread adoption and maturity. Another
commenter stated that requiring the FHIR standard eliminates choice and
leads to bias and further stated that other options may be better
suited for a payer.
Response: We thank the commenters for their suggestions, but FHIR
APIs are the standard that the industry indicated has the greatest
maturity and hence has been adopted by ONC. A variety of solutions will
not lead to

[[Page 8822]]

interoperability across the healthcare system. While payers already
have processes in place for coordinating benefits, that coordination
does not extend to transitions of care between payers, such as
maintaining prior authorizations. Data exchange between payers can
ensure that valuable patient information is not lost, such as prior
authorization requests and approvals, which could make that transition
more seamless. Requiring FHIR will get the healthcare industry to a
more interoperable state, as that standard supports health data
exchange in a standard, structured, but flexible format that can
continue to advance and mature. Impacted payers are already required to
use the FHIR standard for the Patient Access and Provider Directory
APIs, and this final rule is meant to build on this existing policy.
Also, we are extending the compliance dates for the Payer-to-Payer API
to 2027. This delay to the compliance dates versus our proposal allows
for additional time for implementation and IGs to be refined and
matured to support the policies in this final rule.
Comment: Multiple commenters expressed concern regarding payer
access to patient data. They worried that this could lead to patient
risk profiling, increased prior authorization requirements, increased
premiums and limits on coverage and access to care. They recommended
that CMS prohibit impacted payers from using information sent from a
previous payer to discriminate against a patient. A commenter stated
that CMS should implement safeguards to ensure that the payer to payer
data exchange does not encourage payers to make care decisions based on
the patient's record. The commenter recommended that CMS explain that
the provider is the director of medical care, and payers support the
patient's care through payment and coverage of services. They suggested
that large-scale consumer data exchange should be consumer-mediated and
result in meaningful access to comprehensive data for care coordination
among payers.
Response: We agree with the commenters that patient information
should not be used in an inappropriate manner. We remind payers that
section 1852(b) of the Act states that an MA plan may not deny, limit,
or condition the coverage or provision of benefits based on any health
status-related factor described in section 2702(a)(1) of the Public
Health Service Act.\77\ Section 2705(a)(1) of the Public Health Service
Act, which applies to QHP issuers on the FFEs, prohibits discrimination
against individuals based on their health status-related factors.
Similarly, section 2102(b)(1)(B)(ii) of the Act prohibits CHIP programs
from denying eligibility for children with preexisting conditions.
Finally, the overarching regulations at 45 CFR part 92 implementing
section 1557 of the Affordable Care Act prohibit discrimination under
any health program or activity receiving Federal financial assistance
on the basis of race, color, national origin, sex, age, or disability.
---------------------------------------------------------------------------

\77\ Section 2702 of the Public Health Service Act referenced in
section 1852(b) of the Act refers to what is now codified as section
2705 of the Public Health Service Act.
---------------------------------------------------------------------------

Comment: Multiple commenters suggested that implementation of a
Payer-to-Payer API may increase provider burden with unintended
downstream effects. A commenter discussed how the Payer-to-Payer API
could lead to a negative impact on providers who may be required to
ingest large amounts of data if payers maintain a longitudinal record
back to January 1, 2016, that is also shared via the Provider Access
API.
Response: Our modification to require impacted payers to exchange
only 5 years of data via the Payer-to-Payer API will mitigate this
possible issue for providers. By circumscribing the data to be
exchanged by payers to only more recent data, providers are less likely
to receive distant and irrelevant historical data via the Provider
Access API. We acknowledge that not all of a patient's health
information is going to be equally relevant to a particular provider.
Therefore, providers should look for clinically relevant information
and work with their EHR vendors on solutions to easily display the
information most relevant to their practice. We discuss this issue is
greater depth in section II.B.2.c.
Comment: A commenter questioned the utility of the Payer-to-Payer
API if payers other than impacted payers do not voluntarily adopt the
technology and processes to share data.
Response: We appreciate commenters supporting Payer to Payer
adoption by payers other than impacted payers. We strongly encourage
all payers not subject to these provisions to consider the value of
implementing a Payer-to-Payer API, so that all patients, providers, and
payers in the U.S. health care system may ultimately experience the
benefits of such data exchange. Even though not every payer may
participate in it, our Payer-to-Payer API policy can benefit the
millions of Americans covered by impacted payers. We specifically
encourage impacted payers that have other lines of business to adopt
the policies in this final rule for their commercial plans that are not
subject to the requirements of this rule.
Comment: A commenter recommended that CMS work with ONC and
industry stakeholders to develop a longer-term FHIR roadmap, including
patient-centric data homes that efficiently and effectively collect,
storage, and integrate information from across the health system on
behalf of a patient. Another commenter recommended that CMS work with
the DoD and the VA to implement Payer-to-Payer APIs.
Response: We appreciate the support for our Payer-to-Payer API
policies and will continue to work with other Federal agencies to
improve interoperability across the health care system.
Comment: Many commenters recommended delaying the Payer-to-Payer
API compliance dates to give payers more time to design, develop, test
and implement their systems. Some commenters recommended a January 1,
2027, compliance date, and another commenter recommended 4 years after
the publication of the final rule, to give industry time to align on a
standardized implementation approach. A few commenters suggested CMS
delay compliance dates until IGs are mature enough to adopt as required
standards, or to allow payers to adopt Payer-to-Payer API on a
voluntary or pilot basis. Some commenters suggested CMS set rolling
compliance dates and the Payer-to-Payer API should be prioritized after
the Prior Authorization API. Several commenters specifically
recommended that CMS to delay the compliance dates for state Medicaid
agencies to implement a consistent solution at enrollment. A commenter
requested that CMS accelerate the compliance dates to 2024. Another
commenter urged CMS to consider the added cost and burden for payers to
meet the proposed compliance dates.
Response: Because we understand that the payer implementation
process is significant, after reviewing the comments, we are finalizing
a modification to our proposal for the Payer-to-Payer API, to establish
compliance dates in 2027 (by January 1, 2027, for MA organizations and
state Medicaid and CHIP FFS programs; by the rating period beginning on
or after January 1, 2027, for Medicaid managed care plans and CHIP
managed care entities; and for plan years beginning on or after January
1, 2027, for QHP issuers on the FFEs). However, as discussed in

[[Page 8823]]

section I.D.2., we decline to delay beyond that because of the
importance of payer to payer data exchange. Establishing regulatory
compliance dates will provide greater urgency to test and mature the
evolving technical standards and IGs. When we proposed to require the
relevant IGs in our December 2020 CMS Interoperability proposed rule,
we received many comments that those standards were not mature enough
to feasibly implement at that time. In response, we proposed in this
rulemaking to only recommend (rather than require) the IGs for
standardized implementation. After consideration of the comments we
received in response to the CMS Interoperability and Prior
Authorization proposed rule, we are finalizing those IGs as
recommendations because it is prudent to move forward to attain the
policy goals of the Payer-to-Payer API, even while those standards are
being developed to achieve true interoperability. Moving to a 2027
compliance dates will give the industry an extra year to refine those
IGs and for payers to implement their technical solutions.
With regard to the requests for additional time for Medicaid
programs specifically, we refer readers to section II.E.2.a. of this
final rule where we finalize our proposals to create a process for
Medicaid and CHIP FFS programs to request and be granted an extension
to the compliance dates for the Payer-to-Payer API.
2. Proposal To Rescind the CMS Interoperability and Patient Access
Final Rule Payer to Payer Data Exchange Policy
We strongly believe that data exchange among payers is a powerful
way to improve information sharing that would allow patients and
providers to have more complete access to health information, which can
help to promote better patient care. Patients may wish for their health
information to follow with them when they change payers, in part so
that they can track the services they have received, and to ensure that
a new payer has information to better assist with continuity of that
care. However, given the concerns raised by stakeholders regarding the
lack of technical specification in our previously finalized policy, we
proposed to rescind the payer to payer data exchange policy finalized
in the CMS Interoperability and Patient Access rule (85 FR 25568) at 42
CFR 422.119(f)(1) and 438.62(b)(1)(vi) and (vii) and 45 CFR
156.221(f)(1). We did so to prevent industry from developing multiple
systems, and to help payers avoid the costs of developing non-
standardized, non-API systems, and the challenges associated with those
systems. We proposed a new policy that would, instead, require impacted
payers to implement and maintain a Payer-to-Payer API using the FHIR
standard. We stated that using FHIR APIs would ensure greater
uniformity and ultimately lead to payers having more complete
information available to share with patients and providers.
Comment: Commenters supported CMS's proposal to rescind and replace
the Payer-to-Payer API requirements finalized in the CMS
Interoperability and Patient Access rule (85 FR 25568). They agreed
that the proposals would help standardize data exchange and avoid
developing duplicative systems. Multiple commenters strongly supported
the newly proposed FHIR API approach and noted that this API would
leverage the same standards as the Patient Access and Provider Access
APIs. A commenter highlighted how CMS's proposal to replace the payer
to payer data exchange addressed a key concern held by the industry
about the lack of specificity in the previous policy. Another commenter
stated that they welcomed the elimination of provider remittances and
cost-sharing information from the required data content.
Response: We appreciate commenters support and are finalizing our
rescission of the previous policy.
We note that we are correcting a technical error in this final rule
for the Payer-to-Payer API requirements in Medicaid managed care. When
we proposed to remove the requirement at 42 CFR 438.62(b)(1)(vi) and
(vii) and instead use a cross reference to 42 CFR 431.61(b)(1) at Sec.
438.242(b)(7), we inadvertently neglected to properly revise 42 CFR
438.9 to continue excluding NEMT PAHPs from the Payer-to-Payer API
requirements. When the payer to payer data exchange requirements were
finalized in the CMS Interoperability and Patient Access rule (85 FR
25568) at Sec. 438.62(b)(1)(vi) and (vii), NEMT PAHPs were
automatically excluded as 42 CFR 438.62 is not applicable to NEMT
PAHPs. However, by moving the Payer-to-Payer API requirements to Sec.
438.242(b)(7), the requirements would apply to NEMT PAHPs (at 42 CFR
438.9(b)(7)). As we explained when we proposed to exclude NEMT PAHPs
from the Provider Access API (87 FR 76258), we believed that the unique
nature and limited scope of the services provided by NEMT PAHPs, in
that they only cover transportation and not medical care itself,
justified their exclusion from the requirements of the Provider Access
API. Similarly, we do not believe that other payers have a routine need
for NEMT data; therefore, requiring NEMT PAHPs to implement and
maintain a Payer-to-Payer API would be an undue burden on them. It
would also be a burden on other Medicaid payers concurrently covering a
patient to receive NEMT data quarterly as required at 42 CFR
431.61(b)(5). To correct this oversight, we are finalizing 42 CFR
438.9(b)(7) to exclude the requirement at Sec. 438.242(b)(7), which is
to comply with Sec. 431.61(a) and (b).
Comment: A commenter supported our proposal to rescind the previous
requirements but urged us not to finalize our new Payer-to-Payer API
proposals, because many of the technical standards are still undergoing
development and refinement and operational processes have not been
established by payers. The commenter suggested that CMS should consider
establishing a voluntary payer to payer data exchange policy.
Response: We acknowledge that any new requirement is going to have
operational challenges that need to be resolved. Technical standards
have substantially developed over the past 3 years since we issued the
December 2020 CMS Interoperability proposed rule (85 FR 82586). We
refer readers to sections II.G.3.a. and II.G.3.b. of this rule for
additional discussion on enhancements to both the required and
recommended IGs published since the publication of the CMS
Interoperability and Prior Authorization proposed rule. For example,
the recently published PDex IG STU 2.0.0 specification now includes a
Prior Authorization profile that enables payers to communicate prior
authorization requests and decisions. We are extending our compliance
dates for the Payer-to-Payer API from our proposed 2026 to 2027 in
order to provide additional time for stakeholders, and specifically
payers, to address those barriers to implementation.
3. Payer to Payer Data Exchange on FHIR
a. Payer-to-Payer API Technical Standards
In the CMS Interoperability and Patient Access final rule we
finalized a requirement that impacted payers must implement, maintain,
and use a Patient Access API conformant with 45 CFR 170.215. However,
we did not require payers to use an API or specific standards for payer
to payer data exchange in that final rule.
In the CMS Interoperability and Prior Authorization proposed rule,
we

[[Page 8824]]

proposed an API-based payer to payer data exchange utilizing standards
and technology similar to that of the Patient Access API. The degree of
overlap between the requirements for the Patient Access API (discussed
in section II.A.2. of the proposed rule) and the Provider Access API
(discussed in section II.B.2. of the proposed rule) should ease the
development and implementation of the Payer-to-Payer API for payers.
The Patient Access API will provide the foundation to share
adjudicated claims and encounter data, all data classes and data
elements included in a standard adopted at 45 CFR 170.213 (USCDI), as
well as certain information about prior authorizations. Because, as of
January 1, 2021, the same adjudicated claims and encounter data, and
all data classes and data elements included in the standard at 45 CFR
170.213 are already required for the Patient Access API, payers should
have already formatted these categories of data and prepared their
systems to share these standardized data via a FHIR API. As a result,
payers have already devoted the development resources to stand up a
FHIR API infrastructure when they implemented the Patient Access API,
which could be adapted for additional interoperability use cases.
We proposed that, beginning January 1, 2026 (for Medicaid managed
care plans and CHIP managed care entities, by the rating period
beginning on or after January 1, 2026, and for QHP issuers on the FFEs,
for plan years beginning on or after January 1, 2026), impacted payers
must implement and maintain a Payer-to-Payer API that is conformant
with the same technical standards, documentation requirements, and
denial or discontinuation policies as the Patient Access API.
We proposed to require certain standards adopted under 45 CFR
170.215 that are applicable to the Payer-to-Payer API. We are
finalizing our proposals for the Payer-to-Payer API with modifications,
requiring impacted payers to use the following standards: HL7 FHIR
Release 4.0.1 at 45 CFR 170.215(a)(1), US Core IG at 45 CFR
170.215(b)(1)(i), and Bulk Data Access IG at 45 CFR 170.215(d)(1). We
also recommend payers use the CARIN IG for Blue Button STU 2.0.0, PDex
IG STU 2.0.0, and SMART App Launch IG Release 2.0.0 to support Backend
Services Authorization. We proposed but are not finalizing to require
impacted payers to use SMART App Launch IG and OpenID Connect Core for
reasons discussed later in this section. We refer readers to Table H3
for a full list of the required standards and recommended IGs to
support API implementation. We refer readers to section II.G. of this
final rule for further discussion of the required and recommended
technical standards for the Payer-to-Payer API.
One operational difference between the Patient Access and Payer-to-
Payer APIs is that payers may find it more efficient to share data for
multiple patients at a time. It is likely that impacted payers with a
fixed enrollment period will have many patients' data to share at one
time, especially if other payers share that enrollment period (such as
QHPs offered on an FFE). In such a situation, it could require
significant time and resources for payers to send each patient's data
individually through an API. The Bulk Data Access IG for exchanging
multiple patients' data at once has been adopted by ONC at 45 CFR
170.215(d)(1), which is discussed further in section II.F. of this
final rule and is a standard we proposed to require for the Payer-to-
Payer API.
We requested comments on these proposals. We received multiple
comments regarding technical implementation challenges and the maturity
of the recommended IGs, which are addressed in section II.G. of this
final rule. Here we respond to the comments specific to the standards
and IGs for implementing the Payer-to-Payer API.
Comment: Multiple commenters stated their support for the proposed
FHIR standard and recommended IGs for the Payer-to-Payer API. Multiple
commenters stated that the FHIR standard will ultimately prevent issues
with data sharing across payers and allow information to be shared
accurately and timely. Many commenters gave their support for our
proposal that the Payer-to-Payer API must be conformant with the
standards at 45 CFR 170.215, including support for the Bulk Data Access
IG and OpenID Connect Core. Some commenters agreed with not requiring
payers to use the CARIN IG for Blue Button or HL7 Da Vinci IGs.
Additionally, other commenters explained that universally implementing
FHIR would define how health care information is shared, but will have
no impact on how data are collected or stored. Multiple commenters
stated their support for requiring Payer-to-Payer APIs to use the same
standards as the other interoperability APIs. A commenter stated that
leveraging the same standards and IGs will support efficient
implementation. Another commenter stated that the lack of standards has
been one of the barriers to achieving data fluidity between payers.
Response: We thank commenters for their support of the proposed
standards and recommended IGs for the Payer-to-Payer API and agree that
the using standards will support more efficient data sharing. Requiring
impacted payers to use the same standards and IGs will support
consistent implementation and improve interoperability across health
care. We note that for the Payer-to-Payer API, we are finalizing a
modification to our proposal by not requiring the SMART App Launch IG
at 45 CFR 170.215(c) and OpenID Connect Core at 45 CFR 170.215(e)(1),
as discussed further in section II.C.3.d.iii. of this final rule.
Protocols requiring user level credentials managed by the payer, such
as those used with OpenID Connect Core, are generally not appropriate
for business-to-business data exchanges like the Payer-to-Payer API
where a particular individual may not be directly initiating the
exchange.
Comment: Some commenters who supported the proposal that the Payer-
to-Payer API must be conformant with FHIR at 45 CFR 170.215(a)(1)
identified concerns with implementation. Multiple commenters agreed
with the approach to require the FHIR standard for Payer-to-Payer APIs,
but some commenters noted that the standard has not been widely
demonstrated in production by industry stakeholders. A commenter stated
that payers will need to create workflows to process exchanges,
incorporate received data into local records, and troubleshoot any
issues. A commenter recommended that CMS allow 1 to 2 years to
implement new standards depending on complexity. The commenter
encouraged data transfer standards be backward compatible.
Response: We agree that implementing new standards takes time and
appreciate the commenter recommending we allow 1 to 2 years. However,
technology and standards are ever evolving and will never remain static
for the period it would take the entire industry to implement. To
address comments about the time necessary for implementation, we are
delaying the compliance dates for the Payer-to-Payer API to 2027, which
will give implementers approximately 3 years from the publication of
this final rule. Public comment has broadly indicated that the proposed
standards will be sufficiently mature for implementation by that
deadline. We will continue working with HL7, the FHIR accelerators, and
industry stakeholders to define, to participate in and convene testing
events, and to develop and maintain the specifications, which moves
them towards greater

[[Page 8825]]

maturity. Specifically, the PDex IG has been tested, implemented, and
based on industry standard consensus, is ready for use. We acknowledge
that the standards discussed in this rule will continue to mature to
enhance functionality and meet additional use cases. We expect that
future rulemaking by CMS and ONC will be necessary to keep pace with
the latest technical innovations. While the technology may never be
``done,'' commenters indicated that the standards available today are
sufficiently mature to facilitate 2027 compliance dates for the
policies in this final rule that require API development or
enhancement.
We acknowledge that, as with any standard, potential compatibility
issues could arise through the further development of those
specifications. We discuss IG maturity further in section II.G.3.b. of
this final rule. These standards are subject to a standards development
process where changes are reviewed and compatibility is an important
consideration, increasingly so with the level of adoption and use. As
the IGs mature, the number of potential compatibility issues between
versions is expected to decrease.
Comment: Multiple commenters recommended that CMS name specific IG
versions and standards as a baseline for the Payer-to-Payer API and
create a formal standard version advancement process similar to the ONC
Standards Version Advancement Process (SVAP). A commenter noted that an
established SVAP would give the industry and HL7 the opportunity to
continue refining and testing standards and IGs to ensure consistent
implementation. A commenter recommended that CMS ensure that the
applicable Payer-to-Payer API technical standards remain current as new
versions become available. Multiple commenters specifically stated
their concern for endpoint compatibility and recommended that CMS
create required standards so that payers do not need to make one-off
modifications to accommodate slightly different APIs.
Response: In the proposed rule, we stated that we believed the
approach of recommending, but not requiring, specific versions of the
IGs would provide directional guidance without locking implementers
into the versions of the recommended IGs available at the time of the
proposed rule. To not recommend any specific IGs would have meant a
more diverse set of proprietary solutions with little to no
interoperability. Our recommendations have allowed the IG authors and
community to receive feedback from real-world use and to further mature
and refine the IGs. Certification and testing of these APIs could help
avoid implementation variation and will consider ways for CMS to
support such testing in the future. In addition, by using the
recommended IGs, implementers can ensure that their APIs are compatible
and conformant to the requirements. As the standards continue to
mature, we will consider whether to propose requiring additional IGs
through rulemaking.
Comment: A commenter stated that the proposed IGs are dependent on
an outdated network authentication protocol and recommended using the
HL7[supreg] FHIR[supreg] Da Vinci Health Record Exchange (HRex) IG,
which leverages UDAP for authentication. Another commenter simply
recommended utilizing UDAP for authentication. Another commenter
recommended CMS modify the standards and IGs to adequately capture the
Payer-to-Payer API requirements. The commenter stated that CMS should
support the development of content and technical standards for prior
authorization decisions that can be incorporated into the appropriate
IGs for testing.
Response: We acknowledge that there is no single security protocol
approach that will address all use cases. Additionally, within a single
API, implementers may need to utilize more than one protocol to address
specific population and trading partner needs. As discussed in section
II.C.3.d.iii. of this final rule, we are finalizing a modification to
our proposal to not require the OpenID Connect Core and SMART App
Launch IG standards for the Payer-to-Payer API. We recognize that
methods such as SMART Backend Services (which is included in the SMART
App Launch IG v2), mTLS, UDAP, or other trust community specified means
may be appropriate depending on the needs. We refer readers to Table H3
in this final rule for an updated finalized list of all required and
recommended IGs for the Payer-to-Payer API. We will continue to work
with ONC to advance the versions of the standards that ONC adopts at 45
CFR 170.215. We will continue to monitor the development UDAP and other
trust community specified solutions that could support the Payer-to-
Payer API authentication process. We also note that ONC has adopted
SMART Release 2.0.0 at 45 CFR 170.215(c)(2) and while we are not
requiring the SMART App Launch IG for the Payer-to-Payer API, we do
recommend using SMART Backend Services.
Comment: A commenter expressed support for maturing the PDex IG and
noted that the IG still needs more testing for specific use cases.
Another commenter suggested that CMS not finalize the Payer-to-Payer
API until it works with HL7 to diminish the costs with the PDex IG. The
commenter noted that in the PDex IG, the patient would be responsible
for manually executing the data exchange using a third-party app and
then transmitting that information to a new payer. Another commenter
stated that the IGs identified for the payer to payer data exchange
include the capability for two methods (member-mediated and member-
directed), which would cause confusion and redundancy. The commenter
stated that the member-directed solution would potentially give the new
payer access to financial information meant to be available only to the
patient.
Response: The PDex IG provides multiple data exchange methods. One
method allows a member to directly authorize data being sent to a third
party. While this method could be utilized for payer to payer
interactions, it is not the primary method defined by the PDex IG for
that use case. For the Payer-to-Payer API use case, the PDex IG
provides guidance for supporting exchanges that do not require direct
member engagement. The PDex IG STU 2.0.0, which is being recommended
for the Payer-to-Payer API in this rule, can facilitate on the payer to
payer exchange by defining a means for the requesting payer to send a
record of the patient's opt in to retrieve data from the other payer.
This method does not require patient action through OAuth and is the
method we recommend for payer to payer data exchanges. While we
recognize that the PDex IG utilizes mTLS for payer authentication, we
are not requiring that protocol and recognize that other methods, such
as SMART Backend Services, UDAP, or other trust community specified
means, may be appropriate and easier to implement at scale. Payers will
be able to choose the protocols or combination of protocols they deem
appropriate as long as they meet the applicable security and privacy
requirements.
Comment: Multiple commenters had concerns regarding FHIR due to the
lack of mature HL7 FHIR IGs and recommended that CMS instead advance
payer to payer data exchange by leveraging the TEFCA QHINs. A few
commenters recommended that CMS address the need for a legal governance
framework for payer to payer data exchange. A commenter recommended
that CMS work with ONC and the TEFCA RCE to incorporate the payer to
payer data exchange use case into TEFCA's planned support for payment
and operations exchange. The

[[Page 8826]]

commenter also recommended that CMS allow payers to comply with the
Payer-to-Payer API requirements by participating in TEFCA.
Response: We agree with the commenter that TEFCA can provide an
efficient vehicle to query, send, and receive standardized electronic
health information (EHI) from a broad array of participants enabling
payer to payer data exchange. While standards and IGs for using FHIR
within a network like TEFCA are still maturing, the FHIR Roadmap for
TEFCA Exchange outlines the path for implementation. In addition, ONC
and the RCE are currently developing the requirements in Common
Agreement Version 2.0 for FHIR-based exchange under TEFCA across
Exchange Purposes, including for Payment and Operations. ONC is aiming
to publish Common Agreement Version 2.0 in the first quarter of 2024.
To the extent that the requirements of this rule can be met through
TEFCA exchange by the compliance dates, payers are permitted to do so.
However, as there are methods for exchanging data under TEFCA that do
not comply with the standards requirements we are finalizing (such as
exchanging information using a method other than a FHIR API),
participation in TEFCA, including exchanging the required data, does
not necessarily mean that the payer is meeting the requirements of this
rule.
We note that payer to payer data exchange is legally required under
this final rule and as such, legal agreements are not required.
However, we understand that some payers may still request legal
agreements. CMS is also working closely with ONC to explore how TEFCA
could potentially be leveraged to support scalable governance for payer
to payer exchange.
Comment: Multiple commenters expressed support for CMS requiring
the Bulk Data Access IG. A commenter stated that this IG was designed
to exchange population level data to allow payers and providers to
analyze care using the tools of ``big data'' analytics and for bulk
information exchange between payers and providers for populations
covered under value-based arrangements. A commenter stated it is
critical to pace mandates with the development and adoption of
standards and that the Bulk Data Access IG is not finalized or adopted
by HHS. Another commenter stated that while the Bulk Data Access IG is
the correct specification for transferring large amounts of data
between two payers, the IG is still evolving. A commenter highlighted
that the Bulk Data Access IG will require additional development
efforts for their organizations since it is new. Another commenter
stated that the Bulk Data Access IG does not include aspects that are
relevant to the Payer-to-Payer API.
Response: In the ONC Cures Act final rule HHS adopted the Bulk Data
Access IG at 45 CFR 170.215(d)(1). In the CMS Interoperability and
Patient Access final rule (85 FR 25510), we finalized a requirement to
implement, maintain, and use API technology conformant with the
standards at 45 CFR 170.215, which includes the Bulk Data Access IG. In
this final rule, we are finalizing standards applicable for each API.
Bulk data exchanges are usually used for system-to-system use cases and
allow large volumes of information on a group of individuals to be
shared in one exchange, which could be useful for sharing data between
payers. Therefore, we feel that the Bulk Data Access IG is relevant for
the Payer-to-Payer API and is being finalized as proposed.
Comment: Multiple commenters recommended blockchain based
technologies be used for the payer to payer data exchange. A commenter
recommended that CMS support and evaluate blockchain-based technologies
for the payer to payer data exchange and recommended that there needs
to be confidence in the ability of blockchain-based technologies to
leverage APIs for associated data movement. Another commenter
recommended that CMS retain regulatory flexibility to enable future
data exchange opportunities, including the potential for permissioned
on-chain PHI access rather than an API call and response model.
Response: We acknowledge that there are a range of technologies
that may facilitate interoperability. In conjunction with ONC, we are
working to establish standards that result from the work of SDOs and
have been generally agreed upon by the industry through consensus-based
processes. Blockchain technologies do not meet those criteria at this
time, but we will continue to monitor evolving technologies and their
possible benefits for interoperability. In the meantime, we are not
prohibiting payers from using blockchain technology if they are doing
so in a way that meets their legal requirements.
Comment: Some commenters stated that payers, especially state
Medicaid and CHIP agencies, would need technical assistance with
implementing the Payer-to-Payer API. Multiple commenters stated that
payers could use HIEs to implement the Payer-to-Payer API requirements,
including the opt in process, which would reduce the burden on payers.
Response: CMS has hosted, and intends to host in the future, CMS
and HL7 FHIR Connectathons, which are free for stakeholders to attend,
as well as provide educational webinars providing overviews of the
technical requirements set forth in the interoperability rules.
Additional public resources also exist through HL7, such as HL7 FHIR
Connectathons, HL7 website resources and HL7 FHIR workgroup meetings.
We understand that some payers may have implementation challenges and
one of the reasons we are finalizing 2027 compliance dates is to give
impacted payers additional time to prepare and test any new processes
they may need to implement.
To the extent that it reduces burden, we encourage payers to
partner with HIEs or HINs, especially those operating under TEFCA, to
facilitate payer to payer data exchange, subject any other applicable
laws governing privacy and disclosure of these data. Some HIEs may
already have the technical framework to manage patient consent or
engage in standardized data exchange via FHIR APIs in ways that
existing payer systems do not. Nothing in this rule would prohibit an
impacted payer from partnering with an HIE to meet its requirements.
For instance, as HIEs may have access to clinical data from providers
that payers do not, some impacted payers may want to contract with an
HIE to host their required API, either as their repository for clinical
data, or as an intermediary with the payer's own systems. The HIE could
then augment payer data with other clinical data they have access to in
order to enhance the data available to via the Patient Access, Provider
Access, and Payer-to-Payer APIs, subject to other applicable law.
Comment: A commenter cautioned that CMS's proposals could result in
each payer building their own API, and each payer pulling data from
every other payer within a state. A commenter stated that it is not
feasible for every clearinghouse to maintain so many non-standard
connections, and to do so would be costly and risky. The commenter
stressed the urgency to implement a National Data Warehouse Exchange
Hub/Clearinghouse.
Response: Impacted payers will not have to maintain non-standard
connections for this payer to payer data exchange, as we are requiring
impacted payers to use a FHIR API to support interoperable
implementations. We are requiring impacted payers to use the same
standards specifically so that connections between payers do not need
to be ``hard coded'' but can rely on the

[[Page 8827]]

same technical standards to connect to any other payer's endpoint.
There is no requirement to use a clearinghouse, but to the extent it
could benefit payers, we encourage them to leverage HIEs or HINs.
Comment: A commenter recommended that CMS resolve the technological
infrastructure dependencies by further investing in the HL7 FAST
Accelerator and ONC's work to facilitate patient matching and support
implementation of the HL7 FAST Accelerator solutions to enable scaled
exchange through FHIR APIs. Another commenter recommended that CMS
collaborate with ONC to encourage industry adoption of the solutions
outlined by the HL7 FAST Accelerator, at minimum, identity resolution,
security, and directory for the Payer-to-Payer API.
Response: We will continue to work closely with ONC on the FAST
Accelerator and will seek to leverage any appropriate solutions being
developed as part of this work. We are also committed to continuing to
work with HL7, the Accelerators, and interested parties within the
industry in defining, participating in, and convening testing events,
as well as developing and maintaining the specifications, thereby
moving them toward greater maturity and will adopt solutions as
appropriate to our use cases as they mature.
b. Payer-to-Payer API Data Content Requirements
i. Data Content
We proposed to require impacted payers to implement and maintain a
Payer-to-Payer API to exchange claims and encounter data (excluding
provider remittances and patient cost-sharing information), all data
classes and data elements included in a content standard at 45 CFR
170.213 (USCDI), and certain information about prior authorizations
that the payer maintains with a date of service on or after January 1,
2016. As stated in the proposed rule (87 FR 76255), this set of data is
consistent with requirements for the Patient Access API finalized in
the CMS Interoperability and Patient Access final rule (85 FR 2555) and
our proposals for the Patient Access and Provider Access APIs. Using
the same data content standards across the APIs in this final rule adds
efficiencies for payers and maximizes the value of the work that has
already been done, reducing the overall burden for impacted payers.
In response to comments, we are finalizing our proposal, with
modifications. We are modifying the data content by excluding data
related to denied prior authorizations. In addition, we are also
finalizing a modification by only requiring impacted payers to exchange
data with a date of service within 5 years of the request.
Comment: Many commenters expressed that using the same January 1,
2016, start date for the set of data that must be exchanged via the
Payer-to-Payer API would include significant historical data that are
unlikely to be relevant to a patient's current health status and
ongoing care. Those commenters urged us to establish a rolling period
of time to the date of the exchange for the data content that must be
shared. Some commenters pointed out that the technical and operational
level of effort to integrate a patient's full history would impose
significant data storage and archival costs on payers. Some commenters
disagreed with CMS's justification for the proposal that payers were
the appropriate maintainer of a patient's complete health history and
suggested that while payers had a role to play, patient apps could be a
more efficient, effective and reliable method to meet that objective.
Response: While we continue to support and emphasize the benefits
of payer to payer data exchange, we also recognize the burden of
exchanging and storing large amounts of complex patient data. There are
two main benefits for Payer-to-Payer API data exchange: to facilitate
care continuity when a patient changes payers and to maintain the
patient's record so that relevant information is not lost. After
consideration of the comments, we agree that requiring impacted payers
to exchange a patient's entire history back to the proposed January 1,
2016, date would impose a significant burden on payers to integrate and
maintain those data. In effort to balance the benefits we described in
the proposed rule, which were supported by commenters, and the burden
that some commenters raised, we are finalizing a modification to our
proposal to limit the payer to payer data exchange to only the previous
5 years of data.
As described previously, solutions are emerging in the marketplace
for Personal Health Records (PHR) that are better suited to keeping
patient records for an indefinite period than payers, which might
themselves maintain limited clinical data. ONC defines a PHR as an
electronic application through which patients can maintain and manage
their health information (and that of others for whom they are
authorized) in a private, secure, and confidential environment.\78\ For
instance, health apps can create a longitudinal record by gathering
data both from payers via the Patient Access API, and providers' CEHRT.
Even so, it is still important for patient care and continuity for a
patient's new payer to receive and maintain some recent historical
record of the patient's care. When a patient changes payers, only the
information that the current payer maintains would be available via the
Patient Access, Provider Access and Payer-to-Payer APIs.
---------------------------------------------------------------------------

\78\ Office of the National Coordinator for Health Information
Technology (2016, May 2). Frequently Asked Questions. Retrieved from
https://www.healthit.gov/faq/what-personal-health-record.
---------------------------------------------------------------------------

As payers and providers will have a more robust infrastructure for
data exchange (including via the FHIR APIs required in this final
rule), they are better suited to enable data exchange to providers and
between payers than a patient would be with their PHR. A patient could
supplement information that their payer maintains with information from
their PHR, but should not have the primary responsibility for ensuring
the technical capability to send their records.
For continuity of ongoing care, we expect that the more recent data
are, the more relevant they generally would be. Therefore, it is
important to establish a period of time that is reasonably likely to
include information relevant to foreseeable care after a patient
changes payers. While many commenters suggested shortening the
timeframe for data to be exchanged, we did not receive comments
suggesting a specific period. Five years balances the needs to manage
care continuity and establish a patient record with their new payer
while not being overly burdensome on payers to exchange and maintain a
large amount of data that may not be relevant. Being able to keep the
most recent 5 years of data when transitioning between payers will
cover the vast majority of a patient's ongoing and future healthcare
needs. Even for patients with chronic conditions, data older than 5
years are unlikely to have significant relevance or value when more
recent information is available. This amount of data sharing strikes
the right balance of limiting the burden to payers, while still reaping
the benefits of care coordination and continuity and allowing patients
to maintain a significant amount of data with their current payer.
However, we disagree with commenters who suggested limiting the
data exchange to a shorter period to focus only on current health
conditions and ongoing care. We do not want to

[[Page 8828]]

narrow the scope of data to be exchanged to focus simply on care
continuity. Health information that is not relevant at the time a
patient changes payers may later be important for the patient or their
providers to have access to. Beyond the care continuity justification
for payer to payer data exchange, making a reasonable amount of patient
data available, even if it is not the patient's full record, is still
an important goal of this policy. For these reasons, and to better
balance the burden on payers and benefit to patients, we are finalizing
a modification to our proposal to only require the most recent 5 years
of data be exchanged between impacted payers. We will monitor the
Payer-to-Payer API implementation and usage to determine whether to
extend this timeframe in the future.
For some patients, those 5 years of data may still comprise a
significant quantity. However, the data content requirements for the
Payer-to-Payer API are built on structured data standards, such as the
data classes and data elements included in a content standard at 45 CFR
170.213 (USCDI), which should be easily ingested using the recommended
IGs. The exception to that structured data is administrative and
clinical documentation submitted by providers related to prior
authorization requests and decisions, as discussed later in this
section of this final rule. We encourage impacted payers to review the
PDex IG for guidance on ingesting patient data in a structured manner
that creates a useable patient record.\79\ We also note that CMS will
continue to work closely with ONC and other Federal agencies to improve
data interoperability through initiatives such as the USCDI+.
---------------------------------------------------------------------------

\79\ Health Level Seven International (2023, October 28). Da
Vinci Payer Data Exchange. Retrieved from https://build.fhir.org/ig/HL7/davinci-epdx/.
---------------------------------------------------------------------------

Comment: Multiple commenters recommended narrowing the scope of
data that would be exchanged via the Payer-to-Payer API. Some
commenters suggested that CMS narrow the scope of information required
to be exchanged to specific data that would facilitate a change in
coverage. Other commenters recommended that CMS only require a minimum
set of information necessary to facilitate a patient's transition and
improve care coordination. Some commenters recommended that CMS work
with industry stakeholders to determine a subset of key coverage,
clinical, demographic, claims, and encounter information to share via
the payer to payer data exchange to support coverage transitions.
Another commenter expressed that the data exchange should be limited to
claims data and prior authorization decisions.
Response: We disagree with the view that the information sent via a
Payer-to-Payer API should be limited to a minimum set of data that
would facilitate transition between payers and continuity of ongoing
care. While care continuity is one purpose of the Payer-to-Payer API,
there are use cases that benefit from additional information being
sent. Specifically, we proposed to include claims, encounter data and
clinical data to maintain the availability of those data for the
Patient Access and Provider Access APIs after a patient changes payers.
We acknowledge that a patient's historical data may not be directly
relevant to a patient's care at the time of transition. However, that
does not mean that a patient or provider would never have a reason to
access those data. While the payer to payer data exchange has its use
cases, the Patient Access and Provider Access APIs have additional use
cases. Therefore, it is important to consider not just how a payer
would use data received from a previous payer, but how patients and
providers may use it as well. A patient should not lose access to their
recent claims, encounter, or clinical data from their payer because
they are not strictly necessary to facilitate the transition to a new
payer. As discussed, we are finalizing a modification to our proposal
to limit the data to be sent to that with a date of service within 5
years of the request.
Comment: Multiple commenters provided recommendations regarding
clinical data to be exchanged. Some commenters stated that clinical
information is not stored in a sharable format for the Payer-to-Payer
API. Specifically, a commenter discussed how current technology cannot
adequately parse through large, non-standardized files. The commenter
noted that clinical information sent by providers to payers is not
received, structured, or stored in a way to be shared, as the X12 275
transaction standard for healthcare claims attachments has not been
finalized (though a standard has been proposed in the HIPAA Standards
for Healthcare Attachments proposed rule (87 FR 78438)). In addition, a
commenter recommended that CMS work with ONC to implement a requirement
that providers share comprehensive clinical data in a FHIR enabled
format with patients and payers. Another commenter recommended that CMS
remove the requirement that impacted payers share all clinical
information in USCDI and focus on the clinical information that has
been received in standard, electronic structured format related to
prior authorization. A commenter asked CMS to explain whether impacted
payers only need to make available via the API the USCDI data classes
and data elements that they currently maintain.
Response: We acknowledge that not all information that we are
requiring to be made available through the Payer-to-Payer API will be
stored and maintained in a structured data format within the payers'
systems. However, the benefits of ensuring that a patient's data follow
them to a subsequent payer outweigh the burden of exchanging that
information. In many circumstances, clinical information can be
significantly more informative than claims or encounter information.
For example, claims for laboratory tests will not provide the actual
results of those laboratory tests, which is more important than simply
knowing that laboratory tests were done without knowing what the
results were. However, we know that many payers do not maintain
clinical data, or only maintain specific sets of clinical data and
therefore claims and encounter information can fill gaps that would
otherwise be missing.
Our data content requirements for the Payer-to-Payer API are built
on the existing requirements for the Patient Access API. The set of
clinical information that we have required to be available via the
Patient Access API since January 1, 2021, is defined by the USCDI
standard at 45 CFR 170.213. As discussed in section II.A.2.d. of this
final rule, for clarity we are changing the regulatory text to point
directly to the USCDI standard at 45 CFR 170.213 for the Patient Access
API, as well as the new Provider Access and Payer-to-Payer APIs.
Therefore, to the extent a payer maintains those data, the data classes
and data elements in USCDI should already be in payers' systems in a
form that makes them available via a FHIR API. Because payers should
already have experience making that set of information available, there
should not be a significant burden to make the same underlying data
available through multiple APIs. Henceforth, with our revisions to
directly reference the content standard at 45 CFR 170.213, the Patient
Access, Provider Access, and Payer-to-Payer APIs will all be required
to include all data classes and data elements within that content
standard that are maintained by the payer.
We are not adding any requirements in this final rule that would
require payers to parse and convert

[[Page 8829]]

unstructured files into structured data, either for their own records
or to share via the APIs. We also expect that as standards are adopted
across the industry, an increasing percentage of clinical data will be
stored and transmitted in structured formats, which is a result we
encourage. We note, however, that unstructured administrative and
clinical documentation submitted by a provider to support a prior
authorization request (excluding those for drugs and those that were
denied) are required to be sent through the Payer-to-Payer API.
Comment: A commenter recommended that the patient's choice whether
to opt into the Payer-to-Payer API be part of the data exchanged.
Response: That piece of information is required as part of the
attestation of patient opt in and is discussed in more detail in
section II.C.3.d.iv. of this final rule. If a patient does not opt in,
there would be no payer to payer data exchange under these
requirements.
Comment: A commenter recommended that CMS reduce the quantity of
data that needs to be exchanged by not requiring that denied claims be
exchanged between payers.
Response: While some denied claims may be extraneous (such as a
claim denied because it is a duplicate), they may contain important
information about a patient that would be beneficial to their record. A
claim, even if it is denied, can indicate that a patient received items
or services, even if the claim was not paid. Denied claims are also
included in the information that is currently required to be available
via the Patient Access API (85 FR 25532). We did not propose, nor are
we finalizing, to exclude denied claims from the Payer-to-Payer API (or
the Provider Access API). However, as discussed in section
II.C.3.b.iii., we are excluding denied prior authorization requests
from the set of information that must be exchanged between payers.
Unlike claims, a denied prior authorization request does not indicate
that the patient actually received items or services and therefore an
exclusion is justified, as discussed.
Comment: Multiple commenters stated that payers have already
formatted the necessary data elements and prepared their systems to
share the standardized data through other FHIR APIs. A commenter noted
that this infrastructure can be adapted for expanded interoperability
use cases, such as the Payer-to-Payer API. However, another commenter
believed that barriers to implementing FHIR APIs exist in the way of
process siloes in payer organizations.
Response: We appreciate the confirmation that payers have already
formatted the necessary data elements to be shared through other FHIR
APIs, particularly the Patient Access API. We agree that infrastructure
can be adapted for this Payer-to-Payer API and are requiring the same
data classes and data elements already required for the Patient Access
API. Payers have already formatted these data elements and prepared
their systems to share these standardized data via a FHIR API. We note
that the Payer-to-Payer API data content requirement also includes both
structured and unstructured administrative and clinical documentation
submitted by providers related to prior authorizations, of which the
unstructured documentation is not required to be shared through the
Patient Access and Provider Access APIs. We also agree that payers have
already devoted the development resources to standing up a FHIR API
infrastructure when they implemented the Patient Access API, which
could be adapted for expanded interoperability use cases. Using the
recommended IGs will reduce implementation barriers and we encourage
payers to get involved in the HL7 FHIR workgroups and to collaborate
with other payer organizations on these API implementations. In
addition, we are delaying the compliance dates to 2027 rather than the
proposed 2026 not just to give payers time to implement the technical
requirements, but also to address any internal business process changes
that may be necessary.
ii. Provider Remittances and Patient Cost-Sharing
We proposed to exclude provider remittances and patient cost-
sharing information from the Payer-to-Payer API because that
information is often considered proprietary by payers. While there
could be value to patients having provider remittances and patient
cost-sharing information available via the Patient Access API,
exchanging those data between payers would have only a limited
beneficial impact on care. We believed that information about provider
remittances and patient cost-sharing under another payer would have no
impact on a payer's ability to ensure care continuity when a patient
changes payers. Furthermore, there are existing processes for
coordinating payment when a patient has concurrent payers that we did
not wish to affect. Sharing claims and encounter information, even
without these cost details, would complement the data classes and data
elements included in a content standard at 45 CFR 170.213 (USCDI), by
providing more information about the patient's care history to support
care coordination and efficient operation.
Comment: Multiple commenters supported the exclusion of provider
remittances and patient cost-sharing information from the data shared
through the payer to payer data exchange. However, a few commenters
noted that this policy could create additional development work if
payers need to segment data elements to make provider remittances and
patient cost-sharing information available via the Patient Access API,
but not the Payer-to-Payer API (or Provider Access API).
Response: We acknowledge that segmenting data could create
additional burden for payers. However, as discussed in the proposed
rule, we proposed to not require provider remittances and patient cost-
sharing information be included in the data shared via the Payer-to-
Payer API because payers may consider that information proprietary. We
agree that cost information would have limited benefits to care
continuity when a patient changes payers. However, as our policy to
exclude that information is intended to protect the payer's proprietary
information, we are not prohibiting payers from sending it. Therefore,
if a payer believes that implementing their Payer-to-Payer API in such
a way that includes provider remittances and patient cost-sharing
information would reduce burden, they are not prohibited from doing so.
iii. Prior Authorization Data
We refer readers to section II.A.2.a. of this final rule where we
discuss in more detail how prior authorization data must be available
through the Patient Access API--and therefore through the other APIs as
well. Our proposals to include prior authorization data in the Payer-
to-Payer API mirrored our proposals to include prior authorization data
in the Patient Access and Provider Access APIs. We stated that it would
be valuable for payers to make certain information about prior
authorizations available via the Payer-to-Payer API, particularly when
a patient enrolls with a new payer. Prior authorization data can inform
a payer about ongoing treatments. Payers can use that information to
determine whether a new patient needs a new prior authorization, and,
if so, whether the information from the previous payer is sufficient
for them to issue a decision without additional work by the patient or
provider. Prior authorization is a significant focus of this final rule
as a whole, and information about these requests and decisions could be
beneficial to

[[Page 8830]]

patients, providers, and payers. As discussed in more detail in section
I.D., this final rule does not apply to any prior authorization
processes or standards related to any drugs.
We discuss prior authorization and prior authorization processes in
more depth in section II.D. of this final rule. We proposed to add
certain information about prior authorizations to the set of data that
impacted payers must make available via the Payer-to-Payer API upon
request from another payer. We proposed that the information must
include:
The status of the prior authorization;
The date the prior authorization was approved;
The date or circumstance under which the authorization
ends;
The items and services approved;
The quantity used to date; and
Related administrative and clinical documentation.
Comment: Many commenters generally supported including prior
authorization information in the Payer-to-Payer API and stated that
this would increase transparency, improve care coordination, and reduce
burden on providers, patients, and payers. Commenters stated that
including prior authorization data in the Payer-to-Payer API would
protect beneficiaries' access to necessary items and services since
information on prior authorization is not always transferred when
beneficiaries switch coverage today. A commenter stated that prior
authorization information would enable the new payer to provide
continuous coverage for existing treatments and highlighted that this
is especially important for patients receiving cancer treatment and
specific medications after progressing through step therapies. Multiple
commenters expressed support for sharing historical data to increase
payer knowledge of previous patient prior authorization decisions and
health care data, and to encourage continuity of care.
Response: We appreciate commenters concurring on the importance of
previous payers sharing authorization data. The prior authorization
process is a priority area for us to reduce patient and provider
burden.
Comment: Multiple commenters recommended that some types of prior
authorization data should be excluded from the Payer-to-Payer API. A
few commenters suggested that CMS not require impacted payers to
include information about prior authorizations without fully
understanding how payers could use that information. Commenters
specifically recommended that CMS exclude information about previously
denied prior authorizations. A commenter noted that this might be used
to limit care for patients, even if they meet the new payer's criteria
for the same service. Conversely, another commenter noted that there is
some benefit to patients and providers having a basic history of denied
prior authorization requests.
Response: After considering the comments we received, we are
removing the requirement to include denied prior authorization
decisions in the Payer-to-Payer API. However, we note that supporting
clinical information associated with such decision may be available
under the requirement to share all data classes and data elements
included in the data content standard at 45 CFR 170.213 (USCDI) that
are maintained by the payer. As discussed previously, we are focusing
on the aspects of payer to payer data exchange that relate to care
continuity when a patient changes payers. Because a previously denied
prior authorization decision generally would not reflect ongoing
treatment, and thus the information may not support care continuity,
the value of including such information would likely be outweighed by
the drawbacks of doing so. A denied prior authorization decision does
not provide information about the patient's ongoing care because it
does not show that patients received any items or services. If a
patient did receive those items or services despite the denial of
coverage, that information would have to be gathered from elsewhere
(such as clinical data), regardless of whether the payer receives
information about the denied prior authorization decision. However, we
emphasize that denied prior authorization decisions are required to be
shared via the Patient Access and Provider Access APIs because the
benefits to those parties of accessing that information can be
significant, especially for resubmitting requests or appealing
decisions.
However, this information could be used in ways that would
negatively impact a patient's care or coverage. For example,
information about a denied prior authorization decision could
potentially create bias in future prior authorization decisions with
the new payer, and patients could experience challenges to obtain
coverage for a given service. Even if a previously denied prior
authorization does not in fact create bias with the new payer, some
patients may fear that result, which could lead to fewer patients
opting in to payer to payer data exchange.
Comment: Several commenters recommended not including the quantity
of services used to date due to the concern that health plan claims
data updates are often delayed and, therefore, may not be a reliable
source to track the number of authorized services used to date. A
commenter recommended that CMS require only the authorized units of
items and services for a specific prior authorization, rather than the
items and services used under the authorization.
Response: Upon reviewing comments, we agree with the many
commenters who pointed out that the authorized services used to date
under a prior authorization may be more confusing than useful for
patients and providers. We heard that the quantity used to date would
only be available based on claims that have been submitted and
adjudicated for those items or services. Because there can be a
significant lag between the items or services being provided and the
claim being adjudicated, the information available through the APIs
could be out-of-date and inaccurate. Therefore, we are finalizing a
modification to our proposal that will not require payers to share the
number of items or services used under the authorization. We are also
finalizing a modification to our proposals that this information does
not need to be included in the Patient Access API (discussed in section
II.A.2.a.ii. of this final rule) or the Provider Access API (discussed
in section II.B.2.g. of this final rule).
Comment: Several commenters encouraged CMS to include unstructured
documentation and forms that were submitted as part of a prior
authorization request. Some payers commented that making that
documentation available via the Payer-to-Payer API will facilitate
their ability to make prior authorization decisions for a new patients
without requesting duplicative information be submitted. Commenters
stated that unlike in the Patient Access and Provider Access APIs,
sharing supporting documentation through the Payer-to-Payer API could
allow the new payer to use that information to make decisions about
subsequent prior authorizations, if required. A few commenters held the
opposing view that CMS should not finalize requirements to include
clinical documentation and forms with prior authorization information
via the Payer-to-Payer API.
Response: We are finalizing a modification to our proposal for the
Patient Access and Provider Access APIs to remove the proposed
requirement to make available unstructured administrative and clinical
documentation. We have concluded that

[[Page 8831]]

for these APIs, the burden outweighs the benefit. However, that is not
the case for the Payer-to-Payer API. One of the goals of this
regulation and the Payer-to-Payer API requirement is to promote greater
continuity of care when patients change payers, especially regarding
prior authorization. In order for payers to ease that transition, they
need as much relevant data related to recent and ongoing care as
possible. For instance, current data can allow a payer to authorize
coverage for ongoing treatment, without requiring repeat testing or
needing a provider to resubmit clinical information that the provider
has already submitted to a previous payer.
In addition, the concerns regarding payers' ability to quickly make
the unstructured administrative and clinical documentation available,
via the Patient Access and Provider Access APIs, do not apply to the
Payer-to-Payer API. Under our Patient Access and Provider Access API
policies, payers have 1 business day from the time they receive the
prior authorization request or there is another status update to make
prior authorization information available. For the Payer-to-Payer API,
absent a specific patient request, typically payers only have to
exchange data at the time a patient changes payers, or quarterly for
concurrent payers. Therefore, unless a prior authorization request is
submitted within the last days of coverage, payers will have a longer
timeframe to ensure that unstructured documentation is included in the
patient's record and can be transferred to another payer when the need
or requirement to transfer data through the Payer-to-Payer API arises.
Furthermore, the concern about a patient app or provider's EHR not
being able to read and display unstructured documentation does not
apply to payers, which regularly receive unstructured administrative
and clinical documentation with prior authorization requests.
Comment: A commenter suggested that given the complexity and
variation across prior authorizations, any pertinent data from peer-to-
peer reviews should be included in Payer-to-Payer API exchange.
Response: Based on comments and conversations with payers, we
understand that many payers consider the specific criteria they use to
make prior authorization decisions to be proprietary information. In
addition, because payers have different criteria, information about
internal peer reviews of prior authorization requests from another
payer has only limited usefulness. Therefore, we are not requiring
payers to exchange any documentation that the payer itself generates
regarding a peer-to-peer review of a prior authorization request. But
we are requiring impacted payers exchange structured and unstructured
administrative and clinical documentation submitted by providers
related to prior authorizations to assist care continuity and allow
payers to make their own decisions based on the patient's specific
needs without requiring duplicative submissions from a provider.
iv. Duration of Prior Authorization Data to be Exchanged
We proposed that impacted payers would be required to make certain
information about prior authorizations available via the Payer-to-Payer
API for the duration that the authorization is active and for at least
1 year after the prior authorization's last status change. We proposed
to require the availability of prior authorization information for at
least 1 year after any status change across the Patient Access,
Provider Access and Payer-to-Payer APIs, so that information from
denied and expired prior authorizations would not be lost when they
were not approved or no longer active.
Comment: Many commenters supported CMS's proposal that certain
information about prior authorizations be available for the duration of
an active authorization and for at least 1 year after the last status
change. Some commenters were in favor of retaining a patient's
historical prior authorization data indefinitely. Another commenter
requested clarification on how the proposal to make prior authorization
data available for at least 1 year would align with the requirement
that impacted payers make available patient data with a date of service
on or after January 1, 2016.
Response: As discussed previously, we are finalizing a modification
to our proposal that will not require denied prior authorization
requests to be shared via the Payer-to-Payer API at all. Such
information must be shared through the Patient Access and Provider
Access APIs beginning in 2027 (see sections II.A.2.ii. and II.B.2.g. of
this final rule for more information). We note that the requirement to
share patient data with a data of service on or after January 1, 2016,
comes from the CMS Interoperability and Patient Access final rule,
which required claims, encounter information and certain clinical data
to be made available via the Patient Access API. Prior authorization
information was not included in that rule, and therefore, we do not
have reason to believe that payers are generally maintaining prior
authorization data back to that date. In addition, the obligation to
share encounter, claims, or other information from within 5 years of
the request is contingent on the payer maintaining those data; for
payers that are not required to maintain records past a certain point
or that do not have internal policies for retaining records past a
certain time period, the data may not be available to be shared through
the Patient Access API. As discussed in the proposed rule, the
availability of claims and clinical data are more important to patient
care than information about prior authorizations that have expired.
Claims and encounter data indicate items and services that the patient
actually received in the course of their care. Information from a prior
authorization indicates whether certain items and services were
approved for coverage, and often the basis for that decision. While
active or recent prior authorization information is important because
it can indicate current or recent medical necessity, such information
cannot be inferred from prior authorizations that have been expired for
more than 1 year as they would not indicate any sort of ongoing care.
Claims and clinical data maintained by the previous payer that are
related to the treatment that occurred under an expired prior
authorization would replace the need for the expired prior
authorization decision itself. While claims and clinical data
associated with an expired prior authorization can indicate the type of
care received, as discussed earlier in this section, the value to a new
payer of prior authorizations that were not acted upon, meaning they do
not have a claim or any clinical data associated with them and are not
associated with any past treatment or active care for the patient, is
outweighed by the potential drawbacks of including such information. We
also considered comments summarized previously and also discussed in
sections II.A. and II.B. of this final rule regarding the inclusion of
these data in the Patient Access and Provider Access APIs. While some
API content differences may be beneficial or practical (such as the
exclusion of provider remittances and patient cost-sharing
information), we are keeping the API requirements as similar as
possible to reduce burden by standardizing data content. We emphasize
that for ongoing long-term care, any active prior authorizations must
be included, even if they have been in that status for more than 1
year. Furthermore, our policy allows payers to make these prior
authorization data available for longer

[[Page 8832]]

than 1 year, if they believe it adds value to patients, providers,
themselves or future payers.
v. Considering Prior Authorizations From Another Payer
While we did not propose to require payers to review, consider, or
honor the active prior authorization decision of a patient's former
payer, payers may gain efficiencies by doing so. We sought comment on
the benefits, burdens and considerations of imposing such a
requirement. However, we did not make any proposals and therefore are
not finalizing any policies in this area. We do note that since we
published the proposed rule, the Medicare Program; Contract Year 2024
Policy and Technical Changes to the Medicare Advantage Program,
Medicare Prescription Drug Benefit Program, Medicare Cost Plan Program,
and Programs of All-Inclusive Care for the Elderly final rule (CY 2024
MA and Part D final rule) was issued, which requires MA coordinated
care plans to provide a minimum 90-day transition period when an
enrollee switches to a new MA organization, during which the new MA
organization may not require prior authorization for an active course
of treatment.
Comment: A commenter requested clarification about the relationship
between this final rule and the provision for MA plans at 42 CFR
422.112(b)(8)(i)(B) added by the CY 2024 MA and Part D final rule. That
rule requires MA coordinated care plans to provide a minimum 90-day
transition period when an enrollee switches to a new MA organization
during which the new MA organization may not require prior
authorization for an active course of treatment.
Response: The requirements at 42 CFR 422.112(b)(8) adopted in that
recent final rule apply to Part A and B benefits covered by an MA plan.
An ``active course of treatment'' is defined at 42 CFR
422.112(b)(8)(ii) as a course of treatment in which a patient is
actively seeing a provider and following a ``course of treatment,''
which is defined as a prescribed order or ordered course of treatment
for a specific individual with a specific condition, outlined and
decided upon ahead of time with the patient and provider. A patient can
have an active course of treatment to which 42 CFR 422.112(b)(8) will
apply that did not require prior authorization by their previous payer.
Per 42 CFR 422.112(b)(8)(i)(B), MA organizations offering
coordinated care plans must have, as part of their arrangements with
contracted providers, policies for using prior authorization that
provide for a minimum 90-day transition period for any active course(s)
of treatment when an enrollee has enrolled in an MA coordinated care
plan, even if the course of treatment was for a service that commenced
with an out-of-network provider. Further, the MA plan cannot deny
coverage of such active courses of treatment on the basis that the
active course of treatment did not receive prior authorization (or was
furnished by an out-of-network provider) but may review the services
furnished against the MA plan's coverage criteria when determining
payment. This includes enrollees who are new to an MA plan, an enrollee
switching from Traditional Medicare to MA, or enrollees new to Medicare
and enrolling in an MA plan for the first time.
In that final rule, we explained how we expect any active course of
treatment to be documented in the enrollee's medical records so that
the enrollee, provider, and MA plan can track an active course of
treatment to avoid disputes over the scope of the new requirement.
Therefore, an active course of treatment should be included in the data
exchanged between impacted payers, regardless of whether a previous
payer required a prior authorization. Under this final rule, the data
content that must be shared via the Payer-to-Payer API includes the
claims and encounter data (excluding provider remittances and cost-
sharing data), all data classes and data elements included in a content
standard at 45 CFR 170.213 and certain information about prior
authorizations maintained by the payer with a date of service within 5
years of the request. Almost any active course would be represented
within that dataset. Any active course of treatment covered by 42 CFR
422.112(b)(8)(i)(B) will thereby become part of the patient's record
with their new payer. It is important, especially in light of 42 CFR
422.112(b)(8), that MA enrollees are aware that their active course of
treatment is being honored and for how long. That will allow MA
enrollees in plans subject to this new requirement, and their
providers, to plan for a new prior authorization request, if necessary.
Although this particular need for access to information about
active courses of treatment is unique to MA enrollees in MA coordinated
care plans, the data exchange and Payer-to-Payer API requirements
outlined here are applicable to any impacted payer. While we encourage
other payers to honor an active course of treatment similar to the
requirements of 42 CFR 422.112(b)(8) for MA coordinated care plans, we
have not proposed to require that of any payers not covered by that
rule.

c. Identifying Previous and Concurrent Payers and Opt In

i. Process Timing
We proposed that all impacted payers develop and maintain processes
to identify a patient's previous/concurrent payer(s) and to allow
patients or their personal representatives to opt into the payer to
payer data exchange (both with previous and concurrent payers) prior to
the start of coverage. Additionally, we proposed that impacted payers
would be required to establish similar processes for current patients
prior to the compliance dates, to ensure those patients have the
ability to opt in and have their data shared through the API. We are
finalizing a modification to this proposal, as discussed, to establish
a deadline for these processes at 1 week after the start of coverage
(as that term is defined for each program).
We emphasized in the proposed rule that obtaining a patient's opt
in permission and identifying the previous/concurrent payer(s) could
not delay an applicant's eligibility determination or start of coverage
with any impacted payer. We noted that the proposed requirement to
identify a patient's previous/concurrent payer(s) and obtain a
patient's opt in may not always be feasible before the start of
coverage, for instance, if a patient does not provide enough
information to identify their previous payer. We emphasized that payers
must begin this process before the start of coverage, but realize that
it may take longer than enrollment. In that case, the impacted payer
would be required to continue to engage with the patient to gather
their permission and identify any previous/concurrent payer(s). Only
once the impacted payer has received permission and identified those
other payers would they be required to request patient data, as
outlined in sections II.C.3.c.ii. and II.C.3.c.iv. of this final rule.
Using Medicaid as an example, if a state has all the information
necessary to determine an individual's eligibility before it has
identified the previous payer, the state must determine the
individual's eligibility and enroll the individual in Medicaid
coverage, if determined eligible, while continuing to follow the Payer-
to-Payer API requirements as expeditiously as possible post-enrollment.
For new patients enrolling on or after the compliance dates, we
proposed to require impacted payers to maintain a process for patients
to opt into the Payer-to-Payer API data exchange and to

[[Page 8833]]

identify their previous/concurrent payer(s) prior to the start of their
coverage. In section II.C.4.b. of this final rule, we discuss the
possible incorporation of these requirements into state applications
for Medicaid or CHIP eligibility. In the proposed rule, we stated that
making this process available to patients during the enrollment
process, or immediately thereafter, would allow the proposed data
exchange to take place as quickly as possible once the patient is
enrolled with the new payer. For example, where there may not be
communication during the enrollment process such as during the QHP
enrollment on the FFEs, this process should be done immediately
following enrollment. We solicited comment on incorporating the
proposed requirements into the FFE QHP enrollment process as described
at 45 CFR 156.265.
Concurrent coverage means that an individual has coverage provided
by two or more payers at the same time. This could include, for
example, individuals dually eligible for Medicare and Medicaid who are
enrolled in both an MA plan and a Medicaid managed care plan. Another
example of concurrent coverage is when different services are covered
by different Medicaid managed care plans for the same Medicaid
beneficiary.
Several payer deadlines in this rule are based on a patient's
``start of coverage.'' For example, we proposed (and are finalizing) a
requirement for impacted payers to request previous and concurrent
payer information and a patient's opt in for Payer-to-Payer API data
exchange (discussed in section II.C.3.c.iv. of this final rule) no
later than 1 week after the start of coverage. Throughout the preamble,
we are using the term ``start of coverage'' to mean when coverage
begins or, if coverage begins retroactively, to refer to a later
milestone, depending on the payer type. However, to ensure feasible
timeframes for new patients after the compliance dates, we are
finalizing deadlines based on whether coverage starts prospectively or
retroactively. Where coverage starts prospectively, the deadline will
be based on the coverage start date (also known as the coverage
effective date). In the case of retroactive coverage, to avoid a
deadline in the past, the deadline for the payer to provide the
required information about the Payer-to-Payer API, request identifying
information about previous/concurrent payer(s), and an opt in will be
based on the date that the payer gets patient information and makes the
patient's coverage effective.
Because the enrollment and coverage initiation processes for each
program differ in their specifics, in regulation text, the concept of
``start of coverage'' is described differently for each type of
impacted payer. That is, the regulatory text uses different, program-
appropriate terminology for each impacted payer.
For MA organizations, the ``start of coverage'' generally means the
effective date of coverage, as used at 42 CFR 422.68. In some
instances, an individual's enrollment may be accepted by CMS with a
retroactive effective date of coverage, as discussed in the Medicare
Managed Care Manual, Chapter 2, section 60.4.\80\ In those cases, the
``start of coverage'' would be the date that the individual's
enrollment is accepted by CMS.\81\ Effectively, this means that the
``start of coverage'' is whichever is the later of those two dates--the
effective date of coverage or the date that the individual's enrollment
is accepted by CMS.
---------------------------------------------------------------------------

\80\ Centers for Medicare and Medicaid Services (2011, August
19). Medicare Managed Care Manual. Retrieved from https://www.cms.gov/files/document/cy-2024-ma-enrollment-and-disenrollment-guidance.pdf.
\81\ See also Medicare Managed Care Manual, Chapter 2, section
40.4.2. for similar enrollee notification requirements tied to the
date that the individual's enrollment is accepted by CMS.
---------------------------------------------------------------------------

For example, an MA organization that receives an enrollment request
from an individual that is accepted by CMS in January for a February 1
effective date of coverage, would have 1 week from February 1 to
complete the applicable requirements. An MA organization that receives
an enrollment request from an individual in January that is accepted by
CMS on February 7 for a retroactive February 1 effective date of
coverage, would have 1 week from February 7 (not February 1) to
complete the applicable requirements as finalized in this rule.
For Medicaid, a beneficiary's coverage is generally retroactive 3
months from the date that they are enrolled in Medicaid. For CHIP,
retroactive coverage varies among states. Therefore, for Medicaid and
CHIP FFS and managed care, the ``start of coverage'' is simply the date
the beneficiary is enrolled in the state's MMIS (or equivalent
process), not the date coverage takes retroactive effect.
For QHP issuers on the FFEs, the start of coverage is generally the
enrollee's QHP coverage start date. In some cases, a payer may provide
coverage retroactively, that is, a payer provides coverage starting on
a date prior to enrollment, for instance due to the birth, adoption, or
foster care placement of a new child. In that case, the ``start of
coverage'' would be the effectuation of coverage, as described at 45
CFR 155.400(e)(1)(iii). Effectively, this means the ``start of
coverage'' is whichever is the later of those two dates--either the
coverage start date or the effectuation of coverage. We refer to the
coverage start date as the first date for which the enrollee has
coverage and the term ``effectuation of coverage'' to refer to the date
that the payer takes the steps to implement coverage, even if that
coverage starts retroactively.
For example, an FFE QHP issuer that receives enrollee information
during an annual open enrollment period for a consumer whose coverage
will start on January 1 of the following year would have 1 week from
the enrollee's coverage start date of January 1 to complete applicable
requirements. An issuer that receives information and effectuates
coverage on March 6 for an enrollee whose coverage starts retroactively
on February 1 would have a week from the enrollee's effectuation date,
March 6 (not February 1), to complete the applicable requirements.
Comment: Multiple commenters expressed concern regarding processes
for opting in and collecting previous/concurrent payer data occurring
at the start of coverage, noting logistical challenges to collecting
data at the time of a patient's enrollment, including document format
and regulatory challenges to updating existing enrollment forms.
Multiple commenters provided recommendations regarding actions for
payers to take at the time of enrollment to facilitate collecting this
information, such as defining specific data and updating enrollment
forms.
In addition, multiple commenters stated that payers should be
permitted to collect a patient's opt in after enrollment. A commenter
specifically recommended that collection should be allowed during the
first month of active enrollment. Some commenters urged CMS to not
require payers to collect data at enrollment to support the Payer-to-
Payer API, and instead to allow outreach to patients after enrollment
through existing tools, such as payer portals. Another commenter stated
that requesting that information at the time of the patient's
application would allow them to incorporate the process into their
existing data collection processes. A commenter noted that the
inability to opt in after the enrollment start date could result in low
participation rates. Another commenter supported allowing patients to
opt into data sharing during the open enrollment period. A commenter
supported allowing a payer to collect a patient's opt in prior to the
compliance dates for state Medicaid and CHIP agencies and prior to
enrollment

[[Page 8834]]

of new beneficiaries after the compliance dates.
Response: We note that the terms used in the preamble and
regulation text of our proposed rule were different. Our discussions in
the proposed rule referred to ``prior to the start of coverage,'' which
we explained in preamble and fully discussed throughout the proposed
rule, but the proposed regulation text used the phrase ``at
enrollment'' (except for QHP issuers on the FFEs where we used ``no
later than the effectuation of enrollment''). We did not propose that
new payers collect previous payer information at the time of
enrollment. We stated that payers must begin the process of collecting
the previous payer information and opt in prior to the start of
coverage, but that it may take longer than the enrollment process. We
are modifying the regulatory text to identify the start of coverage
(rather than enrollment) as the milestone that tolls these
requirements, consistent with the preamble discussion in the proposed
rule.
However, in response to public comments, we are finalizing a
modification to our proposal by extending the deadline for both
requesting identifying information about a patient's previous/
concurrent payer(s) and seeking opt in from the patient to 1 week after
the start of coverage, with certain differences among payers. For MA
organizations, we are modifying the deadline to no later than 1 week
after the coverage start date or no later than 1 week after receiving
acceptance of enrollment from CMS, whichever is later. In the case of
Medicaid and CHIP FFS, we are modifying both deadlines to refer to 1
week after enrollment, to avoid confusion related to the retroactive
eligibility rules in Medicaid. For QHP issuers on the FFEs, we are
modifying the requirement to no later than 1 week after the after the
coverage start date or no later than 1 week after the effectuation of
coverage, whichever is later. Commenters were clear that establishing
the start of coverage as the deadline for these actions would result in
logistical challenges and compliance would be difficult for impacted
payers. We understand that while some types of impacted payers, such as
MA organizations, may have contact with patients before the start of
coverage, in other cases, payers do not. Furthermore, while we are
recommending that state Medicaid and CHIP agencies incorporate these
requirements into their applications for coverage, states would have
few other options for communicating with patients before enrollment
(which is how ``start of coverage'' is captured in the regulation text
for Medicaid and CHIP).
We emphasize that payers must begin the process of collecting the
previous/concurrent payer information and opt in no later than 1 week
after the start of coverage but understand that it may not be completed
within that timeframe. We believe it is important to gather this
information from patients as soon as possible when a patient enrolls
with a new payer in order to facilitate the timely exchange of patient
data. Patients may take additional time to respond or follow-up may be
required. Impacted payers are encouraged to make a reasonable effort to
engage with patients to gather their permission and identify any
previous/concurrent payer(s). We rely on payers to develop reasonable
processes to follow up with patients, and recommend payers follow-up
one time before determining that the patient is choosing not to opt in.
Though not required, we encourage payers to build into their request
process a method for patients to indicate that they do not want to
provide the requested information, so that payers need not follow up
with them. We note that the patient education requirements, discussed
in section II.C.3.g. of this final rule, will provide patients annual
reminders of the payer to payer exchange functionality. Under this
final rule, patients must be able to opt in or withdraw permission at
any time.
The opt in and identifying previous/concurrent payers processes
could include using existing portals to gather this information from
patients, as we are not being prescriptive on how each payer implements
this process. We also encourage stakeholders to participate in HL7 FHIR
workgroups to collaborate with other industry stakeholders on
identifying best practices and identifying possible processes.
ii. Gathering Previous and Concurrent Payer Information
We proposed that impacted payers would be required to gather
information about patients' previous/concurrent payer(s) that would
allow them to identify and request data from those payers. That could
include the payer's name and a patient ID number or similar identifier.
Under our proposal, an impacted payer would be required to allow a
patient to report multiple previous/concurrent payers if they had (or
continue to have) concurrent coverage. In this circumstance, we
proposed that impacted payers would be required to request the
patient's data from all previous/concurrent payers.
Comment: Multiple commenters expressed concern with the lack of a
standardized process to identify a patient's previous/concurrent
payer(s) and recommended that CMS either establish a policy to identify
the payers, provide technical assistance on how to crosswalk unique
identifiers, or standardize elements of the process. A commenter
highlighted that the lack of clarity on how payers are to identify a
patient's previous/concurrent payer makes the Payer-to-Payer API
difficult to operationalize and would likely introduce errors. Multiple
commenters recommended additional changes to the enrollment process to
support data exchange via the Payer-to-Payer API. A few commenters
recommended that CMS work with stakeholders to develop a specific
process to collect this information. A commenter urged CMS to reinforce
to payers that they should make the processes as easy as possible for
patients by leveraging touchpoints that the patient would already be
engaged in to enroll and initiate new coverage.
Response: Because the requirements for a Payer-to-Payer API and the
need to collect information about previous or concurrent coverage for
patients crosses many payer programs with variation between enrollment
processes, we determined that being prescriptive on a specific process
would cause more implementation burden than necessary. In response to
comments, we are finalizing a modification to our proposal to require
payers to request previous and concurrent payer information no later
than 1 week after the start of coverage. As discussed previously,
payers might not have contact with patients before enrollment.
Therefore, this modification will allow additional time for payers and
broaden the range of options for payers to align with their current
processes. Initial implementation may be challenging; however, it is
important that patients' data are shared as they transition care to a
new payer, because the benefits for patients outweigh the upfront
implementation burden. Leaving the process open for payers to implement
in the least burdensome, most practical way to gather the information
from patients makes the most sense. Gathering previous payer
information and an opportunity for the patient to opt in ideally should
take place through an already established point of contact with the
patient. Leveraging established points of contact will reduce patient
burden and help impacted payers meet the deadline of no later than 1
week after the start of coverage. In particular, payers often have
existing processes to identify concurrent payers to facilitate

[[Page 8835]]

coordination of coverage and Medicare Secondary Payer/Third Party
Liability administration. For instance, per 42 CFR 422.108, MA
organizations are required to identify payers that are primary to
Medicare and coordinate its benefits to Medicare enrollees with those
primary payers. State Medicaid programs are required to collect
sufficient information to enable the state to pursue claims against
such third parties when making an eligibility determination or
redetermination per section 1902(a)(25) of the Act (for beneficiaries
enrolled in managed care, states generally make this the responsibility
of the MCO with state oversight). That requirement also applies to
state CHIP programs by cross reference at section 2107(e)(1)(B) of the
Act. Nothing in this rule would prevent payers from using that
information for both that purpose and to identify concurrent payers for
Payer-to-Payer API data exchange. However, patients would still need to
opt in for payers to proceed with requesting patient data via the
Payer-to-Payer API.
Comment: A few commenters requested clarification on whether the
definition of ``previous payer'' is limited to the immediately previous
payer or to previous payers within a specific time period, such as
within the last 5 years.
Response: The minimum requirement is only to request information
from the immediately previous payer, however if a patient does report
multiple previous payers, impacted payers are required to request that
patient's data from any previous/concurrent payers (identified to or
known by the impacted payer) within the required 5-year period. We are
finalizing that policy because patients may have been enrolled with
payers that are not subject to the requirements of this rule.
Therefore, allowing patients to have their impacted payers request data
from payers other than their immediately previous payer within the 5-
year timeframe could maintain as much of their record as possible.
Comment: A commenter suggested that CMS include a process for new
payers to inquire whether the previous payer supported the Payer-to-
Payer API described in this regulation, such as a monitored email
address, and that some type of consequence for non-compliance should be
levied.
Response: In section I.D. of this final rule we discuss an NDH that
could serve as a centralized place for payers to find other payers'
digital endpoints and identify payers that support the Payer-to-Payer
API. Without an NDH or similar source of information, payers would
likely be required to contact the previous payer directly to determine
if they support the Payer-to-Payer API. We are also exploring other
solutions, such as using TEFCA, that could be leveraged to determine if
the previous payer supports the Payer-to-Payer API. We have addressed
program enforcement and compliance mechanisms in section I.D.2. of this
final rule, as well, and appreciate public interest in mechanisms for
provider and patient appeals and complaints, oversight, and assurance
of compliance.
Comment: A commenter noted that a payer's ability to request data
from a previous payer would be dependent on the patient providing
accurate information about the previous payer. The commenter expressed
concern regarding the accuracy of this information and the effort
required for necessary follow-up.
Response: As discussed previously, we acknowledge that the
obligation to exchange data is contingent on patients supplying the
necessary information about previous/concurrent payers. An impacted
payer cannot comply with these requirements if the patient has not
provided timely or accurate information about their previous/concurrent
payer. We emphasize that payers must request this information no later
than 1 week after the start of coverage, but that it may take longer
than that to obtain information from the patient. If the patient does
not respond or additional information is necessary, the impacted payer
must make reasonable efforts to obtain their response to the opt in
request and to identify any previous/concurrent payer(s).
Comment: Several commenters suggested data elements that would be
necessary or extraneous to make that Payer-to-Payer API request.
Multiple commenters encouraged including the patient's name, patient's
previous/concurrent payer name, member ID, date of birth, physical
address, and phone number in a payer's data request to a previous
payer. Multiple commenters urged payers not to require patients to
provide the specific plan name, which may be long and unintuitive and
because patients may have switched plans over time with that payer. A
commenter expressed security concerns with exchanging Social Security
numbers (SSNs) and suggested that their use be as limited as possible.
Another commenter suggested that patients should be encouraged to
provide the dates coverage started and ended or information about up to
three recent services covered by the previous plan and those dates of
service.
Response: We agree with commenters that demographic information
such as patient's name, member ID, date of birth, physical address and
phone number are appropriate pieces of information to identify
patients. We also agree that SSNs should be used to identify patients
only when necessary (and permissible by law) due to that identifier's
sensitivity. While start and end dates of coverage may be useful in
some instances, patients are unlikely to know or remember those exact
dates, nor are they likely easy to find. Therefore, we discourage their
use for identifying patients. Asking a patient to provide information
about recent services covered by the previous payer could be burdensome
to a patient. Patients are unlikely to have that information without
gathering it from their previous payer. Therefore, there are less
burdensome ways to effectuate this process, such as by using the data
elements mentioned previously. Payers should implement these
requirements in such a way that accomplishes the goal of identifying
patients' previous/concurrent payer(s) with the least burden on
patients.
The data elements that a payer may need to identify a patient and
match that patient to their record are included in the required and
recommended standards for the Payer-to-Payer API. Specifically, the
required US Core IG and the recommended PDex IG have ``Must Support''
fields (meaning that the system must be able to support those data
elements) that could be used for identifying a patient, such as patient
name, addresses, birth sex, gender, birth date, member and subscriber
identifiers, and group number. Requesting payers should use those
fields to identify the patient whose data they are requesting. If the
information provided is insufficient to make a match, or it matches
with more than one member, an error should be returned. Payers will
need to use a combination of data elements to support patient matching,
as they do today with any data exchange. We also will continue to work
with ONC and share information on their patient matching research/
initiatives here: https://www.healthit.gov/topic/interoperability/standards-and-technology/patient-identity-and-patient-record-matching.
We encourage payers to leverage the appropriate patient matching data
elements of the IGs and we will continue to work on ONC on their
patient matching research and initiatives.\82\
---------------------------------------------------------------------------

\82\ Office of the National Coordinator for Health Information
Technology (2022, September 8). Patient Identity and Patient Record
Matching. Retrieved from https://www.healthit.gov/topic/interoperability/standards-and-technology/patient-identity-and-patient-record-matching.

---------------------------------------------------------------------------

[[Page 8836]]

Comment: A commenter suggested the need for a national Health Plan
ID (HPID) to identify a patient's previous/concurrent payers. The
commenter requested that CMS re-work and re-issue required standards
for a national HPID. A commenter also stated that the process would
benefit from establishing technical standards to ensure that all payers
are using the same data elements to verify a patient's payer(s).
Response: We acknowledge industry's interest in a national standard
for a payer identifier. We are aware that there are a few alternative
standards used in transactions today, which are located on member ID
cards and maintained in payer systems. For example, the Payer ID, used
in Electronic Data Interchange (EDI) transactions, is a unique ID
assigned to insurance companies to enable them to communicate with each
other to verify eligibility, coverage, benefits and submit claims. CMS
also maintains a Plan ID for all QHPs on the FFEs, which are 14
alphanumeric characters. Until and unless a national standard is
adopted, industry may wish to collaborate with the SDOs on an
appropriate payer identifier for the APIs.
Comment: Several commenters raised the concern that for QHPs, the
X12 834 transaction standard for health plan enrollment and
disenrollment from the FFEs does not currently carry previous payer
information, complete information on concurrent payers, member IDs, or
opt in needed to support the payer to payer data exchange during QHP
enrollment. A commenter also raised concerns about situations where a
patient begins the QHP enrollment process but does make the binder
payment, and therefore ultimately does not effectuate their coverage.
Response: Requiring payers to gather this information could result
in a more streamlined approach than incorporating it into the X12 834
transaction standard enrollment process, given that FFEs are not
otherwise required to use or retain the information. However, as
discussed previously, we are finalizing a modification to our proposal
to account for the timing of QHP coverage effectuation relative to plan
selection, which impacts when a QHP can reasonably obtain information
from an enrollee. Specifically, QHP issuers on the FFEs will be
required to provide enrollees or their personal representatives with an
opportunity to opt into the QHP issuer's Payer-to-Payer API data
exchange no later than 1 week after the coverage start date or the
effectuation of coverage, whichever is later. This timeframe accounts
for the date on which an issuer has confirmation that an individual
will be enrolled in QHP coverage with the issuer, by receiving the
binder payment that is required to effectuate coverage per 45 CFR
155.400(e), as well as instances in which coverage takes effect
retroactively.
iii. Currently Enrolled Patients
We proposed that no later than the compliance dates for the Payer-
to-Payer API, impacted payers must establish and maintain a process to
gather permission and identify previous/concurrent payer(s) from all
patients who are currently enrolled.
Some payers may want to have a soft launch, rolling implementation,
or pilot for their Payer-to-Payer API before the compliance dates. We
therefore tied our proposal to require impacted payers to gather
permission from currently enrolled patients to the proposed 2026
compliance dates, rather than when a payer implements its API. We
stated that this would allow payers to sequentially target specific
plans, populations, or enrollee categories for operational rollout, as
long as all currently enrolled patients are given the opportunity to
opt into the payer to payer data exchange by the compliance dates.
We received no comments on this proposal. In alignment with the
modified compliance dates discussed throughout this final rule, the
requirements to request currently enrolled patients' opt in permission
and previous/concurrent payer information will be tied to the 2027
compliance dates we are finalizing for the Payer-to-Payer API.
iv. Opt In
We proposed an opt in approach for the data exchange through the
Payer-to-Payer API. We stated that an opt in framework means that the
patient or their personal representative would need to affirmatively
permit a payer to share data, and without that permission, the payer
could not engage in the proposed payer to payer data exchange for that
patient. We noted that this permission (or lack thereof) would apply
only to the data exchange we proposed and would not satisfy any other
obligations required under the HIPAA Privacy Rule or other law.
Additionally, we stated that we believed patients themselves are the
best source for sufficient and accurate information necessary for the
payer to make the request. Should a patient choose to provide this
information, it would require an affirmative act from the patient, so
we stated that the burden of asking a patient to opt in would not
create a significant additional barrier to patient participation. We
also proposed to require impacted payers to have a process for patients
to opt into this data exchange at any time after the start of coverage,
or if they have already opted in, to withdraw that permission at any
time.
As discussed in section II.C.4.c. of this final rule, this opt in
requirement does not apply to data exchanges between a state Medicaid
or CHIP program and its contracted managed care plans or entities. We
also proposed that states, through their Medicaid and CHIP programs,
would be responsible for collecting a patient's choice to opt into the
payer to payer data exchange, rather than their contracted managed care
plans. We explained that a Medicaid or CHIP beneficiary may switch
between FFS and managed care delivery systems within the same state's
Medicaid or CHIP program, but despite these shifts, an eligible
beneficiary remains a beneficiary of the state program. States may also
change the managed care plans that they contract with. Thus, we
proposed that the patient permission for this data exchange, as a
Medicaid or CHIP beneficiary, would be obtained by the state and would
apply regardless of the delivery system in which the beneficiary is
enrolled.
In contrast, our policy for the Provider Access API will allow
payers to exchange patient data with providers unless a patient has
opted out. We proposed an opt out policy for the Provider Access API,
in part, based on the existence of a treatment relationship between the
patient and provider, a contractual relationship between the payer and
the provider, and a coverage relationship between the payer and
patient. Specifically, our policy to only require the Provider Access
API data exchange with providers in the payer's network and require a
process to attribute a patient to that provider before data can be
exchanged creates a level of assurance for the payer that it is sending
patient data to an appropriate party. Two payers exchanging information
may not have a direct relationship, but would be exchanging data based
on a patient's separate relationship with each payer. Therefore, in the
proposed rule, we stated that it would make sense for the patient to
have a larger gatekeeping role for the Payer-to-Payer API.
Comment: Many commenters expressed support for the proposed policy
to require patients to opt into the Payer-to-Payer API. Commenters
provided various rationales for their

[[Page 8837]]

support. Multiple commenters stated that the opt in approach would give
patients greater access to and control over their information. Other
commenters appreciated that the opt in approach protects patient
privacy. Some commenters noted that the opt in approach would be easy
for a payer to implement when a patient is a new beneficiary or
enrollee because the payer's relationship with the patient is new and
active and the payer can request a patient's opt in at the same time as
the payer requests the patient's previous/concurrent payer information.
A commenter noted that the Payer-to-Payer API is particularly well
suited for an opt in approach because it is usually a one-time or time
limited exchange (unless concurrent payers are involved).
Response: We appreciate commenters feedback in support of an opt in
policy and are finalizing this policy as proposed.
Comment: Some commenters voiced concerns about an opt in approach.
Multiple commenters expressed concern that an opt in approach will
result in lower rates of patient participation in the payer to payer
data exchange. Multiple commenters recommended that CMS adopt an opt
out approach for the Payer-to-Payer API instead of an opt in approach.
Primarily, commenters agreed that an opt out framework would lead to
more patient participation and more data available for the new payer,
any new network providers, and patients themselves. A commenter was
concerned that patients may be confused by the opt in process and
recommended providing clear directions to patients detailing how and
when patients can opt into data sharing.
Response: We agree that an opt in approach often results in fewer
data exchanges than an opt out policy. However, increased data exchange
is not necessarily the goal of our policy unto itself, but a process to
facilitate improved care. We believe that patients, as they are the
owners of their data, should have control over who has access to their
data, especially when the two parties exchanging patient data do not
have a direct relationship with each other, as in the case with payer
to payer exchange versus the Provider Access API where the payer and
provider have a network contract. However, we know that the more data
available, the more informed decisions about care can be. Patients
should see value in having their data exchanged between their previous/
current payer(s) and their new payer. As discussed in section II.C.3.g.
of this final rule, impacted payers will be required to provide plain
language information to patients informing them of the benefits of
payer to payer data exchange and directions for opting in.
Comment: A commenter recommended that CMS better explain the length
of time that an opt in election is valid.
Response: The patient's opt in election is valid indefinitely with
that payer unless the patient decides to withdraw their permission at a
later time.
Comment: Multiple commenters requested clarification on the
implications of a patient choosing not to opt into the data exchange
via the Payer-to-Payer API. Specifically, a commenter agreed that the
information proposed for the Payer-to-Payer API can be shared only if
the patient opts in, however, requested clarification on how payers
could meet obligations to exchange these patients' data for other
purposes.
Response: Patients have a choice about whether they want their data
shared under this policy as they transition between payers. If a
patient chooses not to opt into the data sharing, data will not be
exchanged between payers under the requirements in this final rule.
However, payers may exchange information without a patient's
authorization for other purposes, such as benefit coordination in the
case of concurrent payers, or for other permissible reasons under the
HIPAA Privacy Rule. There is nothing in this rule that would prohibit
payers from using the Payer-to-Payer API as the mechanism for data
exchange permissible under other authority, even if the patient has not
opted into the payer to payer data exchange policy in this final rule.
Comment: Multiple commenters submitted responses relating the
Payer-to-Payer API data exchange to the HIPAA Privacy Rule exception
for TPO disclosures, which do not require patient authorization. Some
commenters stated that the information CMS proposed to require be made
available falls under the scope of that exception and therefore opt in
should not be required. Other commenters believe that some of the data
(such as prior authorization information) would fall under that
exception, but other data (such as claims information) would not. A few
commenters suggested that CMS should reduce the scope of the data
exchange to allow disclosure under the TPO exception. Furthermore,
commenters stated that it may confuse and upset patients who have opted
out of sharing their data via the Payer-to-Payer API, but whose PHI may
otherwise be disclosed under the HIPAA Privacy Rule.
Response: We emphasize that our final requirements are not intended
to change any existing obligations under the HIPAA Privacy, Security,
and Breach Notification regulations, the regulations under 42 CFR part
2, or state privacy or other laws, but can and should be implemented in
accordance with those rules. To make a blanket determination that the
Payer-to-Payer API exchange that we are requiring always constitutes a
TPO disclosure would go beyond the scope of this rule and could
overstate and conflict with existing HIPAA Privacy Rule requirements
and guidance. Making such a determination could have unintended effects
on covered entities' ability to disclose PHI. Instead, for the reasons
explained previously, it is appropriate to require patients to opt in
for payer to payer data exchange. Our payer to payer data exchange
requirements are disclosures permitted under the HIPAA Privacy Rule as
``uses or disclosures that are required by law,'' as defined at 45 CFR
164.103, rather than as a permitted TPO disclosure. ``Required by law''
disclosures are limited to the relevant requirements of such law, not
to the HIPAA minimum necessary standard, thereby ensuring that all
content required by our Payer-to-Payer API policy may be disclosed. In
addition, the data exchange must not be prohibited by other law, such
as restrictions on patient records related to substance use disorder at
42 CFR part 2 or state privacy laws.
We emphasize that the opt in process described here applies only to
the payer to payer data exchange in this final rule. That is, it
applies only to the requirement for impacted payers to share individual
claims and encounter data (excluding provider remittances and cost-
sharing data), all data classes and data elements included in a content
standard at 45 CFR 170.213 and certain information about prior
authorizations maintained by the payer with a date of service within 5
years of the request by a patient's new or concurrent payer. Similar to
the discussion in section II.B.3.b.ii. regarding Provider Access API, a
patient's choice not to opt into the payer to payer data exchange does
not prohibit the payer from using the Payer-to-Payer API to exchange
patient data under another permissible authority. For instance, there
may be other permissible bases for payers to share data, without a
patient's authorization, such as under the HIPAA Privacy Rule's
permitted uses and disclosures to carry out treatment, payment, or
health care operations. Patients do not have the ability to opt

[[Page 8838]]

out of a payer using the API itself as a mechanism for sharing data
under such bases for disclosure. We urge payers to inform their
patients of this possibility in the educational resources discussed in
section II.C.3.g. However, we also note that the HIPAA Privacy Rule, at
45 CFR 164.520, has specific notice requirements for covered entities
to send to individuals. Payers should make clear the differences
between the payer to payer data exchange, which requires patients to
opt in, and other permissible disclosures, which may not require
authorization.
We also note that the data that may be shared under other
permissible bases, such as the TPO exception, may overlap with the data
required to be shared by our Payer-to-Payer API policy. For instance, a
payer may be permitted to disclose PHI to another covered entity to
coordinate benefits or determine cost-sharing amounts for the covered
entity's payment purposes under 45 CFR 164.506(c)(3). If that
disclosure is permissible, a patient declining to opt into the payer to
payer exchange policy in this final rule would not prohibit a payer
from using the Payer-to-Payer API to make that disclosure. In fact, we
encourage payers to leverage the Payer-to-Payer API as a standardized
mode of transmitting this information. Payers may leverage a variety of
solutions for exchanging coverage data today and moving to a standard-
based API across the industry could benefit payers by reducing the
types of connections they must maintain to communicate with other
payers.
Per 45 CFR 164.506(b), covered entities may create a process to
obtain consent from an individual to use or disclose PHI to carry out
treatment, payment, or health care operations. Per 45 CFR 164.522(a),
individuals also have the right to request restrictions on how a
covered entity will use and disclose PHI about them for TPO. Except in
limited circumstances, a covered entity is not required to agree to an
individual's request for a restriction. Where covered entities agree to
a restriction, it is bound to the restriction to which it agrees unless
the restriction is subsequently terminated. We emphasize that the opt
in process described in this final rule is specific to the Payer-to-
Payer API policy and is therefore not, on its own, a consent mechanism
per 45 CFR 164.506(b) or an agreed-upon restriction per 45 CFR
164.522(a).
These nuances are necessary for patients to understand that their
personal health information may still be shared in some instances, even
if they do not opt into the payer to payer data exchange. Where the
requirements of this rule change how covered entities or their business
associates may use or disclose PHI, covered entities should consider
their obligations under the HIPAA Privacy Rule.
Comment: A commenter recommended that CMS assist states with
implementing opt in processes. Another commenter explained that the
feasibility of an opt in approach depends on how it would be
implemented. A different commenter recommended that CMS to work with
stakeholders to develop a standard approach for how an opt in
requirement will work when the patient is not the primary insurance
holder, noting that a standard approach is necessary to reduce
confusion and ensure that patient information is protected.
Response: We agree that the feasibility of an opt in approach
depends on how it is implemented, which is why we are leaving the
actual implementation process up to the payers. We expect that payers
will implement the most viable processes for themselves. Each of our
policies in this final rule is targeted toward individual patients, not
any family members that may be covered through the same benefits. We
note that in some cases, applicable law may allow one individual (such
as a parent or guardian) to act as a personal representative for
another individual covered under the same benefits (such as a minor)
and could therefore opt into the payer to payer data exchange for that
individual. Regardless, the opt in is patient-specific and a payer must
make the data request based on the individual's permission and the
previous/concurrent payer should respond in kind with the individual
patient's record. No data should be shared about any patient that has
not opted in (or whose personal representative has not opted in),
regardless of whether another patient covered under the same benefits
has opted in.
Comment: Multiple commenters weighed in on whether patients' opt in
should be collected electronically and specifically recommended that
payers collect the opt in via a patient portal or mobile device. A
commenter explained that payers do not have the means to collect
patients' opt in via multiple methods. A different commenter noted that
payers should collect opt in data electronically. Another commenter
stated that patients should not be required to use a patient portal or
mobile device app to opt into data sharing. A commenter also requested
guidance on how to collect permission from patients who require
assistance enrolling or registering for the patient portal. Another
commenter noted the importance of equitable access to patient data and
highlighted the current usage of patient portals as a method to
authenticate patients' identities and obtain their opt in permission.
They recommended a centralized identity service for patient
authentication, verification, or consent for patients who cannot, or
prefer not to, access the patient portals. A commenter recommended that
CMS provide a centralized security verification through CMS. The
commenter noted that a centralized security certification validation
would relieve burden on payers to manage connectivity with other payers
and provide assurances around self-signed certificates.
Response: We are finalizing that all impacted payers must develop
and maintain processes to identify a patient's previous/concurrent
payer(s) and to allow patients or their personal representatives to opt
into the payer to payer data exchange (both with previous and
concurrent payers) no later than 1 week after the start of coverage. As
finalized in this rule, each new payer will be responsible for
gathering permission through an opt in process before requesting data
from any previous or concurrent payer. If payers believe that a patient
portal or mobile smart device with appropriate security protections is
the best way to gather opt in, it is permissible to use those methods.
We are not being prescriptive about the process or procedures used by
impacted payers for the required opt in process. However, we strongly
recommend that there be a way for patients to record their permission
telephonically or otherwise if they do not have internet access or do
not want to sign up for an electronic portal. We agree that equitable
access to patient data is of the utmost importance and emphasize that
the Payer-to-Payer API requirements are intended to allow for other
solutions besides patient portals for authentication, verification, or
consent. For those patients who require assistance, a personal
representative would be allowed to assist. However, we do note that 45
CFR part 92 requires impacted payers (as health programs or activities
under that section) to provide meaningful access to individuals with
limited English proficiency and accessibility requirements for
individuals with disabilities. The requirements of that part apply to
impacted payers, as described at 45 CFR 92.3.
We also are working closely with ONC on how the Individual Access
Services exchange under TEFCA could

[[Page 8839]]

support patient access to their data on the network, which could
include via payer APIs. We appreciate the suggestion of a centralized
security process and will consider our authority in this area.
Comment: Multiple commenters generally supported the proposed
requirement for payers to implement procedures to allow patients to
withdraw permission for the payer to payer data exchange after
initially opting in. Several commenters requested clarification from
CMS on what action payers must take in such instances. Specifically,
multiple commenters recommended that CMS explain whether payers are
expected to delete data that have already been received through the
Payer-to-Payer API if a patient withdraws their opt in permission after
the data exchange has occurred. Another commenter recommended that CMS
explain whether patients with concurrent payers will be able to
withdraw their opt in permission to stop the quarterly concurrent payer
data exchange.
Response: Our opt in policy is only prospective. If a patient opts
in, their impacted payers would be required to exchange data via the
Payer-to-Payer API, if all other requirements are met. If that patient
subsequently withdraws permission, payers will not need to take any
additional steps with regard to patient data that have already been
received from another payer. Specifically, there is no requirement in
our regulations to delete those data from their records. We acknowledge
that it may not be possible in all cases to clearly delineate which
entity created each part of the patient record and trying to do so
would put a burden on payers without benefit to patients. Payers are
permitted to identify the previous or concurrent payer as the source of
data, but are not required to do so. If a patient withdraws their
permission for the payer to payer data exchange after first opting in,
the payer will not be permitted to request that patient's data from
another payer, including a concurrent payer, unless the patient
subsequently opts in again. As discussed previously, payers may
exchange information for other purposes not related to the policies
described herein, such as for benefit coordination in the case of
concurrent payers or other permissible purposes under the HIPAA Privacy
Rule, and may still use the Payer-to-Payer API as the mechanism to
exchange data for those purposes, even if a patient has not opted in.
Comment: Multiple commenters made recommendations related to CMS
monitoring and oversight of the opt in approach. A commenter suggested
that CMS conduct oversight to ensure that payers implement the opt in
process and provide appropriate messaging to patients. A commenter
recommended that CMS require payers to submit data on the number of
patients who opted into the data exchange and how they were educated to
do so. The commenter stated that this would help CMS understand if the
API is meeting its intended goals. Another commenter recommended that
CMS consider including Payer-to-Payer API claims in the Healthcare
Effectiveness Data and Information Set (HEDIS) measure. Another
commenter recommended that CMS monitor the percentage of patients that
do not opt into these data exchanges via the Payer-to-Payer API and
assess whether those patients are concentrated in certain populations
and whether there are equity issues that CMS should address in the
future.
Response: We did not propose to require impacted payers to report
any metrics regarding the number of patients who opt into data sharing,
but we appreciate the recommendation and will consider it for future
rulemaking. We note that the specifications of HEDIS measures are out
of scope for this rule. We received comments on many of our proposals
about the need for specific compliance and enforcement efforts
pertaining to each API and we address these comments in section I.D. of
this final rule. Oversight and compliance procedures and processes vary
among these CMS programs and may have different implications based on a
payer's status in the program, previous compliance actions, and
corrective action plans.
Comment: Multiple commenters supported our proposal to require
state Medicaid and CHIP programs to collect patients' permission for
payer to payer data exchange in lieu of their contracted managed care
plans and managed care entities. Commenters stated that Medicaid and
CHIP agencies are in the best position to collect information from all
beneficiaries during eligibility and enrollment. However, commenters
warned that if sister agencies within the state perform eligibility and
enrollment processes, there would be additional coordination required
to collect patients' permission.
Response: We agree with commenters that state Medicaid and CHIP
agencies are the logical entity to hold Medicaid and CHIP
beneficiaries' permission for payer to payer data exchange. We note
that MCOs, PIHPs, and PAHPs are still responsible for collecting
previous/concurrent payer information and requesting the data exchange.
However, nothing in this rule would prevent a Medicaid or CHIP agency
from collecting that information and passing it along to their MCOs. We
also acknowledge the specific difficulties that states may face to
implement the requirements of this rule and refer readers to section
II.E. of this final rule for discussion about available extensions and
Federal funding for IT expenditures related to these requirements.
d. Requesting Data Exchange From a Patient's Previous/Concurrent
Payer(s) and Responding to Such a Request
i. Timeframe for Requesting Data
We proposed to require impacted payers to request a patient's data
from their previous/concurrent payer(s) no later than 1 week after the
start of coverage, as defined previously. We stated that 1 week should
be sufficient time for payers to complete their process for identifying
patients' previous/concurrent coverage and to request data from the
other payer(s). We proposed that if, after the start of coverage, a
patient opts into the data exchange or provides previous/concurrent
payer information or requests a payer to payer data exchange for
another reason, then the current payer would be required to request
data from the previous/concurrent payer(s) no later than 1 week after
the payer received the previous/concurrent payer information and the
patient has opted in, or the patient makes the request. We acknowledge
that the obligation to request data is contingent on the patient
supplying the necessary information about a previous/concurrent payer
to enable the new payer to conduct the required exchange. An impacted
payer cannot comply with these requirements if the patient has not
provided timely or accurate information about their previous/concurrent
payer. In that case, payers are required to make reasonable efforts to
gather this information from patients. For example, we recommend payers
follow-up one time before determining that the patient has not opted
in. We are finalizing a modification to the proposed regulatory text to
clearly establish that the 1-week timeframe for requesting patient data
begins when the impacted payer has sufficient identifying information
about previous/concurrent payers and the patient has opted in.
Comment: Many commenters supported our proposal to require impacted
payers to request data from a patient's previous payer no later than 1
week after the start of coverage or obtaining previous/concurrent payer

[[Page 8840]]

information and opt in permission from the patient. Other commenters
suggested a variety of alternative timeframes for payers to request
patient data from previous/concurrent payers. A few commenters
recommended that CMS allow 2 weeks after the start of coverage to
request the data. Other commenters recommended that CMS extend the
timeframe for a data exchange to be within 30 or 90 days after
enrollment to allow payers time to confirm the patient's information,
especially during peak volumes such as open enrollment. A commenter
highlighted that a 90-day timeframe would allow time for the previous
payer to process outstanding claims. Conversely, other commenters
recommended a 3-day timeframe for a new payer to request the patient's
data from their previous payer to expediate the data exchange.
Response: We continue to believe that 1 week is the appropriate
period to require payers to make a request for patient data after they
have sufficient identifying information about the previous/concurrent
payer and the patient has opted in. The longer the period between the
time a patient enrolls with a new payer and that payer receives patient
data, the less relevant those data could be. This is particularly true
for patients who have chronic conditions or ongoing treatment for life-
threatening conditions. For these patients, it is more important that
their new payer get information as soon as possible. If necessary,
additional information can be exchanged as it becomes available. See
our discussion in section II.C.3.d.i. of this final rule regarding
optional additional data exchanges between previous and new payers. For
instance, the CY 2024 MA and Part D final rule requires MA coordinated
care plans to provide a minimum 90-day transition period when an
enrollee switches to a new MA plan. During that time, the new MA
organization may not require prior authorization for an active course
of treatment. Establishing a 90-day timeline for payer to payer
exchange could largely negate the utility of the data to comply with
that requirement. Even a shorter period, such as 2 weeks or 30 days,
could require patients to provide separate information about active
courses of treatment, which would add burden to patients rather than
reducing it. Regardless of whether impacted payers are subject to that
rule, it is important to exchange data quickly so that patients can
maintain a continuity of care.
However, we also determined that our proposed data request deadline
was no longer feasible with the modified deadline for requesting
previous/concurrent payer information and the patient's opt in to be no
later than 1 week after the start of coverage. Therefore, we are also
finalizing a modification to our proposal to require impacted payers to
request data from a patient's previous/concurrent payer(s) no later
than 1 week after the payer has sufficient identifying information and
the patient has opted in, or within 1 week of a patient's request. We
encourage payers to request these data as expeditiously as possible.
Specifically in regard to periods of peak volume for payers, we
encourage payers to use the Bulk Data Access IG to send bulk requests
and responses for multiple patients at once. As discussed in section
II.G. of this final rule, we are finalizing our proposal to require
payers to implement the Bulk Data Access IG for the Payer-to-Payer API
for this very purpose.
Comment: Multiple commenters suggested that CMS explain the meaning
of within 1 week of the start of coverage. A commenter highlighted how
Medicaid policy requires that they grant eligibility retroactively up
to 3 months and recommended that the data request within 1 week of the
start of coverage be based on the date that the eligibility update is
received into their MMIS, not the effective date of coverage, which
could be 3 months prior. Another commenter recommended that only QHP
policies that have been effectuated with a binder payment be subject to
the payer to payer data transfer requirement, which should leave 1 week
after the date that benefits begin for the new payer to request the
data transfer.
Response: As noted previously, we are changing the deadlines for
payers to request information from other payers by tying them more
closely to the date when the payer has sufficient information about a
patient's previous and concurrent payers and the patient has opted in.
As such, the data request deadline is no longer linked to the start of
coverage or enrollment. Further, as explained previously, the term
``start of coverage,'' as used in the preamble to this rule, means when
coverage begins or when the patient enrolls, as applicable. For cases
when there may be retroactive coverage, such as in Medicaid, the payer
will be required to seek a patient's opt in for Payer-to-Payer API data
exchange and to request information about a new patient's previous/
concurrent payer(s) no later than 1 week after the patient's
enrollment. In Medicaid, the patient's ``enrollment'' is the date the
beneficiary is enrolled in the state's MMIS (or equivalent process),
not the date that coverage takes retroactive effect. For that reason,
the regulation text in Medicaid FFS reflects this by referring to
``enrollment'' instead of ``start of coverage.''
Comment: Multiple commenters requested clarification that timing
requirements are flexible to the extent reasonable and necessary to
verify that privacy and security requirements are met. A commenter
emphasized that this timeframe could only be followed if it begins
after the member has provided sufficient information as determined by
the impacted payer to identify a concurrent payer (for example, payer
name, member enrollment number, group number).
Response: We agree that the timeframe for sending a request only
begins when a payer has sufficient information to send a request to
another payer and the patient whose data are being requested has opted
in. We are finalizing that the request must be made no later than 1
week after the payer has sufficient identifying information and the
patient has opted in. We note that, as discussed previously, payers
have an obligation to request that information from their patients no
later than 1 week after the start of coverage, as that term is defined
previously specific to each impacted payer type.
Comment: A commenter suggested that if payer endpoints are not
publicly available or accurate information on a previous payer is not
available, payers should only be required to make reasonable efforts to
complete the data exchange.
Response: Existing requirements require payers to make technical
documentation about their API, including digital endpoint information,
on a publicly accessible section of their website.\83\ In section I.D.
of this rule we discuss an NDH that could serve as a centralized place
for impacted payers to find other payers' digital endpoints. Commenters
indicated that such a directory would significantly improve the process
for requesting patient data.
---------------------------------------------------------------------------

\83\ See 42 CFR 422.119(d) for MA organizations, 42 CFR
431.60(d) for Medicaid FFS, 42 CFR 438.242(b)(5) for Medicaid
managed care, 42 CFR 457.730(d) for CHIP FFS, 42 CFR 457.1233(d) for
CHIP managed care, and 45 CFR 156.221(d) for QHP issuers on the
FFEs. These requirements are cross referenced in the regulations
requiring impacted payers to apply the same technical specifications
to all the APIs required under this final rule.
---------------------------------------------------------------------------

Payers are required to request patient information from previous
and concurrent payers if the conditions in the rule are met, and we
encourage payers to make a reasonable effort to locate information
about a patient's

[[Page 8841]]

previous payer. If a payer is unable to obtain a valid endpoint or
accurate information for a previous or concurrent payer, we recommend
they document the efforts they took to gather the information from the
other payer. Doing so could establish a record for future oversight, or
in case of a dispute, that the payer made a reasonable effort to comply
with the requirements of this rule and the patient's desire for their
data to be exchanged. As discussed, payers are not responsible for
determining whether the patient's previous payer is an impacted payer,
but are required to request previous/concurrent payer information from
the patient and to make the data request to the other payer. We
encourage payers that are not subject to the requirements in this rule
to participate in the Payer-to-Payer API exchange in order to allow
their patients to benefit from this policy. However, a payer not
subject to this regulation may not have a FHIR API or want to exchange
the required information, which would be outside of the impacted
payer's control.
Comment: Multiple commenters flagged that impacted payers will need
time to establish the necessary technology linkages, data use
agreements, and security protocols to exchange information with another
payer in a manner compliant with the HIPAA standard transaction and
code set requirements. A commenter noted that the data exchange would
take longer than 1 week if a payer needs to set up a new connection, as
feeds may differ.
Response: We understand that a functional technological connection
with other payers to meet the requirements for the Payer-to-Payer API
policy can and sometimes will take more than a week to complete.
However, there is no applicable HIPAA standard transaction or code set
for the payer to payer data exchange we are finalizing in this final
rule. The required standards are those being established in this final
rule. Giving impacted payers sufficient time to coordinate with other
payers to establish the capability to exchange data is one rationale
for delaying the compliance dates from the proposed 2026 to 2027. We
expect that payers will use that additional time not only to build the
requisite API technology, but to coordinate with other payers to
establish those linkages. We encourage payers to establish connections
and perform testing with other payers before the compliance dates for
the Payer-to-Payer API to ensure that the data exchange will work as
expected. Payers should also set up a testing or sandbox instance of
their Payer-to-Payer API as early as possible for other payers to test
against. We also encourage payers to establish data use agreements and
register with each other's APIs prior to the compliance dates in order
to facilitate exchange as quickly as possible after the compliance
dates. We expect that those technological and legal requirements will
be most burdensome when one payer connects with another for the first
time. Subsequent exchanges should rely on that same foundation, and it
should not be necessary to repeat those steps. Finally, we suggest
payers prioritize other payers that they are most likely to exchange
with, such as those that overlap with their geographical coverage area.
ii. Additional Data Exchange
In the proposed rule, we solicited comments on whether additional
data exchanges would be warranted to account for data received or
processed by the previous payer after the patient's coverage ends and,
if so, what the appropriate parameters would be. Outside the context of
concurrent payers, we generally expect our policy to require a one-time
data exchange between a previous and new payer. Once the new payer has
received the patient's data from the previous payer, we do not
generally expect there to be additional exchanges with the previous
payer. However, we want to allow patients to request subsequent data
exchanges to account for any outlier situations. We are also aware that
claims take time to process and may be processed after patients have
enrolled with a new payer, thus creating additional data within the
patient's record for some time period after the patient has changed
payers. We considered proposing a policy where, if the patient opts in,
a previous payers would be required to send any additional data within
the required dataset to the new payer no later than 1 week of receiving
the additional data. However, keeping in mind the burden this could
impose on payers, we sought comment on such a policy. We sought comment
on whether additional data could be helpful for the new payer in the
weeks or months after enrollment, and which specific data could be most
pertinent, or whether additional data exchange would be overly
burdensome and not provide value to the new payer. We asked whether it
would be appropriate to limit such a requirement to send updated data
to a certain period after the initial data exchange, for instance
within 30 or 90 days. Additionally, we asked whether impacted payers
should be required to make an additional data exchange within a week of
receiving any new data or on a set cadence, such as monthly or
quarterly, to allow payers to streamline transactions for multiple
patients.
Comment: We received varying comments around additional data
exchanges with multiple commenters supporting a one-time additional
data exchange to promote continuity of care. Some commenters thought it
would not be feasible to share additional data within 1 week of each
update but supported a single exchange at 30-, 60- or 90-days after the
patient has moved to a new payer. A commenter stated it would be
difficult to track when additional data need to be sent after the
initial exchange.
Response: We agree that it could be helpful for payers to
supplement the data exchange required under this rule, to account for
any claims or data that are received after the initial data are sent to
the new payer. While we are not requiring it, we encourage payers to do
so in order to pass along a complete patient record. Likewise, we
encourage the new payer to send an additional request for data within
90 days of receiving the initial data response. The previous impacted
payer would be required to respond to such a request.
iii. Authorization and Authentication Protocols
We proposed that impacted payers would be required to use the
OpenID Connect Core authorization and authentication protocols at 45
CFR 170.215(e)(1) to authenticate the identity of the requesting payer.
We wanted to ensure payers would not have to send data unless they are
confident that the requesting payer is identified. The ONC Cures Act
final rule adopted content and vocabulary standards to provide the
foundation needed and were finalized for use in the CMS
Interoperability and Prior Authorization final rule to support
implementation of the policies (85 FR 25521-25522). Thus, we proposed
OpenID Connect Core in effort to align standards across API
implementations.
Comment: Multiple commenters sought clarification on the general
authentication and authorization process and flagged that requiring
OpenID Connect Core will not be sufficient for the Payer-to-Payer API.
A commenter recommended that CMS consider UDAP or the PDex IG, which
uses a SMART framework instead. Another commenter flagged that the
OpenID Connect Core standard requires a log-in, whereas the proposal
suggested that payers are required to provide these APIs without a user
login or credential.

[[Page 8842]]

A commenter highlighted that the Bulk Data Access IG requirement relies
on portal credentials and user logins created by the individuals to be
linked to their identity in the payer system.
Response: Upon consideration, we agree that it would not be
appropriate to require OpenID Connect Core for the Payer-to-Payer API.
OpenID Connect Core is a means to identify individuals and because the
Payer-to-Payer API is a business-to-business interaction, OpenID
Connect Core is not adequate to meet this use case. Although OpenID
Connect Core can be utilized for the Payer-to-Payer API, it is not a
scalable approach because it requires user credentials. For similar
reasons, we are finalizing a modification to our proposal to not
require OpenID Connect Core for the Provider Access, Payer-to-Payer and
Prior Authorization APIs.\84\ The SMART App Launch IG can also provide
a method for authentication within the Payer-to-Payer API; though we
note that we are not finalizing our proposal to require that IG, it
remains available to payers as an option. However, as part of the
Payer-to-Payer API, payers still need to authenticate bi-directionally
using industry best practices to ensure that patient data are only
shared appropriately. We refer readers to Table H3 in section II.G. for
an updated listed of required and recommended standards and IGs. We
also advise that the Bulk Data Access IG, which is a required IG for
the Payer-to-Payer API, contains a ``SHOULD'' (that is, strongly
recommended) conformance statement to use SMART Backend Services. We
also note that SMART Release 2.0.0, which has since been adopted in the
HTI-1 final rule at 45 CFR 170.215(c)(2) includes SMART backend
services. Though in this final rule we are requiring impacted payers to
support the Bulk Data Access IG in their Provider Access and Payer-to-
Payer APIs, this requirement does not obligate them to use it for every
data exchange if it is not necessary.
---------------------------------------------------------------------------

\84\ In the proposed rule, that requirement was included for MA
organizations at 42 CFR 422.121(b)(1)(i), for Medicaid FFS at 42 CFR
431.61(b)(1)(i), for CHIP FFS at 42 CFR 457.731(b)(1)(i), for
Medicaid managed care plans through cross reference at 42 CFR
438.242(b)(7), for CHIP managed care entities through cross
reference at 42 CFR 457.1233(d), and for QHP issuers on the FFEs at
45 CFR 156.222(b)(1)(i).
---------------------------------------------------------------------------

Comment: A commenter recommended that CMS collaborate with industry
stakeholders to identify best practices for user authentication and
authorization with the Payer-to-Payer API. Another commenter
highlighted that guidance on how to trust and verify inbound data
requests via the Payer-to-Payer API will be essential.
Response: We will continue to collaborate with industry
stakeholders through HL7 FHIR workgroups and through HL7 FHIR
Connectathons as the standards to support the Payer-to-Payer API
continue to be refined to support these final policies. We also will
continue to work closely with ONC on the required authentication and
authorization standards under 45 CFR 170.215. While we are not
specifically requiring an IG or method be used for authentication and
authorization, as part of the Payer-to-Payer API payers still need to
authenticate the other payer they are exchanging data with.
iv. Attestation
We proposed to require the requesting impacted payer to include an
attestation with the request for data affirming that the patient (1) is
enrolled with the requesting payer and (2) has opted into the data
exchange in a manner that meets the applicable legal requirements. As
explained in section II.G. of this final rule, we recommended certain
HL7 FHIR IGs to support the data exchange between payers. The
recommended PDex IG has been developed to include both the technical
and business processes of capturing and sharing a patient's permission
for data exchange with the payer to payer data request. Because that IG
is recommended and not required, impacted payers could also exchange an
attestation regarding patient permission with other implementations,
which could meet or exceed the requirements of the PDex IG.
Comment: Multiple commenters supported the attestation proposals
for the Payer-to-Payer API. Multiple commenters provided
recommendations for processes to share patients' data sharing
permission. Multiple commenters suggested processes for payers to
verify that a patient opted into data sharing with another payer before
giving that payer access to patient data. A commenter requested
clarification on whether patients must opt in for each subsequent
payer. A commenter recommended that patients' data sharing permission
be shared with secondary and tertiary payers. Commenters requested
clarification on which payer (the requestor or requestee) is
responsible for obtaining patients' permission. A commenter highlighted
that an attestation process will not resolve the risks of incorrectly
matching data to the patient. Another commenter asked whether FHIR can
be used to send the attestation. Another commenter requested
clarification on using standards and IGs to facilitate the opt in
process. A commenter sought guidance on where a patient's opt in would
be indicated on the electronic transmission and how they could verify
that the payer provided educational information to the patient.
Response: We appreciate the recommendations for sharing a patient's
opt in but leave that exact process up to payers. The impacted payer
requesting the data from the previous/concurrent payer is responsible
for obtaining the patient's opt in and must include an attestation with
that request for data affirming that the patient (1) is enrolled with
the requesting payer and (2) has opted into the data exchange in a
manner that meets the necessary legal requirements. Patients would have
to opt in for each subsequent payer to request their data from a
previous/concurrent payer. The purpose of the attestation is not to
match the data to the patient, but to affirm that the patient has
enrolled with the requesting payer and has opted into the data exchange
in a manner that meets the necessary legal requirements. We highly
recommend using the IGs discussed in further detail in section II.G. of
this final rule to support the Payer-to-Payer API. The latest published
version of the PDex IG (STU 2.0.0) includes a means for a payer to
communicate that the member has opted in--through a FHIR Consent
resource--when requesting data from another payer. An attestation or
verification that the requesting payer provided educational information
to the patient is not required to be sent with the request.
Comment: A commenter recommended that CMS more clearly explain the
Payer-to-Payer API process to ensure that prospective or potential
payers are not requesting a patient's data. Another commenter suggested
that an attestation from another payer is not sufficient proof to
demonstrate a patient's decision to opt in and suggested that some
assignment of legal liability be considered for the requesting payer,
as it might assuage these concerns.
Response: A prospective or potential payer should not request a
patient's data under this rule. Under this rule, a payer must attest
that the patient is enrolled with that payer as part of its request for
the patient's data from a previous/concurrent payer. We emphasize that
the impacted payers must implement an authentication process (discussed
previously) that verifies the requesting payer's identity as a
legitimate health care coverage entity. If an entity includes a
fraudulent attestation that the patient is enrolled with the payer and
has opted in to payer to payer data

[[Page 8843]]

exchange in its request for patient data, that entity could be subject
to criminal or civil penalties.
v. Timeframe for Responding to a Request
We proposed that impacted payers that are previous/concurrent
payers would be required to respond to a current payer's request, if
specified conditions are met, within 1 business day of receiving the
request. We explained that 1 business day would be the appropriate
timeframe to complete this process to send the data, as new payers need
timely access to previous/concurrent payer data to facilitate care
coordination and make the information available to providers within
their new network. We noted that this timeframe also would align with
the 1 business day response time for the Patient Access and Provider
Access APIs.
We sought comment on whether the proposed timeframes for the
previous/concurrent payer to send these data, are appropriate or
whether other timeframes would better balance the benefits and burdens.
We sought comment on whether payers need more than 1 business day to
respond to a request and sought comments on what might be a more
appropriate timeframe if commenters thought a different timeframe was
warranted. We explained that it is important for patient data to move
to the new payer as soon as possible to send their patient record and
to ensure care continuity.
Comment: Multiple commenters expressed support for the 1 business
day response time for the Payer-to-Payer API. A commenter recommended a
modification that data should be available within 1 calendar day.
Another commenter stated that the purpose of standardized API data
exchange is to have real-time data availability. A commenter requested
that CMS provide at least 24 hours for data from the Prior
Authorization API to be available via the Payer-to-Payer API. Some
commenters expressed general concern with our proposed response
timeframe and suggested that payers may become overwhelmed, especially
during open enrollment periods. A commenter expressed concern that the
proposed timeframe does not consider the degree of manual effort
required to ensure compliance with applicable state laws and
regulations regarding health privacy and confidentiality. Multiple
commenters recommended that CMS require a response time of 2 business
days for the Payer-to-Payer API and another suggested 3 business days.
Response: After reviewing the comments, we believe that keeping the
response timeframe at 1 business day is appropriate. This expedient
data exchange will support care continuity and still allow time for the
processes for payers to appropriately send patient data. We note that
this timeframe also aligns with the finalized 1 business day response
time for the Patient Access and Provider Access APIs. We acknowledge
that some periods may have increased data exchange requests, such as
during open enrollment period, and note that the purpose of the
required Bulk Data Access IG is to efficiently exchange large volumes
of data for multiple individuals and can be utilized for both
requesting and sending data.
The data content we are finalizing that must be included in the
payer to payer data exchange is generally the same as the current
requirements for the Patient Access API, notwithstanding the addition
of prior authorization information. Claims and encounter data and all
data classes and data elements included in a content standard at 45 CFR
170.213 (USCDI) are structured data, which will help payers identify
particular items that are subject to additional privacy requirements.
We are also finalizing 2027 compliance dates, in part, to give payers
additional time to develop internal processes and train staff. That
includes processes make the necessary determinations as to which data
are permitted to be shared via the Payer-to-Payer API. For instance,
payers may use this time to develop processes that flag certain data
elements with metadata--as the payer receives them--if they require
special permissions or are prohibited to disclose under other law. We
highly encourage payers to engage in this process as they receive data
to ease any manual review and decision-making that might be necessary
when a payer requests patient data.
Comment: A commenter recommended that CMS address the need for a
legal governance framework for the payer to payer data exchange because
the technical standards proposed would not enable the requesting payer
to substantiate the patient's authorization. The commenter stated the
need to provide legal assurances that the payer requesting a patient's
records has obtained appropriate authorization to request the records
and without a standardized governance framework, payers would struggle
to fulfill the requirement to respond within 1 business day of
receiving a request.
Response: We understand the importance of legal assurance between
payers to ensure the patient has provided appropriate authorization
before sharing data across payers. The recommended PDex IG STU 2.0.0,
which has since been published since the publication of the CMS
Interoperability and Prior Authorization proposed rule, includes both
the technical and business processes to capture and share a patient's
permission as part of the payer to payer data request. We believe 1
business day is sufficient to fulfill the request for data exchange
because the IG is a means for payers to electronically send a record of
the patient's permission to receive data from the other payer. We are
also working closely with ONC as to how TEFCA could support scalable
governance for payer to payer data exchange. We reiterate that we are
requiring that the new payer provide an attestation with the request
for data affirming that the patient has enrolled with that requesting
payer and has opted into the data exchange.
vi. Payers Not Subject to This Regulation
If a previous/concurrent payer is not an impacted payer, they are
not subject to our final requirements and, therefore, are not required
to send or request data through the Payer-to-Payer API. For example, an
employer-based commercial plan would not be subject to this rulemaking.
If the previous/concurrent payer is not an impacted payer, they are not
subject to our requirements to respond to the request. A new or
concurrent impacted payer is not obligated to determine whether the
previous/concurrent payer is an impacted payer under this final rule or
to limit its requests for a patient's data (or its responses to
requests for a patient's data) to only impacted payers. Therefore, we
proposed that an impacted new payer would be required to request the
data from the patient's previous/concurrent payer, regardless of
whether the other payer is an impacted payer. Conversely, we proposed
that if an impacted payer receives a request for patient data that
meets the requirements of this rule, they would be required to respond
by making available the required data through their Payer-to-Payer API,
regardless of whether the requesting payer is an impacted payer (which
the payer may or may not know).
If a payer not subject to this regulation does not have the
capability or refuses to exchange the required data with an impacted
payer or is willing to exchange the data but is unable or unwilling to
do so through a FHIR API, the impacted payer will not be required to
exchange data with that payer. Payers that have not implemented the
Payer-to-Payer API would not have accessible digital endpoints to make
the required request.

[[Page 8844]]

We emphasized in the proposed rule that impacted payers would not need
to spend resources determining whether other payers are subject to this
rulemaking, but would be required to request patient data, if possible,
and respond to all requests that are made within the requirements.
However, we encourage all payers to implement a Payer-to-Payer API to
support data exchange with other payers, even if they are not subject
to our final requirements to support care coordination and more
efficient operations.
Comment: Multiple commenters flagged concerns regarding
interoperability with payers not subject to this regulation. A
commenter stated that it is unclear what value would be derived from
the investment if there is no response or reciprocation from payers not
subject to this regulation. Another commenter noted that payers need to
build a connectivity system with other payers, including payers not
subject to this regulation.
Response: We disagree that the burden of connecting with a payer
not subject to this regulation that has implemented a Payer-to-Payer
API in conformance with our requirements is any different than
connecting with an impacted payer. Regardless of whether they are
covered by an impacted payer, there is value in maintaining a patient's
data and exchanging those data when a patient transitions to a new
payer or between concurrent payers. Furthermore, requiring impacted
payers to exchange data only with other impacted payers would require
impacted payers to expend effort to determine whether the other payer
is an impacted payer. That effort can be eliminated by simply treating
any payer as a possible exchange partner. Furthermore, not requiring
impacted payers to exchange data with payers not subject to this
regulation would mean that there would be no incentive for those payers
to adopt the requirements of payer to payer data exchange. In addition,
impacted payers are not required to exchange data outside of the
process finalized in this final rule, including using a standards-based
API. If a payer not subject to this regulation requests data in a
format that is not compatible with the Payer-to-Payer API and specific
data formatting, content and vocabulary standards established in
regulation, impacted payers will not be required to send data via a
different method, unless other law requires them to do so.
We understand that impacted payers may have additional difficulty
ascertaining that another payer is not subject to this regulation (or
not compliant), as that payer would not have digital endpoints to
discover. Payers are required to take reasonable steps to determine
whether they can exchange data with the other payer. We encourage
payers to contact the previous payer directly to determine whether they
support the Payer-to-Payer API. Other solutions could also be explored
to help payers determine whether the previous payer supports the Payer-
to-Payer API, such as using TEFCA. In section I.D. of this final rule
we discuss an NDH that could serve as a centralized place for payers to
find other payers' digital endpoints and identify payers that support
the Payer-to-Payer API. Once a payer knows that another payer is not
capable of payer to payer data exchange, they would not be required to
inquire every time they receive a new patient who identifies that
previous payer. However, it would be prudent to occasionally (such as
annually) check whether the other payer has implemented a Payer-to-
Payer API and is now capable of data exchange.
e. Ongoing Data Exchange Requirements for Concurrent Coverage
i. Concurrent Coverage Data Exchange
For individuals who have concurrent coverage with multiple payers,
we proposed to require impacted payers to collect identifying
information about any concurrent payer(s) from patients before the
start of coverage with the impacted payer (consistent with how ``start
of coverage'' is explained previously). Because we believed it would be
beneficial for all of a patient's current payers to maintain a complete
record of the care that the patient has received, we proposed to
require impacted payers to request the same patient data described in
section II.C.3.b. of this final rule from all of a patient's concurrent
payers, and to send those data in response to a request that meets all
the requirements of this final rule. We stated that this would ensure
that the patient's concurrent impacted payers maintain a complete
patient record and can provide all the information proposed to be
required under the Patient Access and Provider Access APIs.
Specifically, we proposed to require impacted payers, no later than
1 week after the start of a patient's coverage,\85\ to request data
from any concurrent payers that the patient reports. Because all payers
will update patient records while a patient is enrolled with those
payers, we proposed that when a patient has concurrent coverage with
two or more payers, the impacted payers would be required to exchange
with every other concurrent payer, at least quarterly. We proposed that
should an impacted payer receive a request for a current patient's data
from a concurrent payer for that patient, the receiving payer would
have to respond with the appropriate data within 1 business day of
receiving the request. Operationally, this proposed exchange would
function the same as the data exchange with a patient's previous payer.
---------------------------------------------------------------------------

\85\ For QHP issuers on the FFEs, no later than 1 week after the
effectuation of enrollment.
---------------------------------------------------------------------------

We also proposed that any impacted payer that receives patient data
from another payer under these regulations must incorporate those data
into the recipient payer's records about the patient. The required data
content we proposed are the same claims and encounter data (excluding
provider remittances and cost-sharing information), all data classes
and data elements included in a content standard at 45 CFR 170.213
(USCDI), and certain information about prior authorizations that the
payer maintains with a date of service on or after January 1, 2016. We
stated that that proposal would require impacted payers to both request
patients' data from other concurrent payers and to respond to requests
from other payers to share patients' data.
Comment: A commenter recommended that we only require concurrent
payers making quarterly data transmissions to send data that have been
updated since the last data exchange. The commenter stated that this
would reduce burden by allowing them to exchange a smaller set of data
that can more easily be integrated into their patient records.
Response: We agree that this is a reasonable solution to reduce
burden. We are finalizing a modification to our proposal to allow
concurrent payers to agree to exclude from ongoing quarterly data
exchange any data that were previously transferred to or originally
received from the other concurrent payer. We leave it to payers to
determine the best process to effectuate this option, as it is intended
to reduce payer burden. If exchanging only new data would increase
burden on payers versus exchanging all patient data, they are not
required to do so. Ultimately, the exchange should result in both
concurrent payers having a complete set of patient data to support
patient care and care coordination.
Comment: A commenter suggested that CMS require payers to clearly
document, in the payer systems, which payer is primary, and which is
secondary to ensure providers receive accurate and timely coordination
of benefit information.

[[Page 8845]]

Response: Coordination of benefits is an established process
(though the exact process may vary by payer and jurisdiction) that we
specifically did not propose to affect. As discussed previously, if
payers find it beneficial to use the Payer-to-Payer API for purposes
other than the data exchange finalized in this rule, such as
coordinating coverage, they are welcome to do so. To the extent that
such coordination information would benefit patients or providers by
being available via the Patient Access and Provider Access APIs, we
encourage payers to do so.
Comment: Several commenters expressed opinions on the appropriate
timeframe for payers to request data from another concurrent payer and
for payers to respond to such a request. Multiple commenters stated
their general support for timely information exchange between
concurrent payers to help minimize unnecessary administrative paperwork
and other inefficiencies. Several commenters supported our proposed
timeframes. Other commenters suggested that payers have up to 30 days
to request patient information. A commenter stated that the data should
be available within 1 calendar day instead of 1 business day. A
commenter recommended CMS allow at least 3-5 business days for a
response.
Response: There should be no procedural or technical difference
between requesting data from a previous payer or a concurrent payer,
other than the requirement that concurrent payers engage in ongoing
quarterly exchange. Similarly, responding to such a request should be
the same process, using the same FHIR standards. Therefore, we believe
it is prudent to establish the same timeframes for the initial requests
to and all responses from concurrent payers as for previous payers.
Therefore, we are finalizing that for concurrent payers, the initial
request for data must be made no later than 1 week after the payer has
sufficient identifying information about concurrent payers and the
patient has opted in and quarterly thereafter. We are finalizing our
proposal that impacted payers must respond within 1 business day to a
request for patient data from a concurrent payer that meets all the
requirements of this final rule.
ii. Concurrent Payer Exchange Timeframe
We also considered whether to propose more frequent exchanges
(weekly or monthly), or less frequent exchanges (semi-annually or
annually) for the required data exchanges between concurrent payers;
however, we explained in the proposed rule that we believed a quarterly
data exchange would strike the right balance between providing
accurate, timely data and payer burden. We believed that sharing data
quarterly would be frequent enough to allow new health data to
accumulate and still be timely, but not so frequent that it causes
unnecessary burden on the payers. We requested comment on this
proposal, including on the appropriate frequency for this payer to
payer exchange for patients with concurrent coverage.
Comment: A significant majority of commenters supported our
proposal to require quarterly data exchange between concurrent payers
because it would facilitate care coordination. Some commenters
suggested that a more frequent data exchange could benefit patients.
Some commenters noted that even quarterly data exchange may miss key
clinical events that would be useful for care coordination and
recommended that the data exchange should take place monthly. On the
other hand, a few commenters stated that impacted payers should only
request additional data from concurrent payers when initiated by a
member.
Response: We agree with the majority of commenters that a quarterly
cadence appropriately balances the benefits and burdens on payers.
Payers may make arrangements with each other to exchange information
more frequently, if they believe it would benefit their mutual
patients. The burden of initiating the exchange should not fall on the
patient, especially at times when they are dealing with specific health
issues that would most benefit from care coordination. As some
commenters recommended more frequent data exchange, we will consider
whether to propose amendments to this policy in future rulemaking after
the industry has experience meeting the requirements of this final
rule.
We note that when a patient has concurrent coverage, the payers
must communicate regularly to ensure that the proper payer is
responsible for that patient's claims. Nothing in this final rule,
including a patient not opting into the Payer-to-Payer API data
exchange, is intended to alter payers' ability to exchange data as they
do today for that purpose, in accordance with applicable law.
f. Data Incorporation and Maintenance
i. Data Incorporation
We proposed that data received by an impacted payer through this
data exchange must be incorporated into the patient's record with the
new payer. We stated that those data could then be part of the
patient's record maintained by the new payer and should be included as
appropriate in the data available through the Patient Access, Provider
Access, and Payer-to-Payer APIs. In this way, a patient's data could
follow them between payers and be available to them and their
providers. We stated that this proposal would not obligate payers to
review, utilize, update, validate, or correct data received from
another payer, but we encouraged impacted payers to do so, at least to
the extent it might benefit the patient's ongoing care. We explained
that payers could choose to indicate which data were received from a
previous payer so a payer, provider, or the patient looking at the
record, would know where to direct questions (such as how to address
contradictory or inaccurate information), but would not be required to
do. Regardless, all data received, maintained, used, or shared via the
proposed Payer-to-Payer API would be required to be received,
maintained, used, or shared in a way that is consistent with all
applicable laws and regulations.
Comment: Multiple commenters supported our proposal to require
payers to incorporate data they receive from other payers via the
Payer-to-Payer API into their own patient records in order to ensure
that a patient's record is not lost. Other commenters stated that they
do not believe that payers are the appropriate holders of a patient's
full medical record and that providers or patients themselves should be
the maintainers of those data.
Response: We agree that in some cases a payer is not the best
entity to hold a patient's longitudinal record and that there is other
technology available for patients to download their data, for example,
using the Patient Access API, and to store it independently of their
payer. As discussed previously, we are finalizing a policy that limits
the payer to payer data exchange to data with a date of service within
5 years of the request. After considering public comments, we
determined that a 5-year period balances the benefits of new payers
having access to recent patient data and the patient not losing recent
information against the burden of integrating and maintaining
historical data that may or may not be useful to care.
For patients who want to maintain their own information in a PHR,
they have that option through the Patient Access API. While in some
cases, a patient may have a provider that can and will aggregate their
records from each other provider that the patient

[[Page 8846]]

sees, we do not believe this is a common scenario, as it would require
a significant amount of work by the provider. As discussed, because
payers receive claims or encounter data from each provider that sees a
patient, they typically possess the most complete historical patient
record. Requiring a payer to send a patient's data to their new payer
will ensure that recent information that could be important for care
continuity is not lost.
Comment: A commenter cautioned that CMS should not assume that the
information received from a previous payer is whole and/or correct. The
commenter noted that the difference in health plans' level of diligence
could cause some discrepancies in patient coverage. Another commenter
suggested that payers would be incentivized to send incorrect
information to another payer rather than correcting the patient's
record.
Response: We acknowledge that any set of patient data may have
errors or omissions. However, we do not believe that the appropriate
response to this issue is to discard data when a patient moves between
payers. As stated, we do not wish to burden payers to proactively
verify patient records when they receive them from another payer.
However, under the HIPAA Privacy Rule, at 45 CFR 164.526, individuals
generally have the right to have a covered entity amend PHI or a record
about the individual in a designated record set for as long as the PHI
is maintained in the designated record set, with certain exceptions.
That right exists regardless of whether the covered entity created the
PHI itself or received it from elsewhere. That requirement is
consistent with our policy, as it does not require proactive
verification, but must be addressed upon request by an individual.
We also do not believe that there is any risk of payers
intentionally proliferating inaccurate information. There is no reason
for a payer to maintain inaccurate records with the ultimate goal of
passing that information to another payer when the patient leaves their
coverage. Finally, payers are only responsible for maintaining their
own records, including that which has been received from another payer.
If there is an error to be corrected in data received from a previous
payer, neither the patient nor their payer will need to contact the
previous payer to correct it and have the patient's record resent. A
patient's current payer is required, by the HIPAA right to amend and
correct data in its records, even if that incorrect information was
initially received from a previous payer.
Comment: A few commenters recommended that all the APIs should
support optional provenance resources that could be added by either the
sender or the receiver to indicate the source of data. A commenter
recommended that instead of CMS recommending payers to note where the
data originated, CMS instead propose that specific provenance resources
be required to indicate which data came from a previous payer, which
could also be included in subsequent data exchanges.
Response: When incorporating the data from an old or concurrent
payer, payers are free to indicate the provenance of that information,
which would then be included in the data available through the Patient
Access or Provider Access APIs. As discussed in section II.G., we are
recommending, but not requiring, the PDex IG for the Payer-to-Payer
API. The PDex IG requires provenance information be included in
outbound FHIR transactions and that a payer receiving such a
transaction must incorporate any included provenance information. There
is also a ``SHOULD'' recommendation within the IG that payers create
provenance records when the provenance is not included in a data set
(for example, when it was received through non-FHIR mechanisms). We
highly recommend that payers use the IG for several reasons, including
that it would help address this issue and help payers, providers, and
patients understand the source of data. We will consider whether to
propose to require provenance information through future rulemaking.
Comment: Multiple commenters highlighted that our Payer-to-Payer
API policy would require extensive data translation and de-duplication.
They suggested that CMS encourage payers to work with HIEs to determine
the best solutions to avoid data duplications and associated errors. A
commenter expressed concern regarding the potential for duplicate data
to be transmitted throughout the health care system.
Response: We appreciate commenters' suggestions that there are
existing marketplace solutions to address some of the concerns about
data duplication. We understand the concern over duplicative
information. There are IT solutions, such as EHR vendors and HIEs,
available that can make the data actionable and help payers avoid
receiving duplicative information via the Payer-to-Payer API. To the
extent it would benefit payers, we encourage them to work with HIEs and
HINs to facilitate payer to payer data exchange. We note that nothing
in our policies prohibits a payer from using an intermediary to aid
with various functions, such as patient matching, data exchange, or
data hygiene.
Comment: A commenter stated that they believe data acquired via
Payer-to-Payer APIs should be dated with the original date of service
to prevent duplication in future Patient Access or Provider Access API
requests, if a patient or provider already had that information from
the previous payer.
Response: We agree that it is important to maintain the fidelity of
data received via the Payer-to-Payer API. While creating additional
metadata is recommended to be able to track where the data came from
and when it was acquired, payers should not be changing the underlying
data itself. For example, the ``date of service'' or ``date claim
processed'' should not be updated to the date that the new payer
receives the record of the claim from a previous payer.
Comment: A commenter stated claims are not typically considered
``patient records'' and suggested CMS define the ``patient record''
into which information from a previous/concurrent payer must be
incorporated.
Response: We do not need to define ``patient record'' as we are
defining the set of data that must be shared between payers, that is,
claims and encounter data (excluding provider remittances and patient
cost-sharing information), all data classes and data elements included
in a content standard at 45 CFR 170.213 (USCDI), and certain
information about prior authorizations maintained by the payer with a
date of service within 5 years of the request by a patient's new or
concurrent payer. Furthermore, we have defined maintain in the
Interoperability and Patient Access final rule ``to mean the payer has
access to the data, control over the data, and authority to make the
data available through the API'' (85 FR 255380). Payers must
incorporate patient data into the appropriate place where they maintain
that type of information that they generate while covering a patient.
We understand that payers will store that information in a variety of
ways, depending on their own data infrastructure.
Comment: A commenter requested clarification as to how payers
should integrate data into a patient's records if the data from their
previous payer includes information from other individuals who were on
the same coverage plan (for example, a family health plan).
Response: Each of our policies in this final rule are tailored
toward individual patients, not any family members that may be covered
through the same

[[Page 8847]]

benefits. In some cases, applicable law may allow one individual (such
as a parent or guardian) to act as a personal representative for
another individual covered under the same benefits (such as a minor)
and could therefore opt into the Payer-to-Payer API data exchange for
that individual. Regardless, the opt in is patient-specific and a payer
must make the data request based on the individual permission and the
previous/concurrent payer should respond in kind with the individual
patient's record. No data should be shared about any patient that has
not opted in, regardless of whether another patient covered under the
same benefits has opted in.
Comment: A commenter cautioned that when a new payer takes on
another payer's information, this may cause a significant amount of
risk for patients as they may get billed for services that are not
approved under their new payer.
Response: We are not requiring impacted payers to honor another
payer's prior authorization decision, nor do our final rules require
reprocessing claims submitted to previous payers. If payers believe
that sending these data will be confusing for patients, they should
include information in their educational resources that makes clear
what the data exchange is and is not used for.
ii. Data Retention
In the proposed rule, we noted that our proposals would not impact
any payer's data retention requirements. Specifically, we did not
propose to require impacted payers to maintain data for unenrolled
patients any longer or differently than they do today under current
law, regulation, or policy. We understand that if a patient is
uninsured or moves to a payer not subject to this regulation that does
not request information from the previous payer, after a period of
time, the previous payer may discard information, which would make it
unavailable to the patient or other payers in the future.
We acknowledged that imposing requirements that would require
payers to alter their data retention policies based on the actions of
other payers would be a significant burden that would outweigh the
benefits of such a policy. We considered proposing a minimum period
during which a payer must maintain patient records after disenrollment,
such as 1 or 2 years. However, we stated that most payers have policies
in place that would maintain patient data for at least that long, and
thus, such a requirement would be unnecessary and duplicative. We
requested comment on whether our understanding is correct and whether
there is a benefit to considering a data retention requirement in the
future.
Comment: Multiple commenters supported our decision not to propose
or establish a data retention requirement for patient records that
would be different or longer than that required by current laws,
regulations, and policies. Other commenters recommended that CMS set a
minimum data retention timeframe. A commenter suggested that a payer
should have to retain data until they are requested by a subsequent
payer or after a minimum period of years, whichever occurs first. Other
commenters recommended data be maintained for 5 or 10 years after a
patient is unenrolled. Some commenters requested further guidance
regarding the time for which impacted payers should maintain the data
received from previous/concurrent payers.
Response: We do not believe that additional data retention
requirements are necessary at this time, as we do not wish to change or
create conflict with existing rules. For example, under 42 CFR
422.504(d), 438.3(u), and 457.1201(q), MA organizations, Medicaid
managed care plans, and CHIP managed care entities, respectively, must
retain records for at least 10 years. Similarly, most states require 5-
10 years of data retention. Nothing in this final rule would extend
existing data retention requirements or create an obligation for
perpetual maintenance. We emphasize that once a payer receives patient
data from another payer, it becomes part of the patient's record and
should be treated the same as data in the patient record created by the
current payer. There should be no difference for data retention or data
availability, as well as the same obligation to update or correct the
data. The only difference is that payers may attach provenance
information designating where the data originated.
Comment: A commenter noted that a patient's previous payer should
not be required to respond to requests from the patient's current payer
more than 90 days after the patient has disenrolled from the previous
payer.
Response: We disagree with setting a 90-day limit on the initiation
of a payer to payer data exchange by a patient's new payer. Patients
should have access to their data for a significantly longer period than
that. Some patients may not learn about payer to payer exchange for
more than 90 days after the start of coverage. Others may move to
payers that are not subject to this rule and do not have a Payer-to-
Payer API or become uninsured for a period before moving back to an
impacted payer. However, we do expect that a significant majority of
the payer to payer data exchanges will be near the beginning of a
patients' new coverage, particularly if the required patient
educational resources clearly present the option at or shortly after
enrollment. Impacted payers are required to exchange the data they
maintain on a patient, with a date of service within 5 years of the
request. We note that we discuss the timeframe for data retention in
this section, for which we are not changing any regulation or
requirement. We may consider, in future rulemaking, establishing a time
period for the data to be available via Payer-to-Payer API, but such a
timeframe would likely be a matter of years, not days or months.
g. Patient Education Resources
Consistent with our proposals for the Provider Access API, we
proposed that impacted payers (excluding including Medicaid managed
care plans and CHIP managed care entities) would be required to provide
patients with educational resources in non-technical, simple, and easy-
to-understand language, explaining at a minimum: the benefits of the
Payer-to-Payer API data exchange, patients' ability to opt in or
withdraw their permission, and instructions for doing so. We proposed
that state Medicaid and CHIP programs would provide this information to
beneficiaries to be consistent with our proposal that states would be
responsible for collecting beneficiaries' permission for payer to payer
exchange. We proposed that those impacted payers would be required to
provide these educational resources to patients at or before requesting
permission for the Payer-to-Payer API data exchange. As discussed
previously, currently enrolled patients must be given the opportunity
to opt into the payer to payer data exchange and to provide previous/
concurrent payer information before the API compliance dates. We
proposed that impacted payers would be required to provide these
educational resources to those currently enrolled patients at or before
requesting their opt in as well. In addition, we proposed that similar
resources would have to be provided annually to all covered patients in
mechanisms that the payer regularly uses to communicate with patients.
Impacted payers would also be required to post these resources in an
easily accessible location on the payer's public website. We requested
comment on whether it would reduce payers' burden to only be required
to provide these resources annually to any patients who have not opted
in and those with known concurrent payers.

[[Page 8848]]

Because we are finalizing a modification to our proposal and
establishing Payer-to-Payer API compliance dates in 2027 this
requirement to provide educational resources is also being moved from
the proposed 2026.
Comment: Multiple commenters expressed support for CMS's proposed
requirements related to resources to educate patients about the
benefits of data exchange between payers, the patient's right to opt in
and to withdraw their permission, and instructions for doing so.
Multiple commenters supported CMS's proposals to require that patient
educational resources be in non-technical, simple, and easy to
understand language. A commenter noted health literacy is the single
largest barrier to health care access for those with coverage. A
commenter recommended that CMS amend the patient resources requirements
to require impacted payers to write resources at the fourth to sixth
grade reading level.
Response: We are slightly modifying the final regulation text to
require that this information be provided in ``plain language'' instead
of using the longer, more cumbersome phrase ``non-technical, simple,
and easy-to-understand language.'' This modification does not change
the meaning of the requirement that the educational information be non-
technical and easy-to-use, but is intended to be more straightforward
and to encourage impacted payers to follow the Federal Government's
plain language guidelines. Those guidelines were informed by the Plain
Writing Act of 2010, which requires Federal agencies use clear
government communication that the public can understand and use. That
statute applies only to Federal Government agencies, but we believe
that the plain writing guidance developed for the Federal Government
will be useful for impacted payers when developing educational
resources for patients. We also encourage payers to review and utilize
the health literacy resources that the AHRQ makes available on their
website.\86\
---------------------------------------------------------------------------

\86\ Agency for Healthcare Research and Quality (2023, May).
Patient Education and Engagement. Retrieved from https://www.ahrq.gov/health-literacy/patient-education/.
---------------------------------------------------------------------------

We do not believe that it is prudent to establish a specific
``grade level'' requirement. A grade level score is based on the
average length of the words and sentences. Readability formulae vary
and the grade level scores for the same text can differ depending on
how it is used. Furthermore, edits that are done to make text score at
a lower grade level can produce choppy text that lacks cohesion.
However, we do note that 45 CFR part 92 requires impacted payers
(such as health programs or activities under that section) to provide
meaningful access to individuals with limited English proficiency and
accessibility requirements for individuals with disabilities. The
requirements of that part apply to impacted payers, as described at 45
CFR 92.3.
Comment: Multiple commenters recommended that CMS develop
resources, such as standardized language, tools, and delivery models,
that payers could customize to ensure a consistent message to patients
on what will be a confusing and complicated topic. A commenter noted
that if CMS led the development, then the educational resources and
programs for the Payer-to-Payer API could be standardized across
carriers, FFS program administrators, and enrollment administrators to
support consistent messaging and improve engagement with the API.
Response: In an effort to assist payers in meeting these
requirements, we intend to provide templates or outlines for
educational resources after this final rule is published and in time
for payers to review and use prior to the compliance dates. However, we
do not expect those resources to be fully sufficient to meet the
requirements of this rule without additional content and customization
by payers to include their specific processes for patients to opt in or
withdraw their permission. To the extent possible, we encourage payers
to collaborate on standardized resources to ensure consistent messaging
to patients, regardless of the payer with whom they are enrolled.
However, we also expect each payer to have to customize their resources
with their own information and opt in process.
Comment: A commenter suggested that it would benefit both patients
and providers for us to allow third parties, such as an HIE or HIN, to
provide educational resources to patients on the payer's behalf. The
commenter stated that if multiple payers use the same third-party
resources, it could simplify the solution across the industry.
Response: Nothing in this rule will prevent a payer from working
with a third party to develop the educational resources discussed here
or from using subcontractors or downstream entities to the extent that
program-specific laws permit that. As discussed in this section, payers
may use an HIE or HIN to facilitate the Payer-to-Payer API exchange.
However, we encourage payers to make it clear that any resources
disseminated to patients under this requirement are from the payer.
Patients are unlikely to devote attention to resources they receive
from entities with which they are not familiar. While we expect that
patients would recognize the name, logo, and other markings of official
correspondence from their payer, they are unlikely to recognize their
payer's partners. Therefore, while a third party may develop (and send
on the payer's behalf) the required educational resources, we strongly
recommend that these resources be clearly branded as communications
from the patient's payer.
Comment: Multiple commenters highlighted the need to educate
patients specifically on the opt in framework. Specifically, these
commenters encouraged CMS to ensure that those educational resources
are easy for patients to find. Some commenters recommended including
that information in the patient's enrollment resources, while others
disagreed and believe that that information may be easily missed within
the larger quantity of information. A commenter recommended that in
addition to payers, Federal agencies should play a role in patient
education regarding data sharing. Another commenter recommended that
CMS engage in testing patient education and opt in notifications before
the compliance dates.
Response: We agree that it is particularly important for patients
to understand what they are opting in to. The educational information
should highlight the benefits of API-based data exchange and explain
patients' permission rights. Additionally, we emphasize that that
information should be communicated in a way that is conspicuous and
makes clear to patients that this policy provides them rights as
consumers. However, each payer has different processes and modalities
for communicating with patients and we do not want to be prescriptive
in a way that may add unintended and unnecessary burden to payers.
As stated previously, we are committed to providing outlines or
templates for these educational resources. In developing those
resources, we will prioritize using plain language for patients. In
addition, we have stated that Medicare FFS intends to conform to the
requirements of this rule, which includes patient educational
resources. Beyond that, we will consider what role CMS may play in
patient education. However, we know that

[[Page 8849]]

patients have a relationship with their payers and expect to receive
various communications from their payer relating to their coverage.
Therefore, patients are more likely to consider educational resources
that come directly from their payer. Further, these educational
resources will need to include instructions for how patients can opt
into Payer-to-Payer API data exchange and withdraw their permission;
such instructions will need to be tailored to the specific procedures
for each payer. While additional education from Federal agencies may
supplement information from payers, it is not a substitute.
Comment: Multiple commenters recommended that CMS limit the
dissemination of annual Payer-to-Payer API educational resources to
only those patients who have not opted in and those with known
concurrent payers. A commenter recommended that making patient
educational resources available on a payer's website should be
sufficient and CMS should not require payers to send that information
on an annual basis.
Response: While we understand that there may be additional burden
to send all patients educational resources annually, we believe that
such a requirement is necessary. As discussed previously, in section
II.C.3.c.iv. of this final rule, patients must have the opportunity to
withdraw their permission for payer to payer exchange at any time.
While we generally expect exchange between a previous and new payer to
be a one-time transaction, we do allow for the possibility of
additional data exchanges, as discussed in section II.C.3.d.ii. of this
final rule. Therefore, the opportunity to withdraw permission needs to
be offered to all patients at any time. In order to be aware of this
right, patients need to be informed of it. Payers are already required
to send information to patients annually and including information
about payer to payer data exchange should not be a significant burden
to include with those resources. We do not believe that it would serve
patients to have resources and information about the Payer-to-Payer API
data exchanges and the patients' rights to opt into and out of those
data exchanges available only on a payer's website. That would require
patients to affirmatively seek out that information on their own, or to
stumble across it by chance.
Comment: Multiple commenters encouraged CMS to use community
outreach and education campaigns to encourage patients to opt into
sharing their data via the Payer-to-Payer API.
Response: We will look into opportunities to educate patients on
opting into data sharing. As mentioned previously, we are committed to
providing outlines or templates for these educational resources. In
developing those resources, we will prioritize patient comprehension.
Beyond that, we will consider what role CMS may play in patient
education.
4. Payer to Payer Data Exchange in Medicaid and CHIP
a. Inclusion of Medicaid and CHIP Fee-for-Service
As discussed in the CMS Interoperability and Prior Authorization
proposed rule (87 FR 76267), we did not require state Medicaid and CHIP
FFS programs to comply with the payer to payer data exchange policies
in the CMS Interoperability and Patient Access final rule (85 FR
25568).
We proposed to make the payer to payer data exchange policies in
this rule applicable to state Medicaid and CHIP FFS programs. We stated
that requiring state Medicaid and CHIP FFS programs to implement the
Payer-to-Payer API data exchange in this rule would not be as
burdensome as the non-API-based payer to payer data exchange that was
finalized in the CMS Interoperability and Patient Access final rule (85
FR 25524), which we are now rescinding. That is because this new API
would be leveraging the same data and technical standards as the
Patient Access API. State programs should have already implemented
Patient Access APIs and should thus be able to leverage the work done
for that API to make implementing this new API more manageable.
Additionally, in the proposed rule we discussed the various benefits
that the Payer-to-Payer API could produce for state Medicaid and CHIP
programs, including creating efficiencies, reducing burden, and
improving health outcomes (87 FR 76276).
Comment: Commenters supported applying the proposed requirements to
Medicaid and CHIP FFS and agreed that such a policy would benefit
Medicaid and CHIP beneficiaries who are covered by FFS by improving
care coordination and continuity of care. Other commenters stated that
the Payer-to-Payer API would reduce burden on patients and providers
and allow state Medicaid agencies to operate more efficiently.
Response: We appreciate the support for including state Medicaid
and CHIP FFS as impacted payers and are finalizing that proposal.
Comment: A commenter questioned the expected value of the Payer-to-
Payer API to state Medicaid agencies and the return on investment for
the time and effort to implement systems.
Response: Data exchange from one payer to another as patients
transition between payers is a powerful way to support care
coordination and continuity of care during coverage transitions,
particularly in the Medicaid program where patients often churn in and
out of the program and between payers. Electronic data exchange between
payers would support payer operations and a patient's coverage
transition to a new payer efficiently and accurately.
b. Medicaid and CHIP--Seeking Permission Using an Opt In Approach in
the Payer-to-Payer API
We proposed that state Medicaid and CHIP agencies, like other
impacted payers, establish a process to allow beneficiaries to opt into
the payer to payer data exchange. We stated that an opt in framework
means that the beneficiary or their personal representative would need
to affirmatively permit state Medicaid and CHIP agencies to share their
data, and without first obtaining that permission, the agency could not
engage in the payer to payer data exchange for that beneficiary. In
contrast, we proposed an opt out policy for the Provider Access API, in
part, based on the existence of a treatment relationship between the
beneficiary and provider. Specifically, our policy to only require the
Provider Access API data exchange with enrolled Medicaid and CHIP
providers and require a process to attribute a patient to that provider
before data can be exchanged creates a level of assurance for the
Medicaid or CHIP agency that it is sending patient data to an
appropriate party. Two payers exchanging information may not have a
direct relationship but would be exchanging data based on a patient's
separate relationship with each payer. Therefore, in the proposed rule,
we stated that it would make sense for the patient to have a larger
gatekeeping role and be required to provide affirmative permission for
the Payer-to-Payer API data exchange.
We proposed that state Medicaid and CHIP agencies, rather than
their managed care plans or managed care entities, would be responsible
for obtaining the required permission. We also proposed that the
requirement to identify patients' previous/concurrent payers would
apply to state Medicaid and CHIP agencies rather than managed care
plans or managed care entities. For clarity and consistency with
existing Medicaid and CHIP rules, we also

[[Page 8850]]

proposed that a patient's permission would not be necessary to exchange
data between a state Medicaid or CHIP agency and its contracted managed
care plans or entities.
We explained in the proposed rule that the opportunity for newly
enrolling patients to opt in could take place through a single
streamlined application, or at some later point of contact with the
beneficiary prior to enrollment, but in no instance would our proposals
permit a delay in the enrollment process or a beneficiary's coverage.
We sought comments, specifically from states and contracted managed
care plans and entities, how we could establish standards for patient
data exchange for state Medicaid and CHIP agencies and their contracted
managed care plans and entities without creating additional barriers or
burden. We requested comment on the workflow and data exchanges that
occur when a Medicaid or CHIP beneficiary is enrolled into a managed
care plan or entity and the feasibility of sending patient permission
during the enrollment process.
We considered proposing that the Payer-to-Payer API requirements
would not apply for beneficiaries moving between or with concurrent
coverage with a state Medicaid or CHIP agency and its contracted
Medicaid or CHIP (as applicable) managed care plan or entity for the
reasons outlined previously. However, we are concerned that many states
today do not exchange data between their Medicaid or CHIP FFS programs
and managed care programs. We requested comments on whether there are
other ways we can ensure patient data are exchanged in this case in a
manner that would reduce burden on states.
Comment: Multiple commenters recommended that CMS reexamine whether
its interpretation of 42 CFR 431.306(d) and 457.1110(b) would prohibit
Medicaid agencies from participating in HIEs. A commenter encouraged
CMS to explain whether requirements at 42 CFR 431.306(d) and
457.1110(b) prohibits Medicaid and CHIP programs from sharing
beneficiary information with HIEs for the purposes of the Payer-to-
Payer API. The commenters advocated for CMS to make a change to privacy
regulations to support an opt out model consistent with industry
standards. Multiple commenters that agreed with the proposal
specifically recommended that state Medicaid and CHIP agencies leverage
current solutions by HIEs and HINs to implement the proposed opt in
requirement.
Response: We do not agree that 42 CFR 431.306(d) and 457.1110(b)
prohibit Medicaid or CHIP agencies from contracting with an entity that
offers the technology to allow for digital access and transfer of a
patient's medical records, often referred to as an HIE. Section
1902(a)(7) of the Social Security Act (the Act), which our regulations
at 42 CFR part 431, subpart F, implement, requires that a state's
Medicaid plan provide safeguards that restrict the use or disclosure of
information concerning Medicaid applicants and beneficiaries to
purposes directly connected with administration of the state plan. Our
regulations at 42 CFR part 431, subpart F, set forth requirements for
states to safeguard Medicaid applicants' and beneficiaries' information
in accordance with section 1902(a)(7) of the Act, including
requirements for safeguarding the information, what types of
information must be safeguarded, and when and how to release otherwise
safeguarded information. The same requirements also apply to separate
CHIPs through a cross reference at 42 CFR 457.1110(b). The disclosures
of beneficiary data to an HIE contracted to implement and maintain the
required Payer-to-Payer API would be directly related to the
administration of the state plan because sharing beneficiary data
through the Payer-to-Payer API supports the provision of services for
beneficiaries, as described at 42 CFR 431.302(c). States that share
information about Medicaid beneficiaries or former beneficiaries with
their concurrent and new payers support opportunities for improved care
coordination, reduce time needed to evaluate beneficiaries' current
care plans, their health risks, and their health conditions at the time
they enroll with the Medicaid program, or another payer. Further, under
section 1902(a)(4) of the Act, Medicaid agencies may contract with
organizations to enhance the agency's capability for effective
administration of the program.
The regulation at 42 CFR 431.306(d) generally requires states to
obtain permission from an individual Medicaid applicant or beneficiary,
or their personal representative, before responding to a request for
information from an outside source to disclose that applicant's or
beneficiary's data safeguarded under 42 CFR 431.305. State Medicaid and
CHIP agencies may share Medicaid and CHIP beneficiary information with
entities with which the agency has contracted to support the
administration of its Medicaid or CHIP state plan. Such contractors
would not be considered ``outside sources'' because they are contracted
to carry out functions directly related to administration of the state
Medicaid or CHIP plan. Thus, if a Medicaid or CHIP agency contracts
with an HIE to carry out administrative functions of the state's
Medicaid or CHIP program, including implementing and maintaining the
required Payer-to-Payer API, the HIE would not be considered an
``outside source'' and the state Medicaid or CHIP agency could share
Medicaid or CHIP beneficiary information with the HIE for purposes
directly connected to administration of the state plan without prior
permission from the Medicaid or CHIP beneficiary required by 42 CFR
431.306(d) and 457.1110(b), respectively. Regardless, whether a
Medicaid or CHIP agency contracts with an HIE to develop and maintain
the required Payer-to-Payer API, the Medicaid or CHIP agency is
responsible for ensuring the contracted entity implements a Payer-to-
Payer API that meets all regulatory requirements, which includes that
an individual or their representative has provided permission (opted
in) prior to their information being shared with other payers via the
Payer-to-Payer API.
In addition, to receive beneficiaries' information from the
Medicaid or CHIP agency, Medicaid or CHIP providers, plans, or
contractors must be subject to standards of confidentiality comparable
to those of the state Medicaid and CHIP agency in accordance with 42
CFR 431.306(b) and 457.1110(b) respectively. Furthermore, Medicaid
regulation at 42 CFR 434.6(a)(8) requires that each of the state
Medicaid agency's contracts must provide that the contractor safeguards
information about beneficiaries as required by 42 CFR part 431, subpart
F. Under these requirements, if a state Medicaid or CHIP agency
contracted with an HIE or other entity, the contractor would be
required to meet the same standards of confidentiality as the state
Medicaid agency (as set forth in section 1902(a)(7) of the Act and our
implementing regulations at 42 CFR part 431, subpart F), including but
not limited to:
Providing safeguards that restrict the use or disclosure
of information concerning applicants and beneficiaries to purposes
directly connected with the administration of the plan in accordance
with section 1902(a)(7) of the Act and 42 CFR 431.300 and 431.302; and
Not disclosing data to an outside source, such as non-
Medicaid or non-CHIP payers with whom the HIE might exchange data,
without prior permission from the individual in accordance with 42 CFR
431.306(d).

[[Page 8851]]

We did not propose any changes to Medicaid or CHIP confidentiality
regulations at 42 CFR part 431, subpart F, and 42 CFR 457.1110(b), but
we appreciate the comment and will consider it for any future
rulemaking.
Comment: A commenter stated that an opt in process implemented
within its system would not authorize another payer (particularly
payers not subject to this regulation) to release patient information
to the commenter or for the commenter to release a patient's data to a
patient's subsequent payer.
Response: All data received, maintained, used, or shared via this
proposed Payer-to-Payer API must be received, maintained, used, or
shared in a way that is consistent with all applicable laws and
regulations. As discussed previously, our regulation for Medicaid at 42
CFR 431.306 (incorporated via cross reference for CHIP at 42 CFR
457.1110(b)) sets forth certain requirements for release of Medicaid
and CHIP applicant and beneficiary data. Consistent with our proposal,
we are finalizing that when another payer (including a payer not
subject to this final rule) is requesting a former Medicaid or CHIP
beneficiary's information from the state Medicaid or CHIP agency, an
attestation from a requesting payer that the patient or their
representative has opted into data exchange with the requesting payer
(that is, given permission for the Medicaid or CHIP agency to share the
beneficiary's data) is sufficient to meet the requirements at 42 CFR
431.306 and 457.111(b) to allow the state Medicaid or CHIP agency to
respond to the data request, though such permission must be received
prior to the state Medicaid or CHIP agency sharing any beneficiary
data. For more information about how the HIPAA Privacy Rule interacts
with Payer-to-Payer API, see section II.C.3.c.iv.
Comment: Multiple commenters agreed with the proposal for state
Medicaid and CHIP agencies to collect and manage patient decisions to
opt into the payer to payer data exchange when beneficiaries are
enrolled in Medicaid or CHIP managed care. Multiple commenters agreed
that collecting a beneficiary's choice to opt into the payer to payer
data exchanges as part of existing Medicaid and CHIP eligibility and
enrollment processes would be the most effective and technically
feasible approach for most states operating managed care programs in
Medicaid and CHIP and would streamline the process for beneficiaries.
Response: For many reasons, we agree that the state Medicaid or
CHIP program is the appropriate custodian of the patient's permission
record, rather than the particular managed care plan or managed care
entity through which a patient receives Medicaid or CHIP covered
services. A Medicaid or CHIP beneficiary may switch between FFS and
managed care delivery systems within the same state's Medicaid or CHIP
program. Despite these shifts, an eligible beneficiary remains a
beneficiary of the state program. States may also change the Medicaid
or CHIP managed care plans or entities with which they contract. Thus,
a Medicaid or CHIP beneficiary's opt into the payer to payer data
exchange, should be obtained by the state and will apply regardless of
the delivery system in which the beneficiary is enrolled. Furthermore,
we understand that in many states, managed care plans may not have any
contact with beneficiaries prior to their enrollment in the Medicaid
managed care plan or CHIP managed care entity.
We believe the ideal time to allow patients to opt into the payer
to payer data exchange is during their application for Medicaid or
CHIP. As stated previously, obtaining a patient's opt in permission and
identifying the previous/concurrent payer(s) cannot delay an
applicant's eligibility determination or start of coverage. If a state
has all the information necessary to determine an individual's
eligibility before it obtains the individual's permission for the payer
to payer data exchange, the state must determine the individual's
eligibility and enroll the individual in Medicaid or CHIP coverage, if
determined eligible, while continuing to follow the Payer-to-Payer API
requirements as expeditiously as possible post-enrollment.
Because we expect higher rates of patients to opt in when they are
presented with the option at a point when they are already providing
information (such as at application or plan selection), we highly
encourage states to leverage any touchpoints before patients are
enrolled in Medicaid or CHIP rather than expecting patients to opt in
through a separate process.
We are finalizing our proposal to require the state to establish a
process for obtaining opt into the payer to payer data exchange prior
to the state Medicaid or CHIP agency's Payer-to-Payer API compliance
dates, and prior to the enrollment of new beneficiaries after that
date, and that the state Medicaid and CHIP agencies will be responsible
for obtaining the required permission.
To the extent that doing so is consistent with Federal Medicaid and
CHIP requirements, including those at section 1902(a)(7) of the Act and
implementing regulations at 42 CFR part 431, subpart F, and applied to
separate CHIPs through a cross reference at 42 CFR 457.1110(b),
Medicaid and CHIP agencies are welcome to contract with HIEs or HINs,
especially those operating under TEFCA, to facilitate payer to payer
data exchange. Some HIEs may already have the technical framework to
manage patient consent or engage in standardized data exchange via FHIR
APIs in ways that Medicaid or CHIP agencies' systems do not. Nothing in
this rule would prohibit a Medicaid or CHIP agency from partnering with
an HIE to meet its requirements, but Medicaid and CHIP agencies must
continue to comply with all other Federal requirements applicable to
the operation of Medicaid and CHIP.
Comment: Multiple commenters expressed concerns about state
Medicaid and CHIP agencies' resources to collect and manage patient
decisions to opt into the exchange of their data via the Payer-to-Payer
API. A commenter stated that it may need to build separate
functionality to support implementation of the opt in requirement if it
is unable to support the requirement within the state's existing
eligibility system. A commenter noted that it will require significant
work to implement an opt in process in states and territories where the
Medicaid agency does not complete eligibility and enrollment processes
and recommended that CMS ensure an appropriate implementation timeline
in these instances. A commenter suggested that CMS work with states to
implement a consistent solution to avoid inconsistencies in what data
are collected and how to address the concern about resources. Another
commenter specifically expressed that the process to identify a
previous/concurrent payer would be challenging for Medicaid.
Response: We understand and appreciate that state Medicaid and CHIP
agencies will need to create new processes to request a patient's
permission to exchange data and identifying information about their
previous/concurrent payer(s), and then to share that information with
their managed care plans and managed care entities. States have
different eligibility and enrollment processes, and a one-size-fits all
approach may not be optimal. We are not being prescriptive on this
process, as we want each program to implement the requirements in the
least burdensome, most efficient way for them.
We also understand that making changes to applications can be a
significant administrative process, and

[[Page 8852]]

for states where Medicaid or CHIP eligibility is determined by a state
or regional agency other than the Medicaid or CHIP agency, there will
be additional administrative steps to implementation. We are extending
our compliance dates for the Payer-to-Payer API from our proposed 2026
to 2027 in order to provide adequate time for payers to implement these
requirements. Further, there may be other places where a state could
obtain a patient's data exchange permission for the Payer-to-Payer API
data exchange. For instance, a state could leverage an online portal or
app, if beneficiaries frequently use those pathways for other purposes,
such as reporting a change in circumstance or providing information for
eligibility renewal. However, the option should be equally available
for all beneficiaries and if only a small portion of the Medicaid or
CHIP population uses these tools to communicate with the Medicaid or
CHIP agency, that subset would be self-selected for greater technology
literacy and taking this approach could exacerbate inequality.
We note that the single streamlined application, which for Medicaid
and CHIP purposes is described at 42 CFR 435.907(b)(1) and 457.330,
respectively, and is also used for applications through the FFEs,
includes questions about concurrent coverage information. We also
expect that some states that do not use the single streamlined
application already ask for this information for Coordination of
Benefits and Third-Party Liability purposes. We believe that it would
generally make sense to gather permission for payer to payer data
exchange at the point the state collects concurrent payer information.
We note that the patient permission provisions in this rule will apply
only to the payer to payer data exchange discussed here and would not
affect states' ability to perform Coordination of Benefits or Third-
Party Liability activities as they do today.
Comment: Multiple commenters stated that CMS should ensure that
regulatory language clearly makes the opt in requirement applicable to
Medicaid managed care plans.
Response: We intentionally did not include regulatory text
requiring Medicaid managed care plans and CHIP managed care entities to
meet the requirement to collect patient permission for payer to payer
data exchange. As discussed in section II.C.4.b. of this final rule, we
are finalizing that requirement for state Medicaid and CHIP agencies
because we believe that they are the proper entity to hold a patient's
opt in decision. State Medicaid and CHIP agencies may work with their
managed care plans and entities to gather that information, but
ultimately the requirement to gather and maintain that information is
the responsibility of the state Medicaid or CHIP agency. As proposed
and discussed in section II.E.2.a. of this final rule, we are
finalizing that the responsibility to collect patient permission for
the Payer-to-Payer API data exchange is not eligible for exemption from
the API requirements. Therefore, even if a state receives an exemption
from the Payer-to-Payer API, it is still responsible for collecting and
maintaining a record of patient opt in permission for this data
exchange. We note that we are also finalizing that state Medicaid and
CHIP programs, rather than their managed care organizations, are
responsible for providing educational resources at the time of
requesting permission for payer to payer data exchange and for
collecting identifying information about patients' previous/concurrent
payer(s).
Comment: A commenter requested clarification on whether a patient's
opt in permission is required to share data between impacted payers
within the same state Medicaid program. Another commenter asked us to
explain what types of managed care plans are included in this statement
(for example, MCOs, PIHPs, PAHPs, Primary Care Case Managers (PCCMs),
integrated plans for patients dually eligible for Medicare and
Medicaid).
Response: As we explained in the preamble to the proposed rule (87
FR 76238), we know that state Medicaid or CHIP agencies regularly
exchange data with their managed care plans and entities. We do not
intend the opt in requirements for the Payer-to-Payer API to interfere
with or affect this permissible exchange. Medicaid managed care plans,
and CHIP managed care entities are not outside sources as described at
42 CFR 431.306(d), but are part of a state's Medicaid and/or CHIP
programs as a whole, because these entities are contracted to support
the agency's administration of its Medicaid or CHIP state plan.
Specifically, Medicaid managed care plans and CHIP managed care
entities are contracted with the Medicaid state agency to deliver
Medicaid program health care services to beneficiaries under the state
plan.
Hence, we are finalizing our proposal that if a Medicaid or CHIP
agency is exchanging information per our Payer-to-Payer API proposals
with a managed care plan or managed care entity with which they have a
contract, the requirement to obtain patient opt in would not apply. We
consider any plan and entity that has a contract with the state
Medicaid or CHIP agency to deliver Medicaid program health care
services to beneficiaries under the state plan, including state
Medicaid agency contracts with D-SNPs under 42 CFR 422.107, to be part
of the state's Medicaid or CHIP programs, regardless of the coverage
model. We note that this policy and opt in requirement to share data
between impacted payers would not replace regulatory requirements as
described at 42 CFR part 422, including as they relate to integrated D-
SNPs.
We note that permissible data exchange only covers data that
facilitate that plan's contracted services. For instance, it would be
inappropriate to share patient data with a managed care plan or entity
other than the one with which the patient is enrolled. The other Payer-
to-Payer API requirements, such as the requirement to use a FHIR API
and the authorization and authentication protocols would apply to data
exchange required in this final rule between state Medicaid and CHIP
agencies and their managed care plans or managed care entities. The
exchange must also not be prohibited by other law.
c. Federal Matching Funds for State Medicaid and CHIP Expenditures on
Implementation of Payer to Payer Data Exchange
In section II.E. of this final rule, we discuss Federal matching
funds for certain state Medicaid and CHIP FFS programs' expenditures
related to implementation of the payer to payer data exchange (this was
also addressed in the proposed rule at 87 FR 76278).
d. Medicaid Expansion CHIP
In section II.E. of this final rule, we discuss implementation for
states with Medicaid Expansion CHIP programs (this was also addressed
in the proposed rule at 86 FR 76279).
5. Extensions, Exemptions, and Exceptions
See section II.E. of this final rule for a discussion of extensions
and exemptions and the final policies for the Payer-to-Payer API for
state Medicaid and CHIP FFS programs and exceptions for the Payer-to-
Payer API for QHP issuers on the FFEs (this was also addressed in the
proposed rule at 86 FR 76279).
BILLING CODE 4150-28-P

[[Page 8853]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.003

[[Page 8854]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.004

BILLING CODE 4150-28-C

[[Page 8855]]

6. Final Action
After considering the comments received, and for the reasons
discussed in the CMS Interoperability and Prior Authorization proposed
rule and our response to those comments (as summarized previously), we
are finalizing our proposal with the following modifications:
Impacted payers must implement and maintain a Payer-to-
Payer API beginning in 2027 (by January 1, 2027, for MA organizations
and state Medicaid and CHIP FFS programs; by the rating period
beginning on or after January 1, 2027, for Medicaid managed care plans
and CHIP managed care entities; and for plan years beginning on or
after January 1, 2027, for QHP issuers on the FFEs) rather than in
2026.
Impacted payers are not required to share the quantity of
items or services used under a prior authorization via the Payer-to-
Payer API.
The data exchange between a previous payer and a new payer
is limited to data with a date of service within the previous 5 years.
Impacted payers are required to request patients'
permission for payer to payer data exchange and identifying information
about patients' previous/concurrent payers no later than 1 week after
the start of coverage, as that term is defined for each type of
impacted payer, rather than at enrollment.
See further discussion for the exact details of the final
requirements for impacted payers.
We are finalizing the rescission of the payer to payer data
exchange policy previously finalized in the CMS Interoperability and
Patient Access rule (85 FR 25568) at 42 CFR 422.119(f)(1) and
438.62(b)(1)(vi) and (vii) and 45 CFR 156.221(f)(1).
We are finalizing a requirement that, beginning in 2027 (by January
1, 2027, for MA organizations and state Medicaid and CHIP FFS programs;
by the rating period beginning on or after January 1, 2027, for
Medicaid managed care plans and CHIP managed care entities; and for
plan years beginning on or after January 1, 2027, for QHP issuers on
the FFEs), impacted payers must implement and maintain a Payer-to-Payer
API that is conformant with certain technical standards, documentation
requirements, and denial or discontinuation policies. Specifically,
those technical standards are HL7 FHIR R4 at 45 CFR 170.215(a)(1), US
Core IG at 45 CFR 170.215(b)(1)(i), and Bulk Data Access IG at 45 CFR
170.215(d)(1).
We are also finalizing a requirement that, by the deadlines,
impacted payers (except Medicaid managed care plans and CHIP managed
care entities) must establish and maintain a process to gather patient
permission for payer to payer data exchange no later than 1 week after
the start of coverage. We are finalizing an opt in framework whereby a
patient or personal representative must affirmatively agree to allow
that data exchange. Impacted payers must also have a process for
patients to change their permission at any time.
We are finalizing a requirement that, by the deadlines, impacted
payers must establish and maintain a process to identify a patient's
previous/concurrent payer(s) no later than 1 week after the start of
coverage. As part of this process, impacted payers are required to
allow a patient to report multiple previous/concurrent payers if they
had (or continue to have) concurrent coverage. If a patient does report
multiple previous payers, impacted payers are required to request that
patient's data from all previous/concurrent payers. If a patient does
not respond or additional information is necessary, the impacted payer
must make reasonable efforts to engage with the enrollee to collect
this information.
We are also finalizing a requirement that, no later than the
compliance dates, impacted payers must establish and maintain a process
to gather permission and previous/concurrent payer(s) information from
patients who are already enrolled.
We are finalizing a requirement that, by the deadlines, impacted
payers must request a patient's data from a patient's previous/
concurrent payer(s) no later than 1 week after the payer has sufficient
identifying information and the patient has opted in. Impacted payers
must also request data from a patient's previous/concurrent payers(s)
within 1 week of that patient's request to do so. Impacted payers must
include an attestation with this request for data affirming that the
patient is enrolled with the requesting payer and has opted into the
data exchange in a manner that meets the legal requirements.
Additionally, we are finalizing a requirement that, by the
deadlines, when an impacted payer has sufficient identifying
information and the patient has opted in, they must request data from
any concurrent payers at least quarterly. Impacted payers who receive a
request for a patient's data from a known concurrent payer must respond
with the required data within 1 business day of receiving the request.
We are finalizing a requirement that, by the deadlines, upon
receiving a request that meets the legal requirements, impacted payers
must make any of the required information that they maintain available
to new payers no later than 1 business day after receiving the request.
We are finalizing a requirement that, by the deadlines, impacted
payers must make available via the Payer-to-Payer API, by request from
payer that meets certain requirements, claims and encounter data
(excluding provider remittances and patient cost-sharing information),
all data classes and data elements included in a content standard at 45
CFR 170.213, and certain information about prior authorization requests
and decisions (excluding those for drugs and those that were denied)
that the payer maintains with a date of service within 5 years of the
request. The required information is--
The prior authorization status;
The date the prior authorization was approved;
The date or circumstance under which the prior
authorization ends;
The items and services approved; and
Structured and unstructured administrative and clinical
documentation submitted by a provider.
We are finalizing a requirement that impacted payers are required
to make this information about prior authorizations available for the
duration that the authorization is active and for at least 1 year after
the prior authorization's last status change.
We are finalizing a requirement that, by the deadlines, information
received by an impacted payer through the payer to payer data exchange
must be incorporated into the payer's patient record.
We are finalizing a requirement that, by the deadlines, impacted
payers (except Medicaid managed care plans and CHIP managed care
entities) must provide educational resources to their patients about
the Payer-to-Payer API in plain language. These resources must include
information about the benefits of Payer-to-Payer API data exchange, the
patient's ability to opt in or withdraw that permission, and
instructions for doing so. Impacted payers must make this information
available to patients when requesting the opt in decision. Thereafter,
impacted payers must provide this information to patients annually, in
mechanisms the payer ordinarily uses to communicate with patients.
These resources must also be available in an easily accessible location
on payers' public websites.
These final policies apply to MA organizations, state Medicaid and
CHIP FFS programs, Medicaid managed care plans, CHIP managed care
entities (excluding NEMT PAHPs), and QHP

[[Page 8856]]

issuers on the FFEs at the CFR sections listed in Table D1.
7. Statutory Authorities for Payer to Payer Data Exchange Proposals
We note that we received no public comments on the statutory
authorities for our Payer-to-Payer API policies.
a. MA Organizations
For MA organizations, we are finalizing these Payer-to-Payer API
requirements under our authority at section 1856(b) of the Act to adopt
by regulation standards consistent with and to carry out Part C of
Title XVIII of the Act (such as section 1852(d)(1)(A) of the Act). In
addition, section 1857(e)(1) of the Act authorizes the Secretary to
adopt contract terms and conditions for MA organizations that are
necessary, appropriate, and not inconsistent with the statute. In
total, the regulations we are adopting in this final rule for MA
organizations and MA plans are necessary and appropriate because they
address and facilitate continued access to enrollees' medical records
and health information when they change payers, which will support
consistent and appropriate coordination of coverage when enrollees have
concurrent payers and will support coordination of care and
continuation of active courses of treatment when enrollees change
payers.
In regulations establishing the MA program,\87\ CMS described it as
a program designed to: provide for private plan options available to
Medicare beneficiaries, especially those in rural areas, enrich the
range of benefit choices, provide incentives to plans and add
specialized plans to coordinate and manage care in ways that
comprehensively serve those with complex and disabling diseases and
conditions, use competition to improve service and benefits, invest in
preventive care, hold costs down in ways that attract enrollees, and
advance the goal of improving quality and increasing efficiency in the
overall health care system. This final rule supports these goals and
enables the MA program to advance services for its enrollees by
providing greater access to information in a way that will improve care
management for payers, providers, and the patient.
---------------------------------------------------------------------------

\87\ Medicare Program: Establishment of the Medicare Advantage
Program, 70 FR 4588 (January 28, 2005) (to be codified at 42 CFR
part 417).
---------------------------------------------------------------------------

Section 1856(b) of the Act requires the Secretary to establish
regulatory standards for MA organizations and plans that are consistent
with, and carry out, Part C of the Medicare statute, Title XVIII of the
Act. The Payer-to-Payer API proposals support MA organizations sharing
certain claims, encounter, and clinical data, as well as prior
authorization requests and decisions, with another payer that, as
identified by the enrollee, has or does cover the enrollee. Such
exchanges of data about patients could facilitate continuity of care
and enhance care coordination. As discussed for the Provider Access API
in section II.B. of this final rule, allowing payers to share health
information for one or more patients at once could increase efficiency
and simplicity of administration. Though we are not requiring payers to
share data for more than one patient at a time, there are efficiencies
to doing so, both for communicating information and for leveraging
available technology.
Further, providing MA organizations with additional data about
their enrollees through these data exchanges will increase the scope of
data that the MA organizations must make available to enrollees through
the Patient Access API. It will give payers access to all their
enrollees' information with limited effort and enable the payer to then
make that information available to providers and to enrollees through
the Provider Access and Patient Access APIs. It may reduce the amount
of time needed to evaluate a patient's current care plan and possible
implications for care continuity, which may introduce efficiencies and
improve care. As discussed earlier, if a new payer receives information
and documentation about prior authorization requests from a previous
payer, the new payer can review this information and determine that a
new prior authorization may not be necessary for an item or service
that was previously approved. Instead, the same care may be continued,
reducing burden on both payers and providers, and improving patient
care. While the statutory provisions governing the MA program do not
explicitly address sharing data with other payers that cover or have
covered an enrollee, the benefits to be gained by sharing data make
adoption of Payer-to-Payer API policies necessary and appropriate for
the MA program. Further, requiring use of the API and the
specifications for the data to be shared provides a step toward greater
interoperability among payers. Ultimately, using the Payer-to-Payer API
is anticipated to ensure that payers receive patient information in a
timely manner, which could lead to more appropriate service utilization
and higher patient satisfaction. Such goals are consistent with the MA
statute.
Section 1852(h) of the Act requires MA organizations to provide
their enrollees with timely access to medical records and health
information as far as MA organizations maintain such information. As
technology evolves to allow for faster, more efficient methods of
information transfer, so do expectations as to what is generally
considered ``timely.'' Currently, consumers across public and private
sectors have become increasingly accustomed to accessing a broad range
of personal records, such as bank statements, credit scores, and voter
registrations, immediately through electronic means and with updates
received in near real-time. Thus, we to align our standards with
current demands, we must take steps for MA enrollees to have immediate,
electronic access to their health information and plan information. The
information exchanged via the Payer-to-Payer API will ultimately be
accessible to enrollees via the Patient Access API and will therefore
improve timeliness to medical records and health information as
enrollees will no longer have to spend time contacting previous payers
to access their information. These data will be accessible as needed by
the enrollee's current payer and would therefore support timely access.
Section 1852(d)(1)(A) of the Act requires MA organizations to, as a
condition of using a network of providers, make covered benefits
available and accessible to enrollees in a manner which assures
continuity in the provision of benefits. In implementing section
1852(d)(1)(A) of the Act, we adopted a regulation, at 42 CFR
422.112(b), that requires MA organizations to ensure the continuity of
care and integration of services through arrangements with providers
that include procedures to ensure that the MA organization and the
contracted providers have access to the information necessary for
effective and continuous patient care. Consistent with section
1852(d)(1)(A) of the Act, the final requirement here for MA
organizations to implement and maintain a Payer-to-Payer API will
facilitate exchanges of information about enrollees that are necessary
for effective and continuous patient care. Under this final rule, the
data received from other impacted payers will become part of the data
the MA organization maintains and will therefore be available (subject
to other law authorizing the disclosure) to providers via the Provider
Access API discussed in section II.B. of this final rule; the data
could then be used for treatment and coordination of care purposes.
The finalized policies in this rule are necessary, appropriate, and
consistent

[[Page 8857]]

with Part C of Title XVIII of the Act. Overall, establishing these
regulatory requirements for MA organizations will improve enrollee's
quality of care by ensuring that they do not lose their patient records
when they change payers.
b. Medicaid and Children's Health Insurance Program
Our provisions in this section fall generally under our authority
in the following provisions of the Act.
Section 1902(a)(4) of the Act, which requires that a state
Medicaid plan provide such methods of administration as are found by
the Secretary to be necessary for the proper and efficient operation of
the state Medicaid plan.
Section 1902(a)(8) of the Act, which requires states to
ensure that Medicaid services are furnished with reasonable promptness
to all eligible individuals.
Section 1902(a)(19) of the Act, which requires states to
ensure that care and services are provided in a manner consistent with
simplicity of administration and the best interests of the recipients.
The final requirements related to the Payer-to-Payer API are
authorized by sections 1902(a)(4), (a)(8), and (a)(19) of the Act for
the following reasons. First, because the Payer-to-Payer API is
designed to enable efficient exchange of data between payers, we
anticipate that it will help state Medicaid programs improve the
efficiencies and simplicity of their own operations under a Medicaid
state plan, consistent with sections 1902(a)(4) and (a)(19) of the Act.
It will give Medicaid agencies and their managed care plans access to
their beneficiaries' information in a standardized manner and enable
states to then make that information available to providers and
patients through the Patient Access and Provider Access APIs. It may
also reduce the amount of time needed to evaluate a patient's current
care plan and have possible implications for care continuity, which may
introduce efficiencies and improve care. Receiving patient information
at the start of coverage will lead to more appropriate service
utilization and higher beneficiary satisfaction by Medicaid agencies
and those managed care plans considered impacted payers under this
final rule by supporting efficient care coordination and continuity of
care, which could lead to better health outcomes.
As discussed in section II.C.3.b. of this final rule, when a state
Medicaid program has access to a previous payer's prior authorization
decisions, the Medicaid program may choose to accept the existing
decision and support continued patient care without requiring a new
prior authorization or duplicate tests. This information exchange might
also improve care continuity for beneficiaries who have concurrent
coverage in addition to Medicaid by improving the coordination of
health coverage they receive, reducing gaps, or duplication of
coverage.
Our final rule is expected to help states and managed care plans
furnish Medicaid services with reasonable promptness and in a manner
consistent with beneficiaries' best interests, consistent with sections
1902(a)(8) and (a)(19) of the Act. A significant portion of Medicaid
beneficiaries experience coverage changes and churn in a given
year.\88\ Therefore, exchanging this information with a beneficiary's
next payer may also better support care continuity for Medicaid
beneficiaries. When states share information about Medicaid
beneficiaries or former beneficiaries with their concurrent and next
payers, they can support opportunities for improved care coordination
for Medicaid beneficiaries and former beneficiaries. Exchanging
information about Medicaid beneficiaries and former beneficiaries
between payers might also reduce the amount of time needed to evaluate
beneficiaries' current care plans, their health risks, and their health
conditions at the time they enroll with the Medicaid program, as well
as with another payer. This information exchange might be of particular
value to improve care continuity for beneficiaries who might churn into
and out of Medicaid coverage. The final rule may also improve the
provision of Medicaid services, by potentially helping to ensure that
Medicaid beneficiaries who may require coordinated services with
concurrent payers can be identified and provided case management
services, reduce duplication of services, and improve the coordination
of care, as appropriate.
---------------------------------------------------------------------------

\88\ Churning occurs when people lose Medicaid coverage and then
re-enroll within a short period of time. Medicaid beneficiaries
frequently experience churning. See U.S. Department of Health and
Human Services, Assistant Secretary for Planning and Evaluation
(2021, April 12). Medicaid churning and continuity of care: Evidence
and policy considerations before and after the COVID-19 pandemic
(issued April 12, 2021). Available at: https://aspe.hhs.gov/reports/medicaid-churning-continuity-care.
---------------------------------------------------------------------------

In addition, section 1902(a)(7) of the Act requires that states
must provide safeguards that restrict the use or disclosure of
information concerning Medicaid applicants and beneficiaries to
purposes that are directly connected with the administration of the
Medicaid state plan. The implementing regulations at 42 CFR part 431,
subpart F, for section 1902(a)(7) of the Act list purposes that CMS has
determined are directly connected with administration of Medicaid state
plans (42 CFR 431.302) and require states to provide safeguards meeting
certain requirements to restrict uses and disclosures of Medicaid
beneficiary data, including requirements about releasing applicant and
beneficiary information at 42 CFR 431.306.
Requiring the data described in this section to be shared via the
Payer-to-Payer API is consistent with states' requirements to provide
safeguards meeting certain requirements to share these data since it is
related to providing services for beneficiaries, a purpose listed at 42
CFR 431.302(c). As described previously in sections II.A.5.b. and
II.B.6.b. of this final rule related to authority under sections
1902(a)(8) and 1902(a)(19) of the Act, states that share information
about Medicaid beneficiaries or former beneficiaries with their
concurrent and next payers, may support opportunities for improved care
coordination, reduction in the amount of time needed to evaluate
beneficiaries' current care plans, their health risks, and their health
conditions at the time they enroll with the Medicaid program, as well
as with another payer. This information exchange might be of particular
value to improve care continuity for beneficiaries who churn into and
out of Medicaid coverage, described in more detail previously. When
state Medicaid agencies share medical records or any other health or
enrollment information pertaining to individual beneficiaries, they
must comply with the requirements of 42 CFR part 431, subpart F,
including 42 CFR 431.306.
For Medicaid managed care, and in addition to the general
authorities cited previously regarding Medicaid programs, the finalized
exchange of adjudicated claims and encounter data, all data classes and
data elements included in a content standard at 45 CFR 170.213 (USCDI),
and certain information about prior authorizations maintained by the
payer with a date of service within 5 years of the request by a
patient's new or concurrent payer will greatly enhance an MCO's,
PIHP's, or PAHP's ability to fulfill its obligations under 42 CFR
438.208(b), which require them to: implement procedures to deliver care
to and coordinate services including ensuring that each enrollee has an
ongoing source of appropriate care; coordinate services between
settings of care, among Medicaid programs, and with community and

[[Page 8858]]

social support providers; make a best effort to conduct an initial
screening of each enrollee's needs; and share with the state or other
MCOs, PIHPs, and PAHPs serving the enrollee the results of any
identification and assessment of that enrollee's needs to prevent
duplication of those activities. The data provided via the Payer-to-
Payer API in this final rule will give managed care plans the
information needed to perform these required functions much more
easily, thus enhancing the effectiveness of the care coordination, and
helping enrollees receive the most appropriate care in an effective and
timely manner.
For CHIP, we finalized these requirements under our authority in
section 2101(a) of the Act, which states that the purpose of Title XXI
of the Act is to provide funds to states to provide child health
assistance to uninsured, low-income children in an effective and
efficient manner that is coordinated with other sources of health
benefits coverage. The provisions in this final rule can strengthen our
ability to fulfill these statutory obligations in a way that recognizes
and accommodates using electronic information exchange in the health
care industry today and will facilitate a significant improvement in
the delivery of quality health care to our beneficiaries.
As with the Medicaid FFS and Medicaid managed care programs, the
provisions in this section of the final rule for CHIP FFS and CHIP
managed care entities require using a Payer-to-Payer API to exchange
claims, encounter, clinical and prior authorization data at a
beneficiary's request, or any time a beneficiary changes payers, using
a FHIR API. The current payer can use data from the previous payer to
respond to a request for a prior authorization more effectively or
accurately, because under this final rule, a new payer will have
historical claims or clinical data upon which they may review a request
with more background data. Access to information about new patients
will enable appropriate staff within the CHIP program to coordinate
care and conduct care management more effectively because they will
have better data available to make decisions for planning. In many
cases, patients do not remember what services they have had, or other
possibly relevant encounters that could help payers manage their care.
This final rule is consistent with the goal of providing more informed
and effective care coordination, which will help to ensure that CHIP
services are provided in a way that supports quality care, which aligns
with section 2101(a) of the Act.
Finally, the safeguards for applicant and beneficiary information
at 42 CFR part 431, subpart F, are also applicable to CHIP through a
cross reference at 42 CFR 457.1110(b). As discussed previously for
Medicaid, CHIP agencies' data exchange through the Payer-to-Payer API
is related to providing services to beneficiaries, which is described
at 42 CFR 431.302(c) as a purpose directly related to state plan
administration. We remind states that when they share medical records
or any other health or enrollment information pertaining to individual
beneficiaries, they must comply with the privacy protections at 42 CFR
457.1110 and the release of information provisions at 42 CFR 431.306.
c. Qualified Health Plan Issuers on the Federally-Facilitated Exchanges
For QHP issuers on the FFEs, we finalized these new requirements
under our authority in section 1311(e)(1)(B) of the Affordable Care
Act, which affords the Exchanges the discretion to certify QHPs if the
Exchange determines that making available such health plans through the
Exchange is in the interests of qualified individuals in the state in
which the Exchange operates.
Requiring QHP issuers on the FFEs to implement and maintain a
Payer-to-Payer API will allow the seamless flow from payer to payer of
adjudicated claims, and encounter data, all data classes and data
elements included in a standard at 45 CFR 170.213 (USCDI), and certain
information about prior authorizations, that are maintained by the
payer with a date of service within 5 years of the request by a
patient's new or concurrent payer. Ensuring a means for an enrollee's
new issuer to electronically obtain the enrollee's claims, encounter,
and other data, as well as prior authorization information with
corresponding medical records, from the previous issuer will reduce
administrative burden and result in more timely and efficient care
coordination and responses to prior authorization requests.
We believe that it is in the interest of qualified individuals that
QHP issuers on the FFEs have systems in place to send information
important to care coordination to a departing enrollee's new payer, and
that QHP issuers on FFEs also have systems in place to receive such
information from other payers on behalf of new and concurrent
enrollees, as appropriate and consistent with the provisions in this
section. Having patient information at the beginning of a new plan may
assist the new payer in identifying patients who need care management
services, which could reduce the cost of care. We encourage SBEs to
consider whether a similar requirement should be applicable to QHP
issuers participating in their Exchange.
Though we are not requiring the exchange of all enrollees' data at
one time between impacted payers, we encourage QHP issuers on the FFEs
to use the Bulk Data Access IG for the Payer-to-Payer API once it is
available, as it will improve the efficiency and simplicity of data
transfers between issuers by enabling the exchange of all data for all
patients at once. The opportunity to support the exchange of data from
multiple patient records at once, rather than data for one patient at a
time, may be cost effective for the issuers.

D. Prior Authorization API and Improving Prior Authorization Processes

1. Background
This section of the final rule addresses the topic of prior
authorization and includes both technical and operational requirements
intended to improve the prior authorization process for payers,
providers, and patients. Here, we finalize our proposals for payers to
implement and maintain an API to support and streamline prior
authorization processes; respond to prior authorization requests within
certain timeframes; provide a specific reason for prior authorization
denials; and publicly report on prior authorization approvals, denials,
and appeals.
In the CMS Interoperability and Prior Authorization proposed rule
(87 FR 76286) we provided a comprehensive review of the work HHS
conducted regarding prior authorization processes and their associated
burden to identify the primary issues that needed to be addressed to
alleviate the burdens of these processes on patients, providers, and
payers. We cited studies from ONC \89\ which highlighted the burdens
associated with prior authorization including difficulty determining
payer-specific requirements for items and services that require prior
authorization; inefficient use of provider and staff time processing
prior authorization requests and information (sending and receiving)
through fax, telephone, and web portals;

[[Page 8859]]

and unpredictable wait times to receive payer decisions.
---------------------------------------------------------------------------

\89\ Office of the National Coordinator for Health Information
Technology (2020). Strategy on Reducing Burden Relating to the Use
of Health IT and EHRs. Retrieved from https://www.healthit.gov/topic/usability-and-provider-burden/strategy-reducing-burden-relating-use-health-it-and-ehrs.
---------------------------------------------------------------------------

We referenced American Medical Association (AMA) physician surveys
from 2018, 2020, and 2022 \90\ which noted issues with prior
authorization, and we used these studies to estimate the costs and
savings for this final rule. Please see the CMS Interoperability and
Prior Authorization proposed rule (87 FR 76286-76287) for the detailed
context of these industry surveys as well as the reports from the 2019
meetings of the two Federal advisory committees, the Health Information
Technology Advisory Committee (HITAC) \91\ and the National Committee
on Vital and Health Statistics (NCVHS),\92\ which conducted joint
hearings to discuss persistent challenges with prior authorization
workflows and standards; and the follow up 2020 task force on the
Intersection of Clinical and Administrative Data (ICAD) Task Force at
87 FR 76287.
---------------------------------------------------------------------------

\90\ American Medical Association (2022). AMA prior
authorization (PA) physician survey. Retrieved from https://www.ama-assn.org/system/files/prior-authorization-survey.pdf.
\91\ Office of the National Coordinator for Health Information
Technology (2023). Health Information Technology Advisory Committee
(HITAC). Retrieved from https://www.healthit.gov/topic/federal-advisory-committees/health-information-technology-advisory-committee-hitac-history.
\92\ National Committee on Vital and Health Statistics (2022).
Charter. Retrieved from https://ncvhs.hhs.gov/about/charter/.
---------------------------------------------------------------------------

We use the term prior authorization to refer to the process by
which a provider must obtain approval from a payer before providing
certain covered items and services to receive payment for delivering
those items or services to a covered individual. As we stated in the
CMS Interoperability and Prior Authorization proposed rule, prior
authorization has an important place in the health care system, but the
process of obtaining prior authorization can be challenging for
patients, providers, and payers. Interested parties, including payers
and providers, say that dissimilar payer policies, inconsistent use of
electronic standards, and other technical barriers have created
provider workflow challenges and an environment in which the prior
authorization process is a primary source of burden for both providers
and payers, a major source of burnout for providers, and can create a
health risk for patients if inefficiencies in the process cause delays
in medically necessary care. The prior authorization policies in this
final rule apply to any formal decision-making process through which
impacted payers render an approval or denial determination in response
to prior authorization requests based on the payer's coverage
guidelines and policies before services or items are rendered or
provided.
As discussed in section I.D. of this final rule, we exclude drugs
from the provisions in this section, meaning any drugs that could be
covered by the impacted payers affected by these provisions. Thus, the
policies herein do not apply to prescription drugs that may be self-
administered, administered by a provider, or that may be dispensed or
administered in a pharmacy or hospital, or OTC drugs that may be
covered by an impacted payer. We include a definition of drugs for
purposes of this exclusion for each impacted payer in the CFR where
applicable to provisions for implementation of the Prior Authorization
API. For MA organizations, the definition of drugs also includes any
products that constitute a Part D drug, as defined by 42 CFR 423.100,
and are covered under the Medicare Part D benefit by MA-PDs; this part
of the definition specific to MA organizations provides a clear
dividing line for MA-PD plans that must comply with this new rule.
However, payers may voluntarily incorporate their business rules for
prior authorizations for drugs using the Prior Authorization API now
being finalized in this rule.
As noted in section I.D., although Medicare FFS is not directly
affected by this final rule, we will evaluate opportunities to improve
automation of prior authorization processes in the Medicare FFS program
as feasible.
We received nearly 900 letters in response to the CMS
Interoperability and Prior Authorization proposed rule, with hundreds
of individual comments specific to the importance of the topic of prior
authorization and the critical timing of addressing this issue. Most of
the comments were relevant to the proposals and others were out of
scope. The majority of commenters supported our proposals which are
intended to mitigate longstanding issues with prior authorization
processes and many commenters stressed the importance of finalizing the
policies in this final rule as soon as practicable to resolve patient
access to care issues. Some commenters identified concerns with the
timing of compliance for the policies (too soon or too late), with
prior authorization decision timeframes (too short or too long), and
with reporting of metrics (too little or too much). We carefully
reviewed each comment and considered the input to inform the policies
now being described in this final rule. To be fully responsive to the
public comment process, yet avoid creating an overwhelming final rule,
we have consolidated input from all of the comments and summarized the
contents with our responses for each provision. We value the diverse
commentary provided by all interested parties as the volume and scope
helped shape our approach to these final policies which advance our
commitment to interoperability, burden reduction, process improvement
for prior authorization, and transparent rulemaking. Comments that were
out of scope for this final rule are not addressed here.
Comment: Multiple commenters stated that, while prior
authorizations may improve the safety or efficiency of care in some
circumstances, they can lead to negative effects for patients and
providers. A commenter suggested that CMS implement a broader set of
changes to prior authorization processes to correct current abuses,
specifically noting that improving the speed of prior authorizations
without addressing the content of prior authorization requests will not
improve outcomes of inappropriate use of prior authorizations. Another
commenter recommended that CMS further evaluate prior authorization
burdens and make additional proposals.
Response: We appreciate that there are still concerns about the
general use of prior authorization in the health care system. However,
prior authorization continues to have a place in the health care system
and can support functions such as utilization management, cost-
effective care delivery, patient safety, and preventing unnecessary
treatment. The policies we are finalizing in this rule are intended to
improve the transparency and efficiency of the process.
Regarding suggestions for us to implement broader policy changes
for prior authorization, we acknowledge that Federal policies alone
cannot control all payer specific processes or patient health outcomes.
Policies must be applied with good medical judgment and review, and we
reiterate that we, in the administration of its programs \93\ and
implementation of programmatic authority, continue to evaluate
opportunities for future rulemaking to alleviate burdens, mitigate
harm, and improve patient care. For example, in the CY 2024 MA and Part
D final rule (88 FR 22120), we finalized several provisions to ensure
that utilization management tools, including prior authorization
requirements, are used in ways that ensure timely and appropriate
access to medically necessary care for

[[Page 8860]]

beneficiaries enrolled in MA plans.\94\ Specifically, we explained
current rules related to acceptable coverage criteria for basic
benefits that require MA organizations to comply with national coverage
determinations (NCDs), local coverage determinations (LCDs), and
general coverage and benefit conditions included in Traditional
Medicare regulations. In addition, under new regulations adopted in
that final rule, when coverage criteria are not fully established, MA
organizations may create internal coverage criteria based on current
evidence in widely used treatment guidelines or clinical literature
made publicly available to us, enrollees, and providers. The CY 2024 MA
and Part D final rule also streamlines prior authorization
requirements, including adding continuity of care requirements and
reducing disruptions for beneficiaries. First, we finalized that prior
authorization policies for coordinated care plans may only be used to
confirm the presence of diagnoses or other medical criteria that are
the basis for coverage determinations and/or ensure that an item or
service is medically necessary based on standards specified in that
final rule (see 42 CFR 422.138(b)). Second, we finalized that for MA
coordinated care plans,\95\ an approval granted through prior
authorization processes must be valid for as long as medically
necessary to avoid disruptions in care in accordance with applicable
coverage criteria, the patient's medical history, and the treating
provider's recommendation, and that plans provide a minimum 90-day
transition period when an enrollee who is currently undergoing an
active course of treatment switches to a new MA plan or is new to MA
(see 42 CFR 422.112(b)(8)). Finally, to ensure prior authorization and
other utilization management policies are consistent with CMS rules, we
finalized a requirement that all MA plans that use utilization
management policies must establish a Utilization Management Committee
to review all utilization management policies, including prior
authorization, annually and ensure they are consistent with regulatory
standards for MA plan coverage, including compliance with current,
Traditional Medicare's NCDs and LCDs (see 42 CFR 422.137).
---------------------------------------------------------------------------

\93\ CMS's oversight and administration authority and roles for
MA, Medicaid, CHIP, and the FFEs vary with each program.
\94\ National Archives (2022, December 27). Federal Register.
Retrieved from https://www.federalregister.gov/documents/2022/12/27/2022-26956/medicare-program-contract-year-2024-policy-and-technical-changes-to-the-medicare-advantage-program.
\95\ An MA coordinated care plan is a plan that includes a
network of providers that are under contract or arrangement with the
organization to deliver the benefit package approved by CMS; this
includes MA plans that are HMOs, PPOs, and MA plans for special
needs individuals.
---------------------------------------------------------------------------

a. Compliance Dates
We proposed compliance dates for most impacted payers in 2026 (by
January 1, 2026, for MA organizations and state Medicaid and CHIP FFS
programs; by the rating period beginning on or after January 1, 2026,
for Medicaid managed care plans and CHIP managed care entities; and for
plan years beginning on or after January 1, 2026, for QHP issuers on
the FFEs). There was one exception for some of the Medicaid FFS fair
hearing and notice requirements, as discussed in the CMS
Interoperability and Prior Authorization proposed rule (87 FR 76299 and
76300), which would take effect upon the effective date of this final
rule.
Based on commenter feedback, we are extending the compliance dates
for the Prior Authorization API for all impacted payers consistent with
the compliance dates for the Provider Access and Payer-to-Payer APIs to
2027 (by January 1, 2027, for MA organizations and state Medicaid and
CHIP FFS programs; by the rating period beginning on or after January
1, 2027, for Medicaid managed care plans and CHIP managed care
entities; and for plan years beginning on or after January 1, 2027, for
QHP issuers on the FFEs). Throughout this rule, we generally refer to
these compliance dates as ``in 2027'' for the various payers. The prior
authorization business process improvements, or those provisions that
do not require API development or enhancement, including the
requirement to communicate a specific reason for a denial, reduced
decision timeframes for standard and expedited prior authorization
decisions, and public reporting of certain prior authorization metrics
are being finalized as proposed with a compliance dates in 2026 (by
January 1, 2026, for MA organizations and state Medicaid and CHIP FFS
programs; by the rating period beginning on or after January 1, 2026,
for Medicaid managed care plans and CHIP managed care entities; and for
plan years beginning on or after January 1, 2026, for QHP issuers on
the FFEs). Throughout this rule, we generally refer to these compliance
dates as ``in 2026'' for the various payers.
We received comments on the compliance dates for both the Prior
Authorization API and process improvement proposals that do not require
API development or enhancement. Overall compliance timeline comments
are addressed in greater detail in section I.B. of this final rule. In
this section, we discuss comments more specifically related to the
Prior Authorization API and process improvement policies.
Comment: Multiple commenters recommended that CMS require the
shortened prior authorization decision timeframes earlier than 2026,
with some noting that payers, specifically MA organizations, already
have the technological capability to implement these new decision
timeframes in 2024. These commenters did not provide additional context
for the reference to technological capabilities. Other commenters
recommended that CMS should require compliance with all requirements
that are not contingent on implementation of the Prior Authorization
API by January 2025 (for example, decision timeframes, providing
specific denial reasons, and reporting of metrics). Commenters said
payers should not have trouble adapting their processes to meet the
requirements related to decision timeframes and communication with
patients and providers by that date, and that patients and providers
should not have to wait any longer to benefit from the proposals in
this rule. Other commenters cited reasons for implementing the Prior
Authorization API proposal as soon as possible or in 2024 or 2025, such
as to ensure that bidirectional flow of electronic prior authorization
information is fully operational by January 1, 2026 and to protect
patients from delays in, and restricted access to, cancer care.
Other commenters indicated that transitioning to use the API-
facilitated process for prior authorization will require significant
development and implementation efforts. A commenter explained that
developers would need 12 to 18 months following publication of the
final rule to design, develop, test, and release updated software. The
commenter went on to state that payers would likely need this same
amount of time following publication of the final rule to build their
specific coverage and prior authorization criteria and rules into the
system for each of their impacted health plans for the Prior
Authorization API. This commenter explained that providers and payers
will also need time to work together to reconcile variances in the FHIR
implementations to ensure that they can engage in accurate exchange of
prior authorization information.
Response: We appreciate the comments in support of the proposed
compliance dates in 2026 for the business process improvement
provisions of the CMS Interoperability and Prior Authorization proposed
rule that do not require API development or

[[Page 8861]]

enhancement, specifically the requirement to communicate a specific
reason for a denial, reduced decision timeframes for standard and
expedited prior authorization decisions, and public reporting of
certain prior authorization metrics. We are finalizing those compliance
dates for those new requirements in this final rule. We agree that
those prior authorization process improvements will initiate burden
reductions and support both payers and providers.
Although there are several early implementations and pilots of the
Prior Authorization API in place today, it is important to take into
account the capabilities of all payer types and sizes to implement the
requirements of the Prior Authorization API, including internal
resource allocation for implementation and testing. All payers must
identify relevant prior authorization coverage criteria and rules and
program these criteria and rules into the appropriate format for the
API in accordance with the IG. Subsequent programming and testing for
the questionnaires within the API must take place to ensure
functionality. To accommodate these development efforts, CMS is
finalizing 2027 compliance dates for the Prior Authorization API. The
compliance timeframe should enable the industry to establish a strong
technical framework to support the development and scalability of the
API-based solution. We anticipate that this timeframe will provide more
time for development and testing to enable the integration of the Prior
Authorization API between payers, providers, and EHR developers.
Additional time for the API implementation also supports state efforts
to process the extraordinarily high volume of renewals and other
eligibility and enrollment actions that need to be conducted following
the end of the Medicaid continuous enrollment condition at section
6008(b)(3) of the Families First Coronavirus Response Act (FFCRA),\96\
which has consumed both staff and technical resources.
---------------------------------------------------------------------------

\96\ As described in prior CMS guidance, states have up to 12
months to initiate, and 14 months to complete, a renewal for all
individuals enrolled in Medicaid, CHIP, and the Basic Health Program
(BHP) following the end of the Medicaid continuous enrollment
condition that ended on March 31, 2023--this process has commonly
been referred to as the ``unwinding period.'' For more details see
CMS (2023, January 27). State Health Official letter #23-002.
Retrieved from https://www.medicaid.gov/sites/default/files/2023-08/sho23002.pdf.
---------------------------------------------------------------------------

2. Requirement Tto Implement an API for Prior Authorization
a. Prior Authorization API
To help address prior authorization process challenges and continue
our roadmap to interoperability, we proposed that certain payers
implement and maintain a PARDD API to be used by providers to
facilitate the prior authorization process. As we explained in section
I.B. of this final rule, for consistency with the naming conventions of
the other APIs, we have elected to finalize the name of this API to the
Prior Authorization API rather than the PARDD API. The purpose of the
API is to support the full prior authorization process, as described in
the CMS Interoperability and Prior Authorization proposed rule. We
believe this revised name best reflects that purpose in this final
rule.
In this section, we are finalizing policies to improve the prior
authorization process between payers and providers using a Prior
Authorization API. The purpose of the API is to streamline the process
and ensure that payers use technology to provide more useful
information about when and how to obtain a prior authorization and the
status of an approved or denied prior authorization.
In the CMS Interoperability and Prior Authorization proposed rule,
we discussed the anticipated benefits of the Prior Authorization API
and explained how this API would automate certain tasks, thereby
mitigating some of the obstacles of the existing process. We stated
that the API would allow a provider to query the payer's system to
determine whether prior authorization was required for certain items
and services and identify documentation requirements. The Prior
Authorization API would send the prior authorization request from the
provider's EHR or practice management system to the payer. In this
final rule, we are finalizing the requirement to use certain standards
and making recommendations to use certain IGs to support development of
the FHIR API. Use of the Prior Authorization API will enable automation
for the prior authorization request and response within the clinical
workflow of the provider. The IGs and relevant standards, which are
discussed in section II.G. of this final rule, serve as the
instructional manuals for the functional capability of the API. When
operational, the API enables a provider to submit a request about a
medical item or service, determine if additional information is
required, submit that information, and additionally assemble the
necessary information to submit a prior authorization request. The
response from the payer must indicate whether the payer approves (and
for how long) or denies the prior authorization request or requests
more information from the provider to support the request.
To support the implementation and maintenance of the Prior
Authorization API, we are requiring certain standards and recommending
certain IGs, as discussed elsewhere and in section II.G. of this final
rule. With the publication of the HTI-1 final rule (89 FR 1192), our
cross references to 45 CFR 170.215 have been updated to reflect the
updated citations as needed. Changes to the structure of 45 CFR 170.215
and versions of the API standards codified there are discussed further
in section II.G. of this final rule and reflected throughout this final
rule. For the Prior Authorization API, impacted payers must use the
following standards: HL7 FHIR Release 4.0.1 at 45 CFR 170.215(a)(1), US
Core IG STU 3.1.1 at 45 CFR 170.215(b)(1)(i), and SMART App Launch IG
Release 1.0.0 at 45 CFR 170.215(c)(1). Impacted payers are permitted to
voluntarily use updated standards, specifications, or IGs that are not
yet adopted in regulation for the APIs discussed in this final rule,
should certain conditions be met. For the standards at 45 CFR 170.215
required for the Prior Authorization API, updated versions available
for use under our policy include, but are not limited to, US Core IG
STU 6.1.0 and the SMART App Launch IG Release 2.0.0, which have been
approved for use in the ONC Health IT Certification Program.\97\ We
refer readers to section II.G.2.c. of this final rule for a full
discussion on using updated standards. We are also recommending payers
use the CRD IG STU 2.0.1, HL7[supreg] FHIR[supreg] Da Vinci
Documentation Templates and Rules (DTR) IG STU 2.0.0, and PAS IG STU
2.0.1. We refer readers to Table H3 for a full list of the required
standards and recommended IGs to support API implementation.
---------------------------------------------------------------------------

\97\ 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: Many commenters supported the proposal to require impacted
payers to implement and maintain a Prior Authorization API to improve
automation of the prior authorization process. Many commenters stated
that the API has the potential to support the needed transition to
electronic prior authorization. Commenters also stated that the Prior
Authorization API would

[[Page 8862]]

reduce the burden for providers and speed up the prior authorization
process for patients to improve care and access treatment options. A
commenter stated that the API would offer much-needed transparency for
rural providers around the prior authorization process. Other
commenters stated that the API would potentially replace old ways of
conducting the prior authorization process and give way to new ways of
conducting prior authorization and explained that the prior
authorization provisions laid out in the CMS Interoperability and Prior
Authorization proposed rule could provide a good return on investment
for payers. Multiple commenters supported CMS's efforts to implement a
standardized API that makes payers' prior authorization and other
documentation requirements electronically accessible to providers and
that supports a more streamlined prior authorization request and
response process. Multiple commenters believe this change will offer
many benefits for patients and providers, including increasing access
to care for patients and increasing providers' understanding of prior
authorization requirements by providing upfront information about which
services require prior authorization and what type of documentation is
required to support approval of a prior authorization request; and
increasing automation in the submission, receipt, and processing of
requests, which could support more timely responses. Commenters also
stated that this automation will help decrease administrative costs and
that the Prior Authorization API would improve the efficiency of
providing services to patients due to the request and response being
automated and in real-time, as well as the quality of patient care. A
large group of commenters expressed their support for the proposed
requirement for payers to implement the Prior Authorization API because
it will make their physical therapy businesses more efficient and allow
them to focus on treating patients.
Response: We agree that these policies will serve to mitigate some
of the burdens that exist in the prior authorization process today.
This is the reason we are finalizing a modification to the compliance
dates. Our proposal did not include a requirement for the Prior
Authorization API to provide real-time processing of the prior
authorization request, but we agree that incorporating a level of
automation and facilitating electronic prior authorization processing
could improve processing timelines in the future. Though we anticipate
that some of the responses or decisions potentially may be made in
real-time, other decisions will continue to necessitate review and
evaluation by clinical staff. The complete automation of a complex
process such as prior authorization is an ongoing process of continuous
improvement.
Comment: Multiple commenters stated that the Prior Authorization
API would not do enough to resolve existing issues surrounding prior
authorization burden and turnaround times. A commenter stated that the
amount of data to be transmitted and used by payers and providers
through the API is burdensome and impractical. This commenter wrote
that the continued transmission of medical information from non-FHIR
systems (for example, administrative transactions) will require payers
to translate such information into a format that is useable for the
Prior Authorization API, which would only shift the manual prior
authorization burden, not alleviate it. The commenter stated it is
important to maintain industry flexibility around prior authorization
to continue industry innovation in interactive decision-making
processes with providers to ensure the best care experience possible
for patients. Multiple commenters expressed concern that the required
implementation of the Prior Authorization API might increase the burden
for both providers and payers. A commenter expressed concerns that what
time may be saved through the API may end up being redirected to
maintain the API, field questions from patients and providers, and
support external development when requests are incomplete, which may
even require a dedicated team to answer provider questions throughout
the electronic prior authorization lifecycle. This commenter provided
insight into their experience with their current online portal and
provider submissions of prior authorizations, and continued reliance on
electronic faxes. A commenter expressed concerns that the maintenance
of the API will also place significant burdens on payers to translate
all coverage criteria to questions suitable for the electronic prior
authorization process and to keep such information up to date. Another
commenter also stated that the work involved in identifying all
policies and authorization processes that would be included in the
Prior Authorization API will be a significant effort as it will require
significant resources, staff, and time.
Response: We acknowledge concerns about the new technology and
processes associated with the Prior Authorization API, including
implementation challenges, potential conflicts with existing workflows,
and increased workload for initially implementing the Prior
Authorization API. Payers will need to identify the policies, conduct
the analysis, and do the necessary programming for the next few years.
Providers will also experience an initial implementation and data
collection burden associated with translating records into FHIR-
compatible formats. It is in part based on these considerations that we
decided to modify our proposed compliance dates so that the impacted
payers and providers alike will have sufficient time to conduct testing
on the newly structured prior authorization process. We disagree with
commenters who indicated that the Prior Authorization API would not do
enough to resolve existing issues surrounding prior authorization
burden and turnaround times, and with those who were concerned that the
transmission of medical information from systems would shift the prior
authorization burden to manual processes rather than alleviate it. The
benefits of using an electronic prior authorization process improve the
manual and burdensome process used today. Making the prior
authorization process electronic will reduce the time and burden
associated with the current process, allowing providers to put time
back into direct patient care, and ultimately will reduce provider
burnout. Once the Prior Authorization API is in place and a provider
can connect to a payer's system using that API, the manual effort for
both payers and providers should decrease because clinical and
administrative staff will be able to leverage the technology to conduct
a more streamlined process for submitting prior authorization requests.
Payers should be able to shift resources to review the requests more
efficiently. While payers may have their policies documented, these are
not in any standard formats, nor are they readable in any structured
way. Providers must often download documents from different portals and
then interpret them individually. The API will centralize and automate
this process for both payers and providers. Further, we have included
several significant policies that do not require API development or
enhancement in this final rule, one of which relates to shortening the
deadline by which impacted payers must respond to prior authorization
requests from providers. The policies being finalized in this rule have
been developed over time with input from providers, payers, and
patients to address the technical

[[Page 8863]]

and operational issues described to us as the most significant issues
in the prior authorization process.
b. FHIR Implementation Guides
In the CMS Interoperability and Prior Authorization proposed rule,
we proposed to require the use of certain technical specifications
(that is, IGs adopted as implementation standards) adopted at 45 CFR
170.215 (87 FR 76239). We also proposed that the same documentation
requirements and discontinuation and denial of access standards as we
proposed for the Patient Access API (discussed in section II.A.2. of
this rule), the Provider Access API (discussed in section II.B.2. of
this rule), and the Payer-to-Payer API (discussed in section II.C.3. of
this rule) would apply to the Prior Authorization API. Additionally,
for the Prior Authorization API, we specifically recommended using
certain FHIR IGs that have been developed to support the functionality
of the Prior Authorization API. These IGs are as follows:

The CRD IG
The DTR IG
The PAS IG

These three IGs are designed to be used by the payer, or
implementer, to develop and implement the Prior Authorization API. The
IGs undergo regular development and testing to support implementation
and use of the Prior Authorization API and to improve the API's
functionality in support of an improved prior authorization process.
Technical information and website access are provided in section II.G.
of this final rule.
The first IG recommended for use to develop the Prior Authorization
API is the CRD IG. As described on the HL7 web page, the CRD IG defines
a workflow to allow payers to provide information about coverage
requirements to providers through their clinical systems.\98\ Use of
this IG improves the transparency of specific coverage rules specific
to the patient and the provider based on the payer's prior
authorization policies, and, when implemented, provides decision
support to providers when they are ordering services. This is the first
stage of the process for determining whether authorization is required
for certain items or services. The CRD IG provides the functionality to
enable the API to inform the provider if a prior authorization is
required, and information about the payers' prior authorization
coverage rules, so the provider knows what information is necessary to
support a request. The functionality of the CRD may return a decision
to the provider if there is sufficient information and the payer
supports early determinations.
---------------------------------------------------------------------------

\98\ Health Level Seven International (2024, January 8). Da
Vinci--Coverage Requirements Discovery. Retrieved from https://www.hl7.org/fhir/us/davinci-crd/.
---------------------------------------------------------------------------

The second IG recommended for use by payers to develop the Prior
Authorization API is the DTR IG. On the HL7 IG web page, the
description explains how this IG specifies how payer rules can be
executed in a provider context to ensure that documentation
requirements are met.\99\ This IG is a companion to the CRD IG. Its
purpose is to automate the process of assembling documentation to
support a prior authorization request for a specific payer. The
instructions will allow the provider to download questionnaires and
populate them automatically with information from the EHR or other
systems for the completion of documentation requirements needed to
demonstrate medical necessity for a proposed item or service, based on
payer rules. The DTR IG enables the return of completed templates with
specific FHIR resources identified as required to support the medical
necessity of the service or item that is being requested for a prior
authorization. This process replaces the need to manually request,
gather, and submit documentation.
---------------------------------------------------------------------------

\99\ Health Level Seven International (2023, November 7). Da
Vinci--Documentation Templates and Rules. Retrieved from https://www.hl7.org/fhir/us/davinci-dtr/.
---------------------------------------------------------------------------

The third IG recommended for the Prior Authorization API is the PAS
IG. On the HL7 web page, the description explains that the PAS IG
enables direct transmission of prior authorization requests (and can
request/receive immediate authorization) from within EHR systems using
the FHIR standard and that it can create the mapping between FHIR and
HIPAA compliant X12 transactions.\100\ The PAS IG ensures that the API
takes the information from the CRD and DTR and allows provider systems
to send (and payer systems to receive) requests using FHIR. Providers
and payers can still meet separate regulatory requirements, where
required, to use the X12 278 transaction standard for prior
authorization(s) to transport the prior authorization request and
response. The PAS IG is the basis for: (1) assembling the information
necessary to substantiate the clinical need for a particular treatment;
and (2) submitting the assembled information and prior authorization
request to an intermediary before it is sent to the intended recipient.
As these IGs have been expanded and improved, the workgroup has
enhanced the graphic display depicting the workflow and made it
available on the HL7 website.\101\
---------------------------------------------------------------------------

\100\ Health Level Seven International (2023, December 1). Da
Vinci--Documentation Templates and Rules. Retrieved from https://www.hl7.org/fhir/us/davinci-pas/.
\101\ Health Level Seven International (2023, November 20). Da
Vinci Coverage Requirements: Technical Background. Retrieved from
https://build.fhir.org/ig/HL7/davinci-crd/background.html.
---------------------------------------------------------------------------

Most importantly, use of the instructions from the IG and the API
provides the necessary information about the status of the prior
authorization request--the response indicates whether the payer
approves (and for how long) or denies (and the reason) the prior
authorization request, or requests more information from the provider
to support the prior authorization request. The PAS IG also defines
capabilities around the management of prior authorization requests,
including checking on the status of a previously submitted request,
revising a previously submitted request, and canceling a request.
Section II.G. of this final rule provides additional discussion of both
the required and recommended standards and IGs to support the Prior
Authorization API.
Comments regarding requiring versus recommending the IGs, maturity
of the IGs, and technical implementation challenges are addressed in
section II.G. of this final rule. For example, commenters recommended
that the FHIR IGs should be required rather than recommended, as merely
recommending the IGs would lead to an additional burden for both payers
and providers as they may use varied implementations of the required
APIs that would ultimately reduce interoperability. We also received
multiple comments about technical implementation challenges and the
maturity of the recommended IGs. Technical comments such as these are
addressed in section II.G. Here we respond to the comments specific to
the standards and IGs for implementation of the Prior Authorization
API.
Comment: Multiple commenters recommended that CMS and HL7 ensure
the recommended CRD, DTR, and PAS IGs are fully tested before the
effective date of the final rule, as the IGs have not been adequately
or widely tested in real-time clinical settings. The commenter noted
that these IGs have data elements and processes that are listed as
optional despite their utility for automation. Another commenter
cautioned that the IGs have several data elements and processes that
are optional, which means payers could meet decision requirements with
vague responses,

[[Page 8864]]

hence jeopardizing CMS's prior authorization reform goal. Multiple
commenters supported using the PAS IG and stated that the IG is well-
positioned to support the development of the proposed Prior
Authorization API. A commenter noted that many of the proposed
requirements are covered in the PAS IG STU 2.0.0, which is targeted for
publication in calendar year 2023. The commenter continued by stating
that based on functional requirements, additional updates can be made
to the IG to ensure it fully supports the proposed Prior Authorization
API once finalized in preparation for compliance in 2026. However,
other commenters expressed some concerns about recommending these IGs.
Multiple commenters noted that hospitals and insurers may need to use
more than one technology solution to participate and track activity
using the Prior Authorization API. A commenter expressed concern with
the proposed IGs, which seem to require fast responses, within 5
seconds, and encouraged CMS to monitor technical standards as they are
developed to avoid excessive burdens that the agency did not intend to
create.
Response: CMS is recommending the three IGs to implement the Prior
Authorization API. These IGs, the CRD, DTR, and PAS IGs, were created
to be used together to provide implementation flexibility. Several
optional or ``situational'' elements were included in these guides as a
means to connect them in a single workflow while allowing for the
decoupling of these processes where necessary. For example, the CRD IG
might be used to develop an API specific to prior authorization
coverage requirements, and a separate API, linked to that one, built
using the DTR IG. Some hospitals and providers will need more than one
technology solution to connect to the payer's Prior Authorization API
endpoint based on the architectures and systems of the provider
organization. Impacted payers and providers may have separate and
unconnected systems that address coverage and eligibility,
documentation, and prior authorization. Since publication of the CMS
Interoperability and Prior Authorization proposed rule, updated
versions of the CRD, DTR, and PAS IGs have all been published. We refer
readers to Table H3 for the required standards and recommended IGs to
support API implementation.
In response to the specific comment about implementation
strategies, we refer implementers to the HL7 Da Vinci workgroups for
technical guidance; however, we understand that payers may need to pull
multiple technology solutions together to meet the overall Prior
Authorization API requirements. Concerning the response time of 5
seconds, which is near real-time, we anticipate that most systems can
accommodate this communication exchange when the information is
available. The PAS IG has a recommended synchronous response time of 15
seconds. Instructions are available in the IG for how systems should
respond in a timeframe with the best possible information. For further
technical details, we encourage interested parties to reach out to the
appropriate HL7 workgroups.
Comment: Multiple commenters stated that there are potential
technological challenges for the implementation of the Prior
Authorization API. A commenter noted that the proposed rule does not
specify what technology hospitals need to support or implement the API,
nor what technology is needed to track participation or be required to
participate in the API once finalized. This commenter noted that
providers will be using the Prior Authorization API without any
meaningful testing. Another commenter noted that they currently offer
providers an option to submit electronic prior authorizations through
an online portal, but utilization is low as most providers still favor
fax as their preferred method to send prior authorizations, and portal
prior authorizations often require corrections to incorrect data
entries.
Multiple commenters said CMS should do more to support the
implementation of the Prior Authorization API. A commenter supported
regulatory efforts to require payers to build APIs to automate prior
authorization, but questioned whether the CMS Interoperability and
Prior Authorization proposed rule goes far enough to accomplish that
goal. Another commenter noted that the Prior Authorization API will
require payers, providers, and vendors to connect but noted that
multiple infrastructure challenges will have to be resolved to ensure
API implementation success and cited the work of the HL7 FAST
Accelerator to identify and address scalability issues to avoid
duplication of efforts, including security and authentication.
Response: The regulations we are finalizing in this rule require
impacted payers to implement a Prior Authorization API, and providers
are encouraged to use the technology in their CEHRT to take advantage
of the improvements in prior authorization processes that will be
available through use of the Prior Authorization API. As we noted in
the proposed rule, HL7 launched an implementation division in 2021,
specifically to provide support for implementers, including education
and technical support. This division will provide payers, providers,
and vendors with access to information about the types of technology
and software that will address implementation, education, and testing
of the standards, IGs, and APIs. Furthermore, the HL7 workgroups, which
are open to the public, continue to be the best resources to learn
about implementation. We will continue to work with associations,
developers, and HL7 on identifying or supporting the development of
appropriate resources for education.
The HL7 FAST Accelerator is addressing the scalability issues of
the FHIR standard through its work on security and the directory IGs.
We and ONC participate in the HL7 FAST Accelerator and will monitor
progress on the IGs being developed by that project.
The policies in this final rule are an important component of the
overall CMS strategic plan to reduce burden, advance interoperability,
and improve patient care. This rule finalizes significant changes to
improve the patient experience and alleviate some of the administrative
burden by applying policies which address both technical and process
barriers. These policies represent foundational regulatory steps toward
addressing the longstanding challenges of prior authorization.
Comment: A commenter, writing from the provider perspective, stated
that the Prior Authorization API would complicate clinical and
administrative workflows by requiring some combination of staff time
and additional technological advances and recommended the FHIR API be
combined with the HIPAA transaction standard.
Response: We do not agree that using the Prior Authorization API
will complicate clinical work. Rather, time will be saved across all
personnel tasks, including researching the requirements for prior
authorization across multiple payers, entering information into
systems, submitting requests, processing approvals, or determining next
steps if a denial is received. The Prior Authorization API is capable
of conducting the prior authorization request as a FHIR only data
exchange, or in combination with the HIPAA transaction standard.
Comment: Multiple commenters urged CMS to name the CDex IG as one
of the recommended IGs to use in support of the Prior Authorization API

[[Page 8865]]

and stated that it is a critical part of burden reduction and plays an
important role in supporting FHIR prior authorization transactions as
proposed. To support the attachments for the Patient Access, Provider
Access, and Payer-to-Payer APIs, as well as the supporting
documentation requirements for the Prior Authorization API, this IG
provides the instructions to enable the exchange of structured
documents \102\--meaning those which could be read and interpreted by a
computer. This functionality to attach documents to support a prior
authorization is currently missing from the other FHIR IGs and
standards. A commenter stated that the PAS IG could support existing
Federal and state requirements to exchange attachments if implementers
also added the functionality of using the CDex IG. Use of this IG would
further support efficiencies in the prior authorization process.
---------------------------------------------------------------------------

\102\ General comparison of structured versus unstructured
documents: Structured documents are organized and fit into
spreadsheets and relational databases. Structured documents often
contain numbers and fit into columns and rows and are easily
searchable. Examples are ICD-codes, Star Ratings, and other discrete
data elements. Unstructured documents include traditional business
files, word processing documents, presentations, notes, and PDFs.
---------------------------------------------------------------------------

Response: We are aware that early adopters have begun testing with
the CDex IG for attachments to advance additional use cases for the
Prior Authorization API. This final rule does not address standards for
attachments and does not prohibit using the CDex IG or other attachment
standards.
c. Implementation, Automation, and Other General Considerations for the
Prior Authorization API and Processes
We proposed and are finalizing requirements for impacted payers to
implement a Prior Authorization API to improve the prior authorization
process. The policy would require use of new standards for some
impacted payers and some changes in procedures. We received comments on
the use of new standards, technology, and automation with
considerations for implementation and have grouped them here.
Comment: A commenter stated that they support the proposed
requirements for the Prior Authorization API; however, they believe
much more needs to be done to achieve the CMS objectives for this
policy. Multiple commenters shared potential concerns and challenges
with the implementation of a Prior Authorization API. A commenter wrote
that the Prior Authorization API use case will not work without
provider participation, as the API requires bidirectional exchange
between impacted payers and providers. A commenter expressed concern
regarding the resource development needed for providers and noted this
needs to be more widely understood before the implementation of the
Prior Authorization API. The commenter recommended CMS work with
interested parties to ensure practices can utilize and leverage this
API. The commenter encouraged CMS to work with ONC to extend the
applicability of the Prior Authorization API requirements to providers
and EHR vendors to ensure technical readiness and enable greater
adoption of the Prior Authorization API and electronic prior
authorization. A commenter suggested that CMS require plans to provide
to each contracted physician, upon request and regardless of their use
of the API, the references to the clinical research evidence that
underlie medical policy determinations when they approve or deny a
service. The commenter noted that some physicians may not be able to
adopt these systems by the compliance dates.
Response: We are finalizing compliance dates in 2027 for payers to
implement the Prior Authorization API which should provide sufficient
time for payers to implement the APIs, collaborate with EHR vendors to
support appropriate connections for their providers, and develop
outreach materials. Ongoing pilots demonstrate that payers and
providers can implement the necessary infrastructure by those
compliance dates. While providers are not required by this final rule
to use the Prior Authorization API, in section II.F. of this final rule
we are incentivizing providers to use this API by finalizing new
electronic prior authorization measures for MIPS eligible clinicians
under the MIPS Promoting Interoperability performance category and for
eligible hospitals and CAHs under the Medicare Promoting
Interoperability Program. To promote Prior Authorization API adoption,
implementation, and use among MIPS eligible clinicians, eligible
hospitals, and CAHs, we are adding a new measure titled ``Electronic
Prior Authorization'' under the HIE objective in the MIPS Promoting
Interoperability performance category and the Medicare Promoting
Interoperability Program, beginning with the calendar year (CY) 2027
performance period/2029 MIPS payment year and CY 2027 EHR reporting
period. There could be many benefits for providers for improvements in
the prior authorization process, and we encourage all providers to
evaluate whether use of the Prior Authorization API could benefit their
practices. Payers should also encourage providers in their network to
use the Prior Authorization API, given that it could be timesaving for
both parties, and we anticipate that many payers will begin education
and awareness campaigns as more pilots are launched and/or payer APIs
are readied for testing. We are monitoring the activities of existing
pilots and receiving positive reports from participants. ONC may
consider developing and making available additional criteria for EHR
certification for electronic prior authorization in future rulemaking.
We did not propose to specifically require payers to make available
the references to the clinical research evidence that underlie medical
policy determinations when they approve or deny a service, but we did
propose that when an impacted payer denies a prior authorization
request, the payer must include a specific reason for that denial in a
notice to the provider who requested the prior authorization. See
section II.D.3. regarding that proposal and the final policy. While we
do not oversee contract provisions between payers and providers, the CY
2024 MA and Part D final rule (88 FR 22120) \103\ finalized a new
requirement at 42 CFR 422.101(b)(6) for MA plans to make certain
information about their internal coverage policies publicly accessible,
including a list of the evidence considered in developing the internal
coverage criteria; that final rule also limits using internal coverage
criteria for Part A and Part B benefits to when coverage criteria are
not fully established in Medicare statute, regulation, NCD, or LCD. We
anticipate this information, along with the requirement that MA plans
provide a reason for denying a request for prior authorization (at 42
CFR 422.122 as adopted here and currently in existing 42 CFR
422.568(e)) will address the commenter's concern about access to
clinical research and evidence supporting denials of coverage in the MA
program. In addition, the CY 2024 MA and Part D final rule adopted a
new regulation, at 42 CFR 422.137, that requires a Utilization
Management Committee to annually review the policies and procedures for
all utilization management, including prior

[[Page 8866]]

authorization, used by the MA plan, and a new regulation at 42 CFR
422.138 that limits how prior authorization may be used by certain MA
plans. Per 42 CFR 422.138, coordinated care MA plans (for example,
Health Maintenance Organization [HMO], Preferred Provider Organization
[PPO], and point-of-service [POS] plans) may only use prior
authorization to confirm the presence of diagnoses or other medical
criteria that are the basis for coverage determinations for the
specific item or service and to ensure that the requested item or
service is medically necessary (for Part A and B benefits) or
clinically appropriate (for supplemental benefits). Finally, we remind
readers that MA regulations at 42 CFR 422.202(b) and 422.136(a) require
MA organizations to provide education and outreach about utilization
management policies and engage in consultation with contracted
providers.
---------------------------------------------------------------------------

\103\ See 88 FR 22120 through 22345 (April 12, 2023). Medicare
Program; Contract Year 2024 Policy and Technical Changes to the
Medicare Advantage Program, Medicare Prescription Drug Benefit
Program, Medicare Cost Plan Program, and Programs of All-Inclusive
Care for the Elderly. Retrieved from https://www.federalregister.gov/documents/2023/04/12/2023-07115/medicare-program-contract-year-2024-policy-and-technical-changes-to-the-medicare-advantage-program.
---------------------------------------------------------------------------

Comment: Multiple commenters discussed automating prior
authorizations, and many were in support of automation, providing
technological suggestions for automation of the prior authorization
process. A commenter stated that, for prior authorization forms,
specific clinical questions require answer formats that are easily
understood and automated by a computer. Another commenter described how
payers might automate the prior authorization process by utilizing
existing matrices to create algorithms that would be able to review a
large proportion of their prior authorization requests. A commenter
noted that deep learning AI methods for submitted clinical data could
be used to inform the review and electronic prior authorization
approval process to expedite a decision that simulates a consensus of
expert human judgment.
Multiple commenters recommended that CMS explore automating service
``bundle'' prior authorizations for instances where one episode of care
needs multiple prior authorizations (for example, a knee replacement
surgery), as this would help ease administrative burden and reduce
delays in patient care.
Response: We are closely following the level of interest in the
types of automation that might be brought to bear on the prior
authorization process, particularly around the infrastructure for
communications, and the innovative thinking shared in the public
comments. While CMS did not directly address using AI for purposes of
implementing the prior authorization policies, or any provisions of
this final rule, we encourage innovation that is secure; includes
medical professional judgment for coverage decisions being considered;
reduces unnecessary administrative burden for patients, providers, and
payers; and involves oversight by an overarching governance structure
for responsible use, including transparency, evaluation, and ongoing
monitoring. We also reiterate that impacted payers must comply with
Federal and state policies and the requirements of the standards and
recommended IGs in implementing these APIs. We encourage these and
other individuals to participate in the HL7 IG development groups to
share these ideas with the drafters of the IGs to further refine their
functionality.
Comment: Multiple commenters recommended that CMS include
additional requirements for payers. A commenter recommended that CMS
require payers to offer their electronic prior authorization system at
no cost to providers. Multiple commenters stated that health plans
should be required to provide a web-based interface for providers and
patients with a standardized, easy-to-use web page with an up-to-date
database that quickly indicates whether prior authorization is
required. The commenter stated that this web page should include prior
authorization rules and medical policies. A commenter requested that
the required response to the query on the online database include the
following data points: transaction ID, group or member ID, date of
service, prior authorization required, instructions, and a medical
policy link. A commenter recommended that, in the case of a technical
glitch with the prior authorization process, insurance plans should
develop a backup system.
Response: We did not specifically address whether payers could
charge providers for use of or access to the Prior Authorization API.
We would encourage payers not to charge additional costs beyond those
that may exist to conduct prior authorization business functions today,
including the costs of conducting transactions. We do not anticipate
that fees would be charged for use of the API or other services
required by this final rule, but are aware that payers will be funding
their own development and vendor related costs.
Concerning the specific functionalities commenters requested be
available through portals, online systems, or the API, such as easy-to-
use web pages with an up-to-date database that quickly indicates
whether prior authorization is required or what the medical policies
are, we reiterate that payers are required to implement a Prior
Authorization API that allows a provider to query a payer's system to
determine whether a prior authorization is required, to identify
documentation requirements, and to receive information about whether a
specific prior authorization request has been approved or denied. As
part of fulfilling these required functions, information about the
policies and how they have been developed may be available, but we
understand that the level of additional information and detail about
the development of prior authorization and coverage policies could vary
by payer. There may be other connected systems and resources available
with information about the medical policies that are associated with
the Prior Authorization API to which the provider will be able to refer
to understand how decisions are being made for certain items and
services. Furthermore, under existing Federal and state laws, such as
the HIPAA Privacy and Security Rules, administrative, technical, and
physical safeguards policies and procedures must be in place to ensure
that systems have effective backup controls to protect access to
patient data during planned and unplanned downtime. We would expect
impacted payers to already have such procedures in place for reliable
backup systems.
Comment: Multiple commenters noted that payers will have to
digitize their prior authorization policies to meet the Prior
Authorization API requirements, which will be difficult and time-
consuming. Multiple commenters noted that payers may be concerned that
if a significant amount of their providers do not adopt the new prior
authorization API process, the payer will not receive the full benefit
of their investment.
Response: We acknowledge that payers will have to digitize their
prior authorization policies to meet the API requirements. Several
organizations have implemented the Prior Authorization API as pilot
projects or as part of the Da Vinci Exception Project, and we are aware
that implementation of the API requires a significant investment of
resources. We also recognize that the full benefit of the API will be
achieved when providers use the API to request information about prior
authorization requirements and change existing workflow patterns. The
changes for both payers and providers will maximize the return on
investment from the new electronic exchange. We encourage other
impacted payers to engage with these early implementers to learn from
their experience and to begin evaluating their policies to understand
the level of effort that will be required within their organizations.
To support

[[Page 8867]]

the analysis, implementation, and testing, we are also finalizing
compliance dates that are a year later than we proposed to provide
additional time for the necessary work to implement the Prior
Authorization API and to conduct outreach and education to the provider
community.
Comment: A commenter recommended that CMS include a Prior
Authorization API opt out policy and another commenter recommended that
CMS explain providers' responsibilities related to communicating
patients' right to opt out of the Prior Authorization API and their
responsibility to notify the payer of that decision.
Response: Prior authorization is an administrative process between
a payer and provider that is conducted almost completely electronically
today with no direct burden on the patient. We would anticipate that an
individual who wishes to obtain medical services expediently might wish
for their provider to use the most efficient resource available to
them. The opt out/opt in rules that we are finalizing in this rule are
for the Provider Access and Payer-to-Payer APIs' data exchange
requirements, discussed in sections II.B. and II.C., and do not apply
to the Prior Authorization API. While this final rule does require
impacted payers to develop and implement the Prior Authorization API,
this rule does not require providers to use the API. As discussed in
section II.F., this final rule does include policies regarding using
the Prior Authorization API for the Promoting Interoperability
performance category of MIPS and the Medicare Promoting
Interoperability Program. As many providers are currently conducting
these processes through EHRs in the office, with the patient present,
we would encourage providers to explain any activity to the patient, as
is being done for any electronic transaction, including electronic
prescribing, lab orders, and scheduling. We also anticipate that
providers would want to use a process in which their EHR or other
medical record systems are capable of connecting with the APIs and
exchanging certain data and documents using FHIR standards. At a
minimum, the Prior Authorization API will provide a means for providers
to identify the prior authorization requirements for the impacted
payers, which will save time and burden associated with having to
research those requirements manually. We do not believe it is necessary
to add a new opt out process for patients regarding prior
authorization. These are administrative tasks already in place in
provider offices. We reiterate that providers are not required by this
rule to use the Prior Authorization API.
Comment: Multiple commenters discussed prior authorization criteria
and specifically referenced the CY 2024 MA and Part D final rule for
the enhancements it provides for prior authorization requirements. A
commenter requested that CMS require payers to make their prior
authorization criteria public in advance of the publication of this
final rule and to ensure that physicians with expertise in the services
are involved in their development. Other commenters requested that CMS
ensure that prior authorization criteria be peer-reviewed. A commenter
wrote that the Prior Authorization API will increase transparency into
payer prior authorization criteria, and another noted that using an
electronic data exchange could improve the accuracy of prior
authorization determinations. A few commenters wrote that the solution
to prior authorizations must include both an expedited prior
authorization process as well as appropriate clinical decision-making,
particularly with treatment guidelines supported by clinical evidence.
Another commenter stated that the Prior Authorization API could
specifically speed up the process of prior authorization for key
treatments of gynecologic cancers. Commenters noted that the increased
transparency will include better timing for responses and accuracy for
treatment protocols subject to prior authorization.
Response: We agree that if the API can enhance provider
understanding of the requirements for requesting a prior authorization,
a provider's ability to submit a complete and accurate request
electronically will be improved and the manual intervention needed to
collect additional information reduced. This transparency in
requirements and criteria should improve communication between payers
and providers during the prior authorization process, which is a core
element of the functionality of the Prior Authorization API. We also
appreciate comments suggesting that prior authorization criteria should
be peer-reviewed and include appropriate clinical decision-making
information with treatment guidelines that are supported by clinical
evidence. Use of such clinical evidence is helpful to reviewers when
creating care treatment plans and evaluating prior authorization
requests. We have also heard from many payer organizations that
aligning with clinical guidelines is part of their process when
establishing prior authorization criteria and we encourage this
practice for all payers. We did not make specific proposals related to
developing prior authorization criteria, but acknowledge the value of
such clinical involvement.
We also note that the provisions in this final rule on prior
authorization will work with several of the utilization management and
prior authorization policies in the CY 2024 MA and Part D final rule to
further CMS's overall goals of improving prior authorization processes
to serve the needs of payers, providers, and patients. We encourage
readers to review that rule as well (88 FR 22120) to have a greater
understanding of the limits on how MA organizations may use and
implement prior authorization.
Comment: Multiple commenters discussed the need for APIs to be
integrated with EHR systems. A commenter expressed concern that current
EHR systems will not be set up to accommodate the requirements of this
rule. Another commenter noted that an obstacle to the effective
implementation of the Prior Authorization API is the lack of
standardized coding and structured data in provider EHRs to support
adjudication of a prior authorization request. The commenter stated
that it will be important for EHR clinical data to be standardized to
successfully adjudicate prior authorization requests through API
interfaces.
Response: We appreciate comments about standardization and the need
for providers and EHR system vendors to address consistency in the
coding of medical records for interoperable data exchange. Such
comments do not reflect a technical readiness issue for the Prior
Authorization API or the standards but rather an industry readiness to
meet the requirements to enable and automate prior authorization
processes. Over the next few years, both provider management systems,
as well as certified EHRs, will advance in their use of standards, data
exchange, and connectivity. Implementation of a content standard at 42
CFR 170.213 (USCDI) for all data classes and data elements will support
communication about medical records will reduce the variation in
medical record coding, increase structured data, and support the
ability for interoperable data exchange. The IGs that support the Prior
Authorization API provide the framework for exchanging standard
information between the payer and provider systems.
We note that ONC previously sought comment on how updates to the
ONC Health IT Certification Program could support electronic prior
authorization through an RFI titled ``Electronic Prior Authorization
Standards,

[[Page 8868]]

Implementation Specifications, and Certification Criteria'' (87 FR
3475), which appeared in the January 24, 2022, issue of the Federal
Register. The Unified Agenda, current at the time of this final rule's
publication, includes an entry for a proposed rule from ONC entitled
``Health Data, Technology, and Interoperability: Patient Engagement,
Information Sharing, and Public Health Interoperability'' (RIN 0955-
AA06). The description indicates that this proposed rule aims to
advance interoperability, including proposals to expand the use of
certified APIs for electronic prior authorization.\104\
---------------------------------------------------------------------------

\104\ Office of Information and Regulatory Affairs, Office of
Management and Budget, Executive Office of the President.
Reginfo.gov. Retrieved from https://www.reginfo.gov/public/do/eAgendaViewRule?pubId=202304&RIN=0955-AA06.
---------------------------------------------------------------------------

Comment: A few commenters recommended that CMS work with states to
resolve conflicts between this rule and existing state regulations. A
commenter noted that Arizona has recently enacted legislation and
published guidance establishing a uniform prior authorization request
form. The commenter expressed concern that potentially conflicting
policies would create confusion and operational process challenges for
QHP issuers on the FFEs and providers.
Response: We are aware that many states are also attempting to
improve prior authorization processes and have read the Arizona
legislation HB 2621 from 2022 \105\ regarding using standard paper
forms and electronic portals. We do not believe there is a conflict
between those requirements and this final rule as the Prior
Authorization API required by this final rule can support the various
state required standardized forms for electronic submission of the
prior authorization request. The AMA also provides a list of other
state legislation designed to improve prior authorization processes,
many of which support or enhance the provisions in this final rule, for
example, by supporting the establishment of an electronic prior
authorization process.\106\ Should a conflict present between state and
Federal requirements, the general rule is that the regulated entity
must comply with both requirements unless compliance with one makes
compliance with the other impossible; in such a situation, Federal law
generally preempts state law in the absence of statutory direction
otherwise.
---------------------------------------------------------------------------

\105\ Office of the Director Arizona Department of Insurance and
Financial Institutions (2022, January 3). Regulatory Bulletin 2022-
01(INS). Retrieved from https://difi.az.gov/sites/default/files/Prior%20Authorization%20Bulletin%20with%20forms%202022-01.pdf.
\106\ American Medical Association (2022). 2022 Prior
Authorization (PA) State Law Chart. Retrieved from https://fixpriorauth.org/sites/default/files/2022-12/2022%20Prior%20Authorization%20State%20Law%20Chart.pdf.
---------------------------------------------------------------------------

d. Implementation Timing Considerations
In the proposed rule (87 FR 76290), we stated that we had
considered proposing that the Prior Authorization API be implemented in
a phased approach. However, we explained that we did not think a phased
implementation strategy would reduce the burden on impacted payers or
providers, but rather could increase burden during the initial
implementation. We also explained that a phased approach could delay
the availability of electronic prior authorization for certain items
and services, which could in turn reduce the overall adoption of the
Prior Authorization API by providers who do not see their specialties
and services represented in the initial rollout of the available Prior
Authorization API. We sought comment on whether to require payers to
make prior authorization rules and documentation requirements available
through the API incrementally, beginning in 2026. Additional comments
and responses regarding the timing and deadlines for compliance with
the Prior Authorization API and those policies that do not require API
development or enhancement are discussed in sections I.B. and II.D.1.
Comment: Some commenters supported a phased implementation of the
Prior Authorization API to allow impacted payers sufficient time to
build the API and recommended processes that would use the IGs in a
staggered fashion rather than implementing the entire process for prior
authorizations. Other commenters recommended a phased implementation
based on the following order for the IGs: CRD IG first, DTR IG second,
and PAS IG third. A commenter stated there are already states making
plans to implement an electronic prior authorization process and
suggested that a staggered approach could help to avoid unnecessary
variation in implementations. A commenter stated that if CMS does not
provide an explanation of terminology (such as ``documentation'') and
specify IGs and common standards on time for the Prior Authorization
API there may need to be a staggered approach for implementing the API.
A commenter agreed with CMS's observation that a phased implementation
approach would still result in having to request and process prior
authorization requests in at least two different manners for a provider
working with the same impacted payer, which makes little sense given
the difficulties in the current state to even get the HIPAA Referral
Certification and Prior Authorization transaction adopted under HIPAA
Administrative Simplification. Multiple commenters recommended a 3-year
timeframe for phased implementation based on the specific/common
services approach. A commenter recommended that instead of using a
percentage criterion, CMS should use a 3-year timeframe with year 1
requiring authorization rules, year 2 adding rules to different
specialty facilities, and year 3 adding the Prior Authorization API to
specific services and care sectors.
Response: As stated at the beginning of this section, we are
finalizing a modification to our proposed compliance dates for the
Prior Authorization API in 2027. We continue to believe, for the
reasons outlined in the CMS Interoperability and Prior Authorization
proposed rule and in our responses to comments on this issue, that
mandating a phased approach is not necessary. Payers may choose to
implement the IGs in a phased approach within their operations, as long
as the API is fully functional by the compliance date. Each payer will
evaluate the scope of work required to program their prior
authorization requirements, build the rules and questionnaires, and
develop appropriate testing. For those payers with extensive prior
authorization requirements and less structured documentation policies
for different benefit packages, the scope will be more significant.
However, a phased approach will not change the scope of this work; the
IGs provide the road map or instructions for implementation. Use of
these guides will help payers determine the scope and level of effort
required for the work that must be completed for system changes, as
well as operational changes for their organizations.
Comment: Multiple commenters stated the phased approach may result
in inconsistent implementation and/or fragmentation when it comes to
leveraging the Prior Authorization API, as different payers and
providers may be at different stages of implementation. Multiple
commenters stated that a phased approach could reduce adoption of Prior
Authorization API by providers, particularly if certain items or
services are listed in the initial rollout and others are not. A
commenter noted that the slow and delayed rollout of the Prior
Authorization API is unlikely to result in standardized, streamlined,
electronic prior authorization experiences for physicians, clinicians,
providers, and

[[Page 8869]]

health IT vendors. Therefore, multiple commenters supported the full
implementation of Prior Authorization API on January 1, 2026.
Response: We thank commenters for affirming that a phased approach
could result in inconsistent and fragmented implementation of the Prior
Authorization API and reiterate that the decision to provide an
additional year for implementation for all impacted payers was made to
ensure that the organizations would have sufficient time for training,
development, testing, and outreach to providers.
e. Existing Prior Authorization Standards: HIPAA Exceptions for Testing
New Standards
In the CMS Interoperability and Prior Authorization proposed rule,
we explained that the X12 278 transaction standard (Version 5010) and
NCPDP D.0 are the current standards for electronic prior authorization
transactions, adopted by HHS under provisions of HIPAA. Many payers and
providers do not use the HIPAA transaction standards, and instead use
proprietary payer interfaces and web portals through which providers
submit their requests, as well as phone calls or faxes to complete the
process for a response. The prior authorization process remains
inefficient and burdensome and creates service issues for patients. We
provided findings from industry surveys and HHS reports about gaps in
the current processes and standards for prior authorization.
The Council for Affordable and Quality Health Care (CAQH) Committee
on Operating Rules for Information Exchange (CORE) annual report, the
CAQH CORE Index, includes data on health plan and provider use of HIPAA
standard transactions, and as noted in the proposed rule (at 87 FR
76288), shows that prior authorization using the X12 278 transaction
standard was the least likely to be supported by payers, practice
management systems, vendors, and clearinghouse services.\107\ The 2021
report \108\ showed an incremental increase in using the X12 278
transaction standard for prior authorization of 26 percent. CAQH CORE
published its 2022 report \109\ in November 2022 with data showing that
while medical plans' adoption of the X12 278 transaction standard
increased by two percentage points (to 28 percent), it was still low as
compared to the other HIPAA transactions.
---------------------------------------------------------------------------

\107\ Council for Affordable and Quality Health Care (2019).
2019 CAQH Index: Conducting Electronic Business Transactions: Why
Greater Harmonization Across the Industry is Needed. Retrieved from
https://www.caqh.org/sites/default/files/explorations/index/report/2019-caqh-index.pdf?token=SP6YxT4u.
\108\ Council for Affordable and Quality Health Care (2021).
2021 CAQH Index: Working Together: Advances in Automation During
Unprecedented Times. Retrieved from https://www.caqh.org/sites/default/files/explorations/index/2021-caqh-index.pdf.
\109\ Council for Affordable and Quality Health Care (2022).
2022 CAQH Index: A Decade of Progress. Retrieved from https://www.caqh.org/sites/default/files/2022-caqh-index-report%20FINAL%20SPREAD%20VERSION.pdf.
---------------------------------------------------------------------------

We received many comments about the adopted HIPAA transaction
standard and its intersection with the proposed rule and address
applicable comments here.
The provisions of this final rule will provide enhancements to the
electronic prior authorization process overall. We are finalizing our
proposal to require impacted payers to implement a Prior Authorization
API that can provide the necessary data to support a payer's use of
electronic prior authorization processes.
In the proposed rule, we referenced section 1104 of the Affordable
Care Act, which amended HIPAA to require that HHS adopt operating rules
for HIPAA standard transactions. ``Operating rules'' are defined at 45
CFR 162.103 as the ``necessary business rules and guidelines for the
electronic exchange of information that are not defined by a standard,
or its implementation specifications as adopted for purposes of HIPAA
Administrative Simplification.'' Operating rules have not been adopted
for the X12 278 transaction standard.
The NCVHS reviews operating rules and advises the Secretary as to
whether HHS should adopt them (section 1173(g) of the Act). The
Secretary adopts operating rules through regulation in accordance with
section 1173(g)(4) of the Act. In June 2022, CAQH CORE submitted
revised and new operating rules to NCVHS for consideration. In June
2023, NCVHS sent a letter to HHS recommending adoption of revised
operating rules for Eligibility & Benefits, Claim Status, and Payment &
Remittance Advice transaction standards, as well as a Connectivity
operating rule. In that letter, NCVHS recommended that HHS not adopt
the proposed CAQH CORE Attachments Prior Authorization Infrastructure
operating rule or the CAQH CORE Attachments Health Care Claims
Infrastructure operating rule. NCVHS wrote that ``[t]he need for these
operating rules should be considered only after publication of a final
rule adopting a health care attachments transaction standard under
HIPAA.'' \110\ Should a future proposal or recommendation for adoption
be submitted to HHS, we would evaluate the effect, if any, on the
policies included in this final rule. After the publication of this
final rule, CMS will continue to evaluate the impact of any NCVHS
recommendation and any separate actions by HHS in that regard.
---------------------------------------------------------------------------

\110\ National Committee on Vital and Health Statistics (2023,
June 30). NCVHS Recommendations on Updated and New CAQH CORE
Operating Rules to Support Adopted HIPAA Standards. Retrieved from
https://ncvhs.hhs.gov/wp-content/uploads/2023/07/Recommendation-Letter-Updated-and-New-CAQH-CORE-Operating-Rules-June-30-2023_Redacted-508.pdf.
---------------------------------------------------------------------------

We also noted in the CMS Interoperability and Prior Authorization
proposed rule (87 FR 76289), that in March 2021, HHS approved an
application \111\ from an industry group of payers, providers, and
vendors for an exception under 45 CFR 162.940 from the HIPAA
transaction standards to allow testing of an alternative to the adopted
HIPAA standard for prior authorization.\112\ The purpose of this
exception is to test an automated exchange of a prior authorization
request and response using only the FHIR standard and the FHIR IGs
recommended in the proposed rule and included in this final rule. Under
this exception, participants are testing the prior authorization
exchange using a FHIR-to-FHIR exchange using the FHIR standard without
using the X12 278 transaction standard. Preliminary findings suggest
that this alternative standard can be used successfully to conduct the
prior authorization request and response as end-to-end FHIR in a cost-
effective, efficient way. Payer and provider groups have presented
these preliminary findings in public forums.
---------------------------------------------------------------------------

\111\ Da Vinci Project (2021, May 26). Da Vinci HIPAA Exception.
Retrieved from https://confluence.hl7.org/display/DVP/Da+Vinci+HIPAA+Exception.
\112\ HHS provides information about requests for exceptions
from standards to permit testing of proposed modifications on the
HIPAA administrative simplification website. Centers for Medicare
and Medicaid Services (2023, September 6). Go-to-Guidance, Guidance
Letters. Retrieved from https://www.cms.gov/Regulations-and-Guidance/Administrative-Simplification/Subregulatory-Guidance/Go-to-Guidance-Guidance-Letters.
---------------------------------------------------------------------------

HHS provides information about requests for exceptions from
standards to permit testing of proposed modifications on the HIPAA
administrative simplification website.\113\
---------------------------------------------------------------------------

\113\ HHS website with information about Sec. 164.940
(Exceptions Process and Guidance Letters): HHS provides information
about requests for exceptions from standards to permit testing of
proposed modifications on the HIPAA administrative simplification
website. Centers for Medicare and Medicaid Services (2023, September
6). Go-to-Guidance, Guidance Letters. Retrieved from https://www.cms.gov/Regulations-and-Guidance/Administrative-Simplification/Subregulatory-Guidance/Go-to-Guidance-Guidance-Letters.

---------------------------------------------------------------------------

[[Page 8870]]

Comment: Multiple commenters made statements about the HIPAA
exceptions process (45 CFR 162.940) and described various burdens
associated with it, including the application process, lack of clarity
for the evaluation criteria, and the time for approval. Commenters
noted the current exceptions process may serve as a barrier for the
industry to take advantage of the opportunity to move interoperability
forward and urged CMS to make it less burdensome to accelerate
opportunities for entities to beta test new standards and approaches to
more efficient data exchange. A commenter recommended that CMS work
with HHS or other agencies to improve the HIPAA exceptions process such
that it is less onerous and more flexible to facilitate innovation.
Another commenter strongly urged CMS to eliminate the requirement for
payers to request an exception to any of the HIPAA transaction and code
standards. This commenter stated that Da Vinci member exceptions should
be discontinued, and CMS should work with other government entities as
needed to eliminate the requirement to obtain an exception from the
HIPAA standard for organizations seeking to directly exchange data
using the FHIR standard without X12 translation. A commenter requested
that HHS develop an administrative process or ``onramp'' for states to
request a HIPAA exception for this specific transaction that individual
states could utilize at their discretion.
Response: The opportunity to apply for an exception to test an
alternative to an adopted standard is established in the HIPAA statute
and implemented in regulation at 45 CFR 162.940. Although we appreciate
these comments regarding the HIPAA exceptions process, they are out of
scope of this rule.
Comment: Many commenters stated that the CMS Interoperability and
Prior Authorization proposed rule failed to address the limitations of
the X12 278 transaction standard. Many others noted that current
industry use of the X12 278 transaction standard is very low, noting it
is complex and outdated, and thus mandating the conversion of FHIR to
the X12 278 transaction standard serves no real value beyond
compliance. A commenter discussed how the CAQH CORE Index report
consistently reports that full automation for X12 standards for prior
authorization lags far behind payment-related use cases. A commenter
noted that because of the low use of the X12 278 transaction standard,
entities would have to develop an implementation process to complete a
FHIR exchange just to convert it to an X12 278 transaction standard.
Another commenter noted the industry will continue to have
interoperability challenges around the Prior Authorization API
capability due to a lack of uniformity if existing issues with the X12
278 transaction standard are not addressed. Multiple commenters
requested that CMS consider certain flexibilities in implementation. A
commenter recommended that CMS consider a floor versus ceiling approach
in which the X12 standard is seen as the floor and a standard FHIR
approach using the PAS IG is the ceiling. Multiple commenters
recommended that CMS provide a waiver for the X12 278 transaction
standard for payers that can implement end-to-end FHIR data exchange. A
commenter requested that CMS grant such payers a safe harbor that
provides an automatic waiver of the X12 278 transaction standard
requirement. A commenter noted these waivers would preferably be
automatic or minimally burdensome to obtain. Another commenter
recommended CMS allow for exceptions to the requirement of converting
Prior Authorization API messages to the X12 278 transaction standard in
scenarios where there is no need for the receiving entity to pass along
the prior authorization transaction to another system. A commenter
sought guidance on whether CMS will consider payers that are not
currently covered under the HIPAA administrative simplification
exception of having prior authorizations sent through the PAS phase of
the Prior Authorization API, translated into and out of the X12 278
transaction standard for an exception. A commenter requested
clarification on whether CMS proposed that the Prior Authorization API
can be used to transform the provision of a health care attachment into
a valid X12 278 transaction standard for meeting HIPAA requirements or
is suggesting that the Prior Authorization API provides an alternative
basis to the proposed X12 278 transaction standard.
Response: We appreciate stakeholder interest in using the FHIR
standard to implement the Prior Authorization API. Unless an impacted
payer is included in the current Da Vinci pilot to test an exception to
the HIPAA transaction, that payer may be required to use the adopted
HIPAA standard when implementing the API. Information on the Da Vinci
pilot is available on the HL7 Da Vinci website.\114\ The participants
in the pilot are testing the prior authorization API over 3 years and
will report to HHS at the end of that time on such metrics as response
time, ability to exchange supporting clinical information, integration
into the provider's workflow, reducing total provider/staff time to
obtain prior authorization, flexibility of the standard, ability to
provide a timely response, and more. The Prior Authorization API can
support the submission of a prior authorization request itself, or
provide data that can support the HIPAA-compliant X12 278 transaction
standard, if used, for prior authorizations, which is then sent as a
separate transmission between the providers and payers, either through
a clearinghouse or through the provider's practice management system.
HL7 provides detailed workflows and graphical depictions of the API and
the HIPAA transaction process.\115\ Finally, this final rule does not
address health care attachments.
---------------------------------------------------------------------------

\114\ Da Vinci Project (2021, May 26). Da Vinci HIPAA Exception.
Retrieved from https://confluence.hl7.org/display/DVP/Da+Vinci+HIPAA+Exception.
\115\ Health Level Seven International (2023, December 1). Da
Vinci Prior Authorization Support (PAS) FHIR: Use Cases and
Overview. Retrieved from https://build.fhir.org/ig/HL7/davinci-pas/usecases.html.
---------------------------------------------------------------------------

Comment: A commenter noted that the lack of requirements for
specific data elements with the X12 278 transaction standard for prior
authorizations limits the value of that transaction standard and would
affect the adoption of the API because providers would lack an
efficient way to identify what critical information to include in a
prior authorization request. Multiple commenters expressed concern
regarding the functionality of the proposal to use the X12 278
transaction standard with the API, and another commenter noted that the
X12 275 transaction standard for health care claims attachments does
not allow for using FHIR, which creates concerns about the
implementation of the Prior Authorization API. Another commenter stated
that certain CAQH CORE operating rules to support HIPAA transactions
were submitted to NCVHS for review and recommendation to HHS in 2023.
These operating rules were specific to certain HIPAA transactions and
included required documentation requirements. The commenter noted that
the operating rules do not name an API documentation requirement, which
is key to locating data in various formats. Finally, another commenter
noted that the X12 and FHIR standards

[[Page 8871]]

do not currently share compatible coding for all the information that
would need to be translated.
Response: We appreciate the concerns commenters expressed regarding
the ability to use the adopted X12 prior authorization transaction with
the Prior Authorization API. Code mapping between the X12 standard and
the FHIR IGs contains X12 standard proprietary information and will
require a license for its use to support the X12 transaction. This
mapping is available on the X12 website through the Glass online viewer
\116\ as HL7 does not publish an X12 mapping artifact.
---------------------------------------------------------------------------

\116\ X12. X12 (2023). Retrieved from www.X12.org.
---------------------------------------------------------------------------

We also note that we did not propose in this rulemaking that the
X12 275 transaction standard be required for use with the Prior
Authorization API. That transaction was proposed for use in the HIPAA
Standards for Health Care Attachments proposed rule (87 FR 78438),\117\
which has not yet been finalized. We reiterate that there are no
operating rule requirements in the HIPAA Administrative Simplification
rules (45 CFR part 162) applicable to the API required for use in this
final rule, or, at this time, to the required HIPAA-compliant X12 278
transaction standard.
---------------------------------------------------------------------------

\117\ National Archives (2022, December 21). Administrative
Simplification: Adoption of Standards for Health Care Attachments
Transactions and Electronic Signatures, and Modification to Referral
Certification and Authorization Transaction Standard. Retrieved from
https://www.federalregister.gov/documents/2022/12/21/2022-27437/administrative-simplification-adoption-of-standards-for-health-care-attachments-transactions-and.
---------------------------------------------------------------------------

Comment: Multiple commenters expressed support to CMS for proposing
an electronic Prior Authorization API that uses the FHIR standard and
IGs in addition to the adopted X12 278 transaction standard to conduct
electronic prior authorization.
Response: We appreciate commenter support for the policy that
utilizes both FHIR and X12 transaction standards. The FHIR standard and
IGs will be used to implement the Prior Authorization API while
supporting compliance with the HIPAA administrative transaction
standard.
Comment: Multiple commenters requested support for their
organizations that are ready and willing to exchange data using FHIR
data and process standards instead of X12 standards. Other commenters
recommended that CMS recognize FHIR data and process standards as a
permitted option for standard transactions (that is, adopted in place
of the X12 standards). These commenters noted that FHIR has
increasingly become the de facto standard in health care since it was
mandated as a standard in the implementation of the Cures Act. To
further accelerate the FHIR standard and exchange of data via FHIR,
commenters recommended that CMS work with other government entities to
eliminate the need for the HIPAA exception requirement for
organizations seeking to exchange data via FHIR directly without X12
transaction standard translation. Some commenters stressed the costs
involved in having to comply with both a new set of standards and
maintain a system for an outdated standard they were not using and for
which they had already developed workarounds. Others suggested that CMS
support both X12 and FHIR to meet market needs and innovation. The SDOs
supported this approach, noting that the FHIR IG is written in such a
way that if the requirement to use the HIPAA standard is removed, the
structure is in place for a FHIR-only transaction.
Response: We appreciate industry interest in moving towards using
the FHIR standard and reiterate that the HIPAA standards are adopted by
HHS. HIPAA covered entities may consider submitting comments regarding
updates to those standards to the Secretary of HHS for consideration.
Comment: Multiple commenters emphasized the importance of exploring
the integration of real-time electronic prior authorization
transactions into workflows as these could reduce payer costs. A
commenter noted that this was also recommended in the 2020 ONC report:
``Strategy on Reducing Regulatory and Administrative Burden Relating to
the Use of Health IT and EHRs.'' A commenter noted these could be used
for medical services and medications that do not typically require
large amounts of supporting documentation. Another commenter
recommended that CMS adopt policies that support integration of
electronic prior authorization into physicians' practice workflows such
as direct financial support for investments in compliant IT platforms,
allowing physicians to access insurer APIs as they work towards full
capability, and supporting flexible sources of documentation for prior
authorization requests within the established framework. A commenter
recommended the electronic prior authorization system be universal
across all payers with information displayed in real-time, with no cost
to clinicians or health systems. The commenter stated that research
showed that switching to real-time electronic prior authorization could
save more money and reduce the time a provider takes to complete a
transaction by 15 minutes on average. The commenter stated that
improving prior authorization processes would benefit every actor in
this transaction. Another commenter expressed the importance for CMS to
acknowledge that real-time prior authorization should be the goal and
that the standards and technology currently exist to implement real-
time prior authorization for certain use cases. A commenter recommended
that payers implement real-time determination by January 1, 2026, for
Medicaid managed care plans, CHIP managed care entities, and QHP
issuers on the FFEs.
Response: Many commenters discussed the potential the Prior
Authorization API and policies in this final rule have for payers to
make real-time decisions, particularly when integrated into both the
payer and provider workflows; however, we did not propose a real-time
decision requirement and are not finalizing such a requirement in this
final rule. Though we anticipate that some of the responses or
decisions may be made in real-time, we anticipate others will continue
to necessitate review and evaluation by clinical staff. We agree that
the automation of a complex process such as prior authorization will
require continuous improvement. Furthermore, some cases will require
manual review because of their complexity. Nonetheless, the overarching
improvements in automation will be an improvement in what exists today.
f. Federal Matching Funds for State Medicaid and CHIP Fee-for-Service
Programs' Expenditures on Implementation of the Prior Authorization API
In section II.E. of this final rule, we discuss Federal matching
funds for certain state Medicaid and CHIP FFS programs' expenditures
related to implementation of the Prior Authorization API (this was also
addressed in the proposed rule at 87 FR 76291 and 76292).
g. Medicaid Expansion CHIP
In section II.E. of this final rule, we discuss implementation for
states with Medicaid Expansion CHIP programs (this was also addressed
in the proposed rule at 87 FR 76292).
3. Requirement for Payers To Provide Reason for Denial of Prior
Authorizations and Notifications
Throughout the Interoperability and Prior Authorization proposed
rule at 87 FR 76292, we described opportunities for improvement with
the prior authorization process, specifically

[[Page 8872]]

where better communication between payers and providers could mitigate
confusion about the status of a prior authorization, particularly if it
was not approved. This section addresses issues about the proposed and
final policy for communication about prior authorization denials and
existing requirements for notifications from impacted payers.
a. Background on Providing a Reason for Denial of Prior Authorization
Payers deny prior authorizations for different reasons, including
because the payer does not consider the items or services to be
medically necessary, the patient exceeded limits on allowable covered
care for a given type of item or service, or documentation to support
the request was missing or inadequate. When a payer provides a specific
reason for a denial, a provider can take appropriate actions such as
re-submitting the request with updated information, identifying
alternatives for the patient, appealing the decision, or communicating
the decision to the patient to enable the patient to consider other
options or to appeal as well. Today, impacted payers send denials
either electronically or through the mail, and the information provided
varies substantially between payers. For denials sent using the X12 278
transaction standard, payers must use the codes from the external code
set maintained by X12. For responses sent through portals, fax, or
other means, payers may use proprietary codes or text to communicate
denial reasons. The process is inefficient and unsatisfactory; and in
general, providers do not have consistent direction on the next steps
for a denied authorization. Our proposal for impacted payers to send a
specific denial reason was one approach to address current
inefficiencies.
We proposed, and are finalizing in this final rule, that, beginning
in 2026, impacted payers must provide a specific reason for denied
prior authorization decisions, regardless of the method used to send
the prior authorization request. As with all policies in this final
rule, this provision does not apply to prior authorization decisions
for drugs. This final policy is an effort to improve the communication
about denials from an impacted payer in response to a request for a
prior authorization through existing mechanisms, such as electronic
portals, telephone calls, email, standard transactions, or other means.
b. Denial Reason and Denial/Decision Codes
Some payers subject to this requirement to provide a specific
reason for denied prior authorization decisions will also remain
subject to existing requirements to provide notice to patients,
providers, or both, with the specific reasons for the denial. In
addition, for certain payers impacted by this final rule, existing
communication requirements related to coverage decisions, notices of
coverage decisions, and appeal processes, remain in effect for coverage
decisions that are made as part of a prior authorization denial or
approval. These requirements are not changed under this final rule. For
example, before an MA plan may issue a prior authorization denial (or
any other organization determination that is a denial) based on medical
necessity, the decision must be reviewed by a physician or other
appropriate health care professional with expertise in the field of
medicine or health care that is appropriate for the services being
requested, including knowledge of Medicare coverage criteria, per 42
CFR 422.566(d); this will apply to any denial of a prior authorization
request, regardless of whether the Prior Authorization API has been
used to request, check the status of, or communicate the decision on
the prior authorization. Nothing in this final rule limits the scope of
the MA regulation at 42 CFR 422.566(d) and it continues to apply to any
prior authorization request and decision that is also subject to the
policies being finalized in this final rule.
Comment: Some commenters recommended that CMS define and provide
examples for terms such as ``approval,'' ``denial,'' and ``specific
reason'' concerning prior authorization denials in the final rule.
Response: We are not adding regulatory definitions for these terms
in this rule, as these terms are clear, frequently used in many
contexts, and commonly used. For this final rule, these terms mean the
following:
Approvals are when the payer authorizes coverage of items
or services for which prior authorization has been requested.
Denials are the refusal by a payer to approve the prior
authorization for a health care item or service. Denials, or rejection
of a prior authorization, may result because the service was not
considered medically necessary under the payer's medical guidelines or
the provider did not provide complete or accurate documentation to
support the request.
A specific reason for denial could include reference to
the specific plan provisions on which the denial is based; information
about or a citation to coverage criteria; how documentation did not
support a plan of care for the therapy or service; a narrative
explanation of why the request was denied, and specifically, why the
service is not deemed necessary or that claim history demonstrated that
the patient had already received a similar service or item.
Comment: Multiple commenters expressed their support for CMS's
proposal to require impacted payers to provide specific reasons for
prior authorization denials, regardless of the mechanism used to submit
the prior authorization request. Multiple commenters also specifically
expressed support for requiring impacted payers to provide the reasons
for denial as part of the information included in the Prior
Authorization and Patient Access APIs. Similarly, commenters expressed
support for CMS's proposal to require impacted payers, particularly MA
organizations, to give providers specific reasons for their prior
authorization denials. Many commenters supported the proposal to
require payers to include in the Prior Authorization API specific
information about prior authorization requests, including the
determination of approval (and for how long), determination of denial
(with a specific reason), and a request for more information from a
provider.
Response: We appreciate the general support for the proposal to
improve this aspect of the prior authorization process, specifically
communication about prior authorization decisions and information about
denials.
Comment: Multiple commenters noted that requiring a reason for
denials and public reporting of prior authorization metrics could help
providers, patients, policymakers, and other interested parties
understand the prior authorization process better. These commenters
asserted that this increased transparency could improve providers'
submissions of prior authorization requests, ensure prior
authorizations are based on the best medical evidence and guidelines,
and allow patients to be better informed regarding their health care
purchasing decisions.
Response: We appreciate the many other comments we received in
support of the proposals to require a reason for denials and public
reporting and discuss other comments specific to those provisions later
in this section. Specifically, we concur that the transparency of
information will support communication between payers, providers, and
patients.
Comment: Multiple commenters recommended that CMS be more specific
about which prior authorization decision information payers should

[[Page 8873]]

include as well as how they should provide this information.
Specifically, multiple commenters recommended that CMS further specify
the level of detail that impacted payers must provide about their
reasons for denial. Other commenters recommended that the information
payers provide regarding reasons for prior authorization denials
include the policy on which the decision was based and the requirements
for coverage assessed, including the standards used to determine
medical necessity. The commenters recommended that CMS require that the
reason for denial provided by payers include the clinical rationale and
patient-specific evidence supporting the denial decision (that is,
which specific criteria the patient did not meet). A commenter
recommended that CMS require payers to provide the following with each
prior authorization decision: whether the prior authorization
adjudication was automatically adjudicated; whether statistical methods
such as AI, machine learning, or other algorithms were used; and
whether a human decision-maker was involved and the name and
credentials of the employee. This commenter noted algorithms should be
publicly accessible so that they can be examined for implicit bias.
Another commenter recommended that CMS require impacted payers to
provide a clinical rationale for prior authorization denials according
to the national medical specialty society guidelines for peer-reviewed
clinical literature. Multiple commenters recommended that CMS specify
that impacted health plans must provide all the prior authorization
decision and denial information in a form that is understandable and
outlines specific steps for the provider, including any additional
information the provider needs to provide to further support the
request, a list of covered alternative treatments, and details
regarding their right to appeal and the process for appeals.
Response: In this final rule, we are requiring impacted payers to
provide a specific reason to the provider when denying a prior
authorization. The volume of comments in this area, as in other areas
of these proposals, was indicative of the challenges providers face in
obtaining specific information about prior authorization decisions and
denials, and that payers face in providing adequate detail for the
decisions they give back to a provider about a prior authorization
denial, such that the provider can take appropriate action. The CMS
Interoperability and Prior Authorization proposed rule and this final
rule do not directly address how prior authorization decisions are
made, such as using AI, statistical methods, requirements for clinical
decisions, or other algorithms, which are out of scope of this specific
rulemaking. However, prior authorization decisions involving AI or
other algorithmic systems must still comply with applicable
requirements, including requirements around clinical decision-making
and the finalized policy requiring communication of the specific reason
for denial. This rule intends to ensure that payers provide better
communication about denials than has been available to date.
There are existing programmatic rules for some of the impacted
payers that also address the content of a denial decision. MA
organizations \118\ are required to provide the specific reasons for
the denial to their enrollees when an item or service is denied, along
with certain other information (such as the ability to appeal the
decision and how). CMS provides a standard form for MA organization
use, which captures a specific and detailed explanation of why the
medical services were denied, including a description of the applicable
coverage rule or applicable plan policy (for example, Evidence of
Coverage provision) upon which the action was based, and a specific
explanation about what information is needed to approve coverage if
applicable. For Medicaid managed care prior authorization decisions, 42
CFR 438.210(b) requires the MCO, PIHP, or PAHP contract with the state
to include provisions requiring the Medicaid managed care plan to
consult with the requesting provider when appropriate and that any
decision to deny a service authorization request or to authorize a
service in an amount, duration, or scope that is less than requested,
be made by an individual who has appropriate expertise in addressing
the enrollee's medical, behavioral health, or long-term services and
supports needs. The regulation at 42 CFR 438.210(c) requires notice
(albeit not necessarily written notice) to the provider of the Medicaid
managed care plan's denial of a service authorization request, or
decision to authorize a service in an amount, duration, or scope that
is less than requested. For Medicaid FFS, 42 CFR 435.917(a) requires
state Medicaid agencies to provide the beneficiary with timely and
adequate written notice of any decision regarding the beneficiary's
prior authorization request, as any such decision would cause a
``denial or change in benefits and services.'' \119\ When a state
denies the prior authorization request in whole or in part, the
beneficiary notice must include, in addition to the content described
at 42 CFR 435.917, the notice content described at 42 CFR part 431,
subpart E, including the requirement at 42 CFR 431.210 that notices
contain a clear statement of the specific reasons supporting the
intended action. Notices must be written in plain language and be
accessible to individuals who have limited English proficiency and
individuals with disabilities consistent with 42 CFR 435.905(b). These
existing provisions, which include a requirement for enrollees to be
provided written notice about an adverse decision, could be useful
examples for the level of specificity that could be given to a
provider, including the applicable medical necessity criteria.
Likewise, for CHIP managed care entities' prior authorization
decisions, 42 CFR 457.1230(d) cross references to 42 CFR 438.210 to
apply Medicaid managed care plans' prior authorization decision
requirements to CHIP managed care entities. Additionally, for QHP
issuers on the FFEs, 45 CFR 147.136(b)(2)(ii)(E) and 29 CFR 2560.503-
1(g) and (j) require group health plans and issuers of group and
individual health insurance coverage to provide notice to individuals,
in a culturally and linguistically appropriate manner, of adverse
benefit determination or final internal adverse benefit determination
and specifies information that this notice must include, such as a
description of the plan's or issuer's standard, if any, that was used
in denying the claim.
---------------------------------------------------------------------------

\118\ See 42 CFR 422.568(e).
\119\ See 42 CFR 435.917(a).
---------------------------------------------------------------------------

When denial information is sent to a provider by any communication
method, including existing notices, the content of a denial should be
sufficiently specific to enable a provider to understand why a prior
authorization has been denied and what actions must be taken to re-
submit or appeal. This requirement would improve the current processes
and reduce manual effort and costs. When implemented, the Prior
Authorization API could mitigate some denials by providing information
about the documentation and information or data necessary to support a
prior authorization request for the service or item.
Comment: Multiple commenters recommended that CMS work with X12 and
other appropriate industry organizations to update the X12 278 Service
Decision Reason Code Set with additional codes for scenarios not yet
covered by the existing code set or for

[[Page 8874]]

use of the X12 Service Decision Reason Codes as the code set for
communicating reasons for the denial. The X12 Service Decision Reason
Code List is a code set maintained by X12 used by HIPAA covered
entities with the HIPAA standard transaction for electronic prior
authorization decisions. A commenter supported using denial codes under
the condition that CMS continue to work with SDOs, NCVHS, and other
relevant organizations to expand the denial reasons and add support for
more specific options. Another commenter requested clarification on
whether the specific reason for the denial requirement must be met by
using the X12 code list of denial reasons. The commenter added that
this code list allows varying interpretations which would result in
ambiguity. Other commenters recommended that CMS establish a clearly
defined standardized set of specific reasons for the denial and require
payers to use them for communicating prior authorization decisions for
all items and services. A commenter recommended that CMS align the FHIR
Certification Action Codes and the X12 Service Decision Reason Codes.
Another commenter stated that the HCR 03 Decision Reason Code is an
optional field in the X12 278 transaction standard and recommended that
CMS refer to ``denial reasons'' as ``decision reason codes.''
Response: We confirm that the X12 Service Decision Reason Code List
is a code set maintained by X12 for electronic prior authorization
decisions. Updates to this code set must be requested through the X12
code maintenance workgroup. We strongly encourage both impacted payers
and providers to evaluate the X12 Decision Reason Code List and make
recommendations to X12 for necessary updated or new codes as
appropriate. We encourage interested organizations and SDOs to continue
their collaboration efforts on crosswalks needed for the IGs supporting
the Prior Authorization API and maintenance of code sets that could be
used with the API. We decline to change the terminology in this final
rule from ``reason for the denial'' to ``decision reasons'' or
``decision reason codes.'' The obligation under this final rule for
impacted payers to provide a specific reason for the denial of a prior
authorization request goes beyond using a single code set and means
that payers must provide sufficient detail in the denial response to
enable the provider to know what action to take as the follow-up to the
denial to obtain coverage--that is whether to appeal, submit additional
documentation, or identify alternative treatment options. Impacted
payers may send additional information through the API which could
provide additional clarity. Finally, though the Medicare FFS program
has a list of decision reason codes in use for its program, and these
could be considered for inclusion in the X12 code set, we did not
propose these for use by all payers as part of this policy. However,
the industry could submit similar text to X12 as additions to that
external code set. We affirm that all denial reasons must be specific.
Comment: Multiple commenters shared concerns about and made
recommendations related to MA organizations' utilization management
policies as these pertain to the denial of prior authorizations.
Response: This rulemaking does not address requirements or
limitations for all utilization management guidelines or policies used
by MA organizations. This rulemaking adopts certain procedural and
timing requirements for prior authorizations and several API
requirements for MA organizations and other impacted payers, including
implementation of a Prior Authorization API, new reporting to CMS, and
new requirements to provide to the applicable provider a specific
reason for the denial of a request for prior authorization. However, in
separate rulemaking for MA organizations, we addressed standards and
requirements for how MA organizations develop and use clinical criteria
and prior authorization policies to help ensure MA beneficiaries
receive the same medically necessary care they would receive under
Traditional Medicare in the CY 2024 MA and Part D final rule (88 FR
22120).\120\ We recommend interested readers review the CY 2024 MA and
Part D final rule for more information on these other requirements for
MA organizations.
---------------------------------------------------------------------------

\120\ See also 42 CFR 422.101(b)(6), 422.112(b)(8), 422.137, and
422.138.
---------------------------------------------------------------------------

Comment: Many commenters described challenges with denials,
including the burdens they faced when attempting to appeal those
denials on behalf of their patients and delays created in access to
care when they did not have information about the reason for the
denial, and therefore little information to include in the response
back to the payer. Multiple commenters wrote that requiring impacted
payers to provide reasons for prior authorization denials would have
positive impacts on the health care system. Multiple commenters stated
that this requirement would facilitate better transparency and
communication between providers and payers. Commenters noted that this
requirement would: (1) allow providers to better communicate the reason
for denial and reasons for potential treatment plan changes to their
patients; (2) provide patients with more insight into how decisions are
made relating to access to care; (3) decrease the number of arbitrary
prior authorization denials and minimize the number of denials that are
overturned on appeal; and 4) reduce unnecessary delays in patient care.
Response: We appreciate the many letters from commenters indicating
support for the provisions of this rule and including in those letters
descriptions of the process challenges that they believe could be
mitigated by the policies being finalized. We concur with the
information in many of the letters that the requirement to provide the
specific reason for the denial in a response to the provider has the
potential to improve communication between payers and providers for the
prior authorization process.
c. Existing Notice Requirements To Communicate Prior Authorization
Denial Information--By Program
Some of the impacted payers are required by existing Federal and
state laws and regulations to notify providers or patients when the
payer makes an adverse decision on a prior authorization request. Our
proposals to impose requirements on payers to communicate certain
information to providers about prior authorization denials were
intended to reinforce and supplement existing Federal and state
requirements and do not alter or replace existing requirements to
provide notice to patients, providers, or both. Further, the
requirements include implementation of a Prior Authorization API that
can provide responses about whether an authorization request has been
approved (and for how long) or denied, a specific reason for the
denial, or request more information from the provider to support the
prior authorization. Communicating denial reasons with specific
information, in addition to the existing program notification
requirements, will increase transparency, reduce burden, and improve
efficiencies for both payers and providers. The API requirements have
compliance dates in 2027.
i. Denial Notice Requirements
This section of the final rule addresses denial notice requirements
which will remain in place for MA organizations, CHIP FFS, Medicaid

[[Page 8875]]

managed care plans, and CHIP managed care entities.
Under the MA program, the actions that constitute an ``organization
determination'' include a prior authorization decision (as well as a
decision in response to a voluntary pre-service request for a decision
on coverage), as it is defined as including an MA organization's
refusal to provide or pay for services, in whole or in part, including
the type or level of services that the enrollee believes should be
furnished or arranged by the MA organization as well as other types of
decisions about coverage and payment.\121\ Existing MA program
regulations impose requirements as to the form and content of the
written notice to enrollees in the event of a partial or full denial.
For example, existing regulations regarding written notices for
enrollees for standard organization determinations require that notice
for any denial by the plan of coverage of an otherwise covered service
or item must--
---------------------------------------------------------------------------

\121\ See 42 CFR 422.566(b).
---------------------------------------------------------------------------

Use approved notice language in a readable and
understandable form;
State the specific reasons for the denial;
Inform the enrollee of their right to a reconsideration;
Describe both the standard and expedited reconsideration
processes, including the enrollee's right to, and conditions for,
obtaining an expedited reconsideration and the rest of the appeal
process; and
Comply with any other notice requirements specified by
CMS.\122\
---------------------------------------------------------------------------

\122\ See 42 CFR 422.568(e).
---------------------------------------------------------------------------

Under existing requirements,\123\ if the MA organization expedites
an organization determination, the MA organization must notify the
enrollee (or the enrollee's representative) and the physician involved,
as appropriate, of its decision, whether adverse or favorable, as
expeditiously as the enrollee's health condition requires, but no later
than 72 hours after receiving the request. Either an enrollee or a
physician, regardless of whether the physician is affiliated with the
MA organization, may request that an MA organization expedite an
organization determination.\124\ The notice of expedited determination
must state the specific reasons for the determination in understandable
language and if the determination is not completely favorable to the
enrollee, the notice must also--
---------------------------------------------------------------------------

\123\ See 42 CFR 422.572.
\124\ See 42 CFR 422.570.
---------------------------------------------------------------------------

Inform the enrollee of their right to a reconsideration;
Describe both the standard and expedited reconsideration
processes, including the enrollee's right to request, and conditions
for obtaining an expedited reconsideration, and the rest of the appeal
process; and
Comply with any other requirements specified by CMS as to
the content of the notice.\125\
---------------------------------------------------------------------------

\125\ See 42 CFR 422.572.
---------------------------------------------------------------------------

Because applicable integrated plans (D-SNPs that have exclusively
aligned enrollment with an affiliated Medicaid MCO) are a type of MA
plan, the regulations regarding prior authorization processes that we
are finalizing apply to them. The final rule revises the specific
timeframes for prior authorization decisions by applicable integrated
plans. Applicable integrated plans cover both Medicaid long term
services and supports and MA benefits in ten states. Existing
requirements already govern denial notices issued by applicable
integrated plans to their enrollees and are similar to the Medicaid
managed care and MA rules described in the prior paragraphs.\126\
Integrated organization determination notices must be written in plain
language, available in a language and format that is accessible to the
enrollee, and explain--
---------------------------------------------------------------------------

\126\ See 42 CFR 422.631.
---------------------------------------------------------------------------

The applicable integrated plan's determination;
The date the determination was made;
The date the determination will take effect;
The reasons for the determination;
The enrollee's right to file an integrated reconsideration
and the ability for someone else to file an appeal on the enrollee's
behalf;
Procedures for exercising an enrollee's rights to an
integrated reconsideration;
The circumstances under which expedited resolution is
available and how to request it; and
If applicable, the enrollee's rights to have benefits
continue pending the resolution of the integrated appeal process.
As with the notices required from MA plans, our finalized policies
do not change the content requirements for these written denial notices
to enrollees but will supplement these notices by requiring applicable
integrated plans to notify the provider of the reason for a denial of a
prior authorization request.
For Medicaid managed care plans and CHIP managed care entities,
existing regulations at 42 CFR 438.210(c) require notice to the
provider without specifying the format or method, while 42 CFR
438.210(c) and 438.404(a) require written notice to the enrollee of an
adverse benefit determination. In addition, 42 CFR 438.210(c) requires
notice (albeit not necessarily written notice) to the provider as well
of the Medicaid managed care plan's denial of a service authorization
request or decision to authorize a service in an amount, duration, or
scope that is less than requested. CHIP managed care entities are
required to comply with similar standards at 42 CFR 457.1230(d)
(referencing 42 CFR 438.210) and 457.1260(c) (referencing 42 CFR
438.404). Nothing in this final rule will limit the existing enrollee
notification requirements at 42 CFR part 438 for Medicaid managed care
plans and at 42 CFR part 457 for CHIP managed care entities as these
requirements will remain in full effect. This final rule fills a
potential gap concerning the information communicated to providers
regarding a denial of a prior authorization request. We proposed and
are finalizing that the response--whether the authorization request has
been approved (and for how long), denied (with the reason for the
denial), or a request for more information to support the prior
authorization--if transmitted to providers via the Prior Authorization
API workflow process or other means, will be sufficient to satisfy the
current requirement for notice to providers at 42 CFR 438.210(c) and
457.1230(d). We are finalizing a slight modification to the regulatory
language to use ``the date or circumstance under which the
authorization ends'' instead of ``how long'' as the scope of
information that must be provided by the payer. The payer will not be
required to send the response to the provider via both the Prior
Authorization API (which is required to furnish certain information,
including denial reason) and a separate, additional manner (for
example, separate written notice or phone call) with duplicate
information. However, given that providers are not required to use the
Prior Authorization API, the payer must ensure that the response to the
provider with the reason for the denial must be furnished to the
provider through some means.
We also remind all Medicaid managed care plans and CHIP managed
care entities subject to this final rule that their existing
obligations to provide these required notices to patients are not
changed by the final policies in this rule. These payers will still
have to

[[Page 8876]]

provide a separate written notice to the enrollee.
QHP issuers on the FFEs that offer individual health insurance must
provide the specific reason for an adverse benefit determination, which
includes denial of prior authorization.\127\ Furthermore, plans and
issuers must ensure that notice is made to individuals in a culturally
and linguistically appropriate manner that complies with existing
requirements.\128\
---------------------------------------------------------------------------

\127\ See 45 CFR 147.136(b)(3)(ii)(E).
\128\ See CFR 147.136(b)(2)(ii)(E) and 29 CFR 2560.503-1(g) and
(j).
---------------------------------------------------------------------------

Finally, impacted payers may be required to provide this
information in languages other than English, which requires impacted
payers (as health programs or activities under that section) to provide
meaningful access to individuals with limited English proficiency and
accessibility requirements for individuals with disabilities.\129\
---------------------------------------------------------------------------

\129\ See 45 CFR 92.3 and 92.101.
---------------------------------------------------------------------------

ii. Notice and Payer Communications
We received comments on the current processes for notice and payer
communications and summarize those and our responses here. Generally,
such processes exist for MA organizations, Medicaid managed care plans,
CHIP managed care entities, and QHP issuers on the FFEs.
Comment: Multiple commenters expressed frustration with the
variation of prior authorization requirements across MA plans,
inconsistencies in access to care and coverage, and painful
interactions during lengthy peer-to-peer review of medical necessity
assessments with MA organizations. A commenter expressed support for
the proposal in the CY 2024 MA and Part D proposed rule (87 FR 79452)
to prohibit MA plans from diverting a patient to a different level of
care than recommended by the patient's physician when the patient
otherwise meets all the clinical criteria appropriate for the setting
requested by the physician. Commenters noted these factors have
contributed to a more complicated prior authorization process, extended
wait times, duplicate or inaccurate prior authorization denials and
post-claim denials, and a shifting focus from patient care. Multiple
commenters recommended CMS implement increased oversight policies to
address MA's challenging prior authorization landscape. Multiple
commenters recommended that CMS continue to oversee MA plans' use of
prior authorization and advance policies that ensure that MA enrollees
have the same access to covered services as those enrolled in
Traditional Medicare and that MA organizations cannot use more
stringent criteria than Traditional Medicare.
Response: As finalized in the CY 2024 MA and Part D final rule, 42
CFR 422.138 provides that coordinated care plan prior authorization
policies may only be used to confirm the presence of diagnoses or other
medical criteria and/or ensure that an item or service is medically
necessary. Second, the CY 2024 MA and Part D final rule requires
coordinated care plans to provide a minimum 90-day transition period
when an enrollee currently undergoing treatment switches to a new MA
plan, during which the new MA plan may not require prior authorization
for the active course of treatment (42 CFR 422.112(b)(8)(ii)(B)).
Third, to ensure prior authorization is being used appropriately, we
are requiring all MA plans that use utilization management policies
(like prior authorization) to establish a Utilization Management
Committee to review policies annually and ensure consistency with
Traditional Medicare's NCDs, LCDs, and guidelines; compliance with
limits on how prior authorization can be used; compliance with other MA
regulations on determining medical necessity (42 CFR 422.101(c)); and
consultation with network providers (42 CFR 422.202(b) and 422.137).
Finally, to address concerns that the CY 2024 MA and Part D proposed
rule did not sufficiently define the expected duration of ``course of
treatment,'' a newly adopted regulation at 42 CFR 422.112(b)(8)
requires that a coordinated care MA plan's approval of a prior
authorization request for a course of treatment must be valid for as
long as medically necessary to avoid disruptions in care in accordance
with applicable coverage criteria, the patient's medical history, and
the treating provider's recommendation. The CY 2024 MA and Part D final
rule and this final rule taken together provide significant guardrails
for prior authorization in the MA program and support a more
streamlined process, which will ultimately lead to reduced burden in
health care.
Comment: A commenter was concerned that without specific guidance
for MA plans regarding certain benefits, the proposed rule will
negatively impact the already existing barriers to electronic exchange
of information between MA organizations and religious nonmedical health
care institution (RNHCI) providers. This commenter supported the
concept of the Prior Authorization API because it makes possible the
electronic exchange of certain prior authorization information between
payers and providers, which RNHCIs have long desired. However, the
organization was concerned about the requirement at 42 CFR 422.122(b)
because of concerns about its applicability to nonmedical benefits.
This commenter proposed amendments to the regulatory text regarding the
obligation to accept and exchange information.
Response: The requirements proposed at 42 CFR 422.122(b) apply to
all covered Medicare services, including covered items and services
furnished by a RNHCI, and all MA supplemental benefits covered by an MA
plan, excluding all drugs, as defined at 42 CFR 422.119(b)(1)(v). See
section I.D. for more information about the exclusion of drugs from the
scope of the prior authorization policies in this rule.
We are finalizing that the prior authorization requirements adopted
in this final rule supplement and do not replace requirements in other
applicable laws, including existing requirements for MA plans, Medicaid
managed care plans, CHIP managed care entities, and QHP issuers on the
FFEs regarding decisions made on requests for prior authorization of
covered benefits. For additional explanation on the continued
applicability of existing standards in this final rule, we are adding
paragraph (b)(5) to 42 CFR 422.122 to explain that prior authorization
decisions made under 42 CFR 422.122 must meet all other applicable MA
requirements in subpart M of part 422, such as the adjudication
timeframes and notice requirements. Under existing standards for
Medicaid managed care plans, all prior authorization decisions by
Medicaid managed care plans must comply with 42 CFR 438.210 as well as
notice requirements at 42 CFR 438.404.
4. Requirements for Prior Authorization Decision Timeframes and
Communications
a. Impact of Delays in Prior Authorization Decisions: Background of
Decision Timeframes
As discussed in the CMS Interoperability and Prior Authorization
proposed rule (87 FR 76294), CMS learned through listening sessions and
other public meetings that excessive wait time for prior authorization
decisions could cause delays to patient care and create medical risks
in some cases. Providers face delays for the approval of the initial
request, or, secondarily, for the resolution of a request ``in
process,'' often meaning the payer is reviewing requested
documentation. In 2019, CMS

[[Page 8877]]

conducted outreach to external entities (87 FR 76294) and received many
comments about timeframes for processing prior authorizations, where
commenters explained that the process of securing approvals for prior
authorization directly affects patient care by delaying access to
services, including transfers between hospitals and post-acute care
facilities, treatment, medication, and supplies. Commenters believed
that these delays occur partly because payers have different policies
and review processes, do not use available technologies consistently,
and continue to rely on manual systems such as phone, fax, and mail,
which are more labor-intensive.
b. Standard and Expedited Prior Authorization Requests and Decision
Timeframes
In the CMS Interoperability and Prior Authorization proposed rule
we used the terms standard and expedited prior authorizations to refer
to two types of prior authorizations for which we are now finalizing
our policies--in this final rule, we affirm that the term ``standard''
prior authorization refers to non-expedited, non-urgent requests and
the term ``expedited'' prior authorization indicates an urgent request.
These terms continue to be used in CMS regulations.\130\ We received a
few comments on these terms and respond to those here.
---------------------------------------------------------------------------

\130\ See 42 CFR 422.568, 422.570, 422.572, and 422.631 for MA
organizations and applicable integrated plans and 42 CFR 438.210(d)
and 438.404 for Medicaid managed care plans.
---------------------------------------------------------------------------

Comment: Multiple commenters stated that there was a lack of
clarity and guidance on the definition of a standard versus an
expedited prior authorization. A commenter recommended that CMS create
additional specificity around what ``expedited'' means, especially for
mental health and substance use disorder conditions. Another commenter
stated that what one provider may deem an expedited request may not be
considered one by the payer. A commenter noted that the lack of a
standard definition leads to discrepancies on what a payer considers
``urgent'' and sometimes leaves some discretion up to the provider.
This lack of standardization can adversely affect a patient. If a payer
has a stricter definition of what constitutes an expedited prior
authorization, this could lead to the patient waiting up to 7 days for
a decision and delay access to care further if prior authorization is
denied. Commenters stated that CMS should release guidance on
definitions of these terms to facilitate more alignment for payers and
strengthen patient access by minimizing variation between network
standards on what is considered ``urgent'' versus ``normal.'' Another
commenter requested that CMS provide clarification on timeframes in
emergencies and if emergency care would override prior authorization
rules.
Response: We decline to create a new definition for standard and
expedited, as the definitions for standard and expedited requests
provide a foundation upon which both payers and providers can rely for
making professional judgments. These terms are used in the provisions
at 42 CFR 422.568, 422.570, 422.572, and 422.631 for MA organizations
and applicable integrated plans. Similar terms are used at 42 CFR
438.210(d) for Medicaid managed care plans, at 42 CFR 457.1230(d) for
CHIP managed care entities (87 FR 76294), and we are adding
requirements at 42 CR 440.230 for Medicaid FFS and at 42 CFR 457.495
for CHIP FFS to meet these timelines--specifically, as expeditiously as
a beneficiary's health condition requires, that may not exceed either 7
calendar days or 72 hours after receiving the request for standard or
expedited requests respectively.
A standard for when expedited determinations are required currently
exists for MA organizations at 42 CFR 422.566(a), which requires MA
organizations to have an expedited procedure for situations in which
applying the standard procedure could seriously jeopardize the
enrollee's life, health, or ability to regain maximum function.\131\
This long-standing medical exigency standard is familiar to MA plans
and providers and affords sufficient guidance on when an expedited
decision is necessary. There is adequate guidance on these standards
for the MA appeals and organization determination deadlines already.
For Medicaid managed care and (by cross reference) CHIP managed care,
42 CFR 438.210(d)(2)(i) specifies an expedited authorization is
required when ``following the standard timeframe could seriously
jeopardize the enrollee's life or health or ability to attain,
maintain, or regain maximum function.'' Standard prior authorization
requests are used when the enrollee's life or health or ability to
attain, maintain, or regain maximum function are not seriously
jeopardized by the managed care plan using the longer, standard
authorization timeframes. These policies are intended to ensure that
impacted payers, including Medicaid FFS, Medicaid managed care plans,
and CHIP managed care entities will evaluate expedited prior
authorization review procedures that will minimize patient risk. We
confirm that MA plans, Medicaid managed care plans, and CHIP managed
care entities are prohibited from applying prior authorization
requirements to evaluation and stabilization services for emergency
medical conditions.\132\
---------------------------------------------------------------------------

\131\ See 42 CFR 422.570 and 422.572.
\132\ See sections 1852(d), 1932(b)(2), and 2103(f)(3) of the
Act and 42 CFR 422.113, 438.114, and 457.1228.
---------------------------------------------------------------------------

Comment: A commenter asserted that eliminating the need for a
provider to reach out to a payer and notify them of a request that
requires an expedited response would reduce a provider's administrative
burden and further the efficiency of the prior authorization process.
The commenter recommended CMS request that payers be required to have
systems that enable providers to electronically differentiate between
standard and expedited prior authorization requests.
Response: While this final rule addresses several important prior
authorization processes, it does not specifically dictate all payer
operational procedures. Existing regulations in the applicable programs
covered by this final rule may address the circumstances under which a
payer must make a coverage decision, such as a prior authorization
request on an expedited basis. For example, under the MA rules at 42
CFR 422.570, an enrollee or a physician (regardless of whether the
physician is affiliated with the MA organization) may request that an
MA organization expedite an organization determination involving a
request for an item or service. The MA organization must promptly
decide whether to expedite an organization determination. Under the
rules at 42 CFR 422.570(c)(2), if a request is made by an enrollee, the
MA organization must provide an expedited determination if it
determines that applying the standard timeframe for making a
determination could seriously jeopardize the life or health of the
enrollee or the enrollee's ability to regain maximum function. If a
request for an expedited decision is made or supported by a physician,
the MA organization must provide an expedited determination if the
physician indicates that applying the standard timeframe for making a
determination could seriously jeopardize the life or health of the
enrollee or the enrollee's ability to regain maximum function. The
existing medical exigency standard related to expedited requests will
continue to

[[Page 8878]]

apply to organization determinations that involve prior authorization.
The recommended PAS IG may not currently have the instructions to
provide the capability to differentiate between standard and expedited
prior authorization requests. However, this data element could be a
helpful addition for the next version, and interested parties are
encouraged to discuss this at an HL7 workgroup meeting. There may be
other means through the payer's Prior Authorization API to determine
how an indicator for the type of prior authorization request might be
incorporated. The current version of FHIR includes a required data
element to indicate the urgency of a request. In FHIR technical
terminology, this required data element is named ``claim.priority.''
However, there is no equivalent value in the HIPAA X12 278 transaction
standard or the X12 external code lists because that data element is
not required in that standard. The PAS IG does not provide any mapping
to X12. For those entities conducting the end-to-end FHIR exchange, the
information about expedited and standard prior authorization requests
is available to them through the FHIR claim.priority data element. As
noted, the X12 278 transaction standard does not include this
information because the current version of the X12 278 transaction
standard for prior authorizations does not support this concept. An
alternative to using the claim.priority data element when using the X12
278 transaction standard for expedited requests would be to include a
service date, to indicate urgency.
c. Decision Timeframes for Standard and Expedited Prior Authorization
Requests
To improve patient care outcomes and ensure that patients have more
timely access to services, we are finalizing our proposals to create,
improve, or shorten prior authorization timeframes for certain payers
to respond to prior authorization requests for covered items and
services, excluding drugs. Specifically, we are finalizing that these
timeframes would be 72 hours for expedited requests, unless a shorter
minimum timeframe is established under applicable state law,\133\ and 7
calendar days for standard requests with the possibility of an
extension to up to 14 days in certain circumstances. We acknowledged
that some of the payers affected by this final rule had different
requirements for prior authorization decision notice and appeal
timeframes, and we are aligning the prior authorization decision
timeframes across those payers except for QHPs on the FFEs, as further
discussed. For some payers, the existing regulation already uses the
timeframe we are adopting in this final rule for standard or expedited
requests for prior authorization; those regulations will continue to
apply while amendments to adopt the new timeframes for other payers
will apply to their prior authorization decisions, beginning in 2026.
---------------------------------------------------------------------------

\133\ The final policies adopted here for state Medicaid and
CHIP FFS programs and Medicaid managed care plans and CHIP managed
care entities at 42 CFR 438.210 and 457.495(d)(2), respectively,
include that a state may set a shorter timeframe for these
decisions. However, such state authority does not apply to MA plans
operating in these states.
---------------------------------------------------------------------------

In the CMS Interoperability and Prior Authorization proposed rule
(87 FR 76295), we provided a chart identifying which regulations we
proposed to modify the decision timeframes for standard prior
authorization decisions made by MA organizations and applicable
integrated plans, CHIP FFS programs, Medicaid managed care plans, and
CHIP managed care entities.\134\ Table E1 at the end of this section
provides the final Federal requirements for prior authorization
decision timeframes that will apply to each payer beginning in 2026.
---------------------------------------------------------------------------

\134\ See 42 CFR 422.570, 422.572, 422.631(c) and (d)(2)(iv)(A),
438.210(d)(2), and 457.1230(d).
---------------------------------------------------------------------------

We did not propose to change any existing timeframes that might
apply to expedited authorization decisions made by any of the impacted
payers, especially given that many of these payers already apply a 72-
hour maximum timeframe for such requests. To ensure consistency and
correctly describe the new timeframes being finalized for these payers
to provide notice of standard determinations, we proposed and are
finalizing certain conforming amendments to the CFR sections listed in
Table E2.
QHPs are not included in the policy on timeframes for the reasons
described at the end of this section. Note that these timeframes do not
apply to any drugs, as discussed in section I.D. of this final rule.
We proposed that beginning January 1, 2026, MA organizations and
applicable integrated plans must provide notice of prior authorization
decisions as expeditiously as a patient's health condition requires,
but no later than 7 calendar days for standard requests. For MA
organizations, on or after January 1, 2026, prior authorization
requests for items and services covered by the finalized requirements
at 42 CFR 422.122 will be affected by this final rule; for all other
items and services, existing timeframes under the MA regulations for
other pre-service requests for an organization determination would
remain applicable. These deadlines are reflected in amendments to 42
CFR 422.568(b)(1) (for MA plans) and 422.631(d)(2)(i) (for applicable
integrated plans).
We proposed and are finalizing conforming amendments to certain
regulations that reference or describe the timeframes that are being
amended in this final rule. Specifically, we proposed and are
finalizing an amendment to the MA program regulation at 42 CFR 422.570;
the revision replaces references to the specific length of the
timeframe for standard decisions with a general reference to 42 CFR
422.568 which we are also amending to include the new timeframe(s) for
prior authorization decisions for items and services.
In addition, this final rule does not change existing Federal
timeframes for expedited and standard determinations on requests for
Part B drugs for MA organizations and applicable integrated plans;
current regulations require notice to the enrollee as expeditiously as
the enrollee's health condition requires, but no later than 72 hours
after receiving the request for a standard determination and as
expeditiously as the enrollee's health condition requires, but no later
than 24 hours after receiving an expedited request.\135\ Due to the
finalized revisions to 42 CFR 422.568(b), we are redesignating existing
42 CFR 422.568(b)(2) related to requests for Part B drugs for MA
organizations to 42 CFR 422.568(b)(3).
---------------------------------------------------------------------------

\135\ See 42 CFR 422.568(b)(3), 422.572(a)(2), and 422.631(a).
---------------------------------------------------------------------------

Furthermore, an MA plan must automatically transfer a request to
the standard timeframe if the MA plan denies a request for an expedited
organization determination or an applicable integrated plan denies a
request for an expedited integrated organization determination.\136\
This step to automatically transfer expedited requests to the standard
timeframe is consistent with Medicaid and CHIP managed care provisions
listed in Tables E2, E3, and E4.
---------------------------------------------------------------------------

\136\ See 42 CFR 422.570(d)(1) and 422.631(d)(2)(iv).
---------------------------------------------------------------------------

As there are no existing CMS regulations imposing timeframes for
state Medicaid FFS programs to provide notice of prior authorization
decisions, in the proposed rule we specified that these programs must
provide notice of such decisions as expeditiously as a patient's health
condition requires, but no later than 72 hours for expedited requests
and 7 calendar days for

[[Page 8879]]

standard requests unless a shorter minimum timeframe is established
under state law. For CHIP FFS, existing regulations require states to
provide prior authorizations within 14 days or according to existing
state law, in accordance with the medical needs of the beneficiary.
Also, a possible extension of up to 14 days may be permitted if the
beneficiary requests the extension or if the physician or health plan
determines that additional information is needed.\137\ To align with
Medicaid, we are finalizing for CHIP FFS that beginning in 2026, states
must provide notice of prior authorization decisions in accordance with
the medical needs of the beneficiary, but no later than 7 calendar days
after receiving the request for a standard determination and by no
later than 72 hours after receiving the request for an expedited
determination.
---------------------------------------------------------------------------

\137\ See 42 CFR 457.495(d).
---------------------------------------------------------------------------

For Medicaid managed care plans and CHIP managed care entities, we
proposed, and are now finalizing, to change the maximum permitted
timeframe for the payer to send notices of prior authorization
decisions as expeditiously as a patient's health condition requires,
but no later than 7 calendar days for standard requests beginning with
the first rating period that starts on or after January 1, 2026. We are
also finalizing requirements for Medicaid managed care plans and CHIP
managed care entities concerning the timeframes for prior authorization
of services (under 42 CFR 438.210 and 457.1230) but not the timeframes
for issuing notices of other adverse benefit determinations and appeals
under 42 CFR 438.404(c)(1) and (2) and 457.1260.
The provisions at 42 CFR 438.210(d)(2)(i) and 457.1230(d) require
Medicaid managed care plans and CHIP managed care entities to make an
expedited authorization decision no later than 72 hours after receipt
of the request if the provider requesting the authorization indicates
that following the standard timeframe could seriously jeopardize the
beneficiary's life or health or ability to attain, maintain, or regain
maximum function. If Medicaid managed care plans or CHIP managed care
entities deny an expedited request, that request becomes standard and
must be reviewed within 7 days.
State law or managed care plan contracts may impose a shorter
timeframe for these decisions in Medicaid and CHIP; the shorter
timeframe would govern for state Medicaid and CHIP FFS programs,
Medicaid managed care plans, and CHIP managed care entities, as
applicable.\138\ If state law imposes a longer timeframe, payers must
comply with Federal regulations within the shorter Federal timeframe--
which will automatically make them compliant with their state
regulations. For this reason, we are adding to the Medicaid managed
care regulations at 42 CFR 438.210(d)(2)(i) and (d)(1), respectively,
and CHIP managed care regulations at 42 CFR 457.1230(d), respectively,
that the decision must be made as expeditiously as the enrollee's
condition requires but no later than 72 hours in the case of expedited
requests or 7 calendar days in the case of standard requests unless a
shorter minimum timeframe is established under state law.
---------------------------------------------------------------------------

\138\ In addition, States may, by contract, require applicable
integrated plans to use shorter decision timeframes. See 42 CFR
422.629(c).
---------------------------------------------------------------------------

State laws do not apply to MA plans, based on the preemption
provision in section 1856(b) of the Act and at 42 CFR 422.402, which
provides that the Federal standards established for MA plans supersede
any state law or regulation, other than state licensing laws or state
laws relating to plan solvency, with respect to the MA plans that are
offered by MA organizations.
This final rule does not change the 72-hour timeframe required by
current Federal regulations, or the authority for an extension of that
timeframe, for expedited decisions made by MA organizations and
applicable integrated plans, Medicaid managed care plans, and CHIP
managed care entities.
For the reasons discussed in the CMS Interoperability and Prior
Authorization proposed rule, we are not requiring that impacted payers
approve a request for prior authorization if that payer did not meet
the required standard or expedited decision timeframe (87 FR 76297). If
a payer fails to meet the timeline for approval or other decision,
providers should contact the payer to obtain the status of the request
and determine if supporting documentation is needed to complete the
processing of the authorization or if there are other reasons for the
delay in a decision. Some programs, such as the MA program (and
including applicable integrated plans) and the Medicaid and CHIP
managed care programs, have regulations that include provisions for the
failure to provide timely notice of an organization determination;
generally, such a failure to meet the timeframe constitutes an adverse
decision that may be appealed.\139\
---------------------------------------------------------------------------

\139\ See 42 CFR 422.568(f), 422.631(d)(1)(ii), 438.404(c)(5),
and 457.1260(b)(3).
---------------------------------------------------------------------------

The final rule does not change timeframes for prior authorization
processes for QHP issuers on the FFEs, in part because existing
regulations at 45 CFR 147.136 establish internal claims and appeals
processes, external review processes, and pre-service claims
requirements for all non-grandfathered group and individual market
plans or coverage. Specifically, individual health insurance issuers
are required to meet minimum internal claims and appeals
standards.\140\ The current regulations for group health plans and
group and individual market health insurance issuers adequately protect
patient interests. QHP issuers on the FFEs are required to provide
notification of a plan's benefit determination within 15 days for
standard authorization decisions and within 72 hours for expedited
requests, which is consistent with the other CMS payers affected by
this provision.
---------------------------------------------------------------------------

\140\ See 45 CFR 147.136(b)(3).
---------------------------------------------------------------------------

We requested comments on the timeframe proposals and provide the
summarized comments and responses here.
Comment: Multiple commenters disagreed with the proposal to exclude
QHP issuers on the FFEs from prior authorization shortened decision
timeframe requirements and recommended that CMS reconsider the
exclusion of these payers. Some commenters expressed concern that
excluding QHP issuers on the FFEs from shorter prior authorization
decision timeframe requirements would result in a negative effect on
patient care. Commenters asserted that patients under these plans
should be entitled to the same protections as others under this
regulation. A commenter stated that they did not believe that
shortening a QHP issuer on the FFEs' decision timeframe from the
current 15-day response time for standard requests to 7 days would pose
an undue burden. Another commenter encouraged CMS to work to align
prior authorization notification requirements across all impacted
payers as this could avoid confusion amongst patients and providers
regarding whether a patient is covered by a QHP. Multiple commenters
wrote that CMS should include QHP issuers on the FFEs in regulations
requiring even shorter prior authorization decision timeframes: 24
hours for urgent or expedited requests and 72 hours for standard
requests. A commenter recommended CMS impose a standard of 24 hours for
expedited requests and 48 hours for standard requests and specified
that this standard should apply to all payers, including those on the
Exchanges. However, multiple commenters supported the

[[Page 8880]]

proposal to leave in place the current prior authorization decision
timeframes applicable to QHP issuers on the FFEs. These commenters
raised general concerns about payer burden due to expedited timeframes
and agreed specifically that applying expedited timeframes to QHP
issuers on the FFEs could harm consumers by reducing participation by
QHP issuers on the FFEs. A commenter recommended that timeframes be
measured with business days as opposed to calendar days.
Response: We discussed in the CMS Interoperability and Prior
Authorization proposed rule the reasons why we did not propose to
change timeframes for prior authorization processes for QHP issuers on
the FFEs. We did not propose and are not finalizing, any changes to
prior authorization timeframes for QHP issuers on the FFEs, in part
because existing regulations at 45 CFR 147.136 establish internal
claims and appeals processes, external review processes, and pre-
service claims requirements for all non-grandfathered group and
individual market plans or coverage. Specifically, individual health
insurance issuers are required to meet minimum internal claims and
appeals standards.\141\ We believe the current standard adequately
protects patient interests. QHP issuers on the FFEs are required to
provide notification of a plan's benefit determination within 15 days
for standard authorization decisions and within 72 hours for expedited
requests; thus, QHP issuers on the FFEs have the same timeframe for
expedited authorization decisions as other impacted payers in this
final rule. For reasons discussed in this section, we are not
finalizing any timeframes shorter than 72 hours for expedited requests
for any impacted payers at this time. Additionally, the benefits for
the patient of a shorter timeframe for standard prior authorization
decisions should outweigh the additional burden that QHP issuers on the
FFEs might experience, as compared to off-Exchange plans. Aligning
timeframe requirements for prior authorization decisions across
individual and group market plans would reduce the burden of compliance
for QHP issuers on the FFEs for the proposed prior authorization
requirements while continuing to protect consumer interests. Finally,
making changes to regulations applicable to all non-grandfathered group
and individual market plans or coverage for consistency with the
proposed approach was outside the scope of the proposed rulemaking.
While we are finalizing this rule as proposed, the prior authorization
information that this final rule requires QHP issuers on the FFEs to
publicly report per 45 CFR 156.223(c) will help provide insight into
prior authorization timelines and practices that may support further
improvements in the future.
---------------------------------------------------------------------------

\141\ See CFR 147.136(b)(3).
---------------------------------------------------------------------------

Comment: Multiple commenters supported the revised standard prior
authorization decision timeframe of 7 calendar days, and many
commenters supported the 72-hour decision timeframe for expedited prior
authorization requests. Additionally, a commenter requested
clarification on whether the 7-day standard decision timeframe would be
calendar days or business days. A commenter recommended counting the
turnaround time in business days rather than calendar days because
processing prior authorization requests requires careful evaluation by
payers and a review process that is dependent on working days as
opposed to calendar days. Defining the turnaround timeframe by calendar
days limits the time needed by payers to accurately reach a decision
and is further reduced during holidays. This commenter suggested
providing a timeframe that aligns with the number of working hours a
payer has to evaluate a request and suggested CMS provide 7 business
days. The commenter indicated that such an approach aligns with
turnaround times for HIPAA transactions and would therefore prevent
confusion over using both calendar days and business days. Another
commenter recommended that the proposed standard be reduced from 7 days
to 72 hours, stating that tracking timelines using hours instead of
days will preclude any confusion or ambiguity regarding calendar days
or business days.
Response: We reiterate that current regulations are specific to
using hours for expedited requests and we are not modifying the
terminology for that requirement of 72 hours for expedited requests.
For example, if a prior authorization request is submitted at 1:00 a.m.
on Sunday, a response within 72 hours would mean by 1:00 a.m. on
Wednesday. The regulations do not contemplate delays based on business
hours or business days. For standard prior authorization requests, the
current regulations (that is, before the amendments made by this final
rule) for MA plans and Medicaid and CHIP managed care programs use the
term ``calendar days,'' in recognition of health care services being
agnostic of business days. The amendment we proposed and are finalizing
for standard prior authorization decisions is ``7 calendar days.'' This
final rule applies to the business process of the prior authorization
request and decision, and not the transmission of the HIPAA standards
when used for the request.
Comment: Multiple commenters recommended having shorter decision
timeframes that are less than 7 calendar days for standard prior
authorization requests, ranging from 5 days, 72 hours, 48 hours, and 24
hours. Some commenters also suggested that decisions be made in real-
time. In general, commenters recommended that CMS create faster prior
authorization response timelines to improve the patient experience and
access to care.
Response: We are finalizing a requirement that prior authorization
decisions be rendered as expeditiously as the patient's condition
requires, but no later than 7 calendar days requires impacted payers to
render their decision based on patient-specific information within 7
calendar days (or shorter if otherwise required via contract or state
law) being the maximum. Further, as discussed in the proposed rule, we
did not propose to change timeframes for prior authorization processes
for QHP issuers on the FFEs, in part because existing regulations at 45
CFR 147.136 establish internal claims and appeals processes, external
review processes, and we believe the current standard adequately
protects patient interests.\142\ We will continue to review these
comments and the supporting information to determine how we might
incorporate such policies in future rulemaking as part of our ongoing
mission to improve the patient and provider experience.
---------------------------------------------------------------------------

\142\ See 87 FR 76297.
---------------------------------------------------------------------------

Comment: Another commenter indicated that timely approvals for
discharge to an appropriate setting of care are paramount to delivering
high-quality care. The commenter explained that inappropriate and
lengthy delays in payer responses to requests for transfers to post-
acute care settings put patient care at risk. Specifically, the
commenter explained that in nine percent of cases, the delay is caused
by an untimely response from a payer. The commenter stated that while
that percentage may seem low, it accounted for over 20,500 patient
encounters across the commenter's system in 2022.
Response: We agree that timely response to such requests can impact
patient care, and thus we are finalizing policies to reduce prior
authorization decision timeframes. We also encourage payers to review
their procedures for this and other similar cases to determine where
process improvements would be

[[Page 8881]]

appropriate to prevent such delays within their own organizations and
provider relationships.
Comment: A commenter stated that ensuring appropriate review
timeframes to make decisions for patients is critical to avoiding
mistakes in care and that accelerated review timeframes increase the
risk of failed or non-optimal therapies. A commenter wanted CMS to
maintain the current 14-day decision timeframes for standard requests
in Medicaid managed care. Another commenter suggested that CMS remove
the proposal to shorten prior authorization turnaround timeframes until
the Prior Authorization API is implemented and the agency can re-
evaluate whether the policy is necessary and then re-issue a proposal.
Multiple commenters had concerns about shortening the prior
authorization timeframes. Several state commenters expressed concern
that they will neither have the staffing capacity nor the operational
efficiencies to implement the prior authorization timeframes by the
compliance date. Some commenters noted that state legislative approval
will be needed to increase state staffing or adjust vendor contracts,
requiring additional time to implement. Some commenters also noted that
states will need to evaluate and overhaul their entire prior
authorization processes to attain the operational efficiencies needed
to achieve the shortened decision timeframes.
Response: We thank the commenters for their concerns about accuracy
in making decisions about prior authorizations, but that utilization
management techniques and other professional safeguards are in place to
mitigate such concerns. As we stated in the CMS Interoperability and
Prior Authorization proposed rule, shorter prior authorization
timeframes will improve patient care, reduce burden, and improve equity
(87 FR 76297). The volume and substance of other comments support our
proposals to shorten certain existing timeframes, and thus we are
finalizing our proposal as described in this final rule. When the Prior
Authorization API is implemented in 2027, this resource should further
improve efficiencies in the process. We recognize the unique challenges
some state commenters shared concerning the practical ability to
implement the new prior authorization timeframes in state Medicaid and
CHIP FFS by January 1, 2026. We understand that states often require
longer timeframes to create new positions, adjust procurement
arrangements, and rework system processes. We are willing to work with
state Medicaid and CHIP FFS programs that may be unable to meet the new
compliance date for the prior authorization timeframes. States should
contact their Medicaid state lead or CHIP project officer before April
1, 2025, to discuss their extenuating circumstances. Any flexibility
granted to a state Medicaid or CHIP FFS program for the implementation
of the new prior authorization decision timeframe requirements will be
temporary and limited to the unique circumstances of the program.
Comment: A commenter stated that providers and health plans have
multiple exchanges of information back and forth, including additional
medical documentation and patient-specific information before a final
determination. The commenter noted that the currently proposed decision
timeframes do not account for these situations as most requests often
require additional information from providers. The commenter also
stated that these requirements, in combination with a lack of required
information about the data content, could unintentionally increase the
number of denials. Multiple commenters stated that shorter timeframes
would mean an increase in staff and administrative resources and that
without enough time there could be an increase in denials.
Response: We also acknowledge that additional staff resources may
be necessary. Firstly, the Prior Authorization API could mitigate
communication and staffing issues, once it is fully implemented, but
acknowledge that additional staff may be necessary during the
implementation process. Also, the focus on process improvement overall
may lead to improved efficiencies as payers address opportunities to
reduce inefficiencies and meet the requirements of the final rule.
Furthermore, the requirement to provide a specific reason for denials,
regardless of the method of the prior authorization, should also
support improvements in communication between health plans and
providers. By making the documentation requirements clearer through the
API, providers should submit more complete and appropriate
documentation in the first submission, thus enabling quicker processing
and fewer denials. Additionally, for Medicaid managed care plans at 42
CFR 438.210(d)(1) and for CHIP managed care entities through an
existing cross reference at 42 CFR 457.1230(d), we are finalizing (with
slight redesignations from current regulations) a provision that
permits standard authorization decisions to have an extension of up to
14 additional calendar days (to the 7-calendar day timeframe) if the
enrollee or the provider requests the extension or if the managed care
plan justifies a need for additional information and how the extension
is in the enrollee's interest. Medicaid managed care plans have been
able to utilize a 14-calendar day extension since 42 CFR 438.210(d)(1)
was first promulgated in 2001 (66 FR 43670). We believe this provides
sufficient time for managed care plans and providers to complete the
needed information exchange and enable the managed care plan to render
its decision. Similarly for CHIP FFS, we are finalizing our policy at
42 CFR 457.495 to allow for a possible extension of up to 14 days if
the enrollee requests the extension or if the physician or health plan
determines that additional information is needed to furnish a prior
authorization decision.
Comment: A commenter suggested that CMS convene a multi-stakeholder
panel of health professionals and payer representatives to determine an
appropriate timeframe for prior authorizations.
Response: We do not agree that a multi-stakeholder panel of health
professionals and payer representatives is necessary to determine an
appropriate timeframe for prior authorizations. CMS has conducted
surveys and listening sessions for nearly a decade, as have
professional associations. Results are consistent for challenges of
timeframes, with the consensus that this issue must be addressed. While
some states have additional requirements for decision timeframes, they
are not the same across the country. This final rule establishes
policies for most of the programs over which CMS has authority to
provide consistent and aligned structure for providers and payer
communications on this important matter. To continue the conversation
with another panel would further delay implementing these important
changes that provide the opportunity for improving access to care and
ensure that the industry collaborates on a solution to a critical
problem that has widespread consensus. CMS will evaluate these reduced
timeframes over time to see if future changes are needed, and may at
that time conduct additional stakeholder meetings, but at this time we
do not believe this is a necessary step to finalizing this policy,
which will reduce timeframes and improve prior authorization processes
across impacted payers.
Comment: Multiple commenters requested clarification regarding the
consequences and the available appeals process if payers do not meet
decision timeframes. For example, a commenter

[[Page 8882]]

stated that for cancer treatments, there should be no extensions unless
a peer-to-peer review is needed, and if so, it should only be for 48
hours from the original request. Another commenter stated that policies
should be implemented for payer oversight and dispute resolutions like
targeted audits and penalties for violations. Multiple commenters
highlighted that if decision timeframes are not met there should be a
presumption of coverage for standard and pre-service determinations for
providers and expedited appeal rights. A commenter noted that payers
should be required to provide more information for denials when they do
not meet decision timeframes and there should be civil monetary
penalties on entities that demonstrate a statistical pattern of
unnecessary documentation requests.
Response: We agree that data will be useful for oversight
activities. The impacted payers are subject to the oversight and
enforcement of the respective programs, in accordance with annual
reporting, certification, and/or auditing. We have addressed program
enforcement and compliance mechanisms in response to other similar
comments in section I.D.2. of this final rule. For Medicaid managed
care, 42 CFR 438.66(a) through (c) requires states to have a monitoring
system for all of their managed care programs that addresses all
aspects of the program and requires that data collected from these
monitoring activities are used to improve program performance. Further,
42 CFR 438.66(e) requires states to complete an annual report on the
performance of each of its managed care programs, submit that report to
CMS, and post it on the state's website. CMS reviews these reports and
can take enforcement action when needed. Along with the metrics
published under 42 CFR 438.210(f), we will have broad visibility into
the timeliness of Medicaid managed care plans' prior authorization
decisions. For QHP issuers on the FFEs, penalties associated with
failure to comply with deadlines or other provisions of 45 CFR 147.136
are generally within the purview of state regulators.\143\ The AMA
published a summary of some state initiatives regarding prior
authorization practices.\144\
---------------------------------------------------------------------------

\143\ Except to the extent that a state has deferred to CMS as
the primary enforcer of these provisions or a state has entered into
a Collaborative Enforcement Agreement (CEA) with CMS whereby the
state attempts to obtain voluntary compliance but if unsuccessful,
defers to CMS to handle enforcement.
\144\ American Medical Association (2023, May 10). Bills in 30
states show momentum to fix prior authorization. Retrieved from
https://www.ama-assn.org/practice-management/prior-authorization/bills-30-states-show-momentum-fix-prior-authorization.
---------------------------------------------------------------------------

For the reasons discussed in the CMS Interoperability and Prior
Authorization proposed rule at 87 FR 76297, we are not requiring that
impacted payers approve a request for prior authorization if that payer
did not meet the required standard or expedited decision timeframe. If
a payer fails to meet the timeline for approval or other decision,
providers should contact the payer to obtain the status of the request
and determine if supporting documentation is needed to complete the
processing of the authorization or if there are other reasons for the
delay in a decision. We do not believe it is practical to require
payers to default to approval for prior authorization requests for
which a timely response has not been provided. Therefore, impacted
payers may choose to evaluate process improvements to meet the proposed
timeframes and API in this final rule, and consider how to efficiently
support provider inquiries on status should responses or timeframes be
missed. Some programs, such as the MA program (and including applicable
integrated plans) and the Medicaid and CHIP managed care programs, have
regulations that include provisions for the failure to provide timely
notice of an organization determination; generally, such a failure to
meet the deadline constitutes an adverse decision on the prior
authorization request that may be appealed.\145\
---------------------------------------------------------------------------

\145\ See 42 CFR 422.568(f), 422.631(d)(1)(ii), 438.404(c)(5),
and 457.1260(b)(3).
---------------------------------------------------------------------------

d. Operational Topics
We solicited comments on what administrative, regulatory,
technical, governance, operational, and workflow solutions would need
to be addressed, for and by payers, to comply with the proposed
timeframes for handling prior authorization review and approval
activities. We also solicited comments on what operational or
procedural changes payers or providers would need to make in their
workflows or systems to reduce decision timeframes from 14 calendar
days to 7 calendar days (for standard prior authorization requests) and
from 72 hours to 1 day or 24 hours (for expedited prior authorization
requests). We indicated that we wished to learn more about barriers
that prevent payers from meeting shorter timeframes than those we
proposed and requested input on whether MA organizations and applicable
integrated plans, state Medicaid and CHIP FFS programs, Medicaid
managed care plans, and CHIP managed care entities could provide notice
of standard and expedited prior authorization decisions within shorter
timeframes (for example, 5 calendar days and 48 hours, respectively),
and if not, what issues and obstacles prevent that. We solicited
comments on whether implementation of the Prior Authorization API could
yield process improvements to support shorter decision timeframe
requirements for prior authorization requests and on anticipated
operational challenges of implementing the API that might affect a
payer's ability to meet the proposed timeframes. Finally, we requested
comments regarding the costs, benefits, and operational impact on
providers and payers, as well as the impact on patients, of making and
communicating prior authorization decisions on a shorter timeframe than
those in the proposed rule. We received a substantial number of
comments on these topics which will be useful as we consider future
policies and guidance on these issues.
These policies for the impacted payers are being finalized in this
final rule in the CFR sections listed in Table E4.
BILLING CODE 4150-28-P

[[Page 8883]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.005

BILLING CODE 4150-28-C

[[Page 8884]]

The timeframe for standard prior authorization requests and
expedited organization determinations for certain programs may be
extended for either 14 or 15 \146\ days for reasons specified and
permitted under existing or new policies. The specific citations are
provided here for reference.
---------------------------------------------------------------------------

\146\ QHP issuers on the FFEs follow 29 CFR 2560.503-
1(f)(2)(iii)(A) for certain extensions. See 29 CFR 2560.503-
1(f)(2)(iii)(A).
---------------------------------------------------------------------------

Medicaid FFS at 42 CFR 440.230(e)(1)(i). Timeframes for
prior authorization decisions under the Medicaid FFS program have been
newly established with this final rule. The timeframe for standard
authorization decisions can be extended by up to 14 calendar days if
the beneficiary or provider requests an extension or if the state
agency determines that additional information from the provider is
needed to make a decision.
MA expedited organization determinations at 42 CFR
422.572(b) and MA standard organization determinations at 42 CFR
422.568(b)(1)(i). Extensions are permitted for expedited and standard
integrated organization determinations by applicable integrated plans
(see 42 CFR 422.631(d)(2)(ii)).
Medicaid managed care plan expedited authorization
decisions at 42 CFR 438.210(d)(2)(ii) and Medicaid managed care plan
standard authorization decisions at 42 CFR 438.210(d)(1)(ii).
Extensions are permitted for expedited and standard prior authorization
requests by up to 14 calendar days under certain circumstances.
QHP issuers on the FFEs are permitted additional time on
expedited requests under certain circumstances when a claimant does not
provide sufficient information. See 29 CFR 2560.503-1(f)(2)(i). Limited
extensions of the timeframe for standard requests are also allowed
under certain circumstances. See 29 CFR 2560.503-1(f)(2)(iii)(A).
5. Requirements for Timing of Notifications Related to Prior
Authorization Decisions
This section outlines the regulatory amendments adopted in this
rule as applicable based on other laws for the timing of notifications
sent by certain payers to patients regarding prior authorization
decisions. These requirements also apply to most impacted payers.
However, we did not address notifications from the QHP issuers on the
FFEs for the same reasons we explained in section II.D.4. of this final
rule.
a. Medicare Advantage Organizations
MA organizations are currently required to provide notifications to
enrollees of decisions regarding coverage, called organization
determinations, which include decisions regarding prior authorizations.
To support more timely decisions and communication of those decisions,
we proposed to amend 42 CFR 422.568(b)(1) to require MA organizations
to notify the enrollee of its prior authorization determination as
expeditiously as the enrollee's health condition requires, but no later
than 7 calendar days after the organization receives the request for a
standard organization determination for a medical item or service
subject to the prior authorization rules at 42 CFR 422.122. We also
proposed to move the existing language at 42 CFR 422.568(b)(1)(i) and
(ii) (regarding extensions of the adjudication timeframe for standard
organization determinations) to 42 CFR 422.568(b)(2). We proposed to
move the language previously at 42 CFR 422.568(b)(2) to a new paragraph
(b)(3). We emphasized that this change to the regulation text structure
would not change current requirements and that the proposed new 7-
calendar day timeframe would remain subject to the existing standards
and limits (currently at 42 CFR 422.568(b)(1)(i), proposed to be at 42
CFR 422.568(b)(2)) related to when an MA organization may extend the
adjudication timeframe by up to 14 additional calendar days. For
additional explanation on the continued applicability of existing
standards, in this final rule, we are adding paragraph (a)(3) to 42 CFR
422.122 to explain that prior authorization decisions made under 42 CFR
422.122 must meet all other applicable requirements in subpart M of
part 422, such as the adjudication timeframes and notice requirements.
In this final rule we are also adding explanatory language to the
beginning of paragraph (b)(1)(i) of 42 CFR 422.568; specifically, we
are adding the phrase ``For a service or item not subject to the prior
authorization rules at Sec. 422.122'' to the beginning of the sentence
to be clear that those requests not subject to the prior authorization
rules at 42 CFR 422.122 will be adjudicated under the existing 14-
calendar day timeframe, such as a request for a supplemental benefit
that involves an OTC drug or a pre-service request made by an enrollee
who is seeking an advance determination on an item or service that is
not subject to prior authorization under the rules at 42 CFR 422.122.
In contrast, 42 CFR 422.568(b)(1)(ii) sets forth the 7-calendar day
timeframe for those requests for a service or item that are subject to
the prior authorization rules at 42 CFR 422.122.
We proposed similar amendments to the integrated organization
determination requirements at 42 CFR 422.631 for applicable integrated
plans. We are making in this final rule explanatory revisions to the
regulation text at 42 CFR 422.631 consistent with the revisions made at
42 CFR 422.568 and amended 42 CFR 422.631(d)(2)(i)(B) to state that
when a provider makes a request for an item or service, the applicable
integrated plan must notify the enrollee of its determination as
expeditiously as the enrollee's health condition requires, but no later
than 7 calendar days after the organization receives the request for a
standard pre-service organization determination that is subject to 42
CFR 422.122. We also proposed an amendment to 42 CFR
422.631(d)(2)(iv)(B) to state that when an applicable integrated plan
denies a request for an expedited determination and automatically
transfers the request to the standard timeframe, it must make its
determination within the applicable timeframe established at 42 CFR
422.631(d)(2)(i)(B). This means that for prior authorization requests
within the scope of 42 CFR 422.122, the 7-calendar day timeframe
applies, rather than the current 14-calendar day timeframe for an
integrated organization determination. These changes also apply to
applicable integrated plans that are MCOs as defined at 42 CFR 438.2,
because per 42 CFR 438.210(d)(4), 42 CFR 422.631 also applies to these
Medicaid plans. These amendments are consistent with changes for other
Medicaid managed care plans being finalized at 42 CFR 438.210(d)(1) and
(2). Concerning MA organizations (including applicable integrated
plans), our proposal was limited to the timeframes for standard
determinations involving prior authorization, and there are no changes
to the timeline for expedited integrated organization determinations,
extensions, or the requirements for notice to enrollees.
Comment: A commenter urged CMS to require that any failure by an MA
plan or applicable integrated plan to provide notice of an organization
determination within the same timeframes (and without having requested
an extension) constitute a deemed denial for which the provider may
request a reconsideration by an independent reviewer.
Response: We acknowledge this commenter's concern about the failure
of MA plans to provide notice within

[[Page 8885]]

the required timeframes. Under the existing MA rules, a failure to meet
the deadline by which an organization determination, including a
request for prior authorization, constitutes a denial that can be
appealed to the next level (reconsideration by the MA organization).
See 42 CFR 422.568(f) and 422.631(d)(1)(ii). The MA program regulations
(42 CFR 422.592 through 422.596 and 422.634) provide for review by an
Independent Review Entity (IRE) after an MA organization's adverse
reconsidered organization determination, including where the MA
organization fails to issue a reconsidered organization determination
in a timely fashion. We did not propose, and are therefore not
finalizing here, an amendment to those rules to escalate prior
authorization denials to the IRE. However, the existing regulations at
42 CFR 422.590(h)(1) and 422.629(k)(4) provide that for
reconsiderations by MA plans and applicable integrated plans, the
individuals who make the reconsideration determination must not have
been involved in the organization determination. We also reiterate that
providers should follow up on the status of a request with the payer.
Failure to respond to a request for the status of the pending prior
authorization request does not constitute a denial (unless the lack of
response continues beyond the deadline for response) but may indicate
other issues in the process such that an appeal may not be necessary.
We acknowledge that issues in communication between payers and
providers may continue to exist, and encourage providers to notify
payers or CMS of any patterns for poor communication and untimely
issuance of prior authorization decisions.
b. Medicaid Fee-for-Service, Including Beneficiary Notice and Fair
Hearings
For the Medicaid FFS program, we proposed, in the CFR sections
listed in Table E2, regulatory timeframes to provide notice of
decisions on both expedited and standard prior authorization requests.
We stated that the new requirements would apply to prior authorization
decisions beginning January 1, 2026. We are finalizing that policy in
this final rule.
Under the new requirement for Medicaid FFS, which appears at 42 CFR
440.230(e)(1), notice of the state Medicaid program's decision
regarding an expedited request for prior authorization will have to be
communicated as expeditiously as a beneficiary's health condition
requires, but no later than 72 hours after receiving a provider's
request for an expedited determination, unless a shorter minimum
timeframe is established under state law. Notice of a decision on a
standard request for prior authorization will have to be communicated
to the requesting provider as expeditiously as a beneficiary's health
condition requires, but no later than 7 calendar days after receiving
the request, unless a shorter minimum timeframe is established under
state law. If the state determines that it needs additional information
from a provider to make a decision, or if the beneficiary or provider
requests an extension, the proposed decision-making and communication
timeframe for a standard request may be extended by up to 14 calendar
days if the beneficiary or provider requests an extension, or if the
state agency determines that additional information from the provider
is needed to make a decision. Such extensions may be justified and in
the beneficiary's interest if medical evidence from outside providers
is needed to support the request, or if there are other circumstances
identified by either the provider or the beneficiary.
Independent of this final rule's API proposals and their
application to Medicaid prior authorization requests, Medicaid has
longstanding beneficiary notice and fair hearing regulations. CMS has
interpreted these existing regulations to apply to prior authorization
requests for Medicaid FFS and will continue to do so in the future.
These existing Medicaid beneficiary notice and fair hearing
requirements will remain in full effect without change, in concert with
other provisions of this final rule, including the Prior Authorization
API.
As discussed in detail in the proposed rule (87 FR 76299 and
76300), the current Medicaid notice and fair hearing regulations at 42
CFR 435.917 and 42 CFR part 431, subpart E, apply to all prior
authorization decisions. Therefore, states are required to--
Provide the beneficiary with timely and adequate written
notice of any decision regarding the beneficiary's prior authorization
request;
Include the content described at 42 CFR 435.917 and at 42
CFR part 431, subpart E, including information about the beneficiary's
right to request a fair hearing to appeal the partial or total denial,
in the beneficiary notice when a state denies the prior authorization
request in whole or in part;
Provide beneficiaries the opportunity to request a fair
hearing if the state fails to act on a claim, which includes prior
authorization requests, with reasonable promptness; and
Provide at least 10-day advance notice to beneficiaries of
any termination, suspension of, or reduction in benefits or services
for which there is a current approved prior authorization, including
information regarding the beneficiary's right to request a fair
hearing.
These notice and fair hearing requirements are not affected by any
of the changes made elsewhere in this final rule. As noted in the CMS
Interoperability and Prior Authorization proposed rule, the Medicaid
notice requirements are separate from and independent of, the new
timeline for provider notice that is finalized at 42 CFR 440.230(e)(1).
To make it explicit that existing Medicaid beneficiary notice and
fair hearing rights apply to Medicaid FFS prior authorization
decisions, we proposed several updates to the existing regulations at
42 CFR 431.201, 431.220, and 435.917, and a new 42 CFR 440.230(e)(2).
The proposed changes are intended to further explain, but not change,
Medicaid notice or fair hearing policy or operational requirements for
states. We proposed and are finalizing, with one exception discussed
below, that the changes referenced in this paragraph take effect on the
effective date of the final rule. Please see 87 FR 76300 for the
detailed text. The regulations and amendments are listed in Table E3.
The proposed changes for 42 CFR 431.201 included replacing the term
``beneficiary'' with ``enrollee'' in the revised definition of
``Action.'' This change was proposed in error, and the preamble to the
CMS Interoperability and Prior Authorization proposed rule did not
discuss the potential impact of changing ``beneficiary'' to
``enrollee'' on the definition of ``Action.'' In this final rule, we
are reverting to the term ``beneficiary'' in the definition of
``Action'' at 42 CFR 431.201, consistent with the current definition
and with our stated intent in the proposed rule that the changes would
not change Medicaid notice or fair hearing policy or operational
requirements for states.
We received comments on fair hearings and provide those and our
responses here.
Comment: Multiple commenters expressed support for our proposal to
further explain the application of Medicaid notice and fair hearing
requirements to Medicaid FFS prior authorization decisions and
recommended that the proposed changes be codified. A few commenters
noted that states already apply notice and fair hearing requirements to
Medicaid FFS prior authorizations.

[[Page 8886]]

Multiple commenters noted that Medicaid agencies already have provider
hearing rights for prior authorization decisions in place.
Response: We appreciate commenters' support for the proposed
updates to the Medicaid notice and fair hearing regulations, which we
are finalizing as proposed.
Comment: A few commenters noted that patients should receive
equitable fair hearing rights for their prior authorizations,
regardless of whether they are enrolled in a Medicaid FFS or a managed
care plan. A few commenters expressed support for the proposed changes
which would explain that Medicaid FFS notice and fair hearing
requirements are consistent with current regulations for notice and
appeal rights for managed care prior authorization decisions.
Response: We agree that comparable and aligned notice and fair
hearing rights should apply across delivery systems. As discussed in
the CMS Interoperability and Prior Authorization proposed rule, we have
historically interpreted the existing Medicaid notice and fair hearing
regulations to apply to prior authorization requests for Medicaid FFS.
Given the alignment between these state-level requirements and the
managed care plan-level requirements, equitable notice and appeal
rights have been and will continue to be available to Medicaid FFS and
managed care beneficiaries and that the updates, which we are
finalizing as proposed, will further strengthen the existing alignment
between delivery systems regarding notices and fair hearings/appeals.
Comment: A commenter stated that there needs to be more
clarification in the rule that existing Medicaid beneficiary notice and
fair hearing rights apply to prior authorization decisions for Medicaid
FFS beneficiaries. Another commenter recommended CMS mandate more
details on the hearing process to ensure that a hearing can be
conducted expeditiously and objectively. A commenter recommended that
the language in the regulation be strengthened to explicitly state that
failure to act on a request for prior authorization will give rise to
notice and hearing rights.
Response: The updates we are making to these regulations, which we
are finalizing as proposed, provide additional details regarding how
Medicaid beneficiary notice and fair hearing rights apply to prior
authorization decisions for Medicaid FFS beneficiaries. These changes
provide further detail about, but do not change, the current
application of these regulations to Medicaid FFS prior authorization
decisions. Therefore, the existing requirements for the fair hearing
process at 42 CFR part 431, subpart E, apply to Medicaid FFS prior
authorization fair hearings. These include a requirement that fair
hearings must be conducted by an impartial person who was not directly
involved in the initial decision (42 CFR 431.240(a)(3)) and
requirements for when the state must take final administrative action
on a fair hearing request (42 CFR 431.244(f)). These regulations also
require the state to provide notice to a beneficiary (42 CFR
431.206(c)(2)) whenever a hearing is required in accordance with 42 CFR
431.220(a), which includes when the state fails to act upon a claim,
including a prior authorization decision, with reasonable promptness.
Comment: A commenter recommended that CMS expand on proposed 42 CFR
440.230(e)(2) to require written notice of a prior authorization
decision be provided to the provider as well as the beneficiary.
Response: The Medicaid notice and fair hearing provisions at 42 CFR
435.917 and 42 CFR part 431, subpart E, which are cross referenced at
42 CFR 440.230(e)(2), apply to applicants and beneficiaries, not
providers. Therefore, we decline this recommendation and will finalize
42 CFR 440.230(e)(2) as proposed. There are separate requirements
regarding provider notification of prior authorization decisions. As
stated in this final rule, we are finalizing requirements for payers to
provide a specific reason for denials, as well as the status of a prior
authorization, either through the Prior Authorization API as specified,
or through existing processes. When providing a status for a prior
authorization, the response must indicate whether the payer approves
(and for how long) or denies (and the reason) the prior authorization
request, or the payer may request more information from the provider to
support the prior authorization request.
Comment: A commenter raised concerns about whether and how notice
and appeal rights can be provided electronically and noted that lower-
income consumers may have inconsistent access to electronic
communications. This commenter recommended that HHS continue to require
a redundant written notice for all important Medicaid notices,
including those related to prior authorization.
Response: The provision of electronic notices to Medicaid
applicants and beneficiaries is addressed at 42 CFR 435.918.
Individuals must be provided a choice to receive notices in electronic
format or by regular mail and have the option to request that all
electronic notices also be provided by regular mail. Changes to 42 CFR
435.918 are outside the scope of this rule. The Medicaid notice
requirements, which include the provision of fair hearing rights, will
continue to apply unchanged when API-based notifications begin.
Therefore, low-income beneficiaries enrolled in Medicaid will continue
to receive notices by mail, electronically, or both, even after the
API-based notifications begin.
Comment: A commenter expressed that CMS's proposal to make explicit
the requirement for a fair hearing to appeal prior authorization non-
compliance is inadequate to address prevalent and profitable wrongful
denials of prior authorization. This commenter stated that very few
patients can appeal wrongful denials and rarely do appeal and noted
that medical practices aren't compensated for prior authorizations or
appeals, which harms patients as well.
Response: Fair hearings are an important part of a beneficiary's
due process rights. While fair hearings cannot directly prevent
inappropriate denials of prior authorization requests, they do provide
a pathway for a beneficiary to remedy an inappropriate prior
authorization denial, termination, or reduction and provide data to
states to help them identify problems with the prior authorization
process. We believe that improvements in the process overall will occur
by using the API once that is in place, as providers will have
additional information on which to base the submission of an initial
prior authorization request.
c. Medicaid Managed Care
For Medicaid managed care, we proposed new timeframes for notice of
decisions on standard (non-expedited) prior authorization requests
which would apply beginning with the rating period that starts on or
after January 1, 2026, and proposed to revise 42 CFR 438.210(d)(1) and
(2) to accomplish this. Specifically, we proposed to revise 42 CFR
438.210(d)(1) to reflect that, beginning with the rating period that
starts on or after January 1, 2026, managed care plans must provide
notice of standard authorization decisions as expeditiously as the
enrollee's health condition requires and within state-established
timeframes that may not exceed 7 calendar days following the plan's
receipt of the request for service. Our proposed amendment provided
that for rating periods that begin before January 1, 2026, the current
rule would

[[Page 8887]]

remain in effect. We proposed to specify the standard authorization
requirements by the compliance dates by leaving the section header
``Standard authorization decisions'' as 42 CFR 438.210(d)(1) and
redesignating standard authorization timeframes as 42 CFR
438.210(d)(1)(i)(A) and (B). We also proposed to move the current
regulation text on extending the prior authorization decision timeframe
from 42 CFR 438.210(d)(1)(i) and (ii) to 42 CFR 438.210(d)(1)(ii)(A)
and (B) and proposed to make slight revisions to the text for
readability. We explained that our proposal would not change the
current provisions for how failure to issue a decision within the
required timeframe constitutes an adverse benefit determination that
can be appealed under 42 CFR 438.404(c)(5). The regulations at 42 CFR
438.404 and other regulations governing appeal rights at 42 CFR part
438, subpart F, would continue to apply and we did not propose to amend
those regulations. We note that 42 CFR 438.404(c)(3) through (6)
provide that certain adverse benefit determinations must be issued on
the timing specified at 42 CFR 422.210(d); the new timeframes proposed
(and finalized) in this rulemaking will apply to those specific adverse
benefit determinations. In addition, under current regulations at 42
CFR 438.3(s)(1) and (6) and 438.210(d)(3), Medicaid managed care plans
must also comply with the requirements in section 1927 of the Act
regarding coverage and prior authorization of covered outpatient drugs;
nothing in this rulemaking would change these requirements. Finally,
because some Medicaid MCOs are applicable integrated plans as defined
at 42 CFR 438.2, our proposal related to 42 CFR 422.631(d) applied to
those plans.
We received a few comments on this subject and provide our
responses to those here.
Comment: A commenter agreed with the proposal to provide notice of
decisions for standard prior authorization requests within state
established timeframes not exceeding 7 calendar days, and another
commenter disagreed with the proposal to shorten the maximum amount of
time for Medicaid managed care plans to respond with a decision from 14
to 7 days. Another commenter proposed that the standard should be 24
hours or less for standard requests. A commenter stated that Medicaid
and CHIP managed care programs already have requirements to issue prior
authorization decisions within a certain timeframe established by the
state and that those standards provide adequate protection for
enrollees and providers.
Response: As we stated in the proposed rule, and based on CMS and
other industry studies on the impact of delays to patient health or
access to care from extended authorizations, reducing standard prior
authorization decision timeframes from 14 calendar days to 7 calendar
days should improve patient care outcomes and ensure that patients have
more timely access to services (87 FR 76296).
d. CHIP Fee-for-Service and Managed Care
To implement the proposed prior authorization timeframes for CHIP,
we proposed to revise certain policies affecting the timing for making
decisions on prior authorization requests under the CHIP FFS and
managed care programs. These changes are listed in Table E2. We
proposed that beginning on January 1, 2026, decisions related to prior
authorization of health services would be required to be completed in
accordance with the medical needs of the patient, but no later than 7
calendar days after receiving the request for a standard determination
and 72 hours after receiving the request for an expedited
determination, unless an alternative option is preferred by industry
based on public comments. Further, we stated that if a beneficiary
requests an extension of a prior authorization review, or if the
provider or health plan determines that additional information is
needed for such review, an extension of up to 14 calendar days may be
granted. We proposed to remove the option for states to follow existing
state law regarding prior authorization of health services, requiring
states to instead follow these updated timeframes. However, if state
laws are more stringent than our proposal, states would be allowed to
apply and enforce those shorter timeframes for prior authorization
responses. Timely prior authorization decisions are important patient
protections, and CHIP patients should be afforded the same decision
timeframes as Medicaid and Medicare patients.
Existing CHIP regulations at 42 CFR 457.1130(b) require a state to
ensure that a beneficiary has an opportunity for external review of
health services matters, including a delay, denial, reduction,
suspension, or termination of health services, in whole or in part,
including a determination about the type or level of service. Under
this regulation, CHIP beneficiaries must have an opportunity for
external review of prior authorization decisions. We did not propose
any changes to this requirement, as it already applies to decisions
related to the prior authorization of services.
In the CMS Interoperability and Prior Authorization proposed rule
we explained that overall, we believed that the decision and
notification timeframes proposed for certain impacted payers would help
ensure that prior authorization processes do not inappropriately delay
patient access to necessary services. Introducing prior authorization
decision timeframes that are the same across these impacted payers for
items and services that require prior authorization would also help
providers better organize and manage administrative resources and thus
may make more time available for providers to render patient-centered
care.
Currently, CHIP managed care program regulations reference the
Medicaid managed care regulations for the timelines and requirements
for CHIP managed care entities as to prior authorization decisions and
notices as well as appeal processes. We explained in the proposed rule
that the proposal to amend 42 CFR 438.210(d) for timeframes would also
apply to standard and expedited decisions made by CHIP managed care
entities because of the cross reference to 42 CFR 438.210 in current 42
CFR 457.1230(d). We did not propose to change the required timeframes
for expedited decisions at 42 CFR 438.210(d)(2), but we proposed to
amend 42 CFR 438.210(d)(2)(i) to explain that the MCO, PIHP, or PAHP
must make these decisions on shorter timeframes if the state requires
shorter timeframes. We did not propose any changes to the authority for
a 14-calendar day decision timeframe provided at 42 CFR
438.210(d)(2)(ii).
We received the following comments related to CHIP FFS and managed
care and include our responses to those comments here.
Comment: A commenter disagreed with CMS's proposal to shorten the
maximum amount of time for CHIP FFS and managed care to respond with a
decision from 14 to 7 days. The commenter proposed that the standard
should be 24 hours or less. Another commenter recommended CMS provide
equal protection for children enrolled in CHIP FFS against unnecessary
delays in accessing necessary services due to prior authorization
procedures. The commenter also recommended that state CHIP agencies
follow the same rules as state Medicaid agencies, including specific
timelines for prior authorization responses for outpatient prescription
drugs. Another commenter expressed their support for aligning the
beneficiary protections in CHIP and Medicaid

[[Page 8888]]

managed care and recommended CMS maintain 42 CFR 457.1230(d) as
proposed, applying 42 CFR 438.210 to CHIP managed care entities with
the proposed shorter timelines for responses to standard requests for
prior authorization, characterizing these as stronger beneficiary
protections.
Response: Though we anticipate the Prior Authorization API will
introduce additional efficiencies into the prior authorization process,
we are uncertain that such a truncated standard decision timeframe
would be possible until we have completed further data collection and
analysis after the implementation of the API. The recommendation
concerning CHIP prior authorization decision timeframes for outpatient
prescription drugs is outside the scope of the final rule. We agree
with comments that recommend CHIP prior authorization decision
timeframes be in alignment with Medicaid.
We are finalizing the proposals to adopt the timeframes we proposed
for responses by MA organizations, state Medicaid and CHIP FFS
programs, Medicaid managed care plans, and CHIP managed care entities
to prior authorization requests. We are not requiring that impacted
payers approve a request for prior authorization if that payer fails to
meet the required standard or expedited decision timeframe. If a payer
fails to meet the timeline for approval or other decision, providers
should contact the payer to obtain the status of the request and
determine if supporting documentation is needed to complete the
processing of the authorization or if there are other reasons for the
delay in a decision. The 72-hour requirement for expedited requests is
measured in hours, whereas the 7-day requirement for standard requests
is measured in calendar days. In the case of expedited and standard
requests, the timeframes are 72 hours and 7 days, respectively, unless
a shorter minimum timeframe is established under state law.
Tables E2 and E3 provide a list of some, but not all of the final
policies for decision notification timelines for the impacted payers.
The full list of final policies and citations is included in Table E4
at the end of this section. We included these tables for ease of
reference for the narrative on the discussion of notifications and
timeframes.
Table E3 is specific to the Medicaid FFS notice and fair hearings
provisions, which provide an important service to beneficiaries and
providers alike. This rule finalizes modifications to those provisions,
and this table and accompanying narrative provide the reader with
citations to new and existing provisions.
[GRAPHIC] [TIFF OMITTED] TR08FE24.006

[[Page 8889]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.007

6. Extensions, Exemptions, and Exceptions
See section II.E. of this final rule for a discussion of extensions
and exemptions and the final policies for the Prior Authorization API
for state Medicaid and CHIP FFS programs and exceptions for the Prior
Authorization API for QHP issuers on the FFEs (this was also addressed
in the proposed rule at 87 FR 76279).
7. Public Reporting Requirements for Prior Authorization Metrics
In the CMS Interoperability and Prior Authorization proposed rule
we discussed the importance of accountability for payer prior
authorization practices and proposed that certain data be made publicly
available for patients and providers to better understand the types of
items and services which required prior authorization and how each
payer performed over time for approvals and denials. We are finalizing
our proposal to require impacted payers to report certain aggregated
metrics about prior authorization by posting them on the payer's
website. This requirement underscores the importance of transparency
and accountability in the health care system. Public disclosure of the
items and services which are subject to prior authorization, as well as
organizational performance, offers useful information to providers,
patients, and other interested parties. Performance data could allow
for objective evaluation of the efficiency of prior authorization
practices of each organization, and it enables payers to assess trends,
identify areas for improvement, and work towards continuous process
improvement while maintaining necessary quality checks for quality and
appropriateness of care.
We are finalizing as proposed that state Medicaid and CHIP FFS
programs will report at the state level, Medicaid managed care plans
and CHIP managed care entities will report at the plan level, and QHP
issuers on the FFEs will report at the issuer level. We are finalizing
a modification to our proposal for reporting to be at the organization
level to require that reporting be at the contract level for MA
organizations as discussed in this section (section II.D.7. of this
final rule). Additionally, we explain that integrated plans will report
items and services covered by MA organizations at the MA contract level
and items and services covered by Medicaid managed care plans at the
plan level as the separate requirements for MA organizations and
Medicaid managed care plans will apply under the respective contracts.
We described how payers might use the information for process
improvements and performance analysis in the proposed rule (87 FR
76304). For example, an impacted payer could use these data to examine
its performance trends. In addition, we explained how providing this
information publicly would benefit patients (who could use the
information when selecting among plan or organization options) and
providers (in when and whether to contract with an impacted payer). The
legal authority for requiring such public reporting is discussed in
section II.D.10. of this final rule.
We are finalizing our proposal that for each metric listed, data
would be reported in aggregate for all items and services. We received
many comments on the proposed public reporting of metrics, the timing,
and the level of reporting. The suggestions were detailed and
represented diverse issues and concerns from interested parties about
prior authorization challenges and potential uses for the data. CMS
will use the comments received as CMS considers future policy
development. We intend to support transparency and accountability and
enable patients to access data that are meaningful and easy to use for
decision-making and understanding the prior authorization processes.
The metrics we are finalizing represent the most significant issues for
both patients and providers identified over the past decade on a
national level, including the CMS listening sessions referenced at the
beginning of this section. Furthermore, payers can supplement the
information they report with additional metrics on prior authorization.
We may consider additional reporting options in the future. We
reiterate that the prior authorization reporting metrics are on medical
items and services, excluding drugs covered by the impacted payers.
We are finalizing the requirement for impacted payers to make
reports available annually on all of the following:
A list of all items and services that require prior
authorization.
The percentage of standard prior authorization requests
that were approved, aggregated for all items and services.
The percentage of standard prior authorization requests
that were denied, aggregated for all items and services.
The percentage of standard prior authorization requests
that were approved after appeal, aggregated for all items and services.
The percentage of prior authorization requests for which
the timeframe for review was extended, and the request was approved,
aggregated for all items and services.
The percentage of expedited prior authorization requests
that were approved, aggregated for all items and services.
The percentage of expedited prior authorization requests
that were denied, aggregated for all items and services.
The average and median time that elapsed between the
submission of a

[[Page 8890]]

request and a determination by the payer, plan, or issuer, for standard
prior authorizations, aggregated for all items and services.
The average and median time that elapsed between the
submission of a request and a decision by the payer, plan, or issuer,
for expedited prior authorizations, aggregated for all items and
services.
a. Reporting Prior Authorization Metrics
As described previously, we proposed to require impacted payers to
report certain metrics to support a level of accountability for the
requirements in this final rule. As discussed previously, public
disclosure of information for each audience--patients, providers, and
the general public--supports the intent of this final rule to improve
the prior authorization process, patient care, and burden reduction.
Comment: Many commenters supported CMS's efforts to promote
transparency through public reporting of these aggregated metrics.
These commenters believe such reporting will increase transparency from
payers related to the volume of prior authorizations. For example, a
commenter wrote to encourage CMS to propose in future rulemaking to use
the prior authorization data the agency would collect from impacted
payers to help develop quality measures to incorporate into quality
ratings across certain payer programs, specifically for MA
organizations. This would ensure that such data are incorporated more
directly into a consumer-friendly comparison tool so that payers' prior
authorization practices are available to physicians and practitioners,
including gastroenterologists, to ensure transparency and
accountability in the prior authorization process. Multiple commenters
stated that reporting metrics could be informative to providers in the
context of what they submit to payers for prior authorization requests,
as the data might provide insights about the types of services that are
approved or denied. A commenter noted that prior authorization metrics
could be useful to patients as they decide which health plans to
select, and another commenter appreciated that CMS's proposal aimed to
strike a balance between data reporting burden and providing meaningful
data to consumers and providers. Another commenter supported reporting
prior authorization metrics on the payer's website by March 31, 2026.
Some commenters believed that CMS should require public reporting of
the metrics sooner than proposed, and multiple commenters recommended
that CMS require the public reporting requirement immediately upon
finalizing the rule.
Response: We thank commenters for their support of our proposed
prior authorization reporting metrics, including those commenters who
recommended that CMS consider additional future uses for the data for
other program purposes and require compliance as soon as the rule is
finalized. We agree that payers have the data available now, as they
are currently conducting the prior authorization process, and that the
data would provide a baseline for reporting. As proposed and finalized,
CMS is not collecting these data, but instead requiring impacted payers
to post such data on the payer's website. We encourage payers to
consider developing and posting reports of these metrics at the
earliest date feasible. We are finalizing the requirements for public
reporting as well as the compliance dates in 2026, as proposed.
Comment: Multiple commenters recommended that CMS require payers to
report prior authorization data at a more granular level. Specifically,
multiple commenters recommended that CMS require MA organizations to
report prior authorization metrics at the plan level or state level.
Commenters stated that the organization level for MA organizations was
a higher level of aggregation than the plan level for Medicaid managed
care plans and CHIP managed care entities and therefore would not
present the same level of detail. Those commenters pointed out that MA
organization metrics reported at the organization level would not be
useful to consumers choosing plans in their area. Other commenters
suggested more discrete reporting levels, including county level,
specialty/benefit level, or service level.
Response: Upon further consideration and taking the comments into
account, we determined that contract level is the more appropriate
reporting level for MA organizations. MA organizations generally have
multiple plans under the same contract as it is common throughout the
industry to offer a variety of plans within a service area. Contract-
level data are aggregated data that are collected from the plan benefit
packages (PBPs) (that is, the various MA plans) offered under an
individual contract; these data are specific to the contract to which
they correspond. CMS already requires MA organizations to report some
contract-level data about their organization determinations to the
agency on an annual basis and Star Ratings are assigned at the contract
level. While this particular provision does not require MA
organizations to submit data to CMS, a consistent approach of contract-
level reporting in the MA program will give consumers useful
information while limiting plan burden. By requiring contract-level
reporting for these data, we ensure that the format of this reported
data remains consistent with that of other similar data that MA
organizations are required to report.
We agree that requiring Medicaid managed care plans and CHIP
managed care entities to report at the plan level will allow
beneficiaries and states to compare plans within the state. Requiring
QHP issuers on the FFEs to report at the issuer level, aggregating
plans under their purview, is consistent with their reporting on
quality improvement strategies as described in section 1311(g) of the
Affordable Care Act (45 CFR 156.1130), which provides consistency with
other QHP reporting requirements.
While we understand the desire from some commenters to increase the
level of granularity for reporting, we have concerns about data
overload, patient understanding, and usability of the data. For
example, reporting at the specialty level and service level could be
overwhelming because of the volume of information presented. A patient
might not be able to relate to the data and would not refer to the
reports as intended. There can and should be both transparency and
accountability in the information that is presented to the public and
we will continue to explore opportunities to strike the appropriate
balance with impacted payers. We are finalizing a modification to our
proposal for MA organizations to report at the contract level. We are
finalizing, as proposed, that state Medicaid and CHIP FFS programs will
report at the state level, Medicaid managed care plans and CHIP managed
care entities will report at the plan level, and QHP issuers on the
FFEs will report at the issuer level.
We may assess whether to collect more detailed metrics than we are
finalizing here in program-specific rulemaking in the future. For
instance, we may consider requiring in future rulemaking that MA plans
report at a more discrete level. Similarly, should a state Medicaid or
CHIP agency believe it would be beneficial to require more detailed
data, the state may require additional metrics in its managed care
contracts.
Comment: A commenter requested clarification on whether integrated
care plans for dually eligible individuals, such as FIDE SNPs, should
report these data consistent with MA organizations, at the contract
level, or consistent with

[[Page 8891]]

Medicaid managed care plans, at the plan level.
Response: Integrated care plans generally combine D-SNPs, which
include FIDE SNPs and HIDE SNPs--both as defined at 42 CFR 422.2--and
Medicaid managed care plans offered by the same parent organization. D-
SNPs are a type of MA plan designed to meet the needs of individuals
who are dually eligible for Medicare and Medicaid, also known as dually
eligible individuals. In these arrangements, there is an MA
organization with a contract with CMS for the MA D-SNP and an
organization with a contact with the state for the Medicaid managed
care plan.
For items and services that require prior authorization under an
integrated plan's MA benefit package, data must be reported in a manner
consistent with the requirements for MA organizations, which we are
finalizing at the contract level. In the case of integrated care, the
affiliated Medicaid managed care plan will report prior authorizations
of items and services covered under the plan's Medicaid benefit package
at the plan level. Where there is not a clear delineation between
whether items or services are covered under Medicare or Medicaid (for
example, home health services), we will accept any reasonable
methodology for attributing the prior authorization reporting to one
payer versus the other.
Comment: Multiple commenters recommended a more phased-in approach
to the reporting of prior authorization metrics. A commenter stated
that while prior authorization metrics should not be publicly reported
until after the electronic FHIR APIs have been implemented, the prior
authorization metrics should still be reported to CMS beginning March
2026. A commenter recommended that CMS begin to phase in reporting
requirements before the 2026 implementation period (for example,
require payers to report some, but not all, metrics soon after the rule
is finalized) to help identify any issues with the reporting process so
that they can be addressed timely.
Response: We disagree that a phased-in approach to reporting
metrics is necessary given that payers already conduct prior
authorization processes and likely already track data for many of the
metrics for their usual business operations. We are finalizing
compliance dates in 2026, as stated previously. We agree that reporting
prior authorization metrics conducted using the Prior Authorization API
will not be reported until after the Prior Authorization API has been
implemented, and that the technology could be capable of supporting
automated reporting on its use. The metrics to be included in the
reports beginning in March 2026 will be based on an impacted payer's
current prior authorization processes, in advance of implementation of
the Prior Authorization API. Reporting information about performance
data in advance of implementation could provide valuable data in the
years post-implementation.
Comment: Multiple commenters expressed concerns about how the prior
authorization metrics could be used by payers in inappropriate or
harmful ways to providers. A commenter flagged that the publicly
reported metrics could lead to plans ``self-selecting'' patients by
implementing other burdensome prior authorization processes to avoid
approving services, which could lead to patients who need those
services enrolling in other plans. Another commenter recommended that
CMS address steps it will take to protect against adverse selection.
This commenter urged CMS to consider how it will mitigate unintended
consequences that may occur as competing payers decide to analyze each
other's data once it becomes public. The commenter wrote that CMS
should make clear that any such practices would be against the spirit
and intent of the reporting requirements.
Response: We acknowledge concerns by a few commenters that prior
authorization policies and information on the publicly reported metrics
could technically be used inappropriately for improper decision-making
purposes or other reasons. Public reporting does not in and of itself
create such behavior. However, we believe requiring that public
availability of prior authorization metrics will have the opposite
effect; that is, payers will use the data to try to improve their
performance to improve their competitive standing in a program.
In addition, there are some safeguards in place to help address the
concerns raised by commenters about inappropriate efforts to discourage
enrollment by individuals who need certain covered services. Medicaid
managed care regulations also provide significant patient protections
for access to covered services at 42 CFR 438.206 through 438.210. For
example, 42 CFR 438.210(a) requires states' contracts with Medicaid
managed care plans to identify, define, and specify the amount,
duration, and scope of each service covered by the plan and such
amount, duration, and scope must be no less than that furnished to
Medicaid FFS beneficiaries. Existing regulations at 42 CFR 438.66
require states to have a monitoring system that addresses all aspects
of each Medicaid managed care program and to use the data collected
from their monitoring activities to improve the performance of their
managed care program, including at a minimum enrollment and
disenrollment trends in each managed care plan. Additionally, 42 CFR
438.66(e) requires states to submit to CMS a report on each of their
Medicaid managed care programs that provides information on and an
assessment of the operation of the managed care program.
Further, section 1852(b)(1) of the Act prohibits discrimination by
MA organizations on the basis of health status-related factors and
directs that CMS may not approve an MA plan if CMS determines that the
design of the plan and its benefits are likely to substantially
discourage enrollment by certain MA eligible individuals. In addition,
MA organizations must comply with applicable Federal civil rights laws
that prohibit discrimination on the basis of race, color, national
origin, sex, age, or disability, including section 1557 of the
Affordable Care Act, Title VI of the Civil Rights Act of 1964, section
504 of the Rehabilitation Act of 1973, and the Age Discrimination Act
of 1975. The regulation at 42 CFR 422.110 provides that an MA
organization may not deny, limit, or condition the coverage or
furnishing of benefits to individuals eligible to enroll in an MA plan
offered by the organization on the basis of any factor that is related
to health status. MA organizations discouraging or preventing
enrollment in an MA plan by beneficiaries by implementing burdensome
prior authorization processes to avoid approving services would be
prohibited by 42 CFR 422.110. CMS relies on the MA anti-discrimination
provision; the agency's authority under section 1856(b) of the Act to
adopt standards for MA organizations; and the agency's authority under
section 1857(e) of the Act to add terms and conditions that are
necessary, appropriate, and not inconsistent with the Medicare statute.
CMS does not collect detailed information on prior authorization
policies as part of the bid. However, CMS will continue to monitor for
potential discrimination by plans through prior authorization and other
utilization management programs in our review of complaints received
from beneficiaries and providers and will take action, as necessary.
CMS may also consider future sub-regulatory guidance based on a review
of complaints.
We also believe that MA and other managed care plans will use the
published data to drive performance

[[Page 8892]]

improvement to facilitate provider network development and that
providers will use the prior authorization metrics to evaluate managed
care plans and make decisions on whether to join or remain part of a
plan's network.
Comment: A commenter recommended that if CMS intends to require
public reporting in the final rule, CMS should explain how the data
would benefit interested parties and conduct education and outreach to
prevent confusion or misinterpretation of data. Multiple commenters
stated their hesitation to require public reporting of prior
authorization data without understanding the purpose of the reporting,
and another recommended that CMS reevaluate the need and value of
payers reporting the prior authorization metrics versus its costs and
resource burden. Multiple commenters highlighted the significant new
administrative burden that reporting prior authorization metrics would
cause. Other commenters recommended that CMS remove the proposed
requirement for payers to publicly report prior authorization metrics.
Response: We are aware that payers have many reporting requirements
for state and Federal programs and that preparing these public
disclosures may require additional effort. Payers also provide
educational resources to patients and providers for enrollment,
directories, and other health care reminders--all to explain benefits
and services and improve the health care experience. We are finalizing
policies in this final rule to address longstanding, important process
challenges related to prior authorization. Reporting on these metrics,
including, for example, the services that require prior authorizations,
the number of denials, those approved, and those overturned after
appeal, will give the patients and providers a better understanding of
payer performance in those categories--and over time--of the changes in
performance in those categories. These data will demonstrate the
intended impact of these policies. Public reporting is one of the most
universal, effective means to demonstrate improvement or change. This
public reporting has value because it can provide a benchmark for
patients or providers to understand, at a high level, the volume of
services a payer approves or denies, the types of services it
authorizes, or changes in those decisions over time. Not all patients
will use or necessarily understand all of the data, but it may help
support the beginning of a conversation between either the patient and
the payer, or the patient and the provider. We anticipate payers will
identify the most appropriate locations on their website for the
information to be public. We additionally note that the Medicare FFS
program currently publicly reports prior authorization metrics on its
website and invites payers to reference the presentation of those
metrics as they develop their public reporting strategy.\147\
---------------------------------------------------------------------------

\147\ Centers for Medicare and Medicaid Services (2023,
September 15). Prior Authorization and Pre-Claim Review Initiatives.
Retrieved from https://www.cms.gov/data-research/monitoring-programs/medicare-fee-service-compliance-programs/prior-authorization-and-pre-claim-review-initiatives.
---------------------------------------------------------------------------

Comment: A commenter recommended that a voluntary consensus SDO
should develop standardized codes that could be used to document prior
authorization denial reasons. Then, CMS could revise the metrics to
include information on the reason for denial to provide a more complete
picture of a plan's prior authorization process.
Response: As discussed previously in the section on providing a
reason for denial, the standard codes for denial reasons are an
external code set maintained by X12, which is a voluntary SDO. Any
organization or individual interested in providing updates to this code
set may do so by submitting a request to X12. At this time, we are not
requiring payers to publicly report the reason for denial in these
reporting metrics; that information is only provided to the requesting
provider and the patient.
Comment: Another commenter recommended that state Medicaid agency
reporting requirements be changed to begin 1 year following the
implementation of the APIs (by March 31 of each year). Another
commenter stated that the proposed metrics do not align with the data
elements required to be reported for appeal for the Managed Care Annual
Care Program Report (MCPAR) that states are required to report. The
commenter stated that alignment is necessary to assess the impact of an
MCO, PHIP, or PAHP's prior authorization determinations on beneficiary
access to requested services.
Response: We disagree that any payer should begin their reporting
period substantially after any other payer, as all payers already have
data to support their prior authorization activities. Even if a state
Medicaid agency were granted an exception or extension, their prior
authorization processes are already in effect and they have data
regarding their current prior authorization activities. The final
action statement in this section of the final rule includes the
compliance dates and reporting requirements for impacted payers, which
remains March 31, 2026, for reporting data for the prior year.
Concerning the MCPAR, alignment is neither necessary nor feasible. The
MCPAR collects information specifically on appeals, and we are
requiring information specifically on prior authorization. While it is
true that a denied prior authorization could generate an appeal, that
is not relevant to these two reporting vehicles. We may revise the data
collected in the MCPAR in the future and will use the existing data
from the MCPAR and this reporting to inform any such revisions.
Comment: Multiple commenters recommended that CMS develop standard
guidance or IGs for payers to have a set format and consistent
calculation of the metrics. A commenter flagged that the lack of
guidance on report formatting could lead to a wide variation across
impacted payers. Another commenter stated that CMS should issue the
guidance and allow adequate time for impacted payers and vendors to
make the appropriate modification to their system before public
reporting begins. A commenter sought clarification as to whether the
public reporting of prior authorization metrics would only apply to
prior authorization requests that are received on or after the
compliance dates. Another commenter recommended that rule language
specify the data required, ensure the data are placed prominently on
the payers' websites, and indicate the cadence at which payers must
refresh the publicly reported data. Many other commenters suggested
various dissemination mechanisms for the prior authorization metrics. A
commenter stated that they support an active distribution method for
the prior authorization metrics, like a newsletter. Another commenter
recommended that prior authorization metrics be available to be
downloaded in Excel and PDF.
Response: The Medicare FFS program currently publicly reports prior
authorization metrics on its website and invites payers to reference
the presentation of those metrics as they develop their public
reporting strategy. We will consider what additional support we can
provide to impacted payers before the compliance date of the final rule
regarding recommended content and format for use in their public
reports. The requirement for data in the first report for prior
authorization metrics to include information about prior authorization
activity for the prior year will provide a baseline for impacted payers
as well as the public.

[[Page 8893]]

The reporting requirement applies to prior authorization requests that
were received the year before the compliance date.
Comment: Multiple commenters recommended that CMS report the
required prior authorization information on the CMS website. A
commenter stated that this will enable easy retrieval of data by
physicians and patients, especially for plan comparison. Another
commenter stated that CMS should also make sure it publishes this
information on pages of its website that correlate to a particular
payer. A commenter stated that CMS should report on the impact prior
authorization has on the quality of care patients receive, potential
delays in care, and associated cost savings due to the prior
authorization process. The commenter suggested that reporting these
data can help policymakers, researchers, providers, and patients make
more informed decisions about the prior authorization process, ensuring
that patient care remains central. Multiple commenters recommended that
instead of payers publicly reporting metrics, there should be
confidential reporting to CMS so it can track outliers and avoid
misleading patients on data that are not comparable across plans.
Another commenter recommended that CMS consider confidential payer
reporting to CMS until the Prior Authorization API experiences
significant uptake by providers.
Response: We considered requiring that payers submit their reports
to a central website for publication. However, as we explained in the
CMS Interoperability and Prior Authorization proposed rule (87 FR
76347), we did not select this alternative because we believe patients
likely would view their health plan and payer as the resource for
information about their plan. While CMS does provide comparative data
for plans in certain programs (for example, the MA program) and may use
such information in future public reports, we are not finalizing such
an approach in this rule. Patients should be able to find information
about their plan or payer from those websites to minimize burden and
confusion. For Medicaid and CHIP, patients generally associate their
coverage with their state or managed care plan, not CMS. While having
the prior authorization data posted on each payer's website is the most
appropriate place, we also encourage state Medicaid agencies to include
the data on their websites (which are required by 42 CFR 438.10(c)(3))
to improve the value of information available to their patients.
Similarly, MA patients look to their MA organization websites for
information and resources about those plans and their performance.
Payers must already include significant patient resource information on
their websites, and CMS will conduct outreach to payers, patients, and
providers to help provide guidance on best practices about the website
locations for such public reporting of prior authorization information.
In our oversight role, we may begin to look at data after the
compliance date to evaluate compliance with these new reporting
requirements. CMS may consider additional reporting requirements as
well as publication of comparative information in the future.
Comment: Multiple commenters stated it would be helpful for
additional context to explain metrics in the event of an outlier, such
as explaining denial or approval rates for services-related data.
Multiple commenters suggested including the total number of requests
approved/denied, rather than only aggregate percentages. A commenter
stated that they also would like to see specific data for common
services to show a direct comparison across different payers and plans
as certain prior authorization requests are more complex than others.
Multiple commenters stated that service-specific reporting will aid
in identifying services for which there is a high rate of approval and
for which prior authorization requirements may no longer be necessary,
or for identifying critical services or items being routinely denied. A
commenter recommended CMS require payers to provide more detailed
information by item or service including Healthcare Common Procedure
Coding System (HCPCS) code, Current Procedural Terminology (CPT) code,
and International Classification of Diseases, Tenth Revision (ICD-10)
code. Other suggestions included requiring payers to report
disaggregated data by diagnosis, race and ethnicity, gender, and age. A
commenter warned that without item- and service-level reporting, it
will be impossible for CMS and the public to understand some data and
to hold impacted payers accountable for excessive denials and delays in
responding to prior authorization requests. Other commenters
recommended CMS require payers to report data with setting-specific
data or by type of provider (for example, physician, short-term care,
long-term care, rehabilitation, psychiatric, and skilled nursing
services). A commenter stated that only with this setting level of
specificity will patients and providers be able to assess which
services are routinely denied, appealed, and overturned in favor of
patients and providers. Another commenter warned that segmentation by
the provider should encompass short-term acute care, long-term care,
rehabilitation, psychiatric, and skilled nursing services to allow
consumers, providers, and regulators to gain a better understanding of
prior authorization processes and where there is a need for
improvement. A commenter recommended that CMS should require metrics be
broken down at the Health Care Provider Taxonomy code set Level II,
Classification, which is a code set used in HIPAA standard
transactions. Another commenter recommended that the metrics be
reported by the payer based on service type, site of care, and whether
the service is inpatient or outpatient. Another commenter wanted CMS to
compare the metrics for MA organization plans to Medicare FFS and
commercial health plans.
Response: Service-specific and demographic reporting may be very
useful to the impacted payers in evaluating their programs and expect
that they use such data today and will continue to do so as they
implement the policies of this final rule. While we agree that there
could be many more reporting requirements, and at more granular levels,
and data are an important tool for different evaluation purposes,
reporting should serve its intended purposes and not become a burden to
the users. Too much data can also become overwhelming. We anticipate
patient and provider feedback following implementation and will review
opportunities after that time.
We agree that it would be appropriate to compare the metrics for
all payers several years after the policies of this final rule have
been implemented to determine its impact on the prior authorization
barriers and burdens. However, commercial plans other than QHPs on the
FFEs are not subject to the provisions of this rule, and CMS does not
have access to performance data for those organizations. If states are
collecting such data, they might be able to analyze the data at the
state level.
b. Publication of Prior Authorization Metrics
We requested comments on how the information might be displayed on
payer websites in a useful and meaningful manner for patients and
providers, including which data would be most useful. The summarized
comments and our responses follow.
Comment: Multiple commenters recommended that the prior
authorization metrics be presented in a readable and accessible format,
particularly for individuals with

[[Page 8894]]

disabilities, individuals with limited or low health and data literacy,
and individuals with limited English proficiency. Other commenters
recommended that CMS require plans to write publicly reported data at a
sixth grade reading level, conduct consumer-focused testing on data
readability, and provide translations in multiple languages. Multiple
commenters recommended that CMS should require payers to provide access
to prior authorization data in multiple languages (based on the most
common languages in a community) and in a format that is comprehensible
to the average consumer. A commenter recommended CMS should make the
reported payer data patient-friendly and public to enable comparison of
metrics.
Response: We appreciate commenter suggestions that payer data be
``patient-friendly,'' easy to understand, and in an accessible format.
We may consider how best to provide guidance to encourage impacted
payers to develop their reports with these factors in mind, as the
intent of these public reports is to ensure that individuals can use
and interpret the information.
c. Types of Prior Authorization Metrics
Impacted payers are required to post a general set of prior
authorization metrics on their public websites to support process
improvement, as well as patient and provider insight into trends for
different payers. While the data will not be submitted to CMS at this
time, it will be available for public review and evaluation and may be
informative as experience with the new policies evolves.
Comment: Some commenters wrote that CMS should include more data on
use of the Prior Authorization API. A commenter suggested certain
metrics be considered for adoption: the number of requests initiated
using the Prior Authorization API, average response time for requests
not requiring a prior authorization, the number of requests initiated
using the Prior Authorization API requiring a prior authorization, the
number of requests initiated using the Prior Authorization API
requiring a prior authorization that had all of the required
documentation available automatically, the percentage of Prior
Authorization API requests requiring a prior authorization with all
required documentation available processed automatically, the number of
requests initiated using the Prior Authorization API requiring a prior
authorization that were unable to automatically supply required
documentation, and a list of all SMART on FHIR app/EHR combinations or
equivalent technology used for Prior Authorization API requests at
provider organizations. A commenter encouraged CMS to consider breaking
reporting out by prior authorization transactions supported by a FHIR
API transaction and those otherwise conducted.
Response: The intended goal of publicly reporting these metrics is
to help providers and patients gain insights into the payers' prior
authorization practices and performance, and to assist payers in
evaluating their prior authorization practices. While the performance
and utilization of the Prior Authorization API is valuable information
for assessing the adoption and use of the API itself, it may not
adequately represent the full scope of a payer's prior authorization
practices. As noted in a prior response, we may consider issuing
guidance before the compliance date with more specifics on the
recommended format and content; however, the lack of regulations or
guidance on the format and content does not prevent payers from
including additional information that could be of value to patients and
providers.
8. ``Gold-Carding'' Programs for Prior Authorization
We solicited comments on the potential for gold-carding or prior
authorization exemption programs and how they might reduce provider and
payer burden and improve services to patients. We also solicited
comments on the incorporation of such a measure into Star Ratings for
these organizations. We received several comments on this topic and
appreciate the input. Since no policies were proposed, we are not
finalizing policies in this area at this time. We thank commenters for
their feedback and will consider all comments for possible future
rulemaking.
BILLING CODE 4150-28-P

[[Page 8895]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.008

[[Page 8896]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.009

BILLING CODE 4150-28-C

[[Page 8897]]

9. Final Action
After considering the comments received, and for the reasons
discussed in the CMS Interoperability and Prior Authorization proposed
rule and our response to those comments (as summarized previously), we
are finalizing our proposals with the following modifications:
Impacted payers must implement and maintain a Prior
Authorization API beginning 2027 (by January 1, 2027, for MA
organizations and state Medicaid and CHIP FFS programs; by the rating
period beginning on or after January 1, 2027, for Medicaid managed care
plans and CHIP managed care entities; and for plan years beginning on
or after January 1, 2027, for QHP issuers on the FFEs) rather than in
2026.
MA organizations must report prior authorization metrics
at the contract level rather than at the proposed organization level.
See further discussion for exact details of the final requirements
for impacted payers.
We are finalizing that, beginning 2027 (by January 1, 2027, for MA
organizations and state Medicaid and CHIP FFS programs; by the rating
period beginning on or after January 1, 2027, for Medicaid managed care
plans and CHIP managed care entities; and for plan years beginning on
or after January 1, 2027, for QHP issuers on the FFEs), impacted payers
must implement and maintain a Prior Authorization API that is compliant
with certain technical standards, documentation requirements, and
denial or discontinuation policies. Specifically, those technical
standards are HL7 FHIR at 45 CFR 170.215(a)(1), US Core IG at 45 CFR
170.215(b)(1)(i), and SMART App Launch IG at 45 CFR 170.215(c)(1).
We are finalizing that, by the compliance dates, impacted payers
must implement a Prior Authorization API that:
Is populated with the payer's list of covered items and
services (excluding drugs) that require prior authorization;
Can identify all documentation required for approval of
any items or services that require prior authorization;
Supports a HIPAA-compliant prior authorization request and
response; and
Communicates whether the payer approves the prior
authorization request (and the date or circumstance under which the
authorization ends), denies the prior authorization request (with a
specific reason), or requests more information.
We are finalizing that, beginning 2026 (by January 1, 2026, for MA
organizations and state Medicaid and CHIP FFS programs; by the rating
period beginning on or after January 1, 2026, for Medicaid managed care
plans and CHIP managed care entities; and for plan years beginning on
or after January 1, 2026, for QHP issuers on the FFEs), impacted
payers' must provide a specific reason for a denial within their
decision timeframe regardless of the method that was used to send the
prior authorization request or decision.
We are finalizing that, beginning in 2026, MA organizations,
including applicable integrated plans, state Medicaid and CHIP FFS
programs, and Medicaid managed care plans and CHIP managed care
entities must provide notice to providers and patients of prior
authorization decisions as expeditiously as a patient's health
condition requires, but no later than 7 calendar days for standard
requests, unless a shorter minimum timeframe is established under
applicable state law.
We are finalizing that, beginning in 2026, MA organizations,
including applicable integrated plans, and state Medicaid and CHIP FFS
programs, must provide notice to providers and patients of prior
authorization decisions as expeditiously as a patient's health
condition requires, but no later than 72 hours for expedited requests,
unless a shorter minimum timeframe is established under applicable
state law. That requirement already exists for Medicaid managed care
plans and CHIP managed care entities, but for consistency with Medicaid
FFS, we are finalizing that those payers must also send notices to
patients and comply with a shorter timeframe, if established by state.
In response to public comments, CMS will work with state Medicaid
and CHIP FFS programs that may be unable to meet the new prior
authorization decision timeframes compliance date in 2026. States
should contact their Medicaid state lead or CHIP project officer before
April 1, 2025, to discuss their extenuating circumstances. Any
flexibility granted to a state Medicaid or CHIP FFS program for the
implementation of the new prior authorization decision timeframes
requirements will be temporary and limited to the unique circumstances
of the program.
We are finalizing that, as of the effective date of this final
rule, existing Medicaid beneficiary notice and fair hearing regulations
apply to Medicaid FFS prior authorization decisions.
We are finalizing that, beginning in 2026, impacted payers must
annually report certain aggregated prior authorization metrics.
Specifically, by March 31, MA organizations at the contract level,
state Medicaid and CHIP FFS programs at the state level, Medicaid
managed care plans and CHIP managed care entities at the plan level,
and QHP issuers on the FFEs at the issuer level must post the required
metrics on their websites. Impacted payers must publicly report the
previous calendar year's metrics by March 31 following any year that
they offered that type of plan.
These policies apply to MA organizations, state Medicaid and CHIP
FFS programs, Medicaid managed care plans, CHIP managed care entities,
and QHP issuers on the FFEs at the CFR sections listed in Table E4.
10. Statutory Authorities To Require Improvements in Prior
Authorization Processes, Decision and Notification Timeframe Policies
We did not receive any public comments on the statutory authorities
for the Prior Authorization API and prior authorization process
policies discussed in this section.
a. Medicare Advantage
Section 1856(b) of the Act directs the Secretary to establish
regulatory standards for MA organizations that are consistent with, and
carry out, Part C of the Medicare statute, including the provisions in
section 1852 of the Act. Section 1852(a) and (d) of the Act provide for
MA plans to cover medically necessary Part A and Part B benefits,
including by making benefits available and accessible with reasonable
promptness. Section 1852(c)(1)(G) of the Act requires that MA
organizations disclose to their enrollees any rules regarding prior
authorization or other review requirements that could result in
nonpayment. Section 1852(g)(1)(A) of the Act requires an MA plan to
have a procedure for making determinations about whether an enrollee is
entitled to receive a health service, how much the enrollee is required
to pay for such service, and to provide an enrollee with a written
notice if the plan denies coverage. Section 1852(g)(1)(A) of the Act
also requires that coverage determinations be made on a timely basis.
Section 1852(g)(3)(B)(iii) of the Act requires that the organization
notify the enrollee (and physician involved, as appropriate) of an
expedited determination (and reconsideration) under time limitations
established by the Secretary, but not later than 72 hours after the
time of receipt of the request. The prior authorization requirements in
this final rule ensure that MA organizations carry out their
responsibilities under section 1852 of the Act in a consistent and
standardized

[[Page 8898]]

fashion and in compliance with standards that carry out and serve the
purposes of the MA program.
Under the authorities referenced previously, we are finalizing
certain requirements for MA organizations. These requirements are to
ensure that MA organizations provide enrollees with appropriate access
to care and information by using certain standards, technologies, and
business processes. The requirements include implementing certain APIs
that provide information about the coverage and documentation
requirements for prior authorization, responding to prior authorization
requests with the status of that request, and meeting certain
timeframes for making decisions on prior authorization requests.
We are requiring that MA organizations implement the Prior
Authorization API using certain implementation specifications as
discussed in section II.G. of this final rule. These implementation
specifications are expected to improve the overall prior authorization
process by addressing deficiencies that exist in the process today
concerning providers' access to information about the prior
authorization rules and documentation requirements. The Prior
Authorization API will communicate the coverage and documentation
requirements for prior authorization, indicating if authorization is
required for a specific item or service and what documentation is
required to support an authorization request. Use of the Prior
Authorization API is consistent with the disclosure obligation on MA
organizations in section 1852(c)(1)(G) of the Act by disclosing to
providers the same information that generally must be provided to
enrollees about which covered benefits are subject to prior
authorization and serves the same larger purpose of ensuring access to
coverage by communicating the limits and rules for covered services.
Additionally, the Prior Authorization API is a mechanism for
receiving and responding to requests for coverage determinations before
the services are rendered or items furnished; therefore, the
requirement to adopt and use the Prior Authorization API is an
additional standard for implementing and complying with section 1852(g)
of the Act regarding an MA organization's obligation to make coverage
determinations. The Prior Authorization API will enable the provider to
submit a HIPAA-compliant prior authorization request through their
existing workflow and receive a timely response to that request. In
concert with these APIs, we are requiring the payer to provide the
status of the request, such as whether it was approved or denied, along
with a specific denial reason, so that the provider knows what steps to
take next--whether to request a different service for the patient, to
submit additional information, or to appeal the decision. These final
requirements will improve patient care and reduce redundancies in
administrative processes between providers and payers because they give
providers clearer instructions, both for submitting the original
request and, if necessary, providing additional information. The
required API has the potential to improve the efficiency of the prior
authorization process because it enables providers to submit accurate
information with the request, which could reduce the number of appeals
or denials, and possibly eliminate requests for additional
documentation.
We expect the prior authorization policies in this final rule to
improve timely access to care for beneficiaries by mitigating delays
that sometimes occur when a provider is trying to determine coverage
requirements or does not know what documents to submit to obtain
approval for a service. Improvements in the timeliness of payer
operations and provider services will contribute to program efficiency,
and effective operations and will be in the best interest of the
enrollees. The requirement for MA organizations to make certain changes
to the timeframes in which they provide notice for prior authorization
has the potential to improve patient access to care in program
operations as discussed in section II.D.5. of this final rule. This
could prevent some patients from abandoning care while waiting for
authorization, and it could improve efficiencies by avoiding repeat
phone calls from providers who must check on the status of
authorization over several days, or sometimes weeks. We finalized
requirements to improve some timeframes for expedited and standard
decisions under the premise that these changes are overdue, feasible,
and would benefit patients and providers. Furthermore, by establishing
more certainty in the process for providers, there may be a reduction
in unnecessary repeat requests for services. More responsive timeframes
will also enhance enrollee access to timely and appropriate care. A
shorter timeframe for both standard and expedited decisions may reduce
administrative time and expense for providers and payers, as they would
spend fewer resources on follow-up inquiries. As such, these
requirements are consistent with our authorities to adopt standards to
carry out and implement the requirements in section 1852 of the Act for
MA organizations to have a procedure for making timely determinations
and to make benefits available and accessible with reasonable
promptness.
Finally, section 1857(e)(1) of the Act explicitly authorizes the
adoption of additional reporting requirements by MA organizations where
necessary and appropriate. The requirement for MA plans to publicly
report prior authorization metrics will enable CMS to assess the
implementation of the policies and attempt to determine the impact of
these new requirements on payers and providers. A review of these
metrics may help CMS and the plans understand the impact of the
requirements, including the impact of using the APIs and improved
decision timeframes. The data may also help plans evaluate operations,
implement new policies and the API, and determine what changes may be
appropriate.
b. Medicaid
For Medicaid, most of the requirements finalized in this section
are authorized by sections 1902(a)(4), (8), and (19) of the Act.
Section 1902(a)(4) of the Act requires that a state Medicaid plan
provide such methods of administration as are found by the Secretary to
be necessary for the proper and efficient operation of the state
Medicaid plan, section 1902(a)(8) of the Act requires states to ensure
that Medicaid services are furnished with reasonable promptness to all
eligible individuals, and section 1902(a)(19) of the Act requires
states to ensure that care and services under a Medicaid state plan are
provided in a manner consistent with the simplicity of administration
and the best interests of the recipients. Some requirements finalized
in this section are also authorized by additional sections of the Act
as discussed in this section of the final rule.
Additionally, section 1902(a)(7) of the Act requires that states
must provide safeguards that restrict the use or disclosure of
information concerning Medicaid applicants and beneficiaries to
purposes that are directly connected with the administration of the
program or plan. The implementing regulations at 42 CFR part 431,
subpart F, for this section 1902(a)(7) of the Act list purposes that
CMS has determined are directly connected with the administration of
Medicaid state plans (42 CFR 431.302) and require states to provide
safeguards meeting certain

[[Page 8899]]

requirements to restrict uses and disclosures of Medicaid beneficiary
data. CHIP programs are subject to the same requirements through a
cross reference at 42 CFR 457.1110(b).
Our finalized policy that the data described in this section be
shared via the Prior Authorization API is consistent with the
requirement at section 1902(a)(7) of the Act, providing that states may
share these data only for purposes directly connected with the
administration of the Medicaid state plan. This data sharing policy for
the Prior Authorization API is related to providing services for
beneficiaries, a purpose listed at 42 CFR 431.302(c). The services
include those for which the state requires that a provider submit a
prior authorization request, and thus needs to communicate about that
prior authorization with other providers enrolled with or authorized by
the state to provide care to its beneficiaries. Prior authorization can
be an integral part of the Medicaid program and facilitates access to
care as well as provider payment processes.
We remind states that to meet the requirements of the regulations
at 42 CFR part 431, subpart F, states must have consistent criteria for
the release and use of information (which should comply with the
proposed Prior Authorization API requirements), in accordance with 42
CFR 431.306(a). Access to information concerning beneficiaries must be
restricted to persons who are subject to standards of confidentiality
that are comparable to that of the state Medicaid agency, in accordance
with 42 CFR 431.306(b). Similar to the Provider Access API discussed
previously, the permission requirement at 42 CFR 431.306(d), which
requires that the state agency obtain permission from a family or
individual, whenever possible, before responding to a request for
information from an outside source, is not relevant to the Prior
Authorization API, because any request for beneficiary information
would be from an enrolled Medicaid or CHIP provider and thus would not
be from an outside source. While the beneficiary's permission is not
required under 42 CFR 431.306(d) for the Prior Authorization API, state
or other laws may require such permission. When requesting approval to
provide certain services from the state using the state's Prior
Authorization API as described in section II.D.2.a. of this final rule,
the provider will be able to determine if prior authorization is
required and what supporting documentation is necessary to obtain
approval for that care.
i. Prior Authorization API
The requirement for state Medicaid FFS programs and Medicaid
managed care plans to implement the Prior Authorization API is expected
to improve the efficiency and timeliness of the prior authorization
process for Medicaid beneficiaries, providers, state Medicaid agencies,
and Medicaid managed care plans by addressing inefficiencies that might
exist in the process today. As discussed in section II.D.2.a. of this
final rule, the Prior Authorization API will allow a provider to
determine whether a prior authorization is required and the
documentation requirements for that prior authorization request. The
Prior Authorization API will:
Enable providers to submit a complete prior authorization
request faster and easier;
Support more timely notice to the provider and beneficiary
of the disposition of the prior authorization request; and
Permit improved scheduling of services or filing appeals,
depending on the decision. The Prior Authorization API has the
potential to improve the prior authorization process by making it more
efficient, including by reducing the number of denials and appeals, or
even by eliminating requests for additional documentation, as noted
elsewhere in this final rule.
ii. Requirement for Payers To Provide Specific Reason for Denial of
Prior Authorizations
Based on the provisions of this final rule, states and Medicaid
managed care plans must provide specific information to providers about
the status of prior authorization requests to enable providers to plan
care for their patients after submitting a prior authorization request.
As discussed in section II.D.3. of this final rule, when providers
receive a response to a prior authorization request, the payer will
typically indicate whether the request is approved, or denied, or if
additional information is needed. If prior authorization has been
denied, the payer must give the provider the specific reason for the
denial; that information may be used by the provider to decide next
steps, such as re-submitting the request with updated information,
identifying alternative treatments for the patient, or appealing the
decision. These requirements will improve the timeliness, clarity, and
consistency of information for providers regarding prior authorization
requests; help providers determine the next steps for timely patient
care; and reduce payer, provider, and patient burden by eliminating the
need for repeated inquiries.
iii. Requirements for Prior Authorization Decision Timeframes,
Notifications Related to Prior Authorization Decision Timeframes, and
Amendments to Existing Medicaid Fair Hearings and Appeals Regulations
As discussed in section II.D.5. of this final rule, delayed prior
authorization decisions may directly affect patient care by delaying
access to treatment, services, and supplies, as well as transfers
between hospitals and post-acute care facilities. The required
timeframes for making prior authorization decisions about items and
services that require prior authorization in Medicaid FFS and managed
care programs will help providers better manage administrative
resources, make more time available for providers to render patient
care, and facilitate faster access to services. These requirements
should make substantive improvements to the care experience for
Medicaid beneficiaries and lead to better health outcomes. In turn,
better health outcomes will contribute to more efficient use of
Medicaid program resources.
The requirement to shorten the maximum amount of time for a
Medicaid managed care plan to make a prior authorization decision from
14 calendar days to 7 calendar days will improve the efficient
operation of the Medicaid program by facilitating faster receipt of
services or filing of appeals.
Our amendment to explicitly state in the regulation text that
current notice and fair hearing requirements apply to Medicaid FFS
prior authorization decisions is authorized under section 1902(a)(3) of
the Act. Section 1902(a)(3) of the Act requires that a Medicaid state
plan provide an opportunity for a fair hearing to any individual whose
claim for medical assistance under the plan is denied or is not acted
upon with reasonable promptness. This is also supported by the 14th
Amendment to the United States Constitution and case law on due
process, specifically, Goldberg v. Kelly, 397 U.S. 254 (1970). States
must establish timely notice and fair hearing processes meeting due
process standards under Goldberg v. Kelly, as incorporated into
existing Medicaid fair hearing regulations at 42 CFR part 431, subpart
E, see 42 CFR 431.205(d).
Additionally, section 1902(a)(17) of the Act requires state
Medicaid plans to include reasonable standards for determining the
extent of medical assistance under the plan that are

[[Page 8900]]

consistent with the objectives of Title XIX of the Act. As set forth at
42 CFR 440.230, the standards that states establish under section
1902(a)(17) of the Act could include appropriate limits on a service
based on such criteria as medical necessity or on utilization control
procedures, as long as each service is sufficient in amount, duration,
and scope to reasonably achieve its purpose. Items and services covered
under Title XIX benefit authorities are subject to 42 CFR 440.230,
unless statute or regulation expressly provides for an exception or
waiver. This would include covered items and services described in
sections 1905(a), 1915(c), 1915(i), 1915(j), 1915(k), 1915(l), 1937,
and 1945 of the Act, and any other authorities as established by
Congress. The standards that states establish under section 1902(a)(17)
of the Act and 42 CFR 440.230 could include prior authorization
requirements. The requirements to establish timeframes for prior
authorization decisions are authorized under section 1902(a)(17) of the
Act because they would be expected to help ensure that states make
prior authorization decisions in a manner that is consistent with the
requirements in section 1902(a)(4), (a)(8), and (a)(19) of the Act,
thus helping to ensure that states' standards for determining the
extent of medical assistance under the plan are consistent with the
objectives of Title XIX.
Section 1932(b)(4) of the Act provides that each Medicaid MCO must
establish an internal grievance procedure whereby a beneficiary who is
eligible for medical assistance may challenge the denial of coverage or
payment for such assistance. CMS has implemented requirements for those
procedures at 42 CFR 438.210, which applies the same appeal and
grievance requirements for PIHPs and PAHPs as for Medicaid MCOs. We
rely on our authority in section 1902(a)(4) of the Act to adopt
standards for PIHPs and PAHPs that mirror requirements for MCOs. This
is consistent with our prior practice for adopting standards for
Medicaid managed care plans (81 FR 27507). We rely on the same
authority here to revise the procedures under which Medicaid managed
care plans may make prior authorization decisions about coverage and
provide those decisions to providers and enrollees. Reducing plan
response time for prior authorization decisions may enable
beneficiaries to file appeals if necessary and receive a resolution to
those appeals sooner. The earlier an appeal is filed, and the
disposition known, the sooner the provider and beneficiary can
determine whether to request a state fair hearing or to identify
treatment alternatives, if necessary. The prior authorization
requirements in this rule are also consistent with how section
1932(c)(2)(A)(i) of the Act requires MCO contracts to contain a
provision for an annual external quality review of quality outcomes and
access to and timeliness of covered services. If the shorter prior
authorization response requirements successfully improve workflow and
processes that facilitate timely access to services, improvements to
the care experience for patients, and better health outcomes, the
results should be visible in external reviews. This requirement
reflects the importance and potential advantages of timely access for
beneficiaries to covered services through more efficient processing of
prior authorization requests as proposed in this rule.
iv. Public Reporting of Prior Authorization Metrics
We are also requiring Medicaid FFS programs and Medicaid managed
care plans to publicly report certain prior authorization metrics by
posting them on the payer's website. As discussed in section II.D.7. of
this final rule, publicly reporting these metrics may support more
timely access to services by identifying prior authorization process
weaknesses or deficiencies and enabling the implementation of
corrective action, and for managed care programs, helping beneficiaries
select Medicaid managed care plans that best meet their needs and
helping some Medicaid providers make informed decisions on which
Medicaid managed care plan networks to join.
Section 1902(a)(4) of the Act authorizes this requirement because
enabling more timely access to services by identifying prior
authorization deficiencies and facilitating the implementation of
corrective action to improve the prior authorization process will
support the proper and efficient operation of the state Medicaid plan.
Requiring Medicaid managed care plans to publicly report their prior
authorization metrics will hold them accountable and enable them to
monitor their performance and identify process improvement
opportunities, which may be an integral part of implementing a quality
assessment and improvement strategy more easily. This is consistent
with the requirements for quality strategies for managed care programs
at section 1932(c)(1)(A)(i) of the Act.
Section 1902(a)(8) of the Act authorizes this requirement because
identifying prior authorization process weaknesses or deficiencies and
enabling the implementation of corrective action as well as helping
beneficiaries select a Medicaid managed care plan that best meets their
needs may improve the promptness with which services are provided to
beneficiaries. Section 1902(a)(19) of the Act authorizes this
requirement because identifying prior authorization process weaknesses
or deficiencies and enabling the implementation of corrective action
will help ensure that care and services are provided in a manner
consistent with the simplicity of administration. Additionally,
implementation of corrective action to improve prior authorization
processes, helping beneficiaries select a managed care plan that best
meets their needs, and helping providers make informed decisions on
which Medicaid managed care plan networks to join is in the best
interest of beneficiaries.
c. CHIP
For CHIP, we finalized these requirements under the authority of
section 2101(a) of the Act, which sets forth that the purpose of Title
XXI is to provide funds to states to provide child health assistance to
uninsured, low-income children effectively and efficiently that is
coordinated with other sources of health benefits coverage. This
provision authorizes us to adopt these requirements for CHIP to obtain
access to program data for analysis. Such analysis supports
improvements in the efficacy of CHIP programs and more efficient
administration of services.
As discussed previously, we are requiring the implementation of the
Prior Authorization API in section II.D.2.a. of this final rule to
improve the prior authorization process for patients, providers, and
payers by addressing deficiencies and inefficiencies that exist
currently. Today, a payer's rules about when prior authorization is
required and what documentation requirements must be fulfilled to
submit the request are not necessarily easily accessible for providers.
The Prior Authorization API will enable a provider to determine if a
prior authorization is required electronically, in real-time and what
the documentation requirements are regarding such requests. While we
expect providers to be the primary beneficiaries of this API, making
this information available in a standardized way and permitting access
through an API will also serve the requirements in section 2101(a) of
the Act that CHIP ensures access to coverage and coordinated care.
The Prior Authorization API is a mechanism for receiving and
responding to requests for coverage

[[Page 8901]]

determinations before the services are furnished; this API will
streamline the initial authorization process for the payer by sharing
this information in an easily accessible way. The API will also allow
the provider to know what to do if prior authorization is required for
a certain service, which will improve the provider's ability to treat
the patient timely. The Prior Authorization API enables the payer to
send a real-time response back to a provider, based on the request for
authorization. This, too, will improve the efficiency of providing
services to the patient because the request and response are automated
and in real-time. We expect payers' use of this API to ensure that a
provider can submit a request for prior authorization with the correct
and complete documentation to avoid an incorrect submission which might
result in an unnecessary denial. The Prior Authorization API will: (1)
enable providers to submit a prior authorization request faster and
easier; (2) support more timely notice to the provider and beneficiary
of the disposition of the prior authorization request; and (3) permit
faster scheduling of services or filing appeals, depending on the
decision. The Prior Authorization API has the potential to improve the
prior authorization process by making it more efficient, including
limiting the number of denials and appeals, or even eliminating
requests for additional documentation, as noted elsewhere.
The safeguards for beneficiary information at 42 CFR part 431,
subpart F, are also applicable to CHIP through a cross reference at 42
CFR 457.1110(b). As discussed previously for Medicaid, CHIP payers' and
providers' data exchange through the Prior Authorization API is related
to providing services to beneficiaries, which is described at 42 CFR
431.302(c) as a purpose directly related to state plan administration.
We remind states that when they share medical records or any other
health or enrollment information about individual beneficiaries, they
must comply with the privacy protections at 42 CFR 457.1110 and the
release of information provisions at 42 CFR 431.306.
The requirement in section II.D.5. of this final rule that CHIP FFS
and CHIP managed care entities meet certain timeframes to provide
decisions for prior authorizations for expedited and standard decisions
is an improvement from the current state, where there is uncertainty
about expectations for when a prior authorization might be approved.
This requirement is intended to establish more certainty in the prior
authorization process for providers and improve access to appropriate
care for all patients, particularly those with chronic conditions or
complicated health risks. Health parity may be increased as barriers
due to process and timeframes will be removed. Similarly, improved
process improvements may reduce administrative costs for providers and
payers as redundancies will be removed from the system. We expect the
requirement to improve timeliness in responding to providers and
patients to support process improvements for the state and managed care
programs and is consistent with our authorities under section 2101(a)
of the Act in that it improves the efficiency of the CHIP programs.
The policy to require CHIP FFS and CHIP managed care entities to
publicly report prior authorization metrics will also support the
states' oversight, evaluation, and administration responsibilities. CMS
may occasionally view some of the CHIP's FFS and managed care websites
to check for compliance, see how data are being reported, and determine
if any trends in prior authorization changes could be indicative of the
benefits of the prior authorization policies as discussed in section
II.D.7. of this final rule. The data may indicate the use of the APIs,
improvements in prior authorization numbers, or changes in total
numbers, denials, and appeals.
d. Qualified Health Plan Issuers on the Federally-Facilitated Exchanges
For QHP issuers on the FFEs, we finalized the requirements in this
section under the authority of section 1311(e)(1)(B) of the Affordable
Care Act, which affords the Exchanges the discretion to certify QHPs if
the Exchange determines that making available such health plans through
the Exchange is in the interests of qualified individuals in the state
in which the Exchange operates.
The policies finalized here may improve the efficiency of the
issuers that are certified to offer QHPs on the FFEs and improve the
quality of services they provide to providers and their patients by
increasing the efficiency in the prior authorization submission and
review process. In section II.D.2.a. of this final rule, we are
requiring that QHP issuers on the FFEs implement an API to support the
prior authorization process. The Prior Authorization API will allow QHP
issuers on the FFEs to communicate requirements for prior authorization
more efficiently and enable providers to similarly operate more
efficiently to determine when a prior authorization is needed and
locate the documentation requirements. The Prior Authorization API may
enable more accurate submission and subsequent processing of prior
authorization requests, with the potential of improving the delivery of
services to patients. Qualified individuals enrolled in QHPs on the
FFEs may receive covered services more quickly using the API. Similar
to the other APIs, we believe that certifying only health plans that
implement the Prior Authorization API and adhere to the other
requirements described in this section of the preamble is in the
interests of qualified individuals in the state or states in which a
QHP issuer on the FFEs operates because of the opportunities for
improvements in patient care, in alignment with the goals of the
Affordable Care Act. We encourage SBEs to consider whether a similar
requirement should apply to QHP issuers participating in their
Exchanges.
We are also requiring that QHP issuers on the FFEs provide a
specific reason for denial when sending a response to a prior
authorization request, to facilitate better communication and
understanding between the provider and issuer. This may enable
efficient and successful resubmission of the previously denied prior
authorization request, which may more promptly facilitate the needed
patient care.
Finally, the requirement for QHP issuers on the FFEs to publicly
report prior authorization metrics in section II.D.7. of this final
rule will hold issuers accountable to their providers and patients,
which could help these organizations improve their program
administration. These data may help QHP issuers on the FFEs evaluate
their processes and determine if there are better ways to leverage the
APIs, including the quality and sufficiency of the coverage and
documentation information included in the APIs.

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

1. Background
The CMS Interoperability and Prior Authorization proposed rule
discussed extensions, exemptions, and exceptions for state Medicaid and
CHIP FFS Programs and QHP issuers on the FFEs, Federal funding
available to states, and applicability to state Medicaid expansion
programs for CHIP populations. As stated in the Provider Access, Payer-
to-Payer, and Prior Authorization API sections of this final rule we
are consolidated in one section the requirements for applying for an

[[Page 8902]]

extension, exemption, or exception. Here we discuss those proposals,
provide responses to the comments received regarding the proposals, and
include the final policies.
2. Extensions, Exemptions, and Exceptions
a. Extensions and Exemptions for State Medicaid and CHIP Fee-for
Service
In the proposed rule we explained that state Medicaid and CHIP FFS
agencies face certain unique financing and operational circumstances
that would not apply to other impacted payers. For example, some states
would need legislative approval to initiate a public procurement
process to secure contractors, particularly those with the necessary
skills to support a state's implementation of the policies that require
API development or enhancement. The timeline for an openly competed
procurement process, together with the time needed to onboard
contractors to develop the APIs can be lengthy for states (87 FR
76302). We described the issues impacting the state Medicaid and CHIP
FFS programs in the proposed rule for the Provider Access (87 FR
76261), Payer-to-Payer (87 FR 76279), and Prior Authorization (87 FR
76302) APIs. However, we also stated that if our proposals regarding
these APIs were finalized, we would strongly encourage state Medicaid
and CHIP FFS programs to implement them as soon as possible, because of
the anticipated benefits for the impacted payers, patients, and
providers. Therefore, to address implementation concerns for state
Medicaid and CHIP FFS programs, we proposed a process through which
states could seek an extension to, and, in specific circumstances, an
exemption from, the requirements to implement and maintain Provider
Access, Payer-to-Payer, and Prior Authorization APIs.
We also proposed that states could request a one-time, 1-year
extension through their annual Advance Planning Document (APD) for
Medicaid Management Information System (MMIS) operations expenditures.
We also proposed to permit state Medicaid FFS programs to request an
exemption from any or all of these three API requirements when at least
90 percent of the state's Medicaid beneficiaries are enrolled in
Medicaid MCOs as defined at 42 CFR 438.2. Similarly, we proposed that
separate state CHIP FFS programs could request an exemption from the
API requirements if at least 90 percent of the state's separate CHIP
beneficiaries are enrolled in CHIP MCOs as defined at 42 CFR 457.10. We
proposed that states could apply for an exemption by submitting a
written request for the exemption as part of the annual APD for MMIS
operations expenditures. CMS approves project plans and enhanced FFP
for Medicaid Enterprise Systems (MES) using the APD process. CHIP
waiver requests and expenditures for systems are managed at CMS in the
operations division responsible for management of APDs. Guidance on the
application process is available through each state's Regional Office
contact.
As discussed in section II.C.4.b. of this final rule, we proposed
and are finalizing, that for the payer to payer data exchange, state
Medicaid and CHIP programs, rather than their managed care plans or
managed care entities, will be responsible for obtaining beneficiaries'
permission, providing educational resources at the time of requesting
permission, and identifying patients' previous/concurrent payers,
including for beneficiaries covered under managed care (87 FR 76280).
Therefore, we also proposed that an exemption would not apply to those
requirements, but only the API requirements, because it would prevent
Medicaid managed care plans and CHIP managed care entities from meeting
their obligations.
For Medicaid managed care plans and CHIP managed care entities, we
did not propose an extension process because we believe that these
managed care plans are actively working to develop the necessary IT
infrastructure to be able to comply with the requirements at 42 CFR
438.272(d)(5) and 42 CFR part 457. Many of these plans might benefit
from efficiencies based on all of the plan types that they offer. For
example, many of these managed care plans with Medicaid and CHIP
beneficiaries are part of a larger organization serving MA and
Marketplace populations. These larger organizations often provide the
technical and operational capacity that would enable implementation of
the APIs across all lines of business. We believe this would be a
practical and efficient use of resources to service all enrollees.
Additionally, because the majority of Medicaid beneficiaries receive
all or some of their benefits in a managed care delivery system, these
plans should be held to the implementation times finalized in this rule
to support the intended policy goals. Please see 87 FR 76263 for the
supporting narrative in the proposed rule.
Comment: Multiple commenters expressed support for the proposed
Medicaid and CHIP FFS extension policy and urged CMS to finalize this
flexibility regarding compliance with the Provider Access, Payer-to-
Payer, and Prior Authorization APIs. Multiple commenters highlighted
extenuating circumstances that state Medicaid and CHIP agencies may
face, especially related to the conclusion of the COVID-19 public
health emergency (PHE), and the resulting impact on IT and personnel
resources.
Multiple commenters submitted comments about which APIs should be
included in the extensions, exemptions, and exceptions proposals and
some recommended that CMS extend these flexibilities to all APIs
included in the rule. A commenter recommended that CMS provide clarity
regarding the exemption and extension provisions for the Patient Access
API requirements.
Response: We acknowledge that states will be conducting long-term
efforts to return to normal Medicaid and CHIP operations after the end
of the COVID-19 PHE and the continuous enrollment condition under
section 6008(b)(3) of the FFCRA. These efforts will continue through
2024, and many of these states have ongoing system development
initiatives that require integration with MES and modules. Some states
must work within their state legislative budget request cycle, as well
as the Federal request cycle for requesting and obtaining funds for
updates to their systems or new contracts.
We reiterate that this final rule requires impacted payers to
implement and maintain Provider Access, Payer-to-Payer, and Prior
Authorization APIs. Impacted payers should have already implemented or
begun implementation of the Patient Access and Provider Directory APIs
as required in the CMS Interoperability and Patient Access final rule,
except for those organizations that have approved exceptions, as
applicable.^{148 149} We did not propose a new Patient Access
API, but rather additional data requirements for that API, and
reporting requirements for use metrics. We did not propose any new

[[Page 8903]]

extensions, exemptions, or exceptions for the Patient Access API in the
proposed rule and are not adding policies of that nature in the final
rule.
---------------------------------------------------------------------------

\148\ In the CMS Interoperability and Patient Access final rule,
we finalized that Patient Access API provisions would be effective
beginning January 1, 2021. We announced a 6-month enforcement
discretion exercised as a result of the PHE until July 1, 2021.
\149\ For example, 45 CFR 156.221(h) permits the FFE to grant an
exception on an annual basis to the requirements in paragraphs (a)
through (g) of that section for an FFE QHP if the Exchange
determines that making their health plan(s) available through the
Exchange is in the interests of qualified individuals in the State
or States in which such Exchange operates, and the QHP issuer
submits a narrative justification describing the reasons why it
cannot reasonably satisfy the requirements for the applicable plan
year, the impact of non-compliance upon enrollees, the current or
proposed means of providing health information to enrollees, and
solutions and a timeline to achieve compliance with the requirements
of this section.
---------------------------------------------------------------------------

Comment: Multiple commenters expressed concern regarding the
proposed state Medicaid and CHIP FFS extension policies, specifically
citing the importance of the impact of these policies on Medicaid
enrollees, and on the need for provider adoption to truly achieve the
burden reduction goals of the proposed rule for patients, payers,
hospitals, and providers. A commenter recommended that CMS not allow
certain payers to have extensions because this could affect provider
adoption of the necessary technology. Another commenter expressed
appreciation of CMS for the proposal to allow extensions but stated
that they believe provider adoption is going to be the most important
factor in achieving burden reduction. The commenter emphasized the
importance of having a certain percentage of their prior authorizations
be electronic so that there is a return on investment from the changes
necessary (for example, workflow changes, training, IT changes). The
commenter stated that if payers are not held to the requirements in the
rule, it could be perceived as a disincentive to providers to invest in
the necessary technology.
Response: We thank commenters for confirmation that payers must be
held accountable for implementation of the APIs, and that provider
adoption of certain APIs is going to be an important factor in
achieving burden reduction--particularly the Prior Authorization API.
Participation by both payers and providers in some of the API
provisions of this final rule will be important to ensure widespread
adoption of the APIs. Because we also believe that provider
participation is important for the Prior Authorization API, we are
finalizing a modification to our proposal to adopt new Electronic Prior
Authorization measures to incentivize providers (specifically, MIPS
eligible clinicians, eligible hospitals, and CAHs) to use the Prior
Authorization API under MIPS and the Medicare Promoting
Interoperability Program as discussed in section II.F. of this rule. We
also reiterate that while these extensions and exemptions apply to the
new API provisions of this final rule, other policies must still meet
the compliance dates established in this final rule. These include the
prior authorization information to be included in the Patient Access
API; information required under the finalized prior authorization
process, such as providing a specific reason for denial, and revised
timeframes for issuing prior authorization decisions. We encourage
states to communicate their implementation plans about the policies in
this final rule (including those to which an extension or exemption may
apply) to network and enrolled providers. Such communication may help
providers prepare for changes in procedures or notify their vendors to
make appropriate system changes on a similar schedule.
Comment: A commenter said that the exemption for the APIs was a
concern because it creates an unfair, two-tiered system that may leave
people with disabilities behind; these people already face high
barriers to care due to administrative burdens and uncertainties caused
by prior authorization. The commenter wrote that the proposed exemption
process will leave some FFS Medicaid populations--groups that include a
disproportionate share of people with disabilities--without comparable
access to any benefits derived from streamlining the prior
authorization process with the Patient Access, Provider Access, and
Payer-to-Payer APIs. The commenter noted the potential challenges of
developing and maintaining the necessary data infrastructure for a
relatively small FFS population, but wrote that in many states, people
receiving Home and Community-Based Services (HCBS) through waivers that
are carved out of managed care, may be individuals who would fall under
the proposed API exemption and would fail to benefit from the
streamlined prior authorization process in this regulation. Another
commenter requested clarification on whether and how CMS considered
health equity when proposing exemptions for some state Medicaid and
CHIP programs. Other commenters expressed disagreement with the
proposed exemptions and stated that these exemption proposals should be
withdrawn, to make the APIs available to every Medicaid beneficiary. A
commenter noted that states with managed care populations close to the
proposed threshold for exemption may be incentivized to pressure
beneficiaries into managed care to qualify for the exemption.
Response: We agree that it is important to consider access and
equity issues, and the risk of a two-tiered system that may impose
barriers to care. CMS will only grant a state an exemption from the
Provider Access, Payer-to-Payer, and Prior Authorization APIs if the
state establishes an alternative plan to enable the electronic exchange
and accessibility of the required information that would otherwise be
shared through the API. For example, CMS will only grant a state an
exemption from the Provider Access API requirement if the state has
established an alternative plan to ensure that enrolled providers have
efficient electronic access to the same required data content about
their patients through other means while the approved exemption is in
effect. Similarly, states would be expected to use efficient means for
electronic prior authorization that would reduce burden for providers
and improve access to information about the requirements for when prior
authorization is required for items and services or what documentation
is required in advance. In light of requirements for the accessibility
of this information, states implementing an alternative plan will be
required to provide this information to all patients and providers in
plain language and to offer auxiliary aids and services to ensure
effective communications with individuals with disabilities.
Comment: Multiple commenters recommended that CMS include managed
care plans in the proposed flexibilities (for extensions and
exemptions) and some commenters said that each state should be able to
decide whether to allow an extension to managed care plans. A commenter
noted that managed care plans have greater resources than state
Medicaid and CHIP FFS programs and would be able to meet the rule
requirements on time. On the other hand, a commenter recommended that
state Medicaid agencies offer managed care plans a 1-year extension.
Response: We acknowledge commenters who recommended that CMS
provide the opportunity for an extension or exemption to Medicaid
managed care plans and CHIP managed care entities to align with our
approach throughout the rule to apply most policies to both state
Medicaid and CHIP FFS programs and Medicaid managed care plans and CHIP
managed care entities. However, we reiterate that the purpose of the
extension policy for state Medicaid and CHIP FFS programs is to provide
states that are making a good faith effort with additional time to work
through lengthy and complex state procurement processes, to secure the
necessary funding, personnel, and technical resources to successfully
implement the requirements. The purpose of the exemption policy for
state Medicaid and CHIP FFS programs is to accommodate the different
enrollment models that are now in effect for each state and provide
consideration

[[Page 8904]]

for states with relatively small FFS populations. In response to these
and many other comments requesting additional time for payers to
implement the Provider Access, Payer-to-Payer, and Prior Authorization
APIs, we are extending the compliance dates for the policies in this
final rule that require API development or enhancement to 2027. This
allows all impacted payers an additional year to meet these
requirements, compared to our initial proposal to implement the
requirements in 2026. We are finalizing the state Medicaid and CHIP FFS
extension and exemption policies as proposed without extending this
option to other payers in the Medicaid program, such as Medicaid
managed care plans. We do not agree with commenters who suggested that
each state be able to decide separately to allow an extension to
managed care plans because the purpose of this final rule is to
encourage adoption of these policies as soon as is practicable. As we
have noted, Medicaid managed care plans are often owned and operated by
larger private organizations, also subject to this final rule, and
likely have the resources and capabilities to implement these policies
and can efficiently leverage the work they do to build APIs across
their Medicaid, MA, and Marketplace lines of business. We do not want
to encourage a system where fewer Medicaid beneficiaries have access to
the benefits of the policies in this final rule versus those with other
types of coverage.
Comment: Multiple commenters provided recommendations regarding
additional payers and plan types that should be eligible to benefit
from the extensions, exemptions, and exceptions proposals. Multiple
commenters recommended that CMS extend these flexibilities to all
impacted payers. For example, a commenter recommended that HHS consider
permitting state Medicaid and CHIP agencies that have a direct
relationship with patients and providers to be eligible for extensions,
exemptions, or exceptions. Another commenter recommended that CMS
create an exception process for state Medicaid agencies in states or
territories with HIEs that would give participating providers the same
data as the Provider Access API. Some Medicaid agencies report concerns
about duplication with these HIEs, as this would be an inefficient use
of resources, could confuse providers, and may inhibit efforts to
expand HIEs. A commenter wrote that CMS should create an exception
process for Medicaid agencies in states or territories with robust HIEs
that provide access to the same data. Another commenter recommended
that CMS consider exception and extension criteria for plans where the
proposed timelines and requirements would jeopardize their ability to
operate.
Response: We thank all commenters for their input regarding
extensions, exemptions, and exceptions for all payers. We are
finalizing the extensions and exemptions policies as proposed for state
Medicaid and CHIP FFS programs without extending them to additional
payers because state Medicaid and CHIP FFS programs face certain unique
challenges. As noted previously, unlike other impacted payers, state
Medicaid and CHIP FFS programs do not have many discrete health care
plans, and therefore cannot balance implementation costs across plans
with low enrollment and those with higher enrollment. As stated at the
beginning of this section, many states have complex procurement and
staffing/recruitment challenges which do not apply to non-governmental
organizations. We acknowledge HIEs could be helpful partners for payers
when implementing these APIs. Nothing in this rule would prohibit a
state from partnering with an HIE to meet its requirements. Further
discussion regarding HIEs can be found in sections II.B.3.b.iii. and
II.C.3.a. of this final rule.
Comment: Some commenters recommended that CMS include extensions
and/or exemptions in the proposal for MA organizations, Special Needs
Plans (SNPs), D-SNPs, or Institutional Special Needs Plans (I-
SNPs).\150\ A commenter wrote that CMS should also permit extensions
and exemptions for MA organizations offering integrated D-SNPs,
especially if CMS does not finalize a phased-in approach to
implementation. The commenter wrote that some of these payers are
facing the challenge of unwinding current flexibilities implemented due
to the PHE and are also facing significant requirements in coming years
as finalized in the CY 2024 MA and Part D final rule (88 FR 22120).
Another commenter asked that CMS consider whether there may be
appropriate circumstances where it would be permissible for very small
MA organizations, such as SNPs or I-SNPs to seek a one-time extension
to the compliance dates.
---------------------------------------------------------------------------

\150\ We note for readers that MA organizations offer MA plans,
which include SNPs (including the specific types of SNPs mentioned
by commenters--D-SNPs and I-SNPs), so we address these comments
together.
---------------------------------------------------------------------------

Response: We did not propose extensions or exemptions for MA
organizations or Medicaid managed care plans, including plans that
integrate managed care Medicare and Medicaid benefits (for example, D-
SNPs or applicable integrated plans). We have provided explanations for
excluding Medicaid managed care plans in previous responses. We believe
that most MA organizations are supported by entities with an
operational and technical infrastructure that can support the API
requirements because these organizations can leverage existing staff
and vendor resources from implementation of the Patient Access and
Provider Directory APIs. Further, MA organizations should have the
operational infrastructure to analyze and implement the requirements
for the new APIs based on that expertise. Finally, because we did not
propose extensions or exemptions for MA organizations in the proposed
rule, we cannot finalize such a policy for these entities in this rule.
Comment: Some commenters recommended that CMS grant exemptions for
states that are already implementing electronic prior authorization
solutions or state-level policies that conflict with the proposed Prior
Authorization API requirements.
Response: The option for states to apply for an exemption exists to
alleviate burden for states with small FFS populations and that have
established an alternative plan to ensure that enrolled providers have
efficient electronic access to the same information through other means
while the exemption is in effect. We will not grant exemptions for
situations where state law conflicts with the final rule. The final
rule pre-empts any conflicting state law.
Comment: Multiple commenters recommended that CMS consider allowing
states to obtain two 1-year extensions. A commenter stated that an
additional, 1-year extension would allow states to better meet the
proposed requirements. Another commenter noted that states face certain
challenges that may be out of their control and prolong implementation.
Response: After consideration of comments received and for the
reasons outlined in our response to these comments, we are extending
the compliance dates for all of the polices that require API
development or enhancement finalized in this rule to begin January 1,
2027, which will allow for additional time for the FHIR standard and
IGs to continue to be refined and advanced to support all of the
policies in this final rule. This applies to the compliance dates for
the Provider Access, Payer-to-Payer, and Prior Authorization APIs.
State Medicaid and CHIP FFS programs will

[[Page 8905]]

be eligible to apply for up to a 1-year extension as proposed.
Comment: Multiple commenters expressed support for CMS's proposal
regarding exemptions for state Medicaid and CHIP FFS programs and
recommended that CMS finalize these proposed flexibilities regarding
implementation of the Provider Access, Payer-to-Payer, and Prior
Authorization APIs. A commenter indicated that in reviewing exemption
requests and the compliance dates in the proposed rule, as well as
other information system projects that are in development, their plans
to implement a comprehensive systems integration platform that would
integrate the MES would necessitate the option for an exemption. This
commenter indicated that the project was particularly urgent due to the
end of system support for another legacy system. Another commenter
recommended that CMS use a flexible interpretation for the exemption
process and noted that it would not be reasonable to require a state to
build out APIs for a Federal Emergency Services Program (FESP),
explaining that some agencies report having a high number of FFS
enrollees in an FESP, such that less than 90 percent of their members
are technically enrolled in managed care.
Response: We appreciate the support for the proposed exemption
process, as well as for the simultaneous encouragement for payers to
secure the necessary resources to implement the technology for the
prior authorization and other APIs being finalized in this rule. We
also confirm that the policy in this final rule does not apply to
FESPs, and that other payers are not being considered eligible for
exemptions, extensions, or exceptions at this time.
Comment: A commenter noted that states with managed care
populations close to the proposed threshold for exemption may be
incentivized to pressure beneficiaries into managed care to qualify for
the exemption. A commenter stated that larger states qualifying for an
exemption will have a total number of FFS beneficiaries that is greater
than the total Medicaid population of smaller states that would not
qualify for the exemption.
Response: CMS needs to balance the benefits to small populations of
beneficiaries with the burden of new operations and costs being placed
on states. CMS will not approve exemptions unless a state has
established an alternative plan to ensure that enrolled providers have
efficient electronic access to the same information, including prior
authorization information, through other means while the exemption is
in effect, or that states are providing efficient electronic access to
other payers. Additionally, state agencies with an approved exemption
will be required to meet the policies that do not require API
development or enhancement for their FFS populations (that is, the
reduced prior authorization decision timeframes, providing a specific
reason for a denial, and reporting prior authorization metrics). These
policies, to the extent they will mitigate barriers to care or support
improvements in the transparency of information between the states and
providers, are part of the overall scope for this final rule to address
challenges with prior authorization. Concerning the methodology states
use to apply and be approved for an exemption, we believe we have
provided a threshold where a state could appropriately claim an
exemption without taking actions that would inappropriately influence
the enrollment process or individual enrollee's enrollment decisions.
States' use of enrollment brokers for choice counseling and enrollment
processing also protects enrollees from undue pressure during the
enrollment process. We remind states of the enrollee protections
specified at 42 CFR 438.54 and 457.1210 for Medicaid and CHIP managed
care enrollment respectively, as well as disenrollment rights specified
at 42 CFR 438.56(c) and 457.1212, respectively.
Comment: A commenter urged CMS to use a flexible interpretation for
the exemption process for the API requirements for Medicaid agencies
with at least 90 percent of their members enrolled in managed care,
noting that some states have a high number of FFS beneficiaries in an
FESP that are only covered for emergency care. The commenter stated
that it would not be reasonable to require a state to build out APIs
for beneficiaries and programs that cover such a narrow scope of
services.
Response: We appreciate the commenter highlighting that some states
may have larger populations in FFS where beneficiaries are not
receiving comprehensive benefits and thus may experience only limited
value from the APIs. Our intent with establishing this condition for
exemption approval is that no FFS population will experience diminished
health care delivery or information exchange capabilities as a result
of an approved exemption. The exemption intends to alleviate the cost
burden of implementing the API provisions on state Medicaid and/or CHIP
agencies with small FFS populations, regardless of the scope of their
benefit package. We remind states that CMS will grant an exemption if
the state establishes to CMS's satisfaction that the state meets the
criteria for the exemption and has established an alternative plan to
ensure that enrolled providers have efficient electronic access to the
same information through other means while the exemption is in effect,
including patient information and prior authorization information.
b. Exception for Qualified Health Plan Issuers on the Federally-
Facilitated Exchanges
For QHP issuers on the FFEs, we proposed an exception process to
the Provider Access, Payer-to-Payer, and Prior Authorization APIs for
issuers applying for QHP certification that cannot satisfy the proposed
requirements. To apply for an exception, we proposed that an issuer
must include as part of its QHP application a narrative justification
describing the reasons why it cannot reasonably satisfy the
requirements for the applicable plan year, the effect of non-compliance
upon providers and enrollees, the current or proposed means of
providing the required information to providers or other payers, and
solutions and a timeline to achieve compliance with the requirements
(87 FR 76304). We reiterate in this final rule that QHP issuers on the
FFEs submit a new application each year and that this information will
be part of the annual QHP Certification application submission. Thus,
should the size, financial condition, or capabilities of the QHP issuer
change such that it believes it can implement one or more of the APIs,
that information would be included in the application. We received a
few comments on the proposals for exceptions for QHPs.
Comment: Multiple commenters expressed support for the proposed
exception process for QHP issuers on the FFEs, highlighting the need
for this policy and recommending that CMS finalize the proposal to
allow exceptions for QHP issuers on the FFEs regarding compliance with
all proposed APIs.
Response: We appreciate the support for the policy that QHPs be
permitted an exception for the policies that require API development or
enhancement in cases where the FFE determines that making such QHPs
available is in the interests of qualified individuals in the state or
states in which the FFE operates, and an exception would be warranted
to permit the QHP issuer to offer QHPs through the FFE. This policy and
the exceptions per 45 CFR 156.222(c) are consistent with the exception
for QHP issuers on the FFEs

[[Page 8906]]

that we finalized for the Patient Access API in the CMS
Interoperability and Patient Access final rule (85 FR 25552). We
believe that having a QHP issuer offer QHPs through an FFE generally is
in the best interest of patients; we would not want patients to have to
go without access to QHP coverage because an issuer is unable to
implement these APIs.
Comment: Multiple commenters expressed concern regarding the
proposed exception process for QHP issuers on the FFEs. Commenters
specifically highlighted the ability for a QHP issuer to be certified,
even with an exception to these requirements. A commenter recommended
that CMS limit using exceptions for QHP issuers on the FFEs for the
Provider Access API, and another commenter recommended that CMS explain
that QHP issuers on the FFEs must eventually comply with the proposed
requirements. A commenter expressed concern that if QHP issuers on the
FFEs can be certified without complying with the regulation, then there
would not be an incentive for compliance. A commenter stated that the
proposal does not make sense given the financial position of QHP
issuers on the FFEs and their ability to afford cost-saving technology.
The commenter recommended that any exception be conditioned on ``no
profit taking'' by a health plan and limited executive compensation
plans until the plan can comply. Additionally, the commenter stated
that CMS had not offered a reasonable proposal for criteria to qualify
a QHP issuer to be exempt from the proposed API requirements.
Response: We understand concerns from commenters about permitting
delayed implementation of requirements to promote access to information
and expedited decision-making. However, given the comments in support
of the proposed exceptions process and our interest in ensuring a
variety of coverage options for FFE enrollees, we are finalizing this
exception as proposed. While some issuers are in a position to
implement the updates that this rule requires, a wide range of issuers
participate in the FFEs and vary in terms of when they will have
available resources to adopt these new requirements. Per applicable
rules at 45 CFR 156.221(h), 156.222(c), and 156.223(d), we have been
and will continue granting exceptions to QHP issuers on the FFEs on an
annual basis, and use information that issuers submit as part of the
QHP certification process to track their progress.
We will implement the exceptions processes per 45 CFR 156.222(c),
and 45 CFR 156.223(d), based on our experience to date with
implementing the existing exception per 45 CFR 156.221(h) that is
available to QHP issuers on the FFEs that cannot satisfy the
requirements per 45 CFR 156.221(a) through (g) to implement and
maintain the Patient Access API for the applicable plan year. When
determining whether a QHP issuer on an FFE may qualify for an exception
to the current requirement to provide a Patient Access API, we take
into consideration the content that the issuer submits per the
requirement at 45 CFR 156.221(h), including the impact of non-
compliance upon enrollees, the current or proposed means of providing
health information to enrollees, and solutions and a timeline to
achieve compliance with the requirements of this section. This
information allows us to assess whether a QHP issuer has a plan in
place to mitigate harm or inconvenience to enrollees by ensuring they
can access necessary information, as well as a plan to fully implement
the requirements as soon as possible. Information that issuers submit
during the QHP certification process also allows us to develop a
knowledge base of API development capacity for issuers based on size
and other circumstances, which can inform future decisions about
whether to allow exceptions. We expect to build on this knowledge base
as we implement the exceptions processes per 45 CFR 156.222(c) and
156.223(d), and as part of our updates to the QHP certification process
in the coming years to reflect this rule's new requirements, we will
continue to work closely with issuers and other stakeholders to ensure
that our implementation balances the importance of access to
information with robust QHP issuer participation on the FFEs.
Finally, QHP issuer applications for plan years 2023 and 2024
indicated that most issuers were compliant with the requirement to
provide a Patient Access API. Further, issuers that sought an exception
under 45 CFR 156.221(h) generally explained in their justifications
that they planned to become compliant with the API requirements mid-way
through the upcoming plan year, or shortly after the start of the plan
year. This high level of compliance suggests that the availability of
an exception does not discourage or de-incentivize issuers'
implementation of these standards.
We agree that the intent of our final policies is for all impacted
payers to provide patients with the benefits of the Provider Access,
Payer-to-Payer, and Prior Authorization APIs as soon as they are
financially and operationally able. For example, for each of the API
provisions for which an exemption is available, we have indicated that
if the payer cannot implement the API and is seeking an exemption, it
must offer alternative options to the providers to support the intent
of the policies; such programs would generally improve the exchange of
patient data between payers for care management or access to
information for patients, and to improve the prior authorization
process for providers and payers. We believe that by requiring
alternatives to the APIs during the exemption, payers will investigate
options to implement the APIs because, in the long term, these will be
more efficient and financially viable than maintaining current manual
processes.
Table F1 shows the impacted payers that are eligible to apply for
an extension, exemption, or exception for the Provider Access, Payer-
to-Payer, and/or Prior Authorization APIs required in this final rule.
Tables C1, D1, and E4 found in sections II.B., II.C., and II.D. of this
final rule include the regulatory citations for the extensions,
exemptions, and exceptions for each impacted payer.

[[Page 8907]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.010

3. Federal Matching Funds for State Medicaid and CHIP Expenditures on
Implementation of the Provider Access, Payer-to-Payer, and Prior
Authorization APIs
We explained in the proposed rule for each of the APIs, we would
anticipate that states operating Medicaid and CHIP programs would be
able to access Federal matching funds to support their implementation
of the APIs--specifically, the Provider Access, Payer-to-Payer, and
Prior Authorization APIs. We expect these APIs to lead to more
efficient administration of Medicaid and CHIP state plans by supporting
more efficient data exchange and prior authorization processes,
consistent with sections 1902(a)(4) and 2101(a) of the Act,
respectively.
We do not consider state expenditures for implementing the Provider
Access, Payer-to-Payer, or Prior Authorization APIs to be attributable
to any covered Medicaid item or service within the definition of
``medical assistance.'' Thus, in Medicaid, CMS will not match these
expenditures at the state's regular Federal Medical Assistance
Percentage (FMAP). However, FFP at a rate of 50 percent could be
available for state expenditures related to implementing these APIs for
Medicaid programs under section 1903(a)(7) of the Act (for the proper
and efficient administration of the Medicaid state plan). The three
APIs should, over time, help the state more efficiently administer its
Medicaid program by supporting data exchange with providers and other
payers and improving efficiencies in the prior authorization process.
As we stated in the proposed rule, sharing certain data through the
Provider Access API with participating providers could improve the
quality of care for patients, using the Payer-to-Payer API may help
patients manage their information across payers to support patient
care, and using the Prior Authorization API will enable administrative
efficiencies by reducing delays in the prior authorization process
overall, and by helping reduce the number of denied and appealed prior
authorization decisions.
States' expenditures to implement the proposed requirements could
be eligible for 90 percent enhanced FFP under section 1903(a)(3)(A)(i)
of the Act if the expenditures can be attributed to the design,
development, and installation (DDI) of mechanized claims processing and
information retrieval systems. Additionally, 75 percent enhanced FFP,
under section 1903(a)(3)(B) of the Act, could be available for state
expenditures to operate Medicaid mechanized claims processing and
information retrieval systems to comply with the finalized API
requirements.
States can request Medicaid enhanced FFP under section
1903(a)(3)(A)(i) or (B) of the Act through the APD process described at
45 CFR part 95, subpart F. Additionally, 42 CFR 433.112(b)(12) and
433.116(c) require that any system for which states are receiving
enhanced FFP under section 1903(a)(3)(A)(i) or (B) of the Act align
with and incorporate the ONC Health IT standards adopted at 45 CFR part
170, subpart B. The APIs complement this requirement because they
further interoperability by using standards adopted by ONC at 45 CFR
170.215.\151\ States must comply with 42 CFR 433.112(b)(10) and
433.116(c) to explicitly support exposed APIs, meaning the API's
functions are visible to others to enable the creation of a software
program or application, as a condition of receiving enhanced FFP under
section 1903(a)(3)(A)(i) or (B) of the Act. We note that FHIR is an
open-source standard that can meet the requirements at 42 CFR
433.112(b)(10) and 433.116(c) if implemented by following our
regulations, particularly the technical, documentation and denial or
discontinuation requirements at 42 CFR 431.60.
---------------------------------------------------------------------------

\151\ Centers for Medicare and Medicaid Services (2020). SHO #
20-003 RE: Implementation of the CMS Interoperability and Patient
Access Final Rule and Compliance with the ONC 21st Century Cures Act
Final Rule. Retrieved from https://www.medicaid.gov/federal-policy-guidance/downloads/sho20003.pdf.
---------------------------------------------------------------------------

Finally, 42 CFR 433.112(b)(13) and 433.116(c) require states to
promote sharing, leverage, and re-use of Medicaid technologies and
systems within and among states as a condition of receiving enhanced
FFP under section 1903(a)(3)(A)(i) or (B) of the Act. CMS interprets
that requirement to apply to technical documentation associated with a
technology or system, such as technical documentation for connecting to
a state's APIs. Making the needed technical documentation publicly
available so that systems that need to do so can connect to the APIs
finalized in this rule is required as part of the technical
requirements at 42 CFR 431.60(d) for all APIs, including the Provider
Access, Payer-to-Payer, and Prior Authorization APIs.

[[Page 8908]]

Separately, for CHIP agencies, section 2105(c)(2)(A) of the Act and
42 CFR 457.618, limiting administrative costs to no more than 10
percent of a state's total computable expenditures for a fiscal year
(FY), will apply to administrative claims for developing the APIs
finalized in this rule.
Comment: Multiple commenters expressed appreciation for the
inclusion of language that states may be eligible for enhanced FFP to
support implementation of the Provider Access, Payer-to-Payer, and
Prior Authorization APIs in this final rule. While these commenters
expressed support for this option, others asked CMS to explain whether
enhanced FFP is also available to implement the Patient Access API
requirements.
Response: Many states have already requested enhanced Federal
matching funds for their expenditures on implementation of the Patient
Access API required in the CMS Interoperability and Patient Access
final rule. Additionally, enhanced funding under section
1903(a)(3)(A)(i) of the Act may be available for certain expenditures
to design, develop, and install the enhancements to the Patient Access
API finalized in this rule, in addition to expenditures related to the
Provider Access, Payer-to-Payer, and Prior Authorization APIs. CMS
encourages states to seek enhanced FFP where it might be applicable for
states' expenditures on work needed to meet state Medicaid and CHIP
agencies' requirements under this rule and looks forward to reviewing
any APDs submitted by states. Instructions for submitting the APDs are
available on the Medicaid website \152\ under the topic of ``Medicaid
State Plan Amendments'' with information about what categories of costs
may be included in the requests, such as HIE connection/interface
costs. The information on the categories that are included in these
requests can be found in the State Medicaid Manual (SMM), Chapter 11,
sections 265 & 276,\153\ the State Medicaid Director Letter (SMDL) 16-
004, ``Mechanized Claims Processing and Information Retrieval Systems-
Enhanced Funding,'' \154\ and the State Health Official (SHO) #20-003,
``Implementation of the CMS Interoperability and Patient Access final
rule.'' \155\
---------------------------------------------------------------------------

\152\ Code of Federal Regulations (amended 2016, June 2).
Retrieved from 45 CFR 95.610, Submissions of advance planning
documents.
\153\ Centers for Medicare and Medicaid Services. The State
Medicaid Manual (SMM), Chapter 11, sections 265 & 276. Retrieved
from https://www.cms.gov/regulations-and-guidance/guidance/manuals/paper-based-manuals-items/cms021927.
\154\ Centers for Medicare and Medicaid Services (2016, March
31). State Medicaid Director letter #16-004. Retrieved from https://www.medicaid.gov/sites/default/files/federal-policy-guidance/downloads/SMD16004.pdf.
\155\ Centers for Medicare and Medicaid Services (2020, August
14). State Health Official letter #20-003. Retrieved from https://www.medicaid.gov/sites/default/files/2020-08/sho20003_0.pdf.
---------------------------------------------------------------------------

Comment: A commenter recommended that states receive a 90 percent
Federal match to support implementation of these requirements. Another
commenter urged CMS to explain in the final rule, or additional
guidance, whether all, or likely all, of the required state investment
to develop these APIs, would qualify for enhanced Federal matching to
establish and operate API systems.
Response: States' expenditures to implement the proposed
requirements for each of the APIs may be eligible for 90 percent
enhanced FFP if the expenditures can be attributed to the DDI for those
APIs that benefit the Medicaid program. CMS determines on a case-by-
case basis when states' APDs requesting this 90 percent FFP are
approvable, consistent with the requirements at 42 CFR part 433,
subpart C, and 45 CFR part 95, subpart F. States should work with their
MES State Officers for further guidance specific to their programs.
Comment: A commenter recommended that CMS clarify that the Federal
funding resources available for states meeting the Prior Authorization
API requirement can also include pass-through payments to providers to
obtain and utilize interoperable EHR technology for these purposes.
This commenter also expressed concern that the proposed rule did not
offer any indication of available resources for providers, but they
appreciate CMS's clarification of available Federal resources available
to states for implementing the Prior Authorization API requirement.
Another commenter said that states should be granted flexibility for
Federal funding sources to expand the number of SNF providers able to
utilize the new Provider Access API.
Response: We encourage states to apply for Federal funding to
support their planning, development, and implementation of state
systems including the Provider Access, Payer-to-Payer, and Prior
Authorization APIs, because these APIs will enable more providers to
engage in data exchange with state systems to improve patient care. As
previously noted, enhanced Federal Medicaid funding at the 90 percent
rate may be available for the DDI and at the 75 percent rate for the
operation of these API initiatives that benefit the Medicaid program.
These enhanced Federal matching funds, as outlined at 42 CFR 433.112
(DDI) and 433.116 (operation), are available for state expenditures on
Medicaid state systems only, and not available for other state or
provider expenditures on provider-only systems to support providers' or
other entities' efforts to implement APIs. Similarly, Federal matching
funds at 50 percent under section 1903(a)(7) of the Act might be
available to support Medicaid state specific activities for the
required provisions. However, none of these funds are available for
funding to providers, as these are designated to support state-specific
initiatives.
4. Medicaid Expansion CHIP
Most states have Medicaid expansion CHIP programs, in which a state
receives Federal funding to expand Medicaid eligibility to optional
targeted low-income children that meet the requirements of section 2103
of the Social Security Act. We proposed and are now finalizing our
policy at 42 CFR 457.700(c), that for states with Medicaid Expansion
CHIP programs, the final requirements as proposed for Medicaid will
apply to those programs rather than separate provisions for the CHIP
program. In this final rule, we make explicit that the Medicaid
requirements at Sec. Sec. 431.60, 431.61, and 431.80 apply to the
Medicaid expansion CHIP programs rather than the separate CHIP
requirements at Sec. Sec. 457.730, 457.731, and 457.732.
Comment: A commenter stated that most states have operating
Medicaid expansion CHIP programs and that the provisions outlined in
the proposed rule would apply to most states.
Response: We agree with this commenter and as stated, are
confirming that Medicaid requirements apply equally to Medicaid
expansion CHIP programs.
5. Final Action
After consideration of the comments received, and for the reasons
discussed in the CMS Interoperability and Prior Authorization proposed
rule and our responses to those comments (as summarized), we are
finalizing our proposal to allow for state Medicaid and CHIP FFS
programs and QHP issuers on the FFEs to apply for certain extensions,
exemptions, or exceptions for the Provider Access, Payer-to-Payer and/
or Prior Authorization APIs. We are also finalizing our proposal
regarding Medicaid Expansion CHIP programs.
We are finalizing the policy to allow state Medicaid and CHIP FFS
programs

[[Page 8909]]

to apply for an extension to the deadline from the requirements to
implement the Provider Access, Payer-to-Payer, and/or Prior
Authorization APIs. Specifically, we are finalizing that states may
request a one-time, 1-year extension as part of their annual APD for
MMIS operations expenditures before the compliance dates. The written
extension request must include the following: (1) a narrative
justification describing the specific reasons why the state cannot
satisfy the requirement(s) by the compliance dates, and why those
reasons result from circumstances that are unique to the agency
operating the Medicaid and/or CHIP FFS program; (2) a report on
completed and ongoing state activities that evidence a good faith
effort toward compliance; and (3) a comprehensive plan to meet the
requirements no later than 1 year after the compliance date. CMS will
grant an extension if the state establishes, to CMS's satisfaction,
that the request adequately establishes a need to delay implementation;
and that the state has a comprehensive plan to meet the requirements no
later than 1 year after the compliance date.
We are finalizing a policy to allow state Medicaid and CHIP FFS
programs to apply for an exemption from the requirements of the
Provider Access, Payer-to-Payer, and/or Prior Authorization APIs when
at least 90 percent of the state's Medicaid beneficiaries are enrolled
in Medicaid MCOs or when at least 90 percent of the state's separate
CHIP beneficiaries are enrolled in CHIP MCOs. We are finalizing that
the requirements for the Payer-to-Payer API to obtain beneficiaries'
permission, provide educational resources at the time of requesting
permission, and identify patients' previous/concurrent payers,
including for beneficiaries covered under managed care are not eligible
for the exemption. Specifically, we are finalizing the policy that a
state may request an exemption, as part of their annual APD for MMIS
operations expenditures before the compliance date (which may be
extended by 1 year if the state receives an extension). The exemption
request must include documentation showing that the state meets the
threshold criterion based on enrollment data from the most recent CMS
``Medicaid Managed Care Enrollment and Program Characteristics'' (for a
Medicaid FFS exemption) or enrollment data from section 5 of the most
recently accepted state submission to CHIP Annual Report Template
System (CARTS). The state must also include an alternative plan to
ensure that providers have efficient electronic access to the same
information through other means while the exemption is in effect. CMS
will grant the exemption if the state establishes, to CMS's
satisfaction, that the state meets the criteria for the exemption,
including an alternative plan to ensure efficient electronic access to
the same information through other means while the exemption is in
effect.
We are finalizing that an exemption will expire under two
scenarios. First, an exemption will expire if, based on the 3 previous
years of available, finalized Medicaid Transformed Medicaid Statistical
Information System (T-MSIS) and/or CHIP CARTS enrollment data, the
State's MCO enrollment for 2 of the previous 3 years is below 90
percent. Second, an exemption will expire if CMS approves a state plan
amendment, waiver, or waiver amendment that would significantly reduce
the percentage of beneficiaries enrolled in managed care and the
anticipated shift in enrollment is confirmed by the first available,
finalized Medicaid T-MSIS and/or CHIP CARTS enrollment data.
We are finalizing that states must provide written notification to
CMS if they no longer qualify for an approved exemption. Written
notification must be submitted to CMS within 90 days of the
finalization of the first annual Medicaid T-MSIS managed care
enrollment data and/or the CARTS report for CHIP demonstrating the
enrollment shift to below 90 percent in managed care. States must
obtain CMS approval of a timeline for compliance with the API
requirements for Medicaid FFS and/or CHIP FFS within 2 years of the
expiration of the exemption. For additional context, please refer to
the proposed rule (87 FR 76263).
In addition, we are finalizing that for states with Medicaid
expansion CHIPs, the requirements for Medicaid will apply to those
programs rather than-the provisions for separate CHIPs.
We are finalizing that an issuer applying for QHP certification may
apply for an exception from requirements of the Provider Access, Payer-
to-Payer, and/or Prior Authorization APIs. The issuer must include, as
part of its QHP application, a narrative justification describing the
reasons why the issuer cannot reasonably satisfy the requirements for
the applicable plan year, the impact of non-compliance upon providers
and enrollees, the current or proposed means of providing health
information to providers or other payers, and solutions and a timeline
to achieve compliance with the requirements. An FFE may grant an
exception to the requirements if it determines that making that
issuer's QHPs available through the FFE is in the interests of
qualified individuals in the state or states in which the FFE operates,
and an exception is warranted to permit the issuer to offer QHPs
through the FFE.
These final policies apply to state Medicaid and CHIP FFS programs
and QHP issuers on the FFEs at the CFR sections listed in Tables C1,
D1, and E4.

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

1. Background
As discussed in detail in section II.D. of this final rule, the
current prior authorization process needs improvement to reduce the
burden associated with the process itself. To facilitate those needed
improvements in the prior authorization process, we are requiring
impacted payers to implement and maintain a Prior Authorization API.
The Prior Authorization API aims to improve care coordination and
shared decision-making by enabling enhanced electronic documentation
discovery and facilitating electronic prior authorization. We believe
the Prior Authorization API will reduce administrative burden, improve
efficiency, and ensure patients promptly receive necessary medical
items and services. We also recognize that efficiencies from payer
implementation of these APIs will only be realized if they are utilized
by requesting providers to complete prior authorization requests.
Therefore, we proposed a new measure for MIPS eligible clinicians
(as defined at 42 CFR 414.1305) under the MIPS Promoting
Interoperability performance category, as well as for eligible
hospitals and CAHs under the Medicare Promoting Interoperability
Program, related to electronic prior authorization and the Prior
Authorization API (87 FR 76312-76314). We proposed the new measures,
titled ``Electronic Prior Authorization,'' to be included in the HIE
objective for the MIPS Promoting Interoperability performance category
and in the HIE objective for the Medicare Promoting Interoperability
Program. The Electronic Prior Authorization measure aims to address
concerns, specifically from commenters in response to the December 2020
Interoperability proposed rule (85 FR 82586), that few providers would
use the Prior

[[Page 8910]]

Authorization API established by impacted payers.
MIPS is authorized under section 1848(q) of the Act. As described
in sections 1848(q)(2) and (5) of the Act, we evaluate the performance
of MIPS eligible clinicians in four performance categories, which we
refer to as the quality, cost, improvement activities, and Promoting
Interoperability performance categories. Under 42 CFR 414.1375(b)(2),
MIPS eligible clinicians must report on objectives and measures as
specified by CMS for the Promoting Interoperability performance
category. We refer readers to the CY 2024 Physician Fee Schedule (PFS)
final rule (88 FR 79357-79362) for a list of the current objectives and
measures required for the MIPS Promoting Interoperability performance
category.\156\ We determine a final score for each MIPS eligible
clinician based on their performance in the MIPS performance categories
during a MIPS performance period for a year. Based on the MIPS eligible
clinician's final score, we calculate a MIPS payment adjustment (which
can be positive, neutral, or negative) that applies for the covered
professional services they furnish in the MIPS payment year which
occurs 2 years later.
---------------------------------------------------------------------------

\156\ In the proposed rule (87 FR 76312), we referred readers to
the CY 2023 PFS final rule (87 FR 70075-70080) for the then-current
list of objectives and measures. We have updated this final rule to
refer to the CY 2024 PFS final rule which includes the most recent
objectives and measures, including changes effective for the CY 2024
MIPS performance period.
---------------------------------------------------------------------------

The Medicare Promoting Interoperability Program for eligible
hospitals and CAHs is authorized in part under sections
1886(b)(3)(B)(ix) and 1814(l)(4) of the Act. Under these statutory
provisions, eligible hospitals and CAHs that are not meaningful EHR
users are subject to Medicare payment reductions. To be considered a
meaningful EHR user (as defined under 42 CFR 495.4), the eligible
hospital or CAH must demonstrate meaningful use of CEHRT by satisfying
objectives and measures as required under 42 CFR 495.24. We refer
readers to the FY 2024 Hospital Inpatient Prospective Payment System
(IPPS) and Long-Term Care Hospital (LTCH) final rule (88 FR 59269-
59277) for a summary of the currently adopted objectives and measures
for the Medicare Promoting Interoperability Program.
2. Electronic Prior Authorization
To support the policies in this final rule and maximize the
potential to improve the prior authorization process for providers and
patients, we proposed to add new measures, titled ``Electronic Prior
Authorization,'' under the HIE objective of the MIPS Promoting
Interoperability performance category and under the HIE objective of
the Medicare Promoting Interoperability Program. These measures support
the electronic exchange of health information to improve the quality of
health care, such as promoting care coordination, as described in
section 1848(o)(2)(A)(ii) of the Act with respect to MIPS eligible
clinicians, and section 1886(n)(3)(A)(ii) of the Act with respect to
eligible hospitals and CAHs.
We proposed that for purposes of the Electronic Prior Authorization
measures, a prior authorization request must be made using the Prior
Authorization API to satisfy the measure, unless the MIPS eligible
clinician, eligible hospital, or CAH could claim an applicable
exclusion. As discussed in more detail in the proposed rule (87 FR
76313) and further in this section II.F., we proposed that MIPS
eligible clinicians, eligible hospitals, and CAHs would report the
number of prior authorizations requested electronically via the Prior
Authorization API using data from their CEHRT as a numerator and
denominator, unless they could claim an applicable exclusion. We
proposed that beginning with the CY 2026 performance period/CY 2028
MIPS payment year for MIPS eligible clinicians and the CY 2026 EHR
reporting period for eligible hospitals and CAHs, a MIPS eligible
clinician, eligible hospital, or CAH that fails to report the measure
or claim an exclusion would not satisfy the MIPS Promoting
Interoperability performance category or Medicare Promoting
Interoperability Program reporting requirements. For the CY 2026
performance period/CY 2028 MIPS payment year for MIPS eligible
clinicians and the CY 2026 EHR reporting period for eligible hospitals
and CAHs, we proposed that the Electronic Prior Authorization measure
would not be scored and would not affect the total score for the MIPS
Promoting Interoperability performance category or the Medicare
Promoting Interoperability Program. In other words, for CY 2026, a MIPS
eligible clinician, eligible hospital, or CAH would be required to
report a numerator of at least one for the measure or claim an
exclusion, but the measure would not be scored. We proposed that, if
the MIPS eligible clinician or eligible hospital or CAH does not report
a numerator of at least one for the measure or claim an exclusion, they
would receive a zero score for the MIPS Promoting Interoperability
performance category or the Medicare Promoting Interoperability
Program, respectively. We noted that we intend to propose a scoring
methodology for the measure in future rulemaking.
First, we are finalizing that MIPS eligible clinicians report the
Electronic Prior Authorization measure beginning with the CY 2027
performance period/2029 MIPS payment year (rather than the CY 2026
performance period/2028 MIPS payment year), and that eligible hospitals
and CAHs report the Electronic Prior Authorization measure beginning
with the CY 2027 EHR reporting period (rather than the CY 2026 EHR
reporting period). We believe that this modification to our proposed
policy for the Electronic Prior Authorization measures will allow more
time for MIPS eligible clinicians, eligible hospitals, and CAHs to
adjust to the new electronic prior authorization workflow using the
Prior Authorization API.
Second, we are finalizing the Electronic Prior Authorization
measure with a modification such that it is structured as an
attestation (yes/no) measure, instead of a numerator and denominator
measure as originally proposed, for both MIPS eligible clinicians and
eligible hospitals and CAHs. As an attestation measure, MIPS eligible
clinicians, eligible hospitals, and CAHs will report a ``yes'' or
``no'' response or report an applicable exclusion for the Electronic
Prior Authorization measure. Instead of reporting how many times the
MIPS eligible clinician, eligible hospital, or CAH requested prior
authorization electronically via the Prior Authorization API in a
numerator and all prior authorizations in a denominator as proposed (87
FR 76313), the MIPS eligible clinician, eligible hospital, or CAH will
either submit an attestation (yes/no) regarding whether they used the
Prior Authorization API to submit at least one prior authorization
request electronically or claim an applicable exclusion to report the
modified Electronic Prior Authorization measures. We are modifying the
proposed reporting methodology to align with the modification to the
measure specifications we are finalizing, specifically reporting this
measure as an attestation yes/no response instead of a numerator and
denominator. We believe that this modification to our proposed policy
for the Electronic Prior Authorization measures will reduce burden by
not requiring MIPS eligible clinicians, eligible hospitals, and CAHs to
calculate and report a numerator and

[[Page 8911]]

denominator for the Electronic Prior Authorization measure.
Additionally, we are finalizing that the measures will not be
scored (that is, not assigned points for completion or failure).
Instead, if a MIPS eligible clinician, eligible hospital, or CAH fails
to report the measure as specified, they would not meet the minimum
reporting requirements, not be considered a meaningful EHR user, and
fail the Medicare Promoting Interoperability Program or the MIPS
Promoting Interoperability performance category. A failure in the
Medicare Promoting Interoperability Program would result in a downward
payment adjustment for eligible hospitals or CAHs (unless the eligible
hospital or CAH receives a hardship exception). A failure in the
Promoting Interoperability performance category would result in the
MIPS eligible clinician receiving a score of zero for the performance
category, which is currently worth 25 percent of their final score for
MIPS. This is consistent with our original proposal that failure to
report a numerator of at least one for the measure, or claim an
exclusion, warrants a zero score for the MIPS Promoting
Interoperability performance category and failure to meet Medicare
Promoting Interoperability Program reporting requirements (87 FR
76313).
For the MIPS Promoting Interoperability performance category,
satisfactory performance on this measure can be demonstrated only by
reporting a ``yes'' response on the attestation or claiming an
applicable exclusion. A ``no'' response on the attestation will result
in the MIPS eligible clinician failing to meet the minimum reporting
requirements, therefore not being considered a meaningful EHR user for
MIPS, as set forth in section 1848(o)(2)(A) of the Act and defined at
42 CFR 414.1305, for the MIPS payment year (42 CFR414.1305). MIPS
eligible clinicians that do not report a ``yes'' response or claim an
applicable exclusion for the Electronic Prior Authorization measure as
specified (that is, they do not submit the measure or claim an
exclusion or report a ``no'' response) will not earn a score for the
MIPS Promoting Interoperability performance category (a score of zero
for the category). A MIPS eligible clinician's score in the Promoting
Interoperability performance category is generally worth 25 percent of
their total final score for MIPS.\157\ We note that to report a
``yes,'' the action of the measure must occur during the selected
performance period \158\ or EHR reporting period,\159\ as per the
measure specifications defined below.
---------------------------------------------------------------------------

\157\ See 42 CFR 414.1375(a); 414.1380(c)(1).
\158\ See 42 CFR 414.1320.
\159\ See 42 CFR 495.40(b)(2)(i).
---------------------------------------------------------------------------

For the Medicare Promoting Interoperability Program, only a ``yes''
response on the attestation, or claiming an applicable exclusion, will
fulfill the minimum requirements of this measure. A ``no'' response
will result in the eligible hospital or CAH failing to meet the
measure, and therefore failing to meet minimum program reporting
requirements, thus not being considered a meaningful EHR user for an
EHR reporting period, as defined in section 1886(n)(3) of the Act.\160\
Eligible hospitals and CAHs that do not meet the minimum program
reporting requirements are subject to a downward payment adjustment
(unless the eligible hospital or CAH receives a hardship exception).
---------------------------------------------------------------------------

\160\ See 42 CFR 495.4; 495.24(f)(1)(i)(A).
---------------------------------------------------------------------------

The following is a summary of the comments we received on our
proposals and our responses.
Comment: Multiple commenters expressed support for our proposal to
add the Electronic Prior Authorization measure under the MIPS Promoting
Interoperability performance category for MIPS eligible clinicians and
the Medicare Promoting Interoperability Program for eligible hospitals
and CAHs to incentivize use of the Prior Authorization API among
providers. Multiple commenters agreed that it is appropriate to place
the proposed Electronic Prior Authorization measure under the HIE
objective for both the MIPS Promoting Interoperability performance
category and the Medicare Promoting Interoperability Program. Multiple
commenters noted that the Electronic Prior Authorization measure would
incentivize MIPS eligible clinicians, eligible hospitals, and CAHs to
use the Prior Authorization API capabilities to automate the prior
authorization process, which could lead to more timely delivery of
care. A commenter stated that this proposal would help ensure that
providers utilize the Prior Authorization and Provider Access APIs'
technology, in addition to promoting interoperability and the
electronic exchange of health information.
Response: We thank commenters for their feedback and support of the
proposed Electronic Prior Authorization measure under the MIPS
Promoting Interoperability performance category and the Medicare
Promoting Interoperability Program. We agree that the Electronic Prior
Authorization measure will help incentivize MIPS eligible clinicians,
eligible hospitals, and CAHs to use the Prior Authorization API to
automate the prior authorization process, which could lead to more
timely delivery of care.
Comment: Multiple commenters encouraged CMS to continue to explore
additional and alternative opportunities to foster API adoption and
utilization of electronic prior authorization tools, as well as
incentivize the adoption of the Prior Authorization API across the
industry and include a broader set of providers outside of these
incentive programs. Commenters suggested expanding the Electronic Prior
Authorization measure to other programs to reach additional provider
populations, such as the Medicare Shared Savings Program (MSSP) and
Alternative Payment Models (APMs). A commenter also recommended
implementing a pilot program as part of CMS's Primary Care First (PCF)
model. A commenter recommended that CMS should work in partnership with
ONC to implement incentives that encourage further adoption of
electronic prior authorization. Another commenter supported further
development of performance measures to encourage interoperability
enhancements and API uptake. A commenter recommended that CMS engage
with various associations to encourage further adoption. A commenter
supported industry-wide adoption of electronic prior authorization
processes but suggested that only requiring impacted payers to build
APIs would not lead to broad adoption. A commenter stated that CMS
should use every available option to influence and incentivize adoption
of these standards within the health care industry if it intends to
mandate that impacted payers participate. Commenters also acknowledged
that the provider community is an important, interested group in the
drive to enable widespread interoperability.
Response: We thank the commenters for their support and additional
recommendations on how we can incentivize using the Prior Authorization
API. We will continue to monitor and assess opportunities we can
leverage to encourage API implementation uptake. Additionally, we will
continue to collaboratively work with ONC to identify ways to
incentivize the adoption of electronic prior authorization. We believe
that establishing the Electronic Prior Authorization measure is a
viable method to begin fostering the adoption and utilization of the
Prior Authorization API by MIPS eligible

[[Page 8912]]

clinicians, eligible hospitals, and CAHs in these initiatives. We note
that nothing in the Prior Authorization API proposal we are finalizing
would prohibit providers that are not subject to MIPS or the Medicare
Promoting Interoperability Program from using the API for electronic
prior authorization as well. Where permitted under applicable law and
relevant program requirements, we encourage providers who are not
included in these programs to leverage the Prior Authorization APIs to
gain the intended benefits, such as improving efficiency and reducing
the administrative burden of prior authorization processes. We agree
that requiring impacted payers to build the APIs would not lead to
broad adoption. However, we believe that establishing the Electronic
Prior Authorization measure under both MIPS and the Medicare Promoting
Interoperability Program will help promote the implementation and use
of the Prior Authorization API by MIPS eligible clinicians, eligible
hospitals, and CAHs. In order for the industry to realize the
efficiencies of the Prior Authorization API and achieve the goals set
forth in this final rule, it is essential that both impacted payers and
providers adopt and use a Prior Authorization API.
Comment: Multiple commenters opposed adoption of the proposed
Electronic Prior Authorization measure stating that the measure would
be inefficient and burdensome, citing challenges with additional
workflow requirements, increased provider burden, and financial burden.
A commenter stated that it would potentially leave providers unfairly
penalized. Several commenters noted that the burden of reporting
outweighs the benefits of use and that hospital IT resources are
already overloaded and limited. Other commenters noted that mandating
the Electronic Prior Authorization measure could further increase
provider burden and detract from patient care, directing MIPS eligible
clinicians, eligible hospitals, and CAHs' attention away from patients.
A commenter stated that the Electronic Prior Authorization measure
proposal is unlikely to provide significant relief to providers (that
is, MIPS eligible clinicians, eligible hospitals, and CAHs). Another
commenter stated that payers should compensate providers fairly for the
cost of each prior authorization for the implementation of costly and
burdensome electronic prior authorization requirements. This commenter
stated that each prior authorization is a net financial loss for
practices. Another commenter recommended that the Electronic Prior
Authorization measure should remain optional until a time when the
benefit, both monetarily and in reduced administrative burden, can be
quantified for a calculated return on investment.
Response: We appreciate the feedback provided by commenters and
note that we believe the benefit of the Prior Authorization API will
outweigh the burden of implementation. We refer readers to the
Collection of Information (COI) requirements in section III. of this
final rule regarding burden and the regulatory impact analysis (RIA) we
conducted in section IV. of this final rule for the additional
information on the cost calculations of this Electronic Prior
Authorization measure for MIPS eligible clinicians reporting for the
MIPS Promoting Interoperability performance category and for eligible
hospitals and CAHs reporting for the Medicare Promoting
Interoperability Program. We acknowledge that there is an initial
implementation and data collection burden associated with the
Electronic Prior Authorization measure. However, we believe that the
benefits of using an electronic prior authorization process outweigh
the burdensome manual process used today. We believe that making the
prior authorization process electronic will improve the time and burden
associated with the current process, allowing providers to put time
back into direct patient care, and ultimately will reduce provider
burnout. We emphasize that we are implementing requirements for both
impacted payers and providers (that is, MIPS eligible clinicians,
eligible hospitals, and CAHs) to help streamline the prior
authorization process because both payers and providers have a role to
play in this process and the solution cannot be one-sided. As discussed
further in this section, in order to address concerns regarding the
burden of the Electronic Prior Authorization measure on MIPS eligible
clinicians, eligible hospitals, and CAHs, we are modifying the measure
to be an attestation (yes/no) measure rather than a numerator and
denominator measure. Therefore, data collection to report a numerator
and denominator for the Electronic Prior Authorization measure is no
longer required.
Comment: A commenter cautioned that the Electronic Prior
Authorization measure for the MIPS Promoting Interoperability
performance category would reflect data regarding a different
population than other MIPS measures, stating that other measures in
MIPS are designed to capture information about the Medicare beneficiary
population specifically. The commenter stated that this would make
these measures difficult to compare. Another commenter stated that the
Electronic Prior Authorization measure proposed for the MIPS Promoting
Interoperability performance category does not apply to Medicare FFS,
which results in misalignment.
Response: We thank the commenters for their feedback. First, we
disagree that the Electronic Prior Authorization measure will reflect
data regarding a different population than other MIPS measures. We note
that all of the MIPS Promoting Interoperability performance category
measures are based on using CEHRT, utilizing data that are captured in
the CEHRT, and require submission of applicable data, regardless of
payer. The Electronic Prior Authorization measure is consistent with
other measures reported under the MIPS Promoting Interoperability
performance category.
Second, although Medicare FFS is not an impacted payer, we refer
readers to section I.D.1. of this final rule where we discuss CMS's
intent to align Medicare FFS to the requirements of this final rule, as
applicable. Although, generally, the policies in this final rule do not
directly pertain to Medicare FFS, we want to ensure that Medicare
beneficiaries, as well as other individuals, can benefit from these
policies, regardless of their coverage, delivery system, or payer.
Comment: A commenter stated that, if CMS does move forward with the
proposed Electronic Prior Authorization measure for the MIPS Promoting
Interoperability performance category, CMS should consider exempting
small, rural, and underserved practices from reporting the Electronic
Prior Authorization measure, which would redistribute the Promoting
Interoperability performance category's weight to other performance
categories. A few commenters suggested that the inclusion of the
Electronic Prior Authorization measure would have a disproportionately
adverse effect on small business entities, federally recognized
American Indian and Alaska Native-Tribal communities, psychiatric
practices, and other specialties and could contribute to the electronic
divide.
Response: We thank commenters for their feedback and would like to
note that there are a number of situations in which MIPS eligible
clinicians may qualify for reweighting of the MIPS Promoting
Interoperability performance category. This includes policies
implemented in our regulations at 42 CFR part 414, subpart O, including
42

[[Page 8913]]

CFR 414.1380(c)(2), if they have a special status (defined at 42 CFR
414.1305), are a qualifying clinician type, or have a CMS-approved
significant hardship or other exception application. For example, MIPS
eligible clinicians in small practices (fifteen or fewer MIPS eligible
clinicians) may have the MIPS Promoting Interoperability performance
category reassigned a weight of zero percent automatically in the event
the MIPS eligible clinician in a small practice (as verified by CMS on
an annual basis) does not submit any data for any of the measures in
that category as provided at 42 CFR 414.1380(c)(2)(i)(C)(9), and
therefore would not be required to meet the MIPS Promoting
Interoperability performance category's requirements including
reporting on this Electronic Prior Authorization measure (86 FR 65485-
65487). If the MIPS Promoting Interoperability performance category is
reweighted to zero percent as provided at 42 CFR 414.1380(c)(2)(i), the
category's 25 percent weight will be redistributed to the remaining
MIPS performance categories in accordance with 42 CFR
414.1380(c)(2)(ii).
Comment: Multiple commenters opposed the proposed addition of the
Electronic Prior Authorization measure. Commenters believed that the
finalization of the Electronic Prior Authorization measure would not be
necessary because MIPS eligible clinicians, eligible hospitals, and
CAHs would be prompted to voluntarily adopt and use the Prior
Authorization API if the API achieves the goal of streamlining the
prior authorization process, which likely would reduce provider burden,
improve prior authorization processing time, and enable more timely
access to care. Multiple commenters expressed that they do not believe
that the proposed Electronic Prior Authorization measure would address
concerns about low provider utilization of APIs, especially for small,
rural providers, due to cost, limited bandwidth, and lack of dedicated
health IT staff. A commenter expressed that they do not believe that
the inclusion of the Electronic Prior Authorization measure would be a
sufficient incentive for MIPS eligible clinicians, eligible hospitals,
and CAHs to overcome the costs associated with the transaction. Some
commenters stated that, as electronic prior authorization becomes more
common and affordable, providers would be incentivized to adopt this
process, which promises to free up resources and allow providers to
spend more time on patient care. A commenter stated that providers will
be naturally incentivized to engage in electronic prior authorization
processes if the processes lower costs, carry a minimal burden, do not
cause unreasonable delays in care, and lead to care that is in their
patients' best interests. Another commenter stated that the proposal to
add a measure on conducting electronic prior authorization for items or
services using the Prior Authorization API is not sufficient to
encourage robust use of the Prior Authorization API by providers and
stated that the proposals will be a one-sided mandate on impacted
payers.
Response: We appreciate the commenters' feedback and are glad to
hear that providers likely would be naturally incentivized and prompted
to voluntarily adopt and use the Prior Authorization API if the API
achieves the goal of streamlining the prior authorization process,
which we believe it will. However, based on experience with adoption of
other similar new EHR technology, we believe there needs to be an
initial drive to encourage all parties involved (payers and providers)
to develop, implement, and use the new Prior Authorization API to
support widespread adoption, thus reaping the benefits of burden
reduction through the electronic prior authorization processes. We
understand and agree that the Electronic Prior Authorization measure
itself may not be enough to address concerns about low provider
utilization of APIs, particularly for small and rural providers.
However, we believe the improvement and benefits in the prior
authorization processes resulting from using the Prior Authorization
API, specifically, may encourage such providers to adopt the API to
help streamline existing paper-based or portal-based processes.
We acknowledge that small, rural providers may have limited
bandwidth and fewer dedicated IT staff. We note that implementing an
electronic prior authorization process could free up resources and
allow providers to spend more time on patient care, which can be a
challenge for small, rural providers. We also note that MIPS eligible
clinicians in small practices (fifteen or fewer MIPS eligible
clinicians) may have the MIPS Promoting Interoperability performance
category reassigned a weight of zero percent automatically in the event
the MIPS eligible clinician in a small practice (as verified by CMS on
an annual basis) does not submit any data for any of the measures in
that category as provided at 42 CFR 414.1380(c)(2)(i)(C)(9), and
therefore would not be required to meet the category's requirements
including reporting on this Electronic Prior Authorization measure (86
FR 65485-65487). We believe that using electronic prior authorization
processes will benefit small, rural providers, and small practices in
underserved communities who are able to implement and maintain the
Prior Authorization API in their processes with by saving time, faster
turnaround on prior authorization requests, and, in turn, improved
patient satisfaction.
Comment: A commenter requested that CMS calculate the additional
cost of compliance with the MIPS requirements generally and consider
what benefit MIPS reporting offers when practices already have a great
interest in lowering their expenses related to prior authorization.
Response: We appreciate the commenter's feedback regarding cost of
the Electronic Prior Authorization measure and refer readers to the RIA
we conducted in section IV. of this final rule for the additional
information on the cost calculations of this Electronic Prior
Authorization measure for MIPS eligible clinicians reporting for the
MIPS Promoting Interoperability performance category and for hospitals
and CAHs reporting for the Medicare Promoting Interoperability Program.
We note that the cost of compliance and benefits of reporting for MIPS
as a whole are outside the scope of this rule. We will continue to
evaluate use of the Prior Authorization API and assess whether the
Electronic Prior Authorization measure has achieved its goal of
promoting widespread Prior Authorization API adoption.
Comment: Multiple commenters acknowledged that the proposed
Electronic Prior Authorization measure is not directed toward the
impacted payers. A commenter stated that CMS should collect prior
authorization data from payers to measure their performance rather than
from providers. Another commenter noted that the electronic prior
authorization proposal does not assess any financial costs against
payers to discourage their overuse of prior authorizations.
Response: We thank the commenters for their feedback and
acknowledge that this Electronic Prior Authorization measure is not
intended to incentivize payers to use the Prior Authorization API. For
more information about the Prior Authorization API requirements for
payers, we refer readers to section II.D. of this final rule.
To reiterate, the success of the Prior Authorization API is
dependent upon both payers and providers using the Prior Authorization
API. We want to stress the importance of both payers and providers
using the Prior Authorization

[[Page 8914]]

API to ensure that all parties can experience the maximum benefits of
engaging in the electronic prior authorization process. Thus, we
recognize the importance of not only requiring impacted payers to
build, implement, and maintain the API, but also to drive MIPS eligible
clinicians, eligible hospitals, and CAHs to use it.
We agree that collecting prior authorization data from payers is
important and provides accountability for using prior authorization
processes. As such, we are finalizing our proposal to require payers to
publicly report certain prior authorization metrics. We refer readers
to section II.D. of this final rule for further information on these
requirements for impacted payers.
We note that prior authorization is an established administrative
process used by payers to help control costs and ensure payment
accuracy by verifying that an item or service is medically necessary,
meets coverage criteria, and is consistent with standards of care
before the item or service is provided. The policies we are finalizing
are not intended to discourage the use of prior authorization, nor do
they impose direct financial repercussions for using prior
authorization by payers. The policies we are finalizing in this final
rule are intended to streamline the existing prior authorization
process.
Comment: Multiple commenters noted that the adoption of the
Electronic Prior Authorization measure contradicts CMS's goal of
reducing provider burden and urged CMS not to replace one type of
administrative burden with another. Another commenter cautioned that
the proposed Electronic Prior Authorization measure is not suitable for
a quality improvement program given that the focus is on technological
capability. A commenter stated that measures related to prior
authorization conflict with the goal of MIPS to improve quality of
health care, stating there is no evidence to indicate that prior
authorization improves outcomes.
Response: We disagree that the Electronic Prior Authorization
measure conflicts with our goals and believe the policies we are
finalizing in this rule are necessary to support a more efficient prior
authorization process in the future. We believe this measure is
entirely suitable for MIPS since the goal of MIPS is to provide
financial incentives to clinicians that provide high-value and high-
quality care to Medicare patients. MIPS supports care improvements by
focusing on better patient outcomes and decreasing clinician burden. We
believe that electronic prior authorization aligns with these goals, as
it streamlines a historically burdensome process to allow providers to
spend more time focused on improving patient outcomes instead of
administratively burdensome processes.
We also believe that the Electronic Prior Authorization measure
fits within the goals of the Medicare Promoting Interoperability
Program and the MIPS Promoting Interoperability performance category by
enhancing the meaningful use of CEHRT. For the MIPS Promoting
Interoperability performance category, section 1848(q)(2)(B)(iv) of the
Act requires MIPS eligible clinicians to report on specified measures
and activities demonstrating that they meet the requirements
established under section 1848(o)(2) of the Act for determining whether
the MIPS eligible clinician is a meaningful EHR user. For the Medicare
Promoting Interoperability Program, section 1886(n) of the Act
similarly requires eligible hospitals and CAHs to demonstrate that they
meet requirements established under section 1886(n)(3)(A) (which align
with section 1848(o)(2)(A) of the Act) for determining whether the
eligible hospital or CAH is a meaningful EHR user. Electronic exchange
of information to improve health care and care coordination is a
central statutory requirement for both the Medicare Promoting
Interoperability Program and the MIPS Promoting Interoperability
performance category.
We proposed this measure under sections 1848(o)(2)(A)(ii) and
1886(n)(3)(A)(ii) of the Act for MIPS and the Medicare Promoting
Interoperability Program, respectively, because we believed, and
continue to believe, this measure will further enable the electronic
exchange of health information to improve the quality of health care
(87 FR 76312). More specifically, we believe the proposed Electronic
Prior Authorization measure, which we are finalizing with
modifications, is fundamental to determining whether a MIPS eligible
clinician, eligible hospital, or CAH meets criterion two of being a
meaningful EHR user: demonstrating that their CEHRT is connected in a
manner that provides for the electronic exchange of health information
to improve the quality of health care, such as promoting care
coordination (sections 1848(o)(2)(A)(ii) and 1886(n)(3)(A)(ii) of the
Act). We believe the Electronic Prior Authorization measure is another
means by which MIPS eligible clinicians, eligible hospitals, and CAHs,
can use their health IT to timely and efficiently share key health
information with payers to obtain prior authorizations promptly and
thereby provide necessary health care to their patients expeditiously.
Therefore, we believe the Electronic Prior Authorization measure does
meet the intended goal of these programs to promote interoperability
and electronically exchange health information.
Comment: Multiple commenters opposed the Electronic Prior
Authorization measure stating that prior authorizations are a harmful
practice that result in delays and denials of necessary care which can
worsen a patient's condition. Several commenters shared concerns about
payer prior authorization policies themselves. A commenter stated that
prior authorizations lower the costs for payers but raise the overall
cost of care by delaying care and shifting costs to providers and
patients, thus worsening clinical outcomes which necessitates the
escalation of more expensive care.
Response: We would like to thank commenters for their feedback
regarding payers' prior authorization processes and the burden placed
on patients and providers. We understand that some commenters expressed
concerns about prior authorization itself, regardless of whether it
could be completed electronically, and whether or not these existing
prior authorization requirements support improved outcomes. We note
that the existence and use of prior authorization processes is outside
the scope of this rule. Our policies are limited to streamlining this
already existing process.
The policies we are finalizing in this rule are not intended to
encourage or discourage the prior authorization requirements that
payers already have; these policies are intended to increase the
efficiency of these existing requirements and processes by encouraging
use of electronic methods. We understand that the existing prior
authorization process can be burdensome, and thus believe the policies
we are finalizing in this rule are necessary to support a more
efficient prior authorization process in the future.
We received many comments on the December 2020 CMS Interoperability
proposed rule, which has since been withdrawn, and in response to the
CMS Interoperability and Prior Authorization proposed rule that
indicated that prior authorization processes could be improved by
electronic, interoperable data exchange. Those comments have informed
the policies we are finalizing in this rule.
Comment: Multiple commenters stated that the Electronic Prior
Authorization measure should not penalize LTCHs and Inpatient
Rehabilitation Facilities (IRFs) for

[[Page 8915]]

failing to use EHRs. Another commenter expressed that practices have
many different technical and infrastructure capabilities; therefore,
they recommended that CMS consider ways to further engage and support
all provider types--especially safety-net, small/independent, and/or
rural health providers--to adopt and use the Prior Authorization API.
The commenter continued by stating that they are concerned that these
providers are at risk of being left behind. Likewise, the commenter
stated that CMS should also explore ways to expand provider incentives
to reach broadly across the health care system to encourage widespread
adoption of the Prior Authorization API. Another commenter recommended
that CMS include all health care providers as recipients of the
benefits of the final rule, whether they are recipients of Meaningful
Use dollars or are participants in MIPS. The commenter continued by
providing a possible scenario in which payers further delay decisions
of excluded providers in favor of meeting the requirements for
providers included under the provisions of the rule.
Response: We note that LTCHs and IRFs are not included in the
definition of an eligible hospital or CAH (42 CFR 495.4 definitions, 75
FR 44327) and therefore would not be required to report the Electronic
Prior Authorization measure under the Medicare Promoting
Interoperability Program.\161\ We also understand that different
practices have different technical and infrastructure capabilities. To
the extent that these facilities or any provider type ordering items or
services requiring prior authorizations have access to appropriate
health IT and the Prior Authorization API and are otherwise permitted
to use the Prior Authorization API, we encourage them to use this
technology for their own benefit. Our proposals for the Prior
Authorization API technology and functionality do not limit its use to
participants under the MIPS Promoting Interoperability performance
category and the Medicare Promoting Interoperability Program. We will
continue to look for ways to encourage API implementation uptake and
ways to incentivize the adoption of electronic prior authorization
across additional programs and provider types, especially safety-net,
small/independent, and rural health providers.
---------------------------------------------------------------------------

\161\ Centers for Medicare and Medicaid Services (2023,
September 6). Medicare Promoting Interoperability Program:
Eligibility Hospital Information. Retrieved from https://www.cms.gov/Regulations-and-Guidance/Legislation/EHRIncentivePrograms/Eligibility-#BOOKMARK2.
---------------------------------------------------------------------------

Additionally, we appreciate the comment regarding possible
scenarios in which impacted payers further delay decisions on prior
authorizations from providers not participating in MIPS or the Medicare
Promoting Interoperability Program or not using the Prior Authorization
API. However, to mitigate this, we are finalizing certain prior
authorization decision timeframes for all impacted payers. We refer
readers to section II.D. of this final rule for more information on the
prior authorization decision timeframe provisions.
Comment: A commenter suggested that instead of developing the
Electronic Prior Authorization measure, CMS should engage in stringent
oversight to ensure that impacted payers are not only developing and
implementing a Prior Authorization API but are also implementing all of
the provisions of this final rule. The commenter also suggested that
CMS should release additional information on how it will enforce the
proposed requirements contained in the CMS Interoperability and Prior
Authorization proposed rule to ensure compliance.
Response: As explained in the proposed rule, and in the CMS
Interoperability and Patient Access final rule, each program oversees
compliance under existing program authorities and responsibilities.
These compliance processes vary among programs and may have different
implications based on a payer's status in the program, previous
compliance actions, and corrective action. Patients and providers
should submit an inquiry or complaint to the appropriate program,
depending on their coverage as described in section I.D.2. of this
final rule. Compliance questions or complaints about compliance may be
sent to the respective program contact at the website or email address
provided there. Compliance will be tracked through specific methods
managed by the programs. While these compliance efforts will help payer
compliance, as we have stated repeatedly throughout this section, it is
imperative that both payers and providers come together to use the
Prior Authorization API to ensure that all parties can experience the
maximum benefits of engaging in the electronic prior authorization
process. Thus, we recognize the importance of not only requiring
impacted payers to build the Prior Authorization API, but also to
incentivize MIPS eligible clinicians, eligible hospitals, and CAHs to
use it through the finalization of this Electronic Prior Authorization
measure.
Comment: A commenter stated that CMS lacks a legitimate
justification for imposing the new Electronic Prior Authorization
measure, as it does not align with the legal requirements under section
1848(q) of the Act. The commenter sought clarification on how the
proposed measure complies with the governing regulations.
Response: We have authority under section 1848(q)(2)(A)(iv) and
(B)(iv) of the Act, which requires that we assess MIPS eligible
clinicians' performance with respect to their meaningful use of CEHRT
in accordance with the requirements established in section 1848(o)(2)
of the Act. We also have authority under section 1848(q)(2)(B)(iv) of
the Act to create new measures under the MIPS Promoting
Interoperability performance category as well as for determining
whether an eligible professional is a meaningful EHR user in accordance
with the requirements established in section 1848(o)(2) of the Act.
Connecting to the API technology identified in the Electronic Prior
Authorization measure helps to facilitate bi-directional data exchange
electronically and can significantly reduce the burden associated with
the prior authorization processes for providers using data from CEHRT
when accessing the Prior Authorization API. This type of function
demonstrates meaningful use of CEHRT and is therefore appropriate in
assessing whether a MIPS eligible clinician is a meaningful EHR user
under section 1848(o)(2)(A) of the Act.
Comment: A commenter requested that CMS use its authority to permit
payers to include quality measures tied to use of the APIs in the
provider contracts.
Response: We appreciate the commenter's recommendation. However, we
leave this decision--whether payers require measures like this for
their providers and how they work with their providers on using the
Prior Authorization API--up to the discretion of the payers.
a. Measure Specifications
In the proposed rule (87 FR 76313), we proposed the following
specifications for the Electronic Prior Authorization measure: \162\
---------------------------------------------------------------------------

\162\ 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.''

---------------------------------------------------------------------------

[[Page 8916]]

1. For MIPS Eligible Clinicians Under the MIPS Promoting
Interoperability Performance Category--Electronic Prior Authorization
Measure Description: For at least one medical item or
service (excluding drugs) ordered by the MIPS eligible clinician during
the performance period, the prior authorization is requested
electronically from a Prior Authorization API using data from CEHRT.
The MIPS eligible clinician would be required to report a numerator
and denominator for the measure or (if applicable) report an exclusion:
Denominator: The number of unique prior authorizations
requested for medical items and services (excluding drugs) ordered by
the MIPS eligible clinician during the performance period, excluding
prior authorizations that cannot be requested using the Prior
Authorization API because the payer does not offer an API that meets
the Prior Authorization API requirements outlined in section II.D.3.a.
of the CMS Interoperability and Prior Authorization proposed rule.
Numerator: The number of unique prior authorizations in
the denominator that are requested electronically from a Prior
Authorization API using data from CEHRT.
Exclusion: Any MIPS eligible clinician who:
(1) Does not order any medical items or services (excluding drugs)
requiring prior authorization during the applicable performance period;
or
(2) Only orders medical items or services (excluding drugs)
requiring prior authorization from a payer that does not offer an API
that meets the Prior Authorization API requirements outlined in section
II.D.3.a. of the CMS Interoperability and Prior Authorization proposed
rule during the applicable performance period.
2. For Eligible Hospitals and Critical Access Hospitals Under the
Medicare Promoting Interoperability Program--Electronic Prior
Authorization
Measure Description: For at least one hospital discharge
and medical item or service (excluding drugs) ordered during the EHR
reporting period, the prior authorization is requested electronically
via a Prior Authorization API using data from CEHRT.
The eligible hospital or CAH would be required to report a
numerator and denominator for the measure or (if applicable) report an
exclusion:
Denominator: The number of unique prior authorizations
requested for medical items and services (excluding drugs) ordered for
patients discharged from the eligible hospital or CAH inpatient or
emergency department (POS code 21 or 23) during the EHR reporting
period, excluding prior authorizations that cannot be requested using
the Prior Authorization API because the payer does not offer an API
that meets the Prior Authorization API requirements outlined in section
II.D.3.a. of the proposed rule.
Numerator: The number of unique prior authorizations in
the denominator that are requested electronically from a Prior
Authorization API using data from CEHRT.
Exclusions: Any eligible hospital or CAH that--
++ Does not order any medical items or services (excluding drugs)
requiring prior authorization during the applicable EHR reporting; or
++ Only orders medical items or services (excluding drugs)
requiring prior authorization from a payer that does not offer an API
that meets the Prior Authorization API requirements outlined in section
II.D.3.a. of the proposed rule during the applicable EHR reporting
period.
Comment: Multiple commenters expressed support for CMS's proposal
regarding the proposed Electronic Prior Authorization measure's
numerator and denominator criteria. Specifically, a commenter agreed
with the numerator being the number of unique prior authorizations that
are requested electronically via a Prior Authorization API using data
from CEHRT if the Electronic Prior Authorization measure includes
electronic prior authorizations from commercial payers. A commenter
recommended that CMS ask for the percentage of prior authorization
requests that are not being completed through the Prior Authorization
API. Another commenter supported CMS's proposal to include prior
authorization requests that are made using fax, mail, or portal in the
denominator of the Electronic Prior Authorization measure unless the
prior authorization cannot be requested using the Prior Authorization
API because the payer does not offer an API that meets the Prior
Authorization API requirements, in which case it would be excluded from
the denominator. A commenter expressed support for CMS progressing the
proposed Electronic Prior Authorization measure to a performance-based
measure in future years.
Response: We thank the commenters for their feedback and appreciate
their support for the numerator and denominator criteria for the
Electronic Prior Authorization measure for the MIPS Promoting
Interoperability performance category and the Medicare Promoting
Interoperability Program. We agree that requiring participants to
report a numerator and denominator for the measure would ultimately
give us the most insight into the degree of adoption and use of the
Prior Authorization API. However, after consideration of comments
received, and as discussed in more detail later in this section, we are
modifying the specifications of the Electronic Prior Authorization
measure to require an attestation (yes/no), in lieu of reporting data
for a numerator and denominator as proposed, for this measure beginning
with the CY 2027 performance period/2029 MIPS payment year for MIPS and
the CY 2027 EHR reporting period for the Medicare Promoting
Interoperability Program.
Comment: A commenter suggested that CMS explore different
mechanisms for tracking electronic prior authorization requests. A few
commenters also noted that tracking these data elements should be the
responsibility of payers, as they would have this information more
easily accessible. Another commenter stated that CMS needs to determine
an approach to measure the usage of electronic prior authorization
tools that does not require collecting information about the
availability of corresponding APIs or functionality. Another commenter
stated that measuring the success of these policies should not be
punitive for providers and that the metrics of success should exist for
all stakeholders. Multiple commenters urged CMS to work with the
provider community, as well as other stakeholders, on various aspects
of the Electronic Prior Authorization measure as well as other prior
authorization reforms to identify ways to incentivize provider uptake
without creating unnecessary provider burden and determine how to
engage providers in the testing and development of the proposed
Electronic Prior Authorization measure. Another commenter noted that
the technology supporting electronic prior authorization must be widely
available and demonstrated to be effectively integrated into EHR
workflows through real-world testing prior to requiring MIPS eligible
clinicians, eligible hospitals, and CAHs to report on use of the Prior
Authorization API for the Electronic Prior Authorization measure. A
commenter suggested that CMS should require payers to provide these
data on electronic prior authorization, rather than place increasing
demands on providers.

[[Page 8917]]

Response: We thank the commenters for their recommendations. We
will consider exploring additional mechanisms for tracking electronic
prior authorization requests in future rulemaking. We believe that
tracking the use of electronic prior authorization processes by
impacted payers and providers (that is, MIPS eligible clinicians,
eligible hospitals, and CAHs) is important to ensure widespread
implementation and use of the Prior Authorization API by both user
groups. In this context, we view the Electronic Prior Authorization
measure not merely as a way to track performance or success. Instead,
we view this measure as a way for MIPS eligible clinicians, eligible
hospitals, and CAHs to adopt and use the electronic Prior Authorization
APIs implemented by payers. As we have noted previously, payers
impacted by this rule are required to implement and maintain the Prior
Authorization API. To fully recognize the benefits and efficiencies of
payer implementation of this API, we need to encourage providers to use
said API to complete prior authorization requests. While we are
encouraged by commenters' statements that the benefits of the Prior
Authorization API are enough to encourage providers to use it, we also
believe that accessing this API using data from CEHRT demonstrates
meaningful use of CEHRT that can improve patient care under sections
1848(o)(2)(A) and 1886(n)(3)(A) of the Act, and thus believe this
measure is appropriate to incentivize providers to adopt and use this
technology. We refer readers to section II.D. of this rule where we
discuss in further detail the metrics impacted payers will be required
to report on electronic prior authorizations.
We note that we do not currently use established workgroups to test
and develop measures for the Medicare Promoting Interoperability
Program or the MIPS Promoting Interoperability performance category
outside of our annual call for measures.\163\ We do work with members
of the provider community in HL7 workgroups to obtain their feedback
during the development and testing phases of the IGs that support the
Prior Authorization API, as well as during discussions around technical
workflow. We encourage providers to engage in the HL7 FHIR workgroup
meetings to get involved in the standards development and
implementation discussions for specific use cases. The IGs are also
tested during Connectathons and throughout the IG development lifecycle
and refined based on testing and implementation feedback. We have also
previously reviewed public comments received on the Reducing Burden and
Improving Electronic Information Exchange of Prior Authorizations RFI
(85 FR 82639) and December 2020 CMS Interoperability proposed rule (85
FR 82586) regarding ways in which we could incentivize and encourage
provider use of the electronic Prior Authorization API and used that
feedback to develop our policies outlined in this final rule.
---------------------------------------------------------------------------

\163\ Centers for Medicare and Medicaid Services. (2023,
September 6). Annual Call For Measures. Retrieved from https://www.cms.gov/Regulations-and-Guidance/Legislation/EHRIncentivePrograms/CallForMeasures.
---------------------------------------------------------------------------

Comment: Multiple commenters expressed their disapproval of the
proposed Electronic Prior Authorization measure's numerator and
denominator criteria. Numerous commenters stated that the Electronic
Prior Authorization measure as proposed would create significant data
collection and reporting burden on MIPS eligible clinicians, eligible
hospitals, CAHs, and support staff. Many commenters specifically
identified the excessive burden with calculating the denominator.
Multiple commenters expressed concern regarding identifying which prior
authorization requests meet the denominator requirements of the
proposed Electronic Prior Authorization measure (for example, which
payers offer a Prior Authorization API or how a provider will be able
to determine the number of prior authorization requests that should be
counted in the denominator) making this measure particularly
burdensome, contributing to provider burnout, and causing further
delays in care. A commenter sought clarification on whether CMS is
considering alternatives to the proposed numerator and denominator
measure criteria and requested changes to these specifications that
would reduce the implementation burden for both providers and health IT
developers.
Some commenters expressed concern regarding compliance and
documentation for the proposed Electronic Prior Authorization measure.
Commenters stated that providers submit prior authorizations in a
variety of modalities and noted it will be hard to track all prior
authorizations submitted. Other commenters expressed similar concerns
given that data surrounding prior authorizations are captured outside
of an EHR, which would make the data collection process extremely
burdensome.
Several commenters urged CMS not to implement the Electronic Prior
Authorization measure as proposed due to these concerns or consider
ways the measure could be implemented without increasing provider
burden. A commenter recommended that CMS continue to evaluate the
numerator and denominator proposals and adjust the requirements based
on real-world testing. Another commenter questioned why CMS would
create a numerator/denominator measure that is not automatically
calculated by EHRs. The commenter continued by stating that several EHR
vendors will likely not have the capability to assist in tracking prior
authorization requests for reporting purposes. Another commenter
disagreed with the proposed measure criteria to collect information on
the total number of prior authorization requests submitted by the Prior
Authorization API versus other request methods given that collecting
these data does nothing to improve patient clinical outcomes.
Therefore, multiple commenters recommended that CMS should use an
attestation (yes/no) measure and remove the proposed numerator/
denominator criteria.
Response: We appreciate the commenters sharing their concerns
regarding the burden associated with calculating a numerator and
denominator as proposed for the Electronic Prior Authorization measure.
Generally, we proposed that to report these measures, MIPS eligible
clinicians, eligible hospitals, and CAHs must use data from their CEHRT
to request prior authorization from a payer for at least one medical
item or service (excluding drugs), and, for eligible hospitals and
CAHs, one hospital discharge and medical item or service that they
ordered via the Prior Authorization API (87 FR 76313). However, we
recognize that the challenge of consistently calculating a numerator
and denominator for these proposed measures across providers increases
if providers are accessing the Prior Authorization API in different
ways. We further recognize that it would be challenging for MIPS
eligible clinicians, eligible hospitals, and CAHs to report a numerator
and denominator for these measures as we proposed until such time as
the ONC Health IT Certification Program establishes health IT
certification criteria to support standardized exchange via the Prior
Authorization API and adopts updated certification criteria supporting
numerator and denominator calculation.
We acknowledge that modifying the Electronic Prior Authorization
measure to be attestation-based would substantially reduce the
reporting burden placed on MIPS eligible clinicians, eligible
hospitals, and CAHs.

[[Page 8918]]

With an attestation-based yes/no measure, those providers would be
required to report a yes/no response, rather than a numerator and
denominator, to indicate whether they used a Prior Authorization API to
submit at least one electronic prior authorization during the
applicable performance period/MIPS payment year or EHR reporting
period. After consideration of this feedback, and as discussed in more
detail later in this section, we are modifying the Electronic Prior
Authorization measure to be an attestation measure, meaning that MIPS
eligible clinicians, eligible hospitals, and CAHs will report a yes/no
response for the measure. We will continue to explore ways to move
toward numerator and denominator reporting for future years of the
measure, particularly should ONC Health IT Certification Program
criteria be made available to support certification of EHRs to the
capability associated with tracking prior authorizations requested
electronically via the Prior Authorization API using data from CEHRT.
Comment: A commenter stated that the Electronic Prior Authorization
measure should not be restricted only to items and services but should
also include drugs to provide consistency across prior authorization
needs.
Response: As discussed earlier in this final rule, the Prior
Authorization API requirements we have finalized for impacted payers
are limited to medical items and services (excluding drugs). Therefore,
for consistency, we are aligning using the API for the Electronic Prior
Authorization measure to limit it to evaluating using a Prior
Authorization API for medical items and services authorization requests
only. We refer readers to section II.D. for additional information on
the Prior Authorization API requirements for impacted payers and the
exclusion of drugs.
Comment: A commenter stated that industry would need to review and
endorse the specification criteria prior to requiring the Electronic
Prior Authorization measure.
Response: We thank commenters for this suggestion; however, we must
note that there is no requirement for industry to review or endorse
measures in either the MIPS Promoting Interoperability performance
category or the Medicare Promoting Interoperability Program. We welcome
comments from any interested parties through public comment during
rulemaking, and also during the annual call for measures for the MIPS
Promoting Interoperability performance category and the Medicare
Promoting Interoperability Program, every summer.
Comment: Multiple commenters expressed concern that MIPS eligible
clinicians, eligible hospitals, and CAHs will not have the necessary
health IT to support the Prior Authorization API and therefore will not
be able to report the proposed Electronic Prior Authorization measure
by the proposed implementation year of CY 2026. Multiple commenters
urged CMS to delay mandating the proposed Electronic Prior
Authorization measure until adequate standards and specifications are
available to support electronic prior authorization, the Prior
Authorization API is implemented, and workflow is established. A
commenter stated that providers should have the flexibility to stage
their adoption, as recognized in the Electronic Prior Authorization
measure proposal, to support a smooth transition from the current,
manual process to a fully electronic workflow. Another commenter
suggested that CMS needs to provide eligible hospitals with adequate
time to convert their current processes into an electronic prior
authorization process prior to implementing the Electronic Prior
Authorization measure under the Medicare Promoting Interoperability
Program. The commenter expressed their concern that this transition to
a new electronic process will allow cases to fall through the cracks.
Response: We thank the commenters for their feedback. After
reviewing comments for both the Prior Authorization API and for using
that API in this Electronic Prior Authorization measure, we
reconsidered our proposal and agree that provision of additional time
for implementation would be beneficial. As previously discussed, we
understand that there may be challenges with the availability of health
IT to calculate a measure numerator and denominator consistently for
the Electronic Prior Authorization measures as we originally proposed.
We also believe the functionality of the Prior Authorization API should
be in place and used by hospitals and providers prior to requiring a
numerator and denominator be reported. We will continue to work with
ONC to explore the adoption of standards and health IT certification
criteria where appropriate to streamline data exchange, support
interoperability, and increase efficiencies associated with the
policies in this final rule. As noted previously, the Unified Agenda,
current at the time of this final rule's publication, includes an entry
for a proposed rule from ONC (RIN 0955-AA06). The description indicates
that that proposed rule aims to advance interoperability, including
proposals to expand the use of certified APIs for electronic prior
authorization.\164\
---------------------------------------------------------------------------

\164\ Office of Information and Regulatory Affairs (2023,
November). Health Data, Technology, and Interoperability: Patient
Engagement, Information Sharing, and Public Health Interoperability.
Retrieved from https://www.reginfo.gov/public/do/eAgendaViewRule?pubId=202304&RIN=0955-AA06.
---------------------------------------------------------------------------

As previously discussed, we are finalizing the Electronic Prior
Authorization measure with modification, to delay implementation for a
year later than originally proposed, beginning with CY 2027 performance
period/2029 MIPS payment year for MIPS eligible clinicians in the MIPS
Promoting Interoperability performance category, and beginning with the
CY 2027 EHR reporting period for eligible hospitals and CAHs under the
Medicare Promoting Interoperability. This modification also aligns with
the finalized compliance dates in 2027 for the Prior Authorization API.
Also, as previously discussed, we are finalizing the Electronic Prior
Authorization measure with modification as an attestation (yes/no)
measure, instead of requiring reporting of data for a numerator and
denominator. We believe this modification will minimize data collection
and reporting burden for this measure.
Comment: Many commenters recommended that the Electronic Prior
Authorization measure be an attestation (yes/no) measure to mitigate
provider burden if CMS moves forward with the proposed measure. Some
commenters stated that they are not opposed to the Electronic Prior
Authorization measure and appreciated CMS not scoring it initially.
However, a commenter noted there may be implementation challenges due
to eligible hospitals and CAHs still recovering from the PHE and not
having enough resources to implement. Another commenter suggested that
the Electronic Prior Authorization measure remain unscored
indefinitely. The commenter noted that the Prior Authorization API
still being in the pilot testing phase is an additional challenge.
Another commenter expressed their appreciation for the implementation
timeline of the Electronic Prior Authorization measures stating that it
would allow for technical implementation, provider implementation, and
education. Multiple commenters were displeased with the proposed
scoring methodology for the Electronic Prior Authorization measure.
Multiple commenters recommended that CMS consider making the Electronic
Prior

[[Page 8919]]

Authorization measure voluntary or award bonus points for the proposed
Electronic Prior Authorization measure rather than including the
measure in the composite score. A commenter stated that an attestation
(yes/no) measure would align the proposed Electronic Prior
Authorization measure with the other measures within the HIE objective.
Response: We appreciate the commenters' concerns and
recommendations on ways to ease burden by making the Electronic Prior
Authorization measure an attestation (yes/no) measure. We agree and
acknowledge that it would significantly reduce the reporting burden for
MIPS eligible clinicians, eligible hospitals, and CAHs if we did not
require a numerator and denominator to be calculated, and instead
require only a ``yes'' or ``no'' response be reported to indicate
whether the Prior Authorization API was used for at least one prior
authorization during the applicable performance period/MIPS payment
year or EHR reporting period. After consideration of this feedback, and
as discussed in more detail elsewhere in this section, we are modifying
the proposed Electronic Prior Authorization measure to be reported as
an attestation (yes/no) measure.
We appreciate the commenters' recommendations for scoring this
measure, such as not scoring the measure or only assigning bonus
points. However, we respectfully disagree with these approaches. First,
we did not propose to score this measure by assigning points (for
example, between 10 and 30 points for successful completion as provided
at 42 CFR 414.1380(b)(4)(ii) for MIPS). However, we did propose that a
MIPS eligible clinician, eligible hospital, or CAH would ``receive a
zero score for the MIPS Promoting Interoperability performance category
or the Medicare Promoting Interoperability Program'' if they did not
``report a numerator of a least one for the measure or claim an
exclusion'' (87 FR 76313). In other words, we proposed that if a MIPS
eligible clinician, eligible hospital, or CAH failed to request at
least one prior authorization electronically via the Prior
Authorization API using data from their CEHRT, as would be required to
report a numerator under the originally proposed measure specifications
(attesting ``no'' to the measure), or claim an applicable exclusion,
then they would not meet the minimum reporting requirements, not be
considered a meaningful EHR user, and fail the Medicare Promoting
Interoperability Program or the Promoting Interoperability performance
category. A failure in the Medicare Promoting Interoperability Program
would result in a downward payment adjustment for eligible hospitals or
CAHs (unless the eligible hospital or CAH receives a hardship
exception). A failure in the MIPS Promoting Interoperability
performance category would result in the MIPS eligible clinician
receiving a score of zero for the performance category, which is
currently worth 25 percent of their final score for MIPS.
Second, we clarify our rationale for proposing this scoring policy
of zero for this measure, which we are finalizing with modification to
align with the attestation-based measure specifications we are
finalizing in this section. Fundamentally, a MIPS eligible clinician,
eligible hospital, or CAH must demonstrate it is a meaningful EHR user
by meeting three statutory criteria set forth in sections 1848(o)(2)(A)
and 1886(n)(3)(A) of the Act, to earn a score for the MIPS Promoting
Interoperability performance category (section 1848(q)(2)(B)(iv) of the
Act) or avoid a downward payment adjustment for the Medicare Promoting
Interoperability Program. We proposed this measure under sections
1848(o)(2)(A)(ii) and 1886(n)(3)(A)(ii) of the Act for MIPS and
Medicare Promoting Interoperability Program, respectively, because we
believed, and continue to believe, this measure would further enable
the electronic exchange of health information to improve the quality of
health care (87 FR 76312). More specifically, we believe the proposed
Electronic Prior Authorization measure, which we are finalizing with
modification, is fundamental to determining whether a MIPS eligible
clinician, eligible hospital, or CAH meets criterion two of being a
meaningful EHR user: demonstrating that their CEHRT is connected in a
manner that provides for the electronic exchange of health information
to improve the quality of health care, such as promoting care
coordination (sections 1848(o)(2)(A)(ii) and 1886(n)(3)(A)(ii) of the
Act). A MIPS eligible clinician, eligible hospital, or CAH using the
Prior Authorization API to request at least one prior authorization
electronically for, or claiming an applicable exclusion from, reporting
this measure, fundamentally demonstrates that they are a meaningful EHR
user. Therefore, we believe that failure to report the Electronic Prior
Authorization measure as specified, or to claim an applicable
exclusion, demonstrates they are not a meaningful EHR user and warrants
the MIPS eligible clinician, eligible hospital, or CAH receiving a
score of zero for the MIPS Promoting Interoperability performance
category or Medicare Promoting Interoperability Program.
After consideration of public comments we received, we are
finalizing a modification to our proposal that the Electronic Prior
Authorization measure will require MIPS eligible clinicians, eligible
hospitals, and CAHs to report a numerator and denominator, and instead,
require that MIPS eligible clinicians, eligible hospitals, and CAHs
attest ``yes'' or ``no'' to having performed at least one electronic
prior authorization using the Prior Authorization API, or claim an
applicable exclusion. We are also finalizing that, if a MIPS eligible
clinician, eligible hospital, or CAH attests ``no'' or fails to claim
an applicable exclusion for this measure, then they will receive a zero
score for the MIPS Promoting Interoperability performance category
(currently worth 25 percent of their final score for MIPS) or fail to
meet Medicare Promoting Interoperability Program reporting
requirements. To allow for additional implementation time, we are
finalizing inclusion of the Electronic Prior Authorization measure in
the MIPS Promoting Interoperability performance category beginning with
the CY 2027 performance period/2029 MIPS payment year and in the
Medicare Promoting Interoperability program beginning with the CY 2027
EHR reporting period.
Comment: Some commenters expressed concerns that providers may be
unfavorably evaluated or unfairly penalized for infrastructure and
system issues or lack of capabilities and not the providers'
willingness or desire to conduct electronic prior authorizations. A
commenter requested clarification on the proposed measure exclusion
criteria applying only to medical items and services (excluding drugs)
requiring prior authorization from a payer that does not offer a Prior
Authorization API, questioning whether this exclusion would lead to
unintended consequences.
Response: We recognize that these capabilities may not yet be
widely adopted in some settings, and that successful implementation of
these capabilities may vary across providers and systems. We note that
we are finalizing that the Electronic Prior Authorization measure would
be reported as an attestation (yes/no) measure, as opposed to the
proposed numerator and denominator, which should reduce some of the
initial implementation challenges. We are also finalizing that the
measure would first be reportable beginning with the CY

[[Page 8920]]

2027 performance period/2029 MIPS payment year and CY 2027 EHR
reporting period. This delayed implementation will give both providers
(that is, MIPS eligible clinicians, eligible hospitals, and CAHs) and
payers time to implement these changes to workflows and establish
integrations prior to the measure reporting being required.
We believe electronic prior authorization capabilities represent an
important investment that will benefit providers, patients, and other
health care system entities. We note that some payers do not fall under
the definition of impacted payers in this final rule. Therefore, we are
finalizing the measure's exclusion criterion (excluding MIPS eligible
clinicians, eligible hospitals, and CAHs that only order medical items
or services [excluding drugs] requiring prior authorization from a
payer that does not offer an API that meets the Prior Authorization API
requirements finalized in this final rule) because we do not want to
penalize MIPS eligible clinicians, eligible hospitals, or CAHs for
ordering medical items or services (excluding drugs) from payers that
do not have the API functionality for reasons such as not being an
impacted payer.
Comment: A commenter stated that they oppose measures that could
negatively impact a MIPS eligible clinician's score, such as the
current all-or-nothing scoring methodology used to score the MIPS
Promoting Interoperability performance category. Another commenter
stated their belief that the proposed rule lacks detail on how the
Electronic Prior Authorization measure will be scored and tied into the
broader scoring of the Medicare Promoting Interoperability Program for
eligible hospitals and CAHs.
Response: We note that the overall scoring methodology for MIPS
Promoting Interoperability performance category is not being changed
with the addition of the Electronic Prior Authorization measure, nor
the scoring methodology for the HIE measure itself. As discussed
previously in this section, we believe that failure to report the
Electronic Prior Authorization measure as specified, or to claim an
applicable exclusion, demonstrates that the MIPS eligible clinicians is
not a meaningful EHR user and warrants the MIPS eligible clinician
receive a score of zero for the MIPS Promoting Interoperability
performance category. While we understand that the all-or-nothing
approach requires MIPS eligible clinicians to report and attest to all
requirements, we note that requiring the Electronic Prior Authorization
measure is in alignment with our scoring policies and methodologies.
Our regulation at 42 CFR 414.1375(b) provides that, to earn a score for
the MIPS Promoting Interoperability performance category, the MIPS
eligible clinician must report on objectives and associated measures as
specified by CMS.
For additional information on overall MIPS scoring policies and
MIPS Promoting Interoperability performance category scoring policies,
we refer readers to our regulations at 42 CFR 414.1375 (governing the
requirements for the MIPS Promoting Interoperability performance
category), 42 CFR 414.1380 (governing scoring for MIPS), as well as
Table 46: Scoring Methodology for the Performance Period in CY 2024 for
the Promoting Interoperability performance category in the CY 2024 PFS
final rule (88 FR 52587). For information on the overall scoring
methodology currently used to calculate MIPS final scores, we refer
readers to the MIPS Final Score Methodology section in the CY 2024 PFS
final rule (88 FR 52591).
To be considered a meaningful EHR user, fulfill the minimum
reporting requirements, and avoid a downward payment adjustment, the
Medicare Promoting Interoperability Program requires that eligible
hospitals and CAHs meet, by reporting on or attesting to, all
objectives and measures selected by CMS. Failure to meet the minimum
reporting requirements results in failure of the Medicare Promoting
Interoperability Program, subjecting the eligible hospital or CAH to a
downward payment adjustment (unless the eligible hospital or CAH
receives a hardship exception).
b. Prior Authorization API Functionality
In the proposed rule (87 FR 76313), we proposed that a prior
authorization request must be made using the Prior Authorization API to
satisfy the Electronic Prior Authorization measure. The Prior
Authorization API functionality is outlined in further detail in
section II.D.2. of this final rule. We proposed that prior
authorization requests that are made using fax, mail, or portal would
be included in the denominator of the measure unless the prior
authorization cannot be requested using the Prior Authorization API
because the payer does not offer an API that meets the Prior
Authorization API requirements, in which case any such prior
authorization request would be excluded from the denominator. Instances
where a payer offering the Prior Authorization API specifically
requests a mailed or faxed prior authorization would be included in the
denominator. Prior authorization requests that are made using fax,
mail, or portal would not be included in the numerator of the measure
because these methods would not incentivize using the standards-based
API functionality as intended by the measure. Prior authorizations for
any and all drugs would be excluded from both the numerator and
denominator of the measure. (For a more detailed discussion of the
exclusion of drugs, see section I.C. of this final rule.)
We proposed that only prior authorizations that are requested
electronically via a Prior Authorization API using data from CEHRT
would be included in the numerator. Using the API to query
documentation requirements alone, and not to request the prior
authorization, would not count in the numerator or denominator.
To satisfy the Electronic Prior Authorization measure, the health
care provider uses data from their CEHRT (such as patient demographics
and medical information) to justify the prior authorization request.
The Prior Authorization API then automates the HIPAA-compliant prior
authorization request. Additional information not contained in CEHRT
may also be required for submission.
Comment: Multiple commenters urged CMS to delay mandating the
proposed Electronic Prior Authorization measure until adequate
standards and specifications are available to support electronic prior
authorization and until the Prior Authorization API workflow is
established. A commenter urged CMS to evaluate whether sufficient
implementation guidance exists to support automating data retrieval
before moving to require the Electronic Prior Authorization measure in
future years. Some commenters noted that CMS must ensure that the
desired standards outlined in the Electronic Prior Authorization
measure specification are achievable. Another commenter recommended
that CMS make all IGs required for payers so the burden is not placed
on providers to figure out something that will be incredibly difficult
and resource-intensive to do. Another commenter recommended that CMS or
ONC should issue an IG to ensure there is standardization of
implementation across payers. The commenter stated that IGs could
reduce payer variability in the creation of the Prior Authorization
API. Another commenter sought clarification on how it will be feasible
for CEHRT to implement an API-based prior authorization functionality
to support performance measurement if payers are not required to adhere
to standardized IGs. The commenter stated that for this to occur
seamlessly CEHRT standards

[[Page 8921]]

would need to be updated appropriately.
Response: We thank the commenters for sharing their
recommendations. We are working with HL7, the HL7 FHIR accelerator
workgroups, and interested parties within the standards development
industry to move the IGs towards greater maturity by defining technical
specifications, participating in and convening testing events for them,
and developing and maintaining the technical specifications. Electronic
prior authorization using a FHIR API has been implemented and is in
production, proving sufficient implementation guidance exists. We agree
that IGs help to ensure standardization of implementation across the
industry. In section II.G. of this final rule, we outline the required
standards and technical specifications necessary to build the Prior
Authorization API and to ensure that implementation is consistent
across all impacted payers and providers to avoid unnecessary
duplication of efforts. We have also recommended certain IGs to help
providers and payers meet that requirement. These IGs are developed
using a consensus process involving many members of the payer and
provider communities. They aid in the implementation process of the
APIs. We anticipate that payers will use the recommended IGs so that
most, if not all, providers benefit from a standardized approach to
accessing patient data with all payers with whom they contract. Our
approach in the proposed rule of recommending, but not requiring, the
specific IGs for each API implementation was to provide directional
guidance with flexibility to the industry without locking implementers
into the versions available at the time of the proposed rule. As
industry moves forward with implementation of these policies and use of
these standards, industry can continue to harmonize on common
approaches that work, eventually culminating in a required set of
specifications when ready.
Comment: A commenter recommended that CMS explain that the
electronic prior authorization workflow does not necessarily need to be
completed by the provider and that such workflows do not necessarily
need to be included in CEHRT. The commenter recommended that CMS
emphasize that only using data from CEHRT as part of the process for
requesting prior authorization via a payer's Prior Authorization API is
sufficient to meet the Electronic Prior Authorization measure. Another
commenter suggested that CMS should consider not limiting the
Electronic Prior Authorization measure to only data relevant to a prior
authorization that is obtained from an EHR as relevant prior
authorization data may not be limited to the provider's EHR alone. A
commenter stated that certain health insurance data, clinical data, and
other administrative data subject to follow-up requests or initial
submissions may exist in non-EHR systems in use. The commenter stated
that this further underscores the premise that any health IT developer
wishing its health IT to be certified must support all USCDI in its
health IT. The commenter stated that USCDI as a driver to enable
standards-based exchange is increasingly less relevant and, instead,
the various IGs would indicate what participating systems should
support. A commenter requested clarification on the expectations for
incorporating such workflows into the Medicare Promoting
Interoperability Program. The commenter sought clarification on whether
eligible hospitals are expected to begin to share prior authorization
information via the integrations with HINs to meet the bi-directional
HIE measure. Multiple commenters encouraged the use of HIEs to connect
impacted payers and providers to facilitate electronic prior
authorization. A commenter stated that HIEs could provide support for
continuing to connect providers and payers, including for the purposes
of prior authorization. Another commenter recommended that CMS should
include an optional, alternative measure that allows MIPS eligible
clinicians, eligible hospitals, and CAHs to claim a Promoting
Interoperability credit by attesting to using a HIE/HIN to request a
prior authorization. Another commenter recommended that CMS create a
health IT activity as part of the HIE Objective for mapping to a Prior
Authorization API that is measured by the transmission of at least one
prior authorization through the Prior Authorization API.
Response: We did not propose, and are not finalizing, details of a
specific workflow, or by whom, that must be completed to report the
Electronic Prior Authorization measure beyond specifying that data from
CEHRT must be used for the transaction with a Prior Authorization API.
CMS recognizes that, under the Electronic Prior Authorization measure
that we are finalizing in this rule, MIPS eligible clinicians, eligible
hospitals, and CAHs may utilize different workflows to submit an
electronic prior authorization request. As noted, the Unified Agenda,
current at the time of publication of this final rule, includes an
entry for a proposed rule from ONC entitled ``Health Data, Technology,
and Interoperability: Patient Engagement, Information Sharing, and
Public Health Interoperability'' (RIN 0955-AA06). The description for
this proposed rulemaking notes that this rule aims to advance
interoperability through proposals for the expanded use of certified
APIs for electronic prior authorization, among other proposals.\165\ We
plan to continue to explore how potential future updates to the ONC
Health IT Certification Program can support our policies and will
address any updates to our requirements related to these future updates
to the ONC Health IT Certification Program criteria if finalized, in
future rulemaking. In reference to the USCDI, we note that health IT
modules may be certified to only one or a few certification criteria
that do not reference the USCDI standard, and therefore are not all
required to support USCDI.
---------------------------------------------------------------------------

\165\ Office of Information and Regulatory Affairs (2023,
November). Health Data, Technology, and Interoperability: Patient
Engagement, Information Sharing, and Public Health Interoperability.
Retrieved from https://www.reginfo.gov/public/do/eAgendaViewRule?pubId=202304&RIN=0955-AA06.
---------------------------------------------------------------------------

With regard to workflows, there is no requirement under the MIPS
Promoting Interoperability performance category or the Medicare
Promoting Interoperability Program that a specific individual person
must request prior authorization electronically via the Prior
Authorization API to meet requirements of the Electronic Prior
Authorization measure. Instead, it can be someone who legally can enter
information into the medical record in accordance with applicable laws
and professional guidelines. Regarding the measure's specifications, we
emphasize that data must come from the CEHRT, as use of CEHRT is a
required element of both the MIPS Promoting Interoperability
performance category and the Medicare Promoting Interoperability
Program. However, additional data outside of CEHRT may also be used in
addition to support the interaction with a Prior Authorization API.
Regarding the USCDI, we note that this standard is referenced in
many of the IGs recommended for these use cases, however, the relative
utility, in the abstract, of USCDI as a standard adopted for use in
certified health IT and cross referenced in certain ONC Health IT
Certification Program criteria is outside the scope of this final rule.
We also note that we did not propose and are not finalizing a
requirement under the MIPS Promoting

[[Page 8922]]

Interoperability performance category or the Medicare Promoting
Interoperability Program to share prior authorization information via
the integrations with HINs to meet the Bi-Directional HIE measure.
Additionally, we thank commenters for their recommendations on
additional measures to promote electronic prior authorization. CMS
reiterates that to meet the requirements of the Electronic Prior
Authorization measure, the electronic prior authorization must use a
Prior Authorization API as finalized in this rule. CMS agrees that
using HIEs and other HINs could help to facilitate sharing of prior
authorization information. Nothing in the Electronic Prior
Authorization measures we are finalizing would restrict using such
networks as long as the payer's Prior Authorization API is used for the
electronic prior authorization.
Comment: A commenter sought clarification on whether a provider
must implement capabilities to connect to all parts of the Prior
Authorization API for full automation of the electronic prior
authorization processing in order to claim numerator credit. Another
commenter questioned whether a provider meets the numerator criteria if
they use the Prior Authorization API that does not meet all the
capabilities outlined in the recommended HL7 Da Vinci CRD, DTR, and PAS
IGs. Another commenter requested clarification regarding whether a MIPS
eligible clinician using the Prior Authorization API to submit a prior
authorization request is not required to use all capabilities (that is,
CRD, DTR, and PAS) in order to meet the numerator qualification, but
rather that, at a minimum, the PAS IG request is used.
Response: We thank the commenters for their feedback and note that
we are finalizing this measure with modification to no longer require
MIPS eligible clinicians, eligible hospitals, and CAHs to report a
numerator and denominator for the measure. Instead, we are finalizing
this measure to require MIPS eligible clinicians, eligible hospitals,
and CAHs to attest a ``yes'' or ``no'' response for the measure or
claim an applicable exclusion. In order to attest ``yes,'' for at least
one medical item or service (excluding drugs) and, for eligible
hospitals and CAHs, for one hospital discharge ordered during the
performance period or EHR reporting period, a prior authorization
request must be submitted to a payer using a Prior Authorization API.
We note that to report a ``yes,'' the action of the measure must occur
during the selected performance period \166\ or EHR reporting
period,\167\ as per the measure specification. The Prior Authorization
API is discussed in more detail in section II.D. of this final rule,
and we note that the submission of the prior authorization request
itself is described through the recommended PAS IG.
---------------------------------------------------------------------------

\166\ See 42 CFR 414.1320.
\167\ See 42 CFR 495.40(b)(2)(i).
---------------------------------------------------------------------------

Comment: Some commenters stated that certain EHR systems are more
sophisticated than others and could track Prior Authorization API
activity, while other hospitals and providers lack this technology. A
commenter sought clarification on how a provider can use their EHR to
identify situations where the prior authorization cannot be requested
via a payer's Prior Authorization API for the purposes of performance
measurement. A commenter stated that some provider systems do not
support one or more payer APIs due to slight differences in structure,
interpretation, or both, which could result in the provider being
penalized due to an EHR system's lack of capability and not the
provider's lack of desire to use the Prior Authorization API. A
commenter noted that the Electronic Prior Authorization measure would
be counterproductive to ONC's strategy of reducing burden related to
using health IT and EHRs and that there should be near-zero reporting
burden. Multiple commenters noted that there will be technical and
financial challenges with adopting an electronic prior authorization
process. Some commenters recommended that CMS should provide financial
and technical assistance/training to providers to adopt and implement
the technology requirements. The commenter noted that some provider
types, such as physical therapists, are ineligible to participate in
the Medicare and Medicaid EHR Incentive Programs and have received
little guidance on using EHR systems. A commenter stated that CMS
should acknowledge the significant financial and administrative risk
providers face when purchasing EHR systems in the context of MIPS. A
commenter noted that many health IT vendors currently charge separately
for electronic prior authorization functionality and the cost
associated with purchasing these functionalities has been a substantial
barrier to adoption for many small and independent practices, as well
as rural hospitals. Some commenters noted the financial burden
associated with using APIs and that practices must first be able to
affordably adopt this technology before a new requirement is
established for its use.
Response: We acknowledge there will be variability in EHR
technology capabilities to track Prior Authorization API activity. As
noted previously, for this reason and to reduce reporting burden, we
are finalizing the Electronic Prior Authorization measure as an
attestation (yes/no) measure. As noted, ONC has sought comment on how
updates to the ONC Health IT Certification Program could support
electronic prior authorization (87 FR 3475). We also note that the
Unified Agenda, current at the time of publication of this final rule,
has been updated to include an entry for a proposed rule from ONC (RIN
0955-AA06) that includes proposals for the expanded use of certified
APIs for electronic prior authorization.\168\ We will monitor these
developments in order to inform updates to the Electronic Prior
Authorization measure in the future, for instance, requiring reporting
of a numerator and denominator.
---------------------------------------------------------------------------

\168\ Office of Information and Regulatory Affairs (2023,
November). Health Data, Technology, and Interoperability: Patient
Engagement, Information Sharing, and Public Health Interoperability.
Retrieved from https://www.reginfo.gov/public/do/eAgendaViewRule?pubId=202304&RIN=0955-AA06.
---------------------------------------------------------------------------

While we acknowledge there may be costs associated with
implementing functionality needed to interact with a payer's Prior
Authorization API, as well as add-on costs charged by health IT vendors
for adding these features, we believe that the benefits of the
technology outweigh the costs. We also remind readers that this
attestation (yes/no) measure would not be included under the Medicare
Promoting Interoperability Program and the MIPS Promoting
Interoperability performance category until the CY 2027 performance
period/2029 MIPS payment year and CY 2027 EHR reporting period. We
believe extending the inclusion of the Electronic Prior Authorization
measure to the CY 2027 performance period/2029 MIPS payment year for
MIPS eligible clinicians and the CY 2027 EHR reporting period for
eligible hospitals and CAHs will allow participants in these programs
to work with health IT vendors to adopt and implement functionality
that can facilitate the actions needed to satisfy the Electronic Prior
Authorization measure.
As far as technical assistance, CMS does host CMS and HL7 FHIR
Connectathons, which are free for interested parties to attend, as well
as provides educational webinars with overviews of the technical
requirements

[[Page 8923]]

in the CMS Interoperability and Patient Access final rule and proposed
requirements in the CMS Interoperability and Prior Authorization
proposed rule. Additional public resources also exist through HL7, such
as HL7 FHIR Connectathons, HL7 website resources, and HL7 FHIR
workgroup meetings. CMS believes that using the EHR systems, and
training for staff using them, is up to each practice or hospital
system to ensure occurs.
CMS also is aware that the initial incentive programs (that is, the
Medicare and Medicaid EHR Incentive Programs) supported EHR adoption
for only certain provider types and the challenges that brings for
certain provider types that were not originally eligible for this
funding. CMS continues to evaluate ways to support providers that may
lag in health IT adoption.
Comment: A commenter requested that CMS establish requirements for
impacted payers to publish their API endpoints for the Prior
Authorization API or provide information on where to find the APIs and
make information concerning how to connect to them conspicuously
available for third-party app developers and for providers through
their public websites similar to what is asked of certified health IT
developers of API functions as a part of their basis of CEHRT under 45
CFR 170.315(g)(10).
Response: We understand that a directory of impacted payers'
digital endpoints would be highly beneficial to facilitate the Prior
Authorization API. Without such a directory, payers would need to
discover other payers' endpoints one by one, and each payer would have
to maintain a list of payers with whom they have previously connected.
Therefore, we are committing to exploring an NDH that contains payers'
digital endpoints before the 2027 compliance dates for the Prior
Authorization API, which could allow providers to easily access those
APIs and thereby facilitate electronic prior authorization, as
discussed in this final rule. Further details about the NDH structure,
requirements, and timing will be released if and when they become
available.
Comment: A commenter discussed the X12 standards and expressed that
they do not believe that the inclusion of the Electronic Prior
Authorization measure would be a sufficient incentive for MIPS eligible
clinicians, eligible hospitals, and CAHs to overcome the costs
associated with the transaction. Multiple commenters recommended that
CMS should include the usage of the X12 278 standard in the numerator
of the proposed measures. A commenter noted organizations that have
standardized usage of the X12 standard may find this effective and
efficient. The commenter stated that requiring these groups to
transition to the Prior Authorization API to meet the measure
requirements would be disruptive and burdensome. Another commenter
recommended CMS use a single standard if CMS would like to incorporate
the Electronic Prior Authorization measure. A commenter also
recommended that CMS provide guidance on the role of HIPAA
administrative transaction standards.
Response: We thank the commenters for their feedback; however, we
do not agree that the X12 278 standard is appropriate for the numerator
of the proposed Electronic Prior Authorization measure because of its
persistent and historically low utilization. While the CAQH efficiency
index report is more reflective of payer and vendor uptake of the HIPAA
standards, it does include some provider information.\169\ In the last
four reporting years, the utilization of the X12 278 transaction has
not exceeded 21 percent. Comments from reporting submitters (for the
CAQH Index) indicate that providers do not use the X12 278 because it
does not include the data elements they need for complete processing,
and many payers are still not supporting it. Thus, to consider using
that standard as the numerator, knowing the utilization rates are low,
would not seem appropriate. We believe the benefit of moving towards a
standardized electronic prior authorization process that leverages FHIR
outweighs the initial implementation cost and burden of the transition.
We will continue coordinating with colleagues across CMS and other
Federal agencies on all ways that that HIPAA administrative transaction
standards could impact our policies. We also note that we are
finalizing a modification to our proposal to no longer require
reporting of a numerator and denominator for this measure, as discussed
in more detail throughout this section.
---------------------------------------------------------------------------

\169\ Coalition for Affordable Quality Healthcare (2022). The
CAQH Index Report. Retrieved from https://https://www.caqh.org/insights/caqh-index-report.
---------------------------------------------------------------------------

c. Measure Exclusions
In the proposed rule (87 FR 76314), we proposed that MIPS eligible
clinicians, eligible hospitals, or CAHs that do not order any medical
items or services (excluding drugs) requiring prior authorization
during the applicable performance period or EHR reporting period could
claim an exclusion for the Electronic Prior Authorization measure. We
also proposed that MIPS eligible clinicians, eligible hospitals, or
CAHs that only order medical items or services (excluding drugs)
requiring prior authorization from a payer that does not offer an API
that meets the Prior Authorization API requirements outlined in section
II.D.2. of this final rule (that is, payers not subject to this
regulation or impacted payers that are non-compliant with the Prior
Authorization API requirements outlined in section II.D.2. of this
final rule), during the applicable performance period/MIPS payment year
or EHR reporting period, could claim an exclusion for the Electronic
Prior Authorization measure. As an alternative to this proposal, we
considered whether MIPS eligible clinicians, eligible hospitals, and
CAHs that request a small number of prior authorizations, such as five
prior authorizations during the performance period/EHR reporting
period, should also be able to claim the exclusion. We sought public
comment on the alternative we considered and whether another minimum
number of prior authorization requests would be appropriate for the
exclusion. Given the previously discussed limitations of the current
prior authorization process, we believe that all MIPS eligible
clinicians, eligible hospitals, and CAHs (as well as their patients and
the payers they request prior authorization from) would benefit from
using the electronic process described here, regardless of how often
they request prior authorization. Therefore, we believe that no minimum
number of prior authorization requests, other than zero, would be a
reasonable threshold for claiming an exclusion for the Electronic Prior
Authorization measure.
Comment: A few commenters stated that if a payer insists on faxing
or other means of communication, CMS should consider treating this
scenario as the basis for exclusion from the Electronic Prior
Authorization measure versus still having authorizations impacted by
such a requirement of a payer included in the denominator. A commenter
stated that some practitioners do not have enough prior authorization
requests or the necessary technology to support electronic prior
authorization, and suggested the exclusion should be based on not only
quantity but also on technical capability of those who do not submit a
high volume of prior authorization requests. The commenter encouraged
CMS to consider alternative exclusion criteria, such as the technical

[[Page 8924]]

capability of those who do not submit a high volume of prior
authorization requests. The commenter continued by stating that CMS
should not penalize providers for failing to use EHRs for this purpose
of electronic prior authorization if they either do not have enough
requests or if the technology they use does not support this
capability.
Response: We appreciate commenters' recommendations and feedback
that some providers may not have enough prior authorization requests or
the necessary technology to support electronic prior authorization. We
believe that all MIPS eligible clinicians, eligible hospitals, and CAHs
(as well as their patients and the impacted payers they request prior
authorization from) would benefit from using the electronic prior
authorization process described in this final rule. We also note that
the modified version of the Electronic Prior Authorization measure
being finalized in this rule only requires reporting of ``at least
one'' medical item or service (excluding drugs) ordered during the
performance period/MIPS payment year or EHR reporting period. We
believe this is achievable for all MIPS eligible clinicians, eligible
hospitals, and CAHs who make any prior authorization requests in a
given year. For those who do not have any prior authorization requests,
we are finalizing our exclusion as proposed. MIPS eligible clinicians,
eligible hospitals, and CAHs who do not order any medical items or
services (excluding drugs) requiring prior authorization during the
applicable performance period/MIPS payment year or EHR reporting period
would be able to report that they qualify for the exclusion for the
Electronic Prior Authorization measure.
We acknowledge that EHR technology may not consistently support
interactions with the Prior Authorization APIs at this time, and as
discussed in further detail elsewhere in this section, we will continue
to work with ONC on potential ONC Health IT Certification Program
criteria that would support the Electronic Prior Authorization measure.
For this reason, we are finalizing this measure for the MIPS Promoting
Interoperability performance category beginning with the CY 2027
performance period/2029 MIPS payment year and for the Medicare
Promoting Interoperability Program beginning with the CY 2027 EHR
reporting period.
d. Office of the National Coordinator for Health Information Technology
Health IT Certification Program
As described previously, ONC previously sought comment through an
RFI titled ``Electronic Prior Authorization Standards, Implementation
Specifications, and Certification Criteria'' (87 FR 3475), which
appeared in the January 24, 2022, issue of the Federal Register, on how
updates to the ONC Health IT Certification Program could support
electronic prior authorization. Since then, the Unified Agenda has been
updated to include a proposed rule from ONC (RIN 0955-AA06) that aims
to advance interoperability through proposals for the expanded use of
certified APIs for electronic prior authorization, among other
proposals.\170\ We plan to continue to explore how potential updates to
the ONC Health IT Certification Program could support our policies and
will address any updates to our requirements related to future updates
to the ONC Health IT Certification Program, if finalized, in future
rulemaking.
---------------------------------------------------------------------------

\170\ Office of Information and Regulatory Affairs (2023,
November). Health Data, Technology, and Interoperability: Patient
Engagement, Information Sharing, and Public Health Interoperability.
Retrieved from https://www.reginfo.gov/public/do/eAgendaViewRule?pubId=202304&RIN=0955-AA06.
---------------------------------------------------------------------------

e. Other Considerations
We invited public comment on considerations and alternatives
related to the Electronic Prior Authorization measure. For example, we
sought comment on the proposed numerator and denominator of the
Electronic Prior Authorization measure or any changes to the
specifications that would reduce the implementation burden for both
impacted providers (MIPS eligible clinicians, eligible hospitals, and
CAHs) and health IT developers. We also sought comment on challenges
that MIPS eligible clinicians, eligible hospitals, and CAHs might face
in identifying those payers that have the Prior Authorization API
technology to accurately include eligible prior authorization requests
in the denominator. Additionally, we sought comment on challenges MIPS
eligible clinicians, eligible hospitals, and CAHs could face in
performing the actions included in the Electronic Prior Authorization
measure specifications if certification criteria are not available in
the ONC Health IT Certification Program at the time MIPS eligible
clinicians, eligible hospitals, and CAHs are required to report the
Electronic Prior Authorization measure under the Medicare Promoting
Interoperability Program or MIPS Promoting Interoperability performance
category.
We received many comments in response to our request for comment.
We thank commenters for their feedback as we consider any future
rulemaking, including collaboration with ONC as appropriate.
Comment: Multiple commenters opposed the proposed Electronic Prior
Authorization measure because of the lack of health IT certification
criteria to ensure EHRs communicate with payers through Prior
Authorization API. Multiple commenters expressed concern about the
inclusion of the Electronic Prior Authorization measure due to possible
technical challenges and the lack of health IT that has the capacity to
support electronic prior authorization. Multiple commenters encouraged
CMS to focus on ensuring that the proposed APIs are implemented and
supported by CEHRT to make sure they are successfully implemented
within the provider's workflow rather than developing a measure related
to electronic prior authorization.
Several commenters noted that ONC has not established health IT
certification criteria to support electronic prior authorization in
such technologies. Multiple commenters suggested various alternative
timeframes for CMS to consider. A commenter recommended that CMS
require payers to make the Prior Authorization API available to
providers no later than 12 months following the publication of this
final rule. Another commenter suggested a compliance date 12 months
after the implementation of the Prior Authorization API or 36 months
following publication of this final rule, whichever is later. Another
commenter requested that CMS consider reopening the comment period for
this rule following the publication of the HTI-1 proposed rule (88 FR
23746). The commenter stated that CMS should give industry 24 months
from the reopening of the comment period to create specifications,
perform development, complete certification testing, and execute client
deployments. Another commenter recommended that CMS suspend the
proposed Electronic Prior Authorization measure until payers implement
and maintain the Prior Authorization API as specified in this rule and
the Prior Authorization API is in effect for at least 3 years. Multiple
commenters were concerned that providers will not be guaranteed access
to the Prior Authorization API if health IT developers are not required
to incorporate the functionality into CEHRT and therefore should not be
held

[[Page 8925]]

accountable for using the Prior Authorization API nor reporting on the
proposed Electronic Prior Authorization measure. A commenter
recommended that CMS and ONC work in collaboration to leverage
technologies, such as electronic prior authorization tools. Another
commenter urged CMS to work with ONC to establish ONC Health IT
Certification Program criteria to require providers and EHR vendors to
adopt the IGs associated with electronic prior authorization.
Commenters stated that it is unreasonable to measure utilization by
MIPS eligible clinicians, eligible hospitals, and CAHs of electronic
prior authorization processes for incentive payments until the ONC
Health IT Certification Program requires CEHRT to include the
functionality necessary for health IT systems to communicate through a
Prior Authorization API. Another commenter stated that CMS should
postpone implementation of the Electronic Prior Authorization measure
until both the ONC Health IT Certification Program and HIPAA attachment
standards are updated. Another commenter stated that the proposed
Electronic Prior Authorization measure would subject MIPS eligible
clinicians, eligible hospitals, and CAHs to be reliant upon untested
technology and tie their performance to such technology. A commenter
emphasized the importance of industry adoption and noted that the API
will have minimal value if EHR vendors do not build the necessary
connections to allow clinicians to access it and if clinicians are not
incentivized to adopt. To mitigate this, the commenter recommended that
CMS require EHR vendors to provide bi-directional patient data access
via an API so payers can better leverage digital patient information
and automate prior authorization requests. Another commenter
recommended that CMS ensure that the proposed Electronic Prior
Authorization measure is supported by technology used by all of the
impacted users. Several commenters stated that providers should not be
subject to punitive action if they do not implement the Prior
Authorization API requirements and should not be evaluated on
electronic prior authorization utilization for payment purposes until
EHRs are required to provide this functionality by the ONC Health IT
Certification Program.
Response: We appreciate the comments received on this request for
comments. As noted, the Unified Agenda, current at the time of
publication of this final rule, includes an entry for a proposed rule
from ONC (RIN 0955-AA06) that aims to advance interoperability through
proposals for the expanded use of certified APIs for electronic prior
authorization.\171\ We will work with ONC to ensure that any future
updates to the ONC Health IT Certification Program around electronic
prior authorization will improve health care providers' capabilities to
interact with the Prior Authorization APIs established by impacted
payers, as well as further support health care providers' ability to
complete the action specified in the Electronic Prior Authorization
measure we are finalizing. We will provide further guidance in future
rulemaking about how any updates made by ONC to the ONC Health IT
Certification program related to electronic prior authorization relate
to the requirements of the Medicare Promoting Interoperability Program
and Promoting Interoperability performance category of MIPS. We note
that CMS does not have authority to regulate EHR vendors directly;
however, we collaborate with ONC regarding certification criteria for
health IT that are included in the voluntary ONC Health IT
Certification Program and referenced in CMS program requirements.
---------------------------------------------------------------------------

\171\ Office of Information and Regulatory Affairs (2023,
November). Health Data, Technology, and Interoperability: Patient
Engagement, Information Sharing, and Public Health Interoperability.
Retrieved from https://www.reginfo.gov/public/do/eAgendaViewRule?pubId=202304&RIN=0955-AA06.
---------------------------------------------------------------------------

In the interim, we note that MIPS eligible clinicians, eligible
hospitals, and CAHs are required to use CEHRT for the measure as a
means to capture clinical information as structured data and to use
such structured data for the prior authorization. This function of
gathering structured data from CEHRTs is achievable today without
additional CEHRT criteria. The request for prior authorization through
the Prior Authorization API could be accomplished through the use of
additional technology to complement CEHRT depending on implementation
preference. We note that MIPS eligible clinicians, eligible hospitals,
and CAHs can report on the measure, saying ``yes'' they submitted a
prior authorization request electronically using the Prior
Authorization API with data from CEHRT, without needing additional
certification criterion in the ONC Health IT Certification Program.
We also note that in December 2022, HHS proposed to adopt a
standard for attachments in the HIPAA Standards for Health Care
Attachments proposed rule (87 FR 78438). That proposed rule has not yet
been finalized. At this time there are no operating rule requirements
applicable to the APIs required for use in this final rule, or to the
HIPAA X12 278 transaction standard.
We appreciate commenters' recommendations regarding implementation
timelines, such as making the Prior Authorization API available to
providers no later than 12 months or 36 months following the
publication of this final rule. We note that, after consideration of
comments received and discussed in more detail elsewhere in the rule,
we are finalizing our proposal with the modification to have MIPS
eligible clinicians report the Electronic Prior Authorization measure
beginning with the CY 2027 performance period/2029 MIPS payment year
and eligible hospitals and CAHs report the Electronic Prior
Authorization measure beginning with the CY 2027 EHR reporting period.
We also acknowledge that a commenter recommended suspending the
Electronic Prior Authorization measure until payers implement the Prior
Authorization API as specified in this rule and use it for some time
period. However, we believe finalization of this Electronic Prior
Authorization measure encourages all parties involved (payers and
providers) to develop, implement, and use the new Prior Authorization
API to drive widespread adoption, thus reaping the benefits of burden
reduction through electronic prior authorization processes. The Prior
Authorization API needs parties on both ends of a request to be using
the API in order for the API to be beneficial to everyone involved.
Comment: Multiple commenters recommended that ONC conduct oversight
of CEHRT products to determine if the products do or do not
successfully support electronic prior authorization, and then publicize
CEHRT products that fail ONC review on the Certified Health IT Product
List (CHPL) so providers can avoid products that will not support the
new electronic prior authorization requirements. The commenter
recommended that ONC work with professional associations to educate
providers about their oversight and reporting process.
Response: There is not a dedicated certification criterion related
to electronic prior authorization in the ONC Health IT Certification
Program at this time. However, as noted previously, ONC previously
sought comment on how updates to the ONC Health IT Certification
Program could support electronic prior authorization (87 FR 3475). We
also note that the Unified Agenda, current at the time of publication
of this final rule, includes an entry for a proposed rule from ONC

[[Page 8926]]

(RIN 0955-AA06), which describes planned proposals for the expanded use
of certified APIs for electronic prior authorization.\172\ We note that
the Electronic Prior Authorization measure requires using data from
CEHRT, and the Prior Authorization API can be implemented without
regard to any changes ONC may propose for the ONC Health IT
Certification Program.
---------------------------------------------------------------------------

\172\ Office of Information and Regulatory Affairs (2023,
November). Health Data, Technology, and Interoperability: Patient
Engagement, Information Sharing, and Public Health Interoperability.
Retrieved from https://www.reginfo.gov/public/do/eAgendaViewRule?pubId=202304&RIN=0955-AA06.
---------------------------------------------------------------------------

While ONC oversight and enforcement authority is beyond the scope
of this final rule, we note that health IT products certified to all
certification criteria are subject to oversight mechanisms within the
ONC Health IT Certification Program. For more information about the
oversight elements within the ONC Health IT Certification Program,
readers should visit the ONC website at https://www.healthit.gov/topic/certification-ehrs/oversight-and-surveillance. Regarding the CHPL
(https://chpl.healthit.gov/), we note this resource includes listings
of those health IT products that have successfully certified to health
IT certification criteria under the Certification Program.
Comment: Multiple commenters recommended that CMS and ONC outline a
roadmap for electronic prior authorization adoption that leverages the
ONC Health IT Certification Program. A commenter recommended that the
roadmap should include details from the ONC Cures Act final rule (85 FR
25642) and these requirements. Another commenter stated that an
established path to electronic prior authorization will avoid delays
and confusion.
Response: We appreciate commenters' feedback. CMS will consider
developing a roadmap for electronic prior authorization adoption in
collaboration with ONC. We will collaborate with ONC to incorporate any
future policies for the ONC Health IT Certification Program as part of
a comprehensive approach to ensuring electronic prior authorization is
conducted in a standardized fashion across parties.
3. Final Action
After consideration of the comments received and for the reasons
discussed in the CMS Interoperability and Prior Authorization proposed
rule and our response to those comments (as summarized previously), we
are finalizing our proposal with the following modifications:
The ``Electronic Prior Authorization'' measure will be
reported as an attestation (yes/no) measure, instead of reporting a
numerator and denominator, regarding whether the MIPS eligible
clinician, eligible hospital, or CAH submitted at least one prior
authorization request electronically via a Prior Authorization API
using data from CEHRT during the performance period/EHR reporting
period, as further specified below.
MIPS eligible clinicians will report the ``Electronic
Prior Authorization'' measure for the MIPS Promoting Interoperability
performance category beginning with the CY 2027 performance period/2029
MIPS payment year and eligible hospitals and CAHs participating under
the Medicare Promoting Interoperability Program will report the measure
beginning with the CY 2027 EHR reporting period.
See further discussion below for exact details of the final
requirements for MIPS eligible clinicians, eligible hospitals, and
CAHs.
We are finalizing the following specifications for the Electronic
Prior Authorization measures:
1. For MIPS Eligible Clinicians Under the MIPS Promoting
Interoperability Performance Category--Electronic Prior Authorization
Measure Description: For at least one medical item or
service (excluding drugs) ordered by the MIPS eligible clinician during
the performance period, the prior authorization is requested
electronically via a Prior Authorization API using data from CEHRT.
Reporting Requirements: Yes/No response.
To successfully report this measure, MIPS eligible clinicians must
attest ``yes'' to requesting prior authorization electronically via a
Prior Authorization API using data from CEHRT for at least one medical
item or service (excluding drugs) ordered by the MIPS eligible
clinician during the performance period or (if applicable) report an
exclusion.
Exclusion: Any MIPS eligible clinician who--
++ Does not order any medical items or services (excluding drugs)
requiring prior authorization during the applicable performance period;
or
++ Only orders medical items or services (excluding drugs)
requiring prior authorization from a payer that does not offer an API
that meets the Prior Authorization API requirements outlined in section
II.D.2. of this final rule during the applicable performance period.
2. For Eligible Hospitals and Critical Access Hospitals Under the
Medicare Promoting Interoperability Program--Electronic Prior
Authorization
Measure Description: For at least one hospital discharge
and medical item or service (excluding drugs) ordered during the EHR
reporting period, the prior authorization is requested electronically
via a Prior Authorization API using data from CEHRT.
Reporting Requirements: Yes/No response.
To meet this measure, the eligible hospital or CAH must attest
``yes'' to requesting a prior authorization electronically via a Prior
Authorization API using data from CEHRT for at least one hospital
discharge and medical item or service (excluding drugs) ordered during
the EHR reporting period or (if applicable) report an applicable
exclusion.
Exclusions: Any eligible hospital or CAH that--
++ Does not order any medical items or services (excluding drugs)
requiring prior authorization during the EHR reporting period.
++ Only orders medical items or services (excluding drugs)
requiring prior authorization from a payer that does not offer an API
that meets the Prior Authorization API requirements outlined in section
II.D.2. of this final rule during the applicable EHR reporting period.
We intend to reevaluate the Electronic Prior Authorization measure
criteria and reporting structure of this measure in future years as the
Prior Authorization API becomes more widely adopted and if additional
certification criteria become available for CEHRT to determine whether
a numerator/denominator reporting structure would be more appropriate
at that time. We would address those issues in future rulemaking.
We are finalizing our proposal that the Electronic Prior
Authorization measure will not be assigned points for the CY 2027
performance period/2029 MIPS payment year for MIPS eligible clinicians,
and the CY 2027 EHR reporting period for eligible hospitals and CAHs.
Instead, if a MIPS eligible clinician, eligible hospital, or CAH fails
to report the measure as specified, they would not meet the minimum
reporting requirements, not be considered a meaningful EHR user, and
fail the Medicare Promoting Interoperability Program or the MIPS
Promoting Interoperability performance category. A failure to meet the
minimum reporting

[[Page 8927]]

requirements of the Medicare Promoting Interoperability Program would
result in a downward payment adjustment for eligible hospitals or CAHs
(unless the eligible hospital or CAH receives a hardship exception). A
failure in the Promoting Interoperability performance category would
result in the MIPS eligible clinician receiving a score of zero for the
performance category, which is currently worth 25 percent of their
final score for MIPS.
For the MIPS Promoting Interoperability performance category,
satisfactory performance on this measure can be demonstrated only by
reporting a ``yes'' response on the attestation or claiming an
applicable exclusion. A ``no'' response on the attestation will result
in the MIPS eligible clinician failing to meet the minimum reporting
requirements, therefore not being considered a meaningful EHR user for
MIPS, as set forth in section 1848(o)(2)(A) of the Act and defined at
42 CFR 414.1305, for the MIPS payment year (42 CFR 414.1305). MIPS
eligible clinicians that do not report a ``yes'' response or claim an
applicable exclusion for the Electronic Prior Authorization measure as
specified (that is, they do not submit the measure or claim an
exclusion or report a ``no'' response) will not earn a score for the
MIPS Promoting Interoperability performance category (a score of zero
for the category). A MIPS eligible clinician's score in the Promoting
Interoperability performance category is generally worth 25 percent of
their total final score for MIPS (42 CFR 414.1375(a); 414.1380(c)(1)).
We note that to report a ``yes,'' the action of the measure must occur
during the selected performance period \173\ or EHR reporting
period,\174\ as per the measure specification defined below.
---------------------------------------------------------------------------

\173\ See 42 CFR 414.1320.
\174\ See 42 CFR 495.40(b)(2)(i).
---------------------------------------------------------------------------

For the Medicare Promoting Interoperability Program, only a ``yes''
response on the attestation, or claiming an applicable exclusion, will
fulfill the minimum requirements of this measure. A ``no'' response
will result in the eligible hospital or CAH failing to meet the
measure, and therefore failing to meet minimum program reporting
requirements, thus not being considered a meaningful EHR user for an
EHR reporting period, as defined in section 1886(n)(3) of the Act.\175\
Eligible hospitals and CAHs that do not meet the minimum program
requirements are subject to a downward payment adjustment (unless the
eligible hospital or CAH receives a hardship exception).
---------------------------------------------------------------------------

\175\ See 42 CFR 495.4 and 495.24(f)(1)(i)(A).
---------------------------------------------------------------------------

G. Interoperability Standards for APIs

1. Background
In the CMS Interoperability and Patient Access final rule (85 FR
25510), we finalized a requirement to implement, maintain, and use API
technology conformant with the API technical standards at 45 CFR
170.215, which at the time included (85 FR 25521):
Health Level Seven (HL7[supreg]) Fast Healthcare
Interoperability Resources (FHIR[supreg]) Release 4.0.1
HL7[supreg] FHIR[supreg] US Core Implementation Guide (IG)
Standard for Trial Use (STU) 3.1.1
HL7[supreg] SMART Application Launch Framework IG Release
1.0.0, including mandatory support for the ``SMART Core Capabilities''
FHIR[supreg] Bulk Data Access (Flat FHIR) IG (v1.0.0: STU
1), including mandatory support for the ``group-export''
``OperationDefinition''
OpenID Connect Core 1.0, incorporating errata set 1
When we finalized the requirement for conformance with the
specifications at 45 CFR 170.215 in the CMS Interoperability and
Patient Access final rule, we required impacted payers to comply with
all standards at 45 CFR 170.215 for each of the APIs finalized in that
rule. However, we understand that the existing requirements for payers
to ``use API technology conformant with 45 CFR 170.215'' (85 CFR 25632)
for each API may introduce confusion to the compliance requirements,
because not all the standards at 45 CFR 170.215 may be applicable for
each specific API.\176\
---------------------------------------------------------------------------

\176\ See 42 CFR 422.119 (Access to and exchange of health data
and plan information), 431.60 (Beneficiary access to and exchange of
data), and 457.730 (Beneficiary access to exchange of data) and 45
CFR 156.221 (Access to and exchange of health data and plan
information).
---------------------------------------------------------------------------

Accordingly, to provide clarity, in the CMS Interoperability and
Prior Authorization proposed rule, we outlined modifications to be more
specific regarding which standards at 45 CFR 170.215 are applicable to
each API (87 FR 76314-21). Specifically, instead of the existing
requirements to use ``API technology conformant with 45 CFR 170.215,''
we proposed that each standard at 45 CFR 170.215 would apply to a given
set of APIs. The specific CFR citations were listed in Table 8 of the
proposed rule (87 FR 76318). We are now finalizing those requirements,
with modifications to some of the specific API requirements. We are
finalizing that impacted payers will only be required to use those
specifications at 45 CFR 170.215 that are listed in Table H3 as
necessary for the Patient Access, Provider Access, Provider Directory,
Payer-to-Payer, and Prior Authorization APIs. We are also finalizing
our proposal to allow impacted payers to use updated standards,
specifications, or IGs for each of these APIs. Finally, we are
reiterating our recommendations to use the IGs listed in Table H3. We
discuss these policies in detail elsewhere in the final rule.
2. Modifications to Required Standards for APIs
We proposed specific standards at 45 CFR 170.215 that would apply
to each API. In the proposed rule, we listed the standards applicable
to each API in Table 10 (87 FR 76320). Since the publication of the CMS
Interoperability and Prior Authorization proposed rule, ONC has
published the HTI-1 final rule which reorganized the structure of 45
CFR 170.215 to delineate the purpose and scope more clearly for each
type of standard or implementation specification (89 FR 1283). We note
that the HTI-1 final rule adopted updated versions of several standards
at 45 CFR 170.215, which now includes:
Health Level Seven (HL7) Fast Healthcare Interoperability
Resources (FHIR) Release 4.0.1 at 45 CFR 170.215(a)(1) (HL7 FHIR);
HL7 FHIR US Core IG Standard for Trial Use (STU) 3.1.1,
which expires on January 1, 2026, at 45 CFR 170.215(b)(1)(i);
HL7 FHIR US Core IG STU 6.1.0 at 45 CFR 170.215(b)(1)(ii)
(US Core IG),
HL7 SMART Application Launch Framework IG Release 1.0.0,
which expires on January 1, 2026, at 45 CFR 170.215(c)(1);
HL7 SMART App Launch IG Release 2.0.0 at 45 CFR
170.215(c)(2) (SMART App Launch IG);
FHIR Bulk Data Access (Flat FHIR) IG (v1.0.0: STU 1) at 45
CFR 170.215(d)(1) (Bulk Data Access IG); and
OpenID Connect Core 1.0, incorporating errata set 1 at 45
CFR 170.215(e)(1) (OpenID Connect Core).
We refer readers to the HTI-1 proposed and final rule for
additional information (FR 1284 through 1295). The specific standards
at 45 CFR 170.215 that we identified in our proposed rule were
restructured by HTI-1 and moved to new locations at 45 CFR 170.215. In
addition, in several cases ONC adopted new versions of the same
standards proposed in the CMS Interoperability and Prior Authorization
proposed rule. Specifically, ONC finalized US Core IG STU 6.1.0 (at 45

[[Page 8928]]

CFR 170.215(b)(1)(ii)) and the SMART App Launch IG Release 2.0.0 (at 45
CFR 170.215(c)(2)). Additionally, ONC has finalized expiration dates
for the US Core IG STU 3.1.1 (at 45 CFR 170.215(b)(1)(i)) and the SMART
App Launch Framework IG Release 1.0.0 (at 45 CFR 170.215(c)(1)) to
indicate when a version of a standard may no longer be used for the ONC
Health IT Certification Program. While we did not propose to require
those updated versions, we emphasize that impacted payers are permitted
to use them based on our policy to allow updated versions of required
standards, as discussed. We intend to align with the updated versions
finalized at 45 CFR 170.215 through future rulemaking prior to our API
compliance dates.
We are finalizing our proposals to identify specific required
standards at 45 CFR 170.215 that are applicable to each of the APIs,
with modifications. The finalized requirements include any additional
mandatory support requirements listed, such as for both the SMART App
Launch IG at 45 CFR 170.215(c) and Bulk Data Access IG at 45 CFR
170.215(d). We are cross-referencing the new locations for these
standards at 45 CFR 170.215 finalized by ONC in the HTI-1 final rule.
Table H3 lists the required versions of each standard and their
citation. Throughout this preamble we refer to the current structure of
45 CFR 170.215 as updated by the HTI-1 final rule.
For the Patient Access API, we are finalizing the required
standards as proposed with modifications to incorporate the expiration
dates ONC adopted at 45 CFR 170.215(b)(1)(i) and (c)(1). For the
Provider Directory API, we are finalizing our proposal with
modifications to incorporate the expiration date ONC adopted at 45 CFR
170.215(b)(1)(i), and to remove the SMART App Launch IG at 45 CFR
170.215(c)(1) and OpenID Connect Core at 45 CFR 170.215(e), which were
erroneously included in the proposed rule. We refer readers to the
footnote in Table H3 for additional information. For the Provider
Access API, we are finalizing our proposal with the modification to not
require OpenID Connect Core at 45 CFR 170.215(e) and with modifications
to incorporate the expiration dates ONC adopted at 45 CFR
170.215(b)(1)(i) and (c)(1). For the Payer-to-Payer API, we are
finalizing our proposal with modifications to not require the SMART App
Launch IG at 45 CFR 170.215(c) and OpenID Connect Core at 45 CFR
170.215(e), and to incorporate the expiration date ONC adopted at 45
CFR 170.215(b)(1)(i). For the Prior Authorization API, we are
finalizing our proposal with modifications to not require OpenID
Connect Core at 45 CFR 170.215(e) and to incorporate expiration dates
ONC adopted at 45 CFR 170.215(b)(1)(i) and (c)(1). Payers will be
required to comply with the applicable specifications that we have
identified for the Patient Access, Provider Access, Provider Directory,
Payer-to-Payer, and Prior Authorization APIs as listed in Table H3. The
exact regulation text for each API will vary depending on which
standards apply to that API. These updates particularize the
specifications at 45 CFR 170.215 that are required for each API. We
received comments on these proposals and discuss details of the
modifications.
a. HL7 FHIR and Technical Readiness
Comment: Multiple commenters expressed support for CMS's proposal
to specify technical standards for each API and recommended that CMS
finalize the proposal. A commenter expressed appreciation for CMS's
efforts to explain the technical requirements for each API and agreed
with the proposal to add more specific language regarding which
standards apply to which API.
Multiple commenters also supported CMS's proposal to require payers
to use the FHIR standard to facilitate information exchange and promote
interoperability. Multiple commenters stated that FHIR APIs help
connect patients, providers, and payers to the correct information. A
commenter stated that FHIR-based standards maximize the chance for
innovation and the proposed revision provides technical clarity to
payers. Another commenter stated that utilizing the FHIR standard
continues to advance the use of transparent, widely available standards
and helps to facilitate electronic information exchange, while another
stated that the FHIR-based IGs support the provider team's workflow and
enable them to better understand patient-specific benefits.
Response: We appreciate commenters support for using the FHIR
standard and FHIR APIs to improve information exchange and agree with
the commenters' assessments that these will advance interoperability.
Comment: Multiple commenters expressed concern about mandating the
FHIR standard. Multiple commenters expressed concern regarding the
maturity of the proposed standards, specifications, and recommended
IGs. Multiple commenters stated that it would be inadvisable to specify
technical requirements at this time given that the technical standards
and IGs have not fully matured. Multiple commenters recommended that
CMS, along with ONC, take steps to adequately and inclusively develop
technical standards and relevant IGs to full maturity as a baseline of
industry consistency, ensuring standards are tested and transparently
evaluated prior to mandated adoption. Another commenter encouraged CMS
to maintain flexibility in the agency's ongoing data exchange
activities to ensure the success of interoperability programs. Another
commenter urged CMS to ensure careful consideration of what technical
standards to require in the future. Another commenter suggested that
requiring all entities to use the FHIR standard may be burdensome. The
commenter stated that CMS has not proposed any alternatives and that
adoption of the FHIR standard may not be feasible for small entities
and asked questions such as what will happen if small businesses are
not able to convert to FHIR.
A commenter cautioned CMS not to view the FHIR standard as the sole
solution to interoperability and patient data exchange challenges. The
commenter noted that as currently proposed, the Patient Access API
would experience challenges if the FHIR standard failed to reach
widespread adoption and maturity. A commenter stated that the HL7 Da
Vinci IGs that support the Patient Access API have not yet reached
sufficient maturity for widespread adoption. The commenter stated that
using the FHIR standard, agnostic of a particular IG, will give
industry stakeholders greater flexibility to pilot different approaches
and build consensus without the risk of distortions that could result
from mandatory adoption of immature specifications.
Response: We thank commenters for providing their thoughts
regarding the FHIR standard. However, we disagree that FHIR is not
mature. The primary components of the FHIR standard are mature, as are
the standards we are requiring in this rule, such as the US Core IG. We
acknowledge that the FHIR resource profiles included in the IGs we
recommend are of varying levels of maturity, but we believe they are
sufficiently mature for industry to start implementing them. We refer
readers to our discussion on IG maturity in section II.G.3.b. of this
final rule. The FHIR standard will help move the health care industry
toward a more interoperable state, and we believe that it supports
transmission of health data in a standard, structured, but flexible
format as FHIR specifications continue to advance and mature. HHS has
already adopted standards for FHIR APIs at 45

[[Page 8929]]

CFR 170.215, as finalized in the ONC Cures Act final rule, and
therefore we did not propose any alternatives (85 FR 25521). We
disagree that the HL7 Da Vinci IGs that support the Patient Access API
have not yet reached sufficient maturity for widespread adoption as
they have already been successfully implemented and are being used
today. Since 2021 impacted payers have been required to implement and
maintain a standards-based Patient Access API that uses FHIR and other
technical standards at 45 CFR 170.215, as finalized in the CMS
Interoperability and Patient Access final rule (85 FR 25558). We are
delaying the compliance date for policies that require API enhancement
or development to 2027, which will allow additional time for the
recommended FHIR IGs to be refined to support the policies in this
final rule. We believe the adoption of the FHIR standard is feasible
for all the APIs finalized in this rule, especially with the additional
implementation time.
Comment: Multiple commenters appreciated CMS's efforts to move
industry towards interoperability and expressed support for CMS's
proposals to promote electronic data exchange among patients,
providers, and payers via APIs leveraging technical standards and IGs.
Multiple commenters supported using FHIR-based standards to facilitate
data transport across the industry and that FHIR-based exchange is
technically feasible for both payers and providers to adopt and
implement. A commenter stated that the FHIR standard and IGs promote a
level of consistency in terms of format, structure, and vocabulary, as
well as allow for a variety of interoperability paradigms that best
suit the interaction requirements between providers, payers, and
patients. A commenter supported using USCDI data classes and data
elements in addition to claims and encounter data when exchanging
patient information.
Multiple commenters expressed support for CMS's proposals to use
standards-based APIs and stated that the industry-wide adoption of
uniform standards will help enhance interoperability and minimize
complexity. Multiple commenters stated that having an established
technical infrastructure to support the development and adoption of the
new APIs outlined in this rule is crucial to prevent added
administration burden, complexity, and variability in implementation.
Response: We agree with the commenters' assessments and thank them
for their support of our policies.
Comment: A commenter requested that CMS define a more prescriptive
designated data set for claims and encounter data akin to USCDI. The
commenter continued by stating that CMS should explicitly call out the
Common Payer Consumer Data Set (CPCDS), which would ensure a more
uniform implementation and ensure that patients, providers, and payers
can use those capabilities in a way that the rule intended. Another
commenter suggested a realignment of the purpose and use of USCDI as a
library of data types, classes, and specifications from which
interoperability requirements can be drawn.
Response: While altering the design and structure of the USCDI are
out of scope for this rule, we will continue to work with ONC to expand
and build upon the USCDI. For instance, we have worked with ONC on the
USCDI+ initiative, which aims to harmonize data sets that extend beyond
the USCDI for additional use cases. While USCDI is one category of data
required to be exchanged via the APIs, we understand that the USCDI is
limited in scope and that additional data and standards will be
necessary to implement these APIs. For instance, the recommended
HL7[supreg] FHIR[supreg] CARIN Consumer Directed Payer Data Exchange IG
(CARIN IG for Blue Button) (87 FR 76316), which was itself informed by
and includes mappings to CPCDS.
Comment: A commenter noted that the implementation of the APIs is
contingent on compliant technical solutions being available in the
marketplace. Another commenter stated that the lack of specificity in
API requirements gives payers significant latitude to determine what
data elements they want to include in their APIs and under what
circumstances, which will not promote widespread interoperability.
Another commenter stated that technical standardization and payer
participation are the only ways that these proposals could be
effective. The commenter stated if the responsibility is not shared
across stakeholders, CMS will simply shift more burden onto providers.
Another commenter stated that variance in API implementation could
require providers to need significant assistance from health IT vendors
to navigate these systems, which would eliminate any efficiencies CMS
expected to derive from the new interoperability requirements. Another
commenter noted a frequent problem with the implementation of technical
processes is variation from system-to-system and interpretation
differences since guidance is not universally communicated to
developers who need the information. Similarly, a commenter noted that
these technical API standards may require providers to hire additional
staff to implement them.
Response: The industry already has significant adoption of the FHIR
standard for several use cases and there are solutions available today
to FHIR-enable existing systems. Additionally, many of the IGs
recommended in this rule have already been implemented by multiple
implementers at some level. We anticipate more solutions will be
available in the marketplace ahead of the API compliance dates in 2027.
We acknowledge that using marketplace technical solutions may ease
implementation. We understand that there is still a learning curve with
respect to the FHIR-based standards and IGs and that entities may need
to hire and train staff.
We appreciate these perspectives and acknowledge that standards are
what promote interoperability. The adoption of the FHIR standard and
the IGs promote interoperability by enabling the secure exchange of
health information across disparate systems. The FHIR APIs provide the
framework for this exchange. Regarding concerns for the lack of
specificity in the API requirements, we acknowledge that we are only
recommending rather than requiring several IGs because they continue to
evolve and are not adopted by HHS at 45 CFR 170.215. As these IGs
continue to mature, we will consider proposing to require them through
future rulemaking. The IGs provide the exchange of the essential data
elements, such as patient demographics, clinical information, prior
authorization requests, and other data to ensure the necessary
information is shared between payers and providers. We acknowledge that
implementation and testing will take time and welcome ongoing feedback
through the programs and standards workgroups.
Comment: Multiple commenters expressed concern regarding the
proposed technical standards and IG provisions outlined in the proposed
rule. Multiple commenters noted that technical challenges around health
information exchange could persist despite these proposals and that the
technical standards lack the specificity and flexibility to properly
support the interoperable exchange of data.
Response: We received many comments regarding our approach in the
proposed rule of recommending, rather than requiring, specific IGs. We
believe that this approach optimally balances the need for us to
provide directional guidance without locking implementers

[[Page 8930]]

into the versions of the recommended IGs that were available at the
time of the proposed rule. As these IGs mature, industry can continue
to harmonize on common approaches that work, eventually culminating in
a required set of specifications, which, when ready, could be proposed
through future CMS rulemaking. If we chose not to recommend specific
IGs, this lack of direction would mean a more diverse set of
proprietary solutions, resulting in little to no interoperability.
Comment: A commenter stated that there is transformative effort and
overall risk in requiring the Patient Access, Provider Access, and
Payer-to-Payer APIs to be implemented around the same time. A commenter
noted that the attachments standard is not mature and that could hinder
non-structured data exchange such as in CMS's proposals to require
prior authorization documentation in the Patient Access, Provider
Access, and Payer-to-Payer APIs. The commenter noted there is a risk in
needing necessary endpoint connections and the functionality to convert
documents between FHIR exchanges to be established by payers,
providers, and health IT vendors for the purpose of data exchange. The
commenter recommended that CMS first require the APIs and then add the
exchange of attachments a few years later.
Response: For the Patient Access, Provider Access, and Payer-to-
Payer APIs, we are requiring impacted payers to share claims and
encounter data, all data classes and data elements included in a
content standard at 45 CFR 170.213 (USCDI), and certain information
about prior authorizations. Many of the data classes and data elements
are already required for the Patient Access API, which means that
payers have already formatted these data and prepared their systems to
share via a FHIR API. We thus believe that payers can concurrently
implement the APIs in this final rule.
We agree that standards for transmitting documentation and
attachments via the FHIR APIs are still under development and in
testing, and thus not yet in widespread use across the industry.
Further, as elaborated in sections II.A. and II.B. of this final rule,
we agree that the burden of requiring impacted payers to make
unstructured documentation available via the Patient Access and
Provider Access APIs outweighs the benefits such documentation would
provide. However, as discussed in section II.C., for the Payer-to-Payer
API we are finalizing a requirement to exchange structured and
unstructured administrative and clinical documentation submitted by
providers related to prior authorization requests and decisions.
Comment: Multiple commenters encouraged CMS to work with ONC to
ensure relevant technical standards and related IGs are sufficiently
mature and reflect the proper content and policies to allow seamless
data transfers between payers and providers. Another commenter urged
CMS to work in partnership with ONC to establish a clear pathway for
the required IGs including: (1) the ability to advance IG versions
outside the regulatory cycle; (2) adequate time for industry to
understand and adopt new IG versions; and (3) limiting options, so as
not to disrupt interoperability.
Response: As previously mentioned in this section, the primary
components of the FHIR standard are mature, as are the standards we are
requiring in this rule. We acknowledge that the FHIR resource profiles
included in the IGs we recommend are of varying levels of maturity, we
believe they are sufficiently mature for industry to start implementing
them. We refer readers to our discussion on IG maturity in section
II.G.3.b. of this final rule. We will continue to closely coordinate
our policies with ONC to ensure that they are mutually reinforcing. We
are also finalizing our proposal to allow payers to use updated
standards, specifications, or IGs for each API, as long as certain
conditions are met, including that the updated version does not disrupt
an end user's ability access the data required for that API.
Comment: A few commenters shared concerns with the lack of a
mandatory testing system, as well as lack of available test data,
staging environments, sandboxes, and other mechanisms to help
developers test their APIs. A commenter suggested CMS conduct usage
validity testing of the payers' APIs throughout the development and
deployment process of the APIs to track and mitigate any risks
associated with missing or incorrect data. The commenter requested that
CMS delay the enforcement timeline to accommodate these critical
prerequisites. Likewise, another commenter recommended that CMS
postpone publication of the final rule until it can require both the
technical standards and IGs to prevent non-standard implementation
across the industry. The commenter recommended that CMS work with the
HL7 Da Vinci workgroup and ONC to ensure the APIs and associated
standards are tested for complex use cases and to scale. Another
commenter recommended CMS define or promote conformity to the ONC
Inferno Framework. Another commenter recommended that CMS should
establish a mandatory testing system like the ONC Cypress testing tool
for the proposed APIs and data standards requirements.
Multiple commenters noted that testing should be conducted in a
variety of clinical settings, including small, independent, and rural
practices, and with all end users to ensure that the technical
standards and IGs are effective, adaptable, and efficient. A commenter
highlighted that it is critical that any solution be fully developed
and tested prior to wide-scale industry rollout and required usage to
ensure the best return on the investment of industry resources. The
commenter stated that this process should include careful consideration
of the transactions' scalability, privacy guardrails, and ability to
complete administrative tasks in a real-world setting. Other commenters
recommended that CMS establish additional pilot testing programs to
ensure industry readiness before the compliance dates.
Response: We agree that testing is an important part of the
implementation process and will continue to support industry efforts to
do so, including coordinating with ONC and HL7, including the DaVinci
Accelerator, on such efforts. We will also continue to engage with ONC
to determine whether the Inferno Framework \177\ could be utilized in
the future. HL7's IG testing process includes privacy and security
testing. Also, FAST,\178\ which is an initiative started by ONC,
identifies FHIR scalability gaps, defines solutions to address current
barriers, and identifies needed infrastructure for scalable FHIR
solutions. Real-world testing can only be accomplished if payers choose
to pilot an implementation during the testing phase, which CMS cannot
require participation in. However, we are not delaying publication of
this final rule, as we understand that industry requires a firm
commitment from the Federal Government to the adoption and
recommendation of standards. Based on comments received, and as
discussed throughout this final rule, we are delaying the compliance
dates for all the policies that require API development and enhancement
to 2027, which will

[[Page 8931]]

allow additional time for FHIR specifications to continue to be refined
and advanced to support the policies in this final rule.
---------------------------------------------------------------------------

\177\ Office of the National Coordinator for Health Information
Technology (n.d.). Inferno. Retrieved from https://inferno.healthit.gov/.
\178\ Health Level Seven International (2023, October 13). FHIR
at Scale Taskforce (FAST). Retrieved from https://confluence.hl7.org/display/FAST.
---------------------------------------------------------------------------

We also appreciate the multiple comments received on the importance
of testing and the provision of examples, such as the ONC Cypress
testing tool, which is an open-source tool used in the ONC Health IT
Certification Program to ensure certified health IT accurately
calculates electronic clinical quality measures (eCQMs). We will
continue to collaborate with ONC and DaVinci on testing the APIs and
with HL7 on communication and outreach to payers, developers, and
providers.
Comment: Multiple commenters urged CMS to closely track and
participate in the standards development process to ensure that all
perspectives are considered, such as providers, payers, and other
applicable end users. Multiple other commenters urged CMS and ONC to
provide funding to HL7 FHIR Accelerators and task forces. A commenter
expressed their desire for CMS to increase opportunities for greater
stakeholder participation in the standards development process. Another
commenter recommended that CMS release a formal assessment of the
status of technology development in support of the new requirements to
demonstrate that the technology is fully developed and implementable.
Response: We are an active participant in the standards development
process through various workgroups and FHIR Accelerators. A few of the
recommended IGs have been developed by HL7 FHIR Accelerator programs,
which bring together individuals across the industry to create and
adopt IGs in alignment with HL7, which allows new and revised
requirements to become open industry standards. Under HL7 FHIR
Accelerators, interested parties within the industry have defined,
designed, and created use-case-specific implementations of FHIR to
address value-based care initiatives. Some HL7 FHIR Accelerators, such
as Da Vinci and CARIN, have created IGs that we recommend be used for
the Patient Access, Provider Directory, Provider Access, Payer-to-
Payer, and Prior Authorization APIs. We also provide contract support
to supplement existing work led by the SDOs and FHIR Accelerators.
Further, we cohost an annual FHIR Connectathon testing event with HL7
and encourage diverse stakeholder participation from payers, providers
and patient advocates. HL7 has developed a FHIR Maturity Model (FMM)
\179\ that defines thresholds of standards maturity as part of their
standards development and publication process. HL7 requires a specific
maturity level for parts of the standards development and publication
process. We also note that ONC publishes an Interoperability Standards
Assessment (ISA).\180\ The latest published 2023 version provides
information on the HL7 standards that are required or recommended in
this rule.
---------------------------------------------------------------------------

\179\ Health Level Seven International (n.d.). Version
Management Policy. Retrieved from https://hl7.org/fhir/R4/versions.html#maturity.
\180\ Office of the National Coordinator for Health Information
Technology (2023). 2023 Interoperability Standards Advisory
Retrieved from https://www.healthit.gov/sites/isa/files/inline-files/2023%20ReferenceM.A20Edition_ISA_508.pdf.
---------------------------------------------------------------------------

Comment: A commenter urged CMS to pay close attention to principles
that focus on assessing provider impact, measuring success in achieving
stated goals, and monitoring standards development and use. The
commenter stated that these principles can help guide CMS and
developers to better respond to provider needs. Another commenter urged
CMS to ensure that the technical standards meet provider and patient
needs and accurately embody CMS's goals to improve care and reduce
provider burden.
Response: We will continue to assess standards development and use
as an active participant in the HL7 community and FHIR workgroups. We
also encourage stakeholders to participate and contribute to the work
of the SDOs in the standards development and evolution, because broad
engagement would support the improvement of interoperable standards.
Comment: A commenter recommended continued Federal support of
ongoing standards development and data interoperability work, including
financial and technical support, for SDOs such as the HL7 Da Vinci
Workgroup, FAST, and other applicable workgroups. Some commenters
encouraged CMS to advance the FAST initiatives to address the ongoing
challenges of patient matching, identity management, security and
authentication, and access to the necessary digital endpoints. Another
commenter expressed support for incentives and investment in FHIR-based
pilots and technology, stating that this would move the industry
towards FHIR APIs for real-time information exchange.
Response: We agree and intend to continue our support for and
participation in various standards development activities. As noted
previously, we provide contract support to supplement existing work led
by the SDOs and FHIR Accelerators. We believe that the policies that we
are finalizing are a crucial step in moving the industry towards real-
time information exchange.
Comment: A commenter stated that to assist providers in making
informed decisions, CMS should apply the same ``discrete data element
standards'' the agency applied to the original Patient Access API to
the new prior authorization data added to the Patient Access, Provider
Access, and Payer-to-Payer APIs. Another commenter requested that CMS
consider synchronizing the required technical standards for those three
APIs given that the APIs are functionally identical. The commenter
stated that having a single standardized API for the three different
access types (patient, provider, and payer) would provide three key
benefits: (1) simplifies the technical approach for initial rollout and
any future changes; (2) allows Medicaid programs to focus on challenges
that these APIs pose; and (3) reduces end user confusion since end
users will see the same data shared through the APIs. A commenter
requested that CMS continue to standardize and harmonize API
requirements to reduce potential burden for providers and confusion for
consumers. Another commenter stated that these requirements should be
consistent across all stakeholders.
Response: Each of the APIs in this rule will require sharing only
structured documentation, except for the Payer-to-Payer API, which
includes unstructured administrative and clinical documentation
submitted by a provider to support a prior authorization request. We
intentionally based the requirements for the Provider Access and Payer-
to-Payer APIs on the content requirements for the Patient Access API,
to facilitate reuse, since payers have already formatted these data
elements and prepared their systems to share these standardized data
via a FHIR API. Payers already devoted the development resources to
build a FHIR API infrastructure when they implemented the Patient
Access API, which can be adapted for additional interoperability use
cases. While the data we are requiring to be shared via these APIs
would be nearly identical, they have different use cases, thus
necessitating separate API regulatory requirements. We also encourage
payers to reuse infrastructure for all the APIs. Payers may implement
the API functionality by using one or multiple APIs, depending on their
approach, as long as all

[[Page 8932]]

requirements are met for each of the APIs.
Comment: Multiple commenters recommended that CMS align the
technical standards provisions outlined in this rule with the HIPAA
Standards for Health Care Attachments proposed rule (87 FR 78438). A
commenter recommended that CMS work with ONC to do so. Another
commenter stated that they support both rules and urged CMS to ensure
that there are no duplicative efforts. Another commenter recommended
removing the prior authorization provisions outlined in the HIPAA
Standards for Health Care Attachments proposed rule and moving forward
with finalizing FHIR-based standards and transactions. Another
commenter encouraged CMS to work with ONC to align any prior
authorization proposals with HHS's proposal to establish a national
standard for electronic attachments.
Response: Requirements to use certain HIPAA transaction standards
for prior authorization were proposed in the HIPAA Standards for Health
Care Attachments proposed rule. These are related policies, and we will
ensure a path toward implementation that will allow payers and
providers to comply with both. However, because that rule has not been
finalized, we cannot comment on how the standards would align with the
policies in this rule. If finalized, in that final rule we would
discuss the impact of those policies and any opportunities to align
with our policies in this final rule. We will also continue to work
with ONC on alignment between standards in this rule, and other
standards adopted across CMS.
Comment: Multiple commenters recommended that CMS institute
financial incentives for market suppliers, providers, and payers to
participate in the testing and development of technical standards, IGs,
and applicable processes. The commenter stated that one of the primary
challenges of standards development and testing is a lack of financial
and regulatory incentives for stakeholders to participate, which then
slows down testing. Multiple commenters cautioned CMS to consider the
cost of establishing the proposed API infrastructure. Another commenter
noted that implementation will require integration between the newly
acquired API functionality and the existing data sources, which
includes exporting data from current systems to be imported and stored
within a FHIR-compliant repository so that it can be presented via the
API to the user. Multiple commenters requested that CMS provide
technical assistance and resources to help the industry implement the
APIs and meet all the technical standards and requirements outlined in
this rule. Another commenter requested that CMS engage with
stakeholders to develop resources and technical assistance to help
industry operationalize and meet the proposed technical standards and
API requirements outlined in the rule and any other parallel agency
efforts.
Response: At this time, we lack statutory authority to provide
financial incentives to participate in the testing and development of
technical standards, IGs, and applicable processes. While we do not
currently provide funding for IT infrastructure development costs
(except for Medicaid agencies, as discussed in section II.E. of this
final rule), we do provide educational webinars providing overviews of
the technical requirements in the interoperability rules. Additional
public resources also exist through HL7, such as their Connectathons,
HL7 website resources, and HL7 FHIR workgroup meetings that are
generally available. We also cohost an annual Connectathon with HL7,
which is free for stakeholders to attend. Ultimately, each payer is
responsible for ensuring that their users are trained on their systems.
Comment: A commenter stated that a frequent problem is that there
is not a well-established or monitored mechanism for an implementer to
contact a payer about implementation issues or implementation
questions. The commenter stated that this is an important missing piece
to making widespread implementation viable. The commenter reflected on
the experience of third-party apps engaging with payers to implement
the existing Patient Access API. They stated that third-party apps
struggle with finding someone to fix issues, answer questions, approve
their registrations, and address other barriers to implementation they
experienced.
Multiple commenters stated that to support the proposed APIs,
provider and payer endpoints must be included in a national directory,
available to support endpoint discovery, before the compliance dates of
the Provider Access, Payer-to-Payer, and Prior Authorization APIs. A
commenter stated that a CMS NDH should be initiated to help find
provider and payer endpoints. Another commenter stated that the lack of
an authoritative central directory could create a significant gap in
the ability for industry to move many critical interoperability
initiatives forward. Another commenter stated the proposed technical
standards for APIs is a helpful step to greater interoperability;
however, CMS failed to properly account for the complexity of this
implementation. The commenter recommended that CMS should implement a
national directory so that each plan and provider must maintain only
one incoming/outgoing connection.
Response: We acknowledge commenter concerns that there is not a
monitored mechanism for contacting a payer about implementation issues
or implementation questions. We thank the commenters for their concern
that the lack of an authoritative central directory is a gap in the
ability to move forward with interoperability initiatives. We do
understand that a directory of payer and provider digital endpoints
would be highly beneficial to facilitate our Payer-to-Payer, Provider
Access, and Prior Authorization APIs policies, and as discussed in
section I.D. of this final rule we are committing to exploring an NDH
that contains payers' digital endpoints in support of the Payer-to-
Payer API and providers' digital endpoints. We will also explore
including payer contact information, including whom to contact
regarding API implementation issues or questions, in any NDH we
propose.
Comment: A commenter stated that adding standard data classes and
data elements around high-priority use cases is an effective strategy
to make data more accessible to consumers. The commenter noted that the
Provider Directory and Patient Access APIs can serve as a base for the
other proposed APIs. The commenter provided recommendations to help CMS
achieve this goal such as establishing operational standards to help
developers, requiring payers to register app developers and grant
authorization to production access without regard to out-of-band
consent standards payers choose to implement, and establishing stronger
requirements for payers to make this information available. The
commenter also recommended that (1) CMS require impacted payers to
establish sandbox environments; (2) CMS impose a reasonable time
standard to mitigate implementation delays; (3) CMS require impacted
payers to perform conformance tests and report results to the public;
and (4) CMS require that impacted payers' technical documentation for
the Patient Access API notes what USCDI data are made available.
Another commenter recommended that CMS should develop a roadmap in
partnership with the private sector for all the technical use cases
outlined in the proposed rule.
Response: We appreciate the additional suggestions, however, many

[[Page 8933]]

of those were not proposed and therefore, we cannot include such
provisions in the final rule. We also understand the value of a sandbox
environment and acknowledge the value of payers establishing sandbox
environments for implementers to test; however, we realize there are
industry costs to doing so.
Comment: Multiple commenters encouraged CMS to consider alternative
approaches to achieving data exchange. A commenter recommended that CMS
consider other types of interoperability technology beyond APIs and
request/response data exchange, which can lead to multiple copies of
data. The commenter suggested CMS consider services that provide
virtual real-time data updates. Another commenter recommended that CMS
work with ONC to develop a future-looking approach to allow consumers
to direct the sharing of claims data with third-party entities via a
national exchange platform. A commenter recommended that CMS, ONC, and
HL7 work together to build the infrastructure for a standard for ADT
data.
Response: While we appreciate the commenters who asked us to
consider services that provide virtual real-time data updates and we
recognize the importance of needing the patient information as soon as
possible or in real time, we also believe that requiring that at this
time would cause undue burden on impacted payers. We nonetheless
encourage payers to make data available to requesting providers as soon
as they are able. We understand the concern over duplicative
information, and it is not our intention to increase provider burden
sharing data through the APIs referenced in this final rule. There are
IT solutions available for providers' EHRs or practice management
systems, such as SMART on FHIR apps, which can make the data received
via the APIs actionable and avoid duplicative information. We also note
that standards for ADT data are outside the scope of this final rule.
Comment: A commenter highlighted that health IT challenges can
sometimes be larger than they appear. The commenter stated that
regulatory requirements can be tailored to coincide with health IT
functionalities that are currently available to support organizations
in accomplishing interoperability in a more affordable way.
Response: We thank the commenter for their input and will continue
to closely coordinate with industry to decrease implementation burden
wherever possible.
Comment: A commenter urged CMS not to finalize the interoperability
proposals until stakeholders have had a chance to review and comment on
ONC's HTI-1 proposed rule, which was still under review at the Office
of Management and Budget (OMB) at the time of publication of the CMS
Interoperability and Prior Authorization proposed rule.
Response: We recognize that commenters are interested in ONC
policies that relate to the policies in the proposed rule. ONC has
since published the HTI-1 final rule. While related, these rules
address separate areas of CMS and ONC authority. We are not finalizing
any modifications from the proposed rule based on HTI-1 other than
updating our regulatory citations and incorporating expiration dates
ONC has finalized for particular standards at 45 CFR 170.215.
Therefore, we did not offer an additional comment period.
Comment: Multiple commenters expressed appreciation for CMS not
requiring health IT certification for the interoperability requirements
outlined in this proposed rule. A commenter stated that establishing
certification criteria based on the current HL7 Da Vinci IGs is
premature. The commenter noted that providers must use data from CEHRT
for the electronic prior authorization measure, which will serve as a
spur for adoption of certified health IT. Another commenter noted that
some of the proposed APIs require multiple health IT systems to
interact and support a complex workflow and stated that establishing a
certification approach using functional capabilities would be
challenging, and encouraged CMS to engage with providers and payers to
gather information to establish a well-defined and scalable set of
guidelines and capabilities.
Opposite to that, a commenter recommended that CMS work with ONC to
incorporate new standards and requirements for API use by EHR vendors
as certification criteria in the ONC Health IT Certification Program.
Response: We did not propose and are not finalizing any other
requirements related to certification under the ONC Health IT
Certification Program in this final rule. However, we note that the
Unified Agenda, at the time of this final rule's publication, includes
an entry for a proposed rule from ONC (RIN 0955-AA06).\181\ The
description indicates that that proposed rule aims to advance
interoperability, including proposals to expand the use of certified
APIs for electronic prior authorization. We plan to continue to explore
how potential updates to the ONC Health IT Certification Program could
support our policies and will address any updates to our requirements
related to the Certification Program in future rulemaking.
---------------------------------------------------------------------------

\181\ Office of Information and Regulatory Affairs (n.d.).
Health Data, Technology, and Interoperability: Patient Engagement,
Information Sharing, and Public Health Interoperability. Retrieved
from https://www.reginfo.gov/public/do/eAgendaViewRule?pubId=202304&RIN=0955-AA06.
---------------------------------------------------------------------------

Comment: A commenter recommended that CMS should establish a
consistent set of technical standards between the TEFCA and CMS-
required APIs so that the industry does not have to implement multiple
different standards depending upon the exchange partner or mechanism
for exchange.
Response: We refer readers to section II.B. of this final rule for
a discussion on the interaction between policies that require API
development or enhancement and TEFCA.
Comment: A commenter recommended CMS consider a policy requiring
third-party payers, benefit managers, and any other party conducting
utilization management to accept and respond to standard electronic
prior authorization transactions for pharmacy benefits that use a
nationally recognized format, such as the NCPDP SCRIPT standard.
Similarly, another commenter stated that CMS should encourage health IT
vendors and developers to provide retail pharmacies with technical IT
infrastructure to bridge the gap between pharmacy claim systems and
medical benefit claims systems and noted that many retail pharmacies
only utilize the NCPDP standards and do not have the capability to
enroll as DME suppliers and submit claims using X12 transactions.
Another commenter recommended that CMS explore the need to designate an
electronic transaction standard for drugs covered under a medical
benefit.
Response: We appreciate stakeholders' interest in pharmacy
standards and bridging the gap between pharmacy and medical benefit
systems and we recognize the need to do so in the future. However, as
noted in section I.D.3., standards for data exchange for any pharmacy
claims and drugs covered under medical benefits are excluded from our
policies and out of scope for this rule.
Comment: A commenter stated that under the ONC Health IT
Certification Program, APIs must be registered within 15 days (45 CFR
170.315(g)(10)). However, the commenter stated that CMS did not impose
any registration requirements for the proposed payer

[[Page 8934]]

APIs. The commenter recommended that CMS should consider imposing a
reasonable registration period for APIs to address delays reported by
CARIN members throughout the onboarding and authorization process to
acquire test accounts, sandbox access to test API connections, and
troubleshooting support.
Response: We did not propose registration deadlines as a
requirement for payer APIs in the same fashion as the health IT
certification criterion at 45 CFR 170.315(g)(10), such that Health IT
Modules certified to 45 CFR 170.315(g)(10) must register patient-facing
applications within 15 days (per associated requirements at 45 CFR
170.404(b)); however, we acknowledge that such requirements can help to
support the usability of APIs. We may further explore how to
incorporate registration deadlines into our API requirements in future
rulemaking.
Comment: A commenter recommended setting an implementation date
before January 1, 2026, and mandating HL7 FHIR Release 4.0.1. The
commenter also recommended operational enhancements for payers such as
payers allowing longer lifespans on access tokens, payers not imposing
unsupported security and authentication workflows, and payers
supporting test accounts and synthetic data in production environments.
The commenter noted that these recommendations would dramatically
improve access to data from available open APIs while setting standards
for payers and their interoperability vendors to follow.
Response: HL7 FHIR Release 4.0.1 has already been adopted by HHS in
the ONC Cures Act final rule at 45 CFR 170.215 (85 FR 25521). We will
continue to work with payers on testing and implementation of their
interoperability APIs through FHIR Connectathons and encourage
stakeholders to participate in FHIR workgroups. We will explore
additional enhancements through future rulemaking.
Comment: A commenter recommended using the most recently approved
HL7 Da Vinci IG that supports HL7 FHIR Release 4.0.1. The commenter
stated that the SMART App Launch IG does not support HL7 FHIR Release
4.0.1.
Response: We thank the commenter for their recommendation, but we
disagree that the SMART App Launch IG does not support HL7 FHIR Release
4.0.1, as the SMART App Launch IG is built on top of the FHIR Release
4.0.1 specification itself. The SMART App Launch IG specifies a number
of capabilities, including user authentication and authorization, back-
end service authentication, application launch, and context sharing,
that systems can use to interact within the FHIR R4 standard.
Comment: A commenter sought clarification on the use case for the
Bulk Data Access IG for the Patient Access API, since one of the
biggest challenges for EHR vendors today is determining how to handle
inbound data exchanged via the FHIR standard.
Response: We did not propose, nor are we finalizing, a requirement
to require the Bulk Data Access IG for the Patient Access API.
b. Additional Implementation Guide Discussion
In the proposed rule, we discussed that several of the recommended
IGs, such as HL7[supreg] FHIR[supreg] Da Vinci Payer Data Exchange
(PDex) IG, build on specific profiles within the US Core IG (87 FR
7615). Following the publication of the HTI-1 final rule, at 45 CFR
170.215(b)(1) there are two adopted versions of the US Core IG: the US
Core IG STU 3.1.1 (at 45 CFR 170.215(b)(1)(i)), until this standard
expires on January 1, 2026, and the US Core IG STU 6.1.0 (at 45 CFR
170.215(b)(1)(ii)). We only proposed to require US Core STU 3.1.1
because it was the only version adopted at the time of the proposed
rule. However, we recognize that some of the recommended IGs (and
subsequent versions) may use profiles added in US Core IG STU 6.1.0.
Payers can use updated versions of the recommended IGs that rely on
newer versions of the US Core IG, if those updated versions meet our
existing requirements finalized in the CMS Interoperability and Patient
Access final rule (85 FR 25532), as discussed further below.
Specifically, in the proposed rule, we recognized that the data
content for each API may only require a subset of the profiles defined
within the US Core IG and gave examples (87 FR 76314-76315). While we
want to ensure that implementers' systems create FHIR resources
conformant to the US Core IG, where applicable, to support
interoperability across implementations, we also do not want to require
payers to engage in unnecessary development. Therefore, we proposed and
are finalizing that impacted payers are only required to use technology
conformant with the US Core IG, where applicable (that is, where there
is a corresponding FHIR resource to the data content requirements for
the API). If a FHIR resource is part of the required data content and
has been profiled by the US Core IG, then the payer must support the
FHIR resource according to the FHIR resource profile's ``Structure
Definition'' in the US Core IG. For example, because the ``Patient''
FHIR resource is required in the Patient Access API, the ``Patient''
FHIR resource must conform with the ``US Core Patient Profile,''
including all the ``mandatory'' and ``must support'' requirements
specified in the US Core IG.
c. Using Updated Versions of Required Standards
In the CMS Interoperability and Patient Access final rule (85 FR
25510), we established that impacted payers could use an updated
version of a required standard for the Patient Access or Provider
Directory APIs under certain conditions. Payers may use updated
versions of standards at 45 CFR 170.213 and 170.215 if the following
conditions are met: (1) the National Coordinator has approved the
updated version for use in the ONC Health IT Certification Program, (2)
the updated version of the standard does not disrupt an end user's
ability to access the required data via that API, and (3) the updated
standard is not prohibited by law (85 FR 25522). Payers may use an
updated version if required by other applicable law. We proposed to
extend this policy to allow payers to use updated versions of a
standard to the Provider Access, Payer-to-Payer, and Prior
Authorization APIs. Under that proposal, impacted payers could upgrade
to newer versions of the required standards, subject to those limiting
conditions (87 FR 76315).
One of those conditions for using updated versions of the standards
at 45 CFR 170.213 and 170.215 is that the National Coordinator has
approved the updated version for use in the ONC Health IT Certification
Program. The National Coordinator approves updated versions of
standards in the ONC Health IT Certification Program through SVAP,
pursuant to 45 CFR 170.555, which was finalized in the ONC Cures Act
final rule as a Maintenance of Certification flexibility included in
the real-world testing Condition of Certification (85 FR 25775). This
flexibility permits health IT developers to voluntarily use, in certain
certified Health IT Modules, newer versions of adopted standards so
long as specific conditions are met, providing a predictable and timely
approach within the ONC Health IT Certification Program to keep pace
with the industry's standards development efforts.
Under SVAP, after a standard has been adopted through notice and
comment rulemaking, ONC engages in

[[Page 8935]]

an open and transparent process to timely ascertain whether a more
recent version of an adopted standard or implementation specification
should be approved by the National Coordinator for developers'
voluntary use in the ONC Health IT Certification Program. ONC publishes
updated versions of standards under consideration for SVAP and lists
the updated versions of standards that the National Coordinator has
approved as part of the Interoperability Standards Advisory on
HealthIT.gov.\182\ Members of the public can use this resource to
review standards that may be approved through SVAP in the future, as
well as provide input on which updated versions should be approved. We
encourage impacted payers to review these resources to better
understand how updated versions of the standards at 45 CFR 170.213 and
170.215 may be approved by the National Coordinator through SVAP and
become available for payers to use in their APIs, provided other
specified conditions for using updated standards are met. Several
updated versions of the standards currently at 45 CFR 170.213 and
170.215 have been approved by the National Coordinator through
SVAP,\183\ including USCDI v2 and v3; US Core IG STU 4.0.0, 5.0.1, and
6.1.0; SMART App Launch IG Release 2.0.0; and Bulk Data Access IG
v2.0.0: STU 2. As soon as the National Coordinator approves updated
versions through SVAP, we consider the updated versions to have met
this condition for use by impacted payers for our API requirements. We
emphasize that if impacted payers choose to use updated standards, it
must not disrupt an end user's ability to access the required data. We
are finalizing this proposal, as proposed.
---------------------------------------------------------------------------

\182\ Office of the National Coordinator for Health Information
Technology (n.d.). SVAP. Retrieved from https://www.healthit.gov/isa/standards-version-advancement-process.
\183\ 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 support for CMS's proposal
to allow flexibility for payers to use updated versions of certain
standards and specifications required for APIs in the proposed rule. A
commenter expressed support for aligning standards between the Patient
Access, Provider Access, and Payer-to-Payer APIs, as this ensures data
compatibility between use cases. Another commenter stated that the
standards and specifications at 45 CFR 170.215 are more advanced and
better aligned with present efforts to streamline prior authorization
workflows by leveraging HL7's FAST work. Another commenter stated that
these standards support widespread interoperability, ease
implementation, and minimize complexity and costs. A commenter
expressed strong support for CMS's efforts to promote portability of
patients' EHI between providers and payers to assure continuity of care
by further building on the common standards platform of FHIR APIs using
USCDI, where applicable. Multiple commenters expressed support for the
continued alignment between CMS and ONC regarding updates to technical
standards and specifications through the rulemaking process.
Response: We acknowledge and thank commenters for their support of
our policies.
Comment: A commenter stated that CMS's approach to mandating
technical standards by referencing specific standards in regulation is
novel for health information exchange. The commenter stated that prior
data exchanges, such as the HIPAA standard transactions or the machine-
readable files, have everything defined in the named specifications and
not defined by reference to another standard in regulation. The
commenter stated that having standards specified elsewhere allows for
the referenced standards to be changed which would then have the
cascading effect of requiring changes in all the APIs on the timeframe
of the standard change for the APIs to remain conformant. The commenter
disagreed with this regulatory approach and stated that it is better to
have each API specified separately and to be self-contained (that is,
not having referenced standards). The commenter stated that this way
individual APIs could be evaluated for change on their own merits, as
standards in the HIPAA Standards for Health Care Attachments proposed
rule are currently being evaluated with the potential change in the
version for the X12 278 transaction standard for attachments under
HIPAA (version 6020) or for the X12 837 transaction standard for
claims, and the X12 835 transaction standard for remittance advice
being recommended by X12 for consideration to X12 8020 transaction
standard for plan premium payments, or the recommended upgrade of three
other X12 transactions to version 8030, including claim status, health
plan enrollment, and health plan premium payments.
Response: We appreciate the commenter's concerns regarding the
timing of updates to required standards via reference to other
regulations. We intend to collaborate with ONC to ensure updates to
standards are deployed with reasonable timeframes and sufficient
advance notice for payers to make any required updates to their APIs.
Aligning with the HHS-adopted API standards and associated
implementation specifications at 45 CFR 170.215 is important to ensure
consistency. We are finalizing the versions of the required standards
that were at 45 CFR 170.215 at the time of this proposed rule. However,
ONC has since finalized the HTI-1 final rule (89 FR 1192), which
adopted updated versions of certain standards including the US Core IG
STU 6.1.0 (at 45 CFR 170.215(b)(1)(ii)) and the SMART App Launch IG
Release 2.0.0 (at 45 CFR 170.215(c)(2)). Additionally, ONC has
finalized expiration dates for the US Core IG STU 3.1.1 (at 45 CFR
170.215 (b)(1)(i)) and the SMART App Launch Framework IG Release 1.0.0
(at 45 CFR 170. 215(c)) to indicate when a version of a standard may no
longer be used. We intend to align with the updated versions finalized
at 45 CFR 170.215 through future rulemaking prior to the API compliance
dates. While we did not propose to require those updated versions, we
emphasize that impacted payers are permitted to use them based on our
policy to allow updated versions of required standards, as discussed
below.
The update and review process for HIPAA transaction standards
follows a statutory review process but does not include the same
testing and balloting process we require for the standards and IGs.
Furthermore, the HL7 standards and IGs adopted by ONC may be updated
for use in the ONC Health IT Certification Program through the SVAP. We
rely on this flexibility in our update policy by allowing payers to use
versions of standards at 45 CFR 170.213 and 170.215 that have been
approved by the National Coordinator, enabling a nimble approach to
industry testing and innovation. This does not currently exist under
the HIPAA standard transaction reference model process.
Comment: Multiple commenters recommended that CMS update the
clinical data requirements to USCDI v2. The commenters also recommended
that CMS give guidance on if and when USCDI v3 and v4 may be required.
The commenters noted that use of these updated standards would advance
health equity and public health work. A commenter strongly recommended
that impacted payers incorporate data elements identified in a newer
version of the USCDI, specifically USCDI v3, instead of the proposed
USCDI v1. The commenter noted that USCDI v1 does not constitute an
elaborated list of data

[[Page 8936]]

elements compared to the most recent versions, which incorporate
elements that play a critical role in electronic data exchange. Another
commenter requested CMS and ONC provide guidance regarding using newer
versions of USCDI and associated US Core IG. The commenter noted that
this guidance will be helpful when multiple versions of the USCDI are
available for use, so all third-party app developers have clear
expectations and understanding regarding what data they need to be able
to share and receive.
Response: As discussed in section II.A.2.d., we are finalizing a
change to the required data content for the Patient Access, Provider
Access and Payer-to-Payer APIs to a standard listed at 45 CFR 170.213.
At the time of the CMS Interoperability and Prior Authorization
proposed rule, USCDI v1 was the only version of the USCDI adopted at 45
CFR 170.213. However, ONC has since published the HTI-1 final rule,
which establishes a January 1, 2026, expiration date for USCDI v1 and
adopts USCDI v3 at 45 CFR 170.213. After January 1, 2026, USCDI v3
would be the only version specified at 45 CFR 170.213 that has not
expired (89 FR 1192). In this way, the required version of the USCDI
for the APIs in this final rule will advance in alignment with versions
adopted by ONC in 45 CFR 170.213. When more than one version of USCDI
is adopted at 45 CFR 170.213 and have not expired, payers may conform
to either version.
As stated previously in this section, we are also finalizing our
proposal that an updated version of a standard could be used if it is
required by other law, or if ONC has approved the updated version for
use in the ONC Health IT Certification Program, users are able to
access the required data via the API, and it is not prohibited by other
law. In order to identify updated standards that have been approved for
use in the ONC Health IT Certification Program, payers can review the
standards approved through the SVAP on ONC's website https://www.healthit.gov/isa/standards-version-advancement-process, as well as
standards that are being considered for approval through SVAP (new
standards for SVAP are approved annually).
We note that USCDI v2 was approved in the 2022 SVAP cycle, while
USCDI v3 was approved as part of the 2023 SVAP cycle.\184\ We also note
that several updated versions of the US Core IG subsequent to the
required US Core IG STU 3.1.1 have been approved by the National
Coordinator through the SVAP and are available for payers to use under
this policy, including US Core IG STU 4.0.0, 5.0.1, and 6.1.0.\185\
---------------------------------------------------------------------------

\184\ 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.
\185\ 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.
---------------------------------------------------------------------------

The US Core IG is updated annually to reflect changes to the USCDI,
and each US Core IG version is built to a specific version of the
USCDI. For instance, US Core IG STU 3.1.1 is built to USCDI v1 and the
US Core IG STU 6.1.0 is built to USCDI v3. As the recommended IGs
continue to be refined and advance, they may reference different
versions of the US Core IG based on updated versions of the USCDI.
Implementers are encouraged to adopt the newer versions of the
recommended IGs as they are published. Consistent with our final
policies to allow payers to use updated standards at 42 CFR 170.215 if
they have been approved by the National Coordinator for use in the ONC
Health IT Certification Program and other conditions, implementers may
use updated versions of US Core referenced to the specifications in
recommended IGs. HL7 and the FHIR Accelerators are aware of these
concerns and are working on an approach to enable greater version
support for IGs.
Comment: Multiple commenters supported flexibility to use updated
standards, such as ONC's SVAP for certified health IT developers, to
allow payers to use the most current recognized versions of vocabulary
standards and interoperability standards or specifications used in the
certification. A commenter stated that CMS should only require new
versions of standards, specifications, and IGs after testing and
adequate time for implementation. Another commenter stated that the
mechanism to allow implementers to advance versions of standards in
this rule as long as using an updated standard does not impair access
to data through the API can be used for any or all IGs used to support
these APIs or related auxiliary processes (for example, patient
attribution).
Response: We appreciate the support for this policy. The standards
we are requiring in this final rule are those that we believe are
sufficiently mature. We intend for future rulemaking to operate
similarly. As stated, payers can implement the latest versions of the
required standards and IGs as long as they meet the specified
conditions, such as not impairing access to data through the API.
Comment: Multiple commenters stated that use of specific FHIR-based
standards, specifications, and IG versions should align with those
approved by ONC through SVAP. A commenter stated that CMS requirements
and adoption timelines should remain coordinated with ONC's
progression. The commenter suggested that CMS use a more general
reference to the ONC Health IT Certification Program and SVAP. Another
commenter stated that ONC will be providing a more current set of
standards and specification versions soon through ONC Health IT
Certification Program updates. The commenter stated that it is
imperative that CMS require developed APIs to conform to the most
recently approved SVAP standards within 12 months of approval. The
commenter also recommended that CMS coordinate with ONC to include more
standards and IGs in the SVAP to align with the rule. The commenter
also recommended that CMS include a transition period (for example, 12
months).
Response: We appreciate the commenters feedback and remind readers
that under this final rule, in addition to our coordination with ONC,
payers are permitted to voluntary use updated standards provided it
does not disrupt an end user's ability to access the data available
through the API. In addition, implementers may advance to those
standard versions approved by the ONC through SVAP.
We decline at this time to set a timeline by which we would require
impacted payers to use the updated version of the standard rather than
the adopted version of the standard. We believe the voluntary nature of
the SVAP supports a transitional period--also a request from
commenters--by allowing for a flexible implementation of standards
versions between regulatory cycles during which ONC revises the adopted
version to the latest update for each standard. We will continue to
engage with patients, providers, payers, health IT developers, and our
Federal partners to ensure that this approach balances the need to
advance standards with the need for flexible transition periods for
updates. We will also continue to work with ONC in their efforts to
support HHS and the health care industry through the advancement and
adoption of interoperable standards and implementation specifications
for a wide range of health IT use cases.
We support innovation and continued efforts to refine standards in
a way that will leverage the most recent technological advancements.
Thus, we also sought comment on the process we

[[Page 8937]]

should use to adopt or allow new versions of standards and
implementation specifications over time. We received many comments in
response to our request for comment and will consider this feedback for
future rulemaking and guidance. We are finalizing the proposal to allow
payers to use an updated standards, specifications, or IGs if required
by law, or if the updated standard, specification, or IG is approved
for use in the ONC Health IT Certification Program, do not disrupt an
end user's ability to access the required data, and is not prohibited
by law for each of the APIs at the CFR sections listed in Table H2.
3. Recommended Standards To Support APIs
In the CMS Interoperability and Patient Access final rule (85 FR
25529), we noted that there are publicly available IGs that provide
implementation information that impacted payers can use to meet the
regulatory requirements for these APIs. Using those IGs supports
interoperability and allows impacted payers to avoid developing an
approach independently, which could save time and resources. In this
final rule, we are recommending specific IGs that are relevant to each
of the APIs, which may be used in addition to the required standards at
45 CFR 170.215.
In the December 2020 CMS Interoperability proposed rule, we
proposed to require impacted payers to use certain IGs, including the
CARIN IG for Blue Button[supreg], HL7[supreg] FHIR[supreg] Da Vinci
PDex IG, HL7[supreg] FHIR[supreg] Da Vinci PDex U.S. Drug Formulary IG,
HL7[supreg] FHIR[supreg] Da Vinci PDex Plan Net IG, HL7[supreg]
FHIR[supreg] Da Vinci Coverage Requirements Discovery (CRD) IG,
HL7[supreg] FHIR[supreg] Da Vinci Documentation Templates and Rules
(DTR) IG, and HL7[supreg] FHIR[supreg] Da Vinci Prior Authorization
Support (PAS) IG (85 FR 82586) to support the APIs in that proposed
rule. As discussed in section I.A. of this final rule, we are
withdrawing the December 2020 CMS Interoperability proposed rule. We
also noted that these IGs continue to be developed and refined through
the HL7 ballot and standard advancement process to better support the
Patient Access, Provider Access, Payer-to-Payer, and Prior
Authorization APIs.
a. Recommending vs. Requiring Implementation Guides
In the CMS Interoperability and Prior Authorization proposed rule,
we proposed to recommend CARIN for Blue Button, PDex, PDex U.S. Drug
Formulary, PDex Plan Net, CRD, DTR, and PAS IGs for specific APIs, as
listed in Table 10 of the proposed rule (87 FR 76320). We also
solicited comments on whether CMS should propose to require these
recommended IGs in future rulemaking and other ways that we could
support innovation and interoperability. We emphasize that while we are
not requiring payers to use the recommended IGs listed in Table H3, we
may propose requiring payers to use these and other IGs in future
rulemaking, should they reach sufficient maturity.
After careful consideration of the versions of the IGs that were
available at the time of the proposed rule, we determined that we were
not ready to propose them as requirements. We stated that we believed
these IGs would continue to be refined over time as interested parties
have opportunities to test and implement them, and as such, we chose to
recommend them rather than require them. Specifically, we stated we
would continue to monitor and evaluate the IG development and consider
whether to propose them as a requirement at some future date. In this
final rule, we are finalizing our recommendation to use the CARIN for
Blue Button, PDex, PDex U.S. Drug Formulary, PDex Plan Net, CRD, DTR,
and PAS IGs for the Patient Access, Provider Access, Provider
Directory, Payer-to-Payer, and Prior Authorization APIs, as applicable
and listed in Table H3. We also note that several of the recommended
IGs have had updated versions published since the CMS Interoperability
and Prior Authorization proposed rule. Thus, we have updated Table H3
accordingly to represent the most recent published versions of the
recommended IGs. Because these are only recommended IGs, we do not
codify version updates through rulemaking.
We acknowledge that by recommending rather than requiring certain
IGs, there is potential for implementation variation that could limit
interoperability and ultimately lead to rework for implementers if
requirements are introduced later. However, we concluded at the time of
the proposed rule that it was more important to not require the IG
versions available at that time due to the maturity of the versions
available. We recommended, but did not propose to require, these IGs
because we wanted to ensure that implementers can use subsequent
versions of these IGs without being restricted to the version available
when we issued the notice of proposed rulemaking. As discussed in
section II.G.2.c. of this final rule, we are finalizing a provision to
allow payers the flexibility to use updated versions of certain
standards required for the APIs in this final rule. In the CMS
Interoperability and Prior Authorization proposed rule (87 FR 76316),
we acknowledged that subsequent versions of the recommended IGs may
include substantial changes that would not be consistent with the
requirement that an updated standard must not impair access to data
through the API. We intend to monitor IG development and may propose to
require specific IGs at a future date and/or allow for voluntary
updates under our flexibility policies. We received comments on our
decision to recommend, rather than require the listed IGs in the
proposed rule.
Comment: Multiple commenters appreciated CMS's decision to
recommend rather than require the CARIN for Blue Button, PDex, PDex
U.S. Drug Formulary, PDex Plan Net, CRD, DTR, and PAS IGs. A commenter
supported CMS's decision to recommend instead of requiring IGs given
that some of the standards and IGs are not yet mature enough for
industry adoption. Another commenter appreciated CMS's decision to
recommend rather than require IGs due to the interplay between this
rule and the HIPAA Standards for Health Care Attachments proposed rule.
Response: We thank commenters for their support of our decision to
recommend certain IGs in the proposed rule, which we believe balanced
the need to provide guidance and flexibility to industry as standards
advance.
Comment: Multiple other commenters supported the recommended IGs,
but noted concern that these IGs do not have enough outside involvement
in the development phase, which could result in gaps in workflows.
However, the commenters noted that they are confident that the HL7
Accelerator workgroups will provide the necessary maturity if given
sufficient time.
Response: These standards development activities do have outside
parties involved throughout the standards development process. We
encourage all interested parties, especially those who already have the
experience implementing the APIs, to engage with the process. HL7 and
the Accelerators welcome and solicit feedback for all of their IGs and
specifications. Meeting participation is largely open to the public,
and one does not have to be a member to participate in testing events
and many other standards development activities.
Comment: Multiple commenters disagreed with CMS's decision to
recommend rather than require the IGs and expressed concern for CMS's
decision to not require certain IGs, with

[[Page 8938]]

one concerned that not requiring the IGs will impact the level of
interoperability necessary to support data exchange. Commenters urged
CMS to consider the potential for implementation variation in APIs and
limit industry-wide interoperability. Multiple commenters expressed
that it is important that adherence to IG requirements is required, not
just encouraged, to ensure the industry adopts these to obtain the
benefits of the near real-time Prior Authorization API transactions.
Another commenter recommended that CMS adopt and require IGs as quickly
as possible. The commenters stated that without IGs, there is a risk
that early work done by health IT developers and the health care
community will have to be refactored or restarted to meet the IG
guidelines. A commenter stated that CMS should act swiftly to encourage
the creation of more appropriate IGs and recommended that CMS work with
payers to create electronic systems and interfaces that are consistent
and easy to use.
Another commenter stated that not requiring certain IGs is not in
line with the interoperability goals and prior authorization
initiatives outlined in this rule to obligate providers to report on
their adoption of this technology if that technology will not be
uniformly adopted and implemented between different payers. A commenter
stated that it is critical that all data contributors be held to the
same set of rules and required to adopt the same standards and IGs. To
ameliorate this, the commenter recommended that the IGs be required
rather than recommended, and that a mere recommendation may result in
more burden and duplicative work. A commenter stated that because CMS
is not requiring certain IGs, it is unfair and contrary to the goals of
these interoperability and prior authorization initiatives to obligate
MIPS eligible clinicians, eligible hospitals, and CAHs to report on
their adoption of this technology when that technology will not be
uniformly adopted and implemented between different payers.
Multiple commenters recommended that CMS require impacted payers to
use the CARIN for Blue Button, HL7[supreg] FHIR[supreg] Da Vinci
Patient Coverage Decisions Exchange (PCDE), PDex, PDex U.S. Drug
Formulary, PDex Plan Net, CRD, DTR, and PAS IGs while allowing for
adaptability and advancement of those IGs over time. A commenter stated
that requiring certain IGs would move payers toward standardized data
exchange. A commenter noted that most of the IGs have been around for
several years, and most have been tested in multiple Connectathons,
pilot projects, and in production environments. The commenter believes
having consistent, well-understood data fields with clear meaning that
everyone uses the same way is a key element of any API or any
successful data exchange. The commenter stated that using standard IGs
would move industry toward interoperable data exchange.
Response: We received a significant number of comments on both
sides regarding requiring IGs and not requiring IGs, which indicates
that there is not broad agreement across the industry. In the proposed
rule, we sought to strike a balance by requiring the standards and IGs
adopted at 45 CFR 170.215 in alignment with ONC and recommending
additional IGs for each API implementation. We acknowledge that by not
requiring all the available IGs, there is potential for implementation
variation in these APIs that could limit interoperability and
ultimately lead to re-work for implementers if requirements are
introduced later. However, at the time of the proposed rule, we
believed it was more important not to require these IGs while they were
still undergoing additional enhancements. We disagree with the concern
that our decision to not propose to require certain IGs is unfair and
contrary to the goals of these interoperability and prior authorization
initiatives of this final rule. The required standards at 45 CFR
170.215 mean that impacted payers must implement these APIs using the
FHIR standard, which will advance interoperability. We continue to
strongly recommend using the other recommended IGs listed in Table H3.
As stated previously, we also believe that the approach in the
proposed rule of recommending, but not requiring, the specific IGs and
versions provided directional guidance with flexibility to the industry
in order to allow for additional improvements to be made without
locking implementers into versions of the IGs available at the time of
the proposed rule. Under the recommendations in the proposed rule, as
these IGs progress, industry could continue to harmonize on common
approaches that work, eventually culminating in a required set of
specifications when ready through updates to CMS policy. To not
identify any specific IGs would have meant a more diverse set of
proprietary solutions with little to no interoperability. Our
recommendations provide direction to implementers.
Comment: A commenter stated that the development and maintenance of
standards and IGs are an extension of Federal policy that does not go
through the rulemaking process. They noted that it is critical that
this development and maintenance process be consensus-based, fair,
transparent, and open to all stakeholders. The commenter continued by
stating that the IG creation process is currently driven by a limited
number of volunteers that do not broadly represent the industry, which
results in IG resource and profile versioning issues. The commenter
stated that CMS should ensure there is no fee to fully participate in
the process for the regulatorily required exchanges and relying on an
American National Standards Institute (ANSI)-accredited process to
develop the IGs would improve the approach.
Response: We acknowledge that standards and IGs are not developed
through the rulemaking process. Rather, standards and IGs go through
the rulemaking process if and when they are proposed to be adopted. We
also appreciate that commenters are invested in the quality of the IGs
and the SDO, and affirm, as we stated in the CMS Interoperability and
Patient Access final rule (85 FR 25540), that development and
maintenance of standards are the purview of SDOs, and that interested
parties, including Federal agencies, participate in that process.
Stakeholders have the opportunity for review and comment on the
standards both at the time they are being developed, as well as during
the proposed rule comment period. HL7 is an ANSI-accredited \186\ SDO,
and Da Vinci is an accelerator workgroup under the umbrella of HL7 and
operates under the same rules of all ANSI accredited SDOs in the manner
in which they obtain consensus on standards. Furthermore, HL7 standards
are free and open-source, and documentation is available to anyone to
ensure that all developers can equally access information. Using these
freely available materials will reduce the development burden for both
payers and app developers and facilitate industry-wide
interoperability. Similarly, participation in online working meetings
and providing feedback as part of the standards development process is
free, and diverse organizational representation is critical to the
quality of the standards and IGs. Thus, we encourage as many
organizations as possible with a stake in the development and quality
of these guides to participate. HHS uses different authorities to adopt
and require standards that are developed and

[[Page 8939]]

maintained by organizations such as HL7 using the processes described
previously. For instance, ONC has adopted the standards and
implementation specifications at 45 CFR 170.215 cross-referenced in
this final rule under the authority of section 3004 of the Public
Health Service Act.
---------------------------------------------------------------------------

\186\ ANSI oversees standards and conformance of processes for
all SDOs. See American National Standards Institute (2023). ANSI.
Retrieved from https://ansi.org/.
---------------------------------------------------------------------------

Comment: A commenter suggested CMS emphasize that using the IGs is
not limited to literal use, but also interpretive use to model
interactions within the respective health IT configuration in a way
that is illustrative rather than prescriptive.
Response: IGs contain both SHALL and SHOULD statements, which
respectively indicate whether health IT systems must meet certain
requirements to conform to the IG or are just strongly recommended to.
While implementers will be required to conform with the required IGs we
are finalizing, we remind readers that the recommended IGs can be
implemented as they see fit as long as they meet the requirements of
the API.
b. Implementation Guide Maturity
In the proposed rule, we welcomed further information about the
maturity of the recommended IGs, including considerations about further
development that may be needed prior to us proposing to require the IGs
we recommended (87 FR 76317).
Comment: Multiple commenters expressed concern regarding the
maturity, scalability, and real-world testing of the IGs recommended in
the proposed rule. Multiple commenters were concerned that there may be
compatibility issues between the current and future versions of the IGs
given that the IG versions are not currently finalized. A commenter
stated that slight variations in API implementation could significantly
increase burden placed on the provider community. A commenter
recommended that CMS and ONC issue guidance on what could be expected
in the IG guidelines to inform early work and to encourage as much
fidelity to these IGs as possible.
Response: We are committed to continuing to work with HL7, the
Accelerators, and interested parties within the industry to define,
participate in, and convene testing events, as well as developing and
maintaining the specifications, thereby moving them toward greater
maturity. We acknowledge that, as with any standard, potential
compatibility issues could arise throughout development. These
standards are subject to a standards development process where changes
are reviewed and compatibility is an important consideration,
increasing with the level of use and adoption. As IGs mature, the
number of potential compatibility issues between versions is expected
to decrease. Likewise, as IGs continue through the standards
development process, they will be enhanced to address areas of variance
among payers that are barriers to interoperability. We determined that
it was important to recommend these IGs to move the industry and
provide direction towards a common set of specifications, as opposed to
not including these recommendations, which would lead to a greater
number of variations and cause a greater burden.
Comment: A commenter recommended that CMS explain that support for
SMART Backend Services specification is also required with the Bulk
Data Access IG. Another commenter stated that significant limitations
exist for the Bulk Data Access IG and OpenID Connect Core standard. The
commenter noted that it is unknown when the Bulk Data Access IG will be
ready for implementation and use on a large scale.
Response: The Bulk Data Access IG v1.0.0: STU 1 includes the option
for SMART Backend Services specification to enable system-to-system
authentication and authorization of backend services. The Backend
Services specification that was included in Bulk Data Access IG v1.0.0:
STU 1 was moved to SMART App Launch IG Release 2.0.0. Therefore, we
strongly recommend that the SMART Backend Services specification of the
SMART App Launch IG Release 2.0.0 be supported and thus have included
this recommendation for both the Provider Access and Payer-to-Payer
APIs in Table H3. We acknowledge that not all connections may use
backend services, but when such services are available, payers may wish
to use the HL7 SMART Framework. More recent versions of the SMART App
Launch IG specification, starting with Release 2.0.0, incorporate the
SMART Backend Services, which ONC has adopted in the HTI-1 final rule
at 45 CFR 170.215(c). We further remind readers that though we are
requiring impacted payers to support Bulk Data Access IG for the
Provider Access and Payer-to-Payer APIs in this final rule (Table H3),
payers are free to set their own criteria for using bulk data exchange.
Comment: A commenter recommended that CMS delay API implementation
until the recommended IGs are ready to be required. The commenter noted
that the proposed APIs are not feasible without standardized adoption
and expressed concern that the necessary IGs to implement the APIs are
not mature, tested, or ready to scale. A commenter suggested that CMS
should work with interested parties across the health IT community to
propose and finalize IGs that are not mature prior to mandating their
use.
Response: We remind readers that we are finalizing 2027 compliance
dates for the policies that require API development and enhancement
partly to allow industry additional time to implement the needed
functionality within their internal systems. By requiring some IGs and
recommending others, we believe that we achieved the appropriate
balance between moving industry forward, while allowing flexibility for
continued development of IGs that were not sufficiently mature at the
time of the proposed rule to propose to require.
Comment: A commenter encouraged CMS to take on an active role in
the continued development and testing of the HL7 Da Vinci IGs. The
commenter recommended that CMS review and release a formal assessment
of the technology development no later than July 1, 2024.
Response: We are a member of HL7 and monitor their activities by
attending the HL7 Da Vinci workgroups, providing contract support for
the development of the IGs, and tracking the ballot process. Through
these efforts, we are continuously engaged in IG development and
maintenance. We thank commenters for their suggestion but note that the
request to release a formal assessment of technology development no
later than July 1, 2024, is out of scope for this final rule.
Comment: Multiple commenters urged CMS to identify a baseline or
``floor'' version of the technical standards and IGs, and multiple
other commenters recommended CMS develop a formal standards advancement
process, like the SVAP, to give industry the opportunity to continue
refining, testing, and deploying new versions. Multiple commenters
noted that requiring an updated version of an IG as a baseline
requirement must be done officially through government regulation.
Another commenter recommended CMS develop a strategy or a process to
decide which version of IGs or standards should be required. A
commenter believed that all interested parties should agree upon IGs
for each of the APIs. The commenter stated that in the final rule, CMS
should identify the requirements, including IGs, for all interested
parties. Another commenter recommended that CMS explain the
functionalities of specific

[[Page 8940]]

IGs they would like applied to each of the APIs.
Multiple commenters urged CMS to work with interested parties to
identify a limited number of IGs to require so industry is not
overwhelmed with too many IGs. Moreover, multiple commenters expressed
concern about requiring more than one IG for specific API
implementations and requested that CMS only require one IG. A commenter
noted they support clear and unambiguous standards to achieve true
interoperability.
Response: The required standards and recommended IGs for each of
the APIs are listed in Table H3 and represent the minimum expected of
impacted payers. The FHIR IGs have been developed to fulfill a specific
purpose and therefore requiring more than one IG for a specific API is
appropriate. Specifically, the IGs we are recommending all have
individual purposes and we are only recommending those relevant to each
API as listed in Table H3. We also remind interested parties that the
IGs go through a consensus-based process and participation in the
online meetings and providing feedback is free, thus, we encourage as
many organizations as possible with an investment in the development
and quality of these guides to participate.
Comment: Multiple commenters recommended that CMS explain how
technical standards and IGs will be mapped to specific API
functionalities.
Response: We refer readers to Table H3 for an outline of which
standards and IGs pertain to which APIs. We also remind readers that
our recommended IGs can support the required standards for the specific
API we are recommending them for.
Comment: Multiple commenters expressed support for work done by the
CARIN Alliance, which provides a method for all payers to make
submitted and processed claims data available to patients and has
sufficient maturity to ensure a successful implementation. Multiple
commenters requested that CMS consider mandating the CARIN IG for Blue
Button. A commenter stated that otherwise, stakeholders will have to
support multiple IGs, which adds burden and increases technology
complexity making development and implementation challenging. Multiple
commenters expressed support for clear and unambiguous standards.
A commenter stated the CARIN IG for Blue Button already produces an
EOB for in-patient, out-patient, professional, pharmacy, dental, and
vision services through a set of FHIR profiles. The commenter noted
that these same profiles could provide the required non-financial view
of the EOBs to meet the requirements outlined in this proposed rule by
using the ``Summary View'' returned by FHIR's summary parameter search.
Response: We agree about the importance of the CARIN Alliance's
work. However, for reasons explained in section II.G.3.a. of this final
rule, we did not propose to require several IGs which are listed in
Table H3 as Recommended IGs, including the CARIN IG for Blue Button.
Regarding the recommendation to leverage the non-financial view of a
CARIN IG for Blue Button, we note that in order to do this, the CARIN
IG for Blue Button would need to be updated, or other guidance provided
to support this requirement, and that the data be made available
through the appropriate API. Work is currently underway in CARIN and in
coordination with HL7 Da Vinci PDex workgroup to define this guidance.
Comment: A commenter noted that a September 2021 Frequently Asked
Questions (FAQ) \187\ document published by CMS states that payers
would be compliant with the Patient Access API requirements if they
used the CMS-recommended IG (CARIN for Blue Button IG v1.1.0: STU 1) to
build their APIs, but that that IG version does not enable the
inclusion of dental or vision claims, which were added in the most
recent version. Multiple commenters supported guidance or rulemaking to
support oral and vision claims using the CARIN IG for Blue Button
v2.0.0: STU 2 version.
---------------------------------------------------------------------------

\187\ Health Informatics and Interoperability Group (2021).
Patient Access API FAQ. Retrieved from https://www.cms.gov/priorities/key-initiatives/burden-reduction/faqs/patient-access-api.
---------------------------------------------------------------------------

A commenter recommended that CMS reaffirm that impacted payers
would be compliant with the requirements for the Patient Access and
Provider Access, and Payer-to-Payer APIs if they follow the CMS
recommended IGs. The commenter also recommended that CMS further
explain that the absence of dental and vision claims information in the
proposed APIs would not result in payer noncompliance given that the
recommended CARIN IG for Blue Button does not include dental and vision
claims.
Response: At the time the proposed rule was drafted, the CARIN IG
for Blue Button v1.1.0: STU 1 was the latest published version for use.
Since then, CARIN IG for Blue Button v2.0.0: STU 2 was released, which
indeed includes dental and vision (vision as part of the professional
and non-clinician profile). We are therefore modifying our
recommendation listed in Table H3 to ``HL7 FHIR Consumer Directed Payer
Data Exchange (CARIN IG for Blue Button) IG v2.0.0: STU 2.'' In
addition to the required standards listed in Table H3, if impacted
payers use the recommended IGs also listed in Table H3 for the APIs and
follow the IGs to specification to build their APIs, they would be
conformant with the technical requirements.
Comment: A commenter expressed support for exchanging data via FHIR
APIs and noted that the PDex IG STU 2.0.0 includes a prior
authorization profile to share prior authorization information, but
this profile is not yet published. However, another commenter noted
that the HL7 Da Vinci PDex workgroup is actively completing an initial
set of updates to the PDex IG to facilitate sharing prior authorization
information and that the workgroup will make any necessary revisions to
support the provisions outlined in the proposed rule to include any
related administrative and clinical documentation. Another commenter
was concerned that some of the proposed data elements for prior
authorization have not yet been profiled within FHIR IGs.
A commenter stated that payers should already have familiarity with
the PDex IG as it was recommended as part of the Patient Access API.
The commenter continued that using the PDex IG to support the new set
of information will also reduce burden.
Response: The recently published PDex IG STU 2.0.0 specification
\188\ does include a Prior Authorization profile that enables payers to
communicate prior authorization decisions and changes to the status of
a prior authorization requests. Based on feedback and developments in
the industry, in addition to the required IGs and previously
recommended IGs, we are now recommending the PDex IG STU 2.0.0. for the
Patient Access, Provider Access, and Payer-to-Payer APIs, as listed in
Table H3. We are delaying the compliance dates for the APIs finalized
in this rule to 2027, which allows for additional time for the FHIR
standard and IGs to continue to be refined and advanced to support all
of the policies in this final rule.
---------------------------------------------------------------------------

\188\ Health Level Seven International (2020). Da Vinci Payer
Data Exchange. Retrieved from https://hl7.org/fhir/us/davinci-pdex/STU1/.
---------------------------------------------------------------------------

Comment: A commenter noted that the proposed rule suggested that
the Provider Directory API finalized in the CMS Interoperability and
Patient Access final rule will be conformant with the PDex Plan Net IG
STU 1.1.0. A commenter stated their belief in

[[Page 8941]]

standards-based methods for the electronic transmission of health
information. The commenter continued that successful standards-based
conveyance of digital health care information relies on clear and
unambiguous standards that apply across the industry. The commenter
stated that the PDex Plan Net IG meets this requirement.
Response: We agree with commenters on the utility of the PDex Plan
Net IG, and are thus recommending its use for the Provider Directory
API.
Comment: Multiple commenters recommended CMS and HL7 ensure the
CRD, DTR, and PAS IGs are fully tested prior to the effective date of
the final rule, as the IGs have not been adequately or widely tested in
real-time clinical settings. A commenter expressed concern with
required versus situational data elements in the current versions of
the recommended IGs outlined in the proposed rule. The commenter noted
that the CRD, DTR, and PAS IGs have data elements and processes that
are listed as optional despite their utility for automation. Another
commenter provided the example that the CRD IG does not require the
return of documentation templates and rules, so the provider would be
required to initiate a separate transaction to determine the
requirements for a prior authorization. Additionally, this commenter
stated that the CRD IG allows for hyperlinks to be returned to the
provider. The commenter stated that this means that a valid response to
a coverage requirements discovery request can be a hyperlink to a
third-party prior authorization vendor where the provider would have to
initiate a prior authorization request through a provider portal and
drop to a manual process outside of their EHR and practice management
system.
Response: The HL7 Da Vinci IGs that we recommend specifically for
the Prior Authorization API are the CRD, DTR, and PAS IGs. These were
created as three distinct IGs that were loosely coupled instead of
created as a single IG in order to provide implementation flexibility
and the ability to disconnect the processes where necessary. A number
of optional or ``situational'' elements are included in these guides to
connect them into a single workflow where needed. While we value the
specificity of other comments regarding the functions of the IGs, such
as hyperlinks and connecting to external portals, these are the purview
of the HL7 Implementation division. We will work with HL7 and
implementers to coordinate appropriate support for such questions prior
to the compliance dates.
Comment: A commenter stated that it was their understanding that
the HL7 Da Vinci PCDE IG was developed with minimal payer input. The
commenter stated that there may be a need for additional time for
impacted payers to understand and implement the IG. Furthermore, the
commenter expressed concern that the PCDE IG only addresses the
movement of data between the provider and payer and does not address
the back-end systems that will need to ingest and process new
information for continuity of care. The commenter urged CMS to continue
exploring other opportunities to promote data exchange. The commenter
acknowledged that there are many industry solutions being developed to
facilitate the coordination of benefits between providers. The
commenter stated that these options could prove to be better solutions
for the industry in the future and recommended that CMS continue to
monitor and enable technical innovation in this area.
A commenter noted that CMS has included two mentions of the PCDE
IG. They stated that there is one reference in the preamble of the
proposed rule (87 FR 76336); however, in the preamble ``Payer Coverage
Decision Exchange'' is followed by a parenthetical reference to
``PDex.'' The commenter stated that the PCDE IG was also listed in
Table 10 (87 FR 76321), though, there are no additional or substantive
mentions of the PCDE IG in the proposed rule. The commenter believes
that it is possible the mention of the PCDE IG was unintentional.
Response: We acknowledge that the PDex IG has expanded to include
prior authorization data and development of PCDE IG is not currently
active. Thus, while we acknowledge the drafting error the commenter
previously noted, we are no longer recommending the PCDE IG for the
Payer-to-Payer API.
Comment: A commenter suggested that CMS consider recommending the
HL7[supreg] FHIR[supreg] Member Attribution (ATR) List IG, which is
currently in the publication process. The commenter stated this IG
focuses on attribution lists for risk-based contracts and it could
serve as an exchange standard for all payers.
Response: While we did not include the ATR List IG as one of
recommendations listed in Table H3, we note that industry expects that
the next version will be published well before the compliance dates for
API development and enhancement policies in this final rule. Payers are
permitted to use the ATR List IG, and we will explore including it,
either as a recommendation or requirement, in future rulemaking.
Comment: Multiple commenters recommended that CMS consider
leveraging the HL7 FHIR Da Vinci Reducing Clinician Burden (RCB) IGs. A
commenter shared that revisions to the RCB IGs are underway to make
prior authorization documentation supporting medical necessity, which
is assembled by the ordering provider, available to the performing
provider. The updated IG is currently titled FHIR Orders Exchange
(FOE), and updates should be balloted in the September 2023 SVAP cycle.
Another commenter stated that they believe RCB IGs would help industry
work towards future readiness for a certified Health IT Module(s) to be
included within the ONC Health IT Certification Program.
Response: We thank commenters for their suggestions and will
consider them for future rulemaking.
Comment: A commenter stated that the HL7[supreg] FHIR[supreg] Da
Vinci Clinical Data Exchange (CDex) IG would enable providers to obtain
additional information that may have been missing or not yet available
on the initial order request.
Response: Though we neither proposed nor recommended the CDex IG,
we recognize that the CDex IG is being developed to exchange
attachments via the Prior Authorization API. Impacted payers are
permitted to use the CDex IG and are encouraged to participate in the
ongoing testing as the IG is further developed. Though HL7 has included
the ability to exchange attachments in its suite of IGs, and this would
be available for use voluntarily, this final rule does not address
health care attachments. We will consider either requiring or
recommending the CDex IG in future rulemaking.
Comment: A commenter recommended using the HL7 Da Vinci DTR IG to
specify how payers codify their rules in clinical quality language for
real-time determination.
Response: We are currently recommending the DTR IG for the Prior
Authorization API. We will continue to monitor and evaluate the
development of the recommended IGs listed in Table H3 and consider
whether to propose them as a requirement at some future date.
c. Authentication and Authorization
Comment: Multiple commenters encouraged CMS to work with HL7 to
integrate the UDAP into the IGs created by HL7. A commenter stated that
a security framework based on a tiered OAuth security specification is
required

[[Page 8942]]

to enable the scalable exchange within trust frameworks. The commenter
stated that industry will not be able to implement at scale based on
how the standards were proposed and suggested CMS focus on making sure
this work is in place prior to making the APIs in the proposed rule
mandatory. In addition, the commenter stated that the HL7 Da Vinci PDex
IG depends on mTLS to establish the identity of each of the
organizations involved in the exchange while other payer-to-provider
and payer-to-patient exchanges rely on OAuth and the SMART framework.
Response: We thank the commenters for their responses and
understand their concerns. As discussed in section II.B. of this final
rule, we are currently supporting efforts to define the specifications
for authentication at scale through UDAP via the FAST Security IG and
mTLS through the PDex IG.
We acknowledge that authentication and authorization via user
credentials, using means such as OpenID Connect Core and OAuth 2.0, is
a requirement for APIs in which individually identifiable user access
is necessary, such as the Patient Access API. In order to use OpenID
Connect Core, each user would need to have credentials with the payer
(or delegated authentication/authorization entity) to access the API.
Thus, we are maintaining OpenID Connect Core 1.0 as a required standard
for the Patient Access API.
We recognize that while protocols involving specific user
credentials as managed by a payer could be used for the Provider Access
and Prior Authorization APIs, other protocols, such as SMART Backend
Services, mTLS, UDAP, or other trust community-specified means, may be
easier to implement at scale. Likewise, protocols requiring user level
credentials, managed by the payer, are generally not appropriate for
business-to-business data exchanges like the Payer-to-Payer API where
an individual may not be directly initiating the exchange. Therefore,
upon further consideration of our proposals, we are not finalizing
OpenID Connect Core (at 45 CFR 170.215(b)) as either a required or
recommended standard for the Provider Access, Payer-to-Payer, and Prior
Authorization APIs.
We are recommending SMART Backend Services Authorization for both
the Provider Access and the Payer-to-Payer APIs. However, payers will
be able to choose the protocols or combination of protocols they deem
appropriate as long as they meet appropriate security and privacy
requirements. We acknowledge that payers will likely use different
protocols, which could represent a barrier to enabling data exchange at
scale. Specifications such as UDAP and the tiered OAuth profile is an
available option for payers and may enable data exchange in a scalable
way by providing dynamic client registration and delegated
authentication potentially within and across trust communities. We
appreciate the comments, will continue to monitor the progress of UDAP
development and implementation, and will consider including it in
future rulemaking.
Comment: A commenter stated that the HL7[supreg] FHIR[supreg] Da
Vinci Health Record Exchange (HRex) IG Coverage Profile allows for
UDAP, which may be viable solution for authentication. The commenter
stated that the HL7 FAST STU 1 Security IG should be considered
foundational in the future for all IGs that require registration,
authentication, and authorization. Additionally, the commenter
suggested that CMS should explain that requiring handwritten signatures
continues to be appropriate when the impacted payer deems it necessary.
The commenter recommended that CMS should support industry discussions
and actions toward UDAP alignment across IGs, when and where
appropriate.
Response: We recognize that methods including, but not limited to
UDAP, may be appropriate depending on the payer's specific needs and
the API. We believe that appropriate security controls can be
implemented without requiring handwritten signatures, unless required
by other applicable law. We continue to monitor the progress of IG
development and remind readers that this final rule does not restrict
payers from using other IGs (assuming they are not an earlier version
than we specify). We will continue to monitor IG development and
consider requiring or recommending additional IGs in future rulemaking.
4. Required Standards and Recommended Implementation Guides To Support
APIs
Using standards and IGs supports consistent implementations across
the industry. In Table H1 of this final rule, we list the CFR citations
that require impacted payers to use API technology conformant with the
standards and specifications outlined in this section of the rule. We
also include Table H3 to provide a clear outline of which standards we
require and which IGs we recommend for each API.
BILLING CODE 4150-01-P

[[Page 8943]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.011

[[Page 8944]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.012

[[Page 8945]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.013

BILLING CODE 4150-01-C

[[Page 8946]]

5. Final Action
After considering the comments received, and for the reasons
discussed in the CMS Interoperability and Prior Authorization proposed
rule (87 FR 76238) and our response to those comments (as summarized
previously), we are finalizing our proposals regarding interoperability
standards for the Patient Access, Provider Access, Provider Directory,
Payer-to-Payer, and Prior Authorization APIs.
We are finalizing greater specificity for the standards at 45 CFR
170.215 that are applicable to each API, with some modifications.
Specifically, impacted payers will only be required to use the
applicable standards and specifications that we have identified as
necessary for the Patient Access, Provider Access, Provider Directory,
Payer-to-Payer, and Prior Authorization APIs. Those standards are
listed as ``required'' in Table H3. We are also finalizing a
modification to incorporate the expiration dates ONC adopted at 45 CFR
170.215(b)(1)(i) and (c)(1) since the CMS Interoperability and Prior
Authorization proposed rule was published.
We are finalizing our proposal to allow impacted payers to use
updated standards, specifications, or IGs for each of these APIs, under
the following conditions: the updated version of the standard is
required by other applicable law; or (1) the updated version of the
standard is not prohibited under other applicable law, (2) the National
Coordinator has approved the updated version for use in the ONC Health
IT Certification Program, and (3) the updated version does not disrupt
an end user's ability to access the data required to be available
through the API. We note that for the required standards at 45 CFR
170.215, several updated versions have been approved by the National
Coordinator for use in the ONC Health IT Certification Program,\189\
including, but not limited to, the US Core IG STU 6.1.0, the SMART App
Launch IG Release 2.0.0, and the Bulk Data Access IG (v2.0.0: STU 2).
---------------------------------------------------------------------------

\189\ 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.
---------------------------------------------------------------------------

Finally, we are recommending specific IGs, listed as
``recommended'' in Table H3, which we encourage payers to use in
addition to the required standards at 45 CFR 170.215.

III. Collection of Information Requirements

Under the Paperwork Reduction Act (PRA) of 1995, we are required to
provide 60-day notice in the Federal Register and solicit public
comment before a collection of information requirement is submitted to
the OMB for review and approval. To fairly evaluate whether an
information collection should be approved by OMB, section 3506(c)(2)(A)
of the PRA of 1995 requires that we solicit comment on the following
issues:
The need for information collection and its usefulness in
carrying out the proper functions of our agency.
The accuracy of our estimate of the information collection
burden.
The quality, utility, and clarity of the information to be
collected.
Recommendations to minimize the information collection
burden on the affected public, including automated collection
techniques.
We requested public comment on areas of this document that contain
information collection requirements (ICRs).

A. Background

Payers and providers should be able to take advantage of new
technologies that improve their ability to exchange information
efficiently, enhance operations, and streamline processes to benefit
patient care. Payers should share prior authorization rules in more
transparent ways to enable providers to meet their requirements, and
thereby, avoid care delays. To continue advancements in our commitment
to interoperability, we are finalizing our proposals for certain
impacted payers to implement FHIR APIs and make other process
improvements to help streamline prior authorizations and improve data
exchange between payers, providers, and patients. Impacted payers will
be required to report metrics for the information about how often
patients use the Patient Access API and about prior authorization
processes to assess implementation of our policies. The final rule
includes provisions that will reduce the amount of time to process
prior authorization requests and improvements for communications about
denied prior authorizations. Combined, these provisions should reduce
the burden on providers, payers, and patients and enhance patient care
coordination.
To incentivize provider use of the Prior Authorization API, we are
finalizing a policy to add a new measure for MIPS eligible clinicians
under the MIPS Promoting Interoperability performance category and for
eligible hospitals and CAHs under the Medicare Promoting
Interoperability Program. Beginning with the CY 2027 performance
period/2029 MIPS payment year (rather than the CY 2026 performance
period/2028 MIPS payment year), we are finalizing this measure as an
attestation (yes/no response); we intend to propose a scoring
methodology for the measure in future rulemaking. This new measure will
be included in a PRA package related to this final rule.

B. Wage Estimates

To derive average costs, we used data from the U.S. Bureau of Labor
(BLS) Statistics' National Occupational Employment and Wage Estimates
\190\ and aligned our analysis with other CMS regulatory actions. Table
J1 presents the mean hourly wage, the cost of fringe benefits and
overhead (calculated at 100 percent of salary), and the adjusted hourly
wage.
---------------------------------------------------------------------------

\190\ U.S. Bureau of Labor Statistics (2021, March 31). May 2020
National Occupational Employment and Wage Estimates. Retrieved from
https://www.bls.gov/oes/2020/may/oes_nat.htm.

---------------------------------------------------------------------------

[[Page 8947]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.014

We adjusted the employee hourly wage estimates by a factor of 100
percent or doubling of the BLS wage estimates. This is a rough
adjustment because fringe benefits and overhead costs vary
significantly across employers based on the age of employees, location,
years of employment, education, vocations, and other factors.

C. Information Collection Requirements

Consistent with our approach in the CMS Interoperability and
Patient Access final rule (85 FR 25622), we determined ICRs by
evaluating cost and burden at the impacted payer level. We determined
that 365 impacted payers together represent the possible plans,
entities, issuers, and state programs impacted by these proposals. The
increase in impacted payers from the first CMS Interoperability and
Patient Access final rule (85 FR 25510) corresponds to the average
annual increase in impacted payers for new market entries. The total
estimated burden on these impacted payers is described in detail in the
following ICRs and Table J9 at the end of this section. We estimated
the total number of burden hours across all impacted payers in the
first year of implementation at 6.9 million hours; assuming a total
cost to impacted payers to begin at approximately $182 million in the
first and second years, increasing to $199 million in the third year
and decreasing to $142 million by the fourth and subsequent years.
We requested comments on each ICR described in the proposed rule
(87 FR 76330), and on the assumptions made in deriving these burden
estimates. We received a few comments on the burden of the proposals
and acknowledge those comments with responses later in this section.
Since we did not receive specific data to include to modify estimates,
no revisions have been made.
1. Information Collection Requirements Regarding Reporting of Patient
Access API Metrics to the Centers for Medicare and Medicaid Services
(42 CFR 422.119, 431.60, 438.242, 457.730, and 457.1233 and 45 CFR
156.221)
CMS does not currently collect data on using the Patient Access API
and does not have industry data on the extent to which patients are
requesting to download their data from their payer into an app. We are
finalizing the requirement that impacted payers annually report certain
metrics to CMS about usage of the Patient Access API. Specifically, we
will collect the total number of unique patients whose data are
transferred via the Patient Access API to a health app designated by
the patient; and the total number of unique patients whose data are
transferred more than once via the Patient Access API to a health app
designated by the patient. We estimate that impacted payers will
conduct two major work phases: (1) implementation, which includes
defining requirements and system design to generate and compile
reports; and (2) maintenance, which we define as including the
compilation and transmission of annual reports to CMS. During the
implementation phase, impacted payers will need to prepare their
systems to capture the data to be transmitted to CMS.
The burden estimate related to the requirements reflects the time
and effort needed to identify, collect, and disclose the information.
The costs include an initial set of one-time costs associated with
implementing the reporting infrastructure and ongoing annual
maintenance costs to report after the reporting infrastructure has been
established.
Table J2 includes our computational estimates for first-year
implementation and ongoing maintenance costs and was used to develop
the official statement of burden found in Table J9. In finalizing these
calculations, we assumed a two-person team of software/web developers
and a business operations specialist spending an aggregate of 160 and
40 hours, respectively, for the first and subsequent years, at a total
cost per impacted payer (rounded) of $15,000 and $3,000. The aggregate
burden (rounded) for 365 impacted payers will be 60,000 hours and
15,000 hours for the first and subsequent years at a cost of $5.5
million and $1 million.

[[Page 8948]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.015

We did not receive comments specific to the estimates for the
Patient Access API metrics reporting.
---------------------------------------------------------------------------

\191\ U.S. Bureau of Labor Statistics (2021, March 31). May 2020
National Occupational Employment and Wage Estimates. Retrieved from
https://www.bls.gov/oes/2020/may/oes_nat.htm.
---------------------------------------------------------------------------

2. Information Collection Requirements Regarding the Provider Access
API (42 CFR 422.121, 431.61, 438.242, 457.731, and 457.1233 and 45 CFR
156.221)
Research shows that patients achieve better outcomes when their
medical records are more complete and there are more data available to
the health care provider at the point of care.\192\ Making
comprehensive information available to providers could thus improve the
care experience for patients. Ensuring that providers have access to
relevant patient data could also reduce the burden on patients to
recall and relay information during an appointment and provide
confirmation that the patient's recollection of prior care is accurate.
This has not always been possible in a disconnected health care system.
However, interoperable standards and technology now make it possible
for providers to access more patient data for a more comprehensive view
of their patients' health history and status. We are finalizing the
Provider Access API requirements as described in section II.B.2. of
this final rule which permits providers to receive standardized patient
data to coordinate care. Cost estimates for this API were developed
based on the methodology finalized in the CMS Interoperability and
Patient Access final rule (85 FR 25510). In that rule, we estimated
that impacted payers would conduct three major work phases: initial
design, development and testing, and long-term support and maintenance
(85 FR 25605). In this final rule, we assume the same major phases of
work will take place for each of the new APIs, with a different level
of effort during each work phase.
---------------------------------------------------------------------------

\192\ Office of the National Coordinator for Health Information
Technology (2019, June 4). Improved Diagnostics & Patient Outcomes.
Retrieved from https://www.healthit.gov/topic/health-it-basics/improved-diagnostics-patient-outcomes.
---------------------------------------------------------------------------

In the initial design phase, tasks include determining available
resources (for example, personnel, hardware, cloud storage space,
etc.), assessing whether to use in-house or contracted resources to
facilitate an API connection, convening a team to scope, build, test,
and maintain the API, gap analysis, and gap mitigation. During the
development and testing phase, impacted payers will conduct mapping of
existing data to the FHIR standards, hardware allocation for the
necessary environments (development, testing, production), building a
new FHIR-based server or leveraging existing FHIR servers, determining
the frequency and method by which internal data are populated on the
FHIR server, building connections between the databases and the FHIR
server, performing capability and security testing, and vetting
provider requests.
Table J3 summarizes the aggregate burden for complying with the
Provider Access API requirements. We provide illustrative points to
explain the calculations within the table and the terms used for the
headings. The occupational categories on the left side of the table
include the titles of the types of labor categories who will perform
the work, for example, Database Administrators and Architects,
Engineers, and Computer System Analysts.
On the top row, under the label ``Database Administrators,'' the
labor cost of $97.20 per hour was obtained from the BLS. The $97.20
represents the mean wage for this occupational title. The calculations
in Table J3 reflect time over the period of the project. We estimate
that a Database Administrator might spend 480 hours in total to
complete this task. The 480 hours are found in the column titled
``Primary Hours.'' The word primary, as used in the CMS
Interoperability and Patient Access final rule (85 FR 25510), refers to
the amount of time most organizations would require for this work. The
total cost of $46,656 for each organization is obtained by multiplying
the 480 hours by the $97.20 per hour wage. This $46,656 is found in the
column labeled ``Total Cost, Primary.''
We provide low and high estimates representing a range of possible
time and costs across all organizations. The low estimate is half the
primary estimate, which is 240 hours. The high estimate is 720 hours.
These numbers are found in the low and high columns (hours) of the top
row. The corresponding low and high costs are obtained by multiplying
the low and high estimates of hours by the $97.20 per hour wage. This
is a reasonable range that captures the amount of time and cost all
organizations may spend on completing this work.
The explanation provided for the top row applies to each of the ten
occupational titles. The sum of the total hours and costs provides a
typical organization's total cost. This number is found in the ``Totals
for a Single Impacted Payer'' row. As depicted, the typical
organization might take a total of 2,800 hours at a cost of $270,045.
We estimate the impact by organization rather than by payer since many
organizations may have entities in several of the programs to which
this final rule applies: MA organizations, state Medicaid and CHIP FFS
programs, Medicaid managed care plans, CHIP managed care entities, and
QHP issuers on the FFEs.
To arrive at the total cost of the final rule, we multiplied the
single organization cost by 365 payers--that is, the number of
organizations hosting plans across the programs. For example, the total
primary hourly burden of the rule is 1,022,000 (365 organizations x
2,800 for a single organization).
Similar to the methodology used in the CMS Interoperability and
Patient Access final rule (85 FR 25510), we estimate maintenance costs
for future years after the API is established at 25 percent of the
aggregate cost. We arrived

[[Page 8949]]

at 25 percent based on our experience with the industry. Rather than
list more columns or create another table, we provide a footnote
indicating that maintenance is estimated to be 25 percent of the cost.
For example, the primary aggregate burden over all 365 organizations is
$98.6 million, implying that the annual maintenance costs are expected
to be $24.6 million (25 percent x $98.6 million).
[GRAPHIC] [TIFF OMITTED] TR08FE24.016

Although compliance with this provision will be required on January
1, 2027, we believe it is reasonable to assume that this API will have
to be under development before this date to conduct testing and ensure
compliance. Acknowledging that impacted payers will have varying
technological and staffing capabilities, as we did in the first CMS
Interoperability and Patient Access final rule (85 FR 25606), we are
finalizing our estimate that the development of this API will require
1,400 to 4,200 hours of work. We have distributed the cost over 3
calendar years to give impacted payers the flexibility to complete the
necessary work (see Table J9).
Comment: A few commenters disagreed with CMS's calculations for the
total burden regarding hours and costs across all impacted payers and
stated that the estimates are significantly understated. These
commenters stated that they were not confident that the proposed rule
captured the true cost of transitioning to the technical standards.
Response: We acknowledge comments about our calculations capturing
the costs of transitioning to the technical standards, however, the
commenters who made these statements did not include any supporting
data which we could analyze or include in the final rule. We are aware
of and have included available information in our estimates and
analysis to address connections, testing, security, and onboarding of
third parties, to accommodate the potential costs and burden for each
API implementation. Additionally, we believe our estimates are the best
possible, without additional information, and reasonable assumptions of
staff and time, with ranges to account for low and high costs. We
welcome continued input from payers and developers based on
implementation of the Patient Access and Provider Directory APIs from
the CMS Interoperability and Patient Access final rule, as well as the
requirements finalized in this final rule. Such information will also
be informative for purposes of future rulemaking.
Comment: A commenter noted that it is unrealistic for CMS to expect
that the industry can obtain the resources necessary to comply with the
provisions outlined in the proposed rule within the current budget year
when the requirements will not be finalized until the final rule is
issued. The commenter recommended that CMS revise the compliance dates
of these provisions to be 36 months after issuance of the final rule
and scheduled on a date other than the end of a calendar year.
Response: We have acknowledged the constraints on both budget
cycles for certain impacted payers such as state Medicaid and CHIP
agencies, as well as the technical complexities of implementation, and
are finalizing a compliance date in 2027 for policies in this final
rule that require API development or enhancement. As explicitly noted
previously, the hours of work needed to build the API as indicated in
Table J3, acknowledges that impacted payers will have varying
technological and staffing capabilities.
a. API Maintenance Costs--All APIs
The third phase for implementation is long-term support and
maintenance. Here we discuss our methodology for the development of the
costs in aggregate for all APIs outlined in this final rule. As
relevant to the APIs discussed in sections III.C.2., 3., and 6. of this
final rule, we estimate ongoing maintenance costs for the Provider
Access, Payer-to-Payer, and Prior Authorization APIs, in aggregate. The
costs of the API development are split into three phases: initial
design, development and testing, and long-term support and maintenance.
We assume that maintenance costs only account for the cost associated
with the technical requirements as outlined in this rule. Any changes
to requirements would add burden, which would be discussed in future
rulemaking. Throughout this section, we discuss the initial design,
development, and testing costs per API. This final rule addresses the
total maintenance cost for all three APIs.
As discussed in the first CMS Interoperability and Patient Access
final rule (85 FR 25606), once the API is established, there will be an
annual cost to maintain the FHIR server, including the cost of
maintaining the necessary patient data and performing capability and
security testing. We believe there are efficiencies to be gained in
implementation and maintenance since the APIs rely on several of the
same underlying foundational technical

[[Page 8950]]

specifications and content. For example, the same standards will be
used to implement the new APIs as were used to implement the Patient
Access and Provider Directory APIs, including FHIR and complementary
security and app registration protocols. We also believe that
maintenance costs will be higher than what we estimated for the CMS
Interoperability and Patient Access final rule for the new APIs in this
final rule, as our estimates also account for new data mapping needs,
standards upgrades, additional data storage, system testing, initial
bug fixes, fixed-cost license renewals, contracting costs, and ongoing
staff education and training.
To account for these maintenance costs, we based our estimates on
input from industry experience piloting and testing APIs for provider
access, prior authorization, and payer to payer data exchange. We
estimated an annual cost averaging approximately 25 percent of the
primary estimate for one-time API costs. In Table J9, we account for
this maintenance cost separately for each API (at 25 percent of the
one-time API cost). As discussed previously, the overlap in some of the
recommended IGs across the APIs should result in shared efficiency that
we believe supports the assumption that maintenance should be accounted
for in aggregate and is presented in this section as such.
We requested public comment on our approach and assumptions for the
aggregate maintenance cost of the APIs, including whether our estimate
was reasonable or should be modified, and did not receive specific
comments on the aggregate maintenance costs.
3. Information Collection Requirements Regarding the Prior
Authorization API (42 CFR 422.122, 431.80, 438.242, 457.732, and
457.1233 and 45 CFR 156.223)
This API addresses ongoing challenges of the prior authorization
process, including identifying whether a prior authorization is
required for an item or service; identifying the payer documentation
requirements for prior authorization; compiling the necessary data
elements to populate the HIPAA-compliant prior authorization
transactions; and enabling payers to provide a specific response
regarding the status of the prior authorization, including information
about the reason for denial. We are finalizing the requirement for
impacted payers to implement and maintain a Prior Authorization API in
this final rule. Use of the Prior Authorization API will begin 2027 (by
January 1, 2027, for MA organizations and Medicaid and CHIP FFS
programs; by the rating period beginning on or after January 1, 2027,
for Medicaid managed care plans and CHIP managed care entities; and for
plan years beginning on or after January 1, 2027, for QHP issuers on
the FFEs).
As discussed previously, with respect to the Provider Access API,
we estimate that impacted payers will need to conduct three major work
phases to implement the requirements for the Prior Authorization API:
initial design, development and testing, and long-term support and
maintenance. Furthermore, for the Prior Authorization API, additional
tasks are necessary to accomplish the requirements. For the costs for
the third phase--long-term support and maintenance--our methodology for
the development of those costs in aggregate for all APIs is presented
in section III.D. of this final rule.
We based our estimate on feedback from industry experts on the
anticipated burden of implementing the Prior Authorization API and on
current pilots. We continue to believe the estimates to be reasonable
regarding the implementation burdens on impacted payers to develop APIs
that can facilitate the prior authorization process. In addition to
implementing this API, impacted payers will be required to send a
specific reason for prior authorization requests that are denied. As
discussed in section II.D. of this final rule, while the Prior
Authorization API will use the FHIR standard to support its basic
capabilities, covered entities must also use the adopted X12 278
transaction standard and remain HIPAA-compliant. Given the added
complexity of accounting for the HIPAA standards, we have accounted for
the multiple skill sets required and licensing costs for accessing the
X12 standards in developing the burden estimates. The recommended HL7
IGs are freely available, as HL7 provides access to all IGs as open-
source materials. This makes the HL7 standards, IGs, reference
implementations, and test scripts available free of charge to the
health care and developer community but requires usage and possibly
transaction costs for the X12 standards. We have accounted for the
necessary engineers, subject matter experts, and health informaticists
in our estimates. These personnel resources will need to convert
payers' prior authorization rules into computable, structured formats,
create provider questionnaires regarding whether a patient had a
medical necessity for a medical item or service, create formats that
can interface with the provider's EHR or practice management system,
create and execute mapping between the HL7 and X12 codes, and integrate
the Prior Authorization API with external systems or servers.
Though this provision will be effective on January 1, 2027, this
API will be under development before that date. Acknowledging that
impacted payers have varying technological and staffing capabilities,
we estimate that the development of the API will require 5,440 to
16,320 hours of work. In Table J9, we have distributed the cost over
approximately 3 calendar years to give impacted payers the flexibility
to complete the necessary work.
Table J4 presents total burden estimates for the Prior
Authorization API (initial design, followed by development and
testing). This table presents the calculations associated with the
total costs. The numbers from this table are used in Table J9 to
present costs per year for 3 years. Based on the same assumptions as
those included in the CMS Interoperability and Patient Access final
rule (85 FR 25510), we used the medium estimate as the primary
estimate.
The narrative description provided for Table J3 also applies to
Table J4. Both tables estimate API costs for 365 organizations and
indicate follow-up annual maintenance costs by analyzing costs for a
single payer using a team spanning approximately ten occupational
titles.
BILLING CODE 4150-28-P

[[Page 8951]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.017

BILLING CODE 4150-28-C
We requested public comment on our approach and assumptions for the
implementation cost of the Prior Authorization API, including whether

[[Page 8952]]

our estimates and ranges are reasonable or should be modified. We did
not receive any comments on this section.
4. Information Collection Requirements Regarding Requirements To Send
Prior Authorization Decisions Within Certain Timeframes (42 CFR
422.568, 422.570, 422.631, 438.210, 440.230, 457.495, and 457.1230)
Patients need to have timely access to care, and providers need to
receive timely responses to their requests for authorization to
requests for services for their patients, particularly when waiting for
answers can delay the pursuit of alternatives. To increase transparency
and reduce burden, we are finalizing our proposal to require that
certain impacted payers, not including QHP issuers on the FFEs, send
prior authorization decisions within 72 hours for expedited requests
and 7 calendar days for standard requests. Impacted payers will have to
comply with these provisions beginning January 1, 2026. We note that
Medicaid managed care plans and CHIP managed care entities will have to
comply with these provisions by the rating period beginning on or after
January 1, 2026.
To implement this policy, there will be up-front costs for impacted
payers to update their policies and procedures. We anticipate this
burden per payer is 8 hours of work by a general and operations manager
to update the policies and procedures, reflecting two half-days of work
at a per-entity cost of $967. Therefore, the total burden for all 365
impacted payers is 2,920 hours of work at a first-year cost of $0.4
million (rounded). These calculations are summarized in Table J5.
[GRAPHIC] [TIFF OMITTED] TR08FE24.018

We requested public comment on our assumptions, estimates, and
approach but received no comments on this proposal and therefore are
finalizing these estimates without modification.
5. Information Collection Requirements Regarding the Requirement for
Public Reporting of Prior Authorization Metrics (42 CFR 422.122,
438.210, 440.230, 457.732, and 457.1230 and 45 CFR 156.223)
To support transparency for patients to understand prior
authorization processes, provide some assistance in choosing health
coverage, and for providers when selecting or evaluating payer networks
we are finalizing our proposal to require that impacted payers publicly
report certain prior authorization metrics on their websites. Impacted
payers will be required to report aggregated data annually for the
previous calendar year's data, beginning March 31, 2026.
We estimate that impacted payers will conduct two major work
phases: implementation, which includes defining requirements, system
design, and updates to generate and compile reports; and maintenance,
including an annual compilation of reports and public reporting of
metrics on a website. In the first phase, impacted payers will need to
define requirements concerning the types and sources of data that need
to be compiled regarding prior authorization activities and data, build
the capability for a system to generate reports, and update or create a
public web page to post the data. In the second phase, impacted payers
will need to create the reports and post them to a public web page
annually.
Table J6 itemizes the activities, hours, and dollar burdens for the
first-year implementation and estimated annual maintenance costs. We
assumed a team of two staff consisting of a software and web developer
with a business operations specialist.
First-year implementation will impose a burden of 320
hours for the first year and 120 hours for subsequent years, at the
cost of $30,000 and $9,000 (rounded), for the first and subsequent
years, respectively.
The aggregate burden of the first-year implementation
across 365 impacted payers will be 117,000 hours and 44,000 hours
(rounded) for the first and subsequent years, respectively, at a cost
of $10.8 million and $3.3 million (rounded) for the first and
subsequent years.
[GRAPHIC] [TIFF OMITTED] TR08FE24.019

[[Page 8953]]

6. Information Collection Requirements Regarding the Payer-to-Payer API
Implementation (42 CFR 422.121, 431.61, 438.242, 42 CFR 457.731, and
457.1233 and 45 CFR 156.222)
Patients may wish to carry certain health information with them
when they change payers, in part so that they can track the services
they have received, and to ensure that a new payer has information
about their past health history for purposes of managing their care
with new or current providers. We are finalizing the requirements for
impacted payers to implement and maintain a Payer-to-Payer API as
described in section II.C. of this final rule. These provisions will
improve care coordination among payers by requiring payers to exchange,
at a minimum, adjudicated claims and encounter data (excluding provider
remittances and patient cost-sharing information), all data classes and
data elements included in a content standard at 45 CFR 170.213 (USCDI),
and certain information about prior authorizations. This exchange will
be required via a Payer-to-Payer API beginning in 2027 (by January 1,
2027, for MA organizations and Medicaid and CHIP FFS programs; by the
rating period beginning on or after January 1, 2027, for Medicaid
managed care plans and CHIP managed care entities; and for plan years
beginning on or after January 1, 2027, for QHP issuers on the FFEs).
As discussed for the other APIs in this rule, impacted payers will
conduct three major work phases: initial design, development and
testing, and long-term support and maintenance.
There will be some costs for impacted payers to implement the
Payer-to-Payer API that are unique to this API. There could be costs to
test and integrate the Payer-to-Payer API with payer systems, albeit
potentially lower costs than those estimated for the Provider Access
API. We estimate the one-time implementation costs at about one-third
the cost of a full de novo Provider Access API implementation based on
input from developers who have implemented and piloted prototype APIs
using the required standards. We accounted for the necessary skill sets
of staff required as we also believe there will be unique costs for
implementing the PDex IG so that payers can exchange active and pending
prior authorization decisions and related documentation and forms when
an enrollee or beneficiary enrolls with a new impacted payer.
Table J7 presents the total activities, hours, and dollar burdens
for implementing the Payer-to-Payer API given our assumptions on the
initial design phase and the development and testing phase. Based on
the same assumptions as those published in the CMS Interoperability and
Patient Access final rule (85 FR 25510), we have the medium estimate as
the primary estimate. We provide the following narrative explanation of
Table J7:
For the primary estimate, one-time implementation efforts
for the first two phases will require, on average, a total of 916 hours
per organization at an average cost of $96,072 per organization.
The aggregate burden of the one-time implementation costs
across 365 impacted payers will be 334,000 hours (rounded) at the cost
of $35.1 million (rounded). This corresponds to the primary estimate;
the low and high estimates are obtained by multiplying the primary
estimate by factors of one-half and one and one-half, respectively.
[GRAPHIC] [TIFF OMITTED] TR08FE24.020

Though this provision will be effective on January 1, 2027, the API
will be under development before that date. Acknowledging that impacted
payers will have varying technological and staffing capabilities, the
development of the API will require 458 to 1,374 hours of work. In
Table J9, we have distributed the cost estimates over 3 calendar years
to give impacted payers the flexibility to complete the work.
We requested public comment on our approach and assumptions for the
cost of the Payer-to-Payer API, including whether our estimates and
ranges are reasonable or should be modified, and received none.
7. Information Collection Requirements Regarding the Electronic Prior
Authorization Measure for Merit-Based Incentive Payment System and the
Medicare Promoting Interoperability Program
The estimates in this section have been submitted to OMB in a PRA
package (OMB control number 0938-1278). The burden associated with the
proposed requirement for eligible hospitals and CAHs to report the
Electronic Prior Authorization measure for the Medicare Promoting
Interoperability Program will be captured in the next revision to the
PRA package currently approved under OMB control number 0938-1278 (CMS-
10552).
As explained in section II.F. of this final rule, in response to
the December 2020 CMS Interoperability proposed rule (85 FR 82586),
commenters indicated that provider reporting would be an appropriate
lever by which CMS could encourage using the APIs to enable enhanced
electronic documentation discovery and facilitate electronic prior
authorization. Thus, to encourage MIPS eligible clinicians, eligible
hospitals, and CAHs to implement and use electronic prior authorization
and the corresponding

[[Page 8954]]

API, we proposed to add a new measure, called the Electronic Prior
Authorization measure, for MIPS eligible clinicians under the MIPS
Promoting Interoperability performance category and for eligible
hospitals and CAHs under the Medicare Promoting Interoperability
Program. After consideration of public comments, we have modified the
Electronic Prior Authorization measure requirements which are further
described and addressed in section II.F. of this final rule.
We are finalizing that MIPS eligible clinicians would report the
Electronic Prior Authorization measure beginning with the CY 2027
performance period/2029 MIPS payment year (rather than the CY 2026
performance period/2028 MIPS payment year) and that eligible hospitals
and CAHs would report the Electronic Prior Authorization measure
beginning with the CY 2027 EHR reporting period (rather than the CY
2026 EHR reporting period). For the CY 2027 performance period/2029
MIPS payment year for MIPS eligible clinicians and the CY 2027 EHR
reporting period for eligible hospitals and CAHs, we are finalizing
with a modification that the Electronic Prior Authorization measure be
structured as an attestation (yes/no), instead of a numerator and
denominator measure as originally proposed for both MIPS eligible
clinicians, and eligible hospitals and CAHs. As an attestation measure,
MIPS eligible clinicians, eligible hospitals, and CAHs are required to
report a ``yes'' or ``no'' response or report an applicable exclusion,
for the Electronic Prior Authorization measure. Additionally, we are
finalizing that this measure will not be assigned points.
For the MIPS Promoting Interoperability performance category,
satisfactory performance on this measure can be demonstrated only by
reporting a ``yes'' response or claiming an applicable exclusion. A
``no'' response will result in the MIPS eligible clinician failing to
meet the minimum reporting requirements, and therefore not being
considered a meaningful EHR user for MIPS, as set forth in section
1848(o)(2)(A) of the Act and defined in 42 CFR 414.1305, for the MIPS
payment year. MIPS eligible clinicians who do not report a ``yes''
response or claim an applicable exclusion for the Electronic Prior
Authorization measure as specified (that is, they do not submit the
measure or report a ``no'' response on the attestation without claiming
an applicable exclusion) will not earn a score for the MIPS Promoting
Interoperability performance category (a score of zero for the
category). A MIPS eligible clinician's score in the Promoting
Interoperability performance category is generally worth 25 percent of
their total final score for MIPS (42 CFR 414.1375(a); 414.1380(c)(1)).
For the Medicare Promoting Interoperability Program, only a ``yes''
response on the attestation, or claiming an applicable exclusion, will
fulfill the minimum requirements of this measure. A ``no'' response
will result in the eligible hospital or CAH failing to meet the minimum
program requirements, and therefore would not be considered a
meaningful user of CEHRT, as defined in section 1886(n)(3) of the Act
for an EHR reporting period (42 CFR 495.24(f)(1)(i)(A)). Eligible
hospitals and CAHs that do not meet the minimum program requirements
are subject to a downward payment adjustment.
The burden in implementing these requirements consists of reporting
an attestation (a ``yes'' or ``no'' response) or claiming an exclusion.
In the RIA, section IV. of this final rule, we estimate burden based on
the effort it takes to report a response for the measure. This
estimated burden to report would be the same whether it is to report a
``yes or no'' response or to report a numerator and denominator as
initially proposed. Therefore, modifying the measure to be reported as
an attestation does not change the overall cost estimates included in
the RIA for this provision. System maintenance is an umbrella term that
includes all activities needed to keep a system running. The two main
components of system maintenance are preventive and corrective
maintenance, which include software tasks such as fixing bugs, updating
data sources, deleting old software tasks, adding new tasks, testing,
and verification. Maintenance requirements for systems were estimated
at 25 percent of total software creation costs, reflecting updates and
bug fixes, as well as deletion and creation of software tasks (85 FR
82649). There will be a moderate software update to implement the
provisions of this final rule, and there will be no added burden over
and above the burden of maintaining already existing software.
The data for the reports on prior authorizations and related claims
should already be stored in the system software of health care
providers who may be required to retain such data for compliance and
regulatory reasons. To report the Electronic Prior Authorization
attestation (yes/no) measure as specified by CMS, the provisions in
this rule should not impose a significant burden of denoting the
information in the system.
For the added burden of extracting, compiling, reviewing, and
submitting the attestation, we assume that for each report, a Medical
Records Specialist will spend about half a minute (0.0083 hours)
extracting the already-existing data at a cost of $0.39 (1/120 hour
(\1/2\ minute) x $46.42 per hour). To obtain the aggregate burden, we
multiply by the number of entities. This is done separately for
eligible hospitals and CAHs, and MIPS eligible clinicians in Table J8.

[[Page 8955]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.021

The following items provide support and rationale for the entries
in Table J8:
The hourly burden estimates of \1/2\ minute (1/120 =
0.00833 hour) for transmission of the Electronic Prior Authorization
attestation (yes/no) response to CMS are consistent with the revised
estimates of burden presented in the FY 2024 IPPS/LTCH proposed rule
(88 FR 27204). The hourly burden estimates for the Electronic Prior
Authorization measure are based on the collection of burden estimates
calculated for the Query of Prescription Drug Monitoring Program
measure.
The estimate of 4,500 hospitals (including eligible
hospitals and CAHs) is consistent with the revised estimates presented
in the FY 2024 IPPS/LTCH final rule (88 FR 27205).
The existing MIPS reporting policies allow MIPS eligible
clinicians to report at the individual or group level. As noted in the
CY 2024 PFS proposed rule (88 FR 52666), CMS did not propose any
submission changes for the MIPS Promoting Interoperability performance
category and therefore refers to previous rules for respondent and
burden estimates. In Table 132 of the CY 2023 PFS final rule (87 FR
70163), the estimated number of respondents submitting MIPS Promoting
Interoperability performance data was based on 2021 participation data
collected during the PHE for the COVID-19 pandemic. We anticipate that
participation will change over the next 10 years and volumes will
rebound to pre-pandemic numbers. We determined that the respondent
estimates in Table 122 of the CY 2023 PFS proposed rule (87 FR 46370)
are more representational of what we anticipate participation will look
like when the Prior Authorization API and associated Electronic Prior
Authorization measure provisions are implemented given that these
estimates are based on pre-pandemic participation data from CY 2019.
Therefore, we maintain that an estimated 54,770 individual or group
MIPS eligible clinicians will submit an attestation for the Electronic
Prior Authorization measure under the MIPS Promoting Interoperability
performance category for the CY 2027 performance period/2029 MIPS
payment year. The 54,770 is the sum of the 43,117 individual MIPS
eligible clinicians, 11,633 groups, and 20 subgroups estimated to
submit MIPS Promoting Interoperability performance data. The ICRs
currently approved under OMB control number 0938-1314 are approved
through January 31, 2025.
The FY 2024 IPPS/LTCH proposed rule uses mean hourly wage
estimates (88 FR 27204), consistent with this final rule and the CMS
Interoperability and Patient Access final rule (85 FR 25605). For
purposes of clarification, we have provided both mean and median
estimates.
++ For eligible hospitals and CAHs, the total cost is $1,741 (4,500
hospitals and CAHs x \1/2\ minute x $46.42 per hour), which equals
$0.002 million as shown in Table J9. This rounds to $0.0 million.
Calculations using the median instead of the average after rounding are
identical. This shows that the bottom-line rounded figure would not
change if we used the median instead of the average. The entries in
Table J9 are rounded numbers while the actual dollar amounts are
provided in Table J8.
++ For MIPS eligible clinicians, the total cost is $21,186 (54,770
clinicians x \1/2\ minute x $46.42 per hour). Since Table J9 relates to
Table K6 in the RIA, we expressed the $21,186 using RIA accounting
standards, which require rounding to the nearest tenth of a million. It
follows that $21,186 is equivalent to $0.021 million, as shown in Table
J9. This value is rounded to $0.0 in the RIA.
Comment: A commenter stated the calculation for the aggregate
estimates for the Electronic Prior Authorization measure costs is
unreasonable and lacks a reasonable basis. This commenter stated there
is no way for an employee to run a report in half a minute, as logging
into the computer system with two-factor authentication alone can take
1 to 2 minutes. The commenter stated getting to the report in the EHR
can take \1/2\ to 1 minute and running a large report can easily take
\1/2\ to 2 minutes. The report then needs to be verified and
transmitted. The commenter stated instead of half a minute, the process
is closer to 5 to 10 minutes. Another commenter stated that the
analysis does not account for the payer burden of connecting and
testing with all EHRs and practice management systems, specifically the
high costs and time commitments. The commenter requested CMS's
clarification on whether payers are only required to share with EHR
systems certified under the ONC Health IT Certification Program.
Response: We appreciate concerns about the timing for reporting but
respectfully disagree, particularly because we have modified the
reporting specifications for the Electronic Prior Authorization
measure. We are finalizing this measure with modifications such that,
beginning with the CY 2027 performance period/2029 MIPS payment year
and the CY 2027 EHR reporting period, a MIPS eligible clinician,
eligible hospital, or CAH will report a ``yes'' or ``no'' response for
the Electronic Prior Authorization measure or claim an exclusion,
instead of a numerator and denominator measure as originally proposed.
If the MIPS eligible clinician, eligible hospital, or CAH does not
report a ``yes'' response for the Electronic Prior Authorization
measure or claim an exclusion, they will receive a zero score for the
MIPS Promoting Interoperability performance category or the Medicare
Promoting Interoperability

[[Page 8956]]

Program, respectively. We are finalizing reporting of the Electronic
Prior Authorization measure as an attestation (yes/no) measure
beginning with the CY 2027 performance period/2029 MIPS payment year
and the CY 2027 EHR reporting period. With these modifications,
completing and reporting the attestation for the Electronic Prior
Authorization measure will not take 10 minutes, but significantly less
time to enter into the reporting system. We are explicitly describing
time spent reporting the Electronic Prior Authorization measure in this
final rule, and half a minute is more representational for reporting a
single attestation measure. The entire reporting process for these
programs may take longer to complete, for example, 5-to-10 minutes. The
amount of time it takes to report data to CMS is dependent on whether
the person reporting the data needs to establish their account
credentials, the amount of data being reported, and the method through
which the data is being submitted. However, this calculation does not
intend to calculate the amount of time it takes to conduct the entire
process or report all performance data, rather it is solely evaluating
the estimated amount of time a person would spend on reporting the
Electronic Prior Authorization measure.
We also acknowledge this commenter's concern about the basis for
the aggregate estimates for the Electronic Prior Authorization measure.
However, this commenter did not provide additional data to which we
could compare our estimates. Furthermore, we disagree with the
commenter as we used information from other interested parties as well
as studies to determine that the cost savings will be substantial after
a period of years because of the improvements in the prior
authorization process for reducing manual effort and delays in
services.
We did not receive any other comments on this section of the rule.
After consideration of public comments, we are finalizing the estimates
without modification.

D. Summary of Information Collection Burdens

We have explained the costs of individual provisions in this
section. Table J9 summarizes costs for the first and subsequent years
of these provisions and is based on the following assumptions:
Modified compliance dates for the policies in this final
rule that require API development or enhancement, Medicare Promoting
Interoperability Program, and MIPS Promoting Interoperability
performance category until the CY 2027 performance period/2029 MIPS
payment year or CY 2027 EHR reporting period to give 3 years (36
months) for appropriate implementation activities.
Maintenance costs for the three APIs are, as indicated in
the tables of this section, assumed to be 25 percent of total costs;
these maintenance costs will be incurred in CY 2027 and subsequent
years.
Certain provisions will be effective in January 2026;
thus, no costs are reflected from 2023 through 2025. However, for the
building of the API systems, we assume impacted payers will be
performing these updates in CY 2024 through 2026 to be prepared for the
CY 2027 compliance date.
Labor costs in Table J9 are either BLS wages when a single
staff member is involved or a weighted average representing a team
effort, which is obtained by dividing the aggregate cost by the
aggregate hours.
Table J9 reflects the primary estimate. The full range of
estimates for all provisions is presented in the RIA section of this
final rule.
BILLING CODE 4150-28-P

[[Page 8957]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.022

BILLING CODE 4150-28-C

[[Page 8958]]

E. Conclusion

The provisions of this final rule are expected to improve data
sharing across impacted payers and providers by facilitating access,
receipt, and exchange of patient data. We are committed to providing
patients, providers, and payers with timely access to patient health
information. We requested comments on our approaches for estimating
cost burden and cost savings and received a few comments which have
been incorporated herein.
The requirements of this final rule are extensions of the
requirements of the CMS Interoperability and Patient Access final rule
(85 FR 22510). Therefore, the ICRs have been submitted to OMB for
review and approval.

IV. Regulatory Impact Analysis

A. Statement of Need

As described in prior sections of this final rule, the changes to
42 CFR parts 422, 431, 435, 438, 440, and 457 and 45 CFR part 156
further support CMS's efforts to empower patients by increasing
electronic access to health care data, while keeping that information
safe and secure. The provisions in this final rule build on the
foundation we laid out in the CMS Interoperability and Patient Access
final rule to move the health care system toward increased
interoperability by enabling better data sharing capabilities of
impacted payers, encouraging health care providers' use of new
capabilities, and making health-related data more easily available to
patients through standards-based technology.
The provisions in this final rule place new requirements on MA
organizations, state Medicaid and CHIP FFS programs, Medicaid managed
care plans, CHIP managed care entities, and QHP issuers on the FFEs to
further improve the electronic exchange of health-related data and
streamline prior authorization processes. We believe these provisions
will improve health information exchange and facilitate appropriate
patient, provider, and payer access to health information via APIs,
while the policies related to prior authorization should improve
certain administrative processes. The final rule also adds a new
attestation measure for eligible hospitals and CAHs under the Medicare
Promoting Interoperability Program and for MIPS eligible clinicians
under the MIPS Promoting Interoperability performance category.

B. Overall Impact

We examined the impacts of this final rule as required by Executive
Order 12866 on Regulatory Planning and Review (September 30, 1993),
Executive Order 13563 on Improving Regulation and Regulatory Review
(January 18, 2011), Executive Order 14094, entitled ``Modernizing
Regulatory Review'' (April 6, 2023), the Regulatory Flexibility Act
(RFA) (September 19, 1980, Pub. L. 96-354), Executive Order 13272 on
Proper Consideration of Small Entities in Agency Rulemaking (August 13,
2002), section 1102(b) of the Act, section 202 of the Unfunded Mandates
Reform Act of 1995 (UMRA) (March 22, 1995, Pub. L. 104-4), and
Executive Order 13132 on Federalism (August 4, 1999) and the
Congressional Review Act (5 U.S.C. 804(2)).
Executive Orders 12866 and 13563 direct agencies to assess all
costs and benefits of available regulatory alternatives and, if
regulation is necessary, to select regulatory approaches that maximize
net benefits (including potential economic, environmental, public
health, and safety effects, distributive impacts, and equity).
Executive Order 14094, entitled ``Modernizing Regulatory Review,''
amends section 3(f)(1) of Executive Order 12866 (Regulatory Planning
and Review). The amended section 3(f) of Executive Order 12866 defines
a ``significant regulatory action'' as an action that is likely to
result in a rule: (1) having an annual effect on the economy of $200
million or more in any 1 year (adjusted every 3 years by the
Administrator of the Office of Information and Regulatory Affairs
(OIRA) for changes in gross domestic product), or adversely affect in a
material way the economy, a sector of the economy, productivity,
competition, jobs, the environment, public health or safety, or state,
local, territorial, or tribal governments or communities; (2) creating
a serious inconsistency or otherwise interfering with an action taken
or planned by another agency; (3) materially altering the budgetary
impacts of entitlement grants, user fees, or loan programs or the
rights and obligations of recipients thereof; or (4) raise legal or
policy issues for which centralized review would meaningfully further
the President's priorities or the principles set forth in this
Executive order, as specifically authorized in a timely manner by the
Administrator of OIRA in each case.
Based on our estimates, OMB's OIRA has determined this rulemaking
to be significant per section 3(f)(1) as measured by having an annual
effect of $200 million in at least 1 year, and hence is also a major
rule under Subtitle E of the Small Business Regulatory Enforcement
Fairness Act of 1996 (also known as the Congressional Review Act).
Accordingly, we have prepared an RIA that, to the best of our ability,
presents the costs and benefits of this final rule.
These provisions will result in some financial burden for impacted
payers and certain providers as discussed in section III. of this final
rule. In the proposed rule, we weighed the potential burdens against
the potential benefits and believe the benefits outweigh the costs (87
FR 76340). Based on our estimates, the total burden across all
providers would be reduced by at least 220 million hours over 10 years,
resulting in a total cost savings of at least $16 billion over 10 years
as seen in Table K6. We did not include these savings in the 10-year
Summary Table (Table K9), nor in the Monetized Table (Table K11), as
explained later on in this section of the final rule.
Comment: Some commenters disagreed with CMS's calculated cost to
implement the provisions outlined in the proposed rule and expressed
that the actual cost will be much higher than estimated. A commenter
stated that they fail to see how the estimated total burden across all
providers would be reduced by the proposed rule's estimates of 206
million hours resulting in the total cost saving of $15 billion that
CMS asserted in the proposed rule.
Response: While we appreciate that commenters do not concur with
the cost estimates, we used the best available data to us at the time
we developed the rule and made related assumptions about the reduction
in hours for clerical, nursing, and provider staff as a result of the
final policies. We are re-stating our assessments of those assumptions
and calculations in this final rule. Though commenters and implementers
did not submit new data for consideration, we did make a slight
revision in the total cost savings to say ``at least $16 billion''
which includes adjustments of where some of the savings would occur.
The potential savings are significant, and we firmly believe that the
policies in this final rule will streamline operations, improve
efficiencies, and pave the way for substantial changes in the way staff
use technology to exchange data and conduct business, particularly for
prior authorization. We welcome tangible data from commenters which we
could use for comparative analysis of costs and savings.
Comment: A commenter raised concerns with the impact analysis and
cost calculations CMS included in the proposed rule, taking issue with
CMS using data that includes the cost of all prior authorizations,
which includes prescription drugs (accounting for 70 percent of prior
authorizations), to

[[Page 8959]]

calculate the savings potential of the proposed rule, as the policies
do not apply to all prior authorizations. The commenter stated that
accurate calculations would likely reveal that the rule as proposed is
too costly to implement unless CMS modifies it to include prior
authorization for prescription drugs, as well as all health plans.
Response: We emphasize that this rule does not apply to
prescription drugs that may be self-administered, administered by a
provider, or that may be dispensed or administered in a pharmacy or
hospital, or OTC drugs. We explicitly note that estimates do not
include all prior authorizations and that formulary prior
authorizations are excluded from our calculation of savings. In
addition, this rule does not apply to all health plans and services,
but rather to certain impacted payers, including MA organizations,
state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP
managed care entities, and QHP issuers on the FFEs. We welcome
alternative data to support further analysis and will continue to
collect information as the final rule is implemented.

C. Regulatory Flexibility Act

Executive Order 13272 requires that HHS thoroughly review rules to
assess and take appropriate account of their potential impact on small
businesses, small governmental jurisdictions, and small organizations
(as mandated by the RFA). HHS considers a ``significant'' impact to be
3 to 5 percent or more of the affected entities' costs or revenues. For
background on the RFA references in the proposed rule, please see 87 FR
76340.
We confirm our analysis of the impacted entities as described in
section IV.C. of this final rule.
1. Payers
The 365 payer organizations will perform updates to systems to
implement the required APIs and prepare for reporting requirements. As
in the proposed rule, we use the term parent organizations in this
final rule to refer to the impacted payers (87 FR 76238). The combined
parent organizations administer MA plans, state Medicaid and CHIP FFS
programs, Medicaid managed care plans, CHIP managed care entities, and
QHP issuers on the FFEs.
The North American Industry Classification System (NAICS) category
relevant to these provisions is Direct Health and Medical Insurance
Carriers, NAICS 524114, which has a $47.0 million threshold for small
size. 75 percent of payers in this category have under 500 employees,
thereby meeting the definition of small businesses.
The 365 parent organizations, including state Medicaid and CHIP
agencies, are responsible for implementing and maintaining three new
APIs, updating policies and procedures to accommodate revised
timeframes for making prior authorization decisions, and reporting
certain metrics either to CMS or making information available to the
public. We determined that state Medicaid and CHIP agencies, as well as
many MA organizations, Medicaid managed care plans, CHIP managed care
entities, and QHP issuers on the FFEs are not considered small
entities. Furthermore, MA organizations and Medicaid managed care plans
and CHIP managed care entities have many of their costs covered through
capitation payments from the Federal Government, and thus we conclude
there is no significant burden on small entities in this final rule.
We are finalizing the provisions that require API development or
enhancement as proposed. We also note that some QHP issuers on the FFEs
will be able to apply for an exception to these requirements, and
certain states operating Medicaid and CHIP FFS programs will be able to
apply for an extension or exemption, under which they will not be
required to meet the new provisions of this final rule that require API
development or enhancement on the compliance dates, provided certain
conditions are met, as discussed in section II.E. further mitigating
potential burden for those payers.
a. Medicare Advantage
On an annual basis, MA organizations estimate their costs for the
upcoming year and submit bids and proposed plan benefit packages to
CMS. Upon approval, the plan commits to providing the proposed
benefits, and CMS commits to paying the plan either the full amount of
the bid, if the bid is below the benchmark (a ceiling on bid payments
annually calculated from Original Medicare data); or the benchmark
amount, if the bid amount is greater than the benchmark. Thus, there is
a cost to plans to bid above the benchmark that is not funded by
government payments. Additionally, if an MA organization bids above the
benchmark for any of its plans, section 1854 of the Act requires the MA
organization to charge enrollees a premium for that amount. In the
proposed rule, we provided a further explanation regarding MA
organizations' bids and government payment processes for MA plans and
MA plans with prescription drug coverage (MA-PDs) and refer readers to
that discussion for additional detail (87 FR 76341).
Table K1 reports the percentage of MA organizations bidding above
the benchmark, along with the percentage of affected enrollees in
recent years. This table reports aggregates of proprietary bid data
collected by the Office of the Actuary (OACT). The CMS threshold for
what constitutes a substantial number of small entities for purposes of
the RFA is 3 to 5 percent. As shown in Table K1, both the percentage of
plans and the percentage of affected enrollees are below this 3 to 5
percent threshold. Consequently, we conclude that the number of plans
bidding above the benchmark is not substantial for purposes of the RFA.

[[Page 8960]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.023

The preceding analysis shows that meeting the direct costs of this
final rule does not have a significant economic impact on a substantial
number of small entities as required by the RFA.
There are certain indirect consequences of the final policies,
which will also have an economic impact. We explained that at least 98
percent of MA organizations bid below the benchmark. Thus, we estimate
that their projected costs for providing services to Medicare
beneficiaries for the coming year are fully paid by the Federal
Government. However, the government additionally pays the plan a
``beneficiary rebate'' amount that is an amount equal to a percentage
(between 50 and 70 percent, depending on a plan's quality rating)
multiplied by the amount by which the benchmark exceeds the bid. The
rebate is used to provide additional benefits to enrollees in the form
of reduced cost-sharing or other supplemental benefits or to lower the
Part B or Part D premiums for enrollees (supplemental benefits may also
partially be paid by enrollee premiums). If the provisions of this
final rule cause the MA organization's bids to increase and if the
benchmark remains unchanged or increases by less than the bid does, the
result will be a reduced rebate and, possibly fewer supplemental
benefits, or higher premiums for the health plans' enrollees. However,
as noted previously, the number of plans bidding above the benchmark to
whom this burden applies does not meet the RFA criteria of a
significant number of plans.
It is possible that if the provisions of this final rule cause bids
to increase, MA organizations will reduce their profit margins, rather
than substantially change their benefit packages. This may be in part
due to market forces; a plan lowering supplemental benefits even for 1
year may lose enrollees to competing plans that offer these
supplemental benefits. Thus, it can be advantageous to the plan to
reduce profit margins, rather than reduce supplemental benefits. With
this, plans would balance competitive pressures with profit targets
immediately following a new regulation. As the regulations are
typically finalized within a few months of the bid submission deadline,
plans may have more time to enact strategies that do not require large
benefit changes in subsequent years, such as negotiations for
supplemental benefit offerings. However, it may be inappropriate to
consider the relevant regulatory impacts (and thus the profit
considerations) as temporary because the issuance of a series of
regulations sustains the effects.\193\ As a result, changes in benefits
packages may be plausible. We did not receive any comments on this
section of the RIA regarding small entities, nor on our assumptions
about the impact or the general summary of the structure for MA bids.
We are therefore finalizing this analysis as is. Based on the
previously discussed considerations, the Secretary has certified that
this final rule will not have a significant impact on a substantial
number of small entities.
---------------------------------------------------------------------------

\193\ See similar discussion in previous regulatory analyses:
Contract Year 2023 Policy and Technical Changes to the Medicare
Advantage and Medicare Prescription Drug Benefit Programs, 87 FR
27704 (May 9, 2022). Retrieved from https://www.federalregister.gov/d/2022-09375; and Changes to the Medicare Advantage and the Medicare
Prescription Drug Benefit Program for Contract Year 2021 and 2022,
87 FR 22290 (April 14, 2022). Retrieved from https://www.federalregister.gov/d/2022-07642.
---------------------------------------------------------------------------

b. Medicaid and CHIP
Title XIX of the Act established the Medicaid program as a Federal-
state partnership to provide and finance medical assistance to
specified groups of eligible individuals. States claim Federal matching
funds quarterly based on their program expenditures. Since states are
not small entities under the RFA, we need not discuss the burden
imposed on them by this final rule.
Medicaid managed care plans and CHIP managed care entities receive
100 percent capitation from the state; we expect that the projected
costs associated with the provisions of this final rule will be
included in their capitation rates. Consequently, we assert that there
will be no substantial impact on a significant number of these
entities.
As discussed in section II.E. of this final rule for the provisions
that require API development or enhancement, states operating Medicaid
and CHIP FFS programs may apply for an extension of 1 year to come into
compliance with the requirements of this final rule. These same
organizations may also apply for an exemption from the requirements if
certain conditions are met.
Comments pertaining to the Medicaid and CHIP explanation of Federal
matching funds are addressed in that section of this final rule, as are
those related to the extension and exemption processes.
c. Qualified Health Plan Issuers on the Federally-Facilitated Exchanges
Few, if any, QHP issuers on the FFEs are small enough to fall below
the size thresholds for a small business established by the SBA.
Consistent with previous CMS analysis in the SHOP/QHP final rule (78 FR
33233), we estimated that any issuers considered small businesses would
likely be subsidiaries of larger issuers that would not be considered
small businesses (78 FR 33238), and thus would not share the same
burdens as an independent small business. Therefore, even though QHP
issuers do not receive Federal reimbursement for the costs of providing
care, we do not conclude that there would be a significant small entity
burden for these issuers. In addition, an exception process is
available to QHP issuers on the FFEs, which could further help to
address regulatory burden that could otherwise prohibit a QHP issuer
from participating in an FFE.
We did not receive any comments specific to the QHP summary section
of this RFA. Comments related to the

[[Page 8961]]

exception process for QHPs are addressed in section II.E.
2. Providers
In response to public comments on the December 2020 CMS
Interoperability proposed rule (85 FR 82586), CMS proposed a new
Electronic Prior Authorization measure for MIPS eligible clinicians
under the MIPS Promoting Interoperability performance category, and for
eligible hospitals and CAHs under the Medicare Promoting
Interoperability Program. CMS proposed that the Electronic Prior
Authorization measure would be required for MIPS eligible clinicians
beginning with the CY 2026 performance period/2028 MIPS payment year
and for eligible hospitals and CAHs beginning with the CY 2026 EHR
reporting year. However, after consideration of substantial feedback
from commenters described in section II.F. of this final rule, we are
finalizing a modification to the Electronic Prior Authorization measure
proposal. Rather than requiring MIPS eligible clinicians, eligible
hospitals, and CAHs to report a numerator and denominator for the
Electronic Prior Authorization measure, we are finalizing the measure
structured as an attestation (yes/no) measure for both MIPS eligible
clinicians, and eligible hospitals and CAHs. As an attestation measure,
MIPS eligible clinicians, eligible hospitals, and CAHs will report a
``yes'' or ``no'' response or report an applicable exclusion for the
Electronic Prior Authorization measure. Additionally, we are finalizing
that this measure will not be assigned points.
For the MIPS Promoting Interoperability performance category,
satisfactory performance on this measure can be demonstrated only by
reporting a ``yes'' response or claiming an applicable exclusion. A
``no'' response will result in the MIPS eligible clinician failing to
meet the minimum reporting requirements, and therefore not being
considered a meaningful EHR user for MIPS, as set forth in section
1848(o)(2)(A) of the Act and defined at 42 CFR 414.1305, for the MIPS
payment year. MIPS eligible clinicians that do not report a ``yes''
response or claim an applicable exclusion for the Electronic Prior
Authorization measure as specified (that is, they do not submit the
measure or report a ``no'' response on the attestation without claiming
an applicable exclusion) will not earn a score for the MIPS Promoting
Interoperability performance category (a score of zero for the
category). A MIPS eligible clinician's score in the Promoting
Interoperability performance category is generally worth 25 percent of
their total final score for MIPS (42 CFR 414.1375(a); 414.1380(c)(1)).
For the Medicare Promoting Interoperability Program, only a ``yes''
response on the attestation, or claim of an applicable exclusion, will
fulfill the minimum requirements of this measure. A ``no'' response
will result in the eligible hospital or CAH failing to meet the minimum
program requirements, therefore not being considered a meaningful user
of CEHRT, as defined in section 1886(n)(3) of the Act for an EHR
reporting period (42 CFR 495.24(f)(1)(i)(A)). Eligible hospitals and
CAHs that do not meet the minimum program requirements are subject to a
downward payment adjustment.
With regard to MIPS eligible clinicians, eligible hospitals, and
CAHs, a discussion of the burden is provided in section III., and
supporting data are shown in Table J8. As noted previously, we modified
the provision for the Electronic Prior Authorization measure in this
final rule based on comments indicating that the denominator
calculation would impose a significant burden on providers. We have
calculated the burden per individual provider at under $2.50 per year
(\1/2\ minute of labor times an hourly wage of under $50).
Based on all information provided herein, we conclude that the
requirements of the RFA have been met by this final rule.
We did not receive comments on this subject in the RFA. The
modification to the Electronic Prior Authorization measure was not
determined to have a significant financial effect on this RIA because
there is no need to re-calculate the numerator and denominator and the
information will be reported as an attestation. We are finalizing this
section as is.

D. Unfunded Mandates Reform Act and Executive Order 13132 Requirements

Section 202 of the UMRA also requires that agencies assess
anticipated costs and benefits before issuing any rule whose mandates
require spending in any 1 year of $100 million in 1995 dollars, updated
annually for inflation. In 2023, that threshold is approximately $177
million. This final rule will not impose an unfunded mandate that
results in the expenditure by state, local, and tribal governments, in
the aggregate, or by the private sector, of more than $177 million in
any 1 year.
Executive Order 13132 establishes certain requirements that an
agency must meet when it publishes a final rule that imposes
substantial direct costs on state and local governments, preempts state
law, or otherwise has federalism implications. As previously outlined,
while the provisions that require API development or enhancement will
be a requirement for state Medicaid and CHIP agencies as described in
this final rule, the cost per beneficiary for implementation is
expected to be negligible when compared with the overall cost per
beneficiary. The analysis we conducted did not consider Federal
matching funds provided to state Medicaid and CHIP agencies, and the
conclusion was the same: there is not expected to be a significant cost
impact on state entities.
For Medicaid and CHIP, we are unaware of any provisions in this
final rule that conflict with state law, and no commenters raised a
pre-emption issue other than the timeframe issue discussed later in
this section. Therefore, we do not anticipate any preemption of state
law. As discussed in section II.D. of this final rule, some state laws
regarding timeframes for prior authorization decisions may be different
than the provisions in this final rule. However, an impacted payer will
be able to comply with both state and Federal requirements by complying
with whichever imposes the shorter timeframe. We invited states to
comment on the proposed rule if they believed that any proposal in this
rule would conflict with state law. We received a few comments from
states and other organizations regarding the preemption of state law
regarding timeframes and addressed these comments regarding prior
authorization decision timeframes and compliance with state law in
section II.D. of this final rule.
As noted previously in this section, we considered whether the
provisions in this final rule imposed substantial costs on state or
local governments, preempted state law, or had federalism implications
and concluded that the rule does not. Therefore, the requirements of
Executive Order 13132 are not applicable.

E. Regulatory Review Costs

If regulations impose administrative costs on private entities,
such as the time needed to read and interpret this final rule, we are
required to estimate the cost associated with regulatory review. We
modeled our estimates of this burden based on similar estimates
presented in the CMS Interoperability and Patient Access final rule (85
FR 25510). In the proposed rule, we cited three numbers that were
needed to calculate this estimate: (1) number of staff per entity
performing the reading; (2) number of hours of reading; and (3) number
of entities reviewing the final

[[Page 8962]]

rule. We estimated a one-time aggregated total review cost of $1.3
million ($128.71 x 10 hours of reading time x 500 entities x two staff
per entity). We requested comments on our estimate and assumptions.
However, we did not receive any comments. For further details on this
matter, refer to the proposed rule at 87 FR 76343. Therefore, we are
finalizing the analysis as presented.

F. Impact of Individual Proposals

The provisions of this final rule all have information collection-
related burdens. This information is provided in Table J9 in section
III. of this final rule. Table K2 provides a list of the ICRs by number
and title, as well as the table numbers in which we provided an impact
assessment.
[GRAPHIC] [TIFF OMITTED] TR08FE24.024

Additionally, this RIA section provides an analysis of expected
savings to providers arising from the replacement of paper documents
related to prior authorization and other plan requirements with EHRs.
Although these savings are neither included in the Monetized Table
(Table K11) nor in the Summary Table (Table K9), we believe that these
large savings are an important consideration in understanding this
final rule. We have identified our assumptions for savings at the end
of this section.
Comment: Several commenters sought clarification regarding CMS's
analysis of how the proposed rule would impact industry. Commenters
stated that the discussion of the costs and benefits of the proposed
rule was not specific enough and disagreed with CMS's claim that the
benefits of the provisions are greater than the costs. Additionally, a
commenter noted that the costs estimated in the proposed rule vastly
underestimate the true cost of implementing and complying with the
provisions. The commenters provided recommendations on certain concepts
and ideas that CMS should take into consideration when assessing the
regulatory impact of this rule.
A few commenters expressed concerns over the calculations
associated with prior authorization. For example, one commenter noted
that CMS failed to account for the increase in prior authorization
burden since the publication of the Casalino report in 2009. Another
commenter noted that CMS failed to include a 2.5 percent fee for
electronic prior authorization transactions and the costs healthcare
providers expect to incur. A commenter agreed that some upfront costs
would be incurred but noted that new burdens and costs would be imposed
on payers, which must be considered. Another commenter noted that there
is little to no quantitative or qualitative data to justify CMS's
approach to calculating cost and savings associated with the provisions
in this rule.
Several commenters recommended that CMS work with payers and
providers to develop protocols to help identify specific cost savings
and efficiencies from automating the prior authorization process.
Response: CMS bases the impact analysis on data we can obtain from
past research and other available information. During development of
the proposed rule, we made certain assumptions about implementation and
development costs. However, based on the number of pilots in the launch
phase, we are optimistic that we will have additional data following
implementation. To the extent feasible, we encourage industry to share
data with us, which would be subject to all requested confidentiality
and proprietary protections afforded under the Freedom of Information
Act.\194\ We will look for opportunities to engage with impacted
entities to identify both cost savings and expenditures based on
automation of prior authorization processes which would support the
publication of the findings.
---------------------------------------------------------------------------

\194\ Office of Information Policy, U.S. Department of Justice
(n.d.). Freedom of Information Act Homepage. Retrieved from https://www.foia.gov/.
---------------------------------------------------------------------------

Comment: A commenter noted that it is unrealistic for CMS to expect
that industry can obtain the resources necessary to comply with these
policies within the current budget year when the requirements will not
be finalized until the final rule is issued. The commenter recommended
that CMS revise the compliance dates for these provisions to be 36
months after issuance of the final rule and scheduled on a date other
than the end of a calendar year. Another commenter recommended that CMS
reconsider the proposed timeline of certain provisions in the rule
given the critiques on the RIA and consider reshaping this rule into a
roadmap with milestones along the journey that would signal that a new
requirement was ready for implementation. A commenter recommended that
CMS adjust the RIA to account for changes in the FHIR-based standards
and recommended IGs.
Response: We appreciate concerns about implementation costs and
timing, as they pertain to this impact analysis, for states which are
dependent on state fiscal timelines for approvals and procurements. We
also remind readers that some impacted payers may be eligible to apply
for extensions, exceptions, and exemptions under certain circumstances,
as described in section II.E. of this final rule. We believe that the
finalized extensions,

[[Page 8963]]

exceptions, and exemptions will adequately address any contingencies
faced by individual payers and other affected entities. Finally, as
stated in section I.D. of this final rule, we are finalizing compliance
dates in 2027 for the policies in this final rule that require API
development or enhancement, in recognition of the need for analysis,
procurement, training, testing, and development. We appreciate the
commenter's feedback on updating our impact analyses to account for
changes to the FHIR standards, specifications, and IGs. However, we
disagree that updates to standards, specifications, and IGs should be
accounted for in the impact analysis. Changes to standards,
specifications, and IGs do not have any bearing on the calculation of
an impact analysis. We acknowledge that it will be important for
implementers to remain engaged in the HL7 workgroups and implementation
forums. We are requiring entities to use certain IGs specified in this
final rule and the ONC Cures Act final rule (85 FR 25642); those
standards will remain consistent. Should there be updates to any of
those standards or IGs, changes will be made available to implementers
through SVAP, as they are tested and approved by ONC. Industry is
strongly encouraged to participate in that process to ensure awareness
and readiness, but we do not believe that the changes or process for
those changes is of significance for the impact analysis.
Finally, as discussed earlier in this final rule, some commenters
wrote regarding the potential costs that might be passed on to
providers from EHR vendors or payers for use of the APIs, in the form
of user fees. We recognize that EHR vendors, providers, and payers have
costs of doing business, particularly for the development and
implementation of the APIs, as described in this RIA. We strongly
encourage EHR vendors to only charge reasonable fees for any initial or
periodic system configurations required to access payers' API
endpoints. We did not include information regarding user fees for APIs
in this impact analysis because of the lack of available data on the
costs incurred between payers, developers, EHRs and providers. However,
we are committed to monitoring and evaluating the expanding landscape
of API usage and will consider opportunities to provide future guidance
on this topic, to ensure that we can provide comprehensive and up-to-
date information for our industry partners.
The Summary Table (Table K9) of this section, using Table J9 as a
basis, provides a 10-year impact estimate. Table K9 includes impact by
year, by type (parent organizations, including state Medicaid and CHIP
agencies), as well as the cost burden to the Federal Government,
allocations of cost by program, and payments by the Federal Government
to MA organizations, Medicaid, and CHIP, as well as the premium tax
credits (PTCs) paid to certain enrollees in the individual market.

G. Alternatives Considered

We stated in the proposed rule that we are continuing to build on
the efforts initiated with the CMS Interoperability and Patient Access
final rule (85 FR 25510) and the work we have done to advance
interoperability, improve care coordination, and empower patients with
access to their data. This final rule covers several provisions aimed
at achieving these goals. We described alternatives to our proposals in
the proposed rule and the reasons we did not select them as proposed
provisions. The details for each of those alternatives and the
rationale behind not including them are available in the proposed rule
at 87 FR 76344.
1. Alternatives Considered for the Patient Access API Enhancements
We are finalizing modifications to our proposals to require payers
to make enhancements to the Patient Access API, which was finalized in
the CMS Interoperability and Patient Access final rule (85 FR 25510).
We are requiring payers to make additional information available to
patients through the Patient Access API and to report certain metrics
about patient use of the Patient Access API to CMS annually. We
considered several policy alternatives for the Patient Access API.
These are described in the proposed rule at 87 FR 76344, and relevant
comments regarding the Patient Access API are addressed in section
II.A. of this final rule.
Regarding reporting Patient Access API metrics, we considered
requiring impacted payers to publicly report these metrics more
frequently than annually. For example, we considered a quarterly
requirement. Public comments on the December 2020 CMS Interoperability
proposed rule (85 FR 82586) indicated a preference for less frequent
reporting to reduce burden on payers. Annual statistics on such
utilization should be sufficient to accomplish our goal of
understanding patient utilization of the API. Comments regarding
reporting on Patient Access API metrics are addressed in section II.A.
of this final rule.
The quantitative effect of quarterly reporting will likely not
change the bottom line of $1.6 billion cost over 10 years shown in
Table K9. However, we acknowledge it may change marginally to $1.7
billion. As shown in the various tables of section III. of this final
rule, the annual cost of reporting is estimated at $3.2 million based
on hours of work required by a business operations specialist. If we
required quarterly reporting this would quadruple the estimate or add
about $10 million annually--or a little under $100 million over 10
years. This would raise the $1.558 billion cost to at most $1.658
which, when rounded, would be either $1.6 or $1.7 billion.
We also considered earlier compliance dates for the proposed
enhancements to the Patient Access API. In the proposed rule, we stated
it would be more appropriate, and less burdensome on impacted payers to
propose compliance dates for these provisions in 2026 (by January 1,
2026, for MA organizations and state Medicaid and CHIP FFS programs; by
the rating period beginning on or after January 1, 2026, for Medicaid
managed care plans and CHIP managed care entities; and for plan years
beginning on or after January 1, 2026, for QHP issuers on the FFEs),
which would have provided a 2-year implementation timeframe. However,
based on public comments, we are finalizing a compliance dates in 2027
(by January 1, 2027, for MA organizations and state Medicaid and CHIP
FFS programs; by the rating period beginning on or after January 1,
2027, for Medicaid managed care plans and CHIP managed care entities;
and for plan years beginning on or after January 1, 2027, for QHP
issuers on the FFEs) for the policies in this final rule that require
API development or enhancement. Additional information regarding the
updated compliance dates for the APIs is available in sections I.D.,
II.A., II.B., II.C., and II.D. of this final rule.
Had we implemented the rule a year earlier, the aggregate $1.6
billion over 10 years would change to $1.7 billion over 10 years. The
total cost for creating the various APIs would not change; rather, they
would be apportioned over 2 years rather than 3 years. However, if we
required compliance a year earlier, then the maintenance costs of $142
million per year would begin in year 3 rather than in year 4. This
would add an extra $142 million per year of cost raising the aggregate
10-year cost of $1.55 billion to $1.69 billion or $1.7 billion after
rounding.

[[Page 8964]]

2. Alternatives Considered for the Provider Access API
To better facilitate the coordination of care across the health
care continuum, we are finalizing our proposal to require impacted
payers to implement and maintain a Provider Access API. This API will
require payers to make available to certain providers the same types of
data they make available to patients via the enhanced Patient Access
API.
As noted in the proposed rule at, we considered other data types
that could be exchanged via the Provider Access API and considered only
requiring the exchange of all data classes and data elements included
in a content standard at 45 CFR 170.213 (USCDI) (87 FR 76345). While
this would have required that less data be exchanged and, thus, be less
burdensome for impacted payers to implement, we believed that claims
and encounter information would complement the content standard and
offer a broader and more holistic understanding of a patient's
interactions with the health care system. Furthermore, the data that we
proposed to be made available through the Provider Access API aligns
with the data that we proposed to be made available to individual
patients through the Patient Access API. We also considered including
additional data elements as required for the Provider Access API,
requiring a complete set of data available from the payer's system.
However, we did not receive such suggestions from industry, including
patients, and such a large volume of data types might have been
overwhelming for providers, would have been an excessive cost, and
would likely not have met minimum necessary provisions. A more robust
description of the alternatives and our rationale for not selecting
those are set out in the proposed rule (87 FR 76346). We did not
receive comments specifically on the alternatives considered in this
section. Other comments regarding the Provider Access API are addressed
in section II.B. of this final rule.
3. Alternatives Considered for the Payer-to-Payer API
We are finalizing our proposal to require impacted payers to
implement and maintain a Payer-to-Payer API that makes certain data
available to other payers via a FHIR API. This provision will make the
same data that is being made available to patients and providers also
available to other payers when a patient changes plans. This will allow
patients to take their data with them as they move from one payer to
another. Before finalizing this provision, we considered several
alternative provisions which we described in detail in the proposed
rule (87 FR 76346).
For example, in the CMS Interoperability and Patient Access final
rule, we finalized a policy to require payers to exchange data with
other payers but did not require a specific mechanism for the payer to
payer data exchange to occur. Rather, we required impacted payers to
receive data in whatever format it was sent and accept data in the form
and format it was received, which ultimately complicated implementation
by requiring payers to accept data in different formats. The cost to
implement these various formats cannot be calculated because there are
endless possibilities and combinations of ways the data could have been
exchanged under the previously finalized policy.
Unlike the policy finalized in the CMS Interoperability and Patient
Access final rule, the use of an API would reduce the amount of
implementation cost needed for this data exchange. Importantly, for the
Payer-to-Payer API, once an organization implements the other APIs of
this final rule, less additional investment will be necessary to
implement the payer to payer data exchange, as payers would be able to
leverage the infrastructure already established for the Patient Access
and Provider Access APIs. The updated background information for the
recommended IGs is found in section II.G. and explains how the existing
resources can be tailored to meet the provisions set out in this final
rule. Given this available infrastructure and the efficiencies of
sharing standardized data via the API, we determined it was most
advantageous for payers to implement an API for this enhanced data
exchange. We did not receive any comments on this section, but comments
specific to the proposal for the Payer-to-Payer API are addressed in
section II.C. of this final rule.
4. Alternatives Considered for the Prior Authorization API and Other
Prior Authorization Process Requirements
We are finalizing our proposals for several important policies to
improve the prior authorization process, which we described in the
proposed rule (87 FR 76346). Our final policy to require that all
impacted payers implement and maintain a Prior Authorization API will
ultimately help patients receive the items and services they need in a
timely fashion, and support streamlined communication between providers
and payers. The Prior Authorization API aims to improve care
coordination by providing more structured information about when a
prior authorization is required, information that is required to
approve a prior authorization, and facilitating electronic prior
authorization. The API will be accessible to providers to integrate
directly into their workflow while maintaining compliance with the
mandatory HIPAA transaction standard. The standards and IGs that
support the development of this API are already being tested and
piloted with some success between providers and payers, and we believe
as enhancements to the IGs are made over the next few years, more
organizations will see the benefit for their programs.
As noted previously, we described our considerations for a phased
approach, or partial implementation of the API over time, and explained
why we did not propose those options. We did not receive comments in
support of a partial implementation in part because of the risk that
such an option might result in inconsistent implementations and
increase burden for providers. As indicated, though quantitative data
from current prior authorization pilots have been shared informally
with the public, it has not yet been submitted to CMS for use in
official evaluations or analysis. CMS anticipates receipt of the pilot
results in CY 2024.
Though we do not have specific data, we believe the quantitative
effects of a phased in implementation option would be negligible. The
total cost of developing the Prior Authorization API would not change;
however, such an approach could mean delaying the 25 percent
maintenance costs by 1 or 2 years, as well as the overall benefits of
the API.
We are finalizing our requirement that impacted payers publish
certain data about their performance on prior authorization, on a
public website, and though we considered options for this reporting, we
believe in the first few years of program implementation it will be
important to gather feedback from payers, providers and patients as to
the usability of the information being made available before modifying
the requirement. As explained in section II.D. of this final rule, CMS
is committed to working with impacted entities on best practices for
reporting.
We considered using only the X12 278 transaction standard adopted
under HIPAA rather than requiring the implementation of a FHIR API to
support the Prior Authorization API. While the adopted X12 278
transaction standard defines the content and format for the exchange of
data for prior authorization, it does not have the

[[Page 8965]]

functionality of the FHIR standard or IGs to support the requirements
of the Prior Authorization API. This includes the ability to
accommodate all of a payers' business rules, indicate which supporting
documents are required, create a questionnaire, and conduct an end-to-
end transaction via FHIR for real-time responses. We received
confirmation through many comments that the X12 standard is not
designed to enable using SMART on FHIR apps connected to the provider's
EHR system, nor is it designed for the scope envisioned in this rule,
including extraction of payer rules, a compilation of data into
electronic-based questionnaires, or communication with EHRs. The
substantive comments on this subject are addressed in section II.D. of
this final rule.
We are finalizing the operational, non-technical provisions related
to prior authorization processes, including requirements for certain
impacted payers to respond to expedited prior authorization requests
within 72 hours, and to standard prior authorization requests within 7
calendar days. We received many comments suggesting that the response
timeframes be shortened because of the potential impact on patient
care, and those comments are addressed in section II.D. of this final
rule.
Understanding the importance of providers and patients getting
decisions as quickly as possible, we believe that the timeframes
outlined in the proposed rule are a significant step to help increase
reliability in the prior authorization process and establish clear
expectations without being overly burdensome for payers.

H. Savings Through the Adoption of the Prior Authorization Provisions
by Health Care Providers

1. Overview
As described in section II.D. of this final rule, we have finalized
new requirements related to prior authorization for impacted payers,
and in section II.F. of this final rule, we described a new Electronic
Prior Authorization measure and the associated reporting requirements
for MIPS eligible clinicians, eligible hospitals, and CAHs.
In section III.C. of this final rule, we discussed the ICRs
regarding cost estimates for reporting and the potential burden
specifically for the MIPS eligible clinicians, eligible hospitals, and
CAHs. Here we address the anticipated cost savings of these provisions
for the broader health care provider population, which is inclusive of,
but not limited to the MIPS eligible clinicians, eligible hospitals,
and CAHs.
We believe that all health care providers can benefit from the
provisions for impacted payers to implement the APIs in this final rule
and base these cost-savings estimates over 10 years. We use the
estimated total number of providers, with estimates described in this
section of the final rule. To conduct this analysis, we used available
resources and invited comments on our assumptions, the data, and our
citations.
The savings estimated in this final rule are true savings, not
transfers, since they reflect savings in reducing the administrative
costs required to process prior authorizations. However, these savings
will be an indirect consequence of the final rule, not direct savings.
This final rule supports efforts to significantly reduce time spent on
manual activities. In general, it is only appropriate to claim that a
regulatory provision's benefits are greater than its costs after a
substantive and preferably quantitative, assessment of the pre-existing
market failure and the provisions' suitability for addressing it. As a
result of data limitations and other analytic challenges preventing
such an assessment, the illustrative savings estimates are neither
included in the Monetized Table (Table K11) nor the Summary Table
(Table K9) of this final rule. Nevertheless, the savings could be
significant, and we believe should be a factor in the industry's
assessment of this final rule. In the proposed rule, we requested
comments on how CMS might attribute savings benefits to avoid double-
counting, and how CMS could account for both costs and benefits from
policy interactions but did not receive specific comments in response.
We are only quantifying savings of reduced paperwork for health
care providers. However, the improved efficiencies outlined in this
rule have potential positive consequences, which could lead to savings.
Several surveys by the AMA cited in section II.D. of this final rule,
list adverse qualitative consequences of the current paper-based prior
authorization system, including life-threatening adverse medical
events, missed, or abandoned treatments, hospitalization, and permanent
bodily damage, however, we do not have specific data related to
outcomes.
2. Methodology for Savings Analysis
The approach adopted in quantifying savings is to quantify those
that we can reliably estimate and note that they are minimal savings.
The provisions of this rule potentially affect individual physicians,
physician groups, hospitals, and CAHs. However, for purposes of
quantification, we initially estimate a reduced paperwork burden for
individual physicians and physician groups, which shows a savings of
several billion dollars over 10 years. We base the estimate on the
number of hours per week spent on prior authorization, using
information about individual physicians and physician groups from
survey data we believe to be reliable (three surveys of several
thousand groups from 2006, 2021, and 2022 cited in this section of the
final rule). To calculate our estimates, we used the same physician
information and made certain assumptions of its applicability to
hospitals. The purpose of using this comprehensive provider information
from three different periods was that no other comprehensive data set
was available to identify savings from reduced paperwork. Our initial
estimate was for savings of several billion dollars for individual
physicians and physician groups.
To estimate reductions in spending on paperwork for prior
authorization for hospitals, we assumed that hospitals perform similar
prior authorization activities to individual physicians and physician
groups. We made this assumption because we do not have a basis for
making a more accurate assumption; that is, we do not have survey data
of similar quality for hospitals on the number of hours per week spent
on prior authorization and the proportion of hours per week spent by
physicians, nurses, and clerical staff.
To support the assumptions on potential benefits for hospital prior
authorization, we rely on data from previously published rules. To
avoid repetition of numbers and sources we summarize all updates in
this final rule, along with the estimates of the proposed rule,
subtotals, and sources in Table K3. Throughout this section, numbers
without specified sources, come from this table.
BILLING CODE 4150-28-P

[[Page 8966]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.025

BILLING CODE 4150-28-C
To calculate the burden and savings for the final rule, we are
using the data from the FY 2024 IPPS/LTCH proposed rule (88 FR 27205),
FY 2024 OPPS proposed rule (88 FR 49552), and CY 2023 PFS proposed rule
(87 FR 46370) rather than the CY 2023 PFS final rule (87 FR 69404) or
CY 2024 PFS final rule (88 FR 78818), as these sources more accurately
reflect the anticipated number of hospitals and providers impacted by
our provisions beginning on January 1, 2027. We believe these sources
are more reflective of the eligible hospitals and CAHs who will
participate in the Medicare Promoting Interoperability Program and the
MIPS eligible clinicians participating in the MIPS Promoting
Interoperability performance category over time. We elected to use MIPS
eligible clinician participation data from the CY 2023 PFS proposed
rule, rather than the CY 2023 PFS final rule or CY 2024 PFS final rule,
to estimate the number of MIPS eligible clinicians reporting MIPS
Promoting Interoperability data to CMS because the 45 percent reduction
in the estimated number of individual MIPS eligible clinicians
reporting MIPS Promoting Interoperability data between the CY 2023 PFS
proposed rule (based on CY 2019 participation data) and the CY 2023 PFS
final rule (based on CY 2021 participation data) appear to be lower due
to the effects of the COVID-19 PHE. Likewise, the number of individual
MIPS eligible clinicians reporting MIPS Promoting Interoperability data
as estimated in the CY 2024 PFS final rule (based on CY 2022
participation data) remain impacted by the COVID-19 PHE,\195\ which
formally ended on May 11, 2023. We do not believe this reduction in
MIPS eligible clinicians reporting MIPS Promoting Interoperability data
will be persistent and believe it is reasonable that participation
numbers in future years may revert to their former levels (before the
COVID-19 PHE).
---------------------------------------------------------------------------

\195\ U.S. Department of Health and Human Services (2023, May
9). Fact Sheet: End of the COVID-19 Public Health Emergency.
Retrieved from www.hhs.gov. https://www.hhs.gov/about/news/2023/05/09/fact-sheet-end-of-the-covid-19-public-health-emergency.html.
---------------------------------------------------------------------------

Additionally, we modified another assumption for this final rule,
acknowledging an increase in hours spent on prior authorization from 13
hours per week spent on prior authorization in 2021 to 14 hours per
week spent on prior authorization in 2022. We did so using AMA survey
data results which we believe are more reasonable. This change in data
encouraged us to update our estimations accordingly.
To account for these changes, and to avoid injecting our own
subjective

[[Page 8967]]

biases on the changes, we have included calculations using both years
of the AMA prior authorization survey data. The two total savings
estimates are based on the AMA prior authorization survey data, one
using 2021 survey data and the other using 2022 survey data, which
differed by about 10 percent. Both resulted in estimated savings of
several billion dollars over 10 years. The amount and effect of these
changes as well as the deviation from the proposed rule estimates are
set out below.
Additionally, given that estimates for MIPS eligible clinicians
reporting MIPS Promoting Interoperability data in the CY 2023 PFS final
rule were based on CY 2021 participation data collected during the
COVID-19 PHE, we are using data published in the CY 2023 PFS proposed
rule as cited in Table K3 for our calculations. We believe that this is
reasonable because the MIPS eligible clinician estimates from the CY
2023 PFS proposed rule are based on pre-pandemic participation data
from CY 2019. As noted previously, we do not believe the reductions in
participation in the MIPS Promoting Interoperability performance
category will continue long term. We believe it reasonable to assume
that participation numbers will continue to increase, at a minimum, by
the compliance dates for the policies that require API development or
enhancement (beginning on January 1, 2027).
3. Physicians and Hospitals
The approach presented in the proposed rule, and finalized here,
computes aggregate savings for physician or group physician practices
by first estimating the savings for a single individual physician or
group physician practice based on supporting surveys, and then
multiplying this single savings by the number of practices. Using the
updated numbers from Table K3 results in savings of at least $15.8
billion over 10 years for individual and physician groups.
We assume hospitals are conducting the prior authorization process
in a manner similar to physicians. Thus, the individual physician and
group physician practices would save at least $15.8 billion over 10
years, as shown in Table K6, and the combined physician practices and
hospitals (207,515 practices consisting of 199,543 individual physician
and group physician practices plus 7,972 hospitals and CAHs) would save
at least $16.5 billion (207,515/199,543 x $15.8 billion). To the
nearest billion, both $15.8 and $16.5 round to $16 billion. The
numerical savings are the same whether we include or exclude hospitals.
4. Base Estimates of Paperwork Savings to Providers
In calculating the potential savings, uncertainties arise in four
areas. The result of this illustrative analysis is that we find a
minimal potential savings point estimate of $15 billion (using 2021 AMA
prior authorization survey data) and $16 billion (using 2022 AMA prior
authorization survey data) over 10 years. To provide credibility to
this savings analysis we have, where we lacked better data,
underestimated any unknown quantities with minimal estimates and
additionally studied the effect of a range of estimates.
In the next few paragraphs, we summarize the four uncertainties and
indicate how we approached the estimation. We refer readers to a more
detailed discussion of these assumptions in the proposed rule (87 FR
76348). We received one comment on the quantitative estimate for
providers and have responded to that comment elsewhere in the final
rule. However, because no additional data was provided, we are not
changing general assumptions in this final rule, except that we are
updating numbers based on Table K3.
a. Assumptions on the Relative Proportion of Current Workload Hours and
Costs by Staff for Prior Authorization
For labor costs, we used the mean hourly wages from the
BLS.
For total hours spent per week on prior authorization by
staff overall we use the latest 2022 AMA survey (Table K3) rather than
the estimate used in the proposed rule, which was based on the 2021 AMA
prior authorization survey.
For the estimates of the current proportions by the staff
of paperwork involved in prior authorization processes, the type of
staff involved, and the type of physician offices, we used numbers in a
survey presented by Casalino et al. (2009),\196\ which gave a detailed
analysis based on a validated survey instrument employed in 2006. By
dividing, for each staff type, the total prior authorization time spent
per week across all physician practices, over the total prior
authorization time spent across all practices and all staff types, we
obtained the proportion of time each staff type spent per week on prior
authorization. These proportions were applied to the updated total time
per week spent on prior authorization as given in Table K3.
---------------------------------------------------------------------------

\196\ Casalino, L.P., Nicholson, S., Gans, D., Hammons, T.,
Morra, D., Karrison, T., & Levinson, W. (May 2009). What Does It
Cost Physician Practices to Interact with Health Insurance Plans?
Health Affairs, 28(4): w533-w543. doi: 10.1377/hlthaff.28.4.w533.
---------------------------------------------------------------------------

The updated results are presented in Table K4 which shows that
individual and group physician practices annually used, on average, at
least 728 hours per year at a cost of at least $52,642 on prior
authorization.
[GRAPHIC] [TIFF OMITTED] TR08FE24.026

[[Page 8968]]

Here, we provide information on the row on registered nurses for
demonstration purposes. Registered nurses are estimated to spend at
least 9 hours per week on prior authorization, and hence, spend 467.5
hours per year (9 hours per week x 52 weeks per year). By multiplying
the 467.5 hours per year spent on prior authorization by the mean wages
per hour for registered nurses, $76.94, obtained from the BLS, we
obtain an aggregate annual cost of $35,969 for registered nurses
dealing with prior authorization. The other rows are interpreted
following the same process.
b. Assumptions on the Total Number of Individual and Group Physician
Practices
Table K4 presents the current hour and dollar burden for a single
physician group and single physician office. To obtain the aggregate
annual burden of prior authorizations for all physician practices, we
use the data in Table K3, which includes a reference to 199,543 total
individual and group physician practices. This number is used to inform
Table K6 which represents a 10-year summary of annual costs.
c. Assumptions on the Reduction in Hours Spent on Prior Authorization
as a Result of the Provisions of This Final Rule
Table K4 provides current hours spent on prior authorizations. To
calculate potential savings, we assume how much these hours will be
reduced as a result of the provisions of this final rule.
A detailed discussion driving our assumptions was presented in the
proposed rule (87 FR 76350). Based on the provisions in this final
rule, we assume that physicians, nurses, and clerical staff will reduce
the time they spend on prior authorization by 10 percent, 50 percent,
and 25 percent respectively. Having received no comments on our
estimates, we have retained these estimates for purposes of the final
calculations. The savings, updated with the numbers from Table K3, is
presented in Table K5.
The narrative following Table K5 presents the total 10-year savings
with different reduction assumptions; however, these different
reduction assumptions do not materially change the range of estimates.
[GRAPHIC] [TIFF OMITTED] TR08FE24.027

To provide an explanation of Table K4, we use registered nurses as
an example. registered nurses spend 467.5 hours per year on prior
authorization (see Table K3). If we assume that registered nurses, as a
result of the finalized provisions of this rule, reduce the number of
hours per week by 50 percent (about half a day, or 4 hours, per week)
then they would save 233.7 hours per year (50 percent x 467.5 hours).
Multiplying the hours saved, 233.7 hours, by the mean hourly wage for
registered nurses, $76.94, the annual aggregate savings per physician
practice is $17,984. The other rows may be interpreted similarly.
d. Assumptions on the Number of Individual and Group Physician
Practices Adopting the Provisions of This Final Rule
As in the proposed rule, we are not assuming that over 10 years all
199,543 individual and group physician practices would adopt the
provisions outlined in this final rule. Instead, we assume the
following:
Because of the payment consequences for not adopting the
provisions of this final rule, we assume all 54,770 MIPS eligible
clinicians (individual and group), a subset of the 199,543 estimated
individual and group physician practices, would adopt the provisions in
this rule in CY 2027 (the first year for payer compliance). This
assumption of compliance by all MIPS eligible clinicians (individual
and group) in the first year of payer compliance is consistent with the
assumptions in the proposed rule (87 FR 76351).
As in the proposed rule, by 2036, we assume 50 percent of
all individual and physician practices will adopt the provisions of
this final rule. The reasons for this assumption are fully discussed in
the proposed rule (87 FR 76351). However, we acknowledge that 78
percent of providers have adopted EHRs, in part to meet ONC
requirements.\197\ Therefore, this estimate of 50 percent is already an
underestimate of the percent of individual and physician practices who
would adopt and benefit from the provisions of this rule.
---------------------------------------------------------------------------

\197\ Office of the National Coordinator for Health Information
Technology (n.d.). National Trends in Hospital and Physician
Adoption of Electronic Health Records. Retrieved from https://
www.healthit.gov/data/quickstats/national-trends-hospital-and-
physician-adoption-electronic-health-
records#:~:text=Office%20of%20the%20National%20Coordinator,IT%20Quick
%2DStat%20%2361.&text=As%20of%202021%2C%20nearly%204,%25)%20adopted%2
0a%20certified%20EHR.
---------------------------------------------------------------------------

We do not assume a constant increase per year but rather a
gradual increase per year, starting with the participation of 54,770
MIPS eligible clinicians in 2027 and growing exponentially to 99,772
(50 percent of 199,543) individual and physician group practices in
2036.
Applying these assumptions, based on the 2022 estimates results (as
shown in

[[Page 8969]]

Table K6), is at least a $15.8 billion ($15,829.3 million) savings over
10 years for individual and group physician practices. If we include
hospitals by increasing the amount by 4 percent, the estimate would be
at least $16.5 billion ($16,461.7 million). The estimate rounded to the
nearest billion is at least $16 billion. Had we used the 2021 estimates
we would obtain $15 billion in savings.
This $16 billion revised estimate differs from the $15 billion
estimate presented in the proposed rule is due to the change noted in
Table K3: a 7.7 percent increase in hours per week spent on prior
authorization (14 hours in 2022 versus 13 hours in 2021 based on the
AMA survey). This result is consistent with comments from industry who
thought our estimates were too low regarding the impact of prior
authorization on practices and hospitals. After adjusting for this
change estimate, and as noted in Tables K4 and K5, we obtain the
additional savings potential. Note that the range of savings based on
different assumptions of savings per staff, $13 to $20 billion over 10
years, still includes the estimate of $15 billion as noted in the
proposed rule.
[GRAPHIC] [TIFF OMITTED] TR08FE24.028

The headers of Table K6 show the logic and sources of the column
entries. The reduced hours per year per practice spent on prior
authorization for 2027 is calculated as shown here: 16.1 million hours
equals 294 hours per year per practice x 199,543 practices x 27.45
percent participation. Similarly, the dollar savings per year per
practice resulting from reduced time spent on prior authorization,
$21,026, obtained from Table K5, when multiplied by 27.45 percent of
all 199,543 group and physician practices yields $1.2 billion ($1,151.6
million) reduced dollar spending in 2027.
By summing the reduced hours and dollars per year we obtain an
aggregate reduction of at least 220.97 million hours and at least $15.8
billion ($15,829.3 million) in reduced spending on paperwork
activities. Finally, by adding 4 percent of these numbers to account
for hospitals, we obtain a total annual reduction of at least 229.27
million hours and at least a $16.5 billion ($16,461.7 million)
reduction.
As in the proposed rule, we obtained a range of estimates by
varying the assumptions of Table K5 which assume that physicians,
nurses, and clerical staff save 10, 50, and 25 percent respectively. If
we assume that all staff types uniformly reduce hours spent by 33
percent, then dollar spending is reduced by $13.2 billion without
hospitals to $13.7 billion with hospitals factored in over 10 years. If
we assume that all staff types uniformly reduce hours spent by 50
percent, then dollar spending is reduced by about $19.8 billion without
hospitals to $20.6 billion with hospitals factored in. Thus, the range
of savings, $10 billion to $20 billion presented in the proposed rule,
is slightly narrowed in this final rule to $13 to $20 billion,
including providers and hospitals.

I. Summary of Costs to the Federal Government

In this section, we present a 10-year Summary Table of costs (Table
K9), an analysis of Federal impacts, and the Monetized Table (Table
K11).
To analyze the cost of this final rule to the Federal Government,
we utilize a method of allocating costs by program (MA, Medicaid, CHIP,
and QHP issuers on the FFEs). As the cost is shared by the 365 parent
organizations, including state Medicaid and CHIP agencies, there is no
readily available way to allocate costs per parent organization across
programs since the percentage of each parent organization's
expenditures on the different programs is not publicly available.
To address this, we utilize the same method used in the CMS
Interoperability and Patient Access final rule (85 FR 25612). In that
final rule, we used the public CMS Medical Loss Ratio (MLR) files,
which break out total premiums among the various programs. The
advantages and disadvantages of such an approach are fully discussed in
that rule. Table K7 presents the 2021 MLR data of premiums by program
and the resulting percentages by program. We use these percentages to
allocate costs by program. This allocation of cost by program forms a
basis to calculate the Federal Government's cost for the proposed
provisions of this rule.

[[Page 8970]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.029

To calculate Federal costs for MA organizations, we use the CMS
internal data used to produce the CMS Trustees' Report. This internal
data indicates that the Trust Fund will pay about 34 percent of plan
costs over the next 10 years. The remaining costs (for the 98 to 99
percent of plans bidding below the benchmark) are borne by the plans.
Similarly, we can calculate the Federal Medicaid payments using the
percentages in Table K8.
[GRAPHIC] [TIFF OMITTED] TR08FE24.030

Table K8 is based on the most recent projections of the CMS OACT
for the FY 2024 Budget.
We illustrate the interpretation of the column by explaining the
items in the 2025 column. The number at the bottom of the column, 65.40
percent, answers the question ``What proportion of the interoperability
systems costs for Medicaid is the Federal Government expected to pay?''
There are two components to this calculation.
The first is the share of Medicaid managed care. Those costs are
directly paid by the MCOs, which in turn would be expected to raise
administrative costs for those plans. The Federal share of that is:
Federal Medical Assistance Percentage (FMAP) \198\ x the managed care
(MC) share of Medicaid; for 2025, this is 58.10 percent x 56.80
percent. The second is the share of the FFS program costs. The FFS
program side of Medicaid would have higher administrative costs. The
Federal share of this would be 90 percent in year 1 and 75 percent
after year 1. For 2025, this is equal to 75 percent x (1-56.8 percent).
The sum of these two components, 58.10 percent x 56.80 percent + 75
percent x (1-56.8 percent), equals 65.40 percent as shown in the bottom
row. When we multiply, in Table K9, the total annual cost of
interoperability for Medicaid by 65.40 percent we obtain the amount the
Federal Government is expected to pay for the interoperability system
costs for Medicaid.
---------------------------------------------------------------------------

\198\ Federal Medical spending is determined by the amount that
states spend. The Federal share for most health care services is
determined by the FMAP. The FMAP is based on a formula that provides
higher reimbursement to states with lower per capita incomes
relative to the national average.
---------------------------------------------------------------------------

It should be noted that although the compliance dates for policies
in this final rule that do not require API development or enhancement
are in 2026, and the compliance dates for policies that require API
development or enhancement are in 2027. We expect plans to begin
constructing software systems for the provisions that require API
development or enhancement upon publication of this final rule.
Based on the discussion presented in Tables K7 and K8, Table K9
presents the calculation of all numerical impacts of this final rule by
program, government, and QHP issuers on the FFEs.
BILLING CODE 4150-28-P

[[Page 8971]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.031

BILLING CODE 4150-28-C
For Table K9:
As explained in connection with Table J9 in the Collection
of Information section, the data in Table K9 is based on 2027
compliance dates for policies that require API development or
enhancement and the Electronic Prior Authorization measure for MIPS and
the Medicare Promoting Interoperability Program and compliance dates in
2026

[[Page 8972]]

for the policies that do not require API development or enhancement.
The bottom-line totals in the columns of Table J9 labeled
``1st Year Cost'' through ``4th Year Cost'' are the totals found in the
``Total Cost'' column of Table K9 in rows 2024 through 2027
respectively. The totals in the column ``4th and Subsequent Year
Costs'' in Table J9 are found in the rows labeled 2028 through 2033 in
the ``Total Cost'' column of Table K9.
The Total Cost to MIPS Eligible Clinicians, Eligible
Hospitals and CAHs column reflects the aggregate cost of producing
reports for MIPS eligible clinicians (including individual clinicians
and groups), eligible hospitals, and CAHs, as found in Table J9 for
years 2027 and further.
The total 10-year cost (excluding PTC payments and savings
from prior authorization) is, as shown in Table K9, $1.6 billion. This
number uses the primary estimates for the provisions that require API
development or enhancement. The low and high 10-year total costs are
$0.8 billion and $2.3 billion, respectively.
The Cost of Final Rule to Payers by Program columns: We
applied the percentages from Table K7 to obtain the cost of the rule to
payers by program (MA, Medicaid, CHIP, and QHP issuers on the FFEs).
The Cost of Final Rule to Government by Program columns:
For the QHP issuers on the FFEs, the government does not pay anything.
For managed care the Government pays approximately 34 percent (the
exact amount varying slightly from year to year and was obtained from
projections by OACT). For Medicaid, we applied the percentages of
payment by the Federal Government discussed in the narrative in Table
K8 to obtain the cost by program.
PTC Payments: The Government does not reimburse QHP
issuers on the FFEs, neither prospectively nor retrospectively, for
their expenses in furnishing health benefits. However, the government
offers QHP enrollees PTCs to help cover the cost of premiums for the
plans. QHP issuers on the FFEs have the option to deal with increased
costs by either temporarily absorbing them (for purposes of market
competitiveness--see, however, a caveat elsewhere in this RIA),
increasing premiums to enrollees, or reducing non-essential health
benefits. To the extent that issuers increase premiums for individual
market QHPs on the FFEs, there would be Federal PTC impacts. The
purpose of the PTC is to assist enrollees in paying premiums. Because
PTC is available only if an individual purchases a QHP on an Exchange
and the individual generally has a household income between 100 and 400
percent of the Federal Poverty Level, the PTC estimates apply only to
Exchange plans. Note, the Inflation Reduction Act of 2022 (IRA) \199\
extended the expanded PTC eligibility provision set forth in the
American Rescue Plan Act of 2021 (ARP) through the 2025 plan year.
---------------------------------------------------------------------------

\199\ H.R. 5376--117th Congress (2021-2022): Inflation Reduction
Act of 2022 (2022, August 16). Retrieved from https://www.congress.gov/bill/117th-congress/house-bill/5376.
---------------------------------------------------------------------------

In the PTC estimate, we have accounted for the fact that some
issuers have both Exchange and non-Exchange plans, and some issuers
have only non-Exchange plans. We reflected these assumptions with
global adjustments, so we believe the estimates are reasonable in
aggregate. Specifically, the methodology to estimate the PTC impact of
the projected expense burden is consistent with the method used to
estimate the PTC impact in the CMS Interoperability and Patient Access
final rule (85 FR 25612). Within the FFE states, the estimated expense
burden would impact premium rates in the individual market and is
spread across both Exchange and non-Exchange plans. PTCs are only paid
in the Exchanges and are calculated as a function of the second lowest-
cost silver plan and the eligible individual's household income. The
estimate of these impacts uses the assumption that the industry would
increase the second lowest-cost silver plan premium rate in the same
amount as the overall premium rate increase. This assumption allows the
application of the overall rate increase to the projected PTC payments
in the FFE states to estimate the impact on PTC payments.
The total cost to the government is the sum of payments
related to each program. This payment is a transfer from the Government
to payers for MA and Medicaid, CHIP, and QHP enrollees.
For MA organizations, Medicaid and CHIP, the remaining
costs are the difference between the total cost to payers and what the
Federal Government pays. For the individual market, the remaining costs
to payers would be the total cost absorbed by the payers and not passed
on through premium increases. Since the PTC is paid on behalf of
individuals and not the payers, it therefore does not reduce the
expenses of the payers.
The dollar savings from reduced paperwork burden for an increase in
using electronic prior authorization (Tables K4 and K5) is not included
in Table K9.
Table K10 describes how the various plans (and states) would bear
the costs remaining after federal payments. We follow the same
methodology and discussion presented in the CMS Interoperability and
Patient Access final rule (85 FR 25612). In the table we explain the
possible ways payers may manage extra implementation costs. We
emphasize that Table K10 only includes possibilities. The impacted
payers would make decisions about how to defray these remaining costs
based on market dynamics and internal business decisions; we have no
uniform way of predicting what these actual behaviors and responses
will be.

[[Page 8973]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.032

Individual Market Plans: Individual market plans have the
option of absorbing costs or passing costs to enrollees in the form of
higher premiums. In some cases, for reasons of market competitiveness,
plans may absorb the increased costs rather than increase premiums.
Medicaid and CHIP: Assuming roughly 71 million patients
enrolled nationally (inclusive of state Medicaid and CHIP FFS programs,
Medicaid managed care plans, and CHIP managed care entities), Medicaid
and CHIP would see an added cost of under a dollar per beneficiary per
year; this contrasts with a total cost per beneficiary per year for the
Medicaid and CHIP programs of several thousand dollars.\200\
---------------------------------------------------------------------------

\200\ Centers for Medicare and Medicaid Services Newsroom (2020,
January 30). Medicaid Facts and Figures [verbar] CMS. Retrieved from
https://www.cms.gov/newsroom/fact-sheets/medicaid-facts-and-figures.
---------------------------------------------------------------------------

Medicare Advantage: In their bids (submitted in the month
of June prior to the beginning of the coverage year), MA plans would
address the reduced rebates (arising from increased bid costs due to
the increased costs of this final rule being included in the bid) by
either: temporarily absorbing costs by reducing profit margins,
reducing the supplemental benefits paid for by the rebates, or raising
enrollee cost-sharing or premium. We believe many plans, for
competitive reasons, would choose to retain a zero-dollar premium
increase and either absorb losses for 1 year or reduce rebate-funded
supplemental benefits.
We received no comments specific to Table K10 or the methods
impacted payers will use to deal with the costs of this rule and are
therefore finalizing it as is.

J. Accounting Statement and Table

As required by OMB Circular A-4 (available at https://www.whitehouse.gov/wp-content/uploads/legacy_drupal_files/omb/circulars/A4/a-4.pdf), the following table, Table K11, summarizes the
classification of annualized costs associated with the provisions of
this final rule for the 10 years, 2024 through 2033. This accounting
table is based on Table K9 and includes the costs of this final rule to
certain providers, including hospitals and CAHs, MA organizations,
state Medicaid and CHIP programs, and QHP issuers on the FFEs. It does
not include the potential savings from Table K6 arising from reduced
burden due to providers, hospitals, and CAHs using electronic prior
authorization. Minor discrepancies in totals reflect use of underlying
spreadsheets, rather than intermediate rounded amounts. Table K11 is
stated in 2023 dollars, with expected compliance dates in 2027 for the
provisions of this final rule that require API development or
enhancement.
[GRAPHIC] [TIFF OMITTED] TR08FE24.033

[[Page 8974]]

In accordance with the provisions of Executive Order 12866, this
final rule was reviewed by OMB.
Chiquita Brooks-LaSure, Administrator of the Centers for Medicare &
Medicaid Services, approved this document on January 12, 2024.

List of Subjects

42 CFR Part 422

Administrative practice and procedure, Health facilities, Health
maintenance organizations (HMO), Medicare, Penalties, Privacy,
Reporting and recordkeeping requirements.

42 CFR Part 431

Grant programs--health, Health facilities, Medicaid, Privacy,
Reporting and recordkeeping requirements, State fair hearings.

42 CFR Part 435

Aid to Families with Dependent Children, Grant programs--health,
Medicaid, Notices, Reporting and recordkeeping requirements,
Supplemental Security Income (SSI), Wages.

42 CFR Part 438

Grant programs--health, Medicaid, Reporting and recordkeeping
requirements.

42 CFR Part 440

Grant programs--health, Medicaid.

42 CFR Part 457

Administrative practice and procedure, Grant programs--health,
Health insurance, Reporting and recordkeeping requirements.

45 CFR Part 156

Administrative practice and procedure, Advertising, Brokers,
Conflict of interests, Consumer protection, Grant programs--health,
Grants administration, Health care, Health insurance, Health
maintenance organizations (HMO), Health records, Hospitals, Indians,
Individuals with disabilities, Intergovernmental relations, Loan
programs--health, Medicaid, Organization and functions (Government
agencies), Prescription drugs, Public assistance programs, Reporting
and recordkeeping requirements, Technical assistance, Women, Youth.

For the reasons set forth in the preamble, the Centers for Medicare
& Medicaid Services amends 42 CFR chapter IV and the Department of
Health and Human Services amends 45 CFR part 156 as set forth below:

TITLE 42--PUBLIC HEALTH

PART 422--MEDICARE ADVANTAGE PROGRAM

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

Authority: 42 U.S.C. 1302, 1306, 1395w-22 through 1395w-28, and
1395hh.

0
2. Section 422.119 is amended by--
0
a. In paragraph (b)(1)(ii), removing the word ``and'' at the end of the
paragraph;
0
b. Revising paragraph (b)(1)(iii);
0
c. Adding paragraphs (b)(1)(iv) and (v); and
0
d. Revising paragraphs (c)(1), (c)(4)(ii)(C), (e)(2), (f), and (h).
The revisions and additions read as follows:

Sec. 422.119 Access to and exchange of health data and plan
information.

* * * * *
(b) * * *
(1) * * *
(iii) All data classes and data elements included in a content
standard in 45 CFR 170.213 that are maintained by the MA organization
no later than 1 business day after the MA organization receives the
data; and
(iv) Beginning January 1, 2027, the information in paragraph
(b)(1)(iv)(A) of this section about prior authorizations for items and
services (excluding drugs, as defined in paragraph (b)(1)(v) of this
section), according to the timelines in paragraph (b)(1)(iv)(B) of this
section.
(A) The prior authorization request and decision, including all of
the following, as applicable:
(1) The prior authorization status.
(2) The date the prior authorization was approved or denied.
(3) The date or circumstance under which the prior authorization
ends.
(4) The items and services approved.
(5) If denied, a specific reason why the request was denied.
(6) Related structured administrative and clinical documentation
submitted by a provider.
(B) The information in paragraph (b)(1)(iv)(A) of this section
must--
(1) Be accessible no later than 1 business day after the MA
organization receives a prior authorization request;
(2) Be updated no later than 1 business day after any status
change; and
(3) Continue to be accessible for the duration that the
authorization is active and at least 1 year after the prior
authorization's last status change.
(v) Drugs are defined for the purposes of paragraph (b)(1)(iv) of
this section as any and all drugs covered by the MA organization,
including any products that constitute a Part D drug, as defined by
Sec. 423.100 of this chapter, and are covered under the Medicare Part
D benefit.
* * * * *
(c) * * *
(1) Must implement and maintain API technology conformant with 45
CFR 170.215(a)(1), (b)(1)(i), (c)(1), and (e)(1);
* * * * *
(4) * * *
(ii) * * *
(C) Using the updated version of the standard, implementation
guide, or specification does not disrupt an end user's ability to
access the data specified in paragraph (b) of this section or
Sec. Sec. 422.120, 422.121, and 422.122 through the required APIs.
* * * * *
(e) * * *
(2) Makes this determination using objective, verifiable criteria
that are applied fairly and consistently across all apps and developers
through which parties seek to access electronic health information, as
defined in 45 CFR 171.102, including but not limited to, criteria that
rely on automated monitoring and risk mitigation tools.
(f) Reporting on Patient Access API usage. Beginning in 2026, by
March 31 following any calendar year that it offers an MA plan, an MA
organization must report to CMS the following metrics, in the form of
aggregated, de-identified data, for the previous calendar year at the
contract level in the form and manner specified by the Secretary:
(1) The total number of unique enrollees whose data are transferred
via the Patient Access API to a health app designated by the enrollee.
(2) The total number of unique enrollees whose data are transferred
more than once via the Patient Access API to a health app designated by
the enrollee.
* * * * *
(h) Applicability. An MA organization must comply with the
requirements of this section beginning in paragraphs (a) through (e)
and (g) of this section beginning January 1, 2021, unless otherwise
specified, and with the requirements in paragraph (f) of this section
beginning in 2026, with regard to data:
(1) With a date of service on or after January 1, 2016; and
(2) That are maintained by the MA organization.

0
3. Section 422.121 is added to read as follows:

Sec. 422.121 Access to and exchange of health data for providers and
payers.

(a) Application programming interface to support data exchange from

[[Page 8975]]

payers to providers--Provider Access API. Beginning January 1, 2027, an
MA organization must do the following:
(1) API requirements. Implement and maintain an application
programming interface (API) conformant with all of the following:
(i) Section 422.119(c)(2) through (4), (d), and (e).
(ii) The standards in 45 CFR 170.215(a)(1), (b)(1)(i), (c)(1), and
(d)(1).
(2) Provider access. Make the data specified at Sec. 422.119(b)
with a date of service on or after January 1, 2016, excluding provider
remittances and enrollee cost-sharing information, that are maintained
by the MA organization available to in-network providers via the API
required in paragraph (a)(1) of this section no later than 1 business
day after receiving a request from such a provider, if all the
following conditions are met:
(i) The MA organization authenticates the identity of the provider
that requests access and attributes the enrollee to the provider under
the attribution process described in paragraph (a)(3) of this section.
(ii) The enrollee does not opt out as described in paragraph (a)(4)
of this section.
(iii) Disclosure of the data is not prohibited by other applicable
law.
(3) Attribution. Establish and maintain a process to associate
enrollees with their in-network providers to enable data exchange via
the Provider Access API.
(4) Opt out and patient educational resources. (i) Establish and
maintain a process to allow an enrollee or the enrollee's personal
representative to opt out of the data exchange described in paragraph
(a)(2) of this section and to change their permission at any time. That
process must be available before the first date on which the MA
organization makes enrollee information available via the Provider
Access API and at any time while the enrollee is enrolled with the MA
organization.
(ii) Provide information to enrollees in plain language about the
benefits of API data exchange with their providers, their opt out
rights, and instructions both for opting out of data exchange and for
subsequently opting in, as follows:
(A) Before the first date on which the MA organization makes
enrollee information available through the Provider Access API.
(B) No later than 1 week after the coverage start date or no later
than 1 week after receiving acceptance of enrollment from CMS,
whichever is later.
(C) At least annually.
(D) In an easily accessible location on its public website.
(5) Provider resources. Provide on its website and through other
appropriate provider communications, information in plain language
explaining the process for requesting enrollee data using the Provider
Access API required in paragraph (a)(1) of this section. The resources
must include information about how to use the MA organization's
attribution process to associate enrollees with their providers.
(b) Application programming interface to support data exchange
between payers--Payer-to-Payer API. Beginning January 1, 2027, an MA
organization must do the following:
(1) API requirements. Implement and maintain an API conformant with
all of the following:
(i) Section 422.119(c)(2) through (4), (d), and (e).
(ii) The standards in 45 CFR 170.215(a)(1), (b)(1)(i), and (d)(1).
(2) Opt in. Establish and maintain a process to allow enrollees or
their personal representatives to opt into the MA organization's payer
to payer data exchange with the enrollee's previous payer(s), described
in paragraphs (b)(4) and (5) of this section, and with concurrent
payer(s), described in paragraph (b)(6) of this section, and to change
their permission at any time.
(i) The opt in process must be offered as follows:
(A) To current enrollees, no later than the compliance date.
(B) To new enrollees, no later than 1 week after the coverage start
date or no later than 1 week after receiving acceptance of enrollment
from CMS, whichever is later.
(ii) If an enrollee does not respond or additional information is
necessary, the MA organization must make reasonable efforts to engage
with the enrollee to collect this information.
(3) Identify previous and concurrent payers. Establish and maintain
a process to identify a new enrollee's previous and concurrent payer(s)
to facilitate the Payer-to-Payer API data exchange. The information
request process must start as follows:
(i) For current enrollees, no later than the compliance date.
(ii) For new enrollees, no later than 1 week after the coverage
start date or no later than 1 week after receiving acceptance of
enrollment from CMS, whichever is later.
(iii) If an enrollee does not respond or additional information is
necessary, the MA organization must make reasonable efforts to engage
with the enrollee to collect this information.
(4) Exchange request requirements. Exchange enrollee data with
other payers, consistent with the following requirements:
(i) The MA organization must request the data listed in paragraph
(b)(4)(ii) of this section through the enrollee's previous payers' API,
if all the following conditions are met:
(A) The enrollee has opted in, as described in paragraph (b)(2) of
this section.
(B) The exchange is not prohibited by other applicable law.
(ii) The data to be requested are all of the following with a date
of service within 5 years before the request:
(A) Data specified in Sec. 422.119(b) excluding the following:
(1) Provider remittances and enrollee cost-sharing information.
(2) Denied prior authorizations.
(B) Unstructured administrative and clinical documentation
submitted by a provider related to prior authorizations.
(iii) The MA organization must include an attestation with this
request affirming that the enrollee is enrolled with the MA
organization and has opted into the data exchange.
(iv) The MA organization must complete this request as follows:
(A) No later than 1 week after the payer has sufficient identifying
information about previous payers and the enrollee has opted in.
(B) At an enrollee's request, within 1 week of the request.
(v) The MA organization must receive, through the API required in
paragraph (b)(1) of this section, and incorporate into its records
about the enrollee, any data made available by other payers in response
to the request.
(5) Exchange response requirements. Make available the data
specified in paragraph (b)(4)(ii) of this section that are maintained
by the MA organization to other payers via the API required in
paragraph (b)(1) of this section within 1 business day of receiving a
request, if all the following conditions are met:
(i) The payer that requests access has its identity authenticated
and includes an attestation with the request that the patient is
enrolled with the payer and has opted into the data exchange.
(ii) Disclosure of the data is not prohibited by other applicable
law.
(6) Concurrent coverage data exchange requirements. When an
enrollee has provided sufficient identifying information about
concurrent payers and has opted in as described in paragraph (b)(2) of
this section, an MA organization must do the following, through the API
required in paragraph (b)(1) of this section:
(i) Request the enrollee's data from all known concurrent payers as
described

[[Page 8976]]

in paragraph (b)(4) of this section, and at least quarterly thereafter
while the enrollee is enrolled with both payers.
(ii) Respond as described in paragraph (b)(5) of this section
within 1 business day of a request from any concurrent payers. If
agreed upon with the requesting payer, the MA organization may exclude
any data that were previously sent to or originally received from the
concurrent payer.
(7) Patient educational resources. Provide information to enrollees
in plain language, explaining at a minimum: the benefits of Payer-to-
Payer API data exchange, their ability to opt in or withdraw that
permission, and instructions for doing so. The MA organization must
provide the following resources:
(i) When requesting an enrollee's permission for Payer-to-Payer API
data exchange, as described in paragraph (b)(2) of this section.
(ii) At least annually, in appropriate mechanisms through which it
ordinarily communicates with current enrollees.
(iii) In an easily accessible location on its public website.

0
4. Section 422.122 is added to read as follows:

Sec. 422.122 Prior authorization requirements.

(a) Communicating a reason for denial. Beginning January 1, 2026,
if the MA organization denies a prior authorization request (excluding
request for coverage of drugs as defined in Sec. 422.119(b)(1)(v)), in
accordance with the timeframes established in Sec. Sec. 422.568(b)(1)
and 422.572(a)(1), the response to the provider must include a specific
reason for the denial, regardless of the method used to communicate
that information.
(b) Prior Authorization Application Programming Interface (API).
Beginning January 1, 2027, an MA organization must implement and
maintain an API conformant with Sec. 422.119(c)(2) through (4), (d),
and (e), and the standards in 45 CFR 170.215(a)(1), (b)(1)(i), and
(c)(1) that--
(1) Is populated with the MA organization's list of covered items
and services (excluding drugs, as defined in Sec. 422.119(b)(1)(v))
that require prior authorization;
(2) Can identify all documentation required by the MA organization
for approval of any items or services that require prior authorization;
(3) Supports a Health Insurance Portability and Accountability Act
(HIPAA)-compliant prior authorization request and response, as
described in 45 CFR part 162; and
(4) Communicates the following information about prior
authorization requests:
(i) Whether the MA organization--
(A) Approves the prior authorization request (and the date or
circumstance under which the authorization ends);
(B) Denies the prior authorization request; or
(C) Requests more information.
(ii) If the MA organization denies the prior authorization request,
it must include a specific reason for the denial.
(5) In addition to the requirements of this section, an MA
organization using prior authorization polices or making prior
authorization decisions must meet all other applicable requirements
under this part, including Sec. 422.138 and the requirements in
subpart M of this part.
(c) Publicly reporting prior authorization metrics. Beginning in
2026, following each calendar year that it offers an MA plan, an MA
organization must report prior authorization data, excluding data on
drugs as defined in Sec. 422.119(b)(1)(v), at the MA contract level by
March 31. The MA organization must make the following data from the
previous calendar year publicly accessible by posting them on its
website:
(1) A list of all items and services that require prior
authorization.
(2) The percentage of standard prior authorization requests that
were approved, aggregated for all items and services.
(3) The percentage of standard prior authorization requests that
were denied, aggregated for all items and services.
(4) The percentage of standard prior authorization requests that
were approved after appeal, aggregated for all items and services.
(5) The percentage of prior authorization requests for which the
timeframe for review was extended, and the request was approved,
aggregated for all items and services.
(6) The percentage of expedited prior authorization requests that
were approved, aggregated for all items and services.
(7) The percentage of expedited prior authorization requests that
were denied, aggregated for all items and services.
(8) The average and median time that elapsed between the submission
of a request and a determination by the MA plan, for standard prior
authorizations, aggregated for all items and services.
(9) The average and median time that elapsed between the submission
of a request and a decision by the MA plan for expedited prior
authorizations, aggregated for all items and services.

0
5. Section 422.568 is amended by--
0
a. Revising paragraph (b)(1);
0
b. Redesignating paragraph (b)(2) as paragraph (b)(3);
0
c. Adding new paragraph (b)(2); and
0
d. In newly redesignated paragraph (b)(3), removing the phrase ``under
the provisions in paragraph (b)(1)(i) of this section'' and adding in
its place the phrase ``under the provisions in paragraph (b)(2) of this
section.''
The revision and addition read as follows:

Sec. 422.568 Standard timeframes and notice requirements for
organization determinations.

* * * * *
(b) * * *
(1) Requests for service or item. Except as provided in paragraph
(b)(2) of this section, when a party has made a request for an item or
service, the MA organization must notify the enrollee of its
determination as expeditiously as the enrollee's health condition
requires but no later than either of the following:
(i) For a service or item not subject to the prior authorization
rules in Sec. 422.122, 14 calendar days after receiving the request
for the standard organization determination.
(ii) Beginning on or after January 1, 2026, for a service or item
subject to the prior authorization rules in Sec. 422.122, 7 calendar
days after receiving the request for the standard organization
determination.
(2) Extensions; requests for service or item--(i) Extension of
timeframe on a request for service or item. The MA organization may
extend the timeframe by up to 14 calendar days under any of the
following circumstances:
(A) The enrollee requests the extension.
(B) The extension is justified and in the enrollee's interest due
to the need for additional medical evidence from a noncontract provider
that may change an MA organization's decision to deny an item or
service.
(C) The extension is justified due to extraordinary, exigent, or
other non-routine circumstances and is in the enrollee's interest.
(ii) Notice of extension. (A) When the MA organization extends the
timeframe, it must--
(1) Notify the enrollee in writing of the reasons for the delay;
and
(2) Inform the enrollee of the right to file an expedited grievance
if the enrollee disagrees with the MA organization's decision to grant
an extension.
(B) The MA organization must notify the enrollee of its
determination as expeditiously as the enrollee's health

[[Page 8977]]

condition requires, but no later than upon expiration of the extension.
* * * * *

Sec. 422.570 [Amended]

0
6. Section 422.570 is amended in paragraph (d)(1) by removing the
phrase ``request to the standard timeframe and make the determination
within the 72-hour or 14-day timeframe, as applicable, established''
and adding in its place the phrase ``request to a standard organization
determination and make the determination within the applicable
timeframe, established''.

0
7. Section 422.631 is amended by revising paragraphs (d)(2)(i)(B),
(d)(2)(iv)(B)(1), and (d)(2)(iv)(B)(2)(i) to read as follows:

Sec. 422.631 Integrated organization determinations.

* * * * *
(d) * * *
(2) * * *
(i) * * *
(B) Except as described in paragraph (d)(2)(i)(A) of this section,
the applicable integrated plan must send a notice of its integrated
organization determination as expeditiously as the enrollee's health
condition requires but no later than either of the following:
(1) For a service or item not subject to the prior authorization
rules in Sec. 422.122, 14 calendar days after receiving the request
for the standard integrated organization determination.
(2) Beginning on or after January 1, 2026, for a service or item
subject to the prior authorization rules in Sec. 422.122, 7 calendar
days after receiving the request for the standard integrated
organization determination.
* * * * *
(iv) * * *
(B) * * *
(1) Automatically transfer a request to the standard timeframe and
make the determination within the applicable timeframe established in
paragraph (d)(2)(i)(B) of this section for a standard integrated
organization determination. The timeframe begins the day the applicable
integrated plan receives the request for expedited integrated
organization determination.
(2) * * *
(i) Explains that the applicable integrated plan will process the
request using the timeframe for standard integrated organization
determinations;
* * * * *

PART 431--STATE ORGANIZATION AND GENERAL ADMINISTRATION

0
8. The authority citation for part 431 continues to read as follows:

Authority: 42 U.S.C. 1302.

0
9. Section 431.60 is amended by--
0
a. Revising paragraph (b)(3);
0
b. Adding paragraphs (b)(5) and (6);
0
c. Revising paragraphs (c)(1), (c)(4)(ii)(C), and (e)(2);
0
d. Removing paragraph (g);
0
e. Redesignating paragraph (f) as paragraph (g); and
0
f. Adding new paragraph (f) and paragraph (h).
The revisions and addition read as follows:

Sec. 431.60 Beneficiary access to and exchange of data.

* * * * *
(b) * * *
(3) All data classes and data elements included in a content
standard in 45 CFR 170.213 that are maintained by the State no later
than 1 business day after the State receives the data; and
* * * * *
(5) Beginning January 1, 2027, the information in paragraph
(b)(5)(i) of this section about prior authorizations for items and
services (excluding drugs as defined in paragraph (b)(6) of this
section), according to the timelines in paragraph (b)(5)(ii) of this
section.
(i) The prior authorization request and decision, including all of
the following, as applicable:
(A) The prior authorization status.
(B) The date the prior authorization was approved or denied.
(C) The date or circumstance under which the prior authorization
ends.
(D) The items and services approved.
(E) If denied, a specific reason why the request was denied.
(F) Related structured administrative and clinical documentation
submitted by a provider.
(ii) The information in paragraph (b)(5)(i) of this section must--
(A) Be accessible no later than 1 business day after the State
receives a prior authorization request;
(B) Be updated no later than 1 business day after any status
change; and
(C) Continue to be accessible for the duration that the
authorization is active and at least 1 year after the prior
authorization's last status change.
(6) Drugs are defined for the purposes of paragraph (b)(5) of this
section as any and all drugs covered by the State.
* * * * *
(c) * * *
(1) Must implement and maintain API technology conformant with 45
CFR 170.215(a)(1), (b)(1)(i), (c)(1), and (e)(1);
* * * * *
(4) * * *
(ii) * * *
(C) Using the updated version of the standard, implementation
guide, or specification does not disrupt an end user's ability to
access the data specified in paragraph (b) of this section or
Sec. Sec. 431.61, 431.70, and 431.80, through the required APIs.
* * * * *
(e) * * *
(2) Makes this determination using objective, verifiable criteria
that are applied fairly and consistently across all apps and developers
through which parties seek to access electronic health information, as
defined in 45 CFR 171.102, including but not limited to criteria that
rely on automated monitoring and risk mitigation tools.
* * * * *
(f) Reporting on Patient Access API usage. Beginning in 2026, by
March 31 of each year, a State must report to CMS the following
metrics, in the form of aggregated, de-identified data, for the
previous calendar year at the State level in the form and manner
specified by the Secretary:
(1) The total number of unique beneficiaries whose data are
transferred via the Patient Access API to a health app designated by
the beneficiary; and
(2) The total number of unique beneficiaries whose data are
transferred more than once via the Patient Access API to a health app
designated by the beneficiary.
* * * * *
(h) Applicability. A State must comply with the requirements in
paragraphs (a) through (e) and (g) of this section beginning January 1,
2021, and with the requirements in paragraph (f) of this section
beginning in 2026, with regard to data:
(1) With a date of service on or after January 1, 2016; and
(2) That are maintained by the State.

0
10. Section 431.61 is added to read as follows:

Sec. 431.61 Access to and exchange of health data for providers and
payers.

[[Page 8978]]

service on or after January 1, 2016, excluding provider remittances and
beneficiary cost-sharing information, that are maintained by the State
available to enrolled Medicaid providers via the API required in
paragraph (a)(1) of this section no later than 1 business day after
receiving a request from such a provider, if all the following
conditions are met:
(i) The State authenticates the identity of the provider that
requests access and attributes the beneficiary to the provider under
the attribution process described in paragraph (a)(3) of this section.
(ii) The beneficiary does not opt out as described in paragraph
(a)(4) of this section.
(iii) Disclosure of the data is not prohibited by other applicable
law.
(3) Attribution. Establish and maintain a process to associate
beneficiaries with their enrolled Medicaid providers to enable data
exchange via the Provider Access API.
(4) Opt out and patient educational resources. (i) Establish and
maintain a process to allow a beneficiary or the beneficiary's personal
representative to opt out of the data exchange described in paragraph
(a)(2) of this section and to change their permission at any time. That
process must be available before the first date on which the State
makes beneficiary information available via the Provider Access API and
at any time while the beneficiary is enrolled with the State.
(ii) Provide information to beneficiaries in plain language about
the benefits of API data exchange with their providers, their opt out
rights, and instructions both for opting out of data exchange and for
subsequently opting in, as follows:
(A) Before the first date on which the State makes beneficiary
information available through the Provider Access API.
(B) No later than 1 week after enrollment.
(C) At least annually.
(D) In an easily accessible location on its public website.
(5) Provider resources. Provide on its website and through other
appropriate provider communications, information in plain language
explaining the process for requesting beneficiary data using the
Provider Access API required in paragraph (a)(1) of this section. The
resources must include information about how to use the State's
attribution process to associate beneficiaries with their providers.
(b) Application programming interface to support data exchange
between payers--Payer-to-Payer API. Beginning January 1, 2027, unless
granted an extension or exemption under paragraph (c) of this section,
a State must do the following:
(1) API requirements. Implement and maintain an API conformant with
all of the following:
(i) Section 431.60(c)(2) through (4), (d), and (e).
(ii) The standards in 45 CFR 170.215(a)(1), (b)(1)(i), and (d)(1).
(2) Opt in. Establish and maintain a process to allow beneficiaries
or their personal representatives to opt into the State's payer to
payer data exchange with the beneficiary's previous payer(s), described
in paragraphs (b)(4) and (5) of this section, and with concurrent
payer(s), described in paragraph (b)(6) of this section, and to change
their permission at any time.
(i) The opt in process must be offered as follows:
(A) To current beneficiaries, no later than the compliance date.
(B) To new beneficiaries, no later than 1 week after enrollment.
(ii) If a beneficiary has coverage through any Medicaid MCO,
prepaid inpatient health plan (PIHP), or prepaid ambulatory health plan
(PAHP) within the same State while enrolled in Medicaid, the State must
share their opt in permission with those MCO, PIHP, or PAHP to allow
the Payer-to-Payer API data exchange described in this section.
(iii) If a beneficiary does not respond or additional information
is necessary, the State must make reasonable efforts to engage with the
beneficiary to collect this information.
(3) Identify previous and concurrent payers. Establish and maintain
a process to identify a new beneficiary's previous and concurrent
payer(s) to facilitate the Payer-to-Payer API data exchange. The
information request process must start as follows:
(i) For current beneficiaries, no later than the compliance date.
(ii) For new beneficiaries, no later than 1 week after enrollment.
(iii) If a beneficiary does not respond or additional information
is necessary, the State must make reasonable efforts to engage with the
beneficiary to collect this information.
(4) Exchange request requirements. Exchange beneficiary data with
other payers, consistent with the following requirements:
(i) The State must request the data specified in paragraph
(b)(4)(ii) of this section through the beneficiary's previous payers'
API, if all the following conditions are met:
(A) The beneficiary has opted in, as described in paragraph (b)(2)
of this section, except for data exchanges between a State Medicaid
agency and its contracted MCOs, PIHPs, or PAHPs, which do not require a
beneficiary to opt in.
(B) The exchange is not prohibited by other applicable law.
(ii) The data to be requested are all of the following with a date
of service within 5 years before the request:
(A) Data specified in Sec. 431.60(b), excluding the following:
(1) Provider remittances and enrollee cost-sharing information.
(2) Denied prior authorizations.
(B) Unstructured administrative and clinical documentation
submitted by a provider related to prior authorizations.
(iii) The State must include an attestation with this request
affirming that the beneficiary is enrolled with the State and has opted
into the data exchange.
(iv) The State must complete this request as follows:
(A) No later than 1 week after the payer has sufficient identifying
information about previous payers and the beneficiary has opted in.
(B) At a beneficiary's request, within 1 week of the request.
(v) The State must receive, through the API required in paragraph
(b)(1) of this section, and incorporate into its records about the
beneficiary, any data made available by other payers in response to the
request.
(5) Exchange response requirements. Make available the data
specified in paragraph (b)(4)(ii) of this section that are maintained
by the State to other payers via the API required in paragraph (b)(1)
of this section within 1 business day of receiving a request, if all
the following conditions are met:
(i) The payer that requests access has its identity authenticated
and includes an attestation with the request that the patient is
enrolled with the payer and has opted into the data exchange.
(ii) Disclosure of the data is not prohibited by other applicable
law.
(6) Concurrent coverage data exchange requirements. When a
beneficiary has provided sufficient identifying information about
concurrent payers and has opted in as described in paragraph (b)(2) of
this section, a State must do the following, through the API required
in paragraph (b)(1) of this section:
(i) Request the beneficiary's data from all known concurrent payers
as described in paragraph (b)(4) of this section, and at least
quarterly thereafter while the beneficiary is enrolled with both
payers.
(ii) Respond as described in paragraph (b)(5) of this section
within 1 business day of a request from any concurrent payers. If
agreed upon with the

[[Page 8979]]

requesting payer, the State may exclude any data that were previously
sent to or originally received from the concurrent payer.
(7) Patient educational resources. Provide information to
applicants or beneficiaries in plain language, explaining at a minimum:
the benefits of Payer-to-Payer API data exchange, their ability to opt
in or withdraw that permission, and instructions for doing so. The
State must provide the following resources:
(i) When requesting a beneficiary's permission for Payer-to-Payer
API data exchange, as described in paragraph (b)(2) of this section.
(ii) At least annually, in appropriate mechanisms through which it
ordinarily communicates with current beneficiaries.
(iii) In an easily accessible location on its public website.
(c) Extensions and exemptions--(1) Extension. (i) A State may
submit a written application to request a one-time, 1-year extension of
the requirements in paragraph (a) or (b) of this section (or paragraphs
(a) and (b)) for its Medicaid fee-for-service (FFS) program. The
written application must be submitted as part of the State's annual
Advance Planning Document (APD) for Medicaid Management Information
System (MMIS) operations expenditures described in part 433, subpart C,
of this chapter, and approved before the compliance date for the
requirements to which the State is seeking an extension. It must
include all the following:
(A) A narrative justification describing the specific reasons why
the State cannot satisfy the requirement(s) by the compliance date and
why those reasons result from circumstances that are unique to the
agency operating the Medicaid FFS program.
(B) A report on completed and ongoing State activities that
evidence a good faith effort towards compliance.
(C) A comprehensive plan to meet the requirements no later than 1
year after the compliance date.
(ii) CMS grants the State's request if it determines, based on the
information provided, that--
(A) The request adequately establishes a need to delay
implementation; and
(B) The State has a comprehensive plan to meet the requirements no
later than 1 year after the compliance date.
(2) Exemption. (i) A State operating a Medicaid program in which at
least 90 percent of the State's Medicaid beneficiaries are enrolled in
Medicaid managed care organizations, as defined in Sec. 438.2 of this
chapter, may request an exemption for its FFS program from either or
both of the following requirement(s):
(A) Paragraph (a) of this section.
(B) Paragraphs (b)(1) and (3) through (7) of this section.
(ii) The State's exemption request must:
(A) Be submitted in writing as part of a State's annual APD for
MMIS operations expenditures before the compliance date for the
requirements to which the State is seeking an exemption.
(B) Include both of the following:
(1) Documentation that the State meets the threshold for the
exemption, based on enrollment data from the most recent CMS ``Medicaid
Managed Care Enrollment and Program Characteristics'' (or successor)
report.
(2) An alternative plan to ensure that enrolled providers will have
efficient electronic access to the same information through other means
while the exemption is in effect.
(iii) CMS grants the exemption if the State establishes to CMS's
satisfaction that the State--
(A) Meets the threshold for the exemption; and
(B) Has established an alternative plan to ensure that enrolled
providers will have efficient electronic access to the same information
through other means while the exemption is in effect.
(iv) The State's exemption expires if either--
(A) Based on the 3 previous years of available, finalized Medicaid
Transformed Medicaid Statistical Information System (T-MSIS) managed
care and FFS enrollment data, the State's managed care enrollment for 2
of the previous 3 years is below 90 percent; or
(B)(1) CMS has approved a State plan amendment, waiver, or waiver
amendment that would significantly reduce the percentage of
beneficiaries enrolled in managed care; and
(2) The anticipated shift in enrollment is confirmed by the first
available, finalized Medicaid T-MSIS managed care and FFS enrollment
data.
(v) If a State's exemption expires under paragraph (c)(2)(iv) of
this section, the State is required to do both of the following--
(A) Submit written notification to CMS that the State no longer
qualifies for the exemption within 90 days of the finalization of
annual Medicaid T-MSIS managed care enrollment data that demonstrates
that there has been the requisite shift from managed care enrollment to
FFS enrollment resulting in the State's managed care enrollment falling
below the 90 percent threshold.
(B) Obtain CMS approval of a timeline for compliance with the
requirements in paragraph (a) or (b) (or paragraph0s (a) and (b)) of
this section within 2 years of the expiration of the exemption.

0
11. Section 431.80 is added to subpart B to read as follows:

Sec. 431.80 Prior authorization requirements.

(a) Communicating a reason for denial. Beginning January 1, 2026,
if the State denies a prior authorization request (excluding a request
for coverage of drugs as defined in Sec. 431.60(b)(6)), in accordance
with the timeframes established in Sec. 440.230(e)(1) of this chapter,
the response to the provider must include a specific reason for the
denial, regardless of the method used to communicate that information.
(b) Prior Authorization Application Programming Interface (API).
Unless granted an extension or exemption under paragraph (c) of this
section, beginning January 1, 2027, a State must implement and maintain
an API conformant with Sec. 431.60(c)(2) through (4), (d), and (e),
and the standards in 45 CFR 170.215(a)(1), (b)(1)(i), and (c)(1) that--
(1) Is populated with the State's list of covered items and
services (excluding drugs, as defined in Sec. 431.60(b)(6)) that
require prior authorization;
(2) Can identify all documentation required by the State for
approval of any items or services that require prior authorization;
(3) Supports a HIPAA-compliant prior authorization request and
response, as described in 45 CFR part 162; and
(4) Communicates the following information about prior
authorization requests:
(i) Whether the State--
(A) Approves the prior authorization request (and the date or
circumstance under which the authorization ends);
(B) Denies the prior authorization request; or
(C) Requests more information.
(ii) If the State denies the prior authorization request, it must
include a specific reason for the denial.
(c) Extensions and exemptions--(1) Extension. (i) A State may
submit a written application to request a one-time, 1-year extension of
the requirements in paragraph (b) of this section for its Medicaid FFS
program. The written application must be submitted as part of the
State's annual APD for MMIS operations expenditures described in part
433, subpart C, of this chapter; and approved before the compliance
date in paragraph (b) of this section. It must include all the
following:
(A) A narrative justification describing the specific reasons why
the

[[Page 8980]]

State cannot satisfy the requirement(s) by the compliance date and why
those reasons result from circumstances that are unique to the agency
operating the Medicaid FFS program.
(B) A report on completed and ongoing State activities that
evidence a good faith effort towards compliance.
(C) A comprehensive plan to meet the requirements no later than 1
year after the compliance date.
(ii) CMS grants the State's request if it determines, based on the
information provided, that--
(A) The request adequately establishes a need to delay
implementation; and
(B) The State has a comprehensive plan to meet the requirements no
later than 1 year after the compliance date.
(2) Exemption. (i) A State operating a Medicaid program in which at
least 90 percent of the State's Medicaid beneficiaries are enrolled in
Medicaid managed care organizations, as defined in Sec. 438.2 of this
chapter, may request an exemption for its FFS program from the
requirements in paragraph (b) of this section.
(ii) The State's exemption request must:
(A) Be submitted in writing as part of a State's annual APD for
MMIS operations expenditures before the compliance date in paragraph
(b) of this section.
(B) The State's request must include both of the following:
(1) Documentation that the State meets the threshold for the
exemption, based on enrollment data from the most recent CMS ``Medicaid
Managed Care Enrollment and Program Characteristics'' (or successor)
report.
(2) An alternative plan to ensure that enrolled providers will have
efficient electronic access to the same information through other means
while the exemption is in effect.
(iii) CMS grants the exemption if the State establishes to CMS's
satisfaction that the State--
(A) Meets the threshold for the exemption; and
(B) Has established an alternative plan to ensure that enrolled
providers will have efficient electronic access to the same information
through other means while the exemption is in effect.
(iv) The State's exemption expires if either--
(A) Based on the 3 previous years of available, finalized Medicaid
Transformed Medicaid Statistical Information System (T-MSIS) managed
care and FFS enrollment data, the State's managed care enrollment for 2
of the previous 3 years is below 90 percent; or
(B)(1) CMS has approved a State plan amendment, waiver, or waiver
amendment that would significantly reduce the percentage of
beneficiaries enrolled in managed care; and
(2) The anticipated shift in enrollment is confirmed by the first
available, finalized Medicaid T-MSIS managed care and FFS enrollment
data.
(v) If a State's exemption expires under paragraph (c)(2)(iv) of
this section, the State is required to do both of the following--
(A) Submit written notification to CMS that the State no longer
qualifies for the exemption within 90 days of the finalization of
annual Medicaid T-MSIS managed care enrollment data that demonstrates
that there has been the requisite shift from managed care enrollment to
FFS enrollment resulting in the State's managed care enrollment falling
below the 90 percent threshold.
(B) Obtain CMS approval of a timeline for compliance with the
requirements in paragraph (b) of this section within 2 years of the
expiration of the exemption.

0
12. Section 431.201 is amended by revising the definition of ``Action''
to read as follows:

Sec. 431.201 Definitions.

* * * * *
Action means one of the following:
(1) A termination, suspension of, or reduction in covered benefits
or services, including benefits or services for which there is a
current approved prior authorization;
(2) A termination, suspension of, or reduction in Medicaid
eligibility, or an increase in beneficiary liability, including a
determination that a beneficiary must incur a greater amount of medical
expenses to establish income eligibility in accordance with Sec.
435.121(e)(4) or Sec. 435.831 of this chapter;
(3) A determination that a beneficiary is subject to an increase in
premiums or cost-sharing charges under subpart A of part 447 of this
chapter; or
(4) A determination by a skilled nursing facility or nursing
facility to transfer or discharge a resident and an adverse
determination by a State regarding the preadmission screening and
resident review requirements of section 1919(e)(7) of the Act.
* * * * *

0
13. Section 431.220 is amended by--
0
a. In paragraph (a)(1)(iv), removing the term ``or'' from the end of
the paragraph;
0
b. In paragraph (a)(1)(v), removing the period from the end of the
paragraph and adding in its place ``; or''; and
0
c. Adding paragraph (a)(1)(vi).
The addition reads as follows:

Sec. 431.220 When a hearing is required.

(a) * * *
(1) * * *
(vi) A prior authorization decision.
* * * * *

PART 435--ELIGIBILITY IN THE STATES, DISTRICT OF COLUMBIA, THE
NORTHERN MARIANA ISLANDS, AND AMERICAN SAMOA

0
14. The authority citation for part 435 continues to read as follows:

Authority: 42 U.S.C. 1302.

0
15. Section 435.917 is amended by--
0
a. Revising the headings of paragraphs (a) and (b); and
0
b. Revising paragraph (b)(2).
The revisions read as follows:

Sec. 435.917 Notice of agency's decision concerning eligibility,
benefits, or services.

(a) Notice of determinations. * * *
(b) Content of notice--* * *
(2) Notice of adverse action. Notice of adverse action including
denial, termination, or suspension of eligibility or change in benefits
or services. Any notice of denial, termination, or suspension of
Medicaid eligibility, or, in the case of beneficiaries receiving
medical assistance, denial of or change in benefits or services must be
consistent with Sec. 431.210 of this chapter.
* * * * *

PART 438--MANAGED CARE

0
16. The authority citation for part 438 continues to read as follows:

Authority: 42 U.S.C. 1302.

0
17. Section 438.9 is amended by revising paragraph (b)(7) to read as
follows:

Sec. 438.9 Provisions that apply to non-emergency medical
transportation PAHPs.

* * * * *
(b) * * *
(7) The PAHP standards in Sec. Sec. 438.206(b)(1), 438.210,
438.214, 438.224, 438.230, and 438.242, excluding the requirement in
Sec. 438.242(b)(7), to comply with Sec. 431.61(a) and (b) of this
chapter.
* * * * *

Sec. 438.62 [Amended]

0
18. Section 438.62 is amended by removing paragraphs (b)(1)(vi) and
(vii).

0
19. Section 438.210 is amended by--
0
a. Revising paragraphs (d)(1) and (d)(2)(i);
0
b. Redesignating paragraph (f) as paragraph (g); and
0
c. Adding new paragraph (f).
The addition and revision read as follows:

[[Page 8981]]

Sec. 438.210 Coverage and authorization of services.

* * * * *
(d) * * *
(1) Standard authorization decisions. (i) For standard
authorization decisions, provide notice as expeditiously as the
enrollee's condition requires and:
(A) For rating periods that start before January 1, 2026, within
state established time frames that may not exceed 14 calendar days
after receiving the request for service.
(B) For rating periods that start on or after January 1, 2026,
within state established time frames that may not exceed 7 calendar
days after receiving the request for service.
(ii) Standard authorization decisions may have an extension to the
timeframes in paragraph (d)(1)(i) of this section up to 14 additional
calendar days if--
(A) The enrollee or the provider requests the extension; or
(B) The MCO, PIHP, or PAHP justifies (to the State agency upon
request) a need for additional information and how the extension is in
the enrollee's interest.
(2) * * *
(i) For cases in which a provider indicates, or the MCO, PIHP, or
PAHP determines, that following the standard timeframe could seriously
jeopardize the enrollee's life or health or ability to attain,
maintain, or regain maximum function, the MCO, PIHP, or PAHP must make
an expedited authorization decision and provide notice as expeditiously
as the enrollee's health condition requires and no later than 72 hours
after receipt of the request for service.
* * * * *
(f) Publicly reporting prior authorization metrics. Beginning
January 1, 2026, following each calendar year it has a contract with a
State Medicaid agency, the MCO, PIHP, or PAHP must report prior
authorization data, excluding data on any and all drugs covered by the
MCO, PIHP, or PAHP, at the plan level by March 31. The MCO, PIHP, or
PAHP must make the following data from the previous calendar year
publicly accessible by posting them on its website:
(1) A list of all items and services that require prior
authorization.
(2) The percentage of standard prior authorization requests that
were approved, aggregated for all items and services.
(3) The percentage of standard prior authorization requests that
were denied, aggregated for all items and services.
(4) The percentage of standard prior authorization requests that
were approved after appeal, aggregated for all items and services.
(5) The percentage of prior authorization requests for which the
timeframe for review was extended, and the request was approved,
aggregated for all items and services.
(6) The percentage of expedited prior authorization requests that
were approved, aggregated for all items and services.
(7) The percentage of expedited prior authorization requests that
were denied, aggregated for all items and services.
(8) The average and median time that elapsed between the submission
of a request and a determination by the MCO, PIHP or PAHP, for standard
prior authorizations, aggregated for all items and services.
(9) The average and median time that elapsed between the submission
of a request and a decision by the MCO, PIHP or PAHP, for expedited
prior authorizations, aggregated for all items and services.
* * * * *

0
20. Section 438.242 is amended by revising paragraph (b)(5) and adding
paragraphs (b)(7) through (9) to read as follows:

Sec. 438.242 Health information systems.

* * * * *
(b) * * *
(5) Subject to paragraph (b)(8) of this section, implement and
maintain a Patient Access Application Programming Interface (API)
required in Sec. 431.60 of this chapter as if such requirements
applied directly to the MCO, PIHP, or PAHP and:
(i) Include all encounter data, including encounter data from any
network providers the MCO, PIHP, or PAHP is compensating based on
capitation payments and adjudicated claims and encounter data from any
subcontractors.
(ii) Exclude covered outpatient drugs as defined in section
1927(k)(2) of the Act.
(iii) Report metrics specified in Sec. 431.60(f) of this chapter
at the plan level.
* * * * *
(7) By the rating period beginning on or after January 1, 2027,
comply with Sec. Sec. 431.61(a), (b)(1) and (4) through (6), and
(b)(7)(ii) and (iii) and 431.80(b) of this chapter as if such
requirements applied directly to the MCO, PIHP, or PAHP
(8) By the rating period beginning on or after January 1, 2026,
comply with Sec. 431.80(a) of this chapter as if such requirements
applied directly to the MCO, PIHP, or PAHP according to the decision
timeframes in Sec. 438.210(d).
(9) The following timeframes apply to paragraph (b)(5) of this
section:
(i) Except for the requirements in Sec. 431.60(b)(5), (g), and (h)
of this chapter, comply with the requirements of Sec. 431.60 of this
chapter by January 1, 2021.
(ii) Comply with the requirements in Sec. 431.60(b)(5) and (g) of
this chapter by the rating period beginning on or after January 1,
2026.
(iii) Beginning in 2026, by March 31 following any year the MCO,
PIHP, or PAHP operates, comply with the reporting requirements in Sec.
431.60(h) of this chapter for the previous calendar year's data, in the
form of aggregated, de-identified metrics, at the plan level.
* * * * *

PART 440--SERVICES: GENERAL PROVISIONS

0
21. The authority citation for part 440 continues to read as follows:

Authority: 42 U.S.C. 1302.

0
22. Section 440.230 is amended by adding paragraph (e) to read as
follows:

Sec. 440.230 Sufficiency of amount, duration, and scope.

* * * * *
(e) For prior authorization requests for items and services
(excluding drugs, as defined in Sec. 431.60(b)(6) of this chapter),
the State Medicaid agency must--
(1) Beginning January 1, 2026, make prior authorization decisions
within the following timeframes:
(i) For a standard determination, as expeditiously as a
beneficiary's health condition requires, but in no case later than 7
calendar days after receiving the request, unless a shorter minimum
timeframe is established under State law. The timeframe for standard
authorization decisions can be extended by up to 14 calendar days if
the beneficiary or provider requests an extension, or if the State
agency determines that additional information from the provider is
needed to make a decision.
(ii) For an expedited determination, as expeditiously as a
beneficiary's health condition requires, but in no case later than 72
hours after receiving the request, unless a shorter minimum timeframe
is established under State law.
(2) Provide the beneficiary with notice of the agency's prior
authorization decision in accordance with Sec. 435.917 of this chapter
and provide fair hearing rights, including advance notice, in
accordance with part 431, subpart E, of this chapter.

[[Page 8982]]

(3) Beginning in 2026, annually report prior authorization data,
excluding data on drugs, as defined in Sec. 431.60(b)(6) of this
chapter, at the State level by March 31. The State must make the
following data from the previous calendar year publicly accessible by
posting them on its website:
(i) A list of all items and services that require prior
authorization.
(ii) The percentage of standard prior authorization requests that
were approved, aggregated for all items and services.
(iii) The percentage of standard prior authorization requests that
were denied, aggregated for all items and services.
(iv) The percentage of standard prior authorization requests that
were approved after appeal, aggregated for all items and services.
(v) The percentage of prior authorization requests for which the
timeframe for review was extended, and the request was approved,
aggregated for all items and services.
(vi) The percentage of expedited prior authorization requests that
were approved, aggregated for all items and services.
(vii) The percentage of expedited prior authorization requests that
were denied, aggregated for all items and services.
(viii) The average and median time that elapsed between the
submission of a request and a determination by the State Medicaid
agency, for standard prior authorizations, aggregated for all items and
services.
(ix) The average and median time that elapsed between the
submission of a request and a decision by the State Medicaid agency for
expedited prior authorizations, aggregated for all items and services.

PART 457--ALLOTMENTS AND GRANTS TO STATES

0
23. The authority citation for part 457 continues to read as follows:

Authority: 42 U.S.C. 1302.

0
24. Section 457.495 is amended by revising paragraph (d) to read as
follows:

Sec. 457.495 State assurance of access to care and procedures to
assure quality and appropriateness of care.

* * * * *
(d) That decisions related to the prior authorization of health
services are completed as follows:
(1) Before January 1, 2026. (i) In accordance with the medical
needs of the patient, within 14 days after receipt of a request for
services. A possible extension of up to 14 days may be permitted if the
enrollee requests the extension or if the physician or health plan
determines that additional information is needed; or
(ii) In accordance with existing State law regarding prior
authorization of health services.
(2) On or after January 1, 2026. (i) In accordance with the medical
needs of the enrollee, but no later than 7 calendar days after
receiving the request for a standard determination and by no later than
72 hours after receiving the request for an expedited determination. A
possible extension of up to 14 days may be permitted if the enrollee
requests the extension or if the physician or health plan determines
the additional information is needed; or
(ii) In accordance with existing State law regarding prior
authorization of health services.
(3) Enrollee notification. Provide the enrollee with--
(i) Notice of the State's prior authorization decision; and
(ii) Information on the enrollee's right to a review process, in
accordance with Sec. 457.1180.

0
25. Section 457.700 is amended by revising paragraph (c) to read as
follows:

Sec. 457.700 Basis, scope, and applicability.

* * * * *
(c) Applicability. The requirements of this subpart apply to
separate child health programs and Medicaid expansion programs, except
that Sec. Sec. 457.730, 457.731, and 457.732 do not apply to Medicaid
expansion programs. Separate child health programs that provide
benefits exclusively through managed care entities may meet the
requirements of Sec. Sec. 457.730, 457.731, and 457.732 by requiring
the managed care entities to meet the requirements of Sec.
457.1233(d).

0
26. Section 457.730 is amended by--
0
a. Revising paragraph (b)(3);
0
b. Adding paragraphs (b)(5) and (6);
0
c. Revising paragraphs (c)(1), (c)(4)(ii)(C), and (e)(2);
0
d. Removing paragraph (g);
0
e. Redesignating paragraph (f) as paragraph (g); and
0
f. Adding new paragraph (f) and paragraph (h).
The revisions and additions read as follows:

Sec. 457.730 Beneficiary access to and exchange of data.

* * * * *
(b) * * *
(3) All data classes and data elements included in a content
standard in 45 CFR 170.213 that are maintained by the State no later
than 1 business day after the State receives the data; and
* * * * *
(5) Beginning January 1, 2027, the information in paragraph
(b)(5)(i) of this section about prior authorizations for items and
services (excluding drugs as defined in paragraph (b)(6) of this
section), according to the timelines in paragraph (b)(5)(ii) of this
section.
(i) The prior authorization request and decision, including all of
the following, as applicable:
(A) The prior authorization status.
(B) The date the prior authorization was approved or denied.
(C) The date or circumstance under which the prior authorization
ends.
(D) The items and services approved.
(E) If denied, a specific reason why the request was denied.
(F) Related structured administrative and clinical documentation
submitted by a provider.
(ii) The information in paragraph (b)(5)(i) of this section must--
(A) Be accessible no later than 1 business day after the State
receives a prior authorization request;
(B) Be updated no later than 1 business day after any status
change; and
(C) Continue to be accessible for the duration that the
authorization is active and at least 1 year after the prior
authorization's last status change.
(6) Drugs are defined for the purposes of paragraph (b)(5) of this
section as any and all drugs covered by the State.
(c) * * *
(1) Must implement and maintain API technology conformant with 45
CFR 170.215(a)(1), (b)(1)(i), (c)(1), and (e)(1);
* * * * *
(4) * * *
(ii) * * *
(C) Using the updated version of the standard, implementation
guide, or specification does not disrupt an end user's ability to
access the data specified in paragraph (b) of this section or
Sec. Sec. 457.731, 457.732, and 457.760 through the required APIs.
* * * * *
(e) * * *
(2) Makes this determination using objective, verifiable criteria
that are applied fairly and consistently across all apps and developers
through which parties seek to access electronic health information, as
defined in 45 CFR 171.102, including but not limited to criteria that
rely on automated monitoring and risk mitigation tools.
* * * * *
(f) Reporting on Patient Access API usage. Beginning in 2026, by
March 31 of each year, a State must report to CMS the following
metrics, in the form of aggregated, de-identified data, for the
previous calendar year at the State level

[[Page 8983]]

in the form and manner specified by the Secretary:
(1) The total number of unique beneficiaries whose data are
transferred via the Patient Access API to a health app designated by
the beneficiary; and
(2) The total number of unique beneficiaries whose data are
transferred more than once via the Patient Access API to a health app
designated by the beneficiary.
* * * * *
(h) Applicability. A State must comply with the requirements in
paragraphs (a) through (e) and (g) of this section beginning January 1,
2021, and with the requirements in paragraph (f) of this section
beginning in 2026, with regard to data:
(1) With a date of service on or after January 1, 2016; and
(2) That are maintained by the State.

0
27. Section 457.731 is added to read as follows:

Sec. 457.731 Access to and exchange of health data for providers and
payers.

(a) Application programming interface to support data exchange from
payers to providers--Provider Access API. Beginning January 1, 2027,
unless granted an extension or exemption under paragraph (c) of this
section, a State must do the following:
(1) API requirements. Implement and maintain an application
programming interface (API) conformant with all of the following:
(i) Section 457.730(c)(2) through (4), (d), and (e).
(ii) The standards in 45 CFR 170.215(a)(1), (b)(1)(i), (c)(1), and
(d)(1).
(2) Provider access. Make the data specified in Sec. 457.730(b)
with a date of service on or after January 1, 2016, excluding provider
remittances and beneficiary cost-sharing information, that are
maintained by the State, available to enrolled CHIP providers via the
API required in paragraph (a)(1) of this section no later than 1
business day after receiving a request from such a provider, if all the
following conditions are met:
(i) The State authenticates the identity of the provider that
requests access and attributes the beneficiary to the provider under
the attribution process described in paragraph (a)(3) of this section.
(ii) The beneficiary does not opt out as described in paragraph
(a)(4) of this section.
(iii) Disclosure of the data is not prohibited by other applicable
law.
(3) Attribution. Establish and maintain a process to associate
beneficiaries with their enrolled CHIP providers to enable data
exchange via the Provider Access API.
(4) Opt out and patient educational resources. (i) Establish and
maintain a process to allow a beneficiary or the beneficiary's personal
representative to opt out of the data exchange described in paragraph
(a)(2) of this section and to change their permission at any time. That
process must be available before the first date on which the State
makes beneficiary information available via the Provider Access API and
at any time while the beneficiary is enrolled with the State.
(ii) Provide information to beneficiaries in plain language about
the benefits of API data exchange with their providers, their opt out
rights, and instructions both for opting out of data exchange and for
subsequently opting in, as follows:
(A) Before the first date on which the State makes beneficiary
information available through the Provider Access API.
(B) No later than 1 week after enrollment.
(C) At least annually.
(D) In an easily accessible location on its public website.
(5) Provider resources. Provide on its website and through other
appropriate provider communications, information in plain language
explaining the process for requesting beneficiary data using the
Provider Access API required in paragraph (a)(1) of this section. The
resources must include information about how to use the State's
attribution process to associate beneficiaries with their providers.
(b) Application programming interface to support data exchange
between payers--Payer-to-Payer API. Beginning January 1, 2027, unless
granted an extension or exemption under paragraph (c) of this section a
State must do the following:
(1) API requirements. Implement and maintain an API conformant with
all of the following:
(i) Section 457.730(c)(2) through (4), (d), and (e).
(ii) The standards in 45 CFR 170.215(a)(1), (b)(1)(i), and (d)(1).
(2) Opt in. Establish and maintain a process to allow beneficiaries
or their personal representatives to opt into the State's payer to
payer data exchange with the beneficiary's previous payer(s), described
in paragraphs (b)(4) and (5) of this section, and with concurrent
payer(s), described in paragraph (b)(6) of this section, and to change
their permission at any time.
(i) The opt in process must be offered as follows:
(A) To current beneficiaries, no later than the compliance date.
(B) To new beneficiaries, no later than 1 week after enrollment.
(ii) If a beneficiary has coverage through any CHIP managed care
entities within the same State while enrolled in CHIP, the State must
share their opt in permission with those managed care entities to allow
the Payer-to-Payer API data exchange described in this section.
(iii) If a beneficiary does not respond or additional information
is necessary, the State must make reasonable efforts to engage with the
beneficiary to collect this information.
(3) Identify previous and concurrent payers. Establish and maintain
a process to identify a new beneficiary's previous and concurrent
payer(s) to facilitate the Payer-to-Payer API data exchange. The
information request process must start as follows:
(i) For current beneficiaries, no later than the compliance date.
(ii) For new beneficiaries, no later than 1 week after enrollment.
(iii) If a beneficiary does not respond or additional information
is necessary, the State must make reasonable efforts to engage with the
beneficiary to collect this information.
(4) Exchange request requirements. Exchange beneficiary data with
other payers, consistent with the following requirements:
(i) The State must request the data specified in paragraph
(b)(4)(ii) of this section through the beneficiary's previous payers'
API, if all the following conditions are met:
(A) The beneficiary has opted in, as described in paragraph (b)(2)
of this section, except for data exchanges between a State CHIP agency
and its contracted managed care entities, which do not require a
beneficiary to opt in.
(B) The exchange is not prohibited by other applicable law.
(ii) The data to be requested are all of the following with a date
of service within 5 years before the request:
(A) Data specified in Sec. 457.730(b), excluding the following:
(1) Provider remittances and enrollee cost-sharing information.
(2) Denied prior authorizations.
(B) Unstructured administrative and clinical documentation
submitted by a provider related to prior authorizations.
(iii) The State must include an attestation with this request
affirming that the beneficiary is enrolled with the State and has opted
into the data exchange.
(iv) The State must complete this request as follows:
(A) No later than 1 week after the payer has sufficient identifying
information about previous payers and the beneficiary has opted in.

[[Page 8984]]

(B) At a beneficiary's request, within 1 week of the request.
(v) The State must receive, through the API required in paragraph
(b)(1) of this section, and incorporate into its records about the
beneficiary, any data made available by other payers in response to the
request.
(5) Exchange response requirements. Make available the data
specified in paragraph (b)(4)(ii) of this section that are maintained
by the State to other payers via the API required in paragraph (b)(1)
of this section within 1 business day of receiving a request, if all
the following conditions are met:
(i) The payer that requests access has its identity authenticated
and includes an attestation with the request that the patient is
enrolled with the payer and has opted into the data exchange.
(ii) Disclosure of the data is not prohibited by other applicable
law.
(6) Concurrent coverage data exchange requirements. When a
beneficiary has provided sufficient identifying information about
concurrent payers and has opted in as described in paragraph (b)(2) of
this section, a State must do the following, through the API required
in paragraph (b)(1) of this section:
(i) Request the beneficiary's data from all known concurrent payers
as described in paragraph (b)(4) of this section, and at least
quarterly thereafter while the beneficiary is enrolled with both
payers.
(ii) Respond as described in paragraph (b)(5) of this section
within 1 business day of a request from any concurrent payers. If
agreed upon with the requesting payer, the State may exclude any data
that were previously sent to or originally received from the concurrent
payer.
(7) Patient educational resources. Provide information to
applicants or beneficiaries in plain language, explaining at a minimum:
the benefits of Payer-to-Payer API data exchange, their ability to opt
in or withdraw that permission, and instructions for doing so. The
State must provide the following resources:
(i) When requesting a beneficiary's permission for Payer-to-Payer
API data exchange, as described in paragraph (b)(2) of this section.
(ii) At least annually, in appropriate mechanisms through which it
ordinarily communicates with current beneficiaries.
(iii) In an easily accessible location on its public website.
(c) Extensions and exemptions--(1) Extension. (i) A State may
submit a written application to request a one-time, 1-year extension of
the requirements in paragraph (a) or (b) (or paragraphs (a) and (b)) of
this section for its CHIP fee-for-service program. The written
application must be submitted as part of the State's annual Advance
Planning Document (APD) for Medicaid Management Information System
(MMIS) operations expenditures, as described in part 433, subpart C, of
this chapter, and approved before the compliance date for the
requirements to which the State is seeking an extension. It must
include all the following:
(A) A narrative justification describing the specific reasons why
the State cannot satisfy the requirement(s) by the compliance date and
why those reasons result from circumstances that are unique to the
agency operating the CHIP fee-for service program.
(B) A report on completed and ongoing State activities that
evidence a good faith effort towards compliance.
(C) A comprehensive plan to meet the requirements no later than 1
year after the compliance date.
(ii) CMS grants the State's request if it determines, based on the
information provided, that--
(A) The request adequately establishes a need to delay
implementation; and
(B) The State has a comprehensive plan to meet the requirements no
later than 1 year after the compliance date.
(2) Exemption. (i) A State operating a separate CHIP in which at
least 90 percent of the State's CHIP beneficiaries are enrolled in CHIP
managed care organizations, as defined in Sec. 457.10, may request an
exemption for its fee-for-service program from either or both of the
following requirements:
(A) Paragraph (a) of this section.
(B) Paragraphs (b)(1) and (3) through (7) of this section.
(ii) The State's exemption request must:
(A) Be submitted in writing as part of a State's annual APD for
MMIS operations expenditures before the compliance date for the
requirements to which the State is seeking an exemption.
(B) Include both of the following:
(1) Documentation that the State meets the threshold for the
exemption, based on enrollment data from section 5 of the most recently
accepted CHIP Annual Report Template System (CARTS).
(2) An alternative plan to ensure that enrolled providers will have
efficient electronic access to the same information through other means
while the exemption is in effect.
(iii) CMS grants the exemption if the State establishes to CMS's
satisfaction that the State--
(A) Meets the threshold for the exemption; and
(B) Has established an alternative plan to ensure that enrolled
providers will have efficient electronic access to the same information
through other means while the exemption is in effect.
(iv) The State's exemption expires if either--
(A) Based on the 3 previous years of available, finalized CHIP
CARTS managed care and fee-for-service enrollment data, the State's
managed care enrollment for 2 of the previous 3 years is below 90
percent; or
(B)(1) CMS has approved a State plan amendment, waiver, or waiver
amendment that would significantly reduce the percentage of
beneficiaries enrolled in managed care; and
(2) The anticipated shift in enrollment is confirmed by the first
available, finalized CARTS managed care and fee-for-service enrollment
data.
(v) If a State's exemption expires under paragraph (c)(2)(iv) of
this section, the State is required to do both of the following:
(A) Submit written notification to CMS that the State no longer
qualifies for the exemption within 90 days of the finalization of
annual CARTS managed care enrollment data that demonstrates that there
has been the requisite shift from managed care enrollment to fee-for-
service enrollment resulting in the State's managed care enrollment
falling below the 90 percent threshold.
(B) Obtain CMS approval of a timeline for compliance with the
requirements in paragraph (a) or (b) (or paragraphs (a) and (b)) of
this section within 2 years of the expiration of the exemption.

0
28. Section 457.732 is added to read as follows:

Sec. 457.732 Prior authorization requirements.

[[Page 8985]]

drugs as defined in Sec. 457.730(b)(6)) that require prior
authorization;
(2) Can identify all documentation required by the State for
approval of any items or services that require prior authorization;
(3) Supports a HIPAA-compliant prior authorization request and
response, as described in 45 CFR part 162; and
(4) Communicates the following information about prior
authorization requests:
(i) Whether the State--
(A) Approves the prior authorization request (and the date or
circumstance under which the authorization ends);
(B) Denies the prior authorization request; or
(C) Requests more information.
(ii) If the State denies the prior authorization request, it must
include a specific reason for the denial.
(c) Publicly reporting prior authorization metrics. Beginning in
2026, a State must annually report prior authorization data, excluding
data on drugs as defined in Sec. 457.730(b)(6), at the State level by
March 31. The State must make the following data from the previous
calendar year publicly accessible by posting them on its website:
(1) A list of all items and services that require prior
authorization.
(2) The percentage of standard prior authorization requests that
were approved, aggregated for all items and services.
(3) The percentage of standard prior authorization requests that
were denied, aggregated for all items and services.
(4) The percentage of standard prior authorization requests that
were approved after appeal, aggregated for all items and services.
(5) The percentage of prior authorization requests for which the
timeframe for review was extended, and the request was approved,
aggregated for all items and services.
(6) The percentage of expedited prior authorization requests that
were approved, aggregated for all items and services.
(7) The percentage of expedited prior authorization requests that
were denied, aggregated for all items and services.
(8) The average and median time that elapsed between the submission
of a request and a determination by the State, for standard prior
authorizations, aggregated for all items and services.
(9) The average and median time that elapsed between the submission
of a request and a decision by the State for expedited prior
authorizations, aggregated for all items and services.
(d) Extensions and exemptions--(1) Extension. (i) A State may
submit a written application to request a one-time, 1-year extension of
the requirements in paragraph (b) of this section for its CHIP fee-for-
service program. The written application must be submitted and approved
as part of the State's annual Advance Planning Document (APD) for
Medicaid Management Information System (MMIS) operations expenditures
described in part 433, subpart C, of this chapter, and approved before
the compliance date in paragraph (b) of this section. It must include
all the following:
(A) A narrative justification describing the specific reasons why
the State cannot satisfy the requirement(s) by the compliance date and
why those reasons result from circumstances that are unique to the
agency operating the CHIP fee-for service program;
(B) A report on completed and ongoing State activities that
evidence a good faith effort toward compliance.
(C) A comprehensive plan to meet the requirements no later than 1
year after the compliance date.
(ii) CMS grants the State's request if it determines, based on the
information provided, that--
(A) The request adequately establishes a need to delay
implementation; and
(B) The State has a comprehensive plan to meet the requirements no
later than 1 year after the compliance date.
(2) Exemption. (i) A State operating a separate CHIP in which at
least 90 percent of the State's CHIP beneficiaries are enrolled in CHIP
managed care organizations, as defined in Sec. 457.10, may request an
exemption for its fee-for-service program from the requirements in
paragraph (b) of this section.
(ii) The State's exemption request must:
(A) Be submitted in writing as part of a State's annual APD for
MMIS operations expenditures before the compliance date in paragraph
(b) of this section.
(B) Include both of the following:
(1) Documentation that the State meets the threshold for the
exemption, based on enrollment data from section 5 of the most recently
accepted CARTS.
(2) An alternative plan to ensure that enrolled providers will have
efficient electronic access to the same information through other means
while the exemption is in effect.
(iii) CMS grants the exemption if the State establishes to CMS's
satisfaction that the State--
(A) Meets the threshold for the exemption; and
(B) Has established an alternative plan to ensure that its enrolled
providers will have efficient electronic access to the same information
through other means while the exemption is in effect.
(iv) The State's exemption expires if either--
(A) Based on the 3 previous years of available, finalized CHIP
CARTS managed care and fee-for-service enrollment data, the State's
managed care enrollment for 2 of the previous 3 years is below 90
percent; or
(B)(1) CMS has approved a State plan amendment, waiver, or waiver
amendment that would significantly reduce the percentage of
beneficiaries enrolled in managed care; and
(2) The anticipated shift in enrollment is confirmed by the first
available, finalized CARTS managed care and fee-for-service enrollment
data.
(v) If a State's exemption expires under paragraph (d)(2)(iv) of
this section, the State is required to do both of the following:
(A) Submit written notification to CMS that the State no longer
qualifies for the exemption within 90 days of the finalization of
annual CARTS managed care enrollment data that demonstrates that there
has been the requisite shift from managed care enrollment to fee-for-
service enrollment resulting in the State's managed care enrollment
falling below the 90 percent threshold.
(B) Obtain CMS approval of a timeline for compliance with the
requirements in paragraph (b) of this section within 2 years of the
expiration of the exemption.

0
29. Section 457.1206 is amended by revising paragraph (b)(6) to read as
follows:

Sec. 457.1206 Non-emergency medical transportation PAHPs.

* * * * *
(b) * * *
(6) The PAHP standards in Sec. 438.206(b)(1) of this chapter, as
cross-referenced by Sec. Sec. 457.1230(a) and (d) and 457.1233(a),
(b), and (d), excluding the requirement in Sec. 438.242(b)(7) of this
chapter to comply with Sec. 431.61(a) of this chapter.
* * * * *

0
30. Section 457.1230 is amended by revising paragraph (d) to read as
follows:

Sec. 457.1230 Access standards.

* * * * *
(d) Coverage and authorization of services. The State must ensure,
through its contracts, that each MCO, PIHP, or PAHP complies with the
coverage and authorization of services requirements in accordance with
the terms of Sec. 438.210 of this chapter, except that the following
do not apply:

[[Page 8986]]

(1) Section 438.210(a)(5) of this chapter (related to medical
necessity standard).
(2) Section 438.210(b)(2)(iii) of this chapter (related to
authorizing long term services and supports (LTSS)).

TITLE 45--Public Welfare

PART 156-HEALTH INSURANCE ISSUER STANDARDS UNDER THE AFFORDABLE
CARE ACT, INCLUDING STANDARDS RELATED TO EXCHANGES

0
31. The authority citation for part 156 continues to read as follows:

Authority: 42 U.S.C. 18021-18024, 18031-18032, 18041-18042,
18044, 18054, 18061, 18063, 18071, 18082, and 26 U.S.C. 36B.

0
32. Section 156.221 is amended by--
0
a. In paragraph (b)(1)(ii), removing the word ``and'' at the end of the
paragraph;
0
b. Revising paragraph (b)(1)(iii);
0
c. Adding paragraphs (b)(1)(iv) and (v); and
0
d. Revising paragraphs (c)(1), (c)(4)(ii)(C), (e)(2), (f), and (i).
The revisions and addition read as follows:

Sec. 156.221 Access to and exchange of health data and plan
information.

* * * * *
(b) * * *
(1) * * *
(iii) All data classes and data elements included in a content
standard in 45 CFR 170.213 that are maintained by the Qualified Health
Plan (QHP) issuer no later than 1 business day after the QHP issuer
receives the data; and
(iv) For plan years beginning on or after January 1, 2027, the
information in paragraph (b)(1)(iv)(A) of this section about prior
authorizations for items and services (excluding drugs, as defined in
paragraph (b)(1)(v) of this section), according to the timelines in
paragraph (b)(1)(iv)(B) of this section.
(A) The prior authorization request and decision, including all of
the following, as applicable:
(1) The prior authorization status.
(2) The date the prior authorization was approved or denied.
(3) The date or circumstance under which the prior authorization
ends.
(4) The items and services approved.
(5) If denied, a specific reason why the request was denied.
(6) Related structured administrative and clinical documentation
submitted by a provider.
(B) The information in paragraph (b)(1)(iv)(A) of this section
must--
(1) Be accessible no later than 1 business day after the QHP issuer
receives a prior authorization request;
(2) Be updated no later than 1 business day after any status
change; and
(3) Continue to be accessible for the duration that the
authorization is active and at least 1 year after the prior
authorization's last status change.
(v) Drugs are defined for the purposes of paragraph (b)(1)(iv) of
this section as any and all drugs covered by the QHP issuer.
* * * * *
(c) * * *
(1) Must implement and maintain API technology conformant with 45
CFR 170.215(a)(1), (b)(1)(i), (c)(1), and (e)(1);
* * * * *
(4) * * *
(ii) * * *
(C) Using the updated version of the standard, implementation
guide, or specification does not disrupt an end user's ability to
access the data specified in paragraph (b) of this section or
Sec. Sec. 156.221, 156.222, and 156.223 through the required APIs.
* * * * *
(e) * * *
(2) Makes this determination using objective, verifiable criteria
that are applied fairly and consistently across all apps and developers
through which parties seek to access electronic health information, as
defined in 45 CFR 171.102, including but not limited to criteria that
rely on automated monitoring and risk mitigation tools.
(f) Reporting on Patient Access API usage. Beginning in 2026, by
March 31 following any calendar year that it offers a QHP on a
Federally-facilitated Exchange, a QHP issuer must report to CMS the
following metrics, in the form of aggregated, de-identified data, for
the previous calendar year at the issuer level in the form and manner
specified by the Secretary:
(1) The total number of unique enrollees whose data are transferred
via the Patient Access API to a health app designated by the enrollee.
(2) The total number of unique enrollees whose data are transferred
more than once via the Patient Access API to a health app designated by
the enrollee.
* * * * *
(i) Applicability. A QHP issuer on an individual market Federally-
facilitated Exchange, not including QHP issuers offering only stand-
alone dental plans, must comply with the requirements in paragraphs (a)
through (e) and (g) of this section beginning with plan years beginning
on or after January 1, 2021, and with the requirements in paragraph (f)
of this section beginning in 2026, with regard to data:
(1) With a date of service on or after January 1, 2016; and
(2) That are maintained by the QHP issuer for enrollees in QHPs.

0
33. Section 156.222 is added to read as follows:

Sec. 156.222 Access to and exchange of health data for providers and
payers.

(a) Application programming interface to support data exchange from
payers to providers--Provider Access API. Unless granted an exception
under paragraph (c) of this section, for plan years beginning on or
after January 1, 2027, QHP issuers on a Federally-facilitated Exchange
must do the following:
(1) API requirements. Implement and maintain an application
programming interface (API) conformant with all of the following:
(i) Section 156.221(c)(2) through (4), (d), and (e).
(ii) The standards in 45 CFR 170.215(a)(1), (b)(1)(i), (c)(1), and
(d)(1).
(2) Provider access. Make the data specified in Sec. 156.221(b)
with a date of service on or after January 1, 2016, excluding provider
remittances and enrollee cost-sharing information, that are maintained
by the QHP issuer to available in-network providers via the API
required in paragraph (a)(1) of this section no later than 1 business
day after receiving a request from such a provider, if all the
following conditions are met:
(i) The QHP issuer authenticates the identity of the provider that
requests access and attributes the enrollee to the provider under the
attribution process described in paragraph (a)(3) of this section.
(ii) The enrollee does not opt out as described in paragraph (a)(4)
of this section.
(iii) Disclosure of the data is not prohibited by other applicable
law.
(3) Attribution. Establish and maintain a process to associate
enrollees with their in-network providers to enable data exchange via
the Provider Access API.
(4) Opt out and patient educational resources. (i) Establish and
maintain a process to allow an enrollee or the enrollee's personal
representative to opt out of data exchange described in paragraph
(a)(2) of this section and to change their permission at any time. That
process must be available before the first date on which the QHP issuer
makes enrollee information available via the Provider Access API and at
any time while the enrollee is enrolled with the QHP issuer.
(ii) Provide information to enrollees in plain language about the
benefits of

[[Page 8987]]

API data exchange with their providers, their opt out rights, and
instructions both for opting out of data exchange and for subsequently
opting in, as follows:
(A) Before the first date on which the QHP issuer makes enrollee
information available through the Provider Access API.
(B) No later than 1 week after the after the coverage start date or
no later than 1 week after the effectuation of coverage, whichever is
later.
(C) At least annually.
(D) In an easily accessible location on its public website.
(5) Provider resources. Provide on its website and through other
appropriate provider communications, information in plain language
explaining the process for requesting enrollee data using the Provider
Access API required in paragraph (a)(1) of this section. The resources
must include information about how to use the QHP issuer's attribution
process to associate enrollees with their providers.
(b) Application programming interface to support data exchange
between payers--Payer-to-Payer API. Unless granted an exception under
paragraph (c) of this section, for plan years beginning on or after
January 1, 2027, QHP issuers on a Federally-facilitated Exchange must
do the following:
(1) API requirements. Implement and maintain an API conformant with
all of the following:
(i) Section 156.221(c)(2) through (4), (d), and (e).
(ii) The standards in 45 CFR 170.215(a)(1), (b)(1)(i), and (d)(1).
(2) Opt in. Establish and maintain a process to allow enrollees or
their personal representatives to opt into the QHP issuer's payer to
payer data exchange with the enrollee's previous payer(s), described in
paragraphs (b)(4) and (5) of this section, and with concurrent
payer(s), described in paragraph (b)(6) of this section, and to change
their permission at any time.
(i) The opt in process must be offered as follows:
(A) To current enrollees, no later than the compliance date.
(B) To new enrollees, no later than 1 week after the coverage start
date or no later than 1 week after the effectuation of coverage,
whichever is later.
(ii) If an enrollee does not respond or additional information is
necessary, the QHP issuer must make reasonable efforts to engage with
the enrollee to collect this information.
(3) Identify previous and concurrent payers. Establish and maintain
a process to identify a new enrollee's previous and concurrent payer(s)
to facilitate the Payer-to-Payer API data exchange. The information
request process must start as follows:
(i) For current enrollees, no later than the compliance date.
(ii) For new enrollees, no later than 1 week after the coverage
start date or no later than 1 week after the effectuation of coverage,
whichever is later.
(iii) If an enrollee does not respond or additional information is
necessary, the QHP issuer must make reasonable efforts to engage with
the enrollee to collect this information.
(4) Exchange request requirements. Exchange enrollee data with
other payers, consistent with the following requirements:
(i) The QHP issuer must request the data specified in paragraph
(b)(4)(ii) of this section through the enrollee's previous payers' API,
if all the following conditions are met:
(A) The enrollee has opted in, as described in paragraph (b)(2) of
this section.
(B) The exchange is not prohibited by other applicable law.
(ii) The data to be requested are all of the following with a date
of service within 5 years before the request:
(A) Data specified in Sec. 156.221(b) excluding the following:
(1) Provider remittances and enrollee cost-sharing information.
(2) Denied prior authorizations.
(B) Unstructured administrative and clinical documentation
submitted by a provider related to prior authorizations.
(iii) The QHP issuer must include an attestation with this request
affirming that the enrollee is enrolled with the QHP issuer and has
opted into the data exchange.
(iv) The QHP issuer must complete this request as follows:
(A) No later than 1 week after the payer has sufficient identifying
information about previous payers and the enrollee has opted in.
(B) At an enrollee's request, within 1 week of the request.
(v) The QHP issuer must receive, through the API required in
paragraph (b)(1) of this section, and incorporate into its records
about the enrollee, any data made available by other payers in response
to the request.
(5) Exchange response requirements. Make available the data
specified in paragraph (b)(4)(ii) of this section that are maintained
by the QHP issuer to other payers via the API required in paragraph
(b)(1) of this section within 1 business day of receiving a request, if
all the following conditions are met:
(i) The payer that requests access has its identity authenticated
and includes an attestation with the request that the patient is
enrolled with the payer and has opted into the data exchange.
(ii) Disclosure of the data is not prohibited by other applicable
law.
(6) Concurrent coverage data exchange requirements. When an
enrollee has provided sufficient identifying information about
concurrent payers and has opted in as described in paragraph (b)(2) of
this section, a QHP issuer on a Federally-facilitated Exchange must do
the following, through the API required in paragraph (b)(1) of this
section:
(i) Request the enrollee's data from all known concurrent payers as
described in paragraph (b)(4) of this section, and at least quarterly
thereafter while the enrollee is enrolled with both payers.
(ii) Respond as described in paragraph (b)(5) of this section
within 1 business day of a request from any concurrent payers. If
agreed upon with the requesting payer, the QHP issuer may exclude any
data that were previously sent to or originally received from the
concurrent payer.
(7) Patient educational resources. Provide information to enrollees
in plain language, explaining at a minimum: the benefits of Payer-to-
Payer API data exchange, their ability to opt in or withdraw that
permission, and instructions for doing so. The QHP issuer must provide
the following resources:
(i) When requesting an enrollee's permission for Payer-to-Payer API
data exchange, as described in paragraph (b)(2) of this section.
(ii) At least annually, in appropriate mechanisms through which it
ordinarily communicates with current enrollees.
(iii) In an easily accessible location on its public website.
(c) Exception. (1) If a plan applying for QHP certification to be
offered through a Federally-facilitated Exchange believes it cannot
satisfy the requirements in paragraph (a) or (b) (or paragraphs (a) and
(b)) of this section, the issuer must include a narrative justification
in its QHP application that describes all of the following:
(i) The reasons why the issuer cannot reasonably satisfy the
requirements for the applicable plan year.
(ii) The impact of non-compliance upon providers and enrollees.
(iii) The current or proposed means of providing health information
to payers.
(iv) Solutions and a timeline to achieve compliance with the
requirements in paragraph (a) or (b) of this section (or paragraphs (a)
and (b)).
(2) The Federally-facilitated Exchange may grant an exception to
the requirements in paragraph (a) or (b) (or paragraphs (a) and (b)) of
this section if

[[Page 8988]]

the Exchange determines that making QHPs of such issuer available
through such Exchange is in the interests of qualified individuals in
the State or States in which such Exchange operates, and an exception
is warranted to permit the issuer to offer QHPs through the FFE.

0
34. Section 156.223 is added to read as follows:

Sec. 156.223 Prior authorization requirements.

(a) Communicating a reason for denial. Beginning January 1, 2026,
if the QHP issuer denies a prior authorization request (excluding a
request for coverage of drugs as defined in Sec. 156.221(b)(1)(v)),
the response to the provider must include a specific reason for the
denial, regardless of the method used to communicate that information.
(b) Prior Authorization Application Programming Interface (API).
Unless granted an exception under paragraph (d) of this section, for
plan years beginning on or after January 1, 2027, a QHP issuer on a
Federally-facilitated Exchange must implement and maintain an API
conformant with Sec. 156.221(c)(2) through (4), (d), and (e), and the
standards in 45 CFR 170.215(a)(1), (b)(1)(i), and (c)(1) that--
(1) Is populated with the QHP issuer's list of covered items and
services (excluding drugs as defined in Sec. 156.221(b)(1)(v)) that
require prior authorization;
(2) Can identify all documentation required by the QHP issuer for
approval of any items or services that require prior authorization;
(3) Supports a HIPAA-compliant prior authorization request and
response, as described in 45 CFR part 162; and
(4) Communicates the following information about prior
authorization requests:
(i) Whether the QHP issuer--
(A) Approves the prior authorization request (and the date or
circumstance under which the authorization ends);
(B) Denies the prior authorization request; or
(C) Requests more information.
(ii) If the QHP issuer denies the prior authorization request, it
must include a specific reason for the denial.
(c) Publicly reporting prior authorization metrics. Beginning in
2026, following each year it offers a QHP on a Federally-facilitated
Exchange, a QHP issuer must report prior authorization data, excluding
data on drugs as defined in Sec. 156.221(b)(1)(v), at the issuer level
by March 31. The QHP issuer must make the following data from the
previous calendar year publicly accessible by posting them on its
website:
(1) A list of all items and services that require prior
authorization.
(2) The percentage of standard prior authorization requests that
were approved, aggregated for all items and services.
(3) The percentage of standard prior authorization requests that
were denied, aggregated for all items and services.
(4) The percentage of standard prior authorization requests that
were approved after appeal, aggregated for all items and services.
(5) The percentage of prior authorization requests for which the
timeframe for review was extended, and the request was approved,
aggregated for all items and services.
(6) The percentage of expedited prior authorization requests that
were approved, aggregated for all items and services.
(7) The percentage of expedited prior authorization requests that
were denied, aggregated for all items and services.
(8) The average and median time that elapsed between the submission
of a request and a determination by the QHP issuer, for standard prior
authorizations, aggregated for all items and services.
(9) The average and median time that elapsed between the submission
of a request and a decision by the QHP issuer for expedited prior
authorizations, aggregated for all items and services.
(d) Exception. (1) If a plan applying for QHP certification to be
offered through a Federally-facilitated Exchange believes it cannot
satisfy the requirements in paragraph (b) of this section, the issuer
must include a narrative justification in its QHP application that
describes all of the following:
(i) The reasons why the issuer cannot reasonably satisfy the
requirements for the applicable plan year.
(ii) The impact of non-compliance upon providers and enrollees.
(iii) The current or proposed means of providing health information
to providers.
(iv) Solutions and a timeline to achieve compliance with the
requirements in paragraph (b) of this section.
(2) The Federally-facilitated Exchange (FFE) may grant an exception
to the requirements in paragraph (b) of this section if the Exchange
determines that making QHPs of such issuer available through such
Exchange is in the interests of qualified individuals in the State or
States in which such Exchange operates and an exception is warranted to
permit the issuer to offer QHPs through the FFE.

Xavier Becerra,
Secretary, Department of Health and Human Services.
[FR Doc. 2024-00895 Filed 1-18-24; 4:15 pm]
BILLING CODE 4150-28-P

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.