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



[[Page 8757]]

Vol. 89

Thursday,

No. 27

February 8, 2024

Part II





Department of Health and Human Services





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





 Centers for Medicare & Medicaid Services





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





42 Parts 422, 431, 435, et al.

45 Part 156





Medicare and Medicaid Programs; Patient Protection and Affordable Care 
Act; Advancing Interoperability and Improving Prior Authorization 
Processes for Medicare Advantage Organizations, Medicaid Managed Care 
Plans, State Medicaid Agencies, Children's Health Insurance Program 
(CHIP) Agencies and CHIP Managed Care Entities, Issuers of Qualified 
Health Plans on the Federally-Facilitated Exchanges, Merit-Based 
Incentive Payment System (MIPS) Eligible Clinicians, and Eligible 
Hospitals and Critical Access Hospitals in the Medicare Promoting 
Interoperability Program; Final Rule

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

[[Page 8758]]


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

DEPARTMENT OF HEALTH AND HUMAN SERVICES

Centers for Medicare & Medicaid Services

42 CFR Parts 422, 431, 435, 438, 440, and 457

Office of the Secretary

45 CFR Part 156

[CMS-0057-F]
RIN 0938-AU87


Medicare and Medicaid Programs; Patient Protection and Affordable 
Care Act; Advancing Interoperability and Improving Prior Authorization 
Processes for Medicare Advantage Organizations, Medicaid Managed Care 
Plans, State Medicaid Agencies, Children's Health Insurance Program 
(CHIP) Agencies and CHIP Managed Care Entities, Issuers of Qualified 
Health Plans on the Federally-Facilitated Exchanges, Merit-Based 
Incentive Payment System (MIPS) Eligible Clinicians, and Eligible 
Hospitals and Critical Access Hospitals in the Medicare Promoting 
Interoperability Program

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

ACTION: Final rule.

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

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

DATES: These regulations are effective on April 8, 2024.

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

SUPPLEMENTARY INFORMATION: 

Table of Contents

I. Background and Summary of Provisions
    A. Purpose and Background
    B. Summary of Major Provisions
    C. Specific Terms Used in This Final Rule
    D. Global Comments
II. Provisions of the Proposed Rule
    A. Patient Access API
    B. Provider Access API
    C. Payer-to-Payer API
    D. Prior Authorization API and Improving Prior Authorization 
Processes
    E. Extensions, Exemptions, and Exceptions; Federal Matching 
Funds for Medicaid and CHIP
    F. Electronic Prior Authorization Measures for the Merit-Based 
Incentive Payment System (MIPS) Promoting Interoperability 
Performance Category and the Medicare Promoting Interoperability 
Program
    G. Interoperability Standards for APIs
III. Collection of Information Requirements
IV. Regulatory Impact Analysis

I. Background, Summary of Provisions, and Terms

A. Purpose and Background

    In the December 13, 2022 Federal Register (87 FR 76238), we issued 
the ``Medicare and Medicaid Programs; Patient Protection and Affordable 
Care Act; Advancing Interoperability and Improving Prior Authorization 
Processes for Medicare Advantage Organizations, Medicaid Managed Care 
Plans, State Medicaid Agencies, Children's Health Insurance Program 
(CHIP) Agencies and CHIP Managed Care Entities, Issuers of Qualified 
Health Plans on the Federally-Facilitated Exchanges, Merit-Based 
Incentive Payment System (MIPS) Eligible Clinicians, and Eligible 
Hospitals and Critical Access Hospitals in the Medicare Promoting 
Interoperability Program'' proposed rule (CMS Interoperability and 
Prior Authorization proposed rule), in which we proposed new 
requirements for MA, state Medicaid FFS programs, state CHIP FFS 
programs, Medicaid managed care plans, CHIP managed care entities, and 
QHP issuers on the FFEs (collectively ``impacted payers'') to improve 
the electronic exchange of health care information and streamline prior 
authorization for medical items and services. The proposed rule also 
included proposals for new electronic prior authorization measures for 
MIPS eligible clinicians (as defined at 42 CFR 414.1305) under the 
Promoting Interoperability performance category of the MIPS, as well as 
for eligible hospitals and CAHs under the Medicare Promoting 
Interoperability Program.
    This rule also builds upon the policies established in the 
``Medicare and Medicaid Programs; Patient Protection and Affordable 
Care Act; Interoperability and Patient Access for MA Organization and 
Medicaid Managed Care Plans, State Medicaid Agencies, CHIP Agencies and 
CHIP Managed Care Entities, Issuers of Qualified Health Plans on the 
Federally-Facilitated Exchanges, and Health Care Providers'' final rule 
(85 FR 25510, May 1, 2020) (hereinafter referred to as the ``CMS 
Interoperability and Patient Access final rule'').
    We received nearly 900 timely pieces of correspondence containing 
comments on the CMS Interoperability and Prior Authorization proposed 
rule. Some public comments were outside of the scope of the proposed 
rule and those out-of-scope comments are not addressed in this final 
rule. Summaries

[[Page 8759]]

of the public comments that are within the scope of the proposed rule 
and our responses to those public comments are addressed in the various 
sections of this final rule under the appropriate heading. However, in 
this section we address certain comments that pertain across policies 
or to the rule overall.
    In this final rule, we are finalizing our proposals with 
modifications in response to commenter feedback. Taken together, these 
final policies will help to increase health information data exchange, 
streamline prior authorization process policies, and help to address a 
significant source of provider burden and burnout to ultimately improve 
patients' access to timely care.

B. Summary of Major Provisions

    In the CMS Interoperability and Patient Access final rule, we 
required impacted payers (MA organizations, state Medicaid FFS 
programs, state CHIP FFS programs, Medicaid managed care plans, CHIP 
managed care entities, and QHP issuers on the FFEs) to implement and 
maintain a standards-based Patient Access API. The Patient Access API 
must allow patients, through the health apps of their choice, to easily 
access their claims and encounter information as well as clinical data, 
including laboratory results, provider remittances, and patient cost-
sharing pertaining to such claims, if maintained by the impacted payer 
(85 FR 25558). In this final rule, we are finalizing our proposal to 
require that impacted payers include information about certain prior 
authorizations in the data that are available through the Patient 
Access API. For those changes to the Patient Access API, we are 
finalizing compliance dates in 2027 (by January 1, 2027, for MA 
organizations and state Medicaid and CHIP FFS programs; by the rating 
period beginning on or after January 1, 2027, for Medicaid managed care 
plans and CHIP managed care entities; and for plan years beginning on 
or after January 1, 2027, for QHP issuers on the FFEs). In addition, 
starting January 1, 2026, we are requiring impacted payers to annually 
report to CMS certain metrics about patient data requests made via the 
Patient Access API. We are also finalizing our proposal to directly 
reference the content standard at 45 CFR 170.213, so that the data 
content requirement is automatically updated as HHS's Office of the 
National Coordinator for Health Information Technology (ONC) adopts new 
versions. As of this final rule's publication, the content standards 
adopted at 45 CFR 170.213 are USCDI v1, which will expire on January 1, 
2026, and USCDI v3.
    To improve coordination of care across the care continuum and 
movement toward value-based care, we are finalizing our proposal to 
require impacted payers to implement and maintain a Provider Access API 
that is consistent with the technical standards finalized in the CMS 
Interoperability and Patient Access final rule (85 FR 25558), including 
the Health Level Seven (HL7[supreg]) International Fast Healthcare 
Interoperability Resources (FHIR[supreg]) Release 4.0.1 standard. 
Providers can use that API to access current patient data from payers, 
including adjudicated claims and encounter data (excluding provider 
remittances and patient cost-sharing information), all data classes and 
data elements included in a content standard at 45 CFR 170.213 (USCDI), 
and prior authorization information. For the Provider Access API 
policy, we are finalizing compliance dates in 2027 (by January 1, 2027, 
for MA organizations and state Medicaid and CHIP FFS programs; by the 
rating period beginning on or after January 1, 2027 for Medicaid 
managed care plans and CHIP managed care entities; and for plan years 
beginning on or after January 1, 2027 for QHP issuers on the FFEs).
    We are finalizing, with modifications, our proposal to require 
impacted payers to implement and maintain a Payer-to-Payer API to 
exchange patient data when a patient moves between payers to ensure 
continued access to their health data and support continuity of care 
between payers. Specifically, the payer to payer data exchange will 
include adjudicated claims and encounter data (excluding provider 
remittances and patient cost-sharing information), all data classes and 
data elements included in a content standard at 45 CFR 170.213 (USCDI), 
and certain information about the patient's prior authorizations. 
Impacted payers will be required to request data from a patient's 
previous payer, with the patient's permission, no later than 1 week 
from the start of coverage or at the patient's request. Impacted payers 
will then be required to integrate any data they receive in response to 
that request into the patient's record, which could facilitate care 
continuity as patients move between payers. We are finalizing a policy 
that payers will be required to exchange five years of patient data, as 
opposed to the entire patient health record. Five years of data are 
sufficient to support care continuity and continuation of prior 
authorizations as necessary, as well as maintaining patient access to 
their most recent data without significant burden to payers. In 
addition, if a patient has two or more concurrent impacted payers, the 
impacted payers will be required to exchange the patient's data at 
least quarterly, to ensure that all impacted payers have a more 
complete patient record. For the Payer-to-Payer API policy, we are 
finalizing compliance dates in 2027 (by January 1, 2027, for MA 
organizations and state Medicaid and CHIP FFS programs; by the rating 
period beginning on or after January 1, 2027, for Medicaid managed care 
plans and CHIP managed care entities; and for plan years beginning on 
or after January 1, 2027, for QHP issuers on the FFEs).
    To improve the patient experience and access to care, we are also 
finalizing several new requirements for prior authorization processes 
that will reduce burden on patients, providers, and payers. To 
streamline the prior authorization process, we are requiring impacted 
payers to implement and maintain a Prior Authorization API. In the 
proposed rule, we used the term ``Prior Authorization Requirements, 
Documentation, and Decision API (PARDD API).'' For simplicity, we are 
finalizing the name of that API as simply the ``Prior Authorization 
API.'' This name change alone does not indicate any changes to the 
requirements or standards that we proposed.
    Providers can use the Prior Authorization API to determine whether 
a specific payer requires prior authorization for a certain item or 
service, thereby easing one of the major points of administrative 
burden in the existing prior authorization process. The Prior 
Authorization API will also allow providers to query the payer's prior 
authorization documentation requirements directly from the provider's 
system, which could facilitate the automated compilation of necessary 
information to submit a prior authorization request. For the Prior 
Authorization API policy, we are finalizing compliance dates in 2027 
(by January 1, 2027, for MA organizations and state Medicaid and CHIP 
FFS programs; by the rating period beginning on or after January 1, 
2027, for Medicaid managed care plans and CHIP managed care entities; 
and for plan years beginning on or after January 1, 2027, for QHP 
issuers on the FFEs).
    We are also finalizing our proposals to establish certain 
requirements for the prior authorization process, regardless of whether 
the payer receives the prior authorization request through the Prior 
Authorization API. We are requiring that impacted payers send notices 
to providers when they make a prior authorization decision, including a

[[Page 8760]]

specific reason for denial when they deny a prior authorization 
request. We are also finalizing our proposal to require impacted 
payers, except for QHP issuers on the FFEs, to respond to prior 
authorization requests within certain timeframes. Finally, we are 
requiring all impacted payers to publicly report certain metrics about 
their prior authorization processes, which will enhance transparency. 
For these prior authorization process policies, we are finalizing 
compliance dates in 2026 (by January 1, 2026, for MA organizations and 
state Medicaid and CHIP FFS programs; by the rating period beginning on 
or after January 1, 2026, for Medicaid managed care plans and CHIP 
managed care entities; and for plan years beginning on or after January 
1, 2026, for QHP issuers on the FFEs).
    We are finalizing, with modifications, our proposal for new 
electronic prior authorization measures for MIPS eligible clinicians 
under the MIPS Promoting Interoperability performance category and for 
eligible hospitals and CAHs under the Medicare Promoting 
Interoperability Program. To promote Prior Authorization API adoption, 
implementation, and use among MIPS eligible clinicians, eligible 
hospitals, and CAHs, we are adding new measures titled ``Electronic 
Prior Authorization'' under the Health Information Exchange (HIE) 
objective in the MIPS Promoting Interoperability performance category 
and the Medicare Promoting Interoperability Program, beginning with the 
calendar year (CY) 2027 performance period/2029 MIPS payment year and 
CY 2027 electronic health record (EHR) reporting period, respectively. 
As detailed in section II.F. of this final rule, we are finalizing a 
modification to our proposal for the Electronic Prior Authorization 
measure that will require a MIPS eligible clinician, eligible hospital, 
or CAH to report a yes/no attestation or (if applicable) an exclusion, 
rather than a numerator and denominator.
    We are additionally finalizing our proposals, with modifications, 
