Rule2024-00895
Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Advancing Interoperability and Improving Prior Authorization Processes for Medicare Advantage Organizations, Medicaid Managed Care Plans, State Medicaid Agencies, Children's Health Insurance Program (CHIP) Agencies and CHIP Managed Care Entities, Issuers of Qualified Health Plans on the Federally-Facilitated Exchanges, Merit-Based Incentive Payment System (MIPS) Eligible Clinicians, and Eligible Hospitals and Critical Access Hospitals in the Medicare Promoting Interoperability Program
Primary source
Metadata and text below are from the Federal Register, a public-domain U.S. government work. Always verify the official published version before relying on it for any legal matter.
Published
February 8, 2024
Effective
April 8, 2024
Issuing agencies
Health and Human Services DepartmentCenters for Medicare & Medicaid Services
Abstract
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.
Full Text
<html>
<head>
<title>Federal Register, Volume 89 Issue 27 (Thursday, February 8, 2024)</title>
</head>
<body><pre>
[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 [<a href="http://www.gpo.gov">www.gpo.gov</a>]
[FR Doc No: 2024-00895]
[[Page 8757]]
Vol. 89
Thursday,
No. 27
February 8, 2024
Part II
Department of Health and Human Services
-----------------------------------------------------------------------
Centers for Medicare & Medicaid Services
-----------------------------------------------------------------------
42 Parts 422, 431, 435, et al.
45 Part 156
Medicare and Medicaid Programs; Patient Protection and Affordable Care
Act; Advancing Interoperability and Improving Prior Authorization
Processes for Medicare Advantage Organizations, Medicaid Managed Care
Plans, State Medicaid Agencies, Children's Health Insurance Program
(CHIP) Agencies and CHIP Managed Care Entities, Issuers of Qualified
Health Plans on the Federally-Facilitated Exchanges, Merit-Based
Incentive Payment System (MIPS) Eligible Clinicians, and Eligible
Hospitals and Critical Access Hospitals in the Medicare Promoting
Interoperability Program; Final Rule
Federal Register / Vol. 89 , No. 27 / Thursday, February 8, 2024 /
Rules and Regulations
[[Page 8758]]
-----------------------------------------------------------------------
DEPARTMENT OF HEALTH AND HUMAN SERVICES
Centers for Medicare & Medicaid Services
42 CFR Parts 422, 431, 435, 438, 440, and 457
Office of the Secretary
45 CFR Part 156
[CMS-0057-F]
RIN 0938-AU87
Medicare and Medicaid Programs; Patient Protection and Affordable
Care Act; Advancing Interoperability and Improving Prior Authorization
Processes for Medicare Advantage Organizations, Medicaid Managed Care
Plans, State Medicaid Agencies, Children's Health Insurance Program
(CHIP) Agencies and CHIP Managed Care Entities, Issuers of Qualified
Health Plans on the Federally-Facilitated Exchanges, Merit-Based
Incentive Payment System (MIPS) Eligible Clinicians, and Eligible
Hospitals and Critical Access Hospitals in the Medicare Promoting
Interoperability Program
AGENCY: Centers for Medicare & Medicaid Services (CMS), Department of
Health and Human Services (HHS).
ACTION: Final rule.
-----------------------------------------------------------------------
SUMMARY: This final rule will improve the electronic exchange of health
care data and streamline processes related to prior authorization
through new requirements for Medicare Advantage (MA) organizations,
state Medicaid fee-for-service (FFS) programs, state Children's Health
Insurance Program (CHIP) FFS programs, Medicaid managed care plans,
CHIP managed care entities, and Qualified Health Plan (QHP) issuers on
the Federally-facilitated Exchanges (FFEs). This final rule will also
add new measures for eligible hospitals and critical access hospitals
(CAHs) to report under the Medicare Promoting Interoperability Program
and for MIPS eligible clinicians to report under the Promoting
Interoperability performance category of the Merit-based Incentive
Payment System (MIPS). These policies, taken together, will reduce
overall payer and provider burden and improve patient access to health
information while continuing CMS's drive toward interoperability in the
health care market.
DATES: These regulations are effective on April 8, 2024.
FOR FURTHER INFORMATION CONTACT:
Alexandra Mugge, (410) 786-4457, for general questions related to
any of the policies in this final rule, or questions related to CMS
interoperability initiatives.
Lorraine Doo, (443) 615-1309, for issues related to the prior
authorization process policies, or the Prior Authorization Application
Programming Interface (API).
Shanna Hartman, (410) 786-0092, for issues related to the Payer-to-
Payer API, the Electronic Prior Authorization measures for the MIPS
Promoting Interoperability performance category and Medicare Promoting
Interoperability Program, or any of the API standards and
implementation guides (IGs) included in this final rule.
David Koppel, (303) 844-2883, for issues related to the data
exchange policies generally, Patient Access API policies, or patient
privacy.
Scott Weinberg, (410) 786-6017, for issues related to the Provider
Access API policies.
Amy Gentile, (410) 786-3499, for issues related to Medicaid managed
care.
Kirsten Jensen, (410) 786-8146, for issues related to Medicaid FFS.
Joshua Bougie, (410) 786-8117, for issues related to CHIP.
Natalie Albright, (410) 786-1671, for issues related to MA
organizations.
Carolyn Kraemer, (301) 492-4197, for issues related to QHPs.
Elizabeth Holland, (410) 786-1309, for issues related to MIPS and
the Medicare Promoting Interoperability Program.
Russell Hendel, (410) 786-0329, for issues related to the
Collection of Information and Regulatory Impact Analysis.
SUPPLEMENTARY INFORMATION:
Table of Contents
I. Background and Summary of Provisions
A. Purpose and Background
B. Summary of Major Provisions
C. Specific Terms Used in This Final Rule
D. Global Comments
II. Provisions of the Proposed Rule
A. Patient Access API
B. Provider Access API
C. Payer-to-Payer API
D. Prior Authorization API and Improving Prior Authorization
Processes
E. Extensions, Exemptions, and Exceptions; Federal Matching
Funds for Medicaid and CHIP
F. Electronic Prior Authorization Measures for the Merit-Based
Incentive Payment System (MIPS) Promoting Interoperability
Performance Category and the Medicare Promoting Interoperability
Program
G. Interoperability Standards for APIs
III. Collection of Information Requirements
IV. Regulatory Impact Analysis
I. Background, Summary of Provisions, and Terms
A. Purpose and Background
In the December 13, 2022 Federal Register (87 FR 76238), we issued
the ``Medicare and Medicaid Programs; Patient Protection and Affordable
Care Act; Advancing Interoperability and Improving Prior Authorization
Processes for Medicare Advantage Organizations, Medicaid Managed Care
Plans, State Medicaid Agencies, Children's Health Insurance Program
(CHIP) Agencies and CHIP Managed Care Entities, Issuers of Qualified
Health Plans on the Federally-Facilitated Exchanges, Merit-Based
Incentive Payment System (MIPS) Eligible Clinicians, and Eligible
Hospitals and Critical Access Hospitals in the Medicare Promoting
Interoperability Program'' proposed rule (CMS Interoperability and
Prior Authorization proposed rule), in which we proposed new
requirements for MA, state Medicaid FFS programs, state CHIP FFS
programs, Medicaid managed care plans, CHIP managed care entities, and
QHP issuers on the FFEs (collectively ``impacted payers'') to improve
the electronic exchange of health care information and streamline prior
authorization for medical items and services. The proposed rule also
included proposals for new electronic prior authorization measures for
MIPS eligible clinicians (as defined at 42 CFR 414.1305) under the
Promoting Interoperability performance category of the MIPS, as well as
for eligible hospitals and CAHs under the Medicare Promoting
Interoperability Program.
This rule also builds upon the policies established in the
``Medicare and Medicaid Programs; Patient Protection and Affordable
Care Act; Interoperability and Patient Access for MA Organization and
Medicaid Managed Care Plans, State Medicaid Agencies, CHIP Agencies and
CHIP Managed Care Entities, Issuers of Qualified Health Plans on the
Federally-Facilitated Exchanges, and Health Care Providers'' final rule
(85 FR 25510, May 1, 2020) (hereinafter referred to as the ``CMS
Interoperability and Patient Access final rule'').
We received nearly 900 timely pieces of correspondence containing
comments on the CMS Interoperability and Prior Authorization proposed
rule. Some public comments were outside of the scope of the proposed
rule and those out-of-scope comments are not addressed in this final
rule. Summaries
[[Page 8759]]
of the public comments that are within the scope of the proposed rule
and our responses to those public comments are addressed in the various
sections of this final rule under the appropriate heading. However, in
this section we address certain comments that pertain across policies
or to the rule overall.
In this final rule, we are finalizing our proposals with
modifications in response to commenter feedback. Taken together, these
final policies will help to increase health information data exchange,
streamline prior authorization process policies, and help to address a
significant source of provider burden and burnout to ultimately improve
patients' access to timely care.
B. Summary of Major Provisions
In the CMS Interoperability and Patient Access final rule, we
required impacted payers (MA organizations, state Medicaid FFS
programs, state CHIP FFS programs, Medicaid managed care plans, CHIP
managed care entities, and QHP issuers on the FFEs) to implement and
maintain a standards-based Patient Access API. The Patient Access API
must allow patients, through the health apps of their choice, to easily
access their claims and encounter information as well as clinical data,
including laboratory results, provider remittances, and patient cost-
sharing pertaining to such claims, if maintained by the impacted payer
(85 FR 25558). In this final rule, we are finalizing our proposal to
require that impacted payers include information about certain prior
authorizations in the data that are available through the Patient
Access API. For those changes to the Patient Access API, we are
finalizing compliance dates in 2027 (by January 1, 2027, for MA
organizations and state Medicaid and CHIP FFS programs; by the rating
period beginning on or after January 1, 2027, for Medicaid managed care
plans and CHIP managed care entities; and for plan years beginning on
or after January 1, 2027, for QHP issuers on the FFEs). In addition,
starting January 1, 2026, we are requiring impacted payers to annually
report to CMS certain metrics about patient data requests made via the
Patient Access API. We are also finalizing our proposal to directly
reference the content standard at 45 CFR 170.213, so that the data
content requirement is automatically updated as HHS's Office of the
National Coordinator for Health Information Technology (ONC) adopts new
versions. As of this final rule's publication, the content standards
adopted at 45 CFR 170.213 are USCDI v1, which will expire on January 1,
2026, and USCDI v3.
To improve coordination of care across the care continuum and
movement toward value-based care, we are finalizing our proposal to
require impacted payers to implement and maintain a Provider Access API
that is consistent with the technical standards finalized in the CMS
Interoperability and Patient Access final rule (85 FR 25558), including
the Health Level Seven (HL7[supreg]) International Fast Healthcare
Interoperability Resources (FHIR[supreg]) Release 4.0.1 standard.
Providers can use that API to access current patient data from payers,
including adjudicated claims and encounter data (excluding provider
remittances and patient cost-sharing information), all data classes and
data elements included in a content standard at 45 CFR 170.213 (USCDI),
and prior authorization information. For the Provider Access API
policy, we are finalizing compliance dates in 2027 (by January 1, 2027,
for MA organizations and state Medicaid and CHIP FFS programs; by the
rating period beginning on or after January 1, 2027 for Medicaid
managed care plans and CHIP managed care entities; and for plan years
beginning on or after January 1, 2027 for QHP issuers on the FFEs).
We are finalizing, with modifications, our proposal to require
impacted payers to implement and maintain a Payer-to-Payer API to
exchange patient data when a patient moves between payers to ensure
continued access to their health data and support continuity of care
between payers. Specifically, the payer to payer data exchange will
include adjudicated claims and encounter data (excluding provider
remittances and patient cost-sharing information), all data classes and
data elements included in a content standard at 45 CFR 170.213 (USCDI),
and certain information about the patient's prior authorizations.
Impacted payers will be required to request data from a patient's
previous payer, with the patient's permission, no later than 1 week
from the start of coverage or at the patient's request. Impacted payers
will then be required to integrate any data they receive in response to
that request into the patient's record, which could facilitate care
continuity as patients move between payers. We are finalizing a policy
that payers will be required to exchange five years of patient data, as
opposed to the entire patient health record. Five years of data are
sufficient to support care continuity and continuation of prior
authorizations as necessary, as well as maintaining patient access to
their most recent data without significant burden to payers. In
addition, if a patient has two or more concurrent impacted payers, the
impacted payers will be required to exchange the patient's data at
least quarterly, to ensure that all impacted payers have a more
complete patient record. For the Payer-to-Payer API policy, we are
finalizing compliance dates in 2027 (by January 1, 2027, for MA
organizations and state Medicaid and CHIP FFS programs; by the rating
period beginning on or after January 1, 2027, for Medicaid managed care
plans and CHIP managed care entities; and for plan years beginning on
or after January 1, 2027, for QHP issuers on the FFEs).
To improve the patient experience and access to care, we are also
finalizing several new requirements for prior authorization processes
that will reduce burden on patients, providers, and payers. To
streamline the prior authorization process, we are requiring impacted
payers to implement and maintain a Prior Authorization API. In the
proposed rule, we used the term ``Prior Authorization Requirements,
Documentation, and Decision API (PARDD API).'' For simplicity, we are
finalizing the name of that API as simply the ``Prior Authorization
API.'' This name change alone does not indicate any changes to the
requirements or standards that we proposed.
Providers can use the Prior Authorization API to determine whether
a specific payer requires prior authorization for a certain item or
service, thereby easing one of the major points of administrative
burden in the existing prior authorization process. The Prior
Authorization API will also allow providers to query the payer's prior
authorization documentation requirements directly from the provider's
system, which could facilitate the automated compilation of necessary
information to submit a prior authorization request. For the Prior
Authorization API policy, we are finalizing compliance dates in 2027
(by January 1, 2027, for MA organizations and state Medicaid and CHIP
FFS programs; by the rating period beginning on or after January 1,
2027, for Medicaid managed care plans and CHIP managed care entities;
and for plan years beginning on or after January 1, 2027, for QHP
issuers on the FFEs).
We are also finalizing our proposals to establish certain
requirements for the prior authorization process, regardless of whether
the payer receives the prior authorization request through the Prior
Authorization API. We are requiring that impacted payers send notices
to providers when they make a prior authorization decision, including a
[[Page 8760]]
specific reason for denial when they deny a prior authorization
request. We are also finalizing our proposal to require impacted
payers, except for QHP issuers on the FFEs, to respond to prior
authorization requests within certain timeframes. Finally, we are
requiring all impacted payers to publicly report certain metrics about
their prior authorization processes, which will enhance transparency.
For these prior authorization process policies, we are finalizing
compliance dates in 2026 (by January 1, 2026, for MA organizations and
state Medicaid and CHIP FFS programs; by the rating period beginning on
or after January 1, 2026, for Medicaid managed care plans and CHIP
managed care entities; and for plan years beginning on or after January
1, 2026, for QHP issuers on the FFEs).
We are finalizing, with modifications, our proposal for new
electronic prior authorization measures for MIPS eligible clinicians
under the MIPS Promoting Interoperability performance category and for
eligible hospitals and CAHs under the Medicare Promoting
Interoperability Program. To promote Prior Authorization API adoption,
implementation, and use among MIPS eligible clinicians, eligible
hospitals, and CAHs, we are adding new measures titled ``Electronic
Prior Authorization'' under the Health Information Exchange (HIE)
objective in the MIPS Promoting Interoperability performance category
and the Medicare Promoting Interoperability Program, beginning with the
calendar year (CY) 2027 performance period/2029 MIPS payment year and
CY 2027 electronic health record (EHR) reporting period, respectively.
As detailed in section II.F. of this final rule, we are finalizing a
modification to our proposal for the Electronic Prior Authorization
measure that will require a MIPS eligible clinician, eligible hospital,
or CAH to report a yes/no attestation or (if applicable) an exclusion,
rather than a numerator and denominator.
We are additionally finalizing our proposals, with modifications,
for more specificity as to which of the required standards at 45 CFR
170.215 are applicable to each API. Impacted payers will only be
required to use the specifications that CMS has identified as necessary
for the Patient Access, Provider Access, Provider Directory, Payer-to-
Payer, and Prior Authorization APIs. Since the publication of the CMS
Interoperability and Prior Authorization proposed rule, ONC has
published the Health Data, Technology, and Interoperability:
Certification Program Updates, Algorithm Transparency, and Information
Sharing (HTI-1) final rule (January 9, 2024; 89 FR 1192) (hereinafter
referred to as the HTI-1 final rule), which reorganized the structure
of 45 CFR 170.215 to delineate the purpose and scope more clearly for
each type of standard or implementation specification. The standards we
are finalizing in this rule, including updated citations are as
follows:
<bullet> Health Level Seven (HL7[supreg]) Fast Healthcare
Interoperability Resources (FHIR[supreg]) Release 4.0.1 at 45 CFR
170.215(a)(1) (HL7 FHIR).
<bullet> HL7[supreg] FHIR[supreg] US Core Implementation Guide (IG)
Standard for Trial Use (STU) 3.1.1, which expires on January 1, 2026,
at 45 CFR 170.215(b)(1)(i) (US Core IG).
<bullet> HL7[supreg] SMART Application Launch Framework IG Release
1.0.0 which expires on January 1, 2026, at 45 CFR 170.215(c)(1) (SMART
App Launch IG).
<bullet> FHIR[supreg] Bulk Data Access (Flat FHIR) IG v1.0.0: STU 1
at 45 CFR 170.215(d)(1) (Bulk Data Access IG).
<bullet> OpenID Connect Core 1.0, incorporating errata set 1 at 45
CFR 170.215(e)(1) (OpenID Connect Core).
We refer readers to the HTI-1 final rule for further information
(89 FR 1192). More detail about the required standards can be found in
section II.G. and Table H3. We are also strongly recommending that
payers use specific IGs to supplement the required standards at 45 CFR
170.215. Additionally, we are finalizing our proposal to allow payers
to voluntarily use updated versions of the standards, specifications,
or IGs for each of these APIs prior to the adoption of updated versions
in regulation, subject to certain conditions and provided the updated
standard does not disrupt an end user's ability to access the data
available through the API. We are also finalizing terminology changes
related to the Patient Access API (in section II.A.2.d. of this final
rule). These policies will take effect on the effective date of the
final rule.
We are finalizing, as proposed, some clarifications to existing
Medicaid beneficiary notice and fair hearing regulations that apply to
Medicaid prior authorization decisions. Because these are
clarifications and improvements to existing regulations, as we
proposed, Medicaid agencies will have to comply with these policies
upon the effective date of a final rule.
In our proposed rule, we proposed compliance dates in 2026 (by
January 1, 2026, for MA organizations and state Medicaid and CHIP FFS
programs; by the rating period beginning on or after January 1, 2026,
for Medicaid managed care plans and CHIP managed care entities; and for
plan years beginning on or after January 1, 2026, for QHP issuers on
the FFEs), for all policies that require API development and
enhancement. Based on commenter feedback and as noted previously, we
are delaying the compliance dates in this final rule for the provisions
that require API development and enhancement in 2027 (by January 1,
2027, for MA organizations and state Medicaid and CHIP FFS programs; by
the rating period beginning on or after January 1, 2027, for Medicaid
managed care plans and CHIP managed care entities; and for plan years
beginning on or after January 1, 2027, for QHP issuers on the FFEs).
Throughout this rule, we generally refer to these compliance dates as
``in 2027'' for the various payers.
We believe this approximately 3-year timeline to recruit and train
staff, update, or build the APIs, and update operational procedures
will be sufficient to implement these policies, based on comments and
public information from some payers and providers regarding similar
initiatives already in progress. In addition to the 3-year
implementation timeframe, we are finalizing our proposal to give state
Medicaid and CHIP FFS programs an opportunity to seek an extension to
the compliance dates, or an exemption from meeting certain
requirements, in certain circumstances. Additionally, we are finalizing
our proposal to provide an exceptions process for QHP issuers on the
FFEs. We believe the approximately 3-year timeframe for implementation
in the final rule will offer sufficient time for state Medicaid and
CHIP FFS programs and QHP issuers on the FFEs to determine whether they
can timely satisfy the API development and enhancement requirements in
this final rule and to prepare the necessary documentation to request
an extension, exemption, or exception, as applicable.
Executive Order 13985 of January 20, 2021, entitled ``Advancing
Racial Equity and Support for Underserved Communities Through the
Federal Government,'' set administration policy that the ``Federal
Government should pursue a comprehensive approach to advancing equity
for all.'' \1\ CMS is committed to pursuing a comprehensive approach to
advancing health equity for all, and the policies in this final rule
are aligned with that Executive order because they represent efforts to
mitigate existing inefficiencies in policies, processes, and technology
that affect many patient populations. Some patient populations are more
negatively affected by existing processes than
[[Page 8761]]
others and should realize greater benefits through the improvements
these policies will provide. One of the main components of this final
rule is our continued support for the individual's ability to select an
app of their choice when accessing their health information. We want to
ensure that members of all communities can access their health
information and benefit from this technology. However, we are
interested in the best ways to ensure that apps are available and
accessible for individuals with disabilities, individuals with limited
English proficiency, individuals with low literacy or low health
literacy, and individuals with geographic, economic, or other social
risk factors that may create barriers to accessing or using technology
and apps.
---------------------------------------------------------------------------
\1\ Executive Order 13985, sec. 1, 86 FR 7009 (January 20,
2021).
---------------------------------------------------------------------------
Our goal is to ensure that these proposed policies do not
exacerbate current disparities or create unintended inequities that
leave some communities or populations unable to benefit from this
information sharing. Further, we seek to ensure that patient privacy
considerations are built into the implementation of these proposed
policies by using secure technologies, such as Open Authorization/Open
ID (OAuth) 2.0 and OpenID Connect Core for authentication,\2\ as
previously discussed in the CMS Interoperability and Patient Access
final rule (85 FR 25520). While we proposed policies that we believed
would address some health care inequities, we solicited comments about
how to ensure that individuals from all communities and populations can
actively benefit from our health care interoperability proposals.
---------------------------------------------------------------------------
\2\ Health Level Seven International. Smart App Launch
Implementation Guide, OpenID and Authentication for Smart Apps.
Retrieved from <a href="https://hl7.org/fhir/smart-app-launch/">https://hl7.org/fhir/smart-app-launch/</a>.
---------------------------------------------------------------------------
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
<a href="http://HealthCare.gov">HealthCare.gov</a>. 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 <a href="https://www.hhs.gov/hipaa/for-professionals/faq/2069/under-hipaa-when-can-a-family-member/index.html">https://www.hhs.gov/hipaa/for-professionals/faq/2069/under-hipaa-when-can-a-family-member/index.html</a> and <a href="https://www.hhs.gov/hipaa/for-professionals/faq/personal-representatives-and-minors/index.html">https://www.hhs.gov/hipaa/for-professionals/faq/personal-representatives-and-minors/index.html</a>.
---------------------------------------------------------------------------
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 <a href="https://www.healthit.gov/api-education-module/story_html5.html">https://www.healthit.gov/api-education-module/story_html5.html</a>.
---------------------------------------------------------------------------
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 <a href="http://www.HL7.org">www.HL7.org</a>.\6\
---------------------------------------------------------------------------
\6\ Health Level Seven International (2023). Guide to Using HL7
Trademarks. Retrieved from <a href="http://www.hl7.org/legal/trademarks.cfm?ref=nav">http://www.hl7.org/legal/trademarks.cfm?ref=nav</a>.
---------------------------------------------------------------------------
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 <a href="https://www.medicare.gov/my/medicare-complaint">https://www.medicare.gov/my/medicare-complaint</a>. The State Health Insurance Assistance Programs (SHIP) are
available to help Medicare beneficiaries, including with filing
complaints.
When states use enhanced funding for expenditures related to system
modifications or enhancements, CMS's enforcement is based upon 45 CFR
95.612 (Disallowance of FFP) and the methodology described in the
Centers for Medicaid and CHIP Services (CMCS) Informational Bulletin
(CIB), ``Medicaid Enterprise Systems Compliance and Reapproval Process
for State Systems with Operational Costs Claimed at the 75 Percent
Federal Match Rate,'' published May 24, 2023. If a state is not
compliant with the requirements included in this final rule, the
appropriate program policy team will address compliance enforcement.
States are obligated by 42 CFR 438.66(b) and (c) to have a
monitoring system for all of their managed care programs, including the
performance of
[[Page 8765]]
each managed care plan, to ensure that all managed care plans are
fulfilling their contractual obligations. States report the results of
their monitoring activities in an annual Managed Care Program Annual
Report, in accordance with 42 CFR 438.66(e). Further, per 42 CFR
438.3(a), CMS must review and approve all managed care plan contracts.
Should information in a state's Managed Care Program Annual Report or
contract indicate a need for improvement or correction, CMS would work
with the state to ensure that the issue is remedied. Patients or
providers with concerns regarding Medicaid or CHIP FFS should contact
their state Medicaid or CHIP agency. Patients and providers can contact
<a href="/cdn-cgi/l/email-protection#3a065b1a52485f5c07" http: Medicaid.gov">Medicaid.gov</a>@cms.hhs.gov"><a href="http://Medicaid.gov">Medicaid.gov</a>@cms.hhs.gov</a> if the state agency is not responsive.
For any concerns related to compliance by Medicaid managed care
plans and CHIP managed care entities, enrollees and providers should
first contact their managed care plan or managed care entity. Enrollees
or providers can contact the state Medicaid or CHIP agency to report
issues that they cannot resolve by working with the managed care plan
or entity directly.
Consistent with the authority under 45 CFR 156.715, the Center for
Consumer Information and Insurance Oversight (CCIIO) performs
compliance reviews of issuers in the FFEs. In addition, 45 CFR 156.800
through 156.815 provides for additional enforcement remedies including
Civil Money Penalties (CMPs) and Notices of Non-Compliance (NONCs) as
well as paths to QHP issuer Suppression and Decertification. If
enrollees in a QHP on the FFEs or their providers have concerns about
an issuer's interoperability implementation, they should first contact
their health plan with questions. For issues that they cannot resolve
by working directly with the plan, enrollees and providers can contact
the Marketplace Call Center at 1-800-318-2596 (TTY: 1-855-889-4325).
CMS manages compliance with the HIPAA administrative transaction
standards under the authority of the administrative simplification
rules. Complaints about non-compliance can be submitted to CMS at
<a href="https://asett.cms.gov/ASETT_HomePage">https://asett.cms.gov/ASETT_HomePage</a>.
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 <a href="https://build.fhir.org/ig/HL7/davinci-pas/usecases.html#scope-of-work-flow">https://build.fhir.org/ig/HL7/davinci-pas/usecases.html#scope-of-work-flow</a>.
---------------------------------------------------------------------------
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 <a href="https://build.fhir.org/ig/HL7/fhir-us-ndh/">https://build.fhir.org/ig/HL7/fhir-us-ndh/</a>.
---------------------------------------------------------------------------
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 <a href="https://www.healthit.gov/topic/interoperability/policy/trusted-exchange-framework-and-common-agreement-tefca">https://www.healthit.gov/topic/interoperability/policy/trusted-exchange-framework-and-common-agreement-tefca</a>.
---------------------------------------------------------------------------
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 <a href="https://www.healthit.gov/topic/standards-version-advancement-process-svap">https://www.healthit.gov/topic/standards-version-advancement-process-svap</a>.
---------------------------------------------------------------------------
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 <a href="https://x12.org/codes/service-review-decision-reason-codes">https://x12.org/codes/service-review-decision-reason-codes</a>.
---------------------------------------------------------------------------
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 <a href="https://hl7.org/fhir/us/davinci-cdex/">https://hl7.org/fhir/us/davinci-cdex/</a>.
---------------------------------------------------------------------------
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
<a href="https://www.healthit.gov/topic/information-blocking">https://www.healthit.gov/topic/information-blocking</a>.
---------------------------------------------------------------------------
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: <a href="https://www.healthit.gov/topic/information-blocking">https://www.healthit.gov/topic/information-blocking</a>.
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 <a href="http://www.hl7.org/Fhir/security.html">http://www.hl7.org/Fhir/security.html</a>.
\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 <a href="https://www.hhs.gov/hipaa/for-professionals/faq/2039/what-is-the-liability-of-a-covered-entity-in-responding/index.html">https://www.hhs.gov/hipaa/for-professionals/faq/2039/what-is-the-liability-of-a-covered-entity-in-responding/index.html</a>.
---------------------------------------------------------------------------
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 <a href="https://www.ftc.gov/business-guidance/resources/mobile-health-apps-interactive-tool">https://www.ftc.gov/business-guidance/resources/mobile-health-apps-interactive-tool</a>.
---------------------------------------------------------------------------
\22\ See U.S. v. Easy Healthcare Corp., Case No. 1:23-cv-3107
(N.D. Ill. 2023), <a href="https://www.ftc.gov/legal-library/browse/cases-proceedings/202-3186-easy-healthcare-corporation-us-v">https://www.ftc.gov/legal-library/browse/cases-proceedings/202-3186-easy-healthcare-corporation-us-v</a>; In the Matter
of BetterHelp, Inc., FTC Dkt. No. C-4796 (July 14, 2023), <a href="https://www.ftc.gov/legal-library/browse/cases-proceedings/2023169-betterhelp-inc-matter">https://www.ftc.gov/legal-library/browse/cases-proceedings/2023169-betterhelp-inc-matter</a>; U.S. v. GoodRx Holdings, Inc., Case No. 23-
cv-460 (N.D. Cal. 2023), <a href="https://www.ftc.gov/legal-library/browse/cases-proceedings/2023090-goodrx-holdings-inc">https://www.ftc.gov/legal-library/browse/cases-proceedings/2023090-goodrx-holdings-inc</a>; In the Matter of Flo
Health Inc., FTC Dkt. No. C-4747 (June 22, 2021), <a href="https://www.ftc.gov/legal-library/browse/cases-proceedings/192-3133-flo-health-inc">https://www.ftc.gov/legal-library/browse/cases-proceedings/192-3133-flo-health-inc</a>.
---------------------------------------------------------------------------
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 <a href="https://www.ftc.gov/tips-advice/business-center/guidance/complying-ftcs-health-breach-notification-rule">https://www.ftc.gov/tips-advice/business-center/guidance/complying-ftcs-health-breach-notification-rule</a>. See also Federal Trade Commission
(2021, September 15). Statement of the Commission on Breaches by
Health Apps and Other Connected Devices. Retrieved from <a href="https://www.ftc.gov/system/files/documents/public_statements/1596364/statement_of_the_commission_on_breaches_by_health_apps_and_other_connected_devices.pdf">https://www.ftc.gov/system/files/documents/public_statements/1596364/statement_of_the_commission_on_breaches_by_health_apps_and_other_connected_devices.pdf</a>.
\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), <a href="https://www.ftc.gov/legal-library/browse/cases-proceedings/202-3186-easy-healthcare-corporation-us-v">https://www.ftc.gov/legal-library/browse/cases-proceedings/202-3186-easy-healthcare-corporation-us-v</a>; U.S. v.
GoodRx Holdings, Inc., Case No. 23-cv-460 (N.D. Cal. 2023), <a href="https://www.ftc.gov/legal-library/browse/cases-proceedings/2023090-goodrx-holdings-inc">https://www.ftc.gov/legal-library/browse/cases-proceedings/2023090-goodrx-holdings-inc</a>.
---------------------------------------------------------------------------
[[Page 8779]]
c. Patient Access API Metrics
We proposed to require impacted payers to report metrics to CMS on
an annual basis about how patients use the Patient Access API, in the
form of aggregated, de-identified data. We stated that those reports
would help CMS better understand whether the Patient Access API
requirement is efficiently and effectively ensuring that patients have
access to their health information and whether payers are providing
that required information in a transparent and timely way.
Additionally, we stated that aggregated usage data from every impacted
payer would help us evaluate whether the Patient Access API policies
are achieving the desired goals. We also stated that gathering this
information would help us to provide targeted support or guidance to
impacted payers, if needed, to help ensure that patients have access to
their data and can use their data consistently across the impacted
payer types.
Specifically, we proposed that impacted payers annually report--
<bullet> The total number of unique patients whose data are
transferred via the Patient Access API to a health app designated by
the patient; and
<bullet> The total number of unique patients whose data are
transferred more than once via the Patient Access API to a health app
designated by the patient.
Tracking multiple data transfers would indicate repeat access,
showing that patients are either using multiple apps or allowing apps
to update their information over the course of the year. While data
transfers may not indicate to what extent patients are using apps to
manage their health care, it would be a preliminary indicator of
interest in the technology.
Comment: A majority of commenters supported CMS's proposal to
require impacted payers to report aggregated, de-identified data
metrics on how patients use the Patient Access API to CMS annually.
Response: We thank commenters for their feedback.
Comment: Commenters recommended that these metrics only be used to
evaluate the effectiveness of CMS's policies and to assess whether
patients are using the Patient Access API in a volume sufficient to
justify the administrative burden of existing and future requirements.
A commenter stated that these metrics would not reflect factors within
a payer's control and recommended that CMS work with FTC to have third-
party app developers directly report these metrics. Another commenter
warned that these metrics may not account for patient preferences for
portals or other resources aside from apps. A commenter recommended
that neither CMS nor state Medicaid agencies attempt to regulate or
oversee the usage of third-party apps by their users. Another commenter
supported the annual public reporting of Patient Access API metrics
provided that this information is not made publicly available in a
manner that identifies specific payers or apps.
Response: We acknowledge that patient app usage is generally
outside the control of payers, though education can help patients make
informed decisions. We emphasize that we proposed and will be
collecting these metrics, not to evaluate or compare payers, but to
help us understand how patients are using apps, the effectiveness of
our Patient Access API policies, and to assess potential future
rulemaking.
Making data available via a FHIR API gives patients a wider range
of options to access their data. Ultimately, patients must decide what
method of accessing their health information is most useful to them. If
patients prefer to use online portals, rather than apps, that could
inform future rulemaking. However, to understand how patients are
accessing data made available through the API using a heath app
designated by the patient, we must have access to the relevant data. We
do not intend to interfere with how a patient uses a third-party app
(and neither should impacted payers, including state Medicaid
agencies), but to provide them options to access their data in the way
that best suits them. As discussed previously, the only permissible
reason to deny or discontinue an app's access to an API is if the payer
reasonably determines that the app presents an unacceptable level of
risk to the security of PHI on the payer's systems.
We do not have the authority to require app developers to report
usage metrics, and even if we did collect data from them, it would not
provide the information that we are seeking, as developers would not
know a patient's health coverage status. For instance, a developer
could tell us that an individual connected to a specific payer
organization but would not be able to report whether the patient is
covered under by an MA plan or QHP. Finally, as noted in the proposed
rule, we do not intend to publicly publish these Patient Access metrics
in a way that identifies specific payers or apps.
Comment: A few commenters suggested that CMS establish an easy-to-
use standardized format for reporting Patient Access API metrics.
Response: We appreciate the request from commenters and are
finalizing a modification to our proposed regulatory text to require
reporting in a specified form and manner to ensure consistency between
impacted payers. We will issue specific format and process guidance for
submitting Patient Access API metrics before reporting is required.
Comment: Most commenters supported CMS's proposed metrics, as they
could provide valuable information regarding Patient Access API
adoption and use.
Commenters voiced widespread support for the first metric to
measure usage of the Patient Access API. Support for the second metric
was mixed, with multiple commenters questioning its value to the API's
policy evaluation. Commenters warned that this metric would be affected
by many external factors, including the user experience of the app, as
opposed to acts of the payer. Another commenter stated that the second
measure would not provide meaningful insight into patient use patterns,
and instead suggested that CMS should solicit information about usage
patterns from app developers.
Response: We understand that the metric on repeat usage may not
provide a high level of statistical validity, which is why we are not
requiring these metrics to be reported publicly. However, it is
important for CMS to understand how many patients are using the Patient
Access API and whether they have simply tried it once or are invested
in using health apps to manage their data. These findings will help us
monitor our interoperability policies and plan for the future. We did
not receive any comments that indicated that submitting either of these
metrics would be a significant burden for impacted payers.
We acknowledge that these metrics could be affected by a plethora
of external factors outside of payers' control. As noted previously, we
are collecting these metrics to better enable us to evaluate our
policies in this area. As we do not have regulatory authority over app
developers, we did not propose to impose reporting requirements on
them.
Comment: A commenter requested that CMS explain what constitutes a
``unique patient'' so that payers can identify unique patients in the
same manner, so the results are not varied.
Response: We define a unique patient by the record of the
individual covered by the payer's benefits, not by the individual
accessing the data. Therefore, if both a patient and their personal
representative access their data, that will only be counted as usage by
a
[[Page 8780]]
single patient for the purpose of these metrics.
i. Reporting Level
We proposed to require MA organizations to report these data to CMS
at the organization level, state Medicaid and CHIP FFS programs,
Medicaid managed care plans, and CHIP managed care entities to report
at the state level, and QHP issuers on the FFEs to report at the issuer
level. We solicited comment on whether we should require payers that
administer multiple plans under a single contract to report these data
to CMS at the contract level. We also solicited comment on an
alternative final policy that would permit MA organizations, Medicaid
managed care plans, CHIP managed care entities, and QHP issuers on the
FFEs to report aggregate data at higher levels (such as the parent
organization level or all plans of the same type in a program).
Comment: We received comments espousing a range of opinions on the
appropriate level of reporting for impacted payers.
Specifically for MA organizations, multiple commenters recommended
a more granular metric reporting level, noting that reporting Patient
Access API metrics at the plan level would better drive plan-specific
improvement efforts and be more consistent with current industry
practice. Conversely, a commenter stated that organization level would
simplify report preparation since some MA organizations have ten or
more separate plan contracts with CMS. A commenter recommended that CMS
not require reporting at the more granular contract level as any
metrics based on small populations could lead to skewed data.
Many commenters supported our proposed reporting levels for Patient
Access API use metrics for state Medicaid and CHIP FFS programs,
Medicaid managed care plans, CHIP managed care entities, and QHP
issuers on the FFEs.
On the other hand, a commenter recommended that payers be required
to report metrics at the county level, rather than the state level.
Another commenter warned that too much aggregation can make data
meaningless and stated that payers should prioritize data metrics that
can be acted upon effectively. Conversely, a commenter recommended that
CMS allow consolidation of Patient Access API use metrics at the
holding or parent company level, which would aggregate that company's
MA plans, Medicaid managed care plans, CHIP managed care entities,
QHPs, and commercial plans. Another commenter suggested that CMS begin
collecting metrics at a more aggregated level and wait to implement
more refined data segmentation as a clear use case arises.
Response: Upon further consideration, we determined that contract
level is the more appropriate reporting level for MA organizations.
Contract-level data are aggregated data that are collected from the
plan benefit packages (PBPs) offered under an individual contract; it
is specific to the contract to which it corresponds. CMS already
requires MA organizations to annually report some contract-level data
about their organization determinations to the agency. A consistent
approach of contract-level reporting in the MA program will give us
useful information while limiting payer burden. By requiring contract-
level reporting for these metrics, we ensure that the format of these
reported data remain consistent with other data that MA organizations
are required to report. There could be value to requiring MA
organizations to report on a plan level in the future to get more
discrete data. However, at this time, we believe that the burden of
requiring MA organizations to report at the plan level, and the small
sample sizes that some plans would have, outweigh the benefits of that
information.
We agree that requiring Medicaid managed care plans and CHIP
managed care entities to report at the state level and QHP issuers on
the FFEs to report at the issuer level balances the reporting burden
and the meaningfulness of the data. Aggregating by holding company
would provide data that are not particularly useful. Many commenters
recommended that we use this information to monitor disparities in data
access, which would be hindered without disaggregation between MA,
Medicaid, CHIP, and QHPs. Similarly, we do not believe that
additionally segmenting data into smaller geographic areas would
provide useful information now, though in the future we may consider
whether it would be beneficial.
We note that CMS programs may assess whether to collect more
detailed metrics than we are finalizing here. For instance, we may
consider requiring in future rulemaking that MA plans report at a more
discrete level. Similarly, should a state Medicaid or CHIP agency
believe it would be beneficial, they may require additional metrics in
their managed care contracts.
Comment: A few commenters requested that we explain whether
integrated care plans for dually eligible individuals, such as fully
integrated dual eligible special needs plans (FIDE SNPs), should report
consistent with MA organizations, at the contract level, or with
Medicaid managed care plans, at the plan level.
Response: An integrated care plan generally combines a dual
eligible special needs plan (D-SNP), which includes FIDE SNPs and
highly integrated dual eligible special needs plans (HIDE SNPs)--both
as defined at 42 CFR 422.2, and a Medicaid managed care plan offered by
the same parent organization. D-SNPs are a type of MA plan designed to
meet the needs of individuals who are dually eligible for Medicare and
Medicaid, also known as dually eligible individuals. Therefore, an MA
organization will report information about Patient Access API usage by
its D-SNP enrollees to CMS at the MA organization's contract level. The
affiliated Medicaid managed care plan will report information about
Patient Access API usage by its enrollees to CMS at the plan level.
We understand that this means an organization that offers an
integrated product for dually eligible individuals (for example, a FIDE
SNP), may report twice and in different ways for the same population.
We do not believe this duplication outweighs the benefits of capturing
the data as we proposed, but we may consider future rulemaking to
separate reporting for integrated D-SNPs from the overall MA
organization.
ii. Annual Reporting
We proposed that payers must report metrics from the previous
calendar year to CMS by March 31st of each year. Under our proposal, in
the first year the requirement would be applicable, payers would report
CY 2025 data by March 31, 2026. A new MA organization, Medicaid managed
care plan, CHIP managed care entity, or QHP issuer on the FFEs would
naturally have no data to report in its first year of existence and
would be required to report data following its first full calendar year
subject to the Patient Access API requirement.
Comment: Multiple commenters expressed support for CMS's proposal
to require payers to share patient use metrics annually starting with
CY 2025 to be reported to CMS by March 31, 2026. Some commenters
recommended that we delay the first year of the reporting requirement
to CY 2026, which would be reported no later than March 31, 2027.
Another commenter suggested that we delay the reporting deadline
because a technical solution would need to be in place by the end of
late 2024 to have metrics for CY 2025 to report in March 2026.
Response: We note that per the CMS Interoperability and Patient
Access final rule, impacted payers were required to
[[Page 8781]]
implement the Patient Access API no later than January 1, 2021. The
metrics that we proposed were not tied to the implementation of any
other proposals in the CMS Interoperability and Prior Authorization
proposed rule, including adding prior authorization information to the
data available via the Patient Access API. Based on this rule's
publication schedule, payers should have sufficient time to implement
any necessary changes to report these metrics.
Comment: A majority of commenters supported the proposed annual
reporting requirement, though multiple commenters recommended that CMS
consider requiring payers to report Patient Access API metrics
quarterly. A commenter recommended that as the popularity for Patient
Access API grows, use metrics should be reported on a quarterly basis.
Commenters agreed that requiring payers to report data on API usage
from the previous calendar year to CMS by March 31 provides an
appropriate amount of time for payers to validate the data before
submitting it to CMS.
Response: After reviewing the comments, we agree that annual
reporting is the appropriate frequency for these metrics. Given that we
are looking to understand the overall usage of third-party apps and any
patterns between payers, we do not believe that the burden of requiring
payers to report these metrics quarterly would improve our
understanding of whether patients are accessing the Patient Access API.
We may in the future consider proposing more frequent reporting or
additional metrics, but for the two metrics we are finalizing now, we
do not expect that it would be beneficial to require payers to report
more often than annually.
iii. Public Reporting
In the preamble to our proposed rule, we stated that we do not plan
to publicly report these metrics at the state, plan, or issuer level,
but may reference or publish aggregated and de-identified data that do
not include names of specific state agencies, plans, or issuers.
Comment: Some commenters recommended that CMS require payers to
publicly report Patient Access API metrics, as they believe that health
IT companies and developers would benefit from the information.
Commenters stated that by making these metrics public, CMS can help
patients and stakeholders better understand the impact of access APIs
and help inform future innovations that promote patient access and
future decision making. A commenter recommended that CMS consider
publicly reporting plan-reported information at the state, plan, or
issuer level.
Other commenters did not support CMS publicly reporting Patient
Access API use metrics. Multiple commenters stated that this could
provide inaccurate information and potentially reveal identifying
information. A commenter cautioned that publicizing reports,
particularly of the second proposed metric (the total number of
patients whose data are transferred more than once to a specific third-
party app), may give consumers an inaccurate portrayal of API success.
Response: There may be value to publicly reporting aggregated and
de-identified data to give the public a sense of Patient Access API
adoption across the industry. But we agree with commenters that, absent
the proper context, those data could be perceived inaccurately or
misleadingly. As discussed, some commenters expressed that there is
currently low health app adoption among patients regardless of the type
of payer. We also understand that low patient adoption does not
necessarily indicate a lack of payer readiness or compliance.
Therefore, until we are confident that these data can be presented in
an easy-to-understand and meaningful way, we may publicly report
aggregated and de-identified data, but will not include names of
specific state agencies, plans, or issuers unless and until proposed
through future rulemaking.
iv. Other Metrics
We requested comment on what other Patient Access API metrics we
should consider requiring payers to report to CMS and/or make available
to the public in future rulemaking. For instance, we solicited comments
on whether payers could report aggregated demographic information, such
as sex, race, age, ethnicity, and geographic data and whether that
could help identify underserved populations or disparities in patient
access to health data and, if so, policies that should be considered to
promote equity. We also solicited comments on the potential benefits
and burdens of requiring payers to report the names of all apps that
patients have used to access the payers' API each year. We considered
collecting this information, or requiring payers to make it public, not
for the purpose of recommending or endorsing specific apps, but to
review for best practices and evaluate patient ease of use.
Comment: Commenters provided many recommendations for additional
Patient Access API metrics.
Response: We greatly appreciate the wide range of metric
suggestions, such as indicators on demographic information,
utilization, query management, successful requests, and barriers to
accessing records. We will continue to research additional ways to
evaluate the effectiveness of the API for consideration in future
rulemaking.
d. Patient Access API Amendments
We proposed two minor terminology changes to the requirements
finalized in the CMS Interoperability and Patient Access final rule (85
FR 25558). Unlike most of our proposals, we proposed that these
amendments would take effect on the effective date of the final rule.
We proposed these changes to explain terms but did not expect them to
substantively change any current regulatory obligation.
First, we proposed to revise the description of the clinical data
impacted payers must make available via the Patient Access API. These
provisions, finalized in the CMS Interoperability and Patient Access
final rule, currently require payers to make available ``clinical data,
including laboratory results'' (85 FR 25536-40). We proposed to revise
these paragraphs to specify that the data that payers must make
available are ``all data classes and data elements included in a
content standard at 45 CFR 170.213.'' That citation is to a content
standard maintained by ONC of clinical data classes and data elements
for interoperable health information exchange. Referring explicitly in
the rule text to a data set in a standard at 45 CFR 170.213 will help
avoid unnecessary confusion, as this reference will more clearly
identify exactly what data must be available through the Patient Access
API. Furthermore, this change brings us into greater alignment with the
standards promulgated by ONC and used by certified health IT
developers.
As versions of the USCDI evolve, there may simultaneously be
multiple versions of the standard referenced at 45 CFR 170.213 (as both
v1 and v3 are listed at the time of publication of this final rule). In
the HTI-1 final rule, ONC finalized the adoption of USCDI v3 in 170.213
and finalized a January 1, 2026, expiration date for USCDI v1 (89 FR
1192). For the ONC Health IT Certification Program, this allows for a
transition period between standards, and, during that time, health IT
developers could incorporate updated standards versions within their
systems and complete required certification. During such a period, when
45 CFR 170.213 includes more than one version of the USCDI standard,
payers would be
[[Page 8782]]
allowed to use any of the then-referenced content standards to meet the
requirement to make clinical data available through the Patient Access
API. If a standard has a listed expiration date (as USCDI v1 is
currently listed to expire on January 1, 2026), payers would not be
able to be use it after expiration.
Second, we proposed to revise the language previously finalized for
denial or discontinuation of a health app's access to the API.
Currently, the rules require impacted payers to make a determination to
deny or discontinue access to the Patient Access API using objective,
verifiable criteria that are applied fairly and consistently across all
apps and developers through which ``enrollees'' or ``beneficiaries''
seek to access patient data. We proposed to change the terms
``enrollees'' and ``beneficiaries'' to ``parties'' for consistency with
our proposal to apply this provision to the Provider Access, Payer-to-
Payer, and Prior Authorization APIs. We stated that because parties
other than patients, such as providers and payers, would be accessing
these APIs, it would be more accurate to use the term ``parties''
rather than ``enrollees'' or ``beneficiaries.'' Those APIs are
discussed further in sections II.B., II.C., and II.D. of this final
rule.
Comment: All comments we received on these technical language
proposals supported our effort to keep the Patient Access API required
data aligned with ONC's standards. However, we did receive a variety of
comments on the USCDI standard currently referenced at 45 CFR 170.213.
Those comments are discussed in section II.G. of this final rule.
A commenter requested clarification on whether payers would be
required to request information from providers to fill any data classes
and data elements of the standard at 45 CFR 170.213 that are missing
within their records. Similarly, another commenter requested that CMS
explain that the requirement to provide claims and encounter data
within 1 business day applies only to information available at the time
of the request.
Response: In the CMS Interoperability and Patient Access final
rule, we defined ``maintain'' to mean the payer has access to the data,
control over the data, and authority to make the data available through
the API (85 FR 25538). Under that existing regulation, payers are
required to share data that they maintain as part of their normal
operations. Nothing in this final rule will change that existing
policy; payers are not required to reach out to providers or other
entities to gather data that the payer does not already maintain, if it
is not part of their normal operations, to share via the Patient Access
API. We thank commenters for their feedback and are finalizing this
proposal without modification.
We note that we are not modifying the Patient Access API
applicability date for MA at 42 CFR 422.119(h), for Medicaid FFS at 42
CFR 431.60(h), for CHIP FFS at 42 CFR 457.730(h), and for QHP issuers
on the FFEs at 45 CFR 156.221(i) because these amendments do not
substantively change any existing requirements finalized in the CMS
Interoperability and Patient Access final rule.
e. Medicaid Expansion CHIP Programs
In the CMS Interoperability and Prior Authorization proposed rule,
we discussed implementation for states with Medicaid Expansion CHIP
programs (86 FR 76279). See section II.E. of this final rule for that
complete discussion, including a summary of public comments received
and our final action statement.
f. Specific CHIP-Related Regulatory Framework
For CHIP, we proposed amendments to 42 CFR 457.1233(d) that would
align separate CHIP managed care API requirements with the Medicaid
managed care plan API requirements, rather than with the CHIP FFS API
requirements. In the CMS Interoperability and Patient Access final rule
(85 FR 25559), we finalized requirements for separate CHIP managed care
entities at 42 CFR 457.1233(d). API requirements for CHIP managed care
entities were codified at 42 CFR 457.1233(d)(2) and (3) through cross-
references to CHIP FFS program requirements at 42 CFR 457.730 and
457.760, respectively. On November 13, 2020, we published a final rule
titled ``Medicaid Program; Medicaid and Children's Health Insurance
Program (CHIP) Managed Care'' (85 FR 72754). In that rule, we removed
42 CFR 457.1233(d)(1) through (3), and, at 42 CFR 457.1233(d), cross-
referenced to Medicaid managed care regulatory requirements at 42 CFR
438.242. Therefore, the policies in the CMS Interoperability and
Patient Access final rule (85 FR 25559) are applicable to separate CHIP
managed care entities per 42 CFR 457.1233(d) through a cross reference
to Medicaid managed care at 42 CFR 438.242. We apply the API
requirements in this final rule to separate CHIP managed care entities
through the existing cross reference at 42 CFR 457.1233(d) to Medicaid
managed care at 42 CFR 438.242.
3. Other Requests for Comment
We requested comment on a variety of topics on which we did not
make specific proposals but are reviewing for future consideration. We
appreciate commenters' submissions regarding the following:
<bullet> How we could and should apply these requirements to
Medicare FFS and its existing prior authorization requirements and
standards.
<bullet> What policy levers we might have to create norms or best
practices for privacy policies by health app developers.
<bullet> How we could leverage ONC's TEFCA or other HHS HIE
initiatives to facilitate secure interoperable data exchange with
health apps.
<bullet> The availability of apps that are accessible to
individuals with disabilities, availability of apps in a multitude of
languages to ensure that individuals with limited English proficiency
can understand the information provided, and availability of apps at
appropriate literacy levels and in plain language.
BILLING CODE 4150-28-P
[[Page 8783]]
[GRAPHIC] [TIFF OMITTED] TR08FE24.000
[[Page 8784]]
BILLING CODE 4150-28-C
4. Final Action
After considering the comments received, and for the reasons
discussed in the CMS Interoperability and Prior Authorization proposed
rule and our response to those comments (as summarized previously), we
are finalizing our proposals with the following modifications:
<bullet> Impacted payers must make information about prior
authorization requests and decisions available via the Patient Access
API beginning 2027 (by January 1, 2027, for MA organizations and state
Medicaid and CHIP FFS programs; by the rating period beginning on or
after January 1, 2027, for Medicaid managed care plans and CHIP managed
care entities; and for plan years beginning on or after January 1,
2027, for QHP issuers on the FFEs), rather than in 2026.
<bullet> Impacted payers are not required to share the quantity of
items or services used under a prior authorization via the Patient
Access API.
<bullet> Impacted payers are not required to share unstructured
documentation related to prior authorizations via the Patient Access
API.
<bullet> MA organizations must report Patient Access API metrics at
the contract level rather than at the proposed organizational level.
See further discussion for exact details of the final requirements
for impacted payers.
Specifically, we are finalizing a requirement that, beginning 2027
(by January 1, 2027, for MA organizations and state Medicaid and CHIP
FFS programs; by the rating period beginning on or after January 1,
2027, for Medicaid managed care plans and CHIP managed care entities;
and for plan years beginning on or after January 1, 2027, for QHP
issuers on the FFEs), impacted payers must make the all of following
information available about prior authorization requests and decisions
(excluding for drugs) available via the Patient Access API:
<bullet> The prior authorization status.
<bullet> The date the prior authorization was approved or denied.
<bullet> The date or circumstance under which the prior
authorization ends.
<bullet> The items and services approved.
<bullet> If denied, a specific reason why the request was denied.
<bullet> Related structured administrative and clinical
documentation submitted by a provider.
We are finalizing the requirement that impacted payers make this
information about prior authorizations available no later than 1
business day after the payer receives a prior authorization request and
must update that information no later than 1 business day after any
status change. This information must be available for the duration that
the authorization is active and at least 1 year after the prior
authorization's last status change.
We are finalizing a requirement that, beginning 2026, impacted
payers must annually report Patient Access API metrics to CMS in the
form of aggregated, de-identified data. Specifically, by March 31, MA
organizations at the contract level, state Medicaid and CHIP FFS
programs, Medicaid managed care plans and CHIP managed care entities at
the state level, and QHP issuers on the FFEs at the issuer level must
report the following metrics: (1) the total number of unique patients
whose data are transferred via the Patient Access API to a health app
designated by the patient; and (2) the total number of unique patients
whose data are transferred more than once via the Patient Access API to
a health app designated by the patient. Impacted payers must report the
previous calendar year's metrics to CMS by March 31 following any year
that they offered that type of plan.
We are finalizing, as of the effective date of this final rule, the
replacement of ``clinical data, including laboratory results'' with
``all data classes and data elements included in a content standard at
45 CFR 170.213'' in the required content for the Patient Access API. We
are also finalizing, as of the effective date o
[…truncated; see source link]Indexed from Federal Register on February 8, 2024.
This is legal information, not legal advice. Laws vary by jurisdiction and change frequently. Always verify current law with official sources and consult a licensed attorney in your jurisdiction for advice on your specific situation.