Federal Register, Volume 89 Issue 27 (Thursday, February 8, 2024)

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

[[Page 8757]]

Vol. 89

Thursday,

No. 27

February 8, 2024

Part II

Department of Health and Human Services

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

Centers for Medicare & Medicaid Services

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

42 Parts 422, 431, 435, et al.

45 Part 156

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

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

[[Page 8758]]

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

DEPARTMENT OF HEALTH AND HUMAN SERVICES

Centers for Medicare & Medicaid Services

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

Office of the Secretary

45 CFR Part 156

[CMS-0057-F]
RIN 0938-AU87

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

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

ACTION: Final rule.

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

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

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

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

SUPPLEMENTARY INFORMATION:

Table of Contents

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

I. Background, Summary of Provisions, and Terms

A. Purpose and Background

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

[[Page 8759]]

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

B. Summary of Major Provisions

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

[[Page 8760]]

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

[[Page 8761]]

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

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

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

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

C. Specific Terms Used in This Final Rule

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

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

[[Page 8766]]

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

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

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

[[Page 8767]]

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

[[Page 8768]]

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

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

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

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

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

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

A. Patient Access API

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

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

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

[[Page 8769]]

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

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

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

[[Page 8770]]

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

[[Page 8771]]

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

[[Page 8772]]

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

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

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

[[Page 8773]]

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

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

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

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

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

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

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

[[Page 8774]]

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

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

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

[[Page 8775]]

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

[[Page 8776]]

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

[[Page 8777]]

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

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

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

[[Page 8778]]

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

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

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

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

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

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

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

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

[[Page 8780]]

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

[[Page 8781]]

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

[[Page 8782]]

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