for more specificity as to which of the required standards at 45 CFR 
170.215 are applicable to each API. Impacted payers will only be 
required to use the specifications that CMS has identified as necessary 
for the Patient Access, Provider Access, Provider Directory, Payer-to-
Payer, and Prior Authorization APIs. Since the publication of the CMS 
Interoperability and Prior Authorization proposed rule, ONC has 
published the Health Data, Technology, and Interoperability: 
Certification Program Updates, Algorithm Transparency, and Information 
Sharing (HTI-1) final rule (January 9, 2024; 89 FR 1192) (hereinafter 
referred to as the HTI-1 final rule), which reorganized the structure 
of 45 CFR 170.215 to delineate the purpose and scope more clearly for 
each type of standard or implementation specification. The standards we 
are finalizing in this rule, including updated citations are as 
follows:
    <bullet> Health Level Seven (HL7[supreg]) Fast Healthcare 
Interoperability Resources (FHIR[supreg]) Release 4.0.1 at 45 CFR 
170.215(a)(1) (HL7 FHIR).
    <bullet> HL7[supreg] FHIR[supreg] US Core Implementation Guide (IG) 
Standard for Trial Use (STU) 3.1.1, which expires on January 1, 2026, 
at 45 CFR 170.215(b)(1)(i) (US Core IG).
    <bullet> HL7[supreg] SMART Application Launch Framework IG Release 
1.0.0 which expires on January 1, 2026, at 45 CFR 170.215(c)(1) (SMART 
App Launch IG).
    <bullet> FHIR[supreg] Bulk Data Access (Flat FHIR) IG v1.0.0: STU 1 
at 45 CFR 170.215(d)(1) (Bulk Data Access IG).
    <bullet> OpenID Connect Core 1.0, incorporating errata set 1 at 45 
CFR 170.215(e)(1) (OpenID Connect Core).
    We refer readers to the HTI-1 final rule for further information 
(89 FR 1192). More detail about the required standards can be found in 
section II.G. and Table H3. We are also strongly recommending that 
payers use specific IGs to supplement the required standards at 45 CFR 
170.215. Additionally, we are finalizing our proposal to allow payers 
to voluntarily use updated versions of the standards, specifications, 
or IGs for each of these APIs prior to the adoption of updated versions 
in regulation, subject to certain conditions and provided the updated 
standard does not disrupt an end user's ability to access the data 
available through the API. We are also finalizing terminology changes 
related to the Patient Access API (in section II.A.2.d. of this final 
rule). These policies will take effect on the effective date of the 
final rule.
    We are finalizing, as proposed, some clarifications to existing 
Medicaid beneficiary notice and fair hearing regulations that apply to 
Medicaid prior authorization decisions. Because these are 
clarifications and improvements to existing regulations, as we 
proposed, Medicaid agencies will have to comply with these policies 
upon the effective date of a final rule.
    In our proposed rule, we proposed compliance dates in 2026 (by 
January 1, 2026, for MA organizations and state Medicaid and CHIP FFS 
programs; by the rating period beginning on or after January 1, 2026, 
for Medicaid managed care plans and CHIP managed care entities; and for 
plan years beginning on or after January 1, 2026, for QHP issuers on 
the FFEs), for all policies that require API development and 
enhancement. Based on commenter feedback and as noted previously, we 
are delaying the compliance dates in this final rule for the provisions 
that require API development and enhancement in 2027 (by January 1, 
2027, for MA organizations and state Medicaid and CHIP FFS programs; by 
the rating period beginning on or after January 1, 2027, for Medicaid 
managed care plans and CHIP managed care entities; and for plan years 
beginning on or after January 1, 2027, for QHP issuers on the FFEs). 
Throughout this rule, we generally refer to these compliance dates as 
``in 2027'' for the various payers.
    We believe this approximately 3-year timeline to recruit and train 
staff, update, or build the APIs, and update operational procedures 
will be sufficient to implement these policies, based on comments and 
public information from some payers and providers regarding similar 
initiatives already in progress. In addition to the 3-year 
implementation timeframe, we are finalizing our proposal to give state 
Medicaid and CHIP FFS programs an opportunity to seek an extension to 
the compliance dates, or an exemption from meeting certain 
requirements, in certain circumstances. Additionally, we are finalizing 
our proposal to provide an exceptions process for QHP issuers on the 
FFEs. We believe the approximately 3-year timeframe for implementation 
in the final rule will offer sufficient time for state Medicaid and 
CHIP FFS programs and QHP issuers on the FFEs to determine whether they 
can timely satisfy the API development and enhancement requirements in 
this final rule and to prepare the necessary documentation to request 
an extension, exemption, or exception, as applicable.
    Executive Order 13985 of January 20, 2021, entitled ``Advancing 
Racial Equity and Support for Underserved Communities Through the 
Federal Government,'' set administration policy that the ``Federal 
Government should pursue a comprehensive approach to advancing equity 
for all.'' \1\ CMS is committed to pursuing a comprehensive approach to 
advancing health equity for all, and the policies in this final rule 
are aligned with that Executive order because they represent efforts to 
mitigate existing inefficiencies in policies, processes, and technology 
that affect many patient populations. Some patient populations are more 
negatively affected by existing processes than

[[Page 8761]]

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

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

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

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

C. Specific Terms Used in This Final Rule

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

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

    We also use terms such as ``payer,'' ``plan,'' and ``issuer'' in 
this final rule. Certain portions of this final rule are applicable to 
MA organizations, state Medicaid FFS programs, state CHIP FFS programs, 
Medicaid managed care plans (managed care organizations (MCOs), prepaid 
inpatient health plans (PIHPs), and prepaid ambulatory health plans 
(PAHPs)), CHIP managed care entities (MCOs, PIHPs, and PAHPs), and QHP 
issuers on the FFEs. Where certain provisions may not apply to specific 
plan or provider types, we have identified them separately from the 
aforementioned categories. We use the term ``payer'' in the preamble of 
this final rule as an inclusive term for all these entities and 
programs and, in the case of plans, plan types, but we also use 
specific terms as applicable in various sections of this final rule.
    We use the term ``policies that require API enhancement or 
development'' to describe the requirements that involve technical 
development work to either establish a new API, such as the Provider 
Access or Payer-to-Payer APIs, or to enhance the functionality of an 
existing API, such as the addition of

[[Page 8762]]

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

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

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

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

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

D. Global Comments

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

[[Page 8763]]

Plans, State Medicaid Agencies, CHIP Agencies and CHIP Managed Care 
Entities, and Issuers of Qualified Health Plans on the Federally-
Facilitated Exchanges; Health Information Technology Standards and 
Implementation Specifications'' proposed rule (December 2020 CMS 
Interoperability proposed rule) (87 FR 76239), and compliance and 
enforcement.
1. Medicare Fee-for-Service Implementation of Final Policies
    Although these requirements do not directly pertain to Medicare 
FFS, we want to ensure that people with Medicare can benefit from the 
policies in this final rule, regardless of their coverage or delivery 
system. We intend for the Medicare FFS program to be a market leader on 
data exchange, including through the Provider Access, Payer-to-Payer, 
and Prior Authorization APIs, and therefore we solicited comments on 
how these proposals could apply to Medicare FFS. We also encouraged 
other payers not directly impacted by this final rule to consider the 
policies in this final rule for voluntary adoption to reduce burden and 
support greater interoperability.
    A significant number of commenters expressed support for our 
intention to ensure that Medicare FFS will comply with the requirements 
of this final rule by the compliance dates we are establishing. We did 
not make any policy proposals regarding this effort, but we are 
considering comments as we plan our roadmap for implementation.
2. Compliance Dates and Enforcement
    For our proposals that require API enhancement or development, we 
proposed compliance dates in 2026 (by January 1, 2026, for MA 
organizations and state Medicaid and CHIP FFS programs; by the rating 
period beginning on or after January 1, 2026, for Medicaid managed care 
plans and CHIP managed care entities; and for plan years beginning on 
or after January 1, 2026, for QHP issuers on the FFEs) (87 FR 76289) 
and indicated that we thought that a 3-year timeline to recruit and 
train staff, update or build the APIs, and update operational 
procedures would be sufficient. In the proposed rule we used the term 
``implementation dates'' rather than ``compliance dates'' as we are 
using in this final rule. Because payers may implement APIs before the 
compliance dates, we want to be clear when we are discussing the 
regulatory deadlines in this final rule. This terminology does not 
indicate any changes to the substance of any proposals or finalized 
requirements.
    Comment: Many commenters expressed support for the proposed 
compliance dates in 2026. A commenter stated that the proposed 
compliance dates give impacted payers, health information technology 
(IT) developers, and providers sufficient time to prepare for 
widespread adoption and utilization. A commenter stated that the 
feasibility of implementation in 2026 will depend on the complexities 
of the implementation and the date the final rule is published. Another 
commenter suggested that CMS provide an implementation timeline with 
steps to ensure all parties are ready for implementation in 2026. 
Another commenter wrote that CMS should conduct pilots before the 
proposed 2026 compliance dates.
    Multiple commenters recommended that CMS establish a shorter 
timeframe for the revisions to the Patient Access API and the 
implementation of the new APIs. Commenters stated that the benefits of 
our prior authorization proposals are especially necessary and 
encouraged us to finalize compliance dates as early as possible. A 
commenter recommended that CMS require MA organizations to implement 
the requirements within 90 days of publication of this final rule. 
Another commenter stated that they believe that MA organizations have 
the revenue and resources to implement the provisions in CY 2024.
    Payers have indicated that they are already collecting information 
about how patients are using their Patient Access API, and many 
submitted comments based on the patient uptake they are witnessing. We 
did not receive comments that indicated that collecting and reporting 
these metrics would be a burden on payers.
    Multiple commenters expressed concern regarding the proposed 2026 
compliance dates, for most of the requirements in the rule. Other 
commenters emphasized that payers would have to begin work on 
implementation immediately following publication of this final rule to 
meet all requirements by the 2026 compliance dates. Multiple commenters 
recommended that CMS delay the compliance dates to 2027 or 2028, citing 
the feasibility of technology implementation and operational changes.
    Commenters indicated that state Medicaid and CHIP FFS programs may 
need more time to implement because they need to secure funding and 
engage in the state's procurement process. A commenter recommended 
compliance dates no earlier than January 1, 2027, with state Medicaid 
and CHIP agencies having the ability to request up to two 1-year 
extensions following that date. The commenter noted that due to unique 
funding cycles and procurement requirements, states could require more 
time than other payers to implement the proposed requirements.
    Multiple commenters weighed in on the amount of time that payers 
will need to implement the provisions in the proposed rule. Multiple 
commenters noted that the proposed requirements for payers to implement 
four APIs within less than 3 years from publication of the final rule 
would create a significant burden on payers. A commenter stated that 
developers will need 12-18 months from the publication of a final rule 
to design, develop, test, and release updated software. The commenter 
stated that payers will also need time to implement the updated 
functionality and train staff to assist patients and other API end 
users. Another commenter stated that developers would need 18 months 
per API. A commenter recommended that CMS finalize any policies with at 
least 24 months of lead time. Another commenter suggested that CMS 
provide at least 24 to 36 months after the publication of the final 
rule for payers to comply. Other commenters suggested 3 years between 
publishing a final rule and the compliance dates. Several commenters 
recommended that CMS consider a staggered implementation approach for 
the API requirements.
    Commenters indicated that, of our proposals, the technical 
development and enhancement of the required APIs would necessitate a 
longer implementation period than the prior authorization process 
improvements.
    Response: Having taken into consideration comments about the 
implementation timeline generally and about each of the policies 
specifically, we are finalizing our policies that require API 
development or enhancement with compliance dates in 2027. Specifically, 
MA organizations and state Medicaid and CHIP FFS programs must comply 
with those policies by January 1, 2027; Medicaid managed care plans and 
CHIP managed care entities must comply beginning with the first rating 
period that begins on or after January 1, 2027; and QHPs in FFEs must 
comply by the first plan year beginning on or after January 1, 2027. 
For simplicity, throughout this rule we generally refer to these 
compliance dates as ``in 2027'' for the various payers. However, we are 
finalizing some of our other policies with the proposed 2026 compliance 
dates, as noted in the Summary of Major Provisions.

[[Page 8764]]

    Specifically, we are finalizing 2026 compliance dates for the 
