[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/index.html and https://www.hhs.gov/hipaa/for-professionals/faq/personal-representatives-and-minors/index.html.
---------------------------------------------------------------------------

    We also use terms such as ``payer,'' ``plan,'' and ``issuer'' in 
this 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 http://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/index.html.
---------------------------------------------------------------------------

    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/index.html.
---------------------------------------------------------------------------

    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 http://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/index.html.
---------------------------------------------------------------------------

    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/index.html.
---------------------------------------------------------------------------

    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/index.html?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 http://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 http://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 http://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 http://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 http://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), http://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