[[Page 8783]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.000

[[Page 8784]]

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

[[Page 8785]]

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

[[Page 8786]]

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

[[Page 8787]]

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

B. Provider Access API

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

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

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

[[Page 8788]]

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

[[Page 8789]]

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

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

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

[[Page 8790]]

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

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

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

[[Page 8791]]

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

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

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

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

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

[[Page 8792]]

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

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

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

[[Page 8793]]

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

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

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

[[Page 8794]]

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

[[Page 8795]]

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

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

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

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

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

[[Page 8796]]

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

[[Page 8797]]

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

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

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

[[Page 8798]]

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

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

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

[[Page 8799]]

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

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

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

[[Page 8800]]

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

\46\ Under the HIPAA Rules at 45 CFR 160.103, a ``covered
entity'' includes a health care provider who transmits any health
information in electronic form in connection with a transaction
covered by the subchapter. See also definitions of health care
provider and transaction at https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-160/subpart-A/section-160.103.
\47\ 45 CFR parts 160 and 164, subparts A, C, and E. Department
of Health and Human Services (2022). Security Rule Guidance
Material. Retrieved from https://www.hhs.gov/hipaa/for-professionals/security/guidance/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--
Providing safeguards that restrict the use or disclosure
of information concerning applicants and beneficiaries to purposes
directly connected with the administration of the plan in accordance
with section 1902(a)(7) of the Act and 42 CFR 431.300 and 431.302; and
Not disclosing data to an outside source, such as
providers that are not enrolled with the state Medicaid or CHIP agency,
and that might be participating in an HIE, without prior permission
from the individual in accordance with 42 CFR 431.306(d).
iv. Opt Out Process Design
Comment: Commenters provided thoughts about the implementation of
the proposed opt out requirement. Multiple commenters suggested that
CMS require a standardized opt out process to improve the patient and
provider experience. A commenter expressed concern that the proposed
implementation flexibility could be difficult for patients to navigate,
while another commenter requested clarification on what opting out and
opting back in means.
Response: We agree that it is important to make it easy for
patients or their personal representatives to opt out of data sharing.
However, it is also important to give payers flexibility in how they
implement the opt out process required by this rule. We recognize that
payers' approaches may vary depending on their systems, capabilities,
and specific enrollee population. Requiring a specific process could
impose unnecessary burden on payers. We remind readers that regardless
of what process payers choose, a patient or their personal
representative must have the ability to change their data sharing
permission at any time. For example, if a patient or their personal
representative previously opted out of having their data shared under
the Provider Access API policy, they should be able to reverse this
decision, effectively choosing to opt back into having their data
shared under the Provider Access API policy. We additionally note that
each of our policies in this final rule is targeted toward individual
patients, not any family members that may be covered through the same
benefits. In some cases, applicable law may allow one individual (such
as a parent or guardian) to act as a personal representative for
another individual covered under the same benefits (such as a minor)
and could therefore opt out of data sharing under the Provider Access
API for that person. No data should be shared about any patient that
has opted out (or whose personal representative has opted out),
regardless of whether another patient covered under the same benefits
has chosen to not opt out. We will continue to monitor implementation
of the Provider Access API opt out requirement to ensure payers' opt
out processes for the Provider Access API are easy and intuitive for
patients or their personal representatives to use.
Comment: Commenters recommended that CMS include several
additional, explicit requirements related to the Provider Access API
opt out process. Multiple commenters also recommended requiring or
permitting payers to incorporate the opt out process into their
existing platforms and communications, including patient portals,
payers' websites, and within payers' regular communications with
patients. A commenter encouraged CMS to collaborate with interested
parties to develop a single platform for patients to give permission
for data sharing.
Response: While we are not requiring impacted payers to incorporate
their opt out processes into their existing platforms and
communications, we generally expect that that would result in the least
amount of burden on payers and patients. There are solutions available
that could be leveraged to manage permissions across payers, such as
HIEs. We encourage impacted payers to investigate a variety of options
to determine the solution that is best for them and their patients.
Comment: Multiple commenters made recommendations related to the
accessibility of the opt out process. They recommended that CMS require
impacted payers to provide options to patients for opting out of data
sharing that are accessible to patients with varied technological
literacy (that is, via mail, fax, and phone). A commenter recommended
that opt out information be available for the Provider Access API in
multiple languages to reduce disparities and barriers to patients'
understanding of the opt out process. Another commenter recommended
that CMS establish clear expectations for how payers should accommodate
patients who may have difficulty accessing the opt out process or that
CMS should track the extent to which patients encounter difficulties
with opting out of data sharing. A commenter further recommended that
payers collect patients' opt out elections at the point of treatment,
so that it is clear which provider(s) have access to the patient's data
via the Provider Access API policy.
Response: We agree with commenters that payers should make efforts
to

[[Page 8812]]

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

[[Page 8813]]

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

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

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

[[Page 8818]]

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

[[Page 8819]]

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

[[Page 8820]]

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

C. Payer-to-Payer API

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

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

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

[[Page 8821]]

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

[[Page 8822]]

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

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

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

[[Page 8823]]

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

[[Page 8824]]

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

[[Page 8825]]

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

[[Page 8826]]

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

[[Page 8827]]

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

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

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

[[Page 8828]]

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

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

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

[[Page 8829]]

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

[[Page 8830]]

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

[[Page 8831]]

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

[[Page 8832]]

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

c. Identifying Previous and Concurrent Payers and Opt In

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

[[Page 8833]]

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

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

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

[[Page 8834]]

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

[[Page 8835]]

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

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

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

[[Page 8836]]

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

[[Page 8837]]

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

[[Page 8838]]

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

[[Page 8839]]

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

[[Page 8840]]

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

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

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

[[Page 8841]]

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

[[Page 8842]]

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

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

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

[[Page 8843]]

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

[[Page 8844]]

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

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

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

[[Page 8845]]

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

[[Page 8846]]

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

[[Page 8847]]

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

[[Page 8848]]

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

\86\ Agency for Healthcare Research and Quality (2023, May).
Patient Education and Engagement. Retrieved from https://www.ahrq.gov/health-literacy/patient-education/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:
Providing safeguards that restrict the use or disclosure
of information concerning applicants and beneficiaries to purposes
directly connected with the administration of the plan in accordance
with section 1902(a)(7) of the Act and 42 CFR 431.300 and 431.302; and
Not disclosing data to an outside source, such as non-
Medicaid or non-CHIP payers with whom the HIE might exchange data,
without prior permission from the individual in accordance with 42 CFR
431.306(d).

[[Page 8851]]

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

[[Page 8852]]

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

[[Page 8853]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.003

[[Page 8854]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.004

BILLING CODE 4150-28-C

[[Page 8855]]

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

[[Page 8856]]

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

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

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

[[Page 8857]]

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

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

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

[[Page 8858]]

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

D. Prior Authorization API and Improving Prior Authorization Processes

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

[[Page 8859]]

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

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

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

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

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

[[Page 8860]]

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

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

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

[[Page 8861]]

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

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

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

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

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

[[Page 8862]]

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

[[Page 8863]]

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

The CRD IG
The DTR IG
The PAS IG

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

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

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

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

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

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

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

[[Page 8864]]

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

[[Page 8865]]

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

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

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

[[Page 8866]]

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

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

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

[[Page 8867]]

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

[[Page 8868]]

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

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

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

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

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

[[Page 8869]]

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

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

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

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

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

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

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

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

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

[[Page 8870]]

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

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

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

[[Page 8871]]

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

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

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

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

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

[[Page 8872]]

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

[[Page 8873]]

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

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

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

[[Page 8874]]

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

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

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

[[Page 8875]]

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

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

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

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

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

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

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

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

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

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

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

[[Page 8876]]

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

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

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

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

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

[[Page 8877]]

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

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

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

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

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

[[Page 8878]]

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

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

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

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

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

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

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

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

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

[[Page 8879]]

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

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

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

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

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

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

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

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

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

[[Page 8880]]

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

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

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

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

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

[[Page 8881]]

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

[[Page 8882]]

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

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

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

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

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

[[Page 8883]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.005

BILLING CODE 4150-28-C

[[Page 8884]]

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

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

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

[[Page 8885]]

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

[[Page 8886]]

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

[[Page 8887]]

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

[[Page 8888]]

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

[[Page 8889]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.007

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

[[Page 8890]]

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

[[Page 8891]]

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

[[Page 8892]]

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

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

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

[[Page 8893]]

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

[[Page 8894]]

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

[[Page 8895]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.008

[[Page 8896]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.009

BILLING CODE 4150-28-C

[[Page 8897]]

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

[[Page 8898]]

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

[[Page 8899]]

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

[[Page 8900]]

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

[[Page 8901]]

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

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

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

[[Page 8902]]

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

[[Page 8903]]

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

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

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

[[Page 8904]]

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

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

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

[[Page 8905]]

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

[[Page 8906]]

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

[[Page 8907]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.010

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

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

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

[[Page 8908]]

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

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

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

[[Page 8909]]

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

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

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

[[Page 8910]]

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

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

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

[[Page 8911]]

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

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

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

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

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

[[Page 8912]]

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

[[Page 8913]]

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

[[Page 8914]]

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

[[Page 8915]]

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

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

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

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

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

[[Page 8916]]

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

[[Page 8917]]

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

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

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

[[Page 8918]]

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

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

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

[[Page 8919]]

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

[[Page 8920]]

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

[[Page 8921]]

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

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

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

[[Page 8922]]

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

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

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

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

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

[[Page 8923]]

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

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

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

[[Page 8924]]

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

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

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

[[Page 8925]]

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

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

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

[[Page 8926]]

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

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

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

[[Page 8927]]

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

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

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

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

G. Interoperability Standards for APIs

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

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

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

[[Page 8928]]

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

[[Page 8929]]

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

[[Page 8930]]

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

[[Page 8931]]

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

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

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

\179\ Health Level Seven International (n.d.). Version
Management Policy. Retrieved from 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:
The need for information collection and its usefulness in
carrying out the proper functions of our agency.
The accuracy of our estimate of the information collection
burden.
The quality, utility, and clarity of the information to be
collected.
Recommendations to minimize the information collection
burden on the affected public, including automated collection
techniques.
We requested public comment on areas of this document that contain
information collection requirements (ICRs).

A. Background

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

B. Wage Estimates

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

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

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

[[Page 8947]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.014

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

C. Information Collection Requirements

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

[[Page 8948]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.015

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

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

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

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

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

[[Page 8949]]

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

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

[[Page 8950]]

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

[[Page 8951]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.017

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

[[Page 8952]]

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

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

[[Page 8953]]

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

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

[[Page 8954]]

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

[[Page 8955]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.021

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

[[Page 8956]]

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

D. Summary of Information Collection Burdens

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

[[Page 8957]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.022

BILLING CODE 4150-28-C

[[Page 8958]]

E. Conclusion

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

IV. Regulatory Impact Analysis

A. Statement of Need

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

B. Overall Impact

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

[[Page 8959]]

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

C. Regulatory Flexibility Act

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

[[Page 8960]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.023

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

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

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

[[Page 8961]]

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

D. Unfunded Mandates Reform Act and Executive Order 13132 Requirements

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

E. Regulatory Review Costs

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

[[Page 8962]]

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

F. Impact of Individual Proposals

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

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

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

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

[[Page 8963]]

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

G. Alternatives Considered

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

[[Page 8964]]

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

[[Page 8965]]

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

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

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

[[Page 8966]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.025

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

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

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

[[Page 8967]]

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

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

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

[[Page 8968]]

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

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

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

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

[[Page 8969]]

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

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

I. Summary of Costs to the Federal Government

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

[[Page 8970]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.029

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

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

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

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

[[Page 8971]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.031

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

[[Page 8972]]

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

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

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

[[Page 8973]]

[GRAPHIC] [TIFF OMITTED] TR08FE24.032

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

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

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

J. Accounting Statement and Table

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

[[Page 8974]]

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

List of Subjects

42 CFR Part 422

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

42 CFR Part 431

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

42 CFR Part 435

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

42 CFR Part 438

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

42 CFR Part 440

Grant programs--health, Medicaid.

42 CFR Part 457

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

45 CFR Part 156

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

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

TITLE 42--PUBLIC HEALTH

PART 422--MEDICARE ADVANTAGE PROGRAM

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

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

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

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

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

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

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

(a) Application programming interface to support data exchange from

[[Page 8975]]

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

[[Page 8976]]

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

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

Sec. 422.122 Prior authorization requirements.

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

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

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

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

[[Page 8977]]

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

Sec. 422.570 [Amended]

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

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

Sec. 422.631 Integrated organization determinations.

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

PART 431--STATE ORGANIZATION AND GENERAL ADMINISTRATION

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

Authority: 42 U.S.C. 1302.

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

Sec. 431.60 Beneficiary access to and exchange of data.

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

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

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

[[Page 8978]]

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

[[Page 8979]]

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

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

Sec. 431.80 Prior authorization requirements.

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

[[Page 8980]]

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

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

Sec. 431.201 Definitions.

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

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

Sec. 431.220 When a hearing is required.

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

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

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

Authority: 42 U.S.C. 1302.

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

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

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

PART 438--MANAGED CARE

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

Authority: 42 U.S.C. 1302.

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

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

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

Sec. 438.62 [Amended]

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

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

[[Page 8981]]

Sec. 438.210 Coverage and authorization of services.

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

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

Sec. 438.242 Health information systems.

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

PART 440--SERVICES: GENERAL PROVISIONS

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

Authority: 42 U.S.C. 1302.

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

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

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

[[Page 8982]]

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

PART 457--ALLOTMENTS AND GRANTS TO STATES

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

Authority: 42 U.S.C. 1302.

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

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

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

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

Sec. 457.700 Basis, scope, and applicability.

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

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

Sec. 457.730 Beneficiary access to and exchange of data.

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

[[Page 8983]]

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

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

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

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

[[Page 8984]]

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

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

Sec. 457.732 Prior authorization requirements.

[[Page 8985]]

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

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

Sec. 457.1206 Non-emergency medical transportation PAHPs.

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

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

Sec. 457.1230 Access standards.

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

[[Page 8986]]

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

TITLE 45--Public Welfare

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

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

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

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

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

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

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

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

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

[[Page 8987]]

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

[[Page 8988]]

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

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

Sec. 156.223 Prior authorization requirements.

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

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