requirements that impacted payers report Patient Access API metrics to 
CMS, make standard and expedited prior authorization decisions within 
specific timeframes, send notices to providers, including a specific 
denial reason for denied prior authorizations, and publicly report 
prior authorization metrics on their websites. While these policies 
require a certain level of development and implementation effort, they 
are not as technically challenging as implementing the APIs. Thus, we 
believe a nearly 2-year implementation timeframe is sufficient and will 
allow payers to prioritize them for an earlier deadline.
    Because impacted payers should already have Patient Access APIs 
implemented based on requirements finalized in the CMS Interoperability 
and Patient Access final rule, reporting on usage of that API should 
not be a significant burden to payers. We proposed to gather those data 
to understand how the Patient Access API is being adopted across the 
industry. We do not believe there is any benefit to delaying this 
reporting requirement, as we need these data to help inform future 
policies.
    Importantly, the prior authorization policies we are finalizing 
with 2026 compliance dates should reduce the burden of prior 
authorization processes, even before the 2027 compliance dates for the 
API development and enhancement policies. Requiring impacted payers to 
send provider notices, including a specific denial reason, respond 
within specific timeframes, and report prior authorization metrics will 
apply regardless of how the payer received the prior authorization 
request, and are not dependent on the API. Therefore, we do not believe 
there is a reason to tie those requirements to the API compliance 
dates. Delaying the changes to prior authorization timeframes and 
procedures would only delay the benefits of those new policies.
    However, we are sensitive to the implementation burdens on payers, 
particularly for the final policies that require API development or 
enhancement. We understand that payers need time to design, develop, 
test, and implement major system changes to implement the new Provider 
Access, Payer-to-Payer, and Prior Authorization APIs. We considered 
finalizing staggered API compliance dates between 2026 and 2027, as 
some commenters suggested, but concluded that we are not in the best 
position to prioritize and understand what work can feasibly be 
completed by 2026 and what scope is better in a second phase for 2027. 
Instead, we are delaying the compliance dates for the three new APIs 
and modifications to the Patient Access API by 1 year from the proposed 
compliance dates to allow payers time to sufficiently plan, develop, 
test, and implement this technology. After considering the comments we 
received, we agree with the volume of commenters that indicated that 
more than 2 years is necessary from the publication of the final rule 
for payers to meet the new API requirements. In consideration of the 
schedule for this final rule's publication, we are finalizing 
compliance dates in 2027, for the new Provider Access, Payer-to-Payer, 
and Prior Authorization API requirements in this final rule. Throughout 
the final rule, we specify the exact regulatory citations that are 
being modified from our proposed rule to reflect the finalized 
compliance dates for each payer.
    We are addressing concerns specific to state Medicaid and CHIP 
programs with the availability of an extension for Medicaid and CHIP 
agencies, under which states could seek to delay implementation until 
2028, as discussed in section II.E. of this final rule. In that 
section, we also discuss the possibility of states receiving enhanced 
Federal Financial Participation (FFP) for expenditures related to 
implementing these requirements.
    Comment: Many commenters expressed concern regarding the lack of 
discussion in the proposed rule for mechanisms to ensure compliance 
with the provisions of the rule once finalized. Multiple commenters 
recommended that CMS clearly outline how it will conduct oversight and 
enforcement of the requirements in the rule and commenters recommended 
that CMS outline a process for formal oversight, audit, and 
enforcement, including financial penalties and other consequences to 
promote accountability. A commenter questioned the enforcement and 
oversight activities for the CMS Interoperability and Patient Access 
final rule (CMS-9115-F). Another commenter highlighted the lack of 
penalties for non-compliance with the Provider Directory API. Other 
commenters recommended that CMS develop a structured process for the 
public to report non-compliance. Multiple commenters recommended that 
CMS closely monitor payer compliance and impose civil monetary 
penalties on payers that are non-compliant.
    Response: As explained in the proposed rule and the CMS 
Interoperability and Patient Access final rule, each CMS program 
oversees compliance under existing program authorities and 
responsibilities for the different types of payers impacted by these 
API requirements (for example, MA organizations, Medicaid programs, 
etc.). Oversight and compliance procedures and processes vary among 
these CMS programs and CMS may choose from an array of possible 
enforcement actions, based on a payer's status in the program, previous 
compliance actions, and corrective action plans. Therefore, we do not 
address specific potential compliance and enforcement actions across 
impacted payers in this final rule, although we do discuss categories 
of enforcement actions that CMS could consider for various payers in 
the discussion later in this section. Patients and providers may submit 
an inquiry or complaint to the appropriate authority, depending on 
their coverage.
    For MA organizations, because these are program requirements, 
depending on the extent of the violation, CMS may take compliance 
actions from warning letters or requiring a corrective action plan, to 
enforcement actions including sanctions, civil money penalties and 
other measures specified at 42 CFR part 422, subpart O. If an MA 
enrollee believes a plan is not fulfilling its responsibilities with 
respect to the API requirements, they have a right to file a grievance 
with a plan under the procedures at 42 CFR 422.564. Individuals may 
also submit complaints about their MA plans to 1-800-MEDICARE and the 
online complaint system at https://www.medicare.gov/my/medicare-complaint. The State Health Insurance Assistance Programs (SHIP) are 
available to help Medicare beneficiaries, including with filing 
complaints.
    When states use enhanced funding for expenditures related to system 
modifications or enhancements, CMS's enforcement is based upon 45 CFR 
95.612 (Disallowance of FFP) and the methodology described in the 
Centers for Medicaid and CHIP Services (CMCS) Informational Bulletin 
(CIB), ``Medicaid Enterprise Systems Compliance and Reapproval Process 
for State Systems with Operational Costs Claimed at the 75 Percent 
Federal Match Rate,'' published May 24, 2023. If a state is not 
compliant with the requirements included in this final rule, the 
appropriate program policy team will address compliance enforcement.
    States are obligated by 42 CFR 438.66(b) and (c) to have a 
monitoring system for all of their managed care programs, including the 
performance of

[[Page 8765]]

each managed care plan, to ensure that all managed care plans are 
fulfilling their contractual obligations. States report the results of 
their monitoring activities in an annual Managed Care Program Annual 
Report, in accordance with 42 CFR 438.66(e). Further, per 42 CFR 
438.3(a), CMS must review and approve all managed care plan contracts. 
Should information in a state's Managed Care Program Annual Report or 
contract indicate a need for improvement or correction, CMS would work 
with the state to ensure that the issue is remedied. Patients or 
providers with concerns regarding Medicaid or CHIP FFS should contact 
their state Medicaid or CHIP agency. Patients and providers can contact 
<a href="/cdn-cgi/l/email-protection#3a065b1a52485f5c07" http: Medicaid.gov">Medicaid.gov</a>@cms.hhs.gov">Medicaid.gov@cms.hhs.gov</a> if the state agency is not responsive.
    For any concerns related to compliance by Medicaid managed care 
plans and CHIP managed care entities, enrollees and providers should 
first contact their managed care plan or managed care entity. Enrollees 
or providers can contact the state Medicaid or CHIP agency to report 
issues that they cannot resolve by working with the managed care plan 
or entity directly.
    Consistent with the authority under 45 CFR 156.715, the Center for 
Consumer Information and Insurance Oversight (CCIIO) performs 
compliance reviews of issuers in the FFEs. In addition, 45 CFR 156.800 
through 156.815 provides for additional enforcement remedies including 
Civil Money Penalties (CMPs) and Notices of Non-Compliance (NONCs) as 
well as paths to QHP issuer Suppression and Decertification. If 
enrollees in a QHP on the FFEs or their providers have concerns about 
an issuer's interoperability implementation, they should first contact 
their health plan with questions. For issues that they cannot resolve 
by working directly with the plan, enrollees and providers can contact 
the Marketplace Call Center at 1-800-318-2596 (TTY: 1-855-889-4325).
    CMS manages compliance with the HIPAA administrative transaction 
standards under the authority of the administrative simplification 
rules. Complaints about non-compliance can be submitted to CMS at 
https://asett.cms.gov/ASETT_HomePage.
3. Exclusion of Drugs
    In the CMS Interoperability and Prior Authorization proposed rule, 
we stated that we were excluding drugs from the Prior Authorization API 
and proposed process requirements for prior authorizations because the 
standards and processes for issuing prior authorizations for drugs 
differ from those that apply to medical items and services.
    Under state Medicaid programs and the MA program, there are similar 
timing requirements for prior authorizations for coverage of drugs. MA 
plans are required to respond to expedited requests for Part B drugs 
within 24 hours (42 CFR 422.572) and to non-expedited requests as 
expeditiously as the enrollee's health condition requires, but no later 
than 72 hours after receipt of the request (42 CFR 422.568). Further, 
MA-PD plans that cover Part A, B, and D benefits must comply with 
similar timelines in responding to prior authorization requests for 
Part D prescription drugs (42 CFR 423.568, 423.572). Similarly, under 
Medicaid (both FFS and managed care), if a state requires prior 
authorizations for covered outpatient drugs, a response must be 
provided within 24 hours of the request for prior authorization (see 
section 1927(d)(5) of the Social Security Act (the Act) and 42 CFR 
438.3(s)(6)). We acknowledge that other drugs do not meet the 
definition of ``covered outpatient drugs,'' including cancer drugs, 
special treatments, and other important medications, and thus are not 
subject to these prior authorization timeline requirements.
    Comment: A plethora of commenters provided input and requested that 
CMS reconsider the proposal to exclude drugs and instead include drugs 
in the prior authorization policies for all or some impacted payers.
    Some commenters expressed support for CMS's exclusion of drugs from 
the proposed requirements and CMS's decision to defer Prior 
Authorization API requirements for drugs to future rulemaking. Multiple 
commenters recommended that CMS make clear the exclusion of drugs from 
all the requirements in a final rule.
    Response: We believe it is clear throughout this final rule that 
none of the prior authorization policies apply to any drugs covered by 
any impacted payer. However, based on the overwhelming number of 
comments in support of our reconsideration of the policy, and 
additional conversations with SDOs and stakeholders, we will consider 
options for future rulemaking to address improvements to the prior 
authorization processes for drugs.
    Comment: Multiple commenters expressed disappointment that CMS 
excluded outpatient prescription drugs from the prior authorization 
process and Prior Authorization API policies in the proposed rule, 
explaining that drug prior authorizations constitute the majority of 
all prior authorizations. Multiple commenters recommended that CMS 
reconsider the exclusion of drugs from the proposed rule and suggested 
that CMS expand a final rule to include outpatient prescription drugs 
covered under a medical benefit.
    A few commenters specifically requested that CMS include drugs 
covered under a medical benefit in the prior authorization process and 
Prior Authorization API policies in the final rule and explained that 
the exclusion was troubling because health plans may cover physician-
administered drugs and specialty drugs through a patient's medical 
benefits, including specialty drugs. A commenter urged CMS to include 
administered drugs, which are inextricably related to other provider 
services. Some commenters stated that by failing to include 
administered drugs throughout the proposed rule, CMS is failing to 
address the biggest culprit of delay to timely care and administrative 
burden for cancer patients. Commenters described barriers to access for 
prescriptions for specialty drugs, cancer drugs, and certain drugs for 
chronic conditions that require ongoing re-authorizations. The 
commenters believed that including prescription drugs in our prior 
authorization policies would improve the effectiveness of this final 
rule and would support CMS's goals of reducing barriers and burdens in 
health care.
    Response: While we acknowledge the request for reconsideration, 
when making the decision to exclude prescription drugs from the 
proposed rule, we believed there would be operational complexities in 
applying the requirements of this rule to prior authorization for 
prescription drugs under current conditions and did not anticipate the 
overwhelming response to that exclusion under current conditions. Based 
on the scope and breadth of the comments, it is essential for us to 
conduct a thorough evaluation of both existing policies and standards, 
and the impact any mandatory changes will have on impacted payers, 
providers, and patients, as well as on other policies before making a 
proposal for public consideration. We are committed to ensuring 
transparency of the process, and the development of the right policy to 
support all entities who might benefit. We anticipate engaging with the 
public on this topic in the near future and encourage the public to 
provide additional feedback.
    Comment: Many commenters questioned whether impacted payers are 
permitted to include the functionality necessary to conduct prior 
authorization for drugs via the Prior Authorization

[[Page 8766]]

API. A commenter also requested that CMS require all payers to include 
drug-related prior authorization requirements in the Prior 
Authorization API to ensure prescribers have ready access to uniform 
policies, and patients have timely access to their medications. Another 
commenter recommended that CMS explain that even if prescription drugs 
are excluded from the requirements, the rule does not prohibit the 
sharing of drug prior authorization data via the Patient Access, 
Provider Access, and Payer-to-Payer APIs.
    Response: While we did not propose a requirement for prior 
