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, 76238-76371 [2022-26479]

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, 76238-76371 [2022-26479]

Download as PDF 76238 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules 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–P] 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: Proposed rule. AGENCY: This proposed rule would place new requirements on Medicare Advantage (MA) organizations, state Medicaid fee-for-service (FFS) programs, state Children’s Health Insurance Program (CHIP) FFS programs, Medicaid managed care plans, CHIP managed care entities, and Qualified Health Plan (QHP) issuers on the Federally-facilitated Exchanges (FFEs) to improve the electronic exchange of healthcare data and streamline processes related to prior authorization, while continuing CMS’ drive toward interoperability in the healthcare market. This proposed rule would also add a new measure for eligible hospitals and critical access hospitals (CAHs) under the Medicare Promoting Interoperability Program and for Merit-based Incentive Payment System (MIPS) eligible clinicians under the Promoting Interoperability performance category of MIPS. These policies taken together would play a key role in reducing overall payer and provider burden and improving patient access to health information. DATES: To be assured consideration, comments must be received at one of lotter on DSK11XQN23PROD with PROPOSALS2 SUMMARY: VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 the addresses provided below, no later than 5 p.m. on March 13, 2023. ADDRESSES: In commenting, please refer to file code CMS–0057–P. Comments, including mass comment submissions, must be submitted in one of the following three ways (please choose only one of the ways listed): 1. Electronically. You may submit electronic comments on this regulation to https://www.regulations.gov. Follow the ‘‘Submit a comment’’ instructions. 2. By regular mail. You may mail written comments to the following address ONLY: Centers for Medicare & Medicaid Services, Department of Health and Human Services, Attention: CMS–0057–P, P.O. Box 8013, Baltimore, MD 21244–8013. Please allow sufficient time for mailed comments to be received before the close of the comment period. 3. By express or overnight mail. You may send written comments to the following address ONLY: Centers for Medicare & Medicaid Services, Department of Health and Human Services, Attention: CMS–0057–P, Mail Stop C4–26–05, 7500 Security Boulevard, Baltimore, MD 21244–1850. For information on viewing public comments, see the beginning of the SUPPLEMENTARY INFORMATION section. FOR FURTHER INFORMATION CONTACT: Alexandra Mugge, (410) 786–4457, for general questions related to any of the policies in this proposed rule, or questions related to CMS interoperability initiatives. Lorraine Doo, (443) 615–1309, for issues related to the prior authorization process policies, or the Prior Authorization Requirements, Documentation, and Decision (PARDD) Application Programming Interface (API). Shanna Hartman, (410) 786–0092, for issues related to the Payer-to-Payer API, the Electronic Prior Authorization measure for the MIPS Promoting Interoperability performance category and Medicare Promoting Interoperability Program, or any of the API standards and implementation guides (IGs) included in this proposed rule. David Koppel, (303) 844–2883, for issues related to the Patient Access API policies, or patient privacy. Scott Weinberg, (410) 786–6017, for issues related to the Provider Access API policies, or the Requests for Information. Amy Gentile, (410) 786–3499, for issues related to Medicaid managed care. Kirsten Jensen, (410) 786–8146, for issues related to Medicaid FFS. PO 00000 Frm 00002 Fmt 4701 Sfmt 4702 Joshua Bougie, (410) 786–8117, for issues related to CHIP. Natalie Albright, (410) 786–1671, for issues related to MA organizations. Ariel Novick, (301) 492–4309, for issues related to QHPs. Elizabeth Holland, (410) 786–1309, for issues related to MIPS and the Medicare Promoting Interoperability Program. Russell Hendel, (410) 786–0329, for issues related to the Collection of Information and Regulatory Impact Analysis. SUPPLEMENTARY INFORMATION: Inspection of Public Comments: All comments received before the close of the comment period are available for viewing by the public, including any personally identifiable or confidential business information that is included in a comment. We post all comments received before the close of the comment period on the following website as soon as possible after they have been received: https:// www.regulations.gov. Follow the search instructions on that website to view public comments. CMS will not post on Regulations.gov public comments that make threats to individuals or institutions or suggest that the individual will take actions to harm the individual. CMS continues to encourage individuals not to submit duplicative comments. We will post acceptable comments from multiple unique commenters even if the content is identical or nearly identical to other comments. Table of Contents I. Background and Summary of Provisions A. Purpose and Background B. Summary of Major Proposals II. Provisions of the Proposed Rule A. Patient Access API B. Provider Access API C. Payer to Payer Data Exchange on FHIR D. Improving Prior Authorization Processes E. Electronic Prior Authorization for the Merit-Based Incentive Payment System (MIPS) Promoting Interoperability Performance Category and the Medicare Promoting Interoperability Program F. Interoperability Standards for APIs III. Requests for Information A. Request for Information: Accelerating the Adoption of Standards Related to Social Risk Factor Data B. Request for Information: Electronic Exchange of Behavioral Health Information C. Request for Information: Improving the Electronic Exchange of Information in Medicare Fee-for-Service D. Request for Information: Advancing Interoperability and Improving Prior Authorization Processes for Maternal Health E:\FR\FM\13DEP2.SGM 13DEP2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules E. Request for Information: Advancing the Trusted Exchange Framework and Common Agreement (TEFCA) IV. Collection of Information Requirements V. Response to Comments VI. Regulatory Impact Analysis Regulations Text lotter on DSK11XQN23PROD with PROPOSALS2 I. Background and Summary of Provisions A. Purpose and Background In the May 1, 2020, Federal Register, we published a final rule implementing the first phase of CMS interoperability rulemaking in the ‘‘Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Interoperability and Patient Access for MA Organization and Medicaid Managed Care Plans, State Medicaid Agencies, CHIP Agencies and CHIP Managed Care Entities, Issuers of Qualified Health Plans on the FederallyFacilitated Exchanges, and Health Care Providers’’ final rule (85 FR 25510) (hereinafter referred to as the ‘‘CMS Interoperability and Patient Access final rule’’). On December 18, 2020, we published a proposed rule (85 FR 82586) (hereinafter referred to as the ‘‘December 2020 CMS Interoperability proposed rule’’) in which we proposed new requirements for state Medicaid FFS programs, state CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to improve the electronic exchange of healthcare data and streamline processes related to prior authorization, while continuing CMS’ drive toward interoperability and reducing burden in the healthcare market. In addition, on behalf of the Department of Health and Human Services (HHS), the Office of the National Coordinator for Health Information Technology (ONC) proposed the adoption of certain specified implementation guides (IGs) needed to support the proposed Application Programming Interface (API) policies in that proposed rule. We received approximately 251 individual comments on the December 2020 CMS Interoperability proposed rule by the close of the comment period on January 4, 2021. While commenters largely supported the intent of the proposals and the proposals themselves, many noted and emphasized that MA organizations were not included among the impacted payers. The National Association of Medicaid Directors and state Medicaid programs expressed concerns about the implementation timeframes, states’ constraints to secure the funding necessary to implement the requirements of the rule in a timely VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 manner, and states’ ability to recruit staff with necessary technical expertise. Commenters also raised concerns that the relatively short comment period inhibited more thorough analyses of the proposals and, for membership organizations, the ability to receive input from and gain consensus among their members. The December 2020 CMS Interoperability proposed rule will not be finalized; we considered whether to issue a final rule based on that proposed rule, but considering the concerns raised by the commenters, we have opted not to do so. Instead, we are withdrawing the December 2020 CMS Interoperability proposed rule and issuing this new proposed rule that incorporates the feedback we received from stakeholders on that proposed rule. This approach will allow us to incorporate the feedback we have already received and provide additional time for public comment. Some of the changes we have incorporated in this proposed rule were influenced by the comments we received on the December 2020 CMS Interoperability proposed rule. For example, unlike in that proposed rule, we now propose to require impacted payers to use those health information technology (IT) standards at 45 CFR 170.215 that are applicable to each set of API requirements proposed in this rule, including the HL7 Fast Healthcare Interoperability Resources (FHIR) standard, the HL7 FHIR US Core Implementation Guide, and the HL7 SMART Application Launch Framework Implementation Guide. Also, in this proposed rule, we include MA organizations as impacted payers and propose that the policies included herein would have a longer implementation timeline. Most of the implementation dates for the proposals included in this proposed rule would begin in 2026, including those for the API proposals, prior authorization decision timeframes for certain impacted payers, and certain reporting proposals. We believe a threeyear timeline to recruit and train staff, update or build the APIs, and update operational procedures would be sufficient for these proposals, particularly based on the information we have from some payers and providers regarding similar initiatives already in progress. In addition to the proposed three-year implementation timeframe, we propose to give state Medicaid and CHIP FFS programs an opportunity to seek an extension of proposed implementation deadlines, or an exemption from meeting certain proposed requirements, in certain circumstances. Additionally, we include PO 00000 Frm 00003 Fmt 4701 Sfmt 4702 76239 a proposal to provide an exceptions process for issuers of QHPs on the FFEs. We believe the three-year timeframe would offer sufficient time for these impacted payers to evaluate their qualifications to participate in the API proposals in this proposed rule and to prepare the necessary documentation to request an extension, exemption, or exception. We are proposing some clarifications to existing Medicaid beneficiary notice and fair hearing regulations which apply to Medicaid prior authorization decisions. Because these are clarifications and improvements to existing regulations, these policies would become effective upon the effective date of a final rule if these proposals are finalized as proposed. We are also proposing terminology changes in section II.A.2.e related to the Patient Access API that would take effect with the effective date of the final rule, should these proposals be finalized as proposed. We are proposing a new Electronic Prior Authorization measure for eligible hospitals and CAHs under the Medicare Promoting Interoperability Program and for MIPS eligible clinicians under the Promoting Interoperability performance category of MIPS, which is in direct response to comments we received on the December 2020 CMS Interoperability proposed rule. We are re-issuing two requests for information (RFIs) that were included in the December 2020 CMS Interoperability proposed rule. We are also issuing three new RFIs: one to solicit information related to opportunities for improving the electronic exchange of medical documentation between providers to support prior authorization programs for Medicare FFS, a second to gather public feedback regarding data standardization and use of prior authorization to improve maternal health care, and a third to solicit comment regarding enabling exchange under the Trusted Exchange Framework and Common Agreement (TEFCA). With this new proposed rule, we are taking an active approach to move certain participants in the healthcare market toward interoperability by proposing policies for the MA program, Medicaid, CHIP, and QHP issuers on the FFEs, as well as eligible hospitals and CAHs under the Medicare Promoting Interoperability Program and for MIPS eligible clinicians under the Promoting Interoperability performance category of MIPS. Our proposals emphasize improving health information exchange and facilitating appropriate and necessary E:\FR\FM\13DEP2.SGM 13DEP2 lotter on DSK11XQN23PROD with PROPOSALS2 76240 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules patient, provider, and payer access to information in health records. We also include several proposals intended to reduce payer, provider, and patient burden by improving prior authorization processes and helping patients remain at the center of their own care. Prior authorization refers to the process through which a healthcare provider, such as an individual clinician, acute care hospital, ambulatory surgical center, or clinic, obtains approval from a payer before providing care. Prior authorization requirements are established by payers to help control costs and ensure payment accuracy by verifying that an item or service is medically necessary, meets coverage criteria, and is consistent with standards of care before the item or service is provided. For purposes of this proposed rule, references to QHP issuers on the FFEs exclude issuers offering only 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 proposed provisions of this rule. We believe that the proposed standards would be overly burdensome for both SADP and SHOP issuers. Requiring issuers offering only SADPs and QHPs in the FF–SHOPs, which have relatively lower enrollment and premium intake compared to individual market QHPs, to comply with the proposals in this rule could result in those issuers no longer participating in the FFEs, which would not be in the best interest of the enrollees. The categorical exclusion of these issuers is consistent with CMS’ approach to some other QHP requirements. We also propose offering an exceptions process for QHP issuers on the FFEs for the API requirements proposed in this rule, that would be conditioned upon approval of a narrative justification that meets CMS requirements. The proposed exceptions processes could apply to small issuers, financially vulnerable issuers, or new entrants to the FFEs that demonstrate that deploying standards-based API technology consistent with the proposed policies would pose a significant barrier to the issuers’ ability to provide coverage or service to patients and that not certifying the issuers QHP or QHPs would result in patients having few or no plan options in certain areas. This approach is consistent with the exceptions process finalized for the Patient Access API in the CMS Interoperability and Patient Access final rule. Were we to apply the proposed standards to such issuers, we believe it VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 could result in those issuers no longer participating in the FFEs, which would not be in the best interest of enrollees. We note that, in this proposed rule, FFEs include FFEs in states that perform plan management functions. State-based Exchanges on the Federal Platform (SBE–FPs) are not FFEs, even though patients in those states enroll in coverage through HealthCare.gov. Hence, QHP issuers in SBE–FPs would not be subject to the requirements in this proposed rule. We encourage SBE– FPs and State-based Exchanges operating their own platforms (SBEs) to consider adopting similar requirements for QHPs on their Exchanges. Throughout this proposed rule, we use terms such as ‘‘patient,’’ ‘‘consumer,’’ ‘‘beneficiary,’’ ‘‘enrollee,’’ and ‘‘individual.’’ Every reader of this proposed rule is a patient and has received, or will receive, medical care at some point in their life. In this proposed rule, we use the term ‘‘patient’’ as an inclusive term. We understand that, historically, we have referred in our regulations to patients using the other terms previously noted. However, for the proposals herein, we will use additional, specific terms applicable to individuals covered under the healthcare programs that we administer and regulate. We also note that when we discuss patients, the term includes, where applicable, a patient’s personal representative. For example, a patient or their personal representative may consent to certain types of information exchange under our proposals. But when we refer to a patient’s medical needs or health records, we are not including the medical needs or health records of the patient’s personal representative. Per the Privacy, Security, and Breach Notification Rules (HIPAA Rules) 1 issued under the Health Insurance Portability and Accountability Act of 1996 (HIPAA) (Pub. L. 104–191, enacted on August 21, 1996), as modified, at 45 CFR 164.502(g), and related guidance thereof, a personal representative, generally and for purposes of access to protected health information (PHI), defined at 45 CFR 160.103, is someone authorized under state or other applicable law to act on behalf of an individual in making healthcare-related decisions (such as a parent, guardian, or person with a medical power of attorney).2 As permitted by the HIPAA 1 See 45 CFR parts 160 and 164. HHS Office of Civil Rights (OCR) guidance regarding personal representatives at https:// www.hhs.gov/hipaa/for-professionals/faq/2069/ under-hipaa-when-can-a-family-member/ index.html and https://www.hhs.gov/hipaa/for2 See PO 00000 Frm 00004 Fmt 4701 Sfmt 4702 Rules, a patient’s personal representative could act on a patient’s behalf using the processes within this proposed rule. We also use terms such as ‘‘payer,’’ ‘‘plan,’’ and ‘‘issuer’’ in this proposed rule. Certain portions of this proposed rule are applicable to MA organizations, state Medicaid FFS programs, state CHIP FFS programs, Medicaid managed care plans (managed care organizations (MCOs), prepaid inpatient health plans (PIHPs), and prepaid ambulatory health plans (PAHPs)), CHIP managed care entities (MCOs, PIHPs, and PAHPs), and QHP issuers on the FFEs. Where certain proposed provisions may not be applicable to specific plan or provider types, we have identified them separately from the aforementioned categories. We use the term ‘‘payer’’ in the preamble of this proposed rule as an inclusive term for all these programs and, in the case of plans, plan types, but we also use specific terms as applicable in various sections of this proposed rule. We are proposing at 42 CFR 457.700(c) that states that have a Medicaid expansion CHIP (a program under which a state receives Federal funding to expand Medicaid eligibility to optional targeted low-income children that meets the requirements of section 2103 of the Social Security Act), the proposals in this rule for Medicaid would apply to those programs rather than our proposals for a separate CHIP. Functionally, our proposals are the same; however, for clarity, we are making explicit that the Medicaid requirements at §§ 431.60, 431.61, and 431.80 would apply to those programs rather than the separate CHIP requirements at §§ 457.730, 457.731, and 457.732. We use the term ‘‘items and services’’ when discussing prior authorization in this proposed rule, and note that, unless otherwise stated, the proposals for prior authorization APIs and processes do not apply to drugs of any type, meaning any drugs that could be covered by the impacted payers in this proposed rule (for example, this would include outpatient drugs, drugs that may be prescribed, those that may be administered by a physician, or that may be administered in a pharmacy or hospital), because the processes and standards for prior authorization applicable to drugs differ from the other ‘‘items and services’’ for which we propose regulation. In the CMS Interoperability and Patient Access final rule, we finalized policies that would require payers to send claims data professionals/faq/personal-representatives-andminors/. E:\FR\FM\13DEP2.SGM 13DEP2 lotter on DSK11XQN23PROD with PROPOSALS2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules related to prescription and other drug claims via an API, and we make several proposals related to claims data in this proposed rule. For example, Medicare Advantage Prescription Drug (MA–PD) plans that cover Part A, Part B, and Part D benefits, as well as supplemental benefits, are required to provide access to information about all those covered benefits through the Patient Access API at 42 CFR 422.119(b). Prescription and other drug information is part of a patient’s longitudinal record and giving patients, providers, and payers access to claims data for prescription and other drugs can offer valuable insights into a patient’s healthcare, provide benefits for care coordination, and help avoid potentially harmful drug interactions. We acknowledge that there are existing laws and regulations that may apply to prior authorization for drugs for the impacted payers in this proposed rule. Thus, while the claims data included in our proposed and previously finalized policies did include prescription and other drug claims, our proposals related to prior authorization in this proposed rule do not include standards or policies for any drugs (as previously described), including covered outpatient drugs under Medicaid, and Medicare Part B or Part D drugs. Additionally, we use the terms ‘‘provider’’ and ‘‘supplier’’ as inclusive terms composed of individuals, organizations, and institutions that provide health services, such as clinicians (that is, physicians and other practitioners), hospitals, skilled nursing facilities, home health agencies, hospice settings, laboratories, suppliers of durable medical equipment, prosthetics, orthotics, and supplies (DMEPOS), community-based organizations, as appropriate in the context used. When specifically discussing policies related to the Medicare Promoting Interoperability Program and the Promoting Interoperability performance category of MIPS, we refer to MIPS eligible clinicians, eligible hospitals, and CAHs. Throughout this proposed rule we make several API-related proposals in which we refer to the functionality as a singular API, or API gateway, though we acknowledge that this functionality may be made up of one or multiple APIs. For example, while we refer to the Patient Access API (discussed in section II.A. of this proposed rule) as a single API for the purpose of describing the functionality, the same functionality may be achieved with one or multiple APIs, depending on the implementation approach chosen by the applicable payer. VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 An API is a set of commands, functions, protocols, or tools published by one software developer (‘‘A’’) that enables other software developers to create programs (applications or ‘‘apps’’) that can interact with A’s software without needing to know the internal workings of A’s software, while maintaining data security and patient privacy, if properly implemented. This is how API technology enables the seamless user experiences associated with applications, which are familiar in other aspects of patients’ daily lives, such as travel and personal finance. Standardized, secure, transparent, and pro-competitive API technology can enable similar benefits for patients of healthcare services.3 Health Level 7 (HL7®) is the standards development organization which develops the Fast Healthcare for Interoperability Resources (FHIR®) standard and IGs referenced throughout this proposed rule. HL7 requires the registered trademark with the first use of its name in a document, for which policies are available on its website at www.HL7.org.4 Finally, we note that throughout this proposed rule we discuss the APIs in relation to the proposed programmatic requirements to share data between payers, between payers and providers, and between payers and patients under specific rules. However, these APIs could be used for a multitude of transactions, aside from those currently described by section 1173(a)(1) of the Social Security Act, beyond those proposed in this rule. For instance, a patient could request data outside the scope of this proposed rule, or program integrity entities could request data from payers or providers (such as under the Inspector General Act of 1978). Nothing in this proposed rule would prevent the requested data from being shared via the APIs discussed in this proposed rule, if technologically feasible, for appropriate purposes. In fact, we encourage the use of these standards-based APIs for purposes beyond the proposed requirements to improve the interoperability of health data regardless of the use case. B. Summary of Major Proposals To drive interoperability, improve care coordination, reduce burden on 3 ONC released an overview of APIs in context of consumers’ access to their own medical information across multiple providers’ electronic health record (EHR) systems, which is available at the HealthIT.gov website at https://www.healthit.gov/ api-education-module/story_html5.html. 4 CMS does not use the trademark symbol elsewhere in the preamble unless necessary when naming specific IGs. For HL7 Trademark policy, see https://www.hl7.org/legal/trademarks.cfm?ref=nav. PO 00000 Frm 00005 Fmt 4701 Sfmt 4702 76241 providers and payers, and empower patients, we are proposing several requirements for MA organizations, state Medicaid FFS programs, state CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs, as well as MIPS eligible clinicians participating in the MIPS Promoting Interoperability performance category, and eligible hospitals and CAHs in the Medicare Promoting Interoperability Program. We are also including RFIs to gather information that may support future rulemaking or other initiatives. Executive Order (E.O.) 13985 of January 20, 2021, entitled ‘‘Advancing Racial Equity and Support for Underserved Communities Through the Federal Government,’’ set Administration policy that the ‘‘Federal Government should pursue a comprehensive approach to advancing equity for all.’’ 5 CMS is committed to pursuing a comprehensive approach to advancing health equity for all, and we believe the proposals in this rule are aligned with this E.O. because they represent efforts to mitigate existing inefficiencies in policies, processes, and technology which affect many patient populations. Some patient populations are more negatively affected by existing processes than others and thus might realize greater benefits through the improvements we propose. One of the main components of this proposed rule is continued support for the individual’s ability to select an app of their choice when accessing their health information. We want to ensure that members of all communities can access their health information and benefit from this technology. However, we are interested in the best ways to ensure that apps are available and accessible for individuals with disabilities, individuals with limited English proficiency, individuals with low literacy or low health literacy, and individuals with geographic, economic, or other social risk factors that may create barriers to accessing or using technology and apps. We are soliciting comments from the public, particularly individuals who have knowledge about how underserved populations use healthcare apps and technology, such as researchers, policy advocates, social service agency staff, providers who serve underserved populations, and others who may be able to provide insight about accessibility, readability, and other relevant factors for consideration. Our goal is to ensure that these proposed policies do not 5 E.O. 13985, sec. 1, 86 FR 7009 (January 20, 2021). E:\FR\FM\13DEP2.SGM 13DEP2 lotter on DSK11XQN23PROD with PROPOSALS2 76242 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules exacerbate current disparities or create unintended inequities that leave some communities or populations unable to benefit from this information sharing. Further, we seek to ensure that patient privacy considerations are built into the implementation of these proposed policies through the use of secure technologies, such as OAuth 2.0 and OpenID Connect for authentication, and as further discussed in the CMS Interoperability and Patient Access final rule (85 FR 25516). While we have proposed policies that we believe would address some healthcare inequities, we are soliciting comment about how to help ensure that individuals from all communities and populations can actively benefit from our healthcare interoperability proposals. In the CMS Interoperability and Patient Access final rule, we required impacted payers (MA organizations, state Medicaid FFS programs, state CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs) to implement and maintain a standardsbased Patient Access API. The Patient Access API must allow patients, through the health applications of their choice, to easily access their claims and encounter information as well as clinical data, including laboratory results, and provider remittances and enrollee cost-sharing pertaining to such claims, if maintained by the impacted payer, (85 FR 25558). In this proposed rule, we are proposing to require that impacted payers (MA organizations, state Medicaid FFS programs, state CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs) include information about prior authorizations in the data that are available through the Patient Access API. In addition, we are proposing to require these impacted payers to annually report to CMS certain metrics about patient data requests via the Patient Access API. To improve coordination across the care continuum and movement toward value-based care, we are proposing to require that impacted payers implement and maintain a Provider Access API that, consistent with the technical standards finalized in the CMS Interoperability and Patient Access final rule (85 FR 25558), utilizes HL7 FHIR version 4.0.1. That API can be used to exchange current patient data from payers to providers, including all data classes and data elements included in a standard adopted at 45 CFR 170.213 (currently USCDI version 1), adjudicated claims and encounter data (not including provider remittances and enrollee cost-sharing information), and VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 the patient’s prior authorization decisions. In the CMS Interoperability and Patient Access final rule, CMS required certain payers (MA organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs) to exchange a patient’s health data with other payers at the patient’s request, beginning on January 1, 2022, or plan years beginning on or after January 1, 2022, as applicable (85 FR 25568). We also required those payers to incorporate the data they receive through this payer to payer data exchange into patient records, with the goal of creating longitudinal records that would follow patients as they move from payer to payer throughout their healthcare journey. However, we did not require a standards-based API for the payer to payer data exchange. Since the rule was finalized in May 2020, multiple impacted payers reported to CMS that the lack of technical specifications for the payer to payer data exchange requirement in the CMS Interoperability and Patient Access final rule was creating challenges for implementation, which, they stated, could lead to incompatible implementations across the industry, poor data quality, operational challenges, and increased administrative burdens. They were concerned that different implementation approaches could create gaps in patient health information, which would directly conflict with the intended goal of interoperable payer to payer data exchange. After considering stakeholder concerns about implementing the payer to payer data exchange requirement finalized in the CMS Interoperability and Patient Access final rule, we announced in a December 10, 2021 Federal Register notification (86 FR 70412) that we would not enforce the payer to payer data exchange requirements until further rules are finalized.6 In this proposed rule, we are proposing to rescind our previous payer to payer data exchange requirements and replace them with a new policy. The CMS Interoperability and Patient Access final rule also did not apply the payer to payer data exchange requirements to Medicaid and CHIP FFS programs. We are now proposing to apply our newly proposed Payer-toPayer API requirements to Medicaid and CHIP FFS programs, in addition to other impacted payers as discussed further in 6 Centers for Medicare & Medicaid Services (2021, December 10). CMS–9115–N2. Notification of Enforcement Discretion. https://www.govinfo.gov/ content/pkg/FR-2021-12-10/pdf/2021-26764.pdf. PO 00000 Frm 00006 Fmt 4701 Sfmt 4702 section II.C.4.a. The new proposed policy would require impacted payers to build a Payer-to-Payer API to facilitate the exchange of patient information between payers, both at a patient’s request and at the start of coverage with a new payer. Specifically, that data exchange would include all data classes and data elements included in a standard adopted at 45 CFR 170.213 (currently USCDI version 1), adjudicated claims and encounter data (not including provider remittances and enrollee cost-sharing information), and the patient’s prior authorization decisions. To improve the patient experience and access to care, we are also proposing several new requirements for prior authorization processes that we believe would ultimately reduce burden on patients, providers, and payers. To streamline the prior authorization process, we are proposing to require all impacted payers to implement and maintain a FHIR Prior Authorization Requirements, Documentation, and Decision API (PARDD API). The API would streamline the prior authorization process by automating the process to determine whether a prior authorization is required for an item or service, thereby eliminating one of the major pain points of the existing prior authorization process. The API would then be able to query the payer’s prior authorization documentation requirements and make those requirements available within the provider’s workflow as well as support the automated compilation of certain information from the provider’s system. Finally, the API would support an automated approach to compiling the necessary data elements to populate the HIPAA-compliant prior authorization transactions and enable payers to compile specific responses regarding the status of the prior authorization, including information about the reason for a denial. For the exchange of the prior authorization transaction, covered entities would continue to use the HIPAA-mandated transaction standards. Use of the FHIR API integrates identification of prior authorization and documentation requirements as well as information about prior authorization requests and decisions into a provider’s workflow while maintaining compliance with the adopted HIPAA standard. We are proposing to require that impacted payers send information to providers regarding the specific reason for denial when a prior authorization request is denied, regardless of the mechanism used to submit the prior authorization request. We are proposing E:\FR\FM\13DEP2.SGM 13DEP2 lotter on DSK11XQN23PROD with PROPOSALS2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules to require impacted payers, except for QHP issuers on the FFEs, to respond to prior authorization requests within certain timeframes. In addition, we are proposing to require impacted payers to publicly report certain metrics about their prior authorization processes for transparency. We are proposing a new measure for electronic prior authorization for MIPS eligible clinicians under the Promoting Interoperability performance category of MIPS and for eligible hospitals and CAHs under the Medicare Promoting Interoperability Program. To promote PARDD API adoption, implementation, and use among MIPS eligible clinicians, eligible hospitals, and CAHs, we are proposing to add a new measure titled ‘‘Electronic Prior Authorization’’ under the Health Information Exchange (HIE) objective in the MIPS Promoting Interoperability performance category and the Medicare Promoting Interoperability Program, beginning with the performance period/EHR reporting period in calendar year (CY) 2026. For this measure, we are proposing that a MIPS eligible clinician, eligible hospital, or CAH must report a numerator and denominator or (if applicable) an exclusion. Although these proposals do not directly pertain to Medicare FFS, we want to ensure that people with Medicare can benefit from the policies we are proposing, regardless of their coverage or delivery system. We intend for the Medicare FFS program to be a market leader on data exchange, including through the Provider Access, Payer-to-Payer, and Prior Authorization APIs. and therefore, seek comment throughout on how these proposals could apply to Medicare FFS. Similarly, we encourage other payers not directly impacted by this proposed rule to evaluate our proposals for voluntary adoption to reduce burden and support greater interoperability. Further information about CMS initiatives to achieve the desired level of data exchange with patients, providers and other payers can be found in those sections in this proposed rule. We are also including five RFIs to gather information that may support future rulemaking or other initiatives. Specifically, we request information on barriers to adopting standards, and opportunities to accelerate the adoption of standards, for social risk data. We recognize that social risk factors (for example, housing instability and food insecurity) influence patient health and healthcare utilization. In addition, we understand that providers in valuebased payment arrangements rely on comprehensive, high-quality social risk VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 data. Given the importance of these data, we want to understand how we can better standardize and promote the exchange of these data in accordance with the law. Additionally, we are seeking comment on how CMS could leverage APIs (or other technology) to facilitate electronic data exchange between and with behavioral healthcare providers, which generally have lower rates of EHR adoption than other provider types. Furthermore, in the Medicare FFS program, the ordering provider can be different than the rendering provider of items or services, which creates unique obstacles to the coordination of patient care and exchange of medical information needed to ensure an accurate and timely payment. We are interested in public comments regarding how Medicare FFS could support improved medical documentation exchange between and among providers, suppliers, and patients as we believe it could enable better care for beneficiaries if covered services are not delayed by inefficiencies. We also seek comment on how using data standards and electronic health records can improve maternal health outcomes. Additionally, we include questions related to how prior authorization can be improved and what special considerations should be given to support data sharing in maternal health care. Finally, we seek comment on how to encourage providers and payers to enable exchange under TEFCA to make patient information more readily available for access and exchange in a variety of circumstances. We wish to understand how CMS can support enabling exchange under TEFCA and what concerns commenters have about potential requirements related to enabling exchange under TEFCA. II. Provisions of the Proposed Rule A. Patient Access API 1. Background In the CMS Interoperability and Patient Access final rule (85 FR 25558), in order to give patients access to their own health information in a way most meaningful and useful to them, we required impacted payers to share, via FHIR APIs, certain information including patient claims, encounter data, and a subset of clinical data that patients can access via health apps. Claims and encounter data, used in conjunction with clinical data, can offer a broad picture of an individual’s healthcare experience. In the CMS Interoperability and Patient Access final rule (85 FR 25523), we gave examples of PO 00000 Frm 00007 Fmt 4701 Sfmt 4702 76243 how claims data can be used to benefit patients and providers. For example, inconsistent benefit utilization patterns in an individual’s claims data, such as a failure to fill a prescription or receive recommended therapies, can indicate to a provider or payer that the individual has had difficulty financing a treatment regimen and may require less expensive prescription drugs or therapies, additional explanation about the severity of their condition, or other types of assistance. Patients tend to receive care from multiple providers, leading to fragmented patient health records where various pieces of an individual’s longitudinal record are locked in disparate, siloed data systems. With patient data scattered across these disconnected systems, it can be challenging for providers to get a clear picture of the patient’s care history, and patients may forget or be unable to provide critical information to their provider. This lack of comprehensive patient data can impede care coordination efforts and access to appropriate care. As stated in section I.A. of this proposed rule, we are withdrawing the December 2020 CMS Interoperability proposed rule and issuing this new proposed rule that incorporates feedback we received from stakeholders. We understand that many readers may be familiar with that proposed rule, and, in an effort to distinguish the differences between that proposed rule and our proposals herein, we refer readers to section I.A. of this proposed rule outlining the overarching differences between them. In this proposed rule, we are again proposing to require impacted payers to report Patient Access API metrics to CMS. However, we have changed the proposal to require reporting annually, as opposed to quarterly. In addition, we are no longer proposing that impacted payers maintain a process for requesting an attestation from health app developers when the developers register their app with the payer’s Patient Access API. Instead, we are seeking comment on a variety of privacy considerations. Finally, we propose to extend the compliance date for our proposed policies to January 1, 2026. As mentioned in section I.A. of this proposed rule, the proposals in this rule do not directly pertain to Medicare FFS. However, if our proposals are finalized, we plan to implement these provisions for Medicare FFS so that people with Medicare FFS could also benefit from their data availability. Through Blue E:\FR\FM\13DEP2.SGM 13DEP2 76244 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules Button 2.0,7 CMS makes Parts A, B, and D claims data available electronically via an API to people with Medicare FFS and those enrolled in Part D. To align with the API provisions included in the CMS Interoperability and Patient Access final rule, we have updated the Blue Button 2.0 API to FHIR Release 4, and begun using the CARIN Consumer Directed Payer Data Exchange IG for Blue Button 2.0. If we finalize our proposals, we plan to further align and enhance Blue Button 2.0 accordingly, as feasible. We seek comment on any considerations for applying these requirements to apply to Medicare FFS, if we finalize these proposals. 2. Enhancing the Patient Access API In the CMS Interoperability and Patient Access final rule (85 FR 25558– 25559), we adopted regulations that require certain payers, specifically MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs, to implement and maintain APIs that permit enrollees to use health apps to access data specified at 42 CFR 422.119, 431.60, 457.730, 438.242(b)(5), and 457.1233(d) and 45 CFR 156.221, respectively. The Patient Access API must make available, at a minimum, adjudicated claims (including provider remittances and enrollee cost-sharing), encounters with capitated providers, and clinical data, including laboratory results, with a date of service on or after January 1, 2016, as maintained by the payer. We finalized a policy that payers must make those data available via the Patient Access API no later than 1 business day after a claim is adjudicated or encounter or clinical data are received. lotter on DSK11XQN23PROD with PROPOSALS2 a. Prior Authorization Information To enhance our policy by improving the usefulness of the information available to patients, we are proposing to add information about prior authorizations to the categories of data required to be made available to patients through the Patient Access API. In this section, we refer to the provider’s workflow and associated information and documentation as the ‘‘prior authorization request’’ and the payer’s processes and associated information and documentation as the ‘‘prior 7 Blue Button 2.0 allows Medicare beneficiaries to download claims data to their computer or device to print it or share it with others. They can also easily link health apps to their account to share their data with providers, pharmacies, caregivers, or others. See Centers for Medicare & Medicaid Services. Share your Medicare claims (Medicare’s Blue Button). Retrieved from https:// www.medicare.gov/manage-your-health/share-yourmedicare-claims-medicares-blue-button. VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 authorization decision.’’ This proposal would apply to all prior authorization requests and decisions for items and services (excluding drugs) for which the payer has data, whether the decision is still pending, active, denied, expired, or is in another status, as discussed further in this section. The primary goal of the Patient Access API is to give patients access to their health information. By expanding patient access to prior authorization information, we intend to help patients be more informed decision makers and true partners in their healthcare. As discussed in section I.A. of this proposed rule, our proposals for prior authorization APIs and processes do not apply to drugs of any type that could be covered by an impacted payer, including, for example, outpatient drugs, drugs that may be prescribed, drugs that may be administered by a provider, or drugs that may be administered in a pharmacy or hospital. In section II.D. of this proposed rule, we propose several provisions focused on making the prior authorization process less burdensome for providers and payers, which we anticipate would reduce care delays and improve patient outcomes. We believe that giving patients access to information about prior authorization requests and decisions would enable patients to take a more active role in their own healthcare. As a result, we are proposing to require impacted payers to provide patients with access to information about the prior authorization requests made for their care through the Patient Access API. We propose to require that via the Patient Access API, impacted payers make information about prior authorization requests and decisions (and related administrative and clinical documentation) for items and services (excluding drugs) available to patients no later than 1 business day after the payer receives the prior authorization request or there is another type of status change for the prior authorization. Examples of status changes include: a payer approves or denies a pending prior authorization request, a provider or patient updates a denied prior authorization request with additional information for reconsideration, or the count of the items or services used under the prior authorization decision is updated. We expect that impacted payers use a variety of terminology, but, generally, any meaningful change to the payer’s record of the prior authorization request or decision would require an update to the information available to the patient. For the requirement to include prior authorization information PO 00000 Frm 00008 Fmt 4701 Sfmt 4702 in the data available via the Patient Access API, we propose a January 1, 2026 compliance date (for Medicaid managed care plans and CHIP managed care entities, by the rating period beginning on or after January 1, 2026, and for QHP issuers on the FFEs, for plan years beginning on or after January 1, 2026). The required information available through the API would include the prior authorization status, the date the prior authorization was approved or denied, the date or circumstance under which the authorization ends, the items and services approved, and the quantity used to date under the authorization. The documentation required to be shared includes any materials that the provider sends to the payer to support a decision, for example, structured or unstructured clinical data including laboratory results, scores or assessments, past medications or procedures, progress notes, or diagnostic reports. In section II.D.4.a. of this proposed rule, we propose that in the case of a prior authorization denial, the payer must provide a specific reason for the denial. We propose that impacted payers would have to make that specific reason for denying a prior authorization request available to the patient via the Patient Access API as well. This information can help patients understand both why a payer denied a prior authorization request and/or what items and services were authorized for the patient’s recent care. As further discussed in sections II.B. and II.C. of this proposed rule, we are proposing to require impacted payers to share the same information about prior authorization requests and decisions with a patient’s provider via the Provider Access API and via the Payerto-Payer API. In this way, these prior authorization data can potentially be available to all relevant parties. We note that the requirement to share information about prior authorization via the API is in addition to any notice requirement that applies to prior authorization requests and decisions, such as the proposals to require notice of a decision within certain timeframes discussed in section II.D.5.b. of this proposed rule. We believe that 1 business day is appropriate, as patients need timely access to the information to understand prior authorization processes and their available care options. As discussed further in section II.D. of this proposed rule, we are proposing to require payers to make much of the same information about prior authorization requests and decisions available via the PARDD API during the decision-making process. In E:\FR\FM\13DEP2.SGM 13DEP2 lotter on DSK11XQN23PROD with PROPOSALS2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules addition, because impacted payers would be required to exchange prior authorization information electronically, we believe it would be reasonable for them to share prior authorization information and documentation with patients within 1 business day of any update to the prior authorization request or decision. We are also proposing to require that information about prior authorizations (and related administrative and clinical documentation) be available via the Patient Access API for as long as the authorization is active and at least 1 year after the last status change. We note that we are formulating our proposal for at least 1 year after any status change, but this provision would be particularly relevant to denied and expired prior authorizations, to ensure that they would be available for at least a year after expiring or being denied. We do not propose to require that payers share a patient’s full prior authorization history because that could comprise a significant amount of information that may no longer be clinically relevant. Claims, encounter, and/or clinical data can provide important information about a patient’s health history. With those data available through the Patient Access API, we believe that processrelated information about long-expired or denied prior authorizations would be redundant. Also, as prior authorization rules may change over time, we believe that this information has a limited lifespan of usefulness to a patient’s current care. At the same time, the API should include information about all active authorizations for as long as they are active and therefore may be related to ongoing care. We anticipate that requiring payers to make prior authorization information accessible through the Patient Access API would help patients better understand the lifecycle of a prior authorization request, the items and services that require prior authorization, the information being considered, and specific clinical criteria their payer uses to make a determination. We believe that more transparency would better equip patients to engage with their payer(s) and/or provider(s). For example, by having access to certain prior authorization information via the Patient Access API, a patient could see that prior authorization is needed and has been submitted for a particular item or service, which could help them better understand the timeline for the process and plan accordingly. Supporting documentation could give patients better visibility into what the payer is evaluating so they could help providers get the best and most accurate VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 information to payers to facilitate a successful request, thus potentially avoiding unnecessary care delays and reducing burden on providers and payers. The proposed requirement could also reduce the need for patients to make repeated calls to their providers and payers to understand the status of requests, or to inquire why there are delays in care. We believe that this proposal would enable patients to participate in their care more and reduce burden on both providers and payers to allow them to more efficiently navigate the prior authorization process. The proposal may also add an additional layer of accountability for payers to make timely prior authorization decisions, as patients would be able to follow the prior authorization process from initiation to conclusion. As with all information made available via the Patient Access API, we believe industry is in the best position to develop apps for patients to effectively use this information, and to make sure that the apps are accessible to people with disabilities. We look to industry innovators to produce apps that will help patients understand their health information and access it in a manner that is useful to them. In summary, we propose that, beginning January 1, 2026 (for Medicaid managed care plans and CHIP managed care entities, by the rating period beginning on or after January 1, 2026, and for QHP issuers on the FFEs, for plan years beginning on or after January 1, 2026), impacted payers would be required to make information available to patients via the Patient Access API about prior authorization requests and decisions (and related administrative and clinical documentations), including, as applicable, the status of the prior authorization; the date the prior authorization was approved or denied; the date or circumstance under which the authorization ends; the items and services approved; the quantity used to date; and, if the prior authorization was denied, a specific reason why the request was denied, no later than 1 business day after the payer receives a prior authorization request for items and services (excluding drugs) or there is another type of status change for the prior authorization. We are also proposing that, beginning January 1, 2026 (for Medicaid managed care plans and CHIP managed care entities, by the rating period beginning on or after January 1, 2026, and for QHP issuers on the FFEs, for plan years beginning on or after January 1, 2026), impacted payers must make prior authorization information (and related administrative PO 00000 Frm 00009 Fmt 4701 Sfmt 4702 76245 and clinical documentation), available to patients via the Patient Access API for the duration it is active and at least 1 year after the last status change. These proposals would apply to MA organizations, state Medicaid FFS and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs at the CFR sections identified in Table 1. The requirements for a Patient Access API imposed on Medicaid managed care plans and CHIP managed care entities are set forth at 42 CFR 438.242(b)(5) and 457.1233(d), respectively. Through an amendment to paragraph (b)(5) and by adding a new paragraph (b)(8) at 42 CFR 438.242, we are proposing to require Medicaid managed care plans (and through § 457.1233(d), CHIP managed care entities) to include information about prior authorization requests and decisions and related administrative and clinical documentation in the data available via to the Patient Access API by the rating period beginning on or after January 1, 2026. We request comment on this proposal. We request comment on how we could or should apply these requirements to Medicare FFS and its existing prior authorization requirements and standards. As stated earlier in this preamble, the proposals in this proposed rule do not apply to any drugs. However, we also request comments on whether we should consider policies to require impacted payers to include information about prior authorizations for drugs, when the payer covers drugs, via the Patient Access API, the Provider Access API, and the Payer-to-Payer API. We request comments on how future rulemaking to make information about prior authorizations for drugs available through these APIs might interact with existing prior authorization requirements and standards. b. Interaction With HIPAA Right of Access Provisions Previous proposals have elicited numerous comments regarding the interaction between the Patient Access API and HIPAA Privacy Rule requirements for individual access.8 Per 45 CFR 164.524, an individual patient generally has a right of access to inspect and obtain a copy of protected health information (PHI) about themselves in a designated record set for as long as the PHI is maintained in the designated record set by a covered entity. This includes the right to inspect or obtain a 8 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\13DEP2.SGM 13DEP2 76246 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules lotter on DSK11XQN23PROD with PROPOSALS2 copy, or both, of the PHI. Our Patient Access API proposals would complement that right by requiring payers to make the PHI that patients already have a right to access available through a standards-based and interoperable Patient Access API. It is critical that individuals have access to their information and the ability to share it with others who are involved in their care, particularly when it could involve care coordination between providers and prior authorization for certain items and services. When an individual requests an electronic copy of PHI that a covered entity maintains electronically (ePHI), per 45 CFR 164.524(c)(2)(ii), the covered entity must provide the individual with access to the information in the requested electronic form and format, if it is readily producible in that form and format. When the ePHI is not readily producible in the electronic form and format requested, then the covered entity must provide access to an agreed upon alternative readable electronic format.9 As health apps become more common, we believe that it behooves us to require that all impacted payers be able to provide individuals’ ePHI via an industry standard FHIR API, as demonstrated by both our current requirements and our proposals in this section. We believe that, in addition to the other benefits described in this proposed rule, ensuring that patients can receive their ePHI in a standard, interoperable format that they can use with the latest technologies would reduce instances of an individual requesting ePHI in an electronic format that is not readily producible. Individuals have the right under the HIPAA Privacy Rule to request access to PHI in the form and format requested by the individual, if it is readily producible in the manner requested.10 For example, the covered entity must transfer or transmit the PHI to the individual even where the requested mode of transfer or transmission is unsecure as long as the PHI is ‘‘readily producible’’ in such manner, the covered entity is capable of transmitting the PHI in the manner the individual requests, and the manner of transmission would not present an unacceptable level of security risk to the PHI on the covered entity’s systems.11 In 9 See 45 CFR 164.524(c)(2)(ii) and U.S. Department of Health and Human Services. Individuals’ Right under HIPAA to Access their Health Information 45 CFR 164.524. Retrieved from https://www.hhs.gov/hipaa/for-professionals/ privacy/guidance/access/. 10 See 45 CFR 164.524(c)(2). 11 U.S. Department of Health and Human Services. Individuals’ Right under HIPAA to Access their Health Information 45 CFR 164.524. Retrieved VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 the CMS Interoperability and Patient Access final rule, we specifically cited this security risk exception as the only reason payers could deny API access to a health app that a patient wishes to use. These risks include, for example, insufficient authentication or authorization controls, poor encryption, or reverse engineering. The payer must make that determination using objective, verifiable criteria that are applied fairly and consistently across all apps and developers through which patients seek to access their electronic health information. See 42 CFR 422.119(e) for MA organizations; 42 CFR 431.60(e) for state Medicaid FFS programs, through the existing cross reference at 42 CFR 438.242(b)(5) for Medicaid managed care plans; 42 CFR 457.730(e) for state CHIP FFS programs, through the existing cross reference at 42 CFR 457.1233(d) for CHIP managed care entities; and 45 CFR 156.221(e) for QHP issuers on the FFEs. Disagreement with the individual about the worthiness of a health app as a recipient of PHI, or even concerns about what the app might do with the requested PHI, would not be acceptable reasons to deny an individual’s request.12 Therefore, as we also noted in the CMS Interoperability and Patient Access final rule, covered entities and business associates would be free to offer advice to patients on the potential risks involved with requesting data transfers to an app or entity not covered by HIPAA, but such efforts generally must stop at education and awareness or advice related to a specific app. For instance, if a payer noted that the app a patient was using to access their data did not explain in its privacy policy specifically how the patient’s personal data would be used or sold (a possibility for apps not covered by HIPAA), the payer could choose to inform the patient that they may not want to share their data with that app without a clear understanding of how the app may use the data, including details about the app’s secondary data use policy. If the patient still wants their data to be shared, or does not respond to the payer’s warning, the payer would need to share their data via the API, absent an unacceptable security risk to the payer’s own system. For more information on this ability to inform patients, see the from https://www.hhs.gov/hipaa/for-professionals/ privacy/guidance/access/. 12 Office for Civil Rights (OCR) (2019, April 18). Can a covered entity refuse to disclose ePHI to an app chosen by an individual because of concerns about how the app will use or disclose the ePHI it receives? Retrieved from https://www.hhs.gov/ hipaa/for-professionals/faq/3012/can-a-coveredentity-refuse-to-disclose-ephi.html. PO 00000 Frm 00010 Fmt 4701 Sfmt 4702 CMS Interoperability and Patient Access final rule at 85 FR 25550. The requirements we are proposing do not affect or alter any obligations under the HIPAA Privacy and Security Rules. We discussed privacy and safety concerns in the context of APIs in the CMS Interoperability and Patient Access final rule (85 FR 25516). We note that while the FHIR standard itself does not define security-related functions, when used in combination with appropriate security controls (such as authentication and access control), a FHIR API can and should be implemented and maintained to comply with the HIPAA Security Rule for secure data exchange.13 Furthermore, the covered entity is not liable for what happens to the PHI once the designated third party receives the information as directed by the individual.14 Our proposals in this section address how a payer must make patients’ data available to them; however, we do not have the authority to regulate health apps that individuals may wish to use, or what those apps do with PHI. As discussed, per the CMS Interoperability and Patient Access final rule, impacted payers may only deny or discontinue an app’s connection to their APIs if an impacted payer makes a determination using objective, verifiable criteria that the specific health app would present a danger to the impacted payer’s own systems, such as increasing the risk of cyber-attack. Regardless of whether HIPAA applies to a health app, other Federal laws may apply, even where HIPAA does not apply, such as the Federal Trade Commission (FTC) Act. Under section 5 of the FTC Act (15 U.S.C. 45(a)), the FTC has authority to challenge unfair or deceptive trade practices, including those related to the privacy and security of personal health information that apps collect, use, maintain, or share. For example, if an app discloses an individual’s health information in a manner inconsistent with the app’s privacy policy, terms of use, or an individual’s reasonable expectations, or fails to take reasonable measures to assess and address privacy or data security risks, the developer of that app may be violating the FTC Act. The FTC has applied its section 5 authority to a 13 HL7 International (2022, May 28). HL7 FHIR Release 4. 6.1.0 FHIR Security. Retrieved from https://www.hl7.org/Fhir/security.html. 14 Office for Civil Rights (OCR) (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/. E:\FR\FM\13DEP2.SGM 13DEP2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules wide variety of entities, including health apps.15 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, which covers most health apps and similar technologies that are not covered by HIPAA, and therefore, not subject to the HIPAA Breach Notification Rule.16 The FTC’s Health Breach Notification Rule sets forth steps entities covered by that rule must follow when there has been a breach of unsecured personal health information. Any violation of the FTC’s Health Breach Notification Rule is treated as an unfair or deceptive act or practice under section 18 of the FTC Act and subject to civil penalties of up to $46,517 per violation per day. lotter on DSK11XQN23PROD with PROPOSALS2 c. Privacy Policy As we discussed earlier in this proposed rule and in detail throughout the CMS Interoperability and Patient Access final rule (85 FR 25550), one of the most important aspects of making health data accessible to patients is to protect the privacy and security of patient health information, especially because once a patient’s data are received by a health app, their data may no longer be protected by the HIPAA Rules.17 Also as discussed earlier, we do not have the authority to directly regulate health apps. Yet, we take the privacy and security of PHI seriously and understand that patients may not know the implications of giving a health app access to their health information. We are continually working to find ways to further protect patient data. In the CMS Interoperability and Patient Access final rule, we required that impacted payers make educational resources available to their current and former patients with information to help protect the privacy and security of their health information. That includes 15 See, for example, Federal Trade Commission (2021, June 22). Flo Health, Inc. Retrieved from https://www.ftc.gov/legal-library/browse/casesproceedings/192-3133-flo-health-inc. 16 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. 17 Office for Civil Rights (OCR) (2021, January 6). The access right, health apps & APIs. Retrieved from https://www.hhs.gov/hipaa/for-professionals/ privacy/guidance/access-right-health-apps-apis/ index.html. VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 factors to consider in selecting an app, including potential secondary uses of data, and the importance of understanding the security and privacy practices of any app to which they will entrust their health information. Furthermore, impacted payers must provide an overview of which types of organizations or individuals are and are not likely to be HIPAA-covered entities, and the oversight responsibilities of the Office for Civil Rights (OCR) and the FTC, and how to submit a complaint to those entities. See 42 CFR 422.119(g) for MA organizations, 42 CFR 431.60(f) for Medicaid FFS programs, through existing cross-reference at 42 CFR 438.242(b)(5) for Medicaid managed care plans, 42 CFR 457.730(f) for CHIP FFS programs, through existing cross reference at 42 CFR 457.1233(d) for CHIP managed care entities, and at 45 CFR 156.221(g) for QHP issuers on the FFEs. We continue to believe these resources are important to provide to patients, but seek comments on how we can improve this policy so patients can make educated decisions about sharing their personal health information. In the 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program final rule (21st Century Cures Act final rule) (85 FR 25642, 25814 through 25815), ONC noted that providing information that is factually accurate, objective, unbiased, not unfair or deceptive, and provided in a nondiscriminatory manner to inform a patient about the advantages, disadvantages and any risks of sharing their health information with a health app, would be unlikely to interfere (as defined in that rule) with the access, exchange, or use of electronic health information (EHI) for purposes of the information blocking regulations at 45 CFR part 171.18 In response to comments on the CMS Interoperability and Patient Access proposed rule (84 FR 7610), we noted in the final rule (85 FR 25549–25550) commenters’ observations that many patients were unlikely to understand the potential risk of disclosure when their data are transmitted to a health app and are thus no longer protected by the HIPAA Rules. Commenters were 18 See 45 CFR 171.102: Electronic health information (EHI) is electronic protected health information as defined in 45 CFR 160.103 to the extent that it would be included in a designated record set as defined in 45 CFR 164.501, regardless of whether the group of records are used or maintained by or for a covered entity as defined in 45 CFR 160.103. EHI shall not include: (1) Psychotherapy notes as defined in 45 CFR 164.501; or (2) Information compiled in reasonable anticipation of, or for use in, a civil, criminal, or administrative action or proceeding. PO 00000 Frm 00011 Fmt 4701 Sfmt 4702 76247 specifically concerned about secondary uses of data, such as whether developers would sell their data to third parties for marketing or other purposes. In the CMS Interoperability and Patient Access final rule (85 FR 25549), we noted that a clear, plain language privacy policy is the best vehicle to inform patients about how their information will be protected and how it will be used once shared with the health app. In the December 2020 CMS Interoperability proposed rule (85 FR 82592 through 82594), we proposed to require impacted payers to request a privacy policy attestation from health app developers when their app requests to connect to the payer’s Patient Access API. We proposed that the attestation would include, at a minimum, statements that the app has a plain language privacy policy that is always publicly available and accessible, and has been affirmatively shared with the patient prior to the patient authorizing the app to access their health information. In addition, the attestation we proposed included yes/no elements as to whether the privacy policy specifically communicates how the patient’s health information could be accessed, exchanged, or used. While we still believe that certain aspects of our previously proposed attestation policy could support enhanced patient education about health apps’ privacy policies, based on public comments and feedback, we are concerned that this type of attestation would not serve to benefit patients in ways that would outweigh the burden on impacted payers. We are also concerned that such a policy could have unintended consequences for patients. Under the proposal in the December 2020 CMS Interoperability proposed rule, a health app developer would only be attesting to the format and inclusion of certain information. There would be no attestation that the substance of the privacy policy meets specific minimum requirements or best practices. We believe that having payers inform patients that an app developer has attested to the form and format of a privacy policy could easily be misinterpreted as assurance that the substance of the privacy policy has been reviewed and found acceptable by the payer (or CMS). We believe this is especially true in the case of patients with low health or technology literacy, who are least likely to be able to find and interpret an app’s privacy policy to make well-informed decisions about their health data. We are concerned that requiring such an attestation would only give the appearance of privacy and E:\FR\FM\13DEP2.SGM 13DEP2 76248 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules lotter on DSK11XQN23PROD with PROPOSALS2 security for patients’ health data, without providing additional benefit. Because CMS does not have the statutory authority to regulate health apps, we cannot require developers to respond to that attestation. Furthermore, as discussed, even if a health app developer does not respond to the attestation (or responds in the negative), a payer would be required to allow that app to connect (unless it would create a security risk to the payer’s own system) and provide a patient’s health information through the app selected by the patient. Commenters also responded that the proposed process would put an undue burden on payers to manage an attestation process for app developers with whom they may have no legal or contractual relationship. Furthermore, commenters expressed concerns about payers’ lack of adherence mechanisms and payer liability due to the HIPAA right of access requirements discussed previously. We still believe it is important for patients to have a clear understanding of how their health information may be used by a person or entity not covered by the HIPAA Rules, such as a health app, whether their data would be sold or marketed, and how to stop sharing their health information with such entities if they so choose. In particular, explaining certain privacy and security practices in a patient-friendly, easy-toread privacy policy would help patients understand those elements and how they can be an active participant in the protection of their information. We also encourage app developers to follow industry best practices, including the CARIN Alliance’s Code of Conduct and the ONC Model Privacy Notice (MPN).19 20 We note that the developer attestation discussed in the December 2020 CMS Interoperability proposed rule (85 FR 82593) included some of the elements of the 2018 ONC MPN, such as explaining how a patient’s health information may be accessed, exchanged, or used by any person or other entity, including whether the patient’s health information may be shared or sold at any time.21 As discussed, if an app has a written privacy policy and the app or developer 19 CARIN. The CARIN Alliance Code of Conduct (May 2020). Retrieved from https:// www.carinalliance.com/our-work/trust-frameworkand-code-of-conduct/. 20 Office of the National Coordinator. Model Privacy Notice (MPN). Retrieved from https:// www.healthit.gov/topic/privacy-security-and-hipaa/ model-privacy-notice-mpn. 21 Office of the National Coordinator. Model Privacy Notice (MPN). Retrieved from https:// www.healthit.gov/topic/privacy-security-and-hipaa/ model-privacy-notice-mpn. VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 operates contrary to that policy, the FTC has authority to act. We request comments on how we can help give patients the tools they need to understand the privacy and security implications of using a health app within the scope of our regulatory authority. We seek ideas on how we can balance our desire to both educate patients and respect their rights under the HIPAA Privacy Rule. For example, should there be a process at the time a developer registers an app with a payer for access to the API to submit information about its privacy policy? Should payers be required to provide that information in an easy-tounderstand format the first time a patient requests access via an app? We encourage comments about how we can leverage the MPN (most recent version from 2018). While we cannot require health app developers to utilize the MPN, should payers notify patients, the first time the patients request data through an app, whether the app utilizes the MPN or not? To encourage visibility for apps that use the MPN versus those that do not, should payers be required to list apps that have established access to their API on their websites that comply with the MPN’s transparency requirements? We note that payers would have to treat apps identically based on the substance of their privacy policies and could not favor certain apps over others, such as for competitive advantage. Again, we (and payers) cannot prohibit patients from using health apps that do not comply with best privacy and security practices unless it presents an unacceptable security risk to the payer’s systems. We also request comment on whether we can leverage and build on other HHS health information exchange initiatives, such as TEFCA, to address these issues. For more background on TEFCA, see the related Request for Information in section III.E. of this proposed rule. The Common Agreement and Framework Agreement include privacy and security requirements for Qualified Health Information Networks (QHINs), Participants, and Subparticipants that elect to exchange information pursuant to it, including entities not covered by the HIPAA Rules.22 Within the Common 22 For the Common Agreement definitions of the terms used in this section (QHIN, Participant, Subparticipant, IAS Provider, Framework Agreement, Connectivity Services, Individual, Required Information, Direct Relationship, Use, Disclosure), see page 3–14 in, Office of the National Coordinator (January 2022). Common Agreement for Nationwide Health Information Interoperability Version 1. Retrieved from https://www.healthit.gov/ sites/default/files/page/2022-01/Common_ PO 00000 Frm 00012 Fmt 4701 Sfmt 4702 Agreement, any QHIN, Participant, or Subparticipant that offers Individual Access Services (IAS) 23 by which an individual can access, inspect, or obtain a copy of that individual’s information is an IAS Provider. If a health app developer becomes a signatory to a Framework Agreement and offers IAS Services, that developer would be an IAS Provider. That developer would be providing services utilizing the TEFCA Connectivity Services to an Individual with whom the QHIN, Participant, or Subparticipant has a Direct Relationship to satisfy that Individual’s ability to access, inspect, or obtain a copy of that Individual’s Required Information that is then maintained by or for any QHIN, Participant, or Subparticipant. IAS Providers must, among other requirements, have a written privacy and security notice; obtain express written consent from individuals regarding the way their information will be accessed, exchanged, used (as defined in the Common Agreement), or disclosed (as defined in the Common Agreement), including the sale of their health information; provide individuals with the right to delete their individually identifiable information as well as the right to revoke their consent, with certain exceptions, in addition to a disclosure of any applicable fees or costs related to IAS; and provide individuals with the right to obtain an export of their individually identifiable information in a computable format.24 Additionally, IAS Providers are required to protect all individually identifiable information (including health information) they hold in accordance with security requirements specified in the Common Agreement and applicable Standard Operating Procedures, such as the draft IAS Provider Privacy and Agreement_for_Nationwide_Health_Information_ Interoperability_Version_1.pdf. 23 The Common Agreement defines Individual Access Services (IAS) as follows: ‘‘with respect to the Exchange Purposes definition, the services provided utilizing the Connectivity Services, to the extent consistent with Applicable Law, to an Individual with whom the QHIN, Participant, or Subparticipant has a Direct Relationship to satisfy that Individual’s ability to access, inspect, or obtain a copy of that Individual’s Required Information that is then maintained by or for any QHIN, Participant, or Subparticipant.’’ See page 7 in, Office of the National Coordinator (January 2022). Common Agreement for Nationwide Health Information Interoperability Version 1. Retrieved from https://www.healthit.gov/sites/default/files/ page/2022-01/Common_Agreement_for_ Nationwide_Health_Information_Interoperability_ Version_1.pdf. 24 See pages 33–38 in, Office of the National Coordinator (January 2022). Common Agreement for Nationwide Health Information Interoperability Version 1. Retrieved from https://www.healthit.gov/ sites/default/files/page/2022-01/Common_ Agreement_for_Nationwide_Health_Information_ Interoperability_Version_1.pdf. E:\FR\FM\13DEP2.SGM 13DEP2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules lotter on DSK11XQN23PROD with PROPOSALS2 Security Notice and Practices Standard Operating Procedure (SOP) 25 and the IAS Exchange Purpose Implementation SOP.26 27 Given the Common Agreement’s privacy and security requirements, and particularly those that will apply when patients access their health information through a participating IAS Provider, we request comment on whether CMS should explore requirements or ways to encourage exchange under TEFCA as a way to ensure that more patients are informed about the privacy and security implications of using health apps to access their health information, consistent with the requirements for IAS Providers described previously. For instance, how could CMS encourage health apps that are not subject to the HIPAA Rules to connect to entities that exchange information under TEFCA? If so, what should be the contours of, and levers for, such encouragement? What other approaches can CMS take to encourage app developers to enable exchange under TEFCA and therefore leverage the Common Agreement’s privacy and security requirements? In addition, we request comments on the availability of apps that are accessible to individuals with disabilities, availability of apps in a multitude of languages to ensure that individuals with limited English proficiency can understand the information provided, and availability of apps at an appropriate literacy level and in plain language. We note that the draft IAS Provider Privacy and Security Notice and Practices SOP includes guidance regarding plain language and literacy requirements.28 We believe apps with these features are important to ensure that all patients can benefit from the proposals in this rule. We 25 The Sequoia Project (2022, June 21). Standard Operating Procedure (SOP): Individual Access Service (IAS) Provider Privacy and Security Notice and Practices. DRAFT FOR PUBLIC FEEDBACK. Retrieved from https://rce.sequoiaproject.org/wpcontent/uploads/2022/06/SOP-IAS-Privacy-andSecurity-Notice-1.pdf. 26 The Sequoia Project (2022). Standard Operating Procedure (SOP): Individual Access Services (IAS) Exchange Purpose Implementation. Retrieved from https://rce.sequoiaproject.org/wp-content/uploads/ 2022/06/SOP_IAS_Exchange_Purpose_ Implementation.pdf. 27 See pages 35–37 in, Office of the National Coordinator (January 2022). Common Agreement for Nationwide Health Information Interoperability Version 1. Retrieved from https://www.healthit.gov/ sites/default/files/page/2022-01/Common_ Agreement_for_Nationwide_Health_Information_ Interoperability_Version_1.pdf. 28 See pages 5–6 in, The Sequoia Project (2022, June 21). Standard Operating Procedure (SOP): Individual Access Service (IAS) Provider Privacy and Security Notice and Practices. DRAFT FOR PUBLIC FEEDBACK. Retrieved from https:// rce.sequoiaproject.org/wp-content/uploads/2022/ 06/SOP-IAS-Privacy-and-Security-Notice-1.pdf. VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 request comment on any actions that we can take to ensure patients’ equitable access to their health information. d. Patient Access API Metrics We are proposing to require impacted payers to report metrics in the form of aggregated, de-identified data to CMS on an annual basis about how patients use the Patient Access API. This reporting would help CMS better understand whether the Patient Access API requirement is efficiently and effectively ensuring that patients have access to their health information and whether payers are providing that required information in a transparent and timely way. Aggregated usage data from every impacted payer would help us evaluate whether the Patient Access API policies are achieving the desired goals. Gathering this information would also help us to provide targeted support or guidance to impacted payers, if needed, to help ensure that patients have access to their data and can use their data consistently across the impacted payer types. We propose to require MA organizations to report these data to CMS at the organization level, state Medicaid and CHIP FFS programs to report at the state level, Medicaid managed care plans to report at the state level, CHIP managed care entities to report at the state level, and QHP issuers on the FFEs to report at the issuer level. We are considering, and therefore seek comment on, whether we should require payers that administer multiple plans under a single contract to report these data to CMS at the contract level. We also seek comment on the benefits or drawbacks of an alternative final policy that would permit MA organizations, entities offering Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to report aggregate data for the same plan type at higher levels (such as the parent organization level or all plans of the same type in a program). We note that in the December 2020 CMS Interoperability proposed rule (85 FR 82594), we proposed that these data be reported quarterly, and received comments from a broad variety of stakeholders strongly in favor of annual reporting. Based on that feedback, we are now proposing annual reporting. Specifically, we propose that these payers annually report: • The total number of unique patients whose data are transferred via the Patient Access API to a health app designated by the patient; and • The total number of unique patients whose data are transferred more than once via the Patient Access API to a health app designated by the patient. PO 00000 Frm 00013 Fmt 4701 Sfmt 4702 76249 Tracking multiple data transfers would indicate repeat access, showing that patients are either using multiple apps or are allowing apps to update their information over the course of the year. While we are not certain whether such data transfers would indicate to what extent patients are using the apps to manage their healthcare, it would be a preliminary indicator of interest in the technology to access their data. We are proposing that payers must report data from the previous calendar year to CMS by March 31 of each year. The first year the requirement would be applicable, payers would report calendar year 2025 data by March 31, 2026. A new MA organization, Medicaid managed care plan, CHIP managed care entity, or QHP issuer on the FFEs would naturally have no data to report in its first year of existence and would be required to report data following its first full calendar year subject to the Patient Access API requirement. In summary, we propose that beginning in 2026, MA organizations at the organization level, state Medicaid and CHIP FFS programs at the state level, Medicaid managed care plans at the state level, CHIP managed care entities at the state level, and QHP issuers on the FFEs at the issuer level must annually report the following metrics to CMS in the form of aggregated, de-identified data: (1) the total number of unique patients whose data are transferred via the Patient Access API to a health app designated by the patient; and (2) the total number of unique patients whose data are transferred more than once via the Patient Access API to a health app designated by the patient. Collecting this information would facilitate CMS’ oversight and evaluation of the MA, Medicaid, and CHIP programs and of QHP issuers on the FFEs. We propose that impacted payers report the previous calendar year’s metrics, in the form of aggregated, de-identified data, to CMS by March 31 of each year. MA organizations, Medicaid managed care plans, and CHIP managed care entities would report metrics to CMS following any year that they operated, and QHP issuers would report metrics to CMS following any year that they offered a QHP on the FFEs. We are making this proposal at the CFR sections identified in Table 1. If we finalize this proposal, we do not plan to publicly report these metrics at the state, plan, or issuer level, but may reference or publish aggregated and deidentified data that does not include names of specific state agencies, plans, or issuers. We solicit comment on this aspect of our proposal. E:\FR\FM\13DEP2.SGM 13DEP2 76250 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules lotter on DSK11XQN23PROD with PROPOSALS2 In addition, we request comment on what other Patient Access API metrics we should consider requiring payers to report to CMS and/or make available to the public on their own websites, for consideration in possible future rulemaking. For instance, we are seeking comments on whether payers could report aggregated demographic information, such as sex, race, age, ethnicity, and geographical (for instance, by zip code) data that they may already have to help identify disparities in patient access to health data or underserved populations and, if so, what policies should be considered to minimize those disparities. We are also seeking comment on the potential benefits and burden of requiring payers to report the names of all apps that patients have used to access the payers’ API each year. We are considering either collecting this information, or requiring payers to make it public, not to recommend or endorse specific apps, but to maintain a view of the apps that patients use to access their health information, which could help us review for best practices and to evaluate patient ease of use. e. Patient Access API Amendments To accommodate the proposed requirements regarding the use of the Patient Access API, we are proposing two minor terminology changes to the requirements finalized in the CMS Interoperability and Patient Access final rule (85 FR 25558, 25547). We note that unlike most of our proposals, we are proposing that these amendments would go into effect on the effective date of the final rule. We are proposing these changes to clarify terms, but do not expect them to substantively change any current regulatory obligation. First, we are proposing to revise the description of the clinical data to be made available via the Patient Access API by MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs at the CFR sections identified in Table 1. These provisions currently require payers to make available ‘‘clinical data, including laboratory results.’’ We are proposing to revise these paragraphs to specify that the data that payers must make available are ‘‘all data classes and data elements included in a content standard at 45 CFR 170.213.’’ The standard currently referenced at 45 CFR 170.213 is the USCDI version 1. Laboratory Values/ Results is a USCDI version 1 data element, and USCDI version 1 includes data classes for other aspects of clinical information such as Immunizations, VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 Procedures, and Assessment and Plan of Treatment. Referring explicitly to the data set in a standard at 45 CFR 170.213 in the rule text would help avoid unnecessary confusion, as this reference would more clearly identify exactly what data must be available through the Patient Access API. In the future, as versions of the USCDI evolve, there may be multiple versions of the standard referenced at 45 CFR 170.213 at one time. For the ONC Health IT Certification Program, this allows for a transition period between standards as health IT developers incorporate updated standards versions within their systems and complete required certification. Through this proposal, we are seeking to ensure that the same flexibility would apply for payers as they transition between the versions of the USCDI. During such a period, when 45 CFR 170.213 includes more than one version of the USCDI standard, payers would be allowed to use any of the then-available standards at 45 CFR 170.213 for the data classes and elements that they make available through the API. Second, we are proposing to revise the language previously finalized for denial or discontinuation of a health app’s access to the API. Currently, the rules require that the payer make a determination to deny or discontinue access to the Patient Access API using objective, verifiable criteria that are applied fairly and consistently across all apps and developers through which ‘‘enrollees’’ or ‘‘beneficiaries’’ seek to access EHI. We are proposing to change the terms ‘‘enrollees’’ and ‘‘beneficiaries’’ to ‘‘parties’’ for consistency with our proposal to apply this provision to the Provider Access API, Payer-to-Payer API, and the PARDD API discussed further in sections II.B., II.C., and II.D. of this proposed rule. Because other parties would be accessing these APIs, such as providers and payers, it would be more accurate to use the term ‘‘parties’’ rather than ‘‘enrollees’’ or ‘‘beneficiaries.’’ In summary, we propose that we will replace ‘‘clinical data, including laboratory results’’ with ‘‘all data classes and data elements included in a content standard at 45 CFR 170.213’’ for MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs at the CFR sections identified in Table 1. We also propose that we will change the terms ‘‘enrollees’’ and ‘‘beneficiaries’’ to ‘‘parties’’ for MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers PO 00000 Frm 00014 Fmt 4701 Sfmt 4702 on the FFEs at the CFR sections identified in Table 1. We request comment on these proposals. We also direct readers to section II.F. of this proposed rule for a discussion of proposed changes to the interoperability standards for APIs that affect the Patient Access API. f. Specific CHIP-Related Regulatory Framework Specifically, for CHIP, the proposed amendments to 42 CFR 457.1233(d) would align separate CHIP managed care API requirements with the Medicaid managed care API requirements, rather than with the CHIP FFS API requirements. In the CMS Interoperability and Patient Access final rule (85 FR 25559), we finalized requirements for separate CHIP managed care entities at 42 CFR 457.1233(d). API requirements for CHIP managed care entities were codified at 42 CFR 457.1233(d)(2) and (3) through cross-references to CHIP FFS program requirements at 42 CFR 457.730 and 457.760, respectively. On November 13, 2020, we published a final rule titled ‘‘Medicaid Program; Medicaid and Children’s Health Insurance Program (CHIP) Managed Care’’ (85 FR 72754). In that rule, we removed 42 CFR 457.1233(d)(1) through (3), and, at 42 CFR 457.1233(d), cross-referenced to Medicaid managed care regulatory requirements at 42 CFR 438.242. Therefore, the policies in the CMS Interoperability and Patient Access final rule (85 FR 25559) are applicable to separate CHIP managed care entities per 42 CFR 457.1233(d) through a cross reference to Medicaid managed care at 42 CFR 438.242. We propose to apply the API requirements in this proposed rule to separate CHIP managed care entities through the existing cross reference at 42 CFR 457.1233(d) to Medicaid managed care at 42 CFR 438.242, and have noted this throughout the proposals in this proposed rule. Most states have Medicaid Expansion CHIP programs, in which a state receives Federal funding to expand Medicaid eligibility to optional targeted low-income children that meet the requirements of section 2103 of the Social Security Act (the Act). We are proposing at 42 CFR 457.700(c) that for states with Medicaid Expansion CHIP programs, the proposals in this rule for Medicaid would apply to those programs rather than our proposals for separate CHIP programs. Functionally, our proposals are the same, however, for clarity, we are making explicit that the Medicaid requirements at 42 CFR 431.60, 431.61, and 431.80 would apply to those programs rather than the E:\FR\FM\13DEP2.SGM 13DEP2 lotter on DSK11XQN23PROD with PROPOSALS2 Frm 00015 Fmt 4701 Sfmt 4702 13DEP2 a. MA Organizations E:\FR\FM\13DEP2.SGM 3. Statutory Authorities for the Patient Access API Proposals PO 00000 I Inclusion of Prior Authorization Information II.A.2.a. I Timeframe for Prior Authorization Data Availability II.A.2.d. I Reporting Patient Access API Metrics II.A.2.e. II.A.2.e. I Revisions to the Scope I of Clinical Data to be Made Available via the Patient Access API Patient Access API Denial/Discontinuation of Access 42CFR 422.119(b) (1 )(iv)(A) 42CFR 431.60(bX5)(i) 42CFR 422. l l 9(b)(1 )(iv) (8) 42CFR 43 l.60(b X5)(ii) 42CFR 422.119([) 42CFR 431.60(h) 42CFR 422.119(b )(1 Xiii) 42CFR 43 l.60(b)(3) 42CFR 422.119(e)(2) 42CFR 431.60(e)(2) Through proposed cross-reference to 42 CFR 431.60 at 42 CFR 438.242(b)(5) Through proposed cross-reference to 42 CFR 431.60 at 42 CFR 438.242(b)(5) Through proposed cross-reference to 431.60(h) at42 CFR 438.242rh )( 5)(iii) Through proposed cross-reference to 42 CFR 431.60 at 42 CFR 438.242(b)(5) Through proposed cross-reference to 42 CFR431.60 at42 CFR 438.242(b)(5) 42CFR 457.730(bX5)(i) 42CFR 457.730(bX5)(ii) 42CFR 457.730(h) 42CFR 457.730(bX3) 42CFR 457.730(e)(2) Through existing cross reference to 42 CFR 438.242 at 42 CFR 457.1233( d) Through existing cross reference to 42 CFR 438.242 at 42 CFR 457.1233(d Through existing cross reference to 42 CFR 438.242 at 42 CFR 457.1233(d Through existing cross reference to 42 CFR 438.242 at 42 CFR 457.1233(d Through existing cross reference to 42 CFR 438.242 at 42 CFR 457.1233(d 145 CFR 156.221(bX1XivXA) 145 CFR 156.22l(b)(lXivXB) I 45 CFR 156.221([) 145 CFR 156.22l(b)(1Xiii) 145 CFR 156.221(eX2) Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules Jkt 259001 II.A.2.a. separate CHIP requirements at 42 CFR 457.730, 457.731, and 457.732. BILLING CODE 4120–01–P 18:56 Dec 12, 2022 BILLING CODE 4120–01–C VerDate Sep<11>2014 TABLE 1: PATIENT ACCESS API PROPOSED POLICIES 76251 EP13DE22.000</GPH> lotter on DSK11XQN23PROD with PROPOSALS2 76252 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules For MA organizations, we are proposing these new requirements and the revisions to current requirements under our authority at sections 1856(b)(1) (to promulgate regulations implementing MA standards, including the requirements in section 1852(h) of the Act), and 1857(e)(1) of the Act (to add contract terms determined by the Secretary to be ‘‘necessary and appropriate’’). Section 1856(b)(1) of the Act requires the Secretary to establish regulatory standards for MA organizations that are consistent with and carry out Part C of the Medicare statute, Title XVIII of the Act. Section 1852(h) of the Act requires that MA organizations have procedures in place to maintain accurate and timely medical records and health information regarding MA enrollees and to assure enrollees have timely access to such records and information. Our proposal for the Patient Access API is to require access for enrollees to specified medical records and health information through a specific mechanism from the MA organization. The Secretary is authorized under section 1857(e)(1) of the Act to add new contract terms, including additional standards and requirements, for MA organizations that the Secretary finds necessary and appropriate and that are not inconsistent with Part C of the Medicare statute. The proposals here meet this standard by addressing and facilitating access to enrollees’ medical records and health information for the reasons identified in our discussions for each proposal. The proposal in section II.A.2.a. of this proposed rule that would require MA organizations to make an enrollee’s prior authorization requests and related clinical documentation available through the Patient Access API would, if finalized as proposed, allow these enrollees to have access to that information in a convenient, timely, secure, and portable way, which is in enrollees’ best interests. This proposed requirement is consistent with section 1852(h) of the Act, which requires MA organizations to assure enrollees timely access to their records and data that is maintained by MA organizations. To ensure that MA organizations meet modern-day patient expectations of transparency, efficiency, and timeliness when providing prior authorization data to enrollees, it is essential for CMS to ensure that each MA organization has a standardized system in place that offers enrollees access to their own data, including data that pertain to their prior authorizations, using existing and emerging technologies of their choice, VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 specifically in this case, health apps. Therefore, making these data available through the Patient Access API is consistent with our programmatic authority to establish standards to implement section 1852(h) of the Act, and could help patients be more informed about and active in their own care, which could potentially lead to better health outcomes. Making this information available via the Patient Access API could help enrollees support the prior authorization process, as well. Enrollees could see what information is needed and what information has been provided on their behalf to facilitate a prior authorization request. Enrollees could provide missing information needed by the payer to reach a decision. This could allow MA organizations to address prior authorization requests more promptly, streamlining this process, and thus simplifying prior authorization for the MA organizations. This could also improve an enrollee’s experience with the process, by facilitating timelier and potentially more successful initial prior authorization requests. This, again, supports efficient operation and timely provision of information and services. In addition, to ensure the requirements proposed here and finalized in the CMS Interoperability and Patient Access final rule (85 FR 25558 through 25559) would be most effective, CMS proposes in this rule that MA organizations report specific metrics to CMS on enrollee use of the Patient Access API. Section 1857(e)(1) of the Act explicitly authorizes the adoption of additional reporting to CMS by MA organizations where necessary and appropriate. Here, these proposed metrics would facilitate CMS’s oversight, evaluation, and administration of patient health data access in the Part C program and therefore, this data collection is necessary and appropriate to adopt. In alignment with HHS’s priorities and goals, CMS is focused on putting patients at the center of their own healthcare and ensuring patients have secure access to their health information. We believe these proposals are critical and appropriate to ensure that MA organizations stay abreast of industry standards and continue to offer enrollees not only quality coverage but also a quality customer experience. b. Medicaid and CHIP Our proposed requirements in this section for Medicaid managed care plans and Medicaid state agencies fall generally under our authority in sections 1902(a)(4), 1902(a)(7), PO 00000 Frm 00016 Fmt 4701 Sfmt 4702 1902(a)(8), and 1902(a)(19) of the Act. Section 1902(a)(4) of the Act requires that a state Medicaid plan provide such methods of administration as are found by the Secretary to be necessary for the proper and efficient operation of the state Medicaid plan. Section 1902(a)(8) of the Act requires states to ensure that Medicaid services are furnished with reasonable promptness to all eligible individuals. Section 1902(a)(19) of the Act requires states to ensure that care and services are provided in a manner consistent with simplicity of administration and the best interests of the recipients. In addition, section 1902(a)(7) of the Act requires that states must provide safeguards that restrict the use or disclosure of information concerning Medicaid applicants and beneficiaries to uses or disclosures of information that are directly connected with the administration of the Medicaid state plan. The implementing regulations for this section of the Act list purposes that CMS has determined are directly connected to Medicaid state plan administration at 42 CFR 431.302 and provide safeguards states must apply to uses and disclosures of beneficiary data at 42 CFR 431.306. CHIP programs are subject to the same requirements through a cross reference at 42 CFR 457.1110(b). Our proposal to require that the data described in this section be shared via the Patient Access API would be consistent with the requirement that states may share these data only for purposes directly connected to the administration of the Medicaid state plan, since this data sharing would be related to providing services for beneficiaries, a purpose listed in § 431.302(c). As mentioned previously, giving a patient access to their own health information can make them a more active participant in ensuring they receive timely and appropriate care (for example, allowing them to monitor medications or access treatment history). Additionally, states must apply the safeguards described at 42 CFR 431.306 when sharing beneficiary data via the Patient Access API. We remind states that in order to meet the requirements of that regulation, states must have consistent criteria for release and use of information (which should comply with the proposed Patient Access API requirements, if finalized), in accordance with 42 CFR 431.306(a). Access to information concerning beneficiaries must be restricted to persons who are subject to standards of confidentiality that are comparable to that of the Medicaid agency, in accordance with 42 CFR 431.306(b). The E:\FR\FM\13DEP2.SGM 13DEP2 lotter on DSK11XQN23PROD with PROPOSALS2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules permission requirement at § 431.306(d), which requires that the State agency obtain permission from a family or individual, whenever possible, before responding to a request for information from an outside source, is not relevant to this proposal, because any request for beneficiary information would be from Medicaid beneficiaries themselves and the apps that they are authorizing to receive their information. Beneficiaries are not ‘‘outside sources,’’ and, while apps might be outside sources, information is shared with an app through this API only if the beneficiary has verified their identity (through authentication protocols) and authorized the app to receive information. We do not believe that any of the other requirements at section 431.306 are relevant because they cover data release and use in contexts outside of our proposals in this section. However, we welcome comments from state Medicaid agencies and other members of the public on this topic. The proposed requirement to make information about prior authorization requests and associated documentation available through the Patient Access API is expected to allow beneficiaries to more easily obtain information about the status of prior authorization requests submitted on their behalf. Beneficiaries could potentially use that information to make more informed decisions about their healthcare, improve the efficiency of accessing and scheduling services, and, if needed, provide missing information that the state (or Medicaid managed care plan, if applicable) needs to reach a decision. Receiving missing information more quickly could enable more prompt responses from Medicaid FFS programs and managed care plans to prior authorization requests, thus facilitating more timely and successful prior authorizations, which would help states fulfill their obligations to provide care and services in a manner consistent with simplicity of administration and the best interests of the recipients, and to furnish services with reasonable promptness to all eligible individuals. Improving the prior authorization process could also help improve the efficient operation of the state plan by potentially improving the speed and consistency of prior authorizations, which could, in turn, facilitate faster access to care for beneficiaries. In these ways, these proposals are authorized under section 1902(a)(4), (8), and (19) of the Act. In addition, this proposal would help implement section 1932(b)(4) of the Act, which provides that each Medicaid managed care organization must establish an internal grievance VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 procedure under which a beneficiary who is eligible for medical assistance may challenge the denial of coverage or payment for such assistance. CMS has traditionally extended requirements applicable to Medicaid managed care organizations to other Medicaid managed care plan types as efficient and proper methods of administration under section 1902(a)(4) of the Act to ensure that Medicaid beneficiaries have the same protections, benefits, and responsibilities regardless of the type of managed care plan in which they are enrolled. Allowing beneficiaries to access the status of their denied prior authorizations within 1 business day could enable beneficiaries to file appeals timelier and receive faster resolution. Enabling beneficiaries to monitor the status of prior authorization requests submitted on their behalf is also consistent with how section 1932(c)(2)(A) of the Act indicates that timely access to care should be assured for beneficiaries. Knowing within 1 business day that a prior authorization has been approved could enable a beneficiary to more promptly schedule or obtain care. We are also proposing to require state Medicaid agencies and Medicaid managed care plans to report Patient Access API metrics to CMS annually. We believe that having these metrics would support CMS’ oversight, evaluation, and administration of the Medicaid program, as it would allow us to evaluate beneficiary access to the Patient Access API. Use of the API could indicate that the policy is supporting program efficiencies and ensuring access to information in a timely and efficient way and in the best interest of beneficiaries, as intended, and as is consistent with section 1902(a)(4) and (19) of the Act. Additionally, section 1902(a)(6) of the Act requires Medicaid state plans to provide that the state Medicaid agency will make such reports, in such form and containing such information, as the Secretary may from time to time require. These metrics would serve as a report to evaluate the implementation and execution of the Patient Access API. For CHIP, we propose these requirements under the authority in section 2101(a) of the Act, which states that the purpose of Title XXI of the Act is to provide funds to states to provide child health assistance to uninsured, low-income children in an effective and efficient manner that is coordinated with other sources of health benefits coverage. This provision provides us with authority to adopt these requirements for CHIP because the proposed requirements increase patient PO 00000 Frm 00017 Fmt 4701 Sfmt 4702 76253 access to their health information, which can improve the efficacy of CHIP programs, allow for more efficient communication and administration of services, and promote coordination across different sources of health benefits coverage. We believe that requiring CHIP agencies, as well CHIP managed care entities, to make CHIP beneficiaries’ prior authorization data and other standardized data available through standards-based APIs would ultimately lead to these beneficiaries accessing that information in a convenient, timely, and portable way. This improved access would help to ensure that services are effectively and efficiently administered in the best interests of beneficiaries, consistent with the requirements in section 2101(a) of the Act. We believe making patient data available in this format would result in better health outcomes and patient satisfaction and improve the cost effectiveness of the entire healthcare system, including CHIP. These proposals align with section 2101(a) of the Act in that they also would improve the efficiency of CHIP programs. For example, adding information about prior authorization requests to the Patient Access API would allow beneficiaries to easily obtain the status of prior authorization requests made on their behalf. This would in turn allow patients to make scheduling decisions, and provide any missing information needed by a payer to reach a decision, which makes the prior authorization process more efficient, ultimately streamlining the prior authorization process. Additionally, the safeguards for applicant and beneficiary information at subpart F of 42 CFR part 431 are also applicable to CHIP through a crossreference at 42 CFR 457.1110(b). As discussed above for Medicaid, giving CHIP beneficiaries access to their prior authorization statuses through the Patient Access API would be related to providing services to beneficiaries, which is described at 42 CFR 431.302(c) as a purpose directly related to state plan administration. Allowing beneficiary access to prior authorization statuses also conforms with provisions for beneficiary access to their records at 42 CFR 457.1110(e). We remind states that when they share beneficiary information through the Patient Access API, they must comply with the privacy protections at 42 CFR 457.1110 and the release of information provisions at 42 CFR 431.306. Finally, proposing to require state CHIP agencies and CHIP managed care entities to report Patient Access API E:\FR\FM\13DEP2.SGM 13DEP2 76254 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules lotter on DSK11XQN23PROD with PROPOSALS2 metrics to CMS annually would help states and CMS understand how this API can be used to continuously improve the effectiveness and efficiency of state CHIP operations by providing information about its use, which is an indication of the API’s uptake among patients, including how many only use it for a one-time setup consistent with 2107(b)(1) of the Act. The more we understand about the use of the Patient Access API, the better we can assess that the API is leading to improved operational efficiencies and providing information to beneficiaries in a way that supports their best interests. c. QHP Issuers on the FFEs For QHP issuers on the FFEs, we propose these new requirements under our authority in section 1311(e)(1)(B) of the Affordable Care Act, which affords the Exchanges the discretion to certify QHPs if the Exchange determines that making available such health plans through the Exchange is in the interests of qualified individuals in the state in which the Exchange operates. We believe generally that certifying only health plans that take steps to make enrollees’ prior authorization requests and related clinical documentation available through interoperable technology would ultimately lead to these enrollees having access to that information in a convenient, timely, and portable way, which is in enrollees’ best interests. Having simple and easy access, without special effort, to their health information also would facilitate enrollees’ ability to detect and report fraud, waste, and abuse—a critical component of an effective program. Adding information about prior authorization requests to the Patient Access API would allow enrollees to easily obtain the status of prior authorization requests submitted on their behalf and use that information effectively to make more informed decisions about their healthcare, improve the efficiency of accessing and scheduling services, and, if needed, provide missing information needed by the issuer to reach a decision. This could allow QHP issuers on the FFEs to more promptly address prior authorization requests. This would also facilitate timelier and potentially more successful initial prior authorization requests. We encourage SBEs (including SBE–FPs) to consider whether a similar requirement should be applicable to QHP issuers on SBEs. Finally, proposing to require QHP issuers on the FFEs to report Patient Access API metrics to CMS annually would help CMS assess the effect this VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 API is having on enrollees and would inform how CMS could either enhance the policy or improve access or use through activities such as additional patient education. These data could help CMS understand how best to leverage this API, and patient access to it, to ensure this requirement is being met efficiently and adding value to CMS operations, including leading to the efficiencies intended. B. Provider Access API 1. Background In the CMS Interoperability and Patient Access final rule, we implemented policies regarding the Patient Access API (85 FR 25558) that would allow patients to access their health information through an app. Patients who do so could then share their information with their provider during an appointment. For example, during a visit with a provider, a patient could share specific diagnoses, procedures, and tests accessed through the Patient Access API and stored on their mobile smart device, which could help inform a discussion with their provider about their health status. We also discussed the potential benefits of payers sharing patient health information directly with providers in that final rule (85 FR 25555) and encouraged payers to consider an API solution that would enable providers to access appropriate health information through the payers’ APIs to support the delivery of care. We sought comment on the feasibility of implementing and maintaining a FHIR API for data exchange between payers and providers and received comments strongly supporting our concept to require data availability through a Provider Access API. Some commenters stated that allowing providers to receive data, including prior authorization information, directly from payers would make FHIR-based data exchange significantly more valuable for patients, providers, and payers. More data could be available to help providers manage an individual’s total care and providers could reduce or eliminate duplicate tests, which might avoid diagnostic errors. Payers might also see fewer duplicate requests for services, fewer appeals and, possibly, lower costs. We specifically agreed with commenters that making information about prior authorization decisions available via an API would reduce burden on providers and their staff (85 FR 25541). While using the Patient Access API is a significant first step toward sharing individual patient health information with providers, it would also be PO 00000 Frm 00018 Fmt 4701 Sfmt 4702 beneficial for payers to make patient data directly available to providers via a FHIR API. In the normal course of business, many providers already maintain EHRs and share data for a variety of purposes authorized by the patient and/or existing law. Therefore, in this rule we propose to require that impacted payers implement and maintain a FHIR API that makes patient data available to providers who have a contractual relationship with the payer and a treatment relationship with the patient. The proposed Provider Access API has the potential to allow payers to build upon their existing systems and processes to enhance access to patient data, while continuing to protect patient privacy and data security. In the December 2020 CMS Interoperability proposed rule, we proposed to require payers to build a Provider Access API. As discussed in section I.A. of this proposed rule, we are withdrawing the December 2020 CMS Interoperability proposed rule and issuing this new proposed rule that incorporates the feedback we received from stakeholders on that proposed rule. We understand that many readers may already be familiar with that proposed rule. To distinguish between that proposed rule and our proposals herein, we refer readers to section I.A. of this proposed rule, which outlines the overarching differences between the two proposed rules. We are again proposing to require impacted payers to implement and maintain a FHIR API to exchange data with providers, but with changes from the December 2020 CMS Interoperability proposed rule. We are again proposing a FHIR API, but we are now taking a different approach to the standards required for the API, as further described in section II.F. of this proposed rule. We are also proposing a patient opt out (rather than an opt in) policy that would require payers to allow patients to opt out of the Provider Access API proposed herein. Finally, we propose to establish the Provider Access API compliance date as January 1, 2026. As mentioned in section I.A. of this proposed rule, these proposals do not pertain to Medicare FFS. We seek comment on how each of our proposals discussed below on Provider Access API could be implemented for the Medicare FFS program. We expect that a Medicare FFS implementation would conform to the same proposed requirements that apply to the impacted payers under this proposed rule, as applicable, so Medicare FFS providers and patients enrolled in Medicare FFS could also benefit from this type of data sharing. We seek comment on whether this E:\FR\FM\13DEP2.SGM 13DEP2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules lotter on DSK11XQN23PROD with PROPOSALS2 could be implemented as proposed for the Medicare FFS program, how we could apply each of these proposals below, and if there would be any differences for implementing the Provider Access API in the Medicare FFS program as a Federal payer. As noted later in this section of this proposed rule, CMS’s Data at the Point of Care (DPC) project is currently piloting an API that makes Medicare FFS claims and Part D data available to certain providers. We note that because Medicare FFS provider remittances and enrollee cost-sharing information are not proprietary, those data are shared in the DPC pilot; however, as discussed in this section, impacted payers would not be required to share that information under our proposals. The information gained from the DPC pilot will be useful to implementers should the proposals in this proposed rule be finalized. 2. Proposed Requirements for Payers: Provider Access API for Individual Patient Information In the CMS Interoperability and Patient Access final rule (85 FR 25558), we required impacted payers to make certain health information available to health apps when requested by a patient, through a Patient Access API. We believe it would be valuable for providers to have access to the same patient data, except for provider remittances and enrollee cost-sharing information, through a FHIR API that allows a provider to request data for an individual patient, as needed, thereby providing further insight into the patient’s care activity. Research shows that patients achieve better outcomes when their record is more complete and there are more data available to the healthcare provider at the point of care.29 Making more comprehensive information available to providers could thus improve the care experience for patients. Ensuring that providers have access to relevant patient data at the point of care could also reduce the burden on patients to recall and relay information during an appointment and/or provide confirmation that the patient’s recollection of prior care is accurate. Therefore, we are proposing to require that impacted payers implement and maintain a Provider Access API to enable current patients’ information to be exchanged from payers to providers that are in that payer’s network, at the provider’s request. A provider in the 29 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:56 Dec 12, 2022 Jkt 259001 payer’s network, for purposes of this proposal, would be any provider or healthcare facility that is part of a specific health plan’s network of providers with which it has a contract. In the case of Medicaid and CHIP FFS programs, it would be any providers or healthcare facilities that are enrolled with the state as Medicaid or CHIP providers. We note that this requirement would only apply to current patients. Once a patient is no longer enrolled with a payer, the payer would not need to share data with providers under this proposal. However, see section II.C. for the proposed Payer-to-Payer API requirements for transferring a patient’s data from a previous payer to a new payer. The proposed Provider Access API would allow a provider to initiate a request, for example, when the provider needs access to a patient’s data prior to or during a patient visit. Both this proposed Provider Access API and the Patient Access API would facilitate the FHIR-based exchange of claims and encounter data, as well as all data classes and data elements included in a content standard adopted at 45 CFR 170.213, such as Immunizations, Procedures, and Assessment and Plan of Treatment, should the payer maintain such information. Both the Patient Access and Provider Access APIs would require payers to share information related to prior authorization requests and decisions (including related administrative and clinical documentation) for items and services (excluding drugs). As discussed in section II.A.2.a of this proposed rule, we are proposing to require that information about prior authorizations (and related administrative and clinical documentation) be available via the Patient Access API for as long as the authorization is active, and at least 1 year after the last status change. We note that we are formulating our proposal for at least 1 year after any status change, but this provision would be particularly relevant to denied and expired prior authorizations, to ensure that they would be available for at least a year after expiring or being denied. We do not propose to require payers to share a patient’s full prior authorization history, because that could comprise a significant amount of information that may no longer be clinically relevant. We believe that sharing claims and encounter information, without provider remittances and enrollee costsharing information, would complement the clinical data classes and data elements included in a content standard at 45 CFR 170.213 by providing more information to support treatment and PO 00000 Frm 00019 Fmt 4701 Sfmt 4702 76255 care coordination. Claims and encounter data used in conjunction with clinical data can offer a broader, more complete picture of an individual’s interactions with all their providers in the healthcare system. With this proposal, we intend to help providers gain efficient access to more comprehensive data on their patients. Thus, we are proposing to require that impacted payers make available any of the applicable patient data with a date of service on or after January 1, 2016. This proposed timeframe for data to be included is consistent with the requirements of the Patient Access API, as finalized in the CMS Interoperability and Patient Access final rule (85 FR 25567), so payers should already be maintaining and making available data from this timeframe via a FHIR API. Such disclosures from payers to healthcare providers would be permitted under the HIPAA Privacy Rule as disclosures for treatment purposes,30 as well as disclosures required by law,31 which this proposed rule would be establishing if finalized. Additionally, Medicaid and CHIP agency disclosures of beneficiary data to in-network providers under this proposal would be consistent with section 1902(a)(7) of the Act and implementing regulations at 42 CFR part 431, subpart F, and 42 CFR 457.1110(b). Under these provisions, states must restrict the use or disclosure of information concerning applicants and beneficiaries to purposes directly connected with the administration of the plan. The disclosures of patient data through the Provider Access API would be directly related to the administration of the state plan because they would support the provision of services for beneficiaries, as described in 42 CFR 431.302(c). As mentioned, a provider could better manage a patient’s total care when they have access to more of that patient’s data because the data would provide a more in-depth medical history, enable more informed decision making, and potentially prevent the provision or ordering of duplicative services. Additionally, states must apply the safeguards described in 42 CFR 431.306 when sharing beneficiary data via the Provider Access API. We remind states that in order to meet the requirements of that regulation, they must have consistent criteria for release and use of information (which should comply with the proposed Provider Access API requirements, if finalized), in accordance with 42 CFR 431.306(a). Access to information concerning 30 See 31 See E:\FR\FM\13DEP2.SGM 45 CFR 164.506(c)(2). 45 CFR 164.512(a). 13DEP2 lotter on DSK11XQN23PROD with PROPOSALS2 76256 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules beneficiaries must be restricted to persons or agency representatives who are subject to standards of confidentiality that are comparable to that of the Medicaid agency, in accordance with 42 CFR 431.306(b). The permission requirement in § 431.306(d), which requires that the State agency obtain permission from a family or individual, whenever possible, before responding to a request for information from an outside source, is not relevant to this proposal, because any request for beneficiary information would be from an enrolled Medicaid or CHIP provider and thus would not be from an ‘‘outside source.’’ A Medicaid or CHIP provider would have a provider agreement with the Medicaid or CHIP agency in order to provide Medicaid or CHIP benefits and services under its state plan. As such, Medicaid and CHIP providers are part of the state’s Medicaid and CHIP program assisting the state agency in carrying out core functions of the state’s Medicaid or CHIP State Plan, providing benefits and services to beneficiaries. Therefore, no additional consent from the beneficiary or personal representative would need to be obtained by the Medicaid or CHIP agency prior to sharing the individual’s information with a Medicaid or CHIP provider. We note that while patient permission is not required under § 431.306(d) for the proposals we discuss here, state, or other laws may require such permission. We do not believe that any of the other requirements of 42 CFR 431.306 are relevant because they cover data release and use in contexts outside of our proposals in this section. However, we welcome comments from state Medicaid agencies and other members of the public on this topic. There are a few notable differences between the requirements for a Patient Access API and our proposals for a Provider Access API. The biggest difference is how and why the end user would access the data. For the Patient Access API, the patient is requesting access to their own data through a health app for their own reference and use. For the Provider Access API proposals, the provider would request and receive access to the patient’s information through their EHR, practice management system, or other technology solution for treatment purposes, including care coordination. Providers would securely access their patients’ data using at least one of these systems through a FHIR API. Providers would not access patient data through their own health app; rather, the data would flow from the payer to the provider’s EHR or practice management VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 system, which would allow them to incorporate the patient data into their records. For example, a provider who is preparing for an upcoming appointment may need more information about the patient than is contained in the patient’s record. Under this proposal, the provider would be able to request the additional data from the patient’s payer, provided the patient has not opted out (as explained in section II.B.3.b. of this proposed rule). The payer would then be required to share the requested data no later than 1 business day after the provider initiates this request. Finally, unlike the Patient Access API, we propose that the Provider Access API would not include provider remittances and enrollee cost-sharing information. Many payers consider costsharing information proprietary, and we believe that information would have limited benefit for treatment or care coordination. We note that our proposals in section II.C. of this proposed rule would exclude provider remittances and enrollee cost-sharing information from the payer to payer data exchange, and we propose the same for the Provider Access API. In the CMS Interoperability and Patient Access final rule CMS required standards for the Patient Access API by cross reference to 45 CFR 170.215 (85 FR 25558). In this proposed rule, we are proposing to amend these cross references, as discussed in section II.F. We also propose, at the CFR citations listed in Table 2, that the Provider Access API would require adherence to the same technical standards, API documentation requirements, and standards for denial or discontinuation of access to the API. Additionally, we note that unlike for the Patient Access API, we are proposing to require the FHIR Bulk Data Access Implementation Guide at 45 CFR 170.215(a)(4). For a complete discussion of these requirements, we refer readers to the CMS Interoperability and Patient Access final rule (85 FR 25526) and to section II.F. of this proposed rule. We acknowledge that it could be helpful for all providers to have access to their patients’ data regardless of contractual or enrollment relationships with a patient’s payer. However, if a provider does not have a provider agreement or is not enrolled (in the case of Medicaid and CHIP FFS programs) with a payer that holds their patient’s data, the payer would not be required to provide patient data to that provider under this proposal, though it may be permissible or even required by other law or regulation. We recognize that this could make it more difficult for an outof-network provider to create a PO 00000 Frm 00020 Fmt 4701 Sfmt 4702 comprehensive care record for a patient. We considered requiring payers to share the data with all providers, regardless of whether the provider is under contract or enrolled with the payer. However, for reasons we explain in this section of this proposed rule, we are not proposing to do so, and are instead seeking comment on various issues surrounding that possible requirement. Though we are not proposing to require it at this time, we encourage payers to share information via API with out-of-network or unenrolled providers who have a verified treatment relationship with the patient, to the extent permitted by law. There could be privacy, security, and program integrity concerns with requiring payers to share patient information with out-of-network providers. For example, because MA organizations, Medicaid FFS programs, CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities must ensure they do not enroll or contract with providers that are on the HHS Office of the Inspector General List of Excluded Individuals/Entities (LEIE), limiting data sharing through the Provider Access API to in-network or enrolled providers can help ensure these data are not shared with providers who have already been determined by the Federal Government to present fraud or other program integrity risks. Since these risks exist, if we were to require payers to share patient information with out-of-network providers, we would also have to require payers to establish safeguards to ensure that an out-ofnetwork provider would be a trustworthy recipient of patient information. This could create significant burden for payers who may need to expend resources towards vetting providers with whom they do not have an existing relationship. The LEIE does not apply to QHPs, but in order to offer coverage through the FFEs, they must comply with certification rules per 45 CFR part 156, which includes requirements to prevent QHP issuers from contracting with providers known to submit fraudulent or wasteful claims. For example, § 156.810(a)(7) specifies that a QHP issuer may be decertified if, based on credible evidence, they have committed or participated in fraudulent or abusive activities, including submission of false or fraudulent data. Section 156.340 provides that a QHP issuer is responsible for its own compliance and the compliance of any of its delegated or downstream entities with all applicable Federal standards related to Exchanges. Per § 156.20, ‘‘delegated entity’’ means any party that enters into an agreement with a QHP issuer to E:\FR\FM\13DEP2.SGM 13DEP2 lotter on DSK11XQN23PROD with PROPOSALS2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules provide administrative services or health care services (for example, contracted providers). Section 156.20 also defines a ‘‘downstream entity’’ as any party that enters into an agreement with a delegated entity or with another downstream entity to provide administrative services or health care services (for example, subcontracted providers). Thus, in order to maintain certified status, QHP issuers generally must have processes in place to avoid contracting with providers that engage in fraudulent practices. QHP issuers that also provide out-of-network coverage can make the determination of whether or not to share data with out-of-network providers using their existing processes. As we consider imposing a requirement to share patient data with out-of-network providers through future rulemaking, we request comment on how payers do so today, the effectiveness of current processes to validate the treatment relationships between patients and providers when a contractual relationship does not exist between the provider and the payer, and what additional program integrity safeguards might be appropriate when other contractual mechanisms are not in place to ensure that patient data are provided only to qualified, trustworthy providers. We are particularly interested in the following questions: How would out-of-network providers request access to their patients’ data and demonstrate that the provider has a treatment relationship with the patient? What processes and verification requirements would we need to require each payer to establish to verify the patient-provider treatment relationship? Should payers consider certain provisions in data use or data exchange agreements? If so, what could those provisions address? What are current best practices for terms of service? What other operational best practices for enabling safe data exchange with out-of-network providers should CMS consider in determining whether to propose a policy requiring this? We emphasize that all data shared and received via this proposed data exchange would still have to be handled in a way that is consistent with all current and applicable laws and regulations, and our proposals are not intended to modify those other laws. Payers and healthcare providers that are covered entities under HIPAA are subject to the HIPAA Rules. Adherence to the HIPAA Rules would ensure that the provider disclosing patient data through the Provider Access API has appropriate security protocols in VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 place.32 These include, but are not limited to, administrative and technical safeguards such as access authorization and audit controls.33 Regardless of whether a provider meets the definition of a covered entity under the HIPAA Rules at 45 CFR 160.103,34 there may also be state laws that require certain privacy and security protections for health information exchange. Additionally, other laws, such as the regulations that focus on confidentiality of patient records associated with substance use disorder at 42 CFR part 2 or state privacy laws, may require the payer to obtain the enrolled individual’s permission to disclose certain PHI. We request comment on any other considerations regarding state privacy or other laws that may be implicated by our proposals. We are proposing to require, at the CFR citations identified in Table 2, that impacted payers share certain patient information with in-network and enrolled providers who have a treatment relationship with the payers’ patients upon request by the provider. Thus, payers would be required by regulation to make such disclosures if there is a treatment relationship with the individual. The HIPAA Privacy Rule permits a covered entity, such as a health plan, to disclose PHI of the enrolled individual to a health care provider without individual authorization for treatment purposes under 45 CFR 164.506(c)(2) or as required by law per 45 CFR 164.512(a)(1). Our proposal would not alter any obligation for HIPAA-covered entities to follow the HIPAA Rules or other applicable law, including, but not limited to, standards regarding the use and disclosure of PHI, administrative, physical, and technical safeguards and other security provisions, and breach notification. The security framework of the proposed API, as required via reference to standards at 45 CFR 170.215, would allow payers to verify the requesting provider’s identity by using the required authorization and authentication protocols. Authorization refers to the process by which the payer would give the provider permission to 32 See 45 CFR part 164, subparts A and C. of Health and Human Services (2022). Security Rule Guidance Material. Retrieved from https://www.hhs.gov/hipaa/for-professionals/ security/guidance/?language=es. 34Under 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. 33 Department PO 00000 Frm 00021 Fmt 4701 Sfmt 4702 76257 access data. The authentication protocols are those that would allow the payer to ensure that the provider that is requesting this access is who they say they are. In addition to using these required protocols, the payer would be required to share the specified data only if it can also attribute the patient to the provider using an attribution process, as discussed in this section of this proposed rule in detail. While FHIR itself does not define security-related functions, used in combination with appropriate security controls (such as authentication and access control), a FHIR API can and should be implemented in compliance with the HIPAA Security Rule for secure data exchange.35 HIPAA also requires the Secretary to adopt standards for specific transactions and establish a process for updating those standards. A HIPAA transaction is an electronic transmission of information from a covered entity to carry out financial or administrative activities related to health care (for example, when a health care provider sends a claim to a health plan to request payment for medical services) for which the Secretary has adopted a standard. Under HIPAA, HHS is required to adopt standards for electronically transmitting certain health care information, including: • Health care claims or equivalent encounter information; • Health care electronic funds transfers and remittance advice; • Health care claim status; • Eligibility for a health plan; • Enrollment and disenrollment in a health plan; • Referrals certification and authorization; • Coordination of benefits; • Health plan premium payments; and • Medicaid pharmacy subrogation (not mandated under HIPAA, but, consistent with section 1173(a)(1)(B) of the Social Security Act, a standard has been adopted for this purpose). The Secretary has adopted a HIPAA transaction standard for transmitting claims or equivalent encounter information. Although our proposals would facilitate sharing claims data from payers to providers, the transmission would not be subject to HIPAA transaction standards because the purpose of the exchange would not be to request or issue a payment.36 We are also not proposing a mechanism to 35 Health Level Seven International (2022). FHIR Security. Retrieved from https://www.hl7.org/Fhir/ security.html. 36 See 45 CFR 162.1101(a) and 162.1601(a). E:\FR\FM\13DEP2.SGM 13DEP2 lotter on DSK11XQN23PROD with PROPOSALS2 76258 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules 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.37 Therefore, a HIPAA transaction standard is not required to be used for our proposals in this section because the Secretary has not adopted a HIPAA standard applicable to communicating claims or encounter information for a purpose other than requesting or issuing payment.38 In summary, we propose that beginning January 1, 2026 (for Medicaid managed care plans and CHIP managed care entities, by the rating period on or after January 1, 2026, and for QHP issuers on the FFEs, for plan years beginning on or after January 1, 2026), impacted payers would be required to implement and maintain a FHIR API to exchange data with providers conformant to the standards discussed in section II.F and at the CFR citations referenced in Table 9. Individual patient data maintained by the payer with a date of service on or after January 1, 2016, must be made available via that API no later than 1 business day after the payer receives a request for data by an in-network provider, (or in the case of a Medicaid or CHIP FFS program, an enrolled Medicaid or CHIP provider). We are proposing these requirements for the Provider Access API for MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities (excluding Non-Emergency Medical Transportation (NEMT) PAHPs, as explained in this section of this proposed rule), and QHP issuers on the FFEs at the CFR sections identified in Table 2. For Medicaid and CHIP managed care, we propose that NEMT PAHPs, as defined at 42 CFR 438.9(a) and 457.1206(a) respectively, would not be subject to the requirement to establish a Provider Access API. MCOs, PIHPs, and non-NEMT PAHPs would be subject to this proposed rule. We believe that the unique nature and limited scope of the services provided by NEMT PAHPs, in that they only cover transportation and not medical care itself, justify their exclusion from the requirements of the Provider Access API proposed at 42 CFR 431.61(a). Specifically, we do not believe that providers have routine need for NEMT data; therefore, requiring NEMT PAHPs to implement and maintain a Provider Access API would be an undue burden. However, we propose to include NEMT PAHPs in the 37 See 38 See 45 CFR 162.1101(b) 45 CFR 162.923(a). VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 scope of most of the other requirements of this proposed rule that apply to all other Medicaid managed care plans listed in Table 2. We request public comment on the proposal for impacted payers to implement and maintain a Provider Access API to provide access to specified patient information. 3. Additional Proposed Requirements for the Provider Access API In general, the proposals discussed in this section regarding the data that payers must make available through the API, as well as the technical specifications, align with the requirements for the Patient Access API finalized in the CMS Interoperability and Patient Access final rule (85 FR 25558) and as proposed in section II.A.2. of this rule. We anticipate that this alignment would provide consistency and help payers build on the work done to comply with the requirements for the Patient Access API, outlined previously. Additional proposed requirements for the Provider Access API regarding attribution, patient opt out process, patient resources, and provider resources are discussed in the sections that follow. a. Attribution Patient attribution is a method of identifying a patient-provider treatment relationship. Attribution is a critical component to ensure that patient health data are shared only with appropriate providers. For the Provider Access API, we are proposing to require that payers develop an attribution process to associate patients with their providers to help ensure that a payer only sends a patient’s data to providers who are requesting that data and who have a treatment relationship with that patient. We are aware that the process of attribution can have many functions for payers, including managing contracts, payments, financial reconciliation, reporting, and continuity of care. In addition, HL7 has developed a member attribution process and workflow in the Da Vinci Member Attribution List FHIR Implementation Guide (IG), which defines various terms and describes a general process by which a payer and provider can coordinate and reconcile their understanding of which patients associated with a particular payerprovider contract.39 This IG does not specify how the payer and provider identify these patients, but it does specify the FHIR resources (that is, data 39 Health Level Seven International (2021, February 8). Da Vinci Member Attribution (ATR) List. Retrieved from https://hl7.org/fhir/us/davinciatr/. PO 00000 Frm 00022 Fmt 4701 Sfmt 4702 elements) which are created as an output of this process. We thus encourage payers to use processes that they may already have to attribute patients to their providers for these other purposes. A payer may implement a process to generate a provider’s current patient roster using claims data, and only permit data exchange through the Provider Access API to providers with whom those patients can be attributed via claims data. For example, payers could accept proof of an upcoming appointment to verify the providerpatient treatment relationship. We know that many providers already verify coverage with the payer before a new patient’s first appointment. If an innetwork provider is seeing a patient for the first time, the provider’s practice can send proof of the upcoming appointment to the payer. Once confirmed, this would then allow the provider to request the patient’s data in preparation for the appointment. We further note that the Argonaut Project has developed an implementation guide specifying how to use FHIR’s Scheduling and Appointment resources to communicate this information.40 We request comments on other examples of how patients can be attributed to the providers from whom they are receiving care, especially for a new patientprovider treatment relationship. We also request comments on whether and how the payer could attribute the patient to the provider at the same time as or through the same data transaction. CMS has implemented an attribution process in our DPC pilot for Medicare beneficiaries, which is the Medicare FFS version of the Provider Access API. The pilot project requires HIPAAcovered entities or their business associates to agree to certain terms of service 41 before data can be sent to them. The current Medicare FFS terms of service require each organization to maintain a list of patients which represents the patient population currently being treated at their facilities.42 To add a new patient, CMS requires providers to attest that they have a treatment-related purpose for adding a patient to their group. This is accomplished by submitting an attestation with every request to add a 40 Health Level Seven International (2022). Argonaut Scheduling IG (Release 1.0.0). Retrieved from https://fhir.org/guides/argonaut/scheduling/. 41 Centers for Medicare & Medicaid Services. (n.d.) Terms of Service. Data at the Point of Care. Retrieved from https://dpc.cms.gov/terms-ofservice. 42 Centers for Medicare & Medicaid Services. (n.d.) Attestation & Attribution. Data at the Point of Care. Retrieved from https://dpc.cms.gov/ docsV1#attestation--attribution. E:\FR\FM\13DEP2.SGM 13DEP2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules lotter on DSK11XQN23PROD with PROPOSALS2 patient to their roster. This pilot will continue to test methodologies to accurately attribute patients to their providers. The information gained from this pilot may assist the industry to develop procedures to identify providers under this proposed requirement. Based on feedback from the industry, the HL7 Da Vinci attribution work group has developed a published Member Attribution List IG.43 The Da Vinci Member Attribution List IG defines the mechanisms (that is, protocols), data structures and value sets to be used for exchanging the Member Attribution List. The Member Attribution List supported by the Da Vinci Member Attribution List IG typically contains: (1) plan/contract information which is the basis for the Member Attribution List, (2) patient information, (3) attributed individual provider information, (4) attributed organization information, and (5) member and subscriber coverage information. DPC has been working with the Da Vinci Member Attribution List team towards compatibility with this IG.44 We also note that the list capability of this IG is informing updates to the Da Vinci Payer Data Exchange (PDex) IG.45 We encourage payers to review the information from the workgroup. We do not wish to be overly prescriptive about how payers could generate an attribution list for providers, but it would be necessary for payers to establish a process to meet these proposed attribution requirements for the Provider Access API. Because the standards for the attribution process continue to evolve, we are not specifying how payers should identify whether a specific patient can be attributed to the requesting provider. Instead, we encourage the community to continue to collaborate on viable approaches. We also recognize that impacted payers may already have multiple arrangements in place with providers to support data exchange, and may even participate in community, local, state, or private health information exchanges (HIEs). In many cases, these HIEs include patient attribution capabilities for which payers may already have a process. Once again, our goal is for 43 Health Level Seven International. (2021, February 8). Da Vinci Member Attribution (ATR) List. Retrieved from https://hl7.org/fhir/us/davinciatr/. 44 Centers for Medicare Medicaid Services. (n.d.) Groups. Data at the Point of Care. Retrieved from https://dpc.cms.gov/docsV2#groups. 45 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:56 Dec 12, 2022 Jkt 259001 payers to avoid having to develop multiple approaches to address attribution, and we encourage collaboration on potential solutions. In summary, we propose that beginning January 1, 2026 (for Medicaid managed care plans and CHIP managed care entities, by the rating period beginning on or after January 1, 2026, and for QHP issuers on the FFEs for plan years beginning on or after January 1, 2026), impacted payers would maintain a process to associate patients with their in-network or enrolled providers to enable payer to provider data exchange via the Provider Access API. We are proposing these attribution requirements for MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans other than NEMT PAHPs, CHIP managed care entities, and QHP issuers on the FFEs at the CFR sections identified in Table 2. We solicit comments on our proposal to require payers to develop processes for verifying the patient-provider treatment relationship, including any processes that may be in place today. b. Opt Out We are proposing that all impacted payers would be required to establish and maintain a process to allow patients or their personal representatives to opt out of having the patients’ data available for providers to access through the Provider Access API. We note that this differs from our Payer-to-Payer API proposal in section II.C.3.c. of this proposed rule, under which all impacted payers would have an opt in process. Similar to the proposed attribution process, as previously discussed, we do not intend to be prescriptive regarding how this opt out process should be implemented, but payers would be required to make this opt out process available, and give all currently enrolled patients or their personal representatives a chance to opt out, before the first date on which patient information is made available via the Provider Access API. Specifically, we are proposing that impacted payers must maintain a process to allow patients or their personal representatives to opt out of data sharing, or if they have already opted out, to opt back in. The process for opting out and opting back in would have to be available before the first date on which patient information is made available via the API and at any time while the patient is enrolled with the payer. We are not proposing to require specific methods for patients to opt out, but anticipate that payers would make that process available by mobile smart PO 00000 Frm 00023 Fmt 4701 Sfmt 4702 76259 device, website, and/or apps. We also anticipate that mail, fax, or telephonic methods may be necessary alternatives for some patients, which payers would have to accommodate if this policy is finalized as proposed. We invite comments on whether we should establish more explicit requirements regarding patient opt out processes. Our proposal would require payers to allow patients to opt out of the Provider Access API data exchange for all providers in that payer’s network. However, we also encourage payers to implement processes that allow more granular controls over the opt out process, so patients can opt out of having data exchanged with individual providers or groups of providers. We are not proposing implementation of such processes as a requirement in this rulemaking, as we are concerned about the potential administrative and technical burden this may place on some payers. However, we request comments about the technical feasibility of implementing an opt out process that would allow patients to make providerspecific opt out decisions, and whether we should consider proposing such a requirement in future rulemaking. We are proposing an opt out approach because opt in models of data sharing, as we discuss in this section of this rule, have been shown to inhibit the utilization and usefulness of data sharing efforts between patients and healthcare providers. We acknowledge that there are positives and negatives to both opt in and opt out policies, and many patients may prefer to control or direct their health information via an opt in process because opt in policies require affirmative permission from a patient before their data can be shared. However, patients who are less technologically savvy or have lower health literacy may be less likely to use the Patient Access API, so having an opt out policy for the Provider Access API would facilitate sharing data directly with the provider, without requiring intervention by the patient. We believe this would promote the positive impacts of data sharing between and among payers, providers, and patients to support care coordination and improved health outcomes, which could lead to greater health equity. In formulating our proposal, we carefully weighed the issues related to both opt in and opt out policies, especially as they relate to making data available to providers. We believe that a proposal defaulting to share data with providers, unless a patient opts out, appropriately balances the benefits of data sharing with the right of patients to control their health information. As we propose in more E:\FR\FM\13DEP2.SGM 13DEP2 76260 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules lotter on DSK11XQN23PROD with PROPOSALS2 detail in this section of this rule, payers would be responsible for providing patient resources to ensure that patients understand the implications of the opt out option. We note that should patients choose not to opt out of data sharing, then the data we propose be made available via the Provider Access API would be available at any time to providers that have been attributed to have a treatment relationship with the patient. However, we believe our proposals, taken together, would give patients ample opportunities to change their data sharing preference as they see fit. Opt in models can create greater administrative burden for smaller healthcare organizations, depending on where the responsibility for obtaining and updating the patient’s data sharing preference is held. We note that smaller hospitals in states with opt in patient permission requirements for HIE are more likely to report regulatory barriers to data exchange compared with those in states with opt out policies, though more technologically advanced hospitals reported no difference.46 A report produced for ONC found that states using an opt out model were quantitatively associated with significantly higher HIE utilization and maturation.47 A 2016 survey found that of the 24 states that give patients a choice regarding participation in the HIE, 16 states have laws describing an opt out procedure, and eight states have enacted an opt in procedure.48 We note that for this report, ‘‘HIE’’ refers exclusively to organizations that facilitate information exchange among healthcare providers, as opposed to the act of exchanging data for other purposes. Within the Department of Veterans Affairs (VA), the Veterans Health Administration, Office of Health Informatics, Veterans Health Information Exchange (VHIE) Program Office, leads interoperability and HIE between VA facilities and private sector 46 Apathy, N.C., & Holmgren, A.J. (2020). Opt-In Consent Policies: Potential Barriers to Hospital Health Information Exchange. The American Journal of Managed Care. 26(1). Retrieved on January 27, 2022, from https://doi.org/10.37765/ ajmc.2020.42148. 47 NORC at the University of Chicago (2016, March). Evaluation of the State HIE Cooperative Agreement Program: Final Report. Retrieved on January 27, 2022, from https://www.healthit.gov/ sites/default/files/reports/finalsummativ ereportmarchl2016.pdf. 48 Schmit et al. (2018). Falling short: how state laws can address health information exchange barriers and enablers. Journal of the American Medical Informatics Association. 25(6). Retrieved on January 27, 2022, from https:// academic.oup.com/jamia/article/25/6/635/ 4587931. VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 providers. Until April 2020, VA operated with an opt in model. Between 2013 and 2017, the VHIE Program Office collected information on the opt in process, and in 2017 reported collecting patient permissions from only 4 percent of the enrolled veterans.49 Consequently, an estimated 90 percent of requests for patient information were rejected by the system for lack of permission. One-third of these were collected online while the other twothirds were paper forms, which indicates a very high level of manual work and administrative burden. Beginning in April 2020, as authorized by section 132 of the John S. McCain III, Daniel K. Akaka, and Samuel R. Johnson VA Maintaining Internal Systems and Strengthening Integrated Outside Networks Act of 2018 (VA MISSION Act of 2018) (Pub. L. 115–182), VA changed its procedures from an opt in to an opt out model for obtaining patient permission to share data.50 51 In the December 2020 CMS Interoperability proposed rule, we proposed an opt in patient permission model for the Provider Access API and requested comments on opt in versus opt out approaches. In response, commenters overwhelmingly supported an opt out model and cited clinical and operational hurdles associated with an opt in approach. Support for an opt out approach came from both provider associations and payers, while patient commenters did not oppose such a proposal. We also believe that an opt out model could address equity issues by ensuring that patients from lower socioeconomic and minority groups, who are more likely to have limited health literacy,52 can benefit from the improved care that the Provider Access API can facilitate. We believe that data sharing as the default option for all patients enhances both personal and organizational health literacy, as they are defined by the Healthy People 2030 49 Donahue et al. (2018). Veterans Health Information Exchange: Successes and Challenges of Nationwide Interoperability. AMIA Annu Symp Proc. Retrieved on January 27, 2022, from https:// www.ncbi.nlm.nih.gov/labs/pmc/articles/ PMC6371252/. 50 U.S. Department of Veteran Affairs (2019, September 30). VA improves information sharing with community care providers. https:// www.va.gov/opa/pressrel/pressrelease. cfm?id=5322. 51 U.S. Department of Veteran Affairs (2020, April 20). VA, DoD implement new capability for bidirectional sharing of health records with community partners. https://www.va.gov/opa/ pressrel/pressrelease.cfm?id=5425. 52 U.S. Department of Health and Human Services. Office of Disease Prevention and Health Promotion (2010). National Action Plan to Improve Health Literacy. Retrieved from https://health.gov/ sites/default/files/2019-09/Health_Literacy_Action_ Plan.pdf. PO 00000 Frm 00024 Fmt 4701 Sfmt 4702 report,53 while protecting patients’ choice to limit data sharing. This proposed opt out option is specific to the data we are proposing payers be required to share via the Provider Access API. As discussed previously, this proposed rule would not alter any other requirements under applicable privacy and security laws and regulations. If there is other authority to share patient information with respect to which a patient may not opt out, such as disclosures required by law, nothing in this proposal would change the payer’s obligation to disclose that information. However, if finalized, we would encourage payers and providers to use the proposed Provider Access API as a technical solution to transmit data between payers and providers beyond the scope of these proposals, provided such disclosure is consistent with all other applicable requirements, such as the HIPAA Rules. We also note that the HIPAA Rules permits health plans to disclose PHI, without an individual’s authorization, to providers via the Provider Access API for certain permitted purposes under the HIPAA Rules, such as, for example, treatment, payment, or health care operations 54 We value the importance of safeguarding the quality and integrity of patient health information. We acknowledge that there may be potential program integrity risks associated with sharing patient data under both an opt in and opt out model. We believe that payers already have program integrity protocols through which they determine if a data exchange has resulted in potential fraud and coordinate investigations of any potential fraud with the relevant programmatic authorities or state laws. We expect that if payers identify any vulnerabilities, they would work to make changes to their operations to address risks that could lead to potential fraud and to limit the impact on patient information. In summary, we propose that beginning January 1, 2026 (for Medicaid managed care plans and CHIP managed care entities, by the rating period beginning on or after January 1, 2026, and for QHP issuers on the FFEs for plan years beginning on or after January 1, 2026), impacted payers must maintain a process for patients or their personal representatives to opt out of and subsequently opt into having the patient’s health information available 53 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. 54 See 45 CFR 164.506(c)(2). E:\FR\FM\13DEP2.SGM 13DEP2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules lotter on DSK11XQN23PROD with PROPOSALS2 and shared via the Provider Access API. We propose that this process must be made available before the first date on which the payer makes patient information available via the Provider Access API, and at any time while the patient is enrolled with the payer. We are proposing this requirement for MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs at the CFR sections identified in Table 2. We request comments on our proposal for a patient opt out framework for the Provider Access API. We additionally request comments on whether patients should be able to exercise more granular controls over which data they permit the payer to share, including permitting the sharing of certain data from only specific timeframes. c. Patient Resources Regarding the Provider Access API To ensure that patients understand the implications of the opt out option for the Provider Access API, we are proposing to require payers to provide information to their patients about the benefits to the patient of the Provider Access API requirements, their opt out rights, and instructions both for opting out of the data exchange and for opting in after previously opting out. Payers would have to provide this information, in non-technical, simple, and easy-tounderstand language, at the time of enrollment and annually. Payers would also be required to make this information available at all times, in an easily accessible location on payers’ public websites. We are not proposing specific text or format of this information, but we request comments on whether there are benefits or burdens to requiring that this information be provided in a specific format or to include specified content. In particular, we are interested in comments on language regarding how patient data could be used and shared through the API. We anticipate payers would include information about patients’ ability to opt out of (and opt back in to) this data sharing in their regular communications, such as annual enrollment information, privacy notices, member handbooks, or newsletters. However, we request comment on the most appropriate and effective communication channel(s) for conveying this information to patients. We also request comment on whether providing this information at the time of enrollment and annually is appropriate, or whether we should require that this information be provided directly to the patient more frequently. VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 We believe it is important to honor patient privacy preferences, and believe it is important for providers to have access to patient information to be able to provide treatment and coordinate care effectively. We also believe that more informed patients are more empowered patients, which we believe leads to increased engagement with their care and ultimately improved health outcomes. Offering patients educational materials about their right to opt out of data sharing via the proposed Provider Access API is thus fundamental to empowering patients with their data. In summary, we propose that beginning January 1, 2026 (for Medicaid managed care plans and CHIP managed care entities, by the rating period beginning on or after January 1, 2026, and for QHP issuers on the FFEs for plan years beginning on or after January 1, 2026), impacted payers must provide information in non-technical, simple, and easy-to-understand language to their patients about the benefits of API data exchange with their providers, their opt out rights, and instructions both for opting out of data exchange and for opting in after previously opting out. We are proposing that these payers must make this information available to currently enrolled patients before the Provider Access API is operational and shares any of their data. We are proposing that thereafter, payers provide this information at enrollment and at least annually. We are also proposing that this information be available in an easily accessible location on payers’ public websites. We are proposing this requirement for annual information for MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs at the CFR sections identified in Table 2. d. Provider Resources Regarding the Provider Access API We are proposing to require payers to develop non-technical and easy-tounderstand educational resources for providers about the Provider Access API. These educational resources should explain how a provider can request patient data using the payer’s Provider Access API. The resources would have to include information about the process for requesting patient data from the payer using the API and how to use the payer’s attribution process to associate patients with the provider. We are proposing that impacted payers provide these resources to providers through the payer’s website and other appropriate provider PO 00000 Frm 00025 Fmt 4701 Sfmt 4702 76261 communications, such as annual contract updates or handbooks. Nontechnical resources would help providers understand how they can use the API to access patient data, thus realizing the expected benefit of the proposed API. Specifically, we propose that beginning January 1, 2026 (for Medicaid managed care plans and CHIP managed care entities, by the rating period beginning on or after January 1, 2026, and for QHP issuers on the FFEs for plan years beginning on or after January 1, 2026), impacted payers would provide educational resources in nontechnical and easy-to-understand language on their websites and through other appropriate mechanisms for communicating with providers, explaining how a provider may make a request to the payer for patient data using the FHIR API. We also propose that those resources must include information about the mechanism for attributing patients to providers. We are proposing this requirement for provider resources for MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP Issuers on the FFEs at the CFR sections identified in Table 2. We request comment on this proposal, including whether CMS should develop guidance regarding, or address in future rulemaking the specific content of these educational materials about the Provider Access API. 4. Extensions, Exemptions, and Exceptions a. Extensions and Exemptions for Medicaid and CHIP FFS Programs Should our proposals regarding the Provider Access API be finalized as proposed, we would strongly encourage state Medicaid and CHIP FFS programs to implement the Provider Access API as soon as possible, due to the many anticipated benefits of the API as discussed in this section. However, we also recognize that state Medicaid and CHIP FFS agencies may face certain circumstances that would not apply to other impacted payers. To address these concerns, we are proposing a process through which states may seek an extension of, and, in specific circumstances, an exemption from, the Provider Access API requirements. We propose the following: (1) Extension At the regulation citations identified in Table 2, we propose to provide state Medicaid FFS and CHIP FFS programs the opportunity to request a one-time E:\FR\FM\13DEP2.SGM 13DEP2 lotter on DSK11XQN23PROD with PROPOSALS2 76262 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules extension of up to 1 year to implement the Provider Access API specified at 42 CFR 431.61(a) and 457.731(a). Some states may be unable to meet the proposed compliance date due to challenges related to securing needed funding for necessary contracting and staff resources in time to develop and implement the API requirements, depending on when the final rule is published in relation to a state’s fiscal year, legislative session, budget process, and related timeline. Some states may need to initiate a public procurement process to secure contractors with the necessary skills to support a state’s implementation of these proposed API policies. The timeline for an openly competed procurement process, together with the time needed to onboard the contractor and develop the API, can be lengthy for states. A state might need to hire new staff with the necessary skillset to implement this policy. The time needed to initiate the public employee hiring process, vet, hire, and onboard the new staff may make meeting the proposed compliance timeline difficult because, generally speaking, public employee hiring processes include stricter guidelines and longer time-tohire periods than other sectors.55 Furthermore, states are currently responding to the effects of the COVID– 19 public health emergency, and their regular operational resources are overextended. Unwinding from the COVID– 19 public health emergency is also expected to require significant IT resources, which could have an impact on future IT work. In all such situations, a state might need more time than other impacted payers to implement the Provider Access API requirements. The 1-year extension that we propose could help mitigate the challenges. We considered delaying implementation of the provisions in this proposed rule an additional year for states, but decided that it would be better to propose to have only those states that needed an extension apply, because states vary in their level of technical expertise and ability to recruit staff and secure contracts. Should the proposal for this API be finalized as proposed, states would be permitted to submit a written application for a one-time, one-year extension as a part of their annual Advance Planning Document (APD) for 55 State hiring processes are comparable with Federal hiring processes. According to the Office of Management and Budget (OMB), the average timeto-hire for Federal employees was 98.3 days in 2018, significantly higher than the private sector average of 23.8 days. See https://www.opm.gov/ news/releases/2020/02/opm-issues-updated-timeto-hire-guidance/. VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 Medicaid Management Information System (MMIS) operations expenditures. The state’s request would have to include the following: (1) a narrative justification describing the specific reasons why the state cannot reasonably satisfy the requirement(s) by the compliance date, and why those reasons result from circumstances that are unique to the agency operating the Medicaid and/or CHIP FFS program (versus other types of impacted payers); (2) a report on completed and ongoing state implementation activities that evidence a good faith effort towards compliance; and (3) a comprehensive plan to meet the Provider Access API requirements no later than 1 year after the compliance date. Under this proposal, CMS would approve an extension if, based on the information provided in the APD, CMS determines that the request adequately establishes a need to delay implementation, and that the state has a comprehensive plan to implement the proposed requirements no later than 1 year after the compliance date. We also solicit comments on whether our proposal would adequately address the unique circumstances that affect states and that might make timely compliance with the proposed API requirement difficult for states. (2) Exemption At the CFR sections identified in Table 2, we propose to permit state Medicaid FFS programs to request an exemption from the Provider Access API requirements when at least 90 percent of the state’s Medicaid beneficiaries are enrolled in Medicaid managed care organizations as defined at 42 CFR 438.2. Likewise, we propose that separate CHIP FFS programs could request an exemption from the Provider Access API requirements if at least 90 percent of the state’s separate CHIP beneficiaries are enrolled in CHIP managed care entities, as defined at 42 CFR 457.10. In this circumstance, the time and resources that the state would need to expend to implement the Provider Access API requirements for a small FFS population may outweigh the benefits of implementing and maintaining the API. Unlike other impacted payers, state Medicaid and CHIP FFS programs do not have a diversity of plans to balance implementation costs for those plans with low enrollment. If there is low enrollment in a state Medicaid or CHIP FFS program, there is no potential for the technology to be leveraged for additional beneficiaries. States, unlike other payers, do not maintain additional lines of business. PO 00000 Frm 00026 Fmt 4701 Sfmt 4702 We acknowledge that the proposed exemption could mean that most beneficiaries enrolled with exempted Medicaid or CHIP FFS programs would not receive the full benefits of having this API available to facilitate health information sharing with providers. To address this, we propose that states that are granted an exemption would be expected to implement an alternative plan to ensure that enrolled providers will have efficient electronic access to the same information through other means, to help ensure that Medicaid or CHIP services are provided with reasonable promptness and in a manner consistent with simplicity of administration and in the best interests of those beneficiaries who are served under the FFS program. We propose that a state could submit a written request for an exemption from the requirements for the Provider Access API as part of its annual APD for MMIS operations expenditures prior to the date by which the state would otherwise need to comply with the requirements (which may be extended by 1 year if the state receives an extension). For Medicaid exemption requests, the state would be required to include documentation that it meets the criteria for the exemption based on enrollment data from the most recent CMS ‘‘Medicaid Managed Care Enrollment and Program Characteristics’’ report. For a CHIP FFS exemption, the state’s request would have to include enrollment data from Section 5 of the most recently accepted state submission to the CHIP Annual Report Template System (CARTS). The state would also be required to include in its request information about an alternative plan to ensure that enrolled providers will have efficient electronic access to the same information through other means while the exemption is in effect. CMS would grant the exemption if the state establishes to CMS’s satisfaction that it meets the criteria for the exemption and has established such an alternative plan. We note that the same considerations for beneficiary opt out, as previously explained, would still be required. Once an exemption has been approved, we propose that the exemption would expire if either of the following two scenarios occurs: (1) based on the 3 previous years of available, finalized Medicaid Transformed Medicaid Statistical Information System (T–MSIS) and/or CHIP CARTS managed care and FFS enrollment data, the State’s managed care enrollment for 2 of the previous 3 years is below 90 percent; or (2) CMS has approved a State plan amendment, E:\FR\FM\13DEP2.SGM 13DEP2 lotter on DSK11XQN23PROD with PROPOSALS2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules waiver, or waiver amendment that would significantly reduce the share of beneficiaries enrolled in managed care and the anticipated shift in enrollment is confirmed by available, finalized Medicaid T–MSIS and/or CHIP CARTS managed care and FFS enrollment data. For the first scenario, CMS recognizes that there may be circumstances where a state’s managed care enrollment may fluctuate slightly below the 90 percent threshold in 1 year, and yet return to above 90 percent the next year. To help reduce the possible burden on exempted states experiencing this type of temporary fluctuation in managed care enrollment, CMS would consider data from the 3 previous years of available, finalized Medicaid T–MSIS and/or CHIP CARTS managed care and FFS enrollment data. We propose that if the state’s managed care enrollment for 2 of the previous 3 years is below 90 percent, the state’s exemption would expire. We propose that a state would be required to provide written notification to CMS that the state no longer qualifies for the Provider Access API exemption when data confirm that there has been a shift from managed care enrollment to FFS enrollment resulting in the State’s managed care enrollment falling below the 90 percent threshold for 2 of the previous 3 years. We propose that the written notification be submitted to CMS within 90 days of the finalization of the annual Medicaid T–MSIS managed care enrollment data and/or the CARTS report for CHIP confirming that there has been the requisite shift from managed care enrollment to FFS enrollment in 2 of the 3 previous years. For the second scenario, we recognize that there may be state plan amendments, waivers, or waiver amendments that would result in a shift from managed care enrollment to FFS enrollment. Additionally, there may be instances where anticipated enrollment shifts may not be fully realized due to other circumstances. We propose that a state would be required to provide written notification to CMS that the state no longer qualifies for the Provider Access API when data confirm that there has been a shift from managed care enrollment to FFS enrollment as anticipated in the state plan amendment or waiver approval. We propose that the written notification be submitted to CMS within 90 days of the finalization of the first annual Medicaid T–MSIS managed care enrollment data and/or the CARTS report for CHIP confirming that there has been the requisite shift from managed care enrollment to FFS enrollment. VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 Regardless of why the exemption expires, if it expires, the state would be required to obtain CMS’s approval of a timeline for compliance with the Provider Access API requirements for the state’s Medicaid FFS and/or CHIP FFS population(s) within two years of the expiration of the exemption. For Medicaid and CHIP managed care, we are not proposing an extension process because we believe that managed care plans are actively working to develop the necessary IT infrastructure to be able to comply with the existing requirements at 42 CFR parts 438 and 457 and because many of them might benefit from efficiencies resulting from the variety of plan types that they offer. Many managed care plans are part of parent organizations that maintain multiple lines of business, including Medicaid managed care plans and plans sold on the Exchanges. As discussed in the CMS Interoperability and Patient Access final rule (85 FR 25607, 25612, and 25620), work done by these organizations can benefit all lines of business and, as such, we do not believe that the proposals in this rule impose undue burden or cannot be achieved by the compliance date. We are soliciting comments on our assumptions regarding the scope of resources and ability of managed care parent organizations to achieve economies of scale when implementing the proposed API. Further, we seek comment on whether an extension process would be warranted for certain managed care plans to provide additional time for the plan to comply with the proposed requirement at 42 CFR 431.61(a) (which cross references at 42 CFR 438.242(b)(7)) for Medicaid managed care plans) and at proposed 42 CFR 457.731(a) (which cross references at 42 CFR 457.1223(d)) for CHIP managed care entities. While we are not proposing such a process for managed care plans and entities and do not believe one is necessary, we are open to evaluating options for possible future rulemaking. Were we to adopt an extension process for these managed care plans and entities, what criteria should a managed care plan or entity meet to qualify for an extension? Should the criteria include enrollment size, plan type, or certain unique characteristics that could hinder their achievement of the proposed requirements by the proposed compliance date? We also seek comment on whether, were we to propose such a process for Medicaid managed care plans or CHIP managed care entities, the entity responsible for evaluating the criteria and exception evaluation process should be the state PO 00000 Frm 00027 Fmt 4701 Sfmt 4702 76263 and whether states could implement the exception evaluation process with available resources. Consistent with the exception process proposed for QHP issuers on the FFEs at 45 CFR 156.222(c), we would expect managed care plans seeking extensions to provide, at a minimum, a narrative justification describing the reasons why a plan or entity cannot reasonably satisfy the requirements by the proposed compliance date, an explanation of the impact of non-compliance upon enrollees, an explanation of the current or proposed means of providing electronic health information to providers, and a comprehensive plan with a timeline to achieve compliance. We request comment on the proposed extension and exemption processes. b. Exception for QHP Issuers For QHP issuers on the FFEs, we propose an exception to the Provider Access API proposal at the regulation citations identified in Table 2. We propose that if an issuer applying for QHP certification to be offered through an FFE believes it cannot satisfy the proposed requirements at 45 CFR 156.222(a) for the Provider Access API, the issuer would have to include as part of its QHP application a narrative justification describing the reasons why the issuer could not reasonably satisfy the requirements for the applicable plan year, the impact of non-compliance upon providers and enrollees, the current or proposed means of providing health information to providers, and solutions and a timeline to achieve compliance with the requirements of this section. We propose that the FFE may grant an exception to the requirements at 45 CFR 156.222(a) for the Provider Access API if it determines that making qualified health plans of such issuer available through such FFE is in the interests of qualified individuals in the state or states in which the FFE operates, and an exception would be warranted to permit the issuer to offer qualified health plans through the FFE. This proposal would be consistent with the exception for QHP issuers on the FFEs we finalized for the Patient Access API in the CMS Interoperability and Patient Access final rule (85 FR 25552). For instance, as noted in that final rule, that exception could apply to small issuers, financially vulnerable issuers, or new entrants to the FFEs that demonstrate that deploying FHIR API technology consistent with the required interoperability standards would pose a significant barrier to the issuer’s ability to provide coverage to patients, and not certifying the issuer’s QHP or QHPs E:\FR\FM\13DEP2.SGM 13DEP2 76264 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules would result in patients having few or no plan options in certain areas. We believe that having a QHP issuer offer QHPs through an FFE generally is in the best interest of patients and would not want patients to have to go without access to QHP coverage because the issuer is unable to implement this API. In summary, we propose to permit certain impacted payers (state Medicaid and CHIP FFS programs and QHP issuers on the FFEs) to apply for an extension, exemption, or exception, as applicable, from implementing the proposed Provider Access API. We propose that these programs would submit and be granted approval for an extension or exemption as a part of applicable established processes. We propose that submission requirements would include certain documentation identified in the regulatory citations in Table 2. 5. Provider Access API in Medicaid and CHIP lotter on DSK11XQN23PROD with PROPOSALS2 a. Federal Funding for State Medicaid and CHIP Expenditures on Implementation of the Provider Access API Should our proposals be finalized as proposed, states operating Medicaid and CHIP programs might be able to access Federal matching funds to support their implementation of the Provider Access API. This proposed API is expected to lead to more efficient administration of the Medicaid and CHIP state plans, consistent with sections 1902(a)(4) and 2101(a) of the Act. We would not consider state expenditures for implementing this proposal to be attributable to any covered Medicaid item or service within the definition of ‘‘medical assistance.’’ Thus, in Medicaid, CMS would not match these expenditures at the state’s regular Federal medical assistance percentage (FMAP). However, were this proposal to be finalized as proposed, Federal financial participation (FFP) under section 1903(a)(7) of the Act, at a rate of 50 percent, for the proper and efficient administration of the Medicaid state plan, might be available for state expenditures related to implementing this proposal for their Medicaid VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 programs. We believe that using the Provider Access API would help the state more efficiently administer its Medicaid program, by ensuring that providers could access data that could improve their ability to render Medicaid services effectively, efficiently, appropriately, and in the best interest of the patient. States’ expenditures to implement these proposed requirements could also be eligible for 90 percent enhanced FFP under section 1903(a)(3)(A)(i) of the Act, if the expenditures can be attributed to the design, development, or installation of mechanized claims processing and information retrieval systems. Additionally, 75 percent enhanced FFP under section 1903(a)(3)(B) of the Act might be available for state expenditures to operate Medicaid mechanized claims processing and information retrieval systems to comply with this proposed requirement. States can request Medicaid enhanced FFP under section 1903(a)(3)(A)(i) or (B) of the Act through the APD process described at 45 CFR part 95, subpart F. States are reminded that 42 CFR 433.112(b)(12) and 433.116(c) in part require that any system for which they are receiving enhanced FFP under section 1903(a)(3)(A)(i) or (B) of the Act align with and incorporate the ONC’s Health Information Technology standards adopted at 45 CFR part 170, subpart B. The Provider Access API would complement this requirement because the API would further interoperability by using standards adopted by ONC at 45 CFR 170.215.56 States are also reminded that 42 CFR 433.112(b)(10) and 433.116(c) explicitly support exposed APIs, meaning the API’s functions are visible to others to enable the creation of a software program or application, as a condition of receiving enhanced FFP under section 1903(a)(3)(A)(i) or (B) of the Act. 56 Centers for Medicare & 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. PO 00000 Frm 00028 Fmt 4701 Sfmt 4702 Similarly, 42 CFR 433.112(b)(13) and 433.116(c) require states to promote sharing, leverage and re-use of Medicaid technologies and systems as a condition of receiving enhanced FFP under section 1903(a)(3)(A)(i) or (B) of the Act. CMS interprets that requirement to apply to technical documentation associated with a technology or system, such as technical documentation for connecting to a state’s APIs. Making the needed technical documentation publicly available so that systems that need to can connect to the APIs proposed in this rule would be required as part of the technical requirements at 42 CFR 431.60(d) for all proposed APIs in this rule, including the Provider Access API. Separately, for state CHIP agencies, section 2105(c)(2)(A) of the Act and 42 CFR 457.618, limiting administrative costs to no more than 10 percent of a state’s total computable expenditures for a fiscal year, would apply to administrative claims for developing the APIs proposed in this rule. We note that the temporary Medicaid FMAP increase available under section 6008 of the Families First Coronavirus Response Act (Pub. L. 116–127) does not apply to administrative expenditures. b. Medicaid Expansion CHIP Program Most states have Medicaid Expansion CHIP programs, in which a state receives Federal funding to expand Medicaid eligibility to optional targeted low-income children that meet the requirements of section 2103 of the Social Security Act. We are proposing at 42 CFR 457.700(c) that for states with Medicaid expansion CHIP programs, the proposals in this rule for Medicaid would apply to those programs rather than our proposals for separate CHIP programs. Functionally, our proposals are the same; however, for clarity, we are making explicit that the Medicaid requirements at §§ 431.60, 431.61, and 431.80 would apply to those programs rather than the separate CHIP requirements at §§ 457.730, 457.731, and 457.732. BILLING CODE 4120–01–P E:\FR\FM\13DEP2.SGM 13DEP2 lotter on DSK11XQN23PROD with PROPOSALS2 BILLING CODE 4120–01–C Jkt 259001 Frm 00029 Fmt 4701 Sfmt 4702 I Provider Access 42CFR II.B.2. API for Individual Patient Infonnation I Applicability of Provider Access APitoNEMT PAHPs I Attribution II.B.3.a. 13DEP2 42CFR 431.6l(a)(l) Through proposed cross reference to 42 CFR 431.61 at 42 CFR 438.242(b )(7) 42CFR 457.73 l(a)(l) Through existing cross reference to 42 CFR 438.242 at 42 CFR 457.1233(d) 145 CFR 156.222(a)(l) NIA NIA 42 CFR 438.9(b)(7) NIA 42CFR 457.1206(b)(6) I NIA 42CFR 457.73 l(a)(2) Through existing cross reference to 42 CFR 438.242 at 42 CFR 457.1233(d) Through existing cross reference to 42 CFR 438.242 at 42 CFR 457.1233(d Through existing cross reference to 42 CFR 438.242 at 42 CFR 457.1233(d Through existing cross reference to 42 CFR 438.242 at 42 CFR 457.1233(d 145 CFR 156.222(a)(2) I 42CFR II.B.3.b. II.B.3.c. I OptOut I Patient Resources Regarding API I Provider Resources Regarding API II.B.4.a. II.B.4.a. II.B.4.b. I Extension for Medicaid and CHIPFFS I Exemption for Medicaid and CHIPFFS I Exceptions for HP Issuers I 42 CFR 142 CFR 431.6l(a)(2) I cross Through proposed reference to 42 I CFR 431.61 at 42 CFR 438.242(b )(7) Through proposed cross reference to 42 CFR 431.61 at 42 CFR 438.242(b )(7) Through proposed cross reference to 42 CFR 431.61 at 42 CFR 438.242rh )(7) Through proposed cross reference to 42 CFR 431.61 at 42 CFR 438.242(bl(7) 42CFR 457.73 l(a)(3)(i) 145 CFR 156.222(a)(3)(i) 422.12l(a)(3)(i) 142 CFR 43 l.6l(a)(3)(i) 42CFR 422.12l(a)(3)(ii) 42CFR 43 l.6l(a)(3)(ii) 42CFR 422.12l(a)(4) 42CFR 431.6l(a)(4) NIA 42CFR 431.6l(c)(l) NIA 42CFR 457.73 l(c)(l) NIA I NIA NIA 42CFR 431.6l(c)(2) NIA 42CFR 457.73l(c)(2) I NIA I NIA NIA NIA NIA NIA I NIA 145 CFR 156.222cc 42CFR 457.73 l(a)(J)(ii) 42CFR 457.73l(a)(4) 145 CFR 156.222(a)(3)(ii) 145 CFR 156.222(a)(4) 76265 EP13DE22.001</GPH> 422.12l(a)(l) 422.12l(a)(2) II.B.3.d. 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 E:\FR\FM\13DEP2.SGM a. MA Organizations For MA organizations, we are proposing these Provider Access API requirements under our authority at PO 00000 TT.B.2. Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules 18:56 Dec 12, 2022 6. Statutory Authorities for Provider Access API Proposals VerDate Sep<11>2014 TABLE 2: PROVIDER ACCESS API PROPOSED POLICIES lotter on DSK11XQN23PROD with PROPOSALS2 76266 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules section 1852(d)(1)(A)) of the Act to adopt new terms and conditions for MA organizations that the Secretary finds ‘‘necessary and appropriate.’’ Section 1852(d)(1)(A) of the Act requires MA organizations to, as a condition of using a network of providers, make covered benefits available and accessible to enrollees in a manner that assures continuity in the provision of benefits. As noted in this section of this proposed rule, these regulations implement this requirement. The Secretary also has authority under section 1857(e)(1) of the Act to add new contract terms, including additional standards and requirements, for MA organizations the Secretary finds necessary and appropriate and that are not inconsistent with Part C of the Medicare statute. In implementing section 1852(d)(1)(A) of the Act, we previously adopted a regulation, at 42 CFR 422.112(b), that requires MA organizations to ensure the continuity of care and integration of services through arrangements with providers that include procedures to ensure that the MA organization and the contracted providers have access to the information necessary for effective and continuous patient care. This proposal aligns with, and provides a means for, MA organizations to comply with that existing regulatory requirement. Our proposal for MA organizations to implement and maintain a Provider Access API would facilitate exchanges of information about enrollees that are necessary for effective and continuous patient care, which is consistent with the requirement at section 1852(d)(1)(A) of the Act for continuing the provision of benefits. The Provider Access API proposal, which would support sharing claims, all data classes and data elements included in a content standard adopted at 45 CFR 170.213, as well as prior authorization decisions (sections II.B.2. and II.B.3. of this proposed rule) and a requirement for MA organizations to offer provider educational resources (section II.B.3.d. of this proposed rule), would give providers tools to support continuity of care and care coordination for enrollees. Were a provider able, through a Provider Access API established by an MA organization, to gather information for their patient, the provider could make more informed decisions and coordinate care more effectively. In addition, if a patient moves from one provider to another, the new provider would be able to ensure continuity of care if they are able to access relevant health information for the patient from the MA organization in an efficient and timely way. A Provider VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 Access API could support this; thus, the proposal would carry out and be consistent with the Part C statute. This proposal would complement and align with MA organization obligations at 42 CFR 422.112(b)(4) by providing a means, through a Provider Access API, for the exchange of information that could support effective and continuous patient care. This API would help MA organizations share information with providers in an effective and efficient way that would help them fulfill program requirements. A Provider Access API could increase the efficiency and simplicity of administration. It could give providers access to a significant amount of their patients’ information with limited effort, and it could reduce the amount of time needed during provider visits to establish a patient’s prior history, which could introduce efficiencies and improve care. These proposals would also be expected to allow for better access to other providers’ prior authorization decisions, which could give a provider a more holistic view of a patient’s care and reduce the likelihood of ordering duplicate or misaligned services. Ultimately, we anticipate that sharing patient information would ensure that providers receive patient information in a timely manner and could lead to more appropriate service utilization and higher patient satisfaction. In addition, the proposal that MA organizations make available educational resources and information would increase access to and understanding of this Provider Access API, leading to more efficient use and integration of the API as a means for providers to access patient information. Thus, the proposed Provider Access API would be necessary and appropriate for the MA program and consistent with existing requirements. b. Medicaid and CHIP Our proposed requirements in this section for Medicaid managed care plans and Medicaid FFS programs fall generally under the authority in the following provisions of the statute: • Section 1902(a)(4) of the Act, which requires that a state Medicaid plan provide such methods of administration as are found by the Secretary to be necessary for the proper and efficient operation of the state Medicaid plan; • Section 1902(a)(8) of the Act, which requires states to ensure that Medicaid services are furnished with reasonable promptness to all eligible individuals; and • Section 1902(a)(19) of the Act, which requires states to ensure that care and services are provided in a manner PO 00000 Frm 00030 Fmt 4701 Sfmt 4702 consistent with simplicity of administration and the best interests of the recipients. These proposals are authorized under these provisions of the Act because they would help ensure that Medicaid providers can access data that could improve their ability to render Medicaid services effectively, efficiently, and appropriately. The proposals would be expected to help states fulfill their obligations to operate their state plans efficiently and to ensure that Medicaid services are furnished with reasonable promptness and in a manner consistent with the best interest of the recipients. In addition, section 1902(a)(7) of the Act requires that states must provide safeguards that restrict the use or disclosure of information concerning Medicaid applicants and beneficiaries to uses or disclosures of information that are directly connected with the administration of the Medicaid state plan. The implementing regulations for this section of the Act list purposes that CMS has determined are directly connected to Medicaid state plan administration at 42 CFR 431.302 and provide safeguards states must apply to uses and disclosures of beneficiary data at 42 CFR 431.306. CHIP programs are subject to the same requirements through a cross reference at 42 CFR 457.1110(b). Our proposal to require that the data described in this section be shared via the Provider Access API would be consistent with the requirement that states may share these data only for purposes directly connected to the administration of the Medicaid state plan, since this data sharing would be related to providing services for beneficiaries, a purpose listed in § 431.302(c). As mentioned previously, a provider could better manage a patient’s total care when they have access to more of that patient’s data because the data would provide a more in-depth medical history, enable more informed decision making, and potentially prevent the provision or ordering of duplicative services. More details about how the proposals could be implemented in a manner consistent with state Medicaid and CHIP agencies’ requirements under 42 CFR part 431, subpart F, are discussed in section II.B.2. Proposing to require states to implement a Provider Access API to share data with enrolled Medicaid providers about certain claims, encounter, and clinical data, including data about prior authorization decisions, for a specific individual beneficiary, could improve states’ ability to ensure that care and services are provided in a manner consistent with simplicity of E:\FR\FM\13DEP2.SGM 13DEP2 lotter on DSK11XQN23PROD with PROPOSALS2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules administration, and to cover services more efficiently. This API would enable Medicaid providers to access beneficiary utilization and authorization information from the state or managed care plan(s) prior to an appointment or at the time of care, and that, in turn, would enable the provider to spend more time on direct care. The proposal would support efficient and prompt delivery of care as well, which would be in beneficiaries’ best interests. These proposals would also be expected to give providers better access to prior authorization decisions for care provided by other enrolled Medicaid providers, which would give a provider a more holistic view of a patient’s care and reduce the likelihood of ordering duplicate or misaligned services. This could also facilitate easier and more informed decision-making by the provider and would therefore support efficient coverage decisions in the best interest of patients. The proposed Provider Access API, if finalized as proposed, would be expected to make available a more complete picture of the patient to the provider at the point of care, which could improve the quality and efficiency of a patient visit, thus enabling the provider to treat more patients. These outcome and process efficiencies could help states fulfill their obligations to ensure prompt access to services in a manner consistent with the best interest of beneficiaries, consistent with sections 1902(a)(8) and (19) of the Act, and the efficiencies created for providers might help the state administer its Medicaid program more efficiently, consistent with section 1902(a)(4) of the Act. These analyses apply similarly to managed care and FFS programs and delivery systems, so we are exercising our authority to adopt virtually identical regulatory requirements for a Provider Access API for both Medicaid FFS programs and Medicaid managed care plans. For CHIP, we are proposing these requirements under the authority in section 2101(a) of the Act, which states that the purpose of Title XXI of the Act is to provide funds to states to provide child health assistance to uninsured, low-income children in an effective and efficient manner that is coordinated with other sources of health benefits coverage. We believe this proposed policy could strengthen states’ abilities to fulfill these statutory obligations under Title XXI of the Act in a way that would recognize and accommodate the use of electronic information exchange in the healthcare industry today and would facilitate a significant VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 improvement in the delivery of quality healthcare to CHIP beneficiaries. When providers have access to patient utilization and authorization information from payers or other health IT systems, they can provide higher quality care. Improving the quality of care aligns with section 2101(a) of the Act, which requires states to provide CHIP services in an effective and efficient manner. The more information a provider has to make informed decisions about a patient’s care, the more likely it is that patients will receive care that best meets their needs. Additionally, providers could be more effective and efficient in their delivery of CHIP services by having direct access to patient utilization and authorization information. If a provider has information about a patient prior to or at the point of care, the provider will be able to spend more time focused on the patient, rather than on their need to collect information. In addition, the information providers do collect would not be based solely on patient recall. This could save time, improve the quality of care, and increase the total amount of direct care provided to CHIP beneficiaries. When data are standardized, and able to be incorporated directly into the provider’s EHR or practice management system, they can be leveraged as needed at the point of care by the provider and also can be used to support coordination across providers and payers. This is inherently more efficient, and ultimately, more cost-effective, as the information does not have to be regularly repackaged and reformatted to be shared or used in a valuable way. As such, the Provider Access API proposals also align with section 2101(a) of the Act in that these proposals could improve coordination between CHIP and other health coverage. For these reasons, we believe this proposal is in the best interest of the beneficiaries and within our long-established statutory authorities. Finally, the safeguards for applicant and beneficiary information at subpart F of 42 CFR part 431 are also applicable to CHIP through a cross-reference at 42 CFR 457.1110(b). As discussed above for Medicaid, giving CHIP providers access to attributed beneficiary data through the Provider Access API is related to providing services to beneficiaries, which is described at 42 CFR 431.302(c) as a purpose directly related to state plan administration. We remind states that when they share beneficiary information through the Provider Access API, they must comply with the privacy protections at 42 CFR 457.1110 PO 00000 Frm 00031 Fmt 4701 Sfmt 4702 76267 and the release of information provisions at 42 CFR 431.306. c. QHP Issuers on the FFEs For QHP issuers on the FFEs, we are proposing these new requirements under our authority in section 1311(e)(1)(B) of the Affordable Care Act, which affords the Exchanges the discretion to certify QHPs if the Exchange determines that making available such health plans through the Exchange is in the interests of qualified individuals in the state in which the Exchange operates. We believe the benefits would outweigh any additional burdens this might impose on issuers. By using the proposed technologies, patients could experience improved health, payers could see reduced costs of care, and providers could see better compliance with care regimens. We also do not believe that premiums would significantly increase because some of the infrastructure necessary to implement the proposed technology has been completed to comply with the May 2020 Interoperability Rule. Furthermore, QHP issuers on the FFEs might combine investments and staff resources from other programs for implementation efforts, avoiding the need to increase premiums. We believe that certifying only health plans that make enrollees’ health information available to their providers via the Provider Access API is in the interests of enrollees. Giving providers access to their patients’ information supplied by QHP issuers on the FFEs would ensure that providers are better positioned to provide enrollees with seamless and coordinated care and help ensure that QHP enrollees on the FFEs are not subject to duplicate testing and procedures, and delays in care and diagnosis. Access to the patient’s more complete medical information could also maximize the efficiency of an enrollee’s office visits. We encourage SBEs, including SBE–FPs, to consider whether a similar requirement should be applicable to QHP issuers participating in their Exchanges. C. Payer to Payer Data Exchange on FHIR 1. Background Research shows that the more complete a patient’s record is and the more data that can be available to healthcare providers at the point of care, the better patient outcomes can be.57 57 Office of the National Coordinator for Health Information Technology (2019, June 4). Improved Diagnostics & Patient Outcomes. Retrieved from E:\FR\FM\13DEP2.SGM Continued 13DEP2 lotter on DSK11XQN23PROD with PROPOSALS2 76268 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules More data lead to better-coordinated care and more informed decisionmaking. Healthcare payers are uniquely positioned to collect and aggregate patient data because they typically maintain a relationship with individual patients over a period of time. Whereas patients may have several providers who manage their care, they generally maintain a relationship with only one or two concurrent payers in a 1-year period and often for multiple years. However, when a patient moves from one payer to another, patients and payers can lose access to that valuable data. Data exchange among payers, specifically, sending patient data from a patient’s previous payer to their new payer, is a powerful way to ensure that data follow patients through the healthcare system. Electronic data exchange between payers would support payer operations and a patient’s coverage transition to a new payer efficiently and accurately, and could support care coordination and continuity of care. Sharing healthcare data between payers also helps patients build a longitudinal record that can follow them across payers. In the CMS Interoperability and Patient Access final rule (85 FR 25565), we highlighted numerous benefits for payers to maintain a longitudinal record (that is, long-term) of their current patients’ health information. If payers are at the center of the exchange, they can make information available to patients and their providers and can help ensure that a patient’s information follows them as they move from provider to provider and payer to payer. In the final rule we finalized a requirement that certain impacted payers would be required to exchange, at a minimum, all data classes and data elements included in a content standard adopted at 45 CFR 170.213 (85 FR 25568) at a patient’s request. This policy applied to MA organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs. It did not include Medicaid or CHIP FFS programs. We did not specify an API standard for payer to payer data exchange in that final rule, because, at the time, there were a variety of transmission solutions that payers could employ to meet this requirement. We encouraged impacted payers to consider using a FHIR API consistent with the larger goal of leveraging FHIR APIs to support a number of interoperability use cases for improving patient, provider, and payer access to healthcare data to reduce burden, increase efficiency, and https://www.healthit.gov/topic/health-it-basics/ improved-diagnostics-patient-outcomes. VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 ultimately facilitate better patient care. In addition, we signaled our intent to consider a future requirement to use FHIR APIs for payer to payer data exchange, envisioning the increasing implementation of FHIR APIs for different purposes within the industry. Since the CMS Interoperability and Patient Access final rule was finalized in May 2020, multiple impacted payers have expressed to CMS that the lack of technical specifications for the payer to payer data exchange requirement in the final rule (85 FR 25565) is creating challenges for implementation. This lack of a standard may lead to differences in implementation across the industry, poor data quality, operational challenges, and increased administrative burden. Differences in implementation approaches may create gaps in patient health information that conflict with the intended goal of interoperable payer to payer data exchange. In the December 2020 CMS Interoperability proposed rule, we attempted to address these challenges by proposing the use of a FHIR API for the payer to payer data exchange. We also proposed to extend the Payer-toPayer API policies to Medicaid and CHIP FFS programs. As stated in section I.A. of this proposed rule, we are withdrawing the December 2020 CMS Interoperability proposed rule and issuing this new proposed rule that incorporates the feedback we received from stakeholders, including this proposal to address the payer to payer data exchange. We refer readers to the discussion in section I.A. outlining the overarching differences between the two proposed rules. Moreover, in order to respond to stakeholder concerns about implementing the payer to payer data exchange requirement finalized in the CMS Interoperability and Patient Access final rule, and noting that we did not finalize the proposals outlined in the December 2020 CMS Interoperability proposed rule, we published a Federal Register notification (86 FR 70412) 58 announcing that we would exercise enforcement discretion and not enforce the payer to payer data exchange requirements until future rulemaking was finalized. We intend this rulemaking to address those concerns 58 Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Interoperability and Patient Access for Medicare Advantage Organizations 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, 86 FR 70412 (December 10, 2021). PO 00000 Frm 00032 Fmt 4701 Sfmt 4702 about the payer to payer data exchange policy finalized in the CMS Interoperability and Patient Access final rule and subject to the enforcement discretion. In this proposed rule, we are again proposing to require impacted payers (MA organizations, state Medicaid FFS programs, state CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs) to implement and maintain a payer to payer data exchange using a FHIR API, but with changes from our proposals in the December 2020 CMS Interoperability proposed rule. We are again proposing that the data exchange take place via a FHIR API at the start of coverage, but we are now taking a different approach to the standards required for the API, as further described in section II.F. of this proposed rule. We are again proposing to establish a patient opt in policy for this data exchange for all impacted payers, for the reasons explained below. Furthermore, we propose to extend the compliance deadline for the Payer-toPayer API to January 1, 2026. We note that our payer to payer data exchange proposals discussed below involve transactions and cooperation between payers, which in many cases may include payers that would not be impacted by our proposals. We emphasize that under our proposals, each impacted payer would be responsible only for its own side of the transaction. For instance, if our proposal would require an impacted payer to request patient data from another payer, it would have to do so regardless of whether the other payer is an impacted payer (a status that may or may not be evident to the requesting payer). Similarly, if an impacted payer receives a request for patient data that meets all the proposed requirements, the impacted payer would be required to share those data, regardless of whether the requesting payer is an impacted payer (which, again, may or may not be evident). In this way, non-impacted payers who implement the Payer-toPayer API and their patients would benefit from the data exchange proposed in this proposed rule. In this section, we talk about data exchange between payers. When we refer to a patient’s new payer, we are referring to the payer that a patient is newly enrolled with and the party responsible for requesting and receiving the patient’s data. When we refer to the patient’s concurrent payers, we are referring to the parties (two or more) that are providing coverage at the same time and responsible for exchanging data with each other as discussed E:\FR\FM\13DEP2.SGM 13DEP2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules lotter on DSK11XQN23PROD with PROPOSALS2 further below. When we refer to the patient’s previous payer, we are referring to the payer that a patient has previously had coverage with and thus the payer responsible for sending the data to the new payer. However, as discussed further in section II.C.4.b., Medicaid and CHIP FFS state agencies as well as Medicaid and CHIP managed care plans within the same state are excluded from the definition of ‘‘previous payer’’ in relation to data exchange with each other. We are exploring steps for Medicare FFS to participate in Payer-to-Payer API data exchange with all interested payers and we would encourage other payers that would not be impacted by these proposals, if finalized, to do the same. If our proposals are finalized, we intend to implement the Payer-to-Payer API capability for Medicare FFS in conformance with the requirements for impacted payers, as feasible. We seek comment on whether this could be implemented as proposed for the Medicare FFS program, how we could apply each of these proposals below and if there would be any differences for implementing the Payer-to-Payer API in the Medicare FFS program as a Federal payer. We strongly encourage all payers that would not be subject to the proposed requirements to consider the value of implementing a Payer-to-Payer API as described in this proposal, so that all patients, providers, and payers in the U.S. healthcare system may ultimately experience the benefits of such data exchange. 2. Proposal To Rescind the CMS Interoperability and Patient Access Final Rule Payer to Payer Data Exchange Policy CMS strongly believes that data exchange among payers is a powerful way to help patients accumulate their data over time and to improve information sharing that would allow patients and providers to have more complete access to health information, which can help to promote better patient care. However, given the concerns raised by stakeholders regarding the lack of technical specification in our final policy, we are now proposing to rescind the payer to payer data exchange policy previously finalized in the CMS Interoperability and Patient Access rule (85 FR 25568) at 42 CFR 422.119(f)(1) and 438.62(b)(1)(vi) and (vii) and 45 CFR 156.221(f)(1). We are doing so to prevent industry from developing multiple systems, and to help payers avoid the costs of developing non-standardized, non-API systems, and the challenges associated with those systems. In the VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 following sections, we are proposing a new policy that would, instead, require impacted payers to implement and maintain a Payer-to-Payer API using the FHIR standard, as described later in this section. We anticipate that the proposed use of FHIR APIs would ensure greater uniformity in implementation and ultimately lead to payers having more complete information available to share with patients and providers. 3. Payer to Payer Data Exchange on FHIR a. Payer-to-Payer API Technical Standards In the CMS Interoperability and Patient Access final rule we finalized a requirement to implement, maintain, and use API technology conformant with 45 CFR 170.215 for the Patient Access API. However we did not require the use of an API or related standards for payer to payer data exchange. We are now building on the technical standards, base content and vocabulary standards used for the Patient Access API, as finalized in the CMS Interoperability and Patient Access final rule (85 FR 25558), for this proposed Payer-to-Payer API. The degree of overlap between the requirements for the Patient Access API (discussed in section II.A.2. of this proposed rule) and the Provider Access API (discussed in section II.B.2. of this proposed rule) should ease the API development and implementation process for payers. The Patient Access API would provide the foundation necessary to share all data classes and data elements included in a standard adopted at 45 CFR 170.213, adjudicated claims, and encounter data as well as the patient’s prior authorization requests and decisions. Because the same data classes and elements included in the standards in 45 CFR 170.213 and adjudicated claims, and encounter data are already required for the Patient Access API, payers have already formatted these data elements and prepared their systems to share these standardized data via a FHIR API. As a result, we believe payers have already devoted the development resources to stand up a FHIR API infrastructure when they implemented the Patient Access API, which could be adapted for expanded interoperability use cases. We are also proposing to require the use of certain IGs adopted under 45 CFR 170.215 that are applicable to the Payerto-Payer API. This includes OpenID Connect Core at 45 CFR 170.215(b) for authorization and authentication. We are proposing that the Payer-to-Payer API must include the authorization and PO 00000 Frm 00033 Fmt 4701 Sfmt 4702 76269 authentication protocols at 45 CFR 170.215(b) to authenticate the identity of the payer requesting access to data through the API. This would create a standardized and trusted method for payers to determine whether the payer who is requesting the data is whom they say they are. We refer readers to section II.F. of this proposed rule for further discussion of the required and recommended standards for the Payerto-Payer API. We note that when exchanging data with another payer through the Payerto-Payer API, payers may find it more efficient to share data for multiple patients at a time. It is likely that impacted payers with a fixed enrollment period would have many patients’ data to share at one time, especially if other payers share that enrollment period (such as QHPs offered on an FFE). In such a situation, it could require significant resources and time for payers to send each patient’s data individually through an API. The FHIR Bulk Data Access (Flat FHIR) IG for exchanging multiple patients’ data at the same time has been adopted by ONC at 45 CFR 170.215(a)(4), which is discussed further in section II.F. of this proposed rule and is a proposed required standard for the Payer-to-Payer API. In summary, we propose that, beginning January 1, 2026 (for Medicaid managed care plans and CHIP managed care entities, by the rating period beginning on or after January 1, 2026, and for QHP issuers on the FFEs, for plan years beginning on or after January 1, 2026), impacted payers must implement and maintain a Payer-toPayer API that is compliant with the same technical standards, documentation requirements, and denial or discontinuation policies as our Patient Access API requirements. In addition, we propose that the API must be conformant with the standards at 45 CFR 170.215, including support for FHIR Bulk Data Access and OpenID Connect Core as further discussed in section II.F. We are proposing these technical specification requirements for the Payerto-Payer API for MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs at the CFR sections identified in Table 3. We request comments on these proposals. b. Payer-to-Payer API Data Content Requirements We are proposing to require that impacted payers implement and maintain a FHIR Payer-to-Payer API to E:\FR\FM\13DEP2.SGM 13DEP2 lotter on DSK11XQN23PROD with PROPOSALS2 76270 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules exchange all data classes and data elements included in a content standard adopted at 45 CFR 170.213, claims and encounter data (excluding provider remittances and enrollee cost-sharing information), and prior authorization requests and decisions that the payer maintains with a date of service on or after January 1, 2016. The data we are proposing to include in the API would be consistent with the proposals discussed in sections II.A. (Patient Access API) and II.B. (Provider Access API) of this proposed rule, which would require impacted payers to share the same types of data with patients and providers via those respective FHIR APIs. We also note that much of the data included in this proposal, except for provider remittances, enrollee cost-sharing information and prior authorizations, as discussed below, would also be consistent with the requirements for the Patient Access API finalized in the CMS Interoperability and Patient Access final rule (85 FR 25559). That final rule requires that impacted payers make data available from a date of service of January 1, 2016. Therefore, payers should already be maintaining and making available patient data back to that date. Using the same data content standards across the APIs in this proposed rule would add efficiencies for payers and maximize the value of the work being done to implement APIs, reducing the overall burden for all impacted payers. We are proposing to exclude provider remittances and enrollee cost-sharing information from Payer-to-Payer API data exchange because that information is often considered proprietary by payers. Therefore, we are not proposing to require payers to exchange those data with each other. While there could be value to patients in having provider remittances and enrollee cost-sharing information available via the Patient Access API, we believe that sharing provider remittances and enrollee costsharing information between payers would have only a limited beneficial impact on care. We believe that sharing claims and encounter information without the cost details would complement the data classes and data elements included in a content standard adopted at 45 CFR 170.213, by providing more information about the patient’s care history to support care coordination and efficient operation. When we refer to prior authorizations in the context of payer to payer data exchange, we propose that this would include any pending, active, denied, and expired prior authorization requests or decisions. We refer readers to section VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 II.A. of this proposed rule where prior authorization data content for the APIs in this proposed rule is discussed in further detail. Our proposals in this section for the inclusion of prior authorization data mirror our proposals for prior authorization data in the Patient Access API and Provider Access API. We believe that it would be valuable for payers to make information about prior authorization requests and decisions available via the Payer-toPayer API, particularly when a patient enrolls with a new payer. Prior authorization is a significant focus of this proposed rule, and information about these requests and decisions could be beneficial to patients, providers, and payers. As noted throughout, this proposed rule does not apply to any prior authorization processes or standards related to any drugs. Currently, when a patient changes payers, information about prior authorization decisions the previous payer made or was in the process of making, about the patient’s ongoing care is inconsistently sent to the new payer. While some payers will make this information available to the new payer upon request, most new payers do not request such information. Instead, most payers with a newly enrolled patient require the treating provider to request a new prior authorization, even for items or services for which a patient had a valid and current prior authorization approval under the previous payer. When this happens, the burden of repeating the prior authorization process with the new payer falls on the provider and patient, which can impede the continuity of care or delay patient care, impacting patient outcomes and complicating care coordination. In addition, it adds burden for payers, who must expend time and effort to review a potentially unnecessary and duplicative prior authorization request. We discuss prior authorization and our proposals regarding prior authorization processes in more depth in section II.D. of this proposed rule. As part of this Payer-to-Payer API proposal, consistent with the proposals for the Patient Access API in section II.A. and the Provider Access API in section II.B. of this proposed rule, we propose to add prior authorization requests and decisions and related administrative and clinical documentation to the set of data that impacted payers must make available via the Payer-to-Payer API. We propose that this documentation would include the status of the prior authorization, the date the prior authorization was approved or denied, the date or circumstance under which PO 00000 Frm 00034 Fmt 4701 Sfmt 4702 the authorization ends, the items and services approved, and the quantity used to date. Furthermore, as outlined in section II.D., we propose that the specific reason why the request was denied should also be included in the case of a prior authorization denial. We propose that impacted payers would be required to make information about prior authorizations available via the Payer-to-Payer API for the duration that the authorization is active and, for at least 1 year after the prior authorization’s last status change. We note that we are formulating our proposal for at least 1 year after any status change, but this provision would be particularly relevant to denied and expired prior authorizations, to ensure that they would be available for at least a year after expiring or being denied. While CMS is not proposing at this time to require payers to review, consider, or honor the active prior authorization decision of a patient’s former payer, CMS believes payers may gain efficiencies by doing so. In this section, we seek comment on some of the considerations around sharing prior authorization data between payers. Under our payer to payer data exchange proposal, prior authorization information would be included as part of the patient’s longitudinal record received from the previous payer. The prior authorization information would thus be available for consideration as part of the patient’s historical record. Should a payer consult this information, even to make a prior authorization decision under its own rules, it could, over time, reduce payer, provider, and patient burden, and possibly healthcare costs. We understand that there is potential for a gap in prior authorization for ongoing services when changing payers, which can be challenging for patients. If a new payer consults the previous payer’s prior authorization information, it could mean that the provider might not need to send a new, duplicative request to the new payer and that the new payer might not need to process that new request. Patients might not have to wait for a new prior authorization for an item or service that a provider and previous payer had already determined the patient needs. This could be particularly helpful for patients with chronic conditions and individuals with disabilities, social risk factors, and limited English proficiency who are changing payers. If a new payer reviews and considers the prior authorization decisions of a patient’s previous payer, based on information the previous payer already had from the patient’s providers, that might reduce E:\FR\FM\13DEP2.SGM 13DEP2 lotter on DSK11XQN23PROD with PROPOSALS2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules delays in care and improve continuity of care. Therefore, we believe that sharing this information between payers could have a significant and positive impact on payers, providers, and patients. We are also interested in comments about whether the continuation of a prior authorization or additional data exchange could be particularly beneficial to patients with specific medical conditions. We understand that payers may use different criteria to make prior authorization decisions. The new payer may not have insight into the criteria used by the previous payer, which could understandably make it challenging for the new payer to accept the previous payer’s decision. With that in mind, we request comments for possible future rulemaking on whether prior authorizations from a previous payer should be honored by the new payer, and if so, should the prior authorizations be limited to a certain period of time based on the type of prior authorization or patient’s medical condition? If so, what should that timeframe be? Should prior authorization from a previous payer be honored in certain instances regarding specific medical conditions? If so, which conditions and for what timeframe? In summary, we propose that, beginning January 1, 2026 (for Medicaid managed care plans and CHIP managed care entities, by the rating period beginning on or after January 1, 2026, and for QHP issuers on the FFEs for plan years beginning on or after January 1, 2026), impacted payers must implement and maintain a FHIR Payerto-Payer API to make available all data classes and data elements included in a content standard adopted at 45 CFR 170.213, claims and encounter data (excluding provider remittances and enrollee cost-sharing information), and prior authorization requests and decisions (and related administrative and clinical documentation) that the payer maintains with a date of service on or after January 1, 2016. We propose that this would include the status of the prior authorization, the date the prior authorization was approved or denied, the date or circumstance under which the prior authorization ends, the items and services approved, and the quantity used to date. If this information includes prior authorization decisions that are denied, we propose that impacted payers must include specific information about why the denial was made. We propose that impacted payers would be required to make information about prior authorizations available via VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 the Payer-to-Payer API for the duration that the authorization is active and, for at least 1 year after the prior authorization’s last status change. We are proposing these Payer-to-Payer API data content requirements for MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs at the CFR sections identified in Table 3. We request comment on these proposals. c. Identifying Previous and Concurrent Payers and Opt In We propose that all impacted payers must develop and maintain processes to identify a patient’s previous and/or concurrent payer(s) and to allow patients or their personal representatives to opt into payer to payer data exchange (both with previous and concurrent payers) prior to the start of coverage. Payers would also need similar processes for current enrollees who are continuing enrollment with their same payer to ensure those patients have the ability to opt in prior to the data being shared through the API. Concurrent coverage means that an individual has coverage provided by two or more payers at the same time. This could include, for example, individuals dually eligible for Medicare and Medicaid who are enrolled in both an MA plan and a Medicaid managed care plan. Another example of concurrent coverage is when different services are covered by different Medicaid managed care plans for the same Medicaid beneficiary. We use the term ‘‘start of coverage’’ in this section to mean when coverage begins or when the patient enrolls and benefits become effective. We note that in some cases a payer may provide coverage retroactively; that is, a payer that provides coverage starting on a date prior to enrollment (as happens in Medicaid, for example). In that case, the payer would be required to have processes to collect permission for Payer-to-Payer API data exchange and to identify a new patient’s previous and/or concurrent payer(s) prior to the date the patient’s enrollment is processed. In Medicaid, this would be the date the beneficiary is enrolled in the state’s MMIS (or equivalent process), not the date coverage takes retroactive effect. We emphasize that obtaining a patient’s opt in permission and identifying the previous and/or concurrent payer(s) cannot delay an applicant’s eligibility determination or start of coverage with any impacted payer. We note that the proposed PO 00000 Frm 00035 Fmt 4701 Sfmt 4702 76271 requirement to identify a patient’s previous and/or concurrent payer(s) and obtain a patient’s opt in permission will not always be feasible before the start of coverage, for instance, if a patient does not provide enough information to identify their previous payer. We emphasize that payers must begin this process before the start of coverage, but it may take longer than enrollment. In that case, the impacted payer would be required to continue to engage with the patient to gather their permission and identify any previous and/or concurrent payer(s). Only once the impacted payer has received permission and identified those other payers would they be required to request patient data, as outlined below. Using Medicaid as an example, if a state has all of the information necessary to determine an individual’s eligibility before it has identified the previous payer, the state must determine the individual’s eligibility and enroll the individual in Medicaid coverage, if determined eligible, while continuing to follow the proposed Payer-to-Payer API requirements outlined here as expeditiously as possible postenrollment. We propose that payers would be required to gather information about the patient’s previous and/or concurrent payer(s) that would allow them to identify and request data from those payers. This could include the payer’s name and a patient ID number or similar identifier. An impacted payer would be required to allow a patient to report multiple previous and/or concurrent payers if they had (or continue to have) concurrent coverage. If that is the case, under our proposals, impacted payers would be required to request the patient’s data from all previous and/or concurrent payers. We are not being prescriptive in these proposals regarding specific information to be gathered from patients, as we believe that this requirement can be implemented in multiple ways. However, we expect that payers would only collect as much information as necessary to identify the previous and/ or concurrent payer(s) and make a successful request in accordance with our proposals, if finalized. For instance, we do not believe specific plan information (as opposed to the payer organization name) or dates of coverage would be necessary to effectuate our proposals. We believe that requesting additional information from patients beyond that which is necessary would impose barriers on patients’ ability to take advantage of our proposed policies E:\FR\FM\13DEP2.SGM 13DEP2 lotter on DSK11XQN23PROD with PROPOSALS2 76272 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules because they may not have that information readily available. We request comments on which data elements would be necessary or extraneous to make that Payer-to-Payer API request. Patients enrolled in ongoing coverage on the compliance date with an impacted payer should be given the same opportunity to have their data shared with their current, ongoing payer by previous and/or concurrent payers. To do so, impacted payers would have to give currently-enrolled patients notice and the opportunity to provide their previous and/or concurrent payer(s) information, as well as to opt in to the proposed payer to payer data exchange. Therefore, we are proposing that no later than the compliance date for the Payer-to-Payer API, impacted payers must establish and maintain a process to gather permission and identify previous and/or concurrent payer(s) from all patients who are currently enrolled. Some payers may want to have a soft launch, rolling implementation or pilot for their Payer-to-Payer API before the proposed compliance date. We want to allow that option and therefore are tying our proposal to require payers to gather permission from currently-enrolled patients to the proposed compliance date, January 1, 2026 (for Medicaid managed care plans and CHIP managed care entities, by the rating period beginning on or after January 1, 2026, and for QHP issuers on the FFEs, for plan years beginning on or after January 1, 2026), rather than when a payer implements their API. That would allow payers to sequentially target specific plans, populations or enrollee categories for operational rollout, as long as all currently-enrolled patients are given the opportunity to opt in to payer to payer data exchange by that compliance date. For new patients enrolling on or after the compliance date, we are proposing to require impacted payers to maintain a process for patients to opt in to the Payer-to-Payer API data exchange and to identify their previous and/or concurrent payer(s) prior to the start of their coverage. Below, in section II.C.4.b., we discuss the possible incorporation of these proposed requirements into state applications for Medicaid or CHIP eligibility. Making this process available to patients during the enrollment process, or immediately thereafter, would allow the proposed data exchange to take place as quickly as possible once the patient is enrolled with the new payer. For example, where there may not be communication during the enrollment process such as during the QHP enrollment on the FFE, this VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 process should be done immediately following enrollment. We solicit comment on incorporation of the proposed requirements into the FFE QHP enrollment process as described at 45 CFR 156.265. In addition, we propose to require impacted payers to have a process for patients to opt in to this data exchange at any time after the start of coverage, or if they have already opted in, to opt out, at any time. We are proposing an opt in approach for the data exchange through the Payerto-Payer API for the reasons discussed below, even though, as discussed in section II.B.3.b. of this proposed rule, we believe that an opt out approach to patient data exchange generally would promote the positive impacts of data sharing to support care coordination and improved health outcomes, which could lead to greater health equity. Furthermore, systems with opt in patient permission requirements are more likely to report regulatory barriers to data exchange compared to those without. However, for a variety of legal and operational reasons, we are proposing an opt in permission policy for our payer to payer data exchange proposal. An opt in framework means that the patient or their personal representative would need to affirmatively permit the payer to share data within the proposed Payer-to-Payer API framework discussed in this section, and without that permission, the payer may not engage in the payer to payer data exchange for that patient. We note that this permission (or lack thereof) would only apply to the data exchange proposals discussed here and not to any other obligations under HIPAA or other law. Certain operational considerations support an opt in framework for this API. As discussed, to request a patient’s data from their previous and/or concurrent payer(s), a new payer must identify those payers by gathering information from the patient. While there may be other ways for payers to collect this information, we believe that patients themselves are the best source for sufficient and accurate information necessary for the payer to make the request. Patients would not be required to provide this information. However, should they choose to, providing this information would require an affirmative act from the patient, so we believe that the burden of asking a patient to opt in would not create a significant additional barrier to patient participation. In contrast, our proposed policy for the Provider Access API would allow payers to exchange patient data with providers unless a patient has opted out. PO 00000 Frm 00036 Fmt 4701 Sfmt 4702 We are proposing an opt out policy for the Provider Access API, in part, based on the existence of a treatment relationship between the patient and provider, a contractual relationship between the payer and the provider, and a coverage relationship between the payer and patient. Specifically, our proposals to require the Provider Access API data exchange only with providers in the payer’s network and require a process to attribute a patient to that provider before data can be exchanged creates a level of assurance for the payer that it is sending patient data to an appropriate party. In contrast, two payers exchanging information do not have a direct relationship but would be exchanging data based on a patient’s separate relationship with each payer. Therefore, it may make sense for the patient to have a larger gatekeeping role within this proposed policy. Furthermore, specific statutory and regulatory requirements applicable to state Medicaid and CHIP programs would prevent those programs from establishing an opt out process, or from sharing information with other payers on the basis of a patient’s failure to opt out of the other payer’s data exchange. Specifically, 42 CFR 431.306(d), a regulation implementing section 1902(a)(7) of the Act, prohibits Medicaid programs from sharing beneficiary information with outside sources before obtaining permission to do so from the individual or family, with limited exceptions. This regulation also applies to CHIP programs under 42 CFR 457.1110(b). This regulation does not conflict with the proposed opt out policy for the Provider Access API because Medicaid and CHIP enrolled providers are not outside sources. However, other payers would typically be outside sources and thus, the regulation would apply to the data shared through the Payer-to-Payer API. For further discussion of data exchange between state Medicaid or CHIP agencies and managed care entities, see section II.C.4.b. below. Additionally, we are proposing that the requesting payer would obtain the permission of the patient for this data exchange, not a Medicaid or CHIP program that would be sharing the data. Accordingly, the payer requesting the data would also need to follow the permission requirements applicable to Medicaid and CHIP programs so that the Medicaid and CHIP programs could share information through this API in a manner that is consistent with 42 CFR 431.306(d). Rather than creating different permission rules for different payers, which would add significant complexity to the payer to payer data E:\FR\FM\13DEP2.SGM 13DEP2 lotter on DSK11XQN23PROD with PROPOSALS2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules exchange process, especially for Medicaid and CHIP programs, it may be preferable for all impacted payers to use an opt in process. We request comments on our proposal for an opt in process for gathering patients’ permission for payer to payer data exchange. Is there any way, such as through any regulatory changes that we should consider, either in this rulemaking or in the future, that would instead allow for an opt out process while protecting patient privacy in accordance with the considerations above? Are there any policy approaches or technical requirements that could provide all impacted payers with the assurance that they have gathered appropriate permission from patients within the statutory and regulatory framework outlined here? Are there any barriers to interoperability with an opt in approach for patient data exchange for all impacted payers that we are not considering? We emphasize that all data maintained, used, shared, or received via this proposed Payer-to-Payer API must be maintained, used, shared, or received in a way that is consistent with all applicable laws and regulations. For example, the HIPAA Privacy Rule does not require a covered entity, such as a health plan, to obtain authorization from the enrolled individual or provide an opportunity for the individual to agree or object, in order to share PHI under 45 CFR 164.512(a)(1) 59 if the disclosure is ‘‘required by law’’ as defined at 45 CFR 164.103. Our proposed requirements, if finalized, would be set forth in a regulation that requires information sharing and therefore would allow for disclosure under that HIPAA provision, without authorization. For Medicaid, as noted above, section 1902(a)(7) of the Social Security Act, and implementing regulations at 42 CFR part 431 govern the requirements for the use and disclosure of applicant and beneficiary information, and are discussed in more detail in section II.C.3.c.1 and in this section. Other laws, such as state privacy laws, may require the payer to obtain the enrolled individual’s consent before disclosing certain information. We emphasize that our proposals are not intended to change any existing obligations under HIPAA, the regulations under 42 CFR part 2, or state privacy or other laws, but could and should be implemented in accordance with those rules if this proposed rule is 59 A covered entity may use or disclose protected health information to the extent that such use or disclosure is required by law and the use or disclosure complies with and is limited to the relevant requirements of such law. VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 finalized as proposed. We request comment on any considerations regarding state privacy or other laws that our proposals may implicate. In summary, we propose that, beginning January 1, 2026 (for Medicaid managed care plans and CHIP managed care entities, by the rating period beginning on or after January 1, 2026, and for QHP issuers on the FFEs, for plan years beginning on or after January 1, 2026), impacted payers must maintain a process to identify a new patient’s previous and/or concurrent payer(s) to facilitate data exchange using the Payer-to-Payer API. As part of this process, impacted payers would be required to allow a patient to report multiple previous and/or concurrent payers if they had (or continue to have) concurrent coverage. If a patient does report multiple previous payers, impacted payers would be required to request that patient’s data from all previous and/or concurrent payers. Furthermore we propose that, prior to the start of coverage, impacted payers must establish and maintain a process to gather patient permission for payer to payer data exchange, as described in this section. That permission process would have to use an opt in framework whereby a patient or personal representative must affirmatively agree to allow that data exchange. In addition, we propose that impacted payers must have a process for patients to opt into this data exchange at any time, after the start of coverage, or, if they have already opted in, to opt back out, at any time. Finally, we propose to require impacted payers to establish and maintain a process to gather permission and previous and/or concurrent payer(s) information from patients who are currently enrolled on the Payer-to-Payer API compliance date. For new patients enrolling on or after that date, we are proposing to require impacted payers to maintain a process for patients to provide previous payer information and opt in to the Payer-to-Payer API data exchange prior to the start of coverage. We are proposing the permission and previous and/or concurrent payer identification requirements for the Payer-to-Payer API for MA organizations, state Medicaid and CHIP agencies, and QHP issuers on the FFEs at the CFR sections identified in Table 3. We request comment on these proposals. PO 00000 Frm 00037 Fmt 4701 Sfmt 4702 76273 d. Requesting Data Exchange From a Patient’s Previous and/or Concurrent Payer(s) and Responding to Such a Request We are proposing to require impacted payers to request a patient’s data from their previous and/or concurrent payer(s) no later than 1 week after the start of coverage. We believe 1 week is sufficient time to allow payers to complete their process for identifying patients’ previous and/or concurrent coverage and to initiate this request for data from the other payer(s). If after the start of coverage a patient opts in to the data exchange or provides previous and/ or concurrent payer information, or requests data exchange for another reason, we propose that the current payer would be required to request data from the previous and/or concurrent payer(s) no later than 1 week after the payer has the necessary permission and information, or the patient makes the request. We acknowledge that the obligation is contingent on the patient supplying the necessary information about a previous and/or concurrent payer to enable the new payer to conduct the required exchange. An impacted payer cannot comply with these requirements if the patient has not provided timely or accurate information about their previous and/or concurrent payer. This applies throughout the proposals in this section of the proposed rule. Other than in the context of concurrent payers, we generally expect our proposal to be a one-time data exchange between a previous and new payer. Once the new payer has received the patient’s data, we do not expect there to be additional information added to the patient record from the previous payer. However, we want to allow patients to request subsequent data exchange to account for any outlier situations. We are also aware that claims take time to process and may be processed after patients have transitioned to a new payer, thus creating additional data within the patient’s record for some time period after the patient has transitioned payers. We considered proposing a policy where, if the patient permits, previous payers would be required to send any additional data within the required dataset to the new payer within 1 week of receiving additional data. However, keeping in mind the frequency and burden this could impose on payers, we seek comment on whether such a policy would be beneficial or overly burdensome. Would additional data be helpful for the new payer for weeks or months after enrollment? Would E:\FR\FM\13DEP2.SGM 13DEP2 lotter on DSK11XQN23PROD with PROPOSALS2 76274 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules specific data be more pertinent than others? Would it lead to overly burdensome data exchanges that would not provide value to the new payer? We also considered whether it would be appropriate to limit that requirement to a certain period after the initial data exchange for instance within 30 or 90 days. Additionally, we considered whether to propose that impacted payers must make that data exchange within a week of receiving any data updates or whether they should only be required to on a set schedule, such as monthly or quarterly, to allow payers to streamline transactions for multiple patients. We seek comment on whether any additional data exchange would be warranted to account for data received by the previous payer after the patient’s coverage ends and, if so, what the appropriate parameters would be. We propose that impacted payers would be required to use the OpenID Connect authorization and authentication protocols at 45 CFR 170.215(b) to authenticate the identity of the requesting payer. Like our proposal for the Provider Access API, discussed in section II.B.2., to protect patient data, we want to ensure payers do not send data unless they are confident that the requesting payer is who it says it is. Because these are the same authorization and authentication protocols that are proposed for Patient Access and Provider Access APIs, we believe that payers are already familiar with this requirement for implementation. To assure the payer receiving the request, we propose to require the requesting payer to include an attestation with the request for data affirming that the patient has enrolled with the requesting payer and has opted in to the data exchange in a manner that meets the necessary legal requirements. As explained in section II.F., we recommend the use of certain HL7 implementation guides to support the exchange of data between impacted payers for the Payer-to-Payer API. The HL7 PDex IG has been developed to ensure that both the technical and business processes of capturing and sharing a patient’s permission for data exchange preferences are included in the payer to payer data request. Therefore, using the PDex IG would meet the requirements of this proposal. Because that IG is recommended and not required, impacted payers could also exchange an attestation regarding patient permission with other implementations that meet or exceed the requirements of the PDex IG. We propose that the previous and/or concurrent payer, if an impacted payer, VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 would be required to respond to a current payer’s request, if it meets the requirements, within 1 business day of receipt. We believe 1 business day is the appropriate timeframe to complete this process to send the data, as payers need timely access to previous and/or concurrent payer data to facilitate care coordination and create a longitudinal record that could be helpful to the patient should they wish to access their information for care planning with any new provider(s) they may see. We note that this timeframe also would align with the 1 business day response time for the Patient Access API and proposed Provider Access API. We seek comment on whether the proposed timeframes for a new payer to request patient data, and for the previous and/or concurrent payer to send these data, are appropriate or whether other timeframes would better balance the benefits and burdens. We seek comment on whether payers could accommodate a shorter period for the data request at the start of coverage, such as 1 to 3 business days, and whether payers need more than 1 business day to respond to a request. If so, what is a more appropriate timeframe for payers to respond to data requests? We believe it is important for patient data to move to the new payer as soon as possible to compile a longitudinal record, as well as obtain information on active prior authorizations. We note that if a previous and/or concurrent payer is not an impacted payer, they would not be subject to our proposed requirements and, therefore would not be required to send data through the Payer-to-Payer API under this proposal. For example, when a patient moves from a QHP on an FFE to an employer-based plan, the employerbased plan would not be impacted by this rulemaking. The new impacted payer would not be obligated to determine whether the previous payer is an impacted payer under this proposed rule. Therefore, an impacted new payer would be required to request the data from the patient’s previous and/or concurrent payer, regardless of whether the other payer is an impacted payer or not. If the previous and/or concurrent payer is not an impacted payer, they would not be subject to our proposed requirements to respond to the request. Conversely, we propose that if an impacted payer receives an appropriate request for patient data under this proposal, they would be required to respond by sending all required data under this proposal, regardless of whether the requesting payer is or is not PO 00000 Frm 00038 Fmt 4701 Sfmt 4702 an impacted payer (which they payer may or may not know). In summary, we propose that, beginning January 1, 2026 (for Medicaid managed care plans and CHIP managed care entities, by the rating period beginning on or after January 1, 2026, and for QHP issuers on the FFEs, for plan years beginning on or after January 1, 2026), impacted payers must request the appropriate data, as described earlier in this section, from any previous and/or concurrent payers through the Payer-to-Payer API, provided that the patient has permitted the data exchange as proposed in section II.C.3.c. We propose that impacted payers would be required to include an attestation with the request for data affirming that the patient has enrolled with that requesting payer and has opted in to the data exchange. We propose that impacted payers must request these data from any previous payer(s) no later than 1 week after the start of coverage or after a patient’s request. If a patient who did not opt in or provide previous payer information subsequently opts in to the payer to payer data exchange and shares that previous payer information, we are proposing that the impacted payer would be required to request the patient’s data from the patient’s previous payer no later than 1 week after the patient opts in or provides that information. We propose that if an impacted payer receives a request from another payer to make data available for former patients who have enrolled with the new payer or a current patient who has concurrent coverage, the impacted payer must respond by making the required data available via the Payer-to-Payer API within 1 business day of receiving the request if the requesting payer has been authenticated according to the requirements of 45 CFR 170.215(b), demonstrated that the patient has permitted the data exchange through an opt in process with the requesting payer, and disclosure of the data is not prohibited by law. We are proposing these payer to payer data exchange timeframe requirements for MA organizations, state Medicaid and CHIP FFS agencies, and QHP issuers on the FFEs at the CFR sections identified in Table 3. We request comment on these proposals. e. Data Exchange Requirements for Concurrent Coverage For individuals who have concurrent coverage with multiple payers, we propose to require impacted payers to collect information about any concurrent payer(s) from patients before E:\FR\FM\13DEP2.SGM 13DEP2 lotter on DSK11XQN23PROD with PROPOSALS2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules the start of coverage with the impacted payer (consistent with how ‘‘start of coverage’’ is explained above). Because we believe it would be beneficial for all of a patient’s current payers to maintain a longitudinal record of the care that the patient has received from all payers, we propose to require impacted payers to request the same patient data described in section II.C.3.b. from all of a patient’s concurrent payers, and to send that data in response to an appropriate request. This would ensure that all of the patient’s concurrent payers maintain a complete patient record and can provide all the information proposed to be required under the Patient Access API and Provider Access API. Specifically, we are proposing to require impacted payers, within 1 week of the start of a patient’s coverage, to exchange data with any concurrent payers that the patient reports. Additionally, we propose that should an impacted payer receive a request for a current patient’s data from a known concurrent payer for that patient, the receiving payer must respond with the appropriate data within 1 business day of receiving the request. Operationally, this proposed exchange would function the same as the data exchange with a patient’s previous payer. Because all payers will update patient records during the period when a patient is enrolled with those payers, we propose that when a patient has concurrent coverage with two or more payers, the impacted payers must exchange the patient’s data available to every other concurrent payer at least quarterly. This proposal would create requirements for impacted payers to both request patients’ data from other concurrent payers and to respond to requests from other payers to share patients’ data. Some patients may be concurrently enrolled with payers that would not be subject to our proposed requirements because they are not impacted payers. As discussed above, if a non-impacted concurrent payer does not have the capability or refuses to exchange the required data with an impacted concurrent payer through a FHIR API, the impacted payer is not required to exchange data with that non-impacted payer under this proposal and would not be required to continue to request data exchange quarterly. However, we encourage all payers to implement a Payer-to-Payer API to support data exchange with concurrent payers, even if they are not subject to our proposed requirements. We expect that this data exchange among concurrent payers would support better care coordination and more efficient operations. If a non- VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 impacted payer requests data in conformance with the proposed requirements of this section via an API that meets the requirements proposed for the Payer-to-Payer API, an impacted payer would be required to respond, as if the requesting payer were subject to the rule. As explained above, impacted payers would not need to spend resources determining whether other payers are impacted by these proposals, but would be required to request patient data and respond to all requests that are made within the requirements of this proposed rule. We also considered whether to propose more frequent exchange (weekly or monthly), or less frequent exchange (semi-annually or annually); however, we believe a quarterly data exchange would strike the right balance between providing accurate, timely data and payer burden. CMS believes sharing data quarterly would be frequent enough to allow time for new health data to accumulate and still be timely, but not so frequently that it causes unnecessary burden on the payers required to provide the information. We request comment on this proposal, including on the appropriate frequency for this payer to payer exchange for patients with concurrent coverage. We note that when a patient has concurrent coverage, the payers must often communicate regularly to ensure that the proper payer is responsible for that patient’s claims. Nothing in this proposed rule, including a patient not opting in to the Payer-to-Payer API data exchange, is intended to alter payers’ ability to exchange data as they do today for that purpose, in accordance with applicable law. In summary, we propose that, beginning January 1, 2026 (for Medicaid managed care plans and CHIP managed care entities, by the rating period beginning on or after January 1, 2026, and for QHP issuers on the FFEs, for plan years beginning on or after January 1, 2026), impacted payers would be required, within 1 week of the start of a new patient’s coverage, to request initial data exchange from any concurrent payers that the patient reports, and thereafter to request data exchange with those payers no less frequently than once per calendar quarter. We propose that should an impacted payer receive a request for a current patient’s data from that patient’s concurrent payer, the receiving payer must respond with the appropriate data within 1 business day of receiving the request. Impacted payers would be required to exchange the same data proposed in section II.C.3.b. PO 00000 Frm 00039 Fmt 4701 Sfmt 4702 76275 We are proposing these requirements for concurrent coverage data exchange for MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs at the CFR sections identified in Table 3. We request comment on these proposals. f. Data Incorporation and Maintenance We propose that information received by an impacted payer through this data exchange must be incorporated into the patient’s record with the new payer. Those data would then be part of the patient’s record maintained by the new payer and should be included as appropriate in the data available through the Patient Access API, Provider Access API and Payer-to-Payer API, if our proposals are finalized as proposed. In this way, a patient’s cumulative record would follow them between payers and be available to them and their providers. While this proposal would not obligate payers to review, utilize, update, validate, or correct data received from another payer, we encourage impacted payers to do so, at least to the extent doing so might benefit the patient’s ongoing care. As previously explained in the CMS Interoperability and Patient Access final rule for the payer to payer data exchange (85 FR 25568), payers could choose to indicate which data were received from a previous payer so a future receiving payer, provider, or even the patient, would know where to direct questions (such as how to address contradictory or inaccurate information), but would not be required to do so under this proposal. Regardless, all data maintained, used, shared, or received via the proposed Payer-toPayer API would be required to be maintained, used, shared, or received in a way that is consistent with all applicable laws and regulations. We note that our proposals would not impact any payer’s data retention requirements. Specifically, we are not proposing to require impacted payers to maintain data for unenrolled patients any longer or differently than they do today under current law, regulation, or policy. We understand that if a patient is uninsured or moves to a nonimpacted payer that does not request information from the previous payer, after a period of time, the old payer may discard information, which would make it unavailable to the patient or other payers in the future. However, we believe that imposing requirements that would require payers to alter their data retention policies based on the actions of other payers E:\FR\FM\13DEP2.SGM 13DEP2 76276 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules lotter on DSK11XQN23PROD with PROPOSALS2 would be a significant burden that would outweigh the benefits of such a policy. We considered proposing a minimum period during which a payer must maintain patient records after disenrollment, such as 1 or 2 years. However, we believe that most payers have policies in place that would maintain patient data for at least that long, and thus, such a requirement is unnecessary and burdensome. We request comment on whether our understanding is correct and whether there is a benefit to us considering a data retention requirement in the future. In summary, we propose that, beginning January 1, 2026 (for Medicaid managed care plans and CHIP managed care entities, by the rating period beginning on or after January 1, 2026, and for QHP issuers on the FFEs, for plan years beginning on or after January 1, 2026), any information received by an impacted payer through this data exchange must be incorporated into the patient’s record with the new payer. We are proposing this requirement regarding data incorporation for MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs at the CFR sections identified in Table 3. g. Patient Education Requirements Consistent with our proposals for the Provider Access API, impacted payers would be required to provide patients with educational materials in nontechnical, simple, and easy-tounderstand language, explaining at a minimum: the benefits of Payer-to-Payer API data exchange, their ability to opt in or withdraw a previous opt in decision, and instructions for doing so. Impacted payers would be required to provide these educational materials to patients at or before requesting permission for the Payer-to-Payer API data exchange. As discussed above, currently enrolled patients must be given the opportunity to opt in to payer to payer data exchange and to provide previous and/or concurrent payer information before the API compliance date. Our proposal would require impacted payers to provide these educational materials to those currently enrolled patients at or before requesting their opt in as well. In addition, similar materials would have to be provided annually to all covered patients in mechanisms that the payer regularly uses to communicate with patients. This information would also be required to be provided in an easily accessible location on the payer’s public website. We request comment on whether it would reduce payers’ burden to only be VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 required to provide these materials annually to any patients who have not opted in and those with known concurrent payers. We propose that impacted payers would have to provide educational materials regarding the payer to payer data exchange to all patients at or before requesting opt in and at least annually beginning January 1, 2026 (for Medicaid managed care plans and CHIP managed care entities, by the rating period beginning on or after January 1, 2026, and for QHP issuers on the FFEs, for plan years beginning on or after January 1, 2026). We are proposing these patient education requirements for MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs at the CFR sections identified in Table 3. 4. Payer to Payer Data Exchange in Medicaid and CHIP a. Inclusion of Medicaid and CHIP FFS We did not require state Medicaid and CHIP FFS programs to comply with the payer to payer data exchange policies in the CMS Interoperability and Patient Access final rule (85 FR 25568). State Medicaid and CHIP FFS programs can face unique circumstances that might make it more challenging for them to meet new requirements within the same timeframe as other payers because of state budget cycles and other funding constraints, possible state legislation or regulatory requirements, contracting timeframes, required systems upgrades, and recruiting necessary staff resources. As a result, in our first phase of interoperability policies in the CMS Interoperability and Patient Access final rule (85 FR 25524), we chose to limit the burden on these programs so they could focus their attention and resources on implementing the Patient Access and Provider Directory APIs and did not make the Payer-to-Payer API policies in that rule applicable to state Medicaid and CHIP FFS programs. However, in August 2020, CMS released a letter to state health officials in which we encouraged state Medicaid and CHIP FFS programs to accommodate payer to payer data exchange requests from beneficiaries.60 We are now proposing to make the proposed payer to payer data exchange policies in this proposed rule applicable 60 Centers for Medicare & 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. PO 00000 Frm 00040 Fmt 4701 Sfmt 4702 to state Medicaid and CHIP FFS programs. We believe that proposing to require Medicaid and CHIP FFS programs to implement the Payer-toPayer API data exchange policies in this proposed rule would not be as burdensome as proposing to require them to follow the non-API-based payer to payer data exchange policies that were finalized in the CMS Interoperability and Patient Access final rule (85 FR 25524) and that we are proposing to withdraw in this proposed rule. That is because this new API would be leveraging the same data and technical standards as the Patient Access API. State programs should have already implemented their Patient Access APIs and should thus be able to leverage the work done for that API to make implementing this newly proposed API more manageable. For state Medicaid and CHIP FFS programs, the state agency is the impacted payer that would share patient data with other impacted payers. As we discuss in more detail in section II.C.3.a. of this proposed rule, using the Payerto-Payer API could create efficiencies for state Medicaid and CHIP programs, thereby reducing burden for these programs, and potentially leading to better coordinated patient care and improved health outcomes. We expect the proposed Payer-to-Payer API requirement to lead to more effective administration of the state plan, and to better enable Medicaid and CHIP programs to ensure care and services are provided in a manner that is consistent with their beneficiaries’ best interests. Ensuring that patient data can follow Medicaid and CHIP beneficiaries as they enter these programs could potentially lead to better care coordination and continuity of care for these patients. It could also reduce burden for patients and providers. The Medicaid and CHIP FFS programs would have additional information from other payers to share via the Patient Access API and the Provider Access API. As a result, Medicaid and CHIP beneficiaries would have more readily available information to support informed decision-making, and Medicaid and CHIP providers would have more information about the care their patients are receiving. This could potentially lead to fewer duplicate tests or less time taken collecting and recollecting information about the patient during a visit. Any effort a state Medicaid or CHIP FFS program takes to evaluate the data from a patient’s previous or concurrent payers could potentially allow the program to avoid wasteful, unnecessary, or duplicative action. In this way, E:\FR\FM\13DEP2.SGM 13DEP2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules lotter on DSK11XQN23PROD with PROPOSALS2 extending this Payer-to-Payer API to state Medicaid and CHIP FFS programs could benefit these programs by helping them to operate more efficiently. If this proposal is finalized to include state Medicaid and CHIP FFS programs, patients would continue to have access to their health information, creating a longitudinal record, as they move into and out of Medicaid or CHIP FFS. A broader range of information about patients’ past care might also be able to follow them to new providers if payers have greater access to data from other payers and can make it available through the Patient Access and Provider Access APIs proposed in this proposed rule. b. Permission and Exchange Considerations Specific to Medicaid and CHIP FFS, Medicaid Managed Care Plans, and CHIP Managed Care Entities We know that state Medicaid or CHIP agencies regularly exchange data with their managed care plans. This Payer-toPayer API proposal would not affect the Medicaid and CHIP programs’ ability to share data as they do today. Specifically, Medicaid agencies and their contracted managed care plans may, and in some cases are required to,61 exchange beneficiary information with each other, as part of the operation of the Medicaid program, subject to any other applicable law. Similarly, CHIP agencies and their contracted managed care entities may exchange beneficiary data, as part of the operation of the CHIP program, subject to any other applicable law.62 This allows effective transitions for beneficiaries who move between managed care plans or entities or between FFS and managed care delivery/coverage systems within the same state’s Medicaid or CHIP programs, and promotes the coordination and continuity of care within those programs—the very coordination that our proposals are intended to enable. As mentioned above, Medicaid managed care plans and CHIP managed care entities are not outside sources, but are part of a state’s Medicaid and/or CHIP programs as a whole. Therefore, we do not wish to impose a policy that would require an opt in for patients for state Medicaid and CHIP agencies and their managed care entities to exchange information, as they may do today. Current consent rules and requirements for exchange within a state’s Medicaid and CHIP programs (such as between a 61 See 42 CFR 438.62(b)(1)(iii), 438.242(c)(2) and (3). 62 See cross-references at 42 CFR 457.1216 and 457.1233(d). VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 managed care plan and the state Medicaid or CHIP agency or between two managed care plans contracted with the state Medicaid or CHIP agency), are not affected by our proposals. There is no requirement for a state Medicaid or CHIP agency to obtain an opt in from an individual or family member prior to providing information about a Medicaid or CHIP beneficiary to its own providers or plans, as such entities would not be an outside source as described at 42 CFR 431.306(d) (and as discussed in section II.B., related to our Provider Access API proposals). We do not intend any of our proposals to interfere with or affect this permissible information exchange. Hence, we are proposing that if a Medicaid or CHIP agency is exchanging information per our Payer-to-Payer API proposals with a managed care plan or managed care entity with which they have a contract, the requirement to obtain patient opt in would not apply. The other proposed payer to payer requirements, such as the requirement to use a FHIR API and the authorization and authentication protocols would apply. The exchange must also not be prohibited by law. We welcome comments, specifically from states and contracted managed care entities, as to how we can establish standards for patient data exchange between state Medicaid and CHIP agencies and their contracted managed care entities without creating additional barriers or burden. We are proposing that Medicaid and CHIP agencies, like all impacted payers, implement a process to allow currently enrolled beneficiaries a chance to opt in to payer to payer data exchange prior to the State Medicaid or CHIP agency’s Payer-to-Payer API compliance date, and prior to the enrollment of new beneficiaries after that date. The opportunity for newly enrolling patients to opt in could take place through the application, or at some later point of contact with the beneficiary prior to the start of coverage, but in no instance would our proposals permit a delay in the enrollment process or a beneficiary’s coverage. As discussed above, 42 CFR 431.306 lists certain requirements for sharing beneficiary data. We note that when an individual’s Medicaid or CHIP enrollment has ended and another payer is requesting a former Medicaid beneficiary’s information, receiving an attestation from a requesting payer that the patient has opted in to data exchange with the requesting payer, consistent with our proposals for all payers, is a permissible way for the state Medicaid or CHIP agency to obtain permission as required under 42 CFR 431.306(d). We are proposing these PO 00000 Frm 00041 Fmt 4701 Sfmt 4702 76277 requirements at the CFR citations in Table 3. States are also reminded that access to information concerning beneficiaries must be restricted to persons and agencies who are subject to standards of confidentiality that are comparable to that of the Medicaid agency, in accordance with 42 CFR 431.306(b). We do not believe that any of the other requirements of 42 CFR 431.306 are relevant because they cover data release and use in contexts outside of our proposals in this section. We are specifically proposing that state Medicaid and CHIP agencies, rather than their managed care plans, would be responsible for obtaining the required permission. A Medicaid or CHIP beneficiary may switch between FFS and managed care delivery systems within the same state’s Medicaid or CHIP program, but despite these shifts, an eligible beneficiary remains a beneficiary of the state program. States may also change the managed care plans that they contract with. Thus, the patient permission to this data exchange, as a Medicaid or CHIP beneficiary, should be obtained by the state and would apply regardless of the delivery system in which the beneficiary is enrolled. We believe that the state is the appropriate custodian of the patient’s permission record, rather than the particular managed care plan or managed care entity through which a patient receives care. We understand that this would require state Medicaid and CHIP agencies to create new processes to share a patient’s opt in preference with their managed care plans and managed care entities. We considered proposing that the Payer-to-Payer API requirements would not apply for beneficiaries moving between or with concurrent coverage with a state Medicaid or CHIP agency and a contracted managed care entity for the reasons outlined above. However, we are concerned that many states today do not exchange data between their Medicaid or CHIP FFS programs and managed care. We request comments on whether there are other ways we can ensure patient data is exchanged in this case in a manner that would reduce burden on states. We are also proposing that the requirement to identify patients’ previous and/or concurrent payers apply to state Medicaid and CHIP agencies rather than managed care plans or managed care entities. For the reasons described above, we believe that having the state maintain that record would allow that information to be retained regardless of any changes to the E:\FR\FM\13DEP2.SGM 13DEP2 lotter on DSK11XQN23PROD with PROPOSALS2 76278 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules patient’s Medicaid or CHIP care delivery system. Furthermore, we understand that in many states, managed care plans may not have any contact with patients prior to their enrollment in the Medicaid or CHIP managed care plan. We believe the ideal time to allow patients to opt into payer to payer data exchange is during their application for Medicaid or CHIP. However, per 42 CFR 435.907(e)(1), states may only require information from an applicant that is necessary to make an eligibility determination. This means that while an applicant may be asked to provide their permission for the data exchange, they may not be required to respond to the question as a condition of submitting the application. Because we expect higher rates of patients providing permission when they are presented with the option at a time when they are already engaged in providing information (such as at application or plan selection), we highly encourage states to leverage any touchpoints before patients are enrolled in FFS or a managed care plan rather than expecting patients to submit permission in a separate process. We understand that making changes to applications can be a significant administrative process and there may be other places where a state could obtain a patient’s data exchange preference for the Payer-to-Payer API data exchange. For instance, a state could leverage an online portal or app, if beneficiaries frequently use those pathways for other purposes, such as reporting a change in circumstance or providing information for eligibility renewal. However, the option should be equally available for all beneficiaries and if only a small portion of the Medicaid population uses these tools to communicate with the Medicaid agency, that subset would be self-selected for greater technology literacy and taking this approach could exacerbate inequality. We note that the single streamlined application, which for Medicaid purposes is described at 42 CFR 435.907(b)(1) and is also used for applications through the FFEs, includes questions about concurrent coverage information. We also expect that some states that do not use the single streamlined application already ask for this information for Coordination of Benefits and Third-Party Liability purposes. We believe that it would generally make sense to gather permission for payer to payer data exchange with that concurrent payer at that point. Furthermore, the patient permission provisions in this proposal would apply only to the payer to payer data exchange discussed here and VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 would not affect states’ ability to perform Coordination of Benefits or Third-Party Liability activities as they do today. We request comment on the workflow and data exchanges that occur when a Medicaid or CHIP beneficiary is enrolled into a managed care plan and the feasibility of including the patient permission during the enrollment process. If not included in the application itself, is it feasible to gather permission and previous and/or concurrent payer information in a postapplication questionnaire? Are there touchpoints that exist with beneficiaries after the application, but before or during enrollment (such as plan selection) that could be leveraged for this purpose? We considered proposing a policy that would require states to include optional questions to capture a patient’s data exchange preference for payer to payer data exchange on their applications (as a non-required field); however, we believe that states have different processes, and a one-size-fitsall approach may not be optimal. Based on comments we receive and implementation across state Medicaid and CHIP programs, we may propose such a policy in the future. c. Federal Funding for State Medicaid and CHIP Expenditures on Implementation of Payer to Payer Data Exchange Should our proposals be finalized as proposed, states operating Medicaid and CHIP programs might be able to access Federal matching funds to support their implementation of the Payer-to-Payer API. This proposed API is expected to lead to more efficient administration of the Medicaid and CHIP state plans, consistent with sections 1902(a)(4) and 2101(a) of the Act. We would not consider state expenditures for implementing this proposal to be attributable to any covered Medicaid item or service within the definition of ‘‘medical assistance.’’ Thus, in Medicaid, CMS would not match these expenditures at the state’s regular Federal FMAP. However, were this proposal to be finalized as proposed, FFP under section 1903(a)(7) of the Act, at a rate of 50 percent, for the proper and efficient administration of the Medicaid state plan, might be available for state expenditures related to implementing this proposal for their Medicaid programs. We believe that using the Payer-to-Payer API would help the state more efficiently administer its Medicaid program, by ensuring that payers can access data that could improve care coordination for patients. PO 00000 Frm 00042 Fmt 4701 Sfmt 4702 States’ expenditures to implement these proposed requirements might also be eligible for 90 percent enhanced FFP under section 1903(a)(3)(A)(i) of the Act, if the expenditures can be attributed to the design, development, or installation of mechanized claims processing and information retrieval systems. Additionally, 75 percent enhanced FFP under section 1903(a)(3)(B) of the Act may be available for state expenditures to operate Medicaid mechanized claims processing and information retrieval systems to comply with this proposed requirement. States can request Medicaid enhanced FFP under section 1903(a)(3)(A)(i) or (B) of the Act through the APD process described in 45 CFR part 95, subpart F. States are reminded that 42 CFR 433.112(b)(12) and 433.116(c) in part require that any system for which they are receiving enhanced FFP under section 1903(a)(3)(A)(i) or (B) of the Act align with and incorporate the ONC’s Health Information Technology standards adopted in 45 CFR part 170, subpart B. The Payer-to-Payer API complements this requirement because these APIs further interoperability by using standards adopted by ONC at 45 CFR 170.215.63 States are also reminded that 42 CFR 433.112(b)(10) and 42 CFR 433.116(c) explicitly support exposed APIs, meaning their functions are visible to others to enable the creation of a software program or application, as a condition of receiving enhanced FFP under section 1903(a)(3)(A)(i) or (B) of the Act. Similarly, 42 CFR 433.112(b)(13) and 433.116(c) require states to promote sharing, leverage, and re-use of Medicaid technologies and systems as a condition of receiving enhanced FFP under section 1903(a)(3)(A)(i) or (B) of the Act. CMS interprets that requirement to apply to technical documentation associated with a technology or system, such as technical documentation for connecting to a state’s APIs. Making the needed technical documentation publicly available so that systems that need to can connect to the APIs proposed in this rule would be required as part of the technical requirements at 42 CFR 431.60(d) for all proposed APIs in this rule, including the Payer-to-Payer API. Separately, for state CHIP agencies, section 2105(c)(2)(A) of the Act and 42 CFR 457.618, limiting administrative 63 Centers for Medicare & 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\13DEP2.SGM 13DEP2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules costs to no more than ten percent of a state’s total computable expenditures for a fiscal year, would apply to administrative claims for developing the APIs proposed in this rule. We note that the temporary Medicaid FMAP increase available under section 6008 of the Families First Coronavirus Response Act (Pub. L. 116–127) does not apply to administrative expenditures. d. Medicaid Expansion CHIP Programs Most states have Medicaid Expansion CHIP programs, in which a state receives Federal funding to expand Medicaid eligibility to optional targeted to low-income children that meet the requirements of section 2103 of the Social Security Act. We are proposing at 42 CFR 457.700(c) that for states with Medicaid expansion CHIP programs, the proposals in this rule for Medicaid would apply to those programs rather than our proposals for separate CHIP programs. Functionally, our proposals are the same; however, for clarity, we are making explicit that the Medicaid requirements at §§ 431.60, 431.61, and 431.80 would apply to those programs rather than the separate CHIP requirements at §§ 457.730, 457.731, and 457.732. 5. Extensions, Exemptions, and Exceptions lotter on DSK11XQN23PROD with PROPOSALS2 a. Extensions and Exemptions for Medicaid and CHIP FFS Programs Should our proposals regarding the Payer-to-Payer API be finalized as proposed, we would strongly encourage state Medicaid and CHIP FFS programs to implement the Payer-to-Payer API as soon as possible, due to the many anticipated benefits of the API as discussed in this section. However, we also recognize that state Medicaid and CHIP FFS agencies may face certain circumstances that would not apply to other impacted payers. To address these concerns, we are proposing a process through which states may seek an extension of, and, in specific circumstances, an exemption from the Payer-to-Payer API requirements. We propose the following: (1) Extension At the regulation citations identified in Table 3, we propose to provide state Medicaid FFS and CHIP FFS programs the opportunity to request a one-time extension of up to 1 year to implement the Payer-to-Payer API specified at 42 CFR 431.61(b) and 457.731(b). Some states may be unable to meet the proposed compliance date due to challenges related to securing needed funding for necessary contracting and VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 staff resources in time to develop and implement the API requirements, depending on when the final rule is published in relation to a state’s fiscal year, legislative session, budget process, and related timeline. Some states may need to initiate a public procurement process to secure contractors with the necessary skills to support a state’s implementation of these proposed API policies. The timeline for an openly competed procurement process, together with the time needed to onboard the contractor and develop the API, can be lengthy for states. A state might need to hire new staff with the necessary skillset to implement this policy. The time needed to initiate the public employee hiring process, vet, hire, and onboard the new staff may make meeting the proposed compliance timeline difficult because, generally speaking, public employee hiring processes include stricter guidelines and longer time-tohire periods than the other sectors.64 Furthermore, states are currently responding to the effects of the COVID– 19 public health emergency, and their regular operational resources are overextended. Unwinding from the COVID– 19 public health emergency is also expected to require significant IT resources, which could have an impact on future IT work. In all such situations, a state might need more time than other impacted payers to implement the Payer-to-Payer API requirements. The 1year extension that we propose could help mitigate the challenges. We considered delaying implementation of the provisions in this proposed rule an additional year for states, but decided that it would be better to propose to have only those states that needed an extension apply, because states vary in their level of technical expertise and ability to recruit staff and secure contracts. Should the proposal for this API be finalized as proposed, states would be permitted to submit a written application for a one-time, one-year extension as part of their annual APD for MMIS operations expenditures. The state’s request would have to include the following: (1) a narrative justification describing the specific reasons why the state cannot reasonably satisfy the requirement(s) by the compliance date, and why those reasons result from circumstances that are unique to the agency operating the 64 State hiring processes are comparable with Federal hiring processes. According to OMB, the average time-to-hire for Federal employees was 98.3 days in 2018, significantly higher than the private sector average of 23.8 days. See https:// www.opm.gov/news/releases/2020/02/opm-issuesupdated-time-to-hire-guidance/. PO 00000 Frm 00043 Fmt 4701 Sfmt 4702 76279 Medicaid and/or CHIP FFS program (versus other types of impacted payers); (2) a report on completed and ongoing state implementation activities that evidence a good faith effort towards compliance; and (3) a comprehensive plan to meet the Payer-to-Payer API requirements no later than 1 year after the compliance date. Under this proposal, CMS would approve an extension if, based on the information provided in the APD, CMS determines that the request adequately establishes a need to delay implementation, and that the state has a comprehensive plan to implement the proposed requirements no later than 1 year after the compliance date. We also solicit comments on whether our proposal would adequately address the unique circumstances that affect states, and that might make timely compliance with the proposed API requirement difficult for states. (2) Exemption At the CFR sections identified in Table 3, we propose to permit state Medicaid FFS programs to request an exemption from the Payer-to-Payer API requirements when at least 90 percent of the state’s Medicaid beneficiaries are enrolled in Medicaid managed care organizations as defined at 42 CFR 438.2. Likewise, we propose that separate CHIP FFS programs could request an exemption from the Payer-toPayer API requirements if at least 90 percent of the state’s separate CHIP beneficiaries are enrolled in CHIP managed care entities as defined at 42 CFR 457.10. In this circumstance, the time and resources that the state would need to expend to implement the Payerto-Payer API requirements for a small FFS population may outweigh the benefits of implementing and maintaining the API. Unlike other impacted payers, state Medicaid and CHIP FFS programs do not have a diversity of plans to balance implementation costs for those plans with low enrollment. If there is low enrollment in a state Medicaid or CHIP FFS program, there is no potential for the technology to be leveraged for additional beneficiaries. States, unlike other payers, do not maintain additional lines of business. We acknowledge that the proposed exemption could mean that most beneficiaries enrolled with exempted Medicaid or CHIP FFS programs would not receive the full benefits of having this API available to facilitate health information sharing with other payers. To address this, we propose that states that are granted an exemption would be expected to implement an alternative E:\FR\FM\13DEP2.SGM 13DEP2 lotter on DSK11XQN23PROD with PROPOSALS2 76280 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules plan to ensure that other payers will have efficient electronic access to the same information through other means, to help ensure that Medicaid or CHIP services are provided with reasonable promptness and in a manner consistent with simplicity of administration and in the best interests of those beneficiaries who are served under the FFS program. We propose that a state could submit a written request for an exemption from the requirements for the Payer-to-Payer API as part of its annual APD for MMIS operations expenditures prior to the date by which the state would otherwise need to comply with the requirements (which may be extended by 1 year if the state receives an extension). For Medicaid exemption requests, the state would be required to include documentation that it meets the criteria for the exemption based on enrollment data from the most recent CMS ‘‘Medicaid Managed Care Enrollment and Program Characteristics’’ report. For a CHIP FFS exemption, the state’s request would have to include enrollment data from Section 5 of the most recently accepted state submission to CARTS. The state would also be required to include in its request information about an alternative plan to ensure that payers will have efficient electronic access to the same information through other means while the exemption is in effect. CMS would grant the exemption if the state establishes to CMS’s satisfaction that it meets the criteria for the exemption and has established such an alternative plan. We note that the exemption would only apply to the API requirements, not the state’s permission collection obligations. Once an exemption has been approved, we propose that the exemption would expire if either of the following two scenarios occurs: (1) based on the 3 previous years of available, finalized Medicaid T–MSIS and/or CHIP CARTS managed care and FFS enrollment data, the State’s managed care enrollment for 2 of the previous 3 years is below 90 percent; or (2) CMS has approved a State plan amendment, waiver, or waiver amendment that would significantly reduce the share of beneficiaries enrolled in managed care and the anticipated shift in enrollment is confirmed by available, finalized Medicaid T–MSIS and/or CHIP CARTS managed care and FFS enrollment data. For the first scenario, CMS recognizes that there may be circumstances where a state’s managed care enrollment may fluctuate slightly below the 90 percent threshold in 1 year, and yet return to above 90 percent the next year. To help reduce the possible burden on exempted VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 states experiencing this type of temporary fluctuation in managed care enrollment, CMS would consider data from the 3 previous years of available, finalized Medicaid T–MSIS and/or CHIP CARTS managed care and FFS enrollment data. We propose that if the state’s managed care enrollment for 2 of the previous 3 years is below 90 percent, the state’s exemption would expire. We propose that a state would be required to provide written notification to CMS that the state no longer qualifies for the Payer-to-Payer API exemption when data confirm that there has been a shift from managed care enrollment to FFS enrollment resulting in the State’s managed care enrollment falling below the 90 percent threshold for 2 of the previous 3 years. We propose that the written notification be submitted to CMS within 90 days of the finalization of the annual Medicaid T–MSIS managed care enrollment data and/or the CARTS report for CHIP confirming that there has been the requisite shift from managed care enrollment to FFS enrollment in 2 of the 3 previous years. For the second scenario, we recognize that there may be state plan amendments, waivers, or waiver amendments that would result in a shift from managed care enrollment to FFS enrollment. Additionally, there may be instances where anticipated enrollment shifts may not be fully realized due to other circumstances. We propose that a state would be required to provide written notification to CMS that the state no longer qualifies for the Payerto-Payer API exemption when data confirm that there has been a shift from managed care enrollment to FFS enrollment as anticipated in the state plan amendment or waiver approval. We propose that the written notification be submitted to CMS within 90 days of the finalization of the first annual Medicaid T–MSIS managed care enrollment data and/or the CARTS report for CHIP confirming that there has been the requisite shift from managed care enrollment to FFS enrollment. Regardless of why the exemption expires, if it expires, the state would be required to obtain CMS’s approval of a timeline for compliance with the Payerto-Payer API requirements for the state’s Medicaid FFS and/or CHIP FFS population(s) within two years of the expiration date of the exemption. For Medicaid and CHIP managed care, we are not proposing an extension process because we believe that managed care plans are actively working to develop the necessary IT infrastructure to be able to comply with PO 00000 Frm 00044 Fmt 4701 Sfmt 4702 the existing requirements at 42 CFR parts 438 and 457 and because many of them might benefit from efficiencies resulting from the variety of plan types that they offer. Many managed care plans are part of parent organizations that maintain multiple lines of business, including Medicaid managed care plans and plans sold on the Exchanges. As discussed in the CMS Interoperability and Patient Access final rule (85 FR 25607, 25612, and 25620), work done by these organizations can benefit all lines of business and, as such, we do not believe that the proposals in this rule impose undue burden or cannot be achieved by the compliance date. We are soliciting comments on our assumptions regarding the scope of resources and ability of managed care parent organizations to achieve economies of scale when implementing the proposed API. Further, we seek comment on whether an extension process would be warranted for certain managed care plans to provide additional time for the plan to comply with the proposed requirement at 42 CFR 431.61(b) (which cross references at 42 CFR 438.242(b)(7) for Medicaid managed care plans) and at proposed 42 CFR 457.731(b) (which cross references at 42 CFR 457.1233(d)) for CHIP managed care entities. While we are not proposing such a process for managed care plans and entities and do not believe one is necessary, we are open to evaluating options for possible future rulemaking. Were we to adopt an extension process for these managed care plans and entities, what criteria should a managed care plan or entity meet to qualify for an extension? Should the criteria include enrollment size, plan type, or certain unique characteristics that could hinder their achievement of the proposed requirements by the proposed compliance date? We also seek comment on whether, were we to propose such a process for Medicaid managed care plans or CHIP managed care entities, the entity responsible for evaluating the criteria and exception evaluation process should be the state and whether states could implement the exception evaluation process with available resources. Consistent with the exception process proposed for QHP issuers on the FFEs at 45 CFR 156.222(c), we would expect managed care plans seeking extensions to provide, at a minimum, a narrative justification describing the reasons why a plan or entity cannot reasonably satisfy the requirements by the proposed compliance date, an explanation of the impact of non-compliance upon E:\FR\FM\13DEP2.SGM 13DEP2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules enrollees, an explanation of the current or proposed means of providing electronic health information to payers, and a comprehensive plan with a timeline to achieve compliance. We request comment on the proposed extension and exemption processes. lotter on DSK11XQN23PROD with PROPOSALS2 b. Exception for QHP Issuers For QHP issuers on the FFEs, we propose an exception to the Payer-toPayer API proposal at the regulation citations identified in Table 3. We propose that if an issuer applying for QHP certification to be offered through an FFE believes it cannot satisfy the proposed requirements at 45 CFR 156.222(b) for the Payer-to-Payer API, the issuer would have to include as part of its QHP application a narrative justification describing the reasons why the issuer could not reasonably satisfy the requirements for the applicable plan year, the impact of non-compliance upon providers and enrollees, the current or proposed means of providing health information to payers, and VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 solutions and a timeline to achieve compliance with the requirements of this section. We propose that the FFE may grant an exception to the requirements at 45 CFR 156.222(b) for the Payer-to-Payer API if it determines that making qualified health plans of such issuer available through such FFE is in the interests of qualified individuals in the state or states in which the FFE operates, and an exception would be warranted to permit the issuer to offer qualified health plans through the FFE. This proposal would be consistent with the exception for QHP issuers on the FFEs we finalized for the Patient Access API in the CMS Interoperability and Patient Access final rule (85 FR 25552). For instance, as noted in that final rule, that exception could apply to small issuers, financially vulnerable issuers, or new entrants to the FFEs that demonstrate that deploying FHIR API technology consistent with the required interoperability standards would pose a significant barrier to the issuer’s ability PO 00000 Frm 00045 Fmt 4701 Sfmt 4702 76281 to provide coverage to patients, and not certifying the issuer’s QHP or QHPs would result in patients having few or no plan options in certain areas. We believe that having a QHP issuer offer QHPs through an FFE generally is in the best interest of patients and would not want patients to have to go without access to QHP coverage because the issuer is unable to implement this API. In summary, we propose to permit certain impacted payers (state Medicaid and CHIP FFS programs and QHP issuers on the FFEs) to apply for an extension, exemption, or exception, as applicable, from implementing the proposed Payer-to-Payer API. We propose that these programs would submit and be granted approval for an extension or exemption as a part of applicable established processes. We propose that submission requirements would include certain documentation identified in the regulatory citations in Table 3. BILLING CODE 4120–01–P E:\FR\FM\13DEP2.SGM 13DEP2 lotter on DSK11XQN23PROD with PROPOSALS2 76282 Jkt 259001 II.C.3.a. I Technical Standards I 42CFR 422.12l(b )(l)(i) PO 00000 II.C.3.b. I Accessible Content and API Requirements Frm 00046 11.C.3.c. I Optln 11.C.3.c. I Identify Previous Fmt 4701 and/or Concurrent Pavers Data Exchange Requirement Sfmt 4702 11.C.3.d. I 11.C.3.e. I Data Incorporation I 42 CFR 422.121(b)(l)(ii) E:\FR\FM\13DEP2.SGM I Concurrent Coverage Data Exchange Requirements 42CFR 431.6 l(b )( 1)(i) I 42CFR 43 l.61(b )(l)(ii) I I Through proposed cross reference to 42 CFR 431.61(b)(l) at 438.242(b )(7) Through proposed cross reference to 42 CFR 431.6l(b)(l) at 438.242(b )(7) 42CFR 457.73l(b )(l)(i) 42CFR 431.6 lfh V2) 42CFR 431.61(b)(3) NIA 42 CFR 457.731(b)(2) NIA NIA 42 CFR 457.731(b)(3) NIA 42CFR 422.121(b)(4) 42CFR 431.61(b)(4) Through proposed cross reference to 42 CFR 431.61(b)(4) at 438.242(b )(7) Through proposed cross reference to 42 CFR 431.6l(b)(4) at 438.242(b )(7) Through proposed cross reference to 42 CFR 431.6l(b)(5) at 438.242(b )(7) Through proposed cross reference to 42 CFR 431.6l(b)(6)(ii) and (iii) at 438.242(b )(7) 42 CFR 457.73l(b)(4) Through existing cross reference to 42 CFR 438.242 at 42 CFR 457.1233(d) Through existing cross reference to 42 CFR 438.242 at 42 CFR 457.1233(d) Through existing cross reference to 42 CFR 438.242 at 42 CFR 457.1233(d) Through existing cross reference to 42 CFR 438.242 at 42 CFR 457.1233(d) I 42CFR I 42CFR 43 l.61(b )(4)(ii) 42CFR 422.121(b )(5) 42CFR 431.6 l(b )( 5) I 13DEP2 II.C.3.g. I Educational Materials 42CFR 422.121(b )(6) 42CFR 431.6 l(b )( 6) 11.C.5.a. I Extension for NIA 42CFR 431.61(c)(l) I NIA NIA 42CFR 431.61(c)(2) NIA NIA 11.C.5.a. I 11.C.5.b. I Medicaid and CHIP FFS Exemption for Medicaid and CHIP FFS Exceptions for QHP Issuers 42CFR 457. 73 l(b)(1 )(ii) Through existing cross reference to 42 CFR 438.242 at 42 CFR 457.1233(d Through existing cross reference to 42 CFR 438.242 at 42 CFR 457.1233(d 42CFR 422.121(b)(2) 42CFR 422.121(b )(3) 121(b)(4)(ii) 11.C.3.f. I 42CFR 457. 73 l(b)(4)(ii) 42 CFR 457.73 l(b)(5) 42 CFR 457.73l(b)(6) I 45CFR 156.222(b )(l)(i) I 45CFR 156.222(b)(l)(ii) 45CFR 156.222(b )(2) 45CFR 156.222(b )(3) 45CFR 156.222(b )(4) I 45CFR 156.222(b)(4)(ii) I 45CFR 156.222(b)(5) I 45CFR 156.222(b)(6) NIA I NIA I NIA I 42 CFR 457.73l(c)(2) I NIA I NIA I NIA I NIA I 45 CFR 156.222(c) 42 CFR 457.73l(c)(l) I NIA Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules 18:56 Dec 12, 2022 BILLING CODE 4120–01–C VerDate Sep<11>2014 EP13DE22.002</GPH> TABLE 3: PAYER TO PAYER DATA EXCHANGE ON FIDR PROPOSED POLICIES Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules lotter on DSK11XQN23PROD with PROPOSALS2 6. Statutory Authorities for Payer to Payer Data Exchange Proposals a. MA Organizations For MA organizations, we are proposing these Payer-to-Payer API requirements under our authority at section 1856(b) of the Act by which the Secretary may adopt by regulation standards to implement provisions in Part C of Title XVIII of the Act (such as section 1852(d)(1)(A)), section 1852(h) of the Act that requires MA organizations to provide their enrollees with timely access to medical records and health information insofar as MA organizations maintain such information; and section 1857(e)(1) of the Act by which the Secretary may incorporate contract terms and conditions for MA organizations that we determine are necessary, appropriate, and not inconsistent with the statute. We note that in regulations establishing the MA program,65 CMS described it as a program designed to provide for regional plans that may make private plan options available to many more beneficiaries, especially those in rural areas. This was done to enrich the range of benefit choices, provide incentives to plans and add specialized plans to coordinate and manage care in ways that comprehensively serve those with complex and disabling diseases and conditions, use competition to improve service and benefits, invest in preventive care, hold costs down in ways that attract enrollees, and advance the goal of improving quality and increasing efficiency in the overall healthcare system. The proposals throughout this proposed rule support these goals and enable the MA program to advance services for its beneficiary population in one significant way—by providing greater access to information in a way specifically to improve care management for payers, providers, and the patient. Section 1856(b) of the Act requires the Secretary to establish regulatory standards for MA organizations and plans that are consistent with, and carry out, Part C of the Medicare statute, Title XVIII of the Act. The Payer-to-Payer API proposals support one payer sharing certain claims, encounter, and clinical data, as well as prior authorization requests and decisions with another payer identified by the patient. Such exchanges of data about enrollees could facilitate continuity of care and enhance care coordination. As discussed for the 65 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:56 Dec 12, 2022 Jkt 259001 Provider Access API in section II.B. of this proposed rule, allowing payers to share health information for one or more patients at once could increase efficiency and simplicity of administration. Though we are not proposing to require payers to share data for more than one patient at a time, we believe there are efficiencies to doing so, both for communicating information and for leveraging available technology. Thus, the proposal for payers to share information could apply as well to data exchanges using the Payer-to-Payer API. It could give payers access to all their enrollees’ information with limited effort and enable the payer to then make that information available to providers and to enrollees through the Provider Access and Patient Access APIs. And it could reduce the amount of time needed to evaluate a patient’s current care plan and possible implications for care continuity, which could introduce efficiencies and improve care. As discussed earlier, if a new payer is able to receive information and documentation about prior authorization requests from a previous payer, the new payer could review this information and determine that a new prior authorization may not be necessary for an item or service that was previously approved. Instead, the same care could be continued, reducing burden on both payers and providers and improving patient care. While the statutory provisions governing the MA program do not explicitly address sharing data with other payers that cover or have covered an enrollee, we believe that the benefits to be gained by sharing data make adoption of Payer-toPayer API policies proposed here necessary and appropriate for the MA program. Further, requiring use of the API and the specifications for the data to be shared provides a step toward greater interoperability among payers. Ultimately, using the Payer-to-Payer API is anticipated to ensure that payers receive patient information in a timely manner, which could lead to more appropriate service utilization and higher beneficiary satisfaction, consistent with sections 1856(b) and 1857(e) of the Act. Section 1852(h) of the Act requires MA organizations to provide their enrollees with timely access to medical records and health information insofar as MA organizations maintain such information. As technology evolves to allow for faster, more efficient methods of information transfer, so do expectations as to what is generally considered ‘‘timely.’’ Currently, consumers across public and private PO 00000 Frm 00047 Fmt 4701 Sfmt 4702 76283 sectors have become increasingly accustomed to accessing a broad range of personal records, such as bank statements, credit scores, and voter registrations, immediately through electronic means and with updates received in near real-time. Thus, we believe that to align our standards with current demands, we must take steps for MA enrollees to have immediate, electronic access to their health information and plan information. The information exchanged via the proposed Payer-to-Payer API would ultimately be accessible to enrollees via the Patient Access API and would therefore improve timeliness to medical records and health information as enrollees would no longer have to spend time contacting previous payers to access their information. These data would be accessible as needed by the enrollee’s current payer and would therefore support timely access. Section 1852(d)(1)(A) requires MA organizations to, as a condition of using a network of providers, make covered benefits available and accessible to enrollees in a manner which assures continuity in the provision of benefits. In implementing section 1852(d)(1)(A) of the Act, we adopted a regulation, at 42 CFR 422.112(b), that requires MA organizations to ensure the continuity of care and integration of services through arrangements with providers that include procedures to ensure that the MA organization and the contracted providers have access to the information necessary for effective and continuous patient care. Consistent with section 1852(d)(1)(A) of the Act, we believe our proposal here for MA organizations to implement and maintain a Payer-toPayer API would facilitate exchanges of information about enrollees that are necessary for effective and continuous patient care. Under our proposal, the data received from other impacted payers would become part of the data the MA organization maintains and would therefore be available (subject to other law authorizing the disclosure) to providers via the Provider Access API discussed in section II.B. of this proposed rule; the data could then be used for treatment and coordination of care purposes. b. Medicaid and CHIP Our proposals in this section above fall generally under our authority in the following provisions of the Act. • Section 1902(a)(4) of the Act, which requires that a state Medicaid plan provide such methods of administration as are found by the Secretary to be necessary for the proper and efficient operation of the state Medicaid plan. E:\FR\FM\13DEP2.SGM 13DEP2 lotter on DSK11XQN23PROD with PROPOSALS2 76284 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules • Section 1902(a)(8) of the Act, which requires states to ensure that Medicaid services are furnished with reasonable promptness to all eligible individuals. • Section 1902(a)(19) of the Act, which requires states to ensure that care and services are provided in a manner consistent with simplicity of administration and the best interests of the recipients. We believe these proposals related to the Payer-to-Payer API are authorized by section 1902(a)(4), (a)(8), and (a)(19) of the Act for the following reasons. First, because the Payer-to-Payer API is designed to enable efficient exchange of data between payers, if finalized as proposed, we anticipate that it would help state Medicaid programs improve the efficiencies and simplicity of their own operations, consistent with sections 1902(a)(4) and (a)(19) of the Act. It could give Medicaid and CHIP agencies and their managed care plans access to their beneficiary’s information in a standardized manner and enable the state to then make that information available to providers and to patients through the Patient Access and Provider Access API. It could also reduce the amount of time needed to evaluate a patient’s current care plan and possible implications for care continuity, which could introduce efficiencies and improve care. Receiving patient information at the start of coverage would help to ensure Medicaid and CHIP agencies and those managed care plans considered impacted payers under this proposed rule could lead to more appropriate service utilization and higher beneficiary satisfaction by supporting efficient care coordination and continuity of care, which could lead to better health outcomes. As discussed in section II.C.3.a. of this proposed rule, if a state Medicaid program has access to a previous payer’s prior authorization decisions, the Medicaid program could choose to accept the existing decision and support continued patient care without requiring a new prior authorization or duplicate tests. This information exchange might also improve care continuity for beneficiaries who have concurrent coverage in addition to Medicaid by improving the coordination of health coverage they receive, reducing gaps, or duplication of coverage. Our proposals, if finalized, are expected to help states and managed care plans furnish Medicaid services with reasonable promptness and in a manner consistent with beneficiaries’ best interests, consistent with section 1902(a)(8) and (a)(19) of the Act. A significant portion of Medicaid VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 beneficiaries experience coverage changes and churn in a given year.66 Therefore, exchanging this information with a beneficiary’s next payer could also better support care continuity for Medicaid beneficiaries. If states were to share information about Medicaid beneficiaries or former beneficiaries with their concurrent and next payers, they could support opportunities for improved care coordination for Medicaid beneficiaries and former beneficiaries. Exchanging information about Medicaid beneficiaries and former beneficiaries between payers might also reduce the amount of time needed to evaluate beneficiaries’ current care plans, their health risks, and their health conditions at the time they enroll with the Medicaid program, as well as with another payer. This information exchange might be of particular value to improve care continuity for beneficiaries who might churn into and out of Medicaid coverage. The proposal could also improve the provision of Medicaid services, by potentially helping to ensure that Medicaid beneficiaries who may require coordinated services with concurrent payers could be identified and provided case management services, reduce duplication of services, and improve the coordination of care, as appropriate. In addition, section 1902(a)(7) of the Act requires that states must provide safeguards that restrict the use or disclosure of information concerning Medicaid applicants and beneficiaries to uses or disclosures of information that are directly connected with the administration of the Medicaid state plan. The implementing regulations for this section of the Act list purposes that CMS has determined are directly connected to Medicaid state plan administration at 42 CFR 431.302. We believe that requiring the data described in this section to be shared via the Payer-to-Payer API would be consistent with states’ requirements to provide safeguards to share these data since it is related to providing services for beneficiaries, a purpose listed in § 431.302(c). As described above in the section related to authority under sections 1902(a)(8) and 1902(a)(19) of the Act, states that share information about Medicaid beneficiaries or former 66 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 00048 Fmt 4701 Sfmt 4702 beneficiaries with their concurrent and next payers, could support opportunities for improved care coordination, reduction in the amount of time needed to evaluate beneficiaries’ current care plans, their health risks, and their health conditions at the time they enroll with the Medicaid program, as well as with another payer. This information exchange might be of particular value to improve care continuity for beneficiaries who churn into and out of Medicaid coverage, described in more detail above. When state Medicaid or CHIP agencies share medical records or any other health or enrollment information pertaining to individual beneficiaries, they must comply with 42 CFR 431.306. See discussion above about how the opt in process proposed for this API would help states comply with 42 CFR 431.306. For Medicaid managed care plans, the proposed exchange of all data classes and data elements included in a content standard adopted at 45 CFR 170.213, adjudicated claims and encounter data, as well as the patient’s prior authorization requests and decisions would greatly enhance an MCO’s, PIHP’s, or PAHP’s ability to fulfill its obligations under 42 CFR 438.208(b) which require them to: implement procedures to deliver care to and coordinate services including ensuring that each enrollee has an ongoing source of appropriate care; coordinate services between settings of care, among Medicaid programs, and with community and social support providers; make a best effort to conduct an initial screening of each enrollee’s needs; and share with the state or other MCOs, PIHPs, and PAHPs serving the enrollee the results of any identification and assessment of that enrollee’s needs to prevent duplication of those activities. The data provided via the Payer-to-Payer API proposed in this rule would give managed care plans the information needed to perform these required functions much more easily, thus enhancing the effectiveness of the care coordination, and helping enrollees receive the most appropriate care in an effective and timely manner. For CHIP, we are proposing these requirements under our authority in section 2101(a) of the Act, which states that the purpose of Title XXI of the Act is to provide funds to states to provide child health assistance to uninsured, low-income children in an effective and efficient manner that is coordinated with other sources of health benefits coverage. We believe the provisions in this proposed rule could strengthen our ability to fulfill these statutory E:\FR\FM\13DEP2.SGM 13DEP2 lotter on DSK11XQN23PROD with PROPOSALS2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules obligations in a way that recognizes and accommodates using electronic information exchange in the healthcare industry today and would facilitate a significant improvement in the delivery of quality healthcare to our beneficiaries. As with the Medicaid FFS and Medicaid managed care programs, the proposals in this section of the proposed rule for CHIP FFS and CHIP managed care entities, require using a Payer-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 could use data from the previous payer to respond to a request for a prior authorization more effectively or accurately, because under this proposal, a new payer would have historical claims or clinical data upon which they may review a request with more background data. Access to information about new patients could enable appropriate staff within the CHIP program to coordinate care and conduct care management more effectively because they would have better data available to make decisions for planning. In many cases, patients do not remember what services they have had, what vaccines they have had, or other possibly relevant encounters that could help payers manage their care. This proposal is consistent with the goal of providing more informed and effective care coordination, which could help to ensure that CHIP services are provided in a way that supports quality care, which aligns with section 2101(a) of the Act. Finally, the safeguards for applicant and beneficiary information at subpart F of 42 CFR part 431 are also applicable to CHIP through a cross-reference at 42 CFR 457.1110(b). As discussed above for Medicaid, CHIP agencies’ data exchange through the Payer-to-Payer API would be related to providing services to beneficiaries, which is described at 42 CFR 431.302(c) as a purpose directly related to state plan administration. We remind states that when they share medical records or any other health or enrollment information pertaining to individual beneficiaries, they must comply with the privacy protections at 42 CFR 457.1110 and the release of information provisions at 42 CFR 431.306. See discussion above about how the opt in process proposed for this API would help states comply with 42 CFR 431.306. c. QHP Issuers on the FFEs For QHP issuers on the FFEs, we are proposing these new requirements VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 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 would allow the seamless flow of all data classes and data elements included in a standard in 45 CFR 170.213, adjudicated claims and encounter data as well as the patient’s prior authorization requests and decisions, from payer to payer. We believe that ensuring a means for an enrollee’s new issuer to electronically obtain the enrollee’s claims, encounter, and other data, as well as prior authorization information with corresponding medical records, from the previous issuer would reduce administrative burden and result in more timely and efficient care coordination and responses to prior authorization requests. We believe it is in the interest of qualified individuals that QHP issuers on FFEs have systems in place to send information important to care coordination with departing enrollees, and that QHP issuers on FFEs also have systems in place to receive such information from payer to payer on behalf of new and concurrent enrollees, as appropriate and consistent with the proposals in this section. Therefore, we believe certifying health plans that make enrollees’ health information available to other payers in a convenient, timely, and portable way is in the interests of qualified individuals in the state in which an FFE operates. We encourage SBEs to consider whether a similar requirement should be applicable to QHP issuers participating in their Exchange. Though we are not requiring the exchange of all enrollee’s data at one time between issuers, we encourage QHP issuers on the FFEs to use the Bulk Specification for the Payer-to-Payer API once it is available as we believe it would improve the efficiency and simplicity of data transfers between issuers by enabling the exchange of all data for all patients at once. We believe the opportunity to support an exchange of large volumes of patient data, rather than data for one patient at a time, may be cost effective for the issuers. Having patient information at the beginning of a new plan could assist the new payer in identifying patients who need care management services, which could reduce the cost of care. Taking in PO 00000 Frm 00049 Fmt 4701 Sfmt 4702 76285 volumes of data would also enable the QHPs to perform analysis on the types of new patients in their plan if they choose to analyze data for existing patients as well. D. Improving Prior Authorization Processes 1. Background This section of the proposed rule addresses the topic of prior authorization and includes both technical and operational proposals that are intended to improve the prior authorization process for payers, providers, and patients. Here we propose to require payers to do the following: implement and maintain an API to support and streamline the prior authorization process; respond to prior authorization requests within certain timeframes; provide a clear reason for prior authorization denials; and publicly report on prior authorization approvals, denials, and appeals. The proposals in this rule would build on the foundation set out in the CMS Interoperability and Patient Access final rule (85 FR 25510) to improve health information exchange and increase interoperability in the healthcare system. These proposals were developed based on input from CMSsponsored listening sessions and stakeholder meetings which included payers, providers, vendors, and patients, as well as reports prepared and released by HHS or its Federal advisory committees, such as the National Committee on Vital and Health Statistics (NCVHS) and the Health Information Technology Advisory Committee (HITAC). The proposals would apply to any formal decision-making process through which impacted payers render an approval or denial determination in response to prior authorization requests based on the payer’s coverage guidelines and policies before services are rendered or items provided. As discussed in section I.A.1., because the processes and standards for prior authorization applicable to drugs differ from other items and services, this proposed rule would not apply to any drugs, meaning any drugs that could be covered by the impacted payers in this proposed rule. As such, this proposed rule would not apply to outpatient drugs, drugs that may be prescribed, those that may be administered by a physician, or that may be administered in a pharmacy, or hospital. We propose a definition for this exclusion for each impacted payer in the regulation text of this proposed rule, and provide a reference to the CFR sections where E:\FR\FM\13DEP2.SGM 13DEP2 lotter on DSK11XQN23PROD with PROPOSALS2 76286 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules these definitions would be added for MA organizations, Medicaid FFS, Medicaid Managed Care Plans, CHIP FFS, CHIP Managed Care Entities, and the QHPs on the FFEs in Table 7. Each definition explains that drugs excluded from this proposal for prior authorization for items and service requirements are defined as ‘‘any and all drugs covered by any of the impacted payers addressed in the proposed rule.’’ Also, as mentioned in section I.A, Medicare FFS is not directly affected by this proposed rule. However, the Medicare FFS program is evaluating opportunities to improve automation of prior authorization processes. If our proposals are finalized, Medicare FFS would align its efforts for implementation of the requirements as feasible. We seek comment on whether this could be implemented as proposed for the Medicare FFS program, how we could apply the proposals below, and if there would be differences for implementing the PARDD API in the Medicare FFS program as a Federal payer. We use the term prior authorization to refer to the process by which a provider must obtain approval from a payer before providing care in order to receive payment for delivering items or services. Prior authorization has an important place in the healthcare system, but the process of obtaining prior authorization can be challenging for patients, providers, and payers. Stakeholders, including payers and providers, have claimed that dissimilar payer policies, provider workflow challenges, inconsistent use of electronic standards, and other technical barriers have created an environment in which the prior authorization process is a primary source of burden for both providers and payers, a major source of burnout for providers, and can become a health risk for patients if inefficiencies in the process cause care to be delayed. HHS has been studying prior authorization processes and their associated burden for several years to identify the primary issues that might need to be addressed to alleviate the burdens of these processes on patients, providers, and payers. For example, to advance the priorities of the 21st Century Cures Act (Pub. L. 114–255),67 specifically to reduce the burden associated with the use of EHR technology, ONC and CMS created a 67 Office of the National Coordinator (2020). Strategy on Reducing Burden Relating to the Use of Health IT and EHRs. Retrieved from https:// www.healthit.gov/topic/usability-and-providerburden/strategy-reducing-burden-relating-usehealth-it-and-ehrs. VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 work group to study prior authorization and identify opportunities for potential solutions. As identified by that work group, and in the reports highlighted in this proposed rule, burdens associated with prior authorization include difficulty determining payer-specific requirements for items and services that require prior authorization; inefficient use of provider and staff time processing prior authorization requests and information (sending and receiving) through fax, telephone, and web portals; and unpredictable wait times to receive payer decisions. The ONC report ‘‘Strategy on Reducing Regulatory and Administrative Burden Relating to the Use of Health IT and EHRs’’ fulfills the statutory requirements of section 4001 of the 21st Century Cures Act. Page eight of this report summarized the challenge with the following statement: ‘‘Payers and health IT developers have generally addressed prior authorization in an ad hoc manner, implementing unique interfaces to facilitate documentation and sharing of information that reflect their own technology considerations, lines of business, and customer-specific constraints.’’ 68 In 2018, the American Medical Association (AMA) conducted a physician survey that noted issues with prior authorization. In December 2020, the AMA released the results of a second member survey, which indicated that provider burdens related to prior authorization had not improved, but rather had gotten worse, indicating a weekly per-physician average of 41 prior authorization requests, which consume an average of 13 hours of practice time per workweek for physicians and their staff. Additionally, 40 percent of physicians employ staff to work exclusively on prior authorizations.69 Most physicians responding to the 2020 survey reported ongoing difficulties determining whether an item or service required authorization. Additionally, physicians reported that most prior authorizations are still done through phone calls and faxes, with only 26 percent reporting that they have an EHR system that supports electronic prior authorization for prescription medications.70 68 Office of the National Coordinator (2020). Strategy on Reducing Regulatory and Administrative Burden Relating to the Use of Health IT and EHRs. Retrieved from https:// www.healthit.gov/sites/default/files/page/2020-02/ BurdenReport_0.pdf. 69 American Medical Association (2021). AMA Prior Authorization (PA) Physician Survey Results. Retrieved from https://www.ama-assn.org/system/ files/prior-authorization-survey.pdf. 70 American Medical Association (2021). Measuring Progress in Improving Prior PO 00000 Frm 00050 Fmt 4701 Sfmt 4702 The burden of prior authorization is not experienced solely by physicians; hospitals are also burdened by prior authorization processes. In a November 4, 2019 letter to the CMS Administrator, the American Hospital Association (AHA) described the ongoing impact of prior authorization on patient care, health system costs, and administrative burdens.71 In that letter, the AHA shared results from the previously referenced 2018 AMA survey of more than 1,000 physicians. According to the AHA, hospitals and provider offices have many full-time employees whose sole role is to manage payer prior authorization requests. According to the AHA survey, one 17-hospital system reported spending $11 million annually just to comply with health plan prior authorization requirements. Operational costs such as these are often factored into negotiated fees or charges to patients to ensure financial viability for healthcare organizations, including providers and facilities. In 2019, CMS conducted several listening sessions with payers, providers, patients, and other industry representatives to gain insight into issues with prior authorization processes and identify potential areas for improvement. While providers and payers agreed that prior authorization provides value to the healthcare system for cost control, utilization management, and program integrity, some stakeholders explained that certain steps in prior authorization processes present an undue burden. For example, the information payers require from providers to evaluate or review a prior authorization can be inconsistent from payer to payer, and it can be difficult for providers to determine the rules for items or services that require prior authorization, or to identify what documentation is needed to obtain approval. Furthermore, documentation requirements are not standardized across payers, and access to the requirements may require the use of proprietary portals. These same types of challenges were described in ONC’s 2020 Strategy on Reducing Regulatory and Administrative Burden Relating to the Use of Health IT and EHRs, which reported that ‘‘[e]ach payer has different requirements and different submission methods, and clinicians report finding it burdensome and time-consuming trying Authorization. Retrieved from https://www.amaassn.org/system/files/2021-05/prior-authorizationreform-progress-update.pdf. 71 American Hospital Association (2019). RE: Health Plan Prior Authorization. Retrieved from https://www.aha.org/system/files/media/file/2019/ 11/aha-to-cms-health-plan-prior-authorization-114-19.pdf. E:\FR\FM\13DEP2.SGM 13DEP2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules lotter on DSK11XQN23PROD with PROPOSALS2 to determine whether prior authorization requirements exist for a given patient, diagnosis, insurance plan, or state.’’ 72 In March and November of 2019, two Federal advisory committees, the HITAC 73 and NCVHS,74 held joint hearings with industry representatives including payers, providers, vendors, and standards development organizations to discuss persistent challenges with prior authorization workflows and standards. During these hearings, payers and providers again agreed that the solutions to the challenges with prior authorization processes are multi-faceted. Many participants suggested that improvement of prior authorization required changes in process, policy, and technology, and reiterated the need for convergence on those three elements to improve the overall process. At the November 13, 2019, NCVHS Full Committee meeting,75 industry participants discussed prior authorization standards and processes. The themes from panelists were consistent with the information described in this proposed rule for changes needed in technology, payer transparency with respect to prior authorization requirements, and provider workflow. At the meeting, AHIP reported the results of its 2019 fall plan survey, which included both AHIP member and non-AHIP-member plans, and noted that plans were evaluating opportunities to improve prior authorization processes. In 2020, AHIP launched a pilot of alternative prior authorization strategies with several plans.76 The study was completed at the end of that year, and a report was published in March 2021. In that report, AHIP wrote that an independent 72 Office of the National Coordinator (2020). Strategy on Reducing Regulatory and Administrative Burden Relating to the Use of Health IT and EHRs. Retrieved from https:// www.healthit.gov/sites/default/files/page/2020-02/ BurdenReport_0.pdf. 73 Office of the National Coordinator (2022). Health Information Technology Advisory Committee (HITAC). Retrieved from https:// www.healthit.gov/topic/federal-advisorycommittees/health-information-technologyadvisory-committee-hitac-history. 74 National Committee on Vital and Health Statistics (2022). Charter. Retrieved from https:// ncvhs.hhs.gov/about/charter/. 75 National Committee on Vital and Health Statistics (2019). Committee Proceedings [Transcript]. Retrieved from https://ncvhs.hhs.gov/ wp-content/uploads/2019/12/Transcript-FullCommittee-Meeting-November-13-2019.pdf. 76 America’s Health Insurance Plans (2020). New Fast PATH Initiative Aims to Improve Prior Authorization for Patients and Doctors. Retrieved from https://www.ahip.org/news/press-releases/ new-fast-path-initiative-aims-to-improve-priorauthorization-for-patients-and-doctors. VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 evaluator examined over 40,000 prior authorization transactions over a 12month period from the participating health insurance providers (that is, payers) and conducted a survey of over 300 clinicians and practice staff who used electronic prior authorization technologies to assess the impact of electronic prior authorization on provider practices and patient care. The key findings from the study include a 69 percent reduction in median time between submitting a prior authorization request and receiving a decision. The study also found improved timeliness to care and lower provider burden from phone calls and faxes.77 In early 2020, NCVHS and HITAC convened another task force, the Intersection of Clinical and Administrative Data (ICAD) Task Force. The overarching charge to the Task Force was to bring together industry experts and produce recommendations related to electronic prior authorizations.78 The ICAD Task Force presented its report to HITAC in November 2020.79 Several recommendations pertaining to the use of FHIR APIs for prior authorization were included in the ICAD Task Force report and are consistent with proposals in this proposed rule. These recommendations from HITAC and others are described in more detail in section II.F. of this proposed rule. The first guiding principle in the ICAD report is that the patient is at the center of care and emphasis should be on process solutions that remove roadblocks to care and support the coordination of timely care while reducing burdens, improving the patient experience, and ultimately improving outcomes.80 Underlying the first principle are seven characteristics for the ideal state of the prior authorization processes: (1) removing burden from patients and caregivers to push the process forward; (2) price transparency; (3) shared decision-making processes between clinician and patient; (4) 77 America’s Health Insurance Plans (2021). Reduced Burden and Faster Decision Times Among Benefits of Implementing Electronic Prior Authorization. Retrieved from https:// www.ahip.org/wp-content/uploads/202103-AHIP_ FastPATH-2pg-v03.pdf. 78 Office of the National Coordinator (2022). Intersection of Clinical and Administrative Data Task Force. Retrieved from https:// www.healthit.gov/hitac/committees/intersectionclinical-and-administrative-data-task-force. 79 Health Information Technology Advisory Committee (2020). A Path Toward Further Clinical and Administrative Data Integration. Retrieved from https://www.healthit.gov/sites/default/files/ page/2020-11/2020-11-17_ICAD_TF_FINAL_ Report_HITAC.pdf. 80 Id. at pages 31–33. PO 00000 Frm 00051 Fmt 4701 Sfmt 4702 76287 information about coverage and potential denials are made available to the patient and provider; (5) tools are available for all patients to lessen burden and overcome barriers related to the digital divide, access, socioeconomic factors, and literacy; (6) patients are able to share data bidirectionally with third parties electronically from an application of their choice; (7) patients have the choice to use a third-party credential/ authorization/consent service to support seamless access to all of their data with minimal effort. The HITAC and NCVHS Federal advisory committee reports, as previously mentioned, describe the need for process improvements for prior authorization, which echo the input CMS received from its payer and provider stakeholder meetings and industry surveys. We believe our proposals, if finalized as proposed, would make meaningful progress to improve prior authorization processes, alleviate burdens, facilitate more equitable access to care, and support efficient operations for providers and payers. As discussed in section I.A. of this proposed rule, in December 2020, CMS published the December 2020 CMS Interoperability proposed rule, in which we made proposals to streamline the prior authorization process. In general, payers and providers supported the intent of the proposed rule, however, they also requested that CMS include the Medicare Advantage program as an impacted payer and evaluate the implementation dates for the APIs. As stated in section I.A., we are withdrawing the December 2020 CMS Interoperability proposed rule and issuing this new proposed rule that incorporates the feedback we received from stakeholders. We understand that many readers may already be familiar with that proposed rule, and to distinguish the differences between the proposals, we refer readers to the discussion in section I.A. which outlines the overarching differences between this proposed rule and the prior proposed rule. There are additional differences specific to proposals in this section. First, we have modified the name and description of the standards-based APIs intended to support prior authorization processes but have not changed the purpose of those APIs. In this proposed rule, we refer to two of the previously proposed APIs collectively as the Prior Authorization Requirements, Documentation, and Decision (PARDD) API. In the December 2020 CMS Interoperability proposed rule, we E:\FR\FM\13DEP2.SGM 13DEP2 76288 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules lotter on DSK11XQN23PROD with PROPOSALS2 referred to these two APIs separately, calling them the Document Requirement Lookup Service (DRLS) API and the Prior Authorization Support (PAS) API. The proposed PARDD API functionality combines the functionality of the previously proposed DRLS and PAS APIs. Second, we are proposing to change the implementation date for many of the proposals in this section to January 1, 2026. We note that some of the Medicaid FFS fair hearings and notice proposals discussed in section II.D.6.b. would take effect before that date if this proposed rule were finalized as proposed. 2. Electronic Options for Prior Authorization While there is a standard available for electronic prior authorization transactions, adopted by HHS under the provisions of the Health Insurance Portability and Accountability Act of 1996 (HIPAA), many payers and providers do not use this adopted standard (the X12 278 Version 5010). Instead, payers build proprietary interfaces and web portals through which providers submit their requests, and both still frequently resort to phone calls or faxes to complete the process for a response. The process may remain inefficient, burdensome, and create service issues for patients. As previously explained, providers indicate that the main hurdle is knowing which services require prior authorization, and what documentation is necessary to support that service or item. The current processes or standard do not address this barrier. In section II.B.2. of this proposed rule, we reference the transactions for which the Secretary must adopt standards for use by HIPAA-covered entities (for example, health plans, health care clearinghouses, and certain health care providers), and list the transactions for which a standard must be adopted. The HIPAA-adopted standards for referral certifications and authorizations, also referred to as the prior authorization transaction standards (45 CFR 162.1302), are the— • National Council for Prescription Drug Programs (NCPDP) Telecommunication Standard Implementation Guide Version D.0 for retail pharmacy drugs; and • ASC X12 Version 5010x217 278 (X12 278) for dental, professional, and institutional requests for review and response. While the prior authorization proposals in this proposed rule do not apply to any drugs, we reference the NCPDP standard for retail pharmacy transactions to acknowledge it as one of VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 the two mandated standards for prior authorization adopted under HIPAA. The X12 278 standard was adopted for the prior authorization of medical items and services. Though payers are required to use the X12 278 version 5010 standard for electronic prior authorization transactions and providers are encouraged to conduct the transaction electronically, the X12 278 has not achieved a high adoption rate by covered entities. The Council for Affordable and Quality Health Care (CAQH) releases an annual report, the CAQH Index, which includes data on health plan and provider adoption of HIPAA standard transactions. In the 2019 report, among the seven transactions benchmarked, prior authorization using the X12 278 standard was the least likely to be supported by payers, practice management systems, vendors, and clearinghouse services.81 According to that year’s report, 13 percent of the respondents indicated that they were using the adopted standard in a fully electronic way, while 54 percent responded that they were conducting electronic prior authorization using web portals, Integrated Voice Response (IVR), and other options, and 33 percent were using fully manual processes such as phone, mail, fax, and email. The 2021 report 82 showed an incremental increase in the use of the X12 278 prior authorization standard of 26 percent. The report stated that the overall volume remained stable, but the volume of transactions conducted using the HIPAA mandated standard for prior authorizations increased, possibly due to payer portal enhancements and provider interest in moving to electronic submissions for prior authorization requests. According to the CAQH Index, reported barriers to using the HIPAA standard include ‘‘lack of vendor support for provider systems, inconsistent use of data content from the transaction, and lack of an attachment standard to submit required medical documentation.’’ Enhancements to the electronic prior authorization process could support greater use of the HIPAA X12 278 standard through automation, which could also reduce the time for submission of the request and response. 81 CAQH (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. 82 CAQH (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. PO 00000 Frm 00052 Fmt 4701 Sfmt 4702 In the following discussion, we propose to require impacted payers to implement an HL7 FHIR API that would work in combination with the adopted HIPAA transaction standard to conduct the prior authorization process. It is important to note that we are not proposing changes to the requirement for covered entities to use the adopted HIPAA transaction standard but are proposing to require that impacted payers develop and implement an API that works together with that standard, and may support greater use of the X12 278 standard. As previously noted, section 1104 of the Affordable Care Act amended HIPAA to also require that HHS adopt operating rules for the HIPAA standard transactions. ‘‘Operating rules’’ are defined at 45 CFR 162.103 as the ‘‘necessary business rules and guidelines for the electronic exchange of information that are not defined by a standard or its implementation specifications as adopted for purposes of HIPAA Administrative Simplification.’’ The NCVHS reviews potential HIPAA operating rules and advises the Secretary as to whether HHS should adopt them (section 1173(g) of the Act). The Secretary adopts operating rules through regulation in accordance with section 1173(g)(4) of the Act. To date, HHS has adopted operating rules for three of the HIPAA standard transactions: eligibility for a health plan and health care claim status (76 FR 40457), health care Electronic Funds Transfer (EFT), and remittance advice (77 FR 48007). In February 2020, CAQH, which develops operating rules for some of the HIPAA standards, submitted two operating rules for NCVHS review regarding HIPAA referral certification and authorization transaction. NCVHS held a hearing to discuss those operating rules in August 2020 and submitted a letter to the HHS Secretary in November 2020 recommending pilot testing to evaluate the proposed operating rules rather than immediate adoption. At this time, NCVHS has not recommended that HHS adopt operating rules for the HIPAA referral certification and authorization transaction. Should NCVHS make such a recommendation, we would evaluate the effect, if any, on the policies included in this proposed rule. Even if this rule is finalized as proposed we would continue to evaluate the impact of an NCVHS recommendation and any separate actions by HHS in that regard. E:\FR\FM\13DEP2.SGM 13DEP2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules In March 2021, HHS approved an application 83 from an industry group of payers, providers, and vendors for an exception under 45 CFR 162.940 from the HIPAA transaction standards. The approved exception allows testing of proposed modifications to HIPAA requirements—specifically for the prior authorization standard. Under this exception, the group would test a prior authorization exchange using the HL7 FHIR standard without the X12 278 standard, to determine whether this alternative standard for prior authorization could improve efficiency. HHS provides information about requests for exceptions from standards to permit testing of proposed modifications on the CMS HIPAA administrative simplification website.84 We note that our proposals in the following discussion are intended to work together with the adopted X12 278 standard. 3. Proposed Requirement for Payers: Implement an API for Prior Authorization Requirements, Documentation, and Decision (PARDD API) a. Prior Authorization Requirements, Documentation, and Decision (PARDD) API lotter on DSK11XQN23PROD with PROPOSALS2 To help address prior authorization process challenges and continue following our roadmap to interoperability, we propose to require that, beginning January 1, 2026, certain payers implement and maintain a FHIR Prior Authorization Requirements, Documentation, and Decision (PARDD) API to be used by providers to facilitate the prior authorization process. We note that in section II.A.2.a., we are proposing that payers make information about prior authorization decisions available to patients through the Patient Access API to help them be more informed decision makers and partners in their healthcare. The proposals in this section are specific to improving the prior authorization process between payers and providers using the PARDD API. These policies taken together help to facilitate a more streamlined and better-informed healthcare team in which patients, providers, and payers have access to the status of prior authorizations. 83 Da Vinci Project (2021). Da Vinci HIPAA Exception. Retrieved from https://confluence. hl7.org/display/DVP/Da+Vinci+HIPAA+Exception. 84 Centers for Medicare & Medicaid Services (2022). Go-to-Guidance, Guidance Letters. Retrieved from https://www.cms.gov/Regulations-andGuidance/Administrative-Simplification/ Subregulatory-Guidance/Go-to-Guidance-GuidanceLetters. VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 The PARDD API would streamline the prior authorization process for the provider or office staff by automating certain tasks, thereby mitigating some of the obstacles of the existing prior authorization process. The API would allow a provider to query the payer’s system to determine whether a prior authorization was required for certain items and services and identify documentation requirements. The API would also automate the compilation of necessary data for populating the HIPAA-compliant prior authorization transaction and enable payers to provide the status of the prior authorization request, including whether the request has been approved or denied. Covered entities would continue to send and receive the HIPAA-compliant prior authorization transactions while using the FHIR PARDD API. In the following discussion, we propose to require certain standards and recommend several others that would support the build of this API, while maintaining compliance with the mandated HIPAA standard for prior authorization. To implement the API, we propose to require the use of certain IGs adopted at 45 CFR 170.215. We also propose that impacted payers would use the same documentation requirements and the same discontinuation and denial of access requirements as we are proposing for the Patient Access API (discussed in section II.A.2), the Provider Access API (section II.B.2), and the Payer-to-Payer API (section II.C.3). We believe that consistency in applying these requirements to all proposed APIs would minimize the cost and burden of implementation and support payer risk mitigation strategies. Should this proposal be finalized as proposed, we would also recommend using certain HL7 FHIR Da Vinci IGs which have been developed specifically to support the functionality of the PARDD API. These include: • The HL7 FHIR Da Vinci Coverage Requirements Discovery (CRD) Implementation Guide. • The HL7 FHIR Da Vinci Documentation Templates and Rules (DTR) Implementation Guide. • The HL7 FHIR Da Vinci Prior Authorization Support (PAS) Implementation Guide. The CRD IG provides information about whether an authorization is required for certain items or services and provides transparency into the payers’ prior authorization coverage rules, so the provider knows what information is necessary to support a request. The DTR IG provides the means to ensure the completion of documentation needed to demonstrate PO 00000 Frm 00053 Fmt 4701 Sfmt 4702 76289 medical necessity for a proposed item or service, based on payer requirements. The PAS IG uses the FHIR standard as the basis for (1) assembling the information necessary to substantiate the clinical need for a particular treatment, and (2) submitting the assembled information and prior authorization request to an intermediary before it is sent to the intended recipient. Under the workflow specified in the PAS IG, to meet regulatory requirements for the HIPAA standard transactions discussed previously, the FHIR interface communicates with an intermediary (for example, a clearinghouse) that converts the FHIR requests to a HIPAA-compliant X12 278 request transaction for submission to the payer. In some cases, the payer may act as the intermediary or clearinghouse and convert the request to a HIPAAcompliant X12 278 transaction. Under the workflow specified in the PAS IG, the response from the payer would then flow back through the intermediary using X12 278 and would be made available to the provider’s health IT system using the FHIR standard. The response would indicate whether the payer approves (and for how long), or denies (and the reason), the prior authorization request, or request more information from the provider to support the prior authorization request. This IG also defines capabilities around the management of prior authorization requests, including checking on the status of a previously submitted request, revising a previously submitted request, and canceling a request. The goal is to provide information about prior authorization, where possible, in the provider’s clinical workflow. We refer to section II.F. of this proposed rule for further discussion of the required and recommended standards to support the PARDD API. To reiterate, for the reasons explained in section I.A., we are not proposing to apply the proposals for the PARDD API to any drugs. Based on a review of Medicare FFS policies and prior authorization requirements, as well as industry pilots and demonstrations, we understand payers may have hundreds of policies that could be included in the PARDD API. The initial phase of identifying and evaluating all the policies may be a significant effort. We also recognize that payers would need to evaluate their prior authorization policies for each plan type, analyze coverage requirements, and program those requirements for the PARDD API. We acknowledge that such efforts would require staff time for evaluation, development, and testing of the API E:\FR\FM\13DEP2.SGM 13DEP2 lotter on DSK11XQN23PROD with PROPOSALS2 76290 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules functionality. To maximize early understanding of how they could implement the recommended IGs for the PARDD API and operationalize these new processes, we encourage stakeholders to participate in the HL7 workgroups as they further refine the IGs that support prior authorization. Information about these and other workgroups may be found on the HL7 website at https://www.HL7.org. Given the effort that would be required to implement the PARDD API, we considered proposing that the API be implemented in a phased approach. Specifically, we considered and are seeking comment on whether to require payers to make prior authorization rules and documentation requirements available through the API incrementally, beginning January 1, 2026. In this alternative, Medicaid managed care plans and CHIP managed care entities would be required to comply with the approach described (in this section of this document) by the rating period beginning on or after January 1, 2026, and QHP issuers on the FFEs for plan years beginning on or after January 1, 2026. Under the proposal we considered, in the first phase, impacted payers would have been required to make 25 percent of their prior authorization rules and documentation requirements available through the API, prioritized by the highest number of requested items and services. We would have proposed that the first phase begin by January 1, 2026. The second phase would have required impacted payers to make available at least 50 percent of their prior authorization rules and documentation requirements, prioritized by the highest number of requested items and services. We would have proposed that this phase begin by January 1, 2027. Finally, beginning January 1, 2028, impacted payers would have been required to make available 100 percent of their prior authorization rules and documentation requirements through the API. Though this alternative approach could have provided additional time for payers to test their implementations and assess the benefits with providers, there was also a potential risk that a phased approach could have added complexity to the process for providers, rather than improving efficiency and reducing burden. If each payer’s highest volume of requirements is unique, provider staff could have been required to spend considerable time alternating between the API and prior methods of researching prior authorization requirements. We opted against proposing this lengthy phased-in option because of the challenges we believe it VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 could have created for providers continuing to navigate different implementation of payer rules. However, we request comments on this phased-in approach, our assumptions, and other potential options for an implementation strategy. For example, we request comment on whether payers would need a phased-in implementation to codify their rules and ensure that they are in a structured format (for example, quantifiable and machinereadable) for purposes of the API. If an alternative approach of this type were to be considered, how could CMS structure such an implementation strategy and timeframe without introducing additional burden? What are the operational and technical challenges involved in converting prior authorization rules into structured, machine-readable documents? Do payers have estimates of the amount of time that would be required for converting the most frequently requested prior authorizations into structured documents? For purposes of this proposed rule, rather than pursue a phased implementation process to maximize the benefits of electronic prior authorization, we propose that payers would be required to implement the PARDD API for all prior authorization rules and requirements for items and services, excluding drugs, by January 1, 2026 (for Medicaid managed care plans and CHIP managed care entities, by the rating period beginning on or after January 1, 2026, and for QHP issuers on the FFEs, for plan years beginning on or after January 1, 2026). We do not believe it necessary to propose a phased implementation strategy because we are not certain such an approach would reduce burden on either impacted payers, or providers, and believe in some cases it could increase the burden during the initial implementation. For example, as we previously outlined, for a phased approach, in the first phase, impacted payers would have been required to make 25 percent of their prior authorization rules and documentation requirements available through the API. Because prior authorizations vary by payer, that could mean that some payers would make one set of items or services available for prior authorization via the PARDD API, and another payer would have another set of items and services available. Providers seeking to utilize the PARDD API would then have conflicting methods of prior authorization available for different types of items or services based on each payer’s implementation decisions. This could be confusing, PO 00000 Frm 00054 Fmt 4701 Sfmt 4702 particularly during the initial rollout of a new API such as this one. We also believe that a phased approach could delay the availability of electronic prior authorization for certain items and services, which may in turn reduce the overall adoption of the PARDD API by providers who do not see their specialties and services represented in the initial rollout of the available PARDD API for items and services. We believe current industry pilots of alternatives for electronically exchanging prior authorization rules and requirements for documentation have already successfully demonstrated that payers may be able to meet the objectives in this proposed rule to improve prior authorization processes through the proposed API. The HL7 Community Roundtable recordings provide examples of these industry pilots and implementation of the HL7 IGs.85 This list is not exhaustive and other organizations may have additional examples. Industry would have additional implementations in place and sufficient experience with both required and proposed IGs to be able to implement the proposals by the proposed compliance dates on or after January 1, 2026. Even if finalized as proposed, our proposal would provide a window of several years for implementation of the PARDD API. We acknowledge that payers might elect to maintain their existing prior authorization processes until the proposed implementation date, but we would encourage them to develop short-term mechanisms to make prior authorization information more easily understandable and publicly available to providers and patients. Some payers publish their prior authorization requirements on their individual websites or make them available through proprietary portals. However, these payer-specific portals and websites may be cumbersome because they each require individual access, login, and passwords. Furthermore, a provider may require a certain amount of patient and plan data to find the relevant detail for a specific item or service to determine prior authorization requirements. These portals or website options may be viable solutions until the PARDD API is built, made widely available, and providers gain experience using the tool. We invite readers of this proposed rule to provide information about other electronic, public-facing resources and 85 Da Vinci Project (2022). Da Vinci 2022— Calendar. Retrieved from https:// confluence.hl7.org/display/DVP/Da+Vinci+2022++Calendar. E:\FR\FM\13DEP2.SGM 13DEP2 lotter on DSK11XQN23PROD with PROPOSALS2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules options available for providers and patients to obtain prior authorization information and whether payers should increase education about these resources. This PARDD API proposal could help both payers and providers mitigate some of the burdens of the prior authorization process and streamline the overall process. Payers that implement and maintain the proposed PARDD API might experience process improvements, fewer unnecessary requests or follow-up inquiries, and a decrease in denials or appeals. Such improvements could contribute to burden reduction for providers by reducing manual tasks and decreasing the volume of denials or appeals made. We acknowledge that the new functionality of the API may require changes to the payer’s customer service operations and procedures for providing support to patients during and after implementation. There may be questions about the required documentation, authorizations or denials about which both staff members and patients may need additional training and resources. We encourage payers to evaluate the procedural and operational changes as part of their implementation strategy, and to make appropriate resources available when the API is launched. While there are a number of resources available to ensure that patients receive quality services when accessing new technologies in health care, we invite feedback from commenters about available resources, such as the recent White House Blueprint for an AI Bill of Rights 86 and others. Finally, the anticipated benefits of the PARDD API are in part contingent upon providers using health IT products that can interact with payers’ APIs. In section II.E. of this proposed rule, we propose a new measure for the MIPS Promoting Interoperability performance category for MIPS eligible clinicians and the Medicare Promoting Interoperability Program for eligible hospitals and CAHs that would require healthcare providers to request a prior authorization electronically using data from certified electronic health record technology (CEHRT) using a payer’s PARDD API. We request comment on additional steps CMS could take to encourage providers and health IT developers to adopt the technology necessary to access payers’ PARDD APIs. In addition, we note that on January 24, 2022, ONC published an RFI titled ‘‘Electronic Prior 86 The White House (2022). Blueprint for an AI Bill of Rights. Retrieved from https:// www.whitehouse.gov/ostp/ai-bill-of-rights/. VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 Authorization Standards, Implementation Specifications, and Certification Criteria’’ (87 FR 3475) requesting comment on how updates to the ONC Health IT Certification Program could support electronic prior authorization. We continue to work with ONC on ways to facilitate the adoption of standards to streamline data exchange, support interoperability, and increase efficiencies. In summary, we propose that, beginning January 1, 2026 (for Medicaid managed care plans and CHIP managed care entities, by the rating period beginning on or after January 1, 2026, and for QHP issuers on the FFEs, for plan years beginning on or after January 1, 2026), these impacted payers would be required to implement and maintain a FHIR PARDD API using technology conformant with certain standards and implementation specifications in 45 CFR 170.215. We propose to require that the PARDD API be populated with the payer’s list of covered items and services, excluding drugs, for which prior authorization is required and accompanied by any documentation requirements. We further propose that the PARDD API would be required to include functionality to determine requirements for any other data, forms, or medical record documentation required by the payer for the items or services for which the provider is seeking prior authorization and while maintaining compliance with the HIPAA standard. Finally, the PARDD API responses from the payer to the provider would be required to include information regarding payer approval (and for how long) or denial (with a specific reason) of the request, or request more information from the provider to support the prior authorization request (see discussion in section II.D.4.a.). We are proposing these requirements for the proposed PARDD API at the CFR sections identified in Table 7. We request comment on the proposal to require implementation of a Prior Authorization Requirements, Documentation, and Decision API. b. Federal Funding for State Medicaid and CHIP Expenditures on Implementation of the PARDD API Should our proposals be finalized as proposed, states operating Medicaid and CHIP programs may be able to access Federal matching funds to support their implementation of the proposed PARDD API. This proposed API is expected to lead to more efficient administration of Medicaid and CHIP state plans by supporting a more efficient prior authorization process, consistent with PO 00000 Frm 00055 Fmt 4701 Sfmt 4702 76291 sections 1902(a)(4) and 2101(a) of the Act. We would not consider state expenditures for implementing this proposal to be attributable to any covered Medicaid item or service within the definition of ‘‘medical assistance.’’ Thus, in Medicaid, CMS would not match these expenditures at the state’s regular Federal medical assistance percentage (FMAP). However, Federal financial participation (FFP) under section 1903(a)(7) of the Act, at a rate of 50 percent, for the proper and efficient administration of the Medicaid state plan, might be available for state expenditures related to implementing this proposal for their Medicaid programs. We believe that using the PARDD API would help the state more efficiently administer its Medicaid program by increasing the efficiencies in the prior authorization process. For instance, using the PARDD API would enable administrative efficiencies by improving accuracy, and by helping reduce the number of denied and appealed prior authorization decisions. States’ expenditures to implement these proposed requirements could also be eligible for 90 percent enhanced FFP under section 1903(a)(3)(A)(i) of the Act, if the expenditures can be attributed to the design, development, or installation of mechanized claims processing and information retrieval systems. Additionally, 75 percent enhanced FFP, under section 1903(a)(3)(B) of the Act, could be available for state expenditures to operate Medicaid mechanized claims processing and information retrieval systems to comply with this proposed requirement. States can request Medicaid enhanced FFP under section 1903(a)(3)(A)(i) or (B) of the Act through the APD process described in 45 CFR part 95, subpart F. States are reminded that 42 CFR 433.112(b)(12) and 433.116(c) in part require that any system for which they are receiving enhanced FFP under section 1903(a)(3)(A)(i) or (B) of the Act align with and incorporate the ONC Health Information Technology standards adopted in 45 CFR part 170, subpart B. The PARDD API would complement this requirement because this API would further interoperability by using standards adopted by ONC at 45 CFR 170.215.87 States are also reminded that 42 CFR 433.112(b)(10) and 433.116(c) explicitly support 87 Centers for Medicare & 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\13DEP2.SGM 13DEP2 76292 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules exposed APIs, meaning the API’s functions are visible to others to enable the creation of a software program or application, as a condition of receiving enhanced FFP under section 1903(a)(3)(A)(i) or (B) of the Act. Similarly, 42 CFR 433.112(b)(13) and 433.116(c) require the states to promote sharing, leverage, and re-use of Medicaid technologies and systems as a condition of receiving enhanced FFP under section 1903(a)(3)(A)(i) or (B) of the Act. CMS interprets that requirement to apply to technical documentation associated with a technology or system, such as technical documentation for connecting to a state’s APIs. Making the needed technical documentation publicly available so that systems that need to can connect to the APIs proposed in this rule would be required as part of the technical requirements at 42 CFR 431.60(d) for all proposed APIs in this rule, including the PARDD API. Separately, for CHIP agencies, section 2105(c)(2)(A) of the Act and 42 CFR 457.618, limiting administrative costs to no more than 10 percent of a state’s total computable expenditures for a fiscal year, would apply to administrative claims for developing the APIs proposed in this rule. We note that the temporary Medicaid FMAP increase available under section 6008 of the Families First Coronavirus Response Act (Pub. L. 116–127) does not apply to administrative expenditures. lotter on DSK11XQN23PROD with PROPOSALS2 c. Medicaid Expansion CHIP Programs Most states have Medicaid Expansion CHIP programs, in which a state receives Federal funding to expand Medicaid eligibility to optional targeted low-income children that meet the requirements of section 2103 of the Social Security Act. We are proposing at 42 CFR 457.700(c) that for states with Medicaid Expansion CHIP programs, the proposals in this rule for Medicaid would apply to those programs rather than our proposals for a separate CHIP program. Functionally, our proposals are the same; however, for clarity, we are making explicit that the Medicaid requirements at §§ 431.60, 431.61, and 431.80 would apply to those programs rather than the separate CHIP requirements at §§ 457.730, 457.731, and 457.732. 4. Requirement for Payers To Provide Status of Prior Authorization and Reason for Denial of Prior Authorizations a. Reason for Denial of Prior Authorization Based on the stakeholder input described in this proposed rule, we believe the prior authorization process could be improved through better communication between payers and providers. One of the opportunities for better communication is timely and specific information about the reason for denying a prior authorization. Payers deny prior authorizations for different reasons. For example, a payer might deny a prior authorization because the payer does not consider the items or services to be medically necessary, the patient may have exceeded limits on allowable covered care for a given type of item or service, or documentation to support the request was missing or inadequate. Providing an understandable reason for a denial could allow a provider to take appropriate actions such as resubmitting the request with updated information, identifying alternatives for the patient, appealing the decision, or communicating the decision to the patient. As noted in the 2021 AMA provider survey, 83 percent of providers report that prior authorization process issues lead to treatment abandonment, while 93 percent reported that process issues led to delays in care.88 Timely and clear information from payers about the status of a prior authorization or the reason(s) for denial could help mitigate these challenges and provide necessary information for submitting additional documentation or arranging for alternative treatment. Impacted payers currently have the capability to send information to providers about the reason a prior authorization request has been denied either electronically or through other communication methods. For denials sent using the X12 278 standard, payers must use the codes from the designated X12 code list. For responses sent through portals, via fax or other means, payers may use proprietary codes or text to provide denial reasons. Consistent use of both technology and terminology (codes) to communicate denial information could mitigate some of the operational inefficiencies for providers so that they could more consistently interpret and react to a denied prior 88 American Medical Association (2021). AMA Prior Authorization (PA) Physician Survey Results. Retrieved from https://www.ama-assn.org/system/ files/prior-authorization-survey.pdf. VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 PO 00000 Frm 00056 Fmt 4701 Sfmt 4702 authorization request. This proposal to send a specific denial reason is one approach to address current inefficiencies. Specifically, we propose that, beginning January 1, 2026 (for Medicaid managed care plans and CHIP managed care entities, by the rating period beginning on or after January 1, 2026, and for QHP issuers on the FFEs, for plan years beginning on or after January 1, 2026), impacted payers would be required to provide a specific reason for denied prior authorization decisions, excluding prior authorization decisions for drugs, regardless of the method used to send the prior authorization request. As stated under the proposal for the PARDD API, we are also proposing that responses about a prior authorization decision sent through the PARDD API from the payer to the provider would have to include information regarding whether the payer approves (and for how long) or denies the prior authorization request, or requests more information from the provider to support the request. We are proposing these requirements regarding prior authorization decisions for MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs at the CFR sections identified in Table 7. Some payers that would be subject to this proposal are also subject to existing requirements to provide notice to patients or providers, or both, with the specific reasons for denial, and this proposal builds on those existing policies. b. Existing Program-Specific Notice Requirements for Prior Authorization Denial Information Some payers that would be affected by this proposed rule are required by existing Federal and state laws and regulations to notify providers and patients when an adverse decision is made about a prior authorization request. As previously discussed, our proposals to impose requirements on payers to communicate certain information to providers about prior authorization requests are intended to reinforce these existing Federal and state requirements. Our proposals would not alter or replace existing requirements to provide notice to patients, providers, or both. The proposed requirement to use the PARDD API to compile necessary data and populate the X12 278 transaction response to the provider, including whether an authorization request has been approved (and for how long), denied, with a reason for the denial, or E:\FR\FM\13DEP2.SGM 13DEP2 lotter on DSK11XQN23PROD with PROPOSALS2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules request more information from the provider to support the prior authorization request, would support current Federal and state notice requirements for certain impacted payers. Clearly communicating denial reasons, in addition to the existing program notification requirements, could increase transparency, reduce burden, and improve efficiencies for both payers and providers. This section of this proposed rule addresses additional denial notice requirements for certain impacted payers in the MA program, as well as Medicaid, and includes information on existing Medicaid beneficiary notice and fair hearing regulations in the context of prior authorization decisions in section II.D.6.b. For Medicaid managed care plans and CHIP managed care entities,89 existing regulations at 42 CFR 438.210(c) require notice to the provider without specifying the format or method, while 42 CFR 438.210(c) and 438.404(a) require written notice to the enrollee of an adverse benefit determination. Nothing in this proposed rule would affect existing enrollee notification requirements in 42 CFR part 438 for Medicaid managed care plans and in 42 CFR part 457 for CHIP managed care entities as these requirements would remain in full effect. This proposed rule would fill a potential gap with respect to the information communicated to providers regarding a denial of a prior authorization request. We propose that the response—whether the authorization request has been approved (and for how long), denied (with the reason for the denial), or a request for more information to support the prior authorization—if transmitted to providers via the PARDD API workflow process or other means, would be sufficient to satisfy the current requirement for notice to providers at 42 CFR 438.210(c). Under our proposal the payer would not be required to send the response via both the PARDD API process, which includes the denial reason, and a separate, additional notice in another manner with duplicate information. We also remind all Medicaid managed care plans and CHIP managed care entities that would be subject to this proposed rule that their existing obligations to provide these required notices to enrollees would not be changed by the proposals in this proposed rule. These payers would still have to provide a separate written 89 See 42 CFR 457.1230(d) and 457.1260(c). VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 notice to the enrollee as required in 42 CFR 438.210(c) and (d) and 438.404.90 Under the MA program, the actions that constitute an ‘‘organization determination’’ at 42 CFR 422.566(b) include a prior authorization (or ‘‘preservice’’) decision, as paragraph (b)(3) refers to an MA organization’s refusal to provide or pay for services, in whole or in part, including the type or level of services, that the enrollee believes should be furnished or arranged by the MA organization. Under existing § 422.566(b), an organization determination would include a request for prior authorization using the PARDD API under the proposed provisions at 42 CFR 422.122. Existing MA program regulations are specific as to the form and content of the written notice to enrollees in the event of a partial or full denial. For example, existing regulations at 42 CFR 422.568(e) regarding written notices for enrollees for standard organization determinations require that a notice for any denial for a covered service or item under 42 CFR 422.568(d) must: (1) use approved notice language in a readable and understandable form; (2) state the specific reasons for the denial; (3) inform the enrollee of their right to a reconsideration; (4) describe both the standard and expedited reconsideration processes, including the enrollee’s right to, and conditions for, obtaining an expedited reconsideration and the rest of the appeal process; and (5) comply with any other notice requirements specified by CMS. Under the rules at 42 CFR 422.572 related to timeframes and notice requirements for expedited organization determinations, an MA organization must send a written denial notice to the enrollee, and physician involved as appropriate, whenever an MA plan’s determination is partially or fully adverse to the enrollee. The rules at 42 CFR 422.572(a)(1) related to expedited organization determinations state that an MA organization that approves a request for expedited determination must make its determination and notify the enrollee, and the physician involved as appropriate, of its decision whether adverse or favorable and as expeditiously as the enrollee’s health condition requires, but no later than 72 hours after receiving the request. Either an enrollee or a physician, regardless of whether the physician is affiliated with the MA organization, may request that an MA organization expedite an organization determination. Given that a physician is often involved in requesting an expedited organization 90 See PO 00000 42 CFR 457.1230(d) and 457.1260(c). Frm 00057 Fmt 4701 Sfmt 4702 76293 determination on behalf of an enrollee, the rules related to notices explicitly require an MA plan to notify the enrollee and the physician involved, as appropriate, of its decision, whether adverse or favorable. The content of a notice of expedited determination must state the specific reasons for the determination in understandable language and if the determination is not completely favorable to the enrollee, the notice must also: (1) inform the enrollee of their right to a reconsideration; (2) describe both the standard and expedited reconsideration processes, including the enrollee’s right to request, and conditions for obtaining, an expedited reconsideration, and the rest of the appeal process; and (3) comply with any other requirements specified by CMS. Because applicable integrated plans may be either MA plans for individuals with special needs who are dually eligible for Medicare and Medicaid, or Medicaid MCOs, the regulations regarding prior authorization processes that we are proposing for MA plans and Medicaid managed care plans would apply to applicable integrated plans as well. Similar rules at 42 CFR 422.631(d) already govern denial notices issued by applicable integrated plans to their enrollees. Integrated organization determination notices must be written in plain language, available in a language and format that is accessible to the enrollee, and explain: (1) the applicable integrated plan’s determination; (2) the date the determination was made; (3) the date the determination will take effect; (4) the reasons for the determination; (5) the enrollee’s right to file an integrated reconsideration and the ability for someone else to file an appeal on the enrollee’s behalf; (6) procedures for exercising an enrollee’s rights to an integrated reconsideration; (7) the circumstances under which expedited resolution is available and how to request it; and (8) if applicable, the enrollee’s rights to have benefits continue pending the resolution of the integrated appeal process. As with the notices required from MA plans, our proposal would not change the content requirements for these written denial notices to enrollees but would supplement these notices by requiring applicable integrated plans to notify the provider of the reason for a denial of a prior authorization request. QHP issuers on the FFEs that offer individual health insurance must provide the specific reason for an adverse benefit determination, which E:\FR\FM\13DEP2.SGM 13DEP2 76294 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules includes denial of prior authorization.91 Furthermore, plans and issuers must ensure that notice is made to individuals in a culturally and linguistically appropriate manner that complies with the requirements of 45 CFR 147.136(b)(2)(ii)(E) and 29 CFR 2560.503–1(g) and (j). lotter on DSK11XQN23PROD with PROPOSALS2 5. Requirements for Prior Authorization Decision Timeframes and Communications a. Impact of Delays in Prior Authorization Decisions: Background and Overview of Current Decision Timeframes During the CMS listening sessions and other public meetings, we heard, largely from providers, that excessive wait time for prior authorization decisions could cause delays to patient care and may create medical risks in some cases. In most examples cited, providers face delays for the approval of the initial request, or, secondarily, for the resolution of a request ‘‘in process,’’ often meaning the payer is reviewing requested documentation. A 2017 AMA study reported that 39 percent of physicians stated that for those patients whose treatment requires prior authorization, the process can delay access to care. In that same study, between 19 and 57 percent of physicians reported that for those patients whose treatment requires prior authorization, the process may lead to patients abandoning their recommended course of treatment.92 As described earlier, in 2019, CMS conducted outreach to external stakeholders, including payers, providers, patients, vendors, and others, through listening sessions, interviews, observational visits, RFIs, and a special email box. The goal was to obtain information about how to improve the transparency, efficiency, and standardization of the prior authorization process. We received a large volume of comments about timeframes for processing prior authorizations, where commenters expressed that the process of securing approvals for prior authorization directly affects patient care by delaying access to services, including transfers between hospitals and post-acute care facilities, treatment, medication, and supplies. Commenters believed that these delays occur partly because payers have different policies and review processes, do not use available 91 See 45 CFR 147.136(b)(3)(ii)(E). Medical Association (2018). 2017 AMA Prior Authorization Physician Survey. Retrieved from https://www.ama-assn.org/sites/ ama-assn.org/files/corp/media-browser/public/arc/ prior-auth-2017.pdf. 92 American VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 technologies consistently, and continue to rely on manual systems such as phone, fax, and mail, which are more labor-intensive. Some commenters noted that the large variations in payer prior authorization policies for the same items and services and the difficulty of discovering these payer’s policies necessitates substantial provider staff research and time, which contributes to delays in care. In this proposed rule, we use the term ‘‘standard’’ prior authorization to refer to non-expedited, non-urgent requests for prior authorization and the term ‘‘expedited’’ prior authorization to indicate an urgent request. These terms are used, as described here, in the provisions in 42 CFR 422.568, 422.570, 422.572, and 422.631 for MA organizations and applicable integrated plans, and 42 CFR 438.210(d) for Medicaid managed care plans, and we will use these terms for all regulated payers to whom the proposed policy in this section applies. Under existing regulations for standard prior authorization decisions, MA organizations and applicable integrated plans must make a decision and send notice of that decision as expeditiously as the enrollee’s condition requires, but may not exceed 14 calendar days following receipt of the request for an item or service.93 Under certain circumstances, a plan may extend this 14-calendar day timeframe consistent with the rules at § 422.568(b)(1)(i) or § 422.631(d)(2)(ii). Similarly, for standard prior authorization decisions, Medicaid managed care plans and CHIP managed care entities must make a decision and send notice of that decision as expeditiously as the beneficiary’s condition requires within stateestablished time frames, but may also not exceed 14 calendar days following receipt of the request for an item or service.94 Under these programs, if a provider indicates or the payer determines that following the standard timeframe could seriously jeopardize the patient’s life, health or ability to attain, maintain, or regain maximum function, the MA plan, applicable integrated plan, Medicaid managed care plan, or CHIP managed care entity must make an expedited authorization decision and provide notice as expeditiously as the beneficiary’s health condition requires, but no later than 72 hours after 93 See 42 CFR 422.568(b)(1), 422.631(d)(2)(i)(B). 42 CFR 422.570, 422.572, 422.631(c) and (d)(2)(iv)(A), 438.210(d)(2), and 457.1230(d). 94 See PO 00000 Frm 00058 Fmt 4701 Sfmt 4702 receiving the request.95 (42 CFR 422.570, 422.572, 422.631(c) and (d)(2)(iv)(A), and 438.210(d)(2), and through an existing cross reference at 42 CFR 457.1230(d)) Under existing Federal regulations for these payers, the enrollee may request an extension of up to 14 additional calendar days from the standard and expedited timeframes for the payer to make a decision on a prior authorization request for an item or service. Also, the payer may initiate the extension up to 14 additional calendar days if the payer needs additional information and the extension is in the enrollee or beneficiary’s interest.96 For example, a provider may need to submit, or a payer may need to gather, additional information by consulting with additional providers with expertise in treating a condition to enable the payer to approve a prior authorization, and such information may not be able to be collected within the standard or expedited timeframe. Under existing Federal CHIP regulations for FFS programs, prior authorization of health services must be completed within 14 days after receiving a request for services or in accordance with existing state law regarding prior authorization of health services.97 This means the CHIP must decide, and send notice of that decision, within 14 calendar days of receiving the request for a medical item or service by the provider. An extension of 14 days may be permitted if the enrollee requests the extension or if the provider or health plan determines that additional information is needed.98 For cases in which a provider indicates, or the payer determines, that the standard timeframe of 14 days could seriously jeopardize the enrollee’s life; health; or ability to attain, maintain, or regain maximum function, the CHIP managed care entity must make an expedited authorization decision and provide notice no later than 72 hours after receiving the request.99 95 See 42 CFR 422.570, 422.572, 422.631(c) and (d)(2)(iv)(A), 438.210(d)(2), and 457.1230(d). 96 See 42 CFR 422.568(b)(1)(i), 422.572(b), 422.631(d)(2)(ii), and 438.210(d)(1) and (2), and through an existing cross reference at 42 CFR 457.1230(d). MA plans may extend the timeframe if 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. MA plans may also extend the timeframe for a standard or expedited organization determination if the extension is justified due to extraordinary, exigent, or other non-routine circumstances and is in the enrollee’s interest. 97 See 42 CFR 457.495(d). 98 See 42 CFR 457.495(d)(1). 99 See 42 CFR 457.1230(d). E:\FR\FM\13DEP2.SGM 13DEP2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules Table 4 provides a summary of current Federal requirements for prior authorization decision timeframes that 76295 apply to the payers that would be affected by this proposed rule. BILLING CODE 4120–01–P TABLE 4: REGULATORY REFERENCES FOR CURRENT FEDERAL PRIOR AUTHORIZATION DECISION TIMEFRAMES AMONG IMPACTED PAYERS Medicare Advantage and Applicable Integrated Plans Medicaid Managed Care No later than 72 hours after receiving the request for items or services. * 42 CFR 422.572(a) 42 CFR 422.63 l(d)(2)(iv) As expeditiously as the beneficiary's health condition requires, but no later than 72 hours after receiving the request. No later than 14 calendar days after receiving the request for items or services. * 42 CFR 422.568(b)(l) 42 CFR 422.631(d)(2)(i)(B) The enrollee can request an extension of up to 14 additional calendar days from the standard timeframe for the decision on prior authorization. Payers can initiate an extension of up to 14 days if the payer needs additional information to approve the request and the extension is in the enrollee's interest. 42 CFR 422.568(b)(l) 42 CFR 422.63 l(d)(2)(ii) As expeditiously as the beneficiary's health condition requires and within state-established time frames that may not exceed 14 calendar days following receipt of the request. 42 CFR 438.210(d)(l) 42 CFR 438.210(d)(2) VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 PO 00000 Frm 00059 Fmt 4701 Sfmt 4725 E:\FR\FM\13DEP2.SGM 13DEP2 EP13DE22.003</GPH> lotter on DSK11XQN23PROD with PROPOSALS2 The beneficiary or provider can request an extension ofup to 14 additional calendar days from the standard decision timeframe. Payers can initiate an extension ofup to 14 days if they can justify to the state Medicaid agency the need for additional information and how the extension is in the beneficiary's interest. 42 CFR 438.210(d)(l)(ii) 76296 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules CHIP Managed Care As expeditiously as the beneficiary's health condition requires, but no later than 72 hours after receiving the request. As expeditiously as the beneficiary's condition requires and within state-established timeframes that may not exceed 14 calendar days following receipt of the request for service. 42 CFR 457.1230(d) 42 CFR 457.1230(d) Medicaid Fee-forService CHIP Fee-forService QHP Issuers on the FFEs The beneficiary can request an extension of 14 additional calendar days from the standard timeframe to make a decision on prior authorization. Payers can initiate an extension of up to 14 additional calendar days if they can justify (to the state agency upon request) a need for additional information and how the extension is in the beneficiary's interest. 42 CFR 457.1230(d) Not specified in Federal regulation Not specified in Federal regulation No current Federal regulation 14 calendar days following receipt of the calendar request for items and services. Notification of a plan's benefit determination for urgent care claims should be provided within 72 hours. Extensions allowed if claimant does not provide sufficient information. The beneficiary can request an extension of 14 additional calendar days from the standard timeframe to make a decision on prior authorization. Payers can initiate an extension if they can justify a need for additional information. 42 CFR 457.495(d) Notification of a plan's benefit determination for pre-service claims should be provided within 15 days. Limited extensions of this timeframe are allowed depending on circumstances. BILLING CODE 4120–01–C lotter on DSK11XQN23PROD with PROPOSALS2 b. Proposals To Address Timeframes for Decisions on Standard and Expedited Prior Authorization Requests Given our interest in improving patient care outcomes, and ensuring that patients have more timely access to services, we are proposing to establish, improve, or shorten Federal prior authorization timeframes for certain payers to respond to requests. We acknowledge that many of the payers that would be affected by this proposed rule have different requirements for prior authorization decision notice and appeal timeframes, and we are VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 proposing to align prior authorization decision timeframes across these payers. We are proposing that, beginning January 1, 2026, MA organizations and applicable integrated plans, Medicaid FFS programs, and CHIP FFS programs must provide notice of prior authorization decisions as expeditiously as a patient’s health condition requires, but no later than 7 calendar days for standard requests. We also propose that Medicaid FFS and CHIP FFS programs must provide notice of prior authorization decisions as expeditiously as a patient’s health condition requires, but no later than 72 hours for expedited requests unless a shorter minimum time frame is established under state law. PO 00000 Frm 00060 Fmt 4701 Sfmt 4702 Assuming these proposals are finalized as proposed, we believe the 7calendar day timeframe for standard decisions could be achieved when payers implement their APIs with improved access to documentation requirements, which could support greater use of electronic prior authorization, and more efficient business processes once implemented. For MA organizations, on or after January 1, 2026, items and services covered by the proposals in 42 CFR 422.122 would be affected by this proposal if finalized; for all other items and services existing timeframes would remain applicable. E:\FR\FM\13DEP2.SGM 13DEP2 EP13DE22.004</GPH> 45 CFR 147.136(b)(3)(i) 45 CFR 147.136(b)(3)(i) 29 CFR 2560.503-l(f)(2)(iii)(A) 29 CFR 2560.503-l(f)(2)(i) * Applicable integrated plans may have shorter timeframes as required by a state (42 CFR 422.629(c)) allows states to implement timeframes that are more protective of enrollees). lotter on DSK11XQN23PROD with PROPOSALS2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules Our proposal would not change the 72-hour deadline required by current Federal regulations, or the authority for an extension of that deadline, for expedited decisions made by MA organizations, applicable integrated plans, Medicaid managed care plans, and CHIP managed care entities. In addition, we do not propose to change existing Federal timeframes for standard and expedited determinations on requests for Part B drugs for MA organizations and applicable integrated plans; current regulations require notice to the enrollee as expeditiously as the enrollee’s health condition requires, but no later than 72 hours after receiving the request for a standard determination and as expeditiously as the enrollee’s health condition requires, but no later than 24 hours after receiving an expedited request.100 Due to the revisions we are proposing to § 422.568(b), we propose to redesignate existing § 422.568(b)(2) related to requests for Part B drugs for MA organizations to 42 CFR 422.568(b)(3). For MA plans and applicable integrated plans, the timeframes would continue to apply to the notice that must be provided to the enrollee, while for Medicaid managed care plans and CHIP managed care entities, existing regulation requires that notices must be provided to both the provider and to the enrollee.101 We are not proposing to change timeframes for prior authorization processes for QHPs on the FFEs, in part because existing regulations at 45 CFR 147.136 establish internal claims and appeals processes, external review processes, and pre-service claims requirements for all non-grandfathered group and individual market plans or coverage. Specifically, individual health insurance issuers are required to meet minimum internal claims and appeals standards.102 We believe the current standard adequately protects patient interests. As summarized in Table 4, QHPs on the FFEs are required to provide notification of a plan’s benefit determination within 15 days for standard authorization decisions and within 72 hours for expedited requests. Should this rule be finalized as proposed, QHPs on the FFEs would have the same timeframe for expedited authorization decisions as the other CMS payers affected by this provision: 72 hours. We believe that the benefits for the patient of a shorter timeframe for standard prior authorization decisions 100 See 42 CFR 422.568(b)(2), 422.572(a)(2), and 422.631(a). 101 See 42 CFR 438.210(c) and 457.1230(d). 102 See 45 CFR 147.136(b)(3). VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 would outweigh the additional burden that plans on the Exchanges 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, we note that making changes to regulations applicable to all non-grandfathered group and individual market plans or coverage for consistency with our proposed approach here would be outside the scope of this proposed rulemaking.103 We are not proposing to require that impacted payers approve a request for prior authorization should that payer not meet the required standard or expedited decision timeframe. If a payer fails to meet the timeline for approval or other decision, providers should contact the payer to obtain the status of the request and determine if supporting documentation is needed to complete processing of the authorization or if there are other reasons for the delay in a decision. We do not believe it is practical to require payers to default to an approval for prior authorization requests for which a timely response has not been provided. Therefore, impacted payers may choose to evaluate process improvements to meet the proposed timeframes and API in this proposed rule, and consider how to efficiently support provider inquiries on status should responses or timeframes be missed. However, we note that some programs, such as Medicare Advantage, have regulations which include provisions for the failure to provide timely notice of an organization determination, which constitutes an adverse decision that may be appealed. We seek comment on what administrative, regulatory, technical, governance, operational, and workflow solutions would need to be addressed, for and by payers, to comply with the proposed timeframes for handling prior authorization review and approval activities. We also seek comment on what operational or procedural changes payers or providers would need to make in their workflows or systems to reduce decision timeframes from 14 days to 7 calendar days (for standard prior authorization requests) and from 72 103 We are not proposing in this proposed rule to impose on individual and group market plans generally timelines for processing of prior authorizations consistent with those we propose for other payers, as such requirements would require rulemaking by the Departments of Labor, the Treasury, and Health and Human Services. PO 00000 Frm 00061 Fmt 4701 Sfmt 4702 76297 hours to 1 day or 24 hours (for expedited prior authorization requests). Based on comments we received in response to the December 2020 CMS Interoperability rule (85 FR 82586), many providers wish to see further improvements in the timeliness of the decision process for prior authorizations. Some commenters, including payers, believe it is possible, given advances in technology, that responses to certain types of prior authorization requests could be made within 24 hours. Some payer and provider commenters agree that shorter prior authorization decision timeframes than those in this proposed rule could help to improve patient care, reduce burden, and improve equity. We wish to learn more about the process and technology barriers which prevent payers from meeting shorter timeframes than those in this proposed rule, and request input on whether MA organizations, applicable integrated plans, Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities might be able to provide notice of standard and expedited prior authorization decisions within, for example, 5 calendar days and 48 hours, respectively, and if not, what specific issues and obstacles prevent that. We believe that as prior authorization processes become more efficient, shorter timeframes may be possible for certain types of requests. For example, if early adopters voluntarily implement and test the proposed PARDD API, and if some impacted payers voluntarily implement process improvements in methods of provider communication, automation, and documentation submission requirements, those payers may be able to accommodate shorter timeframes for certain types of prior authorization requests. Therefore, we solicit comments on whether implementation of the PARDD API as described in this proposed rule could yield process improvements of sufficient magnitude to support shorter decision timeframe requirements for prior authorization requests as suggested by many stakeholders, including payers, providers, vendors, and other interested parties, and described in reports cited earlier. We also seek comment on anticipated operational challenges of implementing the API that might affect a payer’s ability to meet the proposed timeframes. Finally, we request comment from the public regarding the costs, benefits, and operational impact on providers and payers, as well as the impact on patients, of making and communicating prior authorization E:\FR\FM\13DEP2.SGM 13DEP2 lotter on DSK11XQN23PROD with PROPOSALS2 76298 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules decisions on a shorter timeframe than those in this proposed rule. In summary, to address prior authorization decision timeframes, we are proposing to require, beginning January 1, 2026, that MA organizations and applicable integrated plans, Medicaid FFS programs, and CHIP FFS programs must provide notice of prior authorization decisions as expeditiously as a beneficiary’s health condition requires (for CHIP FFS, alternatively stated as in accordance with the medical needs of the patient), but no later than 7 calendar days for standard requests. We are proposing that Medicaid FFS and CHIP FFS programs must provide notice of prior authorization decisions as expeditiously as a beneficiary’s health condition requires (for CHIP, alternatively stated as in accordance with the medical needs of the patient) but no later than 72 hours for expedited requests unless a shorter minimum time frame is established under state law. We are proposing to require that the same maximum timeframes apply to standard authorization decisions by Medicaid managed care plans and CHIP managed care entities beginning with the rating period that starts on or after January 1, 2026. Because Medicaid managed care plans at 42 CFR 438.210(d)(2) and CHIP managed care entities at § 457.1260(c)(3) respectively must already make an expedited authorization decision and provide notice as expeditiously as the beneficiary’s health condition requires but no later than 72 hours after receipt of the request for service, we are not proposing to change those specific timeframes. However, for consistency with Medicaid FFS, we propose to add ‘‘unless a shorter minimum time frame is established under State law’’ to 42 CFR 438.210(d)(2). We are proposing to amend 42 CFR 438.210(d)(2)(i) to clarify that the MCO, PIHP, or PAHP must make these decisions on shorter timeframes if required by the state. These proposals for the impacted payers in this proposed rule are being made at the CFR sections identified in Table 7. If state law imposes a shorter timeframe for these decisions, that shorter time frame would govern for Medicaid FFS, CHIP FFS, Medicaid managed care plans, and CHIP managed care entities. If our proposed regulation is finalized as proposed, and state law imposes a longer time frame, payers could comply with both the Federal and state regulations by complying with the shorter Federal time frame. State laws would not apply to MA plans, based on preemption language at 42 CFR 422.402 which states that the standards established for MA plans supersede any VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 state law or regulation (other than state licensing laws or state laws relating to plan solvency) with respect to the MA plans that are offered by MA organizations. Therefore, MA plans would not be required to comply with timeframes imposed by the states, but rather with the time frames set by this proposed rule. We are not proposing to change any existing Federal timeframes that might apply to expedited authorization decisions made by any of the impacted payers, especially given that many of these payers already apply a 72-hour maximum timeframe for such requests. To ensure consistency and correctly describe the new timeframes being proposed for these payers to provide notice of standard determinations, we are proposing a corresponding amendment to the CFR sections identified in Table 7. Specifically, an MA plan must automatically transfer a request to the standard timeframe if the MA plan denies a request for an expedited organization determination or an applicable integrated plan denies a request for an expedited integrated organization determination. This step to automatically transfer expedited requests to the standard timeframe does not apply to the Medicaid and CHIP managed care provisions listed in Table 7 since the provision at 42 CFR 438.210(d)(2) requires managed care plans to make an expedited authorization decision no later than 72 hours after receipt of the request if the provider requesting the authorization indicates that following the standard timeframe could seriously jeopardize the beneficiary’s life or health or ability to attain, maintain, or regain maximum function. 6. Requirements for Timing of Notifications Related to Prior Authorization Decisions This section proposes requirements for the timing of notifications sent by certain payers to patients regarding prior authorization decisions. This proposal also applies to most impacted payers. However, we are not proposing to address proposals for notifications to the QHPs on the FFEs, for the same reasons we provided in section II.D.5.b. a. MA Organizations MA organizations are currently required to provide notifications to enrollees of decisions regarding coverage, called organization determinations, which includes decisions regarding prior authorizations. To support more timely decisions and communication of those decisions, we propose to amend the CFR sections PO 00000 Frm 00062 Fmt 4701 Sfmt 4702 identified in Table 5 to require MA organizations to notify the enrollee of its determination as expeditiously as the enrollee’s health condition requires, but no later than 7 calendar days after the organization receives the request for a standard pre-service organization determination for a medical item or service. We are also proposing to revise 42 CFR 422.568 and move the existing language at 42 CFR 422.568(b)(1)(i) and (ii) to 42 CFR 422.568(b)(2). We propose to move the language previously at 42 CFR 422.568(b)(2) to new paragraph (b)(3). We emphasize that this proposed change to the regulation text structure does not change current requirements and that this proposed 7 calendar day timeframe would remain subject to the existing requirements (currently at 42 CFR 422.568(b)(1)(i), proposed to be at 42 CFR 422.568(b)(2)) related to the limited circumstances under which an MA organization may extend the adjudication timeframe by up to 14 additional calendar days. We are not proposing to change the current 72-hour decision timeframe for expedited requests or the availability of the 14calendar day extension to make a determination under 42 CFR 422.568 for standard requests and 42 CFR 422.572 for expedited requests. Other than the proposal to require an MA plan to send notification of prior authorization decisions to providers electronically in section II.D.3.a. of this proposed rule, we are not proposing changes to the requirements for an MA plan to notify enrollees of decisions on organization determinations. For example, should an MA plan deny a prior authorization request, it must send written notice to the enrollee under the requirements for standard requests at 42 CFR 422.568(d) and (e) and for expedited requests at 42 CFR 422.572(e). Consistent with policies for MA organizations, we are proposing enrollee notification requirements for the integrated organization determination process described at 42 CFR 422.631. Specifically, we propose to amend the CFR sections identified in Table 5 to state that when a provider makes a request for an item or service, the applicable integrated plan must notify the enrollee of its determination as expeditiously as the enrollee’s health condition requires, but no later than 7 calendar days after the organization receives the request for a standard preservice organization determination regarding coverage for a medical item or service. We are not proposing to change the current 72-hour requirement for decisions and notice on expedited requests at 42 CFR 422.631(d)(2)(iv)(A). Under our proposal, the authority for a E:\FR\FM\13DEP2.SGM 13DEP2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules lotter on DSK11XQN23PROD with PROPOSALS2 14-calendar day extension of the timeframe, in 42 CFR 422.631(d)(2)(ii), would remain unchanged. Also, consistent with the proposed changes to rules for other MA organizations, we are proposing to amend the CFR sections identified in Table 5 to state that when an applicable integrated plan denies a request for an expedited determination and automatically transfers the request to the standard timeframe, it must make its determination within the 7-calendar day timeframe, rather than the current 14 calendar day timeframe for an integrated organization determination. These proposed changes would also apply to applicable integrated plans that are Medicaid managed care organizations (MCOs), as defined in 42 CFR 438.2, because, per 42 CFR 438.210(d)(4), 42 CFR 422.631 also applies to these Medicaid plans. These proposed amendments are consistent with changes for other Medicaid managed care plans being proposed at 42 CFR 438.210(d)(1) and (2), discussed later. As with the proposed requirements for MA organizations, our proposal is limited to the timeframes for standard determinations, and we are not proposing changes to the timeline for expedited integrated organization determinations, extensions, or the requirements for notice to enrollees. b. Medicaid Fee-for-Service, Including Beneficiary Notice and Fair Hearings For the Medicaid FFS program we are proposing, at the CFR sections identified in Table 5, to specify regulatory timeframes to provide notice of decisions on both expedited and standard prior authorization requests. The new requirements would apply to prior authorization decisions beginning January 1, 2026. Under this proposal for Medicaid FFS, which would appear at 42 CFR 440.230(e)(1), notice of the state Medicaid program’s decision regarding an expedited request for prior authorization would have to be communicated as expeditiously as a beneficiary’s health condition requires, but no later than 72 hours after receiving a provider’s request for an expedited determination, unless a shorter minimum time frame is established under state law. Notice of a decision on a standard request for a prior authorization would have to be communicated to the requesting provider as expeditiously as a beneficiary’s health condition requires, but no later than 7 calendar days after receiving the request, unless a shorter minimum time frame is established under state law. If the state determines that it needs additional information VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 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 could be extended by up to 14 calendar days. Such extensions may be justified and in the beneficiary’s interest if medical evidence from outside providers is needed to support the request, or there are other circumstances identified by either the provider or the beneficiary. Independent of this proposed rule’s API proposals and their application to Medicaid prior authorization requests, Medicaid has longstanding beneficiary notice and fair hearing regulations. CMS has interpreted these existing regulations to apply to prior authorizations requests for Medicaid FFS, and expects to do so in the future. These existing Medicaid beneficiary notice and fair hearing requirements will remain in full effect without change, regardless of how or if the API proposals are finalized. Specifically, the current Medicaid notice regulations at 42 CFR 435.917 apply to all prior authorization decisions and require a state to provide the beneficiary with timely and adequate written notice of any decision regarding the beneficiary’s prior authorization request, as any such decision would cause a ‘‘denial or change in benefits and services.’’ 104 The existing regulations do not specify a timeframe for providing notice to a beneficiary of the state decision, nor do we propose such a change to these regulations herein. When a state denies the prior authorization request in whole or in part, the beneficiary notice must include, in addition to the content described in 42 CFR 435.917, the notice content described in 42 CFR part 431, subpart E, including information about the beneficiary’s right to request a fair hearing to appeal the partial or total denial.105 These requirements are separate from, and independent of, the new timeline for provider notice that we are proposing at 42 CFR 440.230(e)(1). Existing regulations at 42 CFR 431.220(a)(1) require the state to provide beneficiaries the opportunity to request a fair hearing if the state fails to act on 104 See 42 CFR 435.917(a). discussion in the Medicaid and Children’s Health Insurance Programs: Eligibility Notices, Fair Hearing and Appeal Processes for Medicaid and Other Provisions Related to Eligibility and Enrollment for Medicaid and CHIP final rule (hereinafter ‘‘Eligibility and Appeals Final Rule’’), published in the Federal Register on November 30, 2016 (81 FR 86382, 86395) (approvals of prior authorization requests for an amount, duration, or scope that is less than what the beneficiary requested are subject to fair hearing requirements in 42 CFR part 431, subpart E). 105 See PO 00000 Frm 00063 Fmt 4701 Sfmt 4702 76299 a claim with reasonable promptness. We consider a prior authorization request a type of claim. Therefore, beneficiaries have the right to a fair hearing when the state fails to make prior authorization decisions with reasonable promptness. Existing regulations at 42 CFR 431.220(a)(1) require that states grant Medicaid beneficiaries the opportunity for a fair hearing whenever a state takes an action as defined in 42 CFR 431.201. This definition includes ‘‘a termination, suspension of, or reduction in covered benefits or services,’’ which, in turn, includes any termination, suspension of, or reduction in benefits or services for which there is a current approved prior authorization. Under existing regulations at 42 CFR 431.211, a state must provide an individual at least 10 days advance notice prior to taking an action and must afford the beneficiary the right to the continuation of services pending the resolution of the state fair hearing, in accordance with 42 CFR 431.230. Therefore, the state must provide advance notice to beneficiaries of any termination, suspension of, or reduction in benefits or services for which there is a current approved prior authorization and must afford the beneficiary the right to request a fair hearing, in accordance with 42 CFR part 431, subpart E. This advance notice requirement would not be affected by any of the proposed changes in this proposed rule. To make it explicit that existing Medicaid beneficiary notice and fair hearing rights apply to Medicaid FFS prior authorization decisions, independent of the notification timeframe proposals elsewhere in this proposed rule, we are proposing several clarifying updates to the existing regulations at 42 CFR 431.201, 431.220, and 431.917, and a new 42 CFR 440.230(e)(2). These proposed changes, if finalized as proposed, would not change Medicaid notice or fair hearing policy or operational requirements for states. Additionally, these proposed changes, if finalized as proposed, would be applicable upon the effective date of the final rule, and thus would take effect sooner than the proposed timeframes for issuing provider notice of a prior authorization decision in 42 CFR 440.230(e)(1). Finally, we note that these proposed Medicaid beneficiary notice and fair hearing regulation changes seek only to clarify, not change, existing policy. Therefore, our interpretation of how existing regulations apply to Medicaid FFS prior authorization decisions, as previously described, applies today and will continue to apply in the future, E:\FR\FM\13DEP2.SGM 13DEP2 lotter on DSK11XQN23PROD with PROPOSALS2 76300 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules regardless of whether these changes are finalized as proposed. We propose the following changes to clarify how existing Medicaid beneficiary notice and fair hearing regulations apply to Medicaid FFS prior authorization decisions: • Modification of the headers in 42 CFR 435.917 to clarify that the information in this section relates broadly to eligibility, benefits, and services notices. Specifically, we propose to remove the word ‘‘eligibility’’ from the headers of paragraphs (a) and (b) of 42 CFR 435.917 to reflect the content of these paragraphs more accurately. • Revision of the definition of an ‘‘action’’ at 42 CFR 431.201 to include termination, suspension of, or reduction in benefits or services for which there is a current approved prior authorization. We also propose to revise the definition of the term ‘‘action’’ to improve readability by numbering the components of the definition, rather than listing them in a single paragraph. • Modification of 42 CFR 431.220 to add a new paragraph (a)(1)(vi) to add prior authorization decisions to the list of situations in which a state must provide the opportunity for a fair hearing in circumstances where the beneficiary believes the agency has taken an action erroneously, denied their claim for eligibility or for covered benefits or services, or issued a determination of an individual’s liability, or has not acted upon the claim with reasonable promptness. • Revision of 42 CFR 435.917(b)(2) to include, among the types of notices that need to comply with the requirements of 42 CFR 431.210, a reference to denials of, or changes in, benefits and services for beneficiaries receiving medical assistance. This would ensure that individuals receiving medical assistance who are denied benefits or services would receive a notice that includes the content at 42 CFR 431.210, which requires that notices include a clear statement of the specific reasons supporting the intended action. • Addition of a new 42 CFR 440.230(e)(2) to specify that states must provide beneficiaries with notice of the Medicaid agency’s prior authorization decisions in accordance with 42 CFR 435.917 and provide fair hearing rights, including advance notice, in accordance with 42 CFR part 431, subpart E. We make these proposed changes at the CFR sections identified in Table 6. Readers are reminded that the Medicaid beneficiary notice requirements at 42 CFR 435.917 and 431.210 through 431.214, including all proposed revisions and additions, such VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 as the proposal at 42 CFR 440.320(e)(2) previously discussed, apply to the written notice provided by the state to the beneficiary. These requirements, including the provision of fair hearing rights, are long-standing and exist independently of the proposed PARDD API provisions of this proposed rule, which represents an interaction between the payer and the provider. Nor do the Medicaid beneficiary notice requirements conflict with the communication of denial reasons to the provider under the proposals in section II.D.4.a. of this proposed rule. The current application of existing notice and fair hearing requirements to Medicaid FFS prior authorization decisions, including the proposed clarifications as previously discussed, is consistent with current regulations for notice and appeal rights for managed care prior authorization decisions. These are sometimes referred to as service authorizations or adverse benefit determinations.106 In summary, our existing Medicaid beneficiary notice and fair hearing regulations apply to Medicaid FFS prior authorization decisions. We propose several revisions and additions to these regulations that would clarify, but not change, their application to Medicaid FFS prior authorization decisions. These include revisions to the definition of ‘‘action’’ and making explicit that prior authorization denials are subject to the same notice and fair hearing rights as other denials of services. These revisions would become applicable upon the effective date of the final rule. We are proposing these clarifications regarding the application of existing Medicaid beneficiary notice and fair hearing requirements at the CFR sections identified in Table 6. We seek comments both on our proposals and on how states currently apply these notice and fair hearing rights to prior authorization decisions. c. Medicaid Managed Care To implement the proposed authorization timeframes for Medicaid managed care, we also propose to revise the CFR sections identified in Table 5. Under our proposal, the new timeframes for Medicaid managed care plans to provide notice of decisions on standard (non-expedited) prior authorization requests would apply beginning with the rating period that starts on or after January 1, 2026. 106 See 42 CFR 438.400 (definition of adverse benefit determination), 438.404 (timely and adequate notice for adverse benefit determination), and 438.420 (continuation of benefits while managed care plan appeal and the state fair hearing process are pending). PO 00000 Frm 00064 Fmt 4701 Sfmt 4702 We propose to revise 42 CFR 438.210(d)(1) to reflect that, beginning with the rating period that starts on or after January 1, 2026, managed care plans must provide notice of standard authorization decisions within stateestablished timeframes that may not exceed 7 calendar days following the plan’s receipt of the request for service. We propose to specify the standard authorization requirements by compliance date by leaving the section header ‘‘Standard authorization decisions’’ as 438.210(d)(1) and redesignating standard authorization timeframes as 438.210(d)(1)(i)(A) and (B). We also proposed to redesignate authorization decision timeframe extensions from § 438.210(d)(1)(i) and (ii) to § 438.210(d)(1)(ii)(A) and (B) and proposed to make slight revisions to the text for readability. Our proposal would not change the current provisions for how failure to issue a decision within the required timeframe constitutes an adverse benefit determination that can be appealed under 42 CFR 438.404(c)(5). Section 438.404 and other regulations governing appeal rights in 42 CFR part 438, subpart F, would continue to apply. This is also consistent with how the definition of ‘‘adverse benefit determination’’ in 42 CFR 438.400(b) includes a Medicaid managed care plan failing to make an authorization decision within the regulatory timeframes. We note that under current regulations at 42 CFR 438.3(s)(1) and (6) and 438.210(d)(3), Medicaid managed care plans must also comply with the requirements in section 1927 of the Act regarding coverage and prior authorization of covered outpatient drugs. Nothing in this proposed rule would change these requirements. Finally, because some Medicaid MCOs are applicable integrated plans as defined in 42 CFR 438.2, our proposal related to 42 CFR 422.631(d) would apply to those plans. We are not proposing to change the required timeframes for expedited decisions at 42 CFR 438.210(d)(2), but we are proposing to amend the CFR sections identified in Table 5 to clarify that the MCO, PIHP, or PAHP must make these decisions on shorter timeframes if the state requires shorter timeframes. However, as described previously, we are soliciting comment on the possible alternative of a shorter time frame of 48 hours maximum, and would use that information to determine if expedited decisions should be required in less time, and as expeditiously as the beneficiary’s condition requires. We are not proposing any changes to the authority E:\FR\FM\13DEP2.SGM 13DEP2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules for a 14-day extension provided at 42 CFR 438.210(d)(2)(ii). The proposal to amend 42 CFR 438.210(d) would also apply to standard and expedited decisions made by CHIP managed care entities because of the cross-reference to 42 CFR 438.210 in current 42 CFR 457.1230(d). d. CHIP Fee-for-Service and Managed Care To implement the proposed prior authorization timeframes for CHIP, we propose to revise certain policies affecting the timing for making decisions on prior authorization requests under the CHIP Fee-for-Service and Managed Care program. These changes are summarized in Table 5. Beginning on January 1, 2026, decisions related to prior authorization of health services would be required to be completed in accordance with the medical needs of the patient, but no later than 7 calendar days after receiving the request for a standard determination and 72 hours after receiving the request for an expedited determination, unless an alternative option is preferred by industry based on public comments. If a beneficiary requests an extension of a prior authorization review, or if the provider or health plan determines that additional information is needed for such review, an extension of up to 14 calendar days may be granted. We propose to remove the option for states to follow existing state law regarding prior authorization of health services, requiring states to instead follow these updated timeframes. However, if state laws are more stringent than our proposal, states would be allowed to apply and enforce those shorter timeframes for prior authorization responses. We believe timely prior authorization decisions are an important beneficiary protection, and CHIP beneficiaries should be afforded the same decision timeframes as Medicaid and Medicare beneficiaries. Existing CHIP regulations at 42 CFR 457.1130(b) require a state to ensure that a beneficiary has an opportunity for external review of health services matters, including a delay, denial, reduction, suspension, or termination of health services, in whole or in part, including a determination about the type or level of service. Under this regulation, CHIP beneficiaries must have an opportunity for external review of prior authorization decisions. We are not proposing any changes to this 76301 requirement, as it already applies to decisions related to the prior authorization of services. Overall, we believe that the decision and notification timeframes proposed for certain impacted payers in this rule would help ensure that prior authorization processes do not inappropriately delay patient access to necessary services. Introducing prior authorization decision timeframes that are the same across these impacted payers for items and services that require prior authorization would also help providers better organize and manage administrative resources and thus may make more time available for providers to render patient-centered care. We believe these proposals would make substantive improvements to the care experience for patients and lead to better health outcomes. In turn, better health outcomes would contribute to more efficient use of program resources. We request comments on these proposals, specifically comments that would provide insight on any unintended consequences of these proposed policies to improve the decision or notification timeframes for prior authorizations. TABLE 5: PROPOSED PRIOR AUTHORIZATION NOTIFICATION TIMELINES AND CERTAIN REGULATORY CHANGES RELATED TO NOTIFICATIONS AND DECISIONS - MA, MEDICAID AND CHIP FFS, CHIP MANAGED CARE Medicare Advantage Applicable Integrated Plans Applicable Integrated Plans Enrollee Notification Requirement Enrollee Standard Notifications Requirement 42 CFR 422.568(b)(l) 42 CFR 422.63 l(d)(2)(i)(B) Enrollee Expedited Notification Requirements Medicaid FFS Notice of Decisions on Expedited and Standard Prior Authorization Requests Prior Authorization Decision Notification Expedited Prior Authorization Decision Timeframes Prior Authorization Decisions 42CFR 422.63 l(d)(2)(iv)(B)(l) 42CFR 422.63 l(d)(2)(iv)(B)(2) 42 CFR 440.230(e)(l) Medicaid Managed Care Medicaid Managed Care Through existing cross reference to 42 CFR 438.210 at 42 CFR 457.1230(d) CHIP FFS Prior Authorization Decisions 42 CFR 457.495(d)(l) Note: some of the citations included in Table 5 also appear in the full list of citations in Table 7. They are included in the table in this section for ease of reference for the reader for this section. VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 PO 00000 Frm 00065 Fmt 4701 Sfmt 4725 E:\FR\FM\13DEP2.SGM 13DEP2 EP13DE22.005</GPH> lotter on DSK11XQN23PROD with PROPOSALS2 CHIP Managed Care 42 CFR 438.210(d)(l) 42 CFR 438.210(d)(2)(i) 76302 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules TABLE 6: PROPOSED MEDICAID FFS PRIOR AUTHORIZATION BENEFICIARY NOTICE AND FAIR HEARING REGULATORY CHANGES Modification to Headers Medicaid FFS Medicaid FFS Revise Definition of Action Addition of Prior Authorization Decision to Situations for Fair Hearin Add a Notice of Denial or Change in Benefits or Services to Notices (note possible applicable dates for awareness) Beneficiary Notice of Prior Authorization Decision and Fair Hearin Ri hts Medicaid FFS Medicaid FFS 7. Extensions, Exemptions, and Exceptions a. Extensions and Exemptions for Medicaid and CHIP FFS Programs Should our proposals regarding the PARDD API be finalized as proposed, we would strongly encourage state Medicaid and CHIP FFS programs to implement the PARDD API as soon as possible, due to the many anticipated benefits of the API discussed in this section. However, we also recognize that state Medicaid and CHIP FFS agencies may face certain unique circumstances that would not apply to other impacted payers. To address these concerns, we are proposing a process through which states may seek an extension of, and, in specific circumstances, an exemption from, the PARDD API requirements. We propose the following: lotter on DSK11XQN23PROD with PROPOSALS2 (1) Extension At the regulation citations identified in Table 7, we propose to provide state Medicaid FFS and CHIP FFS programs the opportunity to request a one-time extension of up to 1 year to implement the PARDD API specified at 42 CFR 431.80(b) and 457.732(b). Some states may be unable to meet the proposed compliance date due to challenges related to securing needed funding for necessary contracting and staff resources in time to develop and implement the API requirements, depending on when the final rule is published in relation to a state’s fiscal year, legislative session, budget process, and related timeline. Some states may need to initiate a public procurement process to secure contractors with the necessary skills to support a state’s implementation of these proposed API policies. The timeline for an openly competed procurement process, together with the time needed to onboard the contractor and develop the API, can be lengthy for states. A state might need to VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 hire new staff with the necessary skillset to implement this policy. The time needed to initiate the public employee hiring process, vet, hire, and onboard the new staff may make meeting the proposed compliance timeline difficult because, generally speaking, public employee hiring processes include stricter guidelines and longer time-tohire periods than other sectors.107 Furthermore, states are currently responding to the effects of the COVID– 19 public health emergency, and their regular operational resources are overextended. Unwinding from the COVID– 19 public health emergency is also expected to require significant IT resources, which could have an impact on future IT work. In all such situations, a state might need more time than other impacted payers to implement the PARDD API requirements. The 1-year extension that we propose could help mitigate the challenges. We considered delaying implementation of the provisions in this proposed rule an additional year for states, but decided that it would be better to propose to have only those states that needed an extension apply because states vary in their level of technical expertise and ability to recruit staff and secure contracts. Should the proposal for this API be finalized as proposed, states would be permitted to submit a written application for a one-time, one-year extension as a part of their annual APD for MMIS operations expenditures. The state’s request would have to include the following: (1) a narrative justification describing the specific reasons why the state cannot reasonably 107 State hiring processes are comparable with Federal hiring processes. According to OMB, the average time-to-hire for Federal employees was 98.3 days in 2018, significantly higher than the private sector average of 23.8 days. See: https:// www.opm.gov/news/releases/2020/02/opm-issuesupdated-time-to-hire-guidance/. PO 00000 Frm 00066 Fmt 4701 Sfmt 4702 42 42 42 42 CFR 435.917(a) CFR 435.917(b) CFR431.201 CFR 43 l.220(a)(l)(vi) 42 CFR 435.917(b)(2) 42 CFR 440.230(e)(2) satisfy the requirement(s) by the compliance date, and why those reasons resulted from circumstances that are unique to the agency operating the Medicaid and/or CHIP FFS program (versus other types of impacted payers); (2) a report on completed and ongoing state implementation activities to evidence a good faith effort toward compliance; and (3) a comprehensive plan to meet the PARDD API requirements no later than 1 year after the compliance date. Under this proposal, CMS would approve an extension if, based on the information provided in the APD, CMS determines that the request adequately establishes a need to delay implementation, and that the state has a comprehensive plan to implement the proposed requirements no later than 1 year after the compliance date. We also solicit comments on whether our proposal would adequately address the unique circumstances that affect states and that might make timely compliance with the proposed API requirement difficult for states. (2) Exemption At the CFR sections identified in Table 7, we propose to permit state Medicaid FFS programs to request an exemption from the PARDD API requirements when at least 90 percent of the state’s Medicaid beneficiaries are enrolled in Medicaid managed care organizations as defined in 42 CFR 438.2. Likewise, we propose that separate CHIP FFS programs could request an exemption from the PARDD API requirements if at least 90 percent of the state’s separate CHIP beneficiaries are enrolled in CHIP managed care entities as defined at 42 CFR 457.10. In this circumstance, the time and resources that the state would need to expend to implement the PARDD API requirements for a small FFS population may outweigh the benefits of E:\FR\FM\13DEP2.SGM 13DEP2 EP13DE22.006</GPH> Medicaid FFS lotter on DSK11XQN23PROD with PROPOSALS2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules implementing and maintaining the API. Unlike other impacted payers, state Medicaid and CHIP FFS programs do not have a diversity of plans to balance implementation costs for those plans with low enrollment. If there is low enrollment in a state Medicaid or CHIP FFS program, there is no potential for the technology to be leveraged for additional beneficiaries. States, unlike other payers, do not maintain additional lines of business. We acknowledge that the proposed exemption could mean that most beneficiaries enrolled with exempted Medicaid or CHIP FFS programs, would not receive the full benefits of having this API available to facilitate the prior authorization exchange between payers and providers. To address this, we propose that states that are granted an exemption would be expected to implement an alternative plan to enable the efficient electronic exchange and accessibility of prior authorization information for those beneficiaries who are served under the FFS program and to ensure that enrolled providers will have efficient electronic access to the same information through other means, to help ensure that Medicaid or CHIP services are provided with reasonable promptness and in a manner consistent with the simplicity of administration and in the best interests of those beneficiaries who are served under the FFS program. We propose that a state could submit a written request for an exemption from the requirements for the PARDD API as part of its annual APD for MMIS operations expenditures prior to the date by which the state would otherwise need to comply with the requirements (which may be extended by 1 year if the state receives an extension). For Medicaid exemption requests, the state would be required to include documentation that it meets the criteria for the exemption based on enrollment data from the most recent CMS ‘‘Medicaid Managed Care Enrollment and Program Characteristics’’ report. For a CHIP FFS exemption, the state’s request would have to include enrollment data from Section 5 of the most recently accepted state submission to the CARTS. The state would also be required to include in its request, information about an alternative plan to ensure that providers will have efficient electronic access to the same information through other means while the exemption is in effect. CMS would grant the exemption if the state establishes to CMS’s satisfaction that it meets the criteria for the exemption and has established such an alternative plan. VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 Once an exemption has been approved, we propose that the exemption would expire if either of the following two scenarios occurs: (1) based on the 3 previous years of available, finalized Medicaid T–MSIS and/or CHIP CARTS managed care and FFS enrollment data, the State’s managed care enrollment for 2 of the previous 3 years is below 90 percent; or (2) CMS has approved a State plan amendment, waiver, or waiver amendment that would significantly reduce the share of beneficiaries enrolled in managed care and the anticipated shift in enrollment is confirmed by available, finalized Medicaid T–MSIS and/or CHIP CARTS managed care and FFS enrollment data. For the first scenario, CMS recognizes that there may be circumstances where a state’s managed care enrollment may fluctuate slightly below the 90 percent threshold in 1 year, and yet return to above 90 percent the next year. To help reduce the possible burden on exempted states experiencing this type of temporary fluctuation in managed care enrollment, CMS would consider data from the 3 previous years of available, finalized Medicaid T–MSIS and/or CHIP CARTS managed care and FFS enrollment data. We propose that if the state’s managed care enrollment for 2 of the previous 3 years is below 90 percent, the state’s exemption would expire. We propose that a state would be required to provide written notification to CMS that the state no longer qualifies for the PARDD API exemption when data confirm that there has been a shift from managed care enrollment to FFS enrollment resulting in the State’s managed care enrollment falling below the 90 percent threshold for 2 of the previous 3 years. We propose that the written notification be submitted to CMS within 90 days of the finalization of the first annual Medicaid T–MSIS managed care enrollment data and/or the CARTS report for CHIP confirming that there has been the requisite shift from managed care enrollment to FFS enrollment in 2 of the 3 previous years. For the second scenario, we recognize that there may be state plan amendments, waivers, or waiver amendments that would result in a shift from managed care enrollment to FFS enrollment. Additionally, there may be instances where anticipated enrollment shifts may not be fully realized due to certain circumstances. We propose that a state would be required to provide written notification to CMS that the state no longer qualifies for the PARDD API exemption when data confirm that there has been a shift from managed PO 00000 Frm 00067 Fmt 4701 Sfmt 4702 76303 care enrollment to FFS enrollment as anticipated in the state plan amendment or waiver approval. We propose that the written notification be submitted to CMS within 90 days of the finalization of the first annual Medicaid T–MSIS managed care enrollment data and/or the CARTS report for CHIP confirming that there has been the requisite shift from managed care enrollment to FFS enrollment. Regardless of why the exemption expires, if it expires, the state would be required to obtain CMS’s approval of a timeline for compliance with the PARDD API requirements for the state’s Medicaid FFS and/or CHIP FFS populations within two years of the expiration date of the exemption. For Medicaid and CHIP managed care, we are not proposing an extension process because we believe that managed care plans are actively working to develop the necessary IT infrastructure to be able to comply with the existing requirements at 42 CFR parts 438 and 457 and because many of these plans might benefit from efficiencies based on the variety of plan types that they offer. Many managed care plans are part of parent organizations that maintain multiple lines of business, including Medicaid managed care plans and plans sold on the Exchanges. As discussed in the CMS Interoperability and Patient Access final rule (85 FR 25607, 25612, and 25620), work done by these organizations can benefit all lines of business and, as such, we do not believe that the proposals in this rule impose undue burden or could not be achieved by the compliance date. We are soliciting comments on our assumptions regarding the scope of resources and ability of managed care parent organizations to achieve economies of scale when implementing the proposed API. Further, we seek comment on whether an extension process would be warranted for certain managed care plans to provide additional time for the plan to comply with the proposed requirement at 42 CFR 438.80(b) (which cross references 42 CFR 438.242(b)(7)) for Medicaid managed care plans and at proposed 42 CFR 457.732(b) (which would cross reference 42 CFR 457.1233(d)) for CHIP managed care entities. While we are not proposing such a process for managed care plans and entities and do not believe one is necessary, we are open to evaluating options for possible future rulemaking. Were we to adopt an extension process for these managed care plans and entities, what criteria should a managed care plan or entity meet to qualify for an extension? Should the criteria include E:\FR\FM\13DEP2.SGM 13DEP2 76304 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules lotter on DSK11XQN23PROD with PROPOSALS2 enrollment size, plan type, or certain unique plan characteristics that could hinder their achievement of the proposed requirements by the proposed compliance date? We also seek comment on whether, were we to propose such a process for Medicaid managed care plans or CHIP managed care entities, the entity responsible for evaluating the criteria and exception evaluation process should be the state and whether states could implement the exception evaluation process with available resources. Consistent with the exception process proposed for QHP issuers on the FFEs at 45 CFR 156.222(c), we would expect managed care plans seeking extensions to provide, at a minimum, a narrative justification describing the reasons why a plan or entity cannot reasonably satisfy the requirements by the proposed compliance date, an explanation of the impact of non-compliance upon enrollees, an explanation of the current or proposed means of providing electronic health information to providers, and a comprehensive plan with a timeline to achieve compliance. We request comment on the proposed extension and exemption processes. b. Exception for QHP Issuers For QHP issuers on the FFEs, we propose an exception process to the PARDD API proposal at the regulation citations identified in Table 7. We propose that if an issuer applying for QHP certification to be offered through an FFE believes it cannot satisfy the proposed requirements at 45 CFR 156.223(b) for the PARDD API, the issuer would have to include as part of its QHP application a narrative justification describing the reasons why the issuer could not reasonably satisfy the requirements for the applicable plan year, the effect of non-compliance upon providers and enrollees, the current or proposed means of providing health information to providers, and solutions and a timeline to achieve compliance with the requirements of this section. We propose that the FFE may grant an exception to the requirements at 45 CFR 156.223(b) for the PARDD API if it determines that making qualified health plans of such issuer available through such FFE is in the interests of qualified individuals in the state or states in which the FFE operates, and an exception would be warranted to permit the issuer to offer qualified health plans through the FFE. This proposal would be consistent with the exception for QHP issuers on the FFEs that we finalized for the Patient Access API in the CMS Interoperability and Patient Access final rule (85 FR 25552). For VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 instance, as noted in that final rule, that exception could apply to small issuers, financially vulnerable issuers, or new entrants to the FFEs that demonstrate that deploying FHIR API technology consistent with the required interoperability standards would pose a significant barrier to the issuer’s ability to provide coverage to patients, and not certifying the issuer’s QHP or QHPs would result in patients having few or no plan options in certain areas. We believe that having a QHP issuer offer QHPs through an FFE generally is in the best interest of patients and would not want patients to have to go without access to QHP coverage because the issuer was unable to implement this API. In summary, we propose to permit certain impacted payers (state Medicaid and CHIP FFS programs and QHP issuers on the FFEs) to apply for an extension, exemption, or exception, as applicable, from implementing the proposed PARDD API. We propose that these programs would submit and be granted approval for an extension or exemption as part of applicable established processes. We propose that submission requirements would include certain documentation identified in the regulatory citations in Table 7. 8. Public Reporting of Prior Authorization Metrics We are proposing to require impacted payers to publicly report certain aggregated metrics about prior authorization by posting them directly on the payer’s website or via a publicly accessible hyperlink(s). This proposed reporting would be at the organizational level for MA, the state level for Medicaid and CHIP FFS, the plan level for Medicaid and CHIP managed care, and the issuer level for QHP issuers on the FFEs. We propose these levels of reporting for each impacted payer because we believe these represent the appropriate organizational level for which aggregated data would be meaningful to a patient or provider to understand an entity’s performance on timeframes for approvals, on volumes of denials and appeals for prior authorization. For example, an MA organization will generally have multiple contracts and it is not uncommon for these organizations to have more than one contract for the same service area. Ideally, reports would present true aggregate figures, which would be at the organizational level. Medicaid and CHIP managed care would be reported at the plan level so that beneficiaries could compare and states could evaluate plans within the state. QHP issuers report on PO 00000 Frm 00068 Fmt 4701 Sfmt 4702 quality improvement strategies consistent with standards of section 1311(g) of the Affordable Care Act (45 CFR 156.20), which is at the issuer level, and would include information for the plans under their purview. Such reporting of prior authorization data at the issuer level would be consistent with their quality reports. Prior authorization data would be compiled from multiple sources, on multiple measures and individuals, and compiled into aggregate data, or summary data, for purposes of public reporting and statistical analysis. Payers may use the detailed information to assess their internal performance, understand trends and determine where improvements may be necessary. At the same time, they would be able to share the aggregate data for all programs with the public. We believe the availability of such data from the payers could contribute to improvements in the prior authorization process. Should this proposed rule be finalized as proposed, we believe that, as payers create and analyze these reports, there would use the data to learn about their own performance. Additionally, we believe that the public availability of prior authorization decision data would further transparency in consumer information. When some patients are looking for a new plan, they may compare several factors including, but not limited to, access to care or authorizations, premiums, benefits, and cost sharing or coinsurance. Both access to care and transparency regarding prior authorization processes could be important considerations. Some providers may find metrics about prior authorization approvals or appeals useful when selecting payer networks, or to be aware of the trends in performance of different payers. Providers should have access to information about how they will be able to treat their patients, and whether it will be possible to do so in a manner they believe will support value-based care and services that are appropriate and necessary for each patient’s health. The legal authority for requiring such public reporting is discussed further in section II.D.10. of this proposed rule. We propose that for each metric listed, data would be reported in aggregate for all items and services. We are not proposing that payers report on categories of items and services, but rather aggregate the information as totals or percentages of total items and services, as outlined in each proposed requirement listed in this section of this rule. Aggregate data could allow each organization to examine trends and obtain insight into their own E:\FR\FM\13DEP2.SGM 13DEP2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules lotter on DSK11XQN23PROD with PROPOSALS2 performance. As noted elsewhere in this proposed rule, we are excluding drugs that could be covered by the impacted payers in this proposed rule. For example, this would include outpatient drugs, drugs that may be prescribed, those that may be administered by a provider, or those that may be administered in a pharmacy or hospital. We propose that impacted payers make reports available annually on all of the following: • A list of all items and services that require prior authorization. • The percentage of standard prior authorization requests that were approved, aggregated for all items and services. • The percentage of standard prior authorization requests that were denied, aggregated for all items and services. • The percentage of standard prior authorization requests that were approved after appeal, aggregated for all items and services. • The percentage of prior authorization requests for which the timeframe for review was extended, and the request was approved, aggregated for all items and services. • The percentage of expedited prior authorization requests that were approved, aggregated for all items and services. • The percentage of expedited prior authorization requests that were denied, aggregated for all items and services. • The average and median time that elapsed between the submission of a request and a determination by the payer, plan, or issuer, for standard prior authorizations, aggregated for all items and services. • The average and median time that elapsed between the submission of a request and a decision by the payer, plan or issuer, for expedited prior authorizations, aggregated for all items and services. We do not propose a format for how payers would present the aggregated data in the reports, but we encourage them to consider readability, and accessibility in preparing the data for viewing and comprehension. We request comments from all stakeholders, including payers, providers, and VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 consumers, on how the information might be displayed on payer websites in a useful and meaningful manner for patients and providers, including which data would be most useful. By having access to the requirements for prior authorization of items and services, and data about prior authorization decisions, patients and providers would have a better understanding of a payer’s prior authorization review and approval processes. Such information may be helpful for some patients when making decisions at the time of open enrollment, special enrollment, or plan selection throughout the year. The first set of data to be publicly available under our proposal would reflect current practices, rather than payer behavior based on compliance with this proposed rule. However, we anticipate that, over time, data might show improvements after implementation of our proposals regarding the PARDD API and timeframes for prior authorization decisions. In addition, year-over-year comparisons could demonstrate positive, or negative, trends, which alone could be useful information for patients who are making enrollment decisions. We acknowledge that not all patients have a choice in enrolling with payers, such as with the Medicaid and CHIP FFS programs. Nonetheless, publicly available data would aid interested providers and patients to generally understand payer performance with respect to prior authorization processes for decisions, approvals, denials, and appeals. CMS would enforce the requirements based on the existing compliance policies for the impacted payers. To facilitate the incorporation of such data more directly into a consumer-friendly comparison tool, we may propose in future rulemaking to use these data to help develop quality measures to incorporate into quality star ratings across certain payer programs, specifically for MA and QHP issuers on the FFEs. In summary, we propose that, beginning in 2026, and by March 31 of that year, impacted payers must PO 00000 Frm 00069 Fmt 4701 Sfmt 4702 76305 annually report certain aggregated prior authorization metrics from the previous year. These reports must be posted on websites or publicly available hyperlinks. We are making this proposal at the CFR sections identified in Table 7. For Medicaid managed care, we propose to replace the current provision at the CFR sections identified in Table 7 which addresses the applicability date for the provisions in that section, with this new requirement. The current provision was added in 2016 to clarify that the previous requirements would remain in effect until the new provisions began starting with rating periods beginning on or after July 1, 2017. As several rating periods have passed since July 1, 2017, we do not believe this clarifying text is needed. Our proposal would apply to CHIP managed care entities through operation of the cross-reference to 42 CFR 438.210, which is currently in 42 CFR 457.1230(d). We propose to accomplish this by removing the current exception for complying with paragraph 42 CFR 438.210(f). As such, the prior authorization metrics policies would be applicable to CHIP managed care through the cross-reference at 42 CFR 457.1230(d) to 42 CFR 438.210. We request comments on the proposal for reporting metrics on prior authorization, for example, on the proposed types of data to be included in the report, on the proposal to report data in aggregate by items and services, on the proposed reporting timeframe, the number of reports, and if there are any other types of data that could be useful to payers, providers, and patients. Given that use of the PARDD API would develop over time, we also request comment on the timing for adding a metric similar to those proposed for the Patient Access API in section II.A, for the total number of prior authorization requests received via the PARDD API. This information could be useful for evaluating the degree to which APIfacilitated requests would grow over time. BILLING CODE 4120–01–P E:\FR\FM\13DEP2.SGM 13DEP2 lotter on DSK11XQN23PROD with PROPOSALS2 I PARDDAPI I 42CFR 422.122(b) PO 00000 I Frm 00070 II.D.5.b. I 11.D.5.b. I II.D.7.a. I II.D.7.a. I II.D.7.b. I II.D.8. I 11.D.8. I Fmt 4701 Jkt 259001 11.D.4.a. I Information Sfmt 4702 E:\FR\FM\13DEP2.SGM 13DEP2 About Status of Prior Authorization Reasonfor Denial of Prior Authorization Standard Prior Authorization Decision Timeframe Expedited Prior Authorization Decision Timeframe Extension for Medicaid and CHIPFFS Exemption for Medicaid and CHIP FFS Exceptions forQHP Issuers Public Reporting of Prior Authorization Metrics Prior Authorization Metrics Compliance Date IN/A 142 CFR 431.80(b) I Through proposed cross reference to 42 CFR 431.80 at 42 CFR 438.242(b)(7) Through proposed cross reference to 42 CFR 431.80 at 42 CFR 438.242(b)(7) Through proposed cross reference to 42 CFR 431.80 at 42 CFR 438.242(b)(7) 42 CFR438.210(d) 42CFR 457.732(b) 42CFR 422.122(a)(l) NIA 42CFR 431.80(a)(l) 42CFR 422.122(a)(2) NIA 42CFR 431.80(a)(2) 42CFR 422.568(b )(1) 42CFR 422.570(d)(l) 42CFR 422.631(d)(2)(i)(B) 42CFR 440.230(e)(l)(A) NIA 42CFR 422.631(d)(2)(iv)(B)(2) 42CFR 440.230(e)(l)(B) NiA 42CFR 457.495(d)(l) NIA NIA 42CFR 431.80(c)(l) NiA 42CFR 457.732(d)(l) NIA NIA 42CFR 431. 80(C)(2) NIA 42CFR 457.732(d)(2) I NIA I NIA I NIA I NiA 42CFR 457.732(a)(l) 42CFR 457.732(a)(2) 42CFR 457.495(d)(l) I NIA Through existing cross reference to 42 CFR 438.242 at 42 CFR 457.1233(d) Through existing cross reference to 42 CFR 438.242 at 42 CFR 457.1233(d) Through existing cross reference to 42 CFR 438.242 at 42 CFR 457.1233(d) Through existing cross reference to 42 CFR 438.210 at 42 CFR 457.1230(d) I 45 CFR 156.223(b) I 45 CFR 156.223(a)(l) I 45 CFR 156.223(a)(2) I Ya/A NiA I Ya/A I NiA I Ya/A I NiA I Ya/A I NiA I 45 CFR 156.223(d) 42CFR 422.122(c) NIA 42 CFR 440.230(f) 42 CFR 438.210(f) 42CFR 457.732(c) Through existing cross reference to 42 CFR 438.210 at 42 CFR 457.1230(d) NIA NIA NIA 42 CFR 438.210(f) NIA Through proposed cross reference to 42 Cl•R 438.210 at 42 CFR 457.1230(d) I 45 CFR 156.223(c) I Ya/A Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules 11.D.3.a. 11.D.4.a. EP13DE22.007</GPH> 76306 18:56 Dec 12, 2022 BILLING CODE 4120–01–C VerDate Sep<11>2014 TABLE 7: PROPOSALS FOR IMPROVING PRIOR AUTHORIZATION PROCESSES lotter on DSK11XQN23PROD with PROPOSALS2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules 9. ‘‘Gold-Carding’’ Programs for Prior Authorization During the CMS listening sessions, we heard about the potential for additional opportunities for payers to support efficiencies in the prior authorization process, including discretion about when to require prior authorization and basing such decisions on data and provider performance. For example, prior authorization is sometimes required for certain items and services that are almost always approved. Some providers have demonstrated a consistent history of complying with all payer requirements for the submission of documentation to support a request. Some payers have implemented what they term ‘‘gold-carding’’ or similar programs to relax or reduce prior authorization requirements for providers that have demonstrated a consistent pattern of compliance. In such programs, providers are relieved of requirements to submit prior authorization requests based on data indicating their adherence to submission requirements, appropriate utilization of items or services, or other evidence-driven criteria. Stakeholders said that the prior authorization process could be significantly more efficient and cost-effective for all parties if these programs were more broadly implemented. Under the MA program, MA organizations may develop and apply prior authorization policies, make prior authorization decisions, and have the discretion to implement gold-carding programs within each contracted plan. CMS uses a similar approach to goldcarding in the Medicare FFS Review Choice Demonstration for Home Health Services, under which home health agencies in demonstration states that select certain review choice options and have a review affirmation rate or claim approval rate of 90 percent or greater over 6 months are given the option to continue in the pre-claim review option or choose a selective post-payment review or spot check review process.108 We believe the use of gold-carding and similar prior authorization reduction programs could help alleviate provider burden. We are also aware that some states have begun to enact goldcarding programs to address provider and patient complaints about access to healthcare services. We encourage 108 Centers for Medicare & Medicaid Services (2019). Review Choice Demonstration for Home Health Services. Retrieved from https:// www.cms.gov/Research-Statistics-Data-andSystems/Monitoring-Programs/Medicare-FFSCompliance-Programs/Review-ChoiceDemonstration/Review-Choice-Demonstration-forHome-Health-Services.html. VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 payers to adopt gold-carding approaches that would allow prior authorization exemptions or more streamlined reviews for certain providers who have demonstrated compliance with requirements. By taking this step, payers could join CMS in helping to build an infrastructure that would allow clinicians to deliver care in a timely and value-based manner. We seek comment for consideration for future rulemaking on how to measure whether and how such gold-carding or prior authorization exemption programs could reduce provider and payer burden, and improve services to patients. In particular, we seek comment on how CMS and other payers could ensure that such programs benefit diverse populations, including individuals in rural areas, individuals with disabilities, individuals with chronic illnesses, small and minority providers, and providers who disproportionately serve minority and underserved communities. To further encourage the adoption and establishment of gold-carding programs, we are considering including a gold-carding measure as a factor in quality ratings for MA organizations and QHPs as a way for these payers to raise their scores in the quality star ratings. We seek comment for potential future rulemaking on the incorporation of such a measure into star ratings for these organizations. We also considered proposing gold-carding as a requirement in payer’s prior authorization policies and seek comment on how such programs could be structured to meet such a potential requirement. 10. Statutory Authorities To Require Improvements in Prior Authorization Processes, Decision and Notification Timeframe Proposals a. Medicare Advantage Section 1856(b) of the Act directs the Secretary to establish regulatory standards for MA organizations that are consistent with, and carry out, Part C of the Medicare statute, including the provisions in section 1852 of the Act. Section 1852(a) and (d) of the Act provide for MA plans to cover medically necessary Part A and Part B benefits, including by making benefits available and accessible with reasonable promptness. Section 1852(c)(1)(G) of the Act requires that MA organizations disclose to their enrollees any rules regarding prior authorization or other review requirements that could result in nonpayment. Section 1852(g)(1)(A) of the Act requires an MA plan to have a procedure for making determinations about whether an enrollee is entitled to receive a health service, how much the PO 00000 Frm 00071 Fmt 4701 Sfmt 4702 76307 enrollee is required to pay for such service and to provide an enrollee with a written notice if the plan denies coverage. Section 1852(g)(1)(A) of the Act also requires that coverage determinations be made on a timely basis. Section 1852(g)(3)(B)(iii) of the Act requires that the organization notify the enrollee (and physician involved, as appropriate) of an expedited determination under time limitations established by the Secretary, but not later than 72 hours of the time of receipt of the request. This proposal serves to ensure that MA organizations carry out their responsibilities under section 1852 of the Act in a consistent and standardized fashion. In the interest of ensuring that MA organizations continue to use appropriate standards, process organization determinations in a timely manner, and provide enrollees with appropriate access to care under the authorities referenced earlier, we are proposing to require that MA organizations implement certain APIs that provide information about the coverage and documentation requirements for prior authorization, that they respond to prior authorization requests with the status of that request, and that they meet certain timeframes for making decisions on prior authorization requests. We are proposing that MA organizations implement the PARDD API, using certain implementation specifications as discussed in section II.D.3.a. of this proposed rule. These implementation specifications would be expected to improve the overall prior authorization process by addressing deficiencies that exist in the process today with respect to providers’ access to information about the prior authorization rules and documentation requirements. The PARDD API would communicate the coverage and documentation requirements for a prior authorization, indicating if an authorization is required for a specific item or service and what documentation is required to support an authorization request. The PARDD API would be consistent with the disclosure obligation on MA organizations in section 1852(c)(1)(G) of the Act by disclosing to providers the same information that generally must be provided to enrollees about which covered benefits are subject prior authorization and would serve the same larger purpose of ensuring access to coverage by communicating the limits and rules for covered services. Additionally, the proposed PARDD API would be a mechanism for receiving and responding to requests for coverage determinations before the services are E:\FR\FM\13DEP2.SGM 13DEP2 lotter on DSK11XQN23PROD with PROPOSALS2 76308 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules rendered or items furnished; therefore, the proposed requirement to adopt and use the PARDD API would be an additional standard for implementing and complying with section 1852(g) of the Act regarding an MA organization’s obligation to make coverage determinations. The PARDD API could enable the provider to compile information that could be used in the HIPAA-compliant prior authorization request through their existing workflow and receive a timely response to that request. In concert with these APIs, we propose that the payer provide the status of the request, such as whether it was approved, or denied, along with a denial reason, so that the provider would know what steps to take next— whether to request a different service for the patient, to submit additional information, or to appeal the decision. These proposals would improve patient care and reduce redundancies in administrative processes between providers and payers because they would give providers clearer instruction, both for submitting the original request and, if necessary, providing additional information. The proposed APIs have the potential to improve the efficiency of the prior authorization process because they would enable providers to submit accurate information with the request, which could reduce the number of appeals or denials, and possibly eliminate requests for additional documentation. The policies could improve timely access to care for beneficiaries, by mitigating delays that sometimes occur when a provider is trying to determine coverage requirements or does not know what documents to submit to obtain approval for a service. Improvements in the timeliness of payer operations and provider services would contribute to program efficiency, and effective operations and would be in the best interest of the enrollees. The proposal to require MA organizations to make certain changes to the timeframes in which these payers provide notice for prior authorization has the potential to improve patient access to care in program operations as discussed in section II.D.5.b. of this proposed rule. The proposal could prevent some patients from abandoning care while waiting for an authorization, and it could improve efficiencies by avoiding repeat phone calls from providers who must check on the status of an authorization over the course of several days, or sometimes weeks. The proposals to improve timeframes for expedited and standard decisions is VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 being made under the premise that these changes are overdue, feasible, and would benefit patients and providers. Furthermore, by establishing more certainty in the process for providers, should the rule be finalized as proposed, there may be a reduction in unnecessary repeat requests for services. More responsive timeframes would also enhance enrollee access to timely and appropriate care. A shorter timeframe for both standard and expedited decisions could reduce administrative time and expense for providers and payers, as they would spend fewer resources on follow up inquiries. Providers may be able to better direct their attention to the clinical aspects of patient care. As such, these proposals are consistent with our authorities under section 1852 of the Act which requires MA organizations to have a procedure for making timely determinations and to make benefits available and accessible with reasonable promptness. Finally, section 1857(e)(1) of the Act explicitly authorizes the adoption of additional reporting requirements by MA organizations where necessary and appropriate. Our proposal to require MA plans to publicly report prior authorization metrics would enable CMS to assess implementation of the policies and attempt to determine the impact of these proposals on payers and providers. Review of these metrics could help CMS and the plans understand the impact of the proposed policies, including use of the APIs, and improved decision timeframes. The data could help plans evaluate operations, implementation of new policies and the APIs and determine what changes may be appropriate. b. Medicaid For Medicaid, most of these proposals are authorized by sections 1902(a)(4), (8), and (19) of the Act. Section 1902(a)(4) of the Act requires that a state Medicaid plan provide such methods of administration as are found by the Secretary to be necessary for the proper and efficient operation of the state Medicaid plan; section 1902(a)(8) of the Act requires states to ensure that Medicaid services are furnished with reasonable promptness to all eligible individuals; and section 1902(a)(19) of the Act requires states to ensure that care and services are provided in a manner consistent with simplicity of administration and the best interests of the recipients. Some proposals are also authorized by additional sections of the Act as discussed in this section of this rule. PO 00000 Frm 00072 Fmt 4701 Sfmt 4702 Additionally, section 1902(a)(7) of the Act requires that states must provide safeguards that restrict the use or disclosure of information concerning Medicaid applicants and beneficiaries to uses or disclosures that are directly connected with the administration of the program or plan. One of the implementing regulations for this section of the Act, at 42 CFR 431.302(c) states that purposes directly connected to plan administration include providing services for beneficiaries. CHIP programs are subject to the same requirements through a cross-reference at 42 CFR 457.1110(b). Medicaid and CHIP programs must also determine which programs require safeguards to apply to uses and disclosures of beneficiary data at 42 CFR 431.306. In order to meet the requirements of that regulation, states must have consistent criteria for release and use of information (which should conform to the proposed requirements for the PARDD API, if finalized). See 42 CFR 431.306(a). Access to information concerning beneficiaries must be restricted to persons who are subject to standards of confidentiality that are comparable to that of the Medicaid agency, in accordance with 42 CFR 431.306(b). The permission provision at § 431.306(d) is not relevant to the API functionality proposed in this section, in part because it pertains to a wellestablished administrative process conducted extensively between the enrolled providers and states currently, and the provider would not be considered an outside source. The services include those for which the state requires that a provider submit a prior authorization request, and thus needs to communicate about that prior authorization with providers enrolled with, or authorized by the state to provide care to its beneficiaries. Prior authorization can be an integral part of the Medicaid program, and facilitates access to care as well as provider payment processes. A provider enrolled with the state must meet privacy and security standards to protect the confidentiality of patient information. When requesting approval to provide certain services from the state using the state’s PARDD API as described in section II.D.3.a., the provider would be able to determine if a prior authorization is required, and what supporting documentation is necessary to obtain approval for that care. (1) PARDD API The proposed requirement for state Medicaid FFS programs and Medicaid managed care plans to implement the PARDD API is expected to improve the E:\FR\FM\13DEP2.SGM 13DEP2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules efficiency and timeliness of the prior authorization process for Medicaid beneficiaries, providers, state Medicaid agencies, and Medicaid managed care plans by addressing inefficiencies that might exist in the process today. As discussed in section II.D.3.a. of this proposed rule, the PARDD API would allow a provider to determine whether a prior authorization is required, and the documentation requirements for that prior authorization request. The PARDD API would: (1) enable providers to submit a complete prior authorization request faster and easier; (2) support more timely notice to provider and beneficiary of the disposition of the prior authorization request; and (3) permit improved scheduling of services or filing appeals, depending on the decision. The PARDD API could have the potential to improve the prior authorization process by making it more efficient, including by reducing the number of denials and appeals, or even by eliminating requests for additional documentation, as noted elsewhere in this proposed rule. lotter on DSK11XQN23PROD with PROPOSALS2 (2) Requirement for Payers To Provide Status of Prior Authorization and Reason for Denial of Prior Authorizations The proposals to require states and Medicaid managed care plans to provide specific information to providers about the status of prior authorization requests are expected to enable providers to plan care for their patients after submitting a prior authorization request. As discussed in section II.D.4.a. of this proposed rule, providers would receive a response to an electronic prior authorization request to indicate that the request is approved, denied, or if additional information is needed. If a prior authorization has been denied, the provider would be provided information about why, so that they can either resubmit the request with updated information, identify alternatives for the patient, or appeal the decision. These proposals would improve the timeliness, clarity, and consistency of information for providers regarding prior authorization requests, help providers determine next steps for timely patient care, and reduce payer, provider, and patient burden by eliminating the need for repeated inquiries. VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 (3) Requirements for Prior Authorization Decision Timeframes, Notifications Related to Prior Authorization Decision Timeframes, and Amendments to Existing Medicaid Fair Hearings and Appeals Regulations As discussed in section II.D.5 of this proposed rule, delayed prior authorization decisions may directly affect patient care by delaying access to treatment, services, and supplies, as well as transfers between hospitals and post-acute-care facilities. The proposed timeframes for making prior authorization decisions about items and services that require prior authorization in Medicaid FFS and managed care programs would help providers better manage administrative resources, make more time available for providers to render patient care, and facilitate faster access to services. We believe these proposals would make substantive improvements to the care experience for Medicaid beneficiaries and lead to better health outcomes. In turn, better health outcomes would contribute to more efficient use of Medicaid program resources. We believe that the proposal to shorten the maximum amount of time for a Medicaid managed care plan to make a prior authorization decision from 14 calendar days to 7 calendar days would improve the efficient operation of the Medicaid program by facilitating faster receipt of services or filing of appeals. Our proposal to make explicit in regulation text that current notice and fair hearing requirements apply to Medicaid FFS prior authorization decisions is authorized under section 1902(a)(3) of the Act. Section 1902(a)(3) of the Act requires that a Medicaid state plan provide for an opportunity for a fair hearing to any individual whose claim for medical assistance under the plan is denied or is not acted upon with reasonable promptness. These proposed amendments are also supported by the 14th Amendment to the United States Constitution and case law on due process, specifically, Goldberg v. Kelly, 397 U.S. 254 (1970). States must establish timely notice and fair hearing processes meeting due process standards under Goldberg v. Kelly, as incorporated into existing Medicaid fair hearing regulations at 42 CFR part 431, subpart E, see 42 CFR 431.205(d). Currently, and under our proposal, 42 CFR 438.210 applies the same appeal and grievance requirements for PIHPs and PAHPs as for MCOs; for this proposal, we rely on our authority in section 1902(a)(4) of the Act to adopt these standards for PIHPs and PAHPs. PO 00000 Frm 00073 Fmt 4701 Sfmt 4702 76309 This is consistent with our prior practice for adopting standards for Medicaid managed care plans (81 FR 27507). Additionally, section 1902(a)(17) of the Act requires state Medicaid plans to include reasonable standards for determining the extent of medical assistance under the plan that are consistent with the objectives of title XIX of the Act. As set forth at 42 CFR 440.230, the standards states establish under section 1902(a)(17) of the Act could include appropriate limits on a service based on such criteria as medical necessity or on utilization control procedures, so long as each service is sufficient in amount, duration, and scope to reasonably achieve its purpose. Items and services covered under Title XIX benefit authorities are subject to 42 CFR 440.230, unless statute or regulation expressly provides for an exception or waiver. This would include covered items and services described in sections 1905(a), 1915(c), 1915(i), 1915(j), 1915(k), 1915(l), 1937, and 1945 of the Act, and any other authorities as established by Congress. The standards that states establish under section 1902(a)(17) of the Act and 42 CFR 440.230 could include prior authorization requirements. Our proposals to establish timeframes for prior authorization decisions are authorized under section 1902(a)(17) of the Act, because they would be expected to help ensure that states make prior authorization decisions in a manner that is consistent with the requirements in section 1902(a)(4), (a)(8) and (a)(19) of the Act, thus helping to ensure that states’ standards for determining the extent of medical assistance under the plan are consistent with the objectives of title XIX. For Medicaid managed care plans, these proposals are also authorized by section 1932(b)(4) of the Act, which provides that each Medicaid managed care organization must establish an internal grievance procedure whereby a beneficiary who is eligible for medical assistance may challenge the denial of coverage or payment for such assistance. Reducing plan response time for prior authorization decisions could enable beneficiaries to file appeals if necessary, and receive resolution to those appeals sooner. The earlier an appeal is filed and the disposition known, the sooner the provider and beneficiary can determine whether to request a state fair hearing or to identify treatment alternatives, if necessary. The prior authorization proposals in this rule are also consistent with how section 1932(c)(2)(A)(i) of the Act requires MCO contracts to contain a provision for an E:\FR\FM\13DEP2.SGM 13DEP2 76310 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules lotter on DSK11XQN23PROD with PROPOSALS2 annual external quality review of quality outcomes, and access to and timeliness of covered services. Should this rule be finalized as proposed, and should the proposed shorter prior authorization response requirements improve workflow and processes that facilitate timely access to services, improvements to the care experience for patients, and better health outcomes, the results should be visible in external reviews. This proposed requirement reflects the importance and potential advantages of timely access for beneficiaries to covered services through more efficient processing of prior authorization requests as proposed in this rule. (4) Public Reporting of Prior Authorization Metrics We are also proposing to require Medicaid FFS programs and Medicaid managed care plans to publicly report certain prior authorization metrics by posting them directly on the payer’s website or via publicly accessible hyperlink(s). As discussed in section II.D.8. of this proposed rule, publicly reporting these metrics could support more timely access to services by identifying prior authorization process weaknesses or deficiencies and enabling the implementation of corrective action, and for managed care programs, helping beneficiaries select Medicaid managed care plans that best meet their needs, and helping some Medicaid providers make informed decisions on which Medicaid managed care plan networks to join. Section 1902(a)(4) of the Act authorizes this proposal because enabling more timely access to services by identifying prior authorization deficiencies and facilitating the implementation of corrective action to improve the prior authorization process would support the proper and efficient operation of the state Medicaid plan. Requiring Medicaid managed care plans to publicly report their prior authorization metrics would hold them accountable and enable them to monitor their own performance and identify process improvement opportunities, which could be an integral part of implementing a quality assessment and improvement strategy more easily. This is consistent with the requirements for quality strategies for managed care programs at section 1932(c)(1)(A)(i) of the Act. Section 1902(a)(8) of the Act authorizes this proposal because identifying prior authorization process weaknesses or deficiencies and enabling the implementation of corrective action as well as helping beneficiaries select a VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 Medicaid managed care plan that best meets their needs may improve the promptness with which services are provided to beneficiaries. Section 1902(a)(19) of the Act authorizes this proposal because identifying prior authorization process weaknesses or deficiencies and enabling the implementation of corrective action would help ensure that care and services are provided in a manner consistent with simplicity of administration. Additionally, implementation of corrective action to improve prior authorization processes, helping beneficiaries select a managed care plan that best meets their needs, and helping providers make informed decisions on which Medicaid managed care plan networks to join is in the best interest of beneficiaries. c. CHIP For CHIP, we propose these requirements under the authority of section 2101(a) of the Act, which sets forth that the purpose of title XXI is to provide funds to states to provide child health assistance to uninsured, lowincome children in an effective and efficient manner that is coordinated with other sources of health benefits coverage. This provision authorizes us to adopt these requirements for CHIP to obtain access to program data for analysis. Such analysis supports improvements in the efficacy of CHIP programs and more efficient administration of services. As discussed previously, we propose to require implementation of the PARDD API in section II.D.3.a. of this proposed rule to improve the prior authorization process for patients, providers, and payers by addressing deficiencies and inefficiencies that exist in the current process. Today, a payer’s rules about when a prior authorization is required, and what documentation requirements must be fulfilled to submit the request, are not necessarily easily accessible for providers. The process may require manual activities including phone calls, use of portals, multiple websites, and paper manuals. These inefficient procedures take time away from actual patient care. The PARDD API would enable a provider to determine if a prior authorization was required electronically, in real time, and what the documentation requirements would be regarding such request. While we expect providers would be the primary stakeholders to benefit from this proposed API, making this information available in a standardized way and permitting access through an API would also serve the requirements in section 2101(a) of the Act that CHIP PO 00000 Frm 00074 Fmt 4701 Sfmt 4702 ensure access to coverage and coordinated care. The proposed PARDD API would be a mechanism for receiving and responding to requests for coverage determinations before the services were furnished; the PARDD API would streamline the initial authorization process for the payer, by sharing this information in an easily accessible way. This would also allow the provider to know what to do if a prior authorization is required for a certain service, which would improve the provider’s ability to treat the patient timely. The proposed PARDD API would enable the payer to send a real time response back to a provider, based on the request for authorization. This, too, would improve the efficiency of providing services to the patient, because the request and response would be automated, and in real time. Payer use of these APIs could ensure that a provider is able to submit a request for a prior authorization with the correct and complete documentation to avoid an incorrect submission which might result in an unnecessary denial. The PARDD API would: (i) enable providers to submit a prior authorization request faster and easier, (ii) support more timely notice to provider and beneficiary of the disposition of the prior authorization request, and (iii) permit faster scheduling of services or filing appeals, depending on the decision. The PARDD API has the potential to improve the prior authorization process by making it more efficient, including limiting the number of denials and appeals, or even eliminating requests for additional documentation, as noted elsewhere. The safeguards for beneficiary information at subpart F of 42 CFR part 431 are also applicable to CHIP through a cross-reference at 42 CFR 457.1110(b). As discussed above for Medicaid, CHIP payers’ and providers’ data exchange through the PARDD API would be related to providing services to beneficiaries, which is described at 42 CFR 431.302(c) as a purpose directly related to state plan administration. We remind states that when they share medical records or any other health or enrollment information pertaining to individual beneficiaries, they must comply with the privacy protections at 42 CFR 457.1110 and the release of information provisions at 42 CFR 431.306. The proposed requirement in section II.D.5.b. of this proposed rule that CHIP FFS and managed care entities meet certain timeframes to provide decisions for prior authorizations, for expedited and standard decisions would be an improvement from the current state, E:\FR\FM\13DEP2.SGM 13DEP2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules lotter on DSK11XQN23PROD with PROPOSALS2 where there is uncertainty about expectations for when a prior authorization might be approved. The proposal is intended to establish more certainty in the prior authorization process for providers and improve access to appropriate care for all patients, particularly those with chronic conditions or complicated health risks. Health parity could be increased as barriers due to process and timeframes would be removed. Similarly, improved process improvements could reduce administrative costs for providers and payers as redundancies would be removed from the system. The proposal to improve timeliness in responding to providers and patients could support process improvements for the state and managed care programs and is consistent with our authorities under section 2101(a) of the Act in that they improve the efficiency of the CHIP programs. Our proposal to require CHIP FFS and CHIP managed care entities to publicly report prior authorization metrics would also support the states’ oversight, evaluation, and administration responsibilities. Should the reporting provisions be finalized as proposed, CMS may occasionally view some of the CHIP’s FFS and CHIP websites to check for compliance, see how data is being reported, and determine if there are any trends in prior authorization changes that could be indicative of the benefits of the proposals for prior authorization policies as discussed in section II.D.8. of this proposed rule. The data may indicate use of the APIs, improvements in prior authorization numbers, or changes in total numbers, denials, and appeals. d. QHP Issuers on the FFEs For QHP issuers on the FFEs, we are proposing these new requirements pursuant to the authority of section 1311(e)(1)(B) of the Affordable Care Act, which affords the Exchanges the discretion to certify QHPs if the Exchange determines that making available such health plans through the Exchange is in the interests of qualified individuals in the state in which the Exchange operates. The policies included here could improve the efficiency of the issuers who are certified to offer QHPs on the FFEs and improve the quality of services they provide to providers and their patients. Qualified individuals in FFEs may receive covered services more quickly, and the information may be more accurate with the use of the APIs. These proposals could improve the quality of the patient experience with their providers by increasing the VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 efficiency in the prior authorization submission and review process. Certifying only health plans that implement FHIR APIs and adhere to the other proposals herein would be in the interests of qualified individuals in the state or states in which an FFE operates. We encourage State-based Exchanges (SBEs) to consider whether a similar requirement should be applicable to QHP issuers participating in their Exchanges. In section II.D.3.a. of this proposed rule, we propose that QHPs issuers on the FFEs implement an API to support the prior authorization process. The PARDD API would allow QHP issuers to communicate requirements for prior authorization more efficiently, and enable providers to similarly operate more efficiently to determine when a prior authorization is needed and locate the documentation requirements. The API could enable more accurate submission and subsequent processing of prior authorization requests, with the potential of improving delivery of services to patients. Similar to the other API proposals, certifying only health plans that implement FHIR APIs would be in the interests of qualified individuals in the state or states in which an FFE operates because of the opportunities for improvements in patient care, in alignment with the goals of the Affordable Care Act. We are also proposing that QHP issuers on the FFEs provide a reason for denial when sending a response to a prior authorization request, to facilitate better communication and understanding between the provider and issuer. This could enable efficient resubmission of the prior authorization request with additional information or an appeal, which could more promptly facilitate the needed patient care. Finally, the proposal to require QHP issuers on the FFEs to publicly report prior authorization metrics in section II.D.8. of this proposed rule would hold issuers accountable to their providers and patients, which could help these organizations improve their program administration. These data could help QHP issuers evaluate their processes and determine if there are better ways to leverage the APIs, including the quality and sufficiency of the coverage and documentation information included in the APIs. PO 00000 76311 E. Electronic Prior Authorization for the Merit-Based Incentive Payment System (MIPS) Promoting Interoperability Performance Category and the Medicare Promoting Interoperability Program 1. Background In the December 2020 CMS Interoperability proposed rule (85 FR 82639), we requested comment on ways in which CMS can incentivize the use of electronic prior authorization solutions by healthcare providers. We sought comment on whether the Quality Payment Program (QPP) Merit-based Incentive Payment System (MIPS) for MIPS eligible clinicians or the Conditions of Participation/Conditions for Coverage requirements for eligible hospitals and other providers would be the appropriate mechanism for new or additional policies that would promote the use of prior authorization APIs. Commenters expressed support for incentivizing healthcare providers to use these processes and tools to improve prior authorization processes. They noted that provider participation and health information technology are critical to promoting the widespread adoption of electronic prior authorization solutions. CMS considered both approaches outlined in that RFI (85 FR 82639) aimed at adopting and using electronic prior authorization processes. We believe that requiring healthcare providers, including clinicians and hospitals, to use these API functions for prior authorization is critical to ensuring the success and widespread adoption of this technology. As discussed in section II.D. of this proposed rule, the current prior authorization process needs improvement to reduce the burden associated with the process itself. According to a 2020 American Medical Association (AMA) survey, 94 percent of respondents experienced patient care delays associated with processing prior authorizations, and 79 percent indicated having at least one experience of abandoned patient care due to onerous prior authorization processes.109 This same survey indicated increased provider and staff burnout and expense associated with current prior authorization processes. Specifically, the data suggest that 40 percent of physician practices have staff who work exclusively on prior authorizations, and, on average, physicians and staff spend approximately two business days (16 109 American Medical Association (2021). 2020 AMA Prior Authorization (PA) Physician Survey. Retrieved from https://www.ama-assn.org/system/ files/2021-04/prior-authorization-survey.pdf. Frm 00075 Fmt 4701 Sfmt 4702 E:\FR\FM\13DEP2.SGM 13DEP2 76312 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules hours) each week on prior authorizations.110 A 2019 study by the Altarum Institute corroborates the AMA’s findings that current prior authorization processes are increasingly burdensome and may lead to poorer patient health outcomes.111 As mandated by section 4001 of the 21st Century Cures Act (Pub. L. 114– 255), ONC published the Strategy on Reducing Regulatory and Administrative Burden Relating to the Use of Health IT and EHRs in February 2020.112 This report recommended multiple strategies for reducing burden through the use of health IT tools, including to ‘‘[l]everage health IT to standardize data and processes around ordering services and related prior authorization processes.’’ 113 Further, the Health Information Technology Advisory Committee’s (HITAC) Intersection of Clinical and Administrative Data (ICAD) Task Force has recommended standards be established for prior authorization workflows, extension and renewal mechanisms for prior authorizations be created, and patients be included in the prior authorization process.114 As described in section II.D. of this proposed rule, stakeholders who participated in listening sessions conducted by CMS, including payers, providers, patients, and other industry representatives, noted that there are aspects of prior authorization processes that may be improved. For example, the information required by payers to evaluate or review a prior authorization can be inconsistent between payers, so it can be difficult for providers to determine the rules and required documentation. Further, submitting a prior authorization request relies on multiple cumbersome submission channels, including payer-specific web- lotter on DSK11XQN23PROD with PROPOSALS2 110 Id. 111 Turner, A., Miller, G., & Clark, S. (Nov. 2019). Impacts of Prior Authorization on Health Care Costs and Quality: A Review of Evidence. Retrieved from https://www.nihcr.org/wp-content/uploads/ Altarum-Prior-Authorization-Review-November2019.pdf. 112 Office of the National Coordinator (Feb. 2020). Strategy on Reducing Regulatory and Administrative Burden Relating to the Use of Health IT and EHRs. Retrieved from https:// www.healthit.gov/sites/default/files/page/2020-02/ BurdenReport_0.pdf. 113 Id. at 14. 114 Health Information Technology Advisory Committee, Office of the National Coordinator (Nov. 2020). A Path Toward Further Clinical and Administrative Data Integration. Final Report of the Health Information Technology Advisory Committee’s Intersection of Clinical and Administrative Data Task Force to the National Coordinator for Health Information Technology. Retrieved from https://www.healthit.gov/sites/ default/files/page/2020-11/2020-11-17_ICAD_TF_ FINAL_Report_HITAC.pdf. VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 based portals, telephone calls, and fax exchange technology. This process can be duplicative for providers who must re-submit prior authorization requests when patients change payers. To pursue these recommendations and facilitate needed improvements in the prior authorization process, in section II.D. of this proposed rule, we propose requiring impacted payers to implement and maintain a PARDD API. The PARDD API aims to improve care coordination and shared decisionmaking by enabling enhanced electronic documentation discovery and facilitating electronic prior authorization. This is discussed in more detail in section II.D. of this proposed rule. We believe the PARDD API would reduce administrative burden, improve efficiency, and ensure patients promptly receive necessary medical items and services. However, as noted in the December 2020 CMS Interoperability proposed rule (85 FR 82639), we recognize that efficiencies from payer implementation of these APIs will only be realized if they are utilized by requesting providers to complete prior authorization requests. Therefore, in this proposed rule, we propose a new measure for MIPS eligible clinicians under the Promoting Interoperability performance category of MIPS, as well as for eligible hospitals and CAHs under the Medicare Promoting Interoperability Program, related to electronic prior authorization. We intend for the new measure, titled ‘‘Electronic Prior Authorization,’’ to be included in the Health Information Exchange (HIE) objective for the MIPS Promoting Interoperability performance category and in the HIE objective for the Medicare Promoting Interoperability Program. This measure aims to address stakeholder concerns regarding possible low provider utilization of APIs established by payers for electronic prior authorization, as described in letters from commenters in response to the December 2020 CMS Interoperability proposed rule (85 FR 82586). MIPS is authorized under section 1848(q) of the Act. As described in sections 1848(q)(2) and (5) of the Act, we evaluate the performance of MIPS eligible clinicians in four performance categories, which we refer to as the quality, cost, improvement activities, and Promoting Interoperability performance categories. Under § 414.1375(b)(2), MIPS eligible clinicians must report on objectives and measures as specified by CMS for the Promoting Interoperability performance category. We refer readers to the Calendar Year (CY) 2023 Physician Fee PO 00000 Frm 00076 Fmt 4701 Sfmt 4702 Schedule (PFS) final rule (87 FR 70075 through 70080) for a list of the current objectives and measures for the Promoting Interoperability performance category. We determine a final score for each MIPS eligible clinician based on their performance in the MIPS performance categories and apply a payment adjustment (which can be positive, neutral, or negative) for the covered professional services they furnish based on their final score. The Medicare Promoting Interoperability Program for eligible hospitals and CAHs are authorized in part under sections 1886(b)(3)(B)(ix) and 1814(l)(4) of the Act. Under these statutory provisions, eligible hospitals and CAHs that do not successfully demonstrate meaningful use of CEHRT are subject to Medicare payment reductions. To demonstrate meaningful use of CEHRT, eligible hospitals and CAHs must satisfy objectives and measures as required under 42 CFR 495.24. We refer readers to the Fiscal Year (FY) 2023 Hospital Inpatient Prospective Payment System (IPPS) and Long-Term Care Hospital (LTCH) final rule (87 FR 49350) for a summary of the current objectives and measures for the Medicare Promoting Interoperability Program. 2. Electronic Prior Authorization To support the policies in this proposed rule and maximize the potential to improve the prior authorization process for providers and patients, we are proposing to add a new measure titled ‘‘Electronic Prior Authorization’’ in the HIE objective of the MIPS Promoting Interoperability performance category and in the HIE objective of the Medicare Promoting Interoperability Program. We believe this measure would further enable the electronic exchange of health information to improve the quality of healthcare, such as promoting care coordination, as described in section 1848(o)(2)(A)(ii) of the Act with respect to MIPS eligible clinicians and section 1886(n)(3)(A)(ii) of the Act with respect to eligible hospitals and CAHs. We are proposing to require MIPS eligible clinicians to report this measure beginning with the CY 2026 performance period/CY 2028 MIPS payment year and for eligible hospitals and CAHs to report this measure beginning with the CY 2026 EHR reporting period. However, we propose that the measure will not be scored in 2026. The proposals we are making in this section with regard to an Electronic Prior Authorization measure do not alter a covered entity’s requirement to use the E:\FR\FM\13DEP2.SGM 13DEP2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules lotter on DSK11XQN23PROD with PROPOSALS2 HIPAA transaction standards at 45 CFR 162.1302. We note that a healthcare provider may use an intermediary or clearinghouse to assemble a HIPAAcompliant X12 278 prior authorization transaction to transmit to the payer, as described in section II.D.3.a. of this proposed rule. In that section, we also note that in March 2021, HHS approved an application 115 from an industry group of payers, providers, and vendors for an exception under 45 CFR 162.940 from the HIPAA transaction standards. The approved exception allows testing of proposed modifications to HIPAA requirements—specifically for the prior authorization standard. Under this exception, the group would test a prior authorization exchange using the HL7 FHIR standard. In this proposal for the Electronic Prior Authorization measure, the healthcare provider would use data from their CEHRT (such as patient demographics and medical information) to justify the prior authorization request. The PARDD API would automate the compilation of necessary data for populating the HIPAA-compliant prior authorization request. Additional information not contained in CEHRT may also be required for submission. This information would then be packaged into a HIPAA-compliant transaction for transmission to the payer. We are proposing the following specifications for the Electronic Prior Authorization measure: a. For MIPS Eligible Clinicians Under the MIPS Promoting Interoperability Performance Category—Electronic Prior Authorization • Measure Description: For at least one medical item or service (excluding drugs) ordered by the MIPS eligible clinician during the performance period, the prior authorization is requested electronically from a PARDD API using data from CEHRT. The MIPS eligible clinician would be required to report a numerator and denominator for the measure or (if applicable) report an exclusion: • Denominator: The number of unique prior authorizations requested for medical items and services (excluding drugs) ordered by the MIPS eligible clinician during the performance period, excluding prior authorizations that cannot be requested using the PARDD API because the payer does not offer an API that meets the PARDD API requirements outlined in section II.D.3.a of this proposed rule. 115 Da Vinci Project. Da Vinci HIPAA Exception Confluence (2021). Retrieved from https:// confluence.hl7.org/display/DVP/Da+Vinci+ HIPAA+Exception. VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 • Numerator: The number of unique prior authorizations in the denominator that are requested electronically from a PARDD API using data from CEHRT. • Exclusion: Any MIPS eligible clinician who: (1) Does not order any medical items or services (excluding drugs) requiring prior authorization during the applicable performance period; or (2) Only orders medical items or services (excluding drugs) requiring prior authorization from a payer that does not offer an API that meets the PARDD API requirements outlined in section II.D.3.a of this proposed rule during the applicable performance period. b. For Eligible Hospitals and Critical Access Hospitals in the Medicare Promoting Interoperability Program— Electronic Prior Authorization • Measure Description: For at least one hospital discharge and medical item or service (excluding drugs) ordered during the EHR reporting period, the prior authorization is requested electronically from a PARDD API using data from CEHRT. The eligible hospital or CAH would be required to report a numerator and denominator for the measure or (if applicable) report an exclusion: • Denominator: The number of unique prior authorizations requested for medical items and services (excluding drugs) ordered for patients discharged from the eligible hospital or CAH inpatient or emergency department (place of service (POS) code 21 or 23) during the EHR reporting period, excluding prior authorizations that cannot be requested using the PARDD API because the payer does not offer an API that meets the PARDD API requirements outlined in section II.D.3.a of this proposed rule. • Numerator: The number of unique prior authorizations in the denominator that are requested electronically from a PARDD API using data from CEHRT. • Exclusions: Any eligible hospital or CAH that: (1) Does not order any medical items or services (excluding drugs) requiring prior authorization during the applicable EHR reporting period; or (2) Only orders medical items or services (excluding drugs) requiring prior authorization from a payer that does not offer an API that meets the PARDD API requirements outlined in section II.D.3.a of this proposed rule during the applicable EHR reporting period. We propose that beginning with the CY 2026 performance period/CY 2028 MIPS payment year for MIPS eligible PO 00000 Frm 00077 Fmt 4701 Sfmt 4702 76313 clinicians and the CY 2026 EHR reporting period for eligible hospitals and CAHs, a MIPS eligible clinician, eligible hospital, or CAH that fails to report the measure or claim an exclusion would not satisfy the MIPS Promoting Interoperability performance category or Medicare Promoting Interoperability Program reporting requirements. For the CY 2026 performance period/CY 2028 MIPS payment year for MIPS eligible clinicians and the CY 2026 EHR reporting period for eligible hospitals and CAHs, we are proposing that the Electronic Prior Authorization measure would not be scored and would not affect the total score for the MIPS Promoting Interoperability performance category or the Medicare Promoting Interoperability Program. In other words, for CY 2026, a MIPS eligible clinician, eligible hospital, or CAH would be required to report a numerator of at least one for the measure or claim an exclusion, but the measure would not be scored. If the MIPS eligible clinician, eligible hospital, or CAH does not report a numerator of at least one for the measure or claim an exclusion, they would receive a zero score for the MIPS Promoting Interoperability performance category or the Medicare Promoting Interoperability Program, respectively. We intend to propose a scoring methodology for the measure in future rulemaking. We are proposing that for purposes of this measure, a prior authorization request must be made using the PARDD API to satisfy the measure. The PARDD API functionality is outlined in further detail in section II.D.3.a of this proposed rule. Prior authorization requests that are made using fax, mail, or portal would be included in the denominator of the measure unless the prior authorization cannot be requested using the PARDD API because the payer does not offer an API that meets the PARDD API requirements, in which case it would be excluded from the denominator. Instances where a payer offering the PARDD API specifically requests a mailed or faxed prior authorization would be included in the denominator. Prior authorization requests that are made using fax, mail, or portal would not be included in the numerator of the measure because these methods would not incentivize the use of standards-based API functionality as intended by the measure. Prior authorizations for any and all drugs would be excluded from both the numerator and denominator of the measure. (For a more detailed E:\FR\FM\13DEP2.SGM 13DEP2 lotter on DSK11XQN23PROD with PROPOSALS2 76314 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules discussion of the exclusion of drugs, see section I.A. of this proposed rule.) We are proposing that only prior authorizations that are requested electronically from a PARDD API using data from CEHRT would be included in the numerator. Using the API to query documentation requirements alone and not to request the prior authorization would not count in the numerator or denominator. We propose that MIPS eligible clinicians, eligible hospitals, or CAHs that do not order any medical items or services (excluding drugs) requiring prior authorization during the applicable performance period or EHR reporting period could claim an exclusion for this measure. We are also proposing that MIPS eligible clinicians, eligible hospitals, or CAHs that only order medical items or services (excluding drugs) requiring prior authorization from a payer that does not offer an API that meets the PARDD API requirements outlined in section II.D.3.a of this proposed rule (that is, nonimpacted payers or impacted payers that are non-compliant with the PARDD API requirements outlined in section II.D.3.a of this proposed rule), during the applicable performance period or EHR reporting period, could claim an exclusion for this measure. As an alternative to this proposal, we considered whether MIPS eligible clinicians, eligible hospitals, and CAHs that request a small number of prior authorizations, such as five prior authorizations during the performance period/EHR reporting period, should also be able to claim the exclusion. Given the previously discussed limitations of the current prior authorization process, we believe that all healthcare providers (as well as their patients and the payers they request prior authorization from) would benefit from using the electronic process described here, regardless of how often they request prior authorization. Therefore, we believe that no minimum number of prior authorization requests, other than zero, would be a reasonable threshold for claiming an exclusion for this measure. However, we seek public comment on the alternative we considered and whether another minimum number of prior authorization requests would be appropriate for the exclusion. ONC recently sought comment through an RFI titled ‘‘Electronic Prior Authorization Standards, Implementation Specifications, and Certification Criteria’’ (87 FR 3475), which appeared in the January 24, 2022 issue of the Federal Register, on how updates to the ONC Health IT VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 Certification Program could support electronic prior authorization. ONC may use comments received from this RFI to inform future rulemaking in the ONC Health IT Certification Program related to electronic prior authorization. Updates to certification requirements for certified health IT introduced in future rulemaking could help MIPS eligible clinicians and eligible hospitals and CAHs to conduct the actions described in these proposed measures. We invite public comment on these proposals. Specifically, we seek comment on the following: • Should CMS consider alternatives to the proposed numerator and denominator of the measure? Are there changes to these specifications that would reduce the implementation burden for both providers and health IT developers? • What challenges will providers face in identifying those payers that have the PARDD API technology in order to accurately include eligible prior authorization requests in the denominator? • What challenges will providers face in performing the actions included in the measure specifications and successfully reporting the measure if certification criteria are not available in the ONC Health IT Certification Program at the time providers are required to report the measure under the Medicare Promoting Interoperability Program or MIPS Promoting Interoperability performance category? • With the understanding that ONC may consider policies in the ONC Health IT Certification Program that could further support this measure, are there alternate implementation timeframes that should be considered? F. Interoperability Standards for APIs 1. Modifications to Required Standards for APIs In the CMS Interoperability and Patient Access final rule (85 FR 25510), we finalized a requirement to implement, maintain, and use API technology conformant with 45 CFR 170.215, which includes API technical standards, including HL7® FHIR® Release 4.0.1 (at 45 CFR 170.215(a)(1)), the HL7 FHIR US Core Implementation Guide Standard for Trial Use (STU) 3.1.1 (at 45 CFR 170.215(a)(2)), the HL7 SMART Application Launch Framework IG Release 1.0.0 (at 45 CFR 170.215(a)(3)), the FHIR Bulk Data Access (Flat FHIR) version 1.0.0: STU 1 (at 45 CFR 170.215(a)(4)) and OpenID Connect Core 1.0 (at 45 CFR 170.215(b)) (85 FR 25521). When we finalized the requirement for conformance with the PO 00000 Frm 00078 Fmt 4701 Sfmt 4702 specifications in 45 CFR 170.215 in the CMS Interoperability and Patient Access final rule (85 FR 25521), we finalized the use of all standards at 45 CFR 170.215 in whole for each of the APIs finalized in that rule. However, we understand that the existing requirements 116 for payers to ‘‘use API technology conformant with 45 CFR 170.215’’ for all API implementations may introduce additional confusion for impacted payers seeking to understand compliance requirements because not all of the standards at 45 CFR 170.215 may be applicable for specific API use cases. For example, the Bulk FHIR implementation would not be applicable to the Patient Access API. We also understand that if we were to propose a similar requirement for the API requirements proposed in this rule, each standard in 45 CFR 170.215 might not be appropriate for each set of API requirements, given the unique factors associated with each API use case. Accordingly, to reduce complexity and provide clarity, we are proposing modifications to be more specific regarding the standards at 45 CFR 170.215 applicable to previously finalized API requirements. We are also proposing specific language regarding the standards at 45 CFR 170.215 applicable for each new set of API requirements proposed in this proposed rule. Specifically, instead of maintaining and extending the language in the existing requirements to use ‘‘API technology conformant with 45 CFR 170.215’’ in our new proposals, we are proposing language which specifies the use of each standard at 45 CFR 170.215 that would apply to a given set of API requirements at the CFR citations identified in Tables 8. We further summarize the standards applicable for each set of API requirements in Table 10. We note that the exact regulation text would vary depending on which standards apply to that API. We believe this language will clarify that payers would only be required to use those specifications included at 45 CFR 170.215 that CMS has identified as necessary for each specific API, as discussed further in section II.F.3 of this proposed rule. Regarding the standard at § 170.215(a)(2), which is currently the HL7 FHIR® US Core Implementation Guide STU 3.1.1 (US Core IG), we 116 Access to and Exchange of Health Data and Plan Information, 42 CFR 422.119 (2020); Beneficiary Access to and Exchange of Data, 42 CFR 431.60 (2020); Beneficiary Access to Exchange of Data, 42 CFR 457.730 (2020); and Access to and Exchange of Health Data and Plan Information, 45 CFR 156.221 (2020). E:\FR\FM\13DEP2.SGM 13DEP2 lotter on DSK11XQN23PROD with PROPOSALS2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules recognize that the information we have required or proposed to require to be made available for different API use cases may only align with a subset of profiles defined within the US Core IG. For example, in 42 CFR 422.120(b)(1), for MA plans, we require the Provider Directory API to include data concepts such as the MA plan’s network of contracted provider names, addresses, and phone numbers, whereas in § 422.119(b), we require the Patient Access API to include a broader set of information, such as all clinical data, including laboratory results. While we want to ensure that FHIR Resources are profiled according to the US Core IG where applicable to support interoperability across implementations, we also want to ensure that payers do not engage in unnecessary development. We are therefore proposing that a payer is only required to use technology conformant with the US Core IG at § 170.215(a)(2) where applicable, that is, where there is a corresponding FHIR Resource in their functional API, pursuant to the data requirements for the API. If the FHIR Resource has been profiled by the US Core IG at 45 CFR 170.215(a)(2), then the payer must support the FHIR Resource according to the FHIR Resource Profile’s ‘‘StructureDefinition’’ as specified in the standard in the US Core IG at 45 CFR 170.215(a)(2). For example, if a ‘‘Patient’’ FHIR Resource is used in a payer’s Patient Access API, the ‘‘Patient’’ FHIR Resource must conform with the ‘‘US Core Patient Profile,’’ including all the ‘‘mandatory’’ and ‘‘must support’’ requirements as specified in the US Core IG. We also recognize that several of the IGs recommended for use in this section of this proposed rule build on specific profiles within the US Core IG. For example, the HL7 FHIR Da Vinci Payer Data Exchange (PDex) Implementation Guide: Version STU 1.0.0. Furthermore, we recognize that the recommended IGs and subsequent versions of these IGs may use profiles in updated versions of the US Core IG. We note that payers could use updated versions of the recommended IGs that rely on newer versions of the US Core IG, as long as those updated versions meet the requirements of our policy for the use of updated standards which is described below and aligns with the procedures established by ONC under the Standards Version Advance Process (SVAP). a. Use of Updated Standards In the CMS Interoperability and Patient Access final rule (85 FR 25510), we explained that while we must codify a specific version of each standard, the VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 need for continually evolving standards development has historically outpaced our ability to amend regulations. In that final rule, we established that payers implementing a Patient Access or Provider Directory API could use an updated version of a standard subject to certain conditions. Specifically, we established that an updated version of a standard could be used if the updated version of the standard is required by other applicable law, or not prohibited under other applicable law, provided that: for content and vocabulary standards other than those at 45 CFR 170.213, the Secretary has not prohibited use of the updated version of a standard for purposes of the section in which the provision is located, or 45 CFR part 170; and for standards at 45 CFR 170.213 and 170.215, the National Coordinator has approved the updated version for use in the ONC Health IT Certification Program (85 FR 25522). Finally, we established that an updated version of the standard could be used if the updated version does not disrupt an end user’s ability to use a required API to access the data required for that API (85 FR 25532). We are now proposing to extend this same policy to allow the use of an updated version of a standard to the Provider Access API, Payer-to-Payer API, and PARDD API. Under this proposal, impacted payers could upgrade to newer versions of the required standards, subject only to those limiting conditions, as previously noted, at any pace they wish. However, we reiterate that when using updated standards, a payer must continue to support connectivity for end users and may only use an updated version of the standard instead of the standard specified in the applicable regulation, if it does not disrupt an end user’s ability to access the data available through the API. We are proposing to allow the use of updated standards, specifications, or Implementation Guides for each of the API requirements at the CFR sections identified in Table 9. We note that any existing or proposed cross-references apply current requirements to the newly proposed APIs. Regarding the use of updated versions of standards at 45 CFR 170.213 and 170.215, we propose that these standards may be used if the National Coordinator has approved the updated version for use in the ONC Health IT Certification Program. We note that the National Coordinator approves the use of updated versions of standards in the Certification Program under SVAP pursuant to 45 CFR 170.555, which was finalized in the ONC 21st Century Cures Act final rule as a Maintenance of PO 00000 Frm 00079 Fmt 4701 Sfmt 4702 76315 Certification flexibility included in the real-world testing Condition of Certification (85 FR 25775). This flexibility permits health IT developers to voluntarily use, in certain certified Health IT Modules, newer versions of adopted standards so long as specific conditions are met, providing a predictable and timely approach within the Certification Program to keep pace with the industry’s standards development efforts. Under the SVAP, after a standard has been adopted through notice and comment rulemaking, ONC engages in an open and transparent process to timely ascertain whether a more recent version of an adopted standard or implementation specification should be approved by the National Coordinator for developers’ voluntary use under the Certification Program. ONC lists updated versions of standards that the National Coordinator has approved on its website.117 In addition, as part of the Interoperability Standards Advisory, ONC publishes updated versions of standards under consideration for the SVAP process.118 Members of the public can use this resource to review standards that may be approved under the SVAP process in the future, as well as provide input on which updated versions should be approved. We encourage impacted payers to review these resources to better understand the flexibility that may be available to utilize updated versions of the standards in §§ 170.215 and 170.213, provided these standards have been approved by the National Coordinator through the SVAP process and meet the other specified conditions for using updated standards to support compliance with the technical requirements for payer APIs. CMS emphasizes that if impacted payers choose to use updated standards, whether approved through the SVAP process or not, there should not be a disruption to an end user’s ability to access the data. We note that several updated versions of the standards currently at §§ 170.213 and 170.215 have been approved by the National Coordinator under the SVAP process,119 including the USCDI (Version 2), HL7 FHIR® US Core 117 Standards Version Advancement Process (SVAP), (2022, August 24). HealthIT.gov. Retrieved from https://www.healthit.gov/topic/standardsversion-advancement-process-svap. 118 Standards Version Advancement Process, (n.d.). HealthIT.gov. Retrieved from https:// www.healthit.gov/isa/standards-versionadvancement-process. 119 Standards Version Advancement Process (SVAP), (2022, August 24). HealthIT.gov. Retrieved from https://www.healthit.gov/topic/standardsversion-advancement-process-svap. E:\FR\FM\13DEP2.SGM 13DEP2 76316 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules lotter on DSK11XQN23PROD with PROPOSALS2 Implementation Guide (Version 4.0.0 and Version 5.0.1), the HL7 FHIR® SMART Application Launch Framework Implementation Guide (Release 2.0.0), and the HL7 FHIR® Bulk Data Access (Flat FHIR®) (v2.0.0: STU 2). As soon as the National Coordinator approves updated versions through the SVAP process; CMS considers the updated versions to have met this condition for use under our payer API requirements. Impacted payers may use these versions as long as the other conditions finalized in our regulations for the use of updated versions of the standard, implementation guide, or specification have also been met. 2. Recommended Standards To Support APIs In the CMS Interoperability and Patient Access final rule (85 FR 25529), we noted certain IGs that are publicly available for use and provide implementation information that payers can use to meet the regulatory requirements for APIs finalized in the rule to support interoperability and avoid having to develop an approach independently, saving time and resources. Reference implementations, which are use case-specific test implementations with test data, have been developed for these IGs and allow payers to see the APIs in production and support testing and development. We explained that using the additional recommended IGs could limit payer burden and support consistent, interoperable API development and implementation. We referred payers to information about recommended IGs and related reference implementations (85 FR 25533). In this proposed rule, we are also recommending specific implementation guides, including implementation guides relevant to the new API requirements proposed in this rule, that may be used in addition to the standards we are proposing to require at 45 CFR 170.215. In the December 2020 CMS Interoperability proposed rule, we proposed to require the use of FHIR IGs, including the CARIN IG for Blue Button®, HL7® FHIR® Da Vinci PDex IG, HL7® FHIR® Da Vinci PDex U.S. Drug Formulary IG, HL7® FHIR® Da Vinci PDex Plan Net IG, Da Vinci Coverage Requirements Discovery (CRD) IG, Documentation Templates and Rules (DTR) IG, and Prior Authorization Support (PAS) IG (85 FR 82586) to support the APIs requirements in the proposed rule. As discussed in section I.A. of this proposed rule, the December 2020 CMS Interoperability proposed rule will not be finalized, and we are withdrawing the proposals included in VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 that rule. We also note that these FHIR IGs continue to undergo further refinement and development as part of the HL7 ballot and standard advancement process that are expected to better support the Patient Access, Provider Access, Payer-to-Payer, and PARDD APIs. Additionally, some aspects of the HL7® FHIR® DaVinci PAS IG, notably the FHIR to X12 transactions and use of FHIR subscriptions, continue to be developed. In the case of the HL7® FHIR® DaVinci PDex US Drug Formulary IG, which was proposed to support API requirements finalized in the CMS Interoperability and Patient Access final rule, nuances involving how the data are used in different ways by payers need to be resolved, such as different co-pay and co-insurance options and subtleties when searching by brand name, ingredients, and drug name. Industry stakeholders continue to pursue production implementations to identify refinements and reconcile inconsistencies in these IGs to address targeted use cases more effectively. After careful ongoing consideration of the IGs, as previously listed, that were proposed previously in the December 2020 CMS Interoperability proposed rule, their development cycles, and our role in advancing interoperability and supporting innovation, we believe that while these IGs will continue to play a critical role in supporting our policy, we are not ready to propose them as a requirement of our interoperability initiatives. We believe these IGs will continue to be refined over time as stakeholders have the opportunity to test and implement them, and as such, we are recommending them for use but are not proposing to require them. Specifically, we will continue to monitor and evaluate the development of the IGs and consider whether to propose them as a requirement at some future date. At this time, we are recommending the use of the CARIN IG for Blue Button®, HL7® FHIR® Da Vinci PDex IG, HL7® FHIR® Da Vinci PDex U.S. Drug Formulary IG, HL7® FHIR® Da Vinci PDex Plan Net IG, and Da Vinci CRD IG, DTR IG, PAS IGs for the Patient Access, Provider Access, Provider Directory, Payer-to-Payer, and PARDD APIs. We acknowledge that by not requiring the use of all of the available FHIR IGs, there is potential for implementation variation in these APIs that could limit interoperability and ultimately lead to re-work for implementers if requirements are introduced later. However, at this time, we believe it is more important not to require these IGs while they are still undergoing PO 00000 Frm 00080 Fmt 4701 Sfmt 4702 additional enhancements. We are recommending, but not requiring, certain IGs that were previously proposed because we want to ensure that implementers use subsequent versions of these IGs without restriction to the version available when we issue a regulation. As discussed in section II.F.1, we previously finalized a policy to allow flexibility for the use of updated versions of certain standards required for the API requirements finalized in the Patient Access and Interoperability final rule, which we have proposed to extend to the API requirements proposed in this rule. However, we understand that the subsequent versions of the recommended IGs may include substantial changes that would not be consistent with the requirement included in our flexibility provisions that the use of an updated standard must not impair access to data through the API. Therefore, we believe that if we proposed to require the recommended IGs at this time, impacted payers would not be able to use an updated version of these IGs unless we were to require the updated versions through additional rulemaking. We intend to monitor IG development and may propose to require specific IGs at some future date when there are versions available for adoption that are mature and more likely to allow for voluntary updates under our flexibility policies. We seek comment on whether CMS should propose to require the use of these IGs for previously finalized and proposed APIs in future rulemaking and other ways that we could support innovation and interoperability. In addition, we seek comment on the process CMS should use to adopt or allow new versions of standards and implementation specifications over time, as previously discussed. CMS supports innovation and continued efforts to refine standards in a way that will leverage the most recent technological advancements. In making these recommendations, we note that these IGs are publicly available at no cost to a user. All HL7® FHIR® IGs are developed through an industry-led, consensus-based public process. HL7® is an American National Standards Institute (ANSI)-accredited standards development organization. HL7 FHIR standards allow disparate systems with different data architectures to exchange information in a standardized way via standards-based APIs. HL7 FHIR IGs are also openly available, so that any interested party can access a HL7 FHIR IG on the HL7 website. All public comments made during the HL7 balloting process and the IG version E:\FR\FM\13DEP2.SGM 13DEP2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules history, are available for review. This way, all stakeholders can fully understand the lifecycle of a given IG. Using IGs developed through such a public process facilitates a transparent and cost-effective path to interoperability that ensures the IGs are informed and approved by industry participants looking to use technology to improve patient care. A few of the recommended FHIR IGs have been developed by HL7 FHIR Accelerator programs,120 which bring together individuals across the industry to create and adopt IGs that are aligned with HL7, allowing new and revised requirements to have the potential to become open industry standards. Under HL7 FHIR Accelerators, industry stakeholders have facilitated the definition, design, and creation of useFHIR AcceleratorTM Program (n.d.). HL7 International. Retrieved from https://www.hl7.org/ about/fhir-accelerator/index.cfm. lotter on DSK11XQN23PROD with PROPOSALS2 120 HL7 VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 case-specific reference implementations based on the HL7 FHIR platform to address value-based care initiatives. Some HL7 FHIR Accelerators, such as Da Vinci and CARIN, have created IGs that we recommend be used to meet the previously finalized and proposed requirements for the Patient Access, Provider Directory, Provider Access, and Payer to Payer APIs. The Da Vinci project was established in 2018 to help payers and providers positively impact clinical, quality, cost, and care management outcomes.121 The CARIN Alliance works collaboratively with Government stakeholders to overcome barriers to advancing consumer-directed exchange across the U.S.122 While we are recommending the IGs proposed previously in the December 121 Da Vinci Project (n.d.). HL7 International. Retrieved from https://www.hl7.org/about/davinci/. 122 CARIN Alliance (n.d.). HL7 International. Retrieved from https://www.hl7.org/carin/. PO 00000 Frm 00081 Fmt 4701 Sfmt 4702 76317 2020 CMS Interoperability proposed rule as discussed, we welcome further information about the maturity of these IGs, including considerations about further development that would be needed prior to CMS requiring the use of specific IGs. 3. Proposed Standards To Support APIs Using IGs supports consistent implementations across the industry. Therefore, we are proposing at the CFR citations identified in Table 8 to require that impacted payers use API technology conformant with the standards at 45 CFR 170.215 that we propose as applicable for each set of API requirements. We include Table 10 to provide a clear outline of which standards we are proposing to require and which IGs we recommend for each proposed API. BILLING CODE 4120–01–P E:\FR\FM\13DEP2.SGM 13DEP2 lotter on DSK11XQN23PROD with PROPOSALS2 76318 VerDate Sep<11>2014 Jkt 259001 se~tici11 :J( :• II.F.1. I Patient Access PO 00000 API II.F.1. I Providcr AL:L:t:ss Frm 00082 API Fmt 4701 II.F.1. I Provider Directory API E:\FR\FM\13DEP2.SGM 13DEP2 Through existing cross reference to 42 CFR431.60(c) at42 CFR 431.70(a) Through existing cross reference to 42 CFR 431.70 at42 CFR 438.242(b X6) Through existing cross reference to 42 CFR 457.730(c) at42 CFR 457.760(a) Through existing cross reference to 42 CFR 438.242 at 42 CFR 457.1233(d) NIA Through proposed cross reference to 42 CFR431.60(c) at42 CFR 431.80(b) Through proposed cross reference to 42 CFR 431.80 at 42 CFR 438.242(b X7) Through proposed cross reference to 42 CFR 457.730(c) at42 CFR 457.732(b) Through existing cross reference to 42 CFR 438.242 at 42 CFR 457.1233(d) Through proposed cross reference to 45CFR 156.221(c)at45 CFR 156.223(b) Through proposed proposed cross cross reference to reference to 42 42 CFR431.60(c) CFR 422.119(c) at42 CFR at42 CFR 431.61(b Xl)(i) 422.121(b)(l )(i) Through proposed cross reference to 42 CFR 431.61(b )(1) at 42 CFR 438.242(b X7) Through proposed cross reference to 42 CFR 457.730(c) at42 CFR 457.73 l(b )(1 Xi) Through existing cross reference to 42 CFR 438.242 at 42 CFR 457.1233(d) Through proposed cross reference to 45CFR 156.221(c)at45 CFR 156.222(b)(1 )(i IThrough proposed cross reference to 42 CFR 422.119(c) at42 CFR 422.121(a)(l) I Through II.F.1. I PARDDAPI II.F.1. I Payer-to-Payer IThrough Sfmt 4725 EP13DE22.008</GPH> Through propost:d L:ross reference to 42 CFR 457.730(c) at 42 CFR 457.73 l(a)(l) Through existing cross reference to 42 CFR 438.242 at 42 CFR 457.1233( d) Through t:xisting L:ross reference to 42 CFR 438.242 at 42 CFR 457.1233(d) existing cross reference to 42 CFR 422.119(c) at42 CFR 422.120(a) I Through proposed cross reference to 42 CFR 422.119(c) at42 CFR 422.122(b) API I Through existing cross reference to 42 CFR 431.60 at 42 CFR 438.242(b Y5) Through propost:d L:ross reference to 42 CFR 431.61(a) at 42 CFR 438.242(b X7) 142 CFR 422.119(cX1) 142 CFR431.60(cXl) Through proposw cross reference to 42 CFR431.60(c) at42 CFR 431.61(a)(l) 42 CFR457.730(c)(l) 145 CFR 156.221(c)(l) Through propost:d cross reference to 45CFR 156.221(c)at45 CFR 156.222(aX1) Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules 18:56 Dec 12, 2022 TABLE 8: INTEROPERABILITY STANDARDS FOR APis PROPOSED POLICIES lotter on DSK11XQN23PROD with PROPOSALS2 VerDate Sep<11>2014 Jkt 259001 ,, Section II.F.l. Proposal Medicart > J Advuntime .. •· .M¢dt€ai~ FFS .. 42CFR 422.119(c)(4Xii) (C) 42 CFR431.60(c)(4X iiXC) II.F.l. Provider Access API lbrough proposed cross reference to 42 CFR431.60(c) at42 CFR 431.6l(a)(l) II.F.l. Provider Directory API II.F.l. PARDDAPI II.F.l. Payer-to-Payer API lbrough proposed cross reference to 42 CFR422.119(c) at42CFR 422.12l(aXl) lbrough existi11g cross reference to 42CFR 422.119(C) at 42 CFR 422.120( a) lbrough proposed cross reference to 42 CFR422.119(c) at42CFR 422.122(b) lbrough proposed cross reference to 42 CFR422.119(c) at42CFR 422.12lrbYl )(i) PO 00000 Patient Access API .· ~dicaid Man~etICare ·•. .. .· ·• CIDPFE:S 42 CFR457.730(c)(4XiiXC ) CHJPl\lana~Ca~; .•· •· Olll'sm1 FFEs . . 45CFR Frm 00083 Fmt 4701 Sfmt 4725 E:\FR\FM\13DEP2.SGM 13DEP2 lbrough existing cross reference to 42 CFR 431.60 at 42 CFR 438.242(b Y 5) lbrough proposed cross reference to 42 CFR 431.6l(a) at42 CFR 438.242(b X7) lbrough proposed cross reference to 42 CFR 457.730(c)at42 CFR 457.73l(a)(l) lbrough existing cross reference to 42 CFR 438.242 at 42 CFR 457.1233(d) lbrough existing cross reference to 42 CFR 438.242 at 42 CFR 457.1233(d) lbrough existi11g cross reference to 42 CFR431.60(c) at42 CFR 431.70(a) lbrough proposed cross reference to 42 CFR431.60(c) at42 CFR 431.80(b) lbrough existing cross reference to 42 CFR 431.70 at42 CFR 438.242(b X6) lbrough existing cross reference to 42 CFR 457.730(c)at42 CFR 457.760(a) Tirrough existing cross reference to 42 CFR 438.242 at 42 CFR 457.1233(d) NIA lbrough proposed cross reference to 42 CFR 431.80 at 42 CFR 438.242(b X7) lbrough proposed cross reference to 42 CFR 457.730(c)at42 CFR 457.732(b) lbrough existing cross reference to 42 CFR 438.242 at 42 CFR 457.1233(d) lbrough proposed cross reference to 45 CFR 156.22l(c)at45 CFR 156.223(b) lbrough proposed cross reference to 42 CFR431.60(c) at42 CFR 431.6l(b)(l)(i) lbrough proposed cross reference to 42 CFR 431.6l(b)(l) at42 CFR 438.242(b X7) lbrough proposed cross reference to 42 CFR 457.730(c)at42 CFR 457.73l(b )(1 Xi) lbrough existing cross reference to 42 CFR 438.242 at 42 CFR 457.1233(d) lbrough proposed cross reference to 45 CFR 156.22l(c)at45 CFR 156.222(bXI )(i) 156.221( c X4)(iiXC) lbrough proposed cross reference to 45 CFR 156.22l(c)at45 CFR 156.222(aXl) Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules 18:56 Dec 12, 2022 TABLE 9: USE OF UPDATED STANDARDS FORAPis PROPOSED POLICIES 76319 EP13DE22.009</GPH> 76320 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules TABLE 10: STANDARDS TO SUPPORT API IMPLEMENTATION API Patient Access API Proposed Required Standards 45 CFR 170.215(a)(l) HL 7 FHIR Release 4.0.1 Recommended Implementation Guides HL7 FHIR CARIN Consumer Directed Payer Data Exchange (CARIN IG for Blue Button®) implementation Guide: Version STU 1. 1.0. URL: httn://hl 7 .org/fh.ir/us/carin-bb/histor,y. html. 45 CFR l 70.215(a)(2) HL 7 FHIR US Core Implementation Guide STU 3.1.1 45 CFR l 70.215(a)(3) HL 7 SMART Application Launch Framework Implementation Guide Release 1.0.0, including mandatory support for the "SMART Core Capabilities" Provider Access API 45 CFR 170.215(b) OpenID Connect Core 1.0, incorporating err.ita set 1 45 CFR l 70.215(a)(l) HL 7 FHIR Release 4.0.1 45 CFR l 70.215(a)(2) HL 7 FHIR US Core Implementation Guide STU 3.1.1 45 CFR 170.215(a)(3) HL7 SMART Application Launch Framework Implementation Guide Release 1.0.0, including mandatory support for the "SMART Core Capabilities" HL7 FHIR Da Vinci Payer Data Exchange (PDex) Implementation Guide: Version STU 1.0.0. URL: http:/1h17 .org/fhir/us/davinci-pdex/history.html. HL7 FHIR Da Vinci - Payer Data Exchange (PDex) US Dmg Formulary Implementation Guide: Version STU 1.1.0. URL: httn://hl7.org/fuir/us/D:winci-drngfonnularv/historv.html. HL7 FHIR CARIN Consumer Directed Payer Data Exchange (CARIN lG for Blue Button®) Implementation Guide: Version STU 1. 1.0. URL: l!ttp://h17.org/fhir/us/carin-bb/history.html. HL7 FHIR Da Vinci Payer Data Exchange (PD ex) Implementation Guide: Version STU 1.0.0. URL: !1ttn://hl7.org/fllir/us/davinei-ndex/history.htrnl. 45 CFR 170 .2 l 5(a)(4) FHIR Bulk Data Access (Flat FHIR) (vl.0.0: STU 1), including mandatory support for the "group-export" "OperationDefinition" Provider Directory API 45 CFR 170.215(b) OpenID Connect Core 1.0, incorporating errata set 1 45 CFR 170.215(a)(l)HL7FHTR Release 4.0.1 45 CFR l 70.215(a)(2) HL 7 FHIR US Core Implementation Guide STU 3.1.1 HL7 FHTR Da Vinci Payer Data Exchange (PDex) Plan Net Implementation Guide: Version STU 1.1.0. URL: httQ;i/www.h17.or_gLfl1ir/us/davim.:iill!~lan-net/history.html. 45 CFR 170 .2 l 5(a)(3) HL 7 SMART Application Launch Framework Implementation Guide Release 1.0.0, including mandatory support for the "SMART Core Capabilities" lotter on DSK11XQN23PROD with PROPOSALS2 45 CFR 170.215(a)(2) HL7 FHTR US Core Implementation Guide STU 3.1.1 45 CFR 170.215(a)(3) HL 7 SMART Application Launch Framework Implementation Guide Release 1.0.0, VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 PO 00000 Frm 00084 Fmt 4701 HL7 FHIR Da Vinci - Coverage Requirements Discovery Implementation Guide: Version STU 1.0.0. URL: htm://hl7.org/fliir/us/dmincicrd/history. htm I. HL7 FHIR Da Vinci - Documentation Templates and Rules Implementation Guide: Version STU urn. URL: httg://hl7.org/fllir/us/davincirltr/hi~tOff him! Sfmt 4725 E:\FR\FM\13DEP2.SGM 13DEP2 EP13DE22.010</GPH> PARDD API 45 CFR 170.215(b) OpenTD Connect Core 1.0, incorporating errata set 1 45 CFR l 70.215(a)(l) HL 7 FHIR Release 4.0.1 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules including mandatory support for the "SMART Core Capabilities" 45 CFR 170.215(b) OpenID Connect Core 1.0, incorporating errata set 1 Payer-toPayer API 45 CFR l 70.215(a)(l) HL 7 FHIR Release 4.0.1 76321 HL 7 FHIR Da Vinci Prior Authorization Support (PAS) Implementation Guide: Version STU 1.1.0. URL: https://W7.org/fhir/us/dayincipas/historv .html. HL 7 FHIR Consumer Directed Payer Data Exchange (CARIN 1G for Blue Button®) Implementation Guide: Version STU 1. 1.0. URL: htto://hi 7.org/fbir/us/carin-bb/historv .html. 45 CFR 170.215(a)(2) HL7 FHIR US Core Implementation Guide STU 3.1.1 45 CFR 170.215(a)(3)HL7 SMART Application Launch Framework Implementation Guide Release 1.0.0, including mandatory support for the "SMART Core Capabilities" 45 CFR 170.215(a)(4)FHIRBulkDataAccess (Flat FHIR) (vl.0.0: STU 1), including mandatory support for the "group-export" "OperationDefinition" HL 7 FHIR Da Vinci - Payer Coverage Decision Exchange (PCDE) Implementation Guide: Version STU 1.0.0. URL: httg:/Av,v,v .hl 7. org/fuir/us/dayincipcde/hist01y .html. HL 7 FHIR Da Vinci Payer Data Exchange (PDex) Implementation Guide: Version STU 1.0.0. URL: htq_r//hl 7 .o rg/fhir/us/davinci-gdex/historv. html. 45 CFR 170.215(b) OpenID Connect Core 1.0, incorporating errata set 1 III. Requests for Information lotter on DSK11XQN23PROD with PROPOSALS2 A. Request for Information: Accelerating the Adoption of Standards Related to Social Risk Factor Data The December 2020 CMS Interoperability proposed rule (85 FR 82586) included several requests for information, including one regarding standards for social risk factor data. We received several comments requesting additional time to comment on this issue, and thus we are reissuing the request for information, with modification to add additional questions in this section. Social determinants of health (SDOH) as defined by Healthy People 2030 are ‘‘the conditions in the environments where people are born, live, learn, work, play, worship, and age that affect a wide range of health, functioning, and quality-of-life outcomes and risks.’’ 123 Social risk factors are those that can lead to unmet social needs that directly influence an individual’s physical, psychosocial, and functional status.124 These can include homelessness, food 123 U.S. Department of Health and Human Services Office of Disease Prevention and Health Promotion. Healthy People 2030. Retrieved from https://health.gov/healthypeople. 124 87 FR 27704 (May 9, 2022). Retrieved https:// www.federalregister.gov/documents/2022/05/09/ 2022-09375/medicare-program-contract-year-2023policy-and-technical-changes-to-the-medicareadvantage-and. VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 insecurity, lack of access to transportation, and low levels of health literacy.125 When these are immediate and pressing needs, these social risk factors may be called unmet social needs, or health-related social needs. Understanding social risk factors and individuals’ immediate unmet needs can help healthcare systems, plans, providers, and other partners target interventions to address these specific factors. CMS recognizes that social risk factors impact patient health, utilization, and outcomes, and that these factors can have a direct impact on our healthcare system as a whole. To the extent that healthcare providers and payers have access to data on social risk factors, they are best equipped to address these factors, and thus have a positive impact on patient health. Healthcare providers in value-based payment arrangements rely on comprehensive, high-quality data to identify opportunities to improve patient care and drive value. When implemented effectively, valuebased payment encourages healthcare providers to care for the whole person and address the social risk factors that are critical for patient quality of life. As value-based payment has grown, so has provider community interest in social risk factor data. 126 A recent 125 Ibid. 126 American Medical Association (Nov. 2020). AMA urges multifaceted approach to address social PO 00000 Frm 00085 Fmt 4701 Sfmt 4702 study 127 found that approximately 24 percent of hospitals and 16 percent of physician practices were screening patients for five health-related social needs (housing, food, transportation, utilities, and interpersonal safety needs). These findings suggest that healthcare providers can use these data to inform care and ensure patients get the services and support they need to address social risk factors and achieve better health outcomes. Unfortunately, social risk factor data are often fragmented, unstandardized, out of date, and duplicative. These circumstances are a result of a lack of clear standards for capturing, recording, and exchanging these data. While the International Classification of Diseases, Tenth Revision, Clinical Modification (ICD–10–CM) psychosocial risk and economic determinant-related codes (‘‘Z codes’’) can be used to capture standardized information on social determinants of health, utilization on Medicare claims remains relatively low for a number of reasons, including a determinants of health. Retrieved from https:// www.ama-assn.org/press-center/press-releases/ ama-urges-multifaceted-approach-address-socialdeterminants-health. 127 Fraze, T., Brewster, A., Lewis, V., Beidler, L., Murray, G., & Colla, C. (2019). Prevalence of screening for food insecurity, housing instability, utility needs, transportation needs, and interpersonal violence by US physician practices and hospitals. JAMA network open. Retrieved from https://pubmed.ncbi.nlm.nih.gov/31532515/. E:\FR\FM\13DEP2.SGM 13DEP2 EP13DE22.011</GPH> BILLING CODE 4120–01–C lotter on DSK11XQN23PROD with PROPOSALS2 76322 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules lack of financial incentives to record them and the limited number of available codes and sub-codes.128 If these data are not exchanged between healthcare providers caring for an individual, these providers who do not or cannot exchange these data with each other may ask the same patient similar questions, or hospitals within a single system may all collect data on the same health-related social needs in different formats. Additionally, relevant data collected without the use of standards to facilitate interoperability by community-based organizations outside the health sector can be difficult for other healthcare and social care providers to integrate and utilize. Siloed social risk factor data may increase the burden on patients, as well as healthcare providers and the healthcare system overall by creating inefficiencies in managing referrals for social services and duplicative and conflicting workflows in an already strained system. Non-interoperable information flows may impede opportunities to provide higher quality care and result in missed opportunities to address the root causes of poor health outcomes and health inequities. As healthcare providers assume greater accountability for costs and outcomes through value-based payment, they need tools to successfully identify and address social risk factors to improve care and health outcomes. Over the last several years, standards development organizations like the Gravity Project under HL7,129 have sought to develop industry-wide standards to collect social determinants of health (specifically, social risk factor data), electronically represent these data, and enable exchange of personcentered data between medical providers and community-based organizations through health information technology platforms. Since the introduction of the 2015 Edition of health IT certification criteria, the Office of the National Coordinator for Health Information Technology (ONC) Health IT Certification Program has certified technology that has enabled approximately half of all office-based clinicians and nearly a third of hospitals to possess technology certified to record, change, and access the data elements of overall financial resource strain, social connection and isolation, 128 Centers for Medicare & Medicaid Services Office of Minority Health (Sep. 2021). Utilization of Z Codes for Social Determinants of Health among Medicare Fee-for-Service Beneficiaries, 2019. Retrieved from https://www.cms.gov/files/ document/z-codes-data-highlight.pdf. 129 HL7 International. Gravity Project. Retrieved from https://www.hl7.org/gravity/. VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 highest level of education, and exposure to violence (intimate partner violence).130 In July 2021, ONC also published the United States Core Data for Interoperability version 2 131 (USCDI v2), which includes the new data elements of SDOH Assessment, SDOH Goals, SDOH Problems/Health Concerns, and SDOH Interventions.132 CMS seeks input on barriers the healthcare industry faces to using industry standards and opportunities to accelerate adoption of data collection standards related to social risk factor data, including exchange of information with community-based organizations. CMS specifically seeks input on these topics from stakeholders in minority and underserved communities as defined by section 2(b) of Executive Order 13985, Advancing Racial Equity and Support for Underserved Communities Through the Federal Government,133 and from the healthcare providers and plans, systems, and networks who serve these communities. Consistent with E.O. 13985, CMS is particularly interested in understanding the perspectives, barriers, and opportunities on these questions from a broad community of provider and healthcare interested parties, including those with whom CMS works with in underserved and minority communities who currently work to identify and meet needs related to social risks which could impact health and health service access, as previously described. We are also interested in receiving comments from individuals who have been referred to services to get support and their experiences with the benefits and burdens of data sharing, as well as their responses to the other questions included in this RFI. We are additionally interested in receiving comments from community-based organizations that work in the social 130 Morton, A., Taylor, A., Meklir, S., & Barker, W. (2019, December 12). Advancing interoperable social determinants of health data. Retrieved from https://www.healthit.gov/buzz-blog/ interoperability/advancing-interoperable-socialdeterminants-of-health-data. 131 HealthIT.gov. United States Core Data for Interoperability (USCDI). Retrieved from https:// www.healthit.gov/isa/united-states-core-datainteroperability-uscdi. 132 Office of the National Coordinator for Health Information Technology (2021, July). United States Core Data for Interoperability Version 2. Retrieved from https://www.healthit.gov/isa/sites/isa/files/ 2021-07/USCDI-Version-2-July-2021-Final.pdf. 133 The White House (2021, January 25). Executive Order 13985 of January 20, 2021 Advancing Racial Equity and Support for Underserved Communities Through the Federal Government. 86 FR 7009 (January 25, 2021). Retrieved from https://www.federalregister.gov/ documents/2021/01/25/2021-01753/advancingracial-equity-and-support-for-underservedcommunities-through-the-federal-government. PO 00000 Frm 00086 Fmt 4701 Sfmt 4702 service field. This feedback from diverse populations, including minority and underserved communities and neighborhoods, and individuals with lived experience related to social risk factor screening and referrals can help ensure that solutions are personcentered, and that CMS and other Federal policy makers understand the needs and challenges from those individuals we seek to serve. Information of interest to CMS includes: • What are best practices regarding frequency of collection of social risk and social needs data? What are factors to be considered around expiration, if any, of certain social needs data? • What are best practices regarding workforce training on collecting social risk and social needs data? How could CMS best support such training? • What are the challenges in representing and exchanging social risk and social needs data from different commonly used screening tools? How do these challenges vary across screening tools or social needs (for example, housing or food access)? • What are the barriers to the exchange of social risk and social needs data across healthcare providers? What are key challenges related to exchange of social risk and social needs data between healthcare providers and community-based organizations? If Federal or other regulations are perceived or actual barriers, please identify the specific regulation, policy, or guidance and clarifying language that would be necessary to resolve the cited barrier. If no specific language or policy is known, please provide a citation where more information is available related to this barrier. • What mechanisms (EHRs, Health Information Exchanges [HIEs], software, cloud-based data platforms, etc.) and/or standards are currently used to capture, exchange, and use social risk and social needs data? What challenges, if any, occur in translating, collecting, or transferring social risk factor data in these platforms to Z codes on claims? • How can payers promote exchange of social risk and social needs data? Are there promising practices used by MA organizations, state Medicaid agencies, Medicaid managed care plans, commercial health plans, or other payers that can potentially be further leveraged in other settings? • What specific strategies, tactics, or policies would help CMS and other Federal agencies facilitate greater standardization in the capture, recording, and exchange of social risk factor data? Are there best practices (related to contracting language, requirements in Federal programs, etc.) E:\FR\FM\13DEP2.SGM 13DEP2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules lotter on DSK11XQN23PROD with PROPOSALS2 that could be adopted, and by which agency? • What are the most promising efforts that exist to date in resolving the challenges previously cited in this proposed rule? Which gaps remain that are not being addressed by existing efforts? • What privacy issues should be considered when formulating policy for collecting and exchanging social risk and social needs data? Are there certain data elements that patients may wish to exercise more control over than others? • What are best practices that are currently addressing other challenges previously cited in this proposed rule, such as integration of social risk and social needs data into clinical workflow, adoption, and use of commonly used screening tools with associated health IT standards and value sets, and integration of social risk data and social needs data into the patient’s longitudinal health record? • Please identify potential existing, emerging, or possible new policy levers that CMS could use to better incentivize use and interoperability of social risk factor data. • Please identify opportunities and approaches that would help CMS facilitate and inform effective infrastructure investments to address gaps and challenges for advancing the interoperability of social risk factor data. We seek comments on these questions and issues for future consideration. B. Electronic Exchange of Behavioral Health Information The December 2020 CMS Interoperability proposed rule (85 FR 82586) included several requests for information, including a request for information regarding electronic data exchange among behavioral health providers (85 FR 82637). We received several comments requesting additional time to comment on this particular issue, and thus we are reissuing the request for information, with modification to add additional questions in this section of this proposed rule. Several factors have led behavioral health providers to adopt EHRs at a significantly lower rate than other types of healthcare providers. One possible contributing factor was that the Health Information Technology for Economic and Clinical Health Act (HITECH Act), enacted as part of the American Recovery and Reinvestment Act of 2009 (Pub. L. 111–5) on February 17, 2009, made Medicare FFS and Medicaid incentive payments for the adoption and meaningful use of CEHRT available only to eligible professionals, eligible VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 hospitals, and CAHs, so behavioral health providers that did not meet those criteria were ineligible for these incentive payments. For example, while behavioral health providers who were physicians (eligible professionals) could receive the incentive payments, other types of non-physician behavioral health providers may not have been eligible. Congress created another potential opportunity to address this issue when it enacted the Substance Use-Disorder Prevention that Promotes Opioid Recovery and Treatment for Patients and Communities Act (SUPPORT Act) (Pub. L. 115–271) on October 24, 2018. Section 6001 of the SUPPORT Act modifies an existing list of possible model opportunities the Center for Medicare & Medicaid Innovation may consider testing to include models to provide incentive payments to behavioral health providers for adopting EHRs. Today, behavioral health providers lag behind their peers in the ability to electronically share health information across providers and with patients. ONC noted that, in 2017, only 14 percent of office-based physicians reported sending data to behavioral health providers, while 12 percent of officebased physicians reported receiving data from behavioral health providers.134 Other regulatory restrictions, such as 42 CFR part 2, which governs the confidentiality of substance use disorder patient records maintained by certain entities, or more restrictive state laws,135 can also inhibit the exchange of behavioral health information. Understanding the time and cost of implementing an EHR system, we are interested in evaluating whether using other applications that exchange data using the FHIR APIs and do not require implementation of a full EHR system might be a way to help behavioral health providers leverage technology to exchange health data to improve care quality and coordination in a more agile fashion. Specifically, would small practices and community-based providers be able to more quickly adopt applications using API technology to exchange health information when the technology is not tied to an EHR? Would these providers be able to achieve the same care coordination goals using such 134 Office of the National Coordinator (May 2019). Interoperability among Office-Based Physicians in 2015 and 2017. ONC Data Brief No. 48. Retrieved from https://www.healthit.gov/sites/default/files/ page/2019–05/2015to2017PhysicianInteroperability DataBrief_0.pdf. 135 For example, see Pa. Cons. Stat. Ann. tit. 71, sec. 1690.108(b), https://www.health.state.pa.us/pdf/ act63.pdf. PO 00000 Frm 00087 Fmt 4701 Sfmt 4702 76323 applications as with a more extensive EHR implementation, or would the value be lower but still sufficient to improve care quality and care coordination? The Substance Abuse and Mental Health Services Administration (SAMHSA) published regulations related to improved care coordination among providers that treat substance use disorders as well as protecting those patients’ records (42 CFR part 2). Section 6001 of the SUPPORT Act also encourages CMS to consider ways to facilitate information sharing among behavioral health providers by adding a model opportunity to the list of possible model opportunities for consideration by the CMS Center for Medicare & Medicaid Innovation under section 1115A(b)(2)(B) of the Act. We are looking for innovative approaches to addressing the need to facilitate the electronic exchange of behavioral health information, as well as approaches to support the exchange of health information to behavioral health providers to inform care and provision of behavioral health services. ONC has been working with other Federal agencies to consolidate input to help inform approaches HHS can take to advance behavioral healthcare delivery and coordination supported by health IT, through the development of action items and high impact projects including to support behavioral health integration consistent with the HHS Roadmap for Behavioral Health Integration.136 Information about projects such as Health Information Exchange and Behavioral Health Care and the Rhode Island Behavioral and Medical Information Exchange Project are available on the ONC website at https://www.healthit.gov.137 Many behavioral health providers practice in community-based roles. As a result, when considering behavioral health specifically, it is valuable to consider community-based providers more broadly. We are interested in public comments on how we might best support electronic data exchange of behavioral health information between and among behavioral health providers, other healthcare providers, and patients, as well as how we might best inform and 136 Assistant Secretary for Planning and Evaluation (Sep. 2022). HHS Roadmap for Behavioral Health Integration. Retrieved from https://aspe.hhs.gov/sites/default/files/documents/ 84a701e0878bc26b2812a074aa22a3e2/roadmapbehavioral-health-integration.pdf. 137 The Office of the National Coordinator for Health Information Technology (ONC). Behavioral Health. Retrieved from https://www.healthit.gov/ topic/behavioral-health. E:\FR\FM\13DEP2.SGM 13DEP2 lotter on DSK11XQN23PROD with PROPOSALS2 76324 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules support the movement of health data (and its consistency) to behavioral health providers for their use to inform care and treatment for individuals with behavioral health needs. Specifically, we are seeking public comments on the following questions: • Can applications using FHIR APIs facilitate electronic data exchange between behavioral health providers and with other healthcare providers, as well as their patients, without greater EHR adoption? Is EHR adoption needed first? What opportunities do FHIR APIs provide to bridge the gap? What needs might not be addressed by using applications with more limited functionality than traditional EHRs? • How can existing criteria under the ONC Health IT Certification Program ensure applications used by behavioral health providers enable interoperability? What updates to existing criteria, or new criteria, could better support exchange by these clinicians? • What levers could CMS consider using to facilitate greater electronic health data exchange from and to behavioral health providers? What costs, resources, and/or burdens are associated with these options? Is there additional sub-regulatory guidance and/or technical assistance that CMS or HHS could provide that would be helpful? • Are there particular considerations for electronic data exchange for behavioral health providers who practice independently, are communitybased, or are non-traditional providers? What about rural-based behavioral health providers? How could an APIbased solution help address these considerations? • Are there state or Federal regulations or payment rules that are perceived as creating barriers to technical integration of systems within these practices? What additional policy issues, technical considerations, and operational realities should we consider when looking at ways to best facilitate the secure electronic exchange of health information that is maintained by behavioral health providers including sensitive health information? • What are current drivers at the Federal, state, or local level that are effectively supporting greater adoption of health IT for behavioral health providers? What new regulations guidance, or other policy levers (including new authorities) could benefit community providers or include incentives for community providers to encourage greater adoption of health IT? • What methods and approaches have stakeholders utilized to help advance health IT adoption among behavioral VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 health providers, for instance, effective practices for braiding/blending of funds and as part of value-based models? How are stakeholders effectively strengthening system capacity, connecting to care, and creating healthy environments today? • What levers and approaches could CMS consider using and advancing to facilitate greater electronic health data exchange from and to community-based health providers including use of relevant health IT standards and certification criteria for health IT as feasible? What costs, resources, and/or burdens are associated with these options? • What privacy and security considerations would be the biggest barriers for community-based providers to engage in information exchange, and which could be addressed by Federal policy, which by technology, and which by process? We seek comments on these questions and issues for future consideration. C. Request for Information: Improving the Exchange of Information in Medicare Fee for Service In the Medicare FFS program, the ordering provider or supplier can often be different than the rendering provider or supplier of items or services, which may contribute to challenges in the coordination of patient care and exchange of medical information needed to ensure accurate and timely payment. Unlike their physician and hospital counterparts, providers such as home health agencies, Durable Medical Equipment, Prosthetics, Orthotics, and Supplies (DMEPOS) suppliers, and ambulance providers were not included in the American Reinvestment and Recovery Act (ARRA) Health Information Technology for Economic and Clinical Health (HITECH) Act programs, so they were not eligible for the same incentive payments for health IT adoption and interoperable data exchange as other providers. Thus, some providers or suppliers continue to use the U.S. Postal Service or fax machines to send patient information, and these methods can also lead to delays in the receipt of orders, prior authorization decisions, and payments. Ideally, health IT and the electronic exchange of information would streamline information-sharing processes between ordering and rendering providers or suppliers so that any impediments are eliminated. For example, with DMEPOS suppliers, a physician or non-physician practitioner (NPP) may order a power wheelchair and document the necessary information in the beneficiary’s medical PO 00000 Frm 00088 Fmt 4701 Sfmt 4702 record, but the DMEPOS provider will provide the wheelchair and submit the claim for payment. For some DMEPOS items, a written order is required prior to delivery.138 This dynamic often necessitates significant coordination between the ordering provider or supplier and the rendering provider to exchange information before the item or service can be provided to the beneficiary so that the rendering provider has the documentation from the ordering provider or supplier that demonstrates that the furnishing of the item or service meets CMS coding, coverage, payment or documentation requirements. The rendering provider or supplier must submit documentation of the patient’s medical condition to justify why a patient requires a specific item or service and/or in order to meet CMS requirements. This helps to ensure that beneficiaries are receiving medically necessary care that meets CMS requirements. This information is usually documented in the ordering provider or supplier’s medical record. The rendering provider or supplier must obtain this information from the ordering provider or supplier to furnish the item, and submit a claim or prior authorization request. The timing of a beneficiary receiving a service or item could be dependent on the ordering provider or supplier sending the documentation to the rendering provider in advance, as their claims are not dependent on sending these data. Such coordination can take time to complete and lead to delays in the receipt of necessary documentation, particularly in those instances where either one or both providers or suppliers do not use health IT to share medical information. Even in situations where both the ordering and rendering providers or suppliers do use health IT to exchange information, the compatibility of the systems may not allow for the easy and/or expeditious exchange of that information. Should prior authorization be required, disparities in health IT system data exchange capabilities could lead to delays in healthcare decision-making and potential delays in the delivery of care for patients. These delays can be more problematic in those settings where the focus of one provider is on the order and the focus of the other provider is on providing the item or service and submitting the claim for payment. This arrangement frequently 138 Centers for Medicare & Medicaid Services (Apr. 2022). Required face-to-face encounter and written order prior to delivery list. Retrieved from https://www.cms.gov/files/document/required-faceface-encounter-and-written-order-prior-deliverylist.pdf. E:\FR\FM\13DEP2.SGM 13DEP2 lotter on DSK11XQN23PROD with PROPOSALS2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules places more burden on the rendering provider to obtain the necessary information and engage in multiple follow-ups—and can result in delays in the patient receiving the item or service. The inconsistent use and lack of uniform health IT to exchange medical documentation will take time to effectively resolve. In the interim, we are interested in public comments on how Medicare FFS might best support improvements to the exchange of medical documentation between and among providers or suppliers and patients, as well as how we might best inform and support the movement of health data (and its consistency) to providers or suppliers for their use to inform care and treat beneficiaries. We are also interested in public comments on what specific changes or improvements in health IT could assist providers or suppliers in submitting medical documentation to CMS and its contractors so that claims are not denied and/or are not deemed improper payments. Specifically, we are seeking public comments on the following questions: • How might CMS encourage more electronic exchange of medical information (for example, orders, progress notes, prior authorization requests, and/or plans of care) between providers/suppliers and with CMS and its contractors at the time an item or service is ordered? When possible, please describe specific recommendations to facilitate improved data exchange between providers or suppliers, and with CMS and its contractors, to support more efficient, timely, and accurate claims and prior authorization communications. Are there specific process changes that you believe would improve the exchange of medical documentation between ordering and rendering providers or suppliers? Are there particular policy, technical, or other needs that must be accounted for in light of the unique roles of ordering and rendering providers or suppliers? • Are there changes necessary to health IT to account for the need for providers/suppliers (ordering and rendering) to exchange medical documentation, either to improve the process in general or to expedite processing to ensure beneficiary care is not delayed? How could existing certification criteria or updates to certification criteria under the ONC Health IT Certification program support specific exchange needs? • What additional steps in the area of health IT and the exchange of information could CMS take to assist providers or suppliers in the claim VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 submission process? Are there changes in technology or processes that could also reduce the number of claims resubmissions and/or improper payments? • What levers could CMS consider using to facilitate greater collaboration and exchange of information among providers/suppliers? What costs, resources, and/or burdens are associated with this type of collaboration? Are there changes that could reduce improper payments and the administrative burden often encountered by rendering providers/ suppliers who need medical record documentation from ordering providers or suppliers? • Are there state or Federal regulations or payment rules that are perceived as creating barriers to the exchange of information between ordering and rendering providers/ suppliers? What additional policy issues, technical considerations, and operational realities should we consider when looking at ways to best facilitate the secure exchange of information between providers or suppliers and with Medicare FFS? We seek comments on these questions and issues for future consideration. 76325 D. Request for Information: Advancing Interoperability and Improving Prior Authorization Processes for Maternal Health The Biden-Harris Administration has prioritized addressing the nation’s maternity care crisis. In April 2021, President Biden issued a Presidential Proclamation marking Black Maternal Health Week.139 In December 2021, Vice President Kamala Harris convened a Federal Maternal Health Day of Action, where she announced a Call to Action 140 to improve maternal health outcomes across the United States. The Administration subsequently released the White House Blueprint for Addressing the Maternal Health Crisis 141 in June 2022, which describes its overarching approach for the Federal Government to combat maternal mortality and morbidity. Among the Blueprint’s five priorities is advancing data collection, standardization, harmonization, transparency, and research, with the Blueprint noting that data and research are foundational to achieving each of the other goals it sets. In July 2022, CMS published its Cross-Cutting Initiative: CMS Maternity Care Action Plan,142 which aims to improve health outcomes and reduce disparities. CMS has identified five key gaps in maternity care related to CMS programs, which are also reflected in the White House Blueprint, and is currently taking steps to address each: (1) coverage and access to care, (2) data, (3) quality of care, (4) workforce, and (5) social supports. CMS is already playing an integral role in addressing many of the White House Blueprint’s goals in concert with its own action plan. For example, in October 2022, CMS announced that more than half of all states have extended Medicaid and CHIP coverage for 12 months after pregnancy, resulting in an additional approximately 418,000 Americans across 26 states and the District of Columbia being eligible for 12 months of postpartum coverage.143 CMS continues to work with additional states to adopt extended postpartum coverage in Medicaid and CHIP. The CMS Maternity Care Action Plan also expressed intentions to coordinate across programs to identify gaps and best practices. Technology can be leveraged to address known racial disparities to prenatal and postnatal care by facilitating telehealth visits or remote monitoring options. For example, research has shown leveraging technology and telehealth significantly reduced the racial disparities in blood pressure ascertainment.144 Some state Medicaid agencies are leveraging the enhanced Federal financial participation (FFP), available under section 1903(a)(3) of the Act and 139 The White House (Apr. 2022). A Proclamation on Black Maternal Health Week, 2022. 87 FR 22095 (April 8, 2022). Retrieved from https:// www.whitehouse.gov/briefing-room/presidentialactions/2022/04/08/a-proclamation-on-blackmaternal-health-week-2022/. 140 The White House (Dec. 2021). Fact Sheet: Vice President Kamala Harris Announces Call to Action to Reduce Maternal Mortality and Morbidity. Retrieved from https://www.whitehouse.gov/ briefing-room/statements-releases/2021/12/07/factsheet-vice-president-kamala-harris-announces-callto-action-to-reduce-maternal-mortality-andmorbidity/. 141 The White House (Jun. 2022). White House Blueprint for Addressing the Maternal Health Crisis. Retrieved from https://www.whitehouse.gov/wpcontent/uploads/2022/06/Maternal-HealthBlueprint.pdf. 142 Centers for Medicare & Medicaid Services. Cross-Cutting Initiative: CMS Maternity Care Action Plan. Retrieved from https://www.cms.gov/files/ document/cms-maternity-care-action-plan.pdf. 143 Centers for Medicare & Medicaid Services (Oct. 2022). Biden-Harris Administration Announces More than Half of All States Have Expanded Access to 12 Months of Medicaid and CHIP Postpartum Coverage. Retrieved from https:// www.cms.gov/newsroom/press-releases/bidenharris-administration-announces-more-half-allstates-have-expanded-access-12-months-medicaid. 144 Yarrington, C., Parker, S., & Mujic, E. (Apr. 2022). Abstract EP50: Implementation of A CloudConnected Remote Blood Pressure Monitoring Program During the Postpartum Period Improves Ascertainment. Retrieved from https:// www.ahajournals.org/doi/10.1161/circ.145.suppl_ 1.EP50. PO 00000 Frm 00089 Fmt 4701 Sfmt 4702 E:\FR\FM\13DEP2.SGM 13DEP2 76326 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules lotter on DSK11XQN23PROD with PROPOSALS2 regulations at 42 CFR 433.111, to procure remote monitoring and telehealth capabilities to address this inequity and expand access to remote blood pressure monitoring, behavioral health consultations, lactation consultations, blood glucose monitoring, etc. CMS seeks comments on how we might further support these state efforts with that enhanced FFP system. As the CMS action plan outlines, we are working to expand our data collection efforts, stratify data by key demographics to identify disparities in maternal care or outcomes, and coordinate across programs to identify gaps and best practices. In the FY 2022 IPPS final rule,145 we finalized Hospital Inpatient Quality Reporting (IQR) program rules that require hospitals to report the Maternal Morbidity Structural Measure. That measure assesses whether or not a hospital participates in a Statewide or National Perinatal Quality Improvement (QI) Collaborative initiative, and if so, whether it implements patient safety practices and/ or bundles related to maternal morbidity from that QI Collaborative.146 These Collaboratives, such as the Alliance for Innovation on Maternal Health (AIM), provide implementation and data support for the adoption of evidencebased patient safety bundles.147 Additionally, we finalized two new electronic clinical quality measures (eCQMs) related to maternal health— one measuring severe obstetric complications and another measuring low-risk Cesarean section rates—in the FY 2023 IPPS final rule (87 FR 49181).148 For state Medicaid and CHIP agencies, CMS annually identifies a core set of measures for voluntary reporting that show the quality of care and health outcomes for those programs’ beneficiaries. These measures are currently voluntarily reported by states, 145 Department of Health and Human Services, Centers for Medicare & Medicaid Services (Aug 2021). 86 FR 44774 (August 13, 2021). Retrieved from https://www.federalregister.gov/documents/ 2021/08/13/2021-16519/medicare-programhospital-inpatient-prospective-payment-systemsfor-acute-care-hospitals-and-the. 146 Centers for Medicare & Medicaid Services. Maternal Morbidity Structural Measure. Retrieved from https://www.cms.gov/files/document/ maternal-morbidity-structural-measurespecifications.pdf. 147 Alliance for Innovation on Maternal Health. Patient Safety Bundles. Retrieved from https:// saferbirth.org/patient-safety-bundles/. 148 Department of Health and Human Services, Centers for Medicare & Medicaid Services (Aug 2022). Retrieved from https:// www.federalregister.gov/documents/2022/08/10/ 2022-16472/medicare-program-hospital-inpatientprospective-payment-systems-for-acute-carehospitals-and-the. VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 but a subset of measures—that, is the Child Core Set and behavioral health measures in the Adult Core Set—will become mandatory for states to report beginning in 2024. We identified a core set of 9 measures in 2022 that support our maternal and perinatal healthfocused efforts (the Maternity Core Set).149 The Maternity Core Set consists of 6 measures from the Child Core Set and 3 measures from the Adult Core Set and is used to measure and evaluate progress toward improvement of maternal and perinatal health in the Medicaid and CHIP. Data reported by states will additionally be used to conduct an equity assessment on the quality of postpartum care in Medicaid and CHIP. In addition to measurement data, which helps us to better understand the state of maternal healthcare in our various programs, CMS also believes that a critical foundation comprised of health IT, data sharing, and interoperability underlie many opportunities to improve maternal health outcomes. CMS is now seeking information from the public on evidence-based policies we could pursue that leverage information technology to improve such outcomes. Health IT can be used to support safe and effective maternal and child healthcare. The ONC Pediatric Health Information Technology: Developer Informational Resource 150 is an HHS non-regulatory initiative to inform the technical and implementation specifications for health IT developers of products used by clinicians that provide healthcare for children that includes recommendations specific to maternal health. CMS invites input on stakeholder experiences with this informational resource and comments on how to advance this work. Using common data exchange standards for human services information can also provide many benefits for supporting maternal healthcare, including, but not limited to, promoting greater information-sharing and interoperability, collaboration with other human services sectors beyond healthcare such as education and public safety, and overall improvements to systems for the effective use of 149 Centers for Medicare & Medicaid Services (2022). 2022 Core Set of Maternal and Perinatal Health Measures for Medicaid and CHIP (Maternity Core Set. Retrieved from https://www.medicaid.gov/ medicaid/quality-of-care/downloads/2022maternity-core-set.pdf. 150 Office of the National Coordinator for Health Information Technology (ONC) (Jun 2020). Pediatric Health Information Technology: Developer Informational Resource. Retrieved from https:// www.healthit.gov/sites/default/files/page/2020-06/ Pediatric-Health-IT-Developer-IR-06102020.pdf. PO 00000 Frm 00090 Fmt 4701 Sfmt 4702 technology. CMS welcomes input on technical and policy approaches that effectively link maternal human services data to health IT codes and value sets, such as ICD–10 and LOINC codes, in order to help improve interoperability across multiple systems, domains, and use cases, including the effective use of interoperable assessment instruments. CMS further welcomes input on how other health IT standards, such as FHIR, can be used to expand healthcare interoperability to integrate with human services for individual maternal health and overall population health improvement. The USCDI version 3, published in July 2022, contains a new data class on pregnancy status, as well as other data classes and elements important for supporting maternal health, including SDOH Assessment, Diagnostic Imaging, and Vital Signs.151 While exchange of the USCDI version 3 dataset is neither currently required nor proposed in this proposed rule, we intend to work with both our Federal partners and industry stakeholders to encourage harmonization of data elements tied to improved maternal health outcomes. In addition, ONC recently launched an initiative called USCDI+ to support the identification and establishment of domain, or program-specific, datasets that build on the existing USCDI dataset.152 USCDI+ is a service that ONC provides to Federal partners to establish, harmonize (that is, unify disparate datasets), and advance the use of interoperable datasets that extend beyond the core data in the USCDI to support agency-specific programmatic requirements. The USCDI+ initiative could advance availability of maternal health information to meet Federal partners’ needs. For instance, by identifying and harmonizing data elements needed for quality reporting on maternal health measures under the Hospital IQR program. As such, we are interested in feedback from the public on the following questions: • Are there other data elements and classes relevant to care coordination for maternal health that should be added to USCDI? • Are there data related to maternal health that are currently not collected at scale, or not collected at all, that would be helpful for stakeholders to have 151 Office of the National Coordinator for Health Information Technology (Jul. 2022). United States Core Data for Interoperability. Retrieved from https://www.healthit.gov/isa/sites/isa/files/2022-07/ USCDI-Version-3-July-2022-Final.pdf. 152 Argentieri et al., 2021. HealthITbuzz. Thinking Outside the Box: The USCDI+ Initiative. Retrieved from https://www.healthit.gov/buzz-blog/health-it/ thinking-outside-the-box-the-uscdi-initiative. E:\FR\FM\13DEP2.SGM 13DEP2 lotter on DSK11XQN23PROD with PROPOSALS2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules access to? How could CMS support the collection of this data? • What are key gaps in the standardization and harmonization of maternal health data? How can HHS support current efforts to address these gaps? • How could an initiative such as USCDI+ be leveraged to harmonize maternal health data needed for care coordination, quality measurement, and other Federal programs that collect maternal health data? In section II.D of this proposed rule, we discuss our proposals to improve prior authorizations. In addition to the impacts on patient care in general discussed in that section, we note the effects of inefficient prior authorizations on maternal health, specifically. For instance, maternal care experts have observed that some payers may utilize an intermediary, such as a radiology benefits management company, to act on their behalf to review healthcare provider requests to perform imaging. This may add an additional waiting period for a decision, potentially creating hazardous delays for pregnant women who, for example, need to obtain an ultrasound.153 Furthermore, requiring prior authorization for screening cervical length in patients with a prior history of preterm birth or growth ultrasound for women at risk for fetal growth restriction can place patients at risk for adverse perinatal outcomes.154 We are therefore interested in stakeholder feedback on the following questions: • Should there be special considerations for the prior authorization process in maternal healthcare? For example, should the timeframes for prior authorization be expedited in cases where the prior authorization is related to prenatal and perinatal care? • How have prior authorization processes impacted maternal healthcare for patients enrolled in CMS programs? Please include references to specific CMS program(s) in your response. • Should prior authorizations carry over from one payer to another when a patient changes payers for the duration of the pregnancy, or at least for a period of time while the patient and their provider gather the necessary documentation to submit a new prior authorization to the new payer? • What other special considerations should be given to data sharing for maternal health transitions? 153 Jain et al., 2020. Prior Authorization and its impact on access to obstetric ultrasound. Retrieved from https://www.sciencedirect.com/science/ article/pii/S0002937820300260?via%3Dihub#bib5. 154 Ibid. VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 E. Request for Information: Advancing the Trusted Exchange Framework and Common Agreement (TEFCA) Section 4003(b) of the 21st Century Cures Act (Pub. L. 114–255), enacted in 2016, amended section 3001(c) of the Public Health Service Act (42 U.S.C. 300jj–11(c)) and required HHS to take steps to advance interoperability for the purpose of ensuring full network-tonetwork exchange of health information. Specifically, Congress directed the National Coordinator to ‘‘develop or support a trusted exchange framework, including a common agreement among health information networks nationally.’’ Since the enactment of the 21st Century Cures Act, HHS has pursued the development of TEFCA. ONC’s goals for TEFCA are: Goal 1: Establish a universal policy and technical floor for nationwide interoperability. Goal 2: Simplify connectivity for organizations to securely exchange information to improve patient care, enhance the welfare of populations, and generate healthcare value. Goal 3: Enable individuals to gather their healthcare information.155 On January 18, 2022, ONC announced a significant TEFCA milestone by releasing the Trusted Exchange Framework 156 and Common Agreement for Nationwide Health Information Interoperability Version 1 (Common Agreement).157 The Trusted Exchange Framework is a set of non-binding principles for health information exchange, and the Common Agreement is a contract that advances those principles. The Common Agreement and the Qualified Health Information Network (QHIN) Technical Framework Version 1 (QTF),158 which is incorporated by reference in the Common Agreement, establishes a technical infrastructure model and governing approach for different health information networks (HINs) and their users to securely share clinical 155 Tripathi, M (2022, January 18). 3 . . . 2 . . . 1 . . . TEFCA is Go for Launch. Health IT Buzz. Retrieved from https://www.healthit.gov/buzz-blog/ interoperability/321tefca-is-go-for-launch. 156 The Trusted Exchange Framework (TEF): Principles for Trusted Exchange (2022, January). HealthIT.gov. Retrieved from https:// www.healthit.gov/sites/default/files/page/2022-01/ Trusted_Exchange_Framework_0122.pdf. 157 Common Agreement for Nationwide Health Information Interoperability Version 1 (Jan. 2022). HealthIT.gov. Retrieved from https:// www.healthit.gov/sites/default/files/page/2022-01/ Common_Agreement_for_Nationwide_Health_ Information_Interoperability_Version_1.pdf. 158 TEFCA: Qualified Health Information Network (QHIN) Technical Framework (QTF) Version 1.0 (2022, January). SequoiaProject.org. https:// rce.sequoiaproject.org/wp-content/uploads/2022/ 01/QTF_0122.pdf. PO 00000 Frm 00091 Fmt 4701 Sfmt 4702 76327 information with each other, all under commonly agreed to terms. The Common Agreement is a legal contract that QHINs 159 sign with the ONC Recognized Coordinating Entity (RCE),160 a private-sector entity that implements the Common Agreement and ensures QHINs comply with its terms. The technical and policy architecture of how exchange occurs under the Common Agreement follows a networkof-networks structure, which allows for connections at different levels and is inclusive of many different types of entities at those different levels, such as HINs, care practices, hospitals, public health agencies, and Individual Access Services (IAS) 161 Providers.162 QHINs connect directly to each other to facilitate nationwide interoperability, and each QHIN can connect Participants, which can connect Subparticipants.163 Compared to most 159 The Common Agreement defines a QHIN as ‘‘to the extent permitted by applicable SOP(s), a Health Information Network that is a U.S. Entity that has been Designated by the RCE and is a party to the Common Agreement countersigned by the RCE.’’ See Common Agreement for Nationwide Health Information Interoperability Version 1, at 10 (Jan. 2022), https://www.healthit.gov/sites/default/ files/page/2022-. 160 In August 2019, ONC awarded a cooperative agreement to The Sequoia Project to serve as the initial RCE. The RCE will operationalize and enforce the Common Agreement, oversee QHINfacilitated network operations, and ensure compliance by participating QHINs. The RCE will also engage stakeholders to create a roadmap for expanding interoperability over time. See ONC Awards The Sequoia Project a Cooperative Agreement for the Trusted Exchange Framework and Common Agreement to Support Advancing Nationwide Interoperability of Electronic Health Information (September 3, 2019), https:// sequoiaproject.org/onc-awards-the-sequoia-projecta-cooperative-agreement-for-the-trusted-exchangeframework-and-common-agreement-to-supportadvancing-nationwide-interoperability-ofelectronic-health-information/. 161 The Common Agreement defines Individual Access Services (IAS) as ‘‘with respect to the Exchange Purposes definition, the services provided utilizing the Connectivity Services, to the extent consistent with Applicable Law, to an Individual with whom the QHIN, Participant, or Subparticipant has a Direct Relationship to satisfy that Individual’s ability to access, inspect, or obtain a copy of that Individual’s Required Information that is then maintained by or for any QHIN, Participant, or Subparticipant.’’ See Common Agreement for Nationwide Health Information Interoperability Version 1, at 7 (Jan. 2022), https:// www.healthit.gov/sites/default/files/page/2022-01/ Common_Agreement_for_Nationwide_Health_ Information_Interoperability_Version_1.pdf. 162 The Common Agreement defines ‘‘IAS Provider’’ as: ‘‘Each QHIN, Participant, and Subparticipant that offers Individual Access Services.’’ See Common Agreement for Nationwide Health Information Interoperability Version 1, at 7 (Jan. 2022), https://www.healthit.gov/sites/default/ files/page/2022-01/Common_Agreement_for_ Nationwide_Health_Information_Interoperability_ Version_1.pdf. 163 For the Common Agreement definitions of QHIN, Participant, Subparticipant, Treatment, E:\FR\FM\13DEP2.SGM Continued 13DEP2 76328 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules lotter on DSK11XQN23PROD with PROPOSALS2 nationwide exchange today, the Common Agreement includes an expanded set of Exchange Purposes beyond Treatment to include IAS, Payment, Health Care Operations, Public Health, and Government Benefits Determination 164—all built upon common technical and policy requirements to meet key needs of the U.S. healthcare system. This flexible structure allows stakeholders to participate in the way that makes the most sense for them, while supporting simplified, seamless exchange. The Common Agreement also requires strong privacy and security protections for all entities who elect to participate, including entities not covered by HIPAA.165 For the purposes of this RFI, we broadly refer to different modes of exchange by different stakeholders under this framework as, ‘‘enabling exchange under TEFCA.’’ The QTF, which was developed and released by the RCE, describes the functional and technical requirements that a HIN 166 must fulfill to serve as a QHIN. The QTF specifies the technical underpinnings for QHIN-to-QHIN exchange and certain other responsibilities described in the Common Agreement. The technical and functional requirements described in the QTF enable information exchange modalities, including querying and message delivery, across participating entities. The Common Agreement and the QTF do not require HL7 FHIR-based exchange. The Common Agreement and QTF allow for the optional exchange of FHIR content using more traditional, established standards to enable the transport of that content. However, TEFCA can nonetheless be a strong catalyst for network enablement of FHIR maturation. To that end, the RCE released a 3-year FHIR Roadmap for TEFCA Exchange, which lays out a deliberate strategy to add FHIR-based exchange under the Common Payment, Health Care Operations, Public Health, and Government Benefits Determination, see Common Agreement for Nationwide Health Information Interoperability Version 1, at 3–13 (Jan. 2022), https://www.healthit.gov/sites/default/files/ page/2022-01/Common_Agreement_for_ Nationwide_Health_Information_Interoperability_ Version_1.pdf. 164 Ibid. 165 Common Agreement for Nationwide Health Information Interoperability Version 1 (Jan. 2022). HealthIT.gov. Retrieved from https:// www.healthit.gov/sites/default/files/page/2022-01/ Common_Agreement_for_Nationwide_Health_ Information_Interoperability_Version_1.pdf. 166 ‘‘Health Information Network’’ under the Common Agreement has the meaning assigned to the term ‘‘Health Information Network or Health Information Exchange’’ in the information blocking regulations at 45 CFR 171.102. VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 Agreement and the QTF in the near future.167 In 2022, prospective QHINs had the opportunity to begin signing the Common Agreement and apply for designation. Following the approval of their applications, the RCE will begin onboarding and designating QHINs to exchange information. In 2023, HHS expects stakeholders across the care continuum to have increasing opportunities to enable exchange under TEFCA. In the FY 2023 IPPS/LTCH final rule (87 FR 48780), we finalized our proposal to add a new, optional Enabling Exchange Under TEFCA measure to the Health Information Exchange Objective in the Medicare Promoting Interoperability program.168 This measure will provide eligible hospitals and CAHs with the opportunity to earn credit for the Health Information Exchange objective if they: (1) are a signatory to a ‘‘Framework Agreement’’ as that term is defined in the Common Agreement; (2) are in good standing (that is, not suspended) under that agreement; (3) enable secure, bidirectional exchange of information to occur for all unique patients discharged from the eligible hospital or CAH inpatient or emergency department (Place of Service (POS) code 21 or 23), and all unique patient records stored or maintained in the EHR for these departments; (4) and use the functions of CEHRT to support bi-directional exchange. The FY 2023 IPPS/LTCH proposed rule (87 FR 28108) also included a request for information about how TEFCA can support CMS policies and programs and how these programs can help to advance exchange under TEFCA to deliver value for stakeholders. The CY 2023 PFS proposed rule (87 FR 45860) likewise includes a nearly identical measure for MIPS eligible clinicians as part of the MIPS Promoting Interoperability Performance Category.169 We believe that the ability for stakeholders to connect to an entity that connects to a QHIN, or to connect directly to a QHIN, can support and 167 FHIR Roadmap for TEFCA Exchange Version 1, at 4 (Jan. 2022), https://rce.sequoiaproject.org/ wp-content/uploads/2022/01/FHIR-Roadmap-v1.0_ updated.pdf. 168 Retrieved from https:// www.federalregister.gov/documents/2022/08/10/ 2022-16472/medicare-program-hospital-inpatientprospective-payment-systems-for-acute-carehospitals-and-the. 169 Revisions to Payment Policies under the Medicare Physician Fee Schedule, Quality Payment Program and Other Revisions to Part B Proposed Rule for CY 2023 (CMS–1770–P). 87 FR 45860 (September 6, 2022). Retrieved from https://www.federalregister.gov/d/2022-14562. PO 00000 Frm 00092 Fmt 4701 Sfmt 4702 advance the payer requirements that we have proposed in this rule that would become applicable by 2026 if enacted as proposed. Specifically, such connections could support exchange of patient information with providers via the Provider Access API and support transmission of coverage and prior authorization requests from providers via the PARDD API. As requirements for use of FHIR are incorporated into the QTF, stakeholders that enable exchange under TEFCA will be better positioned to not only exchange the data we propose to require for these APIs, but also to do so in a multi-networked environment that simplifies connections between providers and payers. We similarly believe that such connections could support requirements for the Patient Access API previously finalized in the CMS Interoperability and Patient Access final rule (85 FR 25510) by enabling patients to access their information held by the payer, as well. As previously noted, TEFCA can be a strong catalyst for FHIR maturation. To the extent that TEFCA evolves in accordance with the FHIR Roadmap for TEFCA Exchange, we anticipate further opportunities for TEFCA to support information availability via FHIR API exchange requirements for payers. We believe enabling exchange under TEFCA by payers and vendors offering health apps could provide a simplified way for vendors to access and make information available to their customers. By accessing payer-held information through a QHIN or an entity connected to a QHIN, health apps could avoid the need to develop direct connections to each individual payer. This is because such apps could connect once and enable patients to gain access to information held by any payer exchanging information under TEFCA. Furthermore, as discussed in section II.A., apps that enable exchange under TEFCA would be required to meet the Common Agreement’s privacy and security requirements,170 which would provide assurance to payers that they meet a common standard for protecting patient data. Enabling exchange under TEFCA by health plans could also support the proposed requirements in section II.C. 170 Privacy and security are addressed in numerous ways throughout the Common Agreement. Relevant sections for this discussion include Section 10, ‘‘Individual Access Services (Required Flow-Downs, if Offering Individual Access Services);’’ Section 11, ‘‘Privacy;’’ and Section 12, ‘‘Security.’’ See Common Agreement for Nationwide Health Information Interoperability Version 1 (Jan. 2022), https://www.healthit.gov/ sites/default/files/page/2022-01/Common_ Agreement_for_Nationwide_Health_Information_ Interoperability_Version_1.pdf. E:\FR\FM\13DEP2.SGM 13DEP2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules lotter on DSK11XQN23PROD with PROPOSALS2 of this proposed rule for a payer to payer data exchange using FHIR APIs under which payers would make beneficiary information available to other plans when patients change their coverage. Health plans that enable exchange under TEFCA could easily identify other plans that hold information about a newly covered beneficiary by querying the network and securely requesting the information that would be required to be shared under our proposed requirements for the payer to payer data exchange. We are requesting input from the public on the ideas previously described in this section and related concepts for future exploration, as well as the following questions: • How could the requirements of the Common Agreement and the QTF help facilitate information exchange in accordance with the final policies in the CMS Interoperability and Patient Access final rule (85 FR 25510) around making clinical and administrative information held by health plans available to patients? How could TEFCA support proposed requirements for payers under this rule related to provider data access and prior authorization processes? • How should CMS approach incentivizing or encouraging payers to enable exchange under TEFCA? Under what conditions would it be appropriate to require this approach by payers subject to the proposed regulations in this rule and previously finalized regulations in the CMS Interoperability and Patient Access final rule (85 FR 25510)? • What concerns do commenters have about potential requirements related to enabling exchange under TEFCA? Could such an approach increase burden for some payers? Are there other financial or technical barriers to this approach? If VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 so, what should CMS do to reduce these barriers? We seek comments on these questions and issues for future consideration. V. Collection of Information Requirements Under the Paperwork Reduction Act of 1995, we are required to provide 60day notice in the Federal Register and solicit public comment before a collection of information requirement is submitted to the Office of Management and Budget (OMB) for review and approval. To fairly evaluate whether an information collection should be approved by OMB, section 3506(c)(2)(A) of the Paperwork Reduction Act (PRA) of 1995 requires that we solicit comment on the following issues: • The need for the information collection and its usefulness in carrying out the proper functions of our agency. • The accuracy of our estimate of the information collection burden. • The quality, utility, and clarity of the information to be collected. • Recommendations to minimize the information collection burden on the affected public, including automated collection techniques. We are requesting public comment on each of these issues for sections of this document that contain information collection requirements (ICRs). A. Background To advance our commitment to interoperability, we are proposing new requirements for certain impacted payers to implement FHIR APIs and several process improvements to help streamline the prior authorization process. The proposed FHIR APIs would permit patients, providers, and payers to access a defined set of standardized data. We additionally propose to require impacted payers to implement a FHIR Prior Authorization Requirements, PO 00000 Frm 00093 Fmt 4701 Sfmt 4702 76329 Documentation, and Decision (PARDD) API to support prior authorization processes; to reduce the amount of time to process prior authorization requests and send information about decisions; and to publicly report certain metrics about patient access utilization, and prior authorization processes, among other proposals. We also propose a new requirement for a Payer-to-Payer API to ensure data can follow patients when they change payers. Finally, we propose to require reporting of certain metrics regarding the use of the existing Patient Access API. Combined, these proposals are intended to reduce burden on providers, payers, and patients and support improvements in patient care coordination. To incentivize provider participation, specifically with the PARDD API, we are proposing a new measure for MIPS eligible clinicians under the Promoting Interoperability performance category of MIPS and for eligible hospitals and CAHs under the Medicare Promoting Interoperability Program related to electronic prior authorization beginning in 2026, but the measure would not be scored until a future date. We would propose future year scoring and the number of points associated with the measure in future rulemaking. This new measure will be included in a PRA package related to this proposed rule. B. Wage Estimates To derive average costs, we use data from the U.S. Bureau of Labor (BLS) Statistics’ National Occupational Employment and Wage Estimates (https://www.bls.gov/oes/current/oes_ nat.htm), and to the extent possible, align with other CMS regulatory actions. Table 11 presents the mean hourly wage, the cost of fringe benefits (calculated at 100 percent of salary), and the adjusted hourly wage. E:\FR\FM\13DEP2.SGM 13DEP2 76330 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules TABLE 11: HOURLY WAGE ESTIMATES lotter on DSK11XQN23PROD with PROPOSALS2 We are adjusting the employee hourly wage estimates by a factor of 100 percent, or doubling the BLS wage estimates. This is necessarily a rough adjustment because fringe benefits and overhead costs vary significantly across employers based on the age of employees, location, years of employment, education, vocations, and other factors. Methods of estimating these benefits and overhead costs can vary across studies. We have elected to use sources in alignment with other CMS regulations after determining that they have used similar estimates and formulas. Consistent with our approach in the CMS Interoperability and Patient Access final rule (85 FR 25622), we determine ICRs by evaluating cost and burden at the impacted payer level, as defined and discussed in detail in that rule. Ultimately, we determined that there are 365 impacted payers 171 that together represent the possible plans, entities, issuers, and state programs impacted by these proposals. The increase in impacted payers from the CMS Interoperability and Patient Access final rule corresponds to the average annual increase in impacted payers resulting from new market entries. The total 171 We provide a detailed rationale for how we determined the number of impacted payers in the CMS Interoperability and Patient Access final rule (85 FR 25622). In that analysis we determined that 288 issuers and 56 states, territories, and U.S. commonwealths, which operate Medicaid and CHIP FFS programs, will be subject to the API provisions for Medicare, Medicaid, and the individual market. To this, we added the one state that operates its CHIP and Medicaid separately. Thus, we have 345 total impacted payers (288 + 56 + 1). This number has been updated to 365 to reflect an increase in impacted payers in the impacted programs. VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 estimated burden on these impacted payers is described in detail in each of the following ICRs and the summary table (M9) at the end of this section. We estimated the total number of burden hours across all impacted payers in the first year of implementation at 5.3 million hours; assuming a total cost to impacted payers to begin at approximately $110 million in the first year, increasing to $221 million in the second and third year and going down to $142 million by the fifth and subsequent years. We describe each ICR in detail and request comment on the assumptions made in deriving these burden estimates. All burden estimates will also be described and the public will have an opportunity to comment on them in a forthcoming PRA package to accompany this proposed rule. 1. ICRs Regarding the Proposal To Require Reporting of Patient Access API Metrics to CMS (42 CFR 422.119, 431.60, 438.242, 457.730, and 457.1233 and 45 CFR 156.221) To assess whether our policy requirements concerning the Patient Access API finalized in the CMS Interoperability and Patient Access final rule (85 FR 25558) have been implemented, we are proposing to require impacted payers to annually report certain metrics to CMS on the use of the Patient Access API. Specifically, we are proposing to collect: 1) the total number of unique patients whose data are transferred via the Patient Access API to a health app designated by the patient; and 2) the total number of unique patients whose data are transferred more than once via the PO 00000 Frm 00094 Fmt 4701 Sfmt 4702 Patient Access API to a health app designated by the patient. We estimate that impacted payers would conduct two major work phases: (1) implementation, which includes defining requirements and system design (and updates) to generate and compile reports; and (2) maintenance, which we define as including the compilation and transmission of annual reports to CMS. During the implementation phase, impacted payers would need to prepare their systems to capture the data to be transmitted to CMS. The burden estimate related to the new proposed requirements reflects the time and effort needed to identify, collect, and disclose the information. We estimate an initial set of one-time costs associated with implementing the reporting infrastructure and an ongoing annual maintenance cost to report after the reporting infrastructure is established. Table 12 presents our preparatory computational estimates for first-year implementation and ongoing maintenance costs. Table 12 is not the official statement of burden, which is found in Table 19, including the number of respondents and responses. Table 12 presents the preparatory calculations needed to create the official statement of burden in Table 19. We assume a two-person team of a software/ web developer and a business operations specialist would spend an aggregate of 160 and 40 hours, respectively, for the first and subsequent years, at a total cost per impacted payer (rounded) up to $15,000 and $3,000, for the first and subsequent years. The E:\FR\FM\13DEP2.SGM 13DEP2 EP13DE22.012</GPH> $37.66 $37.66 $75.32 $20.38 $20.38 $40.76 Com uter and Information Anal sts $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 11-1021 $60.45 $60.45 $120.90 General and O erations Mana ers 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 11 consistently reports mean hourly wages. For Medical Record Specialists, the median wage is $21.20 ($42.40 when multiplied by two to reflect fringe benefits). This median will be used in ICR #8 to provide an alternate aggregate estimate, which does not differ from the estimate using the mean. Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules aggregate burden (rounded) for 365 impacted payers would be 60,000 hours and 15,000 hours for the first and subsequent years at a cost of $5.5 76331 million and $1 million for the first and subsequent years. TABLE 12: AGGREGATE BURDEN FOR COMPLYING WITH THE PROPOSED PATIENT ACCESS API REPORTING REQUIREMENTS We request comment on our assumptions and approach. lotter on DSK11XQN23PROD with PROPOSALS2 2. ICRs Regarding the Provider Access API Proposal (42 CFR 422.121, 431.61, 438.242, 457.731, and 457.1233 and 45 CFR 156.221) To promote our commitment to interoperability, we propose new requirements for a Provider Access API. This FHIR API would permit providers to receive standardized patient data to coordinate care. To estimate costs to implement the new requirements for new APIs proposed in this rule, we use the same methodology as that used in the CMS Interoperability and Patient Access final rule. In the CMS Interoperability and Patient Access final rule, we estimated that impacted payers would conduct three major work phases: initial design, development and testing, and long-term support and maintenance (85 FR 25605). In this proposed rule, we assume the same major phases of work would be required, with a different level of effort during each work phase, for each of the new proposed APIs. Consistent across all newly proposed API provisions, we describe the tasks associated with the first two phases. Where we believe additional effort associated with these tasks is necessary, we describe those as relevant in subsequent ICRs, depending on how we believe they affect cost estimates. We discuss the costs for the third phase, long-term support and maintenance, and our methodology for the development of those costs in aggregate for all proposed APIs in this section. In the initial design phase, we believe tasks would include: determining available resources (personnel, hardware, cloud storage space, etc.), assessing whether to use in-house or contracted resources to facilitate an API connection, convening a team to scope, VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 build, test, and maintain the API, performing a data availability scan to determine any gaps between internal data models and the data required for the necessary HL7 FHIR resources, and mitigating any gaps discovered in the available data. During the development and testing phase, we believe impacted payers would need to conduct the following: map existing data to the HL7 FHIR standards, allocate hardware for the necessary environments (development, testing, production), build a new FHIRbased server or leverage existing FHIR servers, determine the frequency and method by which internal data are populated on the FHIR server, build connections between the databases and the FHIR server, perform capability and security testing, and vet provider requests. Table 13 summarizes the aggregate burden for complying with the proposed Provider Access API requirements. Here we provide illustrative points explaining the calculations within the table and the terms used for the headings. For example, row one is titled ‘‘Database Administrators and Architects.’’ To develop the proposed Provider Access API, each organization will require a team of database administrators, engineers, computer system analysts, etc. The team members are detailed in the rightmost column. Continuing on the top row, ‘‘Database Administrators,’’ we obtained the labor cost of $97.20 per hour from the Bureau of Labor Statistics website. The $97.20 represents the mean wage for this occupational title. We assume most organizations would require 3 months of work for Database Administrators on this task. Three months is twelve weeks, or 480 hours (3 months × 4 weeks per month × 5 days a week × 8 hours per day). The 480 hours are found in the column titled ‘‘Primary Hours.’’ The PO 00000 Frm 00095 Fmt 4701 Sfmt 4702 word primary, as used in the CMS Interoperability and Patient Access final rule, refers to the amount of time most organizations would require to conduct this work. This totals a cost of $46,656 for each organization, which is obtained by multiplying the 480 hours by the $97.20 per hour wage. This $46,656 is found in the column labeled ‘‘Total Cost, Primary.’’ We also provide low and high estimates representing a range of possible time and cost across all organizations. The low estimate is half the primary estimate, which is 240 hours or 1.5 months. The high estimate is 720 hours representing 4.5 months. These numbers are found in the low and high columns (hours) of the top row. The corresponding low and high costs are multiplied by the $97.20 per hour wage. We estimate that this is a reasonable range that would include all organizations. A typical organization would take 3 months, with some organizations completing the work in less time (in as little as 1.5 months) and some organizations taking longer (up to 4.5 months). The explanation of the top row applies to each of the ten occupational titles. The sum of the total hours and cost provides a typical organization’s total cost. This number is found in the ‘‘Totals for a single impacted payer’’ row. As depicted, the typical organization would take a total of 2,800 hours at a cost of $270,045. We estimated the impact by organization rather than by payer since many organizations may have entities in several of the programs to which this proposed rule applies: Medicare Advantage, Medicaid, CHIP, and QHP issuers on the FFEs. To arrive at the total cost of the rule, we multiplied the single-organization cost by 365 payers, the number of organizations hosting plans across the E:\FR\FM\13DEP2.SGM 13DEP2 EP13DE22.013</GPH> .. T<1talsfor *This table contains preparatory computations used for creating Table 19; they are not definitive statements of burden. Table 19 is the official collection of information (COI) statement of burden, including the number of respondents and responses. This table is the same format used in the CMS Interoperability and Patient Access final rule. 76332 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules four programs. For example, the total primary hourly burden of the rule is 1,022,000 (365 organizations × 2,800 for a single organization). Similar to the methodology used in the CMS Interoperability and Patient Access final rule, we estimated maintenance costs in future years after the API is established at 25 percent of the aggregate cost. This 25 percent was arrived at based on our experience with the industry. Rather than list more columns or create another table, we provide a footnote indicating that maintenance is 25 percent of the cost. For example, the primary aggregate burden over all 365 organizations is $98.6 million, implying that the annual maintenance costs would be $24.6 million (25 percent × $98.6 million). TABLE 13: AGGREGATE BURDEN FOR COMPLYING WITH THE PROPOSED PROVIDER ACCESS API REQUIREMENTS $97.20 $102.94 $95.22 $120.90 $46.42 $105.72 $155.52 $68.60 $75.56 $96.80 80 160 160 120 120 160 160 320 320 240 240 320 240 480 480 360 360 480 $23,328 $16,470 $7618 $19,344 $7,427 $12,686 $18,662 $10,976 $3,022 $15,488 $15 235 $38,688 $14,854 $25,373 $37,325 $21,952 $22 853 $58,032 $22,282 $38,059 $55,987 $32,928 lotter on DSK11XQN23PROD with PROPOSALS2 Although this provision would first be applicable on January 1, 2026, we believe it is reasonable that the APIs would have to be under development before this date to conduct testing and ensure compliance. Acknowledging that impacted payers will have varying technological and staffing capabilities, as we did in the CMS Interoperability and Patient Access final rule (85 FR 25606), we estimate that the development of the APIs would require 6 to 12 months of work. Expecting that this proposed rule will be finalized by mid-year 2023, we have distributed the cost over approximately two-and-a-half calendar years to give payers the flexibility to complete the necessary work (see Table 19). We request comment on our approach and assumptions for the cost of the Provider Access API, including whether our estimates and ranges are reasonable or should be modified. a. API Maintenance Costs—All Proposed APIs We discuss the costs for the third phase, long-term support and maintenance, and our methodology for the development of those costs in aggregate for all APIs discussed in this VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 proposed rule. As relevant to the APIs discussed in sections V.C.1., 3., 4., and 8., we estimate ongoing maintenance costs for the Provider Access API, PARDD API, and Payer-to-Payer API in aggregate. This approach aligns with the strategy taken in the CMS Interoperability and Patient Access final rule (85 FR 25605), whereby the costs of the API development are split into three phases: initial design, development and testing, and long-term support and maintenance. However, unlike the CMS Interoperability and Patient Access final rule, this proposed rule assumes that maintenance costs only account for the cost associated with the technical requirements as outlined in this rule. Any changes to requirements would require additional burden, which would be discussed in future rulemaking. Throughout the Collection of Information section, we discuss the initial design, development, and testing costs per API. We next discuss the total maintenance cost for all four APIs. As discussed in the CMS Interoperability and Patient Access final rule (85 FR 25606), once the API is established, we believe there would be an annual cost to maintain the FHIR server, including the cost of maintaining PO 00000 Frm 00096 Fmt 4701 Sfmt 4702 the necessary patient data and performing capability and security testing. We believe there are efficiencies gained in implementation and maintenance due to the fact that these proposed APIs rely on several of the same underlying foundational technical specifications and content. For example, the same baseline standards apply, including the HL7 FHIR Release 4.0.1 and complementary security and app registration protocols. Specifically, the HL7 SMART Application Launch Implementation Guide (SMART IG) 1.0.0, including mandatory support for the ‘‘SMART on FHIR’’ Core Capabilities. However, we do believe that maintenance costs would be higher than what we estimated for the CMS Interoperability and Patient Access final rule for the new APIs proposed in this rule, as our estimates also account for new data mapping needs, standards upgrades, additional data storage, system testing, initial bug fixes, 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 demonstrating APIs for provider access, E:\FR\FM\13DEP2.SGM 13DEP2 EP13DE22.014</GPH> *Estimated burden is the total burden of implementation. The burden is apportioned over 30 months in the COi summary table. Annual maintenance costs are 25 percent of total implementation costs. The 30 months represents the lag between the expected publication of the final rule around July 1, 2023, and the effective date on January 1, 2026. *This table contains preparatory computations used for creating Table 19; they are not definitive statements of burden. Table 19 is the official 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. *Note: Table 13 (as other Tables in this Collection of Information Requirements section) reflects a spreadsheet; therefore, minor inconsistencies are due to rounding. Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules prior authorization, and payer to payer data exchange. We estimate an annual cost averaging approximately 25 percent of the primary estimate for one-time API costs. In the Summary Table (Table 19), we account for this maintenance cost separately for each API (at 25 percent of the one-time API cost). As discussed previously, the overlap in recommended IGs across the proposed APIs should result in shared efficiency that we believe supports the assumption that maintenance should be accounted for in aggregate and is presented in this section as such. We request public comment on our approach and assumptions for the aggregate maintenance cost of the APIs, including whether our estimate is reasonable or should be modified. lotter on DSK11XQN23PROD with PROPOSALS2 3. ICRs Regarding the Prior Authorization Requirements, Documentation, and Decision (PARDD) API Proposal (42 CFR 422.122, 431.80, 438.242, 457.732, and 457.1233 and 45 CFR 156.223) We propose new requirements for the implementation of a PARDD API. This API would address several major challenges of the prior authorization process, including identifying whether a prior authorization is required for an item or service; identifying the payer documentation requirements for prior authorization; compiling the necessary data elements to populate the HIPAAcompliant prior authorization transactions; and enabling payers to provide a specific response regarding the status of the prior authorization, including information about the reason for denial. Use of this proposed API would begin on January 1, 2026, for MA and Medicaid and CHIP FFS, for Medicaid managed care plans and CHIP managed care entities by the rating period beginning on or after January 1, 2026, and for QHPs on the FFEs for plan years beginning on or after January 1, 2026. As discussed previously for the Provider Access API, to implement the VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 proposed new requirements for the PARDD API, we estimate that impacted payers would conduct three major work phases: initial design, development and testing, and long-term support and maintenance. Furthermore, for this proposed API, we believe additional tasks are necessary to accomplish the proposed requirements, which we describe below as they affect the cost estimates. For the costs for the third phase—long-term support and maintenance—our methodology for the development of those costs in aggregate for all proposed APIs is presented in section V.C.3. of this proposed rule. We base our estimate on feedback from industry experts on the anticipated burden of implementing the PARDD API. We believe this to be a reasonable estimate of the implementation burden on payers to develop APIs that can facilitate the prior authorization process. In addition to implementing the PARDD API, these payers would be required to send a reason for denial for prior authorization requests that are denied. As discussed in section II.D. of this proposed rule, while the PARDD API would use the HL7 FHIR standard to support its basic capabilities, covered entities must also use the adopted X12 278 standard and remain HIPAAcompliant. Given the added complexity of accounting for the HIPAA standards, we have accounted for the multiple skill sets required and licensing costs for accessing the X12 standards in developing the burden estimates. The recommended HL7 IGs are freely available, as HL7 provides access to all IGs as open-source materials. This also makes the HL7 standards, IGs, many reference implementations, and test scripts available free of charge to the healthcare and developer community. These low- or no-cost HL7 resources support our belief that payers would incur minor costs for implementing the new standards. As such, we have accounted for the necessary engineers, subject matter experts, and health PO 00000 Frm 00097 Fmt 4701 Sfmt 4702 76333 informaticists in our estimates. These personnel resources would, for example, need to convert payers’ prior authorization documentation rules into computable, structured formats, create provider questionnaires regarding whether a patient had a medical necessity for a medical item or service, create formats that could interface with the provider’s EHR or practice management system, create and execute mapping between the HL7 and X12 codes, and integrate the PARDD API with the payer’s system. As noted previously, although this provision would be applicable on January 1, 2026, this API would be under development before that date. Acknowledging that impacted payers would have varying technological and staffing capabilities, we estimate that the development of the API would require 6 to 12 months of work. Expecting that this proposed rule will be finalized by mid-year 2023, we have distributed the cost over approximately two-and-a-half calendar years to give payers the flexibility to complete the necessary work (see Table 19). Table 14 presents total burden estimates for the PARDD API (initial design phase and the development and testing phase). This table presents the calculations associated with the total costs. The numbers from this table are used in the summary table (Table 19) to present costs per year for 3 years. Based on the same assumptions as those included in the CMS Interoperability and Patient Access final rule, we used the medium estimate as the primary estimate. The narrative description provided for Table 13 also applies to Table 14. Both tables estimate API costs for 365 organizations and indicate follow-up annual maintenance costs by analyzing costs for a single payer using a team spanning approximately ten occupational titles. BILLING CODE 4120–01–P E:\FR\FM\13DEP2.SGM 13DEP2 lotter on DSK11XQN23PROD with PROPOSALS2 76334 Jkt 259001 Frm 00098 Fmt 4701 Sfmt 4702 13DEP2 time implementation cost of the PARDD API, including whether our estimates E:\FR\FM\13DEP2.SGM We request public comment on our approach and assumptions for the one- PO 00000 ** This total is based on our estimate of 365 entities between the MA, Medicaid FFS, Medicaid Managed Care, and QHPs on the FFEs. Notes: + Estimated burden is the total burden of implementation. This burden is apportioned over 30 months in the COi summary table. Annual maintenance costs arc 25 percent of total implementation costs. ++ Tables M2 through M8 contain preparatory computations used for creating Table 19; they arc not definitive statements of burden. Table 19 is the official COi statement of burden, including the number of respondents and responses. This is the same format used in the CMS Interoperability and Patient Access final rule. Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules 18:56 Dec 12, 2022 BILLING CODE 4120–01–C VerDate Sep<11>2014 EP13DE22.015</GPH> TABLE 14: TOTAL BURDEN ESTIMATES FOR IMPACTED PAYERS FOR THE PARDD API* Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules and ranges are reasonable or should be modified. 4. ICRs Regarding Proposed Requirements To Send Prior Authorization Decisions Within Certain Timeframes (42 CFR 422.568, 422.570, 422.631, 438.210, 440.230, 457.495, and 457.1230) To increase transparency and reduce burden, we are proposing to require that impacted payers, not including QHP issuers on the FFEs, send prior authorization decisions within 72 hours for urgent requests and 7 calendar days for non-urgent requests. We are proposing that the payers would have to comply with these provisions beginning January 1, 2026 (for Medicaid managed care plans and CHIP managed care entities, by the rating period beginning on or after January 1, 2026). In order to implement this policy, there would be up-front costs for 76335 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 perentity cost of $967. Therefore, the total burden for all 365 impacted payers is 2,920 hours of work at a first-year cost of $0.4 million (rounded). These calculations are summarized in Table 15: TABLE 15: FIRST-YEAR COST TO UPDATE POLICIES AND PROCEDURES REGARDING THE REQUIREMENT TO SEND PRIOR AUTHORIZATION DECISIONS WITHIN CERTAIN TIMEFRAMES *Tables 12 through 18 contain preparatory computations used for creating Table 19; they are not definitive statements of burden. Table 19 is the official COI statement of burden including the number of respondents and responses. This is the same format used in the CMS Interoperability and Patient Access final rule. We request public comment on our assumptions, estimates, and approach. 5. ICRs Regarding the Proposed Requirement for Public Reporting of Prior Authorization Metrics (42 CFR 422.122, 438.210, 440.230, 457.732, and 457.1230 and 45 CFR 156.223) To support transparency for patients to understand prior authorization processes, provide some assistance in choosing health coverage, and for providers when selecting payer networks to join, we are proposing to require that impacted payers publicly report certain plan-level prior authorization metrics on their websites or via a publicly accessible hyperlink(s). Impacted payers would be required to report aggregated data annually for the previous calendar year’s data, beginning March 31, 2026. We estimate that impacted payers would conduct two major work phases: implementation, which includes defining requirements and system design (and updates) to generate and compile reports; and maintenance, including an annual compilation of reports and public reporting of metrics on a website or through a publicly accessible hyperlink(s). In the first phase, we believe impacted payers would need to define requirements concerning the types and sources of data that would need to be compiled regarding prior authorization activities and data, build the capability for a system to generate reports, and update or create a public web page to post the data. In the second phase, we believe impacted payers would need to create the reports and post them to a public web page annually. Table 16 discusses the activities, hours, and dollar burdens for the firstyear implementation and estimated annual maintenance costs. We assume a team of two staff consisting of a software and web developer with a business operations specialist. • First-year implementation would impose a burden of 320 hours for the first year and 120 hours for subsequent years, at the cost of $30,000 and $9,000 (rounded), for the first and subsequent years, respectively. • The aggregate burden of the firstyear implementation across 365 impacted payers would be 117,000 hours and 44,000 hours (rounded) for the first and subsequent years, respectively, at a cost of $10.8 million and $3.3 million (rounded) for the first and subsequent years. *This table contains preparatory computations used for creating Table 19; they are not definitive statements of burden. Table 19 is the official 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. VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 PO 00000 Frm 00099 Fmt 4701 Sfmt 4725 E:\FR\FM\13DEP2.SGM 13DEP2 EP13DE22.017</GPH> 0 120 120 43 800 EP13DE22.016</GPH> lotter on DSK11XQN23PROD with PROPOSALS2 TABLE 16: AGGREGATE BURDEN FOR COMPLYING WITH PUBLIC REPORTING OF PRIOR AUTHORIZATION METRICS 76336 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules We request public comment on this approach and our assumptions. 6. ICRs Regarding the Payer-to-Payer API Proposal (42 CFR 422.121, 431.61, 438.242, 42 CFR 457.731, and 457.1233 and 45 CFR 156.222) To improve patient access to their health information through care coordination between health plans, as discussed in section II.C. of this proposed rule, we propose new requirements for impacted payers to implement and maintain a Payer-toPayer API. These proposals would improve care coordination among payers by requiring payers to exchange, at a minimum, adjudicated claims and encounter data (excluding provider remittances and enrollee cost-sharing information), all data classes and data elements included in a content standard at 45 CFR 170.213, and pending and active prior authorization decisions. This exchange would be done using an HL7 FHIR Payer-to-Payer API implemented by January 1, 2026 (for Medicaid managed care plans and CHIP managed care entities, by the rating period beginning on or after January 1, 2026, and for QHPs on the FFEs for plan years beginning on or after January 1, 2026). For a complete discussion of the data types proposed to be exchanged, please refer to section II.C. of this proposed rule. As discussed for the other APIs proposed in this rule, we estimate that impacted payers would conduct three major work phases: initial design, development and testing, and long-term support and maintenance. For the Payer-to-Payer API, we believe there may be additional tasks necessary to accomplish the proposed requirements, which we describe below with respect to their impact on cost estimates. The costs for the third phase, long-term support and maintenance, and our methodology for the development of those costs in aggregate for all proposed APIs are presented in section IV.C.3. of this proposed rule. Payers should be able to leverage the API infrastructure already accounted for in the Patient Access API finalized in the CMS Interoperability and Patient Access final rule and the Provider Access API proposal in this rule. As discussed in the CMS Interoperability and Patient Access final rule (as well as the companion 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program final rule (85 FR 25642)) and this proposed rule, payers would be using the HL7 FHIR standards for content and transport, recommended IGs to support interoperability of data sharing, as well as the same underlying standards for security, authentication, and authorization. Taken together, these standards would support the proposed Payer-to-Payer API. Thus, we believe there would be some reduced development costs to implement the Payer-to-Payer API because of efficiencies gained in implementing the same underlying standards and IGs for the other APIs proposed in this rule. We believe there would be some costs for impacted payers to implement the proposed Payer-to-Payer API that are unique to this API. Based on input from current industry experience testing the implementation of this API, there could be costs to test and integrate the Payerto-Payer API with payer systems, albeit potentially lower costs than those estimated for the Provider Access API. We estimate the one-time implementation costs at about one-third the cost of a full de novo Provider Access API implementation based on input from developers who have implemented and piloted prototype APIs using the proposed required standards. As such, we have accounted for the necessary skill sets of staff required as we also believe there would be unique costs for implementing the HL7 FHIR Payer Coverage Decision Exchange (PDex) IG so that payers can exchange active and pending prior authorization decisions and related clinical documentation and forms when an enrollee or beneficiary enrolls with a new impacted payer. Table 17 presents the total activities, hours, and dollar burdens for implementing the Payer-to-Payer API given our assumptions (initial design phase and the development and testing phase). Based on the same assumptions as those published in the CMS Interoperability and Patient Access final rule, we have the medium estimate as the primary estimate. We have included a similar narrative explanation of Table 17 as that provided for Table 13 above. • For the primary estimate, one-time implementation efforts for the first two phases would require, on average, a total of 916 hours per organization at an average cost of $96,072 per organization. • The aggregate burden of the onetime implementation costs across 365 impacted payers would be 334,000 hours (rounded) at the cost of $35.1 million (rounded). This corresponds to the primary estimate; the primary and high estimates are obtained by multiplying the low estimate by factors of two and three, respectively. TABLE 17: TOTAL BURDEN ESTIMATES FOR THE PAYER-TO-PAYERAPI* $5 803 $4162 $43,874 $48,036.20 17,533,213 $11 606 $8 325 $87,748 $96,072 35,066,426 $17410 $12 487 $131,621 $144,109 52,599,639 *Estimated burden is the total burden of implementation; this burden is apportioned over 30 months in the COi summary table. Annual maintenance costs are 25 percent of total implementation costs. *This table contains preparatory computations used for creating Table 19; they are not definitive statements of burden. Table 19 is the official COi statement of burden including the number of respondents and responses. This is the same format used in the CMS Interoperability and Patient Access final rule. As noted previously, although this provision would be applicable on January 1, 2026, we believe the APIs VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 would be under development before that date. Acknowledging that impacted payers would have varying PO 00000 Frm 00100 Fmt 4701 Sfmt 4702 technological and staffing capabilities, we estimate that development of the APIs would require 6 to 12 months of E:\FR\FM\13DEP2.SGM 13DEP2 EP13DE22.018</GPH> lotter on DSK11XQN23PROD with PROPOSALS2 96 86 830 916 334,340 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules work. Expecting that this proposed rule will be finalized by mid-year 2023, we have distributed the cost estimates over approximately two-and-a-half calendar years to give impacted payers the flexibility to complete the work (see Table 19). We request public comment on our approach and assumptions for the cost of the Payer-to-Payer API, including whether our estimates and ranges are reasonable or should be modified. 7. ICRs Regarding the Electronic Prior Authorization Measure for QPP MIPS and the Medicare Promoting Interoperability Program The estimates in this section have been submitted to OMB in a PRA package (OMB control number 0938– 1278). As explained in section II.E. of this proposed rule, commenters to the December 2020 CMS Interoperability proposed rule (85 FR 82586) expressed support for requiring healthcare providers to use electronic prior authorization as part of the QPP MIPS for MIPS eligible clinicians, or the Conditions of Participation/Conditions for Coverage requirements for eligible hospitals, and other providers and suppliers. Commenters indicated these would be appropriate levers by which CMS should propose new or additional provisions that would require the use of APIs to enable enhanced electronic documentation discovery and facilitate electronic prior authorization. To incentivize MIPS eligible clinicians, eligible hospitals, and CAHs to implement and use electronic prior authorization and the corresponding API, we are proposing in section II.E. of this proposed rule to add a new measure titled ‘‘Electronic Prior Authorization’’ for MIPS eligible clinicians under the MIPS Promoting Interoperability performance category and for eligible hospitals and CAHs under the Medicare Promoting Interoperability Program beginning with the performance period/ EHR reporting period in CY 2026. We are proposing that MIPS eligible clinicians, eligible hospitals, and CAHs must report the Electronic Prior Authorization measure beginning with the CY 2026 performance period/EHR reporting period, but the measure would not be scored for CY 2026. For this measure, we propose that a MIPS eligible clinician, eligible hospital, or CAH must request a prior authorization electronically from a PARDD API using data from CEHRT and report a numerator and denominator or claim an exclusion if applicable. The burden in implementing these proposed requirements consists of the following steps: creating or implementing software to capture the data, capturing the data, and reporting the measure as specified by CMS. Beyond implementation, the burden lies in maintaining compliance of the system to support all functionality, including the ability to generate accurate and timely reports. We assume the annual maintenance cost would include updates to the software to meet new reporting requirements for the QPP MIPS Promoting Interoperability performance category and the Medicare Promoting Interoperability Program on behalf of participating MIPS eligible clinicians, eligible hospitals, and CAHs. Such an update would include the ability to report the electronic prior authorization measure as required by CMS. System maintenance is an 76337 umbrella term that includes all activities needed to keep a system running. The two main components of system maintenance are preventive and corrective maintenance, which include software tasks such as fixing bugs, updating data sources, deleting old software tasks, and adding new tasks. Maintenance requirements for systems both in this proposed rule and in the December 2020 CMS Interoperability proposed rule were estimated at 25 percent of total software creation costs, reflecting updates and bug fixes, as well as deletion and creation of software tasks (85 FR 82649). Therefore, although we anticipate there would be a moderate software update to implement the provisions of this proposed rule, there would be no added burden over and above the burden of maintaining already existing software. The data for the reports on prior authorizations and related claims should already be stored in the system software of healthcare providers who may be required to retain such data for compliance and regulatory reasons. To report the measure as specified by CMS, the actual added burden that the proposals in this proposed rule would impose is the burden of extracting data and preparing it in report form. For the added burden of extracting, compiling, reviewing, and submitting data, we assume that for each report, a Medical Records Specialist would spend half a minute extracting the already-existing data at a cost of $0.39 (1⁄2 minute × $46.42 per hour). Then, to obtain the aggregate burden, we multiply by the number of entities. This is done separately for eligible hospitals and CAHs, and MIPS eligible clinicians in Table 18. TABLE 18: AGGREGATE ESTIMATES FOR THE ELECTRONIC PRIOR AUTHORIZATION MEASURE Number of entities Hourly burden per entity 4,500 1/120 hr. (1/2 a minute) $2.50/ ear $46.42 $1,741 $0.002 million *The table estimates reflect mean honrly wages for a medical records specialist for the Medicare Promoting Interoperability Program and MIPS. Had median honrly wage been nsed in the calcnlation, as fonnd in the FY 2023 IPPS/LTCH PPS final rule (87 FR 49393), the estimates wonld be $1,682 and $20,474, respectively, for eligible hospitals, CAHs, and MIPS eligible clinicians. In either case, the snmmary table (19) will record this as $0.0 million consistent with regnlatory impact analysis (RIA) acconnting rules. The following items provide support and rationale for the entries in Table 18: VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 • The hourly burden estimates of 1⁄2 minute (1/120 = 0.00833 hour) for transmission of the measure to CMS are PO 00000 Frm 00101 Fmt 4701 Sfmt 4702 consistent with the revised estimates of burden presented in the FY 2023 IPPS/ LTCH PPS final rule (87 FR 49396). The E:\FR\FM\13DEP2.SGM 13DEP2 EP13DE22.019</GPH> lotter on DSK11XQN23PROD with PROPOSALS2 A 54,770 1/120 hr. (1/2 a minute) $2.50/ ear $46.42 $21,186 $0.021 million 76338 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules lotter on DSK11XQN23PROD with PROPOSALS2 hourly burden estimates for the Electronic Prior Authorization measure are based on the collection of burden estimates calculated for the Query of Prescription Drug Monitoring Program measure. • The estimate of 4,500 hospitals (including eligible hospitals and CAHs) is consistent with the revised estimates presented in the FY 2023 IPPS/LTCH PPS final rule (87 FR 49393). • The existing QPP MIPS reporting policies allow MIPS eligible clinicians to report at the individual or group level. Based on the information available from Table 122 in the CY 2023 PFS final rule (87 FR 69404, 70154), we estimate 54,770 individual or group MIPS eligible clinicians would submit data for the Promoting Interoperability performance category for the CY 2026 performance period/CY 2028 MIPS payment year. The 54,770 is the sum of the 43,117 individual clinicians expected to submit performance data to QPP MIPS, plus the 11,633 groups expected to submit performance data to QPP MIPS, plus 20 subgroups. The information collection requirements currently approved under OMB control number 0938–1314 are approved through January 31, 2025. The FY 2023 IPPS/LTCH PPS final rule uses median hourly wages (87 FR 49393), whereas this proposed rule and the CMS Interoperability and Patient Access final rule (85 FR 25605) use mean hourly wages. For purposes of illustration, we have provided both estimates. For eligible hospitals and CAHs the total cost is $1,740 (4,500 hospitals and CAHs × 1⁄2 minute × $46.20 per hour), which equals 0.002 million as listed in Table 19. This rounds to $0.0 million. Calculations using the median instead of the average are similar. This shows that the bottom-line rounded figure would not change if we used the median instead of the average. However, the entries in the COI Summary Table (M9) are $0.0 million consistent with VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 rounding accounting, and the actual numbers are provided in the table. The costs of this provision 5 years after the finalization of the rule are provided in the Summary Table, M9. For MIPS eligible clinicians, the total cost is $21,186 (54,770 clinicians × 1⁄2 minute × $46.20 per hour). Since this summary table, M9, feeds into the RIA summary table, we expressed this $21,186 using RIA accounting standards, which require rounding to the nearest tenth of a million. It follows that $21,186 is equivalent to $0.021 million, as listed in Table 19. This would round to $0.0. D. Summary of Information Collection Burdens The previous sections have explained the costs of individual provisions in the proposed rule. Table 19 summarizes costs for the first and subsequent years of these provisions and is based on the following assumptions: • A publication date of mid-year 2023 for the final rule. • The effective date for all provisions is January 1, 2026. For the Electronic Prior Authorization measure, this would be required for the QPP MIPS Promoting Interoperability performance category beginning with the 2026 performance period for MIPS eligible clinicians and the Medicare Promoting Interoperability Program starting with the 2026 EHR reporting period for eligible hospitals and CAHs. Accordingly, the COI summary Table 19 reflects costs beginning in 2027, which is year 5 relative to mid-year 2023, the expected publication date of this proposed rule. The table below summarizes the total information burden for all reporting requirements, APIs, and the reporting required under the QPP MIPS Promoting Interoperability performance category and the Medicare Promoting Interoperability Program. The last line of the table is the total cost for all impacted payers and providers, the estimated burden, and the costs per PO 00000 Frm 00102 Fmt 4701 Sfmt 4702 year. The text below offers highlights from our analysis. • For the three new APIs (Provider Access, Prior Authorization Requirements, Documents, and Decisions (PARDD), and Payer-toPayer), we assume implementation would take place uniformly over 30 months (the time from the expected publication date (mid-year 2023) for the final rule until the applicable compliance date in 2026). • Maintenance costs for the three APIs are, as indicated in the tables of this section, assumed to be 25 percent of total costs; we believe these maintenance costs would be incurred in years 2026 and beyond. • For provisions requiring policy updates or first-year implementation costs, we believe it is most reasonable that these first-year costs would take place in 2026, the first year the rule is in effect, and that subsequent year implementation costs, as reflected in the various tables in this section, would take place in years 2027 and beyond. • Since the Electronic Prior Authorization measure would not be applicable until 2026, no costs are reflected from 2023 through 2025. • Since the targeted publication date of this final rule is mid-year 2023, we treat 2023 as a half-year. For purposes of allocating software development costs, 2023 is therefore one-half the costs expected to be incurred during 2024 and 2025. • Labor costs in Table 19 are either BLS wages when a single staff member is involved or a weighted average representing a team effort, which is obtained by dividing the aggregate cost by the aggregate hours. For example, in the first row, $94.32 equals the aggregate $5.5 million cost divided by the aggregate 58,400 hours. We also note that Table 19 reflects the primary estimate. The full range of estimates for all provisions is presented in the RIA section of this proposed rule. BILLING CODE 4120–01–P E:\FR\FM\13DEP2.SGM 13DEP2 lotter on DSK11XQN23PROD with PROPOSALS2 Jkt 259001 PO 00000 Frm 00103 Fmt 4701 Sfmt 4702 PARDD API, Maintenance Update Policies for Communicating Denials for Prior Authorization and Timeframes for Prior Authorization Decisions Public Reporting of Prior Authorization Metrics, 1st Year Public Reporting of Prior Authorization Metrics, subsequent ears Paver-to-Paver API, Development Payer-to-Payer API, Maintenance Reporting for QPP MIPS, MIPS eligible clinicians E:\FR\FM\13DEP2.SGM Reporting for Medicare Promoting Interoperability Program, Eligible Hospitals, and CAHs Total combined cost by year in millions to all 365 Organizations (Payers), all 54,770 MIPS eligible clinicians, and all 4,500 eligible hospitals and CAHs. 365 365 365 365 2,800 700 10,880 2,720 (4) 365 5 365 320 (5) 365 120 365 365 54,770 916 229 6 6 ~120.90 0.0083 $19.7 $39.4 $39.4 $83.5 $167.1 $167.1 13DEP2 CFR 422.119, CFR 422.121, CFR 422.122, CFR 422.566, CFR 422.122, CFR 422.121, $24.6 $104.4 $104.4 2,920 $0.4 $92.42 116,800 $10.8 $75.32 43,800 $104.88 $104.88 334,340 83,585 $46.42 456 $0.021 I $46.42 37 $0.002 Varies 6,896,438 $7.0 I $14.0 I $14.0 $3.3 I $8.8 $8.8 4,500 56,532 o.0083 110 221 221 * Number of responses per respondent is uniformly 1 and therefore omitted. NOTES: (1) 42 (2) 42 (3) 42 (4) 42 (5) 42 (6) 42 $24.6 431.60, 438.242, 457.730, and 457.1233 and 45 CFR 156.221. 431.61, 438.242, 457.731, and 457.1233 and 45 CFR 156.222. 431.80, 438.242, 457.732, 457.1233, 422.122, 431.80, 438.242, 457.732, and 457.1233 and 45 CFR 156.223. 422.568, 422.570, 422.631, 438.210, 440.230, 457.495, and 457.1230. 438.210, 440.230, 457.732, and 457.1233 and 45 CFR 156.223. 431.61, 438.242, 457.731, and 457.1233 and 45 CFR 156.22. 155 142 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules 18:56 Dec 12, 2022 BILLING CODE 4120–01–C VerDate Sep<11>2014 TABLE 19: SUMMARY OF ANNUAL INFORMATION BURDEN* 76339 EP13DE22.020</GPH> 76340 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules E. Conclusion The provisions of this proposed rule could improve data sharing across stakeholders by facilitating access, receipt, and exchange of patient data. We are committed to providing patients, providers, and payers with timely access to patient health information. We request comment on our approaches for estimating cost burden and cost savings. The requirements of this proposed rule are extensions of the requirements of the CMS Interoperability and Patient Access final rule (85 FR 22510). Therefore, the information collection requirements will be submitted to OMB for review and approval. If you would like to provide feedback on these information collections, please submit your comments electronically as specified in the ADDRESSES section of this proposed rule. Comments must be received on/by March 13, 2023. lotter on DSK11XQN23PROD with PROPOSALS2 V. Regulatory Impact Analysis A. Statement of Need As described in prior sections of this proposed rule, the proposed changes to 42 CFR parts 422, 431, 435, 438, 440, and 457 and 45 CFR part 156 further support CMS’ efforts to empower patients by increasing electronic access to healthcare data, while keeping that information safe and secure. The proposals in this rule build on the foundation we laid out in the CMS Interoperability and Patient Access final rule to move the healthcare system toward increased interoperability by proposing to increase the data sharing capabilities of impacted payers, encourage healthcare providers’ use of new capabilities, and make healthrelated data more easily available to patients through standards-based technology. If finalized, the proposals in this rule would place new requirements on MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to improve the electronic exchange of health-related data and streamline prior authorization processes. And these proposals could improve health information exchange and facilitate appropriate and necessary patient, provider, and payer access to health information via APIs. Our proposals related to prior authorization are also intended to improve certain administrative processes. The proposed rule would also add a new measure for eligible hospitals and CAHs under the Medicare Promoting Interoperability Program and for MIPS eligible clinicians under the QPP MIPS Promoting Interoperability performance category. VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 B. Overall Impact We have examined the impacts of this proposed rule as required by Executive Order 12866 on Regulatory Planning and Review (September 30, 1993), Executive Order 13563 on Improving Regulation and Regulatory Review (January 18, 2011), the Regulatory Flexibility Act (RFA) (September 19, 1980, Pub. L. 96–354), section 1102(b) of the Act, section 202 of the Unfunded Mandates Reform Act of 1995 (March 22, 1995, Pub. L. 104–4), and Executive Order 13132 on Federalism (August 4, 1999). Executive Orders 12866 and 13563 direct agencies to assess all costs and benefits of available regulatory alternatives and, if regulation is necessary, to select regulatory approaches that maximize net benefits (including potential economic, environmental, public health, and safety effects, distributive impacts, and equity). Section 3(f) of Executive Order 12866 defines a ‘‘significant regulatory action’’ as an action that is likely to result in a rule: (1) having an annual effect on the economy of $100 million or more in any 1 year, or adversely and materially affecting a sector of the economy, productivity, competition, jobs, the environment, public health or safety, or state, local, or tribal governments or communities (also referred to as ‘‘economically significant’’); (2) creating a serious inconsistency or otherwise interfering with an action taken or planned by another agency; (3) materially altering the budgetary impacts of entitlement grants, user fees, or loan programs or the rights and obligations of recipients thereof; or (4) raising novel legal or policy issues arising out of legal mandates, the President’s priorities, or the principles set forth in the Executive order. A Regulatory Impact Analysis must be prepared for major rules with economically significant effects ($100 million or more in any 1 year). Based on our estimates, OMB’s Office of Information and Regulatory Affairs has determined this rulemaking is ‘‘economically significant’’ as measured by the $100 million threshold. Accordingly, we have prepared a Regulatory Impact Analysis that, to the best of our ability, presents the costs and benefits of this proposed rulemaking. As noted later in this section, we believe that our proposed policies, if finalized, would result in some financial burdens for impacted payers and providers as discussed in section IV. of this proposed rule. We have weighed PO 00000 Frm 00104 Fmt 4701 Sfmt 4702 these potential burdens against the potential benefits, and believe the potential benefits outweigh any potential costs. Based on our estimates, the total burden across all providers would be reduced by at least 206 million hours over 10 years, resulting in a total cost savings over 10 years of approximately $15 billion (see Table 24). However, for reasons discussed later in this proposed rule, these savings are neither included in the 10-year Summary Table (N8), nor in the Monetized Table (N10). C. Regulatory Flexibility Act Executive Order 13272 requires that HHS thoroughly review rules to assess and take appropriate account of their potential impact on small businesses, small governmental jurisdictions, and small organizations (as mandated by the Regulatory Flexibility Act (RFA)). If a proposed rule may have a significant economic impact on a substantial number of small entities, then the proposed rule must discuss steps taken, including alternatives considered, to minimize the burden on small entities. The RFA does not define the terms ‘‘significant economic impact’’ or ‘‘substantial number.’’ The Small Business Administration (SBA) advises that this absence of statutory specificity allows what is ‘‘significant’’ or ‘‘substantial’’ to vary, depending on the problem that is to be addressed in rulemaking, the rule’s requirements, and the preliminary assessment of the rule’s impact. Nevertheless, HHS typically considers a ‘‘significant’’ impact to be 3 to 5 percent or more of the affected entities’ costs or revenues. For purposes of the RFA, we estimate that many impacted payers and providers are small entities, as that term is used in the RFA, either by being nonprofit organizations or by meeting the SBA definition of a small business. For purposes of the RFA, small entities include small businesses, nonprofit organizations, and small governmental jurisdictions. The North American Industry Classification System (NAICS) is used in the U.S., Canada, and Mexico to classify businesses by industry. While there is no distinction between small and large businesses among the NAICS categories, the SBA develops size standards for each NAICS category.172 Note that the most recent update to the NAICS codes went into effect for the 172 U.S. Census Bureau (2021, December 16). 2017 North American Industry Classification System (NAICS) Manual. Census.gov. Retrieved from https://www.census.gov/library/publications/2017/ econ/2017-naics-manual.html. E:\FR\FM\13DEP2.SGM 13DEP2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules lotter on DSK11XQN23PROD with PROPOSALS2 2017 reference year; the most recent size standards were adopted in 2022. In analyzing the impact of this proposed rule, we take note that there would be a quantifiable impact for the following stakeholders. 1. Payers Updates to systems implementing the various APIs described throughout the preamble, including any reporting requirements, would be performed by the 365 payer organizations. Throughout this section of the proposed rule, we also use the term parent organizations to refer to the impacted payers, as we did in the CMS Interoperability and Patient Access final rule (85 FR 25510), which includes the state Medicaid and CHIP agencies. The combined parent organizations administer MA, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs. The NAICS category relevant to these proposed provisions is Direct Health and Medical Insurance Carriers, NAICS 524114, which have a $41.5 million threshold for ‘‘small size.’’ Seventy-five percent of payers in this category have under 500 employees, thereby meeting the definition of small businesses. If the proposals in this rule are finalized, the 365 parent organizations, including state Medicaid and CHIP agencies, would be responsible for implementing and maintaining three new APIs, updating policies and procedures regarding timeframes for making prior authorization decisions, and reporting certain metrics either to CMS or making information available to the public. MA organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs are classified as NAICS code 524114, direct health insurance carriers. We are assuming that a significant number of these entities are not small. We note that none of the state Medicaid and CHIP agencies are considered small. MA organizations and state Medicaid managed care plans and CHIP managed care entities have many of their costs covered through capitation payments from the Federal Government to MA organizations or through state payments. Based on this discussion, there is no significant burden. If finalized as proposed, some QHP issuers on the FFEs would be able to apply for an exception to these requirements, and certain states operating Medicaid and CHIP FFS programs would be able to apply for an extension or exemption, under which they would not be required to meet the VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 new API provisions of the proposed rule on the proposed compliance dates, provided certain conditions are met, as discussed in sections II.B., II.C., and II.D. of this proposed rule. We acknowledge that providing additional information for the annual APD submissions and existing reports would require effort, but we do not believe there would be significant burden to these entities from the proposals in this proposed rule if an extension or exemption is approved. a. Medicare Advantage Each year, MA organizations submit a bid for furnishing Part A and B benefits and the entire bid amount is paid by the Government to each plan if the plan’s bid is below an administratively set benchmark. If a plan’s bid exceeds that benchmark, the beneficiary pays the difference in the form of a basic premium (note that a small percentage of plans bid above the benchmark, whereby enrollees pay a basic premium in addition to their Part B premium; this percentage of plans is not ‘‘significant’’ as defined by the RFA and is explained later in this proposed rule). MA plans with prescription drug coverage (MA–PDs) can also offer supplemental benefits, that is, benefits not covered under Original Medicare (or under Part D). These supplemental benefits are paid for through enrollee premiums, extra Government payments, or a combination of enrollee premiums and extra Government payments. Under the statutory payment formula, if the bid submitted by an MA plan for furnishing Part A and B benefits is lower than the administratively set benchmark, the Government pays a portion of the difference to the plan in the form of a ‘‘beneficiary rebate.’’ The rebate must be used to provide supplemental benefits (that is, benefits not covered under Original Medicare) and/or lower beneficiary Part B or Part D premiums. Some examples of these supplemental benefits include vision, dental, hearing, fitness, and worldwide coverage of emergency and urgently needed services. To the extent that the Government’s payments to plans for the bid plus the rebate exceeds costs in Original Medicare, those additional payments put upward pressure on the Part B premium, which is paid by all Medicare beneficiaries, including those in Original Medicare who do not have the supplemental enhanced coverage available in many MA plans. Part D plans, including MA–PD plans, submit bids and those amounts are paid to plans through a combination of PO 00000 Frm 00105 Fmt 4701 Sfmt 4702 76341 Medicare funds and beneficiary premiums. In addition, for certain enrolled low-income beneficiaries, Part D plans receive Government funds to cover most premium and cost-sharing amounts that those beneficiaries would otherwise pay. Thus, the cost of providing services by these payers is funded by a variety of Government funding and in some cases by enrollee premiums. As a result, MA and Part D plans are not expected to incur burden or losses since the private companies’ costs are being supported by the Government and enrolled beneficiaries. This lack of expected burden applies to both large and small health plans. Small entities that must comply with MA regulations, such as those in this proposed rule, are expected to include the costs of compliance in their bids, thus avoiding additional burden, since the cost of complying with any final rule is funded by payments from the Government and, if applicable, enrollee premiums. For Direct Health and Medical Insurance Carriers, NAICS 524114, MA organizations estimate their costs for the upcoming year and submit bids and proposed plan benefit packages. Upon approval, the plan commits to providing the proposed benefits, and CMS commits to paying the plan either the full amount of the bid, if the bid is below the benchmark, which is a ceiling on bid payments annually calculated from Original Medicare data; or the benchmark, if the bid amount is greater than the benchmark. Thus, there is a cost to plans to bid above the benchmark that is not funded by Government payments. Additionally, if an MA organization bids above the benchmark for any of its plans, section 1854 of the Act requires the MA organization to charge enrollees a premium for that amount. Table 20 reports the percentage of MA organizations bidding above the benchmark, along with the percentage of affected enrollees in recent years. This table reports aggregates of proprietary bid data collected by the Office of the Actuary. The CMS threshold for what constitutes a substantial number of small entities for purposes of the RFA is 3 to 5 percent. As shown in Table 20, both the percentage of plans and the percentage of affected enrollees are decreasing, and below this 3 to 5 percent threshold. Consequently, we conclude that the number of plans bidding above the benchmark is not substantial for purposes of the RFA. E:\FR\FM\13DEP2.SGM 13DEP2 76342 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules TABLE 20: PERCENTAGE OF PLANS BIDDING ABOVE BENCHMARK BY YEAR Number of Unique Bid IDs that Bid Above the Benchmark Projected Enrollment in Plans that Bid Above the Benchmark (Member Months) Number of Unique Bid IDs 2020 100 2,108,026 4,270 231,754,722 2.3% 0.9% 2021 66 1,167,779 4,837 259,609,169 1.4% 0.4% 2022 30 328,621 5,298 288,151,395 0.6% 0.1% The preceding analysis shows that meeting the direct costs of this proposed rule does not have a significant economic impact on a substantial number of small entities as required by the RFA. There are certain indirect consequences of these provisions, which also would have an economic impact. We have explained that at least 98 percent of MA organizations bid below the benchmark. Thus, their estimated costs for providing services to Medicare beneficiaries for the coming year are fully paid by the Federal Government. However, the Government additionally pays the plan a ‘‘beneficiary rebate’’ amount that is an amount equal to a percentage (between 50 and 70 percent, depending on a plan’s quality rating) multiplied by the amount by which the benchmark exceeds the bid. The rebate is used to provide additional benefits to enrollees in the form of reduced cost-sharing or other supplemental benefits, or to lower the Part B or Part D premiums for enrollees (supplemental benefits may also partially be paid by enrollee premiums). It would follow that if the provisions of this proposed rule cause the MA organization’s bids to increase and if the benchmark remains unchanged or increases by less than the bid does, the result would be a reduced rebate and, possibly fewer supplemental benefits, or higher premiums for the health plans’ enrollees. However, as noted previously, the number of plans bidding above the benchmark to whom this burden applies, do not meet the RFA criteria of a significant number of plans. It is possible that if the provisions of this proposed rule would otherwise cause bids to increase, MA organizations would reduce their profit margins, rather than substantially change their benefit packages. This may be in part due to market forces; a plan lowering supplemental benefits even for VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 Projected Enrollment (Member Months) 1 year may lose enrollees to competing plans that offer these supplemental benefits. Thus, it can be advantageous to the plan to temporarily reduce profit margins, rather than reduce supplemental benefits. The temporary claim refers to the possibility that plans will balance competitive pressures with profit targets immediately following a new regulation. As the regulations are typically finalized within a few months of the bid submission deadline, plans may have more time to enact strategies that don’t require large benefit changes in subsequent years, such as negotiations for supplemental benefit offerings. However, it may be inappropriate to consider the relevant regulatory impacts (and thus the profit considerations) as temporary because the issuance of a series of regulations sustains the effects.173 As a result, changes in benefits packages may be plausible and we request comment on the assessment of this outcome in association with this proposed rule. Based on the previously discussed considerations, the Secretary has certified that this proposed rule will not have a significant impact on a substantial number of small entities. b. Medicaid and CHIP Title XIX of the Act established the Medicaid program as a Federal-state partnership for the purpose of providing and financing medical assistance to specified groups of eligible individuals. States claim Federal matching funds on a quarterly basis based on their program expenditures. Since states are not small entities under the Regulatory Flexibility 173 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). 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). https:// www.federalregister.gov/d/2022-07642. PO 00000 Frm 00106 Fmt 4701 Sfmt 4702 Bid ID Percentage Enrollment Percentage Act, we need not discuss, in the Initial Regulatory Flexibility Analysis, the burden imposed on them by this proposed rule. With regard to Medicaid managed care plans and CHIP managed care entities, since managed care plans receive 100 percent capitation from the state, we generally expect that the costs associated with the provisions of this proposed rule would be included in their capitation rates and may be reasonable, appropriate, and attainable costs irrespective of whether they are a small business. Consequently, we can assert that there would be no significant impact on a significant number of these entities. As discussed in sections II.B., II.C., and II.D. for the proposed API provisions, states operating Medicaid FFS and CHIP FFS programs could apply for an extension of 1 year to come into compliance with the requirements of this proposed rule. These same organizations may also apply for an exemption from the requirements if certain conditions are met. c. QHP Issuers on the FFEs Few, if any, QHP issuers on the FFEs are small enough to fall below the size thresholds for a small business established by the SBA. Consistent with previous CMS analysis, we estimate that any issuers that would be considered small businesses are likely to be subsidiaries of larger issuers that are not small businesses (78 FR 33238) and thus do not share the same burdens as an independent small business. Therefore, even though QHP issuers do not receive Federal reimbursement for the costs of providing care, we do not conclude that there would be a significant small entity burden for these issuers. In addition, we propose an exception process be available for QHPs on the FFEs, which further helps to address burden that could otherwise prohibit a QHP issuer from participating in an FFE. E:\FR\FM\13DEP2.SGM 13DEP2 EP13DE22.021</GPH> lotter on DSK11XQN23PROD with PROPOSALS2 Year Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules 2. Providers In response to public comments on the December 2020 CMS Interoperability proposed rule (85 FR 82586), CMS is proposing a new Electronic Prior Authorization measure for MIPS eligible clinicians under the QPP MIPS Promoting Interoperability performance category, and for eligible hospitals and CAHs under the Medicare Promoting Interoperability Program. The measure would be required for reporting beginning in CY 2026. With regard to MIPS eligible clinicians, eligible hospitals, and CAHs, a discussion of the burden placed on these entities were presented in section IV.C.8, Table 18. That table shows that the burden per individual provider is under $2.50 per year (one half-minute of labor times an hourly wage of under $50, depending on whether one uses a mean or median). Consequently, the Secretary asserts that the provisions of this proposed rule do not represent a significant burden on providers. Based on the information provided previously, we conclude that the requirements of the RFA have been met by this proposed rule. lotter on DSK11XQN23PROD with PROPOSALS2 D. UMRA and E.O. 13132 Requirements Section 202 of the Unfunded Mandates Reform Act of 1995 (UMRA) also requires that agencies assess anticipated costs and benefits before issuing any rule whose mandates require spending in any 1 year of $100 million in 1995 dollars, updated annually for inflation. In 2022, that threshold is approximately $165 million. This proposed rule would not impose an unfunded mandate that would result in the expenditure by state, local, and tribal governments, in the aggregate, or by the private sector, of more than $165 million in any 1 year. Executive Order 13132 establishes certain requirements that an agency must meet when it promulgates a proposed rule (and subsequent final rule) that imposes substantial direct costs on state and local governments, preempts state law, or otherwise has federalism implications. As previously outlined, while the API provisions would be a requirement for state Medicaid and CHIP agencies under these proposals, the cost per beneficiary VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 for implementation is expected to be negligible when compared with the overall cost per beneficiary. This analysis does not consider Federal matching funds provided to state Medicaid and CHIP agencies, but the conclusion is the same: there is not expected to be a significant cost impact on state entities. For Medicaid and CHIP, we do not believe that the proposals in this rule would conflict with state law, and therefore, do not anticipate any preemption of state law. As discussed in section II.D. of this proposed rule, some state laws regarding timeframes for prior authorization decisions may be different than the proposals in this proposed rule. However, an impacted payer would be able to comply with both state and Federal requirements by complying with whichever imposes the shorter timeframe. We invite states to comment on this proposed rule if they believe any proposal in this rule would conflict with state law. E. Regulatory Review Costs If regulations impose administrative costs on private entities, such as the time needed to read and interpret this proposed rule, we should estimate the cost associated with regulatory review. We model our estimates of this burden based on similar estimates presented in the CMS Interoperability and Patient Access final rule (85 FR 25510). There are three numbers needed to calculate this estimate: 1. Number of Staff per Entity Performing the Reading The staff involved in such a review would vary from one parent organization to another. We believe that a good approximation for a range of staff would be a person such as a medical and health service manager or a lawyer. Using the wage information from the BLS for medical and health services managers (Code 11–9111) and lawyers (Code 23–1011) we estimate that the cost of reviewing this proposed rule is $128.71 per hour, including overhead and fringe benefits.174 This number was 174 U.S. Bureau of Labor Statistics (2022, March 31). National Occupational Employment and Wage Estimates. Retrieved from https://www.bls.gov/oes/ current/oes_nat.htm. PO 00000 Frm 00107 Fmt 4701 Sfmt 4702 76343 obtained by taking the average wage of a medical manager and lawyer. 2. Number of Hours of Reading In the CMS Interoperability and Patient Access final rule, we estimated 6 hours of reading time. Therefore, we believe 10 hours would be enough time for each parent organization to review relevant portions of this proposed rule. 3. Number of Entities Reviewing the Proposed Rule We believe the review would be done by both parent organizations that would be required to implement the proposed API provisions, and by the physician and provider specialty societies. For parent organizations, we have used an assumption of 365 parent organizations throughout this proposed rule. For physician practices, individual physician practices rely on their specialty societies to read content such as proposed rules for them. The Relative Value Scale Update Committee (RUC) has 32 members representing all specialties.175 This would result in 398 entities (365 Parent organizations plus 32 members of the RUC) in our estimates. We also add 100 entities (for a total of 500 entities) to account for the 66 pharmacy benefit managers and the several dozen major advocacy groups. Thus, we estimate a one-time aggregated total review cost of $1.3 million ($128.71 times 10 hours of reading time times 500 entities times two staff per entity). We request comment on our estimate. F. Impact of Individual Proposals The proposed provisions of this rule all have information collection-related burden. Consequently, the impact analysis may be found in Table 19 of the Collection of Information in section IV. of this proposed rule. To facilitate a review of the provisions and estimates made in the Collection of Information, we have included Table 21, which provides the related ICRs by number and title, as well as the table numbers for which impact is presented. 175 American Medical Association (2022, July 12). Composition of the RVS Update Committee (RUC). Retrieved from https://www.ama-assn.org/about/ rvs-update-committee-ruc/composition-rvs-updatecommittee-ruc. E:\FR\FM\13DEP2.SGM 13DEP2 76344 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules TABLE 21: CROSS-REFERENCES TO IMPACTS IN THE COLLECTION OF INFORMATION REQUIREMENTS (SECTION IV.) OF THIS PROPOSED RULE 1 Patient Access API Metrics Reporting to CMS Proposal Table 12 2 Provider Access API Proposal Table 13 3 P ARDD API Proposal Table 14 4 Timeframes for Prior Authorization Decisions Proposals Table 15 5 Public Reporting of Prior Authorization Metrics Proposal Table 16 6 Payer-to-Payer API Proposal Table 17 7 Electronic Prior Authorization Measure (Eligible Hospitals, CAHs, and MIPS eligible clinicians) 3-Year Analysis of Cost Impact of Proposed Provisions Summary Table lotter on DSK11XQN23PROD with PROPOSALS2 Additionally, this Regulatory Impact Analysis section provides an analysis of potential savings arising from the replacement of paper approaches to prior authorization and other plan requirements with an electronic method. Although these savings are neither included in monetized tables nor in summary tables, as further discussed later in this proposed rule, we believe that these large savings are an important consideration in evaluating this proposed rule. We have identified assumptions for these analyses, and we request public comment. Table 27 of this section, using Table 19 as a basis, provides a 10-year impact estimate. Table 27 includes impact by year, by type (parent organizations, including Medicaid and CHIP state agencies), as well as the cost burden to the Federal Government, allocations of cost by program, and payments by the Federal Government to Medicare Advantage, Medicaid, and CHIP, as well as the premium tax credits (PTC) paid to certain enrollees in the individual market. G. Alternatives Considered In this proposed rule, we continue to build on the efforts initiated with the CMS Interoperability and Patient Access final rule and the work we have done to advance interoperability, improve care coordination, and empower patients with access to their healthcare data. This proposed rule covers a range of policies aimed at achieving these goals. We carefully considered alternatives to the policies we are proposing in this rule, some of which were included in the December 2020 CMS Interoperability proposed rule, and on which we received public comments. Those public comments and other engagements over the year support our conclusions that none of the alternatives VerDate Sep<11>2014 Table Number for ICRs with Impact Analysis ICR Title 18:56 Dec 12, 2022 Jkt 259001 would adequately or immediately begin to address the critical issues related to patient access and interoperability or help to address the processes that contribute to payer, provider, and patient burden. We now discuss the alternatives we considered to our proposed provisions and the reasons we did not select them as proposed policies. 1. Alternatives Considered for the Proposed Patient Access API Enhancements We are proposing to require that payers make enhancements to the Patient Access API finalized in the CMS Interoperability and Patient Access final rule including proposing additional information be made available to patients through the Patient Access API, and proposing certain metrics about patient use of the Patient Access API be reported directly to CMS annually. Before proposing to require these provisions, we considered several policy alternatives. As we discussed in the CMS Interoperability and Patient Access final rule (85 FR 25627), one alternative to the proposed updates to the Patient Access API we considered is allowing payers and providers to upload patient data directly to a patient portal, operated by a provider. However, despite the availability of patient portals, ONC reported in 2020 that only 60 percent of individuals have been offered online access to their medical records by either their healthcare provider or payer. And of the individuals that were offered access, approximately 40 percent of those viewed their record.176 Further, patient 176 Office of the National Coordinator (2021, September). Individuals’ Access and Use of Patient Portals and Smartphone Health Apps, 2020. ONC PO 00000 Frm 00108 Fmt 4701 Sfmt 4702 Table 18 Table 19 portals may not achieve the same interoperability goals that health apps could in order to support a patient’s individual preference to manage their specific health condition or view their complete health record using supplemental data from different sources. A patient portal can only provide the data available from the organization offering the portal, and most portals are not connected to mobile applications to monitor physical activity, medication compliance, or health metrics. Portals may not be connected to the many external health apps for other services such as fitness training, meal planning for special diets, challenges, or other features available in the marketplace. Finally, providers and payers are not yet coordinating on the exchange of administrative and clinical data that we are proposing be shared in this proposed rule. For those reasons we do not believe that patient portals can fully meet patients’ needs and would not be a suitable policy option to propose. We also believe that there could be additional burden associated with using portals because patients might need to use multiple portals and websites to access all of their information. Using multiple portals would require an individual to sign into each portal in order to review all of their relevant data—one for each provider or plan with which the patient is associated. A single health app may be able to compile health information about the patient from multiple sources, based on a patient’s request. The patient could possibly access this information with one login, and could find the same Data Brief N. 57. Retrieved from https:// www.healthit.gov/data/data-briefs/individualsaccess-and-use-patient-portals-and-smartphonehealth-apps-2020. E:\FR\FM\13DEP2.SGM 13DEP2 EP13DE22.022</GPH> ICRNumber lotter on DSK11XQN23PROD with PROPOSALS2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules information, as might be available from the multiple portals. A portal is operated by a provider or payer as an entry point to a finite set of data available from an individual organization. These portals do not lend themselves as well to interoperability because they do not enable other organizations, or the patient, to provide additional data to the system. Because business models and processes pertaining to patient portals are varied across the industry, and any one patient could be associated with a number of different portals, there is no available data today with which we can evaluate the cost impacts of requiring individual portals versus the estimates for enhancing the Patient Access API. As explained in the CMS Interoperability and Patient Access final rule (85 FR 25627), another alternative considered was to allow Health Information Exchanges (HIEs) and Health Information Networks (HINs) to serve as a central source for patients to obtain aggregated data from across their providers and payers in a single location. HIEs and HINs could provide patients with information via an HIE portal that is managed by the patient. However, as previously described, there are reasons why patient portal access does not lend itself to interoperability or innovation, and all patients might not have access to an HIE or HIN. For the reasons described, we ultimately decided to proceed with our proposed requirements versus these alternatives. In the December 2020 CMS Interoperability proposed rule (85 FR 82592), we proposed to require impacted payers to request a privacy policy attestation from health app developers when their health app requests to connect to the payer’s Patient Access API. We proposed that the attestation would include, at a minimum, that the health app has a plain language privacy policy that is always publicly available and accessible and has been affirmatively shared with the patient prior to the patient authorizing the app to access their health information. In addition, the attestation we proposed included yes/no elements as to whether the privacy policy specifically communicates how the patient’s health information could be accessed, exchanged, or used. We considered proposing that policy again, but based on substantial public comment, we believe that this type of attestation would not benefit patients in ways that would outweigh the burden on impacted payers and that such a policy could have unintended consequences for patients. Under that VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 proposal, a health app developer would only be attesting to the format and inclusion of certain information. There would be no attestation that the substance of the privacy policy meets specific minimum requirements or best practices. We believe that having payers inform patients that an app developer has attested to the form and format of a privacy policy could easily be misinterpreted as assurance that the substance of the privacy policy has been reviewed and found acceptable by the payer (or CMS). We are concerned that requiring such an attestation would only give the appearance of privacy and security for patients’ health data, without providing additional privacy or security. Though we did not pursue this option, we continue to work with the Office for Civil Rights and the Federal Trade Commission 177 to determine what additional types of guidance might be warranted to support consumer education with respect to privacy policies when using health apps, as well as guidance for payers when evaluating the apps available to their beneficiaries and enrollees. Regarding reporting Patient Access API metrics, we considered requiring impacted payers to publicly report these metrics more frequently than annually. For example, we considered a quarterly requirement. Public comments on the December 2020 CMS Interoperability proposed rule indicated a preference for less frequent reporting, which would in turn create less burden on payers. Annual statistics on such utilization should be sufficient to accomplish our goals. We also considered alternative effective dates for the proposed policies. For example, we considered January 1, 2024, and 2025 as possible compliance dates for the Patient Access API enhancements. However, based on the public feedback we received from the December 2020 CMS Interoperability proposed rule, we believe it is more appropriate, and less burdensome on impacted payers to propose an effective date for these policies beginning on January 1, 2026 (for Medicaid managed care plans and CHIP managed care entities, by the rating period beginning on or after January 1, 2026, and for QHP Issuers on the FFEs, for plan years beginning on or after January 1, 2026), which provides for a two year implementation time frame. 177 Federal Trade Commission (2022, April 27). Mobile Health Apps Interactive Tool. Retrieved from https://www.ftc.gov/business-guidance/ resources/mobile-health-apps-interactive-tool. PO 00000 Frm 00109 Fmt 4701 Sfmt 4702 76345 2. Alternatives Considered for the Proposed Provider Access API In this proposed rule, to better facilitate the coordination of care across the care continuum, we are proposing to require impacted payers to implement and maintain a Provider Access API. This proposed API would require payers to make available to certain providers the same types of data they would make available to patients via the enhanced Patient Access API. Alternatively, we considered other data types that could be exchanged via the Provider Access API. We considered only requiring the exchange of all data classes and data elements included in a content standard at 45 CFR 170.213. While this would be less data to exchange and, thus, potentially less burdensome for impacted payers to implement, we believe that claims and encounter information can complement the content standard and offer a broader and more holistic understanding of a patient’s interactions with the healthcare system. Furthermore, the data that we propose to be made available through the proposed Provider Access API aligns with the data that we propose to be made available to individual patients through the Patient Access API. Once the data are mapped and prepared to share via one FHIR API, these data should be available for all payer APIs to use within that organization. We also considered having only payer claims and encounter data available to providers, understanding that providers are generally the source of clinical data. This could limit the burden on payers by requiring less data to be made available. However, even if a provider is the source for the clinical data relevant to their patient’s care, a provider may not have access to clinical data from other providers a patient is seeing. As a result, and understanding payers were already preparing these data for use in other APIs, we decided a more comprehensive approach would be most beneficial to both providers and patients and aligned the proposed Provider Access API data requirements with those proposed for the Patient Access API. We also considered including additional data elements in this proposal as well as requiring the complete set of data available from the payer’s system. We had not received recommendations for such an extensive body of data and acknowledge that such a large volume of data types would require too many additional resources, and would likely not be consistent with minimum necessary provisions (unless E:\FR\FM\13DEP2.SGM 13DEP2 76346 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules lotter on DSK11XQN23PROD with PROPOSALS2 its receipt was required by law in concert with how the data was being requested) and be overly burdensome for impacted payers at this time. As described earlier in this proposed rule, the USCDI is a standardized set of data classes and data elements adopted for nationwide, interoperable health information exchange.178 Because this limited set of data has been standardized, and corresponding FHIR IGs have been developed, payers can map these data and make them more easily available via an API. The HL7 workgroups in which payers and providers participate continue to work on the IGs to ensure necessary enhancements to facilitate sharing of a patient’s complete record. We acknowledge that work will be ongoing for the IGs, and important questions about data segmentation, and a patient’s role in potentially specifying what parts of their medical record could or should be available to which providers, need to be considered. 3. Alternatives Considered for the Proposed Payer-to-Payer API We are proposing to require impacted payers to implement and maintain a Payer-to-Payer API that makes certain data available to other payers via a FHIR API. This proposal would make the same data that is being made available to patients and providers also available to other payers when an enrollee changes plans, and in that way allow patients to take their data with them as they move from one payer to another. Before proposing these policies, we considered several policy alternatives. In the CMS Interoperability and Patient Access final rule, we finalized a policy to require payers to exchange data with other payers, but did not require a specific mechanism for the payer to payer data exchange. Rather, CMS required impacted payers to receive data in whatever format it was sent and accept data in the form and format it was received, which ultimately complicated implementation by requiring payers to accept data in different formats. In this proposed rule, we had the option to maintain the previous policy and forgo the API requirement. However, since the CMS Interoperability and Patient Access final rule was finalized in May of 2020, many impacted payers indicated to CMS that the lack of technical specifications for the payer to payer data exchange requirement was creating challenges for 178 Office of the National Coordinator Interoperability Standards Advisory (ISA). (n.d.) United States Core Data for Interoperability (USCDI). Retrieved from https://www.healthit.gov/ isa/united-states-core-data-interoperability-uscdi. VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 implementation, which could have created differences in implementation across the industry, poor data quality, operational challenges, and increased administrative burden. Differences in implementation approaches could have created gaps in patient health information that would have conflicted directly with the intended goal of interoperable payer to payer data exchange. Furthermore, for the Payer-to-Payer API, once an organization implements the other proposed APIs, there would be less additional investment necessary to implement the Payer-to-Payer API as payers would be able to leverage the infrastructure already established for the Patient Access API and Provider Access API. The HL7 Da Vinci Payer Data Exchange work group has expanded their work over the past year to include two paths to exchange claims and associated clinical data. The updated background section for the recommended implementation guide provides an explanation of how the existing resources can be tailored to meet the provisions of our proposals.179 Given this available infrastructure and the efficiencies of sharing standardized data via the API, we determined it was most advantageous for payers to leverage an API for this enhanced data exchange. We also considered which data elements would be the most appropriate to require for the exchange between payers. Similar to the Provider Access API alternatives, we considered only requiring the exchange of data classes and data elements included in a content standard at 45 CFR 170.213. As we previously described, we believe that claims and encounter information can complement the content standard and potentially allow for better care coordination, as well as more efficient payer operations. We do not believe there to be significant additional burden once the data are mapped for the other proposed APIs. 4. Alternatives Considered for the Proposed PARDD API and Other Prior Authorization Proposals We are also proposing several policies associated with the prior authorization process. First, we are proposing to require that all impacted payers implement and maintain a Prior Authorization Requirements, Documentation, and Decision (PARDD) API. We believe this API would 179 Da Vinci Payer Data Exchange (2020, December 22). HL7 International. Retrieved from HL7.FHIR.US.DAVINCI–PDEX\Home—FHIR v4.0.1. PO 00000 Frm 00110 Fmt 4701 Sfmt 4702 ultimately help patients receive the items and services they need in a timely fashion. The PARDD API aims to improve care coordination by enabling enhanced communication about when a prior authorization is required, information that is required to approve a prior authorization, and facilitating electronic prior authorization. This would add efficiencies for both payers and providers, and it could improve patient care by avoiding gaps and delays in care. This API would be accessible to providers to integrate directly into their workflow while maintaining compliance with the mandatory HIPAA transaction standards. As proposed, by January 1, 2026, impacted payers would be required to implement and maintain a FHIR PARDD API, populate the API with their list of covered items and services (excluding drugs) for which prior authorization is required, and any documentation requirements for the prior authorization. (For Medicaid managed care plans and CHIP managed care entities, by the rating period beginning on or after January 1, 2026, and for QHP issuers on the FFEs, for plan years beginning on or after January 1, 2026.) We considered proposing a phased approach for the PARDD API where payers would first make the functionality available for a specified subset of their prior authorization rules and requirements, as opposed to all of the rules and requirements for all applicable items and services at one time. We also considered requiring that payers only prepare the PARDD API for a specific set of services most commonly requiring prior authorization across payers. However, we believe this would be more burdensome in some ways. It would require providers to use different systems to find requirements for different services for each payer. If the requirements for different services were in different places, such as some information in payer portals and some through the PARDD API, providers would have to spend additional time searching for the information in multiple locations for one payer. Therefore, we believe it is ultimately less burdensome overall to require impacted payers to populate the prior authorization and documentation requirements for all covered items and services (excluding drugs) at the same time. There are several pilots underway to test the PARDD API, as well as other tools. The results are all positive for the policies that are being tested and showcased in demonstrations at conferences. However, no quantitative data have yet been shared with CMS to E:\FR\FM\13DEP2.SGM 13DEP2 lotter on DSK11XQN23PROD with PROPOSALS2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules include with this proposed rule, but it is anticipated in the near future. We also considered a phased timeline approach to implement these functionalities. For example, we considered first requiring implementation of the requirements and documentation functionality in 2026 and then a year later requiring implementation of the submission and decision functionality of the API. We also considered whether to propose these two capabilities as separate APIs. However, considering the enforcement discretion we exercised for the APIs finalized in the CMS Interoperability and Patient Access final rule, we believe it is more appropriate to propose compliance dates for this policy in 2026, providing payers with more time to potentially implement both functionalities at the same time. We also considered whether we should propose to require that payers post, on a public-facing website, their list of items and services for which prior authorization is required and populate the website with their associated documentation rules as an interim step while they implement the PARDD API. However, we are aware that some payers already have this information publicly available, and we determined that this would not provide any reduced burden on payers or providers at this time. There is burden associated with updating the information on a website as the list of prior authorization items is likely to change frequently, due to the availability of new therapies. We seek comment on whether a payer website to provide additional transparency to prior authorization requirements and documentation would be beneficial in reducing the overall burden in this process. Another alternative we considered to support prior authorization was to only use the X12 standard transaction adopted under HIPAA rather than require the implementation of a FHIR API. The X12 standard defines the content and format for the exchange of data for specific business purposes and is designed for administrative transactions between administrative systems. For prior authorization, the adopted standard is the X12 278 version 5010. The X12 standard for prior authorization does not have the functionality of the HL7 IGs to support the proposed PARDD API to make available the response from the payer in the provider’s health IT system. Furthermore, the CRD, DTR, and PAS IGs combined, provide the necessary information for the provider to know the coverage and documentation requirements to submit a compliant VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 prior authorization request for each payer. X12 is not designed to enable the use of SMART on FHIR apps connected to the provider’s EHR system, nor is it designed for the scope envisioned in this proposed rule, including extraction of payer rules, a compilation of data into electronic-based questionnaires, or communication with EHRs. The adoption rate of the mandated X12 278 Version 5010 standard is low, according to data compiled annually by CAQH (described earlier in this proposed rule). By 2020, the use of the X12 278 standard for prior authorization transactions had reached 21 percent despite having been available since 2012. Background on the industry’s failure to use the X12 standards is explained in more detail in section II.D. We are proposing other provisions, including requiring certain impacted payers to ensure that prior authorization decisions are made within 72 hours of receiving an expedited request and no later than 7 days after receiving a standard request, and proposing to require impacted payers to publicly report prior authorization metrics on their websites or via a publicly accessible hyperlink(s) annually. We considered several alternative timeframe policies before deciding to propose these policies. We considered alternative timeframes under which payers could provide a decision in less than 72 hours (for expedited decisions) and 7 days (for standard decisions). For example, we considered requiring payers to provide a decision in 48 hours for expedited requests and 3 days for standard requests. We are seeking comment on this proposal but decided not to make it an alternative proposal due to concerns over the feasibility of implementing such timeframes. We will reevaluate these timeframes at a future date once the PARDD API is in place, as we believe the PARDD, as well as the other efficiencies introduced in this proposed rule, would make shorter timeframes more feasible. Understanding the importance of providers and patients getting decisions as quickly as possible, we believe that the timeframes we propose in this rule are a significant step to help increase reliability in the prior authorization process and establish clear expectations without being overly burdensome for payers. These timeframes allow payers to process the prior authorization decisions in a timely fashion and give providers and patients an expectation for when they can anticipate a decision and know when they can receive care. We also considered whether more than 7 days would be necessary for complex PO 00000 Frm 00111 Fmt 4701 Sfmt 4702 76347 cases, for example, adding an additional decision timeframe category to include complex cases. However, we did not propose this alternative because we believe it is important for patients and providers to be able to receive a decision in a shorter timeframe. We believe 7 days is sufficient time for a payer to process prior authorization decisions. Regarding publicly reporting prior authorization metrics, we considered requiring impacted payers to publicly report these metrics more frequently than annually, such as on a quarterly basis. However, because most patients typically shop for health insurance coverage on an annual basis, we believe updating this information annually be sufficient for making decisions. We also considered whether to allow payers to report on a selected subset of metrics, rather than taking an ‘‘all or nothing’’ approach. After further consideration, we believe all metrics proposed would be valuable for payers to report publicly. We also considered reporting these metrics at the parent organization versus at the organization, plan, or issuer level for all impacted payers. After further consideration, we decided this may not be truly operational and may be too aggregated a level of reporting for some payer types to provide useful information for patients and providers. As a result, we are proposing reporting at the organization level for MA, statelevel for Medicaid and CHIP FFS programs, plan-level for Medicaid and CHIP managed care, and at the issuerlevel for QHP issuers on the FFEs. G. Analysis of the Potential Impact for Savings Through Adoption of the Prior Authorization Provisions by Healthcare Providers As described in section II.D., we are proposing new requirements related to prior authorization for impacted payers, and in section II.E. we described our proposal for measure reporting for MIPS eligible clinicians, eligible hospitals, and CAHs. In section IV., we discussed the ICRs regarding cost estimates for reporting and the potential burden specifically for the MIPS eligible clinicians, eligible hospitals, and CAHs. In this impact analysis, we discuss the anticipated cost savings of these proposals for the broader healthcare provider population, which is inclusive of, but not limited to the MIPS eligible clinicians, hospitals, and CAHs. We believe that all healthcare providers could benefit from the proposal for impacted payers to implement the API proposals in this proposed rule and base these costsavings estimates on that total number, E:\FR\FM\13DEP2.SGM 13DEP2 lotter on DSK11XQN23PROD with PROPOSALS2 76348 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules with estimates described in this section of this rule, of the proportion of providers that we expect to benefit over the next 10 years. To conduct this analysis, we used available resources to create the estimates and invite comments on our assumptions, the recency of our data, and our citations. The savings we calculate in this section V.G. of this proposed rule would be true savings, not transfers since they reflect savings in reducing the administrative costs required to process prior authorizations. However, these savings would be an indirect consequence of the proposed rule, not direct savings. This proposed rule supports efforts to significantly reduce time spent on manual activities. In general, it is only appropriate to claim that a regulatory provision’s benefits are greater than its costs after a substantive and preferably quantitative, assessment of the pre-existing market failure and the provisions’ suitability for addressing it. As a result of data limitations and other analytic challenges preventing such an assessment, the illustrative savings estimates are neither included in the monetized table, nor in the summary table of this proposed rule, nor in the 2016 dollar calculation. Nevertheless, the savings could be significant, and we believe should be a factor in the evaluation of this proposed rule. We request comment on this decision not to include the savings in the final summary Table 27 and related tables. Recognizing the potential policy interactions this proposed rule has with other future CMS and HHS rules, as well as Congressional actions, we request comment on how CMS might attribute savings benefits to avoid double-counting. What are the implications if the same effects were attributed to multiple regulations? For example, we note that the Medicare Advantage program is impacted by several CMS regulations, which may overlap with one another. How could CMS account for both costs and benefits from such policy intersections? We note that we are only quantifying savings of reduced paperwork for healthcare providers. However, the improved efficiencies proposed in this rule have several consequences, which could lead to savings. A 2021 survey by the American Medical Association (AMA) 180 lists several adverse qualitative consequences of the current paper-based prior authorization system, including life-threatening adverse 180 American Medical Association (2021). 2021 AMA Prior Authorization (PA) Physician Survey. Retrieved from https://www.ama-assn.org/system/ files/2021-04/prior-authorization-survey.pdf. VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 medical events, missed, or abandoned treatments, hospitalization, and permanent bodily damage. The provisions of this proposed rule, if finalized, could be an important step in reducing these adverse health events. The approach adopted in quantifying savings is to quantify those that we can reliably estimate and note that they are minimal savings. The proposals of this rule potentially affect individual physicians, physician groups, hospitals, and CAHs. However, for purposes of quantification, we initially estimate a reduced paperwork burden for individual physicians and physician groups, which shows a savings of several billion dollars. We start the estimate with individual physicians and physician groups because we have reliable data (two multi-thousand surveys from 2006 and 2021 cited in this section of this proposed rule, which agree with each other) on (1) the number of hours per week spent on prior authorization, and (2) the proportion of hours per week spent by physicians, nurses, and clerical staff. To then estimate reductions in spending on paperwork for prior authorization for hospitals, we assume that hospitals perform their prior authorization activities similar to individual physicians and physician groups. We make this assumption because we do not have a basis for making a more accurate assumption; that is, we do not have similar survey data for hospitals on the number of hours per week spent on prior authorization and the proportion of hours per week spent by physicians, nurses, and clerical staff. To support the assumptions on potential benefits for hospital prior authorization, we rely on data from the 2023 Hospital Inpatient Prospective Payment Systems for Acute Care Hospitals and the Long-Term Care Hospital Prospective Payment System (FY 2023 IPPS/LTCH PPS) final rule (87 FR 48780) and the CY 2023 Hospital Outpatient Prospective Payment and Ambulatory Surgical Center Payment Systems (CY 2023 OPPS/ASC) final rule (87 FR 71748, November 23, 2022) for estimates of the number of possible organizations that could be impacted. We provide more information in this section of this proposed rule, about the estimate of the number of hospitals, 7,978,181 182 and the number of 181 Hospital Inpatient Prospective Payment System for Acute Care Hospitals and the Long-Term Care Hospital Prospective Payment System and Fiscal Year 2023 Rates (CMS–1771–P) 87 FR 48780 (August 10, 2022). Retrieved from https:// www.federalregister.gov/d/2022-16472/p-6888. PO 00000 Frm 00112 Fmt 4701 Sfmt 4702 individual physicians and physician groups, 199,543. If we assume hospitals are conducting the prior authorization process in a manner similar to physicians, then in effect we have increased the number of individual physicians and physician groups from 199,543 to 207,521 entities (199,543 individual physicians and physician groups plus 7,978 hospitals). We compute aggregate savings by first estimating the savings for a single individual physician or group physician practice and then multiplying this single savings by the number of practices. Therefore, it follows that if 199,543 individual physician and group physician practices would save money, as shown in Table 24 of this proposed rule, then 207,521 combined physician practices and hospitals would save $15.3 billion (207,521/199,543 × $14.70). When we round the updated savings to the nearest billion there is no numerical change in the savings since both $15.3 and $14.7 round to $15 billion. We believe this approach to be the clearest. In calculating the potential savings, uncertainties arise in four areas, and the result of this illustrative analysis is that we find a minimal potential savings impact of between $10 to $20 billion over the first 10 years of implementation. To provide credibility to this savings analysis we have, where we lacked better data, underestimated any unknown quantities with minimal estimates and additionally studied the effect of a range of estimates. In the next few paragraphs, we explain each of the four uncertainties, indicate how we approached estimation, and request public comment. 1. Assumptions on the Relative Proportion of Current Workload Hours by Staff for Prior Authorization To estimate the savings impact, we researched estimates of the current amount of paperwork involved in prior authorization, the type and number of staff involved, the type of physician offices involved, and hours per week staff spent engaged in prior authorization processes. Our assumptions on the relative proportion of current workload hours by type of staff are based on a survey presented by Casalino et al. (2009),183 which gave a 182 CY 2023 Hospital Outpatient PPS Policy Changes and Payment Rates and Ambulatory Surgical Center Payment System Policy Changes and Payment Rates Proposed Rule (CMS–1772–P) 87 FR 44502 (July 26, 2022). Retrieved from https:// www.federalregister.gov/d/2022-15372/p-2609. 183 Casalino, L.P., Nicholson, S., Gans, D., Hammons, T., Morra, D., Karrison, T., & Levinson, W. (May 2009). What Does It Cost Physician E:\FR\FM\13DEP2.SGM 13DEP2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules detailed analysis based on a validated survey instrument employed in 2006. The Casalino et al. study is dated; therefore, several numbers in the article were updated, including hourly wages, the number of physician practices, and the hours per week spent on prior authorization. We only use this article for the relative proportions of workload by staff type. We have not found any other studies that address this data point for physician offices and similarly no studies that address this same information for hospitals. Staff type is important because, for example, the hourly wage for clerical staff is about one-half the hourly wage for nurses and about one-fifth the hourly wage for physicians; clearly then, the staff doing the paperwork can significantly affect savings. Such a design allows us to update wages using the Bureau of Labor Statistics’ (BLS) latest wages. It also allows the allocation of costs based on the staff member used in the analysis. We used the relative proportion of time spent by physicians, nurses, and clerical staff presented in this paper in our estimates since they seemed reasonable and were not discussed in any other survey reviewed. Thus, though the article by Casalino et al., is dated, it was useful for proportions of time spent on paperwork for prior authorization for the following reasons: • Unlike many subsequent studies, the survey instrument was validated by several organizations. • Unlike many subsequent studies, the number of physician practices surveyed was in the thousands. • Finally, we note that several other estimates in the literature were reviewed,184 185 1865 187 188 which, although reflecting more recent research, either did not show the basis for their calculations, showed a basis based on a very small number of people, or used a non-validated survey. The Casalino et al. survey excluded certain physician practices, including health maintenance organizations (HMOs), but analyzed workload by staff type (doctor, nurse, clerical, administrator, lawyer, and accountant), office type (solo, 3 to 10 physicians, 10 or more physicians), and the type of medical work involved (prior authorization, formulary, claims billing, quality, etc.). Consistent with our approach, we restricted ourselves to prior authorization activities, though formulary work could possibly add to 76349 burden related to prior authorization activities. Table 22 presents an estimate of the current average annual paperwork burden per physician office for prior authorization activities. Table 22 estimates an average annual burden per individual physician or physician group practice of 676 hours at a cost of $48,882. In reaching this estimate, we note all of the following: • The relative hours per week for physicians, registered nurses, and clerical staff were, as previously discussed, kept the same as in the Casalino et al. article. • The labor costs were updated to 2021, using the Bureau of Labor Statistics (BLS) mean hourly wages. • The 20.4 hours per week estimated for prior authorization in the Casalino et al. article was reduced to 13 hours per week based on the AMA survey conducted in 2021.189 • As previously discussed, we initially estimated reduced paperwork burden for individual physician and group physician practices and updated these numbers at the end of our entire analysis to include hospitals for which we do not have definitive surveys. TABLE 22: TOTAL ANNUAL CURRENT COST OF PRIOR AUTHORIZATION PAPERWORK FOR INDIVIDUAL PHYSICIANS AND GROUP PRACTICES Hours/Week HoursNear Phvsicians 0.6 Registered Nurses 8.3 Clerical 4.0 Total 13 Total Cost Per Individual and Grono Phvsician Practice oer Year Total Cost per Staff (Hours * Labor) $210.44 $76.94 $40.76 $6,973 $33,400 $8,509 $48,882 Table 22 presents the current hour and dollar burden per physician group and individual physician office. To obtain the aggregate annual burden of prior authorizations for all physician practices, including those exclusively furnishing services to Fee for Service (FFS) enrollees, Casalino et al. (2009) multiplies the Table 22 burdens per physician group and individual physician office by the total number of individual and group physician practices. Thus, we need an estimate of the total number of individual and group physician practices. We assume there are a total of 199,543 individual and group physician practices (of which the MIPS eligible clinician practices affected by this proposed rule are a subset). The 199,543 number was arrived at by dividing the estimated 1,596,340 individual physicians derived from Table 144 in the CY 2023 Payment Policies Under the Physician Fee Schedule (PFS) final rule (87 FR 69404, 70171) by an estimated median number of 8 physicians per Practices to Interact with Health Insurance Plans? Health Affairs, 28(4): w533–w543. doi: 10.1377/ hlthaff.28.4.w533. 184 Morley, C.P., Badolato, D.J., Hickner, J., Epling, J.W. (2013, January). The Impact of Prior Authorization Requirements on Primary Care Physicians’ Offices: Report of Two Parallel Network Studies. The Journal of the American Board of Family Medicine, 26(1), 93–95. doi: 10.3122/ jabfm.2013.01.120062. 185 Ward, V. (2018, April). The Shocking Truth About Prior Authorization in Healthcare. Retrieved from https://getreferralmd.com/2018/04/priorauthorization-problems-healthcare/. 186 Robeznieks, A. (2018, November 16). Inside Cleveland Clinic’s $10 million prior authorization price tag. Retrieved from https://www.ama-assn. org/practice-management/prior-authorization/ inside-cleveland-clinic-s-10-million-priorauthorization. 187 American Medical Association (2019, June). Prior Authorization and Utilization Management Reform Principles. Retrieved from https:// www.ama-assn.org/system/files/2019-06/principleswith-signatory-page-for-slsc.pdf. 188 American Medical Association (2021). 2021 AMA Prior Authorization (PA) Physician Survey. Retrieved from https://www.ama-assn.org/system/ files/2021-04/prior-authorization-survey.pdf. 189 American Medical Association (2021). 2021 AMA Prior Authorization (PA) Physician Survey. Retrieved from https://www.ama-assn.org/system/ files/2021-04/prior-authorization-survey.pdf. 190 Muhlestein, D. and Smith, N., 2016. Physician Consolidation: Rapid Movement from Small to Large Group Practices, 2013–15. Health Affairs, 35(9), pp.1638–1642. doi/10.1377/ hlthaff.2016.0130. 2. Assumptions on the Total Number of Individual and Group Physician Practices lotter on DSK11XQN23PROD with PROPOSALS2 33.1 434.1 208.8 676.0 Labor Cost ($/Hour) VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 PO 00000 Frm 00113 Fmt 4701 Sfmt 4702 E:\FR\FM\13DEP2.SGM 13DEP2 EP13DE22.023</GPH> Occupation Title 76350 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules practice from the Muhlestein et al. (2016) article.190 191 3. Assumptions on the Reduction in Hours Spent on Prior Authorization as a Result of the Provisions of This Proposed Rule Table 22 provides current hours spent on prior authorizations. To calculate potential savings, we must make an assumption on how much these hours could be reduced as a result of the provisions of this proposed rule. Section II.D. of this proposed rule would require impacted payers to implement a PARDD API. As we described in that section, this API, if voluntarily used by an individual physician or within a physician group, could allow members of individual physician and physician group practices to discover whether a requested item or service requires prior authorization and, if so, the relevant documentation requirements. All provider office staff types, including physicians, nurses, and clerical staff, could experience reductions in the time needed to locate prior authorization rules and documentation requirements, which are currently either not readily accessible or available in many different payerspecific locations and formats. We believe that our proposal would make it possible for staff to use one system (such as their EHR or practice management system) or software application to find the prior authorization rules and documentation requirements for most impacted payers. With these rules and requirements more consistently and easily accessible, we anticipate a reduction in the need for providers to make multiple attempts at submitting complete information necessary for the payer to approve or deny a prior authorization. Consequently, a PARDD API could also reduce appeals and improper payments,192 but we are not addressing such savings here, as we have no realworld basis on which to make an estimate. (We also note that reduction in improper payments, though experienced as savings by certain entities, would be categorized as transfers from a societywide perspective.) In addition to being able to look up whether a requested item or service requires prior authorization and, if so, the relevant documentation requirements, the PARDD API can compile the necessary data elements to populate the HIPAA-compliant prior authorization transaction along with the documentation needed and receive an approval or denial decision from the payer, including any ongoing communications regarding additional information needed or other status updates. Currently, many prior authorization requests and decisions are conducted through one of several burdensome channels, including telephone, fax, or payer-specific web portals, each of which requires taking action and monitoring status across multiple and varying communication channels. Based on this discussion we assume the following reductions. Physicians who currently (on average over all physician groups) spend 0.6 hours per week on prior authorization (Table 22) are assumed to reduce their time by 10 percent. Nurses who currently spend one day (8.3 hours) per week on prior authorization are assumed to reduce their time to half a day, a reduction of 50 percent. Clerical staff who currently spend 4 hours a week on prior authorization are assumed to reduce their time by 1 hour, a 25 percent reduction. We discuss alternate assumptions in this section of this proposed rule, after presenting the total 10-year savings. We also specifically solicit comments from stakeholders on the reasonableness of these assumptions. TABLE 23: TOTAL SAVINGS FOR A SINGLE INDIVIDUAL AND GROUP PHYSICIAN PRACTICE ADOPTING THE PROPOSALS OF THIS PROPOSED RULE (5)=(3)*(4) (3)=(1)*(2) Hours/Year Assumed Percent Reduction in Hours Total Reduced Hours per Year 33.l 10% 3.3 ($/Hour) $210.44 Total Reduced Dollar Spending Per Year ($) 697 434.l 50% 217.0 $76.94 16,700 208.8 25% 52.2 $40.76 2,127 (1) lotter on DSK11XQN23PROD with PROPOSALS2 Physicians Registered Nurses Clerical Totals per Physician Practice 676 (4) Labor Cost 272.6 19,524 Table 23 presents the total savings in paperwork for prior authorization for a single individual or group physician practice adopting the proposals of this rule. The columns of this table are explained as follows. Column (1), the total hours per year per staff type spent on prior authorization is obtained from Table 22. Column (2) presents our assumptions, as previously discussed, on reduced time by staff type. Column (3) is the product of columns (1) and (2). Column (4) is taken from Table 22. Column (5), the total reduced dollar spending per year is obtained by multiplying columns (3) and (4). The total row indicates aggregate hours and dollars saved over all staff type. 191 Medicare Physician Payment Proposed Rule Calendar Year 2023 (CMS–1772–P) 87 FR 44502. Table 144. (2022, July 26) Retrieved from https:// www.govinfo.gov/content/pkg/FR-2022-07-26/pdf/ 2022-15372.pdf. 192 Centers for Medicare & Medicaid Services (2019, November 15). Simplifying Documentation Requirements. Retrieved from https://www.cms.gov/ Research-Statistics-Data-and-Systems/MonitoringPrograms/Medicare-FFSCompliance-Programs/ SimplifyingRequirements.html. VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 PO 00000 Frm 00114 Fmt 4701 Sfmt 4702 E:\FR\FM\13DEP2.SGM 13DEP2 EP13DE22.024</GPH> Occupation Title (2) 76351 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules 4. Assumptions on the Number of Individual and Group Physician Practices Voluntarily Adopting the Proposals of This Rule We are not assuming that over 10 years all 199,543 individual and group physician practices would adopt the proposals of this rule. Instead we assume as follows: • That the 54,770 MIPS eligible clinicians (individual and group) a subset of the 199,543 estimated individual and group physician practices would adopt the proposals of this rule in 2026 (the 1st year of implementation) since there are payment consequences for them not doing so. • By 2034, 50 percent of all individual and physician practices would adopt the proposals of this rule. We do not assume a constant increase per year but rather a gradual increase per year. We begin our assumptions with the 54,770 MIPS eligible clinicians in 2026 and end with the 99,772 (50 percent of 199,543) individual and physician group practices in 2034, expecting an exponential growth, which is characterized by a slow beginning and more rapid growth later on. Applying these assumptions results in a $14.7 billion savings over 10 years, which are shown in Table 24. If we include hospitals by increasing the amount by 4 percent, the estimate would be $15.2 billion. The estimate rounded to the nearest billion is $15 billion. The 4 percent increase to account for hospitals is arrived at as follows. Based on the FY 2023 IPPS/LTCH final rule (87 FR 48780) and the CY 2023 OPPS/ ASC final rule (87 FR 71748) there are 3,142 Inpatient and Acute Care hospitals; 1,425 CAH hospitals; and 3,411 outpatient hospitals, or a total of 7,978 hospitals. We estimate that the hospitals represent 4 percent of the health care industry (7,978 hospitals/ 199,543 individual and group physician practices) of all individual and group physician practices, which we acknowledge is a rough estimate, only using a calculation of numbers. However, without additional impact *COM007*studies, we propose using this as our estimate for savings opportunities. TABLE 24: TOTAL HOURS (MILLIONS) AND DOLLARS (BILLIONS) SAVED OVER 10 YEARS AS A RESULT OF PHYSICIAN GROUPS AND HOSPITALS ADOPTING PROPOSALS OF THIS PROPOSED RULE (6) (2)*(4)*(5) I 1000000 (4) (5) Year Savings per practice (hr.) Savings per single practice ($) Percentage of practices adopting this proposed rule Total Number of individual and group physician practices Reduced hours per year (millions) Reduced Cost per year($ Billions) 2026 273 19524 27.45% 199543 14.9 1.1 2027 2028 273 273 19524 19524 29.34% 31.36% 199543 199543 16.0 17.1 1.1 1.2 2029 2030 273 273 19524 19524 33.52% 35.83% 199543 199543 18.2 19.5 1.4 2031 2032 273 273 19524 19524 38.30% 40.94% 199543 199543 20.8 22.3 1.5 1.6 2033 2034 273 273 19524 19524 43.76% 46.78% 199543 199543 23.8 25.4 1.7 1.8 2035 273 19524 50.00% 199543 27.2 205.19 1.9 14.7 213.39 15.3 Total lotter on DSK11XQN23PROD with PROPOSALS2 Grand total including hospitals) The columns headers of Table 24 show the logic and sources of the column entries are described here: • Column (1) gives the year, with the first year of implementation being 2026. • Column (2) gives the total reduced hours for any individual or group VerDate Sep<11>2014 (7) (3) (Table 23) 18:56 Dec 12, 2022 Jkt 259001 physician practice adopting the proposals of this rule (Table 23). • Column (3) gives the total reduced dollar spending for any individual or group physician practice adopting the proposals of this rule (Table 23). PO 00000 Frm 00115 Fmt 4701 Sfmt 4702 (3)*(4)*(5) /1 000 00 0 000 1.3 • Column (4) gives the assumed percentage of individual or group physician practices adopting the proposals of this rule in any one year. In 2026 we expect 54,770/199,543 or about 27 percent of all individual and E:\FR\FM\13DEP2.SGM 13DEP2 EP13DE22.025</GPH> (2) (Table 23) (1) 76352 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules physician groups to adopt the proposals. This number gradually increases until reaching 50 percent in 2035. • Column (5) gives the total number of individual and physician practices. • Column (6) gives the total hours saved (millions of hours) by multiplying the hours saved per practice times the number of practices times the percentage of practices adopting the proposals of this rule. • Column (7) gives the total dollars saved (billions) by multiplying the dollars saved per practice times the number of practices times the percentage of practices adopting the proposals of this rule. • The sum of savings over the 10 years is indicated in the next to last row: There is a savings of 205 million hours of work on prior authorization resulting in $14.7 billion reduced cost over 10 years. • The last row multiplies this amount by 207,521/199,543, as explained in the introductory paragraphs of this section V.G, to account for hospitals (Inpatient, Outpatient, and CAHs) assuming hospitals are subject to the same assumptions we made for individual physician groups. • As can be seen, to the nearest billion, $15 billion is saved to physicians and hospitals over 10 years from adopting the proposals of this proposed rule. If we assume additional savings, 10 percent, 50 percent, and 50 percent savings for physicians, nurses, and clerical staff respectively the savings over 10 years would be $17 billion (including savings to hospitals). If we assume less savings, 10 percent, 33 percent, and 33 percent savings for physicians, nurses, and clerical staff respectively the savings over 10 years would be $11 billion. Using a wide array of different assumptions, we expect an aggregate reduction of cost over 10 years of between $10 billion and $20 billion. H. Summary of Costs In this section, we present a 10-year summary table of costs, an analysis for Federal impacts, and the monetized table. To analyze the cost of this proposed rule to the Federal Government, we utilize a method of allocating costs by program (MA, Medicaid, CHIP, and QHP issuers on the FFEs). As the cost is shared by the 365 parent organizations, including Medicaid and CHIP state agencies, there is no readily available way to allocate costs per parent organization across programs since the percentage of each parent organization’s expenditures on the different programs is not publicly available. To address this, we utilize the same method used in the CMS Interoperability and Patient Access final rule (85 FR 25612). In that final rule, we used the public CMS Medical Loss Ratio (MLR) files, which break out total premiums among the various programs. The advantages and disadvantages of such an approach are fully discussed in that rule. Table 25 presents the 2020 MLR data of premiums by program and the resulting percentages by program. We use these percentages to allocate costs by program. This allocation of cost by program forms a basis to calculate the Federal Government’s cost for the proposed provisions of this rule. TABLE 25: ALLOCATION OF PREMIUM BY PROGRAM Program Premium (Billions $) Percentage by Program Total 461 Medicare Advantage (MA) 223 48.33% Medicaid and CHIP 148 32.12% Individual Market Plans 90 19.55% To calculate Federal costs for MA organizations, we use the CMS internal data used to produce the CMS Trustees’ Report. This internal data indicates that the Trust Fund will pay about 33 to 34 percent of plan costs over the next 10 years. The remaining costs (for the 98 to 99 percent of plans bidding below the benchmark) are borne by the plans. In a similar manner, we can calculate the Federal Medicaid payments using the percentages in Table 26. 2023 2024 2025 2026 2027 2028 2029 2030 2031 2032 57.8% 58.6% 59.0% 59.6% 60.0% 60.6% 61.1% 61.4% 61.8% 62.3% 65.4% 66.0% 65.9% 65.9% 65.8% 65.6% 65.5% 65.4% 65.3% 65.2% 75.8% 69.7% 69.6% 69.6% 69.5% 69.3% 69.2% 69.1% 69.0% 68.9% *MC stands for managed care. Data obtained from CMS Office of the Actuary. VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 PO 00000 Frm 00116 Fmt 4701 Sfmt 4725 E:\FR\FM\13DEP2.SGM 13DEP2 EP13DE22.027</GPH> Year MC* share of Medicaid Federal share of Medicaid MC* Weighted cost bv vear EP13DE22.026</GPH> lotter on DSK11XQN23PROD with PROPOSALS2 TABLE 26: PERCENT OF COST INCURRED BY THE FEDERAL GOVERNMENT FOR MEDICAID SPENDING Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules lotter on DSK11XQN23PROD with PROPOSALS2 Table 25 is based on the most recent projections of the CMS Office of the Actuary (OACT) for the Mid-Session Review of the President’s FY 2022 Budget (MSR 2022). We illustrate in the 2025 column that 41 percent (1¥0.59 shown in the second row) of Federal Government payments go to the states for expenditures related to their Medicaid FFS programs and 59 percent (the number shown in the second row) goes to states for their Medicaid managed care programs. For state expenditures on Medicaid mechanized claims processing and information retrieval systems, the Federal Government pays states 90 percent of their expenditures on the VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 design, development, installation, or enhancement of such systems, and 75 percent of their expenditures on the ongoing operation of such systems. For 2025, states receive an average of 65.9 percent FMAP for their managed care program costs as shown on the third row. Therefore, the percentage of costs paid in the first year by the Federal Government is 69.6 percent (75 percent × 41 percent + 65.9 percent × 59 percent) as shown in the fourth row. The calculation of the percent of costs paid in all years is done similarly except that in the first-year 90 percent is used for weighting instead of 75 percent. By applying these percentages to the total PO 00000 Frm 00117 Fmt 4701 Sfmt 4702 76353 Medicaid costs, we obtain Federal costs for the program. These percentages are used to calculate the total dollars going from the Federal Government to states. It should be noted that although the first year of implementation of this proposed rule is 2026, we expect plans to begin constructing software systems as soon as the rule is finalized in 2023. Based on the previous discussion in this proposed rule, the next section shows the calculation of all impacts of this proposed rule by program, Government, and QHP issuers. The numerical impacts are presented in Table 27. BILLING CODE 4120–01–P E:\FR\FM\13DEP2.SGM 13DEP2 lotter on DSK11XQN23PROD with PROPOSALS2 76354 Jkt 259001 Frm 00118 Fmt 4701 Sfmt 4702 13DEP2 Information section, the data in Table 27 is based on an expected publication date E:\FR\FM\13DEP2.SGM • As explained in the connection with Table 19 in the Collection of PO 00000 Year EP13DE22.028</GPH> Total Cost of Rule Total Cost to Providers and Hospitals and CAHs Total Cost to Payers Including States Cost to MA Orgs Totals 1,560 2023 0.15 Costs to Gov't by Program Total Costs by Program Cost to Medicaid Plans and States Cost to Marketplace Total Cost to Gov't by Remaining Costs to Payers Gov't Payments to MA Gov't Payments to Medicaid Gov't Payments (PTC) related to Individual Markets Remaining Cost to MAOrgs Remaining Cost to Medicaid Year Remaining Cost to Individual Markets 1,559 754 501 305 809 251 350 208 502 151 305 110 110 53 35 22 60 18 27 15 35 9 22 2024 221 221 107 71 43 114 36 49 29 71 21 43 2025 221 221 107 71 43 115 36 49 30 71 22 43 2026 155 155 75 50 30 80 25 35 20 50 15 30 2027 142 0.025 142 69 46 28 74 23 32 19 46 14 28 2028 142 0.025 142 69 46 28 73 23 32 19 46 14 28 2029 142 0.025 142 69 46 28 73 23 32 19 46 14 28 2030 142 0.025 142 69 46 28 73 23 32 19 46 14 28 2031 142 0.025 142 69 46 28 73 23 32 19 46 14 28 2032 142 0.025 142 69 46 28 73 23 31 19 46 14 28 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules BILLING CODE 4120–01–C 18:56 Dec 12, 2022 For Table 27: VerDate Sep<11>2014 TABLE 27: 10 YEAR TOTALS OF TIDS PROPOSED RULE BY YEAR, PAYER, PROGRAM, PROVIDERS, HOSPITALS, AND CAHs AND TO THE FEDERAL GOVERNMENT (MILLIONS$) Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules of the final rule is mid-year of 2023 and an effective date of January 1, 2026 for most provisions. • The bottom-line totals in the columns of Table 19 labeled ‘‘1st year cost’’ through ‘‘5th Year Cost’’ are the totals found in the ‘‘Total Cost’’ column of Table 26 in rows 2023 through 2027 respectively. The totals in the column ‘‘Subsequent year costs’’ in Table 19 are found in the rows labeled 2028 through 2032 in the ‘‘Total Cost’’ column of Table 27. • The Total Cost to Providers and Hospitals and CAHs column reflects the aggregate cost of producing reports for MIPS eligible individual providers, provider groups, hospitals, and CAHs, as found in Table 19 for years 2026 and further. • The total 10-year cost (excluding PTC payments and savings from prior authorization) is, as shown in Table 27, $1.6 billion. This number uses the primary estimates for the API provisions. The low and high 10-year total costs are $0.8 billion and $2.3 billion, respectively. • Cost of Proposed Rule to Payers by Program columns: We applied the percentages from Table 25 to obtain the cost of the rule to payers by program (MA, Medicaid, CHIP, and QHP issuers on the FFEs). • Cost of Proposed Rule to Government by Program columns: We applied the percentages of payment by the Federal Government discussed in the narrative on Table 26 to obtain the cost by program. • PTC Payments: The Government does not reimburse QHPs, either partially or totally, nor prospectively or retrospectively, for their expenses in furnishing health benefits. However, the Government does offer QHP enrollees PTC credits to help cover the cost of premiums for the plans. QHP issuers on the FFEs have the option to deal with increased costs by either temporarily absorbing them (for purposes of market competitiveness—see, however, a caveat elsewhere in this regulatory impact analysis), increasing premiums to enrollees, or reducing non-essential health benefits. To the extent that issuers increase premiums for individual market-qualified health plans on the FFEs, there would be Federal PTC impacts. The purpose of the PTC is to assist enrollees in paying premiums. Since PTCs are only available if an individual purchases a qualified health plan on an Exchange and the individual has an income between 100 and 400 percent of the Federal Poverty Level, the PTC estimates apply only to Exchange plans. In the PTC estimate, we have accounted for the fact that some issuers have both Exchange and non-Exchange plans, and some issuers have only nonExchange plans. We reflected these assumptions with global adjustments, so we believe the estimates are reasonable in aggregate. The methodology to estimate the PTC impact of the projected expense burden is consistent with the method used to estimate the PTC impact in the CMS Interoperability and Patient Access final rule (85 FR 25612). Within the FFE states, the estimated expense burden would impact premium rates in the individual market and is spread across both Exchange and non-Exchange plans. PTCs are only paid in the Exchanges and are calculated as a function of the second lowest cost silver plan and the 76355 eligible individual’s household income. The estimate of these impacts uses the assumption that the industry would increase the second lowest cost silver plan premium rate in the same amount as the overall premium rate increase. This assumption allows the application of the overall rate increase to the projected PTC payments in the FFE states to estimate the impact on PTC payments. The PTC payments are currently slightly over 50 percent of total costs. The total cost to the Government is the sum of payments related to each program. This payment is a transfer from the Government to payers for Medicare Advantage and Medicaid, CHIP, and QHP enrollees. • Remaining Cost to Payers columns: For MA organizations, and Medicaid and CHIP, the remaining costs are the difference between the total cost to payers and what the Federal Government pays. For the individual market, the remaining costs to payers would be the total cost absorbed by the payers and not passed on through premium increases. Since the PTC is paid on behalf of individuals and not the payers, it therefore does not reduce the expenses of the payers. Note: The dollar savings from reduced paperwork burden for an increase in use of electronic prior authorization (Tables 22 through Table 24) is not included in Table 27. We next explain how the various plans (and states) would bear the costs remaining after Federal payments. We follow the same methodology and discussion presented in the CMS Interoperability and Patient Access final rule (85 FR 25612). TABLE 28: HOW PAYERS COULD DEFRAY REMAINING COSTS Program lotter on DSK11XQN23PROD with PROPOSALS2 Medicaid/CHIP Medicare Advantage (MA) VerDate Sep<11>2014 QHPs generally have the option of absorbing costs (for example, for reasons of market competitiveness-see, however, a caveat elsewhere in this regulatory impact analysis), increasing premiums to enrollees, or reducing covered non-essential health benefits. Cost would be spread over all parent organization enrollees in a specified state and the individual market in FFE states. As proposed, small commercial QHP issuers on the FFEs may request an exception to the proposed API provisions. To the extent that QHP issuers increase premiums in 2025 and beyond to offset the cost of complying with this proposed rule, such premium increases would be a shift of who bears the cost from QHP issuers to enrollees and a subsequent shift from enrollees to the Federal Governrnent in the form of increased PTC payment. 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. Under certain circumstances, states operating Medicaid and CHIP FFS programs can request an extension or an exemption from the proposed API provisions. 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 regulatory impact analysis); (2) reducing supplemental benefits paid for by the rebates; or (3) raising enrollee cost sharing (or reduce additional, rebate-funded benefits). Tax deferment and amortization as applicable ameliorates cost. Capital costs are spread over entire parent organization enrollees. New plans are allowed to enter with initial negative margins with the expectation that thev will stabilize over the first few vears. 18:56 Dec 12, 2022 Jkt 259001 PO 00000 Frm 00119 Fmt 4701 Sfmt 4725 E:\FR\FM\13DEP2.SGM 13DEP2 EP13DE22.029</GPH> QHP Issuers Avenues of Dealing with Remaining Costs 76356 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules In Table 28 we explain possible ways payers may manage these extra implementation costs. We emphasize that Table 28 lists possibilities. Payers would ultimately make decisions about how to defray these remaining costs based on market dynamics and internal business decisions, and we have no uniform way of predicting what these actual behaviors and responses will be. Individual Market Plans: Individual market plans have the option of absorbing costs or passing costs to enrollees either in the form of higher premiums or reduced benefits that are non-essential health benefits (EHBs). CMS has seen in some cases that plans, for reasons of market competitiveness, will absorb costs rather than increase premiums or reduce benefits. The temporary claim refers to the possibility that plans will balance competitive pressures with profit targets immediately following a new regulation. As the regulations are typically finalized within a few months of the bid submission deadline, plans may have more time to enact strategies that do not require large benefit changes in subsequent years, such as negotiations for supplemental benefit offerings. Medicaid and CHIP: Assuming roughly 71 million enrollees nationally (inclusive of Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities), Medicaid and CHIP would see an added cost of under a dollar per beneficiary per year; this contrasts with a total cost per beneficiary per year for the Medicaid and CHIP programs of several thousand dollars.193 Medicare Advantage: In their bids (submitted the June prior to the beginning of the coverage year), Medicare Advantage plans would address the reduced rebates (arising from increased bid costs due to the increased costs of this proposed rule being included in the bid) by either: temporarily absorbing costs by reducing profit margins, reducing the supplemental benefits paid for by the rebates, or raising enrollee cost sharing or premium. We believe many plans, for competitive reasons, would choose to retain a zero-dollar premium increase and either absorb losses for 1 year or reduce rebate-funded supplemental benefits. I. Accounting Statement and Table As required by OMB Circular A–4 (available at https:// www.whitehouse.gov/sites/ whitehouse.gov/files/omb/circulars/A4/ a-4.pdf), we have prepared an accounting statement in Table 29 showing the classification of annualized costs associated with the provisions of this proposed rule for the 10-year period 2023 through 2032. This accounting table is based on Table 27 and includes the costs of this proposed rule to certain providers, including hospitals and CAHs, Medicare Advantage plans, Medicaid and CHIP state entities, and issuers offering QHPs on the FFEs. It does not include the potential savings (Tables 23 and 24) arising from reduced burden due to providers, hospitals, and CAHs using electronic prior authorization. Table 29 is stated in 2023 dollars reflecting the expected first half year that these provisions would begin to be implemented (primarily by building systems). TABLE 29: ACCOUNTING TABLE (MILLIONS$) Annualized Monetized Cost(as positive numbers in 2023 dollars), Low Estimate Discount Rate Annualized at 7% Annualized Monetized Cost (as positive numbers in 2023 dollars), Primary Estimate 81.1 Annualized at 3% Annualized Monetized Cost (as positive numbers in 2023 dollars), High Estimate 158.2 80.6 157.0 Period Who is Impacted 235.2 Contract Years 2023-2032 State Medicaid and CHIP entities; Medicare Advantage plans, Individual market plans 233.3 Contract Years 2023-2032 State Medicaid and CHIP entities; Medicare Advantage plans, Individual market plans Transfers (PTC Payments) Annualized transfer (In 2023 dollars) Annualized at 7% 21.1 2023-2032 Annualized at 3% 20.9 2023-2032 In accordance with the provisions of Executive Order 12866, this proposed rule was reviewed by OMB. VI. Response to Comments Because of the large number of public comments, we normally receive on 193 Centers for Medicare & Medicaid Services Newsroom. Medicaid Facts and Figures | CMS VerDate Sep<11>2014 Period 18:56 Dec 12, 2022 Jkt 259001 From whom to whom Federal Government to enrollees Federal Government to enrollees Federal Register documents, we are not able to acknowledge or respond to them individually. We will consider all comments we receive by the date and time specified in the DATES section of this preamble, and, when we proceed with a subsequent document, we will respond to the comments in the preamble to that document. Chiquita Brooks-LaSure, Administrator of the Centers for Medicare & Medicaid Services, approved this document on November 23, 2022. (2020, January 30). Retrieved from https:// www.cms.gov/newsroom/fact-sheets/medicaidfacts-and-figures. PO 00000 Frm 00120 Fmt 4701 Sfmt 4702 E:\FR\FM\13DEP2.SGM 13DEP2 EP13DE22.030</GPH> lotter on DSK11XQN23PROD with PROPOSALS2 Disconnt Rate Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules 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. lotter on DSK11XQN23PROD with PROPOSALS2 45 CFR Part 156 Administrative practice and procedure, Advertising, Brokers, Conflict of interests, Consumer protection, Grant programs-health, Grants administration, Health care, Health insurance, Health maintenance organizations (HMO), Health records, Hospitals, Indians, Individuals with disabilities, Intergovernmental relations, Loan programs-health, Medicaid, Organization and functions (Government agencies), Prescription drugs, Public assistance programs, Reporting and recordkeeping requirements, Technical assistance, Women, Youth. For the reasons set forth in the preamble, the Centers for Medicare & Medicaid Services proposes to amend 42 CFR chapter IV and the Department of Health and Human Services proposes to amend 45 CFR part 156 as set forth below: Title 42—Public Health PART 422—MEDICARE ADVANTAGE PROGRAM 1. The authority citation for part 422 continues to read as follows: ■ Authority: 42 U.S.C. 1302 and 1395hh. VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 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: ■ ■ § 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 at 45 CFR 170.213, if the MA organization maintains any such data, no later than 1 business day after the MA organization receives the data; and (iv) Beginning January 1, 2026, the information in paragraph (b)(1)(iv)(A) of this section about prior authorizations for items and services (excluding drugs, as defined at 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 and related administrative and clinical documentation, including all of the following, as applicable: (1) The status of the prior authorization. (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 and the quantity used to date. (5) If denied, a specific reason why the request was denied. (B) The information in paragraph (b)(1)(iv)(A) of this section must be accessible no later than 1 business day after the MA organization receives a prior authorization request, and must be updated no later than 1 business day after any change in status. All information must continue to be accessible for the duration that the authorization is active and at least 1 year from the date of 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. * * * * * (c) * * * (1) Must use API technology conformant with 45 CFR 170.215(a) through (3) and (b); * * * * * (4) * * * (ii) * * * (C) Using the updated version of the standard, implementation guide, or PO 00000 Frm 00121 Fmt 4701 Sfmt 4702 76357 specification does not disrupt an end user’s ability to access the data described 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 applications and developers through which parties seek to access electronic health information, as defined at 45 CFR 171.102, including but not limited to criteria that may rely on automated monitoring and risk mitigation tools. (f) Reporting on the use of the Patient Access API. Beginning in 2026, by March 31 following any calendar year that an MA organization operates, the MA organization must report to CMS the following metrics, in the form of aggregated, de-identified data, for the previous calendar year at the organization level: (1) The total number of unique enrollees whose data are transferred via the Patient Access API to a health app designated by the enrollee; and (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 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 January 1, 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 to providers and payers. (a) Application Programming Interface to support data transfer from payers to providers—Provider Access API. Beginning January 1, 2026, an MA organization must: (1) Accessible content and API requirements. Implement and maintain a standards-based Application Programming Interface (API) compliant with § 422.119(c), (d), and (e), as well as the standard at 42 CFR 170.215(a)(4), that complies with the following: (i) API requirements and accessible content. Make data specified in paragraph (a)(1)(ii) of this section available to in-network providers no later than 1 business day after receiving E:\FR\FM\13DEP2.SGM 13DEP2 lotter on DSK11XQN23PROD with PROPOSALS2 76358 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules a request from such a provider, if all the following conditions are met: (A) The MA organization authenticates the identity of the provider that requests access using the required authorization and authentication protocols at 45 CFR 170.215(b) and attributes the enrollee to the provider under the attribution process required in paragraph (a)(2) of this section. (B) The enrollee does not opt out per paragraph (a)(3) of this section. (C) Disclosure of the data is permitted by applicable law. (ii) Individual enrollee data. Make the data available specified at § 422.119(b) with a date of service on or after January 1, 2016, excluding provider remittances and enrollee cost-sharing information, if maintained by the MA organization. (2) Attribution. Maintain a process to associate enrollees with their innetwork providers to enable payer-toprovider data exchange via the Provider Access API. (3) Opt Out and patient educational resources. (i) Maintain a process to allow an enrollee or the enrollee’s personal representative to opt out of and subsequently opt into the data sharing requirements specified in paragraph (a)(1) of this section. 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 non-technical, simple and easy-tounderstand 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 opting in after previously opting out: (A) Before the first date on which the MA organization makes enrollee information available through the Provider Access API; and (B) At enrollment; and (C) At least annually; and (D) In an easily accessible location on its public website. (4) Provider resources regarding APIs. Provide on its website and through other appropriate provider communications, educational resources in non-technical and easy-to-understand language explaining the process for requesting enrollee data using the Provider Access API described at paragraph (a)(1) of this section. The resources must include information about how to use the MA organization’s attribution process to associate patients with the provider. VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 (b) Application Programming Interface to support data transfer between payers—Payer-to-Payer API. Beginning January 1, 2026: (1) API requirements and accessible content. An MA organization must implement and maintain an API that— (i) Is compliant with § 422.119(c), (d), and (e), as well as the standard at 42 CFR 170.215(a)(4); and (ii) Makes available the data specified at § 422.119(b) with a date of service on or after January 1, 2016, excluding provider remittances and enrollee costsharing, if maintained by the MA organization. (2) Opt in. An MA organization must establish and maintain a process to allow enrollees or their personal representatives to opt in to the MA organization’s Payer-to-Payer API data exchange with the enrollee’s previous payer, described in paragraph (b)(4) of this section, and with concurrent payer(s), described in paragraph (b)(5) of this section, and to allow enrollees to change their preference 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 enrollment. (ii) [Reserved] (3) Identify previous and/or concurrent payers. An MA organization must maintain a process to identify a new enrollee’s previous and/or concurrent payer(s) to facilitate the Payer-to-Payer API data exchange. The information request process must take place: (i) For current enrollees, no later than the compliance date. (ii) For new enrollees, no later than enrollment. (4) Data exchange requirement. (i) An MA organization must request the data specified in paragraph (b)(1)(ii) of this section from the enrollee’s previous payer through the standards-based API described in paragraph (b)(1) of this section, if the enrollee has opted in as described in paragraph (b)(2) of this section, and as permitted by applicable law. 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. The MA organization must complete this request: (A) For new enrollees, no later than 1 week after the start of coverage. (B) At an enrollee’s request, within 1 week of the request. (C) For an enrollee who opts in or provides previous and/or concurrent payer information after enrollment, within 1 week. PO 00000 Frm 00122 Fmt 4701 Sfmt 4702 (ii) The MA organization must incorporate into the enrollee’s record any data received from other payers in response to the request. (iii) The MA organization must make data specified in paragraph (b)(1)(ii) of this section available to other payers via the standards-based API described in paragraph (b)(1) of this section within 1 business day of receiving a request if all the following conditions are met: (A) The payer that requests access has its identity authenticated using the authorization and authentication protocols at 45 CFR 170.215(b) and includes an attestation with the request that the patient is enrolled with the payer and has opted in to the data exchange. (B) Disclosure of the data is not prohibited by law. (5) Concurrent coverage data exchange requirement. When an enrollee has provided concurrent coverage information per paragraph (b)(3) of this section, and has opted in per paragraph (b)(2) of this section, an MA organization must, through the standards-based API described in paragraph (b)(1) of this section: (i) No later than 1 week after enrollment, and then at least quarterly, request the enrollee’s data from all known concurrent payers in accordance with paragraphs (b)(4)(i) and (ii) of this section. (ii) Within 1 business day of a request from any concurrent payers, respond in accordance with paragraph (b)(4)(iii) of this section. (6) Educational materials. An MA organization must provide information to enrollees in non-technical, simple, and easy-to-understand language, explaining at a minimum: the benefits of Payer-to-Payer API data exchange, their ability to opt in or withdraw a previous opt in decision, and instructions for doing so. The MA organization must provide these materials— (i) At or before requesting an enrollee’s consent 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; and (iii) In an easily accessible location on its public website. ■ 4. Section 422.122 is added to read as follows: § 422.122 Prior authorization requirements. (a) Communicating prior authorization status to providers, including reason for denial. Beginning January 1, 2026, MA organizations must E:\FR\FM\13DEP2.SGM 13DEP2 lotter on DSK11XQN23PROD with PROPOSALS2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules provide specific information about prior authorization requests (excluding drugs as defined at § 422.119(b)(1)(v)) to providers, regardless of the method used to communicate that information, in a manner that is consistent with the following requirements: (1) The MA organization’s prior authorization response to the provider must indicate whether the MA organization approves the prior authorization request (and for how long), denies the prior authorization request, or requests more information related to the prior authorization request. (2) If the MA organization denies the prior authorization request, the response to the provider must include a specific reason for the denial. (b) Prior authorization requirements, documentation and decision (PARDD) Application Programming Interface (API). Beginning January 1, 2026, an MA organization must implement and maintain a standards-based API compliant with § 422.119(c), (d), and (e) that— (1) Is populated with the MA organization’s list of covered items and services (excluding drugs, as defined at § 422.119(b)(1)(v)) for which prior authorization is required, and any documentation requirements for the authorization; (2) Include functionality to determine requirements for any other data, forms or medical record documentation required by the MA organization for the items or services for which the provider is seeking prior authorization; (3) Facilitates a Health Insurance Portability and Accountability Act (HIPAA)-compliant prior authorization request and response; and (4) Includes the information required at § 422.122(a). (c) Publicly reporting prior authorization metrics. Beginning in 2026, following each calendar year that it operates, an MA organization must report prior authorization data, excluding data on drugs, as defined at § 422.119(b)(1)(v), at the organization level by March 31. The MA organization must make the following data from the previous calendar year publicly accessible by posting it directly on its website or via hyperlink(s): (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. VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 (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— ■ 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: (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. When the MA organization extends the timeframe, it must notify the enrollee in writing of the reasons for the delay, and inform the enrollee of the right to file an expedited grievance if he or she disagrees with the MA organization’s decision to grant an extension. The MA organization must notify the enrollee of its determination as expeditiously as the enrollee’s health 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.568 Standard timeframes and notice requirements for organization determinations. § 422.631 Integrated 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 and either of the following: (i) No later than 14 calendar days after receiving the request for the standard organization determination; or (ii) On or after January 1, 2026, for a service or item subject to the prior authorization rules at § 422.122, no later than 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. PO 00000 Frm 00123 Fmt 4701 Sfmt 4702 76359 * * * * (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 and either of the following: (1) No later than 14 calendar days after receiving the request for the standard integrated organization determination; or (2) On or after January 1, 2026, for a service or item subject to the prior authorization rules at § 422.122, no later than 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 E:\FR\FM\13DEP2.SGM 13DEP2 76360 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules timeframe established in paragraph (d)(2)(i) 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: ■ Authority: 42 U.S.C. 1302. 9. Section 431.60 is amended by— a. Revising paragraph (b)(3); b. Adding paragraphs (b)(5) and (6); c. Revising paragraphs (c)(1), (c)(4)(ii)(C), and (e)(2); ■ d. Adding paragraph (h). The revisions and addition read as follows: ■ ■ ■ ■ § 431.60 Beneficiary access to and exchange of data. lotter on DSK11XQN23PROD with PROPOSALS2 * * * * * (b) * * * (3) All data classes and data elements included in a content standard at 45 CFR 170.213, if the State maintains any such data, no later than 1 business day after the State receives the data; and * * * * * (5) Beginning January 1, 2026, the information in paragraph (b)(5)(i) of this section about prior authorizations for items and services (excluding drugs as defined at 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 and related administrative and clinical documentation, including all of the following, as applicable: (A) The status of the prior authorization. (B) The date the prior authorization was approved or denied. (C) The date or circumstance under which the authorization ends. (D) The items and services approved and the quantity used to date. (E) If denied, a specific reason why the request was denied. (ii) The information in paragraph (b)(5)(i) of this section must be accessible no later than 1 business day after the State receives a prior authorization request, and must be updated no later than 1 business day after any change in status. All information must continue to be VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 accessible for the duration that the authorization is active and at least 1 year from the date of the prior authorization’s last status change. (6) Drugs are defined for purposes of paragraph (b)(5) of this section as any and all drugs covered by the State. * * * * * (c) * * * (1) Must use API technology conformant with 45 CFR 170.215(a)(1) through (3) and (b); * * * * * (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 described 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 applications and developers through which parties seek to access electronic health information, as defined at 45 CFR 171.102, including but not limited to criteria that may rely on automated monitoring and risk mitigation tools. * * * * * (h) Reporting on the use of the Patient Access API. 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: (1) The total number of unique beneficiaries whose data are transferred via the Patient Access API to a health app designated by the beneficiary. (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. ■ 10. Section 431.61 is added to read as follows: § 431.61 Access to and exchange of health data to providers and payers. (a) Application Programming Interface to support data transfer from payers to providers—Provider Access API. Beginning January 1, 2026, unless granted an extension or exemption under paragraph (c) of this section, a State must do the following: (1) Accessible content and API requirements. Implement and maintain a standards-based Application Programming Interface (API) compliant with § 431.60(c), (d), and (e), as well as the standard at 42 CFR 170.215(a)(4), that complies with the following: PO 00000 Frm 00124 Fmt 4701 Sfmt 4702 (i) API requirements and accessible content. Make data specified in paragraph (a)(1)(ii) of this section available to enrolled Medicaid providers no later than 1 business day after receiving a request from such a provider, if all the following conditions are met: (A) The State authenticates the identity of the provider that requests access using the required authorization and authentication protocols at 45 CFR 170.215(b) and attributes the beneficiary to the provider under the attribution process required in paragraph (a)(2) of this section. (B) The beneficiary does not opt out per paragraph (a)(3) of this section. (C) Disclosure of the data is permitted by applicable law. (ii) Individual beneficiary data. Make available the data specified at § 431.60(b) with a date of service on or after January 1, 2016, excluding provider remittances and beneficiary cost-sharing information, if maintained by the State. (2) Attribution. Maintain a process to associate beneficiaries with their Medicaid-enrolled providers to enable payer-to-provider data exchange via the Provider Access API. (3) Opt out and patient educational resources. (i) Maintain a process to allow a beneficiary or the beneficiary’s personal representative to opt out of or subsequently opt into the data sharing requirements specified in paragraph (a)(1) of this section. 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 non-technical, simple, and easy-to-understand 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 opting in after previously opting out— (A) Before the first date on which the State makes beneficiary information available through the Provider Access API; (B) At enrollment; (C) At least annually; and (D) In an easily accessible location on its public website. (4) Provider resources regarding APIs. Provide on its website and through other appropriate provider communications, educational resources in non-technical and easy-to-understand language explaining the process for requesting beneficiary data using the Provider Access API described in paragraph (a)(1) of this section. The E:\FR\FM\13DEP2.SGM 13DEP2 lotter on DSK11XQN23PROD with PROPOSALS2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules resources must include information about how to use the State’s attribution process to associate patients with the provider. (b) Application Programming Interface to support data transfer between payers—Payer-to-Payer API. Beginning January 1, 2026, unless granted an extension or exemption under paragraph (c) of this section: (1) Accessible content and API requirements. A State must implement and maintain an API that— (i) Is compliant with § 431.60(c), (d), and (e), as well as the standard at 42 CFR 170.215(a)(4); and (ii) Makes available the data specified at § 431.60(b) with a date of service on or after January 1, 2016, excluding provider remittances and beneficiary cost-sharing, if maintained by the State. (2) Opt in. A State must establish and maintain a process to allow beneficiaries or their personal representatives to opt in to the State’s Payer-to-Payer API data exchange with the beneficiary’s previous payer(s), described in paragraph (b)(4) of this section, and concurrent payer(s), described in paragraph (b)(5) of this section, and to allow beneficiaries to change their preference at any time. (i) The opt in process must be offered: (A) To current beneficiaries, no later than the compliance date. (B) To new beneficiaries, no later than enrollment. (ii) If a beneficiary has coverage through any Medicaid managed care plans within the same State while enrolled in Medicaid, the State must share their opt in preference with those managed care plans to allow the Payerto-Payer API data exchange described in this section. (3) Identify previous and/or concurrent payers. A State must maintain a process to identify a new beneficiary’s previous and/or concurrent payer(s) to facilitate the Payer-to-Payer API data exchange. The information request process must take place: (i) For current beneficiaries, no later than the compliance date. (ii) For new beneficiaries, no later than enrollment. (4) Data exchange requirement. (i) A State must request the data specified in paragraph (b)(1)(ii) of this section from the beneficiary’s previous payer through the standards-based API described in paragraph (b)(1) of this section, if the beneficiary has opted in as described in paragraph (b)(2) of this section, and as permitted by applicable law. The State must include an attestation with this request affirming that the beneficiary is enrolled with the State and has opted VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 into the data exchange. The State must complete this request: (A) For new beneficiaries, no later than 1 week after enrollment. (B) At a beneficiary’s request, within 1 week of the request. (C) For a beneficiary who opts in or provides previous and/or concurrent payer information after enrollment, within 1 week. (ii) The State must incorporate into the beneficiary’s record any data received from other payers in response to the request. (iii) The State must make data specified in paragraph (b)(1)(ii) of this section available to other payers via the standards-based API described in paragraph (b)(1) of this section within 1 business day of receiving a request if all the following conditions are met: (A) The payer that requests access has its identity authenticated using the authorization and authentication protocols at 45 CFR 170.215(b) and includes an attestation with the request that the patient is enrolled with the payer and has opted in to the data exchange. (B) Disclosure of the data is not prohibited by law. (5) Concurrent coverage data exchange requirement. When a beneficiary has provided concurrent coverage information, per paragraph (b)(3) of this section, and has opted in per paragraph (b)(2) of this section, a State must, through the standards-based API described in paragraph (b)(1) of this section: (i) No later than one week after enrollment, and then at least quarterly, request the beneficiary’s data from all known concurrent payers in accordance with paragraph (b)(4)(i) and (ii) of this section; and (ii) Within one business day of a request from any concurrent payers, respond in accordance with paragraph (b)(4)(iii) of this section. (6) Educational materials. A State must provide information to applicants or beneficiaries in non-technical, simple, and easy-to-understand language, explaining at a minimum: the benefits of Payer-to-Payer API data exchange, their ability to opt in or withdraw a previous opt in decision, and instructions for doing so. The State must provide these materials: (i) At or before requesting a beneficiary’s consent 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; and PO 00000 Frm 00125 Fmt 4701 Sfmt 4702 76361 (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 to delay implementation of the requirements in paragraphs (a) and/or (b) of this section, for a one-time, one-year extension for its Medicaid 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 and must include all the following: (A) A narrative justification describing the specific reasons why the State cannot reasonably satisfy the requirement(s) by the compliance date and why those reasons result from circumstances that are unique to the agency operating the Medicaid fee-for service program; (B) A report on completed and ongoing State implementation activities that evidence a good faith effort towards compliance; and (C) A comprehensive plan to meet implementation requirements no later than 1 year after the compliance date. (ii) CMS will grant the State’s request if it determines based on the information provided in the State’s annual Advance Planning Document (APD) for Medicaid Management Information System (MMIS) operations expenditures that the request adequately establishes a need to delay implementation; and that the State has a comprehensive plan to implement 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, may request an exemption for its fee-for-service program from the requirement(s) in paragraphs (a) and/or (b) of this section. (A) The exemption request must be submitted in writing as part of a State’s annual Advance Planning Document (APD) for Medicaid Management Information System (MMIS) operations expenditures prior to the date by which the state would otherwise need to comply with the applicable requirement. (B) The State’s request must include documentation that the State meets the criteria for the exemption, based on enrollment data from the most recent CMS ‘‘Medicaid Managed Care Enrollment and Program Characteristics’’ report, and must also include information about an alternative E:\FR\FM\13DEP2.SGM 13DEP2 76362 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules plan to ensure that enrolled providers will have efficient electronic access to the same information through other means while the exemption is in effect. (ii) CMS will grant the 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. (iii) The State’s exemption would expire if: (A) Based on the 3 previous years of available, finalized Medicaid Transformed Medicaid Statistical Information System (T–MSIS) managed care and fee-for-service (FFS) enrollment data, the State’s managed care enrollment for 2 of the previous 3 years is below 90 percent; or (B) CMS has approved a State plan amendment, waiver, or waiver amendment that would significantly reduce the share of beneficiaries enrolled in managed care and the anticipated shift in enrollment is confirmed by the first available, finalized Medicaid T–MSIS managed care and FFS enrollment data. (iv) If a State’s exemption expires per paragraph (c)(2)(iii) of this section, the State would be required to— (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 or approval of a State plan amendment, waiver, or waiver amendment confirming 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; and (B) Obtain CMS approval of a timeline for compliance with the requirements at paragraphs (a) and/or (b) of this section within two years of the expiration of the exemption. ■ 11. Section 431.80 is added to subpart B to read as follows: lotter on DSK11XQN23PROD with PROPOSALS2 § 431.80 Prior authorization requirements. (a) Communicating prior authorization statuses to providers, including reason for denial. Beginning January 1, 2026, States must provide specific information about prior authorization requests (excluding drugs, as defined at § 431.60(b)(6)) to providers, regardless of the method used to communicate that information, in a manner that is consistent with the following requirements: VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 (1) The State’s prior authorization response to the provider must indicate whether the State approves the prior authorization request (and for how long), denies the prior authorization request, or requests more information related to the prior authorization request. (2) If the State denies the prior authorization request, the response to the provider must include a specific reason for the denial. (b) Prior authorization requirements, documentation and decision (PARDD) Application Programming Interface (API). Unless granted an extension or exemption under paragraph (c) of this section, beginning January 1, 2026, a State must implement and maintain a standards-based API compliant with § 431.60(c), (d), and (e) that: (1) Is populated with the State’s list of covered items and services (excluding drugs, as defined at § 431.60(b)(6)) for which prior authorization is required, and any documentation requirements for the authorization; (2) Includes functionality to determine requirements for any other data, forms or medical record documentation required by the State for the items or services for which the provider is seeking prior authorization; (3) Facilitates a Health Insurance Portability and Accountability Act (HIPAA)-compliant prior authorization request and response; and (4) Includes the information required at paragraph (a) of this section. (c) Extensions and exemptions—(1) Extension. (i) A State may submit a written application to request to delay implementation of the requirements in paragraph (b) of this section, for a onetime, one-year extension for its Medicaid 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 and must include all the following: (A) A narrative justification describing the specific reasons why the State cannot reasonably satisfy the requirement(s) by the compliance date and explaining why those reasons result from circumstances that are unique to the agency operating the Medicaid feefor service program; (B) A report on completed and ongoing State implementation activities that evidence a good faith effort towards compliance; and (C) A comprehensive plan to meet implementation requirements no later than 1 year after the compliance date. PO 00000 Frm 00126 Fmt 4701 Sfmt 4702 (ii) CMS will grant the State’s request if it determines based on the information provided in the State’s annual Advance Planning Document for MMIS operations expenditures that the request adequately establishes a need to delay implementation; and that the State has a comprehensive plan to implement 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, may request an exemption for its fee-for-service program from the requirements in paragraph (b) of this section. (A) The exemption request must be submitted in writing as part of a State’s annual Advance Planning Document for Medicaid Management Information System (MMIS) operations expenditures prior to the date by which the state would otherwise need to comply with the applicable requirement. (B) The State’s request must include documentation that demonstrates that the State meets the criteria for the exemption, based on enrollment data from the most recent CMS ‘‘Medicaid Managed Care Enrollment and Program Characteristics’’ report, and must also include information about an alternative plan to ensure that enrolled providers will have efficient electronic access to the same information through other means while the exemption is in effect. (ii) CMS will grant the 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 there will be efficient electronic access the same information through alternative means while the exemption is in effect. (iii) The State’s exemption would expire if: (A) Based on the 3 previous years of available, finalized Medicaid 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) CMS has approved a State plan amendment, waiver, or waiver amendment that would significantly reduce the share of beneficiaries enrolled in managed care, and the anticipated shift in enrollment is confirmed by the first available, finalized Medicaid T–MSIS managed care and FFS enrollment data. (iv) If a State’s exemption expires per paragraph (c)(2)(iii) of this section, the State would be required to: E:\FR\FM\13DEP2.SGM 13DEP2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules (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 confirming that there has been a shift from managed care enrollment to FFS enrollment resulting in the State’s managed care enrollment falling below the 90 percent threshold; and (B) Obtain CMS approval of a timeline for compliance with the requirements at paragraph (b) of this section within two 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: (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 enrollee liability, including a determination that an enrollee 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 an enrollee 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 with regard to 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. lotter on DSK11XQN23PROD with PROPOSALS2 18:56 Dec 12, 2022 Jkt 259001 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) 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 a new paragraph (f). The addition and revision read as follows: ■ * Coverage and authorization of * * * * 14. The authority citation for part 435 is revised to read as follows: VerDate Sep<11>2014 (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 435—ELIGIBILITY IN THE STATES, DISTRICT OF COLUMBIA, THE NORTHERN MARIANA ISLANDS, AND AMERICAN SAMOA Authority: 42 U.S.C. 1302. § 435.917 Notice of agency’s decision concerning eligibility, benefits, or services. § 438.210 services. (a) * * * (1) * * * (vi) A prior authorization decision. * * * * * ■ 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: ■ ■ * * * * (d) * * * (1) Standard authorization decisions. (i) For standard authorization decisions, provide notice as expeditiously as the enrollee’s condition requires and either of the following, as appropriate: (A) For rating periods that start before January 1, 2026, within State- PO 00000 Frm 00127 Fmt 4701 Sfmt 4702 76363 established timeframes that may not exceed 14 calendar days after receiving the request. (B) For rating periods that start on or after January 1, 2026, within Stateestablished timeframes that may not exceed 7 calendar days after receiving the request. (ii) Standard authorization decisions may have an extension to the timeframes in paragraph (d)(1)(i) of this section may have a possible extension of 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 within Stateestablished timeframes that are no later than 72 hours after receipt of the request for service unless a shorter minimum time frame is established under State law. * * * * * (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 it directly on its website or via hyperlink(s): (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 E:\FR\FM\13DEP2.SGM 13DEP2 76364 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules 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) and (8) to read as follows: § 438.242 Health information systems. lotter on DSK11XQN23PROD with PROPOSALS2 * * * * * (b) * * * (5) Subject to paragraph (b)(8) of this section, implement and maintain a Patient Access Application Programming Interface (API) as specified 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 and § 438.3(s). (iii) Report metrics specified at § 431.60(h) of this chapter at the plan level. * * * * * (7) By the rating period beginning on or after January 1, 2026, comply with §§ 431.61(a), (b)(1), (4), and (5), and (b)(6)(ii) and (iii) and 431.80 of this chapter as if such requirements applied directly to the MCO, PIHP, or PAHP. (8) The following timeframes apply to paragraph (b)(5) of this section: (i) Except for the requirements at § 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 at § 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 VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 PAHP operates, comply with the reporting requirements at § 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 paragraphs (e) and (f) to read as follows: ■ § 440.230 Sufficiency of amount, duration, and scope. * * * * * (e) The State Medicaid agency must— (1) Beginning January 1, 2026, provide notice of prior authorization decisions for items and services (excluding drugs, as defined at § 431.60(b)(6) of this chapter) as follows: (i) For standard determinations, 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 time frame 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 time frame 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. (f) Beginning in 2026, a State must annually report prior authorization data, excluding data on drugs, as defined at § 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 it directly on its website or via hyperlink(s): (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. PO 00000 Frm 00128 Fmt 4701 Sfmt 4702 (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 Medicaid agency, 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 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)(1) to read as follows: ■ § 457.495 State assurance of access to care and procedures to assure quality and appropriateness of care. * * * * * (d) * * * (1) 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 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; and * * * * * ■ 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 E:\FR\FM\13DEP2.SGM 13DEP2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules apply to Medicaid expansion programs. Separate child health programs that provide benefits exclusively through managed care organizations may meet the requirements of §§ 457.730, 457.731, and 457.732 by requiring the managed care organizations to meet the requirements of § 457.1233(d). ■ 26. Section 457.730 is amended by— ■ a. Revising paragraph (b)(3); ■ b. Adding paragraph (b)(5) and (6); ■ c. Revising paragraphs (c)(1) and (c)(3) introductory text; ■ d. Adding paragraph (c)(3)(iii); ■ e. Revising paragraphs (c)(4) introductory text, (c)(4)(ii)(C), and (e)(2); and ■ g. Adding paragraph (h). The revisions and additions read as follows: § 457.730 Beneficiary access to and exchange of data. lotter on DSK11XQN23PROD with PROPOSALS2 * * * * * (b) * * * (3) All data classes and data elements included in a content standard at 45 CFR 170.213, if the State maintains any such data, no later than 1 business day after the State receives the data; and * * * * * (5) Beginning January 1, 2026, the information in paragraph (b)(5)(i) of this section about prior authorizations for items and services (excluding drugs as defined at 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 and related administrative and clinical documentation, including all of the following, as applicable: (A) The status of the prior authorization. (B) The date the prior authorization was approved or denied. (C) The date or circumstance under which the authorization ends. (D) The items and services approved and the quantity used to date. (E) If denied, a specific reason why the request was denied. (ii) The information in paragraph (b)(5)(i) of this section must be accessible no later than 1 business day after the State receives a prior authorization request, and must be updated no later than 1 business day after any change in status. All information must continue to be accessible for the duration that the authorization is active and at least 1 year from the date of 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) * * * VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 (1) Must use API technology conformant with 45 CFR 170.215(a)(1) through (3) and (b); * * * * * (3) Must comply with the content and vocabulary standard requirements in paragraphs (c)(3)(i) and (ii) of this section, as applicable to the data type or data element, unless alternate standards are required by other applicable law, and be conformant with the requirements in paragraphs (c)(3)(iii) of this section: * * * * * (iii) Beginning January 1, 2026, for data specified in paragraphs (b)(1) through (5) of this section. (4) May use an updated version of any standard or all standards required under paragraph (b) or (c) of this section and §§ 457.731, 457.732, and 457.760, where: * * * * * (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 described 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 applications and developers through which parties seek to access electronic health information, as defined at 45 CFR 171.102, including but not limited to criteria that may rely on automated monitoring and risk mitigation tools. * * * * * (h) Reporting on the use of the Patient Access API. 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: (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. ■ 27. Section 457.731 is added to read as follows: § 457.731 Access to and exchange of health data to providers and payers. (a) Application Programming Interface to support data transfer from payers to providers—Provider Access API. Beginning January 1, 2026, unless PO 00000 Frm 00129 Fmt 4701 Sfmt 4702 76365 granted an extension or exemption under paragraph (c) of this section, a State must: (1) Accessible content and API requirements. Implement and maintain a standards-based Application Programming Interface (API) compliant with § 457.730(c), (d), and (e), as well as the standard at 42 CFR 170.215(a)(4), that complies with the following: (i) API requirements and accessible content. Make data specified in paragraph (a)(1)(ii) of this section available to enrolled CHIP providers no later than 1 business day after receiving a request from such a provider, if all the following conditions are met: (A) The State authenticates the identity of the provider that requests access using the required authorization and authentication protocols at 45 CFR 170.215(b) and attributes the beneficiary to the provider under the attribution process required in paragraph (a)(2) of this section. (B) The beneficiary does not opt out per paragraph (a)(3) of this section. (C) Disclosure of the data is permitted by applicable law. (ii) Individual beneficiary data. Make available the data specified at § 457.730(b) with a date of service on or after January 1, 2016, excluding provider remittances and beneficiary cost-sharing information, if maintained by the State. (2) Attribution. Maintain a process to associate beneficiaries with their CHIPenrolled providers to enable payer-toprovider data exchange via the Provider Access API. (3) Opt out and patient educational resources. (i) Maintain a process to allow a beneficiary or the beneficiary’s personal representative to opt out of or subsequently opt into the data sharing requirements specified in paragraph (a)(1) of this section. 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 non-technical, simple and easy-to-understand 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 opting in after previously opting out: (A) Before the first date on which the State makes beneficiary information available through the Provider Access API; and (B) At enrollment; and (C) At least annually; and (D) In an easily accessible location on its public website. E:\FR\FM\13DEP2.SGM 13DEP2 lotter on DSK11XQN23PROD with PROPOSALS2 76366 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules (4) Provider resources regarding APIs. Provide on its website and through other appropriate provider communications, educational resources in non-technical and easy-to-understand language explaining the process for requesting beneficiary data using the Provider Access API described in paragraph (a)(1) of this section. The resources must include information about how to use the State’s attribution process to associate patients with the provider. (b) Application Programming Interface to support data transfer between payers—Payer-to-Payer API. Beginning January 1, 2026, unless granted an extension or exemption under paragraph (c) of this section: (1) Accessible content and API requirements. A State must implement and maintain an API that: (i) Is compliant with § 457.730(c), (d), and (e), as well as the standard at 42 CFR 170.215(a)(4); and (ii) Makes available the data specified at § 457.730(b) with a date of service on or after January 1, 2016, excluding provider remittances and beneficiary cost-sharing, if maintained by the State. (2) Opt in. A State must establish and maintain a process to allow beneficiaries or their personal representatives to opt in to the State’s Payer-to-Payer API data exchange with the beneficiary’s previous payer(s), described in paragraph (b)(4) of this section, and concurrent payer(s), described in paragraph (b)(5) of this section, and to allow beneficiaries to change their preference at any time. (i) The opt in process must be offered: (A) To current beneficiaries, no later than the compliance date. (B) To new beneficiaries, no later than 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 preference with those managed care entities to allow the Payer-to-Payer API data exchange described in this section. (3) Identify previous and/or concurrent payers. A State must maintain a process to identify a new beneficiary’s previous and/or concurrent payer(s) to facilitate the Payer-to-Payer API data exchange. The information request process must take place: (i) For current beneficiaries, no later than the compliance date. (ii) For new beneficiaries, no later than enrollment. (4) Data exchange requirement. (i) A State must request the data specified in paragraph (b)(1)(ii) of this section from the beneficiary’s previous payer through VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 the standards-based API described in paragraph (b)(1) of this section, if the beneficiary has opted in as described in paragraph (b)(2) of this section, and as permitted by applicable law. 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. The State must complete this request: (A) For new beneficiaries, no later than 1 week after enrollment. (B) At a beneficiary’s request, within 1 week of the request. (C) For a beneficiary who opts in or provides previous and/or concurrent payer information after enrollment, within 1 week. (ii) The State must incorporate into the beneficiary’s record any data received from other payers in response to the request. (iii) The State must make data specified in paragraph (b)(1)(ii) of this section available to other payers via the standards-based API described in paragraph (b)(1) of this section within 1 business day of receiving a request if all the following conditions are met: (A) The payer that requests access has its identity authenticated using the authorization and authentication protocols at 45 CFR 170.215(b) and includes an attestation with the request that the patient is enrolled with the payer and has opted in to the data exchange. (B) Disclosure of the data is not prohibited by law. (5) Concurrent coverage data exchange requirement. When a beneficiary has provided concurrent coverage information, per paragraph (b)(3) of this section, and has opted in per paragraph (b)(2) of this section, a State must, through the standards-based API described in paragraph (b)(1) of this section: (i) No later than one week after enrollment, and then at least quarterly, request the beneficiary’s data from all known concurrent payers in accordance with paragraphs (b)(4)(i) and (ii) of this section; and (ii) Within one business day of a request from any concurrent payers, respond in accordance with paragraph (b)(4)(iii) of this section. (6) Educational materials. A State must provide information to applicants or beneficiaries in non-technical, simple, and easy-to-understand language, explaining at a minimum: the benefits of Payer-to-Payer API data exchange, their ability to opt in or withdraw a previous opt in decision, and instructions for doing so. The State must provide these materials: PO 00000 Frm 00130 Fmt 4701 Sfmt 4702 (i) At or before requesting a patient’s consent 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; and (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 to delay implementation of the requirements in paragraphs (a) and/or (b) of this section for a one-time, one-year extension 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 and must include all the following: (A) A narrative justification describing the specific reasons why the State cannot reasonably satisfy the requirement(s) by the compliance date and explaining 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 implementation activities that evidence a good faith effort towards compliance; and (C) A comprehensive plan to meet implementation requirements no later than 1 year after the compliance date. (ii) CMS will grant the State’s request if it determines based on the information provided in the State’s annual Advance Planning Document (APD) for Medicaid Management Information System (MMIS) operations expenditures that the request adequately establishes a need to delay implementation; and that the State has a comprehensive plan to implement the requirements no later than 1 year after the compliance date. (2) Exemption. (i) A State operating a CHIP program in which at least 90 percent of the State’s CHIP beneficiaries are enrolled in managed care entities, as defined in § 457.10, may request an exemption for its fee-for-service (FFS) program from the requirements in paragraphs (a) and/or (b) of this section. (A) The exemption request must be submitted in writing as part of the State’s annual Advance Planning Document (APD) for Medicaid Management Information System (MMIS) operations expenditures prior to the date by which the state would otherwise need to comply with the applicable requirement. E:\FR\FM\13DEP2.SGM 13DEP2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules lotter on DSK11XQN23PROD with PROPOSALS2 (B) The State’s request must include documentation that the State meets the criteria for the exemption, based on enrollment data from Section 5 of the most recently accepted CHIP Annual Report Template System (CARTS), and must also include information about an alternative plan to ensure that enrolled providers will have efficient electronic access to the same information through other means while the exemption is in effect. (ii) CMS will grant the 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. (iii) The State’s exemption would expire if: (A) Based on the 3 previous years of available, finalized CHIP CARTS managed care and FFS enrollment data, the State’s managed care enrollment for 2 of the previous 3 years is below 90 percent; or (B) CMS has approved a State plan amendment, waiver, or waiver amendment that would significantly reduce the share of beneficiaries enrolled in managed care and the anticipated shift in enrollment is confirmed by the first available, finalized CARTS managed care and FFS enrollment data. (iv) If a State’s exemption expires per paragraph (c)(2)(iii) of this section, the State would be required to: (A) Submit written notification to CMS that the State no longer qualifies for the exemption within 90 days of the finalization of annual CHIP CARTS managed care enrollment data or approval of a State plan amendment, waiver, or waiver amendment confirming that there has been a shift from managed care enrollment to FFS enrollment resulting in the State’s managed care enrollment falling below the 90 percent threshold; and (B) Obtain CMS approval of a timeline for compliance with the requirements at paragraph (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 prior authorization status to provider, including reason for denial. Beginning January 1, 2026, States must provide specific information about prior authorization requests (excluding drugs as defined at § 457.730(b)(6)) to VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 providers, regardless of the method used to communicate that information, in a manner that is consistent with the following requirements: (1) The State’s prior authorization response to the provider must indicate whether the State approves the prior authorization request (and for how long), denies the prior authorization request, or requests more information related to the prior authorization request. (2) If the State denies the prior authorization request, the response to the provider must include a specific reason for the denial. (b) Prior authorization requirements, documentation and decision (PARDD) Application Programming Interface (API). Unless granted an extension or exemption under paragraph (d) of this section, beginning January 1, 2026, a State must implement and maintain a standards-based API compliant with § 457.730(c), (d), and (e) that: (1) Is populated with the State’s list of covered items and services (excluding drugs as defined at § 457.730(b)(6)) for which prior authorization is required, and any documentation requirements for the prior authorization; (2) Includes functionality to determine requirements for any other data, forms or medical record documentation required by the State for the items or services for which the provider is seeking prior authorization; (3) Facilitates a HIPAA-compliant prior authorization request and response; and (4) Includes the information required at paragraph (a) of this section. (c) Publicly reporting prior authorization metrics. Beginning in 2026, a State must annually report prior authorization data, excluding data on drugs as defined at § 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 it directly on its website or via hyperlink(s): (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 PO 00000 Frm 00131 Fmt 4701 Sfmt 4702 76367 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 to delay implementation of the requirements in paragraph (b) of this section for a onetime, one-year extension 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 and must include all the following: (A) A narrative justification describing the specific reasons why the State cannot reasonably satisfy the requirement(s) by the compliance date and why those reasons result from circumstances that are unique to the agency operating the CHIP fee-for service program; (B) A report on completed and ongoing State implementation activities that evidence a good faith effort toward compliance; and (C) A comprehensive plan to meet implementation requirements no later than 1 year after the compliance date. (ii) CMS will grant the State’s request if it determines based on the information provided in the State’s annual Advance Planning Document (APD) for Medicaid Management Information System (MMIS) operations expenditures that the request adequately establishes a need to delay implementation; and that the State has a comprehensive plan to implement the requirements no later than 1 year after the compliance date. (2) Exemption. (i) A State operating a CHIP program in which at least 90 percent of the State’s CHIP beneficiaries are enrolled in managed care entities, as defined in § 457.10, may request an exemption for its fee-for-service program from the requirements in paragraph (b) of this section. (A) The exemption request must be submitted in writing as part of a State’s E:\FR\FM\13DEP2.SGM 13DEP2 lotter on DSK11XQN23PROD with PROPOSALS2 76368 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules annual Advance Planning Document for Medicaid Management Information System operations expenditures prior to the date by which the state would otherwise need to comply with the applicable requirement. (B) The State’s request must include documentation that the State meets the criteria for the exemption, based on enrollment data from Section 5 of the most recently accepted CHIP Annual Report Template System (CARTS), and must also include information about an alternative plan to ensure that enrolled providers will have efficient electronic access to the same information through other means while the exemption is in effect. (ii) CMS will grant the exemption if the State establishes to CMS’s satisfaction that the State meets the criteria for the exemption and has established a plan to ensure its enrolled providers have efficient electronic access to the same information through other means while the exemption is in effect. (iii) The State’s exemption would expire if: (A) Based on the 3 previous years of available, finalized CHIP CARTS managed care and FFS enrollment data, the State’s managed care enrollment for 2 of the previous 3 years is below 90 percent; or (B) CMS has approved a State plan amendment, waiver, or waiver amendment that would significantly reduce the share of beneficiaries enrolled in managed care and the anticipated shift in enrollment is confirmed by the first available, finalized Medicaid Transformed Medicaid Statistical Information System (T–MSIS) managed care and FFS enrollment data. (iv) If a State’s exemption expires per paragraph (d)(2)(iii) of this section, the State would be required to: (A) Submit written notification to CMS that the State no longer qualifies for the exemption within 90 days of the finalization of annual CHIP CARTS managed care enrollment data confirming that there has been a shift from managed care enrollment to FFS enrollment resulting in the State’s managed care enrollment falling below the 90 percent threshold; and (B) Obtain CMS approval of a timeline for compliance with the requirements at paragraph (b) of this section within two years of the expiration of the exemption. ■ 29. Section 457.1206 is amended by revising paragraph (b)(6) to read as follows: VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 § 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 at § 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: § 438.210(a)(5) of this chapter (related to medical necessity standard); and § 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), and (f). The revisions and addition read as follows: ■ ■ § 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 at 45 CFR 170.213, if the Qualified Health Plan (QHP) issuer maintains any such data, no later than 1 business day after the QHP issuer receives the data; and (iv) For plan years beginning on or after January 1, 2026, the information in paragraph (b)(1)(iv)(A) of this section PO 00000 Frm 00132 Fmt 4701 Sfmt 4702 about prior authorizations for items and services (excluding drugs, as defined at 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 and related administrative and clinical documentation, including all of the following, as applicable: (1) The status of the prior authorization. (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 and the quantity used to date. (5) If denied, a specific reason why the request was denied. (B) The information in paragraph (b)(1)(iv)(A) of this section must be accessible no later than 1 business day after the QHP issuer receives a prior authorization request, and must be updated no later than 1 business day after any change in status. All information must continue to be accessible for the duration that the authorization is active and at least one year from the date of 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 use API technology conformant with 45 CFR 170.215(a)(1) through (3) and (b); * * * * * (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 described in paragraph (b) of this section or § 156.222 or § 156.223 through the required APIs. * * * * * (e) * * * (2) Makes this determination using objective, verifiable criteria that are applied fairly and consistently across all applications and developers through which parties seek to access electronic health information, as defined at § 171.102 of this subchapter, including but not limited to criteria that may rely on automated monitoring and risk mitigation tools. (f) Reporting on the use of the Patient Access API. Beginning in 2026, by March 31 following any calendar year that a QHP issuer offers a QHP on a Federally-facilitated Exchange, the QHP issuer must report to CMS the following E:\FR\FM\13DEP2.SGM 13DEP2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules metrics, in the form of aggregated deidentified data, for the previous calendar year at the issuer level: (1) The total number of unique enrollees whose data are transferred via the Patient Access API to a health app designated by the enrollee; and (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. * * * * * ■ 33. Section 156.222 is added to read as follows: lotter on DSK11XQN23PROD with PROPOSALS2 § 156.222 Access to and exchange of health data for providers and payers. (a) Application Programming Interface to support data transfer 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, 2026, QHP issuers on a Federallyfacilitated Exchange must: (1) Accessible content and API requirements. Implement and maintain a standards-based Application Programming Interface (API) compliant with § 156.221(c), (d), and (e), as well as the standard at 42 CFR 170.215(a)(4), that complies with the following: (i) API requirements and accessible content. Make data specified in paragraph (a)(1)(ii) of this section available to in-network providers no later than 1 business day of receiving a request if all the following conditions are met: (A) The QHP issuer authenticates the identity of the provider that requests access using the required authorization and authentication protocols at 45 CFR 170.215(b) and attributes the enrollee to the provider under the attribution process required in paragraph (a)(2) of this section. (B) The enrollee does not opt out per paragraph (a)(3) of this section. (C) Disclosure of the data is permitted by applicable law. (ii) Individual enrollee data. Make the data available specified at § 156.221(b) with a date of service on or after January 1, 2016, excluding provider remittances and enrollee cost-sharing information, if maintained by the QHP issuer. (2) Attribution. Maintain a process to associate enrollees with their innetwork providers to enable payer-toprovider data exchange via the Provider Access API. (3) Opt out and patient educational resources. (i) Maintain a process to allow an enrollee or the enrollee’s personal representative to opt out of and subsequently opt into the data sharing requirements specified in paragraph VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 (a)(1) of this section. 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 non-technical, simple and easy-tounderstand language, 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: (A) Before the first date on which the QHP issuer makes enrollee information available through the Provider Access API; and (B) At enrollment; and (C) At least annually; and (D) In an easily accessible location on its public website. (4) Provider resources regarding APIs. Provide on its website and through other appropriate provider communications, educational resources in non-technical and easy-to-understand language explaining the process for requesting enrollee data using the standards-based Provider Access API, required under paragraph (a)(1) of this section. The resources must include information about how to use the issuer’s attribution process to associate patients with the provider. (b) Application Programming Interface to support data transfer between payers—Payer-to-Payer API. Beginning January 1, 2026: (1) API requirements and accessible content. A QHP issuer on a Federallyfacilitated Exchange must implement and maintain an API that: (i) Is compliant with § 156.221(c), (d), and (e), as well as the standard at 42 CFR 170.215(a)(4); and (ii) Makes available the data specified at § 156.221(b) with a date of service on or after January 1, 2016, excluding provider remittances and enrollee costsharing, if maintained by the QHP issuer. (2) Opt in. A QHP issuer on a Federally-facilitated Exchange must establish and maintain a process to allow enrollees or their personal representatives to opt in to the QHP issuer’s Payer-to-Payer API data exchange with the enrollee’s previous payer, described in paragraph (b)(4) of this section, and concurrent payer(s), described in paragraph (b)(5) of this section, and to allow enrollees to change their preference at any time. (i) The opt in process must be offered: (A) To current enrollees, no later than the compliance date. PO 00000 Frm 00133 Fmt 4701 Sfmt 4702 76369 (B) To new enrollees, no later than the effectuation of enrollment. (ii) [Reserved] (3) Identify previous and/or concurrent payers. A QHP issuer on a Federally-facilitated Exchange must maintain a process to identify a new enrollee’s previous and/or concurrent payer(s) to facilitate the Payer-to-Payer API data exchange. The information request process must take place: (i) For current enrollees, no later than the compliance date. (ii) For new enrollees, no later than the effectuation of enrollment. (4) Data exchange requirement. (i) A QHP issuer on a Federally-facilitated Exchange must request the data specified in paragraph (b)(1)(ii) of this section from the enrollee’s previous payer through the standards-based API described in paragraph (b)(1) of this section, if the enrollee has opted in as described in paragraph (b)(2) of this section, and as permitted by applicable law. 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. The QHP issuer must complete this request: (A) For current enrollees, no later than 1 week after the effectuation of enrollment. (B) At an enrollee’s request, within 1 week of the request. (C) For an enrollee who opts in or provides previous and/or concurrent payer information after the effectuation of enrollment, within 1 week. (ii) The QHP issuer must incorporate into the enrollee’s record any data received from other payers in response to the request. (iii) The QHP issuer on a Federallyfacilitated Exchange must make data specified in paragraph (b)(1)(ii) of this section available to other payers via the standards-based API described in paragraph (b)(1) of this section within 1 business day of receiving a request if all the following conditions are met: (A) The payer that requests access has its identity authenticated using the authorization and authentication protocols at 45 CFR 170.215(b) and includes an attestation with the request that the patient is enrolled with the payer and has opted in to the data exchange. (B) Disclosure of the data is not prohibited by law. (5) Concurrent coverage data exchange requirement. When an enrollee has provided concurrent coverage information per paragraph (b)(3) of this section, and has opted in per paragraph (b)(2) of this section, a QHP issuer on a Federally-facilitated E:\FR\FM\13DEP2.SGM 13DEP2 lotter on DSK11XQN23PROD with PROPOSALS2 76370 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules Exchange must, through the standardsbased API described in paragraph (b)(1) of this section: (i) No later than one week after the effectuation of enrollment, and then at least quarterly, request the enrollee’s data from all known concurrent payers in accordance with paragraphs (b)(4)(i) and (ii) of this section; and (ii) Within one business day of a request from any concurrent payers, respond in accordance with paragraph (b)(4)(iii) of this section. (6) Educational materials. A QHP issuer must provide information to enrollees in non-technical, simple, and easy-to-understand language, explaining at a minimum: the benefits of Payer-toPayer API data exchange, their ability to opt in or withdraw a previous opt in decision, and instructions for doing so. The QHP issuer must provide these materials: (i) At or before requesting a patient’s consent 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; and (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 paragraphs (a) and/or (b) of this section, 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 payers, and solutions and a timeline to achieve compliance with the requirements in paragraphs (a) and/or (b). (2) The Federally-facilitated Exchange may grant an exception to the requirements in paragraphs (a) and/or (b) of this section if the Exchange determines that making qualified health plans 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 qualified health plans through the FFE. VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 34. Section 156.223 is added to read as follows: ■ § 156.223 Prior authorization requirements. (a) Communicating prior authorization status to providers, including a reason for denial. For plan years beginning on or after January 1, 2026, a QHP issuer on a Federallyfacilitated Exchange must provide specific information about prior authorization requests (excluding drugs as defined at § 156.221(b)(1)(v)) to providers, regardless of the method used to communicate that information, in a manner that is consistent with the following requirements: (1) The QHP issuer’s prior authorization response to the provider must indicate whether the QHP issuer approves the prior authorization request (and for how long), denies the prior authorization request, or requests more information related to the prior authorization request. (2) If the QHP issuer denies the prior authorization request, the response to the provider must include a specific reason for the denial. (b) Prior authorization requirements, documentation and decision (PARDD) Application Programming Interface (API). Unless granted an exception under paragraph (d) of this section, for plan years beginning on or after January 1, 2026, a QHP issuer on a Federallyfacilitated Exchange must implement and maintain a standards-based API compliant with § 156.221(c), (d), and (e) that: (1) Is populated with the QHP issuer’s list of covered items and services (excluding drugs as defined at § 156.221(b)(1)(v)) for which prior authorization is required, and any documentation requirements for the prior authorization; (2) Includes functionality to determine requirements for any other data, forms or medical record documentation required by the QHP issuer for the items or services for which the provider is seeking prior authorization; (3) Facilitates a Health Insurance Portability and Accountability Act (HIPAA)-compliant prior authorization request and response; and (4) Includes the information required at paragraph (a) of this section. (c) Publicly reporting prior authorization metrics. Beginning in 2026, following each year it offers a plan PO 00000 Frm 00134 Fmt 4701 Sfmt 4702 on a Federally-facilitated Exchange, a QHP issuer must report prior authorization data, excluding data on drugs as defined at § 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 it directly on its website or via hyperlink(s): (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 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, and solutions and a timeline to achieve compliance with the requirements in paragraph (b). E:\FR\FM\13DEP2.SGM 13DEP2 Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 / Proposed Rules lotter on DSK11XQN23PROD with PROPOSALS2 (2) The Federally-facilitated Exchange may grant an exception to the requirements in paragraph (b) of this section if the Exchange determines that making qualified health plans of such issuer available through such Exchange VerDate Sep<11>2014 18:56 Dec 12, 2022 Jkt 259001 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 qualified health plans through the FFE. PO 00000 Frm 00135 Fmt 4701 Sfmt 9990 76371 Dated: December 1, 2022. Xavier Becerra, Secretary, Department of Health and Human Services. [FR Doc. 2022–26479 Filed 12–6–22; 4:15 pm] BILLING CODE 4120–01–P E:\FR\FM\13DEP2.SGM 13DEP2

Agencies

[Federal Register Volume 87, Number 238 (Tuesday, December 13, 2022)]
[Proposed Rules]
[Pages 76238-76371]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 2022-26479]

[[Page 76237]]

Vol. 87

Tuesday,

No. 238

December 13, 2022

Part II

Department of Health and Human Services

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

Centers for Medicare & Medicaid Services

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

42 CFR Parts 422, 431, 435, et al.

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

Office of the Secretary

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

45 CFR 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; Proposed Rule

Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 /
Proposed Rules

[[Page 76238]]

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

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-P]
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: Proposed rule.

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

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

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

ADDRESSES: In commenting, please refer to file code CMS-0057-P.
Comments, including mass comment submissions, must be submitted in
one of the following three ways (please choose only one of the ways
listed):
1. Electronically. You may submit electronic comments on this
regulation to https://www.regulations.gov. Follow the ``Submit a
comment'' instructions.
2. By regular mail. You may mail written comments to the following
address ONLY: Centers for Medicare & Medicaid Services, Department of
Health and Human Services, Attention: CMS-0057-P, P.O. Box 8013,
Baltimore, MD 21244-8013.
Please allow sufficient time for mailed comments to be received
before the close of the comment period.
3. By express or overnight mail. You may send written comments to
the following address ONLY: Centers for Medicare & Medicaid Services,
Department of Health and Human Services, Attention: CMS-0057-P, Mail
Stop C4-26-05, 7500 Security Boulevard, Baltimore, MD 21244-1850.
For information on viewing public comments, see the beginning of
the SUPPLEMENTARY INFORMATION section.

FOR FURTHER INFORMATION CONTACT: Alexandra Mugge, (410) 786-4457, for
general questions related to any of the policies in this proposed rule,
or questions related to CMS interoperability initiatives.
Lorraine Doo, (443) 615-1309, for issues related to the prior
authorization process policies, or the Prior Authorization
Requirements, Documentation, and Decision (PARDD) Application
Programming Interface (API).
Shanna Hartman, (410) 786-0092, for issues related to the Payer-to-
Payer API, the Electronic Prior Authorization measure for the MIPS
Promoting Interoperability performance category and Medicare Promoting
Interoperability Program, or any of the API standards and
implementation guides (IGs) included in this proposed rule.
David Koppel, (303) 844-2883, for issues related to the Patient
Access API policies, or patient privacy.
Scott Weinberg, (410) 786-6017, for issues related to the Provider
Access API policies, or the Requests for Information.
Amy Gentile, (410) 786-3499, for issues related to Medicaid managed
care.
Kirsten Jensen, (410) 786-8146, for issues related to Medicaid FFS.
Joshua Bougie, (410) 786-8117, for issues related to CHIP.
Natalie Albright, (410) 786-1671, for issues related to MA
organizations.
Ariel Novick, (301) 492-4309, for issues related to QHPs.
Elizabeth Holland, (410) 786-1309, for issues related to MIPS and
the Medicare Promoting Interoperability Program.
Russell Hendel, (410) 786-0329, for issues related to the
Collection of Information and Regulatory Impact Analysis.

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

Table of Contents

I. Background and Summary of Provisions
A. Purpose and Background
B. Summary of Major Proposals
II. Provisions of the Proposed Rule
A. Patient Access API
B. Provider Access API
C. Payer to Payer Data Exchange on FHIR
D. Improving Prior Authorization Processes
E. Electronic Prior Authorization for the Merit-Based Incentive
Payment System (MIPS) Promoting Interoperability Performance
Category and the Medicare Promoting Interoperability Program
F. Interoperability Standards for APIs
III. Requests for Information
A. Request for Information: Accelerating the Adoption of
Standards Related to Social Risk Factor Data
B. Request for Information: Electronic Exchange of Behavioral
Health Information
C. Request for Information: Improving the Electronic Exchange of
Information in Medicare Fee-for-Service
D. Request for Information: Advancing Interoperability and
Improving Prior Authorization Processes for Maternal Health

[[Page 76239]]

E. Request for Information: Advancing the Trusted Exchange
Framework and Common Agreement (TEFCA)
IV. Collection of Information Requirements
V. Response to Comments
VI. Regulatory Impact Analysis
Regulations Text

I. Background and Summary of Provisions

A. Purpose and Background

In the May 1, 2020, Federal Register, we published a final rule
implementing the first phase of CMS interoperability rulemaking in the
``Medicare and Medicaid Programs; Patient Protection and Affordable
Care Act; Interoperability and Patient Access for MA Organization and
Medicaid Managed Care Plans, State Medicaid Agencies, CHIP Agencies and
CHIP Managed Care Entities, Issuers of Qualified Health Plans on the
Federally-Facilitated Exchanges, and Health Care Providers'' final rule
(85 FR 25510) (hereinafter referred to as the ``CMS Interoperability
and Patient Access final rule'').
On December 18, 2020, we published a proposed rule (85 FR 82586)
(hereinafter referred to as the ``December 2020 CMS Interoperability
proposed rule'') in which we proposed new requirements for state
Medicaid FFS programs, state CHIP FFS programs, Medicaid managed care
plans, CHIP managed care entities, and QHP issuers on the FFEs to
improve the electronic exchange of healthcare data and streamline
processes related to prior authorization, while continuing CMS' drive
toward interoperability and reducing burden in the healthcare market.
In addition, on behalf of the Department of Health and Human Services
(HHS), the Office of the National Coordinator for Health Information
Technology (ONC) proposed the adoption of certain specified
implementation guides (IGs) needed to support the proposed Application
Programming Interface (API) policies in that proposed rule.
We received approximately 251 individual comments on the December
2020 CMS Interoperability proposed rule by the close of the comment
period on January 4, 2021. While commenters largely supported the
intent of the proposals and the proposals themselves, many noted and
emphasized that MA organizations were not included among the impacted
payers. The National Association of Medicaid Directors and state
Medicaid programs expressed concerns about the implementation
timeframes, states' constraints to secure the funding necessary to
implement the requirements of the rule in a timely manner, and states'
ability to recruit staff with necessary technical expertise. Commenters
also raised concerns that the relatively short comment period inhibited
more thorough analyses of the proposals and, for membership
organizations, the ability to receive input from and gain consensus
among their members. The December 2020 CMS Interoperability proposed
rule will not be finalized; we considered whether to issue a final rule
based on that proposed rule, but considering the concerns raised by the
commenters, we have opted not to do so. Instead, we are withdrawing the
December 2020 CMS Interoperability proposed rule and issuing this new
proposed rule that incorporates the feedback we received from
stakeholders on that proposed rule. This approach will allow us to
incorporate the feedback we have already received and provide
additional time for public comment.
Some of the changes we have incorporated in this proposed rule were
influenced by the comments we received on the December 2020 CMS
Interoperability proposed rule. For example, unlike in that proposed
rule, we now propose to require impacted payers to use those health
information technology (IT) standards at 45 CFR 170.215 that are
applicable to each set of API requirements proposed in this rule,
including the HL7 Fast Healthcare Interoperability Resources (FHIR)
standard, the HL7 FHIR US Core Implementation Guide, and the HL7 SMART
Application Launch Framework Implementation Guide. Also, in this
proposed rule, we include MA organizations as impacted payers and
propose that the policies included herein would have a longer
implementation timeline.
Most of the implementation dates for the proposals included in this
proposed rule would begin in 2026, including those for the API
proposals, prior authorization decision timeframes for certain impacted
payers, and certain reporting proposals. We believe a three-year
timeline to recruit and train staff, update or build the APIs, and
update operational procedures would be sufficient for these proposals,
particularly based on the information we have from some payers and
providers regarding similar initiatives already in progress. In
addition to the proposed three-year implementation timeframe, we
propose to give state Medicaid and CHIP FFS programs an opportunity to
seek an extension of proposed implementation deadlines, or an exemption
from meeting certain proposed requirements, in certain circumstances.
Additionally, we include a proposal to provide an exceptions process
for issuers of QHPs on the FFEs. We believe the three-year timeframe
would offer sufficient time for these impacted payers to evaluate their
qualifications to participate in the API proposals in this proposed
rule and to prepare the necessary documentation to request an
extension, exemption, or exception.
We are proposing some clarifications to existing Medicaid
beneficiary notice and fair hearing regulations which apply to Medicaid
prior authorization decisions. Because these are clarifications and
improvements to existing regulations, these policies would become
effective upon the effective date of a final rule if these proposals
are finalized as proposed. We are also proposing terminology changes in
section II.A.2.e related to the Patient Access API that would take
effect with the effective date of the final rule, should these
proposals be finalized as proposed.
We are proposing a new Electronic Prior Authorization measure for
eligible hospitals and CAHs under the Medicare Promoting
Interoperability Program and for MIPS eligible clinicians under the
Promoting Interoperability performance category of MIPS, which is in
direct response to comments we received on the December 2020 CMS
Interoperability proposed rule.
We are re-issuing two requests for information (RFIs) that were
included in the December 2020 CMS Interoperability proposed rule. We
are also issuing three new RFIs: one to solicit information related to
opportunities for improving the electronic exchange of medical
documentation between providers to support prior authorization programs
for Medicare FFS, a second to gather public feedback regarding data
standardization and use of prior authorization to improve maternal
health care, and a third to solicit comment regarding enabling exchange
under the Trusted Exchange Framework and Common Agreement (TEFCA).
With this new proposed rule, we are taking an active approach to
move certain participants in the healthcare market toward
interoperability by proposing policies for the MA program, Medicaid,
CHIP, and QHP issuers on the FFEs, as well as eligible hospitals and
CAHs under the Medicare Promoting Interoperability Program and for MIPS
eligible clinicians under the Promoting Interoperability performance
category of MIPS.
Our proposals emphasize improving health information exchange and
facilitating appropriate and necessary

[[Page 76240]]

patient, provider, and payer access to information in health records.
We also include several proposals intended to reduce payer, provider,
and patient burden by improving prior authorization processes and
helping patients remain at the center of their own care. Prior
authorization refers to the process through which a healthcare
provider, such as an individual clinician, acute care hospital,
ambulatory surgical center, or clinic, obtains approval from a payer
before providing care. Prior authorization requirements are established
by payers to help control costs and ensure payment accuracy by
verifying that an item or service is medically necessary, meets
coverage criteria, and is consistent with standards of care before the
item or service is provided.
For purposes of this proposed rule, references to QHP issuers on
the FFEs exclude issuers offering only stand-alone dental plans
(SADPs). Likewise, we are also excluding QHP issuers offering only QHPs
in the Federally-facilitated Small Business Health Options Program
Exchanges (FF-SHOPs) from the proposed provisions of this rule. We
believe that the proposed standards would be overly burdensome for both
SADP and SHOP issuers. Requiring issuers offering only SADPs and QHPs
in the FF-SHOPs, which have relatively lower enrollment and premium
intake compared to individual market QHPs, to comply with the proposals
in this rule could result in those issuers no longer participating in
the FFEs, which would not be in the best interest of the enrollees. The
categorical exclusion of these issuers is consistent with CMS' approach
to some other QHP requirements. We also propose offering an exceptions
process for QHP issuers on the FFEs for the API requirements proposed
in this rule, that would be conditioned upon approval of a narrative
justification that meets CMS requirements. The proposed exceptions
processes could apply to small issuers, financially vulnerable issuers,
or new entrants to the FFEs that demonstrate that deploying standards-
based API technology consistent with the proposed policies would pose a
significant barrier to the issuers' ability to provide coverage or
service to patients and that not certifying the issuers QHP or QHPs
would result in patients having few or no plan options in certain
areas. This approach is consistent with the exceptions process
finalized for the Patient Access API in the CMS Interoperability and
Patient Access final rule. Were we to apply the proposed standards to
such issuers, we believe it could result in those issuers no longer
participating in the FFEs, which would not be in the best interest of
enrollees. We note that, in this proposed rule, FFEs include FFEs in
states that perform plan management functions. State-based Exchanges on
the Federal Platform (SBE-FPs) are not FFEs, even though patients in
those states enroll in coverage through HealthCare.gov. Hence, QHP
issuers in SBE-FPs would not be subject to the requirements in this
proposed rule. We encourage SBE-FPs and State-based Exchanges operating
their own platforms (SBEs) to consider adopting similar requirements
for QHPs on their Exchanges.
Throughout this proposed rule, we use terms such as ``patient,''
``consumer,'' ``beneficiary,'' ``enrollee,'' and ``individual.'' Every
reader of this proposed rule is a patient and has received, or will
receive, medical care at some point in their life. In this proposed
rule, we use the term ``patient'' as an inclusive term. We understand
that, historically, we have referred in our regulations to patients
using the other terms previously noted. However, for the proposals
herein, we will use additional, specific terms applicable to
individuals covered under the healthcare programs that we administer
and regulate. We also note that when we discuss patients, the term
includes, where applicable, a patient's personal representative. For
example, a patient or their personal representative may consent to
certain types of information exchange under our proposals. But when we
refer to a patient's medical needs or health records, we are not
including the medical needs or health records of the patient's personal
representative. Per the Privacy, Security, and Breach Notification
Rules (HIPAA Rules) \1\ issued under the Health Insurance Portability
and Accountability Act of 1996 (HIPAA) (Pub. L. 104-191, enacted on
August 21, 1996), as modified, at 45 CFR 164.502(g), and related
guidance thereof, a personal representative, generally and for purposes
of access to protected health information (PHI), defined at 45 CFR
160.103, is someone authorized under state or other applicable law to
act on behalf of an individual in making healthcare-related decisions
(such as a parent, guardian, or person with a medical power of
attorney).\2\ As permitted by the HIPAA Rules, a patient's personal
representative could act on a patient's behalf using the processes
within this proposed rule.
---------------------------------------------------------------------------

\1\ See 45 CFR parts 160 and 164.
\2\ See HHS Office of Civil Rights (OCR) guidance regarding
personal representatives at 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 proposed rule. Certain portions of this proposed rule are
applicable to MA organizations, state Medicaid FFS programs, state CHIP
FFS programs, Medicaid managed care plans (managed care organizations
(MCOs), prepaid inpatient health plans (PIHPs), and prepaid ambulatory
health plans (PAHPs)), CHIP managed care entities (MCOs, PIHPs, and
PAHPs), and QHP issuers on the FFEs. Where certain proposed provisions
may not be applicable to specific plan or provider types, we have
identified them separately from the aforementioned categories. We use
the term ``payer'' in the preamble of this proposed rule as an
inclusive term for all these programs and, in the case of plans, plan
types, but we also use specific terms as applicable in various sections
of this proposed rule. We are proposing at 42 CFR 457.700(c) that
states that have a Medicaid expansion CHIP (a program under which a
state receives Federal funding to expand Medicaid eligibility to
optional targeted low-income children that meets the requirements of
section 2103 of the Social Security Act), the proposals in this rule
for Medicaid would apply to those programs rather than our proposals
for a separate CHIP. Functionally, our proposals are the same; however,
for clarity, we are making explicit that the Medicaid requirements at
Sec. Sec. 431.60, 431.61, and 431.80 would apply to those programs
rather than the separate CHIP requirements at Sec. Sec. 457.730,
457.731, and 457.732.
We use the term ``items and services'' when discussing prior
authorization in this proposed rule, and note that, unless otherwise
stated, the proposals for prior authorization APIs and processes do not
apply to drugs of any type, meaning any drugs that could be covered by
the impacted payers in this proposed rule (for example, this would
include outpatient drugs, drugs that may be prescribed, those that may
be administered by a physician, or that may be administered in a
pharmacy or hospital), because the processes and standards for prior
authorization applicable to drugs differ from the other ``items and
services'' for which we propose regulation. In the CMS Interoperability
and Patient Access final rule, we finalized policies that would require
payers to send claims data

[[Page 76241]]

related to prescription and other drug claims via an API, and we make
several proposals related to claims data in this proposed rule. For
example, Medicare Advantage Prescription Drug (MA-PD) plans that cover
Part A, Part B, and Part D benefits, as well as supplemental benefits,
are required to provide access to information about all those covered
benefits through the Patient Access API at 42 CFR 422.119(b).
Prescription and other drug information is part of a patient's
longitudinal record and giving patients, providers, and payers access
to claims data for prescription and other drugs can offer valuable
insights into a patient's healthcare, provide benefits for care
coordination, and help avoid potentially harmful drug interactions. We
acknowledge that there are existing laws and regulations that may apply
to prior authorization for drugs for the impacted payers in this
proposed rule. Thus, while the claims data included in our proposed and
previously finalized policies did include prescription and other drug
claims, our proposals related to prior authorization in this proposed
rule do not include standards or policies for any drugs (as previously
described), including covered outpatient drugs under Medicaid, and
Medicare Part B or Part D drugs.
Additionally, we use the terms ``provider'' and ``supplier'' as
inclusive terms composed of individuals, organizations, and
institutions that provide health services, such as clinicians (that is,
physicians and other practitioners), hospitals, skilled nursing
facilities, home health agencies, hospice settings, laboratories,
suppliers of durable medical equipment, prosthetics, orthotics, and
supplies (DMEPOS), community-based organizations, as appropriate in the
context used. When specifically discussing policies related to the
Medicare Promoting Interoperability Program and the Promoting
Interoperability performance category of MIPS, we refer to MIPS
eligible clinicians, eligible hospitals, and CAHs.
Throughout this proposed rule we make several API-related proposals
in which we refer to the functionality as a singular API, or API
gateway, though we acknowledge that this functionality may be made up
of one or multiple APIs. For example, while we refer to the Patient
Access API (discussed in section II.A. of this proposed rule) as a
single API for the purpose of describing the functionality, the same
functionality may be achieved with one or multiple APIs, depending on
the implementation approach chosen by the applicable payer.
An API is a set of commands, functions, protocols, or tools
published by one software developer (``A'') that enables other software
developers to create programs (applications or ``apps'') that can
interact with A's software without needing to know the internal
workings of A's software, while maintaining data security and patient
privacy, if properly implemented. This is how API technology enables
the seamless user experiences associated with applications, which are
familiar in other aspects of patients' daily lives, such as travel and
personal finance. Standardized, secure, transparent, and pro-
competitive API technology can enable similar benefits for patients of
healthcare services.\3\
---------------------------------------------------------------------------

\3\ ONC released an overview of APIs in context of consumers'
access to their own medical information across multiple providers'
electronic health record (EHR) systems, which is available at the
HealthIT.gov website at https://www.healthit.gov/api-education-module/story_html5.html.
---------------------------------------------------------------------------

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

\4\ CMS does not use the trademark symbol elsewhere in the
preamble unless necessary when naming specific IGs. For HL7
Trademark policy, see https://www.hl7.org/legal/trademarks.cfm?ref=nav.
---------------------------------------------------------------------------

Finally, we note that throughout this proposed rule we discuss the
APIs in relation to the proposed programmatic requirements to share
data between payers, between payers and providers, and between payers
and patients under specific rules. However, these APIs could be used
for a multitude of transactions, aside from those currently described
by section 1173(a)(1) of the Social Security Act, beyond those proposed
in this rule. For instance, a patient could request data outside the
scope of this proposed rule, or program integrity entities could
request data from payers or providers (such as under the Inspector
General Act of 1978). Nothing in this proposed rule would prevent the
requested data from being shared via the APIs discussed in this
proposed rule, if technologically feasible, for appropriate purposes.
In fact, we encourage the use of these standards-based APIs for
purposes beyond the proposed requirements to improve the
interoperability of health data regardless of the use case.

B. Summary of Major Proposals

To drive interoperability, improve care coordination, reduce burden
on providers and payers, and empower patients, we are proposing several
requirements for MA organizations, state Medicaid FFS programs, state
CHIP FFS programs, Medicaid managed care plans, CHIP managed care
entities, and QHP issuers on the FFEs, as well as MIPS eligible
clinicians participating in the MIPS Promoting Interoperability
performance category, and eligible hospitals and CAHs in the Medicare
Promoting Interoperability Program. We are also including RFIs to
gather information that may support future rulemaking or other
initiatives.
Executive Order (E.O.) 13985 of January 20, 2021, entitled
``Advancing Racial Equity and Support for Underserved Communities
Through the Federal Government,'' set Administration policy that the
``Federal Government should pursue a comprehensive approach to
advancing equity for all.'' \5\ CMS is committed to pursuing a
comprehensive approach to advancing health equity for all, and we
believe the proposals in this rule are aligned with this E.O. because
they represent efforts to mitigate existing inefficiencies in policies,
processes, and technology which affect many patient populations. Some
patient populations are more negatively affected by existing processes
than others and thus might realize greater benefits through the
improvements we propose. One of the main components of this proposed
rule is continued support for the individual's ability to select an app
of their choice when accessing their health information. We want to
ensure that members of all communities can access their health
information and benefit from this technology. However, we are
interested in the best ways to ensure that apps are available and
accessible for individuals with disabilities, individuals with limited
English proficiency, individuals with low literacy or low health
literacy, and individuals with geographic, economic, or other social
risk factors that may create barriers to accessing or using technology
and apps. We are soliciting comments from the public, particularly
individuals who have knowledge about how underserved populations use
healthcare apps and technology, such as researchers, policy advocates,
social service agency staff, providers who serve underserved
populations, and others who may be able to provide insight about
accessibility, readability, and other relevant factors for
consideration. Our goal is to ensure that these proposed policies do
not

[[Page 76242]]

exacerbate current disparities or create unintended inequities that
leave some communities or populations unable to benefit from this
information sharing. Further, we seek to ensure that patient privacy
considerations are built into the implementation of these proposed
policies through the use of secure technologies, such as OAuth 2.0 and
OpenID Connect for authentication, and as further discussed in the CMS
Interoperability and Patient Access final rule (85 FR 25516). While we
have proposed policies that we believe would address some healthcare
inequities, we are soliciting comment about how to help ensure that
individuals from all communities and populations can actively benefit
from our healthcare interoperability proposals.
---------------------------------------------------------------------------

\5\ E.O. 13985, sec. 1, 86 FR 7009 (January 20, 2021).
---------------------------------------------------------------------------

In the CMS Interoperability and Patient Access final rule, we
required impacted payers (MA organizations, state Medicaid FFS
programs, state CHIP FFS programs, Medicaid managed care plans, CHIP
managed care entities, and QHP issuers on the FFEs) to implement and
maintain a standards-based Patient Access API. The Patient Access API
must allow patients, through the health applications of their choice,
to easily access their claims and encounter information as well as
clinical data, including laboratory results, and provider remittances
and enrollee cost-sharing pertaining to such claims, if maintained by
the impacted payer, (85 FR 25558). In this proposed rule, we are
proposing to require that impacted payers (MA organizations, state
Medicaid FFS programs, state CHIP FFS programs, Medicaid managed care
plans, CHIP managed care entities, and QHP issuers on the FFEs) include
information about prior authorizations in the data that are available
through the Patient Access API. In addition, we are proposing to
require these impacted payers to annually report to CMS certain metrics
about patient data requests via the Patient Access API.
To improve coordination across the care continuum and movement
toward value-based care, we are proposing to require that impacted
payers implement and maintain a Provider Access API that, consistent
with the technical standards finalized in the CMS Interoperability and
Patient Access final rule (85 FR 25558), utilizes HL7 FHIR version
4.0.1. That API can be used to exchange current patient data from
payers to providers, including all data classes and data elements
included in a standard adopted at 45 CFR 170.213 (currently USCDI
version 1), adjudicated claims and encounter data (not including
provider remittances and enrollee cost-sharing information), and the
patient's prior authorization decisions.
In the CMS Interoperability and Patient Access final rule, CMS
required certain payers (MA organizations, Medicaid managed care plans,
CHIP managed care entities, and QHP issuers on the FFEs) to exchange a
patient's health data with other payers at the patient's request,
beginning on January 1, 2022, or plan years beginning on or after
January 1, 2022, as applicable (85 FR 25568). We also required those
payers to incorporate the data they receive through this payer to payer
data exchange into patient records, with the goal of creating
longitudinal records that would follow patients as they move from payer
to payer throughout their healthcare journey. However, we did not
require a standards-based API for the payer to payer data exchange.
Since the rule was finalized in May 2020, multiple impacted payers
reported to CMS that the lack of technical specifications for the payer
to payer data exchange requirement in the CMS Interoperability and
Patient Access final rule was creating challenges for implementation,
which, they stated, could lead to incompatible implementations across
the industry, poor data quality, operational challenges, and increased
administrative burdens. They were concerned that different
implementation approaches could create gaps in patient health
information, which would directly conflict with the intended goal of
interoperable payer to payer data exchange.
After considering stakeholder concerns about implementing the payer
to payer data exchange requirement finalized in the CMS
Interoperability and Patient Access final rule, we announced in a
December 10, 2021 Federal Register notification (86 FR 70412) that we
would not enforce the payer to payer data exchange requirements until
further rules are finalized.\6\ In this proposed rule, we are proposing
to rescind our previous payer to payer data exchange requirements and
replace them with a new policy. The CMS Interoperability and Patient
Access final rule also did not apply the payer to payer data exchange
requirements to Medicaid and CHIP FFS programs. We are now proposing to
apply our newly proposed Payer-to-Payer API requirements to Medicaid
and CHIP FFS programs, in addition to other impacted payers as
discussed further in section II.C.4.a. The new proposed policy would
require impacted payers to build a Payer-to-Payer API to facilitate the
exchange of patient information between payers, both at a patient's
request and at the start of coverage with a new payer. Specifically,
that data exchange would include all data classes and data elements
included in a standard adopted at 45 CFR 170.213 (currently USCDI
version 1), adjudicated claims and encounter data (not including
provider remittances and enrollee cost-sharing information), and the
patient's prior authorization decisions.
---------------------------------------------------------------------------

\6\ Centers for Medicare & Medicaid Services (2021, December
10). CMS-9115-N2. Notification of Enforcement Discretion. https://www.govinfo.gov/content/pkg/FR-2021-12-10/pdf/2021-26764.pdf.
---------------------------------------------------------------------------

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

[[Page 76243]]

to require impacted payers, except for QHP issuers on the FFEs, to
respond to prior authorization requests within certain timeframes. In
addition, we are proposing to require impacted payers to publicly
report certain metrics about their prior authorization processes for
transparency.
We are proposing a new measure for electronic prior authorization
for MIPS eligible clinicians under the Promoting Interoperability
performance category of MIPS and for eligible hospitals and CAHs under
the Medicare Promoting Interoperability Program. To promote PARDD API
adoption, implementation, and use among MIPS eligible clinicians,
eligible hospitals, and CAHs, we are proposing to add a new measure
titled ``Electronic Prior Authorization'' under the Health Information
Exchange (HIE) objective in the MIPS Promoting Interoperability
performance category and the Medicare Promoting Interoperability
Program, beginning with the performance period/EHR reporting period in
calendar year (CY) 2026. For this measure, we are proposing that a MIPS
eligible clinician, eligible hospital, or CAH must report a numerator
and denominator or (if applicable) an exclusion.
Although these proposals do not directly pertain to Medicare FFS,
we want to ensure that people with Medicare can benefit from the
policies we are proposing, regardless of their coverage or delivery
system. We intend for the Medicare FFS program to be a market leader on
data exchange, including through the Provider Access, Payer-to-Payer,
and Prior Authorization APIs. and therefore, seek comment throughout on
how these proposals could apply to Medicare FFS. Similarly, we
encourage other payers not directly impacted by this proposed rule to
evaluate our proposals for voluntary adoption to reduce burden and
support greater interoperability. Further information about CMS
initiatives to achieve the desired level of data exchange with
patients, providers and other payers can be found in those sections in
this proposed rule.
We are also including five RFIs to gather information that may
support future rulemaking or other initiatives. Specifically, we
request information on barriers to adopting standards, and
opportunities to accelerate the adoption of standards, for social risk
data. We recognize that social risk factors (for example, housing
instability and food insecurity) influence patient health and
healthcare utilization. In addition, we understand that providers in
value-based payment arrangements rely on comprehensive, high-quality
social risk data. Given the importance of these data, we want to
understand how we can better standardize and promote the exchange of
these data in accordance with the law.
Additionally, we are seeking comment on how CMS could leverage APIs
(or other technology) to facilitate electronic data exchange between
and with behavioral healthcare providers, which generally have lower
rates of EHR adoption than other provider types.
Furthermore, in the Medicare FFS program, the ordering provider can
be different than the rendering provider of items or services, which
creates unique obstacles to the coordination of patient care and
exchange of medical information needed to ensure an accurate and timely
payment. We are interested in public comments regarding how Medicare
FFS could support improved medical documentation exchange between and
among providers, suppliers, and patients as we believe it could enable
better care for beneficiaries if covered services are not delayed by
inefficiencies.
We also seek comment on how using data standards and electronic
health records can improve maternal health outcomes. Additionally, we
include questions related to how prior authorization can be improved
and what special considerations should be given to support data sharing
in maternal health care.
Finally, we seek comment on how to encourage providers and payers
to enable exchange under TEFCA to make patient information more readily
available for access and exchange in a variety of circumstances. We
wish to understand how CMS can support enabling exchange under TEFCA
and what concerns commenters have about potential requirements related
to enabling exchange under TEFCA.

II. Provisions of the Proposed Rule

A. Patient Access API

1. Background
In the CMS Interoperability and Patient Access final rule (85 FR
25558), in order to give patients access to their own health
information in a way most meaningful and useful to them, we required
impacted payers to share, via FHIR APIs, certain information including
patient claims, encounter data, and a subset of clinical data that
patients can access via health apps. Claims and encounter data, used in
conjunction with clinical data, can offer a broad picture of an
individual's healthcare experience. In the CMS Interoperability and
Patient Access final rule (85 FR 25523), we gave examples of how claims
data can be used to benefit patients and providers. For example,
inconsistent benefit utilization patterns in an individual's claims
data, such as a failure to fill a prescription or receive recommended
therapies, can indicate to a provider or payer that the individual has
had difficulty financing a treatment regimen and may require less
expensive prescription drugs or therapies, additional explanation about
the severity of their condition, or other types of assistance.
Patients tend to receive care from multiple providers, leading to
fragmented patient health records where various pieces of an
individual's longitudinal record are locked in disparate, siloed data
systems. With patient data scattered across these disconnected systems,
it can be challenging for providers to get a clear picture of the
patient's care history, and patients may forget or be unable to provide
critical information to their provider. This lack of comprehensive
patient data can impede care coordination efforts and access to
appropriate care.
As stated in section I.A. of this proposed rule, we are withdrawing
the December 2020 CMS Interoperability proposed rule and issuing this
new proposed rule that incorporates feedback we received from
stakeholders. We understand that many readers may be familiar with that
proposed rule, and, in an effort to distinguish the differences between
that proposed rule and our proposals herein, we refer readers to
section I.A. of this proposed rule outlining the overarching
differences between them. In this proposed rule, we are again proposing
to require impacted payers to report Patient Access API metrics to CMS.
However, we have changed the proposal to require reporting annually, as
opposed to quarterly. In addition, we are no longer proposing that
impacted payers maintain a process for requesting an attestation from
health app developers when the developers register their app with the
payer's Patient Access API. Instead, we are seeking comment on a
variety of privacy considerations. Finally, we propose to extend the
compliance date for our proposed policies to January 1, 2026.
As mentioned in section I.A. of this proposed rule, the proposals
in this rule do not directly pertain to Medicare FFS. However, if our
proposals are finalized, we plan to implement these provisions for
Medicare FFS so that people with Medicare FFS could also benefit from
their data availability. Through Blue

[[Page 76244]]

Button 2.0,\7\ CMS makes Parts A, B, and D claims data available
electronically via an API to people with Medicare FFS and those
enrolled in Part D. To align with the API provisions included in the
CMS Interoperability and Patient Access final rule, we have updated the
Blue Button 2.0 API to FHIR Release 4, and begun using the CARIN
Consumer Directed Payer Data Exchange IG for Blue Button 2.0. If we
finalize our proposals, we plan to further align and enhance Blue
Button 2.0 accordingly, as feasible. We seek comment on any
considerations for applying these requirements to apply to Medicare
FFS, if we finalize these proposals.
---------------------------------------------------------------------------

\7\ Blue Button 2.0 allows Medicare beneficiaries to download
claims data to their computer or device to print it or share it with
others. They can also easily link health apps to their account to
share their data with providers, pharmacies, caregivers, or others.
See Centers for Medicare & Medicaid Services. Share your Medicare
claims (Medicare's Blue Button). Retrieved from https://www.medicare.gov/manage-your-health/share-your-medicare-claims-medicares-blue-button.
---------------------------------------------------------------------------

2. Enhancing the Patient Access API
In the CMS Interoperability and Patient Access final rule (85 FR
25558-25559), we adopted regulations that require certain payers,
specifically MA organizations, state Medicaid and CHIP FFS programs,
Medicaid managed care plans, CHIP managed care entities, and QHP
issuers on the FFEs, to implement and maintain APIs that permit
enrollees to use health apps to access data specified at 42 CFR
422.119, 431.60, 457.730, 438.242(b)(5), and 457.1233(d) and 45 CFR
156.221, respectively. The Patient Access API must make available, at a
minimum, adjudicated claims (including provider remittances and
enrollee cost-sharing), encounters with capitated providers, and
clinical data, including laboratory results, with a date of service on
or after January 1, 2016, as maintained by the payer. We finalized a
policy that payers must make those data available via the Patient
Access API no later than 1 business day after a claim is adjudicated or
encounter or clinical data are received.
a. Prior Authorization Information
To enhance our policy by improving the usefulness of the
information available to patients, we are proposing to add information
about prior authorizations to the categories of data required to be
made available to patients through the Patient Access API. In this
section, we refer to the provider's workflow and associated information
and documentation as the ``prior authorization request'' and the
payer's processes and associated information and documentation as the
``prior authorization decision.'' This proposal would apply to all
prior authorization requests and decisions for items and services
(excluding drugs) for which the payer has data, whether the decision is
still pending, active, denied, expired, or is in another status, as
discussed further in this section. The primary goal of the Patient
Access API is to give patients access to their health information. By
expanding patient access to prior authorization information, we intend
to help patients be more informed decision makers and true partners in
their healthcare.
As discussed in section I.A. of this proposed rule, our proposals
for prior authorization APIs and processes do not apply to drugs of any
type that could be covered by an impacted payer, including, for
example, outpatient drugs, drugs that may be prescribed, drugs that may
be administered by a provider, or drugs that may be administered in a
pharmacy or hospital. In section II.D. of this proposed rule, we
propose several provisions focused on making the prior authorization
process less burdensome for providers and payers, which we anticipate
would reduce care delays and improve patient outcomes. We believe that
giving patients access to information about prior authorization
requests and decisions would enable patients to take a more active role
in their own healthcare. As a result, we are proposing to require
impacted payers to provide patients with access to information about
the prior authorization requests made for their care through the
Patient Access API.
We propose to require that via the Patient Access API, impacted
payers make information about prior authorization requests and
decisions (and related administrative and clinical documentation) for
items and services (excluding drugs) available to patients no later
than 1 business day after the payer receives the prior authorization
request or there is another type of status change for the prior
authorization. Examples of status changes include: a payer approves or
denies a pending prior authorization request, a provider or patient
updates a denied prior authorization request with additional
information for reconsideration, or the count of the items or services
used under the prior authorization decision is updated. We expect that
impacted payers use a variety of terminology, but, generally, any
meaningful change to the payer's record of the prior authorization
request or decision would require an update to the information
available to the patient. For the requirement to include prior
authorization information in the data available via the Patient Access
API, we propose a January 1, 2026 compliance date (for Medicaid managed
care plans and CHIP managed care entities, by the rating period
beginning on or after January 1, 2026, and for QHP issuers on the FFEs,
for plan years beginning on or after January 1, 2026).
The required information available through the API would include
the prior authorization status, the date the prior authorization was
approved or denied, the date or circumstance under which the
authorization ends, the items and services approved, and the quantity
used to date under the authorization. The documentation required to be
shared includes any materials that the provider sends to the payer to
support a decision, for example, structured or unstructured clinical
data including laboratory results, scores or assessments, past
medications or procedures, progress notes, or diagnostic reports. In
section II.D.4.a. of this proposed rule, we propose that in the case of
a prior authorization denial, the payer must provide a specific reason
for the denial. We propose that impacted payers would have to make that
specific reason for denying a prior authorization request available to
the patient via the Patient Access API as well. This information can
help patients understand both why a payer denied a prior authorization
request and/or what items and services were authorized for the
patient's recent care.
As further discussed in sections II.B. and II.C. of this proposed
rule, we are proposing to require impacted payers to share the same
information about prior authorization requests and decisions with a
patient's provider via the Provider Access API and via the Payer-to-
Payer API. In this way, these prior authorization data can potentially
be available to all relevant parties. We note that the requirement to
share information about prior authorization via the API is in addition
to any notice requirement that applies to prior authorization requests
and decisions, such as the proposals to require notice of a decision
within certain timeframes discussed in section II.D.5.b. of this
proposed rule.
We believe that 1 business day is appropriate, as patients need
timely access to the information to understand prior authorization
processes and their available care options. As discussed further in
section II.D. of this proposed rule, we are proposing to require payers
to make much of the same information about prior authorization requests
and decisions available via the PARDD API during the decision-making
process. In

[[Page 76245]]

addition, because impacted payers would be required to exchange prior
authorization information electronically, we believe it would be
reasonable for them to share prior authorization information and
documentation with patients within 1 business day of any update to the
prior authorization request or decision.
We are also proposing to require that information about prior
authorizations (and related administrative and clinical documentation)
be available via the Patient Access API for as long as the
authorization is active and at least 1 year after the last status
change. We note that we are formulating our proposal for at least 1
year after any status change, but this provision would be particularly
relevant to denied and expired prior authorizations, to ensure that
they would be available for at least a year after expiring or being
denied. We do not propose to require that payers share a patient's full
prior authorization history because that could comprise a significant
amount of information that may no longer be clinically relevant.
Claims, encounter, and/or clinical data can provide important
information about a patient's health history. With those data available
through the Patient Access API, we believe that process-related
information about long-expired or denied prior authorizations would be
redundant. Also, as prior authorization rules may change over time, we
believe that this information has a limited lifespan of usefulness to a
patient's current care. At the same time, the API should include
information about all active authorizations for as long as they are
active and therefore may be related to ongoing care.
We anticipate that requiring payers to make prior authorization
information accessible through the Patient Access API would help
patients better understand the lifecycle of a prior authorization
request, the items and services that require prior authorization, the
information being considered, and specific clinical criteria their
payer uses to make a determination. We believe that more transparency
would better equip patients to engage with their payer(s) and/or
provider(s). For example, by having access to certain prior
authorization information via the Patient Access API, a patient could
see that prior authorization is needed and has been submitted for a
particular item or service, which could help them better understand the
timeline for the process and plan accordingly. Supporting documentation
could give patients better visibility into what the payer is evaluating
so they could help providers get the best and most accurate information
to payers to facilitate a successful request, thus potentially avoiding
unnecessary care delays and reducing burden on providers and payers.
The proposed requirement could also reduce the need for patients to
make repeated calls to their providers and payers to understand the
status of requests, or to inquire why there are delays in care.
We believe that this proposal would enable patients to participate
in their care more and reduce burden on both providers and payers to
allow them to more efficiently navigate the prior authorization
process. The proposal may also add an additional layer of
accountability for payers to make timely prior authorization decisions,
as patients would be able to follow the prior authorization process
from initiation to conclusion. As with all information made available
via the Patient Access API, we believe industry is in the best position
to develop apps for patients to effectively use this information, and
to make sure that the apps are accessible to people with disabilities.
We look to industry innovators to produce apps that will help patients
understand their health information and access it in a manner that is
useful to them.
In summary, we propose that, beginning January 1, 2026 (for
Medicaid managed care plans and CHIP managed care entities, by the
rating period beginning on or after January 1, 2026, and for QHP
issuers on the FFEs, for plan years beginning on or after January 1,
2026), impacted payers would be required to make information available
to patients via the Patient Access API about prior authorization
requests and decisions (and related administrative and clinical
documentations), including, as applicable, the status of the prior
authorization; the date the prior authorization was approved or denied;
the date or circumstance under which the authorization ends; the items
and services approved; the quantity used to date; and, if the prior
authorization was denied, a specific reason why the request was denied,
no later than 1 business day after the payer receives a prior
authorization request for items and services (excluding drugs) or there
is another type of status change for the prior authorization. We are
also proposing that, beginning January 1, 2026 (for Medicaid managed
care plans and CHIP managed care entities, by the rating period
beginning on or after January 1, 2026, and for QHP issuers on the FFEs,
for plan years beginning on or after January 1, 2026), impacted payers
must make prior authorization information (and related administrative
and clinical documentation), available to patients via the Patient
Access API for the duration it is active and at least 1 year after the
last status change. These proposals would apply to MA organizations,
state Medicaid FFS and CHIP FFS programs, Medicaid managed care plans,
CHIP managed care entities, and QHP issuers on the FFEs at the CFR
sections identified in Table 1.
The requirements for a Patient Access API imposed on Medicaid
managed care plans and CHIP managed care entities are set forth at 42
CFR 438.242(b)(5) and 457.1233(d), respectively. Through an amendment
to paragraph (b)(5) and by adding a new paragraph (b)(8) at 42 CFR
438.242, we are proposing to require Medicaid managed care plans (and
through Sec. 457.1233(d), CHIP managed care entities) to include
information about prior authorization requests and decisions and
related administrative and clinical documentation in the data available
via to the Patient Access API by the rating period beginning on or
after January 1, 2026. We request comment on this proposal.
We request comment on how we could or should apply these
requirements to Medicare FFS and its existing prior authorization
requirements and standards.
As stated earlier in this preamble, the proposals in this proposed
rule do not apply to any drugs. However, we also request comments on
whether we should consider policies to require impacted payers to
include information about prior authorizations for drugs, when the
payer covers drugs, via the Patient Access API, the Provider Access
API, and the Payer-to-Payer API. We request comments on how future
rulemaking to make information about prior authorizations for drugs
available through these APIs might interact with existing prior
authorization requirements and standards.
b. Interaction With HIPAA Right of Access Provisions
Previous proposals have elicited numerous comments regarding the
interaction between the Patient Access API and HIPAA Privacy Rule
requirements for individual access.\8\ Per 45 CFR 164.524, an
individual patient generally has a right of access to inspect and
obtain a copy of protected health information (PHI) about themselves in
a designated record set for as long as the PHI is maintained in the
designated record set by a covered entity. This includes the right to
inspect or obtain a

[[Page 76246]]

copy, or both, of the PHI. Our Patient Access API proposals would
complement that right by requiring payers to make the PHI that patients
already have a right to access available through a standards-based and
interoperable Patient Access API. It is critical that individuals have
access to their information and the ability to share it with others who
are involved in their care, particularly when it could involve care
coordination between providers and prior authorization for certain
items and services.
---------------------------------------------------------------------------

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

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

\9\ See 45 CFR 164.524(c)(2)(ii) and U.S. Department of Health
and Human Services. Individuals' Right under HIPAA to Access their
Health Information 45 CFR 164.524. Retrieved from https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/access/.
---------------------------------------------------------------------------

Individuals have the right under the HIPAA Privacy Rule to request
access to PHI in the form and format requested by the individual, if it
is readily producible in the manner requested.\10\ For example, the
covered entity must transfer or transmit the PHI to the individual even
where the requested mode of transfer or transmission is unsecure as
long as the PHI is ``readily producible'' in such manner, the covered
entity is capable of transmitting the PHI in the manner the individual
requests, and the manner of transmission would not present an
unacceptable level of security risk to the PHI on the covered entity's
systems.\11\ In the CMS Interoperability and Patient Access final rule,
we specifically cited this security risk exception as the only reason
payers could deny API access to a health app that a patient wishes to
use. These risks include, for example, insufficient authentication or
authorization controls, poor encryption, or reverse engineering. The
payer must make that determination using objective, verifiable criteria
that are applied fairly and consistently across all apps and developers
through which patients seek to access their electronic health
information. See 42 CFR 422.119(e) for MA organizations; 42 CFR
431.60(e) for state Medicaid FFS programs, through the existing cross
reference at 42 CFR 438.242(b)(5) for Medicaid managed care plans; 42
CFR 457.730(e) for state CHIP FFS programs, through the existing cross
reference at 42 CFR 457.1233(d) for CHIP managed care entities; and 45
CFR 156.221(e) for QHP issuers on the FFEs.
---------------------------------------------------------------------------

\10\ See 45 CFR 164.524(c)(2).
\11\ U.S. Department of Health and Human Services. Individuals'
Right under HIPAA to Access their Health Information 45 CFR 164.524.
Retrieved from https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/access/.
---------------------------------------------------------------------------

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

\12\ Office for Civil Rights (OCR) (2019, April 18). Can a
covered entity refuse to disclose ePHI to an app chosen by an
individual because of concerns about how the app will use or
disclose the ePHI it receives? Retrieved from https://www.hhs.gov/hipaa/for-professionals/faq/3012/can-a-covered-entity-refuse-to-disclose-ephi.html.
---------------------------------------------------------------------------

We discussed privacy and safety concerns in the context of APIs in
the CMS Interoperability and Patient Access final rule (85 FR 25516).
We note that while the FHIR standard itself does not define security-
related functions, when used in combination with appropriate security
controls (such as authentication and access control), a FHIR API can
and should be implemented and maintained to comply with the HIPAA
Security Rule for secure data exchange.\13\ Furthermore, the covered
entity is not liable for what happens to the PHI once the designated
third party receives the information as directed by the individual.\14\
---------------------------------------------------------------------------

\13\ HL7 International (2022, May 28). HL7 FHIR Release 4. 6.1.0
FHIR Security. Retrieved from https://www.hl7.org/Fhir/security.html.
\14\ Office for Civil Rights (OCR) (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 proposals in this section address how a payer must make
patients' data available to them; however, we do not have the authority
to regulate health apps that individuals may wish to use, or what those
apps do with PHI. As discussed, per the CMS Interoperability and
Patient Access final rule, impacted payers may only deny or discontinue
an app's connection to their APIs if an impacted payer makes a
determination using objective, verifiable criteria that the specific
health app would present a danger to the impacted payer's own systems,
such as increasing the risk of cyber-attack.
Regardless of whether HIPAA applies to a health app, other Federal
laws may apply, even where HIPAA does not apply, such as the Federal
Trade Commission (FTC) Act. Under section 5 of the FTC Act (15 U.S.C.
45(a)), the FTC has authority to challenge unfair or deceptive trade
practices, including those related to the privacy and security of
personal health information that apps collect, use, maintain, or share.
For example, if an app discloses an individual's health information in
a manner inconsistent with the app's privacy policy, terms of use, or
an individual's reasonable expectations, or fails to take reasonable
measures to assess and address privacy or data security risks, the
developer of that app may be violating the FTC Act. The FTC has applied
its section 5 authority to a

[[Page 76247]]

wide variety of entities, including health apps.\15\ For more
information about what laws may apply to health apps, see https://www.ftc.gov/business-guidance/resources/mobile-health-apps-interactive-tool.
---------------------------------------------------------------------------

\15\ See, for example, Federal Trade Commission (2021, June 22).
Flo Health, Inc. Retrieved from https://www.ftc.gov/legal-library/browse/cases-proceedings/192-3133-flo-health-inc.
---------------------------------------------------------------------------

The FTC also enforces the FTC Health Breach Notification Rule,
which covers most health apps and similar technologies that are not
covered by HIPAA, and therefore, not subject to the HIPAA Breach
Notification Rule.\16\ The FTC's Health Breach Notification Rule sets
forth steps entities covered by that rule must follow when there has
been a breach of unsecured personal health information. Any violation
of the FTC's Health Breach Notification Rule is treated as an unfair or
deceptive act or practice under section 18 of the FTC Act and subject
to civil penalties of up to $46,517 per violation per day.
---------------------------------------------------------------------------

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

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

\17\ Office for Civil Rights (OCR) (2021, January 6). The access
right, health apps & APIs. Retrieved from https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/access-right-health-apps-apis/.
---------------------------------------------------------------------------

In the CMS Interoperability and Patient Access final rule, we
required that impacted payers make educational resources available to
their current and former patients with information to help protect the
privacy and security of their health information. That includes factors
to consider in selecting an app, including potential secondary uses of
data, and the importance of understanding the security and privacy
practices of any app to which they will entrust their health
information. Furthermore, impacted payers must provide an overview of
which types of organizations or individuals are and are not likely to
be HIPAA-covered entities, and the oversight responsibilities of the
Office for Civil Rights (OCR) and the FTC, and how to submit a
complaint to those entities. See 42 CFR 422.119(g) for MA
organizations, 42 CFR 431.60(f) for Medicaid FFS programs, through
existing cross-reference at 42 CFR 438.242(b)(5) for Medicaid managed
care plans, 42 CFR 457.730(f) for CHIP FFS programs, through existing
cross reference at 42 CFR 457.1233(d) for CHIP managed care entities,
and at 45 CFR 156.221(g) for QHP issuers on the FFEs. We continue to
believe these resources are important to provide to patients, but seek
comments on how we can improve this policy so patients can make
educated decisions about sharing their personal health information.
In the 21st Century Cures Act: Interoperability, Information
Blocking, and the ONC Health IT Certification Program final rule (21st
Century Cures Act final rule) (85 FR 25642, 25814 through 25815), ONC
noted that providing information that is factually accurate, objective,
unbiased, not unfair or deceptive, and provided in a non-discriminatory
manner to inform a patient about the advantages, disadvantages and any
risks of sharing their health information with a health app, would be
unlikely to interfere (as defined in that rule) with the access,
exchange, or use of electronic health information (EHI) for purposes of
the information blocking regulations at 45 CFR part 171.\18\
---------------------------------------------------------------------------

\18\ See 45 CFR 171.102: Electronic health information (EHI) is
electronic protected health information as defined in 45 CFR 160.103
to the extent that it would be included in a designated record set
as defined in 45 CFR 164.501, regardless of whether the group of
records are used or maintained by or for a covered entity as defined
in 45 CFR 160.103. EHI shall not include: (1) Psychotherapy notes as
defined in 45 CFR 164.501; or (2) Information compiled in reasonable
anticipation of, or for use in, a civil, criminal, or administrative
action or proceeding.
---------------------------------------------------------------------------

In response to comments on the CMS Interoperability and Patient
Access proposed rule (84 FR 7610), we noted in the final rule (85 FR
25549-25550) commenters' observations that many patients were unlikely
to understand the potential risk of disclosure when their data are
transmitted to a health app and are thus no longer protected by the
HIPAA Rules. Commenters were specifically concerned about secondary
uses of data, such as whether developers would sell their data to third
parties for marketing or other purposes. In the CMS Interoperability
and Patient Access final rule (85 FR 25549), we noted that a clear,
plain language privacy policy is the best vehicle to inform patients
about how their information will be protected and how it will be used
once shared with the health app.
In the December 2020 CMS Interoperability proposed rule (85 FR
82592 through 82594), we proposed to require impacted payers to request
a privacy policy attestation from health app developers when their app
requests to connect to the payer's Patient Access API. We proposed that
the attestation would include, at a minimum, statements that the app
has a plain language privacy policy that is always publicly available
and accessible, and has been affirmatively shared with the patient
prior to the patient authorizing the app to access their health
information. In addition, the attestation we proposed included yes/no
elements as to whether the privacy policy specifically communicates how
the patient's health information could be accessed, exchanged, or used.
While we still believe that certain aspects of our previously
proposed attestation policy could support enhanced patient education
about health apps' privacy policies, based on public comments and
feedback, we are concerned that this type of attestation would not
serve to benefit patients in ways that would outweigh the burden on
impacted payers. We are also concerned that such a policy could have
unintended consequences for patients. Under the proposal in the
December 2020 CMS Interoperability proposed rule, a health app
developer would only be attesting to the format and inclusion of
certain information. There would be no attestation that the substance
of the privacy policy meets specific minimum requirements or best
practices. We believe that having payers inform patients that an app
developer has attested to the form and format of a privacy policy could
easily be misinterpreted as assurance that the substance of the privacy
policy has been reviewed and found acceptable by the payer (or CMS). We
believe this is especially true in the case of patients with low health
or technology literacy, who are least likely to be able to find and
interpret an app's privacy policy to make well-informed decisions about
their health data. We are concerned that requiring such an attestation
would only give the appearance of privacy and

[[Page 76248]]

security for patients' health data, without providing additional
benefit.
Because CMS does not have the statutory authority to regulate
health apps, we cannot require developers to respond to that
attestation. Furthermore, as discussed, even if a health app developer
does not respond to the attestation (or responds in the negative), a
payer would be required to allow that app to connect (unless it would
create a security risk to the payer's own system) and provide a
patient's health information through the app selected by the patient.
Commenters also responded that the proposed process would put an
undue burden on payers to manage an attestation process for app
developers with whom they may have no legal or contractual
relationship. Furthermore, commenters expressed concerns about payers'
lack of adherence mechanisms and payer liability due to the HIPAA right
of access requirements discussed previously.
We still believe it is important for patients to have a clear
understanding of how their health information may be used by a person
or entity not covered by the HIPAA Rules, such as a health app, whether
their data would be sold or marketed, and how to stop sharing their
health information with such entities if they so choose. In particular,
explaining certain privacy and security practices in a patient-
friendly, easy-to-read privacy policy would help patients understand
those elements and how they can be an active participant in the
protection of their information. We also encourage app developers to
follow industry best practices, including the CARIN Alliance's Code of
Conduct and the ONC Model Privacy Notice (MPN).^{19 20} We note
that the developer attestation discussed in the December 2020 CMS
Interoperability proposed rule (85 FR 82593) included some of the
elements of the 2018 ONC MPN, such as explaining how a patient's health
information may be accessed, exchanged, or used by any person or other
entity, including whether the patient's health information may be
shared or sold at any time.\21\ As discussed, if an app has a written
privacy policy and the app or developer operates contrary to that
policy, the FTC has authority to act.
---------------------------------------------------------------------------

\19\ CARIN. The CARIN Alliance Code of Conduct (May 2020).
Retrieved from https://www.carinalliance.com/our-work/trust-framework-and-code-of-conduct/.
\20\ Office of the National Coordinator. Model Privacy Notice
(MPN). Retrieved from https://www.healthit.gov/topic/privacy-security-and-hipaa/model-privacy-notice-mpn.
\21\ Office of the National Coordinator. Model Privacy Notice
(MPN). Retrieved from https://www.healthit.gov/topic/privacy-security-and-hipaa/model-privacy-notice-mpn.
---------------------------------------------------------------------------

We request comments on how we can help give patients the tools they
need to understand the privacy and security implications of using a
health app within the scope of our regulatory authority. We seek ideas
on how we can balance our desire to both educate patients and respect
their rights under the HIPAA Privacy Rule. For example, should there be
a process at the time a developer registers an app with a payer for
access to the API to submit information about its privacy policy?
Should payers be required to provide that information in an easy-to-
understand format the first time a patient requests access via an app?
We encourage comments about how we can leverage the MPN (most recent
version from 2018). While we cannot require health app developers to
utilize the MPN, should payers notify patients, the first time the
patients request data through an app, whether the app utilizes the MPN
or not? To encourage visibility for apps that use the MPN versus those
that do not, should payers be required to list apps that have
established access to their API on their websites that comply with the
MPN's transparency requirements? We note that payers would have to
treat apps identically based on the substance of their privacy policies
and could not favor certain apps over others, such as for competitive
advantage. Again, we (and payers) cannot prohibit patients from using
health apps that do not comply with best privacy and security practices
unless it presents an unacceptable security risk to the payer's
systems.
We also request comment on whether we can leverage and build on
other HHS health information exchange initiatives, such as TEFCA, to
address these issues. For more background on TEFCA, see the related
Request for Information in section III.E. of this proposed rule. The
Common Agreement and Framework Agreement include privacy and security
requirements for Qualified Health Information Networks (QHINs),
Participants, and Subparticipants that elect to exchange information
pursuant to it, including entities not covered by the HIPAA Rules.\22\
Within the Common Agreement, any QHIN, Participant, or Subparticipant
that offers Individual Access Services (IAS) \23\ by which an
individual can access, inspect, or obtain a copy of that individual's
information is an IAS Provider. If a health app developer becomes a
signatory to a Framework Agreement and offers IAS Services, that
developer would be an IAS Provider. That developer would be providing
services utilizing the TEFCA Connectivity Services to an Individual
with whom the QHIN, Participant, or Subparticipant has a Direct
Relationship to satisfy that Individual's ability to access, inspect,
or obtain a copy of that Individual's Required Information that is then
maintained by or for any QHIN, Participant, or Subparticipant.
---------------------------------------------------------------------------

\22\ For the Common Agreement definitions of the terms used in
this section (QHIN, Participant, Subparticipant, IAS Provider,
Framework Agreement, Connectivity Services, Individual, Required
Information, Direct Relationship, Use, Disclosure), see page 3-14
in, Office of the National Coordinator (January 2022). Common
Agreement for Nationwide Health Information Interoperability Version
1. Retrieved from https://www.healthit.gov/sites/default/files/page/2022-01/Common_Agreement_for_Nationwide_Health_Information_Interoperability_Version_1.pdf.
\23\ The Common Agreement defines Individual Access Services
(IAS) as follows: ``with respect to the Exchange Purposes
definition, the services provided utilizing the Connectivity
Services, to the extent consistent with Applicable Law, to an
Individual with whom the QHIN, Participant, or Subparticipant has a
Direct Relationship to satisfy that Individual's ability to access,
inspect, or obtain a copy of that Individual's Required Information
that is then maintained by or for any QHIN, Participant, or
Subparticipant.'' See page 7 in, Office of the National Coordinator
(January 2022). Common Agreement for Nationwide Health Information
Interoperability Version 1. Retrieved from https://www.healthit.gov/sites/default/files/page/2022-01/Common_Agreement_for_Nationwide_Health_Information_Interoperability_Version_1.pdf.
---------------------------------------------------------------------------

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

[[Page 76249]]

Security Notice and Practices Standard Operating Procedure (SOP) \25\
and the IAS Exchange Purpose Implementation SOP.^{26 27}
---------------------------------------------------------------------------

\24\ See pages 33-38 in, Office of the National Coordinator
(January 2022). Common Agreement for Nationwide Health Information
Interoperability Version 1. Retrieved from https://www.healthit.gov/sites/default/files/page/2022-01/Common_Agreement_for_Nationwide_Health_Information_Interoperability_Version_1.pdf.
\25\ The Sequoia Project (2022, June 21). Standard Operating
Procedure (SOP): Individual Access Service (IAS) Provider Privacy
and Security Notice and Practices. DRAFT FOR PUBLIC FEEDBACK.
Retrieved from https://rce.sequoiaproject.org/wp-content/uploads/2022/06/SOP-IAS-Privacy-and-Security-Notice-1.pdf.
\26\ The Sequoia Project (2022). Standard Operating Procedure
(SOP): Individual Access Services (IAS) Exchange Purpose
Implementation. Retrieved from https://rce.sequoiaproject.org/wp-content/uploads/2022/06/SOP_IAS_Exchange_Purpose_Implementation.pdf.
\27\ See pages 35-37 in, Office of the National Coordinator
(January 2022). Common Agreement for Nationwide Health Information
Interoperability Version 1. Retrieved from https://www.healthit.gov/sites/default/files/page/2022-01/Common_Agreement_for_Nationwide_Health_Information_Interoperability_Version_1.pdf.
---------------------------------------------------------------------------

Given the Common Agreement's privacy and security requirements, and
particularly those that will apply when patients access their health
information through a participating IAS Provider, we request comment on
whether CMS should explore requirements or ways to encourage exchange
under TEFCA as a way to ensure that more patients are informed about
the privacy and security implications of using health apps to access
their health information, consistent with the requirements for IAS
Providers described previously. For instance, how could CMS encourage
health apps that are not subject to the HIPAA Rules to connect to
entities that exchange information under TEFCA? If so, what should be
the contours of, and levers for, such encouragement? What other
approaches can CMS take to encourage app developers to enable exchange
under TEFCA and therefore leverage the Common Agreement's privacy and
security requirements?
In addition, we request comments on the availability of apps that
are accessible to individuals with disabilities, availability of apps
in a multitude of languages to ensure that individuals with limited
English proficiency can understand the information provided, and
availability of apps at an appropriate literacy level and in plain
language. We note that the draft IAS Provider Privacy and Security
Notice and Practices SOP includes guidance regarding plain language and
literacy requirements.\28\ We believe apps with these features are
important to ensure that all patients can benefit from the proposals in
this rule. We request comment on any actions that we can take to ensure
patients' equitable access to their health information.
---------------------------------------------------------------------------

\28\ See pages 5-6 in, The Sequoia Project (2022, June 21).
Standard Operating Procedure (SOP): Individual Access Service (IAS)
Provider Privacy and Security Notice and Practices. DRAFT FOR PUBLIC
FEEDBACK. Retrieved from https://rce.sequoiaproject.org/wp-content/uploads/2022/06/SOP-IAS-Privacy-and-Security-Notice-1.pdf.
---------------------------------------------------------------------------

d. Patient Access API Metrics
We are proposing to require impacted payers to report metrics in
the form of aggregated, de-identified data to CMS on an annual basis
about how patients use the Patient Access API. This reporting would
help CMS better understand whether the Patient Access API requirement
is efficiently and effectively ensuring that patients have access to
their health information and whether payers are providing that required
information in a transparent and timely way. Aggregated usage data from
every impacted payer would help us evaluate whether the Patient Access
API policies are achieving the desired goals. Gathering this
information would also help us to provide targeted support or guidance
to impacted payers, if needed, to help ensure that patients have access
to their data and can use their data consistently across the impacted
payer types. We propose to require MA organizations to report these
data to CMS at the organization level, state Medicaid and CHIP FFS
programs to report at the state level, Medicaid managed care plans to
report at the state level, CHIP managed care entities to report at the
state level, and QHP issuers on the FFEs to report at the issuer level.
We are considering, and therefore seek comment on, whether we should
require payers that administer multiple plans under a single contract
to report these data to CMS at the contract level. We also seek comment
on the benefits or drawbacks of an alternative final policy that would
permit MA organizations, entities offering Medicaid managed care plans,
CHIP managed care entities, and QHP issuers on the FFEs to report
aggregate data for the same plan type at higher levels (such as the
parent organization level or all plans of the same type in a program).
We note that in the December 2020 CMS Interoperability proposed rule
(85 FR 82594), we proposed that these data be reported quarterly, and
received comments from a broad variety of stakeholders strongly in
favor of annual reporting. Based on that feedback, we are now proposing
annual reporting.
Specifically, we propose that these payers annually report:
The total number of unique patients whose data are
transferred via the Patient Access API to a health app designated by
the patient; and
The total number of unique patients whose data are
transferred more than once via the Patient Access API to a health app
designated by the patient.
Tracking multiple data transfers would indicate repeat access,
showing that patients are either using multiple apps or are allowing
apps to update their information over the course of the year. While we
are not certain whether such data transfers would indicate to what
extent patients are using the apps to manage their healthcare, it would
be a preliminary indicator of interest in the technology to access
their data.
We are proposing that payers must report data from the previous
calendar year to CMS by March 31 of each year. The first year the
requirement would be applicable, payers would report calendar year 2025
data by March 31, 2026. A new MA organization, Medicaid managed care
plan, CHIP managed care entity, or QHP issuer on the FFEs would
naturally have no data to report in its first year of existence and
would be required to report data following its first full calendar year
subject to the Patient Access API requirement.
In summary, we propose that beginning in 2026, MA organizations at
the organization level, state Medicaid and CHIP FFS programs at the
state level, Medicaid managed care plans at the state level, CHIP
managed care entities at the state level, and QHP issuers on the FFEs
at the issuer level must annually report the following metrics to CMS
in the form of aggregated, de-identified data: (1) the total number of
unique patients whose data are transferred via the Patient Access API
to a health app designated by the patient; and (2) the total number of
unique patients whose data are transferred more than once via the
Patient Access API to a health app designated by the patient.
Collecting this information would facilitate CMS' oversight and
evaluation of the MA, Medicaid, and CHIP programs and of QHP issuers on
the FFEs. We propose that impacted payers report the previous calendar
year's metrics, in the form of aggregated, de-identified data, to CMS
by March 31 of each year. MA organizations, Medicaid managed care
plans, and CHIP managed care entities would report metrics to CMS
following any year that they operated, and QHP issuers would report
metrics to CMS following any year that they offered a QHP on the FFEs.
We are making this proposal at the CFR sections identified in Table 1.
If we finalize this proposal, we do not plan to publicly report
these metrics at the state, plan, or issuer level, but may reference or
publish aggregated and de-identified data that does not include names
of specific state agencies, plans, or issuers. We solicit comment on
this aspect of our proposal.

[[Page 76250]]

In addition, we request comment on what other Patient Access API
metrics we should consider requiring payers to report to CMS and/or
make available to the public on their own websites, for consideration
in possible future rulemaking. For instance, we are seeking comments on
whether payers could report aggregated demographic information, such as
sex, race, age, ethnicity, and geographical (for instance, by zip code)
data that they may already have to help identify disparities in patient
access to health data or underserved populations and, if so, what
policies should be considered to minimize those disparities. We are
also seeking comment on the potential benefits and burden of requiring
payers to report the names of all apps that patients have used to
access the payers' API each year. We are considering either collecting
this information, or requiring payers to make it public, not to
recommend or endorse specific apps, but to maintain a view of the apps
that patients use to access their health information, which could help
us review for best practices and to evaluate patient ease of use.
e. Patient Access API Amendments
To accommodate the proposed requirements regarding the use of the
Patient Access API, we are proposing two minor terminology changes to
the requirements finalized in the CMS Interoperability and Patient
Access final rule (85 FR 25558, 25547). We note that unlike most of our
proposals, we are proposing that these amendments would go into effect
on the effective date of the final rule. We are proposing these changes
to clarify terms, but do not expect them to substantively change any
current regulatory obligation.
First, we are proposing to revise the description of the clinical
data to be made available via the Patient Access API by MA
organizations, state Medicaid and CHIP FFS programs, Medicaid managed
care plans, CHIP managed care entities, and QHP issuers on the FFEs at
the CFR sections identified in Table 1. These provisions currently
require payers to make available ``clinical data, including laboratory
results.'' We are proposing to revise these paragraphs to specify that
the data that payers must make available are ``all data classes and
data elements included in a content standard at 45 CFR 170.213.'' The
standard currently referenced at 45 CFR 170.213 is the USCDI version 1.
Laboratory Values/Results is a USCDI version 1 data element, and USCDI
version 1 includes data classes for other aspects of clinical
information such as Immunizations, Procedures, and Assessment and Plan
of Treatment. Referring explicitly to the data set in a standard at 45
CFR 170.213 in the rule text would help avoid unnecessary confusion, as
this reference would more clearly identify exactly what data must be
available through the Patient Access API.
In the future, as versions of the USCDI evolve, there may be
multiple versions of the standard referenced at 45 CFR 170.213 at one
time. For the ONC Health IT Certification Program, this allows for a
transition period between standards as health IT developers incorporate
updated standards versions within their systems and complete required
certification. Through this proposal, we are seeking to ensure that the
same flexibility would apply for payers as they transition between the
versions of the USCDI. During such a period, when 45 CFR 170.213
includes more than one version of the USCDI standard, payers would be
allowed to use any of the then-available standards at 45 CFR 170.213
for the data classes and elements that they make available through the
API.
Second, we are proposing to revise the language previously
finalized for denial or discontinuation of a health app's access to the
API. Currently, the rules require that the payer make a determination
to deny or discontinue access to the Patient Access API using
objective, verifiable criteria that are applied fairly and consistently
across all apps and developers through which ``enrollees'' or
``beneficiaries'' seek to access EHI. We are proposing to change the
terms ``enrollees'' and ``beneficiaries'' to ``parties'' for
consistency with our proposal to apply this provision to the Provider
Access API, Payer-to-Payer API, and the PARDD API discussed further in
sections II.B., II.C., and II.D. of this proposed rule. Because other
parties would be accessing these APIs, such as providers and payers, it
would be more accurate to use the term ``parties'' rather than
``enrollees'' or ``beneficiaries.''
In summary, we propose that we will replace ``clinical data,
including laboratory results'' with ``all data classes and data
elements included in a content standard at 45 CFR 170.213'' for MA
organizations, state Medicaid and CHIP FFS programs, Medicaid managed
care plans, CHIP managed care entities, and QHP issuers on the FFEs at
the CFR sections identified in Table 1. We also propose that we will
change the terms ``enrollees'' and ``beneficiaries'' to ``parties'' for
MA organizations, state Medicaid and CHIP FFS programs, Medicaid
managed care plans, CHIP managed care entities, and QHP issuers on the
FFEs at the CFR sections identified in Table 1.
We request comment on these proposals. We also direct readers to
section II.F. of this proposed rule for a discussion of proposed
changes to the interoperability standards for APIs that affect the
Patient Access API.
f. Specific CHIP-Related Regulatory Framework
Specifically, for CHIP, the proposed amendments to 42 CFR
457.1233(d) would align separate CHIP managed care API requirements
with the Medicaid managed care API requirements, rather than with the
CHIP FFS API requirements. In the CMS Interoperability and Patient
Access final rule (85 FR 25559), we finalized requirements for separate
CHIP managed care entities at 42 CFR 457.1233(d). API requirements for
CHIP managed care entities were codified at 42 CFR 457.1233(d)(2) and
(3) through cross-references to CHIP FFS program requirements at 42 CFR
457.730 and 457.760, respectively. On November 13, 2020, we published a
final rule titled ``Medicaid Program; Medicaid and Children's Health
Insurance Program (CHIP) Managed Care'' (85 FR 72754). In that rule, we
removed 42 CFR 457.1233(d)(1) through (3), and, at 42 CFR 457.1233(d),
cross-referenced to Medicaid managed care regulatory requirements at 42
CFR 438.242. Therefore, the policies in the CMS Interoperability and
Patient Access final rule (85 FR 25559) are applicable to separate CHIP
managed care entities per 42 CFR 457.1233(d) through a cross reference
to Medicaid managed care at 42 CFR 438.242. We propose to apply the API
requirements in this proposed rule to separate CHIP managed care
entities through the existing cross reference at 42 CFR 457.1233(d) to
Medicaid managed care at 42 CFR 438.242, and have noted this throughout
the proposals in this proposed rule.
Most states have Medicaid Expansion CHIP programs, in which a state
receives Federal funding to expand Medicaid eligibility to optional
targeted low-income children that meet the requirements of section 2103
of the Social Security Act (the Act). We are proposing at 42 CFR
457.700(c) that for states with Medicaid Expansion CHIP programs, the
proposals in this rule for Medicaid would apply to those programs
rather than our proposals for separate CHIP programs. Functionally, our
proposals are the same, however, for clarity, we are making explicit
that the Medicaid requirements at 42 CFR 431.60, 431.61, and 431.80
would apply to those programs rather than the

[[Page 76251]]

separate CHIP requirements at 42 CFR 457.730, 457.731, and 457.732.
BILLING CODE 4120-01-P
[GRAPHIC] [TIFF OMITTED] TP13DE22.000

BILLING CODE 4120-01-C
3. Statutory Authorities for the Patient Access API Proposals

a. MA Organizations

[[Page 76252]]

For MA organizations, we are proposing these new requirements and
the revisions to current requirements under our authority at sections
1856(b)(1) (to promulgate regulations implementing MA standards,
including the requirements in section 1852(h) of the Act), and
1857(e)(1) of the Act (to add contract terms determined by the
Secretary to be ``necessary and appropriate''). Section 1856(b)(1) of
the Act requires the Secretary to establish regulatory standards for MA
organizations that are consistent with and carry out Part C of the
Medicare statute, Title XVIII of the Act. Section 1852(h) of the Act
requires that MA organizations have procedures in place to maintain
accurate and timely medical records and health information regarding MA
enrollees and to assure enrollees have timely access to such records
and information. Our proposal for the Patient Access API is to require
access for enrollees to specified medical records and health
information through a specific mechanism from the MA organization. The
Secretary is authorized under section 1857(e)(1) of the Act to add new
contract terms, including additional standards and requirements, for MA
organizations that the Secretary finds necessary and appropriate and
that are not inconsistent with Part C of the Medicare statute. The
proposals here meet this standard by addressing and facilitating access
to enrollees' medical records and health information for the reasons
identified in our discussions for each proposal.
The proposal in section II.A.2.a. of this proposed rule that would
require MA organizations to make an enrollee's prior authorization
requests and related clinical documentation available through the
Patient Access API would, if finalized as proposed, allow these
enrollees to have access to that information in a convenient, timely,
secure, and portable way, which is in enrollees' best interests. This
proposed requirement is consistent with section 1852(h) of the Act,
which requires MA organizations to assure enrollees timely access to
their records and data that is maintained by MA organizations. To
ensure that MA organizations meet modern-day patient expectations of
transparency, efficiency, and timeliness when providing prior
authorization data to enrollees, it is essential for CMS to ensure that
each MA organization has a standardized system in place that offers
enrollees access to their own data, including data that pertain to
their prior authorizations, using existing and emerging technologies of
their choice, specifically in this case, health apps. Therefore, making
these data available through the Patient Access API is consistent with
our programmatic authority to establish standards to implement section
1852(h) of the Act, and could help patients be more informed about and
active in their own care, which could potentially lead to better health
outcomes.
Making this information available via the Patient Access API could
help enrollees support the prior authorization process, as well.
Enrollees could see what information is needed and what information has
been provided on their behalf to facilitate a prior authorization
request. Enrollees could provide missing information needed by the
payer to reach a decision. This could allow MA organizations to address
prior authorization requests more promptly, streamlining this process,
and thus simplifying prior authorization for the MA organizations. This
could also improve an enrollee's experience with the process, by
facilitating timelier and potentially more successful initial prior
authorization requests. This, again, supports efficient operation and
timely provision of information and services.
In addition, to ensure the requirements proposed here and finalized
in the CMS Interoperability and Patient Access final rule (85 FR 25558
through 25559) would be most effective, CMS proposes in this rule that
MA organizations report specific metrics to CMS on enrollee use of the
Patient Access API. Section 1857(e)(1) of the Act explicitly authorizes
the adoption of additional reporting to CMS by MA organizations where
necessary and appropriate. Here, these proposed metrics would
facilitate CMS's oversight, evaluation, and administration of patient
health data access in the Part C program and therefore, this data
collection is necessary and appropriate to adopt.
In alignment with HHS's priorities and goals, CMS is focused on
putting patients at the center of their own healthcare and ensuring
patients have secure access to their health information. We believe
these proposals are critical and appropriate to ensure that MA
organizations stay abreast of industry standards and continue to offer
enrollees not only quality coverage but also a quality customer
experience.
b. Medicaid and CHIP
Our proposed requirements in this section for Medicaid managed care
plans and Medicaid state agencies fall generally under our authority in
sections 1902(a)(4), 1902(a)(7), 1902(a)(8), and 1902(a)(19) of the
Act. Section 1902(a)(4) of the Act requires that a state Medicaid plan
provide such methods of administration as are found by the Secretary to
be necessary for the proper and efficient operation of the state
Medicaid plan. Section 1902(a)(8) of the Act requires states to ensure
that Medicaid services are furnished with reasonable promptness to all
eligible individuals. Section 1902(a)(19) of the Act requires states to
ensure that care and services are provided in a manner consistent with
simplicity of administration and the best interests of the recipients.
In addition, section 1902(a)(7) of the Act requires that states
must provide safeguards that restrict the use or disclosure of
information concerning Medicaid applicants and beneficiaries to uses or
disclosures of information that are directly connected with the
administration of the Medicaid state plan. The implementing regulations
for this section of the Act list purposes that CMS has determined are
directly connected to Medicaid state plan administration at 42 CFR
431.302 and provide safeguards states must apply to uses and
disclosures of beneficiary data at 42 CFR 431.306. CHIP programs are
subject to the same requirements through a cross reference at 42 CFR
457.1110(b). Our proposal to require that the data described in this
section be shared via the Patient Access API would be consistent with
the requirement that states may share these data only for purposes
directly connected to the administration of the Medicaid state plan,
since this data sharing would be related to providing services for
beneficiaries, a purpose listed in Sec. 431.302(c). As mentioned
previously, giving a patient access to their own health information can
make them a more active participant in ensuring they receive timely and
appropriate care (for example, allowing them to monitor medications or
access treatment history). Additionally, states must apply the
safeguards described at 42 CFR 431.306 when sharing beneficiary data
via the Patient Access API. We remind states that in order to meet the
requirements of that regulation, states must have consistent criteria
for release and use of information (which should comply with the
proposed Patient Access API requirements, if finalized), in accordance
with 42 CFR 431.306(a). Access to information concerning beneficiaries
must be restricted to persons who are subject to standards of
confidentiality that are comparable to that of the Medicaid agency, in
accordance with 42 CFR 431.306(b). The

[[Page 76253]]

permission requirement at Sec. 431.306(d), which requires that the
State agency obtain permission from a family or individual, whenever
possible, before responding to a request for information from an
outside source, is not relevant to this proposal, because any request
for beneficiary information would be from Medicaid beneficiaries
themselves and the apps that they are authorizing to receive their
information. Beneficiaries are not ``outside sources,'' and, while apps
might be outside sources, information is shared with an app through
this API only if the beneficiary has verified their identity (through
authentication protocols) and authorized the app to receive
information. We do not believe that any of the other requirements at
section 431.306 are relevant because they cover data release and use in
contexts outside of our proposals in this section. However, we welcome
comments from state Medicaid agencies and other members of the public
on this topic.
The proposed requirement to make information about prior
authorization requests and associated documentation available through
the Patient Access API is expected to allow beneficiaries to more
easily obtain information about the status of prior authorization
requests submitted on their behalf. Beneficiaries could potentially use
that information to make more informed decisions about their
healthcare, improve the efficiency of accessing and scheduling
services, and, if needed, provide missing information that the state
(or Medicaid managed care plan, if applicable) needs to reach a
decision. Receiving missing information more quickly could enable more
prompt responses from Medicaid FFS programs and managed care plans to
prior authorization requests, thus facilitating more timely and
successful prior authorizations, which would help states fulfill their
obligations to provide care and services in a manner consistent with
simplicity of administration and the best interests of the recipients,
and to furnish services with reasonable promptness to all eligible
individuals. Improving the prior authorization process could also help
improve the efficient operation of the state plan by potentially
improving the speed and consistency of prior authorizations, which
could, in turn, facilitate faster access to care for beneficiaries. In
these ways, these proposals are authorized under section 1902(a)(4),
(8), and (19) of the Act.
In addition, this proposal would help implement section 1932(b)(4)
of the Act, which provides that each Medicaid managed care organization
must establish an internal grievance procedure under which a
beneficiary who is eligible for medical assistance may challenge the
denial of coverage or payment for such assistance. CMS has
traditionally extended requirements applicable to Medicaid managed care
organizations to other Medicaid managed care plan types as efficient
and proper methods of administration under section 1902(a)(4) of the
Act to ensure that Medicaid beneficiaries have the same protections,
benefits, and responsibilities regardless of the type of managed care
plan in which they are enrolled. Allowing beneficiaries to access the
status of their denied prior authorizations within 1 business day could
enable beneficiaries to file appeals timelier and receive faster
resolution. Enabling beneficiaries to monitor the status of prior
authorization requests submitted on their behalf is also consistent
with how section 1932(c)(2)(A) of the Act indicates that timely access
to care should be assured for beneficiaries. Knowing within 1 business
day that a prior authorization has been approved could enable a
beneficiary to more promptly schedule or obtain care.
We are also proposing to require state Medicaid agencies and
Medicaid managed care plans to report Patient Access API metrics to CMS
annually. We believe that having these metrics would support CMS'
oversight, evaluation, and administration of the Medicaid program, as
it would allow us to evaluate beneficiary access to the Patient Access
API. Use of the API could indicate that the policy is supporting
program efficiencies and ensuring access to information in a timely and
efficient way and in the best interest of beneficiaries, as intended,
and as is consistent with section 1902(a)(4) and (19) of the Act.
Additionally, section 1902(a)(6) of the Act requires Medicaid state
plans to provide that the state Medicaid agency will make such reports,
in such form and containing such information, as the Secretary may from
time to time require. These metrics would serve as a report to evaluate
the implementation and execution of the Patient Access API.
For CHIP, we propose these requirements under the authority in
section 2101(a) of the Act, which states that the purpose of Title XXI
of the Act is to provide funds to states to provide child health
assistance to uninsured, low-income children in an effective and
efficient manner that is coordinated with other sources of health
benefits coverage. This provision provides us with authority to adopt
these requirements for CHIP because the proposed requirements increase
patient access to their health information, which can improve the
efficacy of CHIP programs, allow for more efficient communication and
administration of services, and promote coordination across different
sources of health benefits coverage.
We believe that requiring CHIP agencies, as well CHIP managed care
entities, to make CHIP beneficiaries' prior authorization data and
other standardized data available through standards-based APIs would
ultimately lead to these beneficiaries accessing that information in a
convenient, timely, and portable way. This improved access would help
to ensure that services are effectively and efficiently administered in
the best interests of beneficiaries, consistent with the requirements
in section 2101(a) of the Act. We believe making patient data available
in this format would result in better health outcomes and patient
satisfaction and improve the cost effectiveness of the entire
healthcare system, including CHIP.
These proposals align with section 2101(a) of the Act in that they
also would improve the efficiency of CHIP programs. For example, adding
information about prior authorization requests to the Patient Access
API would allow beneficiaries to easily obtain the status of prior
authorization requests made on their behalf. This would in turn allow
patients to make scheduling decisions, and provide any missing
information needed by a payer to reach a decision, which makes the
prior authorization process more efficient, ultimately streamlining the
prior authorization process.
Additionally, the safeguards for applicant and beneficiary
information at subpart F of 42 CFR part 431 are also applicable to CHIP
through a cross-reference at 42 CFR 457.1110(b). As discussed above for
Medicaid, giving CHIP beneficiaries access to their prior authorization
statuses through the Patient Access API would be related to providing
services to beneficiaries, which is described at 42 CFR 431.302(c) as a
purpose directly related to state plan administration. Allowing
beneficiary access to prior authorization statuses also conforms with
provisions for beneficiary access to their records at 42 CFR
457.1110(e). We remind states that when they share beneficiary
information through the Patient Access API, they must comply with the
privacy protections at 42 CFR 457.1110 and the release of information
provisions at 42 CFR 431.306.
Finally, proposing to require state CHIP agencies and CHIP managed
care entities to report Patient Access API

[[Page 76254]]

metrics to CMS annually would help states and CMS understand how this
API can be used to continuously improve the effectiveness and
efficiency of state CHIP operations by providing information about its
use, which is an indication of the API's uptake among patients,
including how many only use it for a one-time setup consistent with
2107(b)(1) of the Act. The more we understand about the use of the
Patient Access API, the better we can assess that the API is leading to
improved operational efficiencies and providing information to
beneficiaries in a way that supports their best interests.
c. QHP Issuers on the FFEs
For QHP issuers on the FFEs, we propose these new requirements
under our authority in section 1311(e)(1)(B) of the Affordable Care
Act, which affords the Exchanges the discretion to certify QHPs if the
Exchange determines that making available such health plans through the
Exchange is in the interests of qualified individuals in the state in
which the Exchange operates.
We believe generally that certifying only health plans that take
steps to make enrollees' prior authorization requests and related
clinical documentation available through interoperable technology would
ultimately lead to these enrollees having access to that information in
a convenient, timely, and portable way, which is in enrollees' best
interests. Having simple and easy access, without special effort, to
their health information also would facilitate enrollees' ability to
detect and report fraud, waste, and abuse--a critical component of an
effective program. Adding information about prior authorization
requests to the Patient Access API would allow enrollees to easily
obtain the status of prior authorization requests submitted on their
behalf and use that information effectively to make more informed
decisions about their healthcare, improve the efficiency of accessing
and scheduling services, and, if needed, provide missing information
needed by the issuer to reach a decision. This could allow QHP issuers
on the FFEs to more promptly address prior authorization requests. This
would also facilitate timelier and potentially more successful initial
prior authorization requests. We encourage SBEs (including SBE-FPs) to
consider whether a similar requirement should be applicable to QHP
issuers on SBEs.
Finally, proposing to require QHP issuers on the FFEs to report
Patient Access API metrics to CMS annually would help CMS assess the
effect this API is having on enrollees and would inform how CMS could
either enhance the policy or improve access or use through activities
such as additional patient education. These data could help CMS
understand how best to leverage this API, and patient access to it, to
ensure this requirement is being met efficiently and adding value to
CMS operations, including leading to the efficiencies intended.

B. Provider Access API

1. Background
In the CMS Interoperability and Patient Access final rule, we
implemented policies regarding the Patient Access API (85 FR 25558)
that would allow patients to access their health information through an
app. Patients who do so could then share their information with their
provider during an appointment. For example, during a visit with a
provider, a patient could share specific diagnoses, procedures, and
tests accessed through the Patient Access API and stored on their
mobile smart device, which could help inform a discussion with their
provider about their health status.
We also discussed the potential benefits of payers sharing patient
health information directly with providers in that final rule (85 FR
25555) and encouraged payers to consider an API solution that would
enable providers to access appropriate health information through the
payers' APIs to support the delivery of care. We sought comment on the
feasibility of implementing and maintaining a FHIR API for data
exchange between payers and providers and received comments strongly
supporting our concept to require data availability through a Provider
Access API. Some commenters stated that allowing providers to receive
data, including prior authorization information, directly from payers
would make FHIR-based data exchange significantly more valuable for
patients, providers, and payers. More data could be available to help
providers manage an individual's total care and providers could reduce
or eliminate duplicate tests, which might avoid diagnostic errors.
Payers might also see fewer duplicate requests for services, fewer
appeals and, possibly, lower costs. We specifically agreed with
commenters that making information about prior authorization decisions
available via an API would reduce burden on providers and their staff
(85 FR 25541).
While using the Patient Access API is a significant first step
toward sharing individual patient health information with providers, it
would also be beneficial for payers to make patient data directly
available to providers via a FHIR API. In the normal course of
business, many providers already maintain EHRs and share data for a
variety of purposes authorized by the patient and/or existing law.
Therefore, in this rule we propose to require that impacted payers
implement and maintain a FHIR API that makes patient data available to
providers who have a contractual relationship with the payer and a
treatment relationship with the patient. The proposed Provider Access
API has the potential to allow payers to build upon their existing
systems and processes to enhance access to patient data, while
continuing to protect patient privacy and data security.
In the December 2020 CMS Interoperability proposed rule, we
proposed to require payers to build a Provider Access API. As discussed
in section I.A. of this proposed rule, we are withdrawing the December
2020 CMS Interoperability proposed rule and issuing this new proposed
rule that incorporates the feedback we received from stakeholders on
that proposed rule. We understand that many readers may already be
familiar with that proposed rule. To distinguish between that proposed
rule and our proposals herein, we refer readers to section I.A. of this
proposed rule, which outlines the overarching differences between the
two proposed rules.
We are again proposing to require impacted payers to implement and
maintain a FHIR API to exchange data with providers, but with changes
from the December 2020 CMS Interoperability proposed rule. We are again
proposing a FHIR API, but we are now taking a different approach to the
standards required for the API, as further described in section II.F.
of this proposed rule. We are also proposing a patient opt out (rather
than an opt in) policy that would require payers to allow patients to
opt out of the Provider Access API proposed herein. Finally, we propose
to establish the Provider Access API compliance date as January 1,
2026.
As mentioned in section I.A. of this proposed rule, these proposals
do not pertain to Medicare FFS. We seek comment on how each of our
proposals discussed below on Provider Access API could be implemented
for the Medicare FFS program. We expect that a Medicare FFS
implementation would conform to the same proposed requirements that
apply to the impacted payers under this proposed rule, as applicable,
so Medicare FFS providers and patients enrolled in Medicare FFS could
also benefit from this type of data sharing. We seek comment on whether
this

[[Page 76255]]

could be implemented as proposed for the Medicare FFS program, how we
could apply each of these proposals below, and if there would be any
differences for implementing the Provider Access API in the Medicare
FFS program as a Federal payer. As noted later in this section of this
proposed rule, CMS's Data at the Point of Care (DPC) project is
currently piloting an API that makes Medicare FFS claims and Part D
data available to certain providers. We note that because Medicare FFS
provider remittances and enrollee cost-sharing information are not
proprietary, those data are shared in the DPC pilot; however, as
discussed in this section, impacted payers would not be required to
share that information under our proposals. The information gained from
the DPC pilot will be useful to implementers should the proposals in
this proposed rule be finalized.
2. Proposed Requirements for Payers: Provider Access API for Individual
Patient Information
In the CMS Interoperability and Patient Access final rule (85 FR
25558), we required impacted payers to make certain health information
available to health apps when requested by a patient, through a Patient
Access API. We believe it would be valuable for providers to have
access to the same patient data, except for provider remittances and
enrollee cost-sharing information, through a FHIR API that allows a
provider to request data for an individual patient, as needed, thereby
providing further insight into the patient's care activity. Research
shows that patients achieve better outcomes when their record is more
complete and there are more data available to the healthcare provider
at the point of care.\29\ 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.
---------------------------------------------------------------------------

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

Therefore, we are proposing to require that impacted payers
implement and maintain a Provider Access API to enable current
patients' information to be exchanged from payers to providers that are
in that payer's network, at the provider's request. A provider in the
payer's network, for purposes of this proposal, would be any provider
or healthcare facility that is part of a specific health plan's network
of providers with which it has a contract. In the case of Medicaid and
CHIP FFS programs, it would be any providers or healthcare facilities
that are enrolled with the state as Medicaid or CHIP providers. We note
that this requirement would only apply to current patients. Once a
patient is no longer enrolled with a payer, the payer would not need to
share data with providers under this proposal. However, see section
II.C. for the proposed Payer-to-Payer API requirements for transferring
a patient's data from a previous payer to a new payer.
The proposed Provider Access API would allow a provider to initiate
a request, for example, when the provider needs access to a patient's
data prior to or during a patient visit. Both this proposed Provider
Access API and the Patient Access API would facilitate the FHIR-based
exchange of claims and encounter data, as well as all data classes and
data elements included in a content standard adopted at 45 CFR 170.213,
such as Immunizations, Procedures, and Assessment and Plan of
Treatment, should the payer maintain such information. Both the Patient
Access and Provider Access APIs would require payers to share
information related to prior authorization requests and decisions
(including related administrative and clinical documentation) for items
and services (excluding drugs). As discussed in section II.A.2.a of
this proposed rule, we are proposing to require that information about
prior authorizations (and related administrative and clinical
documentation) be available via the Patient Access API for as long as
the authorization is active, and at least 1 year after the last status
change. We note that we are formulating our proposal for at least 1
year after any status change, but this provision would be particularly
relevant to denied and expired prior authorizations, to ensure that
they would be available for at least a year after expiring or being
denied. We do not propose to require payers to share a patient's full
prior authorization history, because that could comprise a significant
amount of information that may no longer be clinically relevant.
We believe that sharing claims and encounter information, without
provider remittances and enrollee cost-sharing information, would
complement the clinical data classes and data elements included in a
content standard at 45 CFR 170.213 by providing more information to
support treatment and care coordination. Claims and encounter data used
in conjunction with clinical data can offer a broader, more complete
picture of an individual's interactions with all their providers in the
healthcare system. With this proposal, we intend to help providers gain
efficient access to more comprehensive data on their patients. Thus, we
are proposing to require that impacted payers make available any of the
applicable patient data with a date of service on or after January 1,
2016. This proposed timeframe for data to be included is consistent
with the requirements of the Patient Access API, as finalized in the
CMS Interoperability and Patient Access final rule (85 FR 25567), so
payers should already be maintaining and making available data from
this timeframe via a FHIR API.
Such disclosures from payers to healthcare providers would be
permitted under the HIPAA Privacy Rule as disclosures for treatment
purposes,\30\ as well as disclosures required by law,\31\ which this
proposed rule would be establishing if finalized. Additionally,
Medicaid and CHIP agency disclosures of beneficiary data to in-network
providers under this proposal would be consistent with section
1902(a)(7) of the Act and implementing regulations at 42 CFR part 431,
subpart F, and 42 CFR 457.1110(b). Under these provisions, states must
restrict the use or disclosure of information concerning applicants and
beneficiaries to purposes directly connected with the administration of
the plan. The disclosures of patient data through the Provider Access
API would be directly related to the administration of the state plan
because they would support the provision of services for beneficiaries,
as described in 42 CFR 431.302(c). As mentioned, a provider could
better manage a patient's total care when they have access to more of
that patient's data because the data would provide a more in-depth
medical history, enable more informed decision making, and potentially
prevent the provision or ordering of duplicative services.
Additionally, states must apply the safeguards described in 42 CFR
431.306 when sharing beneficiary data via the Provider Access API. We
remind states that in order to meet the requirements of that
regulation, they must have consistent criteria for release and use of
information (which should comply with the proposed Provider Access API
requirements, if finalized), in accordance with 42 CFR 431.306(a).
Access to information concerning

[[Page 76256]]

beneficiaries must be restricted to persons or agency representatives
who are subject to standards of confidentiality that are comparable to
that of the Medicaid agency, in accordance with 42 CFR 431.306(b). The
permission requirement in Sec. 431.306(d), which requires that the
State agency obtain permission from a family or individual, whenever
possible, before responding to a request for information from an
outside source, is not relevant to this proposal, because any request
for beneficiary information would be from an enrolled Medicaid or CHIP
provider and thus would not be from an ``outside source.'' A Medicaid
or CHIP provider would have a provider agreement with the Medicaid or
CHIP agency in order to provide Medicaid or CHIP benefits and services
under its state plan. As such, Medicaid and CHIP providers are part of
the state's Medicaid and CHIP program assisting the state agency in
carrying out core functions of the state's Medicaid or CHIP State Plan,
providing benefits and services to beneficiaries. Therefore, no
additional consent from the beneficiary or personal representative
would need to be obtained by the Medicaid or CHIP agency prior to
sharing the individual's information with a Medicaid or CHIP provider.
We note that while patient permission is not required under Sec.
431.306(d) for the proposals we discuss here, state, or other laws may
require such permission. We do not believe that any of the other
requirements of 42 CFR 431.306 are relevant because they cover data
release and use in contexts outside of our proposals in this section.
However, we welcome comments from state Medicaid agencies and other
members of the public on this topic.
---------------------------------------------------------------------------

\30\ See 45 CFR 164.506(c)(2).
\31\ See 45 CFR 164.512(a).
---------------------------------------------------------------------------

There are a few notable differences between the requirements for a
Patient Access API and our proposals for a Provider Access API. The
biggest difference is how and why the end user would access the data.
For the Patient Access API, the patient is requesting access to their
own data through a health app for their own reference and use. For the
Provider Access API proposals, the provider would request and receive
access to the patient's information through their EHR, practice
management system, or other technology solution for treatment purposes,
including care coordination. Providers would securely access their
patients' data using at least one of these systems through a FHIR API.
Providers would not access patient data through their own health app;
rather, the data would flow from the payer to the provider's EHR or
practice management system, which would allow them to incorporate the
patient data into their records. For example, a provider who is
preparing for an upcoming appointment may need more information about
the patient than is contained in the patient's record. Under this
proposal, the provider would be able to request the additional data
from the patient's payer, provided the patient has not opted out (as
explained in section II.B.3.b. of this proposed rule). The payer would
then be required to share the requested data no later than 1 business
day after the provider initiates this request.
Finally, unlike the Patient Access API, we propose that the
Provider Access API would not include provider remittances and enrollee
cost-sharing information. Many payers consider cost-sharing information
proprietary, and we believe that information would have limited benefit
for treatment or care coordination. We note that our proposals in
section II.C. of this proposed rule would exclude provider remittances
and enrollee cost-sharing information from the payer to payer data
exchange, and we propose the same for the Provider Access API.
In the CMS Interoperability and Patient Access final rule CMS
required standards for the Patient Access API by cross reference to 45
CFR 170.215 (85 FR 25558). In this proposed rule, we are proposing to
amend these cross references, as discussed in section II.F. We also
propose, at the CFR citations listed in Table 2, that the Provider
Access API would require adherence to the same technical standards, API
documentation requirements, and standards for denial or discontinuation
of access to the API. Additionally, we note that unlike for the Patient
Access API, we are proposing to require the FHIR Bulk Data Access
Implementation Guide at 45 CFR 170.215(a)(4). For a complete discussion
of these requirements, we refer readers to the CMS Interoperability and
Patient Access final rule (85 FR 25526) and to section II.F. of this
proposed rule.
We acknowledge that it could be helpful for all providers to have
access to their patients' data regardless of contractual or enrollment
relationships with a patient's payer. However, if a provider does not
have a provider agreement or is not enrolled (in the case of Medicaid
and CHIP FFS programs) with a payer that holds their patient's data,
the payer would not be required to provide patient data to that
provider under this proposal, though it may be permissible or even
required by other law or regulation. We recognize that this could make
it more difficult for an out-of-network provider to create a
comprehensive care record for a patient. We considered requiring payers
to share the data with all providers, regardless of whether the
provider is under contract or enrolled with the payer. However, for
reasons we explain in this section of this proposed rule, we are not
proposing to do so, and are instead seeking comment on various issues
surrounding that possible requirement. Though we are not proposing to
require it at this time, we encourage payers to share information via
API with out-of-network or unenrolled providers who have a verified
treatment relationship with the patient, to the extent permitted by
law.
There could be privacy, security, and program integrity concerns
with requiring payers to share patient information with out-of-network
providers. For example, because MA organizations, Medicaid FFS
programs, CHIP FFS programs, Medicaid managed care plans, and CHIP
managed care entities must ensure they do not enroll or contract with
providers that are on the HHS Office of the Inspector General List of
Excluded Individuals/Entities (LEIE), limiting data sharing through the
Provider Access API to in-network or enrolled providers can help ensure
these data are not shared with providers who have already been
determined by the Federal Government to present fraud or other program
integrity risks. Since these risks exist, if we were to require payers
to share patient information with out-of-network providers, we would
also have to require payers to establish safeguards to ensure that an
out-of-network provider would be a trustworthy recipient of patient
information. This could create significant burden for payers who may
need to expend resources towards vetting providers with whom they do
not have an existing relationship.
The LEIE does not apply to QHPs, but in order to offer coverage
through the FFEs, they must comply with certification rules per 45 CFR
part 156, which includes requirements to prevent QHP issuers from
contracting with providers known to submit fraudulent or wasteful
claims. For example, Sec. 156.810(a)(7) specifies that a QHP issuer
may be decertified if, based on credible evidence, they have committed
or participated in fraudulent or abusive activities, including
submission of false or fraudulent data. Section 156.340 provides that a
QHP issuer is responsible for its own compliance and the compliance of
any of its delegated or downstream entities with all applicable Federal
standards related to Exchanges. Per Sec. 156.20, ``delegated entity''
means any party that enters into an agreement with a QHP issuer to

[[Page 76257]]

provide administrative services or health care services (for example,
contracted providers). Section 156.20 also defines a ``downstream
entity'' as any party that enters into an agreement with a delegated
entity or with another downstream entity to provide administrative
services or health care services (for example, subcontracted
providers). Thus, in order to maintain certified status, QHP issuers
generally must have processes in place to avoid contracting with
providers that engage in fraudulent practices. QHP issuers that also
provide out-of-network coverage can make the determination of whether
or not to share data with out-of-network providers using their existing
processes.
As we consider imposing a requirement to share patient data with
out-of-network providers through future rulemaking, we request comment
on how payers do so today, the effectiveness of current processes to
validate the treatment relationships between patients and providers
when a contractual relationship does not exist between the provider and
the payer, and what additional program integrity safeguards might be
appropriate when other contractual mechanisms are not in place to
ensure that patient data are provided only to qualified, trustworthy
providers. We are particularly interested in the following questions:
How would out-of-network providers request access to their patients'
data and demonstrate that the provider has a treatment relationship
with the patient? What processes and verification requirements would we
need to require each payer to establish to verify the patient-provider
treatment relationship? Should payers consider certain provisions in
data use or data exchange agreements? If so, what could those
provisions address? What are current best practices for terms of
service? What other operational best practices for enabling safe data
exchange with out-of-network providers should CMS consider in
determining whether to propose a policy requiring this?
We emphasize that all data shared and received via this proposed
data exchange would still have to be handled in a way that is
consistent with all current and applicable laws and regulations, and
our proposals are not intended to modify those other laws. Payers and
healthcare providers that are covered entities under HIPAA are subject
to the HIPAA Rules. Adherence to the HIPAA Rules would ensure that the
provider disclosing patient data through the Provider Access API has
appropriate security protocols in place.\32\ These include, but are not
limited to, administrative and technical safeguards such as access
authorization and audit controls.\33\ Regardless of whether a provider
meets the definition of a covered entity under the HIPAA Rules at 45
CFR 160.103,\34\ there may also be state laws that require certain
privacy and security protections for health information exchange.
Additionally, other laws, such as the regulations that focus on
confidentiality of patient records associated with substance use
disorder at 42 CFR part 2 or state privacy laws, may require the payer
to obtain the enrolled individual's permission to disclose certain PHI.
We request comment on any other considerations regarding state privacy
or other laws that may be implicated by our proposals.
---------------------------------------------------------------------------

\32\ See 45 CFR part 164, subparts A and C.
\33\ Department of Health and Human Services (2022). Security
Rule Guidance Material. Retrieved from https://www.hhs.gov/hipaa/for-professionals/security/guidance/?language=es.
\34\ 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.
---------------------------------------------------------------------------

We are proposing to require, at the CFR citations identified in
Table 2, that impacted payers share certain patient information with
in-network and enrolled providers who have a treatment relationship
with the payers' patients upon request by the provider. Thus, payers
would be required by regulation to make such disclosures if there is a
treatment relationship with the individual. The HIPAA Privacy Rule
permits a covered entity, such as a health plan, to disclose PHI of the
enrolled individual to a health care provider without individual
authorization for treatment purposes under 45 CFR 164.506(c)(2) or as
required by law per 45 CFR 164.512(a)(1).
Our proposal would not alter any obligation for HIPAA-covered
entities to follow the HIPAA Rules or other applicable law, including,
but not limited to, standards regarding the use and disclosure of PHI,
administrative, physical, and technical safeguards and other security
provisions, and breach notification. The security framework of the
proposed API, as required via reference to standards at 45 CFR 170.215,
would allow payers to verify the requesting provider's identity by
using the required authorization and authentication protocols.
Authorization refers to the process by which the payer would give the
provider permission to access data. The authentication protocols are
those that would allow the payer to ensure that the provider that is
requesting this access is who they say they are. In addition to using
these required protocols, the payer would be required to share the
specified data only if it can also attribute the patient to the
provider using an attribution process, as discussed in this section of
this proposed rule in detail. While FHIR itself does not define
security-related functions, used in combination with appropriate
security controls (such as authentication and access control), a FHIR
API can and should be implemented in compliance with the HIPAA Security
Rule for secure data exchange.\35\
---------------------------------------------------------------------------

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

HIPAA also requires the Secretary to adopt standards for specific
transactions and establish a process for updating those standards. A
HIPAA transaction is an electronic transmission of information from a
covered entity to carry out financial or administrative activities
related to health care (for example, when a health care provider sends
a claim to a health plan to request payment for medical services) for
which the Secretary has adopted a standard. Under HIPAA, HHS is
required to adopt standards for electronically transmitting certain
health care information, including:
Health care claims or equivalent encounter information;
Health care electronic funds transfers and remittance
advice;
Health care claim status;
Eligibility for a health plan;
Enrollment and disenrollment in a health plan;
Referrals certification and authorization;
Coordination of benefits;
Health plan premium payments; and
Medicaid pharmacy subrogation (not mandated under HIPAA,
but, consistent with section 1173(a)(1)(B) of the Social Security Act,
a standard has been adopted for this purpose).
The Secretary has adopted a HIPAA transaction standard for
transmitting claims or equivalent encounter information. Although our
proposals would facilitate sharing claims data from payers to
providers, the transmission would not be subject to HIPAA transaction
standards because the purpose of the exchange would not be to request
or issue a payment.\36\ We are also not proposing a mechanism to

[[Page 76258]]

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.\37\ Therefore, a HIPAA
transaction standard is not required to be used for our proposals in
this section because the Secretary has not adopted a HIPAA standard
applicable to communicating claims or encounter information for a
purpose other than requesting or issuing payment.\38\
---------------------------------------------------------------------------

\36\ See 45 CFR 162.1101(a) and 162.1601(a).
\37\ See 45 CFR 162.1101(b)
\38\ See 45 CFR 162.923(a).
---------------------------------------------------------------------------

In summary, we propose that beginning January 1, 2026 (for Medicaid
managed care plans and CHIP managed care entities, by the rating period
on or after January 1, 2026, and for QHP issuers on the FFEs, for plan
years beginning on or after January 1, 2026), impacted payers would be
required to implement and maintain a FHIR API to exchange data with
providers conformant to the standards discussed in section II.F and at
the CFR citations referenced in Table 9. Individual patient data
maintained by the payer with a date of service on or after January 1,
2016, must be made available via that API no later than 1 business day
after the payer receives a request for data by an in-network provider,
(or in the case of a Medicaid or CHIP FFS program, an enrolled Medicaid
or CHIP provider).
We are proposing these requirements for the Provider Access API for
MA organizations, state Medicaid and CHIP FFS programs, Medicaid
managed care plans, CHIP managed care entities (excluding Non-Emergency
Medical Transportation (NEMT) PAHPs, as explained in this section of
this proposed rule), and QHP issuers on the FFEs at the CFR sections
identified in Table 2.
For Medicaid and CHIP managed care, we propose that NEMT PAHPs, as
defined at 42 CFR 438.9(a) and 457.1206(a) respectively, would not be
subject to the requirement to establish a Provider Access API. MCOs,
PIHPs, and non-NEMT PAHPs would be subject to this proposed rule. We
believe that the unique nature and limited scope of the services
provided by NEMT PAHPs, in that they only cover transportation and not
medical care itself, justify their exclusion from the requirements of
the Provider Access API proposed at 42 CFR 431.61(a). Specifically, we
do not believe that providers have routine need for NEMT data;
therefore, requiring NEMT PAHPs to implement and maintain a Provider
Access API would be an undue burden. However, we propose to include
NEMT PAHPs in the scope of most of the other requirements of this
proposed rule that apply to all other Medicaid managed care plans
listed in Table 2.
We request public comment on the proposal for impacted payers to
implement and maintain a Provider Access API to provide access to
specified patient information.
3. Additional Proposed Requirements for the Provider Access API
In general, the proposals discussed in this section regarding the
data that payers must make available through the API, as well as the
technical specifications, align with the requirements for the Patient
Access API finalized in the CMS Interoperability and Patient Access
final rule (85 FR 25558) and as proposed in section II.A.2. of this
rule. We anticipate that this alignment would provide consistency and
help payers build on the work done to comply with the requirements for
the Patient Access API, outlined previously. Additional proposed
requirements for the Provider Access API regarding attribution, patient
opt out process, patient resources, and provider resources are
discussed in the sections that follow.
a. Attribution
Patient attribution is a method of identifying a patient-provider
treatment relationship. Attribution is a critical component to ensure
that patient health data are shared only with appropriate providers.
For the Provider Access API, we are proposing to require that payers
develop an attribution process to associate patients with their
providers to help ensure that a payer only sends a patient's data to
providers who are requesting that data and who have a treatment
relationship with that patient.
We are aware that the process of attribution can have many
functions for payers, including managing contracts, payments, financial
reconciliation, reporting, and continuity of care. In addition, HL7 has
developed a member attribution process and workflow in the Da Vinci
Member Attribution List FHIR Implementation Guide (IG), which defines
various terms and describes a general process by which a payer and
provider can coordinate and reconcile their understanding of which
patients associated with a particular payer-provider contract.\39\ This
IG does not specify how the payer and provider identify these patients,
but it does specify the FHIR resources (that is, data elements) which
are created as an output of this process. We thus encourage payers to
use processes that they may already have to attribute patients to their
providers for these other purposes.
---------------------------------------------------------------------------

\39\ Health Level Seven International (2021, February 8). Da
Vinci Member Attribution (ATR) List. Retrieved from https://hl7.org/fhir/us/davinci-atr/.
---------------------------------------------------------------------------

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

\40\ Health Level Seven International (2022). Argonaut
Scheduling IG (Release 1.0.0). Retrieved from https://fhir.org/guides/argonaut/scheduling/.
---------------------------------------------------------------------------

CMS has implemented an attribution process in our DPC pilot for
Medicare beneficiaries, which is the Medicare FFS version of the
Provider Access API. The pilot project requires HIPAA-covered entities
or their business associates to agree to certain terms of service \41\
before data can be sent to them. The current Medicare FFS terms of
service require each organization to maintain a list of patients which
represents the patient population currently being treated at their
facilities.\42\ To add a new patient, CMS requires providers to attest
that they have a treatment-related purpose for adding a patient to
their group. This is accomplished by submitting an attestation with
every request to add a

[[Page 76259]]

patient to their roster. This pilot will continue to test methodologies
to accurately attribute patients to their providers. The information
gained from this pilot may assist the industry to develop procedures to
identify providers under this proposed requirement.
---------------------------------------------------------------------------

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

Based on feedback from the industry, the HL7 Da Vinci attribution
work group has developed a published Member Attribution List IG.\43\
The Da Vinci Member Attribution List IG defines the mechanisms (that
is, protocols), data structures and value sets to be used for
exchanging the Member Attribution List. The Member Attribution List
supported by the Da Vinci Member Attribution List IG typically
contains: (1) plan/contract information which is the basis for the
Member Attribution List, (2) patient information, (3) attributed
individual provider information, (4) attributed organization
information, and (5) member and subscriber coverage information. DPC
has been working with the Da Vinci Member Attribution List team towards
compatibility with this IG.\44\ We also note that the list capability
of this IG is informing updates to the Da Vinci Payer Data Exchange
(PDex) IG.\45\ We encourage payers to review the information from the
workgroup.
---------------------------------------------------------------------------

\43\ Health Level Seven International. (2021, February 8). Da
Vinci Member Attribution (ATR) List. Retrieved from https://hl7.org/fhir/us/davinci-atr/.
\44\ Centers for Medicare Medicaid Services. (n.d.) Groups. Data
at the Point of Care. Retrieved from https://dpc.cms.gov/docsV2#groups.
\45\ Health Level Seven International (2020). Da Vinci Payer
Data Exchange. Retrieved from https://hl7.org/fhir/us/davinci-pdex/STU1/.
---------------------------------------------------------------------------

We do not wish to be overly prescriptive about how payers could
generate an attribution list for providers, but it would be necessary
for payers to establish a process to meet these proposed attribution
requirements for the Provider Access API. Because the standards for the
attribution process continue to evolve, we are not specifying how
payers should identify whether a specific patient can be attributed to
the requesting provider. Instead, we encourage the community to
continue to collaborate on viable approaches.
We also recognize that impacted payers may already have multiple
arrangements in place with providers to support data exchange, and may
even participate in community, local, state, or private health
information exchanges (HIEs). In many cases, these HIEs include patient
attribution capabilities for which payers may already have a process.
Once again, our goal is for payers to avoid having to develop multiple
approaches to address attribution, and we encourage collaboration on
potential solutions.
In summary, we propose that beginning January 1, 2026 (for Medicaid
managed care plans and CHIP managed care entities, by the rating period
beginning on or after January 1, 2026, and for QHP issuers on the FFEs
for plan years beginning on or after January 1, 2026), impacted payers
would maintain a process to associate patients with their in-network or
enrolled providers to enable payer to provider data exchange via the
Provider Access API.
We are proposing these attribution requirements for MA
organizations, state Medicaid and CHIP FFS programs, Medicaid managed
care plans other than NEMT PAHPs, CHIP managed care entities, and QHP
issuers on the FFEs at the CFR sections identified in Table 2.
We solicit comments on our proposal to require payers to develop
processes for verifying the patient-provider treatment relationship,
including any processes that may be in place today.
b. Opt Out
We are proposing that all impacted payers would be required to
establish and maintain a process to allow patients or their personal
representatives to opt out of having the patients' data available for
providers to access through the Provider Access API. We note that this
differs from our Payer-to-Payer API proposal in section II.C.3.c. of
this proposed rule, under which all impacted payers would have an opt
in process. Similar to the proposed attribution process, as previously
discussed, we do not intend to be prescriptive regarding how this opt
out process should be implemented, but payers would be required to make
this opt out process available, and give all currently enrolled
patients or their personal representatives a chance to opt out, before
the first date on which patient information is made available via the
Provider Access API. Specifically, we are proposing that impacted
payers must maintain a process to allow patients or their personal
representatives to opt out of data sharing, or if they have already
opted out, to opt back in. The process for opting out and opting back
in would have to be available before the first date on which patient
information is made available via the API and at any time while the
patient is enrolled with the payer. We are not proposing to require
specific methods for patients to opt out, but anticipate that payers
would make that process available by mobile smart device, website, and/
or apps. We also anticipate that mail, fax, or telephonic methods may
be necessary alternatives for some patients, which payers would have to
accommodate if this policy is finalized as proposed. We invite comments
on whether we should establish more explicit requirements regarding
patient opt out processes.
Our proposal would require payers to allow patients to opt out of
the Provider Access API data exchange for all providers in that payer's
network. However, we also encourage payers to implement processes that
allow more granular controls over the opt out process, so patients can
opt out of having data exchanged with individual providers or groups of
providers. We are not proposing implementation of such processes as a
requirement in this rulemaking, as we are concerned about the potential
administrative and technical burden this may place on some payers.
However, we request comments about the technical feasibility of
implementing an opt out process that would allow patients to make
provider-specific opt out decisions, and whether we should consider
proposing such a requirement in future rulemaking.
We are proposing an opt out approach because opt in models of data
sharing, as we discuss in this section of this rule, have been shown to
inhibit the utilization and usefulness of data sharing efforts between
patients and healthcare providers. We acknowledge that there are
positives and negatives to both opt in and opt out policies, and many
patients may prefer to control or direct their health information via
an opt in process because opt in policies require affirmative
permission from a patient before their data can be shared. However,
patients who are less technologically savvy or have lower health
literacy may be less likely to use the Patient Access API, so having an
opt out policy for the Provider Access API would facilitate sharing
data directly with the provider, without requiring intervention by the
patient. We believe this would promote the positive impacts of data
sharing between and among payers, providers, and patients to support
care coordination and improved health outcomes, which could lead to
greater health equity. In formulating our proposal, we carefully
weighed the issues related to both opt in and opt out policies,
especially as they relate to making data available to providers. We
believe that a proposal defaulting to share data with providers, unless
a patient opts out, appropriately balances the benefits of data sharing
with the right of patients to control their health information. As we
propose in more

[[Page 76260]]

detail in this section of this rule, payers would be responsible for
providing patient resources to ensure that patients understand the
implications of the opt out option. We note that should patients choose
not to opt out of data sharing, then the data we propose be made
available via the Provider Access API would be available at any time to
providers that have been attributed to have a treatment relationship
with the patient. However, we believe our proposals, taken together,
would give patients ample opportunities to change their data sharing
preference as they see fit.
Opt in models can create greater administrative burden for smaller
healthcare organizations, depending on where the responsibility for
obtaining and updating the patient's data sharing preference is held.
We note that smaller hospitals in states with opt in patient permission
requirements for HIE are more likely to report regulatory barriers to
data exchange compared with those in states with opt out policies,
though more technologically advanced hospitals reported no
difference.\46\ A report produced for ONC found that states using an
opt out model were quantitatively associated with significantly higher
HIE utilization and maturation.\47\ A 2016 survey found that of the 24
states that give patients a choice regarding participation in the HIE,
16 states have laws describing an opt out procedure, and eight states
have enacted an opt in procedure.\48\ We note that for this report,
``HIE'' refers exclusively to organizations that facilitate information
exchange among healthcare providers, as opposed to the act of
exchanging data for other purposes.
---------------------------------------------------------------------------

\46\ Apathy, N.C., & Holmgren, A.J. (2020). Opt-In Consent
Policies: Potential Barriers to Hospital Health Information
Exchange. The American Journal of Managed Care. 26(1). Retrieved on
January 27, 2022, from https://doi.org/10.37765/ajmc.2020.42148.
\47\ NORC at the University of Chicago (2016, March). Evaluation
of the State HIE Cooperative Agreement Program: Final Report.
Retrieved on January 27, 2022, from https://www.healthit.gov/sites/default/files/reports/finalsummativereportmarch_2016.pdf.
\48\ Schmit et al. (2018). Falling short: how state laws can
address health information exchange barriers and enablers. Journal
of the American Medical Informatics Association. 25(6). Retrieved on
January 27, 2022, from https://academic.oup.com/jamia/article/25/6/635/4587931.
---------------------------------------------------------------------------

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

\49\ Donahue et al. (2018). Veterans Health Information
Exchange: Successes and Challenges of Nationwide Interoperability.
AMIA Annu Symp Proc. Retrieved on January 27, 2022, from https://www.ncbi.nlm.nih.gov/labs/pmc/articles/PMC6371252/.
\50\ U.S. Department of Veteran Affairs (2019, September 30). VA
improves information sharing with community care providers. https://www.va.gov/opa/pressrel/pressrelease.cfm?id=5322.
\51\ U.S. Department of Veteran Affairs (2020, April 20). VA,
DoD implement new capability for bidirectional sharing of health
records with community partners. https://www.va.gov/opa/pressrel/pressrelease.cfm?id=5425.
---------------------------------------------------------------------------

In the December 2020 CMS Interoperability proposed rule, we
proposed an opt in patient permission model for the Provider Access API
and requested comments on opt in versus opt out approaches. In
response, commenters overwhelmingly supported an opt out model and
cited clinical and operational hurdles associated with an opt in
approach. Support for an opt out approach came from both provider
associations and payers, while patient commenters did not oppose such a
proposal. We also believe that an opt out model could address equity
issues by ensuring that patients from lower socioeconomic and minority
groups, who are more likely to have limited health literacy,\52\ can
benefit from the improved care that the Provider Access API can
facilitate. We believe that data sharing as the default option for all
patients enhances both personal and organizational health literacy, as
they are defined by the Healthy People 2030 report,\53\ while
protecting patients' choice to limit data sharing.
---------------------------------------------------------------------------

\52\ U.S. Department of Health and Human Services. Office of
Disease Prevention and Health Promotion (2010). National Action Plan
to Improve Health Literacy. Retrieved from https://health.gov/sites/default/files/2019-09/Health_Literacy_Action_Plan.pdf.
\53\ 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.
---------------------------------------------------------------------------

This proposed opt out option is specific to the data we are
proposing payers be required to share via the Provider Access API. As
discussed previously, this proposed rule would not alter any other
requirements under applicable privacy and security laws and
regulations. If there is other authority to share patient information
with respect to which a patient may not opt out, such as disclosures
required by law, nothing in this proposal would change the payer's
obligation to disclose that information. However, if finalized, we
would encourage payers and providers to use the proposed Provider
Access API as a technical solution to transmit data between payers and
providers beyond the scope of these proposals, provided such disclosure
is consistent with all other applicable requirements, such as the HIPAA
Rules. We also note that the HIPAA Rules permits health plans to
disclose PHI, without an individual's authorization, to providers via
the Provider Access API for certain permitted purposes under the HIPAA
Rules, such as, for example, treatment, payment, or health care
operations \54\
---------------------------------------------------------------------------

\54\ See 45 CFR 164.506(c)(2).
---------------------------------------------------------------------------

We value the importance of safeguarding the quality and integrity
of patient health information. We acknowledge that there may be
potential program integrity risks associated with sharing patient data
under both an opt in and opt out model. We believe that payers already
have program integrity protocols through which they determine if a data
exchange has resulted in potential fraud and coordinate investigations
of any potential fraud with the relevant programmatic authorities or
state laws. We expect that if payers identify any vulnerabilities, they
would work to make changes to their operations to address risks that
could lead to potential fraud and to limit the impact on patient
information.
In summary, we propose that beginning January 1, 2026 (for Medicaid
managed care plans and CHIP managed care entities, by the rating period
beginning on or after January 1, 2026, and for QHP issuers on the FFEs
for plan years beginning on or after January 1, 2026), impacted payers
must maintain a process for patients or their personal representatives
to opt out of and subsequently opt into having the patient's health
information available

[[Page 76261]]

and shared via the Provider Access API. We propose that this process
must be made available before the first date on which the payer makes
patient information available via the Provider Access API, and at any
time while the patient is enrolled with the payer.
We are proposing this requirement for MA organizations, state
Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP
managed care entities, and QHP issuers on the FFEs at the CFR sections
identified in Table 2.
We request comments on our proposal for a patient opt out framework
for the Provider Access API. We additionally request comments on
whether patients should be able to exercise more granular controls over
which data they permit the payer to share, including permitting the
sharing of certain data from only specific timeframes.
c. Patient Resources Regarding the Provider Access API
To ensure that patients understand the implications of the opt out
option for the Provider Access API, we are proposing to require payers
to provide information to their patients about the benefits to the
patient of the Provider Access API requirements, their opt out rights,
and instructions both for opting out of the data exchange and for
opting in after previously opting out. Payers would have to provide
this information, in non-technical, simple, and easy-to-understand
language, at the time of enrollment and annually. Payers would also be
required to make this information available at all times, in an easily
accessible location on payers' public websites. We are not proposing
specific text or format of this information, but we request comments on
whether there are benefits or burdens to requiring that this
information be provided in a specific format or to include specified
content. In particular, we are interested in comments on language
regarding how patient data could be used and shared through the API. We
anticipate payers would include information about patients' ability to
opt out of (and opt back in to) this data sharing in their regular
communications, such as annual enrollment information, privacy notices,
member handbooks, or newsletters. However, we request comment on the
most appropriate and effective communication channel(s) for conveying
this information to patients. We also request comment on whether
providing this information at the time of enrollment and annually is
appropriate, or whether we should require that this information be
provided directly to the patient more frequently.
We believe it is important to honor patient privacy preferences,
and believe it is important for providers to have access to patient
information to be able to provide treatment and coordinate care
effectively. We also believe that more informed patients are more
empowered patients, which we believe leads to increased engagement with
their care and ultimately improved health outcomes. Offering patients
educational materials about their right to opt out of data sharing via
the proposed Provider Access API is thus fundamental to empowering
patients with their data.
In summary, we propose that beginning January 1, 2026 (for Medicaid
managed care plans and CHIP managed care entities, by the rating period
beginning on or after January 1, 2026, and for QHP issuers on the FFEs
for plan years beginning on or after January 1, 2026), impacted payers
must provide information in non-technical, simple, and easy-to-
understand language to their patients about the benefits of API data
exchange with their providers, their opt out rights, and instructions
both for opting out of data exchange and for opting in after previously
opting out. We are proposing that these payers must make this
information available to currently enrolled patients before the
Provider Access API is operational and shares any of their data. We are
proposing that thereafter, payers provide this information at
enrollment and at least annually. We are also proposing that this
information be available in an easily accessible location on payers'
public websites.
We are proposing this requirement for annual information for MA
organizations, state Medicaid and CHIP FFS programs, Medicaid managed
care plans, CHIP managed care entities, and QHP issuers on the FFEs at
the CFR sections identified in Table 2.
d. Provider Resources Regarding the Provider Access API
We are proposing to require payers to develop non-technical and
easy-to-understand educational resources for providers about the
Provider Access API. These educational resources should explain how a
provider can request patient data using the payer's Provider Access
API. The resources would have to include information about the process
for requesting patient data from the payer using the API and how to use
the payer's attribution process to associate patients with the
provider. We are proposing that impacted payers provide these resources
to providers through the payer's website and other appropriate provider
communications, such as annual contract updates or handbooks. Non-
technical resources would help providers understand how they can use
the API to access patient data, thus realizing the expected benefit of
the proposed API.
Specifically, we propose that beginning January 1, 2026 (for
Medicaid managed care plans and CHIP managed care entities, by the
rating period beginning on or after January 1, 2026, and for QHP
issuers on the FFEs for plan years beginning on or after January 1,
2026), impacted payers would provide educational resources in non-
technical and easy-to-understand language on their websites and through
other appropriate mechanisms for communicating with providers,
explaining how a provider may make a request to the payer for patient
data using the FHIR API. We also propose that those resources must
include information about the mechanism for attributing patients to
providers.
We are proposing this requirement for provider resources for MA
organizations, state Medicaid and CHIP FFS programs, Medicaid managed
care plans, CHIP managed care entities, and QHP Issuers on the FFEs at
the CFR sections identified in Table 2.
We request comment on this proposal, including whether CMS should
develop guidance regarding, or address in future rulemaking the
specific content of these educational materials about the Provider
Access API.
4. Extensions, Exemptions, and Exceptions
a. Extensions and Exemptions for Medicaid and CHIP FFS Programs
Should our proposals regarding the Provider Access API be finalized
as proposed, we would strongly encourage state Medicaid and CHIP FFS
programs to implement the Provider Access API as soon as possible, due
to the many anticipated benefits of the API as discussed in this
section. However, we also recognize that state Medicaid and CHIP FFS
agencies may face certain circumstances that would not apply to other
impacted payers. To address these concerns, we are proposing a process
through which states may seek an extension of, and, in specific
circumstances, an exemption from, the Provider Access API requirements.
We propose the following:
(1) Extension
At the regulation citations identified in Table 2, we propose to
provide state Medicaid FFS and CHIP FFS programs the opportunity to
request a one-time

[[Page 76262]]

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

\55\ State hiring processes are comparable with Federal hiring
processes. According to the Office of Management and Budget (OMB),
the average time-to-hire for Federal employees was 98.3 days in
2018, significantly higher than the private sector average of 23.8
days. See https://www.opm.gov/news/releases/2020/02/opm-issues-updated-time-to-hire-guidance/.
---------------------------------------------------------------------------

Should the proposal for this API be finalized as proposed, states
would be permitted to submit a written application for a one-time, one-
year extension as a part of their annual Advance Planning Document
(APD) for Medicaid Management Information System (MMIS) operations
expenditures. The state's request would have to include the following:
(1) a narrative justification describing the specific reasons why the
state cannot reasonably satisfy the requirement(s) by the compliance
date, and why those reasons result from circumstances that are unique
to the agency operating the Medicaid and/or CHIP FFS program (versus
other types of impacted payers); (2) a report on completed and ongoing
state implementation activities that evidence a good faith effort
towards compliance; and (3) a comprehensive plan to meet the Provider
Access API requirements no later than 1 year after the compliance date.
Under this proposal, CMS would approve an extension if, based on
the information provided in the APD, CMS determines that the request
adequately establishes a need to delay implementation, and that the
state has a comprehensive plan to implement the proposed requirements
no later than 1 year after the compliance date. We also solicit
comments on whether our proposal would adequately address the unique
circumstances that affect states and that might make timely compliance
with the proposed API requirement difficult for states.
(2) Exemption
At the CFR sections identified in Table 2, we propose to permit
state Medicaid FFS programs to request an exemption from the Provider
Access API requirements when at least 90 percent of the state's
Medicaid beneficiaries are enrolled in Medicaid managed care
organizations as defined at 42 CFR 438.2. Likewise, we propose that
separate CHIP FFS programs could request an exemption from the Provider
Access API requirements if at least 90 percent of the state's separate
CHIP beneficiaries are enrolled in CHIP managed care entities, as
defined at 42 CFR 457.10. In this circumstance, the time and resources
that the state would need to expend to implement the Provider Access
API requirements for a small FFS population may outweigh the benefits
of implementing and maintaining the API. Unlike other impacted payers,
state Medicaid and CHIP FFS programs do not have a diversity of plans
to balance implementation costs for those plans with low enrollment. If
there is low enrollment in a state Medicaid or CHIP FFS program, there
is no potential for the technology to be leveraged for additional
beneficiaries. States, unlike other payers, do not maintain additional
lines of business.
We acknowledge that the proposed exemption could mean that most
beneficiaries enrolled with exempted Medicaid or CHIP FFS programs
would not receive the full benefits of having this API available to
facilitate health information sharing with providers. To address this,
we propose that states that are granted an exemption would be expected
to implement an alternative plan to ensure that enrolled providers will
have efficient electronic access to the same information through other
means, to help ensure that Medicaid or CHIP services are provided with
reasonable promptness and in a manner consistent with simplicity of
administration and in the best interests of those beneficiaries who are
served under the FFS program.
We propose that a state could submit a written request for an
exemption from the requirements for the Provider Access API as part of
its annual APD for MMIS operations expenditures prior to the date by
which the state would otherwise need to comply with the requirements
(which may be extended by 1 year if the state receives an extension).
For Medicaid exemption requests, the state would be required to include
documentation that it meets the criteria for the exemption based on
enrollment data from the most recent CMS ``Medicaid Managed Care
Enrollment and Program Characteristics'' report. For a CHIP FFS
exemption, the state's request would have to include enrollment data
from Section 5 of the most recently accepted state submission to the
CHIP Annual Report Template System (CARTS). The state would also be
required to include in its request information about an alternative
plan to ensure that enrolled providers will have efficient electronic
access to the same information through other means while the exemption
is in effect. CMS would grant the exemption if the state establishes to
CMS's satisfaction that it meets the criteria for the exemption and has
established such an alternative plan. We note that the same
considerations for beneficiary opt out, as previously explained, would
still be required.
Once an exemption has been approved, we propose that the exemption
would expire if either of the following two scenarios occurs: (1) based
on the 3 previous years of available, finalized Medicaid Transformed
Medicaid Statistical Information System (T-MSIS) and/or CHIP CARTS
managed care and FFS enrollment data, the State's managed care
enrollment for 2 of the previous 3 years is below 90 percent; or (2)
CMS has approved a State plan amendment,

[[Page 76263]]

waiver, or waiver amendment that would significantly reduce the share
of beneficiaries enrolled in managed care and the anticipated shift in
enrollment is confirmed by available, finalized Medicaid T-MSIS and/or
CHIP CARTS managed care and FFS enrollment data.
For the first scenario, CMS recognizes that there may be
circumstances where a state's managed care enrollment may fluctuate
slightly below the 90 percent threshold in 1 year, and yet return to
above 90 percent the next year. To help reduce the possible burden on
exempted states experiencing this type of temporary fluctuation in
managed care enrollment, CMS would consider data from the 3 previous
years of available, finalized Medicaid T-MSIS and/or CHIP CARTS managed
care and FFS enrollment data. We propose that if the state's managed
care enrollment for 2 of the previous 3 years is below 90 percent, the
state's exemption would expire.
We propose that a state would be required to provide written
notification to CMS that the state no longer qualifies for the Provider
Access API exemption when data confirm that there has been a shift from
managed care enrollment to FFS enrollment resulting in the State's
managed care enrollment falling below the 90 percent threshold for 2 of
the previous 3 years. We propose that the written notification be
submitted to CMS within 90 days of the finalization of the annual
Medicaid T-MSIS managed care enrollment data and/or the CARTS report
for CHIP confirming that there has been the requisite shift from
managed care enrollment to FFS enrollment in 2 of the 3 previous years.
For the second scenario, we recognize that there may be state plan
amendments, waivers, or waiver amendments that would result in a shift
from managed care enrollment to FFS enrollment. Additionally, there may
be instances where anticipated enrollment shifts may not be fully
realized due to other circumstances. We propose that a state would be
required to provide written notification to CMS that the state no
longer qualifies for the Provider Access API when data confirm that
there has been a shift from managed care enrollment to FFS enrollment
as anticipated in the state plan amendment or waiver approval. We
propose that the written notification be submitted to CMS within 90
days of the finalization of the first annual Medicaid T-MSIS managed
care enrollment data and/or the CARTS report for CHIP confirming that
there has been the requisite shift from managed care enrollment to FFS
enrollment.
Regardless of why the exemption expires, if it expires, the state
would be required to obtain CMS's approval of a timeline for compliance
with the Provider Access API requirements for the state's Medicaid FFS
and/or CHIP FFS population(s) within two years of the expiration of the
exemption.
For Medicaid and CHIP managed care, we are not proposing an
extension process because we believe that managed care plans are
actively working to develop the necessary IT infrastructure to be able
to comply with the existing requirements at 42 CFR parts 438 and 457
and because many of them might benefit from efficiencies resulting from
the variety of plan types that they offer. Many managed care plans are
part of parent organizations that maintain multiple lines of business,
including Medicaid managed care plans and plans sold on the Exchanges.
As discussed in the CMS Interoperability and Patient Access final rule
(85 FR 25607, 25612, and 25620), work done by these organizations can
benefit all lines of business and, as such, we do not believe that the
proposals in this rule impose undue burden or cannot be achieved by the
compliance date. We are soliciting comments on our assumptions
regarding the scope of resources and ability of managed care parent
organizations to achieve economies of scale when implementing the
proposed API.
Further, we seek comment on whether an extension process would be
warranted for certain managed care plans to provide additional time for
the plan to comply with the proposed requirement at 42 CFR 431.61(a)
(which cross references at 42 CFR 438.242(b)(7)) for Medicaid managed
care plans) and at proposed 42 CFR 457.731(a) (which cross references
at 42 CFR 457.1223(d)) for CHIP managed care entities. While we are not
proposing such a process for managed care plans and entities and do not
believe one is necessary, we are open to evaluating options for
possible future rulemaking. Were we to adopt an extension process for
these managed care plans and entities, what criteria should a managed
care plan or entity meet to qualify for an extension? Should the
criteria include enrollment size, plan type, or certain unique
characteristics that could hinder their achievement of the proposed
requirements by the proposed compliance date? We also seek comment on
whether, were we to propose such a process for Medicaid managed care
plans or CHIP managed care entities, the entity responsible for
evaluating the criteria and exception evaluation process should be the
state and whether states could implement the exception evaluation
process with available resources. Consistent with the exception process
proposed for QHP issuers on the FFEs at 45 CFR 156.222(c), we would
expect managed care plans seeking extensions to provide, at a minimum,
a narrative justification describing the reasons why a plan or entity
cannot reasonably satisfy the requirements by the proposed compliance
date, an explanation of the impact of non-compliance upon enrollees, an
explanation of the current or proposed means of providing electronic
health information to providers, and a comprehensive plan with a
timeline to achieve compliance.
We request comment on the proposed extension and exemption
processes.
b. Exception for QHP Issuers
For QHP issuers on the FFEs, we propose an exception to the
Provider Access API proposal at the regulation citations identified in
Table 2. We propose that if an issuer applying for QHP certification to
be offered through an FFE believes it cannot satisfy the proposed
requirements at 45 CFR 156.222(a) for the Provider Access API, the
issuer would have to include as part of its QHP application a narrative
justification describing the reasons why the issuer could not
reasonably satisfy the requirements for the applicable plan year, the
impact of non-compliance upon providers and enrollees, the current or
proposed means of providing health information to providers, and
solutions and a timeline to achieve compliance with the requirements of
this section. We propose that the FFE may grant an exception to the
requirements at 45 CFR 156.222(a) for the Provider Access API if it
determines that making qualified health plans of such issuer available
through such FFE is in the interests of qualified individuals in the
state or states in which the FFE operates, and an exception would be
warranted to permit the issuer to offer qualified health plans through
the FFE. This proposal would be consistent with the exception for QHP
issuers on the FFEs we finalized for the Patient Access API in the CMS
Interoperability and Patient Access final rule (85 FR 25552). For
instance, as noted in that final rule, that exception could apply to
small issuers, financially vulnerable issuers, or new entrants to the
FFEs that demonstrate that deploying FHIR API technology consistent
with the required interoperability standards would pose a significant
barrier to the issuer's ability to provide coverage to patients, and
not certifying the issuer's QHP or QHPs

[[Page 76264]]

would result in patients having few or no plan options in certain
areas. We believe that having a QHP issuer offer QHPs through an FFE
generally is in the best interest of patients and would not want
patients to have to go without access to QHP coverage because the
issuer is unable to implement this API.
In summary, we propose to permit certain impacted payers (state
Medicaid and CHIP FFS programs and QHP issuers on the FFEs) to apply
for an extension, exemption, or exception, as applicable, from
implementing the proposed Provider Access API. We propose that these
programs would submit and be granted approval for an extension or
exemption as a part of applicable established processes. We propose
that submission requirements would include certain documentation
identified in the regulatory citations in Table 2.
5. Provider Access API in Medicaid and CHIP
a. Federal Funding for State Medicaid and CHIP Expenditures on
Implementation of the Provider Access API
Should our proposals be finalized as proposed, states operating
Medicaid and CHIP programs might be able to access Federal matching
funds to support their implementation of the Provider Access API. This
proposed API is expected to lead to more efficient administration of
the Medicaid and CHIP state plans, consistent with sections 1902(a)(4)
and 2101(a) of the Act.
We would not consider state expenditures for implementing this
proposal to be attributable to any covered Medicaid item or service
within the definition of ``medical assistance.'' Thus, in Medicaid, CMS
would not match these expenditures at the state's regular Federal
medical assistance percentage (FMAP). However, were this proposal to be
finalized as proposed, Federal financial participation (FFP) under
section 1903(a)(7) of the Act, at a rate of 50 percent, for the proper
and efficient administration of the Medicaid state plan, might be
available for state expenditures related to implementing this proposal
for their Medicaid programs. We believe that using the Provider Access
API would help the state more efficiently administer its Medicaid
program, by ensuring that providers could access data that could
improve their ability to render Medicaid services effectively,
efficiently, appropriately, and in the best interest of the patient.
States' expenditures to implement these proposed requirements could
also be eligible for 90 percent enhanced FFP under section
1903(a)(3)(A)(i) of the Act, if the expenditures can be attributed to
the design, development, or installation of mechanized claims
processing and information retrieval systems. Additionally, 75 percent
enhanced FFP under section 1903(a)(3)(B) of the Act might be available
for state expenditures to operate Medicaid mechanized claims processing
and information retrieval systems to comply with this proposed
requirement.
States can request Medicaid enhanced FFP under section
1903(a)(3)(A)(i) or (B) of the Act through the APD process described at
45 CFR part 95, subpart F. States are reminded that 42 CFR
433.112(b)(12) and 433.116(c) in part require that any system for which
they are receiving enhanced FFP under section 1903(a)(3)(A)(i) or (B)
of the Act align with and incorporate the ONC's Health Information
Technology standards adopted at 45 CFR part 170, subpart B. The
Provider Access API would complement this requirement because the API
would further interoperability by using standards adopted by ONC at 45
CFR 170.215.\56\ States are also reminded that 42 CFR 433.112(b)(10)
and 433.116(c) explicitly support exposed APIs, meaning the API's
functions are visible to others to enable the creation of a software
program or application, as a condition of receiving enhanced FFP under
section 1903(a)(3)(A)(i) or (B) of the Act.
---------------------------------------------------------------------------

\56\ Centers for Medicare & 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.
---------------------------------------------------------------------------

Similarly, 42 CFR 433.112(b)(13) and 433.116(c) require states to
promote sharing, leverage and re-use of Medicaid technologies and
systems as a condition of receiving enhanced FFP under section
1903(a)(3)(A)(i) or (B) of the Act. CMS interprets that requirement to
apply to technical documentation associated with a technology or
system, such as technical documentation for connecting to a state's
APIs. Making the needed technical documentation publicly available so
that systems that need to can connect to the APIs proposed in this rule
would be required as part of the technical requirements at 42 CFR
431.60(d) for all proposed APIs in this rule, including the Provider
Access API.
Separately, for state CHIP agencies, section 2105(c)(2)(A) of the
Act and 42 CFR 457.618, limiting administrative costs to no more than
10 percent of a state's total computable expenditures for a fiscal
year, would apply to administrative claims for developing the APIs
proposed in this rule.
We note that the temporary Medicaid FMAP increase available under
section 6008 of the Families First Coronavirus Response Act (Pub. L.
116-127) does not apply to administrative expenditures.
b. Medicaid Expansion CHIP Program
Most states have Medicaid Expansion CHIP programs, in which a state
receives Federal funding to expand Medicaid eligibility to optional
targeted low-income children that meet the requirements of section 2103
of the Social Security Act. We are proposing at 42 CFR 457.700(c) that
for states with Medicaid expansion CHIP programs, the proposals in this
rule for Medicaid would apply to those programs rather than our
proposals for separate CHIP programs. Functionally, our proposals are
the same; however, for clarity, we are making explicit that the
Medicaid requirements at Sec. Sec. 431.60, 431.61, and 431.80 would
apply to those programs rather than the separate CHIP requirements at
Sec. Sec. 457.730, 457.731, and 457.732.
BILLING CODE 4120-01-P

[[Page 76265]]

[GRAPHIC] [TIFF OMITTED] TP13DE22.001

BILLING CODE 4120-01-C

6. Statutory Authorities for Provider Access API Proposals
a. MA Organizations
For MA organizations, we are proposing these Provider Access API
requirements under our authority at sections 1856(b)(1) of the Act to
promulgate regulations that adopt standards to implement provisions in
Part C of Title XVIII of the Act (such as

[[Page 76266]]

section 1852(d)(1)(A)) of the Act to adopt new terms and conditions for
MA organizations that the Secretary finds ``necessary and
appropriate.'' Section 1852(d)(1)(A) of the Act requires MA
organizations to, as a condition of using a network of providers, make
covered benefits available and accessible to enrollees in a manner that
assures continuity in the provision of benefits. As noted in this
section of this proposed rule, these regulations implement this
requirement. The Secretary also has authority under section 1857(e)(1)
of the Act to add new contract terms, including additional standards
and requirements, for MA organizations the Secretary finds necessary
and appropriate and that are not inconsistent with Part C of the
Medicare statute.
In implementing section 1852(d)(1)(A) of the Act, we previously
adopted a regulation, at 42 CFR 422.112(b), that requires MA
organizations to ensure the continuity of care and integration of
services through arrangements with providers that include procedures to
ensure that the MA organization and the contracted providers have
access to the information necessary for effective and continuous
patient care. This proposal aligns with, and provides a means for, MA
organizations to comply with that existing regulatory requirement. Our
proposal for MA organizations to implement and maintain a Provider
Access API would facilitate exchanges of information about enrollees
that are necessary for effective and continuous patient care, which is
consistent with the requirement at section 1852(d)(1)(A) of the Act for
continuing the provision of benefits. The Provider Access API proposal,
which would support sharing claims, all data classes and data elements
included in a content standard adopted at 45 CFR 170.213, as well as
prior authorization decisions (sections II.B.2. and II.B.3. of this
proposed rule) and a requirement for MA organizations to offer provider
educational resources (section II.B.3.d. of this proposed rule), would
give providers tools to support continuity of care and care
coordination for enrollees. Were a provider able, through a Provider
Access API established by an MA organization, to gather information for
their patient, the provider could make more informed decisions and
coordinate care more effectively. In addition, if a patient moves from
one provider to another, the new provider would be able to ensure
continuity of care if they are able to access relevant health
information for the patient from the MA organization in an efficient
and timely way. A Provider Access API could support this; thus, the
proposal would carry out and be consistent with the Part C statute.
This proposal would complement and align with MA organization
obligations at 42 CFR 422.112(b)(4) by providing a means, through a
Provider Access API, for the exchange of information that could support
effective and continuous patient care. This API would help MA
organizations share information with providers in an effective and
efficient way that would help them fulfill program requirements. A
Provider Access API could increase the efficiency and simplicity of
administration. It could give providers access to a significant amount
of their patients' information with limited effort, and it could reduce
the amount of time needed during provider visits to establish a
patient's prior history, which could introduce efficiencies and improve
care. These proposals would also be expected to allow for better access
to other providers' prior authorization decisions, which could give a
provider a more holistic view of a patient's care and reduce the
likelihood of ordering duplicate or misaligned services. Ultimately, we
anticipate that sharing patient information would ensure that providers
receive patient information in a timely manner and could lead to more
appropriate service utilization and higher patient satisfaction. In
addition, the proposal that MA organizations make available educational
resources and information would increase access to and understanding of
this Provider Access API, leading to more efficient use and integration
of the API as a means for providers to access patient information.
Thus, the proposed Provider Access API would be necessary and
appropriate for the MA program and consistent with existing
requirements.
b. Medicaid and CHIP
Our proposed requirements in this section for Medicaid managed care
plans and Medicaid FFS programs fall generally under the authority in
the following provisions of the statute:
Section 1902(a)(4) of the Act, which requires that a state
Medicaid plan provide such methods of administration as are found by
the Secretary to be necessary for the proper and efficient operation of
the state Medicaid plan;
Section 1902(a)(8) of the Act, which requires states to
ensure that Medicaid services are furnished with reasonable promptness
to all eligible individuals; and
Section 1902(a)(19) of the Act, which requires states to
ensure that care and services are provided in a manner consistent with
simplicity of administration and the best interests of the recipients.
These proposals are authorized under these provisions of the Act
because they would help ensure that Medicaid providers can access data
that could improve their ability to render Medicaid services
effectively, efficiently, and appropriately. The proposals would be
expected to help states fulfill their obligations to operate their
state plans efficiently and to ensure that Medicaid services are
furnished with reasonable promptness and in a manner consistent with
the best interest of the recipients.
In addition, section 1902(a)(7) of the Act requires that states
must provide safeguards that restrict the use or disclosure of
information concerning Medicaid applicants and beneficiaries to uses or
disclosures of information that are directly connected with the
administration of the Medicaid state plan. The implementing regulations
for this section of the Act list purposes that CMS has determined are
directly connected to Medicaid state plan administration at 42 CFR
431.302 and provide safeguards states must apply to uses and
disclosures of beneficiary data at 42 CFR 431.306. CHIP programs are
subject to the same requirements through a cross reference at 42 CFR
457.1110(b). Our proposal to require that the data described in this
section be shared via the Provider Access API would be consistent with
the requirement that states may share these data only for purposes
directly connected to the administration of the Medicaid state plan,
since this data sharing would be related to providing services for
beneficiaries, a purpose listed in Sec. 431.302(c). As mentioned
previously, a provider could better manage a patient's total care when
they have access to more of that patient's data because the data would
provide a more in-depth medical history, enable more informed decision
making, and potentially prevent the provision or ordering of
duplicative services. More details about how the proposals could be
implemented in a manner consistent with state Medicaid and CHIP
agencies' requirements under 42 CFR part 431, subpart F, are discussed
in section II.B.2.
Proposing to require states to implement a Provider Access API to
share data with enrolled Medicaid providers about certain claims,
encounter, and clinical data, including data about prior authorization
decisions, for a specific individual beneficiary, could improve states'
ability to ensure that care and services are provided in a manner
consistent with simplicity of

[[Page 76267]]

administration, and to cover services more efficiently. This API would
enable Medicaid providers to access beneficiary utilization and
authorization information from the state or managed care plan(s) prior
to an appointment or at the time of care, and that, in turn, would
enable the provider to spend more time on direct care. The proposal
would support efficient and prompt delivery of care as well, which
would be in beneficiaries' best interests. These proposals would also
be expected to give providers better access to prior authorization
decisions for care provided by other enrolled Medicaid providers, which
would give a provider a more holistic view of a patient's care and
reduce the likelihood of ordering duplicate or misaligned services.
This could also facilitate easier and more informed decision-making by
the provider and would therefore support efficient coverage decisions
in the best interest of patients. The proposed Provider Access API, if
finalized as proposed, would be expected to make available a more
complete picture of the patient to the provider at the point of care,
which could improve the quality and efficiency of a patient visit, thus
enabling the provider to treat more patients. These outcome and process
efficiencies could help states fulfill their obligations to ensure
prompt access to services in a manner consistent with the best interest
of beneficiaries, consistent with sections 1902(a)(8) and (19) of the
Act, and the efficiencies created for providers might help the state
administer its Medicaid program more efficiently, consistent with
section 1902(a)(4) of the Act. These analyses apply similarly to
managed care and FFS programs and delivery systems, so we are
exercising our authority to adopt virtually identical regulatory
requirements for a Provider Access API for both Medicaid FFS programs
and Medicaid managed care plans.
For CHIP, we are proposing these requirements under the authority
in section 2101(a) of the Act, which states that the purpose of Title
XXI of the Act is to provide funds to states to provide child health
assistance to uninsured, low-income children in an effective and
efficient manner that is coordinated with other sources of health
benefits coverage. We believe this proposed policy could strengthen
states' abilities to fulfill these statutory obligations under Title
XXI of the Act in a way that would recognize and accommodate the use of
electronic information exchange in the healthcare industry today and
would facilitate a significant improvement in the delivery of quality
healthcare to CHIP beneficiaries.
When providers have access to patient utilization and authorization
information from payers or other health IT systems, they can provide
higher quality care. Improving the quality of care aligns with section
2101(a) of the Act, which requires states to provide CHIP services in
an effective and efficient manner. The more information a provider has
to make informed decisions about a patient's care, the more likely it
is that patients will receive care that best meets their needs.
Additionally, providers could be more effective and efficient in their
delivery of CHIP services by having direct access to patient
utilization and authorization information. If a provider has
information about a patient prior to or at the point of care, the
provider will be able to spend more time focused on the patient, rather
than on their need to collect information. In addition, the information
providers do collect would not be based solely on patient recall. This
could save time, improve the quality of care, and increase the total
amount of direct care provided to CHIP beneficiaries. When data are
standardized, and able to be incorporated directly into the provider's
EHR or practice management system, they can be leveraged as needed at
the point of care by the provider and also can be used to support
coordination across providers and payers. This is inherently more
efficient, and ultimately, more cost-effective, as the information does
not have to be regularly repackaged and reformatted to be shared or
used in a valuable way. As such, the Provider Access API proposals also
align with section 2101(a) of the Act in that these proposals could
improve coordination between CHIP and other health coverage. For these
reasons, we believe this proposal is in the best interest of the
beneficiaries and within our long-established statutory authorities.
Finally, the safeguards for applicant and beneficiary information
at subpart F of 42 CFR part 431 are also applicable to CHIP through a
cross-reference at 42 CFR 457.1110(b). As discussed above for Medicaid,
giving CHIP providers access to attributed beneficiary data through the
Provider Access API is related to providing services to beneficiaries,
which is described at 42 CFR 431.302(c) as a purpose directly related
to state plan administration. We remind states that when they share
beneficiary information through the Provider Access API, they must
comply with the privacy protections at 42 CFR 457.1110 and the release
of information provisions at 42 CFR 431.306.
c. QHP Issuers on the FFEs
For QHP issuers on the FFEs, we are proposing these new
requirements under our authority in section 1311(e)(1)(B) of the
Affordable Care Act, which affords the Exchanges the discretion to
certify QHPs if the Exchange determines that making available such
health plans through the Exchange is in the interests of qualified
individuals in the state in which the Exchange operates. We believe the
benefits would outweigh any additional burdens this might impose on
issuers. By using the proposed technologies, patients could experience
improved health, payers could see reduced costs of care, and providers
could see better compliance with care regimens. We also do not believe
that premiums would significantly increase because some of the
infrastructure necessary to implement the proposed technology has been
completed to comply with the May 2020 Interoperability Rule.
Furthermore, QHP issuers on the FFEs might combine investments and
staff resources from other programs for implementation efforts,
avoiding the need to increase premiums.
We believe that certifying only health plans that make enrollees'
health information available to their providers via the Provider Access
API is in the interests of enrollees. Giving providers access to their
patients' information supplied by QHP issuers on the FFEs would ensure
that providers are better positioned to provide enrollees with seamless
and coordinated care and help ensure that QHP enrollees on the FFEs are
not subject to duplicate testing and procedures, and delays in care and
diagnosis. Access to the patient's more complete medical information
could also maximize the efficiency of an enrollee's office visits. We
encourage SBEs, including SBE-FPs, to consider whether a similar
requirement should be applicable to QHP issuers participating in their
Exchanges.

C. Payer to Payer Data Exchange on FHIR

1. Background
Research shows that the more complete a patient's record is and the
more data that can be available to healthcare providers at the point of
care, the better patient outcomes can be.\57\

[[Page 76268]]

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

\57\ 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 CMS Interoperability and Patient Access final rule (85 FR
25565), we highlighted numerous benefits for payers to maintain a
longitudinal record (that is, long-term) of their current patients'
health information. If payers are at the center of the exchange, they
can make information available to patients and their providers and can
help ensure that a patient's information follows them as they move from
provider to provider and payer to payer. In the final rule we finalized
a requirement that certain impacted payers would be required to
exchange, at a minimum, all data classes and data elements included in
a content standard adopted at 45 CFR 170.213 (85 FR 25568) at a
patient's request. This policy applied to MA organizations, Medicaid
managed care plans, CHIP managed care entities, and QHP issuers on the
FFEs. It did not include Medicaid or CHIP FFS programs. We did not
specify an API standard for payer to payer data exchange in that final
rule, because, at the time, there were a variety of transmission
solutions that payers could employ to meet this requirement. We
encouraged impacted payers to consider using a FHIR API consistent with
the larger goal of leveraging FHIR APIs to support a number of
interoperability use cases for improving patient, provider, and payer
access to healthcare data to reduce burden, increase efficiency, and
ultimately facilitate better patient care. In addition, we signaled our
intent to consider a future requirement to use FHIR APIs for payer to
payer data exchange, envisioning the increasing implementation of FHIR
APIs for different purposes within the industry.
Since the CMS Interoperability and Patient Access final rule was
finalized in May 2020, multiple impacted payers have expressed to CMS
that the lack of technical specifications for the payer to payer data
exchange requirement in the final rule (85 FR 25565) is creating
challenges for implementation. This lack of a standard may lead to
differences in implementation across the industry, poor data quality,
operational challenges, and increased administrative burden.
Differences in implementation approaches may create gaps in patient
health information that conflict with the intended goal of
interoperable payer to payer data exchange.
In the December 2020 CMS Interoperability proposed rule, we
attempted to address these challenges by proposing the use of a FHIR
API for the payer to payer data exchange. We also proposed to extend
the Payer-to-Payer API policies to Medicaid and CHIP FFS programs. As
stated in section I.A. of this proposed rule, we are withdrawing the
December 2020 CMS Interoperability proposed rule and issuing this new
proposed rule that incorporates the feedback we received from
stakeholders, including this proposal to address the payer to payer
data exchange. We refer readers to the discussion in section I.A.
outlining the overarching differences between the two proposed rules.
Moreover, in order to respond to stakeholder concerns about
implementing the payer to payer data exchange requirement finalized in
the CMS Interoperability and Patient Access final rule, and noting that
we did not finalize the proposals outlined in the December 2020 CMS
Interoperability proposed rule, we published a Federal Register
notification (86 FR 70412) \58\ announcing that we would exercise
enforcement discretion and not enforce the payer to payer data exchange
requirements until future rulemaking was finalized. We intend this
rulemaking to address those concerns about the payer to payer data
exchange policy finalized in the CMS Interoperability and Patient
Access final rule and subject to the enforcement discretion.
---------------------------------------------------------------------------

\58\ Medicare and Medicaid Programs; Patient Protection and
Affordable Care Act; Interoperability and Patient Access for
Medicare Advantage Organizations 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, 86 FR 70412
(December 10, 2021).
---------------------------------------------------------------------------

In this proposed rule, we are again proposing to require impacted
payers (MA organizations, state Medicaid FFS programs, state CHIP FFS
programs, Medicaid managed care plans, CHIP managed care entities, and
QHP issuers on the FFEs) to implement and maintain a payer to payer
data exchange using a FHIR API, but with changes from our proposals in
the December 2020 CMS Interoperability proposed rule. We are again
proposing that the data exchange take place via a FHIR API at the start
of coverage, but we are now taking a different approach to the
standards required for the API, as further described in section II.F.
of this proposed rule. We are again proposing to establish a patient
opt in policy for this data exchange for all impacted payers, for the
reasons explained below. Furthermore, we propose to extend the
compliance deadline for the Payer-to-Payer API to January 1, 2026.
We note that our payer to payer data exchange proposals discussed
below involve transactions and cooperation between payers, which in
many cases may include payers that would not be impacted by our
proposals. We emphasize that under our proposals, each impacted payer
would be responsible only for its own side of the transaction. For
instance, if our proposal would require an impacted payer to request
patient data from another payer, it would have to do so regardless of
whether the other payer is an impacted payer (a status that may or may
not be evident to the requesting payer). Similarly, if an impacted
payer receives a request for patient data that meets all the proposed
requirements, the impacted payer would be required to share those data,
regardless of whether the requesting payer is an impacted payer (which,
again, may or may not be evident). In this way, non-impacted payers who
implement the Payer-to-Payer API and their patients would benefit from
the data exchange proposed in this proposed rule.
In this section, we talk about data exchange between payers. When
we refer to a patient's new payer, we are referring to the payer that a
patient is newly enrolled with and the party responsible for requesting
and receiving the patient's data. When we refer to the patient's
concurrent payers, we are referring to the parties (two or more) that
are providing coverage at the same time and responsible for exchanging
data with each other as discussed

[[Page 76269]]

further below. When we refer to the patient's previous payer, we are
referring to the payer that a patient has previously had coverage with
and thus the payer responsible for sending the data to the new payer.
However, as discussed further in section II.C.4.b., Medicaid and CHIP
FFS state agencies as well as Medicaid and CHIP managed care plans
within the same state are excluded from the definition of ``previous
payer'' in relation to data exchange with each other.
We are exploring steps for Medicare FFS to participate in Payer-to-
Payer API data exchange with all interested payers and we would
encourage other payers that would not be impacted by these proposals,
if finalized, to do the same. If our proposals are finalized, we intend
to implement the Payer-to-Payer API capability for Medicare FFS in
conformance with the requirements for impacted payers, as feasible. We
seek comment on whether this could be implemented as proposed for the
Medicare FFS program, how we could apply each of these proposals below
and if there would be any differences for implementing the Payer-to-
Payer API in the Medicare FFS program as a Federal payer. We strongly
encourage all payers that would not be subject to the proposed
requirements to consider the value of implementing a Payer-to-Payer API
as described in this proposal, so that all patients, providers, and
payers in the U.S. healthcare system may ultimately experience the
benefits of such data exchange.
2. Proposal To Rescind the CMS Interoperability and Patient Access
Final Rule Payer to Payer Data Exchange Policy
CMS strongly believes that data exchange among payers is a powerful
way to help patients accumulate their data over time and to improve
information sharing that would allow patients and providers to have
more complete access to health information, which can help to promote
better patient care. However, given the concerns raised by stakeholders
regarding the lack of technical specification in our final policy, we
are now proposing to rescind the payer to payer data exchange policy
previously finalized in the CMS Interoperability and Patient Access
rule (85 FR 25568) at 42 CFR 422.119(f)(1) and 438.62(b)(1)(vi) and
(vii) and 45 CFR 156.221(f)(1). We are doing so to prevent industry
from developing multiple systems, and to help payers avoid the costs of
developing non-standardized, non-API systems, and the challenges
associated with those systems. In the following sections, we are
proposing a new policy that would, instead, require impacted payers to
implement and maintain a Payer-to-Payer API using the FHIR standard, as
described later in this section. We anticipate that the proposed use of
FHIR APIs would ensure greater uniformity in implementation and
ultimately lead to payers having more complete information available to
share with patients and providers.
3. Payer to Payer Data Exchange on FHIR
a. Payer-to-Payer API Technical Standards
In the CMS Interoperability and Patient Access final rule we
finalized a requirement to implement, maintain, and use API technology
conformant with 45 CFR 170.215 for the Patient Access API. However we
did not require the use of an API or related standards for payer to
payer data exchange.
We are now building on the technical standards, base content and
vocabulary standards used for the Patient Access API, as finalized in
the CMS Interoperability and Patient Access final rule (85 FR 25558),
for this proposed Payer-to-Payer API. The degree of overlap between the
requirements for the Patient Access API (discussed in section II.A.2.
of this proposed rule) and the Provider Access API (discussed in
section II.B.2. of this proposed rule) should ease the API development
and implementation process for payers.
The Patient Access API would provide the foundation necessary to
share all data classes and data elements included in a standard adopted
at 45 CFR 170.213, adjudicated claims, and encounter data as well as
the patient's prior authorization requests and decisions. Because the
same data classes and elements included in the standards in 45 CFR
170.213 and adjudicated claims, and encounter data are already required
for the Patient Access API, payers have already formatted these data
elements and prepared their systems to share these standardized data
via a FHIR API. As a result, we believe payers have already devoted the
development resources to stand up a FHIR API infrastructure when they
implemented the Patient Access API, which could be adapted for expanded
interoperability use cases.
We are also proposing to require the use of certain IGs adopted
under 45 CFR 170.215 that are applicable to the Payer-to-Payer API.
This includes OpenID Connect Core at 45 CFR 170.215(b) for
authorization and authentication. We are proposing that the Payer-to-
Payer API must include the authorization and authentication protocols
at 45 CFR 170.215(b) to authenticate the identity of the payer
requesting access to data through the API. This would create a
standardized and trusted method for payers to determine whether the
payer who is requesting the data is whom they say they are. We refer
readers to section II.F. of this proposed rule for further discussion
of the required and recommended standards for the Payer-to-Payer API.
We note that when exchanging data with another payer through the
Payer-to-Payer API, payers may find it more efficient to share data for
multiple patients at a time. It is likely that impacted payers with a
fixed enrollment period would have many patients' data to share at one
time, especially if other payers share that enrollment period (such as
QHPs offered on an FFE). In such a situation, it could require
significant resources and time for payers to send each patient's data
individually through an API. The FHIR Bulk Data Access (Flat FHIR) IG
for exchanging multiple patients' data at the same time has been
adopted by ONC at 45 CFR 170.215(a)(4), which is discussed further in
section II.F. of this proposed rule and is a proposed required standard
for the Payer-to-Payer API.
In summary, we propose that, beginning January 1, 2026 (for
Medicaid managed care plans and CHIP managed care entities, by the
rating period beginning on or after January 1, 2026, and for QHP
issuers on the FFEs, for plan years beginning on or after January 1,
2026), impacted payers must implement and maintain a Payer-to-Payer API
that is compliant with the same technical standards, documentation
requirements, and denial or discontinuation policies as our Patient
Access API requirements. In addition, we propose that the API must be
conformant with the standards at 45 CFR 170.215, including support for
FHIR Bulk Data Access and OpenID Connect Core as further discussed in
section II.F.
We are proposing these technical specification requirements for the
Payer-to-Payer API for MA organizations, state Medicaid and CHIP FFS
programs, Medicaid managed care plans, CHIP managed care entities, and
QHP issuers on the FFEs at the CFR sections identified in Table 3.
We request comments on these proposals.
b. Payer-to-Payer API Data Content Requirements
We are proposing to require that impacted payers implement and
maintain a FHIR Payer-to-Payer API to

[[Page 76270]]

exchange all data classes and data elements included in a content
standard adopted at 45 CFR 170.213, claims and encounter data
(excluding provider remittances and enrollee cost-sharing information),
and prior authorization requests and decisions that the payer maintains
with a date of service on or after January 1, 2016.
The data we are proposing to include in the API would be consistent
with the proposals discussed in sections II.A. (Patient Access API) and
II.B. (Provider Access API) of this proposed rule, which would require
impacted payers to share the same types of data with patients and
providers via those respective FHIR APIs. We also note that much of the
data included in this proposal, except for provider remittances,
enrollee cost-sharing information and prior authorizations, as
discussed below, would also be consistent with the requirements for the
Patient Access API finalized in the CMS Interoperability and Patient
Access final rule (85 FR 25559). That final rule requires that impacted
payers make data available from a date of service of January 1, 2016.
Therefore, payers should already be maintaining and making available
patient data back to that date. Using the same data content standards
across the APIs in this proposed rule would add efficiencies for payers
and maximize the value of the work being done to implement APIs,
reducing the overall burden for all impacted payers.
We are proposing to exclude provider remittances and enrollee cost-
sharing information from Payer-to-Payer API data exchange because that
information is often considered proprietary by payers. Therefore, we
are not proposing to require payers to exchange those data with each
other. While there could be value to patients in having provider
remittances and enrollee cost-sharing information available via the
Patient Access API, we believe that sharing provider remittances and
enrollee cost-sharing information between payers would have only a
limited beneficial impact on care. We believe that sharing claims and
encounter information without the cost details would complement the
data classes and data elements included in a content standard adopted
at 45 CFR 170.213, by providing more information about the patient's
care history to support care coordination and efficient operation.
When we refer to prior authorizations in the context of payer to
payer data exchange, we propose that this would include any pending,
active, denied, and expired prior authorization requests or decisions.
We refer readers to section II.A. of this proposed rule where prior
authorization data content for the APIs in this proposed rule is
discussed in further detail. Our proposals in this section for the
inclusion of prior authorization data mirror our proposals for prior
authorization data in the Patient Access API and Provider Access API.
We believe that it would be valuable for payers to make information
about prior authorization requests and decisions available via the
Payer-to-Payer API, particularly when a patient enrolls with a new
payer. Prior authorization is a significant focus of this proposed
rule, and information about these requests and decisions could be
beneficial to patients, providers, and payers. As noted throughout,
this proposed rule does not apply to any prior authorization processes
or standards related to any drugs.
Currently, when a patient changes payers, information about prior
authorization decisions the previous payer made or was in the process
of making, about the patient's ongoing care is inconsistently sent to
the new payer. While some payers will make this information available
to the new payer upon request, most new payers do not request such
information. Instead, most payers with a newly enrolled patient require
the treating provider to request a new prior authorization, even for
items or services for which a patient had a valid and current prior
authorization approval under the previous payer. When this happens, the
burden of repeating the prior authorization process with the new payer
falls on the provider and patient, which can impede the continuity of
care or delay patient care, impacting patient outcomes and complicating
care coordination. In addition, it adds burden for payers, who must
expend time and effort to review a potentially unnecessary and
duplicative prior authorization request.
We discuss prior authorization and our proposals regarding prior
authorization processes in more depth in section II.D. of this proposed
rule. As part of this Payer-to-Payer API proposal, consistent with the
proposals for the Patient Access API in section II.A. and the Provider
Access API in section II.B. of this proposed rule, we propose to add
prior authorization requests and decisions and related administrative
and clinical documentation to the set of data that impacted payers must
make available via the Payer-to-Payer API. We propose that this
documentation would include the status of the prior authorization, the
date the prior authorization was approved or denied, the date or
circumstance under which the authorization ends, the items and services
approved, and the quantity used to date. Furthermore, as outlined in
section II.D., we propose that the specific reason why the request was
denied should also be included in the case of a prior authorization
denial.
We propose that impacted payers would be required to make
information about prior authorizations available via the Payer-to-Payer
API for the duration that the authorization is active and, for at least
1 year after the prior authorization's last status change. We note that
we are formulating our proposal for at least 1 year after any status
change, but this provision would be particularly relevant to denied and
expired prior authorizations, to ensure that they would be available
for at least a year after expiring or being denied.
While CMS is not proposing at this time to require payers to
review, consider, or honor the active prior authorization decision of a
patient's former payer, CMS believes payers may gain efficiencies by
doing so. In this section, we seek comment on some of the
considerations around sharing prior authorization data between payers.
Under our payer to payer data exchange proposal, prior authorization
information would be included as part of the patient's longitudinal
record received from the previous payer. The prior authorization
information would thus be available for consideration as part of the
patient's historical record. Should a payer consult this information,
even to make a prior authorization decision under its own rules, it
could, over time, reduce payer, provider, and patient burden, and
possibly healthcare costs.
We understand that there is potential for a gap in prior
authorization for ongoing services when changing payers, which can be
challenging for patients. If a new payer consults the previous payer's
prior authorization information, it could mean that the provider might
not need to send a new, duplicative request to the new payer and that
the new payer might not need to process that new request. Patients
might not have to wait for a new prior authorization for an item or
service that a provider and previous payer had already determined the
patient needs. This could be particularly helpful for patients with
chronic conditions and individuals with disabilities, social risk
factors, and limited English proficiency who are changing payers. If a
new payer reviews and considers the prior authorization decisions of a
patient's previous payer, based on information the previous payer
already had from the patient's providers, that might reduce

[[Page 76271]]

delays in care and improve continuity of care. Therefore, we believe
that sharing this information between payers could have a significant
and positive impact on payers, providers, and patients. We are also
interested in comments about whether the continuation of a prior
authorization or additional data exchange could be particularly
beneficial to patients with specific medical conditions.
We understand that payers may use different criteria to make prior
authorization decisions. The new payer may not have insight into the
criteria used by the previous payer, which could understandably make it
challenging for the new payer to accept the previous payer's decision.
With that in mind, we request comments for possible future rulemaking
on whether prior authorizations from a previous payer should be honored
by the new payer, and if so, should the prior authorizations be limited
to a certain period of time based on the type of prior authorization or
patient's medical condition? If so, what should that timeframe be?
Should prior authorization from a previous payer be honored in certain
instances regarding specific medical conditions? If so, which
conditions and for what timeframe?
In summary, we propose that, beginning January 1, 2026 (for
Medicaid managed care plans and CHIP managed care entities, by the
rating period beginning on or after January 1, 2026, and for QHP
issuers on the FFEs for plan years beginning on or after January 1,
2026), impacted payers must implement and maintain a FHIR Payer-to-
Payer API to make available all data classes and data elements included
in a content standard adopted at 45 CFR 170.213, claims and encounter
data (excluding provider remittances and enrollee cost-sharing
information), and prior authorization requests and decisions (and
related administrative and clinical documentation) that the payer
maintains with a date of service on or after January 1, 2016.
We propose that this would include the status of the prior
authorization, the date the prior authorization was approved or denied,
the date or circumstance under which the prior authorization ends, the
items and services approved, and the quantity used to date. If this
information includes prior authorization decisions that are denied, we
propose that impacted payers must include specific information about
why the denial was made. We propose that impacted payers would be
required to make information about prior authorizations available via
the Payer-to-Payer API for the duration that the authorization is
active and, for at least 1 year after the prior authorization's last
status change.
We are proposing these Payer-to-Payer API data content requirements
for MA organizations, state Medicaid and CHIP FFS programs, Medicaid
managed care plans, CHIP managed care entities, and QHP issuers on the
FFEs at the CFR sections identified in Table 3.
We request comment on these proposals.
c. Identifying Previous and Concurrent Payers and Opt In
We propose that all impacted payers must develop and maintain
processes to identify a patient's previous and/or concurrent payer(s)
and to allow patients or their personal representatives to opt into
payer to payer data exchange (both with previous and concurrent payers)
prior to the start of coverage. Payers would also need similar
processes for current enrollees who are continuing enrollment with
their same payer to ensure those patients have the ability to opt in
prior to the data being shared through the API.
Concurrent coverage means that an individual has coverage provided
by two or more payers at the same time. This could include, for
example, individuals dually eligible for Medicare and Medicaid who are
enrolled in both an MA plan and a Medicaid managed care plan. Another
example of concurrent coverage is when different services are covered
by different Medicaid managed care plans for the same Medicaid
beneficiary.
We use the term ``start of coverage'' in this section to mean when
coverage begins or when the patient enrolls and benefits become
effective. We note that in some cases a payer may provide coverage
retroactively; that is, a payer that provides coverage starting on a
date prior to enrollment (as happens in Medicaid, for example). In that
case, the payer would be required to have processes to collect
permission for Payer-to-Payer API data exchange and to identify a new
patient's previous and/or concurrent payer(s) prior to the date the
patient's enrollment is processed. In Medicaid, this would be the date
the beneficiary is enrolled in the state's MMIS (or equivalent
process), not the date coverage takes retroactive effect.
We emphasize that obtaining a patient's opt in permission and
identifying the previous and/or concurrent payer(s) cannot delay an
applicant's eligibility determination or start of coverage with any
impacted payer. We note that the proposed requirement to identify a
patient's previous and/or concurrent payer(s) and obtain a patient's
opt in permission will not always be feasible before the start of
coverage, for instance, if a patient does not provide enough
information to identify their previous payer. We emphasize that payers
must begin this process before the start of coverage, but it may take
longer than enrollment. In that case, the impacted payer would be
required to continue to engage with the patient to gather their
permission and identify any previous and/or concurrent payer(s). Only
once the impacted payer has received permission and identified those
other payers would they be required to request patient data, as
outlined below. Using Medicaid as an example, if a state has all of the
information necessary to determine an individual's eligibility before
it has identified the previous payer, the state must determine the
individual's eligibility and enroll the individual in Medicaid
coverage, if determined eligible, while continuing to follow the
proposed Payer-to-Payer API requirements outlined here as expeditiously
as possible post-enrollment.
We propose that payers would be required to gather information
about the patient's previous and/or concurrent payer(s) that would
allow them to identify and request data from those payers. This could
include the payer's name and a patient ID number or similar identifier.
An impacted payer would be required to allow a patient to report
multiple previous and/or concurrent payers if they had (or continue to
have) concurrent coverage. If that is the case, under our proposals,
impacted payers would be required to request the patient's data from
all previous and/or concurrent payers. We are not being prescriptive in
these proposals regarding specific information to be gathered from
patients, as we believe that this requirement can be implemented in
multiple ways. However, we expect that payers would only collect as
much information as necessary to identify the previous and/or
concurrent payer(s) and make a successful request in accordance with
our proposals, if finalized. For instance, we do not believe specific
plan information (as opposed to the payer organization name) or dates
of coverage would be necessary to effectuate our proposals. We believe
that requesting additional information from patients beyond that which
is necessary would impose barriers on patients' ability to take
advantage of our proposed policies

[[Page 76272]]

because they may not have that information readily available.
We request comments on which data elements would be necessary or
extraneous to make that Payer-to-Payer API request.
Patients enrolled in ongoing coverage on the compliance date with
an impacted payer should be given the same opportunity to have their
data shared with their current, ongoing payer by previous and/or
concurrent payers. To do so, impacted payers would have to give
currently-enrolled patients notice and the opportunity to provide their
previous and/or concurrent payer(s) information, as well as to opt in
to the proposed payer to payer data exchange. Therefore, we are
proposing that no later than the compliance date for the Payer-to-Payer
API, impacted payers must establish and maintain a process to gather
permission and identify previous and/or concurrent payer(s) from all
patients who are currently enrolled.
Some payers may want to have a soft launch, rolling implementation
or pilot for their Payer-to-Payer API before the proposed compliance
date. We want to allow that option and therefore are tying our proposal
to require payers to gather permission from currently-enrolled patients
to the proposed compliance date, January 1, 2026 (for Medicaid managed
care plans and CHIP managed care entities, by the rating period
beginning on or after January 1, 2026, and for QHP issuers on the FFEs,
for plan years beginning on or after January 1, 2026), rather than when
a payer implements their API. That would allow payers to sequentially
target specific plans, populations or enrollee categories for
operational rollout, as long as all currently-enrolled patients are
given the opportunity to opt in to payer to payer data exchange by that
compliance date.
For new patients enrolling on or after the compliance date, we are
proposing to require impacted payers to maintain a process for patients
to opt in to the Payer-to-Payer API data exchange and to identify their
previous and/or concurrent payer(s) prior to the start of their
coverage. Below, in section II.C.4.b., we discuss the possible
incorporation of these proposed requirements into state applications
for Medicaid or CHIP eligibility. Making this process available to
patients during the enrollment process, or immediately thereafter,
would allow the proposed data exchange to take place as quickly as
possible once the patient is enrolled with the new payer. For example,
where there may not be communication during the enrollment process such
as during the QHP enrollment on the FFE, this process should be done
immediately following enrollment. We solicit comment on incorporation
of the proposed requirements into the FFE QHP enrollment process as
described at 45 CFR 156.265. In addition, we propose to require
impacted payers to have a process for patients to opt in to this data
exchange at any time after the start of coverage, or if they have
already opted in, to opt out, at any time.
We are proposing an opt in approach for the data exchange through
the Payer-to-Payer API for the reasons discussed below, even though, as
discussed in section II.B.3.b. of this proposed rule, we believe that
an opt out approach to patient data exchange generally would promote
the positive impacts of data sharing to support care coordination and
improved health outcomes, which could lead to greater health equity.
Furthermore, systems with opt in patient permission requirements are
more likely to report regulatory barriers to data exchange compared to
those without. However, for a variety of legal and operational reasons,
we are proposing an opt in permission policy for our payer to payer
data exchange proposal. An opt in framework means that the patient or
their personal representative would need to affirmatively permit the
payer to share data within the proposed Payer-to-Payer API framework
discussed in this section, and without that permission, the payer may
not engage in the payer to payer data exchange for that patient. We
note that this permission (or lack thereof) would only apply to the
data exchange proposals discussed here and not to any other obligations
under HIPAA or other law.
Certain operational considerations support an opt in framework for
this API. As discussed, to request a patient's data from their previous
and/or concurrent payer(s), a new payer must identify those payers by
gathering information from the patient. While there may be other ways
for payers to collect this information, we believe that patients
themselves are the best source for sufficient and accurate information
necessary for the payer to make the request. Patients would not be
required to provide this information. However, should they choose to,
providing this information would require an affirmative act from the
patient, so we believe that the burden of asking a patient to opt in
would not create a significant additional barrier to patient
participation.
In contrast, our proposed policy for the Provider Access API would
allow payers to exchange patient data with providers unless a patient
has opted out. We are proposing an opt out policy for the Provider
Access API, in part, based on the existence of a treatment relationship
between the patient and provider, a contractual relationship between
the payer and the provider, and a coverage relationship between the
payer and patient. Specifically, our proposals to require the Provider
Access API data exchange only with providers in the payer's network and
require a process to attribute a patient to that provider before data
can be exchanged creates a level of assurance for the payer that it is
sending patient data to an appropriate party. In contrast, two payers
exchanging information do not have a direct relationship but would be
exchanging data based on a patient's separate relationship with each
payer. Therefore, it may make sense for the patient to have a larger
gatekeeping role within this proposed policy.
Furthermore, specific statutory and regulatory requirements
applicable to state Medicaid and CHIP programs would prevent those
programs from establishing an opt out process, or from sharing
information with other payers on the basis of a patient's failure to
opt out of the other payer's data exchange. Specifically, 42 CFR
431.306(d), a regulation implementing section 1902(a)(7) of the Act,
prohibits Medicaid programs from sharing beneficiary information with
outside sources before obtaining permission to do so from the
individual or family, with limited exceptions. This regulation also
applies to CHIP programs under 42 CFR 457.1110(b). This regulation does
not conflict with the proposed opt out policy for the Provider Access
API because Medicaid and CHIP enrolled providers are not outside
sources. However, other payers would typically be outside sources and
thus, the regulation would apply to the data shared through the Payer-
to-Payer API. For further discussion of data exchange between state
Medicaid or CHIP agencies and managed care entities, see section
II.C.4.b. below.
Additionally, we are proposing that the requesting payer would
obtain the permission of the patient for this data exchange, not a
Medicaid or CHIP program that would be sharing the data. Accordingly,
the payer requesting the data would also need to follow the permission
requirements applicable to Medicaid and CHIP programs so that the
Medicaid and CHIP programs could share information through this API in
a manner that is consistent with 42 CFR 431.306(d). Rather than
creating different permission rules for different payers, which would
add significant complexity to the payer to payer data

[[Page 76273]]

exchange process, especially for Medicaid and CHIP programs, it may be
preferable for all impacted payers to use an opt in process.
We request comments on our proposal for an opt in process for
gathering patients' permission for payer to payer data exchange. Is
there any way, such as through any regulatory changes that we should
consider, either in this rulemaking or in the future, that would
instead allow for an opt out process while protecting patient privacy
in accordance with the considerations above? Are there any policy
approaches or technical requirements that could provide all impacted
payers with the assurance that they have gathered appropriate
permission from patients within the statutory and regulatory framework
outlined here? Are there any barriers to interoperability with an opt
in approach for patient data exchange for all impacted payers that we
are not considering?
We emphasize that all data maintained, used, shared, or received
via this proposed Payer-to-Payer API must be maintained, used, shared,
or received in a way that is consistent with all applicable laws and
regulations. For example, the HIPAA Privacy Rule does not require a
covered entity, such as a health plan, to obtain authorization from the
enrolled individual or provide an opportunity for the individual to
agree or object, in order to share PHI under 45 CFR 164.512(a)(1) \59\
if the disclosure is ``required by law'' as defined at 45 CFR 164.103.
Our proposed requirements, if finalized, would be set forth in a
regulation that requires information sharing and therefore would allow
for disclosure under that HIPAA provision, without authorization. For
Medicaid, as noted above, section 1902(a)(7) of the Social Security
Act, and implementing regulations at 42 CFR part 431 govern the
requirements for the use and disclosure of applicant and beneficiary
information, and are discussed in more detail in section II.C.3.c.1 and
in this section. Other laws, such as state privacy laws, may require
the payer to obtain the enrolled individual's consent before disclosing
certain information. We emphasize that our proposals are not intended
to change any existing obligations under HIPAA, the regulations under
42 CFR part 2, or state privacy or other laws, but could and should be
implemented in accordance with those rules if this proposed rule is
finalized as proposed. We request comment on any considerations
regarding state privacy or other laws that our proposals may implicate.
---------------------------------------------------------------------------

\59\ A covered entity may use or disclose protected health
information to the extent that such use or disclosure is required by
law and the use or disclosure complies with and is limited to the
relevant requirements of such law.
---------------------------------------------------------------------------

In summary, we propose that, beginning January 1, 2026 (for
Medicaid managed care plans and CHIP managed care entities, by the
rating period beginning on or after January 1, 2026, and for QHP
issuers on the FFEs, for plan years beginning on or after January 1,
2026), impacted payers must maintain a process to identify a new
patient's previous and/or concurrent payer(s) to facilitate data
exchange using the Payer-to-Payer API. As part of this process,
impacted payers would be required to allow a patient to report multiple
previous and/or concurrent payers if they had (or continue to have)
concurrent coverage. If a patient does report multiple previous payers,
impacted payers would be required to request that patient's data from
all previous and/or concurrent payers.
Furthermore we propose that, prior to the start of coverage,
impacted payers must establish and maintain a process to gather patient
permission for payer to payer data exchange, as described in this
section. That permission process would have to use an opt in framework
whereby a patient or personal representative must affirmatively agree
to allow that data exchange. In addition, we propose that impacted
payers must have a process for patients to opt into this data exchange
at any time, after the start of coverage, or, if they have already
opted in, to opt back out, at any time.
Finally, we propose to require impacted payers to establish and
maintain a process to gather permission and previous and/or concurrent
payer(s) information from patients who are currently enrolled on the
Payer-to-Payer API compliance date. For new patients enrolling on or
after that date, we are proposing to require impacted payers to
maintain a process for patients to provide previous payer information
and opt in to the Payer-to-Payer API data exchange prior to the start
of coverage.
We are proposing the permission and previous and/or concurrent
payer identification requirements for the Payer-to-Payer API for MA
organizations, state Medicaid and CHIP agencies, and QHP issuers on the
FFEs at the CFR sections identified in Table 3.
We request comment on these proposals.
d. Requesting Data Exchange From a Patient's Previous and/or Concurrent
Payer(s) and Responding to Such a Request
We are proposing to require impacted payers to request a patient's
data from their previous and/or concurrent payer(s) no later than 1
week after the start of coverage. We believe 1 week is sufficient time
to allow payers to complete their process for identifying patients'
previous and/or concurrent coverage and to initiate this request for
data from the other payer(s). If after the start of coverage a patient
opts in to the data exchange or provides previous and/or concurrent
payer information, or requests data exchange for another reason, we
propose that the current payer would be required to request data from
the previous and/or concurrent payer(s) no later than 1 week after the
payer has the necessary permission and information, or the patient
makes the request. We acknowledge that the obligation is contingent on
the patient supplying the necessary information about a previous and/or
concurrent payer to enable the new payer to conduct the required
exchange. An impacted payer cannot comply with these requirements if
the patient has not provided timely or accurate information about their
previous and/or concurrent payer. This applies throughout the proposals
in this section of the proposed rule.
Other than in the context of concurrent payers, we generally expect
our proposal to be a one-time data exchange between a previous and new
payer. Once the new payer has received the patient's data, we do not
expect there to be additional information added to the patient record
from the previous payer. However, we want to allow patients to request
subsequent data exchange to account for any outlier situations. We are
also aware that claims take time to process and may be processed after
patients have transitioned to a new payer, thus creating additional
data within the patient's record for some time period after the patient
has transitioned payers. We considered proposing a policy where, if the
patient permits, previous payers would be required to send any
additional data within the required dataset to the new payer within 1
week of receiving additional data. However, keeping in mind the
frequency and burden this could impose on payers, we seek comment on
whether such a policy would be beneficial or overly burdensome. Would
additional data be helpful for the new payer for weeks or months after
enrollment? Would

[[Page 76274]]

specific data be more pertinent than others? Would it lead to overly
burdensome data exchanges that would not provide value to the new
payer? We also considered whether it would be appropriate to limit that
requirement to a certain period after the initial data exchange for
instance within 30 or 90 days. Additionally, we considered whether to
propose that impacted payers must make that data exchange within a week
of receiving any data updates or whether they should only be required
to on a set schedule, such as monthly or quarterly, to allow payers to
streamline transactions for multiple patients. We seek comment on
whether any additional data exchange would be warranted to account for
data received by the previous payer after the patient's coverage ends
and, if so, what the appropriate parameters would be.
We propose that impacted payers would be required to use the OpenID
Connect authorization and authentication protocols at 45 CFR 170.215(b)
to authenticate the identity of the requesting payer. Like our proposal
for the Provider Access API, discussed in section II.B.2., to protect
patient data, we want to ensure payers do not send data unless they are
confident that the requesting payer is who it says it is. Because these
are the same authorization and authentication protocols that are
proposed for Patient Access and Provider Access APIs, we believe that
payers are already familiar with this requirement for implementation.
To assure the payer receiving the request, we propose to require
the requesting payer to include an attestation with the request for
data affirming that the patient has enrolled with the requesting payer
and has opted in to the data exchange in a manner that meets the
necessary legal requirements. As explained in section II.F., we
recommend the use of certain HL7 implementation guides to support the
exchange of data between impacted payers for the Payer-to-Payer API.
The HL7 PDex IG has been developed to ensure that both the technical
and business processes of capturing and sharing a patient's permission
for data exchange preferences are included in the payer to payer data
request. Therefore, using the PDex IG would meet the requirements of
this proposal. Because that IG is recommended and not required,
impacted payers could also exchange an attestation regarding patient
permission with other implementations that meet or exceed the
requirements of the PDex IG.
We propose that the previous and/or concurrent payer, if an
impacted payer, would be required to respond to a current payer's
request, if it meets the requirements, within 1 business day of
receipt. We believe 1 business day is the appropriate timeframe to
complete this process to send the data, as payers need timely access to
previous and/or concurrent payer data to facilitate care coordination
and create a longitudinal record that could be helpful to the patient
should they wish to access their information for care planning with any
new provider(s) they may see. We note that this timeframe also would
align with the 1 business day response time for the Patient Access API
and proposed Provider Access API.
We seek comment on whether the proposed timeframes for a new payer
to request patient data, and for the previous and/or concurrent payer
to send these data, are appropriate or whether other timeframes would
better balance the benefits and burdens. We seek comment on whether
payers could accommodate a shorter period for the data request at the
start of coverage, such as 1 to 3 business days, and whether payers
need more than 1 business day to respond to a request. If so, what is a
more appropriate timeframe for payers to respond to data requests? We
believe it is important for patient data to move to the new payer as
soon as possible to compile a longitudinal record, as well as obtain
information on active prior authorizations.
We note that if a previous and/or concurrent payer is not an
impacted payer, they would not be subject to our proposed requirements
and, therefore would not be required to send data through the Payer-to-
Payer API under this proposal. For example, when a patient moves from a
QHP on an FFE to an employer-based plan, the employer-based plan would
not be impacted by this rulemaking. The new impacted payer would not be
obligated to determine whether the previous payer is an impacted payer
under this proposed rule. Therefore, an impacted new payer would be
required to request the data from the patient's previous and/or
concurrent payer, regardless of whether the other payer is an impacted
payer or not. If the previous and/or concurrent payer is not an
impacted payer, they would not be subject to our proposed requirements
to respond to the request. Conversely, we propose that if an impacted
payer receives an appropriate request for patient data under this
proposal, they would be required to respond by sending all required
data under this proposal, regardless of whether the requesting payer is
or is not an impacted payer (which they payer may or may not know).
In summary, we propose that, beginning January 1, 2026 (for
Medicaid managed care plans and CHIP managed care entities, by the
rating period beginning on or after January 1, 2026, and for QHP
issuers on the FFEs, for plan years beginning on or after January 1,
2026), impacted payers must request the appropriate data, as described
earlier in this section, from any previous and/or concurrent payers
through the Payer-to-Payer API, provided that the patient has permitted
the data exchange as proposed in section II.C.3.c. We propose that
impacted payers would be required to include an attestation with the
request for data affirming that the patient has enrolled with that
requesting payer and has opted in to the data exchange. We propose that
impacted payers must request these data from any previous payer(s) no
later than 1 week after the start of coverage or after a patient's
request. If a patient who did not opt in or provide previous payer
information subsequently opts in to the payer to payer data exchange
and shares that previous payer information, we are proposing that the
impacted payer would be required to request the patient's data from the
patient's previous payer no later than 1 week after the patient opts in
or provides that information.
We propose that if an impacted payer receives a request from
another payer to make data available for former patients who have
enrolled with the new payer or a current patient who has concurrent
coverage, the impacted payer must respond by making the required data
available via the Payer-to-Payer API within 1 business day of receiving
the request if the requesting payer has been authenticated according to
the requirements of 45 CFR 170.215(b), demonstrated that the patient
has permitted the data exchange through an opt in process with the
requesting payer, and disclosure of the data is not prohibited by law.
We are proposing these payer to payer data exchange timeframe
requirements for MA organizations, state Medicaid and CHIP FFS
agencies, and QHP issuers on the FFEs at the CFR sections identified in
Table 3.
We request comment on these proposals.
e. Data Exchange Requirements for Concurrent Coverage
For individuals who have concurrent coverage with multiple payers,
we propose to require impacted payers to collect information about any
concurrent payer(s) from patients before

[[Page 76275]]

the start of coverage with the impacted payer (consistent with how
``start of coverage'' is explained above). Because we believe it would
be beneficial for all of a patient's current payers to maintain a
longitudinal record of the care that the patient has received from all
payers, we propose to require impacted payers to request the same
patient data described in section II.C.3.b. from all of a patient's
concurrent payers, and to send that data in response to an appropriate
request. This would ensure that all of the patient's concurrent payers
maintain a complete patient record and can provide all the information
proposed to be required under the Patient Access API and Provider
Access API.
Specifically, we are proposing to require impacted payers, within 1
week of the start of a patient's coverage, to exchange data with any
concurrent payers that the patient reports. Additionally, we propose
that should an impacted payer receive a request for a current patient's
data from a known concurrent payer for that patient, the receiving
payer must respond with the appropriate data within 1 business day of
receiving the request. Operationally, this proposed exchange would
function the same as the data exchange with a patient's previous payer.
Because all payers will update patient records during the period
when a patient is enrolled with those payers, we propose that when a
patient has concurrent coverage with two or more payers, the impacted
payers must exchange the patient's data available to every other
concurrent payer at least quarterly. This proposal would create
requirements for impacted payers to both request patients' data from
other concurrent payers and to respond to requests from other payers to
share patients' data.
Some patients may be concurrently enrolled with payers that would
not be subject to our proposed requirements because they are not
impacted payers. As discussed above, if a non-impacted concurrent payer
does not have the capability or refuses to exchange the required data
with an impacted concurrent payer through a FHIR API, the impacted
payer is not required to exchange data with that non-impacted payer
under this proposal and would not be required to continue to request
data exchange quarterly. However, we encourage all payers to implement
a Payer-to-Payer API to support data exchange with concurrent payers,
even if they are not subject to our proposed requirements. We expect
that this data exchange among concurrent payers would support better
care coordination and more efficient operations. If a non-impacted
payer requests data in conformance with the proposed requirements of
this section via an API that meets the requirements proposed for the
Payer-to-Payer API, an impacted payer would be required to respond, as
if the requesting payer were subject to the rule. As explained above,
impacted payers would not need to spend resources determining whether
other payers are impacted by these proposals, but would be required to
request patient data and respond to all requests that are made within
the requirements of this proposed rule.
We also considered whether to propose more frequent exchange
(weekly or monthly), or less frequent exchange (semi-annually or
annually); however, we believe a quarterly data exchange would strike
the right balance between providing accurate, timely data and payer
burden. CMS believes sharing data quarterly would be frequent enough to
allow time for new health data to accumulate and still be timely, but
not so frequently that it causes unnecessary burden on the payers
required to provide the information. We request comment on this
proposal, including on the appropriate frequency for this payer to
payer exchange for patients with concurrent coverage.
We note that when a patient has concurrent coverage, the payers
must often communicate regularly to ensure that the proper payer is
responsible for that patient's claims. Nothing in this proposed rule,
including a patient not opting in to the Payer-to-Payer API data
exchange, is intended to alter payers' ability to exchange data as they
do today for that purpose, in accordance with applicable law.
In summary, we propose that, beginning January 1, 2026 (for
Medicaid managed care plans and CHIP managed care entities, by the
rating period beginning on or after January 1, 2026, and for QHP
issuers on the FFEs, for plan years beginning on or after January 1,
2026), impacted payers would be required, within 1 week of the start of
a new patient's coverage, to request initial data exchange from any
concurrent payers that the patient reports, and thereafter to request
data exchange with those payers no less frequently than once per
calendar quarter. We propose that should an impacted payer receive a
request for a current patient's data from that patient's concurrent
payer, the receiving payer must respond with the appropriate data
within 1 business day of receiving the request. Impacted payers would
be required to exchange the same data proposed in section II.C.3.b.
We are proposing these requirements for concurrent coverage data
exchange for MA organizations, state Medicaid and CHIP FFS programs,
Medicaid managed care plans, CHIP managed care entities, and QHP
issuers on the FFEs at the CFR sections identified in Table 3.
We request comment on these proposals.
f. Data Incorporation and Maintenance
We propose that information received by an impacted payer through
this data exchange must be incorporated into the patient's record with
the new payer. Those data would then be part of the patient's record
maintained by the new payer and should be included as appropriate in
the data available through the Patient Access API, Provider Access API
and Payer-to-Payer API, if our proposals are finalized as proposed. In
this way, a patient's cumulative record would follow them between
payers and be available to them and their providers. While this
proposal would not obligate payers to review, utilize, update,
validate, or correct data received from another payer, we encourage
impacted payers to do so, at least to the extent doing so might benefit
the patient's ongoing care. As previously explained in the CMS
Interoperability and Patient Access final rule for the payer to payer
data exchange (85 FR 25568), payers could choose to indicate which data
were received from a previous payer so a future receiving payer,
provider, or even the patient, would know where to direct questions
(such as how to address contradictory or inaccurate information), but
would not be required to do so under this proposal. Regardless, all
data maintained, used, shared, or received via the proposed Payer-to-
Payer API would be required to be maintained, used, shared, or received
in a way that is consistent with all applicable laws and regulations.
We note that our proposals would not impact any payer's data
retention requirements. Specifically, we are not proposing to require
impacted payers to maintain data for unenrolled patients any longer or
differently than they do today under current law, regulation, or
policy. We understand that if a patient is uninsured or moves to a non-
impacted payer that does not request information from the previous
payer, after a period of time, the old payer may discard information,
which would make it unavailable to the patient or other payers in the
future.
However, we believe that imposing requirements that would require
payers to alter their data retention policies based on the actions of
other payers

[[Page 76276]]

would be a significant burden that would outweigh the benefits of such
a policy. We considered proposing a minimum period during which a payer
must maintain patient records after disenrollment, such as 1 or 2
years. However, we believe that most payers have policies in place that
would maintain patient data for at least that long, and thus, such a
requirement is unnecessary and burdensome. We request comment on
whether our understanding is correct and whether there is a benefit to
us considering a data retention requirement in the future.
In summary, we propose that, beginning January 1, 2026 (for
Medicaid managed care plans and CHIP managed care entities, by the
rating period beginning on or after January 1, 2026, and for QHP
issuers on the FFEs, for plan years beginning on or after January 1,
2026), any information received by an impacted payer through this data
exchange must be incorporated into the patient's record with the new
payer.
We are proposing this requirement regarding data incorporation for
MA organizations, state Medicaid and CHIP FFS programs, Medicaid
managed care plans, CHIP managed care entities, and QHP issuers on the
FFEs at the CFR sections identified in Table 3.
g. Patient Education Requirements
Consistent with our proposals for the Provider Access API, impacted
payers would be required to provide patients with educational materials
in non-technical, simple, and easy-to-understand language, explaining
at a minimum: the benefits of Payer-to-Payer API data exchange, their
ability to opt in or withdraw a previous opt in decision, and
instructions for doing so. Impacted payers would be required to provide
these educational materials to patients at or before requesting
permission for the Payer-to-Payer API data exchange. As discussed
above, currently enrolled patients must be given the opportunity to opt
in to payer to payer data exchange and to provide previous and/or
concurrent payer information before the API compliance date. Our
proposal would require impacted payers to provide these educational
materials to those currently enrolled patients at or before requesting
their opt in as well. In addition, similar materials would have to be
provided annually to all covered patients in mechanisms that the payer
regularly uses to communicate with patients. This information would
also be required to be provided in an easily accessible location on the
payer's public website. We request comment on whether it would reduce
payers' burden to only be required to provide these materials annually
to any patients who have not opted in and those with known concurrent
payers.
We propose that impacted payers would have to provide educational
materials regarding the payer to payer data exchange to all patients at
or before requesting opt in and at least annually beginning January 1,
2026 (for Medicaid managed care plans and CHIP managed care entities,
by the rating period beginning on or after January 1, 2026, and for QHP
issuers on the FFEs, for plan years beginning on or after January 1,
2026).
We are proposing these patient education requirements for MA
organizations, state Medicaid and CHIP FFS programs, Medicaid managed
care plans, CHIP managed care entities, and QHP issuers on the FFEs at
the CFR sections identified in Table 3.
4. Payer to Payer Data Exchange in Medicaid and CHIP
a. Inclusion of Medicaid and CHIP FFS
We did not require state Medicaid and CHIP FFS programs to comply
with the payer to payer data exchange policies in the CMS
Interoperability and Patient Access final rule (85 FR 25568). State
Medicaid and CHIP FFS programs can face unique circumstances that might
make it more challenging for them to meet new requirements within the
same timeframe as other payers because of state budget cycles and other
funding constraints, possible state legislation or regulatory
requirements, contracting timeframes, required systems upgrades, and
recruiting necessary staff resources. As a result, in our first phase
of interoperability policies in the CMS Interoperability and Patient
Access final rule (85 FR 25524), we chose to limit the burden on these
programs so they could focus their attention and resources on
implementing the Patient Access and Provider Directory APIs and did not
make the Payer-to-Payer API policies in that rule applicable to state
Medicaid and CHIP FFS programs. However, in August 2020, CMS released a
letter to state health officials in which we encouraged state Medicaid
and CHIP FFS programs to accommodate payer to payer data exchange
requests from beneficiaries.\60\
---------------------------------------------------------------------------

\60\ Centers for Medicare & 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.
---------------------------------------------------------------------------

We are now proposing to make the proposed payer to payer data
exchange policies in this proposed rule applicable to state Medicaid
and CHIP FFS programs. We believe that proposing to require Medicaid
and CHIP FFS programs to implement the Payer-to-Payer API data exchange
policies in this proposed rule would not be as burdensome as proposing
to require them to follow the non-API-based payer to payer data
exchange policies that were finalized in the CMS Interoperability and
Patient Access final rule (85 FR 25524) and that we are proposing to
withdraw in this proposed rule. That is because this new API would be
leveraging the same data and technical standards as the Patient Access
API. State programs should have already implemented their Patient
Access APIs and should thus be able to leverage the work done for that
API to make implementing this newly proposed API more manageable.
For state Medicaid and CHIP FFS programs, the state agency is the
impacted payer that would share patient data with other impacted
payers. As we discuss in more detail in section II.C.3.a. of this
proposed rule, using the Payer-to-Payer API could create efficiencies
for state Medicaid and CHIP programs, thereby reducing burden for these
programs, and potentially leading to better coordinated patient care
and improved health outcomes. We expect the proposed Payer-to-Payer API
requirement to lead to more effective administration of the state plan,
and to better enable Medicaid and CHIP programs to ensure care and
services are provided in a manner that is consistent with their
beneficiaries' best interests. Ensuring that patient data can follow
Medicaid and CHIP beneficiaries as they enter these programs could
potentially lead to better care coordination and continuity of care for
these patients. It could also reduce burden for patients and providers.
The Medicaid and CHIP FFS programs would have additional information
from other payers to share via the Patient Access API and the Provider
Access API. As a result, Medicaid and CHIP beneficiaries would have
more readily available information to support informed decision-making,
and Medicaid and CHIP providers would have more information about the
care their patients are receiving. This could potentially lead to fewer
duplicate tests or less time taken collecting and recollecting
information about the patient during a visit. Any effort a state
Medicaid or CHIP FFS program takes to evaluate the data from a
patient's previous or concurrent payers could potentially allow the
program to avoid wasteful, unnecessary, or duplicative action. In this
way,

[[Page 76277]]

extending this Payer-to-Payer API to state Medicaid and CHIP FFS
programs could benefit these programs by helping them to operate more
efficiently.
If this proposal is finalized to include state Medicaid and CHIP
FFS programs, patients would continue to have access to their health
information, creating a longitudinal record, as they move into and out
of Medicaid or CHIP FFS. A broader range of information about patients'
past care might also be able to follow them to new providers if payers
have greater access to data from other payers and can make it available
through the Patient Access and Provider Access APIs proposed in this
proposed rule.
b. Permission and Exchange Considerations Specific to Medicaid and CHIP
FFS, Medicaid Managed Care Plans, and CHIP Managed Care Entities
We know that state Medicaid or CHIP agencies regularly exchange
data with their managed care plans. This Payer-to-Payer API proposal
would not affect the Medicaid and CHIP programs' ability to share data
as they do today. Specifically, Medicaid agencies and their contracted
managed care plans may, and in some cases are required to,\61\ exchange
beneficiary information with each other, as part of the operation of
the Medicaid program, subject to any other applicable law. Similarly,
CHIP agencies and their contracted managed care entities may exchange
beneficiary data, as part of the operation of the CHIP program, subject
to any other applicable law.\62\ This allows effective transitions for
beneficiaries who move between managed care plans or entities or
between FFS and managed care delivery/coverage systems within the same
state's Medicaid or CHIP programs, and promotes the coordination and
continuity of care within those programs--the very coordination that
our proposals are intended to enable.
---------------------------------------------------------------------------

\61\ See 42 CFR 438.62(b)(1)(iii), 438.242(c)(2) and (3).
\62\ See cross-references at 42 CFR 457.1216 and 457.1233(d).
---------------------------------------------------------------------------

As mentioned above, Medicaid managed care plans and CHIP managed
care entities are not outside sources, but are part of a state's
Medicaid and/or CHIP programs as a whole. Therefore, we do not wish to
impose a policy that would require an opt in for patients for state
Medicaid and CHIP agencies and their managed care entities to exchange
information, as they may do today. Current consent rules and
requirements for exchange within a state's Medicaid and CHIP programs
(such as between a managed care plan and the state Medicaid or CHIP
agency or between two managed care plans contracted with the state
Medicaid or CHIP agency), are not affected by our proposals. There is
no requirement for a state Medicaid or CHIP agency to obtain an opt in
from an individual or family member prior to providing information
about a Medicaid or CHIP beneficiary to its own providers or plans, as
such entities would not be an outside source as described at 42 CFR
431.306(d) (and as discussed in section II.B., related to our Provider
Access API proposals). We do not intend any of our proposals to
interfere with or affect this permissible information exchange. Hence,
we are proposing that if a Medicaid or CHIP agency is exchanging
information per our Payer-to-Payer API proposals with a managed care
plan or managed care entity with which they have a contract, the
requirement to obtain patient opt in would not apply. The other
proposed payer to payer requirements, such as the requirement to use a
FHIR API and the authorization and authentication protocols would
apply. The exchange must also not be prohibited by law.
We welcome comments, specifically from states and contracted
managed care entities, as to how we can establish standards for patient
data exchange between state Medicaid and CHIP agencies and their
contracted managed care entities without creating additional barriers
or burden.
We are proposing that Medicaid and CHIP agencies, like all impacted
payers, implement a process to allow currently enrolled beneficiaries a
chance to opt in to payer to payer data exchange prior to the State
Medicaid or CHIP agency's Payer-to-Payer API compliance date, and prior
to the enrollment of new beneficiaries after that date. The opportunity
for newly enrolling patients to opt in could take place through the
application, or at some later point of contact with the beneficiary
prior to the start of coverage, but in no instance would our proposals
permit a delay in the enrollment process or a beneficiary's coverage.
As discussed above, 42 CFR 431.306 lists certain requirements for
sharing beneficiary data. We note that when an individual's Medicaid or
CHIP enrollment has ended and another payer is requesting a former
Medicaid beneficiary's information, receiving an attestation from a
requesting payer that the patient has opted in to data exchange with
the requesting payer, consistent with our proposals for all payers, is
a permissible way for the state Medicaid or CHIP agency to obtain
permission as required under 42 CFR 431.306(d). We are proposing these
requirements at the CFR citations in Table 3.
States are also reminded that access to information concerning
beneficiaries must be restricted to persons and agencies who are
subject to standards of confidentiality that are comparable to that of
the Medicaid agency, in accordance with 42 CFR 431.306(b). We do not
believe that any of the other requirements of 42 CFR 431.306 are
relevant because they cover data release and use in contexts outside of
our proposals in this section.
We are specifically proposing that state Medicaid and CHIP
agencies, rather than their managed care plans, would be responsible
for obtaining the required permission. A Medicaid or CHIP beneficiary
may switch between FFS and managed care delivery systems within the
same state's Medicaid or CHIP program, but despite these shifts, an
eligible beneficiary remains a beneficiary of the state program. States
may also change the managed care plans that they contract with. Thus,
the patient permission to this data exchange, as a Medicaid or CHIP
beneficiary, should be obtained by the state and would apply regardless
of the delivery system in which the beneficiary is enrolled. We believe
that the state is the appropriate custodian of the patient's permission
record, rather than the particular managed care plan or managed care
entity through which a patient receives care. We understand that this
would require state Medicaid and CHIP agencies to create new processes
to share a patient's opt in preference with their managed care plans
and managed care entities.
We considered proposing that the Payer-to-Payer API requirements
would not apply for beneficiaries moving between or with concurrent
coverage with a state Medicaid or CHIP agency and a contracted managed
care entity for the reasons outlined above. However, we are concerned
that many states today do not exchange data between their Medicaid or
CHIP FFS programs and managed care. We request comments on whether
there are other ways we can ensure patient data is exchanged in this
case in a manner that would reduce burden on states.
We are also proposing that the requirement to identify patients'
previous and/or concurrent payers apply to state Medicaid and CHIP
agencies rather than managed care plans or managed care entities. For
the reasons described above, we believe that having the state maintain
that record would allow that information to be retained regardless of
any changes to the

[[Page 76278]]

patient's Medicaid or CHIP care delivery system.
Furthermore, we understand that in many states, managed care plans
may not have any contact with patients prior to their enrollment in the
Medicaid or CHIP managed care plan. We believe the ideal time to allow
patients to opt into payer to payer data exchange is during their
application for Medicaid or CHIP. However, per 42 CFR 435.907(e)(1),
states may only require information from an applicant that is necessary
to make an eligibility determination. This means that while an
applicant may be asked to provide their permission for the data
exchange, they may not be required to respond to the question as a
condition of submitting the application. Because we expect higher rates
of patients providing permission when they are presented with the
option at a time when they are already engaged in providing information
(such as at application or plan selection), we highly encourage states
to leverage any touchpoints before patients are enrolled in FFS or a
managed care plan rather than expecting patients to submit permission
in a separate process.
We understand that making changes to applications can be a
significant administrative process and there may be other places where
a state could obtain a patient's data exchange preference for the
Payer-to-Payer API data exchange. For instance, a state could leverage
an online portal or app, if beneficiaries frequently use those pathways
for other purposes, such as reporting a change in circumstance or
providing information for eligibility renewal. However, the option
should be equally available for all beneficiaries and if only a small
portion of the Medicaid population uses these tools to communicate with
the Medicaid agency, that subset would be self-selected for greater
technology literacy and taking this approach could exacerbate
inequality.
We note that the single streamlined application, which for Medicaid
purposes is described at 42 CFR 435.907(b)(1) and is also used for
applications through the FFEs, includes questions about concurrent
coverage information. We also expect that some states that do not use
the single streamlined application already ask for this information for
Coordination of Benefits and Third-Party Liability purposes. We believe
that it would generally make sense to gather permission for payer to
payer data exchange with that concurrent payer at that point.
Furthermore, the patient permission provisions in this proposal would
apply only to the payer to payer data exchange discussed here and would
not affect states' ability to perform Coordination of Benefits or
Third-Party Liability activities as they do today.
We request comment on the workflow and data exchanges that occur
when a Medicaid or CHIP beneficiary is enrolled into a managed care
plan and the feasibility of including the patient permission during the
enrollment process. If not included in the application itself, is it
feasible to gather permission and previous and/or concurrent payer
information in a post-application questionnaire? Are there touchpoints
that exist with beneficiaries after the application, but before or
during enrollment (such as plan selection) that could be leveraged for
this purpose? We considered proposing a policy that would require
states to include optional questions to capture a patient's data
exchange preference for payer to payer data exchange on their
applications (as a non-required field); however, we believe that states
have different processes, and a one-size-fits-all approach may not be
optimal. Based on comments we receive and implementation across state
Medicaid and CHIP programs, we may propose such a policy in the future.
c. Federal Funding for State Medicaid and CHIP Expenditures on
Implementation of Payer to Payer Data Exchange
Should our proposals be finalized as proposed, states operating
Medicaid and CHIP programs might be able to access Federal matching
funds to support their implementation of the Payer-to-Payer API. This
proposed API is expected to lead to more efficient administration of
the Medicaid and CHIP state plans, consistent with sections 1902(a)(4)
and 2101(a) of the Act.
We would not consider state expenditures for implementing this
proposal to be attributable to any covered Medicaid item or service
within the definition of ``medical assistance.'' Thus, in Medicaid, CMS
would not match these expenditures at the state's regular Federal FMAP.
However, were this proposal to be finalized as proposed, FFP under
section 1903(a)(7) of the Act, at a rate of 50 percent, for the proper
and efficient administration of the Medicaid state plan, might be
available for state expenditures related to implementing this proposal
for their Medicaid programs. We believe that using the Payer-to-Payer
API would help the state more efficiently administer its Medicaid
program, by ensuring that payers can access data that could improve
care coordination for patients.
States' expenditures to implement these proposed requirements might
also be eligible for 90 percent enhanced FFP under section
1903(a)(3)(A)(i) of the Act, if the expenditures can be attributed to
the design, development, or installation of mechanized claims
processing and information retrieval systems. Additionally, 75 percent
enhanced FFP under section 1903(a)(3)(B) of the Act may be available
for state expenditures to operate Medicaid mechanized claims processing
and information retrieval systems to comply with this proposed
requirement.
States can request Medicaid enhanced FFP under section
1903(a)(3)(A)(i) or (B) of the Act through the APD process described in
45 CFR part 95, subpart F. States are reminded that 42 CFR
433.112(b)(12) and 433.116(c) in part require that any system for which
they are receiving enhanced FFP under section 1903(a)(3)(A)(i) or (B)
of the Act align with and incorporate the ONC's Health Information
Technology standards adopted in 45 CFR part 170, subpart B. The Payer-
to-Payer API complements this requirement because these APIs further
interoperability by using standards adopted by ONC at 45 CFR
170.215.\63\ States are also reminded that 42 CFR 433.112(b)(10) and 42
CFR 433.116(c) explicitly support exposed APIs, meaning their functions
are visible to others to enable the creation of a software program or
application, as a condition of receiving enhanced FFP under section
1903(a)(3)(A)(i) or (B) of the Act.
---------------------------------------------------------------------------

\63\ Centers for Medicare & 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.
---------------------------------------------------------------------------

Similarly, 42 CFR 433.112(b)(13) and 433.116(c) require states to
promote sharing, leverage, and re-use of Medicaid technologies and
systems as a condition of receiving enhanced FFP under section
1903(a)(3)(A)(i) or (B) of the Act. CMS interprets that requirement to
apply to technical documentation associated with a technology or
system, such as technical documentation for connecting to a state's
APIs. Making the needed technical documentation publicly available so
that systems that need to can connect to the APIs proposed in this rule
would be required as part of the technical requirements at 42 CFR
431.60(d) for all proposed APIs in this rule, including the Payer-to-
Payer API.
Separately, for state CHIP agencies, section 2105(c)(2)(A) of the
Act and 42 CFR 457.618, limiting administrative

[[Page 76279]]

costs to no more than ten percent of a state's total computable
expenditures for a fiscal year, would apply to administrative claims
for developing the APIs proposed in this rule.
We note that the temporary Medicaid FMAP increase available under
section 6008 of the Families First Coronavirus Response Act (Pub. L.
116-127) does not apply to administrative expenditures.
d. Medicaid Expansion CHIP Programs
Most states have Medicaid Expansion CHIP programs, in which a state
receives Federal funding to expand Medicaid eligibility to optional
targeted to low-income children that meet the requirements of section
2103 of the Social Security Act. We are proposing at 42 CFR 457.700(c)
that for states with Medicaid expansion CHIP programs, the proposals in
this rule for Medicaid would apply to those programs rather than our
proposals for separate CHIP programs. Functionally, our proposals are
the same; however, for clarity, we are making explicit that the
Medicaid requirements at Sec. Sec. 431.60, 431.61, and 431.80 would
apply to those programs rather than the separate CHIP requirements at
Sec. Sec. 457.730, 457.731, and 457.732.
5. Extensions, Exemptions, and Exceptions
a. Extensions and Exemptions for Medicaid and CHIP FFS Programs
Should our proposals regarding the Payer-to-Payer API be finalized
as proposed, we would strongly encourage state Medicaid and CHIP FFS
programs to implement the Payer-to-Payer API as soon as possible, due
to the many anticipated benefits of the API as discussed in this
section. However, we also recognize that state Medicaid and CHIP FFS
agencies may face certain circumstances that would not apply to other
impacted payers. To address these concerns, we are proposing a process
through which states may seek an extension of, and, in specific
circumstances, an exemption from the Payer-to-Payer API requirements.
We propose the following:
(1) Extension
At the regulation citations identified in Table 3, we propose to
provide state Medicaid FFS and CHIP FFS programs the opportunity to
request a one-time extension of up to 1 year to implement the Payer-to-
Payer API specified at 42 CFR 431.61(b) and 457.731(b). Some states may
be unable to meet the proposed compliance date due to challenges
related to securing needed funding for necessary contracting and staff
resources in time to develop and implement the API requirements,
depending on when the final rule is published in relation to a state's
fiscal year, legislative session, budget process, and related timeline.
Some states may need to initiate a public procurement process to secure
contractors with the necessary skills to support a state's
implementation of these proposed API policies. The timeline for an
openly competed procurement process, together with the time needed to
onboard the contractor and develop the API, can be lengthy for states.
A state might need to hire new staff with the necessary skillset to
implement this policy. The time needed to initiate the public employee
hiring process, vet, hire, and onboard the new staff may make meeting
the proposed compliance timeline difficult because, generally speaking,
public employee hiring processes include stricter guidelines and longer
time-to-hire periods than the other sectors.\64\ Furthermore, states
are currently responding to the effects of the COVID-19 public health
emergency, and their regular operational resources are over-extended.
Unwinding from the COVID-19 public health emergency is also expected to
require significant IT resources, which could have an impact on future
IT work. In all such situations, a state might need more time than
other impacted payers to implement the Payer-to-Payer API requirements.
The 1-year extension that we propose could help mitigate the
challenges. We considered delaying implementation of the provisions in
this proposed rule an additional year for states, but decided that it
would be better to propose to have only those states that needed an
extension apply, because states vary in their level of technical
expertise and ability to recruit staff and secure contracts.
---------------------------------------------------------------------------

\64\ State hiring processes are comparable with Federal hiring
processes. According to OMB, the average time-to-hire for Federal
employees was 98.3 days in 2018, significantly higher than the
private sector average of 23.8 days. See https://www.opm.gov/news/releases/2020/02/opm-issues-updated-time-to-hire-guidance/.
---------------------------------------------------------------------------

Should the proposal for this API be finalized as proposed, states
would be permitted to submit a written application for a one-time, one-
year extension as part of their annual APD for MMIS operations
expenditures. The state's request would have to include the following:
(1) a narrative justification describing the specific reasons why the
state cannot reasonably satisfy the requirement(s) by the compliance
date, and why those reasons result from circumstances that are unique
to the agency operating the Medicaid and/or CHIP FFS program (versus
other types of impacted payers); (2) a report on completed and ongoing
state implementation activities that evidence a good faith effort
towards compliance; and (3) a comprehensive plan to meet the Payer-to-
Payer API requirements no later than 1 year after the compliance date.
Under this proposal, CMS would approve an extension if, based on
the information provided in the APD, CMS determines that the request
adequately establishes a need to delay implementation, and that the
state has a comprehensive plan to implement the proposed requirements
no later than 1 year after the compliance date.
We also solicit comments on whether our proposal would adequately
address the unique circumstances that affect states, and that might
make timely compliance with the proposed API requirement difficult for
states.
(2) Exemption
At the CFR sections identified in Table 3, we propose to permit
state Medicaid FFS programs to request an exemption from the Payer-to-
Payer API requirements when at least 90 percent of the state's Medicaid
beneficiaries are enrolled in Medicaid managed care organizations as
defined at 42 CFR 438.2. Likewise, we propose that separate CHIP FFS
programs could request an exemption from the Payer-to-Payer API
requirements if at least 90 percent of the state's separate CHIP
beneficiaries are enrolled in CHIP managed care entities as defined at
42 CFR 457.10. In this circumstance, the time and resources that the
state would need to expend to implement the Payer-to-Payer API
requirements for a small FFS population may outweigh the benefits of
implementing and maintaining the API. Unlike other impacted payers,
state Medicaid and CHIP FFS programs do not have a diversity of plans
to balance implementation costs for those plans with low enrollment. If
there is low enrollment in a state Medicaid or CHIP FFS program, there
is no potential for the technology to be leveraged for additional
beneficiaries. States, unlike other payers, do not maintain additional
lines of business.
We acknowledge that the proposed exemption could mean that most
beneficiaries enrolled with exempted Medicaid or CHIP FFS programs
would not receive the full benefits of having this API available to
facilitate health information sharing with other payers. To address
this, we propose that states that are granted an exemption would be
expected to implement an alternative

[[Page 76280]]

plan to ensure that other payers will have efficient electronic access
to the same information through other means, to help ensure that
Medicaid or CHIP services are provided with reasonable promptness and
in a manner consistent with simplicity of administration and in the
best interests of those beneficiaries who are served under the FFS
program.
We propose that a state could submit a written request for an
exemption from the requirements for the Payer-to-Payer API as part of
its annual APD for MMIS operations expenditures prior to the date by
which the state would otherwise need to comply with the requirements
(which may be extended by 1 year if the state receives an extension).
For Medicaid exemption requests, the state would be required to include
documentation that it meets the criteria for the exemption based on
enrollment data from the most recent CMS ``Medicaid Managed Care
Enrollment and Program Characteristics'' report. For a CHIP FFS
exemption, the state's request would have to include enrollment data
from Section 5 of the most recently accepted state submission to CARTS.
The state would also be required to include in its request information
about an alternative plan to ensure that payers will have efficient
electronic access to the same information through other means while the
exemption is in effect. CMS would grant the exemption if the state
establishes to CMS's satisfaction that it meets the criteria for the
exemption and has established such an alternative plan. We note that
the exemption would only apply to the API requirements, not the state's
permission collection obligations.
Once an exemption has been approved, we propose that the exemption
would expire if either of the following two scenarios occurs: (1) based
on the 3 previous years of available, finalized Medicaid T-MSIS and/or
CHIP CARTS managed care and FFS enrollment data, the State's managed
care enrollment for 2 of the previous 3 years is below 90 percent; or
(2) CMS has approved a State plan amendment, waiver, or waiver
amendment that would significantly reduce the share of beneficiaries
enrolled in managed care and the anticipated shift in enrollment is
confirmed by available, finalized Medicaid T-MSIS and/or CHIP CARTS
managed care and FFS enrollment data.
For the first scenario, CMS recognizes that there may be
circumstances where a state's managed care enrollment may fluctuate
slightly below the 90 percent threshold in 1 year, and yet return to
above 90 percent the next year. To help reduce the possible burden on
exempted states experiencing this type of temporary fluctuation in
managed care enrollment, CMS would consider data from the 3 previous
years of available, finalized Medicaid T-MSIS and/or CHIP CARTS managed
care and FFS enrollment data. We propose that if the state's managed
care enrollment for 2 of the previous 3 years is below 90 percent, the
state's exemption would expire.
We propose that a state would be required to provide written
notification to CMS that the state no longer qualifies for the Payer-
to-Payer API exemption when data confirm that there has been a shift
from managed care enrollment to FFS enrollment resulting in the State's
managed care enrollment falling below the 90 percent threshold for 2 of
the previous 3 years. We propose that the written notification be
submitted to CMS within 90 days of the finalization of the annual
Medicaid T-MSIS managed care enrollment data and/or the CARTS report
for CHIP confirming that there has been the requisite shift from
managed care enrollment to FFS enrollment in 2 of the 3 previous years.
For the second scenario, we recognize that there may be state plan
amendments, waivers, or waiver amendments that would result in a shift
from managed care enrollment to FFS enrollment. Additionally, there may
be instances where anticipated enrollment shifts may not be fully
realized due to other circumstances. We propose that a state would be
required to provide written notification to CMS that the state no
longer qualifies for the Payer-to-Payer API exemption when data confirm
that there has been a shift from managed care enrollment to FFS
enrollment as anticipated in the state plan amendment or waiver
approval. We propose that the written notification be submitted to CMS
within 90 days of the finalization of the first annual Medicaid T-MSIS
managed care enrollment data and/or the CARTS report for CHIP
confirming that there has been the requisite shift from managed care
enrollment to FFS enrollment.
Regardless of why the exemption expires, if it expires, the state
would be required to obtain CMS's approval of a timeline for compliance
with the Payer-to-Payer API requirements for the state's Medicaid FFS
and/or CHIP FFS population(s) within two years of the expiration date
of the exemption.
For Medicaid and CHIP managed care, we are not proposing an
extension process because we believe that managed care plans are
actively working to develop the necessary IT infrastructure to be able
to comply with the existing requirements at 42 CFR parts 438 and 457
and because many of them might benefit from efficiencies resulting from
the variety of plan types that they offer. Many managed care plans are
part of parent organizations that maintain multiple lines of business,
including Medicaid managed care plans and plans sold on the Exchanges.
As discussed in the CMS Interoperability and Patient Access final rule
(85 FR 25607, 25612, and 25620), work done by these organizations can
benefit all lines of business and, as such, we do not believe that the
proposals in this rule impose undue burden or cannot be achieved by the
compliance date. We are soliciting comments on our assumptions
regarding the scope of resources and ability of managed care parent
organizations to achieve economies of scale when implementing the
proposed API.
Further, we seek comment on whether an extension process would be
warranted for certain managed care plans to provide additional time for
the plan to comply with the proposed requirement at 42 CFR 431.61(b)
(which cross references at 42 CFR 438.242(b)(7) for Medicaid managed
care plans) and at proposed 42 CFR 457.731(b) (which cross references
at 42 CFR 457.1233(d)) for CHIP managed care entities. While we are not
proposing such a process for managed care plans and entities and do not
believe one is necessary, we are open to evaluating options for
possible future rulemaking. Were we to adopt an extension process for
these managed care plans and entities, what criteria should a managed
care plan or entity meet to qualify for an extension? Should the
criteria include enrollment size, plan type, or certain unique
characteristics that could hinder their achievement of the proposed
requirements by the proposed compliance date? We also seek comment on
whether, were we to propose such a process for Medicaid managed care
plans or CHIP managed care entities, the entity responsible for
evaluating the criteria and exception evaluation process should be the
state and whether states could implement the exception evaluation
process with available resources. Consistent with the exception process
proposed for QHP issuers on the FFEs at 45 CFR 156.222(c), we would
expect managed care plans seeking extensions to provide, at a minimum,
a narrative justification describing the reasons why a plan or entity
cannot reasonably satisfy the requirements by the proposed compliance
date, an explanation of the impact of non-compliance upon

[[Page 76281]]

enrollees, an explanation of the current or proposed means of providing
electronic health information to payers, and a comprehensive plan with
a timeline to achieve compliance.
We request comment on the proposed extension and exemption
processes.
b. Exception for QHP Issuers
For QHP issuers on the FFEs, we propose an exception to the Payer-
to-Payer API proposal at the regulation citations identified in Table
3. We propose that if an issuer applying for QHP certification to be
offered through an FFE believes it cannot satisfy the proposed
requirements at 45 CFR 156.222(b) for the Payer-to-Payer API, the
issuer would have to include as part of its QHP application a narrative
justification describing the reasons why the issuer could not
reasonably satisfy the requirements for the applicable plan year, the
impact of non-compliance upon providers and enrollees, the current or
proposed means of providing health information to payers, and solutions
and a timeline to achieve compliance with the requirements of this
section. We propose that the FFE may grant an exception to the
requirements at 45 CFR 156.222(b) for the Payer-to-Payer API if it
determines that making qualified health plans of such issuer available
through such FFE is in the interests of qualified individuals in the
state or states in which the FFE operates, and an exception would be
warranted to permit the issuer to offer qualified health plans through
the FFE. This proposal would be consistent with the exception for QHP
issuers on the FFEs we finalized for the Patient Access API in the CMS
Interoperability and Patient Access final rule (85 FR 25552). For
instance, as noted in that final rule, that exception could apply to
small issuers, financially vulnerable issuers, or new entrants to the
FFEs that demonstrate that deploying FHIR API technology consistent
with the required interoperability standards would pose a significant
barrier to the issuer's ability to provide coverage to patients, and
not certifying the issuer's QHP or QHPs would result in patients having
few or no plan options in certain areas. We believe that having a QHP
issuer offer QHPs through an FFE generally is in the best interest of
patients and would not want patients to have to go without access to
QHP coverage because the issuer is unable to implement this API.
In summary, we propose to permit certain impacted payers (state
Medicaid and CHIP FFS programs and QHP issuers on the FFEs) to apply
for an extension, exemption, or exception, as applicable, from
implementing the proposed Payer-to-Payer API. We propose that these
programs would submit and be granted approval for an extension or
exemption as a part of applicable established processes. We propose
that submission requirements would include certain documentation
identified in the regulatory citations in Table 3.
BILLING CODE 4120-01-P

[[Page 76282]]

[GRAPHIC] [TIFF OMITTED] TP13DE22.002

BILLING CODE 4120-01-C

[[Page 76283]]

6. Statutory Authorities for Payer to Payer Data Exchange Proposals
a. MA Organizations
For MA organizations, we are proposing these Payer-to-Payer API
requirements under our authority at section 1856(b) of the Act by which
the Secretary may adopt by regulation standards to implement provisions
in Part C of Title XVIII of the Act (such as section 1852(d)(1)(A)),
section 1852(h) of the Act that requires MA organizations to provide
their enrollees with timely access to medical records and health
information insofar as MA organizations maintain such information; and
section 1857(e)(1) of the Act by which the Secretary may incorporate
contract terms and conditions for MA organizations that we determine
are necessary, appropriate, and not inconsistent with the statute.
We note that in regulations establishing the MA program,\65\ CMS
described it as a program designed to provide for regional plans that
may make private plan options available to many more beneficiaries,
especially those in rural areas. This was done to enrich the range of
benefit choices, provide incentives to plans and add specialized plans
to coordinate and manage care in ways that comprehensively serve those
with complex and disabling diseases and conditions, use competition to
improve service and benefits, invest in preventive care, hold costs
down in ways that attract enrollees, and advance the goal of improving
quality and increasing efficiency in the overall healthcare system. The
proposals throughout this proposed rule support these goals and enable
the MA program to advance services for its beneficiary population in
one significant way--by providing greater access to information in a
way specifically to improve care management for payers, providers, and
the patient.
---------------------------------------------------------------------------

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

[[Page 76284]]

Section 1902(a)(8) of the Act, which requires states to
ensure that Medicaid services are furnished with reasonable promptness
to all eligible individuals.
Section 1902(a)(19) of the Act, which requires states to
ensure that care and services are provided in a manner consistent with
simplicity of administration and the best interests of the recipients.
We believe these proposals related to the Payer-to-Payer API are
authorized by section 1902(a)(4), (a)(8), and (a)(19) of the Act for
the following reasons. First, because the Payer-to-Payer API is
designed to enable efficient exchange of data between payers, if
finalized as proposed, we anticipate that it would help state Medicaid
programs improve the efficiencies and simplicity of their own
operations, consistent with sections 1902(a)(4) and (a)(19) of the Act.
It could give Medicaid and CHIP agencies and their managed care plans
access to their beneficiary's information in a standardized manner and
enable the state to then make that information available to providers
and to patients through the Patient Access and Provider Access API. It
could also reduce the amount of time needed to evaluate a patient's
current care plan and possible implications for care continuity, which
could introduce efficiencies and improve care. Receiving patient
information at the start of coverage would help to ensure Medicaid and
CHIP agencies and those managed care plans considered impacted payers
under this proposed rule could lead to more appropriate service
utilization and higher beneficiary satisfaction by supporting efficient
care coordination and continuity of care, which could lead to better
health outcomes.
As discussed in section II.C.3.a. of this proposed rule, if a state
Medicaid program has access to a previous payer's prior authorization
decisions, the Medicaid program could choose to accept the existing
decision and support continued patient care without requiring a new
prior authorization or duplicate tests. This information exchange might
also improve care continuity for beneficiaries who have concurrent
coverage in addition to Medicaid by improving the coordination of
health coverage they receive, reducing gaps, or duplication of
coverage.
Our proposals, if finalized, are expected to help states and
managed care plans furnish Medicaid services with reasonable promptness
and in a manner consistent with beneficiaries' best interests,
consistent with section 1902(a)(8) and (a)(19) of the Act. A
significant portion of Medicaid beneficiaries experience coverage
changes and churn in a given year.\66\ Therefore, exchanging this
information with a beneficiary's next payer could also better support
care continuity for Medicaid beneficiaries. If states were to share
information about Medicaid beneficiaries or former beneficiaries with
their concurrent and next payers, they could support opportunities for
improved care coordination for Medicaid beneficiaries and former
beneficiaries. Exchanging information about Medicaid beneficiaries and
former beneficiaries between payers might also reduce the amount of
time needed to evaluate beneficiaries' current care plans, their health
risks, and their health conditions at the time they enroll with the
Medicaid program, as well as with another payer. This information
exchange might be of particular value to improve care continuity for
beneficiaries who might churn into and out of Medicaid coverage. The
proposal could also improve the provision of Medicaid services, by
potentially helping to ensure that Medicaid beneficiaries who may
require coordinated services with concurrent payers could be identified
and provided case management services, reduce duplication of services,
and improve the coordination of care, as appropriate.
---------------------------------------------------------------------------

\66\ 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 uses or
disclosures of information that are directly connected with the
administration of the Medicaid state plan. The implementing regulations
for this section of the Act list purposes that CMS has determined are
directly connected to Medicaid state plan administration at 42 CFR
431.302. We believe that requiring the data described in this section
to be shared via the Payer-to-Payer API would be consistent with
states' requirements to provide safeguards to share these data since it
is related to providing services for beneficiaries, a purpose listed in
Sec. 431.302(c). As described above in the section related to
authority under sections 1902(a)(8) and 1902(a)(19) of the Act, states
that share information about Medicaid beneficiaries or former
beneficiaries with their concurrent and next payers, could support
opportunities for improved care coordination, reduction in the amount
of time needed to evaluate beneficiaries' current care plans, their
health risks, and their health conditions at the time they enroll with
the Medicaid program, as well as with another payer. This information
exchange might be of particular value to improve care continuity for
beneficiaries who churn into and out of Medicaid coverage, described in
more detail above. When state Medicaid or CHIP agencies share medical
records or any other health or enrollment information pertaining to
individual beneficiaries, they must comply with 42 CFR 431.306. See
discussion above about how the opt in process proposed for this API
would help states comply with 42 CFR 431.306.
For Medicaid managed care plans, the proposed exchange of all data
classes and data elements included in a content standard adopted at 45
CFR 170.213, adjudicated claims and encounter data, as well as the
patient's prior authorization requests and decisions would greatly
enhance an MCO's, PIHP's, or PAHP's ability to fulfill its obligations
under 42 CFR 438.208(b) which require them to: implement procedures to
deliver care to and coordinate services including ensuring that each
enrollee has an ongoing source of appropriate care; coordinate services
between settings of care, among Medicaid programs, and with community
and social support providers; make a best effort to conduct an initial
screening of each enrollee's needs; and share with the state or other
MCOs, PIHPs, and PAHPs serving the enrollee the results of any
identification and assessment of that enrollee's needs to prevent
duplication of those activities. The data provided via the Payer-to-
Payer API proposed in this rule would give managed care plans the
information needed to perform these required functions much more
easily, thus enhancing the effectiveness of the care coordination, and
helping enrollees receive the most appropriate care in an effective and
timely manner.
For CHIP, we are proposing these requirements under our authority
in section 2101(a) of the Act, which states that the purpose of Title
XXI of the Act is to provide funds to states to provide child health
assistance to uninsured, low-income children in an effective and
efficient manner that is coordinated with other sources of health
benefits coverage. We believe the provisions in this proposed rule
could strengthen our ability to fulfill these statutory

[[Page 76285]]

obligations in a way that recognizes and accommodates using electronic
information exchange in the healthcare industry today and would
facilitate a significant improvement in the delivery of quality
healthcare to our beneficiaries.
As with the Medicaid FFS and Medicaid managed care programs, the
proposals in this section of the proposed rule for CHIP FFS and CHIP
managed care entities, require using a Payer-to-Payer API to exchange
claims, encounter, clinical and prior authorization data at a
beneficiary's request, or any time a beneficiary changes payers, using
a FHIR API. The current payer could use data from the previous payer to
respond to a request for a prior authorization more effectively or
accurately, because under this proposal, a new payer would have
historical claims or clinical data upon which they may review a request
with more background data. Access to information about new patients
could enable appropriate staff within the CHIP program to coordinate
care and conduct care management more effectively because they would
have better data available to make decisions for planning. In many
cases, patients do not remember what services they have had, what
vaccines they have had, or other possibly relevant encounters that
could help payers manage their care. This proposal is consistent with
the goal of providing more informed and effective care coordination,
which could help to ensure that CHIP services are provided in a way
that supports quality care, which aligns with section 2101(a) of the
Act.
Finally, the safeguards for applicant and beneficiary information
at subpart F of 42 CFR part 431 are also applicable to CHIP through a
cross-reference at 42 CFR 457.1110(b). As discussed above for Medicaid,
CHIP agencies' data exchange through the Payer-to-Payer API would be
related to providing services to beneficiaries, which is described at
42 CFR 431.302(c) as a purpose directly related to state plan
administration. We remind states that when they share medical records
or any other health or enrollment information pertaining to individual
beneficiaries, they must comply with the privacy protections at 42 CFR
457.1110 and the release of information provisions at 42 CFR 431.306.
See discussion above about how the opt in process proposed for this API
would help states comply with 42 CFR 431.306.
c. QHP Issuers on the FFEs
For QHP issuers on the FFEs, we are proposing these new
requirements under our authority in section 1311(e)(1)(B) of the
Affordable Care Act, which affords the Exchanges the discretion to
certify QHPs if the Exchange determines that making available such
health plans through the Exchange is in the interests of qualified
individuals in the state in which the Exchange operates.
Requiring QHP issuers on the FFEs to implement and maintain a
Payer-to-Payer API would allow the seamless flow of all data classes
and data elements included in a standard in 45 CFR 170.213, adjudicated
claims and encounter data as well as the patient's prior authorization
requests and decisions, from payer to payer. We believe that ensuring a
means for an enrollee's new issuer to electronically obtain the
enrollee's claims, encounter, and other data, as well as prior
authorization information with corresponding medical records, from the
previous issuer would reduce administrative burden and result in more
timely and efficient care coordination and responses to prior
authorization requests.
We believe it is in the interest of qualified individuals that QHP
issuers on FFEs have systems in place to send information important to
care coordination with departing enrollees, and that QHP issuers on
FFEs also have systems in place to receive such information from payer
to payer on behalf of new and concurrent enrollees, as appropriate and
consistent with the proposals in this section. Therefore, we believe
certifying health plans that make enrollees' health information
available to other payers in a convenient, timely, and portable way is
in the interests of qualified individuals in the state in which an FFE
operates. We encourage SBEs to consider whether a similar requirement
should be applicable to QHP issuers participating in their Exchange.
Though we are not requiring the exchange of all enrollee's data at
one time between issuers, we encourage QHP issuers on the FFEs to use
the Bulk Specification for the Payer-to-Payer API once it is available
as we believe it would improve the efficiency and simplicity of data
transfers between issuers by enabling the exchange of all data for all
patients at once. We believe the opportunity to support an exchange of
large volumes of patient data, rather than data for one patient at a
time, may be cost effective for the issuers. Having patient information
at the beginning of a new plan could assist the new payer in
identifying patients who need care management services, which could
reduce the cost of care. Taking in volumes of data would also enable
the QHPs to perform analysis on the types of new patients in their plan
if they choose to analyze data for existing patients as well.

D. Improving Prior Authorization Processes

1. Background
This section of the proposed rule addresses the topic of prior
authorization and includes both technical and operational proposals
that are intended to improve the prior authorization process for
payers, providers, and patients. Here we propose to require payers to
do the following: implement and maintain an API to support and
streamline the prior authorization process; respond to prior
authorization requests within certain timeframes; provide a clear
reason for prior authorization denials; and publicly report on prior
authorization approvals, denials, and appeals. The proposals in this
rule would build on the foundation set out in the CMS Interoperability
and Patient Access final rule (85 FR 25510) to improve health
information exchange and increase interoperability in the healthcare
system. These proposals were developed based on input from CMS-
sponsored listening sessions and stakeholder meetings which included
payers, providers, vendors, and patients, as well as reports prepared
and released by HHS or its Federal advisory committees, such as the
National Committee on Vital and Health Statistics (NCVHS) and the
Health Information Technology Advisory Committee (HITAC).
The proposals would apply to any formal decision-making process
through which impacted payers render an approval or denial
determination in response to prior authorization requests based on the
payer's coverage guidelines and policies before services are rendered
or items provided. As discussed in section I.A.1., because the
processes and standards for prior authorization applicable to drugs
differ from other items and services, this proposed rule would not
apply to any drugs, meaning any drugs that could be covered by the
impacted payers in this proposed rule. As such, this proposed rule
would not apply to outpatient drugs, drugs that may be prescribed,
those that may be administered by a physician, or that may be
administered in a pharmacy, or hospital. We propose a definition for
this exclusion for each impacted payer in the regulation text of this
proposed rule, and provide a reference to the CFR sections where

[[Page 76286]]

these definitions would be added for MA organizations, Medicaid FFS,
Medicaid Managed Care Plans, CHIP FFS, CHIP Managed Care Entities, and
the QHPs on the FFEs in Table 7. Each definition explains that drugs
excluded from this proposal for prior authorization for items and
service requirements are defined as ``any and all drugs covered by any
of the impacted payers addressed in the proposed rule.''
Also, as mentioned in section I.A, Medicare FFS is not directly
affected by this proposed rule. However, the Medicare FFS program is
evaluating opportunities to improve automation of prior authorization
processes. If our proposals are finalized, Medicare FFS would align its
efforts for implementation of the requirements as feasible. We seek
comment on whether this could be implemented as proposed for the
Medicare FFS program, how we could apply the proposals below, and if
there would be differences for implementing the PARDD API in the
Medicare FFS program as a Federal payer.
We use the term prior authorization to refer to the process by
which a provider must obtain approval from a payer before providing
care in order to receive payment for delivering items or services.
Prior authorization has an important place in the healthcare system,
but the process of obtaining prior authorization can be challenging for
patients, providers, and payers. Stakeholders, including payers and
providers, have claimed that dissimilar payer policies, provider
workflow challenges, inconsistent use of electronic standards, and
other technical barriers have created an environment in which the prior
authorization process is a primary source of burden for both providers
and payers, a major source of burnout for providers, and can become a
health risk for patients if inefficiencies in the process cause care to
be delayed.
HHS has been studying prior authorization processes and their
associated burden for several years to identify the primary issues that
might need to be addressed to alleviate the burdens of these processes
on patients, providers, and payers. For example, to advance the
priorities of the 21st Century Cures Act (Pub. L. 114-255),\67\
specifically to reduce the burden associated with the use of EHR
technology, ONC and CMS created a work group to study prior
authorization and identify opportunities for potential solutions. As
identified by that work group, and in the reports highlighted in this
proposed rule, burdens associated with prior authorization include
difficulty determining payer-specific requirements for items and
services that require prior authorization; inefficient use of provider
and staff time processing prior authorization requests and information
(sending and receiving) through fax, telephone, and web portals; and
unpredictable wait times to receive payer decisions. The ONC report
``Strategy on Reducing Regulatory and Administrative Burden Relating to
the Use of Health IT and EHRs'' fulfills the statutory requirements of
section 4001 of the 21st Century Cures Act. Page eight of this report
summarized the challenge with the following statement: ``Payers and
health IT developers have generally addressed prior authorization in an
ad hoc manner, implementing unique interfaces to facilitate
documentation and sharing of information that reflect their own
technology considerations, lines of business, and customer-specific
constraints.'' \68\
---------------------------------------------------------------------------

\67\ Office of the National Coordinator (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.
\68\ Office of the National Coordinator (2020). Strategy on
Reducing Regulatory and Administrative Burden Relating to the Use of
Health IT and EHRs. Retrieved from https://www.healthit.gov/sites/default/files/page/2020-02/BurdenReport_0.pdf.
---------------------------------------------------------------------------

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

\69\ American Medical Association (2021). AMA Prior
Authorization (PA) Physician Survey Results. Retrieved from https://www.ama-assn.org/system/files/prior-authorization-survey.pdf.
\70\ American Medical Association (2021). Measuring Progress in
Improving Prior Authorization. Retrieved from https://www.ama-assn.org/system/files/2021-05/prior-authorization-reform-progress-update.pdf.
---------------------------------------------------------------------------

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

\71\ American Hospital Association (2019). RE: Health Plan Prior
Authorization. Retrieved from https://www.aha.org/system/files/media/file/2019/11/aha-to-cms-health-plan-prior-authorization-11-4-19.pdf.
---------------------------------------------------------------------------

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

[[Page 76287]]

to determine whether prior authorization requirements exist for a given
patient, diagnosis, insurance plan, or state.'' \72\
---------------------------------------------------------------------------

\72\ Office of the National Coordinator (2020). Strategy on
Reducing Regulatory and Administrative Burden Relating to the Use of
Health IT and EHRs. Retrieved from https://www.healthit.gov/sites/default/files/page/2020-02/BurdenReport_0.pdf.
---------------------------------------------------------------------------

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

\73\ Office of the National Coordinator (2022). Health
Information Technology Advisory Committee (HITAC). Retrieved from
https://www.healthit.gov/topic/federal-advisory-committees/health-information-technology-advisory-committee-hitac-history.
\74\ National Committee on Vital and Health Statistics (2022).
Charter. Retrieved from https://ncvhs.hhs.gov/about/charter/.
\75\ National Committee on Vital and Health Statistics (2019).
Committee Proceedings [Transcript]. Retrieved from https://ncvhs.hhs.gov/wp-content/uploads/2019/12/Transcript-Full-Committee-Meeting-November-13-2019.pdf.
\76\ America's Health Insurance Plans (2020). New Fast PATH
Initiative Aims to Improve Prior Authorization for Patients and
Doctors. Retrieved from https://www.ahip.org/news/press-releases/new-fast-path-initiative-aims-to-improve-prior-authorization-for-patients-and-doctors.
\77\ America's Health Insurance Plans (2021). Reduced Burden and
Faster Decision Times Among Benefits of Implementing Electronic
Prior Authorization. Retrieved from https://www.ahip.org/wp-content/uploads/202103-AHIP_FastPATH-2pg-v03.pdf.
---------------------------------------------------------------------------

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

\78\ Office of the National Coordinator (2022). Intersection of
Clinical and Administrative Data Task Force. Retrieved from https://www.healthit.gov/hitac/committees/intersection-clinical-and-administrative-data-task-force.
\79\ Health Information Technology Advisory Committee (2020). A
Path Toward Further Clinical and Administrative Data Integration.
Retrieved from https://www.healthit.gov/sites/default/files/page/2020-11/2020-11-17_ICAD_TF_FINAL_Report_HITAC.pdf.
---------------------------------------------------------------------------

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

\80\ Id. at pages 31-33.
---------------------------------------------------------------------------

The HITAC and NCVHS Federal advisory committee reports, as
previously mentioned, describe the need for process improvements for
prior authorization, which echo the input CMS received from its payer
and provider stakeholder meetings and industry surveys. We believe our
proposals, if finalized as proposed, would make meaningful progress to
improve prior authorization processes, alleviate burdens, facilitate
more equitable access to care, and support efficient operations for
providers and payers.
As discussed in section I.A. of this proposed rule, in December
2020, CMS published the December 2020 CMS Interoperability proposed
rule, in which we made proposals to streamline the prior authorization
process. In general, payers and providers supported the intent of the
proposed rule, however, they also requested that CMS include the
Medicare Advantage program as an impacted payer and evaluate the
implementation dates for the APIs. As stated in section I.A., we are
withdrawing the December 2020 CMS Interoperability proposed rule and
issuing this new proposed rule that incorporates the feedback we
received from stakeholders. We understand that many readers may already
be familiar with that proposed rule, and to distinguish the differences
between the proposals, we refer readers to the discussion in section
I.A. which outlines the overarching differences between this proposed
rule and the prior proposed rule.
There are additional differences specific to proposals in this
section. First, we have modified the name and description of the
standards-based APIs intended to support prior authorization processes
but have not changed the purpose of those APIs. In this proposed rule,
we refer to two of the previously proposed APIs collectively as the
Prior Authorization Requirements, Documentation, and Decision (PARDD)
API. In the December 2020 CMS Interoperability proposed rule, we

[[Page 76288]]

referred to these two APIs separately, calling them the Document
Requirement Lookup Service (DRLS) API and the Prior Authorization
Support (PAS) API. The proposed PARDD API functionality combines the
functionality of the previously proposed DRLS and PAS APIs. Second, we
are proposing to change the implementation date for many of the
proposals in this section to January 1, 2026. We note that some of the
Medicaid FFS fair hearings and notice proposals discussed in section
II.D.6.b. would take effect before that date if this proposed rule were
finalized as proposed.
2. Electronic Options for Prior Authorization
While there is a standard available for electronic prior
authorization transactions, adopted by HHS under the provisions of the
Health Insurance Portability and Accountability Act of 1996 (HIPAA),
many payers and providers do not use this adopted standard (the X12 278
Version 5010). Instead, payers build proprietary interfaces and web
portals through which providers submit their requests, and both still
frequently resort to phone calls or faxes to complete the process for a
response. The process may remain inefficient, burdensome, and create
service issues for patients. As previously explained, providers
indicate that the main hurdle is knowing which services require prior
authorization, and what documentation is necessary to support that
service or item. The current processes or standard do not address this
barrier.
In section II.B.2. of this proposed rule, we reference the
transactions for which the Secretary must adopt standards for use by
HIPAA-covered entities (for example, health plans, health care
clearinghouses, and certain health care providers), and list the
transactions for which a standard must be adopted. The HIPAA-adopted
standards for referral certifications and authorizations, also referred
to as the prior authorization transaction standards (45 CFR 162.1302),
are the--
National Council for Prescription Drug Programs (NCPDP)
Telecommunication Standard Implementation Guide Version D.0 for retail
pharmacy drugs; and
ASC X12 Version 5010x217 278 (X12 278) for dental,
professional, and institutional requests for review and response.
While the prior authorization proposals in this proposed rule do
not apply to any drugs, we reference the NCPDP standard for retail
pharmacy transactions to acknowledge it as one of the two mandated
standards for prior authorization adopted under HIPAA. The X12 278
standard was adopted for the prior authorization of medical items and
services. Though payers are required to use the X12 278 version 5010
standard for electronic prior authorization transactions and providers
are encouraged to conduct the transaction electronically, the X12 278
has not achieved a high adoption rate by covered entities. The Council
for Affordable and Quality Health Care (CAQH) releases an annual
report, the CAQH Index, which includes data on health plan and provider
adoption of HIPAA standard transactions. In the 2019 report, among the
seven transactions benchmarked, prior authorization using the X12 278
standard was the least likely to be supported by payers, practice
management systems, vendors, and clearinghouse services.\81\ According
to that year's report, 13 percent of the respondents indicated that
they were using the adopted standard in a fully electronic way, while
54 percent responded that they were conducting electronic prior
authorization using web portals, Integrated Voice Response (IVR), and
other options, and 33 percent were using fully manual processes such as
phone, mail, fax, and email. The 2021 report \82\ showed an incremental
increase in the use of the X12 278 prior authorization standard of 26
percent. The report stated that the overall volume remained stable, but
the volume of transactions conducted using the HIPAA mandated standard
for prior authorizations increased, possibly due to payer portal
enhancements and provider interest in moving to electronic submissions
for prior authorization requests. According to the CAQH Index, reported
barriers to using the HIPAA standard include ``lack of vendor support
for provider systems, inconsistent use of data content from the
transaction, and lack of an attachment standard to submit required
medical documentation.''
---------------------------------------------------------------------------

\81\ CAQH (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.
\82\ CAQH (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.
---------------------------------------------------------------------------

Enhancements to the electronic prior authorization process could
support greater use of the HIPAA X12 278 standard through automation,
which could also reduce the time for submission of the request and
response. In the following discussion, we propose to require impacted
payers to implement an HL7 FHIR API that would work in combination with
the adopted HIPAA transaction standard to conduct the prior
authorization process. It is important to note that we are not
proposing changes to the requirement for covered entities to use the
adopted HIPAA transaction standard but are proposing to require that
impacted payers develop and implement an API that works together with
that standard, and may support greater use of the X12 278 standard.
As previously noted, section 1104 of the Affordable Care Act
amended HIPAA to also require that HHS adopt operating rules for the
HIPAA standard transactions. ``Operating rules'' are defined at 45 CFR
162.103 as the ``necessary business rules and guidelines for the
electronic exchange of information that are not defined by a standard
or its implementation specifications as adopted for purposes of HIPAA
Administrative Simplification.'' The NCVHS reviews potential HIPAA
operating rules and advises the Secretary as to whether HHS should
adopt them (section 1173(g) of the Act). The Secretary adopts operating
rules through regulation in accordance with section 1173(g)(4) of the
Act. To date, HHS has adopted operating rules for three of the HIPAA
standard transactions: eligibility for a health plan and health care
claim status (76 FR 40457), health care Electronic Funds Transfer
(EFT), and remittance advice (77 FR 48007). In February 2020, CAQH,
which develops operating rules for some of the HIPAA standards,
submitted two operating rules for NCVHS review regarding HIPAA referral
certification and authorization transaction. NCVHS held a hearing to
discuss those operating rules in August 2020 and submitted a letter to
the HHS Secretary in November 2020 recommending pilot testing to
evaluate the proposed operating rules rather than immediate adoption.
At this time, NCVHS has not recommended that HHS adopt operating rules
for the HIPAA referral certification and authorization transaction.
Should NCVHS make such a recommendation, we would evaluate the effect,
if any, on the policies included in this proposed rule. Even if this
rule is finalized as proposed we would continue to evaluate the impact
of an NCVHS recommendation and any separate actions by HHS in that
regard.

[[Page 76289]]

In March 2021, HHS approved an application \83\ from an industry
group of payers, providers, and vendors for an exception under 45 CFR
162.940 from the HIPAA transaction standards. The approved exception
allows testing of proposed modifications to HIPAA requirements--
specifically for the prior authorization standard. Under this
exception, the group would test a prior authorization exchange using
the HL7 FHIR standard without the X12 278 standard, to determine
whether this alternative standard for prior authorization could improve
efficiency. HHS provides information about requests for exceptions from
standards to permit testing of proposed modifications on the CMS HIPAA
administrative simplification website.\84\ We note that our proposals
in the following discussion are intended to work together with the
adopted X12 278 standard.
---------------------------------------------------------------------------

\83\ Da Vinci Project (2021). Da Vinci HIPAA Exception.
Retrieved from https://confluence.hl7.org/display/DVP/Da+Vinci+HIPAA+Exception.
\84\ Centers for Medicare & Medicaid Services (2022). Go-to-
Guidance, Guidance Letters. Retrieved from https://www.cms.gov/Regulations-and-Guidance/Administrative-Simplification/Subregulatory-Guidance/Go-to-Guidance-Guidance-Letters.
---------------------------------------------------------------------------

3. Proposed Requirement for Payers: Implement an API for Prior
Authorization Requirements, Documentation, and Decision (PARDD API)
a. Prior Authorization Requirements, Documentation, and Decision
(PARDD) API
To help address prior authorization process challenges and continue
following our roadmap to interoperability, we propose to require that,
beginning January 1, 2026, certain payers implement and maintain a FHIR
Prior Authorization Requirements, Documentation, and Decision (PARDD)
API to be used by providers to facilitate the prior authorization
process.
We note that in section II.A.2.a., we are proposing that payers
make information about prior authorization decisions available to
patients through the Patient Access API to help them be more informed
decision makers and partners in their healthcare. The proposals in this
section are specific to improving the prior authorization process
between payers and providers using the PARDD API. These policies taken
together help to facilitate a more streamlined and better-informed
healthcare team in which patients, providers, and payers have access to
the status of prior authorizations.
The PARDD API would streamline the prior authorization process for
the provider or office staff by automating certain tasks, thereby
mitigating some of the obstacles of the existing prior authorization
process. The API would allow a provider to query the payer's system to
determine whether a prior authorization was required for certain items
and services and identify documentation requirements. The API would
also automate the compilation of necessary data for populating the
HIPAA-compliant prior authorization transaction and enable payers to
provide the status of the prior authorization request, including
whether the request has been approved or denied. Covered entities would
continue to send and receive the HIPAA-compliant prior authorization
transactions while using the FHIR PARDD API. In the following
discussion, we propose to require certain standards and recommend
several others that would support the build of this API, while
maintaining compliance with the mandated HIPAA standard for prior
authorization.
To implement the API, we propose to require the use of certain IGs
adopted at 45 CFR 170.215. We also propose that impacted payers would
use the same documentation requirements and the same discontinuation
and denial of access requirements as we are proposing for the Patient
Access API (discussed in section II.A.2), the Provider Access API
(section II.B.2), and the Payer-to-Payer API (section II.C.3). We
believe that consistency in applying these requirements to all proposed
APIs would minimize the cost and burden of implementation and support
payer risk mitigation strategies. Should this proposal be finalized as
proposed, we would also recommend using certain HL7 FHIR Da Vinci IGs
which have been developed specifically to support the functionality of
the PARDD API. These include:
The HL7 FHIR Da Vinci Coverage Requirements Discovery
(CRD) Implementation Guide.
The HL7 FHIR Da Vinci Documentation Templates and Rules
(DTR) Implementation Guide.
The HL7 FHIR Da Vinci Prior Authorization Support (PAS)
Implementation Guide.
The CRD IG provides information about whether an authorization is
required for certain items or services and provides transparency into
the payers' prior authorization coverage rules, so the provider knows
what information is necessary to support a request. The DTR IG provides
the means to ensure the completion of documentation needed to
demonstrate medical necessity for a proposed item or service, based on
payer requirements.
The PAS IG uses the FHIR standard as the basis for (1) assembling
the information necessary to substantiate the clinical need for a
particular treatment, and (2) submitting the assembled information and
prior authorization request to an intermediary before it is sent to the
intended recipient. Under the workflow specified in the PAS IG, to meet
regulatory requirements for the HIPAA standard transactions discussed
previously, the FHIR interface communicates with an intermediary (for
example, a clearinghouse) that converts the FHIR requests to a HIPAA-
compliant X12 278 request transaction for submission to the payer. In
some cases, the payer may act as the intermediary or clearinghouse and
convert the request to a HIPAA-compliant X12 278 transaction. Under the
workflow specified in the PAS IG, the response from the payer would
then flow back through the intermediary using X12 278 and would be made
available to the provider's health IT system using the FHIR standard.
The response would indicate whether the payer approves (and for how
long), or denies (and the reason), the prior authorization request, or
request more information from the provider to support the prior
authorization request. This IG also defines capabilities around the
management of prior authorization requests, including checking on the
status of a previously submitted request, revising a previously
submitted request, and canceling a request. The goal is to provide
information about prior authorization, where possible, in the
provider's clinical workflow. We refer to section II.F. of this
proposed rule for further discussion of the required and recommended
standards to support the PARDD API.
To reiterate, for the reasons explained in section I.A., we are not
proposing to apply the proposals for the PARDD API to any drugs.
Based on a review of Medicare FFS policies and prior authorization
requirements, as well as industry pilots and demonstrations, we
understand payers may have hundreds of policies that could be included
in the PARDD API. The initial phase of identifying and evaluating all
the policies may be a significant effort. We also recognize that payers
would need to evaluate their prior authorization policies for each plan
type, analyze coverage requirements, and program those requirements for
the PARDD API. We acknowledge that such efforts would require staff
time for evaluation, development, and testing of the API

[[Page 76290]]

functionality. To maximize early understanding of how they could
implement the recommended IGs for the PARDD API and operationalize
these new processes, we encourage stakeholders to participate in the
HL7 workgroups as they further refine the IGs that support prior
authorization. Information about these and other workgroups may be
found on the HL7 website at https://www.HL7.org.
Given the effort that would be required to implement the PARDD API,
we considered proposing that the API be implemented in a phased
approach. Specifically, we considered and are seeking comment on
whether to require payers to make prior authorization rules and
documentation requirements available through the API incrementally,
beginning January 1, 2026. In this alternative, Medicaid managed care
plans and CHIP managed care entities would be required to comply with
the approach described (in this section of this document) by the rating
period beginning on or after January 1, 2026, and QHP issuers on the
FFEs for plan years beginning on or after January 1, 2026.
Under the proposal we considered, in the first phase, impacted
payers would have been required to make 25 percent of their prior
authorization rules and documentation requirements available through
the API, prioritized by the highest number of requested items and
services. We would have proposed that the first phase begin by January
1, 2026. The second phase would have required impacted payers to make
available at least 50 percent of their prior authorization rules and
documentation requirements, prioritized by the highest number of
requested items and services. We would have proposed that this phase
begin by January 1, 2027. Finally, beginning January 1, 2028, impacted
payers would have been required to make available 100 percent of their
prior authorization rules and documentation requirements through the
API. Though this alternative approach could have provided additional
time for payers to test their implementations and assess the benefits
with providers, there was also a potential risk that a phased approach
could have added complexity to the process for providers, rather than
improving efficiency and reducing burden. If each payer's highest
volume of requirements is unique, provider staff could have been
required to spend considerable time alternating between the API and
prior methods of researching prior authorization requirements. We opted
against proposing this lengthy phased-in option because of the
challenges we believe it could have created for providers continuing to
navigate different implementation of payer rules. However, we request
comments on this phased-in approach, our assumptions, and other
potential options for an implementation strategy. For example, we
request comment on whether payers would need a phased-in implementation
to codify their rules and ensure that they are in a structured format
(for example, quantifiable and machine-readable) for purposes of the
API. If an alternative approach of this type were to be considered, how
could CMS structure such an implementation strategy and timeframe
without introducing additional burden? What are the operational and
technical challenges involved in converting prior authorization rules
into structured, machine-readable documents? Do payers have estimates
of the amount of time that would be required for converting the most
frequently requested prior authorizations into structured documents?
For purposes of this proposed rule, rather than pursue a phased
implementation process to maximize the benefits of electronic prior
authorization, we propose that payers would be required to implement
the PARDD API for all prior authorization rules and requirements for
items and services, excluding drugs, by January 1, 2026 (for Medicaid
managed care plans and CHIP managed care entities, by the rating period
beginning on or after January 1, 2026, and for QHP issuers on the FFEs,
for plan years beginning on or after January 1, 2026). We do not
believe it necessary to propose a phased implementation strategy
because we are not certain such an approach would reduce burden on
either impacted payers, or providers, and believe in some cases it
could increase the burden during the initial implementation. For
example, as we previously outlined, for a phased approach, in the first
phase, impacted payers would have been required to make 25 percent of
their prior authorization rules and documentation requirements
available through the API. Because prior authorizations vary by payer,
that could mean that some payers would make one set of items or
services available for prior authorization via the PARDD API, and
another payer would have another set of items and services available.
Providers seeking to utilize the PARDD API would then have conflicting
methods of prior authorization available for different types of items
or services based on each payer's implementation decisions. This could
be confusing, particularly during the initial rollout of a new API such
as this one. We also believe that a phased approach could delay the
availability of electronic prior authorization for certain items and
services, which may in turn reduce the overall adoption of the PARDD
API by providers who do not see their specialties and services
represented in the initial rollout of the available PARDD API for items
and services.
We believe current industry pilots of alternatives for
electronically exchanging prior authorization rules and requirements
for documentation have already successfully demonstrated that payers
may be able to meet the objectives in this proposed rule to improve
prior authorization processes through the proposed API. The HL7
Community Roundtable recordings provide examples of these industry
pilots and implementation of the HL7 IGs.\85\ This list is not
exhaustive and other organizations may have additional examples.
Industry would have additional implementations in place and sufficient
experience with both required and proposed IGs to be able to implement
the proposals by the proposed compliance dates on or after January 1,
2026.
---------------------------------------------------------------------------

\85\ Da Vinci Project (2022). Da Vinci 2022--Calendar. Retrieved
from https://confluence.hl7.org/display/DVP/Da+Vinci+2022+-+Calendar.
---------------------------------------------------------------------------

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

[[Page 76291]]

options available for providers and patients to obtain prior
authorization information and whether payers should increase education
about these resources.
This PARDD API proposal could help both payers and providers
mitigate some of the burdens of the prior authorization process and
streamline the overall process. Payers that implement and maintain the
proposed PARDD API might experience process improvements, fewer
unnecessary requests or follow-up inquiries, and a decrease in denials
or appeals. Such improvements could contribute to burden reduction for
providers by reducing manual tasks and decreasing the volume of denials
or appeals made.
We acknowledge that the new functionality of the API may require
changes to the payer's customer service operations and procedures for
providing support to patients during and after implementation. There
may be questions about the required documentation, authorizations or
denials about which both staff members and patients may need additional
training and resources. We encourage payers to evaluate the procedural
and operational changes as part of their implementation strategy, and
to make appropriate resources available when the API is launched. While
there are a number of resources available to ensure that patients
receive quality services when accessing new technologies in health
care, we invite feedback from commenters about available resources,
such as the recent White House Blueprint for an AI Bill of Rights \86\
and others.
---------------------------------------------------------------------------

\86\ The White House (2022). Blueprint for an AI Bill of Rights.
Retrieved from https://www.whitehouse.gov/ostp/ai-bill-of-rights/.
---------------------------------------------------------------------------

Finally, the anticipated benefits of the PARDD API are in part
contingent upon providers using health IT products that can interact
with payers' APIs. In section II.E. of this proposed rule, we propose a
new measure for the MIPS Promoting Interoperability performance
category for MIPS eligible clinicians and the Medicare Promoting
Interoperability Program for eligible hospitals and CAHs that would
require healthcare providers to request a prior authorization
electronically using data from certified electronic health record
technology (CEHRT) using a payer's PARDD API. We request comment on
additional steps CMS could take to encourage providers and health IT
developers to adopt the technology necessary to access payers' PARDD
APIs. In addition, we note that on January 24, 2022, ONC published an
RFI titled ``Electronic Prior Authorization Standards, Implementation
Specifications, and Certification Criteria'' (87 FR 3475) requesting
comment on how updates to the ONC Health IT Certification Program could
support electronic prior authorization. We continue to work with ONC on
ways to facilitate the adoption of standards to streamline data
exchange, support interoperability, and increase efficiencies.
In summary, we propose that, beginning January 1, 2026 (for
Medicaid managed care plans and CHIP managed care entities, by the
rating period beginning on or after January 1, 2026, and for QHP
issuers on the FFEs, for plan years beginning on or after January 1,
2026), these impacted payers would be required to implement and
maintain a FHIR PARDD API using technology conformant with certain
standards and implementation specifications in 45 CFR 170.215. We
propose to require that the PARDD API be populated with the payer's
list of covered items and services, excluding drugs, for which prior
authorization is required and accompanied by any documentation
requirements. We further propose that the PARDD API would be required
to include functionality to determine requirements for any other data,
forms, or medical record documentation required by the payer for the
items or services for which the provider is seeking prior authorization
and while maintaining compliance with the HIPAA standard. Finally, the
PARDD API responses from the payer to the provider would be required to
include information regarding payer approval (and for how long) or
denial (with a specific reason) of the request, or request more
information from the provider to support the prior authorization
request (see discussion in section II.D.4.a.). We are proposing these
requirements for the proposed PARDD API at the CFR sections identified
in Table 7.
We request comment on the proposal to require implementation of a
Prior Authorization Requirements, Documentation, and Decision API.
b. Federal Funding for State Medicaid and CHIP Expenditures on
Implementation of the PARDD API
Should our proposals be finalized as proposed, states operating
Medicaid and CHIP programs may be able to access Federal matching funds
to support their implementation of the proposed PARDD API. This
proposed API is expected to lead to more efficient administration of
Medicaid and CHIP state plans by supporting a more efficient prior
authorization process, consistent with sections 1902(a)(4) and 2101(a)
of the Act.
We would not consider state expenditures for implementing this
proposal to be attributable to any covered Medicaid item or service
within the definition of ``medical assistance.'' Thus, in Medicaid, CMS
would not match these expenditures at the state's regular Federal
medical assistance percentage (FMAP). However, Federal financial
participation (FFP) under section 1903(a)(7) of the Act, at a rate of
50 percent, for the proper and efficient administration of the Medicaid
state plan, might be available for state expenditures related to
implementing this proposal for their Medicaid programs. We believe that
using the PARDD API would help the state more efficiently administer
its Medicaid program by increasing the efficiencies in the prior
authorization process. For instance, using the PARDD API would enable
administrative efficiencies by improving accuracy, and by helping
reduce the number of denied and appealed prior authorization decisions.
States' expenditures to implement these proposed requirements could
also be eligible for 90 percent enhanced FFP under section
1903(a)(3)(A)(i) of the Act, if the expenditures can be attributed to
the design, development, or installation of mechanized claims
processing and information retrieval systems. Additionally, 75 percent
enhanced FFP, under section 1903(a)(3)(B) of the Act, could be
available for state expenditures to operate Medicaid mechanized claims
processing and information retrieval systems to comply with this
proposed requirement.
States can request Medicaid enhanced FFP under section
1903(a)(3)(A)(i) or (B) of the Act through the APD process described in
45 CFR part 95, subpart F. States are reminded that 42 CFR
433.112(b)(12) and 433.116(c) in part require that any system for which
they are receiving enhanced FFP under section 1903(a)(3)(A)(i) or (B)
of the Act align with and incorporate the ONC Health Information
Technology standards adopted in 45 CFR part 170, subpart B. The PARDD
API would complement this requirement because this API would further
interoperability by using standards adopted by ONC at 45 CFR
170.215.\87\ States are also reminded that 42 CFR 433.112(b)(10) and
433.116(c) explicitly support

[[Page 76292]]

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

\87\ Centers for Medicare & 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.
---------------------------------------------------------------------------

Similarly, 42 CFR 433.112(b)(13) and 433.116(c) require the states
to promote sharing, leverage, and re-use of Medicaid technologies and
systems as a condition of receiving enhanced FFP under section
1903(a)(3)(A)(i) or (B) of the Act. CMS interprets that requirement to
apply to technical documentation associated with a technology or
system, such as technical documentation for connecting to a state's
APIs. Making the needed technical documentation publicly available so
that systems that need to can connect to the APIs proposed in this rule
would be required as part of the technical requirements at 42 CFR
431.60(d) for all proposed APIs in this rule, including the PARDD API.
Separately, for CHIP agencies, section 2105(c)(2)(A) of the Act and
42 CFR 457.618, limiting administrative costs to no more than 10
percent of a state's total computable expenditures for a fiscal year,
would apply to administrative claims for developing the APIs proposed
in this rule.
We note that the temporary Medicaid FMAP increase available under
section 6008 of the Families First Coronavirus Response Act (Pub. L.
116-127) does not apply to administrative expenditures.
c. Medicaid Expansion CHIP Programs
Most states have Medicaid Expansion CHIP programs, in which a state
receives Federal funding to expand Medicaid eligibility to optional
targeted low-income children that meet the requirements of section 2103
of the Social Security Act. We are proposing at 42 CFR 457.700(c) that
for states with Medicaid Expansion CHIP programs, the proposals in this
rule for Medicaid would apply to those programs rather than our
proposals for a separate CHIP program. Functionally, our proposals are
the same; however, for clarity, we are making explicit that the
Medicaid requirements at Sec. Sec. 431.60, 431.61, and 431.80 would
apply to those programs rather than the separate CHIP requirements at
Sec. Sec. 457.730, 457.731, and 457.732.
4. Requirement for Payers To Provide Status of Prior Authorization and
Reason for Denial of Prior Authorizations
a. Reason for Denial of Prior Authorization
Based on the stakeholder input described in this proposed rule, we
believe the prior authorization process could be improved through
better communication between payers and providers. One of the
opportunities for better communication is timely and specific
information about the reason for denying a prior authorization. Payers
deny prior authorizations for different reasons. For example, a payer
might deny a prior authorization because the payer does not consider
the items or services to be medically necessary, the patient may have
exceeded limits on allowable covered care for a given type of item or
service, or documentation to support the request was missing or
inadequate. Providing an understandable reason for a denial could allow
a provider to take appropriate actions such as re-submitting the
request with updated information, identifying alternatives for the
patient, appealing the decision, or communicating the decision to the
patient. As noted in the 2021 AMA provider survey, 83 percent of
providers report that prior authorization process issues lead to
treatment abandonment, while 93 percent reported that process issues
led to delays in care.\88\ Timely and clear information from payers
about the status of a prior authorization or the reason(s) for denial
could help mitigate these challenges and provide necessary information
for submitting additional documentation or arranging for alternative
treatment.
---------------------------------------------------------------------------

\88\ American Medical Association (2021). AMA Prior
Authorization (PA) Physician Survey Results. Retrieved from https://www.ama-assn.org/system/files/prior-authorization-survey.pdf.
---------------------------------------------------------------------------

Impacted payers currently have the capability to send information
to providers about the reason a prior authorization request has been
denied either electronically or through other communication methods.
For denials sent using the X12 278 standard, payers must use the codes
from the designated X12 code list. For responses sent through portals,
via fax or other means, payers may use proprietary codes or text to
provide denial reasons. Consistent use of both technology and
terminology (codes) to communicate denial information could mitigate
some of the operational inefficiencies for providers so that they could
more consistently interpret and react to a denied prior authorization
request. This proposal to send a specific denial reason is one approach
to address current inefficiencies.
Specifically, we propose that, beginning January 1, 2026 (for
Medicaid managed care plans and CHIP managed care entities, by the
rating period beginning on or after January 1, 2026, and for QHP
issuers on the FFEs, for plan years beginning on or after January 1,
2026), impacted payers would be required to provide a specific reason
for denied prior authorization decisions, excluding prior authorization
decisions for drugs, regardless of the method used to send the prior
authorization request. As stated under the proposal for the PARDD API,
we are also proposing that responses about a prior authorization
decision sent through the PARDD API from the payer to the provider
would have to include information regarding whether the payer approves
(and for how long) or denies the prior authorization request, or
requests more information from the provider to support the request. We
are proposing these requirements regarding prior authorization
decisions for MA organizations, state Medicaid and CHIP FFS programs,
Medicaid managed care plans, CHIP managed care entities, and QHP
issuers on the FFEs at the CFR sections identified in Table 7.
Some payers that would be subject to this proposal are also subject
to existing requirements to provide notice to patients or providers, or
both, with the specific reasons for denial, and this proposal builds on
those existing policies.
b. Existing Program-Specific Notice Requirements for Prior
Authorization Denial Information
Some payers that would be affected by this proposed rule are
required by existing Federal and state laws and regulations to notify
providers and patients when an adverse decision is made about a prior
authorization request. As previously discussed, our proposals to impose
requirements on payers to communicate certain information to providers
about prior authorization requests are intended to reinforce these
existing Federal and state requirements. Our proposals would not alter
or replace existing requirements to provide notice to patients,
providers, or both. The proposed requirement to use the PARDD API to
compile necessary data and populate the X12 278 transaction response to
the provider, including whether an authorization request has been
approved (and for how long), denied, with a reason for the denial, or

[[Page 76293]]

request more information from the provider to support the prior
authorization request, would support current Federal and state notice
requirements for certain impacted payers. Clearly communicating denial
reasons, in addition to the existing program notification requirements,
could increase transparency, reduce burden, and improve efficiencies
for both payers and providers.
This section of this proposed rule addresses additional denial
notice requirements for certain impacted payers in the MA program, as
well as Medicaid, and includes information on existing Medicaid
beneficiary notice and fair hearing regulations in the context of prior
authorization decisions in section II.D.6.b.
For Medicaid managed care plans and CHIP managed care entities,\89\
existing regulations at 42 CFR 438.210(c) require notice to the
provider without specifying the format or method, while 42 CFR
438.210(c) and 438.404(a) require written notice to the enrollee of an
adverse benefit determination. Nothing in this proposed rule would
affect existing enrollee notification requirements in 42 CFR part 438
for Medicaid managed care plans and in 42 CFR part 457 for CHIP managed
care entities as these requirements would remain in full effect. This
proposed rule would fill a potential gap with respect to the
information communicated to providers regarding a denial of a prior
authorization request. We propose that the response--whether the
authorization request has been approved (and for how long), denied
(with the reason for the denial), or a request for more information to
support the prior authorization--if transmitted to providers via the
PARDD API workflow process or other means, would be sufficient to
satisfy the current requirement for notice to providers at 42 CFR
438.210(c). Under our proposal the payer would not be required to send
the response via both the PARDD API process, which includes the denial
reason, and a separate, additional notice in another manner with
duplicate information.
---------------------------------------------------------------------------

\89\ See 42 CFR 457.1230(d) and 457.1260(c).
---------------------------------------------------------------------------

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

\90\ See 42 CFR 457.1230(d) and 457.1260(c).
---------------------------------------------------------------------------

Under the MA program, the actions that constitute an ``organization
determination'' at 42 CFR 422.566(b) include a prior authorization (or
``pre-service'') decision, as paragraph (b)(3) refers to an MA
organization's refusal to provide or pay for services, in whole or in
part, including the type or level of services, that the enrollee
believes should be furnished or arranged by the MA organization. Under
existing Sec. 422.566(b), an organization determination would include
a request for prior authorization using the PARDD API under the
proposed provisions at 42 CFR 422.122. Existing MA program regulations
are specific as to the form and content of the written notice to
enrollees in the event of a partial or full denial. For example,
existing regulations at 42 CFR 422.568(e) regarding written notices for
enrollees for standard organization determinations require that a
notice for any denial for a covered service or item under 42 CFR
422.568(d) must: (1) use approved notice language in a readable and
understandable form; (2) state the specific reasons for the denial; (3)
inform the enrollee of their right to a reconsideration; (4) describe
both the standard and expedited reconsideration processes, including
the enrollee's right to, and conditions for, obtaining an expedited
reconsideration and the rest of the appeal process; and (5) comply with
any other notice requirements specified by CMS. Under the rules at 42
CFR 422.572 related to timeframes and notice requirements for expedited
organization determinations, an MA organization must send a written
denial notice to the enrollee, and physician involved as appropriate,
whenever an MA plan's determination is partially or fully adverse to
the enrollee. The rules at 42 CFR 422.572(a)(1) related to expedited
organization determinations state that an MA organization that approves
a request for expedited determination must make its determination and
notify the enrollee, and the physician involved as appropriate, of its
decision whether adverse or favorable and as expeditiously as the
enrollee's health condition requires, but no later than 72 hours after
receiving the request. Either an enrollee or a physician, regardless of
whether the physician is affiliated with the MA organization, may
request that an MA organization expedite an organization determination.
Given that a physician is often involved in requesting an expedited
organization determination on behalf of an enrollee, the rules related
to notices explicitly require an MA plan to notify the enrollee and the
physician involved, as appropriate, of its decision, whether adverse or
favorable. The content of a notice of expedited determination must
state the specific reasons for the determination in understandable
language and if the determination is not completely favorable to the
enrollee, the notice must also: (1) inform the enrollee of their right
to a reconsideration; (2) describe both the standard and expedited
reconsideration processes, including the enrollee's right to request,
and conditions for obtaining, an expedited reconsideration, and the
rest of the appeal process; and (3) comply with any other requirements
specified by CMS.
Because applicable integrated plans may be either MA plans for
individuals with special needs who are dually eligible for Medicare and
Medicaid, or Medicaid MCOs, the regulations regarding prior
authorization processes that we are proposing for MA plans and Medicaid
managed care plans would apply to applicable integrated plans as well.
Similar rules at 42 CFR 422.631(d) already govern denial notices issued
by applicable integrated plans to their enrollees. Integrated
organization determination notices must be written in plain language,
available in a language and format that is accessible to the enrollee,
and explain: (1) the applicable integrated plan's determination; (2)
the date the determination was made; (3) the date the determination
will take effect; (4) the reasons for the determination; (5) the
enrollee's right to file an integrated reconsideration and the ability
for someone else to file an appeal on the enrollee's behalf; (6)
procedures for exercising an enrollee's rights to an integrated
reconsideration; (7) the circumstances under which expedited resolution
is available and how to request it; and (8) if applicable, the
enrollee's rights to have benefits continue pending the resolution of
the integrated appeal process. As with the notices required from MA
plans, our proposal would not change the content requirements for these
written denial notices to enrollees but would supplement these notices
by requiring applicable integrated plans to notify the provider of the
reason for a denial of a prior authorization request.
QHP issuers on the FFEs that offer individual health insurance must
provide the specific reason for an adverse benefit determination, which

[[Page 76294]]

includes denial of prior authorization.\91\ Furthermore, plans and
issuers must ensure that notice is made to individuals in a culturally
and linguistically appropriate manner that complies with the
requirements of 45 CFR 147.136(b)(2)(ii)(E) and 29 CFR 2560.503-1(g)
and (j).
---------------------------------------------------------------------------

\91\ See 45 CFR 147.136(b)(3)(ii)(E).
---------------------------------------------------------------------------

5. Requirements for Prior Authorization Decision Timeframes and
Communications
a. Impact of Delays in Prior Authorization Decisions: Background and
Overview of Current Decision Timeframes
During the CMS listening sessions and other public meetings, we
heard, largely from providers, that excessive wait time for prior
authorization decisions could cause delays to patient care and may
create medical risks in some cases. In most examples cited, providers
face delays for the approval of the initial request, or, secondarily,
for the resolution of a request ``in process,'' often meaning the payer
is reviewing requested documentation. A 2017 AMA study reported that 39
percent of physicians stated that for those patients whose treatment
requires prior authorization, the process can delay access to care. In
that same study, between 19 and 57 percent of physicians reported that
for those patients whose treatment requires prior authorization, the
process may lead to patients abandoning their recommended course of
treatment.\92\ As described earlier, in 2019, CMS conducted outreach to
external stakeholders, including payers, providers, patients, vendors,
and others, through listening sessions, interviews, observational
visits, RFIs, and a special email box. The goal was to obtain
information about how to improve the transparency, efficiency, and
standardization of the prior authorization process. We received a large
volume of comments about timeframes for processing prior
authorizations, where commenters expressed that the process of securing
approvals for prior authorization directly affects patient care by
delaying access to services, including transfers between hospitals and
post-acute care facilities, treatment, medication, and supplies.
Commenters believed that these delays occur partly because payers have
different policies and review processes, do not use available
technologies consistently, and continue to rely on manual systems such
as phone, fax, and mail, which are more labor-intensive. Some
commenters noted that the large variations in payer prior authorization
policies for the same items and services and the difficulty of
discovering these payer's policies necessitates substantial provider
staff research and time, which contributes to delays in care.
---------------------------------------------------------------------------

\92\ American Medical Association (2018). 2017 AMA Prior
Authorization Physician Survey. Retrieved from https://www.ama-assn.org/sites/ama-assn.org/files/corp/media-browser/public/arc/prior-auth-2017.pdf.
---------------------------------------------------------------------------

In this proposed rule, we use the term ``standard'' prior
authorization to refer to non-expedited, non-urgent requests for prior
authorization and the term ``expedited'' prior authorization to
indicate an urgent request. These terms are used, as described here, in
the provisions in 42 CFR 422.568, 422.570, 422.572, and 422.631 for MA
organizations and applicable integrated plans, and 42 CFR 438.210(d)
for Medicaid managed care plans, and we will use these terms for all
regulated payers to whom the proposed policy in this section applies.
Under existing regulations for standard prior authorization
decisions, MA organizations and applicable integrated plans must make a
decision and send notice of that decision as expeditiously as the
enrollee's condition requires, but may not exceed 14 calendar days
following receipt of the request for an item or service.\93\ Under
certain circumstances, a plan may extend this 14-calendar day timeframe
consistent with the rules at Sec. 422.568(b)(1)(i) or Sec.
422.631(d)(2)(ii). Similarly, for standard prior authorization
decisions, Medicaid managed care plans and CHIP managed care entities
must make a decision and send notice of that decision as expeditiously
as the beneficiary's condition requires within state-established time
frames, but may also not exceed 14 calendar days following receipt of
the request for an item or service.\94\
---------------------------------------------------------------------------

\93\ See 42 CFR 422.568(b)(1), 422.631(d)(2)(i)(B).
\94\ See 42 CFR 422.570, 422.572, 422.631(c) and (d)(2)(iv)(A),
438.210(d)(2), and 457.1230(d).
---------------------------------------------------------------------------

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

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

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

\96\ See 42 CFR 422.568(b)(1)(i), 422.572(b), 422.631(d)(2)(ii),
and 438.210(d)(1) and (2), and through an existing cross reference
at 42 CFR 457.1230(d). MA plans may extend the timeframe if 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. MA plans may also extend the timeframe for a standard or
expedited organization determination if the extension is justified
due to extraordinary, exigent, or other non-routine circumstances
and is in the enrollee's interest.
---------------------------------------------------------------------------

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

\97\ See 42 CFR 457.495(d).
\98\ See 42 CFR 457.495(d)(1).
\99\ See 42 CFR 457.1230(d).

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

[[Page 76295]]

Table 4 provides a summary of current Federal requirements for
prior authorization decision timeframes that apply to the payers that
would be affected by this proposed rule.
BILLING CODE 4120-01-P
[GRAPHIC] [TIFF OMITTED] TP13DE22.003

[[Page 76296]]

[GRAPHIC] [TIFF OMITTED] TP13DE22.004

BILLING CODE 4120-01-C
b. Proposals To Address Timeframes for Decisions on Standard and
Expedited Prior Authorization Requests
Given our interest in improving patient care outcomes, and ensuring
that patients have more timely access to services, we are proposing to
establish, improve, or shorten Federal prior authorization timeframes
for certain payers to respond to requests. We acknowledge that many of
the payers that would be affected by this proposed rule have different
requirements for prior authorization decision notice and appeal
timeframes, and we are proposing to align prior authorization decision
timeframes across these payers.
We are proposing that, beginning January 1, 2026, MA organizations
and applicable integrated plans, Medicaid FFS programs, and CHIP FFS
programs must provide notice of prior authorization decisions as
expeditiously as a patient's health condition requires, but no later
than 7 calendar days for standard requests. We also propose that
Medicaid FFS and CHIP FFS programs must provide notice of prior
authorization decisions as expeditiously as a patient's health
condition requires, but no later than 72 hours for expedited requests
unless a shorter minimum time frame is established under state law.
Assuming these proposals are finalized as proposed, we believe the
7-calendar day timeframe for standard decisions could be achieved when
payers implement their APIs with improved access to documentation
requirements, which could support greater use of electronic prior
authorization, and more efficient business processes once implemented.
For MA organizations, on or after January 1, 2026, items and services
covered by the proposals in 42 CFR 422.122 would be affected by this
proposal if finalized; for all other items and services existing
timeframes would remain applicable.

[[Page 76297]]

Our proposal would not change the 72-hour deadline required by
current Federal regulations, or the authority for an extension of that
deadline, for expedited decisions made by MA organizations, applicable
integrated plans, Medicaid managed care plans, and CHIP managed care
entities. In addition, we do not propose to change existing Federal
timeframes for standard and expedited determinations on requests for
Part B drugs for MA organizations and applicable integrated plans;
current regulations require notice to the enrollee as expeditiously as
the enrollee's health condition requires, but no later than 72 hours
after receiving the request for a standard determination and as
expeditiously as the enrollee's health condition requires, but no later
than 24 hours after receiving an expedited request.\100\ Due to the
revisions we are proposing to Sec. 422.568(b), we propose to
redesignate existing Sec. 422.568(b)(2) related to requests for Part B
drugs for MA organizations to 42 CFR 422.568(b)(3).
---------------------------------------------------------------------------

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

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

\101\ See 42 CFR 438.210(c) and 457.1230(d).
---------------------------------------------------------------------------

We are not proposing to change timeframes for prior authorization
processes for QHPs on the FFEs, in part because existing regulations at
45 CFR 147.136 establish internal claims and appeals processes,
external review processes, and pre-service claims requirements for all
non-grandfathered group and individual market plans or coverage.
Specifically, individual health insurance issuers are required to meet
minimum internal claims and appeals standards.\102\ We believe the
current standard adequately protects patient interests. As summarized
in Table 4, QHPs on the FFEs are required to provide notification of a
plan's benefit determination within 15 days for standard authorization
decisions and within 72 hours for expedited requests. Should this rule
be finalized as proposed, QHPs on the FFEs would have the same
timeframe for expedited authorization decisions as the other CMS payers
affected by this provision: 72 hours. We believe that the benefits for
the patient of a shorter timeframe for standard prior authorization
decisions would outweigh the additional burden that plans on the
Exchanges might experience, as compared to off-Exchange plans. Aligning
timeframe requirements for prior authorization decisions across
individual and group market plans would reduce the burden of compliance
for QHP issuers on the FFEs for the proposed prior authorization
requirements while continuing to protect consumer interests. Finally,
we note that making changes to regulations applicable to all non-
grandfathered group and individual market plans or coverage for
consistency with our proposed approach here would be outside the scope
of this proposed rulemaking.\103\
---------------------------------------------------------------------------

\102\ See 45 CFR 147.136(b)(3).
\103\ We are not proposing in this proposed rule to impose on
individual and group market plans generally timelines for processing
of prior authorizations consistent with those we propose for other
payers, as such requirements would require rulemaking by the
Departments of Labor, the Treasury, and Health and Human Services.
---------------------------------------------------------------------------

We are not proposing to require that impacted payers approve a
request for prior authorization should that payer not meet the required
standard or expedited decision timeframe. If a payer fails to meet the
timeline for approval or other decision, providers should contact the
payer to obtain the status of the request and determine if supporting
documentation is needed to complete processing of the authorization or
if there are other reasons for the delay in a decision. We do not
believe it is practical to require payers to default to an approval for
prior authorization requests for which a timely response has not been
provided. Therefore, impacted payers may choose to evaluate process
improvements to meet the proposed timeframes and API in this proposed
rule, and consider how to efficiently support provider inquiries on
status should responses or timeframes be missed. However, we note that
some programs, such as Medicare Advantage, have regulations which
include provisions for the failure to provide timely notice of an
organization determination, which constitutes an adverse decision that
may be appealed.
We seek comment on what administrative, regulatory, technical,
governance, operational, and workflow solutions would need to be
addressed, for and by payers, to comply with the proposed timeframes
for handling prior authorization review and approval activities. We
also seek comment on what operational or procedural changes payers or
providers would need to make in their workflows or systems to reduce
decision timeframes from 14 days to 7 calendar days (for standard prior
authorization requests) and from 72 hours to 1 day or 24 hours (for
expedited prior authorization requests). Based on comments we received
in response to the December 2020 CMS Interoperability rule (85 FR
82586), many providers wish to see further improvements in the
timeliness of the decision process for prior authorizations. Some
commenters, including payers, believe it is possible, given advances in
technology, that responses to certain types of prior authorization
requests could be made within 24 hours. Some payer and provider
commenters agree that shorter prior authorization decision timeframes
than those in this proposed rule could help to improve patient care,
reduce burden, and improve equity. We wish to learn more about the
process and technology barriers which prevent payers from meeting
shorter timeframes than those in this proposed rule, and request input
on whether MA organizations, applicable integrated plans, Medicaid and
CHIP FFS programs, Medicaid managed care plans, and CHIP managed care
entities might be able to provide notice of standard and expedited
prior authorization decisions within, for example, 5 calendar days and
48 hours, respectively, and if not, what specific issues and obstacles
prevent that.
We believe that as prior authorization processes become more
efficient, shorter timeframes may be possible for certain types of
requests. For example, if early adopters voluntarily implement and test
the proposed PARDD API, and if some impacted payers voluntarily
implement process improvements in methods of provider communication,
automation, and documentation submission requirements, those payers may
be able to accommodate shorter timeframes for certain types of prior
authorization requests. Therefore, we solicit comments on whether
implementation of the PARDD API as described in this proposed rule
could yield process improvements of sufficient magnitude to support
shorter decision timeframe requirements for prior authorization
requests as suggested by many stakeholders, including payers,
providers, vendors, and other interested parties, and described in
reports cited earlier. We also seek comment on anticipated operational
challenges of implementing the API that might affect a payer's ability
to meet the proposed timeframes. Finally, we request comment from the
public regarding the costs, benefits, and operational impact on
providers and payers, as well as the impact on patients, of making and
communicating prior authorization

[[Page 76298]]

decisions on a shorter timeframe than those in this proposed rule.
In summary, to address prior authorization decision timeframes, we
are proposing to require, beginning January 1, 2026, that MA
organizations and applicable integrated plans, Medicaid FFS programs,
and CHIP FFS programs must provide notice of prior authorization
decisions as expeditiously as a beneficiary's health condition requires
(for CHIP FFS, alternatively stated as in accordance with the medical
needs of the patient), but no later than 7 calendar days for standard
requests. We are proposing that Medicaid FFS and CHIP FFS programs must
provide notice of prior authorization decisions as expeditiously as a
beneficiary's health condition requires (for CHIP, alternatively stated
as in accordance with the medical needs of the patient) but no later
than 72 hours for expedited requests unless a shorter minimum time
frame is established under state law. We are proposing to require that
the same maximum timeframes apply to standard authorization decisions
by Medicaid managed care plans and CHIP managed care entities beginning
with the rating period that starts on or after January 1, 2026. Because
Medicaid managed care plans at 42 CFR 438.210(d)(2) and CHIP managed
care entities at Sec. 457.1260(c)(3) respectively must already make an
expedited authorization decision and provide notice as expeditiously as
the beneficiary's health condition requires but no later than 72 hours
after receipt of the request for service, we are not proposing to
change those specific timeframes. However, for consistency with
Medicaid FFS, we propose to add ``unless a shorter minimum time frame
is established under State law'' to 42 CFR 438.210(d)(2).
We are proposing to amend 42 CFR 438.210(d)(2)(i) to clarify that
the MCO, PIHP, or PAHP must make these decisions on shorter timeframes
if required by the state. These proposals for the impacted payers in
this proposed rule are being made at the CFR sections identified in
Table 7.
If state law imposes a shorter timeframe for these decisions, that
shorter time frame would govern for Medicaid FFS, CHIP FFS, Medicaid
managed care plans, and CHIP managed care entities. If our proposed
regulation is finalized as proposed, and state law imposes a longer
time frame, payers could comply with both the Federal and state
regulations by complying with the shorter Federal time frame. State
laws would not apply to MA plans, based on preemption language at 42
CFR 422.402 which states that the standards established for MA plans
supersede any state law or regulation (other than state licensing laws
or state laws relating to plan solvency) with respect to the MA plans
that are offered by MA organizations. Therefore, MA plans would not be
required to comply with timeframes imposed by the states, but rather
with the time frames set by this proposed rule.
We are not proposing to change any existing Federal timeframes that
might apply to expedited authorization decisions made by any of the
impacted payers, especially given that many of these payers already
apply a 72-hour maximum timeframe for such requests. To ensure
consistency and correctly describe the new timeframes being proposed
for these payers to provide notice of standard determinations, we are
proposing a corresponding amendment to the CFR sections identified in
Table 7. Specifically, an MA plan must automatically transfer a request
to the standard timeframe if the MA plan denies a request for an
expedited organization determination or an applicable integrated plan
denies a request for an expedited integrated organization
determination. This step to automatically transfer expedited requests
to the standard timeframe does not apply to the Medicaid and CHIP
managed care provisions listed in Table 7 since the provision at 42 CFR
438.210(d)(2) requires managed care plans to make an expedited
authorization decision no later than 72 hours after receipt of the
request if the provider requesting the authorization indicates that
following the standard timeframe could seriously jeopardize the
beneficiary's life or health or ability to attain, maintain, or regain
maximum function.
6. Requirements for Timing of Notifications Related to Prior
Authorization Decisions
This section proposes requirements for the timing of notifications
sent by certain payers to patients regarding prior authorization
decisions. This proposal also applies to most impacted payers. However,
we are not proposing to address proposals for notifications to the QHPs
on the FFEs, for the same reasons we provided in section II.D.5.b.
a. MA Organizations
MA organizations are currently required to provide notifications to
enrollees of decisions regarding coverage, called organization
determinations, which includes decisions regarding prior
authorizations. To support more timely decisions and communication of
those decisions, we propose to amend the CFR sections identified in
Table 5 to require MA organizations to notify the enrollee of its
determination as expeditiously as the enrollee's health condition
requires, but no later than 7 calendar days after the organization
receives the request for a standard pre-service organization
determination for a medical item or service. We are also proposing to
revise 42 CFR 422.568 and move the existing language at 42 CFR
422.568(b)(1)(i) and (ii) to 42 CFR 422.568(b)(2). We propose to move
the language previously at 42 CFR 422.568(b)(2) to new paragraph
(b)(3). We emphasize that this proposed change to the regulation text
structure does not change current requirements and that this proposed 7
calendar day timeframe would remain subject to the existing
requirements (currently at 42 CFR 422.568(b)(1)(i), proposed to be at
42 CFR 422.568(b)(2)) related to the limited circumstances under which
an MA organization may extend the adjudication timeframe by up to 14
additional calendar days. We are not proposing to change the current
72-hour decision timeframe for expedited requests or the availability
of the 14-calendar day extension to make a determination under 42 CFR
422.568 for standard requests and 42 CFR 422.572 for expedited
requests.
Other than the proposal to require an MA plan to send notification
of prior authorization decisions to providers electronically in section
II.D.3.a. of this proposed rule, we are not proposing changes to the
requirements for an MA plan to notify enrollees of decisions on
organization determinations. For example, should an MA plan deny a
prior authorization request, it must send written notice to the
enrollee under the requirements for standard requests at 42 CFR
422.568(d) and (e) and for expedited requests at 42 CFR 422.572(e).
Consistent with policies for MA organizations, we are proposing
enrollee notification requirements for the integrated organization
determination process described at 42 CFR 422.631. Specifically, we
propose to amend the CFR sections identified in Table 5 to state that
when a provider makes a request for an item or service, the applicable
integrated plan must notify the enrollee of its determination as
expeditiously as the enrollee's health condition requires, but no later
than 7 calendar days after the organization receives the request for a
standard pre-service organization determination regarding coverage for
a medical item or service. We are not proposing to change the current
72-hour requirement for decisions and notice on expedited requests at
42 CFR 422.631(d)(2)(iv)(A). Under our proposal, the authority for a

[[Page 76299]]

14-calendar day extension of the timeframe, in 42 CFR
422.631(d)(2)(ii), would remain unchanged. Also, consistent with the
proposed changes to rules for other MA organizations, we are proposing
to amend the CFR sections identified in Table 5 to state that when an
applicable integrated plan denies a request for an expedited
determination and automatically transfers the request to the standard
timeframe, it must make its determination within the 7-calendar day
timeframe, rather than the current 14 calendar day timeframe for an
integrated organization determination. These proposed changes would
also apply to applicable integrated plans that are Medicaid managed
care organizations (MCOs), as defined in 42 CFR 438.2, because, per 42
CFR 438.210(d)(4), 42 CFR 422.631 also applies to these Medicaid plans.
These proposed amendments are consistent with changes for other
Medicaid managed care plans being proposed at 42 CFR 438.210(d)(1) and
(2), discussed later. As with the proposed requirements for MA
organizations, our proposal is limited to the timeframes for standard
determinations, and we are not proposing changes to the timeline for
expedited integrated organization determinations, extensions, or the
requirements for notice to enrollees.
b. Medicaid Fee-for-Service, Including Beneficiary Notice and Fair
Hearings
For the Medicaid FFS program we are proposing, at the CFR sections
identified in Table 5, to specify regulatory timeframes to provide
notice of decisions on both expedited and standard prior authorization
requests. The new requirements would apply to prior authorization
decisions beginning January 1, 2026.
Under this proposal for Medicaid FFS, which would appear at 42 CFR
440.230(e)(1), notice of the state Medicaid program's decision
regarding an expedited request for prior authorization would have to be
communicated as expeditiously as a beneficiary's health condition
requires, but no later than 72 hours after receiving a provider's
request for an expedited determination, unless a shorter minimum time
frame is established under state law. Notice of a decision on a
standard request for a prior authorization would have to be
communicated to the requesting provider as expeditiously as a
beneficiary's health condition requires, but no later than 7 calendar
days after receiving the request, unless a shorter minimum time frame
is established under state law. If the state determines that it needs
additional information from a provider to make a decision, or if the
beneficiary or provider requests an extension, the proposed decision-
making and communication timeframe for a standard request could be
extended by up to 14 calendar days. Such extensions may be justified
and in the beneficiary's interest if medical evidence from outside
providers is needed to support the request, or there are other
circumstances identified by either the provider or the beneficiary.
Independent of this proposed rule's API proposals and their
application to Medicaid prior authorization requests, Medicaid has
longstanding beneficiary notice and fair hearing regulations. CMS has
interpreted these existing regulations to apply to prior authorizations
requests for Medicaid FFS, and expects to do so in the future. These
existing Medicaid beneficiary notice and fair hearing requirements will
remain in full effect without change, regardless of how or if the API
proposals are finalized.
Specifically, the current Medicaid notice regulations at 42 CFR
435.917 apply to all prior authorization decisions and require a state
to provide the beneficiary with timely and adequate written notice of
any decision regarding the beneficiary's prior authorization request,
as any such decision would cause a ``denial or change in benefits and
services.'' \104\ The existing regulations do not specify a timeframe
for providing notice to a beneficiary of the state decision, nor do we
propose such a change to these regulations herein. When a state denies
the prior authorization request in whole or in part, the beneficiary
notice must include, in addition to the content described in 42 CFR
435.917, the notice content described in 42 CFR part 431, subpart E,
including information about the beneficiary's right to request a fair
hearing to appeal the partial or total denial.\105\ These requirements
are separate from, and independent of, the new timeline for provider
notice that we are proposing at 42 CFR 440.230(e)(1).
---------------------------------------------------------------------------

\104\ See 42 CFR 435.917(a).
\105\ See discussion in the Medicaid and Children's Health
Insurance Programs: Eligibility Notices, Fair Hearing and Appeal
Processes for Medicaid and Other Provisions Related to Eligibility
and Enrollment for Medicaid and CHIP final rule (hereinafter
``Eligibility and Appeals Final Rule''), published in the Federal
Register on November 30, 2016 (81 FR 86382, 86395) (approvals of
prior authorization requests for an amount, duration, or scope that
is less than what the beneficiary requested are subject to fair
hearing requirements in 42 CFR part 431, subpart E).
---------------------------------------------------------------------------

Existing regulations at 42 CFR 431.220(a)(1) require the state to
provide beneficiaries the opportunity to request a fair hearing if the
state fails to act on a claim with reasonable promptness. We consider a
prior authorization request a type of claim. Therefore, beneficiaries
have the right to a fair hearing when the state fails to make prior
authorization decisions with reasonable promptness.
Existing regulations at 42 CFR 431.220(a)(1) require that states
grant Medicaid beneficiaries the opportunity for a fair hearing
whenever a state takes an action as defined in 42 CFR 431.201. This
definition includes ``a termination, suspension of, or reduction in
covered benefits or services,'' which, in turn, includes any
termination, suspension of, or reduction in benefits or services for
which there is a current approved prior authorization. Under existing
regulations at 42 CFR 431.211, a state must provide an individual at
least 10 days advance notice prior to taking an action and must afford
the beneficiary the right to the continuation of services pending the
resolution of the state fair hearing, in accordance with 42 CFR
431.230. Therefore, the state must provide advance notice to
beneficiaries of any termination, suspension of, or reduction in
benefits or services for which there is a current approved prior
authorization and must afford the beneficiary the right to request a
fair hearing, in accordance with 42 CFR part 431, subpart E. This
advance notice requirement would not be affected by any of the proposed
changes in this proposed rule.
To make it explicit that existing Medicaid beneficiary notice and
fair hearing rights apply to Medicaid FFS prior authorization
decisions, independent of the notification timeframe proposals
elsewhere in this proposed rule, we are proposing several clarifying
updates to the existing regulations at 42 CFR 431.201, 431.220, and
431.917, and a new 42 CFR 440.230(e)(2). These proposed changes, if
finalized as proposed, would not change Medicaid notice or fair hearing
policy or operational requirements for states. Additionally, these
proposed changes, if finalized as proposed, would be applicable upon
the effective date of the final rule, and thus would take effect sooner
than the proposed timeframes for issuing provider notice of a prior
authorization decision in 42 CFR 440.230(e)(1). Finally, we note that
these proposed Medicaid beneficiary notice and fair hearing regulation
changes seek only to clarify, not change, existing policy. Therefore,
our interpretation of how existing regulations apply to Medicaid FFS
prior authorization decisions, as previously described, applies today
and will continue to apply in the future,

[[Page 76300]]

regardless of whether these changes are finalized as proposed.
We propose the following changes to clarify how existing Medicaid
beneficiary notice and fair hearing regulations apply to Medicaid FFS
prior authorization decisions:
Modification of the headers in 42 CFR 435.917 to clarify
that the information in this section relates broadly to eligibility,
benefits, and services notices. Specifically, we propose to remove the
word ``eligibility'' from the headers of paragraphs (a) and (b) of 42
CFR 435.917 to reflect the content of these paragraphs more accurately.
Revision of the definition of an ``action'' at 42 CFR
431.201 to include termination, suspension of, or reduction in benefits
or services for which there is a current approved prior authorization.
We also propose to revise the definition of the term ``action'' to
improve readability by numbering the components of the definition,
rather than listing them in a single paragraph.
Modification of 42 CFR 431.220 to add a new paragraph
(a)(1)(vi) to add prior authorization decisions to the list of
situations in which a state must provide the opportunity for a fair
hearing in circumstances where the beneficiary believes the agency has
taken an action erroneously, denied their claim for eligibility or for
covered benefits or services, or issued a determination of an
individual's liability, or has not acted upon the claim with reasonable
promptness.
Revision of 42 CFR 435.917(b)(2) to include, among the
types of notices that need to comply with the requirements of 42 CFR
431.210, a reference to denials of, or changes in, benefits and
services for beneficiaries receiving medical assistance. This would
ensure that individuals receiving medical assistance who are denied
benefits or services would receive a notice that includes the content
at 42 CFR 431.210, which requires that notices include a clear
statement of the specific reasons supporting the intended action.
Addition of a new 42 CFR 440.230(e)(2) to specify that
states must provide beneficiaries with notice of the Medicaid agency's
prior authorization decisions in accordance with 42 CFR 435.917 and
provide fair hearing rights, including advance notice, in accordance
with 42 CFR part 431, subpart E.
We make these proposed changes at the CFR sections identified in
Table 6.
Readers are reminded that the Medicaid beneficiary notice
requirements at 42 CFR 435.917 and 431.210 through 431.214, including
all proposed revisions and additions, such as the proposal at 42 CFR
440.320(e)(2) previously discussed, apply to the written notice
provided by the state to the beneficiary. These requirements, including
the provision of fair hearing rights, are long-standing and exist
independently of the proposed PARDD API provisions of this proposed
rule, which represents an interaction between the payer and the
provider. Nor do the Medicaid beneficiary notice requirements conflict
with the communication of denial reasons to the provider under the
proposals in section II.D.4.a. of this proposed rule.
The current application of existing notice and fair hearing
requirements to Medicaid FFS prior authorization decisions, including
the proposed clarifications as previously discussed, is consistent with
current regulations for notice and appeal rights for managed care prior
authorization decisions. These are sometimes referred to as service
authorizations or adverse benefit determinations.\106\
---------------------------------------------------------------------------

\106\ See 42 CFR 438.400 (definition of adverse benefit
determination), 438.404 (timely and adequate notice for adverse
benefit determination), and 438.420 (continuation of benefits while
managed care plan appeal and the state fair hearing process are
pending).
---------------------------------------------------------------------------

In summary, our existing Medicaid beneficiary notice and fair
hearing regulations apply to Medicaid FFS prior authorization
decisions. We propose several revisions and additions to these
regulations that would clarify, but not change, their application to
Medicaid FFS prior authorization decisions. These include revisions to
the definition of ``action'' and making explicit that prior
authorization denials are subject to the same notice and fair hearing
rights as other denials of services. These revisions would become
applicable upon the effective date of the final rule. We are proposing
these clarifications regarding the application of existing Medicaid
beneficiary notice and fair hearing requirements at the CFR sections
identified in Table 6. We seek comments both on our proposals and on
how states currently apply these notice and fair hearing rights to
prior authorization decisions.
c. Medicaid Managed Care
To implement the proposed authorization timeframes for Medicaid
managed care, we also propose to revise the CFR sections identified in
Table 5. Under our proposal, the new timeframes for Medicaid managed
care plans to provide notice of decisions on standard (non-expedited)
prior authorization requests would apply beginning with the rating
period that starts on or after January 1, 2026.
We propose to revise 42 CFR 438.210(d)(1) to reflect that,
beginning with the rating period that starts on or after January 1,
2026, managed care plans must provide notice of standard authorization
decisions within state-established timeframes that may not exceed 7
calendar days following the plan's receipt of the request for service.
We propose to specify the standard authorization requirements by
compliance date by leaving the section header ``Standard authorization
decisions'' as 438.210(d)(1) and redesignating standard authorization
timeframes as 438.210(d)(1)(i)(A) and (B). We also proposed to
redesignate authorization decision timeframe extensions from Sec.
438.210(d)(1)(i) and (ii) to Sec. 438.210(d)(1)(ii)(A) and (B) and
proposed to make slight revisions to the text for readability. Our
proposal would not change the current provisions for how failure to
issue a decision within the required timeframe constitutes an adverse
benefit determination that can be appealed under 42 CFR 438.404(c)(5).
Section 438.404 and other regulations governing appeal rights in 42 CFR
part 438, subpart F, would continue to apply. This is also consistent
with how the definition of ``adverse benefit determination'' in 42 CFR
438.400(b) includes a Medicaid managed care plan failing to make an
authorization decision within the regulatory timeframes. We note that
under current regulations at 42 CFR 438.3(s)(1) and (6) and
438.210(d)(3), Medicaid managed care plans must also comply with the
requirements in section 1927 of the Act regarding coverage and prior
authorization of covered outpatient drugs. Nothing in this proposed
rule would change these requirements. Finally, because some Medicaid
MCOs are applicable integrated plans as defined in 42 CFR 438.2, our
proposal related to 42 CFR 422.631(d) would apply to those plans.
We are not proposing to change the required timeframes for
expedited decisions at 42 CFR 438.210(d)(2), but we are proposing to
amend the CFR sections identified in Table 5 to clarify that the MCO,
PIHP, or PAHP must make these decisions on shorter timeframes if the
state requires shorter timeframes. However, as described previously, we
are soliciting comment on the possible alternative of a shorter time
frame of 48 hours maximum, and would use that information to determine
if expedited decisions should be required in less time, and as
expeditiously as the beneficiary's condition requires. We are not
proposing any changes to the authority

[[Page 76301]]

for a 14-day extension provided at 42 CFR 438.210(d)(2)(ii). The
proposal to amend 42 CFR 438.210(d) would also apply to standard and
expedited decisions made by CHIP managed care entities because of the
cross-reference to 42 CFR 438.210 in current 42 CFR 457.1230(d).
d. CHIP Fee-for-Service and Managed Care
To implement the proposed prior authorization timeframes for CHIP,
we propose to revise certain policies affecting the timing for making
decisions on prior authorization requests under the CHIP Fee-for-
Service and Managed Care program. These changes are summarized in Table
5. Beginning on January 1, 2026, decisions related to prior
authorization of health services would be required to be completed in
accordance with the medical needs of the patient, but no later than 7
calendar days after receiving the request for a standard determination
and 72 hours after receiving the request for an expedited
determination, unless an alternative option is preferred by industry
based on public comments. If a beneficiary requests an extension of a
prior authorization review, or if the provider or health plan
determines that additional information is needed for such review, an
extension of up to 14 calendar days may be granted. We propose to
remove the option for states to follow existing state law regarding
prior authorization of health services, requiring states to instead
follow these updated timeframes. However, if state laws are more
stringent than our proposal, states would be allowed to apply and
enforce those shorter timeframes for prior authorization responses. We
believe timely prior authorization decisions are an important
beneficiary protection, and CHIP beneficiaries should be afforded the
same decision timeframes as Medicaid and Medicare beneficiaries.
Existing CHIP regulations at 42 CFR 457.1130(b) require a state to
ensure that a beneficiary has an opportunity for external review of
health services matters, including a delay, denial, reduction,
suspension, or termination of health services, in whole or in part,
including a determination about the type or level of service. Under
this regulation, CHIP beneficiaries must have an opportunity for
external review of prior authorization decisions. We are not proposing
any changes to this requirement, as it already applies to decisions
related to the prior authorization of services.
Overall, we believe that the decision and notification timeframes
proposed for certain impacted payers in this rule would help ensure
that prior authorization processes do not inappropriately delay patient
access to necessary services. Introducing prior authorization decision
timeframes that are the same across these impacted payers for items and
services that require prior authorization would also help providers
better organize and manage administrative resources and thus may make
more time available for providers to render patient-centered care. We
believe these proposals would make substantive improvements to the care
experience for patients and lead to better health outcomes. In turn,
better health outcomes would contribute to more efficient use of
program resources.
We request comments on these proposals, specifically comments that
would provide insight on any unintended consequences of these proposed
policies to improve the decision or notification timeframes for prior
authorizations.
[GRAPHIC] [TIFF OMITTED] TP13DE22.005

[[Page 76302]]

[GRAPHIC] [TIFF OMITTED] TP13DE22.006

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

\107\ State hiring processes are comparable with Federal hiring
processes. According to OMB, the average time-to-hire for Federal
employees was 98.3 days in 2018, significantly higher than the
private sector average of 23.8 days. See: https://www.opm.gov/news/releases/2020/02/opm-issues-updated-time-to-hire-guidance/.
---------------------------------------------------------------------------

Should the proposal for this API be finalized as proposed, states
would be permitted to submit a written application for a one-time, one-
year extension as a part of their annual APD for MMIS operations
expenditures. The state's request would have to include the following:
(1) a narrative justification describing the specific reasons why the
state cannot reasonably satisfy the requirement(s) by the compliance
date, and why those reasons resulted from circumstances that are unique
to the agency operating the Medicaid and/or CHIP FFS program (versus
other types of impacted payers); (2) a report on completed and ongoing
state implementation activities to evidence a good faith effort toward
compliance; and (3) a comprehensive plan to meet the PARDD API
requirements no later than 1 year after the compliance date.
Under this proposal, CMS would approve an extension if, based on
the information provided in the APD, CMS determines that the request
adequately establishes a need to delay implementation, and that the
state has a comprehensive plan to implement the proposed requirements
no later than 1 year after the compliance date. We also solicit
comments on whether our proposal would adequately address the unique
circumstances that affect states and that might make timely compliance
with the proposed API requirement difficult for states.
(2) Exemption
At the CFR sections identified in Table 7, we propose to permit
state Medicaid FFS programs to request an exemption from the PARDD API
requirements when at least 90 percent of the state's Medicaid
beneficiaries are enrolled in Medicaid managed care organizations as
defined in 42 CFR 438.2. Likewise, we propose that separate CHIP FFS
programs could request an exemption from the PARDD API requirements if
at least 90 percent of the state's separate CHIP beneficiaries are
enrolled in CHIP managed care entities as defined at 42 CFR 457.10. In
this circumstance, the time and resources that the state would need to
expend to implement the PARDD API requirements for a small FFS
population may outweigh the benefits of

[[Page 76303]]

implementing and maintaining the API. Unlike other impacted payers,
state Medicaid and CHIP FFS programs do not have a diversity of plans
to balance implementation costs for those plans with low enrollment. If
there is low enrollment in a state Medicaid or CHIP FFS program, there
is no potential for the technology to be leveraged for additional
beneficiaries. States, unlike other payers, do not maintain additional
lines of business.
We acknowledge that the proposed exemption could mean that most
beneficiaries enrolled with exempted Medicaid or CHIP FFS programs,
would not receive the full benefits of having this API available to
facilitate the prior authorization exchange between payers and
providers. To address this, we propose that states that are granted an
exemption would be expected to implement an alternative plan to enable
the efficient electronic exchange and accessibility of prior
authorization information for those beneficiaries who are served under
the FFS program and to ensure that enrolled providers will have
efficient electronic access to the same information through other
means, to help ensure that Medicaid or CHIP services are provided with
reasonable promptness and in a manner consistent with the simplicity of
administration and in the best interests of those beneficiaries who are
served under the FFS program.
We propose that a state could submit a written request for an
exemption from the requirements for the PARDD API as part of its annual
APD for MMIS operations expenditures prior to the date by which the
state would otherwise need to comply with the requirements (which may
be extended by 1 year if the state receives an extension). For Medicaid
exemption requests, the state would be required to include
documentation that it meets the criteria for the exemption based on
enrollment data from the most recent CMS ``Medicaid Managed Care
Enrollment and Program Characteristics'' report. For a CHIP FFS
exemption, the state's request would have to include enrollment data
from Section 5 of the most recently accepted state submission to the
CARTS. The state would also be required to include in its request,
information about an alternative plan to ensure that providers will
have efficient electronic access to the same information through other
means while the exemption is in effect. CMS would grant the exemption
if the state establishes to CMS's satisfaction that it meets the
criteria for the exemption and has established such an alternative
plan.
Once an exemption has been approved, we propose that the exemption
would expire if either of the following two scenarios occurs: (1) based
on the 3 previous years of available, finalized Medicaid T-MSIS and/or
CHIP CARTS managed care and FFS enrollment data, the State's managed
care enrollment for 2 of the previous 3 years is below 90 percent; or
(2) CMS has approved a State plan amendment, waiver, or waiver
amendment that would significantly reduce the share of beneficiaries
enrolled in managed care and the anticipated shift in enrollment is
confirmed by available, finalized Medicaid T-MSIS and/or CHIP CARTS
managed care and FFS enrollment data.
For the first scenario, CMS recognizes that there may be
circumstances where a state's managed care enrollment may fluctuate
slightly below the 90 percent threshold in 1 year, and yet return to
above 90 percent the next year. To help reduce the possible burden on
exempted states experiencing this type of temporary fluctuation in
managed care enrollment, CMS would consider data from the 3 previous
years of available, finalized Medicaid T-MSIS and/or CHIP CARTS managed
care and FFS enrollment data. We propose that if the state's managed
care enrollment for 2 of the previous 3 years is below 90 percent, the
state's exemption would expire.
We propose that a state would be required to provide written
notification to CMS that the state no longer qualifies for the PARDD
API exemption when data confirm that there has been a shift from
managed care enrollment to FFS enrollment resulting in the State's
managed care enrollment falling below the 90 percent threshold for 2 of
the previous 3 years. We propose that the written notification be
submitted to CMS within 90 days of the finalization of the first annual
Medicaid T-MSIS managed care enrollment data and/or the CARTS report
for CHIP confirming that there has been the requisite shift from
managed care enrollment to FFS enrollment in 2 of the 3 previous years.
For the second scenario, we recognize that there may be state plan
amendments, waivers, or waiver amendments that would result in a shift
from managed care enrollment to FFS enrollment. Additionally, there may
be instances where anticipated enrollment shifts may not be fully
realized due to certain circumstances. We propose that a state would be
required to provide written notification to CMS that the state no
longer qualifies for the PARDD API exemption when data confirm that
there has been a shift from managed care enrollment to FFS enrollment
as anticipated in the state plan amendment or waiver approval. We
propose that the written notification be submitted to CMS within 90
days of the finalization of the first annual Medicaid T-MSIS managed
care enrollment data and/or the CARTS report for CHIP confirming that
there has been the requisite shift from managed care enrollment to FFS
enrollment.
Regardless of why the exemption expires, if it expires, the state
would be required to obtain CMS's approval of a timeline for compliance
with the PARDD API requirements for the state's Medicaid FFS and/or
CHIP FFS populations within two years of the expiration date of the
exemption.
For Medicaid and CHIP managed care, we are not proposing an
extension process because we believe that managed care plans are
actively working to develop the necessary IT infrastructure to be able
to comply with the existing requirements at 42 CFR parts 438 and 457
and because many of these plans might benefit from efficiencies based
on the variety of plan types that they offer. Many managed care plans
are part of parent organizations that maintain multiple lines of
business, including Medicaid managed care plans and plans sold on the
Exchanges. As discussed in the CMS Interoperability and Patient Access
final rule (85 FR 25607, 25612, and 25620), work done by these
organizations can benefit all lines of business and, as such, we do not
believe that the proposals in this rule impose undue burden or could
not be achieved by the compliance date. We are soliciting comments on
our assumptions regarding the scope of resources and ability of managed
care parent organizations to achieve economies of scale when
implementing the proposed API.
Further, we seek comment on whether an extension process would be
warranted for certain managed care plans to provide additional time for
the plan to comply with the proposed requirement at 42 CFR 438.80(b)
(which cross references 42 CFR 438.242(b)(7)) for Medicaid managed care
plans and at proposed 42 CFR 457.732(b) (which would cross reference 42
CFR 457.1233(d)) for CHIP managed care entities. While we are not
proposing such a process for managed care plans and entities and do not
believe one is necessary, we are open to evaluating options for
possible future rulemaking. Were we to adopt an extension process for
these managed care plans and entities, what criteria should a managed
care plan or entity meet to qualify for an extension? Should the
criteria include

[[Page 76304]]

enrollment size, plan type, or certain unique plan characteristics that
could hinder their achievement of the proposed requirements by the
proposed compliance date? We also seek comment on whether, were we to
propose such a process for Medicaid managed care plans or CHIP managed
care entities, the entity responsible for evaluating the criteria and
exception evaluation process should be the state and whether states
could implement the exception evaluation process with available
resources. Consistent with the exception process proposed for QHP
issuers on the FFEs at 45 CFR 156.222(c), we would expect managed care
plans seeking extensions to provide, at a minimum, a narrative
justification describing the reasons why a plan or entity cannot
reasonably satisfy the requirements by the proposed compliance date, an
explanation of the impact of non-compliance upon enrollees, an
explanation of the current or proposed means of providing electronic
health information to providers, and a comprehensive plan with a
timeline to achieve compliance.
We request comment on the proposed extension and exemption
processes.
b. Exception for QHP Issuers
For QHP issuers on the FFEs, we propose an exception process to the
PARDD API proposal at the regulation citations identified in Table 7.
We propose that if an issuer applying for QHP certification to be
offered through an FFE believes it cannot satisfy the proposed
requirements at 45 CFR 156.223(b) for the PARDD API, the issuer would
have to include as part of its QHP application a narrative
justification describing the reasons why the issuer could not
reasonably satisfy the requirements for the applicable plan year, the
effect of non-compliance upon providers and enrollees, the current or
proposed means of providing health information to providers, and
solutions and a timeline to achieve compliance with the requirements of
this section. We propose that the FFE may grant an exception to the
requirements at 45 CFR 156.223(b) for the PARDD API if it determines
that making qualified health plans of such issuer available through
such FFE is in the interests of qualified individuals in the state or
states in which the FFE operates, and an exception would be warranted
to permit the issuer to offer qualified health plans through the FFE.
This proposal would be consistent with the exception for QHP issuers on
the FFEs that we finalized for the Patient Access API in the CMS
Interoperability and Patient Access final rule (85 FR 25552). For
instance, as noted in that final rule, that exception could apply to
small issuers, financially vulnerable issuers, or new entrants to the
FFEs that demonstrate that deploying FHIR API technology consistent
with the required interoperability standards would pose a significant
barrier to the issuer's ability to provide coverage to patients, and
not certifying the issuer's QHP or QHPs would result in patients having
few or no plan options in certain areas. We believe that having a QHP
issuer offer QHPs through an FFE generally is in the best interest of
patients and would not want patients to have to go without access to
QHP coverage because the issuer was unable to implement this API.
In summary, we propose to permit certain impacted payers (state
Medicaid and CHIP FFS programs and QHP issuers on the FFEs) to apply
for an extension, exemption, or exception, as applicable, from
implementing the proposed PARDD API. We propose that these programs
would submit and be granted approval for an extension or exemption as
part of applicable established processes. We propose that submission
requirements would include certain documentation identified in the
regulatory citations in Table 7.
8. Public Reporting of Prior Authorization Metrics
We are proposing to require impacted payers to publicly report
certain aggregated metrics about prior authorization by posting them
directly on the payer's website or via a publicly accessible
hyperlink(s). This proposed reporting would be at the organizational
level for MA, the state level for Medicaid and CHIP FFS, the plan level
for Medicaid and CHIP managed care, and the issuer level for QHP
issuers on the FFEs. We propose these levels of reporting for each
impacted payer because we believe these represent the appropriate
organizational level for which aggregated data would be meaningful to a
patient or provider to understand an entity's performance on timeframes
for approvals, on volumes of denials and appeals for prior
authorization.
For example, an MA organization will generally have multiple
contracts and it is not uncommon for these organizations to have more
than one contract for the same service area. Ideally, reports would
present true aggregate figures, which would be at the organizational
level. Medicaid and CHIP managed care would be reported at the plan
level so that beneficiaries could compare and states could evaluate
plans within the state. QHP issuers report on quality improvement
strategies consistent with standards of section 1311(g) of the
Affordable Care Act (45 CFR 156.20), which is at the issuer level, and
would include information for the plans under their purview. Such
reporting of prior authorization data at the issuer level would be
consistent with their quality reports.
Prior authorization data would be compiled from multiple sources,
on multiple measures and individuals, and compiled into aggregate data,
or summary data, for purposes of public reporting and statistical
analysis. Payers may use the detailed information to assess their
internal performance, understand trends and determine where
improvements may be necessary. At the same time, they would be able to
share the aggregate data for all programs with the public. We believe
the availability of such data from the payers could contribute to
improvements in the prior authorization process. Should this proposed
rule be finalized as proposed, we believe that, as payers create and
analyze these reports, there would use the data to learn about their
own performance. Additionally, we believe that the public availability
of prior authorization decision data would further transparency in
consumer information. When some patients are looking for a new plan,
they may compare several factors including, but not limited to, access
to care or authorizations, premiums, benefits, and cost sharing or
coinsurance. Both access to care and transparency regarding prior
authorization processes could be important considerations.
Some providers may find metrics about prior authorization approvals
or appeals useful when selecting payer networks, or to be aware of the
trends in performance of different payers. Providers should have access
to information about how they will be able to treat their patients, and
whether it will be possible to do so in a manner they believe will
support value-based care and services that are appropriate and
necessary for each patient's health. The legal authority for requiring
such public reporting is discussed further in section II.D.10. of this
proposed rule.
We propose that for each metric listed, data would be reported in
aggregate for all items and services. We are not proposing that payers
report on categories of items and services, but rather aggregate the
information as totals or percentages of total items and services, as
outlined in each proposed requirement listed in this section of this
rule. Aggregate data could allow each organization to examine trends
and obtain insight into their own

[[Page 76305]]

performance. As noted elsewhere in this proposed rule, we are excluding
drugs that could be covered by the impacted payers in this proposed
rule. For example, this would include outpatient drugs, drugs that may
be prescribed, those that may be administered by a provider, or those
that may be administered in a pharmacy or hospital. We propose that
impacted payers make reports available annually on all of the
following:
A list of all items and services that require prior
authorization.
The percentage of standard prior authorization requests
that were approved, aggregated for all items and services.
The percentage of standard prior authorization requests
that were denied, aggregated for all items and services.
The percentage of standard prior authorization requests
that were approved after appeal, aggregated for all items and services.
The percentage of prior authorization requests for which
the timeframe for review was extended, and the request was approved,
aggregated for all items and services.
The percentage of expedited prior authorization requests
that were approved, aggregated for all items and services.
The percentage of expedited prior authorization requests
that were denied, aggregated for all items and services.
The average and median time that elapsed between the
submission of a request and a determination by the payer, plan, or
issuer, for standard prior authorizations, aggregated for all items and
services.
The average and median time that elapsed between the
submission of a request and a decision by the payer, plan or issuer,
for expedited prior authorizations, aggregated for all items and
services.
We do not propose a format for how payers would present the
aggregated data in the reports, but we encourage them to consider
readability, and accessibility in preparing the data for viewing and
comprehension. We request comments from all stakeholders, including
payers, providers, and consumers, on how the information might be
displayed on payer websites in a useful and meaningful manner for
patients and providers, including which data would be most useful.
By having access to the requirements for prior authorization of
items and services, and data about prior authorization decisions,
patients and providers would have a better understanding of a payer's
prior authorization review and approval processes. Such information may
be helpful for some patients when making decisions at the time of open
enrollment, special enrollment, or plan selection throughout the year.
The first set of data to be publicly available under our proposal
would reflect current practices, rather than payer behavior based on
compliance with this proposed rule. However, we anticipate that, over
time, data might show improvements after implementation of our
proposals regarding the PARDD API and timeframes for prior
authorization decisions. In addition, year-over-year comparisons could
demonstrate positive, or negative, trends, which alone could be useful
information for patients who are making enrollment decisions. We
acknowledge that not all patients have a choice in enrolling with
payers, such as with the Medicaid and CHIP FFS programs. Nonetheless,
publicly available data would aid interested providers and patients to
generally understand payer performance with respect to prior
authorization processes for decisions, approvals, denials, and appeals.
CMS would enforce the requirements based on the existing compliance
policies for the impacted payers. To facilitate the incorporation of
such data more directly into a consumer-friendly comparison tool, we
may propose in future rulemaking to use these data to help develop
quality measures to incorporate into quality star ratings across
certain payer programs, specifically for MA and QHP issuers on the
FFEs.
In summary, we propose that, beginning in 2026, and by March 31 of
that year, impacted payers must annually report certain aggregated
prior authorization metrics from the previous year. These reports must
be posted on websites or publicly available hyperlinks. We are making
this proposal at the CFR sections identified in Table 7.
For Medicaid managed care, we propose to replace the current
provision at the CFR sections identified in Table 7 which addresses the
applicability date for the provisions in that section, with this new
requirement. The current provision was added in 2016 to clarify that
the previous requirements would remain in effect until the new
provisions began starting with rating periods beginning on or after
July 1, 2017. As several rating periods have passed since July 1, 2017,
we do not believe this clarifying text is needed. Our proposal would
apply to CHIP managed care entities through operation of the cross-
reference to 42 CFR 438.210, which is currently in 42 CFR 457.1230(d).
We propose to accomplish this by removing the current exception for
complying with paragraph 42 CFR 438.210(f). As such, the prior
authorization metrics policies would be applicable to CHIP managed care
through the cross-reference at 42 CFR 457.1230(d) to 42 CFR 438.210.
We request comments on the proposal for reporting metrics on prior
authorization, for example, on the proposed types of data to be
included in the report, on the proposal to report data in aggregate by
items and services, on the proposed reporting timeframe, the number of
reports, and if there are any other types of data that could be useful
to payers, providers, and patients. Given that use of the PARDD API
would develop over time, we also request comment on the timing for
adding a metric similar to those proposed for the Patient Access API in
section II.A, for the total number of prior authorization requests
received via the PARDD API. This information could be useful for
evaluating the degree to which API-facilitated requests would grow over
time.
BILLING CODE 4120-01-P

[[Page 76306]]

[GRAPHIC] [TIFF OMITTED] TP13DE22.007

BILLING CODE 4120-01-C

[[Page 76307]]

9. ``Gold-Carding'' Programs for Prior Authorization

During the CMS listening sessions, we heard about the potential for
additional opportunities for payers to support efficiencies in the
prior authorization process, including discretion about when to require
prior authorization and basing such decisions on data and provider
performance. For example, prior authorization is sometimes required for
certain items and services that are almost always approved. Some
providers have demonstrated a consistent history of complying with all
payer requirements for the submission of documentation to support a
request. Some payers have implemented what they term ``gold-carding''
or similar programs to relax or reduce prior authorization requirements
for providers that have demonstrated a consistent pattern of
compliance. In such programs, providers are relieved of requirements to
submit prior authorization requests based on data indicating their
adherence to submission requirements, appropriate utilization of items
or services, or other evidence-driven criteria. Stakeholders said that
the prior authorization process could be significantly more efficient
and cost-effective for all parties if these programs were more broadly
implemented.
Under the MA program, MA organizations may develop and apply prior
authorization policies, make prior authorization decisions, and have
the discretion to implement gold-carding programs within each
contracted plan. CMS uses a similar approach to gold-carding in the
Medicare FFS Review Choice Demonstration for Home Health Services,
under which home health agencies in demonstration states that select
certain review choice options and have a review affirmation rate or
claim approval rate of 90 percent or greater over 6 months are given
the option to continue in the pre-claim review option or choose a
selective post-payment review or spot check review process.\108\
---------------------------------------------------------------------------

\108\ Centers for Medicare & Medicaid Services (2019). Review
Choice Demonstration for Home Health Services. Retrieved from
https://www.cms.gov/Research-Statistics-Data-and-Systems/Monitoring-Programs/Medicare-FFS-Compliance-Programs/Review-Choice-Demonstration/Review-Choice-Demonstration-for-Home-Health-Services.html.
---------------------------------------------------------------------------

We believe the use of gold-carding and similar prior authorization
reduction programs could help alleviate provider burden. We are also
aware that some states have begun to enact gold-carding programs to
address provider and patient complaints about access to healthcare
services. We encourage payers to adopt gold-carding approaches that
would allow prior authorization exemptions or more streamlined reviews
for certain providers who have demonstrated compliance with
requirements. By taking this step, payers could join CMS in helping to
build an infrastructure that would allow clinicians to deliver care in
a timely and value-based manner. We seek comment for consideration for
future rulemaking on how to measure whether and how such gold-carding
or prior authorization exemption programs could reduce provider and
payer burden, and improve services to patients. In particular, we seek
comment on how CMS and other payers could ensure that such programs
benefit diverse populations, including individuals in rural areas,
individuals with disabilities, individuals with chronic illnesses,
small and minority providers, and providers who disproportionately
serve minority and underserved communities.
To further encourage the adoption and establishment of gold-carding
programs, we are considering including a gold-carding measure as a
factor in quality ratings for MA organizations and QHPs as a way for
these payers to raise their scores in the quality star ratings. We seek
comment for potential future rulemaking on the incorporation of such a
measure into star ratings for these organizations. We also considered
proposing gold-carding as a requirement in payer's prior authorization
policies and seek comment on how such programs could be structured to
meet such a potential requirement.
10. Statutory Authorities To Require Improvements in Prior
Authorization Processes, Decision and Notification Timeframe Proposals
a. Medicare Advantage
Section 1856(b) of the Act directs the Secretary to establish
regulatory standards for MA organizations that are consistent with, and
carry out, Part C of the Medicare statute, including the provisions in
section 1852 of the Act. Section 1852(a) and (d) of the Act provide for
MA plans to cover medically necessary Part A and Part B benefits,
including by making benefits available and accessible with reasonable
promptness. Section 1852(c)(1)(G) of the Act requires that MA
organizations disclose to their enrollees any rules regarding prior
authorization or other review requirements that could result in
nonpayment. Section 1852(g)(1)(A) of the Act requires an MA plan to
have a procedure for making determinations about whether an enrollee is
entitled to receive a health service, how much the enrollee is required
to pay for such service and to provide an enrollee with a written
notice if the plan denies coverage. Section 1852(g)(1)(A) of the Act
also requires that coverage determinations be made on a timely basis.
Section 1852(g)(3)(B)(iii) of the Act requires that the organization
notify the enrollee (and physician involved, as appropriate) of an
expedited determination under time limitations established by the
Secretary, but not later than 72 hours of the time of receipt of the
request. This proposal serves to ensure that MA organizations carry out
their responsibilities under section 1852 of the Act in a consistent
and standardized fashion.
In the interest of ensuring that MA organizations continue to use
appropriate standards, process organization determinations in a timely
manner, and provide enrollees with appropriate access to care under the
authorities referenced earlier, we are proposing to require that MA
organizations implement certain APIs that provide information about the
coverage and documentation requirements for prior authorization, that
they respond to prior authorization requests with the status of that
request, and that they meet certain timeframes for making decisions on
prior authorization requests.
We are proposing that MA organizations implement the PARDD API,
using certain implementation specifications as discussed in section
II.D.3.a. of this proposed rule. These implementation specifications
would be expected to improve the overall prior authorization process by
addressing deficiencies that exist in the process today with respect to
providers' access to information about the prior authorization rules
and documentation requirements. The PARDD API would communicate the
coverage and documentation requirements for a prior authorization,
indicating if an authorization is required for a specific item or
service and what documentation is required to support an authorization
request. The PARDD API would be consistent with the disclosure
obligation on MA organizations in section 1852(c)(1)(G) of the Act by
disclosing to providers the same information that generally must be
provided to enrollees about which covered benefits are subject prior
authorization and would serve the same larger purpose of ensuring
access to coverage by communicating the limits and rules for covered
services.
Additionally, the proposed PARDD API would be a mechanism for
receiving and responding to requests for coverage determinations before
the services are

[[Page 76308]]

rendered or items furnished; therefore, the proposed requirement to
adopt and use the PARDD API would be an additional standard for
implementing and complying with section 1852(g) of the Act regarding an
MA organization's obligation to make coverage determinations. The PARDD
API could enable the provider to compile information that could be used
in the HIPAA-compliant prior authorization request through their
existing workflow and receive a timely response to that request. In
concert with these APIs, we propose that the payer provide the status
of the request, such as whether it was approved, or denied, along with
a denial reason, so that the provider would know what steps to take
next--whether to request a different service for the patient, to submit
additional information, or to appeal the decision. These proposals
would improve patient care and reduce redundancies in administrative
processes between providers and payers because they would give
providers clearer instruction, both for submitting the original request
and, if necessary, providing additional information. The proposed APIs
have the potential to improve the efficiency of the prior authorization
process because they would enable providers to submit accurate
information with the request, which could reduce the number of appeals
or denials, and possibly eliminate requests for additional
documentation. The policies could improve timely access to care for
beneficiaries, by mitigating delays that sometimes occur when a
provider is trying to determine coverage requirements or does not know
what documents to submit to obtain approval for a service. Improvements
in the timeliness of payer operations and provider services would
contribute to program efficiency, and effective operations and would be
in the best interest of the enrollees. The proposal to require MA
organizations to make certain changes to the timeframes in which these
payers provide notice for prior authorization has the potential to
improve patient access to care in program operations as discussed in
section II.D.5.b. of this proposed rule. The proposal could prevent
some patients from abandoning care while waiting for an authorization,
and it could improve efficiencies by avoiding repeat phone calls from
providers who must check on the status of an authorization over the
course of several days, or sometimes weeks. The proposals to improve
timeframes for expedited and standard decisions is being made under the
premise that these changes are overdue, feasible, and would benefit
patients and providers. Furthermore, by establishing more certainty in
the process for providers, should the rule be finalized as proposed,
there may be a reduction in unnecessary repeat requests for services.
More responsive timeframes would also enhance enrollee access to timely
and appropriate care. A shorter timeframe for both standard and
expedited decisions could reduce administrative time and expense for
providers and payers, as they would spend fewer resources on follow up
inquiries. Providers may be able to better direct their attention to
the clinical aspects of patient care. As such, these proposals are
consistent with our authorities under section 1852 of the Act which
requires MA organizations to have a procedure for making timely
determinations and to make benefits available and accessible with
reasonable promptness.
Finally, section 1857(e)(1) of the Act explicitly authorizes the
adoption of additional reporting requirements by MA organizations where
necessary and appropriate. Our proposal to require MA plans to publicly
report prior authorization metrics would enable CMS to assess
implementation of the policies and attempt to determine the impact of
these proposals on payers and providers. Review of these metrics could
help CMS and the plans understand the impact of the proposed policies,
including use of the APIs, and improved decision timeframes. The data
could help plans evaluate operations, implementation of new policies
and the APIs and determine what changes may be appropriate.
b. Medicaid
For Medicaid, most of these proposals are authorized by sections
1902(a)(4), (8), and (19) of the Act. Section 1902(a)(4) of the Act
requires that a state Medicaid plan provide such methods of
administration as are found by the Secretary to be necessary for the
proper and efficient operation of the state Medicaid plan; section
1902(a)(8) of the Act requires states to ensure that Medicaid services
are furnished with reasonable promptness to all eligible individuals;
and section 1902(a)(19) of the Act requires states to ensure that care
and services are provided in a manner consistent with simplicity of
administration and the best interests of the recipients. Some proposals
are also authorized by additional sections of the Act as discussed in
this section of this rule.
Additionally, section 1902(a)(7) of the Act requires that states
must provide safeguards that restrict the use or disclosure of
information concerning Medicaid applicants and beneficiaries to uses or
disclosures that are directly connected with the administration of the
program or plan. One of the implementing regulations for this section
of the Act, at 42 CFR 431.302(c) states that purposes directly
connected to plan administration include providing services for
beneficiaries. CHIP programs are subject to the same requirements
through a cross-reference at 42 CFR 457.1110(b). Medicaid and CHIP
programs must also determine which programs require safeguards to apply
to uses and disclosures of beneficiary data at 42 CFR 431.306. In order
to meet the requirements of that regulation, states must have
consistent criteria for release and use of information (which should
conform to the proposed requirements for the PARDD API, if finalized).
See 42 CFR 431.306(a). Access to information concerning beneficiaries
must be restricted to persons who are subject to standards of
confidentiality that are comparable to that of the Medicaid agency, in
accordance with 42 CFR 431.306(b). The permission provision at Sec.
431.306(d) is not relevant to the API functionality proposed in this
section, in part because it pertains to a well-established
administrative process conducted extensively between the enrolled
providers and states currently, and the provider would not be
considered an outside source. The services include those for which the
state requires that a provider submit a prior authorization request,
and thus needs to communicate about that prior authorization with
providers enrolled with, or authorized by the state to provide care to
its beneficiaries. Prior authorization can be an integral part of the
Medicaid program, and facilitates access to care as well as provider
payment processes. A provider enrolled with the state must meet privacy
and security standards to protect the confidentiality of patient
information. When requesting approval to provide certain services from
the state using the state's PARDD API as described in section
II.D.3.a., the provider would be able to determine if a prior
authorization is required, and what supporting documentation is
necessary to obtain approval for that care.
(1) PARDD API
The proposed requirement for state Medicaid FFS programs and
Medicaid managed care plans to implement the PARDD API is expected to
improve the

[[Page 76309]]

efficiency and timeliness of the prior authorization process for
Medicaid beneficiaries, providers, state Medicaid agencies, and
Medicaid managed care plans by addressing inefficiencies that might
exist in the process today. As discussed in section II.D.3.a. of this
proposed rule, the PARDD API would allow a provider to determine
whether a prior authorization is required, and the documentation
requirements for that prior authorization request. The PARDD API would:
(1) enable providers to submit a complete prior authorization request
faster and easier; (2) support more timely notice to provider and
beneficiary of the disposition of the prior authorization request; and
(3) permit improved scheduling of services or filing appeals, depending
on the decision. The PARDD API could have the potential to improve the
prior authorization process by making it more efficient, including by
reducing the number of denials and appeals, or even by eliminating
requests for additional documentation, as noted elsewhere in this
proposed rule.
(2) Requirement for Payers To Provide Status of Prior Authorization and
Reason for Denial of Prior Authorizations
The proposals to require states and Medicaid managed care plans to
provide specific information to providers about the status of prior
authorization requests are expected to enable providers to plan care
for their patients after submitting a prior authorization request. As
discussed in section II.D.4.a. of this proposed rule, providers would
receive a response to an electronic prior authorization request to
indicate that the request is approved, denied, or if additional
information is needed. If a prior authorization has been denied, the
provider would be provided information about why, so that they can
either re-submit the request with updated information, identify
alternatives for the patient, or appeal the decision. These proposals
would improve the timeliness, clarity, and consistency of information
for providers regarding prior authorization requests, help providers
determine next steps for timely patient care, and reduce payer,
provider, and patient burden by eliminating the need for repeated
inquiries.
(3) Requirements for Prior Authorization Decision Timeframes,
Notifications Related to Prior Authorization Decision Timeframes, and
Amendments to Existing Medicaid Fair Hearings and Appeals Regulations
As discussed in section II.D.5 of this proposed rule, delayed prior
authorization decisions may directly affect patient care by delaying
access to treatment, services, and supplies, as well as transfers
between hospitals and post-acute-care facilities. The proposed
timeframes for making prior authorization decisions about items and
services that require prior authorization in Medicaid FFS and managed
care programs would help providers better manage administrative
resources, make more time available for providers to render patient
care, and facilitate faster access to services. We believe these
proposals would make substantive improvements to the care experience
for Medicaid beneficiaries and lead to better health outcomes. In turn,
better health outcomes would contribute to more efficient use of
Medicaid program resources.
We believe that the proposal to shorten the maximum amount of time
for a Medicaid managed care plan to make a prior authorization decision
from 14 calendar days to 7 calendar days would improve the efficient
operation of the Medicaid program by facilitating faster receipt of
services or filing of appeals.
Our proposal to make explicit in regulation text that current
notice and fair hearing requirements apply to Medicaid FFS prior
authorization decisions is authorized under section 1902(a)(3) of the
Act. Section 1902(a)(3) of the Act requires that a Medicaid state plan
provide for an opportunity for a fair hearing to any individual whose
claim for medical assistance under the plan is denied or is not acted
upon with reasonable promptness. These proposed amendments are also
supported by the 14th Amendment to the United States Constitution and
case law on due process, specifically, Goldberg v. Kelly, 397 U.S. 254
(1970). States must establish timely notice and fair hearing processes
meeting due process standards under Goldberg v. Kelly, as incorporated
into existing Medicaid fair hearing regulations at 42 CFR part 431,
subpart E, see 42 CFR 431.205(d).
Currently, and under our proposal, 42 CFR 438.210 applies the same
appeal and grievance requirements for PIHPs and PAHPs as for MCOs; for
this proposal, we rely on our authority in section 1902(a)(4) of the
Act to adopt these standards for PIHPs and PAHPs. This is consistent
with our prior practice for adopting standards for Medicaid managed
care plans (81 FR 27507).
Additionally, section 1902(a)(17) of the Act requires state
Medicaid plans to include reasonable standards for determining the
extent of medical assistance under the plan that are consistent with
the objectives of title XIX of the Act. As set forth at 42 CFR 440.230,
the standards states establish under section 1902(a)(17) of the Act
could include appropriate limits on a service based on such criteria as
medical necessity or on utilization control procedures, so long as each
service is sufficient in amount, duration, and scope to reasonably
achieve its purpose. Items and services covered under Title XIX benefit
authorities are subject to 42 CFR 440.230, unless statute or regulation
expressly provides for an exception or waiver. This would include
covered items and services described in sections 1905(a), 1915(c),
1915(i), 1915(j), 1915(k), 1915(l), 1937, and 1945 of the Act, and any
other authorities as established by Congress. The standards that states
establish under section 1902(a)(17) of the Act and 42 CFR 440.230 could
include prior authorization requirements. Our proposals to establish
timeframes for prior authorization decisions are authorized under
section 1902(a)(17) of the Act, because they would be expected to help
ensure that states make prior authorization decisions in a manner that
is consistent with the requirements in section 1902(a)(4), (a)(8) and
(a)(19) of the Act, thus helping to ensure that states' standards for
determining the extent of medical assistance under the plan are
consistent with the objectives of title XIX.
For Medicaid managed care plans, these proposals are also
authorized by section 1932(b)(4) of the Act, which provides that each
Medicaid managed care organization must establish an internal grievance
procedure whereby a beneficiary who is eligible for medical assistance
may challenge the denial of coverage or payment for such assistance.
Reducing plan response time for prior authorization decisions could
enable beneficiaries to file appeals if necessary, and receive
resolution to those appeals sooner. The earlier an appeal is filed and
the disposition known, the sooner the provider and beneficiary can
determine whether to request a state fair hearing or to identify
treatment alternatives, if necessary. The prior authorization proposals
in this rule are also consistent with how section 1932(c)(2)(A)(i) of
the Act requires MCO contracts to contain a provision for an

[[Page 76310]]

annual external quality review of quality outcomes, and access to and
timeliness of covered services. Should this rule be finalized as
proposed, and should the proposed shorter prior authorization response
requirements improve workflow and processes that facilitate timely
access to services, improvements to the care experience for patients,
and better health outcomes, the results should be visible in external
reviews. This proposed requirement reflects the importance and
potential advantages of timely access for beneficiaries to covered
services through more efficient processing of prior authorization
requests as proposed in this rule.
(4) Public Reporting of Prior Authorization Metrics
We are also proposing to require Medicaid FFS programs and Medicaid
managed care plans to publicly report certain prior authorization
metrics by posting them directly on the payer's website or via publicly
accessible hyperlink(s). As discussed in section II.D.8. of this
proposed rule, publicly reporting these metrics could support more
timely access to services by identifying prior authorization process
weaknesses or deficiencies and enabling the implementation of
corrective action, and for managed care programs, helping beneficiaries
select Medicaid managed care plans that best meet their needs, and
helping some Medicaid providers make informed decisions on which
Medicaid managed care plan networks to join.
Section 1902(a)(4) of the Act authorizes this proposal because
enabling more timely access to services by identifying prior
authorization deficiencies and facilitating the implementation of
corrective action to improve the prior authorization process would
support the proper and efficient operation of the state Medicaid plan.
Requiring Medicaid managed care plans to publicly report their prior
authorization metrics would hold them accountable and enable them to
monitor their own performance and identify process improvement
opportunities, which could be an integral part of implementing a
quality assessment and improvement strategy more easily. This is
consistent with the requirements for quality strategies for managed
care programs at section 1932(c)(1)(A)(i) of the Act.
Section 1902(a)(8) of the Act authorizes this proposal because
identifying prior authorization process weaknesses or deficiencies and
enabling the implementation of corrective action as well as helping
beneficiaries select a Medicaid managed care plan that best meets their
needs may improve the promptness with which services are provided to
beneficiaries. Section 1902(a)(19) of the Act authorizes this proposal
because identifying prior authorization process weaknesses or
deficiencies and enabling the implementation of corrective action would
help ensure that care and services are provided in a manner consistent
with simplicity of administration. Additionally, implementation of
corrective action to improve prior authorization processes, helping
beneficiaries select a managed care plan that best meets their needs,
and helping providers make informed decisions on which Medicaid managed
care plan networks to join is in the best interest of beneficiaries.
c. CHIP
For CHIP, we propose these requirements under the authority of
section 2101(a) of the Act, which sets forth that the purpose of title
XXI is to provide funds to states to provide child health assistance to
uninsured, low-income children in an effective and efficient manner
that is coordinated with other sources of health benefits coverage.
This provision authorizes us to adopt these requirements for CHIP to
obtain access to program data for analysis. Such analysis supports
improvements in the efficacy of CHIP programs and more efficient
administration of services.
As discussed previously, we propose to require implementation of
the PARDD API in section II.D.3.a. of this proposed rule to improve the
prior authorization process for patients, providers, and payers by
addressing deficiencies and inefficiencies that exist in the current
process. Today, a payer's rules about when a prior authorization is
required, and what documentation requirements must be fulfilled to
submit the request, are not necessarily easily accessible for
providers. The process may require manual activities including phone
calls, use of portals, multiple websites, and paper manuals. These
inefficient procedures take time away from actual patient care. The
PARDD API would enable a provider to determine if a prior authorization
was required electronically, in real time, and what the documentation
requirements would be regarding such request. While we expect providers
would be the primary stakeholders to benefit from this proposed API,
making this information available in a standardized way and permitting
access through an API would also serve the requirements in section
2101(a) of the Act that CHIP ensure access to coverage and coordinated
care.
The proposed PARDD API would be a mechanism for receiving and
responding to requests for coverage determinations before the services
were furnished; the PARDD API would streamline the initial
authorization process for the payer, by sharing this information in an
easily accessible way. This would also allow the provider to know what
to do if a prior authorization is required for a certain service, which
would improve the provider's ability to treat the patient timely. The
proposed PARDD API would enable the payer to send a real time response
back to a provider, based on the request for authorization. This, too,
would improve the efficiency of providing services to the patient,
because the request and response would be automated, and in real time.
Payer use of these APIs could ensure that a provider is able to submit
a request for a prior authorization with the correct and complete
documentation to avoid an incorrect submission which might result in an
unnecessary denial. The PARDD API would: (i) enable providers to submit
a prior authorization request faster and easier, (ii) support more
timely notice to provider and beneficiary of the disposition of the
prior authorization request, and (iii) permit faster scheduling of
services or filing appeals, depending on the decision. The PARDD API
has the potential to improve the prior authorization process by making
it more efficient, including limiting the number of denials and
appeals, or even eliminating requests for additional documentation, as
noted elsewhere.
The safeguards for beneficiary information at subpart F of 42 CFR
part 431 are also applicable to CHIP through a cross-reference at 42
CFR 457.1110(b). As discussed above for Medicaid, CHIP payers' and
providers' data exchange through the PARDD API would be related to
providing services to beneficiaries, which is described at 42 CFR
431.302(c) as a purpose directly related to state plan administration.
We remind states that when they share medical records or any other
health or enrollment information pertaining to individual
beneficiaries, they must comply with the privacy protections at 42 CFR
457.1110 and the release of information provisions at 42 CFR 431.306.
The proposed requirement in section II.D.5.b. of this proposed rule
that CHIP FFS and managed care entities meet certain timeframes to
provide decisions for prior authorizations, for expedited and standard
decisions would be an improvement from the current state,

[[Page 76311]]

where there is uncertainty about expectations for when a prior
authorization might be approved. The proposal is intended to establish
more certainty in the prior authorization process for providers and
improve access to appropriate care for all patients, particularly those
with chronic conditions or complicated health risks. Health parity
could be increased as barriers due to process and timeframes would be
removed. Similarly, improved process improvements could reduce
administrative costs for providers and payers as redundancies would be
removed from the system. The proposal to improve timeliness in
responding to providers and patients could support process improvements
for the state and managed care programs and is consistent with our
authorities under section 2101(a) of the Act in that they improve the
efficiency of the CHIP programs.
Our proposal to require CHIP FFS and CHIP managed care entities to
publicly report prior authorization metrics would also support the
states' oversight, evaluation, and administration responsibilities.
Should the reporting provisions be finalized as proposed, CMS may
occasionally view some of the CHIP's FFS and CHIP websites to check for
compliance, see how data is being reported, and determine if there are
any trends in prior authorization changes that could be indicative of
the benefits of the proposals for prior authorization policies as
discussed in section II.D.8. of this proposed rule. The data may
indicate use of the APIs, improvements in prior authorization numbers,
or changes in total numbers, denials, and appeals.
d. QHP Issuers on the FFEs
For QHP issuers on the FFEs, we are proposing these new
requirements pursuant to the authority of section 1311(e)(1)(B) of the
Affordable Care Act, which affords the Exchanges the discretion to
certify QHPs if the Exchange determines that making available such
health plans through the Exchange is in the interests of qualified
individuals in the state in which the Exchange operates.
The policies included here could improve the efficiency of the
issuers who are certified to offer QHPs on the FFEs and improve the
quality of services they provide to providers and their patients.
Qualified individuals in FFEs may receive covered services more
quickly, and the information may be more accurate with the use of the
APIs. These proposals could improve the quality of the patient
experience with their providers by increasing the efficiency in the
prior authorization submission and review process. Certifying only
health plans that implement FHIR APIs and adhere to the other proposals
herein would be in the interests of qualified individuals in the state
or states in which an FFE operates. We encourage State-based Exchanges
(SBEs) to consider whether a similar requirement should be applicable
to QHP issuers participating in their Exchanges.
In section II.D.3.a. of this proposed rule, we propose that QHPs
issuers on the FFEs implement an API to support the prior authorization
process. The PARDD API would allow QHP issuers to communicate
requirements for prior authorization more efficiently, and enable
providers to similarly operate more efficiently to determine when a
prior authorization is needed and locate the documentation
requirements. The API could enable more accurate submission and
subsequent processing of prior authorization requests, with the
potential of improving delivery of services to patients. Similar to the
other API proposals, certifying only health plans that implement FHIR
APIs would be in the interests of qualified individuals in the state or
states in which an FFE operates because of the opportunities for
improvements in patient care, in alignment with the goals of the
Affordable Care Act.
We are also proposing that QHP issuers on the FFEs provide a reason
for denial when sending a response to a prior authorization request, to
facilitate better communication and understanding between the provider
and issuer. This could enable efficient resubmission of the prior
authorization request with additional information or an appeal, which
could more promptly facilitate the needed patient care.
Finally, the proposal to require QHP issuers on the FFEs to
publicly report prior authorization metrics in section II.D.8. of this
proposed rule would hold issuers accountable to their providers and
patients, which could help these organizations improve their program
administration. These data could help QHP issuers evaluate their
processes and determine if there are better ways to leverage the APIs,
including the quality and sufficiency of the coverage and documentation
information included in the APIs.

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

1. Background
In the December 2020 CMS Interoperability proposed rule (85 FR
82639), we requested comment on ways in which CMS can incentivize the
use of electronic prior authorization solutions by healthcare
providers. We sought comment on whether the Quality Payment Program
(QPP) Merit-based Incentive Payment System (MIPS) for MIPS eligible
clinicians or the Conditions of Participation/Conditions for Coverage
requirements for eligible hospitals and other providers would be the
appropriate mechanism for new or additional policies that would promote
the use of prior authorization APIs. Commenters expressed support for
incentivizing healthcare providers to use these processes and tools to
improve prior authorization processes. They noted that provider
participation and health information technology are critical to
promoting the widespread adoption of electronic prior authorization
solutions. CMS considered both approaches outlined in that RFI (85 FR
82639) aimed at adopting and using electronic prior authorization
processes. We believe that requiring healthcare providers, including
clinicians and hospitals, to use these API functions for prior
authorization is critical to ensuring the success and widespread
adoption of this technology.
As discussed in section II.D. of this proposed rule, the current
prior authorization process needs improvement to reduce the burden
associated with the process itself. According to a 2020 American
Medical Association (AMA) survey, 94 percent of respondents experienced
patient care delays associated with processing prior authorizations,
and 79 percent indicated having at least one experience of abandoned
patient care due to onerous prior authorization processes.\109\ This
same survey indicated increased provider and staff burnout and expense
associated with current prior authorization processes. Specifically,
the data suggest that 40 percent of physician practices have staff who
work exclusively on prior authorizations, and, on average, physicians
and staff spend approximately two business days (16

[[Page 76312]]

hours) each week on prior authorizations.\110\ A 2019 study by the
Altarum Institute corroborates the AMA's findings that current prior
authorization processes are increasingly burdensome and may lead to
poorer patient health outcomes.\111\
---------------------------------------------------------------------------

\109\ American Medical Association (2021). 2020 AMA Prior
Authorization (PA) Physician Survey. Retrieved from https://www.ama-assn.org/system/files/2021-04/prior-authorization-survey.pdf.
\110\ Id.
\111\ Turner, A., Miller, G., & Clark, S. (Nov. 2019). Impacts
of Prior Authorization on Health Care Costs and Quality: A Review of
Evidence. Retrieved from https://www.nihcr.org/wp-content/uploads/Altarum-Prior-Authorization-Review-November-2019.pdf.
---------------------------------------------------------------------------

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

\112\ Office of the National Coordinator (Feb. 2020). Strategy
on Reducing Regulatory and Administrative Burden Relating to the Use
of Health IT and EHRs. Retrieved from https://www.healthit.gov/sites/default/files/page/2020-02/BurdenReport_0.pdf.
\113\ Id. at 14.
\114\ Health Information Technology Advisory Committee, Office
of the National Coordinator (Nov. 2020). A Path Toward Further
Clinical and Administrative Data Integration. Final Report of the
Health Information Technology Advisory Committee's Intersection of
Clinical and Administrative Data Task Force to the National
Coordinator for Health Information Technology. Retrieved from
https://www.healthit.gov/sites/default/files/page/2020-11/2020-11-17_ICAD_TF_FINAL_Report_HITAC.pdf.
---------------------------------------------------------------------------

As described in section II.D. of this proposed rule, stakeholders
who participated in listening sessions conducted by CMS, including
payers, providers, patients, and other industry representatives, noted
that there are aspects of prior authorization processes that may be
improved. For example, the information required by payers to evaluate
or review a prior authorization can be inconsistent between payers, so
it can be difficult for providers to determine the rules and required
documentation. Further, submitting a prior authorization request relies
on multiple cumbersome submission channels, including payer-specific
web-based portals, telephone calls, and fax exchange technology. This
process can be duplicative for providers who must re-submit prior
authorization requests when patients change payers. To pursue these
recommendations and facilitate needed improvements in the prior
authorization process, in section II.D. of this proposed rule, we
propose requiring impacted payers to implement and maintain a PARDD
API. The PARDD API aims to improve care coordination and shared
decision-making by enabling enhanced electronic documentation discovery
and facilitating electronic prior authorization. This is discussed in
more detail in section II.D. of this proposed rule. We believe the
PARDD API would reduce administrative burden, improve efficiency, and
ensure patients promptly receive necessary medical items and services.
However, as noted in the December 2020 CMS Interoperability proposed
rule (85 FR 82639), we recognize that efficiencies from payer
implementation of these APIs will only be realized if they are utilized
by requesting providers to complete prior authorization requests.
Therefore, in this proposed rule, we propose a new measure for MIPS
eligible clinicians under the Promoting Interoperability performance
category of MIPS, as well as for eligible hospitals and CAHs under the
Medicare Promoting Interoperability Program, related to electronic
prior authorization. We intend for the new measure, titled ``Electronic
Prior Authorization,'' to be included in the Health Information
Exchange (HIE) objective for the MIPS Promoting Interoperability
performance category and in the HIE objective for the Medicare
Promoting Interoperability Program. This measure aims to address
stakeholder concerns regarding possible low provider utilization of
APIs established by payers for electronic prior authorization, as
described in letters from commenters in response to the December 2020
CMS Interoperability proposed rule (85 FR 82586).
MIPS is authorized under section 1848(q) of the Act. As described
in sections 1848(q)(2) and (5) of the Act, we evaluate the performance
of MIPS eligible clinicians in four performance categories, which we
refer to as the quality, cost, improvement activities, and Promoting
Interoperability performance categories. Under Sec. 414.1375(b)(2),
MIPS eligible clinicians must report on objectives and measures as
specified by CMS for the Promoting Interoperability performance
category. We refer readers to the Calendar Year (CY) 2023 Physician Fee
Schedule (PFS) final rule (87 FR 70075 through 70080) for a list of the
current objectives and measures for the Promoting Interoperability
performance category. We determine a final score for each MIPS eligible
clinician based on their performance in the MIPS performance categories
and apply a payment adjustment (which can be positive, neutral, or
negative) for the covered professional services they furnish based on
their final score.
The Medicare Promoting Interoperability Program for eligible
hospitals and CAHs are authorized in part under sections
1886(b)(3)(B)(ix) and 1814(l)(4) of the Act. Under these statutory
provisions, eligible hospitals and CAHs that do not successfully
demonstrate meaningful use of CEHRT are subject to Medicare payment
reductions. To demonstrate meaningful use of CEHRT, eligible hospitals
and CAHs must satisfy objectives and measures as required under 42 CFR
495.24. We refer readers to the Fiscal Year (FY) 2023 Hospital
Inpatient Prospective Payment System (IPPS) and Long-Term Care Hospital
(LTCH) final rule (87 FR 49350) for a summary of the current objectives
and measures for the Medicare Promoting Interoperability Program.
2. Electronic Prior Authorization
To support the policies in this proposed rule and maximize the
potential to improve the prior authorization process for providers and
patients, we are proposing to add a new measure titled ``Electronic
Prior Authorization'' in the HIE objective of the MIPS Promoting
Interoperability performance category and in the HIE objective of the
Medicare Promoting Interoperability Program. We believe this measure
would further enable the electronic exchange of health information to
improve the quality of healthcare, such as promoting care coordination,
as described in section 1848(o)(2)(A)(ii) of the Act with respect to
MIPS eligible clinicians and section 1886(n)(3)(A)(ii) of the Act with
respect to eligible hospitals and CAHs. We are proposing to require
MIPS eligible clinicians to report this measure beginning with the CY
2026 performance period/CY 2028 MIPS payment year and for eligible
hospitals and CAHs to report this measure beginning with the CY 2026
EHR reporting period. However, we propose that the measure will not be
scored in 2026.
The proposals we are making in this section with regard to an
Electronic Prior Authorization measure do not alter a covered entity's
requirement to use the

[[Page 76313]]

HIPAA transaction standards at 45 CFR 162.1302. We note that a
healthcare provider may use an intermediary or clearinghouse to
assemble a HIPAA-compliant X12 278 prior authorization transaction to
transmit to the payer, as described in section II.D.3.a. of this
proposed rule. In that section, we also note that in March 2021, HHS
approved an application \115\ from an industry group of payers,
providers, and vendors for an exception under 45 CFR 162.940 from the
HIPAA transaction standards. The approved exception allows testing of
proposed modifications to HIPAA requirements--specifically for the
prior authorization standard. Under this exception, the group would
test a prior authorization exchange using the HL7 FHIR standard. In
this proposal for the Electronic Prior Authorization measure, the
healthcare provider would use data from their CEHRT (such as patient
demographics and medical information) to justify the prior
authorization request. The PARDD API would automate the compilation of
necessary data for populating the HIPAA-compliant prior authorization
request. Additional information not contained in CEHRT may also be
required for submission. This information would then be packaged into a
HIPAA-compliant transaction for transmission to the payer.
---------------------------------------------------------------------------

\115\ Da Vinci Project. Da Vinci HIPAA Exception Confluence
(2021). Retrieved from https://confluence.hl7.org/display/DVP/Da+Vinci+HIPAA+Exception.
---------------------------------------------------------------------------

We are proposing the following specifications for the Electronic
Prior Authorization measure:
a. For MIPS Eligible Clinicians Under the MIPS Promoting
Interoperability Performance Category--Electronic Prior Authorization
Measure Description: For at least one medical item or
service (excluding drugs) ordered by the MIPS eligible clinician during
the performance period, the prior authorization is requested
electronically from a PARDD API using data from CEHRT.
The MIPS eligible clinician would be required to report a numerator
and denominator for the measure or (if applicable) report an exclusion:
Denominator: The number of unique prior authorizations
requested for medical items and services (excluding drugs) ordered by
the MIPS eligible clinician during the performance period, excluding
prior authorizations that cannot be requested using the PARDD API
because the payer does not offer an API that meets the PARDD API
requirements outlined in section II.D.3.a of this proposed rule.
Numerator: The number of unique prior authorizations in
the denominator that are requested electronically from a PARDD API
using data from CEHRT.
Exclusion: Any MIPS eligible clinician who:
(1) Does not order any medical items or services (excluding drugs)
requiring prior authorization during the applicable performance period;
or
(2) Only orders medical items or services (excluding drugs)
requiring prior authorization from a payer that does not offer an API
that meets the PARDD API requirements outlined in section II.D.3.a of
this proposed rule during the applicable performance period.
b. For Eligible Hospitals and Critical Access Hospitals in the Medicare
Promoting Interoperability Program--Electronic Prior Authorization
Measure Description: For at least one hospital discharge
and medical item or service (excluding drugs) ordered during the EHR
reporting period, the prior authorization is requested electronically
from a PARDD API using data from CEHRT.
The eligible hospital or CAH would be required to report a
numerator and denominator for the measure or (if applicable) report an
exclusion:
Denominator: The number of unique prior authorizations
requested for medical items and services (excluding drugs) ordered for
patients discharged from the eligible hospital or CAH inpatient or
emergency department (place of service (POS) code 21 or 23) during the
EHR reporting period, excluding prior authorizations that cannot be
requested using the PARDD API because the payer does not offer an API
that meets the PARDD API requirements outlined in section II.D.3.a of
this proposed rule.
Numerator: The number of unique prior authorizations in
the denominator that are requested electronically from a PARDD API
using data from CEHRT.
Exclusions: Any eligible hospital or CAH that:
(1) Does not order any medical items or services (excluding drugs)
requiring prior authorization during the applicable EHR reporting
period; or
(2) Only orders medical items or services (excluding drugs)
requiring prior authorization from a payer that does not offer an API
that meets the PARDD API requirements outlined in section II.D.3.a of
this proposed rule during the applicable EHR reporting period.
We propose that beginning with the CY 2026 performance period/CY
2028 MIPS payment year for MIPS eligible clinicians and the CY 2026 EHR
reporting period for eligible hospitals and CAHs, a MIPS eligible
clinician, eligible hospital, or CAH that fails to report the measure
or claim an exclusion would not satisfy the MIPS Promoting
Interoperability performance category or Medicare Promoting
Interoperability Program reporting requirements. For the CY 2026
performance period/CY 2028 MIPS payment year for MIPS eligible
clinicians and the CY 2026 EHR reporting period for eligible hospitals
and CAHs, we are proposing that the Electronic Prior Authorization
measure would not be scored and would not affect the total score for
the MIPS Promoting Interoperability performance category or the
Medicare Promoting Interoperability Program. In other words, for CY
2026, a MIPS eligible clinician, eligible hospital, or CAH would be
required to report a numerator of at least one for the measure or claim
an exclusion, but the measure would not be scored. If the MIPS eligible
clinician, eligible hospital, or CAH does not report a numerator of at
least one for the measure or claim an exclusion, they would receive a
zero score for the MIPS Promoting Interoperability performance category
or the Medicare Promoting Interoperability Program, respectively. We
intend to propose a scoring methodology for the measure in future
rulemaking.
We are proposing that for purposes of this measure, a prior
authorization request must be made using the PARDD API to satisfy the
measure. The PARDD API functionality is outlined in further detail in
section II.D.3.a of this proposed rule. Prior authorization requests
that are made using fax, mail, or portal would be included in the
denominator of the measure unless the prior authorization cannot be
requested using the PARDD API because the payer does not offer an API
that meets the PARDD API requirements, in which case it would be
excluded from the denominator. Instances where a payer offering the
PARDD API specifically requests a mailed or faxed prior authorization
would be included in the denominator. Prior authorization requests that
are made using fax, mail, or portal would not be included in the
numerator of the measure because these methods would not incentivize
the use of standards-based API functionality as intended by the
measure. Prior authorizations for any and all drugs would be excluded
from both the numerator and denominator of the measure. (For a more
detailed

[[Page 76314]]

discussion of the exclusion of drugs, see section I.A. of this proposed
rule.)
We are proposing that only prior authorizations that are requested
electronically from a PARDD API using data from CEHRT would be included
in the numerator. Using the API to query documentation requirements
alone and not to request the prior authorization would not count in the
numerator or denominator.
We propose that MIPS eligible clinicians, eligible hospitals, or
CAHs that do not order any medical items or services (excluding drugs)
requiring prior authorization during the applicable performance period
or EHR reporting period could claim an exclusion for this measure. We
are also proposing that MIPS eligible clinicians, eligible hospitals,
or CAHs that only order medical items or services (excluding drugs)
requiring prior authorization from a payer that does not offer an API
that meets the PARDD API requirements outlined in section II.D.3.a of
this proposed rule (that is, non-impacted payers or impacted payers
that are non-compliant with the PARDD API requirements outlined in
section II.D.3.a of this proposed rule), during the applicable
performance period or EHR reporting period, could claim an exclusion
for this measure. As an alternative to this proposal, we considered
whether MIPS eligible clinicians, eligible hospitals, and CAHs that
request a small number of prior authorizations, such as five prior
authorizations during the performance period/EHR reporting period,
should also be able to claim the exclusion. Given the previously
discussed limitations of the current prior authorization process, we
believe that all healthcare providers (as well as their patients and
the payers they request prior authorization from) would benefit from
using the electronic process described here, regardless of how often
they request prior authorization. Therefore, we believe that no minimum
number of prior authorization requests, other than zero, would be a
reasonable threshold for claiming an exclusion for this measure.
However, we seek public comment on the alternative we considered and
whether another minimum number of prior authorization requests would be
appropriate for the exclusion.
ONC recently sought comment through an RFI titled ``Electronic
Prior Authorization Standards, Implementation Specifications, and
Certification Criteria'' (87 FR 3475), which appeared in the January
24, 2022 issue of the Federal Register, on how updates to the ONC
Health IT Certification Program could support electronic prior
authorization. ONC may use comments received from this RFI to inform
future rulemaking in the ONC Health IT Certification Program related to
electronic prior authorization. Updates to certification requirements
for certified health IT introduced in future rulemaking could help MIPS
eligible clinicians and eligible hospitals and CAHs to conduct the
actions described in these proposed measures.
We invite public comment on these proposals. Specifically, we seek
comment on the following:
Should CMS consider alternatives to the proposed numerator
and denominator of the measure? Are there changes to these
specifications that would reduce the implementation burden for both
providers and health IT developers?
What challenges will providers face in identifying those
payers that have the PARDD API technology in order to accurately
include eligible prior authorization requests in the denominator?
What challenges will providers face in performing the
actions included in the measure specifications and successfully
reporting the measure if certification criteria are not available in
the ONC Health IT Certification Program at the time providers are
required to report the measure under the Medicare Promoting
Interoperability Program or MIPS Promoting Interoperability performance
category?
With the understanding that ONC may consider policies in
the ONC Health IT Certification Program that could further support this
measure, are there alternate implementation timeframes that should be
considered?

F. Interoperability Standards for APIs

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

\116\ Access to and Exchange of Health Data and Plan
Information, 42 CFR 422.119 (2020); Beneficiary Access to and
Exchange of Data, 42 CFR 431.60 (2020); Beneficiary Access to
Exchange of Data, 42 CFR 457.730 (2020); and Access to and Exchange
of Health Data and Plan Information, 45 CFR 156.221 (2020).
---------------------------------------------------------------------------

Accordingly, to reduce complexity and provide clarity, we are
proposing modifications to be more specific regarding the standards at
45 CFR 170.215 applicable to previously finalized API requirements. We
are also proposing specific language regarding the standards at 45 CFR
170.215 applicable for each new set of API requirements proposed in
this proposed rule.
Specifically, instead of maintaining and extending the language in
the existing requirements to use ``API technology conformant with 45
CFR 170.215'' in our new proposals, we are proposing language which
specifies the use of each standard at 45 CFR 170.215 that would apply
to a given set of API requirements at the CFR citations identified in
Tables 8. We further summarize the standards applicable for each set of
API requirements in Table 10. We note that the exact regulation text
would vary depending on which standards apply to that API. We believe
this language will clarify that payers would only be required to use
those specifications included at 45 CFR 170.215 that CMS has identified
as necessary for each specific API, as discussed further in section
II.F.3 of this proposed rule.
Regarding the standard at Sec. 170.215(a)(2), which is currently
the HL7 FHIR[supreg] US Core Implementation Guide STU 3.1.1 (US Core
IG), we

[[Page 76315]]

recognize that the information we have required or proposed to require
to be made available for different API use cases may only align with a
subset of profiles defined within the US Core IG. For example, in 42
CFR 422.120(b)(1), for MA plans, we require the Provider Directory API
to include data concepts such as the MA plan's network of contracted
provider names, addresses, and phone numbers, whereas in Sec.
422.119(b), we require the Patient Access API to include a broader set
of information, such as all clinical data, including laboratory
results. While we want to ensure that FHIR Resources are profiled
according to the US Core IG where applicable to support
interoperability across implementations, we also want to ensure that
payers do not engage in unnecessary development. We are therefore
proposing that a payer is only required to use technology conformant
with the US Core IG at Sec. 170.215(a)(2) where applicable, that is,
where there is a corresponding FHIR Resource in their functional API,
pursuant to the data requirements for the API. If the FHIR Resource has
been profiled by the US Core IG at 45 CFR 170.215(a)(2), then the payer
must support the FHIR Resource according to the FHIR Resource Profile's
``StructureDefinition'' as specified in the standard in the US Core IG
at 45 CFR 170.215(a)(2). For example, if a ``Patient'' FHIR Resource is
used in a payer's Patient Access API, the ``Patient'' FHIR Resource
must conform with the ``US Core Patient Profile,'' including all the
``mandatory'' and ``must support'' requirements as specified in the US
Core IG.
We also recognize that several of the IGs recommended for use in
this section of this proposed rule build on specific profiles within
the US Core IG. For example, the HL7 FHIR Da Vinci Payer Data Exchange
(PDex) Implementation Guide: Version STU 1.0.0. Furthermore, we
recognize that the recommended IGs and subsequent versions of these IGs
may use profiles in updated versions of the US Core IG. We note that
payers could use updated versions of the recommended IGs that rely on
newer versions of the US Core IG, as long as those updated versions
meet the requirements of our policy for the use of updated standards
which is described below and aligns with the procedures established by
ONC under the Standards Version Advance Process (SVAP).
a. Use of Updated Standards
In the CMS Interoperability and Patient Access final rule (85 FR
25510), we explained that while we must codify a specific version of
each standard, the need for continually evolving standards development
has historically outpaced our ability to amend regulations. In that
final rule, we established that payers implementing a Patient Access or
Provider Directory API could use an updated version of a standard
subject to certain conditions. Specifically, we established that an
updated version of a standard could be used if the updated version of
the standard is required by other applicable law, or not prohibited
under other applicable law, provided that: for content and vocabulary
standards other than those at 45 CFR 170.213, the Secretary has not
prohibited use of the updated version of a standard for purposes of the
section in which the provision is located, or 45 CFR part 170; and for
standards at 45 CFR 170.213 and 170.215, the National Coordinator has
approved the updated version for use in the ONC Health IT Certification
Program (85 FR 25522). Finally, we established that an updated version
of the standard could be used if the updated version does not disrupt
an end user's ability to use a required API to access the data required
for that API (85 FR 25532). We are now proposing to extend this same
policy to allow the use of an updated version of a standard to the
Provider Access API, Payer-to-Payer API, and PARDD API. Under this
proposal, impacted payers could upgrade to newer versions of the
required standards, subject only to those limiting conditions, as
previously noted, at any pace they wish. However, we reiterate that
when using updated standards, a payer must continue to support
connectivity for end users and may only use an updated version of the
standard instead of the standard specified in the applicable
regulation, if it does not disrupt an end user's ability to access the
data available through the API. We are proposing to allow the use of
updated standards, specifications, or Implementation Guides for each of
the API requirements at the CFR sections identified in Table 9. We note
that any existing or proposed cross-references apply current
requirements to the newly proposed APIs.
Regarding the use of updated versions of standards at 45 CFR
170.213 and 170.215, we propose that these standards may be used if the
National Coordinator has approved the updated version for use in the
ONC Health IT Certification Program. We note that the National
Coordinator approves the use of updated versions of standards in the
Certification Program under SVAP pursuant to 45 CFR 170.555, which was
finalized in the ONC 21st Century Cures Act final rule as a Maintenance
of Certification flexibility included in the real-world testing
Condition of Certification (85 FR 25775). This flexibility permits
health IT developers to voluntarily use, in certain certified Health IT
Modules, newer versions of adopted standards so long as specific
conditions are met, providing a predictable and timely approach within
the Certification Program to keep pace with the industry's standards
development efforts.
Under the SVAP, after a standard has been adopted through notice
and comment rulemaking, ONC engages in an open and transparent process
to timely ascertain whether a more recent version of an adopted
standard or implementation specification should be approved by the
National Coordinator for developers' voluntary use under the
Certification Program. ONC lists updated versions of standards that the
National Coordinator has approved on its website.\117\ In addition, as
part of the Interoperability Standards Advisory, ONC publishes updated
versions of standards under consideration for the SVAP process.\118\
Members of the public can use this resource to review standards that
may be approved under the SVAP process in the future, as well as
provide input on which updated versions should be approved. We
encourage impacted payers to review these resources to better
understand the flexibility that may be available to utilize updated
versions of the standards in Sec. Sec. 170.215 and 170.213, provided
these standards have been approved by the National Coordinator through
the SVAP process and meet the other specified conditions for using
updated standards to support compliance with the technical requirements
for payer APIs. CMS emphasizes that if impacted payers choose to use
updated standards, whether approved through the SVAP process or not,
there should not be a disruption to an end user's ability to access the
data.
---------------------------------------------------------------------------

\117\ Standards Version Advancement Process (SVAP), (2022,
August 24). HealthIT.gov. Retrieved from https://www.healthit.gov/topic/standards-version-advancement-process-svap.
\118\ Standards Version Advancement Process, (n.d.).
HealthIT.gov. Retrieved from https://www.healthit.gov/isa/standards-version-advancement-process.
\119\ Standards Version Advancement Process (SVAP), (2022,
August 24). HealthIT.gov. Retrieved from https://www.healthit.gov/topic/standards-version-advancement-process-svap.
---------------------------------------------------------------------------

We note that several updated versions of the standards currently at
Sec. Sec. 170.213 and 170.215 have been approved by the National
Coordinator under the SVAP process,\119\ including the USCDI (Version
2), HL7 FHIR[supreg] US Core

[[Page 76316]]

Implementation Guide (Version 4.0.0 and Version 5.0.1), the HL7
FHIR[supreg] SMART Application Launch Framework Implementation Guide
(Release 2.0.0), and the HL7 FHIR[supreg] Bulk Data Access (Flat
FHIR[supreg]) (v2.0.0: STU 2). As soon as the National Coordinator
approves updated versions through the SVAP process; CMS considers the
updated versions to have met this condition for use under our payer API
requirements. Impacted payers may use these versions as long as the
other conditions finalized in our regulations for the use of updated
versions of the standard, implementation guide, or specification have
also been met.
2. Recommended Standards To Support APIs
In the CMS Interoperability and Patient Access final rule (85 FR
25529), we noted certain IGs that are publicly available for use and
provide implementation information that payers can use to meet the
regulatory requirements for APIs finalized in the rule to support
interoperability and avoid having to develop an approach independently,
saving time and resources. Reference implementations, which are use
case-specific test implementations with test data, have been developed
for these IGs and allow payers to see the APIs in production and
support testing and development. We explained that using the additional
recommended IGs could limit payer burden and support consistent,
interoperable API development and implementation. We referred payers to
information about recommended IGs and related reference implementations
(85 FR 25533). In this proposed rule, we are also recommending specific
implementation guides, including implementation guides relevant to the
new API requirements proposed in this rule, that may be used in
addition to the standards we are proposing to require at 45 CFR
170.215.
In the December 2020 CMS Interoperability proposed rule, we
proposed to require the use of FHIR IGs, including the CARIN IG for
Blue Button[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, Da Vinci Coverage
Requirements Discovery (CRD) IG, Documentation Templates and Rules
(DTR) IG, and Prior Authorization Support (PAS) IG (85 FR 82586) to
support the APIs requirements in the proposed rule. As discussed in
section I.A. of this proposed rule, the December 2020 CMS
Interoperability proposed rule will not be finalized, and we are
withdrawing the proposals included in that rule. We also note that
these FHIR IGs continue to undergo further refinement and development
as part of the HL7 ballot and standard advancement process that are
expected to better support the Patient Access, Provider Access, Payer-
to-Payer, and PARDD APIs.
Additionally, some aspects of the HL7[supreg] FHIR[supreg] DaVinci
PAS IG, notably the FHIR to X12 transactions and use of FHIR
subscriptions, continue to be developed. In the case of the HL7[supreg]
FHIR[supreg] DaVinci PDex US Drug Formulary IG, which was proposed to
support API requirements finalized in the CMS Interoperability and
Patient Access final rule, nuances involving how the data are used in
different ways by payers need to be resolved, such as different co-pay
and co-insurance options and subtleties when searching by brand name,
ingredients, and drug name. Industry stakeholders continue to pursue
production implementations to identify refinements and reconcile
inconsistencies in these IGs to address targeted use cases more
effectively.
After careful ongoing consideration of the IGs, as previously
listed, that were proposed previously in the December 2020 CMS
Interoperability proposed rule, their development cycles, and our role
in advancing interoperability and supporting innovation, we believe
that while these IGs will continue to play a critical role in
supporting our policy, we are not ready to propose them as a
requirement of our interoperability initiatives. We believe these IGs
will continue to be refined over time as stakeholders have the
opportunity to test and implement them, and as such, we are
recommending them for use but are not proposing to require them.
Specifically, we will continue to monitor and evaluate the development
of the IGs and consider whether to propose them as a requirement at
some future date. At this time, we are recommending the use of the
CARIN IG for Blue Button[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, and Da Vinci CRD
IG, DTR IG, PAS IGs for the Patient Access, Provider Access, Provider
Directory, Payer-to-Payer, and PARDD APIs.
We acknowledge that by not requiring the use of all of the
available FHIR IGs, there is potential for implementation variation in
these APIs that could limit interoperability and ultimately lead to re-
work for implementers if requirements are introduced later. However, at
this time, we believe it is more important not to require these IGs
while they are still undergoing additional enhancements. We are
recommending, but not requiring, certain IGs that were previously
proposed because we want to ensure that implementers use subsequent
versions of these IGs without restriction to the version available when
we issue a regulation. As discussed in section II.F.1, we previously
finalized a policy to allow flexibility for the use of updated versions
of certain standards required for the API requirements finalized in the
Patient Access and Interoperability final rule, which we have proposed
to extend to the API requirements proposed in this rule. However, we
understand that the subsequent versions of the recommended IGs may
include substantial changes that would not be consistent with the
requirement included in our flexibility provisions that the use of an
updated standard must not impair access to data through the API.
Therefore, we believe that if we proposed to require the recommended
IGs at this time, impacted payers would not be able to use an updated
version of these IGs unless we were to require the updated versions
through additional rulemaking. We intend to monitor IG development and
may propose to require specific IGs at some future date when there are
versions available for adoption that are mature and more likely to
allow for voluntary updates under our flexibility policies.
We seek comment on whether CMS should propose to require the use of
these IGs for previously finalized and proposed APIs in future
rulemaking and other ways that we could support innovation and
interoperability. In addition, we seek comment on the process CMS
should use to adopt or allow new versions of standards and
implementation specifications over time, as previously discussed. CMS
supports innovation and continued efforts to refine standards in a way
that will leverage the most recent technological advancements.
In making these recommendations, we note that these IGs are
publicly available at no cost to a user. All HL7[supreg] FHIR[supreg]
IGs are developed through an industry-led, consensus-based public
process. HL7[supreg] is an American National Standards Institute
(ANSI)-accredited standards development organization. HL7 FHIR
standards allow disparate systems with different data architectures to
exchange information in a standardized way via standards-based APIs.
HL7 FHIR IGs are also openly available, so that any interested party
can access a HL7 FHIR IG on the HL7 website. All public comments made
during the HL7 balloting process and the IG version

[[Page 76317]]

history, are available for review. This way, all stakeholders can fully
understand the lifecycle of a given IG. Using IGs developed through
such a public process facilitates a transparent and cost-effective path
to interoperability that ensures the IGs are informed and approved by
industry participants looking to use technology to improve patient
care.
A few of the recommended FHIR IGs have been developed by HL7 FHIR
Accelerator programs,\120\ which bring together individuals across the
industry to create and adopt IGs that are aligned with HL7, allowing
new and revised requirements to have the potential to become open
industry standards. Under HL7 FHIR Accelerators, industry stakeholders
have facilitated the definition, design, and creation of use-case-
specific reference implementations based on the HL7 FHIR platform to
address value-based care initiatives. Some HL7 FHIR Accelerators, such
as Da Vinci and CARIN, have created IGs that we recommend be used to
meet the previously finalized and proposed requirements for the Patient
Access, Provider Directory, Provider Access, and Payer to Payer APIs.
The Da Vinci project was established in 2018 to help payers and
providers positively impact clinical, quality, cost, and care
management outcomes.\121\ The CARIN Alliance works collaboratively with
Government stakeholders to overcome barriers to advancing consumer-
directed exchange across the U.S.\122\
---------------------------------------------------------------------------

\120\ HL7 FHIR Accelerator\TM\ Program (n.d.). HL7
International. Retrieved from https://www.hl7.org/about/fhir-accelerator/index.cfm.
\121\ Da Vinci Project (n.d.). HL7 International. Retrieved from
https://www.hl7.org/about/davinci/.
\122\ CARIN Alliance (n.d.). HL7 International. Retrieved from
https://www.hl7.org/carin/.
---------------------------------------------------------------------------

While we are recommending the IGs proposed previously in the
December 2020 CMS Interoperability proposed rule as discussed, we
welcome further information about the maturity of these IGs, including
considerations about further development that would be needed prior to
CMS requiring the use of specific IGs.
3. Proposed Standards To Support APIs
Using IGs supports consistent implementations across the industry.
Therefore, we are proposing at the CFR citations identified in Table 8
to require that impacted payers use API technology conformant with the
standards at 45 CFR 170.215 that we propose as applicable for each set
of API requirements. We include Table 10 to provide a clear outline of
which standards we are proposing to require and which IGs we recommend
for each proposed API.
BILLING CODE 4120-01-P

[[Page 76318]]

[GRAPHIC] [TIFF OMITTED] TP13DE22.008

[[Page 76319]]

[GRAPHIC] [TIFF OMITTED] TP13DE22.009

[[Page 76320]]

[GRAPHIC] [TIFF OMITTED] TP13DE22.010

[[Page 76321]]

[GRAPHIC] [TIFF OMITTED] TP13DE22.011

BILLING CODE 4120-01-C

III. Requests for Information

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

The December 2020 CMS Interoperability proposed rule (85 FR 82586)
included several requests for information, including one regarding
standards for social risk factor data. We received several comments
requesting additional time to comment on this issue, and thus we are
reissuing the request for information, with modification to add
additional questions in this section.
Social determinants of health (SDOH) as defined by Healthy People
2030 are ``the conditions in the environments where people are born,
live, learn, work, play, worship, and age that affect a wide range of
health, functioning, and quality-of-life outcomes and risks.'' \123\
Social risk factors are those that can lead to unmet social needs that
directly influence an individual's physical, psychosocial, and
functional status.\124\ These can include homelessness, food
insecurity, lack of access to transportation, and low levels of health
literacy.\125\ When these are immediate and pressing needs, these
social risk factors may be called unmet social needs, or health-related
social needs. Understanding social risk factors and individuals'
immediate unmet needs can help healthcare systems, plans, providers,
and other partners target interventions to address these specific
factors.
---------------------------------------------------------------------------

\123\ U.S. Department of Health and Human Services Office of
Disease Prevention and Health Promotion. Healthy People 2030.
Retrieved from https://health.gov/healthypeople.
\124\ 87 FR 27704 (May 9, 2022). Retrieved https://www.federalregister.gov/documents/2022/05/09/2022-09375/medicare-program-contract-year-2023-policy-and-technical-changes-to-the-medicare-advantage-and.
\125\ Ibid.
---------------------------------------------------------------------------

CMS recognizes that social risk factors impact patient health,
utilization, and outcomes, and that these factors can have a direct
impact on our healthcare system as a whole. To the extent that
healthcare providers and payers have access to data on social risk
factors, they are best equipped to address these factors, and thus have
a positive impact on patient health. Healthcare providers in value-
based payment arrangements rely on comprehensive, high-quality data to
identify opportunities to improve patient care and drive value. When
implemented effectively, value-based payment encourages healthcare
providers to care for the whole person and address the social risk
factors that are critical for patient quality of life.
As value-based payment has grown, so has provider community
interest in social risk factor data.\126\ A recent study \127\ found
that approximately 24 percent of hospitals and 16 percent of physician
practices were screening patients for five health-related social needs
(housing, food, transportation, utilities, and interpersonal safety
needs). These findings suggest that healthcare providers can use these
data to inform care and ensure patients get the services and support
they need to address social risk factors and achieve better health
outcomes.
---------------------------------------------------------------------------

\126\ American Medical Association (Nov. 2020). AMA urges
multifaceted approach to address social determinants of health.
Retrieved from https://www.ama-assn.org/press-center/press-releases/ama-urges-multifaceted-approach-address-social-determinants-health.
\127\ Fraze, T., Brewster, A., Lewis, V., Beidler, L., Murray,
G., & Colla, C. (2019). Prevalence of screening for food insecurity,
housing instability, utility needs, transportation needs, and
interpersonal violence by US physician practices and hospitals. JAMA
network open. Retrieved from https://pubmed.ncbi.nlm.nih.gov/31532515/.
---------------------------------------------------------------------------

Unfortunately, social risk factor data are often fragmented,
unstandardized, out of date, and duplicative. These circumstances are a
result of a lack of clear standards for capturing, recording, and
exchanging these data. While the International Classification of
Diseases, Tenth Revision, Clinical Modification (ICD-10-CM)
psychosocial risk and economic determinant-related codes (``Z codes'')
can be used to capture standardized information on social determinants
of health, utilization on Medicare claims remains relatively low for a
number of reasons, including a

[[Page 76322]]

lack of financial incentives to record them and the limited number of
available codes and sub-codes.\128\ If these data are not exchanged
between healthcare providers caring for an individual, these providers
who do not or cannot exchange these data with each other may ask the
same patient similar questions, or hospitals within a single system may
all collect data on the same health-related social needs in different
formats. Additionally, relevant data collected without the use of
standards to facilitate interoperability by community-based
organizations outside the health sector can be difficult for other
healthcare and social care providers to integrate and utilize. Siloed
social risk factor data may increase the burden on patients, as well as
healthcare providers and the healthcare system overall by creating
inefficiencies in managing referrals for social services and
duplicative and conflicting workflows in an already strained system.
Non-interoperable information flows may impede opportunities to provide
higher quality care and result in missed opportunities to address the
root causes of poor health outcomes and health inequities.
---------------------------------------------------------------------------

\128\ Centers for Medicare & Medicaid Services Office of
Minority Health (Sep. 2021). Utilization of Z Codes for Social
Determinants of Health among Medicare Fee-for-Service Beneficiaries,
2019. Retrieved from https://www.cms.gov/files/document/z-codes-data-highlight.pdf.
---------------------------------------------------------------------------

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

\129\ HL7 International. Gravity Project. Retrieved from https://www.hl7.org/gravity/.
\130\ Morton, A., Taylor, A., Meklir, S., & Barker, W. (2019,
December 12). Advancing interoperable social determinants of health
data. Retrieved from https://www.healthit.gov/buzz-blog/interoperability/advancing-interoperable-social-determinants-of-health-data.
\131\ HealthIT.gov. United States Core Data for Interoperability
(USCDI). Retrieved from https://www.healthit.gov/isa/united-states-core-data-interoperability-uscdi.
\132\ Office of the National Coordinator for Health Information
Technology (2021, July). United States Core Data for
Interoperability Version 2. Retrieved from https://www.healthit.gov/isa/sites/isa/files/2021-07/USCDI-Version-2-July-2021-Final.pdf.
---------------------------------------------------------------------------

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

\133\ The White House (2021, January 25). Executive Order 13985
of January 20, 2021 Advancing Racial Equity and Support for
Underserved Communities Through the Federal Government. 86 FR 7009
(January 25, 2021). Retrieved from https://www.federalregister.gov/documents/2021/01/25/2021-01753/advancing-racial-equity-and-support-for-underserved-communities-through-the-federal-government.
---------------------------------------------------------------------------

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

[[Page 76323]]

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

B. Electronic Exchange of Behavioral Health Information

The December 2020 CMS Interoperability proposed rule (85 FR 82586)
included several requests for information, including a request for
information regarding electronic data exchange among behavioral health
providers (85 FR 82637). We received several comments requesting
additional time to comment on this particular issue, and thus we are
reissuing the request for information, with modification to add
additional questions in this section of this proposed rule.
Several factors have led behavioral health providers to adopt EHRs
at a significantly lower rate than other types of healthcare providers.
One possible contributing factor was that the Health Information
Technology for Economic and Clinical Health Act (HITECH Act), enacted
as part of the American Recovery and Reinvestment Act of 2009 (Pub. L.
111-5) on February 17, 2009, made Medicare FFS and Medicaid incentive
payments for the adoption and meaningful use of CEHRT available only to
eligible professionals, eligible hospitals, and CAHs, so behavioral
health providers that did not meet those criteria were ineligible for
these incentive payments. For example, while behavioral health
providers who were physicians (eligible professionals) could receive
the incentive payments, other types of non-physician behavioral health
providers may not have been eligible. Congress created another
potential opportunity to address this issue when it enacted the
Substance Use-Disorder Prevention that Promotes Opioid Recovery and
Treatment for Patients and Communities Act (SUPPORT Act) (Pub. L. 115-
271) on October 24, 2018. Section 6001 of the SUPPORT Act modifies an
existing list of possible model opportunities the Center for Medicare &
Medicaid Innovation may consider testing to include models to provide
incentive payments to behavioral health providers for adopting EHRs.
Today, behavioral health providers lag behind their peers in the
ability to electronically share health information across providers and
with patients. ONC noted that, in 2017, only 14 percent of office-based
physicians reported sending data to behavioral health providers, while
12 percent of office-based physicians reported receiving data from
behavioral health providers.\134\ Other regulatory restrictions, such
as 42 CFR part 2, which governs the confidentiality of substance use
disorder patient records maintained by certain entities, or more
restrictive state laws,\135\ can also inhibit the exchange of
behavioral health information.
---------------------------------------------------------------------------

\134\ Office of the National Coordinator (May 2019).
Interoperability among Office-Based Physicians in 2015 and 2017. ONC
Data Brief No. 48. Retrieved from https://www.healthit.gov/sites/default/files/page/2019-05/2015to2017PhysicianInteroperabilityDataBrief_0.pdf.
\135\ For example, see Pa. Cons. Stat. Ann. tit. 71, sec.
1690.108(b), https://www.health.state.pa.us/pdf/act63.pdf.
---------------------------------------------------------------------------

Understanding the time and cost of implementing an EHR system, we
are interested in evaluating whether using other applications that
exchange data using the FHIR APIs and do not require implementation of
a full EHR system might be a way to help behavioral health providers
leverage technology to exchange health data to improve care quality and
coordination in a more agile fashion. Specifically, would small
practices and community-based providers be able to more quickly adopt
applications using API technology to exchange health information when
the technology is not tied to an EHR? Would these providers be able to
achieve the same care coordination goals using such applications as
with a more extensive EHR implementation, or would the value be lower
but still sufficient to improve care quality and care coordination?
The Substance Abuse and Mental Health Services Administration
(SAMHSA) published regulations related to improved care coordination
among providers that treat substance use disorders as well as
protecting those patients' records (42 CFR part 2). Section 6001 of the
SUPPORT Act also encourages CMS to consider ways to facilitate
information sharing among behavioral health providers by adding a model
opportunity to the list of possible model opportunities for
consideration by the CMS Center for Medicare & Medicaid Innovation
under section 1115A(b)(2)(B) of the Act. We are looking for innovative
approaches to addressing the need to facilitate the electronic exchange
of behavioral health information, as well as approaches to support the
exchange of health information to behavioral health providers to inform
care and provision of behavioral health services.
ONC has been working with other Federal agencies to consolidate
input to help inform approaches HHS can take to advance behavioral
healthcare delivery and coordination supported by health IT, through
the development of action items and high impact projects including to
support behavioral health integration consistent with the HHS Roadmap
for Behavioral Health Integration.\136\ Information about projects such
as Health Information Exchange and Behavioral Health Care and the Rhode
Island Behavioral and Medical Information Exchange Project are
available on the ONC website at https://www.healthit.gov.\137\
---------------------------------------------------------------------------

\136\ Assistant Secretary for Planning and Evaluation (Sep.
2022). HHS Roadmap for Behavioral Health Integration. Retrieved from
https://aspe.hhs.gov/sites/default/files/documents/84a701e0878bc26b2812a074aa22a3e2/roadmap-behavioral-health-integration.pdf.
\137\ The Office of the National Coordinator for Health
Information Technology (ONC). Behavioral Health. Retrieved from
https://www.healthit.gov/topic/behavioral-health.
---------------------------------------------------------------------------

Many behavioral health providers practice in community-based roles.
As a result, when considering behavioral health specifically, it is
valuable to consider community-based providers more broadly.
We are interested in public comments on how we might best support
electronic data exchange of behavioral health information between and
among behavioral health providers, other healthcare providers, and
patients, as well as how we might best inform and

[[Page 76324]]

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

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

In the Medicare FFS program, the ordering provider or supplier can
often be different than the rendering provider or supplier of items or
services, which may contribute to challenges in the coordination of
patient care and exchange of medical information needed to ensure
accurate and timely payment. Unlike their physician and hospital
counterparts, providers such as home health agencies, Durable Medical
Equipment, Prosthetics, Orthotics, and Supplies (DMEPOS) suppliers, and
ambulance providers were not included in the American Reinvestment and
Recovery Act (ARRA) Health Information Technology for Economic and
Clinical Health (HITECH) Act programs, so they were not eligible for
the same incentive payments for health IT adoption and interoperable
data exchange as other providers. Thus, some providers or suppliers
continue to use the U.S. Postal Service or fax machines to send patient
information, and these methods can also lead to delays in the receipt
of orders, prior authorization decisions, and payments. Ideally, health
IT and the electronic exchange of information would streamline
information-sharing processes between ordering and rendering providers
or suppliers so that any impediments are eliminated.
For example, with DMEPOS suppliers, a physician or non-physician
practitioner (NPP) may order a power wheelchair and document the
necessary information in the beneficiary's medical record, but the
DMEPOS provider will provide the wheelchair and submit the claim for
payment. For some DMEPOS items, a written order is required prior to
delivery.\138\ This dynamic often necessitates significant coordination
between the ordering provider or supplier and the rendering provider to
exchange information before the item or service can be provided to the
beneficiary so that the rendering provider has the documentation from
the ordering provider or supplier that demonstrates that the furnishing
of the item or service meets CMS coding, coverage, payment or
documentation requirements. The rendering provider or supplier must
submit documentation of the patient's medical condition to justify why
a patient requires a specific item or service and/or in order to meet
CMS requirements. This helps to ensure that beneficiaries are receiving
medically necessary care that meets CMS requirements. This information
is usually documented in the ordering provider or supplier's medical
record. The rendering provider or supplier must obtain this information
from the ordering provider or supplier to furnish the item, and submit
a claim or prior authorization request. The timing of a beneficiary
receiving a service or item could be dependent on the ordering provider
or supplier sending the documentation to the rendering provider in
advance, as their claims are not dependent on sending these data.
---------------------------------------------------------------------------

\138\ Centers for Medicare & Medicaid Services (Apr. 2022).
Required face-to-face encounter and written order prior to delivery
list. Retrieved from https://www.cms.gov/files/document/required-face-face-encounter-and-written-order-prior-delivery-list.pdf.
---------------------------------------------------------------------------

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

[[Page 76325]]

places more burden on the rendering provider to obtain the necessary
information and engage in multiple follow-ups--and can result in delays
in the patient receiving the item or service.
The inconsistent use and lack of uniform health IT to exchange
medical documentation will take time to effectively resolve. In the
interim, we are interested in public comments on how Medicare FFS might
best support improvements to the exchange of medical documentation
between and among providers or suppliers and patients, as well as how
we might best inform and support the movement of health data (and its
consistency) to providers or suppliers for their use to inform care and
treat beneficiaries. We are also interested in public comments on what
specific changes or improvements in health IT could assist providers or
suppliers in submitting medical documentation to CMS and its
contractors so that claims are not denied and/or are not deemed
improper payments. Specifically, we are seeking public comments on the
following questions:
How might CMS encourage more electronic exchange of
medical information (for example, orders, progress notes, prior
authorization requests, and/or plans of care) between providers/
suppliers and with CMS and its contractors at the time an item or
service is ordered? When possible, please describe specific
recommendations to facilitate improved data exchange between providers
or suppliers, and with CMS and its contractors, to support more
efficient, timely, and accurate claims and prior authorization
communications. Are there specific process changes that you believe
would improve the exchange of medical documentation between ordering
and rendering providers or suppliers? Are there particular policy,
technical, or other needs that must be accounted for in light of the
unique roles of ordering and rendering providers or suppliers?
Are there changes necessary to health IT to account for
the need for providers/suppliers (ordering and rendering) to exchange
medical documentation, either to improve the process in general or to
expedite processing to ensure beneficiary care is not delayed? How
could existing certification criteria or updates to certification
criteria under the ONC Health IT Certification program support specific
exchange needs?
What additional steps in the area of health IT and the
exchange of information could CMS take to assist providers or suppliers
in the claim submission process? Are there changes in technology or
processes that could also reduce the number of claims re-submissions
and/or improper payments?
What levers could CMS consider using to facilitate greater
collaboration and exchange of information among providers/suppliers?
What costs, resources, and/or burdens are associated with this type of
collaboration? Are there changes that could reduce improper payments
and the administrative burden often encountered by rendering providers/
suppliers who need medical record documentation from ordering providers
or suppliers?
Are there state or Federal regulations or payment rules
that are perceived as creating barriers to the exchange of information
between ordering and rendering providers/suppliers? What additional
policy issues, technical considerations, and operational realities
should we consider when looking at ways to best facilitate the secure
exchange of information between providers or suppliers and with
Medicare FFS?
We seek comments on these questions and issues for future
consideration.

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

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

\139\ The White House (Apr. 2022). A Proclamation on Black
Maternal Health Week, 2022. 87 FR 22095 (April 8, 2022). Retrieved
from https://www.whitehouse.gov/briefing-room/presidential-actions/2022/04/08/a-proclamation-on-black-maternal-health-week-2022/.
\140\ The White House (Dec. 2021). Fact Sheet: Vice President
Kamala Harris Announces Call to Action to Reduce Maternal Mortality
and Morbidity. Retrieved from https://www.whitehouse.gov/briefing-room/statements-releases/2021/12/07/fact-sheet-vice-president-kamala-harris-announces-call-to-action-to-reduce-maternal-mortality-and-morbidity/.
\141\ The White House (Jun. 2022). White House Blueprint for
Addressing the Maternal Health Crisis. Retrieved from https://www.whitehouse.gov/wp-content/uploads/2022/06/Maternal-Health-Blueprint.pdf.
---------------------------------------------------------------------------

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

\142\ Centers for Medicare & Medicaid Services. Cross-Cutting
Initiative: CMS Maternity Care Action Plan. Retrieved from https://www.cms.gov/files/document/cms-maternity-care-action-plan.pdf.
\143\ Centers for Medicare & Medicaid Services (Oct. 2022).
Biden-Harris Administration Announces More than Half of All States
Have Expanded Access to 12 Months of Medicaid and CHIP Postpartum
Coverage. Retrieved from https://www.cms.gov/newsroom/press-releases/biden-harris-administration-announces-more-half-all-states-have-expanded-access-12-months-medicaid.
---------------------------------------------------------------------------

The CMS Maternity Care Action Plan also expressed intentions to
coordinate across programs to identify gaps and best practices.
Technology can be leveraged to address known racial disparities to
prenatal and postnatal care by facilitating telehealth visits or remote
monitoring options. For example, research has shown leveraging
technology and telehealth significantly reduced the racial disparities
in blood pressure ascertainment.\144\ Some state Medicaid agencies are
leveraging the enhanced Federal financial participation (FFP),
available under section 1903(a)(3) of the Act and

[[Page 76326]]

regulations at 42 CFR 433.111, to procure remote monitoring and
telehealth capabilities to address this inequity and expand access to
remote blood pressure monitoring, behavioral health consultations,
lactation consultations, blood glucose monitoring, etc. CMS seeks
comments on how we might further support these state efforts with that
enhanced FFP system.
---------------------------------------------------------------------------

\144\ Yarrington, C., Parker, S., & Mujic, E. (Apr. 2022).
Abstract EP50: Implementation of A Cloud-Connected Remote Blood
Pressure Monitoring Program During the Postpartum Period Improves
Ascertainment. Retrieved from https://www.ahajournals.org/doi/10.1161/circ.145.suppl_1.EP50.
---------------------------------------------------------------------------

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

\145\ Department of Health and Human Services, Centers for
Medicare & Medicaid Services (Aug 2021). 86 FR 44774 (August 13,
2021). Retrieved from https://www.federalregister.gov/documents/2021/08/13/2021-16519/medicare-program-hospital-inpatient-prospective-payment-systems-for-acute-care-hospitals-and-the.
\146\ Centers for Medicare & Medicaid Services. Maternal
Morbidity Structural Measure. Retrieved from https://www.cms.gov/files/document/maternal-morbidity-structural-measure-specifications.pdf.
\147\ Alliance for Innovation on Maternal Health. Patient Safety
Bundles. Retrieved from https://saferbirth.org/patient-safety-bundles/.
\148\ Department of Health and Human Services, Centers for
Medicare & Medicaid Services (Aug 2022). Retrieved from https://www.federalregister.gov/documents/2022/08/10/2022-16472/medicare-program-hospital-inpatient-prospective-payment-systems-for-acute-care-hospitals-and-the.
---------------------------------------------------------------------------

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

\149\ Centers for Medicare & Medicaid Services (2022). 2022 Core
Set of Maternal and Perinatal Health Measures for Medicaid and CHIP
(Maternity Core Set. Retrieved from https://www.medicaid.gov/medicaid/quality-of-care/downloads/2022-maternity-core-set.pdf.
---------------------------------------------------------------------------

In addition to measurement data, which helps us to better
understand the state of maternal healthcare in our various programs,
CMS also believes that a critical foundation comprised of health IT,
data sharing, and interoperability underlie many opportunities to
improve maternal health outcomes. CMS is now seeking information from
the public on evidence-based policies we could pursue that leverage
information technology to improve such outcomes.
Health IT can be used to support safe and effective maternal and
child healthcare. The ONC Pediatric Health Information Technology:
Developer Informational Resource \150\ is an HHS non-regulatory
initiative to inform the technical and implementation specifications
for health IT developers of products used by clinicians that provide
healthcare for children that includes recommendations specific to
maternal health. CMS invites input on stakeholder experiences with this
informational resource and comments on how to advance this work.
---------------------------------------------------------------------------

\150\ Office of the National Coordinator for Health Information
Technology (ONC) (Jun 2020). Pediatric Health Information
Technology: Developer Informational Resource. Retrieved from https://www.healthit.gov/sites/default/files/page/2020-06/Pediatric-Health-IT-Developer-IR-06102020.pdf.
---------------------------------------------------------------------------

Using common data exchange standards for human services information
can also provide many benefits for supporting maternal healthcare,
including, but not limited to, promoting greater information-sharing
and interoperability, collaboration with other human services sectors
beyond healthcare such as education and public safety, and overall
improvements to systems for the effective use of technology. CMS
welcomes input on technical and policy approaches that effectively link
maternal human services data to health IT codes and value sets, such as
ICD-10 and LOINC codes, in order to help improve interoperability
across multiple systems, domains, and use cases, including the
effective use of interoperable assessment instruments. CMS further
welcomes input on how other health IT standards, such as FHIR, can be
used to expand healthcare interoperability to integrate with human
services for individual maternal health and overall population health
improvement.
The USCDI version 3, published in July 2022, contains a new data
class on pregnancy status, as well as other data classes and elements
important for supporting maternal health, including SDOH Assessment,
Diagnostic Imaging, and Vital Signs.\151\ While exchange of the USCDI
version 3 dataset is neither currently required nor proposed in this
proposed rule, we intend to work with both our Federal partners and
industry stakeholders to encourage harmonization of data elements tied
to improved maternal health outcomes.
---------------------------------------------------------------------------

\151\ Office of the National Coordinator for Health Information
Technology (Jul. 2022). United States Core Data for
Interoperability. Retrieved from https://www.healthit.gov/isa/sites/isa/files/2022-07/USCDI-Version-3-July-2022-Final.pdf.
---------------------------------------------------------------------------

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

\152\ Argentieri et al., 2021. HealthITbuzz. Thinking Outside
the Box: The USCDI+ Initiative. Retrieved from https://www.healthit.gov/buzz-blog/health-it/thinking-outside-the-box-the-uscdi-initiative.
---------------------------------------------------------------------------

Are there other data elements and classes relevant to care
coordination for maternal health that should be added to USCDI?
Are there data related to maternal health that are
currently not collected at scale, or not collected at all, that would
be helpful for stakeholders to have

[[Page 76327]]

access to? How could CMS support the collection of this data?
What are key gaps in the standardization and harmonization
of maternal health data? How can HHS support current efforts to address
these gaps?
How could an initiative such as USCDI+ be leveraged to
harmonize maternal health data needed for care coordination, quality
measurement, and other Federal programs that collect maternal health
data?
In section II.D of this proposed rule, we discuss our proposals to
improve prior authorizations. In addition to the impacts on patient
care in general discussed in that section, we note the effects of
inefficient prior authorizations on maternal health, specifically. For
instance, maternal care experts have observed that some payers may
utilize an intermediary, such as a radiology benefits management
company, to act on their behalf to review healthcare provider requests
to perform imaging. This may add an additional waiting period for a
decision, potentially creating hazardous delays for pregnant women who,
for example, need to obtain an ultrasound.\153\ Furthermore, requiring
prior authorization for screening cervical length in patients with a
prior history of preterm birth or growth ultrasound for women at risk
for fetal growth restriction can place patients at risk for adverse
perinatal outcomes.\154\ We are therefore interested in stakeholder
feedback on the following questions:
---------------------------------------------------------------------------

\153\ Jain et al., 2020. Prior Authorization and its impact on
access to obstetric ultrasound. Retrieved from https://www.sciencedirect.com/science/article/pii/S0002937820300260?via%3Dihub#bib5.
\154\ Ibid.
---------------------------------------------------------------------------

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

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

Section 4003(b) of the 21st Century Cures Act (Pub. L. 114-255),
enacted in 2016, amended section 3001(c) of the Public Health Service
Act (42 U.S.C. 300jj-11(c)) and required HHS to take steps to advance
interoperability for the purpose of ensuring full network-to-network
exchange of health information. Specifically, Congress directed the
National Coordinator to ``develop or support a trusted exchange
framework, including a common agreement among health information
networks nationally.'' Since the enactment of the 21st Century Cures
Act, HHS has pursued the development of TEFCA. ONC's goals for TEFCA
are:
Goal 1: Establish a universal policy and technical floor for
nationwide interoperability.
Goal 2: Simplify connectivity for organizations to securely
exchange information to improve patient care, enhance the welfare of
populations, and generate healthcare value.
Goal 3: Enable individuals to gather their healthcare
information.\155\
---------------------------------------------------------------------------

\155\ Tripathi, M (2022, January 18). 3 . . . 2 . . . 1 . . .
TEFCA is Go for Launch. Health IT Buzz. Retrieved from https://www.healthit.gov/buzz-blog/interoperability/321tefca-is-go-for-launch.
---------------------------------------------------------------------------

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

\156\ The Trusted Exchange Framework (TEF): Principles for
Trusted Exchange (2022, January). HealthIT.gov. Retrieved from
https://www.healthit.gov/sites/default/files/page/2022-01/Trusted_Exchange_Framework_0122.pdf.
\157\ Common Agreement for Nationwide Health Information
Interoperability Version 1 (Jan. 2022). HealthIT.gov. Retrieved from
https://www.healthit.gov/sites/default/files/page/2022-01/Common_Agreement_for_Nationwide_Health_Information_Interoperability_Version_1.pdf.
\158\ TEFCA: Qualified Health Information Network (QHIN)
Technical Framework (QTF) Version 1.0 (2022, January).
SequoiaProject.org. https://rce.sequoiaproject.org/wp-content/uploads/2022/01/QTF_0122.pdf.
\159\ The Common Agreement defines a QHIN as ``to the extent
permitted by applicable SOP(s), a Health Information Network that is
a U.S. Entity that has been Designated by the RCE and is a party to
the Common Agreement countersigned by the RCE.'' See Common
Agreement for Nationwide Health Information Interoperability Version
1, at 10 (Jan. 2022), https://www.healthit.gov/sites/default/files/page/2022-.
\160\ In August 2019, ONC awarded a cooperative agreement to The
Sequoia Project to serve as the initial RCE. The RCE will
operationalize and enforce the Common Agreement, oversee QHIN-
facilitated network operations, and ensure compliance by
participating QHINs. The RCE will also engage stakeholders to create
a roadmap for expanding interoperability over time. See ONC Awards
The Sequoia Project a Cooperative Agreement for the Trusted Exchange
Framework and Common Agreement to Support Advancing Nationwide
Interoperability of Electronic Health Information (September 3,
2019), https://sequoiaproject.org/onc-awards-the-sequoia-project-a-cooperative-agreement-for-the-trusted-exchange-framework-and-common-agreement-to-support-advancing-nationwide-interoperability-of-electronic-health-information/.
---------------------------------------------------------------------------

The technical and policy architecture of how exchange occurs under
the Common Agreement follows a network-of-networks structure, which
allows for connections at different levels and is inclusive of many
different types of entities at those different levels, such as HINs,
care practices, hospitals, public health agencies, and Individual
Access Services (IAS) \161\ Providers.\162\ QHINs connect directly to
each other to facilitate nationwide interoperability, and each QHIN can
connect Participants, which can connect Subparticipants.\163\ Compared
to most

[[Page 76328]]

nationwide exchange today, the Common Agreement includes an expanded
set of Exchange Purposes beyond Treatment to include IAS, Payment,
Health Care Operations, Public Health, and Government Benefits
Determination \164\--all built upon common technical and policy
requirements to meet key needs of the U.S. healthcare system. This
flexible structure allows stakeholders to participate in the way that
makes the most sense for them, while supporting simplified, seamless
exchange. The Common Agreement also requires strong privacy and
security protections for all entities who elect to participate,
including entities not covered by HIPAA.\165\ For the purposes of this
RFI, we broadly refer to different modes of exchange by different
stakeholders under this framework as, ``enabling exchange under
TEFCA.''
---------------------------------------------------------------------------

\161\ The Common Agreement defines Individual Access Services
(IAS) as ``with respect to the Exchange Purposes definition, the
services provided utilizing the Connectivity Services, to the extent
consistent with Applicable Law, to an Individual with whom the QHIN,
Participant, or Subparticipant has a Direct Relationship to satisfy
that Individual's ability to access, inspect, or obtain a copy of
that Individual's Required Information that is then maintained by or
for any QHIN, Participant, or Subparticipant.'' See Common Agreement
for Nationwide Health Information Interoperability Version 1, at 7
(Jan. 2022), https://www.healthit.gov/sites/default/files/page/2022-01/Common_Agreement_for_Nationwide_Health_Information_Interoperability_Version_1.pdf.
\162\ The Common Agreement defines ``IAS Provider'' as: ``Each
QHIN, Participant, and Subparticipant that offers Individual Access
Services.'' See Common Agreement for Nationwide Health Information
Interoperability Version 1, at 7 (Jan. 2022), https://www.healthit.gov/sites/default/files/page/2022-01/Common_Agreement_for_Nationwide_Health_Information_Interoperability_Version_1.pdf.
\163\ For the Common Agreement definitions of QHIN, Participant,
Subparticipant, Treatment, Payment, Health Care Operations, Public
Health, and Government Benefits Determination, see Common Agreement
for Nationwide Health Information Interoperability Version 1, at 3-
13 (Jan. 2022), https://www.healthit.gov/sites/default/files/page/2022-01/Common_Agreement_for_Nationwide_Health_Information_Interoperability_Version_1.pdf.
\164\ Ibid.
\165\ Common Agreement for Nationwide Health Information
Interoperability Version 1 (Jan. 2022). HealthIT.gov. Retrieved from
https://www.healthit.gov/sites/default/files/page/2022-01/Common_Agreement_for_Nationwide_Health_Information_Interoperability_Version_1.pdf.
---------------------------------------------------------------------------

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

\166\ ``Health Information Network'' under the Common Agreement
has the meaning assigned to the term ``Health Information Network or
Health Information Exchange'' in the information blocking
regulations at 45 CFR 171.102.
---------------------------------------------------------------------------

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

\167\ FHIR Roadmap for TEFCA Exchange Version 1, at 4 (Jan.
2022), https://rce.sequoiaproject.org/wp-content/uploads/2022/01/FHIR-Roadmap-v1.0_updated.pdf.
---------------------------------------------------------------------------

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

\168\ Retrieved from https://www.federalregister.gov/documents/2022/08/10/2022-16472/medicare-program-hospital-inpatient-prospective-payment-systems-for-acute-care-hospitals-and-the.
\169\ Revisions to Payment Policies under the Medicare Physician
Fee Schedule, Quality Payment Program and Other Revisions to Part B
Proposed Rule for CY 2023 (CMS-1770-P). 87 FR 45860 (September 6,
2022). Retrieved from https://-www.federalregister.gov/d/2022-14562.
---------------------------------------------------------------------------

We believe that the ability for stakeholders to connect to an
entity that connects to a QHIN, or to connect directly to a QHIN, can
support and advance the payer requirements that we have proposed in
this rule that would become applicable by 2026 if enacted as proposed.
Specifically, such connections could support exchange of patient
information with providers via the Provider Access API and support
transmission of coverage and prior authorization requests from
providers via the PARDD API. As requirements for use of FHIR are
incorporated into the QTF, stakeholders that enable exchange under
TEFCA will be better positioned to not only exchange the data we
propose to require for these APIs, but also to do so in a multi-
networked environment that simplifies connections between providers and
payers. We similarly believe that such connections could support
requirements for the Patient Access API previously finalized in the CMS
Interoperability and Patient Access final rule (85 FR 25510) by
enabling patients to access their information held by the payer, as
well. As previously noted, TEFCA can be a strong catalyst for FHIR
maturation. To the extent that TEFCA evolves in accordance with the
FHIR Roadmap for TEFCA Exchange, we anticipate further opportunities
for TEFCA to support information availability via FHIR API exchange
requirements for payers.
We believe enabling exchange under TEFCA by payers and vendors
offering health apps could provide a simplified way for vendors to
access and make information available to their customers. By accessing
payer-held information through a QHIN or an entity connected to a QHIN,
health apps could avoid the need to develop direct connections to each
individual payer. This is because such apps could connect once and
enable patients to gain access to information held by any payer
exchanging information under TEFCA. Furthermore, as discussed in
section II.A., apps that enable exchange under TEFCA would be required
to meet the Common Agreement's privacy and security requirements,\170\
which would provide assurance to payers that they meet a common
standard for protecting patient data.
---------------------------------------------------------------------------

\170\ Privacy and security are addressed in numerous ways
throughout the Common Agreement. Relevant sections for this
discussion include Section 10, ``Individual Access Services
(Required Flow-Downs, if Offering Individual Access Services);''
Section 11, ``Privacy;'' and Section 12, ``Security.'' See Common
Agreement for Nationwide Health Information Interoperability Version
1 (Jan. 2022), https://www.healthit.gov/sites/default/files/page/2022-01/Common_Agreement_for_Nationwide_Health_Information_Interoperability_Version_1.pdf.
---------------------------------------------------------------------------

Enabling exchange under TEFCA by health plans could also support
the proposed requirements in section II.C.

[[Page 76329]]

of this proposed rule for a payer to payer data exchange using FHIR
APIs under which payers would make beneficiary information available to
other plans when patients change their coverage. Health plans that
enable exchange under TEFCA could easily identify other plans that hold
information about a newly covered beneficiary by querying the network
and securely requesting the information that would be required to be
shared under our proposed requirements for the payer to payer data
exchange.
We are requesting input from the public on the ideas previously
described in this section and related concepts for future exploration,
as well as the following questions:
How could the requirements of the Common Agreement and the
QTF help facilitate information exchange in accordance with the final
policies in the CMS Interoperability and Patient Access final rule (85
FR 25510) around making clinical and administrative information held by
health plans available to patients? How could TEFCA support proposed
requirements for payers under this rule related to provider data access
and prior authorization processes?
How should CMS approach incentivizing or encouraging
payers to enable exchange under TEFCA? Under what conditions would it
be appropriate to require this approach by payers subject to the
proposed regulations in this rule and previously finalized regulations
in the CMS Interoperability and Patient Access final rule (85 FR
25510)?
What concerns do commenters have about potential
requirements related to enabling exchange under TEFCA? Could such an
approach increase burden for some payers? Are there other financial or
technical barriers to this approach? If so, what should CMS do to
reduce these barriers?
We seek comments on these questions and issues for future
consideration.

V. Collection of Information Requirements

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

A. Background

To advance our commitment to interoperability, we are proposing new
requirements for certain impacted payers to implement FHIR APIs and
several process improvements to help streamline the prior authorization
process. The proposed FHIR APIs would permit patients, providers, and
payers to access a defined set of standardized data. We additionally
propose to require impacted payers to implement a FHIR Prior
Authorization Requirements, Documentation, and Decision (PARDD) API to
support prior authorization processes; to reduce the amount of time to
process prior authorization requests and send information about
decisions; and to publicly report certain metrics about patient access
utilization, and prior authorization processes, among other proposals.
We also propose a new requirement for a Payer-to-Payer API to ensure
data can follow patients when they change payers. Finally, we propose
to require reporting of certain metrics regarding the use of the
existing Patient Access API. Combined, these proposals are intended to
reduce burden on providers, payers, and patients and support
improvements in patient care coordination.
To incentivize provider participation, specifically with the PARDD
API, we are proposing a new measure for MIPS eligible clinicians under
the Promoting Interoperability performance category of MIPS and for
eligible hospitals and CAHs under the Medicare Promoting
Interoperability Program related to electronic prior authorization
beginning in 2026, but the measure would not be scored until a future
date. We would propose future year scoring and the number of points
associated with the measure in future rulemaking. This new measure will
be included in a PRA package related to this proposed rule.

B. Wage Estimates

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

[[Page 76330]]

[GRAPHIC] [TIFF OMITTED] TP13DE22.012

We are adjusting the employee hourly wage estimates by a factor of
100 percent, or doubling the BLS wage estimates. This is necessarily a
rough adjustment because fringe benefits and overhead costs vary
significantly across employers based on the age of employees, location,
years of employment, education, vocations, and other factors. Methods
of estimating these benefits and overhead costs can vary across
studies. We have elected to use sources in alignment with other CMS
regulations after determining that they have used similar estimates and
formulas.
Consistent with our approach in the CMS Interoperability and
Patient Access final rule (85 FR 25622), we determine ICRs by
evaluating cost and burden at the impacted payer level, as defined and
discussed in detail in that rule. Ultimately, we determined that there
are 365 impacted payers \171\ that together represent the possible
plans, entities, issuers, and state programs impacted by these
proposals. The increase in impacted payers from the CMS
Interoperability and Patient Access final rule corresponds to the
average annual increase in impacted payers resulting from new market
entries. The total estimated burden on these impacted payers is
described in detail in each of the following ICRs and the summary table
(M9) at the end of this section. We estimated the total number of
burden hours across all impacted payers in the first year of
implementation at 5.3 million hours; assuming a total cost to impacted
payers to begin at approximately $110 million in the first year,
increasing to $221 million in the second and third year and going down
to $142 million by the fifth and subsequent years. We describe each ICR
in detail and request comment on the assumptions made in deriving these
burden estimates. All burden estimates will also be described and the
public will have an opportunity to comment on them in a forthcoming PRA
package to accompany this proposed rule.
---------------------------------------------------------------------------

\171\ We provide a detailed rationale for how we determined the
number of impacted payers in the CMS Interoperability and Patient
Access final rule (85 FR 25622). In that analysis we determined that
288 issuers and 56 states, territories, and U.S. commonwealths,
which operate Medicaid and CHIP FFS programs, will be subject to the
API provisions for Medicare, Medicaid, and the individual market. To
this, we added the one state that operates its CHIP and Medicaid
separately. Thus, we have 345 total impacted payers (288 + 56 + 1).
This number has been updated to 365 to reflect an increase in
impacted payers in the impacted programs.
---------------------------------------------------------------------------

1. ICRs Regarding the Proposal To Require Reporting of Patient Access
API Metrics to CMS (42 CFR 422.119, 431.60, 438.242, 457.730, and
457.1233 and 45 CFR 156.221)
To assess whether our policy requirements concerning the Patient
Access API finalized in the CMS Interoperability and Patient Access
final rule (85 FR 25558) have been implemented, we are proposing to
require impacted payers to annually report certain metrics to CMS on
the use of the Patient Access API. Specifically, we are proposing to
collect: 1) the total number of unique patients whose data are
transferred via the Patient Access API to a health app designated by
the patient; and 2) the total number of unique patients whose data are
transferred more than once via the Patient Access API to a health app
designated by the patient. We estimate that impacted payers would
conduct two major work phases: (1) implementation, which includes
defining requirements and system design (and updates) to generate and
compile reports; and (2) maintenance, which we define as including the
compilation and transmission of annual reports to CMS. During the
implementation phase, impacted payers would need to prepare their
systems to capture the data to be transmitted to CMS.
The burden estimate related to the new proposed requirements
reflects the time and effort needed to identify, collect, and disclose
the information. We estimate an initial set of one-time costs
associated with implementing the reporting infrastructure and an
ongoing annual maintenance cost to report after the reporting
infrastructure is established.
Table 12 presents our preparatory computational estimates for
first-year implementation and ongoing maintenance costs. Table 12 is
not the official statement of burden, which is found in Table 19,
including the number of respondents and responses. Table 12 presents
the preparatory calculations needed to create the official statement of
burden in Table 19. We assume a two-person team of a software/web
developer and a business operations specialist would spend an aggregate
of 160 and 40 hours, respectively, for the first and subsequent years,
at a total cost per impacted payer (rounded) up to $15,000 and $3,000,
for the first and subsequent years. The

[[Page 76331]]

aggregate burden (rounded) for 365 impacted payers would be 60,000
hours and 15,000 hours for the first and subsequent years at a cost of
$5.5 million and $1 million for the first and subsequent years.
[GRAPHIC] [TIFF OMITTED] TP13DE22.013

We request comment on our assumptions and approach.
2. ICRs Regarding the Provider Access API Proposal (42 CFR 422.121,
431.61, 438.242, 457.731, and 457.1233 and 45 CFR 156.221)
To promote our commitment to interoperability, we propose new
requirements for a Provider Access API. This FHIR API would permit
providers to receive standardized patient data to coordinate care. To
estimate costs to implement the new requirements for new APIs proposed
in this rule, we use the same methodology as that used in the CMS
Interoperability and Patient Access final rule.
In the CMS Interoperability and Patient Access final rule, we
estimated that impacted payers would conduct three major work phases:
initial design, development and testing, and long-term support and
maintenance (85 FR 25605). In this proposed rule, we assume the same
major phases of work would be required, with a different level of
effort during each work phase, for each of the new proposed APIs.
Consistent across all newly proposed API provisions, we describe the
tasks associated with the first two phases. Where we believe additional
effort associated with these tasks is necessary, we describe those as
relevant in subsequent ICRs, depending on how we believe they affect
cost estimates. We discuss the costs for the third phase, long-term
support and maintenance, and our methodology for the development of
those costs in aggregate for all proposed APIs in this section.
In the initial design phase, we believe tasks would include:
determining available resources (personnel, hardware, cloud storage
space, etc.), assessing whether to use in-house or contracted resources
to facilitate an API connection, convening a team to scope, build,
test, and maintain the API, performing a data availability scan to
determine any gaps between internal data models and the data required
for the necessary HL7 FHIR resources, and mitigating any gaps
discovered in the available data.
During the development and testing phase, we believe impacted
payers would need to conduct the following: map existing data to the
HL7 FHIR standards, allocate hardware for the necessary environments
(development, testing, production), build a new FHIR-based server or
leverage existing FHIR servers, determine the frequency and method by
which internal data are populated on the FHIR server, build connections
between the databases and the FHIR server, perform capability and
security testing, and vet provider requests.
Table 13 summarizes the aggregate burden for complying with the
proposed Provider Access API requirements. Here we provide illustrative
points explaining the calculations within the table and the terms used
for the headings. For example, row one is titled ``Database
Administrators and Architects.'' To develop the proposed Provider
Access API, each organization will require a team of database
administrators, engineers, computer system analysts, etc. The team
members are detailed in the rightmost column.
Continuing on the top row, ``Database Administrators,'' we obtained
the labor cost of $97.20 per hour from the Bureau of Labor Statistics
website. The $97.20 represents the mean wage for this occupational
title. We assume most organizations would require 3 months of work for
Database Administrators on this task. Three months is twelve weeks, or
480 hours (3 months x 4 weeks per month x 5 days a week x 8 hours per
day). The 480 hours are found in the column titled ``Primary Hours.''
The word primary, as used in the CMS Interoperability and Patient
Access final rule, refers to the amount of time most organizations
would require to conduct this work. This totals a cost of $46,656 for
each organization, which is obtained by multiplying the 480 hours by
the $97.20 per hour wage. This $46,656 is found in the column labeled
``Total Cost, Primary.''
We also provide low and high estimates representing a range of
possible time and cost across all organizations. The low estimate is
half the primary estimate, which is 240 hours or 1.5 months. The high
estimate is 720 hours representing 4.5 months. These numbers are found
in the low and high columns (hours) of the top row. The corresponding
low and high costs are multiplied by the $97.20 per hour wage. We
estimate that this is a reasonable range that would include all
organizations. A typical organization would take 3 months, with some
organizations completing the work in less time (in as little as 1.5
months) and some organizations taking longer (up to 4.5 months).
The explanation of the top row applies to each of the ten
occupational titles. The sum of the total hours and cost provides a
typical organization's total cost. This number is found in the ``Totals
for a single impacted payer'' row. As depicted, the typical
organization would take a total of 2,800 hours at a cost of $270,045.
We estimated the impact by organization rather than by payer since many
organizations may have entities in several of the programs to which
this proposed rule applies: Medicare Advantage, Medicaid, CHIP, and QHP
issuers on the FFEs.
To arrive at the total cost of the rule, we multiplied the single-
organization cost by 365 payers, the number of organizations hosting
plans across the

[[Page 76332]]

four 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, we estimated maintenance costs in future
years after the API is established at 25 percent of the aggregate cost.
This 25 percent was arrived at based on our experience with the
industry. Rather than list more columns or create another table, we
provide a footnote indicating that maintenance is 25 percent of the
cost. For example, the primary aggregate burden over all 365
organizations is $98.6 million, implying that the annual maintenance
costs would be $24.6 million (25 percent x $98.6 million).
[GRAPHIC] [TIFF OMITTED] TP13DE22.014

Although this provision would first be applicable on January 1,
2026, we believe it is reasonable that the APIs would have to be under
development before this date to conduct testing and ensure compliance.
Acknowledging that impacted payers will have varying technological and
staffing capabilities, as we did in the CMS Interoperability and
Patient Access final rule (85 FR 25606), we estimate that the
development of the APIs would require 6 to 12 months of work. Expecting
that this proposed rule will be finalized by mid-year 2023, we have
distributed the cost over approximately two-and-a-half calendar years
to give payers the flexibility to complete the necessary work (see
Table 19).
We request comment on our approach and assumptions for the cost of
the Provider Access API, including whether our estimates and ranges are
reasonable or should be modified.
a. API Maintenance Costs--All Proposed APIs
We discuss the costs for the third phase, long-term support and
maintenance, and our methodology for the development of those costs in
aggregate for all APIs discussed in this proposed rule. As relevant to
the APIs discussed in sections V.C.1., 3., 4., and 8., we estimate
ongoing maintenance costs for the Provider Access API, PARDD API, and
Payer-to-Payer API in aggregate. This approach aligns with the strategy
taken in the CMS Interoperability and Patient Access final rule (85 FR
25605), whereby the costs of the API development are split into three
phases: initial design, development and testing, and long-term support
and maintenance. However, unlike the CMS Interoperability and Patient
Access final rule, this proposed rule assumes that maintenance costs
only account for the cost associated with the technical requirements as
outlined in this rule. Any changes to requirements would require
additional burden, which would be discussed in future rulemaking.
Throughout the Collection of Information section, we discuss the
initial design, development, and testing costs per API. We next discuss
the total maintenance cost for all four APIs.
As discussed in the CMS Interoperability and Patient Access final
rule (85 FR 25606), once the API is established, we believe there would
be an annual cost to maintain the FHIR server, including the cost of
maintaining the necessary patient data and performing capability and
security testing. We believe there are efficiencies gained in
implementation and maintenance due to the fact that these proposed APIs
rely on several of the same underlying foundational technical
specifications and content. For example, the same baseline standards
apply, including the HL7 FHIR Release 4.0.1 and complementary security
and app registration protocols. Specifically, the HL7 SMART Application
Launch Implementation Guide (SMART IG) 1.0.0, including mandatory
support for the ``SMART on FHIR'' Core Capabilities. However, we do
believe that maintenance costs would be higher than what we estimated
for the CMS Interoperability and Patient Access final rule for the new
APIs proposed in this rule, as our estimates also account for new data
mapping needs, standards upgrades, additional data storage, system
testing, initial bug fixes, fixed-cost license renewals, contracting
costs, and ongoing staff education and training.
To account for these maintenance costs, we based our estimates on
input from industry experience piloting and demonstrating APIs for
provider access,

[[Page 76333]]

prior authorization, and payer to payer data exchange. We estimate an
annual cost averaging approximately 25 percent of the primary estimate
for one-time API costs. In the Summary Table (Table 19), we account for
this maintenance cost separately for each API (at 25 percent of the
one-time API cost). As discussed previously, the overlap in recommended
IGs across the proposed APIs should result in shared efficiency that we
believe supports the assumption that maintenance should be accounted
for in aggregate and is presented in this section as such.
We request public comment on our approach and assumptions for the
aggregate maintenance cost of the APIs, including whether our estimate
is reasonable or should be modified.
3. ICRs Regarding the Prior Authorization Requirements, Documentation,
and Decision (PARDD) API Proposal (42 CFR 422.122, 431.80, 438.242,
457.732, and 457.1233 and 45 CFR 156.223)
We propose new requirements for the implementation of a PARDD API.
This API would address several major challenges of the prior
authorization process, including identifying whether a prior
authorization is required for an item or service; identifying the payer
documentation requirements for prior authorization; compiling the
necessary data elements to populate the HIPAA-compliant prior
authorization transactions; and enabling payers to provide a specific
response regarding the status of the prior authorization, including
information about the reason for denial. Use of this proposed API would
begin on January 1, 2026, for MA and Medicaid and CHIP FFS, for
Medicaid managed care plans and CHIP managed care entities by the
rating period beginning on or after January 1, 2026, and for QHPs on
the FFEs for plan years beginning on or after January 1, 2026.
As discussed previously for the Provider Access API, to implement
the proposed new requirements for the PARDD API, we estimate that
impacted payers would conduct three major work phases: initial design,
development and testing, and long-term support and maintenance.
Furthermore, for this proposed API, we believe additional tasks are
necessary to accomplish the proposed requirements, which we describe
below as they affect the cost estimates. For the costs for the third
phase--long-term support and maintenance--our methodology for the
development of those costs in aggregate for all proposed APIs is
presented in section V.C.3. of this proposed rule.
We base our estimate on feedback from industry experts on the
anticipated burden of implementing the PARDD API. We believe this to be
a reasonable estimate of the implementation burden on payers to develop
APIs that can facilitate the prior authorization process. In addition
to implementing the PARDD API, these payers would be required to send a
reason for denial for prior authorization requests that are denied. As
discussed in section II.D. of this proposed rule, while the PARDD API
would use the HL7 FHIR standard to support its basic capabilities,
covered entities must also use the adopted X12 278 standard and remain
HIPAA-compliant. Given the added complexity of accounting for the HIPAA
standards, we have accounted for the multiple skill sets required and
licensing costs for accessing the X12 standards in developing the
burden estimates. The recommended HL7 IGs are freely available, as HL7
provides access to all IGs as open-source materials. This also makes
the HL7 standards, IGs, many reference implementations, and test
scripts available free of charge to the healthcare and developer
community. These low- or no-cost HL7 resources support our belief that
payers would incur minor costs for implementing the new standards. As
such, we have accounted for the necessary engineers, subject matter
experts, and health informaticists in our estimates. These personnel
resources would, for example, need to convert payers' prior
authorization documentation rules into computable, structured formats,
create provider questionnaires regarding whether a patient had a
medical necessity for a medical item or service, create formats that
could interface with the provider's EHR or practice management system,
create and execute mapping between the HL7 and X12 codes, and integrate
the PARDD API with the payer's system.
As noted previously, although this provision would be applicable on
January 1, 2026, this API would be under development before that date.
Acknowledging that impacted payers would have varying technological and
staffing capabilities, we estimate that the development of the API
would require 6 to 12 months of work. Expecting that this proposed rule
will be finalized by mid-year 2023, we have distributed the cost over
approximately two-and-a-half calendar years to give payers the
flexibility to complete the necessary work (see Table 19).
Table 14 presents total burden estimates for the PARDD API (initial
design phase and the development and testing phase). This table
presents the calculations associated with the total costs. The numbers
from this table are used in the summary table (Table 19) to present
costs per year for 3 years. Based on the same assumptions as those
included in the CMS Interoperability and Patient Access final rule, we
used the medium estimate as the primary estimate.
The narrative description provided for Table 13 also applies to
Table 14. Both tables estimate API costs for 365 organizations and
indicate follow-up annual maintenance costs by analyzing costs for a
single payer using a team spanning approximately ten occupational
titles.
BILLING CODE 4120-01-P

[[Page 76334]]

[GRAPHIC] [TIFF OMITTED] TP13DE22.015

BILLING CODE 4120-01-C
We request public comment on our approach and assumptions for the
one-time implementation cost of the PARDD API, including whether our
estimates

[[Page 76335]]

and ranges are reasonable or should be modified.
4. ICRs Regarding Proposed Requirements To Send Prior Authorization
Decisions Within Certain Timeframes (42 CFR 422.568, 422.570, 422.631,
438.210, 440.230, 457.495, and 457.1230)
To increase transparency and reduce burden, we are proposing to
require that impacted payers, not including QHP issuers on the FFEs,
send prior authorization decisions within 72 hours for urgent requests
and 7 calendar days for non-urgent requests. We are proposing that the
payers would have to comply with these provisions beginning January 1,
2026 (for Medicaid managed care plans and CHIP managed care entities,
by the rating period beginning on or after January 1, 2026).
In order to implement this policy, there would be up-front costs
for impacted payers to update their policies and procedures. We
anticipate this burden per payer is 8 hours of work by a general and
operations manager to update the policies and procedures, reflecting
two half-days of work at a per-entity cost of $967. Therefore, the
total burden for all 365 impacted payers is 2,920 hours of work at a
first-year cost of $0.4 million (rounded).
These calculations are summarized in Table 15:
[GRAPHIC] [TIFF OMITTED] TP13DE22.016

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

[[Page 76336]]

We request public comment on this approach and our assumptions.
6. ICRs Regarding the Payer-to-Payer API Proposal (42 CFR 422.121,
431.61, 438.242, 42 CFR 457.731, and 457.1233 and 45 CFR 156.222)
To improve patient access to their health information through care
coordination between health plans, as discussed in section II.C. of
this proposed rule, we propose new requirements for impacted payers to
implement and maintain a Payer-to-Payer API. These proposals would
improve care coordination among payers by requiring payers to exchange,
at a minimum, adjudicated claims and encounter data (excluding provider
remittances and enrollee cost-sharing information), all data classes
and data elements included in a content standard at 45 CFR 170.213, and
pending and active prior authorization decisions. This exchange would
be done using an HL7 FHIR Payer-to-Payer API implemented by January 1,
2026 (for Medicaid managed care plans and CHIP managed care entities,
by the rating period beginning on or after January 1, 2026, and for
QHPs on the FFEs for plan years beginning on or after January 1, 2026).
For a complete discussion of the data types proposed to be exchanged,
please refer to section II.C. of this proposed rule.
As discussed for the other APIs proposed in this rule, we estimate
that impacted payers would conduct three major work phases: initial
design, development and testing, and long-term support and maintenance.
For the Payer-to-Payer API, we believe there may be additional tasks
necessary to accomplish the proposed requirements, which we describe
below with respect to their impact on cost estimates. The costs for the
third phase, long-term support and maintenance, and our methodology for
the development of those costs in aggregate for all proposed APIs are
presented in section IV.C.3. of this proposed rule.
Payers should be able to leverage the API infrastructure already
accounted for in the Patient Access API finalized in the CMS
Interoperability and Patient Access final rule and the Provider Access
API proposal in this rule. As discussed in the CMS Interoperability and
Patient Access final rule (as well as the companion 21st Century Cures
Act: Interoperability, Information Blocking, and the ONC Health IT
Certification Program final rule (85 FR 25642)) and this proposed rule,
payers would be using the HL7 FHIR standards for content and transport,
recommended IGs to support interoperability of data sharing, as well as
the same underlying standards for security, authentication, and
authorization. Taken together, these standards would support the
proposed Payer-to-Payer API. Thus, we believe there would be some
reduced development costs to implement the Payer-to-Payer API because
of efficiencies gained in implementing the same underlying standards
and IGs for the other APIs proposed in this rule.
We believe there would be some costs for impacted payers to
implement the proposed Payer-to-Payer API that are unique to this API.
Based on input from current industry experience testing the
implementation of this API, there could be costs to test and integrate
the Payer-to-Payer API with payer systems, albeit potentially lower
costs than those estimated for the Provider Access API. We estimate the
one-time implementation costs at about one-third the cost of a full de
novo Provider Access API implementation based on input from developers
who have implemented and piloted prototype APIs using the proposed
required standards. As such, we have accounted for the necessary skill
sets of staff required as we also believe there would be unique costs
for implementing the HL7 FHIR Payer Coverage Decision Exchange (PDex)
IG so that payers can exchange active and pending prior authorization
decisions and related clinical documentation and forms when an enrollee
or beneficiary enrolls with a new impacted payer.
Table 17 presents the total activities, hours, and dollar burdens
for implementing the Payer-to-Payer API given our assumptions (initial
design phase and the development and testing phase). Based on the same
assumptions as those published in the CMS Interoperability and Patient
Access final rule, we have the medium estimate as the primary estimate.
We have included a similar narrative explanation of Table 17 as that
provided for Table 13 above.
For the primary estimate, one-time implementation efforts
for the first two phases would require, on average, a total of 916
hours per organization at an average cost of $96,072 per organization.
The aggregate burden of the one-time implementation costs
across 365 impacted payers would be 334,000 hours (rounded) at the cost
of $35.1 million (rounded). This corresponds to the primary estimate;
the primary and high estimates are obtained by multiplying the low
estimate by factors of two and three, respectively.
[GRAPHIC] [TIFF OMITTED] TP13DE22.018

As noted previously, although this provision would be applicable on
January 1, 2026, we believe the APIs would be under development before
that date. Acknowledging that impacted payers would have varying
technological and staffing capabilities, we estimate that development
of the APIs would require 6 to 12 months of

[[Page 76337]]

work. Expecting that this proposed rule will be finalized by mid-year
2023, we have distributed the cost estimates over approximately two-
and-a-half calendar years to give impacted payers the flexibility to
complete the work (see Table 19).
We request public comment on our approach and assumptions for the
cost of the Payer-to-Payer API, including whether our estimates and
ranges are reasonable or should be modified.
7. ICRs Regarding the Electronic Prior Authorization Measure for QPP
MIPS and the Medicare Promoting Interoperability Program
The estimates in this section have been submitted to OMB in a PRA
package (OMB control number 0938-1278).
As explained in section II.E. of this proposed rule, commenters to
the December 2020 CMS Interoperability proposed rule (85 FR 82586)
expressed support for requiring healthcare providers to use electronic
prior authorization as part of the QPP MIPS for MIPS eligible
clinicians, or the Conditions of Participation/Conditions for Coverage
requirements for eligible hospitals, and other providers and suppliers.
Commenters indicated these would be appropriate levers by which CMS
should propose new or additional provisions that would require the use
of APIs to enable enhanced electronic documentation discovery and
facilitate electronic prior authorization.
To incentivize MIPS eligible clinicians, eligible hospitals, and
CAHs to implement and use electronic prior authorization and the
corresponding API, we are proposing in section II.E. of this proposed
rule to add a new measure titled ``Electronic Prior Authorization'' for
MIPS eligible clinicians under the MIPS Promoting Interoperability
performance category and for eligible hospitals and CAHs under the
Medicare Promoting Interoperability Program beginning with the
performance period/EHR reporting period in CY 2026.
We are proposing that MIPS eligible clinicians, eligible hospitals,
and CAHs must report the Electronic Prior Authorization measure
beginning with the CY 2026 performance period/EHR reporting period, but
the measure would not be scored for CY 2026. For this measure, we
propose that a MIPS eligible clinician, eligible hospital, or CAH must
request a prior authorization electronically from a PARDD API using
data from CEHRT and report a numerator and denominator or claim an
exclusion if applicable.
The burden in implementing these proposed requirements consists of
the following steps: creating or implementing software to capture the
data, capturing the data, and reporting the measure as specified by
CMS. Beyond implementation, the burden lies in maintaining compliance
of the system to support all functionality, including the ability to
generate accurate and timely reports. We assume the annual maintenance
cost would include updates to the software to meet new reporting
requirements for the QPP MIPS Promoting Interoperability performance
category and the Medicare Promoting Interoperability Program on behalf
of participating MIPS eligible clinicians, eligible hospitals, and
CAHs. Such an update would include the ability to report the electronic
prior authorization measure as required by CMS. System maintenance is
an umbrella term that includes all activities needed to keep a system
running. The two main components of system maintenance are preventive
and corrective maintenance, which include software tasks such as fixing
bugs, updating data sources, deleting old software tasks, and adding
new tasks. Maintenance requirements for systems both in this proposed
rule and in the December 2020 CMS Interoperability proposed rule were
estimated at 25 percent of total software creation costs, reflecting
updates and bug fixes, as well as deletion and creation of software
tasks (85 FR 82649). Therefore, although we anticipate there would be a
moderate software update to implement the provisions of this proposed
rule, there would be no added burden over and above the burden of
maintaining already existing software.
The data for the reports on prior authorizations and related claims
should already be stored in the system software of healthcare providers
who may be required to retain such data for compliance and regulatory
reasons. To report the measure as specified by CMS, the actual added
burden that the proposals in this proposed rule would impose is the
burden of extracting data and preparing it in report form.
For the added burden of extracting, compiling, reviewing, and
submitting data, we assume that for each report, a Medical Records
Specialist would spend half a minute extracting the already-existing
data at a cost of $0.39 (\1/2\ minute x $46.42 per hour). Then, to
obtain the aggregate burden, we multiply by the number of entities.
This is done separately for eligible hospitals and CAHs, and MIPS
eligible clinicians in Table 18.
[GRAPHIC] [TIFF OMITTED] TP13DE22.019

The following items provide support and rationale for the entries
in Table 18:
The hourly burden estimates of \1/2\ minute (1/120 =
0.00833 hour) for transmission of the measure to CMS are consistent
with the revised estimates of burden presented in the FY 2023 IPPS/LTCH
PPS final rule (87 FR 49396). The

[[Page 76338]]

hourly burden estimates for the Electronic Prior Authorization measure
are based on the collection of burden estimates calculated for the
Query of Prescription Drug Monitoring Program measure.
The estimate of 4,500 hospitals (including eligible
hospitals and CAHs) is consistent with the revised estimates presented
in the FY 2023 IPPS/LTCH PPS final rule (87 FR 49393).
The existing QPP MIPS reporting policies allow MIPS
eligible clinicians to report at the individual or group level. Based
on the information available from Table 122 in the CY 2023 PFS final
rule (87 FR 69404, 70154), we estimate 54,770 individual or group MIPS
eligible clinicians would submit data for the Promoting
Interoperability performance category for the CY 2026 performance
period/CY 2028 MIPS payment year. The 54,770 is the sum of the 43,117
individual clinicians expected to submit performance data to QPP MIPS,
plus the 11,633 groups expected to submit performance data to QPP MIPS,
plus 20 subgroups. The information collection requirements currently
approved under OMB control number 0938-1314 are approved through
January 31, 2025.
The FY 2023 IPPS/LTCH PPS final rule uses median hourly wages (87
FR 49393), whereas this proposed rule and the CMS Interoperability and
Patient Access final rule (85 FR 25605) use mean hourly wages. For
purposes of illustration, we have provided both estimates.
For eligible hospitals and CAHs the total cost is $1,740 (4,500
hospitals and CAHs x \1/2\ minute x $46.20 per hour), which equals
0.002 million as listed in Table 19. This rounds to $0.0 million.
Calculations using the median instead of the average are similar. This
shows that the bottom-line rounded figure would not change if we used
the median instead of the average. However, the entries in the COI
Summary Table (M9) are $0.0 million consistent with rounding
accounting, and the actual numbers are provided in the table. The costs
of this provision 5 years after the finalization of the rule are
provided in the Summary Table, M9.
For MIPS eligible clinicians, the total cost is $21,186 (54,770
clinicians x \1/2\ minute x $46.20 per hour). Since this summary table,
M9, feeds into the RIA summary table, we expressed this $21,186 using
RIA accounting standards, which require rounding to the nearest tenth
of a million. It follows that $21,186 is equivalent to $0.021 million,
as listed in Table 19. This would round to $0.0.

D. Summary of Information Collection Burdens

The previous sections have explained the costs of individual
provisions in the proposed rule. Table 19 summarizes costs for the
first and subsequent years of these provisions and is based on the
following assumptions:
A publication date of mid-year 2023 for the final rule.
The effective date for all provisions is January 1, 2026.
For the Electronic Prior Authorization measure, this would be required
for the QPP MIPS Promoting Interoperability performance category
beginning with the 2026 performance period for MIPS eligible clinicians
and the Medicare Promoting Interoperability Program starting with the
2026 EHR reporting period for eligible hospitals and CAHs. Accordingly,
the COI summary Table 19 reflects costs beginning in 2027, which is
year 5 relative to mid-year 2023, the expected publication date of this
proposed rule. The table below summarizes the total information burden
for all reporting requirements, APIs, and the reporting required under
the QPP MIPS Promoting Interoperability performance category and the
Medicare Promoting Interoperability Program. The last line of the table
is the total cost for all impacted payers and providers, the estimated
burden, and the costs per year. The text below offers highlights from
our analysis.
For the three new APIs (Provider Access, Prior
Authorization Requirements, Documents, and Decisions (PARDD), and
Payer-to-Payer), we assume implementation would take place uniformly
over 30 months (the time from the expected publication date (mid-year
2023) for the final rule until the applicable compliance date in 2026).
Maintenance costs for the three APIs are, as indicated in
the tables of this section, assumed to be 25 percent of total costs; we
believe these maintenance costs would be incurred in years 2026 and
beyond.
For provisions requiring policy updates or first-year
implementation costs, we believe it is most reasonable that these
first-year costs would take place in 2026, the first year the rule is
in effect, and that subsequent year implementation costs, as reflected
in the various tables in this section, would take place in years 2027
and beyond.
Since the Electronic Prior Authorization measure would not
be applicable until 2026, no costs are reflected from 2023 through
2025.
Since the targeted publication date of this final rule is
mid-year 2023, we treat 2023 as a half-year. For purposes of allocating
software development costs, 2023 is therefore one-half the costs
expected to be incurred during 2024 and 2025.
Labor costs in Table 19 are either BLS wages when a single
staff member is involved or a weighted average representing a team
effort, which is obtained by dividing the aggregate cost by the
aggregate hours. For example, in the first row, $94.32 equals the
aggregate $5.5 million cost divided by the aggregate 58,400 hours.
We also note that Table 19 reflects the primary estimate. The full
range of estimates for all provisions is presented in the RIA section
of this proposed rule.
BILLING CODE 4120-01-P

[[Page 76339]]

[GRAPHIC] [TIFF OMITTED] TP13DE22.020

BILLING CODE 4120-01-C

[[Page 76340]]

E. Conclusion

The provisions of this proposed rule could improve data sharing
across stakeholders by facilitating access, receipt, and exchange of
patient data. We are committed to providing patients, providers, and
payers with timely access to patient health information. We request
comment on our approaches for estimating cost burden and cost savings.
The requirements of this proposed rule are extensions of the
requirements of the CMS Interoperability and Patient Access final rule
(85 FR 22510). Therefore, the information collection requirements will
be submitted to OMB for review and approval.
If you would like to provide feedback on these information
collections, please submit your comments electronically as specified in
the ADDRESSES section of this proposed rule. Comments must be received
on/by March 13, 2023.

V. Regulatory Impact Analysis

A. Statement of Need

As described in prior sections of this proposed rule, the proposed
changes to 42 CFR parts 422, 431, 435, 438, 440, and 457 and 45 CFR
part 156 further support CMS' efforts to empower patients by increasing
electronic access to healthcare data, while keeping that information
safe and secure. The proposals in this rule build on the foundation we
laid out in the CMS Interoperability and Patient Access final rule to
move the healthcare system toward increased interoperability by
proposing to increase the data sharing capabilities of impacted payers,
encourage healthcare providers' use of new capabilities, and make
health-related data more easily available to patients through
standards-based technology.
If finalized, the proposals in this rule would place new
requirements on MA organizations, state Medicaid and CHIP FFS programs,
Medicaid managed care plans, CHIP managed care entities, and QHP
issuers on the FFEs to improve the electronic exchange of health-
related data and streamline prior authorization processes. And these
proposals could improve health information exchange and facilitate
appropriate and necessary patient, provider, and payer access to health
information via APIs. Our proposals related to prior authorization are
also intended to improve certain administrative processes. The proposed
rule would also add a new measure for eligible hospitals and CAHs under
the Medicare Promoting Interoperability Program and for MIPS eligible
clinicians under the QPP MIPS Promoting Interoperability performance
category.

B. Overall Impact

We have examined the impacts of this proposed rule as required by
Executive Order 12866 on Regulatory Planning and Review (September 30,
1993), Executive Order 13563 on Improving Regulation and Regulatory
Review (January 18, 2011), the Regulatory Flexibility Act (RFA)
(September 19, 1980, Pub. L. 96-354), section 1102(b) of the Act,
section 202 of the Unfunded Mandates Reform Act of 1995 (March 22,
1995, Pub. L. 104-4), and Executive Order 13132 on Federalism (August
4, 1999).
Executive Orders 12866 and 13563 direct agencies to assess all
costs and benefits of available regulatory alternatives and, if
regulation is necessary, to select regulatory approaches that maximize
net benefits (including potential economic, environmental, public
health, and safety effects, distributive impacts, and equity). Section
3(f) of Executive Order 12866 defines a ``significant regulatory
action'' as an action that is likely to result in a rule: (1) having an
annual effect on the economy of $100 million or more in any 1 year, or
adversely and materially affecting a sector of the economy,
productivity, competition, jobs, the environment, public health or
safety, or state, local, or tribal governments or communities (also
referred to as ``economically significant''); (2) creating a serious
inconsistency or otherwise interfering with an action taken or planned
by another agency; (3) materially altering the budgetary impacts of
entitlement grants, user fees, or loan programs or the rights and
obligations of recipients thereof; or (4) raising novel legal or policy
issues arising out of legal mandates, the President's priorities, or
the principles set forth in the Executive order.
A Regulatory Impact Analysis must be prepared for major rules with
economically significant effects ($100 million or more in any 1 year).
Based on our estimates, OMB's Office of Information and Regulatory
Affairs has determined this rulemaking is ``economically significant''
as measured by the $100 million threshold. Accordingly, we have
prepared a Regulatory Impact Analysis that, to the best of our ability,
presents the costs and benefits of this proposed rulemaking.
As noted later in this section, we believe that our proposed
policies, if finalized, would result in some financial burdens for
impacted payers and providers as discussed in section IV. of this
proposed rule. We have weighed these potential burdens against the
potential benefits, and believe the potential benefits outweigh any
potential costs. Based on our estimates, the total burden across all
providers would be reduced by at least 206 million hours over 10 years,
resulting in a total cost savings over 10 years of approximately $15
billion (see Table 24). However, for reasons discussed later in this
proposed rule, these savings are neither included in the 10-year
Summary Table (N8), nor in the Monetized Table (N10).

C. Regulatory Flexibility Act

Executive Order 13272 requires that HHS thoroughly review rules to
assess and take appropriate account of their potential impact on small
businesses, small governmental jurisdictions, and small organizations
(as mandated by the Regulatory Flexibility Act (RFA)). If a proposed
rule may have a significant economic impact on a substantial number of
small entities, then the proposed rule must discuss steps taken,
including alternatives considered, to minimize the burden on small
entities. The RFA does not define the terms ``significant economic
impact'' or ``substantial number.'' The Small Business Administration
(SBA) advises that this absence of statutory specificity allows what is
``significant'' or ``substantial'' to vary, depending on the problem
that is to be addressed in rulemaking, the rule's requirements, and the
preliminary assessment of the rule's impact. Nevertheless, HHS
typically considers a ``significant'' impact to be 3 to 5 percent or
more of the affected entities' costs or revenues.
For purposes of the RFA, we estimate that many impacted payers and
providers are small entities, as that term is used in the RFA, either
by being nonprofit organizations or by meeting the SBA definition of a
small business. For purposes of the RFA, small entities include small
businesses, nonprofit organizations, and small governmental
jurisdictions. The North American Industry Classification System
(NAICS) is used in the U.S., Canada, and Mexico to classify businesses
by industry. While there is no distinction between small and large
businesses among the NAICS categories, the SBA develops size standards
for each NAICS category.\172\ Note that the most recent update to the
NAICS codes went into effect for the

[[Page 76341]]

2017 reference year; the most recent size standards were adopted in
2022.
---------------------------------------------------------------------------

\172\ U.S. Census Bureau (2021, December 16). 2017 North
American Industry Classification System (NAICS) Manual. Census.gov.
Retrieved from https://www.census.gov/library/publications/2017/econ/2017-naics-manual.html.
---------------------------------------------------------------------------

In analyzing the impact of this proposed rule, we take note that
there would be a quantifiable impact for the following stakeholders.
1. Payers
Updates to systems implementing the various APIs described
throughout the preamble, including any reporting requirements, would be
performed by the 365 payer organizations. Throughout this section of
the proposed rule, we also use the term parent organizations to refer
to the impacted payers, as we did in the CMS Interoperability and
Patient Access final rule (85 FR 25510), which includes the state
Medicaid and CHIP agencies. The combined parent organizations
administer MA, state Medicaid and CHIP FFS programs, Medicaid managed
care plans, CHIP managed care entities, and QHP issuers on the FFEs.
The NAICS category relevant to these proposed provisions is Direct
Health and Medical Insurance Carriers, NAICS 524114, which have a $41.5
million threshold for ``small size.'' Seventy-five percent of payers in
this category have under 500 employees, thereby meeting the definition
of small businesses.
If the proposals in this rule are finalized, the 365 parent
organizations, including state Medicaid and CHIP agencies, would be
responsible for implementing and maintaining three new APIs, updating
policies and procedures regarding timeframes for making prior
authorization decisions, and reporting certain metrics either to CMS or
making information available to the public. MA organizations, Medicaid
managed care plans, CHIP managed care entities, and QHP issuers on the
FFEs are classified as NAICS code 524114, direct health insurance
carriers. We are assuming that a significant number of these entities
are not small. We note that none of the state Medicaid and CHIP
agencies are considered small. MA organizations and state Medicaid
managed care plans and CHIP managed care entities have many of their
costs covered through capitation payments from the Federal Government
to MA organizations or through state payments. Based on this
discussion, there is no significant burden.
If finalized as proposed, some QHP issuers on the FFEs would be
able to apply for an exception to these requirements, and certain
states operating Medicaid and CHIP FFS programs would be able to apply
for an extension or exemption, under which they would not be required
to meet the new API provisions of the proposed rule on the proposed
compliance dates, provided certain conditions are met, as discussed in
sections II.B., II.C., and II.D. of this proposed rule. We acknowledge
that providing additional information for the annual APD submissions
and existing reports would require effort, but we do not believe there
would be significant burden to these entities from the proposals in
this proposed rule if an extension or exemption is approved.
a. Medicare Advantage
Each year, MA organizations submit a bid for furnishing Part A and
B benefits and the entire bid amount is paid by the Government to each
plan if the plan's bid is below an administratively set benchmark. If a
plan's bid exceeds that benchmark, the beneficiary pays the difference
in the form of a basic premium (note that a small percentage of plans
bid above the benchmark, whereby enrollees pay a basic premium in
addition to their Part B premium; this percentage of plans is not
``significant'' as defined by the RFA and is explained later in this
proposed rule).
MA plans with prescription drug coverage (MA-PDs) can also offer
supplemental benefits, that is, benefits not covered under Original
Medicare (or under Part D). These supplemental benefits are paid for
through enrollee premiums, extra Government payments, or a combination
of enrollee premiums and extra Government payments. Under the statutory
payment formula, if the bid submitted by an MA plan for furnishing Part
A and B benefits is lower than the administratively set benchmark, the
Government pays a portion of the difference to the plan in the form of
a ``beneficiary rebate.'' The rebate must be used to provide
supplemental benefits (that is, benefits not covered under Original
Medicare) and/or lower beneficiary Part B or Part D premiums. Some
examples of these supplemental benefits include vision, dental,
hearing, fitness, and worldwide coverage of emergency and urgently
needed services.
To the extent that the Government's payments to plans for the bid
plus the rebate exceeds costs in Original Medicare, those additional
payments put upward pressure on the Part B premium, which is paid by
all Medicare beneficiaries, including those in Original Medicare who do
not have the supplemental enhanced coverage available in many MA plans.
Part D plans, including MA-PD plans, submit bids and those amounts
are paid to plans through a combination of Medicare funds and
beneficiary premiums. In addition, for certain enrolled low-income
beneficiaries, Part D plans receive Government funds to cover most
premium and cost-sharing amounts that those beneficiaries would
otherwise pay.
Thus, the cost of providing services by these payers is funded by a
variety of Government funding and in some cases by enrollee premiums.
As a result, MA and Part D plans are not expected to incur burden or
losses since the private companies' costs are being supported by the
Government and enrolled beneficiaries. This lack of expected burden
applies to both large and small health plans.
Small entities that must comply with MA regulations, such as those
in this proposed rule, are expected to include the costs of compliance
in their bids, thus avoiding additional burden, since the cost of
complying with any final rule is funded by payments from the Government
and, if applicable, enrollee premiums.
For Direct Health and Medical Insurance Carriers, NAICS 524114, MA
organizations estimate their costs for the upcoming year and submit
bids and proposed plan benefit packages. Upon approval, the plan
commits to providing the proposed benefits, and CMS commits to paying
the plan either the full amount of the bid, if the bid is below the
benchmark, which is a ceiling on bid payments annually calculated from
Original Medicare data; or the benchmark, if the bid amount is greater
than the benchmark.
Thus, there is a cost to plans to bid above the benchmark that is
not funded by Government payments. Additionally, if an MA organization
bids above the benchmark for any of its plans, section 1854 of the Act
requires the MA organization to charge enrollees a premium for that
amount. Table 20 reports the percentage of MA organizations bidding
above the benchmark, along with the percentage of affected enrollees in
recent years. This table reports aggregates of proprietary bid data
collected by the Office of the Actuary. The CMS threshold for what
constitutes a substantial number of small entities for purposes of the
RFA is 3 to 5 percent. As shown in Table 20, both the percentage of
plans and the percentage of affected enrollees are decreasing, and
below this 3 to 5 percent threshold. Consequently, we conclude that the
number of plans bidding above the benchmark is not substantial for
purposes of the RFA.

[[Page 76342]]

[GRAPHIC] [TIFF OMITTED] TP13DE22.021

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

\173\ 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). 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). https://www.federalregister.gov/d/2022-07642.
---------------------------------------------------------------------------

Based on the previously discussed considerations, the Secretary has
certified that this proposed rule will not have a significant impact on
a substantial number of small entities.
b. Medicaid and CHIP
Title XIX of the Act established the Medicaid program as a Federal-
state partnership for the purpose of providing and financing medical
assistance to specified groups of eligible individuals. States claim
Federal matching funds on a quarterly basis based on their program
expenditures. Since states are not small entities under the Regulatory
Flexibility Act, we need not discuss, in the Initial Regulatory
Flexibility Analysis, the burden imposed on them by this proposed rule.
With regard to Medicaid managed care plans and CHIP managed care
entities, since managed care plans receive 100 percent capitation from
the state, we generally expect that the costs associated with the
provisions of this proposed rule would be included in their capitation
rates and may be reasonable, appropriate, and attainable costs
irrespective of whether they are a small business. Consequently, we can
assert that there would be no significant impact on a significant
number of these entities.
As discussed in sections II.B., II.C., and II.D. for the proposed
API provisions, states operating Medicaid FFS and CHIP FFS programs
could apply for an extension of 1 year to come into compliance with the
requirements of this proposed rule. These same organizations may also
apply for an exemption from the requirements if certain conditions are
met.
c. QHP Issuers on the FFEs
Few, if any, QHP issuers on the FFEs are small enough to fall below
the size thresholds for a small business established by the SBA.
Consistent with previous CMS analysis, we estimate that any issuers
that would be considered small businesses are likely to be subsidiaries
of larger issuers that are not small businesses (78 FR 33238) and thus
do not share the same burdens as an independent small business.
Therefore, even though QHP issuers do not receive Federal reimbursement
for the costs of providing care, we do not conclude that there would be
a significant small entity burden for these issuers. In addition, we
propose an exception process be available for QHPs on the FFEs, which
further helps to address burden that could otherwise prohibit a QHP
issuer from participating in an FFE.

[[Page 76343]]

2. Providers
In response to public comments on the December 2020 CMS
Interoperability proposed rule (85 FR 82586), CMS is proposing a new
Electronic Prior Authorization measure for MIPS eligible clinicians
under the QPP MIPS Promoting Interoperability performance category, and
for eligible hospitals and CAHs under the Medicare Promoting
Interoperability Program. The measure would be required for reporting
beginning in CY 2026.
With regard to MIPS eligible clinicians, eligible hospitals, and
CAHs, a discussion of the burden placed on these entities were
presented in section IV.C.8, Table 18. That table shows that the burden
per individual provider is under $2.50 per year (one half-minute of
labor times an hourly wage of under $50, depending on whether one uses
a mean or median). Consequently, the Secretary asserts that the
provisions of this proposed rule do not represent a significant burden
on providers.
Based on the information provided previously, we conclude that the
requirements of the RFA have been met by this proposed rule.

D. UMRA and E.O. 13132 Requirements

Section 202 of the Unfunded Mandates Reform Act of 1995 (UMRA) also
requires that agencies assess anticipated costs and benefits before
issuing any rule whose mandates require spending in any 1 year of $100
million in 1995 dollars, updated annually for inflation. In 2022, that
threshold is approximately $165 million. This proposed rule would not
impose an unfunded mandate that would result in the expenditure by
state, local, and tribal governments, in the aggregate, or by the
private sector, of more than $165 million in any 1 year.
Executive Order 13132 establishes certain requirements that an
agency must meet when it promulgates a proposed rule (and subsequent
final rule) that imposes substantial direct costs on state and local
governments, preempts state law, or otherwise has federalism
implications. As previously outlined, while the API provisions would be
a requirement for state Medicaid and CHIP agencies under these
proposals, the cost per beneficiary for implementation is expected to
be negligible when compared with the overall cost per beneficiary. This
analysis does not consider Federal matching funds provided to state
Medicaid and CHIP agencies, but the conclusion is the same: there is
not expected to be a significant cost impact on state entities. For
Medicaid and CHIP, we do not believe that the proposals in this rule
would conflict with state law, and therefore, do not anticipate any
preemption of state law. As discussed in section II.D. of this proposed
rule, some state laws regarding timeframes for prior authorization
decisions may be different than the proposals in this proposed rule.
However, an impacted payer would be able to comply with both state and
Federal requirements by complying with whichever imposes the shorter
timeframe. We invite states to comment on this proposed rule if they
believe any proposal in this rule would conflict with state law.

E. Regulatory Review Costs

If regulations impose administrative costs on private entities,
such as the time needed to read and interpret this proposed rule, we
should estimate the cost associated with regulatory review. We model
our estimates of this burden based on similar estimates presented in
the CMS Interoperability and Patient Access final rule (85 FR 25510).
There are three numbers needed to calculate this estimate:
1. Number of Staff per Entity Performing the Reading
The staff involved in such a review would vary from one parent
organization to another. We believe that a good approximation for a
range of staff would be a person such as a medical and health service
manager or a lawyer. Using the wage information from the BLS for
medical and health services managers (Code 11-9111) and lawyers (Code
23-1011) we estimate that the cost of reviewing this proposed rule is
$128.71 per hour, including overhead and fringe benefits.\174\ This
number was obtained by taking the average wage of a medical manager and
lawyer.
---------------------------------------------------------------------------

\174\ U.S. Bureau of Labor Statistics (2022, March 31). National
Occupational Employment and Wage Estimates. Retrieved from https://www.bls.gov/oes/current/oes_nat.htm.
---------------------------------------------------------------------------

2. Number of Hours of Reading
In the CMS Interoperability and Patient Access final rule, we
estimated 6 hours of reading time. Therefore, we believe 10 hours would
be enough time for each parent organization to review relevant portions
of this proposed rule.
3. Number of Entities Reviewing the Proposed Rule
We believe the review would be done by both parent organizations
that would be required to implement the proposed API provisions, and by
the physician and provider specialty societies. For parent
organizations, we have used an assumption of 365 parent organizations
throughout this proposed rule. For physician practices, individual
physician practices rely on their specialty societies to read content
such as proposed rules for them. The Relative Value Scale Update
Committee (RUC) has 32 members representing all specialties.\175\ This
would result in 398 entities (365 Parent organizations plus 32 members
of the RUC) in our estimates. We also add 100 entities (for a total of
500 entities) to account for the 66 pharmacy benefit managers and the
several dozen major advocacy groups.
---------------------------------------------------------------------------

\175\ American Medical Association (2022, July 12). Composition
of the RVS Update Committee (RUC). Retrieved from https://www.ama-assn.org/about/rvs-update-committee-ruc/composition-rvs-update-committee-ruc.
---------------------------------------------------------------------------

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

F. Impact of Individual Proposals

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

[[Page 76344]]

[GRAPHIC] [TIFF OMITTED] TP13DE22.022

Additionally, this Regulatory Impact Analysis section provides an
analysis of potential savings arising from the replacement of paper
approaches to prior authorization and other plan requirements with an
electronic method. Although these savings are neither included in
monetized tables nor in summary tables, as further discussed later in
this proposed rule, we believe that these large savings are an
important consideration in evaluating this proposed rule. We have
identified assumptions for these analyses, and we request public
comment.
Table 27 of this section, using Table 19 as a basis, provides a 10-
year impact estimate. Table 27 includes impact by year, by type (parent
organizations, including Medicaid and CHIP state agencies), as well as
the cost burden to the Federal Government, allocations of cost by
program, and payments by the Federal Government to Medicare Advantage,
Medicaid, and CHIP, as well as the premium tax credits (PTC) paid to
certain enrollees in the individual market.

G. Alternatives Considered

In this proposed rule, we continue to build on the efforts
initiated with the CMS Interoperability and Patient Access final rule
and the work we have done to advance interoperability, improve care
coordination, and empower patients with access to their healthcare
data. This proposed rule covers a range of policies aimed at achieving
these goals. We carefully considered alternatives to the policies we
are proposing in this rule, some of which were included in the December
2020 CMS Interoperability proposed rule, and on which we received
public comments. Those public comments and other engagements over the
year support our conclusions that none of the alternatives would
adequately or immediately begin to address the critical issues related
to patient access and interoperability or help to address the processes
that contribute to payer, provider, and patient burden.
We now discuss the alternatives we considered to our proposed
provisions and the reasons we did not select them as proposed policies.
1. Alternatives Considered for the Proposed Patient Access API
Enhancements
We are proposing to require that payers make enhancements to the
Patient Access API finalized in the CMS Interoperability and Patient
Access final rule including proposing additional information be made
available to patients through the Patient Access API, and proposing
certain metrics about patient use of the Patient Access API be reported
directly to CMS annually. Before proposing to require these provisions,
we considered several policy alternatives.
As we discussed in the CMS Interoperability and Patient Access
final rule (85 FR 25627), one alternative to the proposed updates to
the Patient Access API we considered is allowing payers and providers
to upload patient data directly to a patient portal, operated by a
provider. However, despite the availability of patient portals, ONC
reported in 2020 that only 60 percent of individuals have been offered
online access to their medical records by either their healthcare
provider or payer. And of the individuals that were offered access,
approximately 40 percent of those viewed their record.\176\ Further,
patient portals may not achieve the same interoperability goals that
health apps could in order to support a patient's individual preference
to manage their specific health condition or view their complete health
record using supplemental data from different sources. A patient portal
can only provide the data available from the organization offering the
portal, and most portals are not connected to mobile applications to
monitor physical activity, medication compliance, or health metrics.
Portals may not be connected to the many external health apps for other
services such as fitness training, meal planning for special diets,
challenges, or other features available in the marketplace. Finally,
providers and payers are not yet coordinating on the exchange of
administrative and clinical data that we are proposing be shared in
this proposed rule. For those reasons we do not believe that patient
portals can fully meet patients' needs and would not be a suitable
policy option to propose. We also believe that there could be
additional burden associated with using portals because patients might
need to use multiple portals and websites to access all of their
information. Using multiple portals would require an individual to sign
into each portal in order to review all of their relevant data--one for
each provider or plan with which the patient is associated. A single
health app may be able to compile health information about the patient
from multiple sources, based on a patient's request. The patient could
possibly access this information with one login, and could find the
same

[[Page 76345]]

information, as might be available from the multiple portals.
---------------------------------------------------------------------------

\176\ Office of the National Coordinator (2021, September).
Individuals' Access and Use of Patient Portals and Smartphone Health
Apps, 2020. ONC Data Brief N. 57. Retrieved from https://www.healthit.gov/data/data-briefs/individuals-access-and-use-patient-portals-and-smartphone-health-apps-2020.
---------------------------------------------------------------------------

A portal is operated by a provider or payer as an entry point to a
finite set of data available from an individual organization. These
portals do not lend themselves as well to interoperability because they
do not enable other organizations, or the patient, to provide
additional data to the system. Because business models and processes
pertaining to patient portals are varied across the industry, and any
one patient could be associated with a number of different portals,
there is no available data today with which we can evaluate the cost
impacts of requiring individual portals versus the estimates for
enhancing the Patient Access API.
As explained in the CMS Interoperability and Patient Access final
rule (85 FR 25627), another alternative considered was to allow Health
Information Exchanges (HIEs) and Health Information Networks (HINs) to
serve as a central source for patients to obtain aggregated data from
across their providers and payers in a single location. HIEs and HINs
could provide patients with information via an HIE portal that is
managed by the patient.
However, as previously described, there are reasons why patient
portal access does not lend itself to interoperability or innovation,
and all patients might not have access to an HIE or HIN. For the
reasons described, we ultimately decided to proceed with our proposed
requirements versus these alternatives.
In the December 2020 CMS Interoperability proposed rule (85 FR
82592), we proposed to require impacted payers to request a privacy
policy attestation from health app developers when their health app
requests to connect to the payer's Patient Access API. We proposed that
the attestation would include, at a minimum, that the health app has a
plain language privacy policy that is always publicly available and
accessible and has been affirmatively shared with the patient prior to
the patient authorizing the app to access their health information. In
addition, the attestation we proposed included yes/no elements as to
whether the privacy policy specifically communicates how the patient's
health information could be accessed, exchanged, or used.
We considered proposing that policy again, but based on substantial
public comment, we believe that this type of attestation would not
benefit patients in ways that would outweigh the burden on impacted
payers and that such a policy could have unintended consequences for
patients. Under that proposal, a health app developer would only be
attesting to the format and inclusion of certain information. There
would be no attestation that the substance of the privacy policy meets
specific minimum requirements or best practices. We believe that having
payers inform patients that an app developer has attested to the form
and format of a privacy policy could easily be misinterpreted as
assurance that the substance of the privacy policy has been reviewed
and found acceptable by the payer (or CMS). We are concerned that
requiring such an attestation would only give the appearance of privacy
and security for patients' health data, without providing additional
privacy or security. Though we did not pursue this option, we continue
to work with the Office for Civil Rights and the Federal Trade
Commission \177\ to determine what additional types of guidance might
be warranted to support consumer education with respect to privacy
policies when using health apps, as well as guidance for payers when
evaluating the apps available to their beneficiaries and enrollees.
---------------------------------------------------------------------------

\177\ Federal Trade Commission (2022, April 27). Mobile Health
Apps Interactive Tool. Retrieved from https://www.ftc.gov/business-guidance/resources/mobile-health-apps-interactive-tool.
---------------------------------------------------------------------------

Regarding reporting Patient Access API metrics, we considered
requiring impacted payers to publicly report these metrics more
frequently than annually. For example, we considered a quarterly
requirement. Public comments on the December 2020 CMS Interoperability
proposed rule indicated a preference for less frequent reporting, which
would in turn create less burden on payers. Annual statistics on such
utilization should be sufficient to accomplish our goals.
We also considered alternative effective dates for the proposed
policies. For example, we considered January 1, 2024, and 2025 as
possible compliance dates for the Patient Access API enhancements.
However, based on the public feedback we received from the December
2020 CMS Interoperability proposed rule, we believe it is more
appropriate, and less burdensome on impacted payers to propose an
effective date for these policies beginning on January 1, 2026 (for
Medicaid managed care plans and CHIP managed care entities, by the
rating period beginning on or after January 1, 2026, and for QHP
Issuers on the FFEs, for plan years beginning on or after January 1,
2026), which provides for a two year implementation time frame.
2. Alternatives Considered for the Proposed Provider Access API
In this proposed rule, to better facilitate the coordination of
care across the care continuum, we are proposing to require impacted
payers to implement and maintain a Provider Access API. This proposed
API would require payers to make available to certain providers the
same types of data they would make available to patients via the
enhanced Patient Access API.
Alternatively, we considered other data types that could be
exchanged via the Provider Access API. We considered only requiring the
exchange of all data classes and data elements included in a content
standard at 45 CFR 170.213. While this would be less data to exchange
and, thus, potentially less burdensome for impacted payers to
implement, we believe that claims and encounter information can
complement the content standard and offer a broader and more holistic
understanding of a patient's interactions with the healthcare system.
Furthermore, the data that we propose to be made available through the
proposed Provider Access API aligns with the data that we propose to be
made available to individual patients through the Patient Access API.
Once the data are mapped and prepared to share via one FHIR API, these
data should be available for all payer APIs to use within that
organization.
We also considered having only payer claims and encounter data
available to providers, understanding that providers are generally the
source of clinical data. This could limit the burden on payers by
requiring less data to be made available. However, even if a provider
is the source for the clinical data relevant to their patient's care, a
provider may not have access to clinical data from other providers a
patient is seeing. As a result, and understanding payers were already
preparing these data for use in other APIs, we decided a more
comprehensive approach would be most beneficial to both providers and
patients and aligned the proposed Provider Access API data requirements
with those proposed for the Patient Access API.
We also considered including additional data elements in this
proposal as well as requiring the complete set of data available from
the payer's system. We had not received recommendations for such an
extensive body of data and acknowledge that such a large volume of data
types would require too many additional resources, and would likely not
be consistent with minimum necessary provisions (unless

[[Page 76346]]

its receipt was required by law in concert with how the data was being
requested) and be overly burdensome for impacted payers at this time.
As described earlier in this proposed rule, the USCDI is a standardized
set of data classes and data elements adopted for nationwide,
interoperable health information exchange.\178\ Because this limited
set of data has been standardized, and corresponding FHIR IGs have been
developed, payers can map these data and make them more easily
available via an API. The HL7 workgroups in which payers and providers
participate continue to work on the IGs to ensure necessary
enhancements to facilitate sharing of a patient's complete record. We
acknowledge that work will be ongoing for the IGs, and important
questions about data segmentation, and a patient's role in potentially
specifying what parts of their medical record could or should be
available to which providers, need to be considered.
---------------------------------------------------------------------------

\178\ Office of the National Coordinator Interoperability
Standards Advisory (ISA). (n.d.) United States Core Data for
Interoperability (USCDI). Retrieved from https://www.healthit.gov/isa/united-states-core-data-interoperability-uscdi.
---------------------------------------------------------------------------

3. Alternatives Considered for the Proposed Payer-to-Payer API
We are proposing to require impacted payers to implement and
maintain a Payer-to-Payer API that makes certain data available to
other payers via a FHIR API. This proposal would make the same data
that is being made available to patients and providers also available
to other payers when an enrollee changes plans, and in that way allow
patients to take their data with them as they move from one payer to
another. Before proposing these policies, we considered several policy
alternatives.
In the CMS Interoperability and Patient Access final rule, we
finalized a policy to require payers to exchange data with other
payers, but did not require a specific mechanism for the payer to payer
data exchange. Rather, CMS required impacted payers to receive data in
whatever format it was sent and accept data in the form and format it
was received, which ultimately complicated implementation by requiring
payers to accept data in different formats. In this proposed rule, we
had the option to maintain the previous policy and forgo the API
requirement. However, since the CMS Interoperability and Patient Access
final rule was finalized in May of 2020, many impacted payers indicated
to CMS that the lack of technical specifications for the payer to payer
data exchange requirement was creating challenges for implementation,
which could have created differences in implementation across the
industry, poor data quality, operational challenges, and increased
administrative burden. Differences in implementation approaches could
have created gaps in patient health information that would have
conflicted directly with the intended goal of interoperable payer to
payer data exchange.
Furthermore, for the Payer-to-Payer API, once an organization
implements the other proposed APIs, there would be less additional
investment necessary to implement the Payer-to-Payer API as payers
would be able to leverage the infrastructure already established for
the Patient Access API and Provider Access API. The HL7 Da Vinci Payer
Data Exchange work group has expanded their work over the past year to
include two paths to exchange claims and associated clinical data. The
updated background section for the recommended implementation guide
provides an explanation of how the existing resources can be tailored
to meet the provisions of our proposals.\179\ Given this available
infrastructure and the efficiencies of sharing standardized data via
the API, we determined it was most advantageous for payers to leverage
an API for this enhanced data exchange.
---------------------------------------------------------------------------

\179\ Da Vinci Payer Data Exchange (2020, December 22). HL7
International. Retrieved from HL7.FHIR.US.DAVINCI-PDEX\Home--FHIR
v4.0.1.
---------------------------------------------------------------------------

We also considered which data elements would be the most
appropriate to require for the exchange between payers. Similar to the
Provider Access API alternatives, we considered only requiring the
exchange of data classes and data elements included in a content
standard at 45 CFR 170.213. As we previously described, we believe that
claims and encounter information can complement the content standard
and potentially allow for better care coordination, as well as more
efficient payer operations. We do not believe there to be significant
additional burden once the data are mapped for the other proposed APIs.
4. Alternatives Considered for the Proposed PARDD API and Other Prior
Authorization Proposals
We are also proposing several policies associated with the prior
authorization process. First, we are proposing to require that all
impacted payers implement and maintain a Prior Authorization
Requirements, Documentation, and Decision (PARDD) API. We believe this
API would ultimately help patients receive the items and services they
need in a timely fashion. The PARDD API aims to improve care
coordination by enabling enhanced communication about when a prior
authorization is required, information that is required to approve a
prior authorization, and facilitating electronic prior authorization.
This would add efficiencies for both payers and providers, and it could
improve patient care by avoiding gaps and delays in care. This API
would be accessible to providers to integrate directly into their
workflow while maintaining compliance with the mandatory HIPAA
transaction standards.
As proposed, by January 1, 2026, impacted payers would be required
to implement and maintain a FHIR PARDD API, populate the API with their
list of covered items and services (excluding drugs) for which prior
authorization is required, and any documentation requirements for the
prior authorization. (For Medicaid managed care plans and CHIP managed
care entities, by the rating period beginning on or after January 1,
2026, and for QHP issuers on the FFEs, for plan years beginning on or
after January 1, 2026.) We considered proposing a phased approach for
the PARDD API where payers would first make the functionality available
for a specified subset of their prior authorization rules and
requirements, as opposed to all of the rules and requirements for all
applicable items and services at one time. We also considered requiring
that payers only prepare the PARDD API for a specific set of services
most commonly requiring prior authorization across payers. However, we
believe this would be more burdensome in some ways. It would require
providers to use different systems to find requirements for different
services for each payer. If the requirements for different services
were in different places, such as some information in payer portals and
some through the PARDD API, providers would have to spend additional
time searching for the information in multiple locations for one payer.
Therefore, we believe it is ultimately less burdensome overall to
require impacted payers to populate the prior authorization and
documentation requirements for all covered items and services
(excluding drugs) at the same time. There are several pilots underway
to test the PARDD API, as well as other tools. The results are all
positive for the policies that are being tested and showcased in
demonstrations at conferences. However, no quantitative data have yet
been shared with CMS to

[[Page 76347]]

include with this proposed rule, but it is anticipated in the near
future.
We also considered a phased timeline approach to implement these
functionalities. For example, we considered first requiring
implementation of the requirements and documentation functionality in
2026 and then a year later requiring implementation of the submission
and decision functionality of the API. We also considered whether to
propose these two capabilities as separate APIs. However, considering
the enforcement discretion we exercised for the APIs finalized in the
CMS Interoperability and Patient Access final rule, we believe it is
more appropriate to propose compliance dates for this policy in 2026,
providing payers with more time to potentially implement both
functionalities at the same time.
We also considered whether we should propose to require that payers
post, on a public-facing website, their list of items and services for
which prior authorization is required and populate the website with
their associated documentation rules as an interim step while they
implement the PARDD API. However, we are aware that some payers already
have this information publicly available, and we determined that this
would not provide any reduced burden on payers or providers at this
time. There is burden associated with updating the information on a
website as the list of prior authorization items is likely to change
frequently, due to the availability of new therapies. We seek comment
on whether a payer website to provide additional transparency to prior
authorization requirements and documentation would be beneficial in
reducing the overall burden in this process.
Another alternative we considered to support prior authorization
was to only use the X12 standard transaction adopted under HIPAA rather
than require the implementation of a FHIR API. The X12 standard defines
the content and format for the exchange of data for specific business
purposes and is designed for administrative transactions between
administrative systems. For prior authorization, the adopted standard
is the X12 278 version 5010. The X12 standard for prior authorization
does not have the functionality of the HL7 IGs to support the proposed
PARDD API to make available the response from the payer in the
provider's health IT system. Furthermore, the CRD, DTR, and PAS IGs
combined, provide the necessary information for the provider to know
the coverage and documentation requirements to submit a compliant prior
authorization request for each payer. X12 is not designed to enable the
use of SMART on FHIR apps connected to the provider's EHR system, nor
is it designed for the scope envisioned in this proposed rule,
including extraction of payer rules, a compilation of data into
electronic-based questionnaires, or communication with EHRs. The
adoption rate of the mandated X12 278 Version 5010 standard is low,
according to data compiled annually by CAQH (described earlier in this
proposed rule). By 2020, the use of the X12 278 standard for prior
authorization transactions had reached 21 percent despite having been
available since 2012. Background on the industry's failure to use the
X12 standards is explained in more detail in section II.D.
We are proposing other provisions, including requiring certain
impacted payers to ensure that prior authorization decisions are made
within 72 hours of receiving an expedited request and no later than 7
days after receiving a standard request, and proposing to require
impacted payers to publicly report prior authorization metrics on their
websites or via a publicly accessible hyperlink(s) annually.
We considered several alternative timeframe policies before
deciding to propose these policies. We considered alternative
timeframes under which payers could provide a decision in less than 72
hours (for expedited decisions) and 7 days (for standard decisions).
For example, we considered requiring payers to provide a decision in 48
hours for expedited requests and 3 days for standard requests. We are
seeking comment on this proposal but decided not to make it an
alternative proposal due to concerns over the feasibility of
implementing such timeframes. We will reevaluate these timeframes at a
future date once the PARDD API is in place, as we believe the PARDD, as
well as the other efficiencies introduced in this proposed rule, would
make shorter timeframes more feasible. Understanding the importance of
providers and patients getting decisions as quickly as possible, we
believe that the timeframes we propose in this rule are a significant
step to help increase reliability in the prior authorization process
and establish clear expectations without being overly burdensome for
payers.
These timeframes allow payers to process the prior authorization
decisions in a timely fashion and give providers and patients an
expectation for when they can anticipate a decision and know when they
can receive care. We also considered whether more than 7 days would be
necessary for complex cases, for example, adding an additional decision
timeframe category to include complex cases. However, we did not
propose this alternative because we believe it is important for
patients and providers to be able to receive a decision in a shorter
timeframe. We believe 7 days is sufficient time for a payer to process
prior authorization decisions.
Regarding publicly reporting prior authorization metrics, we
considered requiring impacted payers to publicly report these metrics
more frequently than annually, such as on a quarterly basis. However,
because most patients typically shop for health insurance coverage on
an annual basis, we believe updating this information annually be
sufficient for making decisions. We also considered whether to allow
payers to report on a selected subset of metrics, rather than taking an
``all or nothing'' approach. After further consideration, we believe
all metrics proposed would be valuable for payers to report publicly.
We also considered reporting these metrics at the parent
organization versus at the organization, plan, or issuer level for all
impacted payers. After further consideration, we decided this may not
be truly operational and may be too aggregated a level of reporting for
some payer types to provide useful information for patients and
providers. As a result, we are proposing reporting at the organization
level for MA, state-level for Medicaid and CHIP FFS programs, plan-
level for Medicaid and CHIP managed care, and at the issuer-level for
QHP issuers on the FFEs.

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

As described in section II.D., we are proposing new requirements
related to prior authorization for impacted payers, and in section
II.E. we described our proposal for measure reporting for MIPS eligible
clinicians, eligible hospitals, and CAHs.
In section IV., we discussed the ICRs regarding cost estimates for
reporting and the potential burden specifically for the MIPS eligible
clinicians, eligible hospitals, and CAHs. In this impact analysis, we
discuss the anticipated cost savings of these proposals for the broader
healthcare provider population, which is inclusive of, but not limited
to the MIPS eligible clinicians, hospitals, and CAHs. We believe that
all healthcare providers could benefit from the proposal for impacted
payers to implement the API proposals in this proposed rule and base
these cost-savings estimates on that total number,

[[Page 76348]]

with estimates described in this section of this rule, of the
proportion of providers that we expect to benefit over the next 10
years. To conduct this analysis, we used available resources to create
the estimates and invite comments on our assumptions, the recency of
our data, and our citations.
The savings we calculate in this section V.G. of this proposed rule
would be true savings, not transfers since they reflect savings in
reducing the administrative costs required to process prior
authorizations. However, these savings would be an indirect consequence
of the proposed rule, not direct savings. This proposed rule supports
efforts to significantly reduce time spent on manual activities. In
general, it is only appropriate to claim that a regulatory provision's
benefits are greater than its costs after a substantive and preferably
quantitative, assessment of the pre-existing market failure and the
provisions' suitability for addressing it. As a result of data
limitations and other analytic challenges preventing such an
assessment, the illustrative savings estimates are neither included in
the monetized table, nor in the summary table of this proposed rule,
nor in the 2016 dollar calculation. Nevertheless, the savings could be
significant, and we believe should be a factor in the evaluation of
this proposed rule. We request comment on this decision not to include
the savings in the final summary Table 27 and related tables.
Recognizing the potential policy interactions this proposed rule has
with other future CMS and HHS rules, as well as Congressional actions,
we request comment on how CMS might attribute savings benefits to avoid
double-counting. What are the implications if the same effects were
attributed to multiple regulations? For example, we note that the
Medicare Advantage program is impacted by several CMS regulations,
which may overlap with one another. How could CMS account for both
costs and benefits from such policy intersections?
We note that we are only quantifying savings of reduced paperwork
for healthcare providers. However, the improved efficiencies proposed
in this rule have several consequences, which could lead to savings. A
2021 survey by the American Medical Association (AMA) \180\ lists
several adverse qualitative consequences of the current paper-based
prior authorization system, including life-threatening adverse medical
events, missed, or abandoned treatments, hospitalization, and permanent
bodily damage. The provisions of this proposed rule, if finalized,
could be an important step in reducing these adverse health events.
---------------------------------------------------------------------------

\180\ American Medical Association (2021). 2021 AMA Prior
Authorization (PA) Physician Survey. Retrieved from https://www.ama-assn.org/system/files/2021-04/prior-authorization-survey.pdf.
---------------------------------------------------------------------------

The approach adopted in quantifying savings is to quantify those
that we can reliably estimate and note that they are minimal savings.
The proposals of this rule potentially affect individual physicians,
physician groups, hospitals, and CAHs. However, for purposes of
quantification, we initially estimate a reduced paperwork burden for
individual physicians and physician groups, which shows a savings of
several billion dollars. We start the estimate with individual
physicians and physician groups because we have reliable data (two
multi-thousand surveys from 2006 and 2021 cited in this section of this
proposed rule, which agree with each other) on (1) the number of hours
per week spent on prior authorization, and (2) the proportion of hours
per week spent by physicians, nurses, and clerical staff.
To then estimate reductions in spending on paperwork for prior
authorization for hospitals, we assume that hospitals perform their
prior authorization activities similar to individual physicians and
physician groups. We make this assumption because we do not have a
basis for making a more accurate assumption; that is, we do not have
similar survey data for hospitals on the number of hours per week spent
on prior authorization and the proportion of hours per week spent by
physicians, nurses, and clerical staff.
To support the assumptions on potential benefits for hospital prior
authorization, we rely on data from the 2023 Hospital Inpatient
Prospective Payment Systems for Acute Care Hospitals and the Long-Term
Care Hospital Prospective Payment System (FY 2023 IPPS/LTCH PPS) final
rule (87 FR 48780) and the CY 2023 Hospital Outpatient Prospective
Payment and Ambulatory Surgical Center Payment Systems (CY 2023 OPPS/
ASC) final rule (87 FR 71748, November 23, 2022) for estimates of the
number of possible organizations that could be impacted. We provide
more information in this section of this proposed rule, about the
estimate of the number of hospitals, 7,978,^{181 182} and the
number of individual physicians and physician groups, 199,543.
---------------------------------------------------------------------------

\181\ Hospital Inpatient Prospective Payment System for Acute
Care Hospitals and the Long-Term Care Hospital Prospective Payment
System and Fiscal Year 2023 Rates (CMS-1771-P) 87 FR 48780 (August
10, 2022). Retrieved from https://www.federalregister.gov/d/2022-16472/p-6888.
\182\ CY 2023 Hospital Outpatient PPS Policy Changes and Payment
Rates and Ambulatory Surgical Center Payment System Policy Changes
and Payment Rates Proposed Rule (CMS-1772-P) 87 FR 44502 (July 26,
2022). Retrieved from https://www.federalregister.gov/d/2022-15372/p-2609.
---------------------------------------------------------------------------

If we assume hospitals are conducting the prior authorization
process in a manner similar to physicians, then in effect we have
increased the number of individual physicians and physician groups from
199,543 to 207,521 entities (199,543 individual physicians and
physician groups plus 7,978 hospitals). We compute aggregate savings by
first estimating the savings for a single individual physician or group
physician practice and then multiplying this single savings by the
number of practices. Therefore, it follows that if 199,543 individual
physician and group physician practices would save money, as shown in
Table 24 of this proposed rule, then 207,521 combined physician
practices and hospitals would save $15.3 billion (207,521/199,543 x
$14.70). When we round the updated savings to the nearest billion there
is no numerical change in the savings since both $15.3 and $14.7 round
to $15 billion. We believe this approach to be the clearest.
In calculating the potential savings, uncertainties arise in four
areas, and the result of this illustrative analysis is that we find a
minimal potential savings impact of between $10 to $20 billion over the
first 10 years of implementation. To provide credibility to this
savings analysis we have, where we lacked better data, underestimated
any unknown quantities with minimal estimates and additionally studied
the effect of a range of estimates. In the next few paragraphs, we
explain each of the four uncertainties, indicate how we approached
estimation, and request public comment.
1. Assumptions on the Relative Proportion of Current Workload Hours by
Staff for Prior Authorization
To estimate the savings impact, we researched estimates of the
current amount of paperwork involved in prior authorization, the type
and number of staff involved, the type of physician offices involved,
and hours per week staff spent engaged in prior authorization
processes. Our assumptions on the relative proportion of current
workload hours by type of staff are based on a survey presented by
Casalino et al. (2009),\183\ which gave a

[[Page 76349]]

detailed analysis based on a validated survey instrument employed in
2006.
---------------------------------------------------------------------------

\183\ 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 Casalino et al. study is dated; therefore, several numbers in
the article were updated, including hourly wages, the number of
physician practices, and the hours per week spent on prior
authorization. We only use this article for the relative proportions of
workload by staff type. We have not found any other studies that
address this data point for physician offices and similarly no studies
that address this same information for hospitals. Staff type is
important because, for example, the hourly wage for clerical staff is
about one-half the hourly wage for nurses and about one-fifth the
hourly wage for physicians; clearly then, the staff doing the paperwork
can significantly affect savings.
Such a design allows us to update wages using the Bureau of Labor
Statistics' (BLS) latest wages. It also allows the allocation of costs
based on the staff member used in the analysis. We used the relative
proportion of time spent by physicians, nurses, and clerical staff
presented in this paper in our estimates since they seemed reasonable
and were not discussed in any other survey reviewed. Thus, though the
article by Casalino et al., is dated, it was useful for proportions of
time spent on paperwork for prior authorization for the following
reasons:
Unlike many subsequent studies, the survey instrument was
validated by several organizations.
Unlike many subsequent studies, the number of physician
practices surveyed was in the thousands.
Finally, we note that several other estimates in the
literature were reviewed,^{184 185 1865 187 188} which,
although reflecting more recent research, either did not show the basis
for their calculations, showed a basis based on a very small number of
people, or used a non-validated survey.
---------------------------------------------------------------------------

\184\ Morley, C.P., Badolato, D.J., Hickner, J., Epling, J.W.
(2013, January). The Impact of Prior Authorization Requirements on
Primary Care Physicians' Offices: Report of Two Parallel Network
Studies. The Journal of the American Board of Family Medicine,
26(1), 93-95. doi: 10.3122/jabfm.2013.01.120062.
\185\ Ward, V. (2018, April). The Shocking Truth About Prior
Authorization in Healthcare. Retrieved from https://getreferralmd.com/2018/04/prior-authorization-problems-healthcare/.
\186\ Robeznieks, A. (2018, November 16). Inside Cleveland
Clinic's $10 million prior authorization price tag. Retrieved from
https://www.ama-assn.org/practice-management/prior-authorization/inside-cleveland-clinic-s-10-million-prior-authorization.
\187\ American Medical Association (2019, June). Prior
Authorization and Utilization Management Reform Principles.
Retrieved from https://www.ama-assn.org/system/files/2019-06/principles-with-signatory-page-for-slsc.pdf.
\188\ American Medical Association (2021). 2021 AMA Prior
Authorization (PA) Physician Survey. Retrieved from https://www.ama-assn.org/system/files/2021-04/prior-authorization-survey.pdf.
---------------------------------------------------------------------------

The Casalino et al. survey excluded certain physician practices,
including health maintenance organizations (HMOs), but analyzed
workload by staff type (doctor, nurse, clerical, administrator, lawyer,
and accountant), office type (solo, 3 to 10 physicians, 10 or more
physicians), and the type of medical work involved (prior
authorization, formulary, claims billing, quality, etc.). Consistent
with our approach, we restricted ourselves to prior authorization
activities, though formulary work could possibly add to burden related
to prior authorization activities.
Table 22 presents an estimate of the current average annual
paperwork burden per physician office for prior authorization
activities. Table 22 estimates an average annual burden per individual
physician or physician group practice of 676 hours at a cost of
$48,882. In reaching this estimate, we note all of the following:
The relative hours per week for physicians, registered
nurses, and clerical staff were, as previously discussed, kept the same
as in the Casalino et al. article.
The labor costs were updated to 2021, using the Bureau of
Labor Statistics (BLS) mean hourly wages.
The 20.4 hours per week estimated for prior authorization
in the Casalino et al. article was reduced to 13 hours per week based
on the AMA survey conducted in 2021.\189\
---------------------------------------------------------------------------

\189\ American Medical Association (2021). 2021 AMA Prior
Authorization (PA) Physician Survey. Retrieved from https://www.ama-assn.org/system/files/2021-04/prior-authorization-survey.pdf.
---------------------------------------------------------------------------

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

2. Assumptions on the Total Number of Individual and Group Physician
Practices
Table 22 presents the current hour and dollar burden per physician
group and individual physician office. To obtain the aggregate annual
burden of prior authorizations for all physician practices, including
those exclusively furnishing services to Fee for Service (FFS)
enrollees, Casalino et al. (2009) multiplies the Table 22 burdens per
physician group and individual physician office by the total number of
individual and group physician practices. Thus, we need an estimate of
the total number of individual and group physician practices.
We assume there are a total of 199,543 individual and group
physician practices (of which the MIPS eligible clinician practices
affected by this proposed rule are a subset). The 199,543 number was
arrived at by dividing the estimated 1,596,340 individual physicians
derived from Table 144 in the CY 2023 Payment Policies Under the
Physician Fee Schedule (PFS) final rule (87 FR 69404, 70171) by an
estimated median number of 8 physicians per

[[Page 76350]]

practice from the Muhlestein et al. (2016) article.^{190 191}
---------------------------------------------------------------------------

\190\ Muhlestein, D. and Smith, N., 2016. Physician
Consolidation: Rapid Movement from Small to Large Group Practices,
2013-15. Health Affairs, 35(9), pp.1638-1642. doi/10.1377/
hlthaff.2016.0130.
\191\ Medicare Physician Payment Proposed Rule Calendar Year
2023 (CMS-1772-P) 87 FR 44502. Table 144. (2022, July 26) Retrieved
from https://www.govinfo.gov/content/pkg/FR-2022-07-26/pdf/2022-15372.pdf.
---------------------------------------------------------------------------

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

\192\ Centers for Medicare & Medicaid Services (2019, November
15). Simplifying Documentation Requirements. Retrieved from https://www.cms.gov/Research-Statistics-Data-and-Systems/Monitoring-Programs/Medicare-FFSCompliance-Programs/SimplifyingRequirements.html.
---------------------------------------------------------------------------

In addition to being able to look up whether a requested item or
service requires prior authorization and, if so, the relevant
documentation requirements, the PARDD API can compile the necessary
data elements to populate the HIPAA-compliant prior authorization
transaction along with the documentation needed and receive an approval
or denial decision from the payer, including any ongoing communications
regarding additional information needed or other status updates.
Currently, many prior authorization requests and decisions are
conducted through one of several burdensome channels, including
telephone, fax, or payer-specific web portals, each of which requires
taking action and monitoring status across multiple and varying
communication channels.
Based on this discussion we assume the following reductions.
Physicians who currently (on average over all physician groups) spend
0.6 hours per week on prior authorization (Table 22) are assumed to
reduce their time by 10 percent. Nurses who currently spend one day
(8.3 hours) per week on prior authorization are assumed to reduce their
time to half a day, a reduction of 50 percent. Clerical staff who
currently spend 4 hours a week on prior authorization are assumed to
reduce their time by 1 hour, a 25 percent reduction. We discuss
alternate assumptions in this section of this proposed rule, after
presenting the total 10-year savings. We also specifically solicit
comments from stakeholders on the reasonableness of these assumptions.
[GRAPHIC] [TIFF OMITTED] TP13DE22.024

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

[[Page 76351]]

4. Assumptions on the Number of Individual and Group Physician
Practices Voluntarily Adopting the Proposals of This Rule
We are not assuming that over 10 years all 199,543 individual and
group physician practices would adopt the proposals of this rule.
Instead we assume as follows:
That the 54,770 MIPS eligible clinicians (individual and
group) a subset of the 199,543 estimated individual and group physician
practices would adopt the proposals of this rule in 2026 (the 1st year
of implementation) since there are payment consequences for them not
doing so.
By 2034, 50 percent of all individual and physician
practices would adopt the proposals of this rule.
We do not assume a constant increase per year but rather a gradual
increase per year. We begin our assumptions with the 54,770 MIPS
eligible clinicians in 2026 and end with the 99,772 (50 percent of
199,543) individual and physician group practices in 2034, expecting an
exponential growth, which is characterized by a slow beginning and more
rapid growth later on.
Applying these assumptions results in a $14.7 billion savings over
10 years, which are shown in Table 24. If we include hospitals by
increasing the amount by 4 percent, the estimate would be $15.2
billion. The estimate rounded to the nearest billion is $15 billion.
The 4 percent increase to account for hospitals is arrived at as
follows. Based on the FY 2023 IPPS/LTCH final rule (87 FR 48780) and
the CY 2023 OPPS/ASC final rule (87 FR 71748) there are 3,142 Inpatient
and Acute Care hospitals; 1,425 CAH hospitals; and 3,411 outpatient
hospitals, or a total of 7,978 hospitals. We estimate that the
hospitals represent 4 percent of the health care industry (7,978
hospitals/199,543 individual and group physician practices) of all
individual and group physician practices, which we acknowledge is a
rough estimate, only using a calculation of numbers. However, without
additional impact studies, we propose using this as our estimate for
savings opportunities.
[GRAPHIC] [TIFF OMITTED] TP13DE22.025

The columns headers of Table 24 show the logic and sources of the
column entries are described here:
Column (1) gives the year, with the first year of
implementation being 2026.
Column (2) gives the total reduced hours for any
individual or group physician practice adopting the proposals of this
rule (Table 23).
Column (3) gives the total reduced dollar spending for any
individual or group physician practice adopting the proposals of this
rule (Table 23).
Column (4) gives the assumed percentage of individual or
group physician practices adopting the proposals of this rule in any
one year. In 2026 we expect 54,770/199,543 or about 27 percent of all
individual and

[[Page 76352]]

physician groups to adopt the proposals. This number gradually
increases until reaching 50 percent in 2035.
Column (5) gives the total number of individual and
physician practices.
Column (6) gives the total hours saved (millions of hours)
by multiplying the hours saved per practice times the number of
practices times the percentage of practices adopting the proposals of
this rule.
Column (7) gives the total dollars saved (billions) by
multiplying the dollars saved per practice times the number of
practices times the percentage of practices adopting the proposals of
this rule.
The sum of savings over the 10 years is indicated in the
next to last row: There is a savings of 205 million hours of work on
prior authorization resulting in $14.7 billion reduced cost over 10
years.
The last row multiplies this amount by 207,521/199,543, as
explained in the introductory paragraphs of this section V.G, to
account for hospitals (Inpatient, Outpatient, and CAHs) assuming
hospitals are subject to the same assumptions we made for individual
physician groups.
As can be seen, to the nearest billion, $15 billion is
saved to physicians and hospitals over 10 years from adopting the
proposals of this proposed rule.
If we assume additional savings, 10 percent, 50 percent, and 50
percent savings for physicians, nurses, and clerical staff respectively
the savings over 10 years would be $17 billion (including savings to
hospitals). If we assume less savings, 10 percent, 33 percent, and 33
percent savings for physicians, nurses, and clerical staff respectively
the savings over 10 years would be $11 billion. Using a wide array of
different assumptions, we expect an aggregate reduction of cost over 10
years of between $10 billion and $20 billion.

H. Summary of Costs

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

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

[[Page 76353]]

Table 25 is based on the most recent projections of the CMS Office
of the Actuary (OACT) for the Mid-Session Review of the President's FY
2022 Budget (MSR 2022).
We illustrate in the 2025 column that 41 percent (1-0.59 shown in
the second row) of Federal Government payments go to the states for
expenditures related to their Medicaid FFS programs and 59 percent (the
number shown in the second row) goes to states for their Medicaid
managed care programs. For state expenditures on Medicaid mechanized
claims processing and information retrieval systems, the Federal
Government pays states 90 percent of their expenditures on the design,
development, installation, or enhancement of such systems, and 75
percent of their expenditures on the ongoing operation of such systems.
For 2025, states receive an average of 65.9 percent FMAP for their
managed care program costs as shown on the third row. Therefore, the
percentage of costs paid in the first year by the Federal Government is
69.6 percent (75 percent x 41 percent + 65.9 percent x 59 percent) as
shown in the fourth row. The calculation of the percent of costs paid
in all years is done similarly except that in the first-year 90 percent
is used for weighting instead of 75 percent. By applying these
percentages to the total Medicaid costs, we obtain Federal costs for
the program. These percentages are used to calculate the total dollars
going from the Federal Government to states.
It should be noted that although the first year of implementation
of this proposed rule is 2026, we expect plans to begin constructing
software systems as soon as the rule is finalized in 2023.
Based on the previous discussion in this proposed rule, the next
section shows the calculation of all impacts of this proposed rule by
program, Government, and QHP issuers. The numerical impacts are
presented in Table 27.
BILLING CODE 4120-01-P

[[Page 76354]]

[GRAPHIC] [TIFF OMITTED] TP13DE22.028

BILLING CODE 4120-01-C
For Table 27:
As explained in the connection with Table 19 in the
Collection of Information section, the data in Table 27 is based on an
expected publication date

[[Page 76355]]

of the final rule is mid-year of 2023 and an effective date of January
1, 2026 for most provisions.
The bottom-line totals in the columns of Table 19 labeled
``1st year cost'' through ``5th Year Cost'' are the totals found in the
``Total Cost'' column of Table 26 in rows 2023 through 2027
respectively. The totals in the column ``Subsequent year costs'' in
Table 19 are found in the rows labeled 2028 through 2032 in the ``Total
Cost'' column of Table 27.
The Total Cost to Providers and Hospitals and CAHs column
reflects the aggregate cost of producing reports for MIPS eligible
individual providers, provider groups, hospitals, and CAHs, as found in
Table 19 for years 2026 and further.
The total 10-year cost (excluding PTC payments and savings
from prior authorization) is, as shown in Table 27, $1.6 billion. This
number uses the primary estimates for the API provisions. The low and
high 10-year total costs are $0.8 billion and $2.3 billion,
respectively.
Cost of Proposed Rule to Payers by Program columns: We
applied the percentages from Table 25 to obtain the cost of the rule to
payers by program (MA, Medicaid, CHIP, and QHP issuers on the FFEs).
Cost of Proposed Rule to Government by Program columns: We
applied the percentages of payment by the Federal Government discussed
in the narrative on Table 26 to obtain the cost by program.
PTC Payments: The Government does not reimburse QHPs,
either partially or totally, nor prospectively or retrospectively, for
their expenses in furnishing health benefits. However, the Government
does offer QHP enrollees PTC credits to help cover the cost of premiums
for the plans. QHP issuers on the FFEs have the option to deal with
increased costs by either temporarily absorbing them (for purposes of
market competitiveness--see, however, a caveat elsewhere in this
regulatory impact analysis), increasing premiums to enrollees, or
reducing non-essential health benefits. To the extent that issuers
increase premiums for individual market-qualified health plans on the
FFEs, there would be Federal PTC impacts. The purpose of the PTC is to
assist enrollees in paying premiums. Since PTCs are only available if
an individual purchases a qualified health plan on an Exchange and the
individual has an income between 100 and 400 percent of the Federal
Poverty Level, the PTC estimates apply only to Exchange plans. In the
PTC estimate, we have accounted for the fact that some issuers have
both Exchange and non-Exchange plans, and some issuers have only non-
Exchange plans. We reflected these assumptions with global adjustments,
so we believe the estimates are reasonable in aggregate.
The methodology to estimate the PTC impact of the projected expense
burden is consistent with the method used to estimate the PTC impact in
the CMS Interoperability and Patient Access final rule (85 FR 25612).
Within the FFE states, the estimated expense burden would impact
premium rates in the individual market and is spread across both
Exchange and non-Exchange plans. PTCs are only paid in the Exchanges
and are calculated as a function of the second lowest cost silver plan
and the eligible individual's household income. The estimate of these
impacts uses the assumption that the industry would increase the second
lowest cost silver plan premium rate in the same amount as the overall
premium rate increase. This assumption allows the application of the
overall rate increase to the projected PTC payments in the FFE states
to estimate the impact on PTC payments. The PTC payments are currently
slightly over 50 percent of total costs.
The total cost to the Government is the sum of payments related to
each program. This payment is a transfer from the Government to payers
for Medicare Advantage and Medicaid, CHIP, and QHP enrollees.
Remaining Cost to Payers columns: For MA organizations,
and Medicaid and CHIP, the remaining costs are the difference between
the total cost to payers and what the Federal Government pays. For the
individual market, the remaining costs to payers would be the total
cost absorbed by the payers and not passed on through premium
increases. Since the PTC is paid on behalf of individuals and not the
payers, it therefore does not reduce the expenses of the payers.
Note: The dollar savings from reduced paperwork burden for an
increase in use of electronic prior authorization (Tables 22 through
Table 24) is not included in Table 27.
We next explain how the various plans (and states) would bear the
costs remaining after Federal payments. We follow the same methodology
and discussion presented in the CMS Interoperability and Patient Access
final rule (85 FR 25612).
[GRAPHIC] [TIFF OMITTED] TP13DE22.029

[[Page 76356]]

In Table 28 we explain possible ways payers may manage these extra
implementation costs. We emphasize that Table 28 lists possibilities.
Payers would ultimately make decisions about how to defray these
remaining costs based on market dynamics and internal business
decisions, and we have no uniform way of predicting what these actual
behaviors and responses will be.
Individual Market Plans: Individual market plans have the option of
absorbing costs or passing costs to enrollees either in the form of
higher premiums or reduced benefits that are non-essential health
benefits (EHBs). CMS has seen in some cases that plans, for reasons of
market competitiveness, will absorb costs rather than increase premiums
or reduce benefits. The temporary claim refers to the possibility that
plans will balance competitive pressures with profit targets
immediately following a new regulation. As the regulations are
typically finalized within a few months of the bid submission deadline,
plans may have more time to enact strategies that do not require large
benefit changes in subsequent years, such as negotiations for
supplemental benefit offerings.
Medicaid and CHIP: Assuming roughly 71 million enrollees nationally
(inclusive of Medicaid and CHIP FFS programs, Medicaid managed care
plans, and CHIP managed care entities), Medicaid and CHIP would see an
added cost of under a dollar per beneficiary per year; this contrasts
with a total cost per beneficiary per year for the Medicaid and CHIP
programs of several thousand dollars.\193\
---------------------------------------------------------------------------

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

Medicare Advantage: In their bids (submitted the June prior to the
beginning of the coverage year), Medicare Advantage plans would address
the reduced rebates (arising from increased bid costs due to the
increased costs of this proposed rule being included in the bid) by
either: temporarily absorbing costs by reducing profit margins,
reducing the supplemental benefits paid for by the rebates, or raising
enrollee cost sharing or premium. We believe many plans, for
competitive reasons, would choose to retain a zero-dollar premium
increase and either absorb losses for 1 year or reduce rebate-funded
supplemental benefits.

I. Accounting Statement and Table

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

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

VI. Response to Comments

Because of the large number of public comments, we normally receive
on Federal Register documents, we are not able to acknowledge or
respond to them individually. We will consider all comments we receive
by the date and time specified in the DATES section of this preamble,
and, when we proceed with a subsequent document, we will respond to the
comments in the preamble to that document.
Chiquita Brooks-LaSure, Administrator of the Centers for Medicare &
Medicaid Services, approved this document on November 23, 2022.

[[Page 76357]]

List of Subjects

42 CFR Part 422

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

42 CFR Part 431

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

42 CFR Part 435

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

42 CFR Part 438

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

42 CFR Part 440

Grant programs-health, Medicaid.

42 CFR Part 457

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

45 CFR Part 156

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

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

Title 42--Public Health

PART 422--MEDICARE ADVANTAGE PROGRAM

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

Authority: 42 U.S.C. 1302 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 at 45 CFR 170.213, if the MA organization maintains any such
data, no later than 1 business day after the MA organization receives
the data; and
(iv) Beginning January 1, 2026, the information in paragraph
(b)(1)(iv)(A) of this section about prior authorizations for items and
services (excluding drugs, as defined at 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 and related
administrative and clinical documentation, including all of the
following, as applicable:
(1) The status of the prior authorization.
(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 and the quantity used to date.
(5) If denied, a specific reason why the request was denied.
(B) The information in paragraph (b)(1)(iv)(A) of this section must
be accessible no later than 1 business day after the MA organization
receives a prior authorization request, and must be updated no later
than 1 business day after any change in status. All information must
continue to be accessible for the duration that the authorization is
active and at least 1 year from the date of 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.
* * * * *
(c) * * *
(1) Must use API technology conformant with 45 CFR 170.215(a)
through (3) and (b);
* * * * *
(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 described 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 applications and
developers through which parties seek to access electronic health
information, as defined at 45 CFR 171.102, including but not limited to
criteria that may rely on automated monitoring and risk mitigation
tools.
(f) Reporting on the use of the Patient Access API. Beginning in
2026, by March 31 following any calendar year that an MA organization
operates, the MA organization must report to CMS the following metrics,
in the form of aggregated, de-identified data, for the previous
calendar year at the organization level:
(1) The total number of unique enrollees whose data are transferred
via the Patient Access API to a health app designated by the enrollee;
and
(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 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 January 1, 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 to providers and
payers.

(a) Application Programming Interface to support data transfer from
payers to providers--Provider Access API. Beginning January 1, 2026, an
MA organization must:
(1) Accessible content and API requirements. Implement and maintain
a standards-based Application Programming Interface (API) compliant
with Sec. 422.119(c), (d), and (e), as well as the standard at 42 CFR
170.215(a)(4), that complies with the following:
(i) API requirements and accessible content. Make data specified in
paragraph (a)(1)(ii) of this section available to in-network providers
no later than 1 business day after receiving

[[Page 76358]]

a request from such a provider, if all the following conditions are
met:
(A) The MA organization authenticates the identity of the provider
that requests access using the required authorization and
authentication protocols at 45 CFR 170.215(b) and attributes the
enrollee to the provider under the attribution process required in
paragraph (a)(2) of this section.
(B) The enrollee does not opt out per paragraph (a)(3) of this
section.
(C) Disclosure of the data is permitted by applicable law.
(ii) Individual enrollee data. Make the data available 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,
if maintained by the MA organization.
(2) Attribution. Maintain a process to associate enrollees with
their in-network providers to enable payer-to-provider data exchange
via the Provider Access API.
(3) Opt Out and patient educational resources. (i) Maintain a
process to allow an enrollee or the enrollee's personal representative
to opt out of and subsequently opt into the data sharing requirements
specified in paragraph (a)(1) of this section. 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 non-technical, simple and
easy-to-understand 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 opting in after previously opting
out:
(A) Before the first date on which the MA organization makes
enrollee information available through the Provider Access API; and
(B) At enrollment; and
(C) At least annually; and
(D) In an easily accessible location on its public website.
(4) Provider resources regarding APIs. Provide on its website and
through other appropriate provider communications, educational
resources in non-technical and easy-to-understand language explaining
the process for requesting enrollee data using the Provider Access API
described at paragraph (a)(1) of this section. The resources must
include information about how to use the MA organization's attribution
process to associate patients with the provider.
(b) Application Programming Interface to support data transfer
between payers--Payer-to-Payer API. Beginning January 1, 2026:
(1) API requirements and accessible content. An MA organization
must implement and maintain an API that--
(i) Is compliant with Sec. 422.119(c), (d), and (e), as well as
the standard at 42 CFR 170.215(a)(4); and
(ii) Makes available 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, if maintained by the MA
organization.
(2) Opt in. An MA organization must establish and maintain a
process to allow enrollees or their personal representatives to opt in
to the MA organization's Payer-to-Payer API data exchange with the
enrollee's previous payer, described in paragraph (b)(4) of this
section, and with concurrent payer(s), described in paragraph (b)(5) of
this section, and to allow enrollees to change their preference 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 enrollment.
(ii) [Reserved]
(3) Identify previous and/or concurrent payers. An MA organization
must maintain a process to identify a new enrollee's previous and/or
concurrent payer(s) to facilitate the Payer-to-Payer API data exchange.
The information request process must take place:
(i) For current enrollees, no later than the compliance date.
(ii) For new enrollees, no later than enrollment.
(4) Data exchange requirement. (i) An MA organization must request
the data specified in paragraph (b)(1)(ii) of this section from the
enrollee's previous payer through the standards-based API described in
paragraph (b)(1) of this section, if the enrollee has opted in as
described in paragraph (b)(2) of this section, and as permitted by
applicable law. 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. The MA organization
must complete this request:
(A) For new enrollees, no later than 1 week after the start of
coverage.
(B) At an enrollee's request, within 1 week of the request.
(C) For an enrollee who opts in or provides previous and/or
concurrent payer information after enrollment, within 1 week.
(ii) The MA organization must incorporate into the enrollee's
record any data received from other payers in response to the request.
(iii) The MA organization must make data specified in paragraph
(b)(1)(ii) of this section available to other payers via the standards-
based API described in paragraph (b)(1) of this section within 1
business day of receiving a request if all the following conditions are
met:
(A) The payer that requests access has its identity authenticated
using the authorization and authentication protocols at 45 CFR
170.215(b) and includes an attestation with the request that the
patient is enrolled with the payer and has opted in to the data
exchange.
(B) Disclosure of the data is not prohibited by law.
(5) Concurrent coverage data exchange requirement. When an enrollee
has provided concurrent coverage information per paragraph (b)(3) of
this section, and has opted in per paragraph (b)(2) of this section, an
MA organization must, through the standards-based API described in
paragraph (b)(1) of this section:
(i) No later than 1 week after enrollment, and then at least
quarterly, request the enrollee's data from all known concurrent payers
in accordance with paragraphs (b)(4)(i) and (ii) of this section.
(ii) Within 1 business day of a request from any concurrent payers,
respond in accordance with paragraph (b)(4)(iii) of this section.
(6) Educational materials. An MA organization must provide
information to enrollees in non-technical, simple, and easy-to-
understand language, explaining at a minimum: the benefits of Payer-to-
Payer API data exchange, their ability to opt in or withdraw a previous
opt in decision, and instructions for doing so. The MA organization
must provide these materials--
(i) At or before requesting an enrollee's consent 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; and
(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 prior authorization status to providers,
including reason for denial. Beginning January 1, 2026, MA
organizations must

[[Page 76359]]

provide specific information about prior authorization requests
(excluding drugs as defined at Sec. 422.119(b)(1)(v)) to providers,
regardless of the method used to communicate that information, in a
manner that is consistent with the following requirements:
(1) The MA organization's prior authorization response to the
provider must indicate whether the MA organization approves the prior
authorization request (and for how long), denies the prior
authorization request, or requests more information related to the
prior authorization request.
(2) If the MA organization denies the prior authorization request,
the response to the provider must include a specific reason for the
denial.
(b) Prior authorization requirements, documentation and decision
(PARDD) Application Programming Interface (API). Beginning January 1,
2026, an MA organization must implement and maintain a standards-based
API compliant with Sec. 422.119(c), (d), and (e) that--
(1) Is populated with the MA organization's list of covered items
and services (excluding drugs, as defined at Sec. 422.119(b)(1)(v))
for which prior authorization is required, and any documentation
requirements for the authorization;
(2) Include functionality to determine requirements for any other
data, forms or medical record documentation required by the MA
organization for the items or services for which the provider is
seeking prior authorization;
(3) Facilitates a Health Insurance Portability and Accountability
Act (HIPAA)-compliant prior authorization request and response; and
(4) Includes the information required at Sec. 422.122(a).
(c) Publicly reporting prior authorization metrics. Beginning in
2026, following each calendar year that it operates, an MA organization
must report prior authorization data, excluding data on drugs, as
defined at Sec. 422.119(b)(1)(v), at the organization level by March
31. The MA organization must make the following data from the previous
calendar year publicly accessible by posting it directly on its website
or via hyperlink(s):
(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 and either of the following:
(i) No later than 14 calendar days after receiving the request for
the standard organization determination; or
(ii) On or after January 1, 2026, for a service or item subject to
the prior authorization rules at Sec. 422.122, no later than 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. When the MA organization extends the
timeframe, it must notify the enrollee in writing of the reasons for
the delay, and inform the enrollee of the right to file an expedited
grievance if he or she disagrees with the MA organization's decision to
grant an extension. The MA organization must notify the enrollee of its
determination as expeditiously as the enrollee's health 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 and either of the following:
(1) No later than 14 calendar days after receiving the request for
the standard integrated organization determination; or
(2) On or after January 1, 2026, for a service or item subject to
the prior authorization rules at Sec. 422.122, no later than 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

[[Page 76360]]

timeframe established in paragraph (d)(2)(i) 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. Adding 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 at 45 CFR 170.213, if the State maintains any such data, no
later than 1 business day after the State receives the data; and
* * * * *
(5) Beginning January 1, 2026, the information in paragraph
(b)(5)(i) of this section about prior authorizations for items and
services (excluding drugs as defined at 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 and related
administrative and clinical documentation, including all of the
following, as applicable:
(A) The status of the prior authorization.
(B) The date the prior authorization was approved or denied.
(C) The date or circumstance under which the authorization ends.
(D) The items and services approved and the quantity used to date.
(E) If denied, a specific reason why the request was denied.
(ii) The information in paragraph (b)(5)(i) of this section must be
accessible no later than 1 business day after the State receives a
prior authorization request, and must be updated no later than 1
business day after any change in status. All information must continue
to be accessible for the duration that the authorization is active and
at least 1 year from the date of the prior authorization's last status
change.
(6) Drugs are defined for purposes of paragraph (b)(5) of this
section as any and all drugs covered by the State.
* * * * *
(c) * * *
(1) Must use API technology conformant with 45 CFR 170.215(a)(1)
through (3) and (b);
* * * * *
(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 described 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 applications and
developers through which parties seek to access electronic health
information, as defined at 45 CFR 171.102, including but not limited to
criteria that may rely on automated monitoring and risk mitigation
tools.
* * * * *
(h) Reporting on the use of the Patient Access API. 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:
(1) The total number of unique beneficiaries whose data are
transferred via the Patient Access API to a health app designated by
the beneficiary.
(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.
0
10. Section 431.61 is added to read as follows:

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

(a) Application Programming Interface to support data transfer from
payers to providers--Provider Access API. Beginning January 1, 2026,
unless granted an extension or exemption under paragraph (c) of this
section, a State must do the following:
(1) Accessible content and API requirements. Implement and maintain
a standards-based Application Programming Interface (API) compliant
with Sec. 431.60(c), (d), and (e), as well as the standard at 42 CFR
170.215(a)(4), that complies with the following:
(i) API requirements and accessible content. Make data specified in
paragraph (a)(1)(ii) of this section available to enrolled Medicaid
providers no later than 1 business day after receiving a request from
such a provider, if all the following conditions are met:
(A) The State authenticates the identity of the provider that
requests access using the required authorization and authentication
protocols at 45 CFR 170.215(b) and attributes the beneficiary to the
provider under the attribution process required in paragraph (a)(2) of
this section.
(B) The beneficiary does not opt out per paragraph (a)(3) of this
section.
(C) Disclosure of the data is permitted by applicable law.
(ii) Individual beneficiary data. Make available the data specified
at Sec. 431.60(b) with a date of service on or after January 1, 2016,
excluding provider remittances and beneficiary cost-sharing
information, if maintained by the State.
(2) Attribution. Maintain a process to associate beneficiaries with
their Medicaid-enrolled providers to enable payer-to-provider data
exchange via the Provider Access API.
(3) Opt out and patient educational resources. (i) Maintain a
process to allow a beneficiary or the beneficiary's personal
representative to opt out of or subsequently opt into the data sharing
requirements specified in paragraph (a)(1) of this section. 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 non-technical, simple,
and easy-to-understand 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 opting in after previously opting
out--
(A) Before the first date on which the State makes beneficiary
information available through the Provider Access API;
(B) At enrollment;
(C) At least annually; and
(D) In an easily accessible location on its public website.
(4) Provider resources regarding APIs. Provide on its website and
through other appropriate provider communications, educational
resources in non-technical and easy-to-understand language explaining
the process for requesting beneficiary data using the Provider Access
API described in paragraph (a)(1) of this section. The

[[Page 76361]]

resources must include information about how to use the State's
attribution process to associate patients with the provider.
(b) Application Programming Interface to support data transfer
between payers--Payer-to-Payer API. Beginning January 1, 2026, unless
granted an extension or exemption under paragraph (c) of this section:
(1) Accessible content and API requirements. A State must implement
and maintain an API that--
(i) Is compliant with Sec. 431.60(c), (d), and (e), as well as the
standard at 42 CFR 170.215(a)(4); and
(ii) Makes available the data specified at Sec. 431.60(b) with a
date of service on or after January 1, 2016, excluding provider
remittances and beneficiary cost-sharing, if maintained by the State.
(2) Opt in. A State must establish and maintain a process to allow
beneficiaries or their personal representatives to opt in to the
State's Payer-to-Payer API data exchange with the beneficiary's
previous payer(s), described in paragraph (b)(4) of this section, and
concurrent payer(s), described in paragraph (b)(5) of this section, and
to allow beneficiaries to change their preference at any time.
(i) The opt in process must be offered:
(A) To current beneficiaries, no later than the compliance date.
(B) To new beneficiaries, no later than enrollment.
(ii) If a beneficiary has coverage through any Medicaid managed
care plans within the same State while enrolled in Medicaid, the State
must share their opt in preference with those managed care plans to
allow the Payer-to-Payer API data exchange described in this section.
(3) Identify previous and/or concurrent payers. A State must
maintain a process to identify a new beneficiary's previous and/or
concurrent payer(s) to facilitate the Payer-to-Payer API data exchange.
The information request process must take place:
(i) For current beneficiaries, no later than the compliance date.
(ii) For new beneficiaries, no later than enrollment.
(4) Data exchange requirement. (i) A State must request the data
specified in paragraph (b)(1)(ii) of this section from the
beneficiary's previous payer through the standards-based API described
in paragraph (b)(1) of this section, if the beneficiary has opted in as
described in paragraph (b)(2) of this section, and as permitted by
applicable law. 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. The State must complete this request:
(A) For new beneficiaries, no later than 1 week after enrollment.
(B) At a beneficiary's request, within 1 week of the request.
(C) For a beneficiary who opts in or provides previous and/or
concurrent payer information after enrollment, within 1 week.
(ii) The State must incorporate into the beneficiary's record any
data received from other payers in response to the request.
(iii) The State must make data specified in paragraph (b)(1)(ii) of
this section available to other payers via the standards-based API
described in paragraph (b)(1) of this section within 1 business day of
receiving a request if all the following conditions are met:
(A) The payer that requests access has its identity authenticated
using the authorization and authentication protocols at 45 CFR
170.215(b) and includes an attestation with the request that the
patient is enrolled with the payer and has opted in to the data
exchange.
(B) Disclosure of the data is not prohibited by law.
(5) Concurrent coverage data exchange requirement. When a
beneficiary has provided concurrent coverage information, per paragraph
(b)(3) of this section, and has opted in per paragraph (b)(2) of this
section, a State must, through the standards-based API described in
paragraph (b)(1) of this section:
(i) No later than one week after enrollment, and then at least
quarterly, request the beneficiary's data from all known concurrent
payers in accordance with paragraph (b)(4)(i) and (ii) of this section;
and
(ii) Within one business day of a request from any concurrent
payers, respond in accordance with paragraph (b)(4)(iii) of this
section.
(6) Educational materials. A State must provide information to
applicants or beneficiaries in non-technical, simple, and easy-to-
understand language, explaining at a minimum: the benefits of Payer-to-
Payer API data exchange, their ability to opt in or withdraw a previous
opt in decision, and instructions for doing so. The State must provide
these materials:
(i) At or before requesting a beneficiary's consent 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; and
(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 to delay implementation of the
requirements in paragraphs (a) and/or (b) of this section, for a one-
time, one-year extension for its Medicaid 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 and must include all
the following:
(A) A narrative justification describing the specific reasons why
the State cannot reasonably satisfy the requirement(s) by the
compliance date and why those reasons result from circumstances that
are unique to the agency operating the Medicaid fee-for service
program;
(B) A report on completed and ongoing State implementation
activities that evidence a good faith effort towards compliance; and
(C) A comprehensive plan to meet implementation requirements no
later than 1 year after the compliance date.
(ii) CMS will grant the State's request if it determines based on
the information provided in the State's annual Advance Planning
Document (APD) for Medicaid Management Information System (MMIS)
operations expenditures that the request adequately establishes a need
to delay implementation; and that the State has a comprehensive plan to
implement 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. [thinsp]438.2,
may request an exemption for its fee-for-service program from the
requirement(s) in paragraphs (a) and/or (b) of this section.
(A) The exemption request must be submitted in writing as part of a
State's annual Advance Planning Document (APD) for Medicaid Management
Information System (MMIS) operations expenditures prior to the date by
which the state would otherwise need to comply with the applicable
requirement.
(B) The State's request must include documentation that the State
meets the criteria for the exemption, based on enrollment data from the
most recent CMS ``Medicaid Managed Care Enrollment and Program
Characteristics'' report, and must also include information about an
alternative

[[Page 76362]]

plan to ensure that enrolled providers will have efficient electronic
access to the same information through other means while the exemption
is in effect.
(ii) CMS will grant the 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.
(iii) The State's exemption would expire if:
(A) Based on the 3 previous years of available, finalized Medicaid
Transformed Medicaid Statistical Information System (T-MSIS) managed
care and fee-for-service (FFS) enrollment data, the State's managed
care enrollment for 2 of the previous 3 years is below 90 percent; or
(B) CMS has approved a State plan amendment, waiver, or waiver
amendment that would significantly reduce the share of beneficiaries
enrolled in managed care and the anticipated shift in enrollment is
confirmed by the first available, finalized Medicaid T-MSIS managed
care and FFS enrollment data.
(iv) If a State's exemption expires per paragraph (c)(2)(iii) of
this section, the State would be required to--
(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 or approval of a
State plan amendment, waiver, or waiver amendment confirming 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; and
(B) Obtain CMS approval of a timeline for compliance with the
requirements at paragraphs (a) and/or (b) of this section within two
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 prior authorization statuses to providers,
including reason for denial. Beginning January 1, 2026, States must
provide specific information about prior authorization requests
(excluding drugs, as defined at Sec. 431.60(b)(6)) to providers,
regardless of the method used to communicate that information, in a
manner that is consistent with the following requirements:
(1) The State's prior authorization response to the provider must
indicate whether the State approves the prior authorization request
(and for how long), denies the prior authorization request, or requests
more information related to the prior authorization request.
(2) If the State denies the prior authorization request, the
response to the provider must include a specific reason for the denial.
(b) Prior authorization requirements, documentation and decision
(PARDD) Application Programming Interface (API). Unless granted an
extension or exemption under paragraph (c) of this section, beginning
January 1, 2026, a State must implement and maintain a standards-based
API compliant with Sec. 431.60(c), (d), and (e) that:
(1) Is populated with the State's list of covered items and
services (excluding drugs, as defined at Sec. 431.60(b)(6)) for which
prior authorization is required, and any documentation requirements for
the authorization;
(2) Includes functionality to determine requirements for any other
data, forms or medical record documentation required by the State for
the items or services for which the provider is seeking prior
authorization;
(3) Facilitates a Health Insurance Portability and Accountability
Act (HIPAA)-compliant prior authorization request and response; and
(4) Includes the information required at paragraph (a) of this
section.
(c) Extensions and exemptions--(1) Extension. (i) A State may
submit a written application to request to delay implementation of the
requirements in paragraph (b) of this section, for a one-time, one-year
extension for its Medicaid 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 and must include all
the following:
(A) A narrative justification describing the specific reasons why
the State cannot reasonably satisfy the requirement(s) by the
compliance date and explaining why those reasons result from
circumstances that are unique to the agency operating the Medicaid fee-
for service program;
(B) A report on completed and ongoing State implementation
activities that evidence a good faith effort towards compliance; and
(C) A comprehensive plan to meet implementation requirements no
later than 1 year after the compliance date.
(ii) CMS will grant the State's request if it determines based on
the information provided in the State's annual Advance Planning
Document for MMIS operations expenditures that the request adequately
establishes a need to delay implementation; and that the State has a
comprehensive plan to implement 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. [thinsp]438.2,
may request an exemption for its fee-for-service program from the
requirements in paragraph (b) of this section.
(A) The exemption request must be submitted in writing as part of a
State's annual Advance Planning Document for Medicaid Management
Information System (MMIS) operations expenditures prior to the date by
which the state would otherwise need to comply with the applicable
requirement.
(B) The State's request must include documentation that
demonstrates that the State meets the criteria for the exemption, based
on enrollment data from the most recent CMS ``Medicaid Managed Care
Enrollment and Program Characteristics'' report, and must also include
information about an alternative plan to ensure that enrolled providers
will have efficient electronic access to the same information through
other means while the exemption is in effect.
(ii) CMS will grant the 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 there will be efficient
electronic access the same information through alternative means while
the exemption is in effect.
(iii) The State's exemption would expire if:
(A) Based on the 3 previous years of available, finalized Medicaid
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) CMS has approved a State plan amendment, waiver, or waiver
amendment that would significantly reduce the share of beneficiaries
enrolled in managed care, and the anticipated shift in enrollment is
confirmed by the first available, finalized Medicaid T-MSIS managed
care and FFS enrollment data.
(iv) If a State's exemption expires per paragraph (c)(2)(iii) of
this section, the State would be required to:

[[Page 76363]]

(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 confirming that
there has been a shift from managed care enrollment to FFS enrollment
resulting in the State's managed care enrollment falling below the 90
percent threshold; and
(B) Obtain CMS approval of a timeline for compliance with the
requirements at paragraph (b) of this section within two 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:
(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 enrollee liability, including a
determination that an enrollee 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 an enrollee 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 with regard to 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 is revised 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) 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 a new paragraph (f).
The addition and revision read as follows:

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 either of the following, as
appropriate:
(A) For rating periods that start before January 1, 2026, within
State-established timeframes that may not exceed 14 calendar days after
receiving the request.
(B) For rating periods that start on or after January 1, 2026,
within State-established timeframes that may not exceed 7 calendar days
after receiving the request.
(ii) Standard authorization decisions may have an extension to the
timeframes in paragraph (d)(1)(i) of this section may have a possible
extension of 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 within State-
established timeframes that are no later than 72 hours after receipt of
the request for service unless a shorter minimum time frame is
established under State law.
* * * * *
(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 it directly on its website or via
hyperlink(s):
(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

[[Page 76364]]

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) and (8) 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) as
specified 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 and Sec. 438.3(s).
(iii) Report metrics specified at Sec. 431.60(h) of this chapter
at the plan level.
* * * * *
(7) By the rating period beginning on or after January 1, 2026,
comply with Sec. Sec. 431.61(a), (b)(1), (4), and (5), and (b)(6)(ii)
and (iii) and 431.80 of this chapter as if such requirements applied
directly to the MCO, PIHP, or PAHP.
(8) The following timeframes apply to paragraph (b)(5) of this
section:
(i) Except for the requirements at 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 at 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 at 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 paragraphs (e) and (f) to read
as follows:

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

* * * * *
(e) The State Medicaid agency must--
(1) Beginning January 1, 2026, provide notice of prior
authorization decisions for items and services (excluding drugs, as
defined at Sec. 431.60(b)(6) of this chapter) as follows:
(i) For standard determinations, 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
time frame 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 time frame
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.
(f) Beginning in 2026, a State must annually report prior
authorization data, excluding data on drugs, as defined at 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 it directly on its website or via hyperlink(s):
(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 Medicaid agency, 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 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)(1) to read as
follows:

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

* * * * *
(d) * * *
(1) 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 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; and
* * * * *
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

[[Page 76365]]

apply to Medicaid expansion programs. Separate child health programs
that provide benefits exclusively through managed care organizations
may meet the requirements of Sec. Sec. 457.730, 457.731, and 457.732
by requiring the managed care organizations 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 paragraph (b)(5) and (6);
0
c. Revising paragraphs (c)(1) and (c)(3) introductory text;
0
d. Adding paragraph (c)(3)(iii);
0
e. Revising paragraphs (c)(4) introductory text, (c)(4)(ii)(C), and
(e)(2); and
0
g. Adding 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 at 45 CFR 170.213, if the State maintains any such data, no
later than 1 business day after the State receives the data; and
* * * * *
(5) Beginning January 1, 2026, the information in paragraph
(b)(5)(i) of this section about prior authorizations for items and
services (excluding drugs as defined at 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 and related
administrative and clinical documentation, including all of the
following, as applicable:
(A) The status of the prior authorization.
(B) The date the prior authorization was approved or denied.
(C) The date or circumstance under which the authorization ends.
(D) The items and services approved and the quantity used to date.
(E) If denied, a specific reason why the request was denied.
(ii) The information in paragraph (b)(5)(i) of this section must be
accessible no later than 1 business day after the State receives a
prior authorization request, and must be updated no later than 1
business day after any change in status. All information must continue
to be accessible for the duration that the authorization is active and
at least 1 year from the date of 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 use API technology conformant with 45 CFR 170.215(a)(1)
through (3) and (b);
* * * * *
(3) Must comply with the content and vocabulary standard
requirements in paragraphs (c)(3)(i) and (ii) of this section, as
applicable to the data type or data element, unless alternate standards
are required by other applicable law, and be conformant with the
requirements in paragraphs (c)(3)(iii) of this section:
* * * * *
(iii) Beginning January 1, 2026, for data specified in paragraphs
(b)(1) through (5) of this section.
(4) May use an updated version of any standard or all standards
required under paragraph (b) or (c) of this section and Sec. Sec.
457.731, 457.732, and 457.760, where:
* * * * *
(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 described 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 applications and
developers through which parties seek to access electronic health
information, as defined at 45 CFR 171.102, including but not limited to
criteria that may rely on automated monitoring and risk mitigation
tools.
* * * * *
(h) Reporting on the use of the Patient Access API. 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:
(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.
0
27. Section 457.731 is added to read as follows:

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

(a) Application Programming Interface to support data transfer from
payers to providers--Provider Access API. Beginning January 1, 2026,
unless granted an extension or exemption under paragraph (c) of this
section, a State must:
(1) Accessible content and API requirements. Implement and maintain
a standards-based Application Programming Interface (API) compliant
with Sec. 457.730(c), (d), and (e), as well as the standard at 42 CFR
170.215(a)(4), that complies with the following:
(i) API requirements and accessible content. Make data specified in
paragraph (a)(1)(ii) of this section available to enrolled CHIP
providers no later than 1 business day after receiving a request from
such a provider, if all the following conditions are met:
(A) The State authenticates the identity of the provider that
requests access using the required authorization and authentication
protocols at 45 CFR 170.215(b) and attributes the beneficiary to the
provider under the attribution process required in paragraph (a)(2) of
this section.
(B) The beneficiary does not opt out per paragraph (a)(3) of this
section.
(C) Disclosure of the data is permitted by applicable law.
(ii) Individual beneficiary data. Make available the data specified
at Sec. 457.730(b) with a date of service on or after January 1, 2016,
excluding provider remittances and beneficiary cost-sharing
information, if maintained by the State.
(2) Attribution. Maintain a process to associate beneficiaries with
their CHIP-enrolled providers to enable payer-to-provider data exchange
via the Provider Access API.
(3) Opt out and patient educational resources. (i) Maintain a
process to allow a beneficiary or the beneficiary's personal
representative to opt out of or subsequently opt into the data sharing
requirements specified in paragraph (a)(1) of this section. 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 non-technical, simple
and easy-to-understand 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 opting in after previously opting
out:
(A) Before the first date on which the State makes beneficiary
information available through the Provider Access API; and
(B) At enrollment; and
(C) At least annually; and
(D) In an easily accessible location on its public website.

[[Page 76366]]

(4) Provider resources regarding APIs. Provide on its website and
through other appropriate provider communications, educational
resources in non-technical and easy-to-understand language explaining
the process for requesting beneficiary data using the Provider Access
API described in paragraph (a)(1) of this section. The resources must
include information about how to use the State's attribution process to
associate patients with the provider.
(b) Application Programming Interface to support data transfer
between payers--Payer-to-Payer API. Beginning January 1, 2026, unless
granted an extension or exemption under paragraph (c) of this section:
(1) Accessible content and API requirements. A State must implement
and maintain an API that:
(i) Is compliant with Sec. 457.730(c), (d), and (e), as well as
the standard at 42 CFR 170.215(a)(4); and
(ii) Makes available the data specified at Sec. 457.730(b) with a
date of service on or after January 1, 2016, excluding provider
remittances and beneficiary cost-sharing, if maintained by the State.
(2) Opt in. A State must establish and maintain a process to allow
beneficiaries or their personal representatives to opt in to the
State's Payer-to-Payer API data exchange with the beneficiary's
previous payer(s), described in paragraph (b)(4) of this section, and
concurrent payer(s), described in paragraph (b)(5) of this section, and
to allow beneficiaries to change their preference at any time.
(i) The opt in process must be offered:
(A) To current beneficiaries, no later than the compliance date.
(B) To new beneficiaries, no later than 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 preference with those managed care entities to allow
the Payer-to-Payer API data exchange described in this section.
(3) Identify previous and/or concurrent payers. A State must
maintain a process to identify a new beneficiary's previous and/or
concurrent payer(s) to facilitate the Payer-to-Payer API data exchange.
The information request process must take place:
(i) For current beneficiaries, no later than the compliance date.
(ii) For new beneficiaries, no later than enrollment.
(4) Data exchange requirement. (i) A State must request the data
specified in paragraph (b)(1)(ii) of this section from the
beneficiary's previous payer through the standards-based API described
in paragraph (b)(1) of this section, if the beneficiary has opted in as
described in paragraph (b)(2) of this section, and as permitted by
applicable law. 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. The State must complete this request:
(A) For new beneficiaries, no later than 1 week after enrollment.
(B) At a beneficiary's request, within 1 week of the request.
(C) For a beneficiary who opts in or provides previous and/or
concurrent payer information after enrollment, within 1 week.
(ii) The State must incorporate into the beneficiary's record any
data received from other payers in response to the request.
(iii) The State must make data specified in paragraph (b)(1)(ii) of
this section available to other payers via the standards-based API
described in paragraph (b)(1) of this section within 1 business day of
receiving a request if all the following conditions are met:
(A) The payer that requests access has its identity authenticated
using the authorization and authentication protocols at 45 CFR
170.215(b) and includes an attestation with the request that the
patient is enrolled with the payer and has opted in to the data
exchange.
(B) Disclosure of the data is not prohibited by law.
(5) Concurrent coverage data exchange requirement. When a
beneficiary has provided concurrent coverage information, per paragraph
(b)(3) of this section, and has opted in per paragraph (b)(2) of this
section, a State must, through the standards-based API described in
paragraph (b)(1) of this section:
(i) No later than one week after enrollment, and then at least
quarterly, request the beneficiary's data from all known concurrent
payers in accordance with paragraphs (b)(4)(i) and (ii) of this
section; and
(ii) Within one business day of a request from any concurrent
payers, respond in accordance with paragraph (b)(4)(iii) of this
section.
(6) Educational materials. A State must provide information to
applicants or beneficiaries in non-technical, simple, and easy-to-
understand language, explaining at a minimum: the benefits of Payer-to-
Payer API data exchange, their ability to opt in or withdraw a previous
opt in decision, and instructions for doing so. The State must provide
these materials:
(i) At or before requesting a patient's consent 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; and
(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 to delay implementation of the
requirements in paragraphs (a) and/or (b) of this section for a one-
time, one-year extension 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 and must include all
the following:
(A) A narrative justification describing the specific reasons why
the State cannot reasonably satisfy the requirement(s) by the
compliance date and explaining 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 implementation
activities that evidence a good faith effort towards compliance; and
(C) A comprehensive plan to meet implementation requirements no
later than 1 year after the compliance date.
(ii) CMS will grant the State's request if it determines based on
the information provided in the State's annual Advance Planning
Document (APD) for Medicaid Management Information System (MMIS)
operations expenditures that the request adequately establishes a need
to delay implementation; and that the State has a comprehensive plan to
implement the requirements no later than 1 year after the compliance
date.
(2) Exemption. (i) A State operating a CHIP program in which at
least 90 percent of the State's CHIP beneficiaries are enrolled in
managed care entities, as defined in Sec. [thinsp]457.10, may request
an exemption for its fee-for-service (FFS) program from the
requirements in paragraphs (a) and/or (b) of this section.
(A) The exemption request must be submitted in writing as part of
the State's annual Advance Planning Document (APD) for Medicaid
Management Information System (MMIS) operations expenditures prior to
the date by which the state would otherwise need to comply with the
applicable requirement.

[[Page 76367]]

(B) The State's request must include documentation that the State
meets the criteria for the exemption, based on enrollment data from
Section 5 of the most recently accepted CHIP Annual Report Template
System (CARTS), and must also include information about an alternative
plan to ensure that enrolled providers will have efficient electronic
access to the same information through other means while the exemption
is in effect.
(ii) CMS will grant the 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.
(iii) The State's exemption would expire if:
(A) Based on the 3 previous years of available, finalized CHIP
CARTS managed care and FFS enrollment data, the State's managed care
enrollment for 2 of the previous 3 years is below 90 percent; or
(B) CMS has approved a State plan amendment, waiver, or waiver
amendment that would significantly reduce the share of beneficiaries
enrolled in managed care and the anticipated shift in enrollment is
confirmed by the first available, finalized CARTS managed care and FFS
enrollment data.
(iv) If a State's exemption expires per paragraph (c)(2)(iii) of
this section, the State would be required to:
(A) Submit written notification to CMS that the State no longer
qualifies for the exemption within 90 days of the finalization of
annual CHIP CARTS managed care enrollment data or approval of a State
plan amendment, waiver, or waiver amendment confirming that there has
been a shift from managed care enrollment to FFS enrollment resulting
in the State's managed care enrollment falling below the 90 percent
threshold; and
(B) Obtain CMS approval of a timeline for compliance with the
requirements at paragraph (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.

(a) Communicating prior authorization status to provider, including
reason for denial. Beginning January 1, 2026, States must provide
specific information about prior authorization requests (excluding
drugs as defined at Sec. 457.730(b)(6)) to providers, regardless of
the method used to communicate that information, in a manner that is
consistent with the following requirements:
(1) The State's prior authorization response to the provider must
indicate whether the State approves the prior authorization request
(and for how long), denies the prior authorization request, or requests
more information related to the prior authorization request.
(2) If the State denies the prior authorization request, the
response to the provider must include a specific reason for the denial.
(b) Prior authorization requirements, documentation and decision
(PARDD) Application Programming Interface (API). Unless granted an
extension or exemption under paragraph (d) of this section, beginning
January 1, 2026, a State must implement and maintain a standards-based
API compliant with Sec. 457.730(c), (d), and (e) that:
(1) Is populated with the State's list of covered items and
services (excluding drugs as defined at Sec. 457.730(b)(6)) for which
prior authorization is required, and any documentation requirements for
the prior authorization;
(2) Includes functionality to determine requirements for any other
data, forms or medical record documentation required by the State for
the items or services for which the provider is seeking prior
authorization;
(3) Facilitates a HIPAA-compliant prior authorization request and
response; and
(4) Includes the information required at paragraph (a) of this
section.
(c) Publicly reporting prior authorization metrics. Beginning in
2026, a State must annually report prior authorization data, excluding
data on drugs as defined at 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 it directly on its website
or via hyperlink(s):
(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 to delay implementation of the
requirements in paragraph (b) of this section for a one-time, one-year
extension 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 and must include all the following:
(A) A narrative justification describing the specific reasons why
the State cannot reasonably satisfy the requirement(s) by the
compliance date and why those reasons result from circumstances that
are unique to the agency operating the CHIP fee-for service program;
(B) A report on completed and ongoing State implementation
activities that evidence a good faith effort toward compliance; and
(C) A comprehensive plan to meet implementation requirements no
later than 1 year after the compliance date.
(ii) CMS will grant the State's request if it determines based on
the information provided in the State's annual Advance Planning
Document (APD) for Medicaid Management Information System (MMIS)
operations expenditures that the request adequately establishes a need
to delay implementation; and that the State has a comprehensive plan to
implement the requirements no later than 1 year after the compliance
date.
(2) Exemption. (i) A State operating a CHIP program in which at
least 90 percent of the State's CHIP beneficiaries are enrolled in
managed care entities, as defined in Sec. [thinsp]457.10, may request
an exemption for its fee-for-service program from the requirements in
paragraph (b) of this section.
(A) The exemption request must be submitted in writing as part of a
State's

[[Page 76368]]

annual Advance Planning Document for Medicaid Management Information
System operations expenditures prior to the date by which the state
would otherwise need to comply with the applicable requirement.
(B) The State's request must include documentation that the State
meets the criteria for the exemption, based on enrollment data from
Section 5 of the most recently accepted CHIP Annual Report Template
System (CARTS), and must also include information about an alternative
plan to ensure that enrolled providers will have efficient electronic
access to the same information through other means while the exemption
is in effect.
(ii) CMS will grant the exemption if the State establishes to CMS's
satisfaction that the State meets the criteria for the exemption and
has established a plan to ensure its enrolled providers have efficient
electronic access to the same information through other means while the
exemption is in effect.
(iii) The State's exemption would expire if:
(A) Based on the 3 previous years of available, finalized CHIP
CARTS managed care and FFS enrollment data, the State's managed care
enrollment for 2 of the previous 3 years is below 90 percent; or
(B) CMS has approved a State plan amendment, waiver, or waiver
amendment that would significantly reduce the share of beneficiaries
enrolled in managed care and the anticipated shift in enrollment is
confirmed by the first available, finalized Medicaid Transformed
Medicaid Statistical Information System (T-MSIS) managed care and FFS
enrollment data.
(iv) If a State's exemption expires per paragraph (d)(2)(iii) of
this section, the State would be required to:
(A) Submit written notification to CMS that the State no longer
qualifies for the exemption within 90 days of the finalization of
annual CHIP CARTS managed care enrollment data confirming that there
has been a shift from managed care enrollment to FFS enrollment
resulting in the State's managed care enrollment falling below the 90
percent threshold; and
(B) Obtain CMS approval of a timeline for compliance with the
requirements at paragraph (b) of this section within two 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 at 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: Sec. 438.210(a)(5) of this chapter (related to medical
necessity standard); and Sec. 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), and (f).
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 at 45 CFR 170.213, if the Qualified Health Plan (QHP) issuer
maintains any such data, no later than 1 business day after the QHP
issuer receives the data; and
(iv) For plan years beginning on or after January 1, 2026, the
information in paragraph (b)(1)(iv)(A) of this section about prior
authorizations for items and services (excluding drugs, as defined at
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 and related
administrative and clinical documentation, including all of the
following, as applicable:
(1) The status of the prior authorization.
(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 and the quantity used to date.
(5) If denied, a specific reason why the request was denied.
(B) The information in paragraph (b)(1)(iv)(A) of this section must
be accessible no later than 1 business day after the QHP issuer
receives a prior authorization request, and must be updated no later
than 1 business day after any change in status. All information must
continue to be accessible for the duration that the authorization is
active and at least one year from the date of 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 use API technology conformant with 45 CFR 170.215(a)(1)
through (3) and (b);
* * * * *
(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 described in paragraph (b) of this section or Sec.
156.222 or Sec. 156.223 through the required APIs.
* * * * *
(e) * * *
(2) Makes this determination using objective, verifiable criteria
that are applied fairly and consistently across all applications and
developers through which parties seek to access electronic health
information, as defined at Sec. 171.102 of this subchapter, including
but not limited to criteria that may rely on automated monitoring and
risk mitigation tools.
(f) Reporting on the use of the Patient Access API. Beginning in
2026, by March 31 following any calendar year that a QHP issuer offers
a QHP on a Federally-facilitated Exchange, the QHP issuer must report
to CMS the following

[[Page 76369]]

metrics, in the form of aggregated de-identified data, for the previous
calendar year at the issuer level:
(1) The total number of unique enrollees whose data are transferred
via the Patient Access API to a health app designated by the enrollee;
and
(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.
* * * * *
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 transfer 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, 2026, QHP issuers on a Federally-facilitated Exchange
must:
(1) Accessible content and API requirements. Implement and maintain
a standards-based Application Programming Interface (API) compliant
with Sec. 156.221(c), (d), and (e), as well as the standard at 42 CFR
170.215(a)(4), that complies with the following:
(i) API requirements and accessible content. Make data specified in
paragraph (a)(1)(ii) of this section available to in-network providers
no later than 1 business day of receiving a request if all the
following conditions are met:
(A) The QHP issuer authenticates the identity of the provider that
requests access using the required authorization and authentication
protocols at 45 CFR 170.215(b) and attributes the enrollee to the
provider under the attribution process required in paragraph (a)(2) of
this section.
(B) The enrollee does not opt out per paragraph (a)(3) of this
section.
(C) Disclosure of the data is permitted by applicable law.
(ii) Individual enrollee data. Make the data available specified at
Sec. 156.221(b) with a date of service on or after January 1, 2016,
excluding provider remittances and enrollee cost-sharing information,
if maintained by the QHP issuer.
(2) Attribution. Maintain a process to associate enrollees with
their in-network providers to enable payer-to-provider data exchange
via the Provider Access API.
(3) Opt out and patient educational resources. (i) Maintain a
process to allow an enrollee or the enrollee's personal representative
to opt out of and subsequently opt into the data sharing requirements
specified in paragraph (a)(1) of this section. 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 non-technical, simple and
easy-to-understand language, 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:
(A) Before the first date on which the QHP issuer makes enrollee
information available through the Provider Access API; and
(B) At enrollment; and
(C) At least annually; and
(D) In an easily accessible location on its public website.
(4) Provider resources regarding APIs. Provide on its website and
through other appropriate provider communications, educational
resources in non-technical and easy-to-understand language explaining
the process for requesting enrollee data using the standards-based
Provider Access API, required under paragraph (a)(1) of this section.
The resources must include information about how to use the issuer's
attribution process to associate patients with the provider.
(b) Application Programming Interface to support data transfer
between payers--Payer-to-Payer API. Beginning January 1, 2026:
(1) API requirements and accessible content. A QHP issuer on a
Federally-facilitated Exchange must implement and maintain an API that:
(i) Is compliant with Sec. 156.221(c), (d), and (e), as well as
the standard at 42 CFR 170.215(a)(4); and
(ii) Makes available the data specified at Sec. 156.221(b) with a
date of service on or after January 1, 2016, excluding provider
remittances and enrollee cost-sharing, if maintained by the QHP issuer.
(2) Opt in. A QHP issuer on a Federally-facilitated Exchange must
establish and maintain a process to allow enrollees or their personal
representatives to opt in to the QHP issuer's Payer-to-Payer API data
exchange with the enrollee's previous payer, described in paragraph
(b)(4) of this section, and concurrent payer(s), described in paragraph
(b)(5) of this section, and to allow enrollees to change their
preference at any time.
(i) The opt in process must be offered:
(A) To current enrollees, no later than the compliance date.
(B) To new enrollees, no later than the effectuation of enrollment.
(ii) [Reserved]
(3) Identify previous and/or concurrent payers. A QHP issuer on a
Federally-facilitated Exchange must maintain a process to identify a
new enrollee's previous and/or concurrent payer(s) to facilitate the
Payer-to-Payer API data exchange. The information request process must
take place:
(i) For current enrollees, no later than the compliance date.
(ii) For new enrollees, no later than the effectuation of
enrollment.
(4) Data exchange requirement. (i) A QHP issuer on a Federally-
facilitated Exchange must request the data specified in paragraph
(b)(1)(ii) of this section from the enrollee's previous payer through
the standards-based API described in paragraph (b)(1) of this section,
if the enrollee has opted in as described in paragraph (b)(2) of this
section, and as permitted by applicable law. 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. The
QHP issuer must complete this request:
(A) For current enrollees, no later than 1 week after the
effectuation of enrollment.
(B) At an enrollee's request, within 1 week of the request.
(C) For an enrollee who opts in or provides previous and/or
concurrent payer information after the effectuation of enrollment,
within 1 week.
(ii) The QHP issuer must incorporate into the enrollee's record any
data received from other payers in response to the request.
(iii) The QHP issuer on a Federally-facilitated Exchange must make
data specified in paragraph (b)(1)(ii) of this section available to
other payers via the standards-based API described in paragraph (b)(1)
of this section within 1 business day of receiving a request if all the
following conditions are met:
(A) The payer that requests access has its identity authenticated
using the authorization and authentication protocols at 45 CFR
170.215(b) and includes an attestation with the request that the
patient is enrolled with the payer and has opted in to the data
exchange.
(B) Disclosure of the data is not prohibited by law.
(5) Concurrent coverage data exchange requirement. When an enrollee
has provided concurrent coverage information per paragraph (b)(3) of
this section, and has opted in per paragraph (b)(2) of this section, a
QHP issuer on a Federally-facilitated

[[Page 76370]]

Exchange must, through the standards-based API described in paragraph
(b)(1) of this section:
(i) No later than one week after the effectuation of enrollment,
and then at least quarterly, request the enrollee's data from all known
concurrent payers in accordance with paragraphs (b)(4)(i) and (ii) of
this section; and
(ii) Within one business day of a request from any concurrent
payers, respond in accordance with paragraph (b)(4)(iii) of this
section.
(6) Educational materials. A QHP issuer must provide information to
enrollees in non-technical, simple, and easy-to-understand language,
explaining at a minimum: the benefits of Payer-to-Payer API data
exchange, their ability to opt in or withdraw a previous opt in
decision, and instructions for doing so. The QHP issuer must provide
these materials:
(i) At or before requesting a patient's consent 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; and
(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 paragraphs (a) and/or (b) of this section,
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 payers, and solutions and a
timeline to achieve compliance with the requirements in paragraphs (a)
and/or (b).
(2) The Federally-facilitated Exchange may grant an exception to
the requirements in paragraphs (a) and/or (b) of this section if the
Exchange determines that making qualified health plans 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 qualified
health plans through the FFE.
0
34. Section 156.223 is added to read as follows:

Sec. 156.223 Prior authorization requirements.

(a) Communicating prior authorization status to providers,
including a reason for denial. For plan years beginning on or after
January 1, 2026, a QHP issuer on a Federally-facilitated Exchange must
provide specific information about prior authorization requests
(excluding drugs as defined at Sec. 156.221(b)(1)(v)) to providers,
regardless of the method used to communicate that information, in a
manner that is consistent with the following requirements:
(1) The QHP issuer's prior authorization response to the provider
must indicate whether the QHP issuer approves the prior authorization
request (and for how long), denies the prior authorization request, or
requests more information related to the prior authorization request.
(2) If the QHP issuer denies the prior authorization request, the
response to the provider must include a specific reason for the denial.
(b) Prior authorization requirements, documentation and decision
(PARDD) Application Programming Interface (API). Unless granted an
exception under paragraph (d) of this section, for plan years beginning
on or after January 1, 2026, a QHP issuer on a Federally-facilitated
Exchange must implement and maintain a standards-based API compliant
with Sec. 156.221(c), (d), and (e) that:
(1) Is populated with the QHP issuer's list of covered items and
services (excluding drugs as defined at Sec. 156.221(b)(1)(v)) for
which prior authorization is required, and any documentation
requirements for the prior authorization;
(2) Includes functionality to determine requirements for any other
data, forms or medical record documentation required by the QHP issuer
for the items or services for which the provider is seeking prior
authorization;
(3) Facilitates a Health Insurance Portability and Accountability
Act (HIPAA)-compliant prior authorization request and response; and
(4) Includes the information required at paragraph (a) of this
section.
(c) Publicly reporting prior authorization metrics. Beginning in
2026, following each year it offers a plan on a Federally-facilitated
Exchange, a QHP issuer must report prior authorization data, excluding
data on drugs as defined at 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 it directly on
its website or via hyperlink(s):
(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 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, and solutions and a timeline
to achieve compliance with the requirements in paragraph (b).

[[Page 76371]]

(2) The Federally-facilitated Exchange may grant an exception to
the requirements in paragraph (b) of this section if the Exchange
determines that making qualified health plans 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 qualified health plans through
the FFE.

Dated: December 1, 2022.
Xavier Becerra,
Secretary, Department of Health and Human Services.
[FR Doc. 2022-26479 Filed 12-6-22; 4:15 pm]
BILLING CODE 4120-01-P

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