authorization policies for drugs to be included in the Prior 
Authorization API, payers may add such coverage rules and requirements 
to their APIs; nothing in this final rule prohibits broader use of the 
required Prior Authorization API by impacted payers and we encourage 
them to do so to the extent permitted by law. The scope of the IGs for 
the Prior Authorization API includes prior authorization for 
medications covered under a medical benefit. We describe the IGs and 
the Prior Authorization API in further detail in section II.D.2. of 
this final rule. However, we note that a FHIR API cannot be used with a 
National Council for Prescription Drug Programs (NCPDP) SCRIPT standard 
because the data elements have not yet been mapped. Also, the 
HL7[supreg] FHIR[supreg] Da Vinci Prior Authorization Support (PAS) IG 
states it ``SHOULD NOT be used for any medication that is covered under 
a prescription drug program benefit where Prior Authorization is 
provided by another electronic exchange process (for example, NCPCP 
SCRIPT).'' \7\
---------------------------------------------------------------------------

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

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

[[Page 8767]]

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

[[Page 8768]]

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

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

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

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

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

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

A. Patient Access API

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

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

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

[[Page 8769]]

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

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

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

[[Page 8770]]

include the capability to send information from a patient to a payer. 
Therefore, while patients have the right under the HIPAA Privacy Rule 
to request that a HIPAA-covered entity (such as a provider or payer) 
amend their record, that functionality is out of scope for the Patient 
Access API.
a. Prior Authorization Information
    To enhance our policy finalized in the CMS Interoperability and 
Patient Access final rule, we proposed in the CMS Interoperability and 
Prior Authorization proposed rule to add information about prior 
authorizations to the categories of data required to be made available 
to patients through the Patient Access API. We stated that this 
proposal would apply to all prior authorization requests and decisions 
for items and services (excluding drugs) for which a payer has data in 
the patient's record, as discussed further in this section. We also 
proposed that the Patient Access API must include certain information 
about prior authorizations within 1 business day of receipt of, or 
change of status to, the prior authorization. The primary goal of the 
Patient Access API is to give patients access to their health 
information, and by expanding patient access to prior authorization 
information, we aim to help patients be more informed decision makers 
and true partners in their health care.
    As discussed in section I.D. of this final rule, our prior 
authorization proposals did not apply to drugs of any type that could 
be covered by an impacted payer, including, for example, outpatient 
drugs, drugs that may be prescribed, drugs that may be administered by 
a provider, drugs that may be dispensed or administered in a pharmacy 
or hospital, or over-the-counter (OTC) drugs.
    In section II.D. of this final rule, we finalize several proposals 
focused on making the prior authorization process less burdensome for 
providers and payers, which we anticipate will reduce delays in 
medically necessary access to covered items and services and improve 
patient outcomes. Giving patients access to information about prior 
authorization requests and decisions will enable them to take a more 
active role in their own health care.
    We are finalizing our proposal to require impacted payers to 
provide patients, through the Patient Access API, with access to 
information about prior authorization requests and decisions made for 
their care and coverage. However, we are finalizing a modification to 
our proposal and not requiring payers to share the quantity of items or 
services used under a prior authorization or unstructured documentation 
related to a prior authorization, as discussed elsewhere in this final 
rule. We are finalizing these changes with compliance dates in 2027 (by 
January 1, 2027, for MA organizations and state Medicaid and CHIP FFS 
programs; by the rating period beginning on or after January 1, 2027, 
for Medicaid managed care plans and CHIP managed care entities; and for 
plan years beginning on or after January 1, 2027, for QHP issuers on 
the FFEs), which is a year after the proposed 2026 compliance dates.
    Comment: A significant majority of commenters expressed support for 
CMS's proposal to include prior authorization information in the 
Patient Access API. Commenters listed multiple benefits to making prior 
authorization information available via the Patient Access API, 
including empowering patients in their care, reducing the burden of 
repeated inquiries to payers, and facilitating faster decisions by 
allowing patients to help providers submit the necessary documentation. 
Multiple commenters highlighted current challenges for patients to 
access their prior authorization information.
    Response: We appreciate commenters' feedback confirming the 
significant burden that prior authorizations processes place on 
patients. We received comments from across the industry that indicated 
that those processes could be improved by interoperable data exchange. 
Those comments have informed the policies we are finalizing to require 
impacted payers to make available via the Patient Access API certain 
information about prior authorizations.
    Comment: Multiple commenters expressed concerns that because many 
patients do not have an overall understanding of the prior 
authorization process, giving patients access to prior authorization 
information would add to existing confusion, and that this information 
may be overwhelming. Some commenters stated that they do not believe 
that additional requirements and burden on impacted payers around the 
Patient Access API are warranted based on current app adoption by 
patients. The commenters stated that there should be greater Patient 
Access API use before adding more requirements to the Patient Access 
API.
    Commenters cautioned against creating any expectations for patient 
involvement in a prior authorization process that they may not 
understand and over which they may have little control. Other 
commenters recommended that CMS explore strategies to promote access to 
timely prior authorization-related information for patients who cannot 
or do not want to use health apps.
    Response: We understand that not all patients will want to access 
their prior authorization data, and some may not be able to fully 
understand the information that is presented to them. However, we do 
not believe that this is a sufficient justification for not making 
those data available to patients who want that access and insight into 
their care. We strongly encourage payers to make data transparent and 
explain the processes involved in a patient's coverage in an easily 
understandable manner.
    We do not intend to create expectations for patient involvement in 
the prior authorization process but want to make that opportunity 
available where it can be beneficial to expedite prior authorization 
decisions. To the extent that program-specific requirements do not 
already require such disclosures to enrolled patients, we urge payers 
to make prior authorization information available to patients 
regardless of what method they use to inquire about their coverage or 
care--whether that is an online patient portal, a phone call to 
customer service agents, or an email inquiry. However, our proposals in 
this section only addressed information available to patients via the 
Patient Access API.
    Comment: Some commenters stated that, because prior authorization 
requests today are commonly submitted via multiple modalities, CMS 
should modify its proposal to require prior authorization information 
be included in the Patient Access API only if it came from requests 
submitted via a Prior Authorization API. Commenters flagged that prior 
authorization data received in non-standard formats, such as fax, would 
require significant resources for many payers to translate into a 
standard format to be shared via the Patient Access API. Commenters 
stated that adoption of electronic prior authorization by providers 
would be gradual, and it would be administratively complex and 
burdensome to require payers to convert prior authorizations submitted 
via phone or fax to electronic format. The commenters recommended that 
CMS make sharing prior authorizations received via phone or fax 
optional for payers.
    Response: We understand that data submitted for prior authorization 
requests via non-electronic or non-standardized modalities could 
require an additional step to make available through the Patient Access 
API. However, we also note that the burden of ingesting data from non-
standard and

[[Page 8771]]

non-electronic requests into a payer's prior authorization systems 
exists regardless of the requirement to share data with the patient. 
While sharing requests submitted via a Prior Authorization API might be 
simpler, as they are already in a FHIR format, we do not believe that 
the burden of converting data from the format payers currently use in 
their prior authorization systems outweighs the benefit of making prior 
authorization information available to patients. We also note that the 
same prior authorization data are largely required to be shared via the 
Provider Access and Payer-to-Payer APIs, thus creating an economy of 
scale by spreading the benefit to all parties while the burden of data 
translation would only have to happen once. We believe that all 
patients should have access to their prior authorization information, 
regardless of the process between their provider and payer.
    In section II.D. of this rule, we are finalizing a requirement for 
impacted payers to implement and maintain a Prior Authorization API and 
in section II.F. of this rule, we are finalizing a measure within MIPS 
to incentivize providers to use that Prior Authorization API. We are 
finalizing those policies to promote the adoption of electronic prior 
authorization and, therefore, expect that as electronic prior 
authorization increases over time, the overall burden of making 
available prior authorization information submitted and received 
through other modalities will decrease. We believe that payers will 
also encourage their providers to use electronic prior authorization to 
decrease that burden, which will lead to greater interoperability and 
data availability for patients.
    Also, if we required only prior authorization data submitted via a 
Prior Authorization API to be available via the Patient Access API, we 
would be excluding patients whose providers may not be able to 
implement electronic prior authorization for technological or other 
reasons. Therefore, we are finalizing a Patient Access API policy that 
covers data from all prior authorizations, regardless of the medium 
through which the payer receives the request.
    Comment: A commenter noted challenges that state Medicaid agencies 
would face to include prior authorization data in the Patient Access 
API. The commenter stated that there are differences between how states 
process prior authorizations today, with some state Medicaid agencies 
relying on manual processes.
    Response: State expenditures on designing, developing, installing, 
enhancing, or operating state Medicaid systems that can conduct 
electronic prior authorization may be eligible for enhanced Federal 
financial participation. Implementation of the Prior Authorization API 
should facilitate a faster and more automated workflow to make prior 
authorization data available. We encourage states to take this 
opportunity to determine whether modernizing prior authorization 
systems beyond the implementation of a Prior Authorization API can 
improve their prior authorization processes. We describe the enhanced 
Medicaid Federal matching percentages in fuller detail in section II.E. 
of this final rule.
    Comment: A commenter requested that CMS explain that the 
information it is requiring to be available does not need to be 
``pushed'' to a patient app, but should be available for query, if a 
patient chooses to use their app to retrieve their information.
    Response: We confirm that the Patient Access API works on a query 
mechanism and not a ``push.'' Our final policy requires that the data 
be available for a patient's app to query and receive from an impacted 
payer.
    Comment: Some commenters suggested that patients should be able to 
provide supporting documentation directly to their payer via the 
Patient Access API. The commenters stated that patients should have the 
choice to submit prior authorization requests themselves, or to have a 
provider or third party do it, and should also have the option to 
initiate, monitor, and appeal prior authorization decisions. Another 
commenter believed that patients should be able to challenge decisions 
and report delays.
    Response: We did not propose to require impacted payers to accept a 
prior authorization request or supporting documentation directly from 
patients. We fear that this would create confusion about the prior 
authorization process and whether the provider or patient is ultimately 
responsible for the submission of prior authorization requests and 
documentation. Providers are in the best position to understand the 
clinical requirements to obtain prior authorization and are responsible 
for using their clinical judgment to decide on the best course of 
treatment. As discussed, it is valuable for patients to have 
transparency into that process and be able to assist providers to 
submit necessary information. However, without a clinical 
understanding, patients may submit extraneous or irrelevant 
information. Furthermore, patients likely do not have systems that 
would be able to communicate and submit information via the Prior 
Authorization API. That would require the availability of an 
alternative system and negate some of the efficiencies the Prior 
Authorization API will bring to the prior authorization process. Taken 
together, such a requirement would add burden to payers and may end up 
delaying the prior authorization decision process. Nothing in this rule 
will prohibit a payer from accepting information directly from patients 
if that would benefit the payer's processes or patient care. 
Furthermore, payers are already required to have a process in place for 
patients or providers to appeal prior authorization decisions and to 
file a complaint with the appropriate Federal or state oversight 
agency.
i. Compliance Dates
    For the requirement to include prior authorization information in 
the data available via the Patient Access API, we proposed compliance 
dates in 2026 (by January 1, 2026, for MA organizations and state 
Medicaid and CHIP FFS programs; by the rating period beginning on or 
after January 1, 2026, for Medicaid managed care plans and CHIP managed 
care entities; and for plan years beginning on or after January 1, 
2026, for QHP issuers on the FFEs).
    Comment: Some commenters supported the proposed compliance dates. 
However, several commenters recommended that the compliance dates for 
adding prior authorization information to the Patient Access API be 
accelerated--with recommendations for July 1, 2024, January 1, 2025, or 
12 months after the finalization of this rule. Multiple commenters 
recommended earlier compliance dates due to the significant impact that 
this information could have on patient empowerment and information 
transparency.
    Conversely, multiple commenters recommended that CMS delay the 
proposed compliance date until the Prior Authorization API, discussed 
in section II.D. of this final rule, is widely adopted. Commenters 
stated that while the technical data standards may be mature, CMS 
should also consider the status of payers' data infrastructure, which 
may not have prior authorization information in a structured format to 
be shared via the Patient Access API. As discussed previously, some 
commenters recommended limiting the requirement to make prior 
authorization data available through the Patient Access API only to 
data contained in standardized HIPAA-compliant electronic prior 
authorization transactions, such as those facilitated by the Prior 
Authorization

[[Page 8772]]

API. These commenters recommended that CMS work with payers, providers, 
health IT developers, and consumer advocacy groups to first advance 
electronic prior authorization uptake before determining appropriate 
compliance dates. A commenter suggested CMS consider additional 
flexibilities and exceptions for impacted entities unable to comply 
with the proposed 2026 compliance dates.
    Another commenter recommended delaying the compliance dates by 
another 2-3 years to allow for simultaneous implementation with the 
``Administrative Simplification: Adoption of Standards for Health Care 
Attachments Transactions and Electronic Signatures, and Modification to 
Referral Certification and Authorization Transaction Standard'' 
proposed rule (hereinafter referred to as the HIPAA Standards for 
Health Care Attachments proposed rule) (87 FR 78438).
    Response: After reviewing public comments, we have elected to 
finalize the provision with a 1 year delay to the compliance dates, to 
2027 (by January 1, 2027, for MA organizations and state Medicaid and 
CHIP FFS programs; by the rating period beginning on or after January 
1, 2027, for Medicaid managed care plans and CHIP managed care 
entities; and for plan years beginning on or after January 1, 2027, for 
QHP issuers on the FFEs). While making data related to prior 
authorization available to patients is necessary and urgent, we also 
understand that it will take time for payers to implement the policies 
we are finalizing. We believe that the additional year will allow 
payers to ensure a smooth rollout of this additional functionality. 
However, we encourage payers to meet the requirements of this rule as 
soon as possible to benefit their patients.
    We decline to delay the compliance date for including prior 
authorization information in the Patient Access API until after the 
Prior Authorization API compliance dates and are finalizing the same 
compliance dates for both this policy and the Prior Authorization API. 
The purpose of the Prior Authorization API is to facilitate the 
exchange of structured prior authorization data, and we agree that 
receiving requests electronically may expedite payers' ability to make 
that information available to patients. However, even after the Prior 
Authorization API compliance dates, we expect that a number of prior 
authorizations are going to be submitted through other channels 
(hopefully in declining number). As discussed previously, payers will 
need to have the ability to share prior authorization information that 
is submitted via channels other than the Prior Authorization API, 
regardless of the compliance dates. By finalizing 2027 compliance 
dates, we are providing payers with an additional year beyond what we 
proposed to implement the needed functionality within their internal 
systems.
    Comment: A commenter suggested that prior authorization decisions 
issued before the compliance dates should not be required to be 
available via the Patient Access API.
    Response: We proposed, and are finalizing, that impacted payers 
must give patients access to existing prior authorization information 
maintained by the payer beginning on the compliance dates. In the CMS 
Interoperability and Patient Access final rule, we required payers to 
make available the specified data they maintained with a date of 
service on or after January 1, 2016, which meant that patients had 
access to their historical data beginning on the January 1, 2021, 
compliance date. That date range also applies to the prior 
authorization data that must be included. However, unlike the other 
categories of data, there is a period of time after which prior 
authorization data no longer needs to be available. As discussed 
elsewhere in this final rule, prior authorization information must be 
shared while the prior authorization is active and for 1 year after the 
last status change. As of the compliance dates, payers must make all 
required data available via the Patient Access API. However, it is 
unlikely that a significant number of patients will have data from many 
years before the compliance dates. On January 1, 2027 (or the actual 
compliance date), payers will be required to make available data about 
all active prior authorizations, regardless of how long they have been 
active, and any requests that have had a status update within the 
previous 1 year period (that is, since January 1, 2026, if a payer 
implements on these changes on that day).
ii. Data Content
    We proposed that the information required to be available through 
the API would include the prior authorization request and related 
administrative and clinical documentation, including all of the 
following:

    (1) The prior authorization status.
    (2) The date the prior authorization was approved or denied.
    (3) The date or circumstance under which the authorization ends.
    (4) The items and services approved.
    (5) The quantity used to date under the authorization.
    (6) If denied, the specific reason why the request was denied.

    In section II.D.3. of this final rule, we are finalizing that in 
the case of a prior authorization denial, the payer must give the 
provider a specific reason for the denial that is separate from the 
content requirements for the APIs finalized in this rulemaking. 
Including the reason in the Patient Access API can help patients 
understand why a payer denied a prior authorization request. The 
administrative and clinical documentation related to a prior 
authorization request that we proposed must be shared through the 
Patient Access API would include any materials that the provider sends 
to the payer to support a decision, for example, structured or 
unstructured clinical data including laboratory results, scores or 
assessments, past medications or procedures, progress notes, or 
diagnostic reports. For the reasons discussed, we are finalizing 
modifications to our proposals to not require impacted payers to 
include ``the quantity used to date'' or unstructured documentation in 
the data available via the Patient Access API.
    As further discussed in sections II.B. and II.C. of this final 
rule, we are requiring impacted payers to make available generally the 
same information about prior authorization requests and decisions via 
the Provider Access and Payer-to-Payer APIs. In this way, these prior 
authorization data can be available to all relevant parties. We note 
that the requirement to share information about prior authorizations 
via the Patient Access and Provider Access APIs is in addition to any 
notice requirements that apply to prior authorization requests and 
decisions, such as the requirement to notify providers of a decision 
within certain timeframes discussed in section II.D.5.b. of this final 
rule.
    Comment: Some commenters recommended that CMS require payers to 
make data more actionable and descriptive by including detailed reasons 
why a prior authorization request is pending. Many commenters 
recommended a status for when certain services do not require prior 
authorization. Conversely, to make status updates simpler via the 
Patient Access API, multiple commenters suggested only having a 
pending, active, denied, or expired status update. A commenter 
requested clarification on whether, in our proposal, the listed 
``another status'' was a status unto itself or used as a catch-all 
description of any statuses other than those listed.
    Response: While we consider five basic statuses (pending, active, 
denied,

[[Page 8773]]

expired, authorization not required) to cover the general scope of a 
prior authorization request and decision, we are neither defining the 
term ``status'' as used in this rule, nor these five basic statuses or 
the conditions under which they must be used by impacted payers. We 
understand that payers use a variety of processes and do not intend to 
prescribe exactly when a particular status must be used. Rather, we are 
indicating that impacted payers must make clear to patients (via the 
Patient Access API) and providers (via the Provider Access API 
discussed in section II.B. of this final rule), the status of a prior 
authorization decision, such as when it is pending, approved, denied, 
or expired or a request has been submitted for an item or service that 
does not require prior authorization. We expect payers will generally 
use those statuses, but they are also welcome to use other statuses 
that provide additional information or are more specific to the 
particular payer's process. Such statuses should be clear and 
understandable to patients and providers. For example, a payer could 
use statuses such as ``under appeal'' or ``expired--approved quantity 
used.'' However, in some cases, the status information available beyond 
``pending'' could be meaningless to patients if it refers only to the 
payer's internal processes.
    We also agree that patients could benefit from payers making it 
clear through the Patient Access API when an item or service submitted 
for prior authorization does not require prior authorization for 
coverage. However, we emphasize that a mere query as to whether prior 
authorization is required would not create a record that needs to be 
shared via the Patient Access API (or the Provider Access API). For 
instance, a provider may use the HL7[supreg] FHIR[supreg] Da Vinci 
Coverage Requirements Discovery (CRD) IG, which is the part of the 
Prior Authorization API that allows a provider to query whether a payer 
requires prior authorization before they will cover a specific item or 
service for a specific patient. Similar queries made through other 
channels, or submissions that are rejected for being unnecessary, need 
not be made available through the Patient Access API unless the request 
creates a record in the patient's data maintained by the payer. Though 
not required, impacted payers would be welcome to make that information 
available.
    Comment: Multiple commenters supported our proposal that the 
Patient Access API enhance transparency by including a specific reason 
for denial. Commenters stated that including a reason for denial would 
help beneficiaries dispute decisions in a more effective manner. A few 
commenters urged CMS to require impacted payers to disclose via the 
Patient Access API the specific coverage or clinical criteria upon 
which the impacted payer relied to issue a denial.
    Response: While we encourage payers to provide coverage or clinical 
criteria that they used to make a prior authorization decision if that 
information would help the patient or provider understand the prior 
authorization decision, many payers consider that specific information 
to be proprietary. In addition to potentially being proprietary, those 
clinical criteria may be significantly more complicated than the 
information we are requiring, and not easily understood by patients. 
Therefore, we did not propose to require that detailed clinical 
criteria for a prior authorization decision be shared with patients 
through the Patient Access API. Instead, we proposed and are finalizing 
that when a payer denies a prior authorization request, they must 
provide a specific reason for that denial through the Patient Access 
API. That reason may indicate which clinical criteria the patient did 
not meet to be approved for the items or services. We reiterate that 
the requirement that the specific reason for a denial be included in 
the Patient Access API is in addition to any other applicable 
requirements regarding notice of decisions, such as the requirement at 
42 CFR 422.568(e) that MA organizations issue a notice containing 
specific content when denying a prior authorization request and similar 
requirements for Medicaid managed care plans at 42 CFR 438.210(c) and 
for health insurance issuers offering individual health insurance 
coverage (which includes QHP issuers on the FFEs) at 45 CFR 
147.136(b)(3)(ii)(E).\12\
---------------------------------------------------------------------------

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

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

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

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

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

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

[[Page 8774]]

a patient for weeks or months until claims are processed.
    Response: We understand that payers may not always have accurate or 
current information about the quantity of approved items or services 
that a patient has used as of a specific date under a prior 
authorization. Payers must rely on claims data for that information, 
which are often not current because there is typically a time lag 
between when an item or service is rendered and when the claim is 
submitted and/or processed. If a patient knows that they have used some 
quantity of the approved items and services, but is not sure of the 
specific quantity, receiving inaccurate information from their payer 
about the quantity used to date would lead to confusion and possibly 
unnecessary inquiries that take patients, providers, and payers time to 
resolve. Therefore, we are not finalizing our proposal to include 
``quantity of approved items or services used to date'' in the prior 
authorization information available via the Patient Access API. 
However, we are finalizing our proposal to require a total number of 
items or services approved under the prior authorization decision.
    Comment: Some commenters recommended that administrative and 
clinical documentation sent by the provider for prior authorization 
requests be included in the Patient Access API. However, multiple other 
commenters recommended that CMS not finalize its proposal to include 
supporting documentation for prior authorization requests. Some 
commenters specifically recommended that CMS not require payers to 
include data or forms that were not sent in a standardized electronic 
manner, such as via the Prior Authorization API. The commenters 
expressed concern about the feasibility for impacted payers to provide 
information that they received in a non-electronic or unstructured 
format (such as scanned documents or PDFs) and whether third-party 
patient apps can access or display such documentation. Instead, 
commenters recommended that CMS focus on requiring that discrete data 
elements and structured data related to prior authorizations be 
available to patients. While some commenters expressed that structured 
data may be duplicative or unnecessary, a majority of commenters 
indicated that including such data would not be overly burdensome for 
payers.
    Other commenters requested clarification regarding what types of 
provider-generated documentation would be required and some recommended 
that CMS assess the prior authorization information requirements 
against information already available in the APIs to mitigate redundant 
or duplicative information.
    Response: After reviewing the comments, we agree that the burden of 
requiring impacted payers to make unstructured documentation available 
via the Patient Access API outweighs the benefits such documentation 
would provide, so we are finalizing a requirement that the Patient 
Access API must include structured administrative and clinical 
documentation submitted by a provider related to the prior 
authorization request.
    Structured documentation includes any data received from a provider 
and stored in the payer's system in a standardized format with defined 
data attributes, such as USCDI or FHIR. Examples of structured 
documentation include data sent by the provider via a transaction 
standard for prior authorization(s), which utilizes standard code sets, 
data sent via a Prior Authorization API in a format other than as an 
attachment, or structured questionnaires that a payer requires 
providers to fill out when making the prior authorization request. 
Unstructured data include any attachments submitted by providers, such 
as radiological scans, large PDFs of clinical data, or, generally, 
another file that a provider sends to the payer as an attachment to the 
prior authorization request.
    We note that documentation received in an unstructured format does 
not need to be parsed and converted to structured data to be included 
in the Patient Access API. However, if a payer does parse the 
unstructured documentation to store the contained data in a structured 
format, those structured data would then be ``maintained'' by the 
payer, as defined in the CMS Interoperability and Patient Access final 
rule (85 FR 25538), and the payer would be required to make it 
available via the Patient Access API.
    At this time, the standards for transmitting documentation and 
attachments via the FHIR APIs are still under development and in 
testing, and thus not yet in widespread use across the industry. The 
developing standard for exchanging attachments via FHIR APIs is the 
HL7[supreg] FHIR[supreg] Da Vinci Clinical Data Exchange (CDex) IG.\15\ 
Version 2 of the IG completed the HL7 consensus-based process in 2023 
and was published as an STU, indicating that it is being prepared for 
additional testing by implementers before being proposed for adoption. 
Without the FHIR standard, payers might implement unstructured 
documentation attachments within the Patient Access API in a variety of 
ways, which would lead to confusion and lack of interoperability. At 
this time, attachments exchanged via CDex are considered unstructured 
documentation and would not need to be made available via the Patient 
Access API as part of the prior authorization information. If the CDex 
becomes a mature standard, we may reconsider in future rulemaking 
whether it would be beneficial to share unstructured documentation as 
attachments via the Patient Access API.
---------------------------------------------------------------------------

    \15\ Health Level Seven International (2023). Da Vinci Clinical 
Data Exchange. Retrieved from https://hl7.org/fhir/us/davinci-cdex/.
---------------------------------------------------------------------------

    We recognize that unstructured administrative and clinical 
documentation from a provider could be important to help patients 
understand the prior authorization process, so we encourage payers to 
make that information available when possible. Furthermore, the policy 
we are finalizing will require impacted payers to make available any 
documentation that a provider sends to the payer to support a prior 
authorization request that is received in a structured format. Since we 
are finalizing that only structured data be made available, and 
structured data are formatted in a way that makes them easily 
transmissible between systems, our final policy should place 
significantly less burden on payers than our proposal, while still 
giving patients access to information about their prior authorization 
processes.
    We note that some of that information may already be available via 
the Patient Access API as clinical data. However, we believe that there 
is value to patients being able to ensure that the clinical information 
reviewed by the payer is accurate and up to date. Therefore, it is 
important for payers to make available the specific clinical data that 
they are looking at to decide on the prior authorization request, even 
if that information may be elsewhere in the patient's record.
    Comment: Multiple commenters suggested that the Patient Access API 
should include information regarding whether the requesting provider is 
in-network or out-of-network, by requiring payers to fully implement 
the X12 270/271 transaction standards for health plan eligibility 
benefit inquiry and responses. Another commenter recommended that CMS 
require payers to make available via the Patient Access API the names 
and contact information for the in-network provider who can furnish the 
appropriate service within the time and distance standards required by 
law. Multiple commenters

[[Page 8775]]

believed that patients should be able to access prior authorization 
information via the Patient Access API regardless of their provider. A 
commenter noted consideration for varying network adequacy standards 
and that a patient may need to seek care from an out-of-network 
provider. A commenter noted that Medicaid managed care plans have wide 
discretion for measuring provider network adequacy and that a patient's 
provider should be able to offer the same services for prior 
authorization despite their network status with the patient.
    Response: This rule makes no distinction between in-network and 
out-of-network providers with regard to making prior authorization 
information available through the Patient Access API. Regardless of the 
requesting provider's network status, the required information must be 
shared with patients. We understand that it is important for patients 
to know whether the provider they are seeing is in their payer's 
network, but we do not believe that the appropriate place for that 
information is with prior authorization information. Furthermore, the 
FHIR API technical specifications and IGs for the Patient Access API 
are not built to include information on a provider's network 
participation. We note that in the CMS Interoperability and Patient 
Access final rule (85 FR 25563), we required MA organizations, state 
Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP 
managed care entities to build and maintain a Provider Directory API. 
We encourage developers to integrate within their apps network 
information from payers' Provider Directory APIs for easy patient 
access.
    To the extent that a provider's network status may increase a 
patient's out of pocket costs, we encourage payers to inform patients 
before they receive items or services from an out-of-network provider 
to the extent that applicable programmatic requirements do not already 
require the payer to do so.
    Comment: A commenter recommended that a log of all instances that a 
patient's data was transferred via the Provider Access and Payer-to-
Payer APIs should also be documented and accessible under the Patient 
Access API.
    Response: We did not propose that payers must make that information 
available via the Patient Access API but encourage payers to do so for 
transparency with respect to when and with whom a patient's data are 
being shared. We will consider proposing to require this in future 
rulemaking.
iii. Timeline for Data Sharing
    We proposed to require impacted payers to make available, via the 
Patient Access API, information about prior authorization requests and 
decisions for items and services (excluding drugs) to patients no later 
than 1 business day after the payer receives the prior authorization 
request or there is another status change for the prior authorization. 
Examples of status changes include: a payer receives a request, a payer 
approves or denies a pending prior authorization request, or a provider 
updates a denied prior authorization request with additional 
information for reconsideration. We expect that impacted payers use a 
variety of terminology, but, generally, any meaningful change to the 
payer's record of the prior authorization request or decision will 
require an update to the information available to the patient.
    We proposed 1 business day as the appropriate timeframe because 
patients need timely access to the information to understand prior 
authorization processes and their available care options. As discussed 
further in section II.D. of this final rule, we proposed to require 
payers to make much of the same information about prior authorization 
requests and decisions available via the Prior Authorization API during 
the decision-making process. In addition, we stated that because 
impacted payers would be required to have the ability to exchange prior 
authorization information electronically, it would be reasonable for 
them to share prior authorization information with patients within 1 
business day of any update to the prior authorization request or 
decision.
    Comment: Many commenters expressed that the prior authorization 
process is opaque and burdensome to patients. Commenters stated that 
patients often wait for approval for critical items and services 
without status updates from their payer. Those commenters voiced 
support for the proposed requirement that payers make prior 
authorization information, including decision status and documentation 
information, available through the Patient Access API within 1 business 
day after the payer receives the request. Multiple commenters noted 
that this will provide greater transparency with respect to the prior 
authorization process.
    Response: We appreciate commenters confirming that our proposed 
policies would ease the burden of prior authorization processes and 
benefit patients and providers. We agree that timely access to 
information about their prior authorizations is important to increase 
transparency and ensure that patients understand their care and 
coverage.
    Comment: Multiple commenters, specifically payers, noted that the 
proposed 1 business day window may not be operationally feasible for 
payers. A commenter noted that, to implement this requirement, payers 
would need to develop an interface to move prior authorization data 
between multiple internal systems, which will be especially difficult 
for requests submitted in a non-electronic format. Other commenters 
noted business process and operational challenges that would make 1 
business day difficult and burdensome, such as the time to manually 
assess whether they can legally make the information available via the 
Patient Access API under applicable state law. A commenter stated that 
1 business day would not be feasible for Medicaid agencies due to the 
necessary updates to the Medicaid Management Information System (MMIS) 
systems.
    Many commenters recommended that CMS instead consider requiring a 2 
business day response requirement. A commenter recommended extending 
the proposed requirement to 2 business days until electronic Prior 
Authorization APIs are widely adopted and proven, and only then 
consider a 1 business day requirement. Another commenter recommended 
that CMS extend the timeframe window to 7 calendar days. Some 
commenters noted that although the prior authorization process would be 
automated by the implementation of the Prior Authorization API, they 
recommend extending the 1 business day timeframe for the Patient Access 
API to match the period a payer has to make a determination on the 
prior authorization.
    Response: We appreciate commenters' perspectives regarding the 
feasibility of a 1 business day timeframe. Per the comments we 
received, the most significant barrier to the 1 business day timeframe 
we proposed was the proposed requirement to include unstructured 
documentation with prior authorization information. As discussed 
previously, we are not finalizing a requirement to make available 
unstructured prior authorization documentation via the Patient Access 
API. That exclusion from the data required to be made available will 
reduce the amount of data translation and transformation required to 
have data available via the Patient Access API. In addition, as 
discussed in section I.D., we are delaying the compliance

[[Page 8776]]

dates by 1 year from our proposed 2026 to 2027 in order to give 
impacted payers additional time to make system changes necessary to 
meet the requirements of this final rule. We acknowledge that this may 
be particularly challenging for Medicaid and CHIP agencies based on 
existing MMIS systems. As discussed in section II.E. of this final 
rule, expenditures for required changes to states' MMIS or other state 
systems may be eligible for enhanced Federal financial participation. 
That funding may be available, not just for systems and processes that 
directly contribute to data available via the Patient Access API, but 
for other systems, such as those that track prior authorization 
requests and decisions. We also note that the Prior Authorization API 
discussed in section II.D. will greatly facilitate the movement of 
structured prior authorization data. Payers, including Medicaid and 
CHIP, should consider levers for promoting its usage by their 
providers.
    After reviewing comments, we believe that between the changes to 
the data that must be shared and the additional implementation time, 
payers will be able to make necessary changes to meet these 
requirements by the finalized compliance dates. Therefore, we are 
finalizing the timeframe as proposed and are requiring payers to make 
prior authorization information available via the Patient Access API 
within 1 business day of receiving a request. Impacted payers must 
update prior authorization information made available via the Patient 
Access API within 1 business day of any status change.
    Comment: Multiple commenters recommended that CMS retain the 
proposed 1 business day timeframe for prior authorization requests 
received via the Prior Authorization API but extend the timeframe for 
prior authorizations received through other channels (for example, by 
proprietary portal, fax, or phone). A commenter noted that, in the 
dental field, not all prior authorizations are submitted 
electronically. An additional commenter noted this timeframe does not 
provide impacted issuers adequate time to transfer information received 
by alternate methods (phone, fax) to interoperable, electronic formats. 
A commenter stated that the turnaround is not operationally feasible if 
the information is not received in a standardized format.
    Response: As discussed in the previous section, we are finalizing 
our proposal with a modification to require that only structured 
documentation related to prior authorizations be made available via the 
Patient Access API. We believe this modification will, in large part, 
address this issue. Payers will not be required to convert 
documentation from non-electronic or non-standardized prior 
authorization requests into standardized data that can be available via 
the Patient Access API. However, by requiring only the structured data 
elements, including documentation, and not unstructured documents or 
images, we believe that this will streamline that conversion process 
and make the 1 business day timeline feasible for payers.
    Comment: A commenter recommended that CMS create flexibility for 
delays between a provider sending the request and the payer's receipt. 
Another commenter recommended that CMS finalize a policy that the 1 
business day timeline for making prior authorization data available via 
the Patient Access API begins only once the payer has information 
adequate to adjudicate the prior authorization request, as defined by 
payers' prior authorization policies. The commenter noted that some 
payers may require additional time to gather the information and 
perform any necessary data transformation to the FHIR standards. 
Similarly, another commenter recommended that the 1 business day 
requirement only applies after a request is received via the X12 278 
transaction standard or Prior Authorization API electronic transaction 
that passes validation. Another commenter recommended that CMS require 
information about prior authorization be made available no later than 1 
business day after a payer makes a decision.
    Response: Our proposal was for the 1 business day timeframe to 
begin when the payer receives the prior authorization request. We are 
not requiring payers to share information that they do not possess. 
However, we disagree with the commenters' suggestions that the 1 
business day timeline should begin when the payer has sufficient 
information to adjudicate a prior authorization request, or an 
adjudication has been made. A payer could not know whether there is 
sufficient information in the request to make a decision before the 
request is reviewed. As other commenters noted, it is critical that 
patients know that a payer has received the prior authorization request 
made on their behalf, even if it has not yet been reviewed or 
adjudicated. In section II.D., we are finalizing a policy that requires 
certain payers to make a decision within 7 calendar days for standard 
requests and 72 hours for expedited requests. It may take a payer 
several days to review a prior authorization request, and not having 
any status updates during that time would leave patients and providers 
in limbo.
    We did not propose and are not finalizing a requirement that the 
timeline for making data available only applies to prior authorization 
requests received via an electronic HIPAA-compliant X12 278 transaction 
and/or FHIR transaction. We know that payers currently support a 
variety of modalities for providers to submit prior authorization 
requests, including online portals, phone, and fax. We believe that 
patients should have access to their prior authorization data within 
the same timeframe, regardless of how the prior authorization request 
was submitted. Because we are not finalizing the requirement to include 
unstructured documentation, receiving documentation in an unstructured 
format as part of a request will not hamper or delay a payer's ability 
to make the required prior authorization data available through the 
Patient Access API. A HIPAA-compliant X12 278 transaction is, by 
definition, composed of structured data, which must be made available 
through the Patient Access API, though attachments to such a 
transaction are likely unstructured documentation. Finally, we note 
that if the payer receives a request that does not pass validation or 
cannot be processed for some other reason, this could be an acceptable 
status to provide. If a payer's system fails to receive such a request, 
we cannot expect the data to be made available via the Patient Access 
API.
    Comment: A commenter recommended that CMS require providers to 
respond to payers' requests for information within a certain timeframe 
and include information on provider response timeliness in the Patient 
Access API.
    Response: We did not propose a timeline for providers to respond to 
payers' requests for additional information. However, it is entirely 
appropriate for a prior authorization status to be ``waiting for 
additional information from provider'' or similar. That would indicate 
to the patient that the provider must take some action to receive 
approval of the prior authorization, which would allow them to follow 
up with the provider to ensure that is done in a timely manner.
    Comment: A couple of commenters requested clarification about the 
relationship between our Patient Access API requirements and ONC's 
information blocking regulations at 45 CFR part 171. Specifically, 
commenters questioned the implications of the

[[Page 8777]]

information blocking regulations if payers also meet the definition of 
a health information network (HIN) or HIE at 45 CFR 171.102. They 
questioned whether our timeline requirement is compatible with the 
``21st Century Cures Act: Interoperability, Information Blocking, and 
the ONC Health IT Certification Program'' final rule (85 FR 25642) (ONC 
Cures Act final rule), which the commenter explained requires 
information to be made available to the patient ``without delay.''
    Response: Any impacted payer should consider reviewing the ONC 
Cures Act final rule to determine whether they are an actor (as defined 
at 45 CFR 171.102) and to ensure they are complying with any applicable 
information sharing policies. The information blocking regulations (45 
CFR part 171) are based on separate statutory provisions (see 42 U.S.C. 
300jj-52), unrelated to our authority to issue this rule. We encourage 
commenters to address questions or complaints regarding information 
blocking to ONC.\16\
---------------------------------------------------------------------------

    \16\ Office of the National Coordinator for Health Information 
Technology (2023, November 2). Information Blocking. Retrieved from 
https://www.healthit.gov/topic/information-blocking.
---------------------------------------------------------------------------

    We work closely with ONC and our other Federal partners to ensure 
that our regulations do not place conflicting requirements or 
unnecessary burdens on entities that are regulated by more than one 
Federal agency. However, comments specific to the information blocking 
regulations or other regulations issued by ONC are outside the scope of 
this rule. Additional information is available from the Information 
Blocking page of ONC's website: https://www.healthit.gov/topic/information-blocking.
iv. Length of Prior Authorization Data Availability
    We proposed to require that information about prior authorizations 
be available via the Patient Access API for as long as the 
authorization is active and at least 1 year after the last status 
change. We note that, under the proposal, information on denied and 
expired prior authorizations would be available for at least 1 year 
after expiring or being denied. We did not propose to require payers to 
share a patient's full prior authorization history because that could 
comprise a significant amount of information that may no longer be 
clinically relevant. Claims, encounter, and clinical data can provide 
valuable information about a patient's health history. With those data 
available through the Patient Access API, we believe that process-
related information about long-expired or denied prior authorizations 
will be irrelevant. Also, as payers' prior authorization policies may 
change over time, that information has a limited lifespan of usefulness 
to a patient's current care. At the same time, the API should include 
information about all active authorizations for as long as they are 
active, and, therefore, may include information related to ongoing 
care.
    Comment: A majority of commenters supported CMS's proposal to 
require prior authorization information to be available via the Patient 
Access API for as long as the authorization is active and for 1 year 
after the last status change. Commenters opined that this timeframe 
balanced the benefits of data availability and the burden of 
maintaining data.
    Some commenters suggested that CMS require payers to make prior 
authorization information available through the Patient Access API for 
longer than 1 year after the last status change. For example, some 
commenters suggested 3 years and others 5 years as the appropriate 
period to make information available after the last status change. 
Other commenters recommended that CMS require payers to make all prior 
authorization information available via the Patient Access API until 1 
year after the patient is no longer covered by that payer. Those 
commenters stated that historical prior authorization information may 
yet be relevant to a patient's care or could create a record for 
patients to demonstrate that they face repeated barriers in accessing 
care or receiving coverage. Finally, another commenter suggested that 
those data may be important for long-term treatment that exceeds 1 
year.
    Response: We continue to believe that 1 year after the last status 
change is the appropriate amount of time to require payers to make 
historical prior authorization information available to patients 
through the Patient Access API. There may be other requirements outside 
the scope of this rulemaking that require certain payers to make health 
care records available to individuals over a longer time period. 
Further, this rulemaking does not address the record maintenance 
requirements that apply to impacted payers. We only address the 
timeframe during which certain data must be made available through 
specific APIs. While background information may impact and improve 
patient care, we believe that the availability of claims and clinical 
data are more important to patients and providers than information 
about prior authorizations that have expired or been denied. In fact, a 
patient's claims or encounter data are likely to include any items or 
services that were subject to a past prior authorization. As finalized 
in the CMS Interoperability and Patient Access final rule, and as 
modified by this final rule, payers are also required to make available 
through the Patient Access API any claims and encounter data, and all 
data classes and data elements included in a content standard at 45 CFR 
170.213 (USCDI), which includes clinical data, maintained by the 
impacted payer with a date of service on or after January 1, 2016.
    As discussed previously, some commenters stated that including 
prior authorization information in the Patient Access API could lead to 
information overload and confusion for patients. While we do not 
believe that to be the case for active and recent prior authorizations, 
it may be so if patients were presented with a large amount of 
historical prior authorization data that may no longer be relevant. 
Therefore, we believe that 1 year is the appropriate timeframe for 
requiring prior authorization data to be available via the Patient 
Access API. We emphasize that for ongoing long-term care, any active 
prior authorizations must be included, even if they have been in that 
status for more than 1 year. Furthermore, we encourage payers to make 
these prior authorization data available for longer than 1 year if they 
believe it adds value to patients, providers, or themselves and their 
own processes.
b. Interaction With HIPAA Right of Access Provisions
    Previous CMS interoperability proposals have elicited numerous 
comments regarding the interaction between the Patient Access API and 
HIPAA Privacy Rule individual right of access.\17\ Per 45 CFR 164.524, 
an individual patient generally has a right of access to inspect and 
obtain a copy of PHI about themselves in a designated record set for as 
long as the PHI is maintained in the designated record set by a covered 
entity. This includes the right to inspect or obtain a copy, or both, 
of the PHI. Our Patient Access API policies complement that right by 
requiring payers to make available--through a standards-based and 
interoperable FHIR API (that is, the Patient Access API)--PHI that 
patients already have a right to access. It is critical that 
individuals have access to their own health information and the ability 
to share it with others who are

[[Page 8778]]

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

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

    Consistent with the HIPAA Privacy Rule, we believe that it behooves 
us to require all impacted payers to have the capability to provide 
individuals' PHI via an industry standard FHIR API, so that patients 
can access their data through apps of their choice. We believe that, in 
addition to the other benefits described in this final rule, ensuring 
that patients can receive their PHI in a standard, interoperable format 
that they can use with the latest technologies will reduce instances of 
an individual requesting PHI in an electronic format that is not 
readily producible, which could reduce costs and burden for patients 
and payers.
    In the CMS Interoperability and Patient Access final rule, we 
established that the only reason payers could deny API access to a 
patient's preferred health app is if it would present an unacceptable 
level of risk to the security of PHI on the payer's system. These risks 
include, for example, insufficient authentication or authorization 
controls, poor encryption, or reverse engineering. The payer must make 
that determination using objective, verifiable criteria that are 
applied fairly and consistently across all apps and developers.\18\
---------------------------------------------------------------------------

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

    As we discussed in the CMS Interoperability and Patient Access 
final rule (85 FR 25518), disagreement with the patient about the 
worthiness of a health app as a recipient of patient data, or even 
concerns about what the app might do with the requested data, are not 
acceptable reasons to deny an individual's request. Impacted payers may 
offer advice to patients on the potential risks of permitting an app or 
entity access to the patient data required to be made available via the 
Patient Access API. However, such efforts generally must stop at 
education and awareness or advice related to a specific app. Payers can 
inform the patient that the patient may not want to allow an app to 
access their data without a clear understanding of how that app may use 
their data, including how the patient's personal data would be used or 
sold (a possibility for apps that are not covered entities or business 
associates under the HIPAA Privacy Rule and the Security Standards for 
the Protection of Electronic Protected Health Information \19\ [the 
Security Rule]). For instance, if a payer learns that a particular app 
has publicly known privacy or security vulnerabilities, they could 
inform patients who use that app to access their data of those known 
vulnerabilities. Per our policies finalized in the CMS Interoperability 
and Patient Access final rule, if a patient still wants to use the app, 
or does not respond to the payer's warning, the impacted payer is 
required to share their data via the API, absent an unacceptable 
security risk to the payer's own system. For more information on this 
ability to inform patients, see the CMS Interoperability and Patient 
Access final rule at 85 FR 25550. Again, the finalized policies in this 
rule do not affect or alter any obligations under the HIPAA Privacy and 
Security Rules.
---------------------------------------------------------------------------

    \19\ See also the HIPAA Security Rule, 45 CFR parts 160 and 164, 
subparts A and C.
---------------------------------------------------------------------------

    While FHIR itself does not define security-related functions, when 
used in combination with appropriate security controls (such as 
authentication and access control), a FHIR API can and should be 
implemented and maintained to comply with the HIPAA Security Rule, at 
45 CFR parts 160 and 164, subparts A and C, for secure data 
exchange.\20\ Furthermore, a covered entity is not liable for what 
happens to the PHI once the designated third party receives the 
information as directed by the individual.\21\
---------------------------------------------------------------------------

    \20\ Health Level Seven International (2022, May 28). HL7 FHIR 
Release 4. 6.1.0 FHIR Security. Retrieved from http://www.hl7.org/Fhir/security.html.
    \21\ Office for Civil Rights (2020, January 31). What is the 
liability of a covered entity in responding to an individual's 
access request to send the individual's PHI to a third party? 
Retrieved from https://www.hhs.gov/hipaa/for-professionals/faq/2039/what-is-the-liability-of-a-covered-entity-in-responding/index.html.
---------------------------------------------------------------------------

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

    \22\ See U.S. v. Easy Healthcare Corp., Case No. 1:23-cv-3107 
(N.D. Ill. 2023), https://www.ftc.gov/legal-library/browse/cases-proceedings/202-3186-easy-healthcare-corporation-us-v; In the Matter 
of BetterHelp, Inc., FTC Dkt. No. C-4796 (July 14, 2023), https://www.ftc.gov/legal-library/browse/cases-proceedings/2023169-betterhelp-inc-matter; U.S. v. GoodRx Holdings, Inc., Case No. 23-
cv-460 (N.D. Cal. 2023), https://www.ftc.gov/legal-library/browse/cases-proceedings/2023090-goodrx-holdings-inc; In the Matter of Flo 
Health Inc., FTC Dkt. No. C-4747 (June 22, 2021), https://www.ftc.gov/legal-library/browse/cases-proceedings/192-3133-flo-health-inc.
---------------------------------------------------------------------------

    The FTC also enforces the FTC Health Breach Notification Rule (16 
CFR part 318), which applies to most health apps and similar 
technologies that are not covered entities or business associates under 
HIPAA and, therefore, are not subject to the HIPAA Breach Notification 
Rule (45 CFR 164.400 through 164.414).\23\ The FTC's Health Breach 
Notification Rule sets forth steps that entities covered by that rule 
must follow when there has been a breach of unsecured personal health 
information. Any violation of the FTC's Health Breach Notification Rule 
is treated as an unfair or deceptive act or practice under section 18 
of the FTC Act and is subject to civil penalties of up to $50,120 per 
violation per day.\24\ In 2023, the Commission brought its first 
enforcement actions under the Health Breach Notification Rule.\25\
---------------------------------------------------------------------------

    \23\ Federal Trade Commission (January 2022). Complying with 
FTC's Health Breach Notification Rule. Retrieved from https://www.ftc.gov/tips-advice/business-center/guidance/complying-ftcs-health-breach-notification-rule. See also Federal Trade Commission 
(2021, September 15). Statement of the Commission on Breaches by 
Health Apps and Other Connected Devices. Retrieved from https://www.ftc.gov/system/files/documents/public_statements/1596364/statement_of_the_commission_on_breaches_by_health_apps_and_other_connected_devices.pdf.
    \24\ 16 CFR 1.98 makes inflation adjustments in the dollar 
amounts of civil monetary penalties provided by law within the 
Commission's jurisdiction.
    \25\ See U.S. v. Easy Healthcare Corp., Case No. 1:23-cv-3107 
(N.D. Ill. 2023), https://www.ftc.gov/legal-library/browse/cases-proceedings/202-3186-easy-healthcare-corporation-us-v; U.S. v. 
GoodRx Holdings, Inc., Case No. 23-cv-460 (N.D. Cal. 2023), https://www.ftc.gov/legal-library/browse/cases-proceedings/2023090-goodrx-holdings-inc.

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

[[Page 8779]]

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

[[Page 8780]]

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

[[Page 8781]]

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

[[Page 8782]]

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

[[Page 8783]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.000


[[Page 8784]]


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

[[Page 8785]]

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

[[Page 8786]]

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

[[Page 8787]]

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

B. Provider Access API

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

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

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

[[Page 8788]]

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

[[Page 8789]]

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

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

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

[[Page 8790]]

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

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

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

[[Page 8791]]

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

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

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

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

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

[[Page 8792]]

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

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

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

[[Page 8793]]

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

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

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

[[Page 8794]]

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

[[Page 8795]]

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

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

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

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

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

[[Page 8796]]

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

[[Page 8797]]

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

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

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

[[Page 8798]]

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

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

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

[[Page 8799]]

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

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

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

[[Page 8800]]

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

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

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

[[Page 8801]]

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

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

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

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

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

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

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

[[Page 8802]]

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

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

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

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

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

[[Page 8803]]

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

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

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

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

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

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

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

[[Page 8804]]

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

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

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

[[Page 8805]]

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

[[Page 8806]]

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

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

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

[[Page 8807]]

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

[[Page 8808]]

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

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

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

[[Page 8809]]

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

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

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

[[Page 8810]]

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

[[Page 8811]]

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

[[Page 8812]]

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

[[Page 8813]]

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

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

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

[[Page 8814]]

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

[[Page 8815]]

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

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

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

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

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

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

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

[[Page 8816]]

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


[[Page 8817]]


[GRAPHIC] [TIFF OMITTED] TR08FE24.002

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

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

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

[[Page 8818]]

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

[[Page 8819]]

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

[[Page 8820]]

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

C. Payer-to-Payer API

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

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

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

[[Page 8821]]

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

[[Page 8822]]

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

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

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

[[Page 8823]]

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

[[Page 8824]]

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

[[Page 8825]]

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

[[Page 8826]]

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

[[Page 8827]]

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

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

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

[[Page 8828]]

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

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

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

[[Page 8829]]

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

[[Page 8830]]

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

[[Page 8831]]

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

[[Page 8832]]

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

c. Identifying Previous and Concurrent Payers and Opt In

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

[[Page 8833]]

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

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

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

[[Page 8834]]

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

[[Page 8835]]

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

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

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

[[Page 8836]]

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

[[Page 8837]]

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

[[Page 8838]]

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

[[Page 8839]]

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

[[Page 8840]]

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

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

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

[[Page 8841]]

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

[[Page 8842]]

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

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

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

[[Page 8843]]

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

[[Page 8844]]

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

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

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

[[Page 8845]]

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

[[Page 8846]]

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

[[Page 8847]]

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

[[Page 8848]]

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

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

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

[[Page 8849]]

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

[[Page 8850]]

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

[[Page 8851]]

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

[[Page 8852]]

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

[[Page 8853]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.003


[[Page 8854]]


[GRAPHIC] [TIFF OMITTED] TR08FE24.004

BILLING CODE 4150-28-C

[[Page 8855]]

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

[[Page 8856]]

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

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

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

[[Page 8857]]

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

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

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

[[Page 8858]]

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

D. Prior Authorization API and Improving Prior Authorization Processes

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

[[Page 8859]]

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

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

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

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

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

[[Page 8860]]

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

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

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

[[Page 8861]]

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

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

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

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

    Comment: Many commenters supported the proposal to require impacted 
payers to implement and maintain a Prior Authorization API to improve 
automation of the prior authorization process. Many commenters stated 
that the API has the potential to support the needed transition to 
electronic prior authorization. Commenters also stated that the Prior 
Authorization API would

[[Page 8862]]

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

[[Page 8863]]

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

<bullet> The CRD IG
<bullet> The DTR IG
<bullet> The PAS IG

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

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

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

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

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

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

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

[[Page 8864]]

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

[[Page 8865]]

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

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

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

[[Page 8866]]

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

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

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

[[Page 8867]]

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

[[Page 8868]]

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

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

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

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

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

[[Page 8869]]

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

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

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

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

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

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

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

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

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

[[Page 8870]]

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

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

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

[[Page 8871]]

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

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

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

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

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

[[Page 8872]]

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

[[Page 8873]]

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

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

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

[[Page 8874]]

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

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

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

[[Page 8875]]

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

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

    <bullet> Use approved notice language in a readable and 
understandable form;
    <bullet> State the specific reasons for the denial;
    <bullet> Inform the enrollee of their right to a reconsideration;
    <bullet> 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
    <bullet> Comply with any other notice requirements specified by 
CMS.\122\
---------------------------------------------------------------------------

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

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

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

    <bullet> Inform the enrollee of their right to a reconsideration;
    <bullet> 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
    <bullet> Comply with any other requirements specified by CMS as to 
the content of the notice.\125\
---------------------------------------------------------------------------

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

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

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

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

[[Page 8876]]

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

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

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

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

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

[[Page 8877]]

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

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

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

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

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

[[Page 8878]]

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

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

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

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

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

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

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

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

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

[[Page 8879]]

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

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

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

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

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

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

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

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

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

[[Page 8880]]

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

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

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

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

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

[[Page 8881]]

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

[[Page 8882]]

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

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

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

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

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

[[Page 8883]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.005

BILLING CODE 4150-28-C

[[Page 8884]]

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

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

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

[[Page 8885]]

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

[[Page 8886]]

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

[[Page 8887]]

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

[[Page 8888]]

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


[[Page 8889]]


[GRAPHIC] [TIFF OMITTED] TR08FE24.007

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

[[Page 8890]]

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

[[Page 8891]]

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

[[Page 8892]]

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

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

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

[[Page 8893]]

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

[[Page 8894]]

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

[[Page 8895]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.008


[[Page 8896]]


[GRAPHIC] [TIFF OMITTED] TR08FE24.009

BILLING CODE 4150-28-C

[[Page 8897]]

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

[[Page 8898]]

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

[[Page 8899]]

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

[[Page 8900]]

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

[[Page 8901]]

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

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

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

[[Page 8902]]

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

[[Page 8903]]

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

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

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

[[Page 8904]]

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

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

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

[[Page 8905]]

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

[[Page 8906]]

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

[[Page 8907]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.010

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

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

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

[[Page 8908]]

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

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

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

[[Page 8909]]

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

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

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

[[Page 8910]]

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

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

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

[[Page 8911]]

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

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

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

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

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

[[Page 8912]]

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

[[Page 8913]]

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

[[Page 8914]]

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

[[Page 8915]]

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

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

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

    \162\ In the proposed rule, we used the term ``Prior 
Authorization Requirements, Documentation, and Decision API (PARDD 
API).'' For simplicity, we are finalizing the name of that API as 
simply the ``Prior Authorization API.''

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

[[Page 8916]]

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

[[Page 8917]]

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

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

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

[[Page 8918]]

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

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

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

[[Page 8919]]

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

[[Page 8920]]

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

[[Page 8921]]

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

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

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

[[Page 8922]]

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

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

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

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

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

[[Page 8923]]

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

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

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

[[Page 8924]]

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

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

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

[[Page 8925]]

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

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

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

[[Page 8926]]

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

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

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

[[Page 8927]]

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

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

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

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

G. Interoperability Standards for APIs

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

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

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

[[Page 8928]]

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

[[Page 8929]]

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

[[Page 8930]]

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

[[Page 8931]]

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

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

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

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

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

[[Page 8932]]

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

[[Page 8933]]

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

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

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

[[Page 8934]]

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

[[Page 8935]]

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

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

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

[[Page 8936]]

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

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

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

[[Page 8937]]

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

[[Page 8938]]

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

[[Page 8939]]

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

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

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

[[Page 8940]]

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

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

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

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

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

[[Page 8941]]

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

[[Page 8942]]

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

[[Page 8943]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.011


[[Page 8944]]


[GRAPHIC] [TIFF OMITTED] TR08FE24.012


[[Page 8945]]


[GRAPHIC] [TIFF OMITTED] TR08FE24.013

BILLING CODE 4150-01-C

[[Page 8946]]

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

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

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

III. Collection of Information Requirements

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

A. Background

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

B. Wage Estimates

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

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

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

[[Page 8947]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.014

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

C. Information Collection Requirements

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

[[Page 8948]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.015

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

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

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

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

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

[[Page 8949]]

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

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

[[Page 8950]]

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

[[Page 8951]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.017

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

[[Page 8952]]

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

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


[[Page 8953]]


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

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

[[Page 8954]]

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

[[Page 8955]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.021

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

[[Page 8956]]

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

D. Summary of Information Collection Burdens

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

[[Page 8957]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.022

BILLING CODE 4150-28-C

[[Page 8958]]

E. Conclusion

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

IV. Regulatory Impact Analysis

A. Statement of Need

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

B. Overall Impact

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

[[Page 8959]]

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

C. Regulatory Flexibility Act

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

[[Page 8960]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.023

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

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

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

[[Page 8961]]

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

D. Unfunded Mandates Reform Act and Executive Order 13132 Requirements

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

E. Regulatory Review Costs

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

[[Page 8962]]

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

F. Impact of Individual Proposals

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

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

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

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

[[Page 8963]]

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

G. Alternatives Considered

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

[[Page 8964]]

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

[[Page 8965]]

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

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

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

[[Page 8966]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.025

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

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

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

[[Page 8967]]

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

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

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


[[Page 8968]]


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

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

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

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

[[Page 8969]]

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

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

I. Summary of Costs to the Federal Government

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

[[Page 8970]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.029

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

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

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

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

[[Page 8971]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.031

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

[[Page 8972]]

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

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

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

[[Page 8973]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.032

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

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

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

J. Accounting Statement and Table

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


[[Page 8974]]


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

List of Subjects

42 CFR Part 422

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

42 CFR Part 431

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

42 CFR Part 435

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

42 CFR Part 438

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

42 CFR Part 440

    Grant programs--health, Medicaid.

42 CFR Part 457

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

45 CFR Part 156

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

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

TITLE 42--PUBLIC HEALTH

PART 422--MEDICARE ADVANTAGE PROGRAM

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

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


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


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

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

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


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

    (a) Application programming interface to support data exchange from

[[Page 8975]]

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

[[Page 8976]]

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

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


Sec.  422.122  Prior authorization requirements.

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

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


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

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

[[Page 8977]]

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


Sec.  422.570  [Amended]

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

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


Sec.  422.631  Integrated organization determinations.

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

PART 431--STATE ORGANIZATION AND GENERAL ADMINISTRATION

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

    Authority: 42 U.S.C. 1302.

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


Sec.  431.60  Beneficiary access to and exchange of data.

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

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


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

    (a) Application programming interface to support data exchange from 
payers to providers--Provider Access API. Beginning January 1, 2027, 
unless granted an extension or exemption under paragraph (c) of this 
section, a State must do the following:
    (1) API requirements. Implement and maintain an application 
programming interface (API) conformant with all of the following:
    (i) Section 431.60(c)(2) through (4), (d), and (e).
    (ii) The standards in 45 CFR 170.215(a)(1), (b)(1)(i), (c)(1), and 
(d)(1).
    (2) Provider access. Make the data specified in Sec.  431.60(b) 
with a date of

[[Page 8978]]

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

[[Page 8979]]

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

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


Sec.  431.80  Prior authorization requirements.

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

[[Page 8980]]

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

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


Sec.  431.201  Definitions.

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

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


Sec.  431.220  When a hearing is required.

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

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

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

    Authority:  42 U.S.C. 1302.

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


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

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

PART 438--MANAGED CARE

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

    Authority:  42 U.S.C. 1302.

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


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

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


Sec.  438.62  [Amended]

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

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

[[Page 8981]]

Sec.  438.210  Coverage and authorization of services.

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

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


Sec.  438.242  Health information systems.

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

PART 440--SERVICES: GENERAL PROVISIONS

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

    Authority: 42 U.S.C. 1302.

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


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

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

[[Page 8982]]

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

PART 457--ALLOTMENTS AND GRANTS TO STATES

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

    Authority:  42 U.S.C. 1302.

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


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

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

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


Sec.  457.700  Basis, scope, and applicability.

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

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


Sec.  457.730  Beneficiary access to and exchange of data.

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

[[Page 8983]]

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

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


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

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

[[Page 8984]]

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

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


Sec.  457.732  Prior authorization requirements.

    (a) Communicating a reason for denial. Beginning January 1, 2026, 
if the State denies a prior authorization request (excluding a request 
for coverage of drugs as defined in Sec.  457.730(b)(6)), in accordance 
with the timeframes established in Sec.  457.495(d), the response to 
the provider must include a specific reason for the denial, regardless 
of the method used to communicate that information.
    (b) Prior Authorization Application Programming Interface (API). 
Unless granted an extension or exemption under paragraph (d) of this 
section, beginning January 1, 2027, a State must implement and maintain 
an API conformant with Sec.  457.730(c)(2) through (4), (d), and (e), 
and the standards in 45 CFR 170.215(a)(1), (b)(1)(i), and (c)(1) that--
    (1) Is populated with the State's list of covered items and 
services (excluding

[[Page 8985]]

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

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


Sec.  457.1206  Non-emergency medical transportation PAHPs.

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

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


Sec.  457.1230  Access standards.

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

[[Page 8986]]

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

TITLE 45--Public Welfare

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

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

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

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


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

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

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


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

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

[[Page 8987]]

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

[[Page 8988]]

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

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


Sec.  156.223  Prior authorization requirements.

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

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


</pre><script data-cfasync="false" src="/cdn-cgi/scripts/5c5dd728/cloudflare-static/email-decode.min.js"></script></body>
</html>