[Federal Register Volume 91, Number 71 (Tuesday, April 14, 2026)]
[Proposed Rules]
[Pages 19890-20062]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 2026-07205]
[[Page 19889]]
Vol. 91
Tuesday,
No. 71
April 14, 2026
Part IV
Department of Health and Human Services
-----------------------------------------------------------------------
Centers for Medicare & Medicaid Services
-----------------------------------------------------------------------
42 CFR Parts 403, 422, et al.
-----------------------------------------------------------------------
Office of the Secretary
-----------------------------------------------------------------------
45 CFR Parts 156, 162, and 170
-----------------------------------------------------------------------
Medicare and Medicaid Programs; Patient Protection and Affordable Care
Act; Interoperability Standards and Prior Authorization for Drugs for
Medicare Advantage Organizations, Medicaid Managed Care Plans, State
Medicaid Agencies, Children's Health Insurance Program (CHIP) Agencies
and CHIP Managed Care Entities, and Issuers of Qualified Health Plans
on the Federally-Facilitated Exchanges; Proposed Rule
Federal Register / Vol. 91 , No. 71 / Tuesday, April 14, 2026 /
Proposed Rules
[[Page 19890]]
-----------------------------------------------------------------------
DEPARTMENT OF HEALTH AND HUMAN SERVICES
Centers for Medicare & Medicaid Services
42 CFR Parts 403, 422, 431, 438, 440, and 457
Office of the Secretary
45 CFR Parts 156, 162, and 170
[CMS-0062-P]
RIN 0938-AV44
Medicare and Medicaid Programs; Patient Protection and Affordable
Care Act; Interoperability Standards and Prior Authorization for Drugs
for Medicare Advantage Organizations, Medicaid Managed Care Plans,
State Medicaid Agencies, Children's Health Insurance Program (CHIP)
Agencies and CHIP Managed Care Entities, and Issuers of Qualified
Health Plans on the Federally-Facilitated Exchanges
AGENCY: Centers for Medicare & Medicaid Services (CMS) and Office of
the National Coordinator for Health Information Technology (ONC),
Department of Health and Human Services (HHS).
ACTION: Proposed rule.
-----------------------------------------------------------------------
SUMMARY: These proposals are intended to improve the electronic
exchange of health care data and streamline processes related to prior
authorization by increasing the interoperability of systems used across
the health care industry. We are proposing 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), including issuers that offer small group market QHPs
on the Federally-facilitated Small Business Health Options Program (FF-
SHOP) Exchanges (hereinafter referred to as ``small group market QHP
issuers on the FF-SHOPs'') (collectively ``impacted payers''), to make
available electronic prior authorization for drugs. We are also
proposing to extend many existing interoperability requirements for the
prior authorization of non-drug items and services to include prior
authorizations for drugs to further reduce patient and provider burden.
We are also proposing to require impacted payers to report their
application programming interfaces (API) endpoints and related
information for the Patient Access, Provider Directory, Provider
Access, Payer-to-Payer, and Prior Authorization APIs to CMS. To help
assess the impact of our policies, we are proposing to collect API
usage metrics. In addition, we are proposing to apply the existing
interoperability requirements to small group market QHP issuers on the
FF-SHOPs as impacted payers. To improve impacted payers' ability to
exchange health information while continuing CMS's drive toward
interoperability, we are proposing to require certain Health Level
Seven (HL7[supreg]) Fast Healthcare Interoperability Resources
(FHIR[supreg]) implementation guides (IGs) that are currently
recommended. In addition, HHS is proposing to adopt the HL7 FHIR base
standard and certain associated specifications and IGs as the Health
Insurance Portability and Accountability Act of 1996 (hereinafter
referred to as ``HIPAA'') (Pub. L. 104-191, enacted Aug. 21, 1996)
standards for dental, professional, and institutional ``referral
certification and authorization'' transactions and ``eligibility for a
health plan'' transactions associated with prior authorization. We are
proposing to add a definition for ``failure to report,'' which would
allow CMS to impose a civil monetary penalty (CMP) on applicable
manufacturers or applicable group purchasing organizations (GPOs) if
those entities fail to grant CMS timely access to documents for the
purposes of an audit. Finally, ONC is using this rulemaking to propose
to adopt updated versions of certain health information technology
(health IT) standards and specifications for HHS use, such as CMS's
interoperability requirements, to support a more robust health IT
infrastructure.
DATES: To be assured consideration, comments must be received at one of
the addresses provided below, by June 15, 2026.
ADDRESSES: In commenting, please refer to file code CMS-0062-P.
Comments, including mass comment submissions, must be submitted in
one of the following three ways (please choose only one of the ways
listed):
1. Electronically. You may submit electronic comments on this
regulation to http://www.regulations.gov. Follow the ``Submit a
comment'' instructions.
2. By regular mail. You may mail written comments to the following
address ONLY: Centers for Medicare & Medicaid Services, Department of
Health and Human Services, Attention: CMS-0062-P, P.O. Box 8013,
Baltimore, MD 21244-8013.
Please allow sufficient time for mailed comments to be received
before the close of the comment period.
3. By express or overnight mail. You may send written comments to
the following address ONLY: Centers for Medicare & Medicaid Services,
Department of Health and Human Services, Attention: CMS-0062-P, Mail
Stop C4-26-05, 7500 Security Boulevard, Baltimore, MD 21244-1850.
For information on viewing public comments, see the beginning of
the SUPPLEMENTARY INFORMATION section.
FOR FURTHER INFORMATION CONTACT:
[email protected] for general inquiries.
David Koppel, (303) 844-2883, for policy issues.
Shanna Hartman, (410) 786-0092, for standards issues.
Scott Weinberg, (410) 786-6017, for Access APIs issues.
Katie Brooks, 667-414-0612, for API endpoints issues.
Emmanuelle Vasilak, 667-290-9848, for compliance issues.
Nora Simmons, (410) 786-1981, for Collection of Information or
Regulatory Impact Analysis issues.
Alexander Baker, (202) 260-2048, for ONC issues.
SUPPLEMENTARY INFORMATION:
Inspection of Public Comments: All comments received before the
close of the comment period are available for viewing by the public,
including any personally identifiable or confidential business
information that is included in a comment. We post all comments
received before the close of the comment period on the following
website as soon as possible after they have been received: http://www.regulations.gov. Follow the search instructions on that website to
view public comments. CMS will not post on Regulations.gov public
comments that make threats to individuals or institutions or suggest
that the commenter will take actions to harm an individual. CMS
continues to encourage individuals not to submit duplicative comments.
We will post acceptable comments from multiple unique commenters even
if the content is identical or nearly identical to other comments.
Plain Language Summary: In accordance with 5 U.S.C. 553(b)(4), a
plain language summary of this rule may be found at https://www.regulations.gov/.
Table of Contents
I. Background, Summary of Proposals, Terms, and Severability
A. Purpose and Background
B. Summary of Major Proposals
[[Page 19891]]
C. Specific Terms Used in this Proposed Rule
D. Severability
II. Provisions of the Proposed Rule
A. Interoperability Standards for APIs
B. Electronic Prior Authorization for Drugs
C. Improving Communications and Decision Timeframes for Prior
Authorizations
D. Requirements for Issuers That Offer Small Group Market
Qualified Health Plans on the Federally-facilitated Small Business
Health Options Program Exchanges
E. Reporting Payer API Endpoints and Associated Information for
CMS To Publish
F. Updates to Patient Access, Provider Directory, Provider
Access, and Payer-to-Payer APIs; API Usage Metrics
G. Open Payments Civil Monetary Penalties
H. Modifications to HIPAA Standards Related to Prior
Authorization
J. Adoption of Health Information Technology Standards and
Incorporation by Reference
III. Requests for Information
A. Electronic Event Notifications for Value-Based Care and Care
Coordination
B. Increasing Health Care Resiliency
C. Improving Implementation of Payer Application Programming
Interface Technology
D. Step Therapy
E. Laboratory Tests and Durable Medical Equipment, Prosthetics,
Orthotics, and Supplies Items
IV. Collection of Information Requirements
V. Regulatory Impact Analysis
VI. Response to Comments
Regulation Text
I. Background, Summary of Proposals, Terms, and Severability
A. Purpose and Background
The ``Medicare and Medicaid Programs; Patient Protection and
Affordable Care Act; Interoperability and Patient Access for MA
Organizations and Medicaid Managed Care Plans, State Medicaid Agencies,
CHIP Agencies and CHIP Managed Care Entities, Issuers of Qualified
Health Plans on the Federally-Facilitated Exchanges, and Health Care
Providers'' final rule (85 FR 25510) (hereinafter referred to as the
``2020 CMS Interoperability and Patient Access final rule'') appeared
in the Federal Register on May 1, 2020. That rule was the first phase
of CMS's interoperability rulemaking and focused on giving patients
access to their health data maintained by their payer through a Patient
Access API. In that rule, we required MA organizations, state Medicaid
and CHIP FFS programs, Medicaid managed care plans, CHIP managed care
entities, and issuers that offer individual market QHPs on the FFEs
(hereinafter referred to as ``individual market QHP issuers on the
FFEs'') to implement a Patient Access API that allows patients, through
health apps with the necessary functionality, to easily access their
claims and encounter information, provider remittances, patient cost-
sharing information, and clinical data, including laboratory results,
maintained by the impacted payer.\1\
---------------------------------------------------------------------------
\1\ See 42 CFR 422.119(b) for MA organizations, 42 CFR 431.60(b)
for state Medicaid FFS programs, 42 CFR 457.730(b) for state CHIP
FFS programs, cross reference to 42 CFR 431.60 in 42 CFR
438.242(b)(5) for Medicaid managed care plans, cross reference to 42
CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care entities,
and 45 CFR 156.221(b) for individual market QHP issuers on the FFEs.
---------------------------------------------------------------------------
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 (CAHs)
in the Medicare Promoting Interoperability Program'' final rule (89 FR
8758) (hereinafter referred to as the ``2024 CMS Interoperability and
Prior Authorization final rule'') appeared in the Federal Register on
February 8, 2024. In that rule, we finalized requirements for impacted
payers to improve the electronic exchange of health care information,
not just with patients, but also with providers and other payers. We
also finalized requirements for impacted payers to implement and
maintain a Prior Authorization API that supports electronic prior
authorization between providers and payers.\2\ We also finalized
general process requirements for prior authorization, such as requiring
MA organizations, state Medicaid and CHIP FFS programs, Medicaid
managed care plans, and CHIP managed care entities to respond to prior
authorization requests for non-drug items and services within certain
timeframes.
---------------------------------------------------------------------------
\2\ See 42 CFR 422.122(b) for MA organizations, 42 CFR 431.80(b)
for state Medicaid FFS programs, 42 CFR 457.732(b) for state CHIP
FFS programs, through cross reference to 42 CFR 431.80(b) in 42 CFR
438.242(b)(7) for Medicaid managed care plans, through cross
reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed
care entities, and 45 CFR 156.223(b) for individual market QHP
issuers on the FFEs.
---------------------------------------------------------------------------
In the 2024 CMS Interoperability and Prior Authorization final
rule, we did not propose or finalize requirements that apply to drugs
of any type because, as we discussed in the proposed and final rules,
the processes and electronic standards for prior authorization of drugs
differ from the non-drug items and services included in our final
policies. We also acknowledged that there are existing laws and
regulations around the prior authorization of drugs that may apply to
impacted payers (such as the existing electronic prescribing
requirements for covered Part D drugs in 42 CFR 423.160) (87 FR 76240
and 76241, and 89 FR 8762). However, we received many public comments
in response to 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 (87 FR
76238) (hereinafter referred to as the ``2022 CMS Interoperability and
Prior Authorization proposed rule''), which appeared in the Federal
Register on December 13, 2022, as well as additional feedback from
providers, payers, and standards developing organizations (SDOs),
indicating that while some prior authorization processes and standards
for drugs currently exist, the health care industry would benefit from
consistent electronic prior authorization requirements to promote
patients' timely access to drugs and alleviate burden for providers and
payers. Commenters emphasized the impact that prior authorization for
drugs has on patients and providers and urged CMS to implement similar
requirements for drugs as were proposed for non-drug items and
services. In addition, commenters explained that the Prior
Authorization API can facilitate electronic prior authorization for
drugs covered under a medical benefit, so the same standards and
requirements could be used for that category of drugs. Commenters also
pointed out that requirements already existed for Medicare Part D
sponsors to support (and prescribers to use) a standard adopted by the
Secretary for the prior authorization of covered Part D drugs, the
National Council for Prescription Drug Programs (NCPDP) SCRIPT Standard
Implementation Guide (NCPDP SCRIPT standard). Those
[[Page 19892]]
commenters suggested modeling requirements for the other types of
impacted payers on the existing Part D requirements in 42 CFR 423.160,
as established in the ``Medicare Program; Secure Electronic Prior
Authorization for Medicare Part D'' final rule (85 FR 86824)
(hereinafter referred to as the ``2020 Medicare Part D ePA final
rule''), which appeared in the Federal Register on December 31, 2020.
The 2024 CMS Interoperability and Prior Authorization final rule
also established, improved, or shortened prior authorization timeframes
for impacted payers other than QHP issuers on the FFEs (MA
organizations, state Medicaid and CHIP FFS programs, Medicaid managed
care plans, and CHIP managed care entities) to respond to prior
authorization requests for non-drug items and services. Specifically,
we finalized timeframes of 7 calendar days for standard requests and 72
hours for expedited requests, with the possibility of an extension of
up to 14 days in certain circumstances (89 FR 8878). For Medicaid and
CHIP, state law may establish a shorter timeframe.\3\ Some of the
payers affected by those requirements had existing timeframes for prior
authorization decisions, notices, and appeals that differed, so we
aligned the prior authorization decision timeframes across impacted
payers, except for QHP issuers on the FFEs (89 FR 8878). As discussed
in the 2022 CMS Interoperability and Prior Authorization proposed rule
and the 2024 CMS Interoperability and Prior Authorization final rule,
we did not propose prior authorization decision timeframes for QHP
issuers on the FFEs, in part because existing regulations in 45 CFR
147.136 already establish internal claims and appeals processes,
external review processes, and pre-service claims (prior authorization)
requirements for all non-grandfathered group and individual market
plans or coverage (87 FR 76297 and 89 FR 8879). Specifically, 45 CFR
147.136(b)(3) specifies that individual market QHP issuers on the FFEs
are generally subject to requirements of the Employee Retirement Income
Security Act of 1974 (hereinafter referred to as ``ERISA'') (Pub. L.
93-406, enacted September 2, 1974) and internal claims and appeals
procedures applicable to group health plans under 29 CFR 2560.503-1 as
if the issuer were a group health plan. Thus, QHP issuers on the FFEs
are required to provide notification of a plan's benefit determination
for pre-service claims to enrollees within a reasonable period of time
appropriate to the medical circumstances, but not later than 15 days
for standard prior authorization decisions, and as soon as possible,
taking into account the medical exigencies, but not later than 72 hours
for expedited requests. The latter is a similar timeframe for notices
to enrollees for expedited authorization decisions as finalized for
other impacted payers (89 FR 8880).
---------------------------------------------------------------------------
\3\ See 42 CFR 440.230(e) for state Medicaid FFS programs, 42
CFR 457.495(d)(2) for state CHIP FFS programs, 42 CFR 438.210(d) for
Medicaid managed care plans, and 42 CFR 457.1230(d) for CHIP managed
care entities. State law may not impose a shorter timeline on MA
organizations in light of the preemption provisions in section
1856(b)(3) of the Social Security Act (the Act) and 42 CFR 422.402.
---------------------------------------------------------------------------
At the time, we did not propose to change those timeframes because
they are aligned with other non-grandfathered group and individual
market plans. However, we received numerous comments that opposed the
exclusion of QHP issuers on the FFEs from these policies and urged that
QHPs offered on the FFEs should be aligned with the requirements for
other CMS programs. Some expressed concern that not doing so would have
negative effects on enrollee care, and that enrollees with coverage
through these plans should be entitled to the same protections as those
with coverage through the other impacted payers. In addition, we
received comments that recommended we reconsider the exclusion of drugs
from our proposals and suggested that CMS finalize the prior
authorization process and Prior Authorization API requirements in the
2024 CMS Interoperability and Prior Authorization final rule to cover
drugs covered under a medical benefit. Commenters further expressed
that by failing to include drugs in those requirements, CMS was failing
to address the biggest culprit of delay to timely care and
administrative burden.
B. Summary of Major Proposals
We are proposing to require that impacted payers support electronic
prior authorization for all drugs that require prior authorization. We
are proposing two separate sets of standards to facilitate electronic
prior authorization for all drugs, the HL7 FHIR standard (and certain
FHIR IGs) as one set, and three NCPDP standards (the NCPDP SCRIPT
standard, NCPDP Formulary & Benefit Standard Implementation Guide
[NCPDP F&B standard], and the NCPDP Real-Time Prescription Benefit
Standard Implementation Guide [NCPDP RTPB standard]) as the other set.
The FHIR standard, including the IGs, and the three NCPDP standards,
all facilitate electronic prior authorization for drugs; which
standards set is applicable depends on whether the drug is covered
under the payer's medical benefit or its pharmacy benefit. We are
proposing to require impacted payers to expand their Prior
Authorization API, finalized in the 2024 CMS Interoperability and Prior
Authorization final rule (89 FR 8758), to incorporate drugs covered
under a medical benefit. We are also proposing to require impacted
payers (other than MA organizations for whom requirements already
exist) to support the proposed NCPDP standards for the electronic prior
authorization of drugs covered under a pharmacy benefit.
As proposed in this proposed rule, the Prior Authorization API
comprises the HL7 FHIR Da Vinci Coverage Requirements Discovery (CRD)
IG, the HL7 FHIR Da Vinci Documentation Templates and Rules (DTR) IG,
and the HL7 FHIR Da Vinci Prior Authorization Support (PAS) IG, and can
be used to support drugs under a medical benefit, but should not be
used for the prior authorization of drugs covered under a pharmacy
benefit. Specifically, the PAS IG states that the IG ``SHOULD NOT be
used for any medication that is covered under a pharmacy benefit where
prior authorization is provided by another electronic exchange process
(for example, NCPDP SCRIPT).'' \4\
---------------------------------------------------------------------------
\4\ NOTE: This document contains links to non-United States
Government websites. We are providing these links because they
contain additional information relevant to the topic(s) discussed in
this document or that otherwise may be useful to the reader. We
cannot attest to the accuracy of information provided on the cited
third-party websites or any other linked third-party site. We are
providing these links for reference only; linking to a non-United
States Government website does not constitute an endorsement by CMS,
HHS, or any of their employees of the sponsors or the information
and any products presented on the website. Also, please be aware
that the privacy protections generally provided by United States
Government websites do not apply to third-party sites.
Health Level Seven International. (2026, March 27). Da Vinci
Prior Authorization Support (PAS) FHIR: Use Cases and Overview.
Retrieved from https://hl7.org/fhir/us/davinci-pas/2.2.1/en/usecases.html.
---------------------------------------------------------------------------
Conversely, the NCPDP SCRIPT standard include instructions that it
is to be used for ``products covered by a patient's pharmacy benefit.''
The NCPDP F&B and NCPDP RTPB standards complement the NCPDP SCRIPT
standard and apply to the same category of drugs. Payers can use the
NCPDP F&B standard to make available formulary and benefit information,
including prior authorization requirements, at the health plan level.
The NCPDP RTPB standard enables real-time exchange at the point-of-
prescribing of patient-specific eligibility, coverage, and estimated
cost-sharing information for drugs covered
[[Page 19893]]
under a pharmacy benefit. Therefore, these sets of FHIR and NCPDP
standards are mutually exclusive and, when used in conjunction,
encompass the full scope of drugs that are covered by any particular
payer. We propose that impacted payers be required to support
electronic prior authorization for all drugs through the Prior
Authorization API and NCPDP standards beginning on October 1, 2027.
Our proposals regarding the prior authorization of drugs are
similar to the provisions finalized for non-drug items and services in
the 2024 CMS Interoperability and Prior Authorization final rule (89 FR
8897) but with special consideration to existing policies, operational
processes, and standards for the electronic prior authorizations of
drugs. The proposals would require impacted payers to support
electronic prior authorization for all drugs, which should improve the
process for impacted payers' patients and providers. In section II.A.
of this proposed rule, we describe each of these standards and how they
would be used. In section II.B. of this proposed rule, we describe our
proposals as they apply to each category of impacted payer, including
program specifics as to distinction of drugs covered under medical
benefits versus drugs covered under pharmacy benefits.
For the proposed requirement to incorporate drugs covered under a
medical benefit into the Prior Authorization API, we are proposing an
October 1, 2027 compliance date. As discussed in section II.B.3. of
this proposed rule, incorporating drugs into Prior Authorization APIs
means that, using the proposed standards, information is available
through the API as to whether prior authorization is required for drugs
covered under a medical benefit, the coverage and documentation
requirements for prior authorization are available, and that the API
can transmit prior authorization requests and decisions between
providers and the payer.
Medicare Part D sponsors (including MA organizations that offer a
Medicare Advantage Prescription Drug [MA-PD] plan) are already
required, in 42 CFR 423.160(b)(1), to use an unexpired version of the
NCPDP SCRIPT standard adopted by the Secretary in 45 CFR 170.205(b) as
part of their electronic prescription drug programs. Prescribers and
dispensers are also required to use an adopted version of the NCPDP
SCRIPT standard when electronically transmitting prescriptions and
prescription-related information for covered Part D drugs for Part D-
eligible individuals. Similarly, beginning January 1, 2027, Part D
sponsors are required, in 42 CFR 423.160(b)(3) and (b)(5), to implement
for uses described in those paragraphs unexpired versions of the NCPDP
F&B and RTPB standards adopted by the Secretary in 45 CFR 170.205(u)
and 45 CFR 170.205(c), respectively.
We propose that state Medicaid and CHIP FFS programs, Medicaid
managed care plans, CHIP managed care entities, and QHP issuers on the
FFEs, including small group market QHP issuers on the FF-SHOPs,
similarly could use any unexpired version of the NCPDP standards
adopted by the Secretary in 45 CFR 170.205(b), (c), and (u) to support
electronic prior authorization of drugs covered under a pharmacy
benefit. We are proposing an October 1, 2027 compliance date to support
the proposed NCPDP standards to facilitate electronic prior
authorization of drugs covered under a pharmacy benefit.
Consistent with section 3004(b)(3) of the PHSA, the Secretary
adopts standards for HHS use, including those adopted in 45 CFR
170.215. We are proposing to require impacted payers to implement and
maintain their required FHIR APIs in conformance with certain
applicable standards adopted in 45 CFR 170.215, without specifying
versions of each required standard, which would allow impacted payers
to use unexpired versions of the required standards, as the Secretary
adopts updated versions in 45 CFR 170.215. Where more than one
unexpired version of a standard is adopted in 45 CFR 170.215, impacted
payers would be able to use any of the unexpired standards, allowing
for transition periods as updated versions are adopted by the Secretary
and older versions expire. To support interoperability, these proposals
require impacted payers to implement and maintain API technology
conformant with certain IGs that were recommended in the 2024 CMS
Interoperability and Prior Authorization final rule, as applicable to
each interoperability API (89 FR 8945). We are proposing an October 1,
2027 compliance date to implement the proposed standards. We are also
recommending additional IGs for some of the APIs that could be used to
support certain use cases.
We are proposing to replace the policy finalized in the 2024 CMS
Interoperability and Prior Authorization final rule that allows states
with small FFS populations to request an exemption from CMS for the
non-drug items and services Prior Authorization API requirements with a
policy that would allow all state Medicaid and CHIP FFS programs to
request extensions to the compliance date for that requirement. We are
proposing that those extensions would only be available until the
compliance date for the HIPAA Administrative Simplification proposals
in this rule, if the proposals are finalized. In addition, we are
proposing a process for state Medicaid and CHIP FFS programs to request
from CMS extensions to allow additional time to meet the proposed
requirement to incorporate drugs covered under a medical benefit into
the Prior Authorization API and the proposed requirement to support the
NCPDP standards for electronic prior authorization of drugs covered
under a pharmacy benefit, if they meet certain criteria. We are also
proposing that QHP issuers on the FFEs be permitted to request an
exception from the requirement to support electronic prior
authorization of drugs covered under a pharmacy benefit through the
proposed NCPDP standards, as part of the annual QHP certification
process. Issuers could seek an exception by submitting a narrative
justification with information specified in 45 CFR 156.223(h),
including why the QHP issuer on the FFEs cannot reasonably satisfy the
requirements for the applicable plan year.\5\ Those proposals are
similar to the exception policies finalized in the 2024 CMS
Interoperability and Prior Authorization final rule and are discussed
in section II.B.7. of this proposed rule.\6\
---------------------------------------------------------------------------
\5\ We note that existing language in 45 CFR 156.223(d)(1)(i)
would also allow QHP issuers to request an exception to the
requirement, if finalized, to incorporate electronic prior
authorization for drugs under a medical benefit into the Prior
Authorization API.
\6\ For exceptions, see 45 CFR 156.222(c) and 45 CFR 156.223(d)
for individual market QHP issuers on the FFEs.
---------------------------------------------------------------------------
We are proposing to require state Medicaid and CHIP FFS programs,
Medicaid managed care plans, CHIP managed care entities, and QHP
issuers on the FFEs to respond to the provider with a specific reason
for denying a prior authorization request for any drugs. We are
proposing an October 1, 2027 compliance date for those impacted payers
to respond to a provider with a specific reason for denying a prior
authorization request for any drugs. This proposal builds on the
requirement finalized in the 2024 CMS Interoperability and Prior
Authorization final rule that impacted payers must provide a specific
reason to the provider for denying a prior authorization request for
non-drug items and services.\7\
---------------------------------------------------------------------------
\7\ See 42 CFR 422.122(a) for MA organizations and applicable
integrated plans, 42 CFR 431.80(a) for state Medicaid FFS programs,
through cross reference to 42 CFR 431.80(a) in 42 CFR 438.242(b)(8)
for Medicaid managed care plans, 42 CFR 457.732(a) for state CHIP
FFS programs, through cross reference to 42 CFR 438.242 in 42 CFR
457.1233(d) for CHIP managed care entities, and 45 CFR 156.223(a)
for individual market QHP issuers on the FFEs.
---------------------------------------------------------------------------
[[Page 19894]]
For state Medicaid FFS programs, Medicaid managed care plans, and
CHIP managed care entities, the timeframes for making decisions on
prior authorization requests for covered outpatient drugs is 24
hours.\8\ However, the term ``covered outpatient drugs'' does not apply
to all drugs that are covered by states for which states receive
Federal Financial Participation (FFP) from CMS. Therefore, we are
requesting comment to identify whether there are drugs for which a
prior authorization timeframe does not currently exist and needs to be
established. If there are gaps identified in the prior authorization
decision timeframe requirements for drugs, in order to align patient
protections and create consistent requirements across the Medicaid and
CHIP programs, we propose to require state Medicaid FFS programs,
Medicaid managed care plans, and CHIP managed care entities to provide
notice of prior authorization decisions for drugs within a timeframe
that aligns with applicable existing decision timeframe requirements.
We are proposing an October 1, 2027 compliance date. In addition, we
are proposing to require state CHIP FFS programs to make decisions on
prior authorization requests for prescription drugs for which the state
receives FFP no later than 24 hours after receiving a prior
authorization request, rather than the current requirements that cover
both drugs and non-drug items and services. We are proposing an October
1, 2027 compliance date.
---------------------------------------------------------------------------
\8\ See section 1927(d)(5)(A) of the Act for state Medicaid FFS
programs, 42 CFR 438.3(s)(6) for Medicaid managed care plans, and 42
CFR 457.1230(d) for CHIP managed care entities.
---------------------------------------------------------------------------
We are proposing to shorten timeframes within which QHP issuers on
the FFEs, including small group market QHP issuers on the FF-SHOPs,
must make a decision on prior authorization requests by establishing
timeframes by which QHP issuers on the FFEs must notify requesting
providers of their decision. The proposed timeframes generally align
with the timeframes for other impacted payers that we finalized in the
2024 CMS Interoperability and Prior Authorization final rule for non-
drug items and services (89 FR 8878) and that we are proposing for
drugs in this proposed rule. Specifically, we propose to require QHP
issuers on the FFEs to send notice of their decision to the requesting
provider for standard prior authorization requests for non-drug items
and services as expeditiously as the enrollee's health condition
requires, but no later than 7 calendar days after receiving the
request. We are not proposing to change the existing 72-hour timeframe
to notify enrollees about prior authorization decisions on expedited
requests for non-drug items and services, but are proposing that QHP
issuers on the FFEs notify the requesting provider of their decision on
a prior authorization request for non-drug items and services within
the same timeframe. These proposed timeframes for non-drug items and
services align with existing timeframes that were finalized in the 2024
CMS Interoperability and Prior Authorization final rule for MA
organizations, state Medicaid and CHIP FFS programs, Medicaid managed
care plans, and CHIP managed care entities (89 FR 8878). We are also
proposing to require QHP issuers on the FFEs to send notice of their
decision to the requesting provider for standard prior authorization
requests for drugs as expeditiously as the enrollee's health condition
requires, but no later than 72 hours after receiving the request. We
are further proposing to require QHP issuers on the FFEs to send notice
of their decision to the requesting provider for expedited prior
authorization requests for drugs as expeditiously as the enrollee's
health condition requires, but no later than 24 hours after receiving
the request. These proposed timeframes generally align with existing
requirements for Part D sponsors in 42 CFR 423.568(b) and in 42 CFR
423.572(a). For these proposals, we are proposing an October 1, 2027
compliance date.
In the 2024 CMS Interoperability and Prior Authorization final
rule, we finalized an annual March 31 reporting deadline for all
impacted payers to report Patient Access API usage metrics to CMS and
to publicly post prior authorization metrics for non-drug items and
services from the previous year (89 FR 8784, 8817, and 8855). However,
we have determined that such deadlines may not align with Medicaid
managed care plans' and CHIP managed care entities' contract rating
periods and with the QHP certification process for QHP issuers on the
FFEs. Therefore, to align the reporting deadlines with the contract
rating period, we are now proposing to require Medicaid managed care
plans and CHIP managed care entities to report Patient Access API usage
metrics from each rating period to states no later than 90 days after
the end of each rating period and to publicly post the required prior
authorization metrics for non-drug items and services no later than 90
days after the end of each rating period. For QHP issuers on the FFEs,
we are proposing regulatory text to refer to the reporting deadline for
Patient Access API usage metrics in a manner similar to the reporting
deadlines for other plan data that CMS collects during the annual QHP
certification process. Specifically, we propose that following each
year it offers a QHP on an FFE, a QHP issuer on the FFEs must report
the specified metrics to CMS as aggregated, de-identified data at the
issuer level in the form and manner and within the timeframes specified
by the Secretary. That would allow flexibility for CMS to include API
usage metrics reporting within specific deadlines set for the QHP
certification process, which, in practice, is generally the final
deadline for the QHP certification process that takes place the
following year.\9\ We are proposing that these changes become effective
beginning on the effective date of the final rule.
---------------------------------------------------------------------------
\9\ Information about QHP certification, including deadlines can
be found at https://www.qhpcertification.cms.gov/QHP/aboutthemarketplace/Timeline.
---------------------------------------------------------------------------
Building on the requirement finalized in the 2024 CMS
Interoperability and Prior Authorization final rule that impacted
payers must report Patient Access API usage metrics to CMS, we are
proposing to require impacted payers to report similar usage metrics
about their Provider Access, Payer-to-Payer, and Prior Authorization
APIs.\10\ Collecting these metrics should help CMS evaluate the impact
of our policies and plan for future changes, if necessary. We are
proposing that the metrics would be reported annually by MA
organizations at the contract level, state Medicaid and CHIP FFS
programs at the state level, Medicaid managed care plans and CHIP
managed care entities at the plan and program level, and QHP issuers on
the FFEs at the issuer level. We are proposing that beginning in 2028,
MA organizations and state Medicaid and CHIP FFS programs would be
required to report the previous calendar year's metrics by March 31 of
each year. We are proposing that Medicaid managed care plans and CHIP
managed care entities would report their metrics to states from
[[Page 19895]]
each rating period no later than 90 days after the end of each rating
period. We are proposing that QHP issuers on the FFEs report their API
usage metrics as aggregated, de-identified data at the issuer level in
the form and manner and within the timeframes specified by the
Secretary, as we are proposing to amend the deadline for Patient Access
API usage metrics. For these proposals, we propose compliance dates
beginning in 2028.
---------------------------------------------------------------------------
\10\ See 42 CFR 422.119(f) for MA organizations, 42 CFR
431.60(f) for state Medicaid FFS programs, through cross reference
to 431.60 in 42 CFR 438.242(b)(5)(iii) for Medicaid managed care
plans, 42 CFR 457.730(f) for CHIP FFS programs, through existing
cross reference to 42 CFR 438.242 in existing 42 CFR 457.1233(d) for
CHIP managed care entities, and 45 CFR 156.221(f) for individual
market QHP issuers on the FFEs.
---------------------------------------------------------------------------
In the 2024 CMS Interoperability and Prior Authorization final
rule, we finalized requirements for impacted payers to report on their
websites certain prior authorization metrics for non-drug items and
services, including the percentage of prior authorizations that were
approved, denied, approved after appeal, and approved after the
timeframe for review was extended (89 FR 8897). In an effort to provide
more useful and complete information, we are now proposing that
impacted payers report a numeric count for each of those metrics (in
addition to the percentages). We are also proposing that impacted
payers report six new metrics: four new metrics about prior
authorization denials after an extended timeframe and appeals for non-
drug items and services and two new metrics about prior authorization
approvals after an extended timeframe and appeals for non-drug items
and services for expedited prior authorization requests only. The
proposed metrics complement existing metrics finalized in the 2024 CMS
Interoperability and Prior Authorization final rule about prior
authorization approvals after an extended timeframe and appeals for
non-drug items for standard prior authorization requests. We are
proposing compliance dates beginning in 2028 for impacted payers to
report the additional metrics.
Similarly, we are proposing to require impacted payers to publicly
post on their websites a set of metrics on prior authorizations for all
drugs (excluding covered Part D drugs for MA-PD plans). To align with
the finalized requirements and our new proposals, we are proposing that
these reports must be posted no later than March 31 following any
calendar year that the impacted payer offered that type of plan for MA
organizations, state Medicaid and CHIP FFS programs, and QHP issuers on
the FFEs, and no later than 90 days after the end of each rating period
for Medicaid managed care plans and CHIP managed care entities.\11\ We
are proposing compliance dates beginning in 2028 for impacted payers to
post these metrics.
---------------------------------------------------------------------------
\11\ See 42 CFR 422.122(c) for MA organizations and applicable
integrated plans, 42 CFR 440.230(e)(3) for state Medicaid FFS
programs, 42 CFR 457.732(c) for state CHIP FFS programs, 42 CFR
438.210(f) for Medicaid managed care plans, through cross reference
to 42 CFR 438.210 in 42 CFR 457.1230(d) for CHIP managed care
entities, and 45 CFR 156.223(c) for individual market QHP issuers on
the FFEs.
---------------------------------------------------------------------------
We propose to include small group market QHP issuers on the FF-
SHOPs in the list of impacted payers for all the proposals in this
proposed rule that apply to individual market QHPs on the FFEs. In
addition, we are proposing to apply the existing requirements in 45 CFR
156.221, 45 CFR 156.222, and 45 CFR 156.223, which were finalized in
the 2020 CMS Interoperability and Patient Access final rule and in the
2024 CMS Interoperability and Prior Authorization final rule (85 FR
25510 and 89 FR 8758), to small group market QHP issuers on the FF-
SHOPs. We did not apply these policies to small group market QHP
issuers on the FF-SHOPs in previous rulemaking due to concerns about
placing burden on these issuers (85 FR 25553 and 89 FR 8767). However,
based on subsequent research, all issuers that offer small group market
QHPs on the FF-SHOPs, as of the time of this proposal, also offer
individual market QHPs on the FFEs. Therefore, we anticipate that the
burden for these issuers to implement these proposals for their small
group market QHPs on the FF-SHOPs should be relatively low because
these issuers are already required to implement the policies for their
individual market QHPs on the FFEs. Since plan year 2021, we have only
seen one instance of a new entrant into an FF-SHOP Exchange. However,
should this change in the future--for example, if an issuer that does
not offer one or more individual market QHPs on the FFEs newly enters
an FF-SHOP, and this proposal has been finalized, we could still
mitigate potential burden for such an issuer by considering whether an
exception to one or more of these requirements is appropriate based on,
for example, whether such an exception would be in the interests of
qualified individuals and qualified employers.\12\
---------------------------------------------------------------------------
\12\ For more information on interoperability and QHP
certification, including further detail on the exceptions process,
see https://www.qhpcertification.cms.gov/QHP/applicationmaterials/Interoperability. Discussion of this topic is also available in the
2024 CMS Interoperability and Prior Authorization final rule
preamble: 89 FR 8906.
---------------------------------------------------------------------------
Throughout this proposed rule, we will refer to ``QHP issuers on
the FFEs'' where we propose requirements that apply to both individual
market QHP issuers on the FFEs and small group market QHP issuers on
the FF-SHOPs, and we will refer to ``small group market QHP issuers on
the FF-SHOPs'' in proposals to apply requirements in 45 CFR 156.221, 45
CFR 156.222, and 45 CFR 156.223 that we previously finalized for
individual market QHP issuers on the FFEs. We are proposing that
references to QHP issuers on the FFEs in 45 CFR 156.221, 45 CFR
156.222, and 45 CFR 156.223 would include small group market QHP
issuers on the FF-SHOPs, because that term is used throughout 45 CFR
part 156 Subpart C to refer to QHPs offered in both the individual and
small group markets. We will only use different terminology in cases
where there is a need to distinguish between individual market QHP
issuers on the FFEs and small group market QHP issuers on the FF-SHOPs,
such as in proposals to apply a different compliance date for small
group market QHP issuers on the FF-SHOPs. For example, because the
requirements in 45 CFR 156.221 already took effect for plan years
beginning on or after January 1, 2021, our proposed amendment to that
regulation would apply the requirements to implement and maintain a
Patient Access API to small group market QHP issuers on the FF-SHOPs as
of plan years beginning on or after January 1, 2028. We are also
proposing a compliance date of plan years beginning on or after January
1, 2028 for small group market QHP issuers on the FF-SHOPs to comply
with rules in 45 CFR 156.222 to implement and maintain Provider Access
and Payer-to-Payer APIs unless granted an exception pursuant to 45 CFR
156.222(c). We believe that aligning these compliance dates would
simplify these requirements, and that it likely provides enough time
for issuers that have already implemented the required APIs for their
individual market QHPs on the FFEs.
The phrase ``plan years beginning on or after January 1'' already
accommodates small group market QHP issuers on the FF-SHOPs that may
have non-calendar year plan years. We solicit comments on the proposals
throughout this rule specifically regarding the proposed compliance
dates for small group market QHP issuers on the FF-SHOPs, including
regarding whether these plans may need more time to implement these
requirements. For instance, how could the prior authorization proposals
in section II.B. of this proposed rule (electronic prior authorization
proposal applicable to all QHP issuers on the FFEs) and II.C. of this
proposed rule (prior authorization processes applicable to all QHP
issuers on the FFEs) affect small group market QHP issuers on the FF-
SHOPs' ability
[[Page 19896]]
to meet the requirements proposed in section II.D. of this proposed
rule (requirements for small group market QHP issuers on the FF-SHOPs),
and vice versa?
To support implementation of the policies finalized in the 2020 CMS
Interoperability and Patient Access and 2024 CMS Interoperability and
Prior Authorization final rules, we propose to require impacted payers
to report their API endpoints for each of the required APIs to CMS. In
response to the 2022 CMS Interoperability and Prior Authorization
proposed rule, we received numerous comments from the public indicating
that a centralized directory of API endpoints would be necessary to
unlock the full potential of our electronic data exchange policies and
reduce administrative burden (89 FR 8932). For instance, a centralized
directory of API endpoints could help providers locate a payer's
Provider Access API to request patient data or Prior Authorization API
to submit a prior authorization request. In addition, payers will need
to discover each other's API endpoints to exchange data via the Payer-
to-Payer API. Commenters emphasized that there would be a significant
burden if payers' API endpoints had to be found individually rather
than being listed in a centralized directory. Therefore, we are
proposing to require impacted payers to report their Patient Access,
Provider Directory, Provider Access, Payer-to-Payer, and Prior
Authorization API endpoints and related information to CMS no later
than 60 days after the effective date of a final rule, in a manner to
be determined. We are also proposing that new impacted payers be
required to report this information no later than 60 days before they
begin covering patients under the applicable CMS program.
To ensure that patients, providers, and other payers can have
complete and appropriate access to information about prior
authorizations, we are proposing to require impacted payers to make
information about prior authorization requests and decisions for all
drugs available to patients via the Patient Access, Provider Access,
and Payer-to-Payer APIs (collectively ``Access APIs''). For the Patient
Access and Provider Access APIs, this includes, as applicable, the
status of the prior authorization; the date the prior authorization was
approved or denied; the date or circumstance under which the
authorization ends; the drug or drugs approved (including the dosage);
if the prior authorization was denied, a specific reason why the
request was denied; and related structured administrative and clinical
documentation submitted by a provider. For the Payer-to-Payer API, that
includes, as applicable, the status of the prior authorization; the
date the prior authorization was approved; the date or circumstance
under which the authorization ends; the drugs or drugs approved
(including the dosage); and related structured and unstructured
administrative and clinical documentation submitted by a provider,
excluding denied prior authorization requests. We are proposing an
October 1, 2027 compliance date for these proposals.
In addition, we are proposing to add a definition for ``failure to
report'' in 42 CFR 403.902 to support the Open Payments program. The
Open Payments program, mandated by section 1128G of the Social Security
Act (hereinafter referred to as ``the Act'') and codified in 42 CFR
403.900 through 403.914, requires the pharmaceutical and medical device
industry to submit information about certain payments or other
transfers of value made to certain types of health care providers. This
proposal would allow CMS to impose a CMP on applicable manufacturers or
applicable GPOs if those entities fail to grant CMS timely access to
documents for the purposes of an audit authorized by 42 CFR
402.912(e)(2). We propose this definition be effective beginning on the
effective date of the final rule.
Under the Administrative Simplification provisions of HIPAA (Part C
of Title XI of the Act), HHS is proposing to adopt the FHIR standard
and certain associated IGs as the standards for dental, professional,
and institutional ``referral certification and authorization''
transactions and ``eligibility for a health plan'' transactions
associated with prior authorization. Specifically, in addition to the
FHIR standard, HHS is proposing to adopt the HL7 FHIR US Core (US
Core), HL7 Substitutable Medical Applications, Reusable Technologies
(SMART) Application Launch Framework (SMART App Lauch), CRD, DTR, and
PAS IGs in place of the adopted versions of the X12N 278 Health Care
Services Review--Request for Review and Response transaction standard
(X12N 278 transaction standard) in 45 CFR 162.1302 and the existing
X12N 270/271 Health Care Eligibility Benefit Inquiry and Response
transaction standard (X12N 270/271 transaction standard) in 45 CFR
162.1202 for transactions related to prior authorization. Additionally,
HHS is proposing to adopt the HL7 FHIR Da Vinci Clinical Data Exchange
(CDex) IG in 45 CFR 162.1302(g)(2)(vii) as the attachment standard for
prior authorization transactions. The proposals to adopt the FHIR
standards would only apply to dental, professional, and institutional
transactions, not to those for retail pharmacy drugs, which are
currently required to be conducted using NCPDP standards. HHS proposes
a compliance date for these HIPAA Administrative Simplification
proposals 24 months after the effective date of a final rule, except
for small health plans, for which HHS proposes a compliance date 36
months after the effective date of a final rule. HHS is making these
proposals after evaluating the results of the exception from the
currently adopted standards granted to the HL7 Da Vinci Project, as
provided in 45 CFR 162.940, to test FHIR standards.\13\
---------------------------------------------------------------------------
\13\ Centers for Medicare & Medicaid Services. (2026, April 7).
Exceptions Process. Retrieved from https://www.cms.gov/priorities/key-initiatives/burden-reduction/administrative-simplification/hipaa/exceptions-process.
---------------------------------------------------------------------------
As part of this proposed rule, ONC \14\ is proposing to adopt
updated versions of certain health IT standards and specifications in
45 CFR 170.215 on behalf of HHS. Specifically, ONC is proposing to
adopt updated versions of the health IT standards and specifications
codified in 45 CFR 170.215(j)(1) through (3), (k)(1), (m), and (n),
which CMS is proposing to require impacted payers to use. Additionally,
ONC is proposing a January 1, 2028 expiration date for versions of the
standards and specifications currently in 45 CFR 170.215(j)(1) through
(3), (k)(1), (m), and (n), provided that the proposals to adopt the
newer versions of these adopted standards are finalized. These updated
standards versions could support a more robust health IT
infrastructure, create consistency for industry, and facilitate
interoperability by ensuring that health IT leveraging these standards
under different HHS programs use the same baseline standards for the
same use cases, such as electronic prior authorization.
---------------------------------------------------------------------------
\14\ ASTP/ONC is now referred to as ONC, pursuant to a notice
which appeared in the Federal Register on April 1, 2026 (91 FR
16204). Although, at the time of specific references noted herein,
ONC was either referenced as ASTP/ONC or as ONC, for clarity, all
references in this document are now noted as ONC.
---------------------------------------------------------------------------
Finally, we are publishing five requests for information (RFIs) to
gather information that may support future rulemaking or other
initiatives. The RFIs are related to electronic event notifications for
value-based care and care coordination, health care resiliency and
securing health care operations in a modern health care ecosystem,
improving the implementation of payer API technology through testing
and
[[Page 19897]]
certification, using technology to manage step therapy, and prior
authorization requirements for laboratory tests and durable medical
equipment, prosthetics, orthotics, and supplies (DMEPOS) items.
Electronic event notifications are valuable tools for coordinating
care in the modern health care environment, and we are seeking comment
on ways to improve this process with expanded use and content of
electronic event notifications (often referred to as admission,
discharge, and transfer, or ``ADT'' notifications). We want to
understand the types of providers or other entities that should receive
ADT notifications along with technical approaches that are currently in
use or that could be used for patient event notifications. We also seek
comments on health IT certification criteria for notification
capabilities and strengthening enforcement of ADT notification
requirements.
Hacking, ransomware, and other cybersecurity attacks on health care
systems and electronic protected health information (ePHI) present an
ever-increasing threat. These attacks have already caused, and could
continue to cause, significant disruption to the health care industry,
potentially resulting in significant harm to patients, providers,
payers, and the health care ecosystem at large. We are seeking feedback
on opportunities to strengthen, protect, and increase the resiliency of
our health care system in cybersecurity spaces to prevent and better
handle future threats. Additionally, we would like to hear about
existing standards and technologies, as well as the current role of
point-to-point connections within the health care system.
Monitoring compliance and technical conformance with standards is
critical to effective interoperability within the health care ecosystem
based on the API requirements that we have established for impacted
payers. We are seeking comment on steps that we could take to improve
oversight of payer APIs, for instance, through strengthening testing
and transparency requirements. We are also exploring opportunities to
leverage existing programs, such as the ONC Health IT Certification
Program, to ensure that API technology used by payers meets the
technical requirements we establish.
We are also seeking comments on ways to streamline the step therapy
process through technology and data sharing (such as the Payer-to-Payer
API) to allow payers access to historical patient information. We seek
comment on how technology may facilitate step therapy determinations
and improve current step therapy processes. This includes the role of
technology in evaluating and applying step therapy criteria and how
payers evaluate and honor step therapy criteria from other payers.
Prior authorization requirements for laboratory tests and DMEPOS
items have emerged, in some instances, as a barrier to care and
coverage that impacts both patients and providers. The primary issues
associated with prior authorization for laboratory tests and DMEPOS
items are coordination between providers and laboratories or DMEPOS
suppliers and the length of time approval takes for tests and
equipment. We are soliciting public comment on how prior authorization
for laboratory tests and DMEPOS items impacts patient care and provider
burden and what can be done to mitigate that burden.
C. Specific Terms Used in This Proposed Rule
Throughout this proposed rule, we use terms such as ``patient,''
``consumer,'' ``beneficiary,'' ``enrollee,'' and ``individual.'' In
this proposed rule, we use the term ``patient'' as an inclusive term.
Each CMS program may use different terms to refer to patients in
regulation. Therefore, in this proposed rule, we use ``patients''
collectively across programs. However, when discussing proposals for a
particular program, we will use specific terms applicable to
individuals covered under that program. Also, when we discuss patients,
the term includes, where applicable, a patient's personal
representative. For example, a patient or their personal representative
may access certain types of information under the proposals in this
proposed rule. However, 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. Pursuant to the ``Standards
for Privacy of Individually Identifiable Health Information'' final
rule (65 FR 82462) (hereinafter referred to as the ``HIPAA Privacy
Rule''), which appeared in the Federal Register on December 28, 2000,
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).15 16 Under the HIPAA Privacy Rule, the
individual's personal representative generally may exercise the right
to access the individual's protected health information (PHI).
---------------------------------------------------------------------------
\15\ See 45 CFR parts 160 and 164, subparts A and E.
\16\ United States Department of Health and Human Services.
(2020, January 31). Health Information and Privacy. Retrieved from
https://www.hhs.gov/hipaa/for-professionals/faq/2069/under-hipaa-when-can-a-family-member/index.html and https://www.hhs.gov/hipaa/for-professionals/faq/personal-representatives-and-minors/index.html.
---------------------------------------------------------------------------
We also use terms such as ``payer,'' ``plan,'' and ``issuer'' in
this proposed rule. Certain portions of this proposed rule are
applicable to MA organizations, state Medicaid and 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), QHP
issuers on the FFEs, including proposals for small group market QHP
issuers on the FF-SHOPs. We use the term ``impacted payer'' in the
preamble of this proposed 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
proposed rule. Notably, the term ``impacted payers'' only applies to
the CMS proposals in this proposed rule, not to the HHS proposals for
HIPAA Administrative Simplification. As discussed in section II.H. of
this proposed rule, the HIPAA Administrative Simplification proposals
would apply to HIPAA covered entities, as described in section 1172(a)
of the Act and defined in 45 CFR 160.103.
Some plans that participate in those CMS programs may not be
permitted to use prior authorization (such as Private FFS MA plans) or
may choose not to use prior authorization. Our prior authorization
proposals only apply to the extent that a payer (or plan) uses prior
authorization. Therefore, if an impacted payer does not use prior
authorization, they would not be subject to the prior authorization
proposals. However, other proposals, such as those related to the
Access APIs and standards, would apply to all types of plans under the
categories of impacted payers.
Many payers use a pharmacy benefit manager (PBM) to manage
prescription drug benefits on their behalf, including through
utilization management techniques such as prior authorization. These
proposals do not apply directly to PBMs, but we understand that, if
these proposals are finalized, PBMs may play a role in helping impacted
payers meet the requirements proposed in this rule. For example, if a
PBM is contracted by an impacted payer to manage its prescription drug
benefits, including to
[[Page 19898]]
conduct prior authorization, it may make sense for the payer to have
providers send prior authorization requests for those drugs directly to
the PBM. In that case, if finalized, the PBM would be required to
support an unexpired version of the NCPDP SCRIPT standard adopted by
the Secretary in 45 CFR 170.205(b) for the electronic prior
authorization of drugs, thereby making electronic prior authorization
available to providers and meeting the proposed requirement on behalf
of the impacted payer. Such arrangements would be permissible under
these proposals, if allowed under applicable program rules. However, we
emphasize that the ultimate responsibility for regulatory compliance
would be on impacted payers themselves.
Although Medicare FFS is not directly affected by the CMS
interoperability regulations, CMS continues to explore and initiate
opportunities to enhance electronic prior authorization within the
Medicare FFS program, as appropriate, including those for drugs. The
Medicare FFS program has developed a Prior Authorization API that makes
available Medicare coverage criteria rules and documentation
requirements to providers. This API helps providers determine whether
prior authorization is required and identify the necessary
documentation. The API also facilitates the extraction of relevant
clinical information from the provider's electronic health record (EHR)
to compile the required documentation and enables the electronic
submission of prior authorization requests in a structured format to
CMS review contractors. We want to ensure that Medicare beneficiaries
can benefit from the policies we are proposing, regardless of their
coverage or delivery system. We intend for the Medicare FFS program to
be a market leader on electronic prior authorization and therefore,
seek comment throughout this proposed rule on how these proposals could
apply to Medicare FFS. In addition, Medicare FFS is a HIPAA covered
entity, subject to the HIPAA Administrative Simplification statutory
provisions. Therefore, if HHS' proposals in section II.H. are
finalized, Medicare FFS would be subject to the electronic transaction
standards adopted by the Secretary.
As was the case for the 2020 CMS Interoperability and Patient
Access and the 2024 CMS Interoperability and Prior Authorization final
rules, Medicare Supplemental Insurance plans (commonly known as
Medigap) are not impacted payers. Medigap plans do not perform prior
authorization but rely on coverage determinations by Medicare FFS. In
addition, as stated in the 2020 CMS Interoperability and Patient Access
final rule, Program of All-Inclusive Care for the Elderly (PACE)
organizations are not impacted payers under the CMS interoperability
rules (85 FR 25621).
For purposes of this proposed rule, references to QHP issuers on
the FFEs exclude issuers offering stand-alone dental plans (SADPs) on
the FFEs. In the 2024 CMS Interoperability and Prior Authorization
final rule, we did not propose or finalize requirements applicable to
SADP issuers because they have relatively lower enrollment and premium
intake compared to individual market QHP issuers on the FFEs. In
addition, we had concerns that requiring those plans to comply with the
final rule's policies could result in those issuers no longer
participating in the FFEs, which would not be in the best interest of
enrollees (89 FR 8766). Several public comments also made this point,
that a requirement for SADP issuers to implement the required FHIR APIs
would impose burden with minimal or no benefit (85 FR 25552 and 25553).
Additionally, SADP issuers are not required to cover prescription
drugs. When a dental provider writes a prescription, that drug is
generally processed through the enrollee's non-dental medical benefit.
Although dental providers may provide medication as part of a dental
procedure, such as local anesthesia, it is our understanding that this
is generally part of the dental procedure itself and therefore dental
providers are reimbursed for the service as a bundle rather than
through a separate claim for drugs. Therefore, we are not proposing to
apply requirements to SADP issuers, but we solicit comment on whether
the considerations described previously do in fact diminish the need
for electronic prior authorization requirements and prior authorization
process requirements for SADP issuers. We solicit comments on whether
we should consider future rulemaking to apply these proposed
requirements and those finalized in the 2024 CMS Interoperability and
Prior Authorization final rule to SADP issuers.
For the purposes of this proposed rule, FFEs include FFEs in states
that perform plan management functions, and as noted in the 2024 CMS
Interoperability and Prior Authorization final rule, State-based
Exchanges on the Federal Platform (SBE-FPs) are not FFEs, even though
patients in those states enroll in coverage through HealthCare.gov (89
FR 8761). Hence, issuers in SBE-FPs would not be impacted payers
subject to the CMS proposals in this proposed rule. We believe that it
is appropriate at this time to continue to exclude issuers on the
State-based Exchanges (SBEs), including SBE-FPs, as impacted payers to
keep with prior interoperability rulemaking. As we assess the
effectiveness of interoperability policies, we will consider whether
future rulemaking to include those types of issuers as impacted payers
is appropriate, as we are proposing now for small group market QHP
issuers on the FF-SHOPs. Importantly, we will be informed by the
Patient Access API usage metrics required in 45 CFR 156.221(f), and, if
finalized, the proposed Provider Access, Payer-to-Payer, and Prior
Authorization API usage metrics discussed in section II.F.2.c. of this
proposed rule. This data, as well as information we receive from
issuers applying for QHP certification about their interoperability
activities, will help us to understand how patients, providers, and
payers use these tools and the success of current requirements. We also
solicit comment in this proposed rule on whether to consider future
rulemaking to extend these proposals, and those policies finalized in
the 2020 CMS Interoperability and Patient Access and the 2024 CMS
Interoperability and Prior Authorization final rules, to issuers that
offer coverage through SBE-FPs, SBEs, or both. In the 2024 CMS
Interoperability and Prior Authorization final rule, we encouraged
these Exchanges to consider adopting similar requirements (89 FR 8761),
and, in this proposed rule, we solicit comment on the extent to which
they have or may do so, as well as potential feasible deadlines for
issuers in those Exchanges to implement interoperability requirements,
so their enrollees can benefit from access to their health care data
and more efficient and timely prior authorization processes.
In this proposed rule, we use the terms ``provider'' and
``supplier'' to mean individuals, organizations, and institutions that
provide or furnish health services, such as clinicians (that is,
physicians and other practitioners), hospitals, skilled nursing
facilities (SNFs), home health agencies, hospice settings,
laboratories, pharmacies, suppliers of DMEPOS items, and community-
based organizations, as appropriate in the context used. Similarly, we
are generally not using the term ``prescriber'' in this rule, as
``provider'' is a broader term that includes any individual who
authorizes a particular prescription or order. Our proposals related to
the prior authorization of drugs are discussed in the context of
providers who request
[[Page 19899]]
prior authorization from a payer, which may or may not be the actual
prescriber.
Many of the existing and proposed interoperability standards are
based on API technology. An API is a set of rules that lets different
software systems communicate with each other. It defines how one
program (a client, often an app) can request data or services from
another system (a server), and how the response should be structured.
APIs are commonly used to connect apps. For example, a health app can
use an API implemented within a payer's system to request and receive a
specific patient's data. This allows developers to build on and
communicate with existing systems without needing to understand their
internal workings. APIs are essential for building modern, integrated
digital experiences in a variety of industries, including health care,
banking, and e-commerce.\17\
---------------------------------------------------------------------------
\17\ The Office of the National Coordinator for Health
Information Technology. (n.d.). Application Programming Interfaces.
Retrieved from https://www.healthit.gov/api-education-module/story_html5.html.
---------------------------------------------------------------------------
Throughout this rule, we collectively refer to the APIs finalized
in the 2020 CMS Interoperability and Patient Access and 2024 CMS
Interoperability and Prior Authorization final rules--the Patient
Access, Provider Directory, Provider Access, Payer-to-Payer, and Prior
Authorization APIs--as the ``interoperability APIs.'' When we refer to
``access APIs,'' we mean those that are used primarily to access a
specific patient's health record, the Patient Access, Provider Access,
and Payer-to-Payer APIs. Each of the interoperability APIs are required
to be built using the FHIR standard. FHIR is a standards framework
created by HL7 to electronically exchange health information via APIs
using the latest technology standards. FHIR defines categories of data,
called ``Resources'' that, individually or in combination, satisfy most
common use cases. The Patient Resource, for example, includes
demographic data related to a patient, such as their name, address, and
phone number. Using these FHIR Resources enables granular data
retrieval, so that a request returns just the relevant data rather than
a full record or document that itself must then be searched. Once they
are modified for specific requirements using FHIR's built-in
capabilities, combinations of Resources are brought together in an IG
to address a specific use case, such as a provider directory or prior
authorization. This structure lends itself well to expansion beyond
FHIR's core capabilities.\18\
---------------------------------------------------------------------------
\18\ The Office of the National Coordinator for Health
Information Technology. (n.d.). What Is HL7[supreg] FHIR[supreg]?
Retrieved from https://www.healthit.gov/sites/default/files/page/2021-04/What%20Is%20FHIR%20Fact%20Sheet.pdf.
---------------------------------------------------------------------------
As in the 2024 CMS Interoperability and Prior Authorization final
rule, we use the term ``prior authorization'' to refer to the process
through which a provider, such as an individual clinician, acute care
hospital, ambulatory surgical center, or clinic, obtains approval from
a payer before providing care (89 FR 8761). A prior authorization is
made up of two parts--a request from a provider and a decision/response
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.'' Payers establish prior
authorization requirements to help control costs and ensure payment
accuracy by verifying that an item, service, or drug is medically
necessary for the specific patient, meets coverage criteria, and, for
some payers, is consistent with standards of care before being
provided. As we explained in the 2024 CMS Interoperability and Prior
Authorization final rule, prior authorization has an important place in
the health care system for utilization management, but the process and
delays continue to be challenging for providers (89 FR 8914).
Furthermore, issuers with complex payer policies, inconsistent use of
electronic standards, and other technical barriers create provider
workflow challenges and an environment in which the prior authorization
process is a primary source of burden for both providers and payers and
can create a health risk for patients if they don't receive medically
necessary care in a timely manner.
In this proposed rule, we refer to two categories of drugs--``drugs
covered under a pharmacy benefit'' and ``drugs covered under a medical
benefit.'' We acknowledge that these terms do not have statutory or
regulatory correlations for impacted payers other than MA organizations
(based on the distinctions between Parts A, B, and D). For instance,
for Medicaid and CHIP, we propose that the distinction can be
distinguished by the systems used to process claims. We are using
``drugs covered under a pharmacy benefit'' to reflect how the NCPDP
SCRIPT standard describes the category of drugs within its scope.\19\
Conversely, we are using ``drugs covered under a medical benefit'' to
describe the category of drugs for which the NCPDP SCRIPT standard is
not to be used, pursuant to the IG, but is within the scope of the
Prior Authorization API, based on instructions in the PAS IG, which
states that the IG ``SHOULD NOT be used for any medication that is
covered under a pharmacy benefit where prior authorization is provided
by another electronic exchange process (for example, NCPDP SCRIPT).''
These standards and their scopes are further discussed in sections
II.A.2. and II.A.3. of this proposed rule. We request comment on
whether there are drugs covered by any impacted payer that may not fit
into the categories ``drugs covered under a medical benefit'' and
``drugs covered under a pharmacy benefit'' and how such drugs can be
included in one of those two categories.
---------------------------------------------------------------------------
\19\ See 89 FR 51262.
---------------------------------------------------------------------------
When we refer to both drugs covered under a pharmacy benefit and
drugs covered under a medical benefit, throughout this rule we use the
terms ``all drugs'' or ``any drugs.'' Further discussion of these terms
is included in the discussion of those standards in section II.A. of
this proposed rule.
HL7 is an American National Standards Institute (ANSI)-accredited
SDO that develops the FHIR standard and the IGs referenced throughout
this proposed rule. In addition, they are a designated standard
maintenance organization (DSMO), designated by the Secretary under 45
CFR 162.910.\20\ NCPDP is a non-profit ANSI-accredited SDO supporting
standards for the drug supply chain. The NCPDP SCRIPT, F&B, and RTPB
standards are established standards that can support prior
authorization and other prescription information exchange tasks for
drugs covered under a pharmacy benefit, as described further in
sections II.A. and II.B. of this proposed rule.
---------------------------------------------------------------------------
\20\ As announced in the Federal Register in 65 FR 50373.
---------------------------------------------------------------------------
D. Severability
In this proposed rule, CMS and HHS propose a variety of policies
related to prior authorization. To the extent a court may enjoin one
provision of this final rule, CMS and HHS propose that the other
provisions should remain in effect, ensuring the continuity of the
regulations. We propose that any provision of the requirements of this
rule that is held to be invalid or unenforceable by its terms or as
applied to any person or circumstance would be construed so as to
continue to give maximum effect to the provision permitted by law,
unless such holding is one of utter invalidity or unenforceability, in
which event we
[[Page 19900]]
propose that the provision would be severable from the other provisions
of this rulemaking and would not affect the remainder thereof or the
application of the provision to persons not similarly situated or to
dissimilar circumstances.
We propose that if any section, subsection, sentence, clause,
phrase, word, provision, or application of this final rule shall be
found to be invalid, illegal, unconstitutional, or unenforceable, that
finding shall not affect or undermine the validity of any other
section, subsection, sentence, clause, phrase, word, provision, or
application which can be enforced without the use of the offending
provision. We request comments from the public on severability,
particularly which policies could be severable, if finalized, and how
the other policies in a final rule would operate absent those
particular provisions.
II. Provisions of the Proposed Rule
A. Interoperability Standards for APIs
1. Background
Standards set the foundation for consistent technical
implementation to support interoperable exchange of information, which
facilitates efficient, safe, and high-quality care for patients. In the
2024 CMS Interoperability and Prior Authorization final rule, we
require impacted payers to use API technology conformant with specific
standards in 45 CFR 170.215 applicable to the interoperability APIs (89
FR 8927). We finalized requirements to use these standards through
cross-references to 45 CFR 170, subpart B, where ONC adopts standards
that may be used across HHS programs. Those standards, which are
applicable to different APIs, include the following:
Health Level Seven (HL7[supreg]) Fast Healthcare
Interoperability Resources (FHIR[supreg]), Release 4.0.1 in 45 CFR
170.215(a)(1);
HL7 FHIR US Core IG, Standard for Trial Use (STU) 3.1.1 in
45 CFR 170.215(b)(1)(i) (US Core IG);
HL7 Substitutable Medical Applications, Reusable
Technologies (SMART) Application Launch Framework IG, Release 1.0.0 in
45 CFR 170.215(c)(1) (SMART App Launch IG);
FHIR Bulk Data Access (Flat FHIR) IG, v1.0.0: STU 1 in 45
CFR 170.215(d)(1) (Bulk Data Access IG); and
OpenID Connect Core 1.0, incorporating errata set 1, in 45
CFR 170.215(e)(1) (OpenID Connect Core).
The specific standards for the interoperability APIs are listed in
Table H3 of the 2024 CMS Interoperability and Prior Authorization final
rule (89 FR 8945). In that same final rule, we finalized policies that
allow impacted payers to use updated standards for these APIs, if
specific conditions are met, which are similar to policies previously
finalized in the 2020 CMS Interoperability and Patient Access final
rule.\21\ We also strongly recommended payers use additional IGs for
each API, listed in Table H3 (89 FR 8945).
---------------------------------------------------------------------------
\21\ See 42 CFR 422.119(c)(4)(ii) for MA organizations, 42 CFR
431.60(c)(4)(ii) for state Medicaid FFS programs; through cross
references to 42 CFR 431.60 in 42 CFR 438.242(b)(5), 42 CFR
431.61(a) in 42 CFR 438.242(b)(7), 42 CFR 431.61(b)(1) in 42 CFR
438.242(b)(7), 42 CFR 431.70 in 42 CFR 438.242(b)(6), 42 CFR
431.80(b) in 42 CFR 438.242(b)(7) for Medicaid managed care plans;
42 CFR 457.730(c)(4)(ii) for state CHIP FFS programs; through cross
reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed
care entities; and 45 CFR 156.221(c)(4)(ii) for individual market
QHP issuers.
---------------------------------------------------------------------------
The ``Health Data, Technology, and Interoperability: Certification
Program Updates, Algorithm Transparency, and Information Sharing''
proposed and final rules (88 FR 23746 and 89 FR 1192) (hereinafter
referred to as the ``HTI-1 proposed rule'' and the ``HTI-1 final
rule''), appeared in the Federal Register on April 18, 2023 and January
9, 2024, respectively. In that rulemaking, which took place between the
2022 and 2024 CMS Interoperability and Prior Authorization proposed and
final rules, the Secretary adopted updated versions of several
standards set forth in 45 CFR 170.215 and finalized expiration dates
for previous versions of standards. As a result, the 2024 CMS
Interoperability and Prior Authorization final rule finalized
requirements for impacted payers to use standards in 45 CFR 170.215
available at the time of the 2022 CMS Interoperability and Prior
Authorization proposed rule, and not versions subsequently proposed and
finalized by the Secretary. Some of those required versions now have
established expiration dates.
In the 2024 CMS Interoperability and Prior Authorization final
rule, we finalized requirements to use the versions of the standards in
45 CFR 170.215 that we had proposed, not those that were newly adopted
in the HT1-1 final rule. For example, when the 2022 CMS
Interoperability and Prior Authorization proposed rule appeared in the
Federal Register on December 13, 2022, the US Core IG, STU 3.1.1 and
SMART App Launch IG, Release 1.0.0 were the current versions of these
standards. In the 2024 CMS Interoperability and Prior Authorization
final rule, we finalized a requirement that impacted payers must use
the versions set forth in the proposed rule (which had not yet expired
on the date the final rule appeared in the Federal Register), although
the Secretary adopted newer versions (US Core IG, STU 6.1.0 in 45 CFR
170.215(b)(1)(ii) and SMART App Launch IG, Release 2.0.0 in 45 CFR
170.215(c)(2)) in the HTI-1 final rule (89 FR 1284, 1285, and 1291).
The Secretary also finalized a January 1, 2026 expiration date for
the US Core IG, STU 3.1.1 (in 45 CFR 170.215(b)(1)(i)) and the SMART
App Launch IG, Release 1.0.0 (in 45 CFR 170.215(c)(1)). Upon the
specified expiration date, the expired versions of the standards are no
longer eligible for certification of Health IT Modules through the ONC
Health IT Certification Program (89 FR 1285 and 1292). As of this
proposed rule, there are two adopted versions of the US Core IG: (1)
the US Core IG, STU 3.1.1 (in 45 CFR 170.215(b)(1)(i)), which expired
on January 1, 2026, and (2) the US Core IG, STU 6.1.0 (in 45 CFR
170.215(b)(1)(ii)) without an expiration date.
Through our proposals in this rule, we are seeking to align with
the regulatory framework established by ONC to adopt, update, and
expire health IT standards incorporated by reference in the Code of
Federal Regulations (CFR). Accordingly, under our proposals, if ONC
establishes an expiration date for an adopted standard, or for a
specific version thereof, in subpart B of 45 CFR part 170, upon the
specified expiration date, impacted payers would no longer be permitted
to use that standard or version to meet the interoperability
requirements. We believe these proposals will support greater alignment
across interoperability standards requirements that impact payers,
health care providers, health IT developers and other parties.
In the 2020 CMS Interoperability and Patient Access and 2024 CMS
Interoperability and Prior Authorization final rules, we also finalized
policies that allow impacted payers to voluntarily conform with updated
versions of the standards we have required payers to use in 45 CFR
170.213 and 45 CFR 170.215 (such as the US Core IG and SMART App Launch
IG), provided that (1) the National Coordinator for Health Information
Technology (hereinafter referred to as the ``National Coordinator'')
has approved the updated version for use in the ONC Health IT
Certification Program; (2) the updated version of the standard does not
disrupt an end user's ability to access the required data via that API;
and (3) the updated standard is not prohibited by law (85 FR 25532 and
89 FR 8946). In addition, impacted payers may use an
[[Page 19901]]
updated version if required by other applicable law.\22\ Under these
provisions, impacted payers may upgrade to newer versions of the
required standards, subject to the specified limiting conditions (85 FR
25532 and 89 FR 8946).
---------------------------------------------------------------------------
\22\ See 42 CFR 422.119(c)(4)(ii) for MA organizations, 42 CFR
431.60(c)(4)(ii) for state Medicaid FFS programs; through cross
references to 42 CFR 431.60 in 42 CFR 438.242(b)(5), 42 CFR
431.61(a) in 42 CFR 438.242(b)(7), 42 CFR 431.61(b)(1) in 42 CFR
438.242(b)(7), 42 CFR 431.70 in 42 CFR 438.242(b)(6), 42 CFR
431.80(b) in 42 CFR 438.242(b)(7) for Medicaid managed care plans;
42 CFR 457.730(c)(4)(ii) for state CHIP FFS programs; through cross
reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed
care entities; and 45 CFR 156.221(c)(4)(ii) for individual market
QHP issuers.
---------------------------------------------------------------------------
Finally, in the 2022 CMS Interoperability and Prior Authorization
proposed rule, we did not propose, nor did we finalize any requirements
in the 2024 CMS Interoperability and Prior Authorization final rule,
that applied to any drugs because, as we discussed in the proposed and
final rules, the processes and standards for prior authorization of
drugs differ from the non-drug items and services included in our final
policies (89 FR 8762). However, we received many public comments in
response to the 2022 CMS Interoperability and Prior Authorization
proposed rule, as well as additional feedback from providers, payers,
and SDOs, indicating that while some prior authorization processes and
standards for drugs currently exist, patients and other stakeholders
would benefit from consistent requirements to provide patients timely
access to drugs, and from a streamlined electronic prior authorization
process that alleviates burden for providers and impacted payers.
2. NCPDP Standards for Prior Authorization of Drugs Covered Under a
Pharmacy Benefit
a. NCPDP SCRIPT Standard
After considering stakeholder comments on the 2022 CMS
Interoperability and Prior Authorization proposed rule, our goals for
interoperability across impacted payers, and the technical standards
available to support electronic prior authorization for drugs, we are
now proposing to require impacted payers to support electronic prior
authorization for drugs. We are proposing to require impacted payers to
use either the FHIR standards and IGs required for the Prior
Authorization API or the NCPDP SCRIPT standard depending upon whether
the drugs are covered under a medical benefit or a pharmacy benefit, as
detailed by the standards implementation specifications, and further
discussed below.
As discussed further in section II.B. of this proposed rule, we are
proposing to require state Medicaid and CHIP FFS programs, Medicaid
managed care plans, CHIP managed care entities, and QHP issuers on the
FFEs to support an unexpired version of the NCPDP SCRIPT Standard
Implementation Guide (NCPDP SCRIPT) \23\ adopted by the Secretary in 45
CFR 170.205(b) for the electronic prior authorization of drugs covered
under a pharmacy benefit. In the ``Medicare Program; Medicare
Prescription Drug Benefit Program; Health Information Technology
Standards and Implementation Specifications'' final rule (89 FR 51238)
(hereinafter referred to as the ``2024 Part D and Health IT Standards''
final rule), which appeared in the Federal Register on June 17, 2024,
ONC finalized a January 1, 2028 expiration date for the NCPDP SCRIPT
Standard Implementation Guide, Version 2017071 in 45 CFR 170.205(b)(1),
and adopted the NCPDP SCRIPT Standard Implementation Guide, Version
2023011 in 45 CFR 170.205(b)(2) (89 FR 51244 and 51258-51259). Like the
approach discussed above for required standards for payer APIs, our
proposals in this rule seek to align to ONC's framework to adopt and
update versions of the SCRIPT standard. Under these proposals, if ONC
establishes an expiration date for the NCPDP SCRIPT standard in 45 CFR
170.205(b), or for a specific version thereof, upon the specified
expiration date, impacted payers would no longer be permitted to use
that standard or version to meet the interoperability requirements. We
are proposing an October 1, 2027 compliance date for this proposed
requirement.
---------------------------------------------------------------------------
\23\ NCPDP SCRIPT Standard IG, Versions 2017071 and 2023011.
NCPDP SCRIPT IGs are available to NCPDP members for free and to non-
members for a fee at https://standards.ncpdp.org/Access-to-Standards.aspx.
---------------------------------------------------------------------------
NCPDP is a not-for-profit ANSI-accredited SDO representing the
pharmacy services industry and is responsible for developing and
maintaining standards for the exchange of information between
providers, pharmacies, and payers. NCPDP is an SDO for pharmacy
standards, including billing, subrogation, formulary and benefits,
electronic prior authorization, electronic prescribing, and real-time
benefit checks. The NCPDP SCRIPT standard can be used for multiple
transactions between entities during the prescribing and dispensing
processes including between providers, pharmacies, and payers for
electronic prescribing; electronic prior authorization; and medication
history exchange. This proposed rule focuses only on the electronic
prior authorization functionality of the standard.
The NCPDP SCRIPT standard is the most widely used standard by
providers and payers for electronic prescribing and electronic prior
authorization for drugs covered under a pharmacy benefit. The NCPDP
SCRIPT standard can be used by providers to submit a prior
authorization request to the payer (including the payer's processor or
PBM, as appropriate). The NCPDP SCRIPT standard is designed
specifically and solely for a category of drugs, which are described as
``drugs covered under a pharmacy benefit.'' \24\ The transactions in
the NCPDP SCRIPT standards for electronic prior authorization are not
intended to be used to communicate information for medical items or
services or drugs covered under a medical (non-pharmacy) benefit.
---------------------------------------------------------------------------
\24\ NCPDP (2015, August). NCPDP SCRIPT Standard Supports
Electronic Prior Authorization (ePA) Fact Sheet. Retrieved from
https://ncpdp.org/NCPDP/media/pdf/NCPDP_ePA_Fact_Sheet.doc.
---------------------------------------------------------------------------
(1) Scope of the NCPDP SCRIPT Standard and FHIR IGs for Electronic
Prior Authorization of Drugs
In the 2024 CMS Interoperability and Prior Authorization final
rule, we finalized a policy that established HL7 FHIR, Release 4.0.1 as
the API base standard for the Prior Authorization API.\25\
Specifically, we finalized that certain impacted payers must implement
and maintain the Prior Authorization API, and that the Prior
Authorization API use the HL7 FHIR standard, Release 4.0.1 for
electronic prior authorization of non-drug items and services (89 FR
8859 and 8861). We also strongly recommended that impacted payers use
the HL7 FHIR Da Vinci Coverage Requirements Discovery (CRD) IG, the HL7
FHIR Da Vinci Documentation Templates and Rules (DTR) IG, and HL7 FHIR
Da Vinci Prior Authorization Support (PAS) IG when implementing the
Prior Authorization API (89 FR 8863). These FHIR IGs are technically
capable of supporting prior authorization of non-drug items and
services and drugs covered under a medical benefit. The FHIR
specifications, specifically the PAS IG, states that it ``SHOULD NOT be
used for any Medication that is covered under a pharmacy benefit where
prior authorization is provided by another electronic exchange process
(for
[[Page 19902]]
example, NCPDP SCRIPT).'' 26 27 That directive is intended
to differentiate the scope of the FHIR IGs for prior authorization from
the scope of the NCPDP SCRIPT standard, which is used for prior
authorization of drugs under a pharmacy benefit.
---------------------------------------------------------------------------
\25\ See 45 CFR 170.215(a)(1).
\26\ See section II.A.4.a.6. of this proposed rule for a
description of the CRD, DTR, and PAS IGs and section II.A.4.b.4. of
this proposed rule regarding CMS's proposal to require use of these
IGs for the Prior Authorization API.
\27\ Health Level Seven International (2024, December 20). Da
Vinci Prior Authorization Support (PAS) FHIR: Use Cases and
Overview. Retrieved from https://hl7.org/fhir/us/davinci-pas/usecases.html.
---------------------------------------------------------------------------
The 2024 Part D and Health IT Standards final rule requires
prescribers, dispensers, and Part D sponsors (as part of their
electronic prescription drug programs) to use a version of the NCPDP
SCRIPT standard adopted in 170.205(b) to transmit electronic prior
authorization for covered Part D drugs for Part D eligible individuals
(89 FR 51239). Any drugs covered by MA plans other than covered Part D
drugs, that is, drugs payable under Part A or Part B, are not within
the scope of the NCPDP SCRIPT standard and instead are within the scope
of the Prior Authorization API (using HL7 FHIR, Release 4.0.1).
However, we acknowledge that for state Medicaid and CHIP FFS programs,
Medicaid managed care plans, CHIP managed care entities, and QHP
issuers on the FFEs, there is currently no statutory or regulatory
definition that distinguishes between drugs covered under a pharmacy
benefit and drugs covered under a medical benefit, as described in the
NCPDP SCRIPT or Da Vinci FHIR IGs for electronic prior authorization.
Therefore, if these proposals, found in sections II.A.2. and II.B.3. of
this proposed rule, are finalized as proposed, we anticipate that state
Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP
managed care entities, and QHP issuers on the FFEs would analyze their
list of covered drugs for which they require prior authorization and
determine whether electronic prior authorization for each drug could be
supported by the NCPDP SCRIPT standard or should instead be provided
through the Prior Authorization API. Drugs covered under a pharmacy
benefit, which would use the NCPDP SCRIPT standard for electronic prior
authorization requests, are often those medications dispensed at a
retail pharmacy. Drugs covered under a medical benefit, which would use
the Prior Authorization API, are often those dispensed by a medical
provider in a health care setting. We understand that the same drug
could fall into different categories for different impacted payers
based on their terms of coverage, but we do not think that would
undermine this proposal's effectiveness because impacted payers could
indicate which method a provider should use to submit a particular
prior authorization.
The CRD IG has the technical capability to return specific coverage
information through the ``CoverageInformation'' extension, and we seek
comment on how the ``CoverageInformation'' extension could best be
utilized to indicate whether a particular drug is covered under a
medical benefit and, therefore, that the Prior Authorization API should
be used for electronic prior authorization. Similarly, we seek comment
on whether the impacted payers could utilize the NCPDP Real-Time
Prescription Benefit (RTPB) standard to indicate whether a drug is
covered under a medical benefit. We also solicit comment on whether
there are existing technical solutions or methods that show promise but
would require additional development that impacted payers could utilize
to indicate to providers how a prior authorization request for a drug
should be submitted. In addition, we discuss below how the NCPDP
Formulary & Benefit (F&B) or NCPDP RTPB standards could be used.
(2) Transactions
As of the date this proposed rule appears in the Federal Register,
providers can use the NCPDP SCRIPT standard versions 2017071 and
2023011 for multiple transactions associated with the electronic prior
authorization of drugs covered under a pharmacy benefit. The SCRIPT
standard can be used in conjunction with the NCPDP F&B or NCPDP RTPB
standards, to support a complete workflow around determining whether
prior authorization is required. Additionally, these versions of the
NCPDP SCRIPT standard include transactions for requesting prior
authorization for drugs, communicating decisions, and exchanging
information regarding appeals. The NCPDP SCRIPT standard version
2023011 has numerous updates from version 20217071, including that it
can facilitate a three-way transaction to notify providers and
pharmacies when prior authorization has been requested.28 29
The NCPDP SCRIPT standard versions 2017071 and 2023011 support both the
workflow to determine whether prior authorization is required and the
coverage and documentation requirements to receive a decision, as well
as the technical processes to send prior authorization requests from a
provider to a payer, followed by the payer's responses (for example,
approved, denied, and additional information required). The NCPDP
SCRIPT standard versions 2017071 and 2023011 also support features that
minimize manual data entry by the provider based on information in the
EHR or other health IT system. These functions should reduce the time a
provider or their administrative staff spend reviewing and responding
to payer documentation requirements for prior authorization decisions.
The NCPDP SCRIPT standard versions 2017071 and 2023011 can send
information to a payer (or the payer's PBM) in real time, which should
result in faster prior authorization approvals and therefore faster
patient access to medications compared to manual prior authorization
processes. We note that the NCPDP SCRIPT standard version 2017071
expires on January 1, 2028, which is shortly after the proposed
compliance date for certain impacted payers to support an unexpired
version of the NCPDP SCRIPT standard adopted in 45 CFR 170.205(b). If
our proposal is finalized, we would expect those impacted payers to
utilize only the NCPDP SCRIPT standard versions 2023011 after January
1, 2028 to meet the proposed requirements.
---------------------------------------------------------------------------
\28\ NCPDP. (2022, January 14). Re: Next version of SCRIPT
Standard Recommendations. Retrieved from https://standards.ncpdp.org/Standards/media/pdf/Correspondence/2022/202201NCPDP-SCRIPTNextVersionLetter.pdf.
\29\ NCPDP. (2023, February 13). Re: Proposed Rule CMS-4201-P.
Retrieved from https://standards.ncpdp.org/Standards/media/pdf/Correspondence/2023/20230213_To_CMS_CMS_4201_P_NPRM.pdf.
---------------------------------------------------------------------------
Therefore, we are proposing to require that state Medicaid and CHIP
FFS programs, Medicaid managed care plans, CHIP managed care entities,
and QHP issuers on the FFEs support an unexpired version of the NCPDP
SCRIPT standard adopted by the Secretary in 45 CFR 170.205(b) for the
following transactions to support electronic prior authorization of
drugs covered under a pharmacy benefit:
[[Page 19903]]
[GRAPHIC] [TIFF OMITTED] TP14AP26.273
We emphasize that our proposals in this rule would not impose
requirements directly on providers. We are not proposing to require
providers to use the NCPDP SCRIPT standards or to conduct electronic
prior authorization, but we acknowledge other HHS programs aim to
support providers' ability to conduct electronic prior authorization
using the NCPDP SCRIPT standard.
The ``Health Data, Technology, and Interoperability: Patient
Engagement, Information Sharing, and Public Health Interoperability:
Electronic Prescribing, Real-Time Prescription Benefit and Electronic
Prior Authorization'' final rule (hereinafter referred to as the ``HTI-
4 final rule'') (90 FR 36536) appeared in the Federal Register as part
of the ``Medicare Program; Hospital Inpatient Prospective Payment
Systems for Acute Care Hospitals (IPPS) and the Long-Term Care Hospital
Prospective Payment System and Policy Changes and Fiscal Year (FY) 2026
Rates; Changes to the FY 2025 IPPS Rates Due to Court Decision;
Requirements for Quality Programs; and Other Policy Changes; Health
Data, Technology, and Interoperability: Electronic Prescribing, Real-
Time Prescription Benefit and Electronic Prior Authorization'' final
rule (hereinafter collectively referred to as the ``FY 2026 IPPS/LTCH
final rule'') (90 FR 36536), which appeared in the Federal Register on
August 4, 2025. In the HTI-4 final rule, ONC finalized that Health IT
Modules certified under the ONC Health IT Certification Program to 45
CFR 170.315(b)(3) are permitted to maintain conformance with either
version 2017071 or version 2023011 of the NCPDP SCRIPT standard up to
and including December 31, 2027. On and after January 1, 2028, all
Health IT Modules certified to 45 CFR 170.315(b)(3) are required to
support the NCPDP SCRIPT standard version 2023011. ONC also finalized
that Health IT Modules seeking certification to the updated
``electronic prescribing'' health IT certification criterion in 45 CFR
170.315(b)(3) using the NCPDP SCRIPT standard version 2023011 must
support certain electronic prior authorization transactions by January
1, 2028 (90 FR 36541).
Eligible hospitals and CAHs that participate in the Medicare
Promoting Interoperability Program and MIPS eligible clinicians that
participate in the MIPS Promoting Interoperability performance category
must use certified EHR technology (42 CFR 495.4, 495.24(f)(1), and
414.1375(b)(1)). As provided in 42 CFR 414.1305 and 42 CFR 495.4, we
define certified EHR technology (CEHRT) for these programs as EHR
technology that has been certified under the ONC Health IT
Certification Program to meet the 2015 Edition Base EHR definition or
subsequent Base EHR definition \30\ and
[[Page 19904]]
has been certified to certain ONC health IT certification criteria,
adopted in 45 CFR 170.315, as necessary to report on objectives and
measures in the Medicare Promoting Interoperability Program and the
MIPS Promoting Interoperability performance category. To complete the
measures under the Electronic Prescribing objectives in those programs,
eligible hospitals, CAHs, and MIPS eligible clinicians must use CEHRT
certified to the ``electronic prescribing'' criterion in 45 CFR
170.315(b)(3).\31\ Once their Health IT Module is certified to the
``electronic prescribing'' criterion finalized in the HTI-4 final rule,
to complete the relevant measure requirements, participants in these
programs are required to meaningfully use certified health IT capable
of electronic prior authorization for prescription drugs using the
NCPDP SCRIPT standard version 2023011 by January 1, 2028.
---------------------------------------------------------------------------
\30\ Base EHR means an electronic record of health-related
information on an individual that (1) Includes patient demographic
and clinical health information, such as medical history and problem
lists; (2) Has the capacity to provide clinical decision support;
support physician order entry; capture and query information
relevant to healthcare quality; exchange electronic health
information with, and integrate such information from other sources;
and (3) Has been certified to the certification criteria adopted by
the Secretary in all of the following: section 170.315(a)(1), (2),
or (3); (a)(5) and (14), (b)(1), (c)(1), and (g)(7), (9), (10); and
(h)(1) or (2); section 170.315(a)(9) or (b)(11) for the period up to
and including December 31, 2024; section 170.315(b)(11) on and after
January 1, 2025; section 170.315(b)(4) on and after January 1, 2028
(see 45 CFR 170.102).
\31\ For eligible hospitals and CAHs, see the FY 2026 IPPS/LTCH
final rule (89 FR 69615); for MIPS eligible clinicians, see the CY
2025 Medicare Physician Fee Schedule final rule (89 FR 98417-98427).
---------------------------------------------------------------------------
We believe that providers would embrace electronic prior
authorization using the NCPDP SCRIPT standard, as electronic prior
authorization is less burdensome than manual prior authorization, as
commenters told CMS in response to the 2022 CMS Interoperability and
Prior Authorization proposed rule (89 FR 8765). In section II.C.4. of
this proposed rule, we propose to require impacted payers to conduct
electronic prior authorization using the NCPDP SCRIPT standard, which
supports CMS's interoperability goals by reducing burden on providers
and impacted payers. Requiring impacted payers to support the NCPDP
SCRIPT standard also aligns with requirements for Medicare Part D
prescribers, dispensers, and Part D sponsors, as finalized in the 2024
Part D and Health IT Standards final rule (89 FR 51238) and previous
rulemaking, and enables other payers and providers to benefit from
consistent standards.
b. NCPDP Formulary & Benefit Standard
The NCPDP F&B standard complements standards utilized for
electronic prescribing, electronic prior authorization, and real-time
prescription benefit applications, including the NCPDP SCRIPT standard,
by providing formulary and benefit information at the health plan
level. As discussed in section II.B. in this proposed rule, we are
proposing to require impacted payers to support an unexpired version of
the NCPDP F&B standard adopted by the Secretary in 45 CFR 170.205(u),
for providers to use in their prior authorization workflow for drugs
covered under a pharmacy benefit. In the 2024 Part D and Health IT
Standards final rule, the Secretary adopted the NCPDP F&B standard
version 60 in 45 CFR 170.205(u)(1) (89 FR 51260). This is the most
recently published and adopted version of the standard as of the date
this proposed rule appears in the Federal Register. Accordingly, if ONC
establishes an expiration date for the NCPDP F&B standard or for a
specific version thereof, upon the specified expiration date, impacted
payers would no longer be permitted to use that standard or version to
meet the interoperability requirements, and would be required to use
another unexpired version adopted by the Secretary in 45 CFR
170.205(u). We are proposing an October 1, 2027 compliance date for
this proposed requirement.
If this proposal is finalized, impacted payers could use an
unexpired version of the NCPDP F&B standard adopted by the Secretary to
provide a range of formulary and benefit information, such as formulary
status, preferred alternatives, benefit coverage, and estimated co-pay
information to end users, including providers, at the time of
prescribing. This formulary and benefit information enables providers
to determine at the point of prescribing whether a particular drug is
covered and whether the impacted payer requires prior authorization.
The information can then be used to create and send an electronic prior
authorization request, using the NCPDP SCRIPT standard, to the payer or
PBM, as appropriate.
The NCPDP F&B standard relies on payers producing a periodic flat
file (or simple, plain text database) that includes point-in-time
information about drugs covered under a pharmacy benefit.\32\ The NCPDP
F&B standard is mature and has widespread industry adoption to provide
useful information about group-level drug coverage for a variety of use
cases. However, the NCPDP F&B standard does not require this
information to be updated in real time; therefore, as information
changes, a payer's F&B file could become out of date. Furthermore,
information is provided for group-level coverage information rather
than being patient-specific.
---------------------------------------------------------------------------
\32\ National Council for Prescription Drug Programs (NCPDP)
Real-Time Prescription Benefit Standard IG, Version 13. NCPDP RTPB
IGs are available to NCPDP members for free and to non-members for a
fee at https://standards.ncpdp.org/Access-to-Standards.aspx.
---------------------------------------------------------------------------
c. NCPDP Real-Time Prescription Benefit Standard
The NCPDP RTPB standard enables the real-time exchange of patient-
specific eligibility, drug coverage (including any restrictions and
alternatives), and estimated cost sharing to enable access to this
information at the point of prescribing. In the 2024 Part D and Health
IT Standards final rule, the Secretary adopted the NCPDP RTPB standard
version 13 in 45 CFR 170.205(c)(1) (89 FR 51260). This is the most
recently published and adopted version of the standard as of the date
this proposed rule appeared in the Federal Register.
As discussed in section II.B.6. of this proposed rule, we are
proposing to require impacted payers to support an unexpired version of
the NCPDP RTPB standard adopted by the Secretary in 45 CFR 170.205(c).
Accordingly, if ONC establishes an expiration date for the NCPDP RTPB
standard or for a specific version thereof, upon the specified
expiration date, impacted payers would no longer be permitted to use
that standard or version to meet the interoperability requirements, and
would be required to use another unexpired version adopted by the
Secretary in 45 CFR 170.205(c). We are proposing an October 1, 2027
compliance date for this proposed requirement.
While the NCPDP F&B standard provides group-level coverage
information to the provider, the NCPDP RTPB standard provides member-
specific information to the provider. The NCPDP F&B and NCPDP RTPB
standards can complement each other in the provider's workflow to allow
for relevant formulary, coverage, cost, and prior authorization
information to be utilized when prescribing a drug. Findings from NCPDP
grant-funded research on the NCPDP F&B and NCPDP RTPB standards showed
that when the NCPDP F&B standard is used in conjunction with the NCPDP
RTPB standard, providers had a more complete view of patient-specific
medication options, costs, and prior authorization information at the
point of prescribing.\33\
---------------------------------------------------------------------------
\33\ Journal of American Pharmacists Association. (2023,
February 2). Formulary & Benefit and Real-time Pharmacy Benefit:
Electronic Standards Delivering Value to Prescribers and
Pharmacists. Retrieved from https://www.japha.org/article/S1544-3191(23)00016-X/abstractqq.
---------------------------------------------------------------------------
[[Page 19905]]
Utilizing the proposed NCPDP standards for electronic prior
authorization in the provider's workflow would likely lead to faster
prior authorization processes and thus result in improved patient
access to prescribed medications.
In summary, we request comment on our proposals in the CFR
citations listed in Table 2, and specifically on the following:
The proposal to require state Medicaid and CHIP FFS
programs, Medicaid managed care plans, CHIP managed care entities, and
QHP issuers on the FFEs to support an unexpired version of the NCPDP
SCRIPT standard adopted by the Secretary in 45 CFR 170.205(b) for the
electronic prior authorization of drugs covered under a pharmacy
benefit.
The proposal to require state Medicaid and CHIP FFS
programs, Medicaid managed care plans, CHIP managed care entities, and
QHP issuers on the FFEs to support an unexpired version of the NCPDP
F&B standard adopted by the Secretary in 45 CFR 170.205(u) to make
available formulary and benefits information for drugs covered under a
pharmacy benefit.
The proposal to require state Medicaid and CHIP FFS
programs, Medicaid managed care plans, CHIP managed care entities, and
QHP issuers on the FFEs to support an unexpired version of the NCPDP
RTPB standard adopted by the Secretary in 45 CFR 170.205(c) for
exchanging real-time coverage information regarding drugs covered under
a pharmacy benefit.
The proposed October 1, 2027 compliance date for these
proposals, as discussed in section II.B.2.c. of this proposed rule.
In addition, we request comments on the following:
Through what mechanisms do payers make their NCPDP F&B
files available today?
How frequently do payers or their PBMs update their F&B
flat file today? How often should payers update their F&B flat file to
account for formulary or benefit changes?
How often do payers update the indicators for whether
prior authorization is required within their F&B flat files? How often
does that information change and is there typically a lag between
policy changes and published F&B flat files?
How frequently do providers use the NCPDP F&B standard as
part of their prior authorization workflow today?
How well integrated is the NCPDP F&B standard into
providers' EHRs today?
How accurate is the group-level information included in
the NCPDP F&B standard to specific patients?
How could impacted payers utilize the NCPDP RTPB standard
to indicate whether a drug is covered under a medical benefit?
Through what mechanisms do payers make information
available using the NCPDP RTPB standard today?
How frequently do providers use tools conforming to the
NCPDP RTPB standard as part of their prior authorization workflow
today?
How prevalent is implementation of the NCPDP RTPB standard
into providers' EHRs today? How automated are current interactions with
the NCPDP RTPB standard within providers' EHRs and clinical workflow?
For electronic prior authorization, would or could
requiring impacted payers to make available information using the NCPDP
RTPB standard negate the need for impacted payers to make available
information using the NCPDP F&B standard? Does the NCPDP RTPB standard
include all the necessary formulary and benefits information and
functionality that would be available by using the NCPDP F&B standard
for electronic prior authorization?
Would requiring impacted payers to make information
available using both standards add value, or create additional burden,
specifically related to electronic prior authorization of drugs?
Does the CRD IG have the technical capability to return
specific coverage information through the ``CoverageInformation''
extension?
++ How could the ``CoverageInformation'' extension be best utilized
to indicate whether a particular drug is covered under a medical
benefit and whether the Prior Authorization API should be used for
electronic prior authorization?
Are there other existing technical solutions or methods
that impacted payers could utilize to indicate to providers how a prior
authorization request for a drug should be submitted?
3. Required Standards for FHIR APIs
a. Modification to Required Standards for FHIR APIs
We are proposing to require each impacted payer to implement and
maintain APIs that are conformant with applicable standards in 45 CFR
170.215 in a manner that will allow for progressive adoption of new
versions of these required standards. Under this approach, impacted
payers would be permitted to conform with any updated versions of the
required standards as the Secretary adopts them, via notice and comment
rulemaking, in 45 CFR 170.215. In addition, if ONC establishes an
expiration date for a standard in 45 CFR 170.215, or for a specific
version thereof, upon the specified expiration date, impacted payers
would no longer be permitted to use that standard or version to meet
the interoperability requirements. When more than one unexpired version
of a required standard is adopted in 45 CFR 170.215, impacted payers
would be able to use any of the unexpired versions of the adopted
standard to meet the interoperability requirements. This would allow
impacted payers to have more predictable transition periods to update
their APIs, and to conform with newer versions of the required
standards in 45 CFR 170.215 as they are adopted, and older versions
expire. CMS and ONC will work in close collaboration to evaluate the
standards adopted in 45 CFR 170.215 and determine whether and when
updated versions are ready for adoption through rulemaking.
For example, in the 2024 CMS Interoperability and Prior
Authorization final rule, we required impacted payers to use API
technology conformant with the SMART App Launch IG, Release 1.0.0, in
45 CFR 170.215(c)(1) (89 FR 8927-8928). In this proposed rule, we are
proposing to revise this requirement so that impacted payers would be
required to use API technology conformant with an unexpired version of
the SMART App Launch IG adopted by the Secretary in 45 CFR 170.215(c).
As of the date this proposed rule appears in the Federal Register,
adopted versions of this standard include: (1) the SMART App Launch IG,
Release 1.0.0 in 45 CFR 170.215(c)(1), which expired on January 1,
2026, and (2) the SMART App Launch IG, Release 2.0.0 in 45 CFR
170.215(c)(2), without an expiration date. In this example, impacted
payers would need their API technology to be conformant with SMART App
Launch IG, Release 2.0.0, as that would be the only unexpired version
available upon the effective date of a final rule. Finalizing this
proposal, which would require impacted payers to use an unexpired
version of the required standards cross-referenced in 45 CFR 170.215,
would revise the existing requirement that impacted payers use specific
versions of these standards that have since expired.
We propose to update the technical requirements for each API, for
each impacted payer, to cross reference to
[[Page 19906]]
locations in 45 CFR 170.215 that include all versions of the required
standards adopted by the Secretary. For readability purposes, citations
where we are proposing to require the standards and IGs in 45 CFR
170.215 for each impacted payer are listed in Table 2. Specifically, we
propose to update the cross references to the following:
HL7 FHIR Standard in 45 CFR 170.215(a);
US Core IG in 45 CFR 170.215(b)(1);
SMART App Launch IG in 45 CFR 170.215(c);
Bulk Data Access IG in 45 CFR 170.215(d); and
OpenID Connect Core in 45 CFR 170.215(e).
We propose that the revised references to 45 CFR 170.215(a),
(b)(1), and (c) through (e), as listed in Table 3, would be effective
beginning on the effective date of the final rule, for all
interoperability APIs.
Impacted payers would continue to be required to maintain the
Patient Access and Provider Directory APIs that they are presently
required to maintain. In the 2024 CMS Interoperability and Prior
Authorization final rule, we finalized requirements for impacted payers
to make the Provider Access, Payer-to-Payer, and Prior Authorization
APIs available beginning in 2027 (by January 1, 2027, for MA
organizations and state Medicaid and CHIP FFS programs; by the first
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 individual market QHP
issuers on the FFEs) (89 FR 8759-8760). This proposal would not change
those compliance dates but would allow impacted payers to better plan
for implementation by those dates as the Secretary adopts new standards
or specifies new expiration dates for existing standards, or specific
versions thereof, adopted in 45 CFR 170.215.
As discussed in section II.A.1. of this proposed rule, ONC has
adopted additional versions of certain required standards, which are
included in Table 2. We also expect that several of the standards and
IGs we currently require, or recommend and are proposing to require,
may have newer versions published before this rule is finalized. For
example, we expect that some of the IGs discussed in this proposed rule
will be updated to support newer versions of the US Core IG. In this
proposed rule, we discuss either the most recently published or most
recently adopted versions of the standards and IGs at the time this
proposed rule appears in the Federal Register.
In summary, we request comment on our proposals in the CFR
citations listed in Table 2, and specifically on the following:
The proposal to require impacted payers to implement and
maintain API technology conformant with unexpired versions of the
standards adopted by the Secretary in 45 CFR 170.215, specifically 45
CFR 170.215(a), (b)(1), and (c), (d), and (e), as applicable.
The proposal to become effective beginning on the
effective date of the final rule.
In addition, we request comments on the following:
Whether there are opportunities to streamline our
regulatory requirements in instances where requiring conformance with
the previously recommended IGs proposed in II.A.4.b. of this proposed
rule for specific API use cases would achieve the same functional goal
as explicitly requiring conformance with both the use-case specific IGs
and required IGs or standards. For instance, whether it is necessary to
require the base FHIR standard as well as the CRD, DTR, and PAS IGs
that we propose to require for the Prior Authorization API, or whether
requiring the CRD, DTR, and PAS IGs alone, which are based on the FHIR
standard, would provide comparable technical guidance for implementers
while reducing regulatory complexity.
+ Scenarios in which independently requiring both the required
standards in this section (II.A.3.a. of the proposed rule) and use-case
specific IGs proposed in section II.A.4.b. of the proposed rule could
introduce alignment challenges. For instance, where one required
standard references a specific version of another required standard,
independent adoption of the latter standard could present further
alignment challenges.
+ Instances in which requiring conformance with both the required
standards in this section (II.A.3.a. of this proposed rule) and the
use-case specific IGs proposed in section II.A.4.b. of the proposed
rule are necessary to fully represent necessary technical requirements
and should be maintained.
Comments on whether it would be helpful to payers to more
specifically identify capabilities of required IGs relevant to a
specific API, to further streamline requirements and reduce unnecessary
development. For instance, whether we should specify only those
capabilities of the SMART App Launch IG relevant to the Patient Access
API use case (e.g. the ``Patient Access for Standalone Apps''
Capability Set as well as the capabilities of ``launch-standalone'' and
``context-standalone-patient,'' and the capabilities in subsections
``Authorization Methods,'' ``Client Types,'' ``Single Sign-on,'' and
``Permissions'' except the ``permission-online'' and ``permission-
user'').
4. Requiring Additional Implementation Guides to Support
Interoperability APIs
a. Description of the Implementation Guides
Using standards and IGs supports consistent implementation across
the industry, thus leading to interoperable data exchange. There are
many FHIR IGs that exist to support data exchange between payers,
providers, and patients and enable the exchange of data such as claims,
encounter, clinical, and coverage information; drug formulary
information; and prior authorization information.
Here, we provide descriptions of FHIR IGs that we require or
recommend impacted payers support (89 FR 8927 and 8928, 8937, and
8945). Specifically, we required impacted payers to use the Bulk Data
Access IG for the Provider Access and Payer-to-Payer APIs, while the
other IGs described later in this section were recommended.\34\ We are
now proposing to require impacted payers to support these IGs as
described in section II.A.4.b. of this proposed rule. Table 2 outlines
the citations to where we propose to require use of the standards for
each of the specified APIs.
---------------------------------------------------------------------------
\34\ See 45 CFR 170.215(d)(1).
---------------------------------------------------------------------------
(1) CARIN Implementation Guide for Blue Button[supreg]
The Creating Access to Real-time Information Now through Consumer
Directed Exchange (CARIN) Alliance designed the HL7 FHIR CARIN Consumer
Directed Payer Data Exchange (CARIN IG for Blue Button) IG \35\ to meet
the requirements in the 2020 CMS Interoperability and Patient Access
final rule for impacted payers to make available adjudicated claims and
encounter data, from a financial perspective, via a Patient Access API
through consumer-directed exchange (85 FR 25532). Consumer-directed
exchange occurs when a patient or an authorized personal representative
requests the patient's digital health information via a health app or
other third-party data steward, such as a health information exchange
(HIE). As of the date this proposed rule appears in the Federal
Register, the most recently published version is the CARIN IG for Blue
Button, Version 2.2.0--STU 2.2.
---------------------------------------------------------------------------
\35\ Health Level Seven International. (n.d.). CARIN IG for Blue
Button. Retrieved from http://hl7.org/fhir/us/carin-bb/ImplementationGuide/hl7.fhir.us.carin-bb.
---------------------------------------------------------------------------
[[Page 19907]]
(2) HL7 FHIR Da Vinci PDex Implementation Guide
The HL7 FHIR Da Vinci Payer Data Exchange (PDex) IG \36\
facilitates the creation and exchange of a patient's health history
using clinical data (based on US Core Profiles established from FHIR
R4) in a manner that allows providers to integrate the data received
into their EHRs. The PDex IG supports sharing of payer data through a
more clinical perspective, in line with the United States Core Data for
Interoperability (USCDI) and US Core IG, than a financial perspective
as is done with the CARIN IG for Blue Button. However, the PDex IG does
include information about prior authorizations that impacted payers are
required to make available by the 2024 CMS Interoperability and Prior
Authorization final rule (89 FR 8758). The PDex IG can support all the
required data elements for prior authorization data exchange, though we
note that the PDex IG enhancements to support payer to payer bulk data
exchange, payer to provider exchange, and explanation of benefits are
currently in draft form and have not appeared in ballot, but have been
tested at multiple Connectathons. The PDex IG has been updated to
support newer versions of the US Core IG, including versions 6.1.0 and
7.0.0. As of the date this proposed rule appears in the Federal
Register, the most recently published and adopted version is the PDex
IG, Version 2.1.0--STU 2.1.
---------------------------------------------------------------------------
\36\ Health Level Seven International. (n.d.). Da Vinci PDex IG.
Retrieved from http://hl7.org/fhir/us/davinci-pdex/ImplementationGuide/hl7.fhir.us.davinci-pdex.
---------------------------------------------------------------------------
(3) HL7 FHIR Da Vinci PDex US Drug Formulary Implementation Guide
The HL7 FHIR Da Vinci PDex US Drug Formulary IG (PDex US Drug
Formulary IG) \37\ defines a FHIR interface to a payer's drug formulary
information for patients. A drug formulary is a list of prescription
drugs covered by the payer under the patient's coverage. The primary
use case for this FHIR interface is to enable patients to understand
the costs for drugs that have been prescribed and to compare their drug
costs across different types of coverage. As of the date this proposed
rule appears in the Federal Register, the most recently published
version is the PDex US Drug Formulary IG, Version 2.1.0--STU 2.
---------------------------------------------------------------------------
\37\ Health Level Seven International. (n.d.). Da Vinci PDex US
Drug Formulary IG. Retrieved from http://hl7.org/fhir/us/davinci-drug-formulary/ImplementationGuide/hl7.fhir.us.davinci-drug-formulary.
---------------------------------------------------------------------------
(4) HL7 FHIR Da Vinci PDex Plan Net Implementation Guide
The HL7 FHIR Da Vinci PDex Plan Net IG (PDex Plan Net IG) \38\
defines a FHIR interface to access information about a payer's health
plans, associated networks, and the providers and other entities that
participate in their networks. Publishing that information through a
publicly available FHIR API allows third party developers to build apps
for patients to find in-network care that could be covered by their
payer. As of the date this proposed rule appears in the Federal
Register, the most recently published version is the PDex Plan Net IG,
Version 1.2.0--STU 1.2 US.
---------------------------------------------------------------------------
\38\ Health Level Seven International. (n.d.). Da Vinci PDex
Plan Net IG. Retrieved from http://hl7.org/fhir/us/davinci-pdex-plan-net/ImplementationGuide/hl7.fhir.us.davinci-pdex-plan-net.
---------------------------------------------------------------------------
5) FHIR Bulk Data Access Implementation Guide
The FHIR Bulk Data Access (Flat FHIR) IG (Bulk Data Access IG) \39\
was developed to facilitate the exchange of a large number of patient
records at the same time. FHIR APIs generally work well for accessing
small amounts of data, but large data exports can require hundreds or
thousands of requests that may overwhelm a FHIR server. This IG defines
a standardized, FHIR-based approach for asynchronously exporting bulk
data from a FHIR server to an authorized client. As of the date this
proposed rule appears in the Federal Register, the most recently
published version is the Bulk Data Access IG (v3.0.0: STU 3).
---------------------------------------------------------------------------
\39\ Health Level Seven International. (n.d.). FHIR Bulk Data
Access IG. Retrieved from http://hl7.org/fhir/uv/bulkdata/ImplementationGuide/hl7.fhir.uv.bulkdata.
---------------------------------------------------------------------------
(6) HL7 FHIR Da Vinci CRD, DTR, and PAS Implementation Guides
These three IGs are designed to be used by payers to develop and
implement the Prior Authorization API. The HL7 FHIR Da Vinci Coverage
Requirements Discovery (CRD) IG \40\ defines a workflow to allow payers
to provide information about coverage requirements to providers through
their EHR or other health IT system. This is the first stage of the
process for determining whether prior authorization is required for
certain items or services. The CRD IG enables the Prior Authorization
API to inform a provider whether prior authorization is required and
provide information about the payers' prior authorization coverage
rules, so the provider knows what is necessary to support prior
authorization approval. As of the date this proposed rule appears in
the Federal Register, the most recently published version is the CRD
IG, Version 2.2.1--STU 2.2.\41\
---------------------------------------------------------------------------
\40\ Health Level Seven International. (n.d.). Da Vinci CRD IG.
Retrieved from http://hl7.org/fhir/us/davinci-crd/ImplementationGuide/hl7.fhir.us.davinci-crd.
\41\ Health Level Seven International. (2026, March 27). Da
Vinci CRD IG, Version 2.2.1--STU 2.2. Retrieved from https://hl7.org/fhir/us/davinci-crd/2.2.1/en/.
---------------------------------------------------------------------------
The HL7 FHIR Da Vinci Documentation Templates and Rules (DTR) IG
\42\ specifies how payer documentation requirements for prior
authorization requests can be communicated to a provider. If necessary,
this would allow providers to download questionnaires and populate them
automatically with information from their EHR or other health IT
systems to demonstrate medical necessity or other coverage requirements
based on the payer's specific rules. The DTR IG can also automate the
assemblage of documentation to support a prior authorization request.
For instance, the DTR IG can be used to write rules that support
automatically extracting patient information from the EHR or other
health IT system for the provider to review and confirm before
submission. As of the date this proposed rule appears in the Federal
Register, the most recently published version is the DTR IG, Version
2.2.0--STU 2.2.\43\
---------------------------------------------------------------------------
\42\ Health Level Seven International. (n.d.). Da Vinci DTR IG.
Retrieved from http://hl7.org/fhir/us/davinci-dtr/ImplementationGuide/hl7.fhir.us.davinci-dtr.
\43\ Health Level Seven International. (2026, March 27). Da
Vinci DTR IG, Version 2.2.0--STU 2.2. Retrieved from https://hl7.org/fhir/us/davinci-dtr/2.2.0/en/.
---------------------------------------------------------------------------
The HL7 FHIR Da Vinci Prior Authorization Support (PAS) IG \44\
enables prior authorization requests and decisions to be transmitted
via FHIR API from within providers' EHRs or other health IT systems.
The PAS IG is the basis for: (1) assembling the information necessary
to substantiate the clinical need for a particular treatment; and (2)
submitting the assembled information and prior authorization request to
the intended recipient. The PAS IG also defines capabilities for
managing prior authorization requests, including checking the status of
a previously submitted request, updating a previously submitted
request, and canceling a request. As of the date this proposed rule
appears in the Federal Register, the most recently published
[[Page 19908]]
version is the PAS IG, Version 2.2.1--STU 2.2.\45\
---------------------------------------------------------------------------
\44\ Health Level Seven International. (n.d.). Da Vinci PAS IG.
Retrieved from http://hl7.org/fhir/us/davinci-pas/ImplementationGuide/hl7.fhir.us.davinci-pas.
\45\ Health Level Seven International. (2026, March 27). Da
Vinci PAS IG, Version 2.2.1--STU 2.2. Retrieved from https://hl7.org/fhir/us/davinci-pas/2.2.1/en/.
---------------------------------------------------------------------------
b. Requiring Implementation Guides
In the 2024 CMS Interoperability and Prior Authorization final
rule, we discussed use-case specific IGs that impacted payers can use
to implement their interoperability APIs (89 FR 8937). Using those IGs
supports interoperability because impacted payers need not develop an
approach independently, which should save time and resources. In that
final rule, we strongly encouraged payers to use the IGs listed as
``recommended'' in Table H3 for each API, in addition to the required
standards in 45 CFR 170.215 (89 FR 8945). We recommended specific IGs
for each API to provide guidance to the industry without locking payers
into the versions of those IGs available at the time of the 2022 CMS
Interoperability and Prior Authorization proposed rule (89 FR 8937). We
carefully considered the versions of the recommended IGs that were
available at the time and determined that they were not ready to be
proposed as requirements. However, we acknowledged that by recommending
rather than requiring certain IGs, there is potential for
implementation variation that could limit interoperability and
ultimately lead to rework for impacted payers if we required the IGs in
the future (89 FR 8937). We believed that those IGs would continue to
be refined as they were tested and implemented in the real world. We
stated that we would continue to monitor and evaluate the IGs'
development and consider whether to propose to require their use in the
future (89 FR 8937). Since publication of the 2022 CMS Interoperability
and Prior Authorization proposed rule, those IGs have continued to
mature, and updated versions of many of the recommended IGs have been
published.
Therefore, we are now proposing to require impacted payers to
implement and maintain API technology conformant with specific IGs for
each applicable API. We propose to require these IGs to through cross
references to the applicable citations in 45 CFR 170.215. For
readability purposes, citations where we propose to require the IGs for
each type of impacted payer are listed in Table 2.
In the HTI-4 final rule, the Secretary adopted the following IGs
(90 FR 37167 and 37182):
CARIN IG for Blue Button, Version 2.0.0--STU 2 in 45 CFR
170.215(k)(1)(i);
PDex IG, Version 2.1.0--STU 2.1 in 45 CFR
170.215(k)(2)(i);
PDex US Drug Formulary IG, Version 2.0.1--STU 2 in 45 CFR
170.215(m)(1);
PDex Plan Net IG, Version 1.1.0--STU 1.1 US in 45 CFR
170.215(n)(1);
CRD IG, Version 2.0.1--STU 2 in 45 CFR 170.215(j)(1);
DTR IG, Version 2.0.1--STU 2 in 45 CFR 170.215(j)(2)(i);
and
PAS IG, Version 2.0.1--STU 2 in 45 CFR 170.215(j)(3)(i).
Since publication of the ``Health Data, Technology, and
Interoperability: Patient Engagement, Information Sharing, and Public
Health Interoperability'' proposed rule (89 FR 63498) (hereinafter
referred to as the ``HTI-2 proposed rule''), which appeared in the
Federal Register on August 5, 2024, and subsequent finalization of the
HTI-4 final rule, updated versions of many of the standards and IGs
have been published. In section II.J. of this proposed rule, ONC is now
proposing to adopt updated versions of standards in 45 CFR 170.215 and
proposing to add expiration dates to versions of these standards that
were previously adopted in 45 CFR 170.215. We propose to cross
reference the locations in 45 CFR 170.215 that include those versions
of a specific standard adopted by the Secretary, and specify that
impacted payers must use an unexpired version of the standard at that
location:
CARIN IG for Blue Button in 45 CFR 170.215(k)(1);
PDex IG in 45 CFR 170.215(k)(2);
PDex US Drug Formulary IG in 45 CFR 170.215(m)(1);
PDex Plan Net IG in 45 CFR 170.215(n)(1);
CRD IG in 45 CFR 170.215(j)(1);
DTR IG in 45 CFR 170.215(j)(2); and
PAS IG in 45 CFR 170.215(j)(3).
Requiring impacted payers to use an unexpired version of the
standards adopted in 45 CFR 170.215 automatically incorporates updated
versions into the interoperability requirements as they are adopted by
the Secretary. Specifically, if the Secretary adopts updated versions
of any of these standards, such as the updated versions ONC has
proposed for adoption in section II.J. of this proposed rule (subject
to finalization), those versions would be incorporated in 45 CFR
170.215. As noted previously, if the Secretary establishes an
expiration date for a standard, or for specific version thereof, upon
the specified expiration date, impacted payers would no longer be
permitted to use that standard or version to meet the interoperability
requirements.
We propose that impacted payers would be required to implement and
maintain API technology conformant with an unexpired version of the
proposed additional FHIR IGs for each API as described in section
II.A.4.b. of this proposed rule beginning on October 1, 2027. In the
2024 CMS Interoperability and Prior Authorization final rule, we
finalized compliance dates beginning in 2027 for impacted payers to
implement and maintain Provider Access, Payer-to-Payer, and Prior
Authorization APIs (89 FR 8790, 8820, and 8860). We recognize that
impacted payers may already be developing and implementing their APIs
to comply with the technical requirements established in the 2024 CMS
Interoperability and Prior Authorization final rule in preparation for
the January 1, 2027 compliance deadline. Some impacted payers may have
opted not to use the currently recommended IGs, which we now propose to
require. Therefore, we believe that the proposed October 1, 2027
compliance date would provide impacted payers with additional time to
update their APIs to conform to the additional IGs we are proposing to
require beginning on October 1, 2027. Table 3 in this proposed rule
lists the required standards finalized in the 2024 CMS Interoperability
and Prior Authorization final rule and additional FHIR IGs proposed in
this rule by applicable API.
(1) Patient Access API
In the 2020 CMS Interoperability and Patient Access final rule, we
required impacted payers to implement and maintain a standards-based
Patient Access API (85 FR 25558).\46\ The Patient Access API allows
patients, through the health apps of their choice, to easily access
their claims and encounter information, including provider remittances
and patient cost-sharing, as well as all data classes and data elements
included in a content standard (USCDI) adopted by the Secretary in 45
CFR 170.213.\47\ In the 2024 CMS
[[Page 19909]]
Interoperability and Prior Authorization final rule, we finalized a
requirement that, beginning in 2027 (by January 1, 2027, for MA
organizations and state Medicaid and CHIP FFS programs; by the rating
period beginning on or after January 1, 2027, for Medicaid managed care
plans and CHIP managed care entities; and for plan years beginning on
or after January 1, 2027, for QHP issuers on the FFEs), impacted payers
must include certain information about prior authorizations for non-
drug items and services in the data that are available through the
Patient Access API (89 FR 8768).\48\ In that 2024 final rule, we also
finalized a requirement that impacted payers must implement and
maintain their Patient Access APIs conformant with standards in 45 CFR
170.215, including FHIR, US Core IG, SMART App Launch IG, and the
OpenID Connect Core 1.0.
---------------------------------------------------------------------------
\46\ See 42 CFR 422.119(a) for MA organizations, 42 CFR
431.60(a) for state Medicaid FFS programs, 42 CFR 457.730(a) for
state CHIP FFS programs, through cross reference to 42 CFR 431.60 in
42 CFR 438.242(b)(5) for Medicaid managed care plans, through cross
reference to 42 CFR 457.730 in 42 CFR 457.1233(d)(2) for CHIP
managed care entities, and 45 CFR 156.221(a) for individual market
QHPs.
\47\ See 42 CFR 422.119(b)(1) for MA organizations, 42 CFR
431.60(b)(3) for state Medicaid FFS programs, cross reference to 42
CFR 431.60 in 42 CFR 438.242(b)(5) for Medicaid managed care plans,
42 CFR 457.730 for state CHIP FFS programs, through cross reference
to 42 CFR 438.242 in existing 42 CFR 457.1233(d) for CHIP managed
care entities, and 45 CFR 156.221(b)(1)(iii) for individual market
QHP issuers.
\48\ See 42 CFR 422.119(b)(1)(iv) for MA organizations, 42 CFR
431.60(b) for state Medicaid FFS programs, through cross reference
to 42 CFR 431.60 in 42 CFR 438.242(b)(5) for Medicaid managed care
plans, 42 CFR 457.730(b) for state CHIP FFS programs, through cross
reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed
care entities, and 45 CFR 156.221(b) for individual market QHP
issuers.
---------------------------------------------------------------------------
To further support consistent implementation of the Patient Access
API, we are now proposing to require impacted payers to implement and
maintain API technology conformant with an unexpired version of the
CARIN IG for Blue Button, the PDex IG, and the PDex US Drug Formulary
IG adopted by the Secretary. Specifically, we are proposing to require
impacted payers to implement and maintain a Patient Access API
conformant with the CARIN IG for Blue Button to support sharing claims
and encounter data, the PDex IG to support sharing clinical data and
prior authorization information, and the PDex US Drug Formulary IG to
share a formulary of drugs covered by the payer under the patient's
health plan through the Patient Access API. We believe that by
requiring these IGs, impacted payers would format data available
through the Patient Access API in a consistent manner that would allow
health app developers to easily access and display patients' health
data, thus having those data readily available and easily accessible to
patients. Enabling patients to easily access their health information
electronically through an API should allow patients to better manage
their health care.
(2) Provider Access API
In the 2024 CMS Interoperability and Prior Authorization final
rule, we finalized a requirement for impacted payers to implement and
maintain a Provider Access API conformant with standards in 45 CFR
170.215, including FHIR, US Core IG, SMART App Launch IG, and the Bulk
Data Access IG (85 FR 25521-25522 and 89 FR 8788). Providers would be
able to use that API to access current patient data from impacted
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 (USCDI) in 45
CFR 170.213, and certain information about prior authorizations for
non-drug items and services.\49\
---------------------------------------------------------------------------
\49\ See 42 CFR 422.121(a)(2) for MA organizations, 42 CFR
431.61(a)(2) for state Medicaid FFS programs, 42 CFR 457.731(a)(2)
for CHIP FFS programs, through cross reference to 42 CFR 431.61 in
42 CFR 438.242(b)(7) for Medicaid managed care plans, through cross
reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed
care entities, and 45 CFR 156.222(a)(2) for individual market QHP
issuers.
---------------------------------------------------------------------------
To facilitate care coordination and to further standardize impacted
payers' APIs, we are now proposing to require impacted payers to
implement and maintain API technology conformant with an unexpired
version of the CARIN IG for Blue Button and the PDex IG adopted by the
Secretary in their Provider Access API implementation. Specifically, we
are proposing to require impacted payers to implement and maintain a
Provider Access API conformant with the CARIN IG for Blue Button, to
support sharing claims and encounter data, as well as the PDex IG, to
support sharing clinical data and prior authorization information.
In the 2024 CMS Interoperability and Prior Authorization final
rule, we finalized requirements for impacted payers to make drug
formulary information available through the Provider Access API in
alignment with the Patient Access API requirements set forth in the
2020 CMS Interoperability and Patient Access final rule.\50\ We refer
readers to section II.E.3. of this proposed rule, where we discuss our
proposal to remove drug formulary information from the content required
in the Provider Access and Payer-to-Payer APIs. However, we will
consider the comments we receive on this proposal and may choose to
retain this requirement, in which case we propose here, as an
alternative, to require the PDex US Drug Formulary IG at the citations
identified in Table 2 along with the other standards for the Provider
Access API to support consistent solutions for sharing drug formulary
information.
---------------------------------------------------------------------------
\50\ See cross reference to 42 CFR 422.119(b) in 42 CFR
422.121(a)(2) for MA organizations, through cross reference to 42
CFR 431.60(b) in 42 CFR 431.61(a)(2) for state Medicaid FFS
programs, through cross reference to 42 CFR 457.730(b) in 42 CFR
457.731(a)(2) for state CHIP FFS programs, through cross reference
to 42 CFR 431.61 in 42 CFR 438.242(b)(7) for Medicaid managed care
plans, through cross reference to 42 CFR 438.242 in 42 CFR
457.1233(d) for CHIP managed care entities, and 45 CFR 156.222(a)(1)
for individual market QHP issuers.
---------------------------------------------------------------------------
(3) Provider Directory API
In the 2020 CMS Interoperability and Patient Access final rule, we
finalized a requirement that impacted payers (excluding QHP issuers on
the FFEs) must implement and maintain a Provider Directory API to make
available specific information about their provider networks.\51\
Impacted payers were required to implement and maintain the Provider
Directory API by January 1, 2021.\52\ To further standardize
implementation, we are now proposing to require impacted payers to
implement and maintain a Provider Directory API conformant with an
unexpired version of the PDex Plan Net IG adopted by the Secretary. The
PDex Plan Net IG defines the technical parameters and data elements to
share information about a payer's network and the providers and other
entities that participate in their network.
---------------------------------------------------------------------------
\51\ See 42 CFR 422.120(a) for MA organizations, 42 CFR
431.70(a) for state Medicaid FFS programs, 42 CFR 457.760(a) for
state CHIP FFS programs, through cross reference to 42 CFR 431.70 in
42 CFR 438.242(b)(6) for Medicaid managed care plans, and through
cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP
managed care entities.
\52\ See 42 CFR 422.120(c) for MA organizations, 42 CFR
431.70(c) for state Medicaid FFS programs, 42 CFR 457.760(c) for
state CHIP FFS programs, through cross reference to 42 CFR 431.70(c)
in 42 CFR 438.242(b)(6) for Medicaid managed care plans, and through
cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP
managed care entities.
---------------------------------------------------------------------------
(4) Payer-to-Payer API
In the 2024 CMS Interoperability and Prior Authorization final
rule, we finalized a requirement that, beginning in 2027 (by January 1,
2027, for MA organizations and state Medicaid and CHIP FFS programs; by
the rating period beginning on or after January 1, 2027, for Medicaid
managed care plans and CHIP managed care entities; and for plan years
beginning on or after January 1, 2027, for QHP issuers on the FFEs),
impacted payers must implement and maintain a Payer-to-Payer API to
exchange patient data when a patient moves between payers or has
concurrent coverage to ensure continued access to their health data and
support care continuity and coordination between payers.\53\
Specifically, this data
[[Page 19910]]
exchange requirement includes adjudicated claims and encounter data
(excluding provider remittances and patient cost-sharing information),
all data classes and data elements included in a content standard
(USCDI) in 45 CFR 170.213, and certain information about prior
authorizations for non-drug items and services.\54\
---------------------------------------------------------------------------
\53\ See 42 CFR 422.121(b)(1) for MA organizations, 42 CFR
431.61(b)(1) for state Medicaid FFS programs, through cross
reference to 42 CFR 431.61(b)(1) in 42 CFR 438.242(b)(7) for
Medicaid managed care plans, 42 CFR 457.731(b) for state CHIP FFS
programs, through cross reference to 42 CFR 438.242 in 42 CFR
457.1233(d) for CHIP managed care entities, and 45 CFR 156.222(b)(1)
for individual market QHPs.
\54\ See 42 CFR 422.121(b)(4)(ii) for MA organizations, 42 CFR
431.61(b)(4)(ii) for state Medicaid FFS programs, through cross
reference to 42 CFR 431.61(b)(4) in 42 CFR 438.242(b)(7) for
Medicaid managed care plans, 42 CFR 457.731(b) for state CHIP FFS
programs, 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed care
entities, and 45 CFR 156.222(b)(4)(ii) for individual market QHPs.
---------------------------------------------------------------------------
To ensure impacted payers are implementing the Payer-to-Payer API
in an interoperable and standardized way, we are now proposing to
require impacted payers to implement and maintain API technology
conformant with the CARIN IG for Blue Button and the PDex IG.
Specifically, we are proposing to require impacted payers to implement
and maintain a Payer-to-Payer API conformant with an unexpired version
of the CARIN IG for Blue Button adopted by the Secretary to support
sharing claims and encounter data, as well as the PDex IG to support
sharing clinical data and prior authorization information.
In the 2024 CMS Interoperability and Prior Authorization final
rule, we require impacted payers to make drug formulary information
available through the Payer-to-Payer API in alignment with the Patient
Access API requirements set forth in the 2020 CMS Interoperability and
Patient Access final rule.\55\ We refer readers to section II.E.3. of
this proposed rule, where we discuss our proposal to remove drug
formulary information from the content required in the Payer-to-Payer
and Provider Access APIs. However, we will consider the comments we
receive on this proposal and may choose to retain this requirement, in
which case we propose here, as an alternative, to require the PDex US
Drug Formulary IG at the citations identified in Table 2 along with the
other standards for the Payer to Payer API to support consistent
solutions for sharing drug formulary information.
---------------------------------------------------------------------------
\55\ See cross reference to 42 CFR 422.119(b) in 42 CFR
422.121(b)(4)(ii)(A) for MA organizations, through cross reference
to 42 CFR 431.60(b) in 42 CFR 431.61(b)(4)(ii)(A) for state Medicaid
FFS programs, through cross reference to 42 CFR 457.730(b) in 42 CFR
457.731(b)(4)(ii)(A) for state CHIP FFS programs, through cross
reference to 42 CFR 431.61 in 42 CFR 438.242(b)(7), and through
cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d).
---------------------------------------------------------------------------
(5) Prior Authorization API
To streamline the prior authorization process, in the 2024 CMS
Interoperability and Prior Authorization final rule, we finalized a
requirement that impacted payers must implement and maintain a Prior
Authorization API beginning in 2027 (by January 1, 2027, for MA
organizations and state Medicaid and CHIP FFS programs; by the rating
period beginning on or after January 1, 2027, for Medicaid managed care
plans and CHIP managed care entities; and for plan years beginning on
or after January 1, 2027, for QHP issuers on the FFEs).\56\ The Prior
Authorization API would allow providers to determine whether a specific
impacted payer requires prior authorization for a certain item or
service, query the impacted payer's prior authorization documentation
requirements, as well as facilitate the automated compilation of
necessary information to submit a prior authorization request
electronically (89 FR 8861).
---------------------------------------------------------------------------
\56\ See 42 CFR 422.122(b) for MA organizations, 42 CFR
431.80(b) for state Medicaid FFS programs, through cross reference
to 42 CFR 431.80(b) in 42 CFR 438.242(b)(7) for Medicaid managed
care plans, 42 CFR 457.732(b) for state CHIP FFS programs, through
cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d), and 45 CFR
156.223(b) for individual market QHPs.
---------------------------------------------------------------------------
At the time of the 2022 CMS Interoperability and Prior
Authorization proposed rule, we did not believe that the CRD, DTR, and
PAS IGs were mature enough to propose requiring impacted payers to use
them, and therefore, we only recommended their use. In the final rule,
we updated our recommendations to the latest versions of the CRD, DTR,
and PAS IGs (89 FR 8937 and 8945). Upon reviewing updated versions of
the CRD, DTR, and PAS IGs that have been published since the 2022 CMS
Interoperability and Prior Authorization proposed rule appeared in the
Federal Register, we now believe that these IGs are mature enough for
us to propose to require their use. We believe that requiring impacted
payers to use these three IGs in their Prior Authorization APIs would
avoid inconsistent or proprietary solutions that would make it
challenging for providers to easily connect with impacted payers.
Therefore, to ensure uniform and consistent implementations of the
Prior Authorization API, we are now proposing to require impacted
payers to implement and maintain API technology conformant with an
unexpired version of the CRD, DTR, and PAS IGs adopted by the Secretary
to implement their required Prior Authorization API.
Specifically, we are proposing to require impacted payers to
implement and maintain a Prior Authorization API conformant with an
unexpired version of the CRD IG adopted by the Secretary to define the
technical implementation to allow providers to access coverage
requirements through their EHR or other health IT system. The CRD IG
allows providers to then discover specific payer requirements for what
services are covered by the payer and whether prior authorization is
required.\57\ We are also proposing to require impacted payers to
implement and maintain a Prior Authorization API conformant with an
unexpired version of the DTR IG adopted by the Secretary so providers
can consistently access documentation requirements through their EHR or
other health IT system, as well as to gather information needed to
support prior authorization requests.\58\ Finally, we are proposing to
require impacted payers to implement and maintain a Prior Authorization
API conformant with an unexpired version of the PAS IG adopted by the
Secretary to enable the direct submission of prior authorization
requests from providers' health IT systems to the impacted payer.\59\
---------------------------------------------------------------------------
\57\ Health Level Seven International. (n.d.). Da Vinci CRD IG.
Retrieved from http://hl7.org/fhir/us/davinci-crd/ImplementationGuide/hl7.fhir.us.davinci-crd.
\58\ Health Level Seven International. (n.d.). Da Vinci DTR IG.
Retrieved from http://hl7.org/fhir/us/davinci-dtr/ImplementationGuide/hl7.fhir.us.davinci-dtr.
\59\ Health Level Seven International. (n.d.). Da Vinci PAS IG.
Retrieved from http://hl7.org/fhir/us/davinci-pas/ImplementationGuide/hl7.fhir.us.davinci-pas.
---------------------------------------------------------------------------
In summary, we request comment on our proposals in the CFR
citations listed in Table 2, and specifically the following:
The proposal to require impacted payers to use an
unexpired version of the CARIN IG for Blue Button, the PDex IG, and the
PDex US Drug Formulary IG adopted by the Secretary for their Patient
Access API.
The proposal to require impacted payers to use an
unexpired version of the CARIN IG for Blue Button and the PDex IG
adopted by the Secretary for their Provider Access API.
The proposal to require impacted payers to use an
unexpired version of the PDex Plan Net IG adopted by the Secretary for
their Provider Directory API.
The proposal to require impacted payers to use an
unexpired version of the CARIN IG for Blue Button and the
[[Page 19911]]
PDex IG adopted by the Secretary for their Payer-to-Payer API.
The proposal to require impacted payers to use an
unexpired version of the CRD, DTR, and PAS IGs adopted by the Secretary
for their Prior Authorization API.
The alternative proposal to require impacted payers to use
an unexpired version of the PDex US Drug Formulary IG adopted by the
Secretary, if the drug formulary data requirement is retained, for
impacted payers' Provider Access and Payer-to-Payer API.
The proposed October 1, 2027 compliance date for the
proposed requirements for impacted payers.
c. Using Testing Tools To Ensure Conformance With Implementation Guides
The technical requirements for the APIs we finalized in the 2020
CMS Interoperability and Patient Access and the 2024 CMS
Interoperability and Prior Authorization final rules include general
requirements for impacted payers to test their interoperability APIs
(85 FR 25514 and 89 FR 8927).\60\ For instance, technical requirements
for APIs established by MA plans in 42 CFR 422.119(c) state that payers
must conduct routine testing and monitoring, and update as appropriate,
to ensure the API functions properly. We are seeking to provide more
information about the existing testing requirement to further advance
interoperable data exchange across the health care system using
standard APIs.
---------------------------------------------------------------------------
\60\ For information on current regulatory requirements that are
applicable to each impacted payer, see Table H1: Use of
Interoperability Standards for Required APIs and Table H2: Use of
Updated Standards for the Required APIs in the 2024 CMS
Interoperability and Prior Authorization final rule (89 FR 8943 and
8944). For information on the proposed regulatory requirements that
would be applicable to each impacted payer, see Table 2: Proposed
Updates to Required Standards for Interoperability APIs in section
II.A.5. of this proposed rule.
---------------------------------------------------------------------------
Testing tools are available that can help impacted payers to meet
existing testing requirements for APIs, for instance, with ensuring
conformance to specified standards. The Inferno testing tool on
HealthIT.gov (hereinafter referred to as ``Inferno'') is an HL7 FHIR
testing tool offered by ONC.\61\ Inferno is an open-source tool for
creating, executing, and sharing conformance tests for numerous FHIR
standards and IGs. ONC has developed test kits within Inferno that can
be used by payers to test API conformance with certain versions of the
required standards and proposed IGs.\62\ For example, Inferno test kits
are currently published for the following specifications:
---------------------------------------------------------------------------
\61\ Assistant Secretary for Technology Policy/Office of the
National Coordinator for Health IT. (n.d.). Inferno on HealthIT.gov.
Retrieved from https://inferno.healthit.gov/.
\62\ Assistant Secretary for Technology Policy/Office of the
National Coordinator for Health IT. (n.d.). Inferno on HealthIT.gov
Test Kits. Retrieved from https://inferno.healthit.gov/test-kits/.
---------------------------------------------------------------------------
CRD IG, Version 2.0.1--STU 2;
DTR IG, Version 2.0.1--STU 2;
PAS IG, Version 2.0.1--STU 2;
CARIN IG for Blue Button, Version 2.0.0--STU 2;
PDex IG, Version 2.0.0--STU 2;
PDex US Drug Formulary IG, Version 2.0.1--STU 2; and
PDex Plan Net IG, Version 1.1.0--STU 1.1.
Inferno uses a combination of automated and manual verification to
assess a system's conformance. Inferno can act as a server to test an
app by receiving requests, returning appropriate responses, and
validating the conformance of the app's requests and its ability to
handle the responses appropriately. Inferno can also test a server by
acting as an app, making requests against the server and validating the
conformance and appropriateness of the server's responses. We intend to
work with ONC on additional and updated test kits for subsequently
adopted versions of the IGs above, new versions of the IGs identified
through the Standards Version Advancement Process (SVAP) that may be
available for voluntary use by payers, and additional IGs identified to
support payer APIs.
CMS strongly encourages impacted payers to utilize available
testing tools, such as the Inferno testing tool, to meet the existing
testing requirements and ensure conformance with the required IGs. We
also encourage impacted payers to publish testing results to
demonstrate conformance with the technical requirements. Doing so would
increase transparency and trust that the technology has been properly
implemented to facilitate interoperability. Inferno can be downloaded
for local deployment and is hosted on ONC's website at https://inferno.healthit.gov/.
We also note that we include an RFI in section III.C. of this
proposed rule soliciting public feedback on how we can continue to
strengthen oversight mechanisms to ensure the required interoperability
APIs are appropriately implemented.
d. Voluntary Use of Updated Versions of Required Standards
As discussed in section II.A.1. of this proposed rule, we
previously finalized policies that allow impacted payers to conform
with updated versions of the required standards in 45 CFR 170.213 and
45 CFR 170.215 under certain conditions. There are certain conditions
that must be met for impacted payers to be permitted to use updated
versions of the required standards, for example, the conditions
described in 42 CFR 422.119(c) for MA plans. We emphasize two of those
conditions here.
First, we note that if impacted payers choose to use updated
standards, it must not disrupt an end user's ability to access the
required data as finalized in the 2020 CMS Interoperability and Patient
Access and 2024 CMS Interoperability and Prior Authorization final
rules (85 FR 25532 and 89 FR 8935). Another condition that permits
impacted payers to voluntarily use an updated version of a required
standard in 45 CFR 170.213 or 45 CFR 170.215 is when the National
Coordinator has approved the updated version for use in the ONC Health
IT Certification Program.\63\ The National Coordinator approves updated
versions of standards for the ONC Health IT Certification Program
through the Standards Version Advancement Process (SVAP), pursuant to
45 CFR 170.555, as finalized in the ``21st Century Cures Act:
Interoperability, Information Blocking, and the ONC Health IT
Certification Program'' final rule (85 FR 25642) (hereinafter referred
to as the ``ONC Cures Act final rule''), which appeared in the Federal
Register on May 1, 2020, as a Maintenance of Certification flexibility
included in the real-world testing Condition of Certification (85 FR
25775). This flexibility permits health IT developers to voluntarily
use, in certain certified Health IT Modules, newer versions of adopted
standards if specific conditions are met, which allows the ONC Health
IT Certification Program to keep pace with the industry's standards
development efforts.
---------------------------------------------------------------------------
\63\ See 42 CFR 422.119(c)(4)(ii) for MA organizations, 42 CFR
431.60(c)(4)(ii) for state Medicaid FFS programs; through cross
references to 42 CFR 431.60 in 42 CFR 438.242(b)(5), 431.61(a) in 42
CFR 438.242(b)(7), 42 CFR 431.61(b)(1) in 42 CFR 438.242(b)(7), 42
CFR 431.70 in 42 CFR 438.242(b)(6), 42 CFR 431.80(b) in 42 CFR
438.242(b)(7) for Medicaid managed care plans; 42 CFR
457.730(c)(4)(ii) for state CHIP FFS programs; through cross
reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed
care entities; and 45 CFR 156.221(c)(4)(ii) for individual market
QHP issuers.
---------------------------------------------------------------------------
Under SVAP, after a standard has been adopted through notice and
comment rulemaking, ONC engages in an open and transparent process to
timely ascertain whether an updated version of the adopted standard or
implementation specification should be
[[Page 19912]]
approved by the National Coordinator for health IT developers'
voluntary use in the ONC Health IT Certification Program. ONC publishes
updated versions of standards under consideration for SVAP and lists
the updated versions of standards that the National Coordinator has
approved as part of the Interoperability Standards Advisory (ISA) on
HealthIT.gov.\64\ Members of the public can use this resource to review
standards that may be approved through SVAP in the future, as well as
provide input on which updated versions should be approved. SVAP occurs
annually, meaning that newer versions of standards will continue to be
updated and assessed by ONC for use. Impacted payers may find it
beneficial to monitor the SVAP process to stay current on standards
updates and to assess whether adoption of a newer version of a standard
may be an option. We encourage impacted payers to review these
resources to better understand how updated versions of the standards in
45 CFR 170.213 and 45 CFR 170.215 may be approved by the National
Coordinator through SVAP and meet that condition for using an updated
standard.
---------------------------------------------------------------------------
\64\ Assistant Secretary for Technology Policy and Office of the
National Coordinator for Health Information Technology. (n.d.).
SVAP. Retrieved from https://www.healthit.gov/isa/standards-version-advancement-process.
---------------------------------------------------------------------------
5. Recommended Implementation Guides To Support Interoperability APIs
and Request for Comment
As we have discussed, using common standards and IGs supports
consistent implementations across the industry. However, as noted in
the 2024 CMS Interoperability and Prior Authorization final rule, IGs
take time to mature (89 FR 8839 through 8841). We believe it is
important to recommend these additional IGs, although they may not be
fully mature, to provide direction towards a common set of
specifications. If we did not include these recommendations, it could
lead to more implementation variation and cause a greater burden on
implementers. We are now recommending additional IGs for certain
interoperability APIs.
For the Provider Access API we are recommending the HL7 FHIR Da
Vinci Member Attribution (ATR) List IG (ATR List IG).\65\ The ATR List
IG provides specific technical guidance for payers and providers to
exchange Member Attribution Lists. The Member Attribution List
typically contains information about plans/contracts, attributed
patients, attributed providers, attributed organizations, and patient
coverage and can be used by providers and payers to support use cases
for quality reporting, payer data exchange, and clinical data exchange
by identifying populations of patients that are relevant between data
exchange partners. The ATR List IG allows transactions to exchange a
full Member Attribution List, request changes to existing Member
Attribution Lists, and request and receive notifications of changes to
Member Attribution Lists. As of the date this proposed rule appears in
the Federal Register, the most recently published version is the ATR
List IG, Version 2.1.0--STU 2.1.
---------------------------------------------------------------------------
\65\ Health Level Seven International. (n.d.). Da Vinci ATR List
IG. Retrieved from http://hl7.org/fhir/us/davinci-atr/ImplementationGuide/hl7.fhir.us.davinci-atr.
---------------------------------------------------------------------------
For the Provider Access API specifically, the ATR List IG can be
used to identify members with an established patient treatment,
contractual, or other type of relationship with providers, provider
groups, and organizations to enable data exchange access. Impacted
payers could also use the ATR List IG to identify groups of members
that are opting out of sharing data with providers.
For the Prior Authorization API, we are recommending the HL7 FHIR
Da Vinci Clinical Data Exchange (CDex) IG.\66\ The CDex IG provides
detailed guidance that helps implementers use FHIR-based interactions
to support specific clinical data exchanges. In the context of the IG,
``clinical data'' means any information a provider holds in a patient's
health record. Unlike the PDex IG, the format of the data exchanged is
not limited to FHIR resources but includes the ability to provide
attachments such as HL7 Consolidated Clinical Document Architecture (C-
CDA) documents, Portable Document Formats (PDFs), text files, and other
types of data. Using the CDex IG allows the standardized exchange of
non-structured data, such as radiological images, questionnaires, or
lab results, as attachments for a variety of purposes, including
determining the medical necessity of a prior authorization request. As
of the date this proposed rule appears in the Federal Register, the
most recently published version is the CDex IG, Version 2.1.0--STU 2.1.
The CDex IG describes how attachments to claims and prior
authorizations transactions can be requested and sent to support payer
operations. We are recommending the CDex IG specifically to support
prior authorization exchanges but note that its capabilities go beyond
that purpose and can be used in the other APIs.
---------------------------------------------------------------------------
\66\ Health Level Seven International. (n.d.). Da Vinci CDex IG.
Retrieved from http://hl7.org/fhir/us/davinci-cdex/ImplementationGuide/hl7.fhir.us.davinci-cdex.
---------------------------------------------------------------------------
In the 2024 CMS Interoperability and Prior Authorization final
rule, we discussed different methods of authentication and
authorization (89 FR 8841-8842). We recognized that while protocols
involving specific user credentials managed by an impacted payer could
be used for the Provider Access and Prior Authorization APIs, other
protocols, such as SMART Backend Services, mutual Transport Layer
Security (mTLS), Unified Data Access Profiles (UDAPTM), or
other trust community-specified means to enable authentication, may be
easier to implement at scale (89 FR 8942). Likewise, protocols
requiring user level credentials, managed by the impacted payer, are
generally not appropriate for business-to-business data exchanges like
the Payer-to-Payer API where an individual may not be directly
initiating the exchange.
As discussed in the 2024 CMS Interoperability and Prior
Authorization final rule, efforts have been made to further refine the
specifications for security (including authentication) at scale through
UDAP via the FHIR at Scale Taskforce (FAST) Security for Scalable
Registration, Authentication, and Authorization IG (FAST Security IG)
(89 FR 8802). We are recommending the FAST Security IG \67\ to support
standardized dynamic registration, authentication, and authorization
requirements for the Patient Access, Provider Access, Payer-to-Payer,
and Prior Authorization APIs to provide a more uniform, standardized,
and automated application registration pathway. The FAST Security IG
enables scalable and standardized application registration capabilities
compatible with FHIR and the SMART App Launch IG. As of the date this
proposed rule appears in the Federal Register, the most recently
published version is the FAST Security IG, Version 2.0.0--STU 2.
---------------------------------------------------------------------------
\67\ Health Level Seven International. (n.d.). FAST Security IG.
Retrieved from https://build.fhir.org/ig/HL7/fhir-udap-security-ig/.
---------------------------------------------------------------------------
We are recommending the FAST Security IG, rather than proposing to
require it, given nascent adoption of business-to-business API-based
technologies among impacted payers. We acknowledge that for the FAST
Security IG to work successfully, there needs to be an entity or a set
of entities to manage the trust between participating organizations
(trust community). While the FAST Security
[[Page 19913]]
IG provides for client registration, authentication, and authorization,
the entity that performs the registration must have a ``trust
relationship'' established.
CMS is considering whether it would be valuable to recommend
additional authentication and authorization standards within FHIR. One
authentication and authorization method that can be used within the
FAST Security IG is Tiered Open Authorization (Tiered
OAuth).68 69 Tiered OAuth enables the federation of digital
identity management across multiple trusted identity providers using
the OpenID Core standard. This frees a data holder (such as an impacted
payer) from having to solely rely on a single identity provider to
maintain the digital identities across all accessing users.
---------------------------------------------------------------------------
\68\ UDAP Unified Data Access Profiles. (n.d.) UDAP Tiered OAuth
for User Authentication. Retrieved from https://www.udap.org/udap-user-auth-stu1.html.
\69\ Health Level Seven International. (n.d.). FAST Security IG.
Retrieved from https://build.fhir.org/ig/HL7/fhir-udap-security-ig/.
---------------------------------------------------------------------------
In addition to the NCPDP implementation standards discussed in
sections II.A.2.b. and II.A.2.c. of this proposed rule that facilitate
the exchange of prescription drug benefit information, we also
recognize that HL7 has developed a FHIR IG called the CARIN Consumer
Real-Time Pharmacy Benefit Check (RTPBC) IG.\70\ This IG could enable
patients to access real-time information about the cost and insurance
coverage of their prescription medications. Specifically, the RTPBC IG
could help patients determine their benefit coverage, estimate their
out-of-pocket costs for specific drugs at the pharmacy, and explore
potential alternative medications. While we are not proposing to
require or recommend adoption of this IG at this time, we acknowledge
that there may be value in making such information available through
the Patient Access API.
---------------------------------------------------------------------------
\70\ Health Level Seven International. (n.d.). Consumer Real-
Time Pharmacy Benefit Check IG. Retrieved from https://hl7.org/fhir/us/carin-rtpbc/.
---------------------------------------------------------------------------
In summary, we request comment on our recommendations, and
specifically on the following:
The recommendation for impacted payers to use the ATR List
IG to document and share attribution lists that identify whose patient
data may be shared with a provider through the Provider Access API.
The recommendation for impacted payers to use the CDex IG
for the Prior Authorization API for exchanging attachments related to
prior authorization.
The recommendation for impacted payers to use the FAST
Security IG for registration, authentication, and authorization for the
Patient Access, Provider Access, Payer-to-Payer, and Prior
Authorization APIs.
Whether any of these IGs are now mature and important
enough for CMS to adopt in a final rule.
In addition, we request comment on the following:
How can CMS know whether and when the ATR List, CDex, and
FAST Security IGs are ready for us to propose to require their use?
Should CMS consider recommending or requiring the FAST
Security IG ``Tiered OAuth'' in future rulemaking?
If CMS proposes, in future rulemaking, to require the FAST
Security IG, should we also propose to require impacted payers to use
Tiered OAuth for user authentication? If so, to which APIs should that
proposal apply? Would this be a useful solution to enable
authentication and authorization at scale?
Are there trust communities that exist today that impacted
payers can utilize for business-to-business authentication and
authorization? Do such communities exist for other stakeholders in the
health care system, such as providers, or in other industries that
could be used or expanded for this purpose?
How much testing is necessary and under what readiness
conditions would it be appropriate for us to propose to require use of
the FAST Security IG for the Patient Access, Provider Access, Payer-to-
Payer, and Prior Authorization APIs?
Should CMS consider recommending the RTPBC IG?
Are there differences in scope or use cases between the
RTPBC IG and the Da Vinci PDex Drug Formulary IG? Specifically, would
RTPBC IG provide additional or distinct benefits compared to the PDex
Drug Formulary IG, or do the two largely address overlapping use cases?
Is there value in providing patients with real-time
prescription drug cost and coverage information through the Patient
Access API?
Are there potential technical or operational challenges
associated with implementing the RTPBC IG within the Patient Access
API?
Is there enough patient demand via third-party apps to
justify the burden of implementing the RTPBC IG?
Do any third-party apps currently include this
functionality, or would developers build it, if recommended?
Do payers or PBMs currently support the required technical
standards to enable third-party apps to use the RTPBC IG and would
payers build that functionality, if recommended?
6. Clarification of Standards for the Provider Directory FHIR API
In the 2024 CMS Interoperability and Prior Authorization final
rule, we stated that we were removing the SMART App Launch IG in 45 CFR
170.215(c)(1) and OpenID Connect Core in 45 CFR 170.215(e), which were
erroneously included as required standards for the Provider Directory
API in Table 10 of the 2022 CMS Interoperability and Prior
Authorization proposed rule (87 FR 76320 and 89 FR 8928) and codified
in the CFR. CMS also discussed this in the 2020 CMS Interoperability
and Patient Access final rule, where we finalized a policy that
security protocols related to user authentication and authorization in
45 CFR 170.215, namely the SMART App Launch IG and OpenID Connect Core
standard, would not apply to the Provider Directory API (85 FR 25560).
We are now proposing that impacted payers be required to implement
and maintain a Provider Directory API (MA organizations in 42 CFR
422.120(a), state Medicaid FFS programs in 42 CFR 431.70(a), state CHIP
FFS programs in 42 CFR 457.760(a), Medicaid managed care plans through
cross reference to 42 CFR 431.70 in 42 CFR 438.242(b)(6), and CHIP
managed care entities through cross reference to 42 CFR 438.242 in 42
CFR 457.1233(d)) conformant with FHIR in 45 CFR 170.215(a) and US Core
IG in 45 CFR 170.215(b)(1), but not the SMART App Launch IG in 45 CFR
170.215(c)(1) or OpenID Connect Core in 45 CFR 170.215(e)(1).
[[Page 19914]]
[GRAPHIC] [TIFF OMITTED] TP14AP26.274
[[Page 19915]]
[GRAPHIC] [TIFF OMITTED] TP14AP26.275
[[Page 19916]]
[GRAPHIC] [TIFF OMITTED] TP14AP26.276
[[Page 19917]]
[GRAPHIC] [TIFF OMITTED] TP14AP26.277
[[Page 19918]]
[GRAPHIC] [TIFF OMITTED] TP14AP26.278
[[Page 19919]]
[GRAPHIC] [TIFF OMITTED] TP14AP26.279
[[Page 19920]]
[GRAPHIC] [TIFF OMITTED] TP14AP26.280
[[Page 19921]]
[GRAPHIC] [TIFF OMITTED] TP14AP26.281
B. Electronic Prior Authorization for Drugs
1. Background of the Prior Authorization API
In the 2024 CMS Interoperability and Prior Authorization final
rule, we finalized requirements for impacted payers to implement and
maintain a Prior Authorization API with compliance dates beginning in
2027 (by January 1, 2027 for MA organizations and state Medicaid and
CHIP FFS programs; by the rating period beginning on or after January
1, 2027 for Medicaid managed care plans and CHIP managed care entities;
and for plan years beginning on or after January 1, 2027 for individual
market QHP issuers on the FFEs).\96\ The Prior Authorization API
enables providers to conduct electronic prior authorizations directly
from their EHRs or other health IT systems by determining whether a
payer requires prior authorization for a particular item or service,
accessing coverage and documentation requirements, submitting the prior
authorization request, and receiving a response to that request,
thereby easing a significant point of administrative burden.
---------------------------------------------------------------------------
\96\ See 42 CFR 422.122(b) for MA organizations, 42 CFR
431.80(b) for state Medicaid FFS programs, 42 CFR 457.732(b) for
state CHIP FFS programs, through cross reference to 42 CFR 431.80(b)
in 42 CFR 438.242(b)(7) for Medicaid managed care plans, through
cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP
managed care entities, and 45 CFR 156.223(b) for individual market
QHP issuers on the FFEs.
---------------------------------------------------------------------------
In that final rule, we limited the required content accessible
through the Prior Authorization API to non-drug items and services. We
excluded all drugs covered by impacted payers (for example, drugs that
may be self-administered, administered by a provider, or that may be
dispensed or administered in a pharmacy or hospital) (89 FR 8762). We
explained in the 2022 CMS Interoperability and Prior Authorization
proposed rule and 2024 CMS Interoperability and Prior Authorization
final rule that existing processes and standards for prior
authorization of drugs differ significantly from those for non-drug
items and services (87 FR 76240-76241 and 89 FR 8765).
[[Page 19922]]
In response to the 2022 CMS Interoperability and Prior
Authorization proposed rule, we received numerous comments requesting
that we reconsider the exclusion of drugs from the proposed
requirements. Those comments stated that providers face similar
challenges with prior authorizations for drugs as with non-drug items
and services, and that the current prior authorization processes
sometimes delay access to medically necessary drug treatments.
Commenters noted that the inconsistent use of technology and standards
can create barriers to care and burden both providers and payers. For
example, providers are sometimes unaware that a prior authorization is
required until a payer rejects a prescription claim presented to a
pharmacy, which causes delays for patients to receive necessary
medication and affects the provider's ability to timely identify and
prescribe an alternative medication. In many cases, providers still
have to use fax, telephone, or payer-specific web portals for drug
prior authorizations. While portals are used for data entry, they
typically do not provide immediate feedback to providers about prior
authorization requirements or accept supporting documentation, nor do
they provide real time responses. Thus, current methods can be
inefficient and create additional process challenges (89 FR 8765-8766).
Many commenters, including payers and providers, advocated that
prior authorization for drugs could and should be incorporated into the
Prior Authorization API. Commenters specifically emphasized the need
for more streamlined electronic prior authorization processes for drugs
administered in a medical setting, such as infusions, oral cancer
drugs, oral antiemetics, and drugs for terminal or chronic conditions,
such as cancer or multiple sclerosis. Other commenters pointed to
existing rules that require Medicare Part D sponsors to offer
electronic prior authorization for covered Part D drugs via a standard
adopted by the Secretary, which includes NCPDP SCRIPT standard versions
2017071 and 2023011, adopted in 45 CFR 170.205(b)(1) and 45 CFR
170.205(b)(2) (89 FR 8765-8766).
In the 2024 CMS Interoperability and Prior Authorization final
rule, we stated that we would gather additional information and
consider opportunities for future rulemaking (89 FR 8765). After
considering stakeholder comments, our goals for interoperability, and
the technical standards available to support electronic prior
authorization for drugs, we are now proposing to require impacted
payers to support electronic prior authorization for all drugs using a
combination of standards, including the HL7[supreg] FHIR[supreg]
standards that compose the Prior Authorization API and the NCPDP
standards required for covered Part D drugs.
2. Existing Standards for Electronic Prior Authorizations
a. Electronic Prior Authorization API
In the 2024 CMS Interoperability and Prior Authorization final
rule, we finalized requirements for impacted payers to implement and
maintain a FHIR API to facilitate prior authorization for non-drug
items and services.\97\ The FHIR standards are designed to support the
interoperable exchange of health care information. In that final rule,
we also recommended impacted payers use certain IGs within their Prior
Authorization APIs, namely the CRD IG, DTR IG, and PAS IG (89 FR 8861).
Details about the standards and IGs for the Prior Authorization API,
including proposals to now require those IGs, are in section II.A. of
this proposed rule. The IGs provide consistent formats to discover
coverage and documentation requirements and exchange prior
authorization requests and responses. The IGs include a set of
workflows designed to support the exchange of prior authorization
information, which includes drugs covered under a medical benefit and
excludes those covered under a pharmacy benefit for which prior
authorization is facilitated by another electronic exchange process
(for example, the NCPDP SCRIPT standard).
---------------------------------------------------------------------------
\97\ See 42 CFR 422.122(b) for MA organizations, 42 CFR
431.80(b) for state Medicaid FFS programs, 42 CFR 457.732(b) for
state CHIP FFS programs, through cross reference to 42 CFR 431.80(b)
in 42 CFR 438.242(b)(7) for Medicaid managed care plans, through
cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP
managed care entities, and 45 CFR 156.223(b) for individual market
QHP issuers on the FFEs.
---------------------------------------------------------------------------
b. X12N 278 Transaction Standard for Prior Authorization(s)
Under the HIPAA Administrative Simplification rules, the Secretary
has adopted standards for use by covered entities--which includes all
impacted payers--for, among other transactions, referral certification
and authorization, a subset of which are used for prior
authorization.\98\ In January 2024, HHS announced it was exercising its
enforcement discretion regarding the standard adopted under HIPAA for
electronic prior authorization, the X12N 278 transaction standard.\99\
HHS announced that it would not take enforcement action against HIPAA
covered entities that, as part of a Prior Authorization API, do not use
the X12N 278 transaction standard. HHS issued that notice of
enforcement discretion based on substantial industry and stakeholder
comments regarding the potential requirement to use the X12N 278
transaction standard in combination with the Prior Authorization API.
Stakeholders informed HHS that requiring the HIPAA standard to be used
within the FHIR standard would be duplicative, unnecessary, and
burdensome. HHS's exercise of enforcement discretion is intended to
promote efficiency. In section II.H.3. of this proposed rule, HHS is
proposing to replace the X12N 278 transaction standard by adopting the
Prior Authorization API as the HIPAA standard for prior authorization-
related transactions.
---------------------------------------------------------------------------
\98\ See 45 CFR 162.1302.
\99\ Department of Health and Human Services. (2024, February
28). Statement of Enforcement Discretion for Referral Certification
and Authorization Transaction Standard at 45 CFR 162.1302 for HIPAA
Covered Entities Subject to the 2024 CMS Interoperability and Prior
Authorization Final Rule (CMS-0057-F) that Implement an All-FHIR-
Based Prior Authorization API. Retrieved from https://www.cms.gov/files/document/discretion-x12-278-enforcement-guidance-letter-remediated-2024-02-28.pdf.
---------------------------------------------------------------------------
c. The NCPDP SCRIPT Standard for Electronic Prior Authorizations
The 2020 Medicare Part D ePA final rule (85 FR 86824-86827)
extensively details the NCPDP SCRIPT standard's history. For context,
we provide here some of the narrative from that final rule. Congress
required electronic prior authorization in the Substance Use Disorder
Prevention that Promotes Opioid Recovery and Treatment for Patients and
Communities Act (hereinafter referred to as the ``SUPPORT Act'') (Pub.
L. 115-271, enacted October 24, 2018). Section 6062 of the SUPPORT Act
amended section 1860D-4(e)(2) of the Act to require Part D sponsors and
prescribing health care professionals to use technical standards
adopted by the Secretary when transmitting electronic prior
authorization requests and responses for coverage of a covered Part D
drug for a Part D eligible individual enrolled in a Part D plan (PDP).
The 2020 Medicare Part D ePA final rule established the NCPDP
SCRIPT standard version 2017071 as the required standard for electronic
prior authorization for covered Part D drugs in 42 CFR 423.160(b)(8)
(85 FR 86832). Part D sponsors and providers were permitted to use the
standard beginning
[[Page 19923]]
January 1, 2021 and were required to do so beginning January 1, 2022.
In the 2024 Part D and Health IT Standards final rule, ONC
finalized a January 1, 2028 expiration date for the NCPDP SCRIPT
standard version 2017071 in 45 CFR 170.205(b)(1) and adopted the NCPDP
SCRIPT standard version 2023011 in 45 CFR 170.205(b)(2). In the same
final rule, CMS finalized the requirement in 42 CFR 423.160(b)(1) that
communication of electronic prior authorization must comply with a
standard in 45 CFR 170.205(b). Therefore, Part D sponsors, providers,
and dispensers are permitted to use either version of the NCPDP SCRIPT
standard to conduct electronic prior authorization for drugs until
January 1, 2028, when the NCPDP SCRIPT standard version 2023011 must be
used exclusively (89 FR 51247).
d. Other HIPAA Standards for Pharmacy Transactions
In 2009, the Secretary adopted the NCPDP Telecommunication Standard
IG, Version D, Release 0 (Version D.0) as a HIPAA Administrative
Simplification transaction standard to improve the efficiency of retail
pharmacy transactions.\100\ Version D.0 is used for retail pharmacy
electronic transactions between pharmacies and payers. Version D.0
allows for accurate and consistent data exchange, reduces errors in
claims processing, enhances eligibility and benefits verification, and
streamlines pharmacy transactions, contributing to an efficient health
care exchange for pharmacies, health care clearinghouses (where used as
an intermediary between pharmacies and payers), and payers. Though
Version D.0 is largely used for claims and eligibility transactions, it
also includes the capability to transmit prior authorization requests
from, and responses to, pharmacies.
---------------------------------------------------------------------------
\100\ See 45 CFR 162.1302.
---------------------------------------------------------------------------
On December 13, 2024, the ``Administrative Simplification:
Modifications of Health Insurance Portability and Accountability Act of
1996 (HIPAA) National Council for Prescription Drugs (NCPDP) Retail
Pharmacy Standards; and Modification of the Medicaid Pharmacy
Subrogation Standard'' final rule (89 FR 100763) (hereinafter referred
to as the ``2024 HIPAA NCPDP Pharmacy Standards final rule'') appeared
in the Federal Register. In that final rule, the Secretary adopted the
NCPDP Telecommunication Standard IG, Version F6 (Version F6) to replace
Version D.0 to address emerging industry needs and improve the accuracy
of pharmacy claim transactions, such as larger fields to accommodate
increasingly expensive drugs (89 FR 100767-100768).
The NCPDP Version F6 Telecommunications standard, like Version D.0,
is designed for transactions between pharmacies and payers, not between
non-pharmacy providers and payers (89 FR 100767-100768). The CMS
proposal to require payers to support the NCPDP SCRIPT standard for
electronic prior authorization does not conflict with the HIPAA
transaction standard because electronic prior authorizations utilizing
the NCPDP SCRIPT standard are not intended to be used by pharmacies.
This rulemaking does not affect pharmacies, which will continue to be
required by HIPAA to use Version F6.
3. Proposed Requirement To Incorporate Drugs Covered Under a Medical
Benefit Into the Prior Authorization API for All Impacted Payers
We are now proposing to require impacted payers to expand the scope
of the required Prior Authorization API to incorporate drugs covered
under a medical benefit, as that term is explained in section I.C. of
this proposed rule. We are proposing an October 1, 2027 compliance date
for MA organizations, state Medicaid and CHIP FFS programs, Medicaid
managed care plans, CHIP managed care entities, and QHP issuers on the
FFEs.
Stakeholder input indicates that enhancing the Prior Authorization
API by incorporating drugs covered under a medical benefit would
improve the prior authorization process by giving providers and
patients more timely information about prior authorization requirements
to obtain these drugs. As with non-drug items and services, a Prior
Authorization API enables EHRs or other health IT to determine whether
prior authorization is required, collect documentation, and submit a
request. Expanding the scope of impacted payers' Prior Authorization
APIs to incorporate drugs covered under a medical benefit would
streamline the administrative process for providers and result in
payers receiving more complete requests and fewer unnecessary requests,
which could accelerate decision-making. Reducing those burdens should
mitigate ambiguity and reduce delays in providing patients with
medically necessary drugs.
Therefore, we are proposing to require impacted payers to enhance
their Prior Authorization APIs by incorporating prior authorization
coverage and documentation requirements for drugs covered under a
medical benefit, as we describe that term in section I.C. of this
proposed rule, beginning October 1, 2027. The IGs we are proposing to
require for the Prior Authorization API include a set of workflows
designed to support prior authorization. Those workflows specifically
include drugs covered under a medical benefit and exclude drugs covered
under a pharmacy benefit, for which prior authorization is conducted by
another electronic exchange process, such as the NCPDP SCRIPT standard.
We emphasize that adding drugs covered under a medical benefit to
the non-drug items and services included in the Prior Authorization API
requires no changes to the existing standards, the IGs we are proposing
to require in section II.A. of this proposed rule, or other recommended
IGs. Furthermore, the functionality of the Prior Authorization API
would not need to be modified, but the specific coverage and
documentation requirements for drugs covered under a medical benefit
would have to be added to the content available via the API.\101\
---------------------------------------------------------------------------
\101\ Health Level Seven International. (2026, March 27). Da
Vinci Prior Authorization Support (PAS) FHIR IG. Retrieved from
https://hl7.org/fhir/us/davinci-pas/usecases.html#scope-of-work-flow.
---------------------------------------------------------------------------
While we describe some of the types of drugs that might be covered
under a medical benefit versus a pharmacy benefit for each payer in
section I.C. of this proposed rule, we do not intend to specify an
exhaustive list of drugs covered under a medical benefit, as each payer
structures their formularies differently while following statutory and
regulatory coverage requirements. For example, while certain infusions,
injections, and services conducted in a provider's office could be
included under a medical benefit, self-administered oral medications
would likely be included under a pharmacy benefit. However, we intend
the categories of ``drugs covered under a medical benefit'' and ``drugs
covered under a pharmacy benefit'' to be mutually exclusive and
collectively include all drugs covered by any particular payer. Put
differently, we are proposing that electronic prior authorization must
be available for all drugs covered by any impacted payer for which they
require prior authorization, either through the Prior Authorization API
or NCPDP SCRIPT standards adopted by the Secretary.
In Medicare FFS, drugs are either payable by Part A or Part B, or
covered by Part D prescription drug coverage. Medicare Part B may pay
for prescription drugs and biologicals (hereinafter referred to as
``drugs'')
[[Page 19924]]
administered in an outpatient setting under certain conditions, for
example, drugs provided as part of (or incident to) a physician's
service and drugs furnished for use with covered DMEPOS items. Many
drugs payable under Part A or Part B are infused or injected by
physicians such as oncologists, rheumatologists, and urologists. Drugs
payable by Part A or Part B are not usually self-administered. Medicare
Part D is the prescription drug benefit of Medicare, which covers most
outpatient prescription drugs through Plan D sponsors and MA
organizations offering MA-PD plans. Covered Part D drugs are defined in
section 1860D-2(e) of the Act. A Part D drug is further defined in 42
CFR 423.100 and includes the following, if used for a medically
accepted indication as defined by section 1860D-2(e)(4) of the Act:
A drug that may be dispensed only upon a prescription that
is described in sections 1927(k)(2)(A)(i) through (iii) of the Act.
A biological product described in sections
1927(k)(2)(B)(i) through (iii) of the Act.
Insulin described in section 1927(k)(2)(C) of the Act.
Medical supplies associated with the injection of insulin.
A vaccine licensed under section 351 of the Public Health
Service Act (hereinafter referred to as the ``PHSA'') (Pub. L. 115-5,
enacted November 21, 1997) and its administration.
A combination product approved and regulated by the Food
and Drug Administration (FDA) as a drug, vaccine, or biologic.
The following are excluded from the definition of Part D drugs:
Drugs for which payment as so prescribed and dispensed or
administered to an individual is available for that individual under
Part A or Part B.
Drugs that may be excluded from coverage or otherwise
restricted under sections 1927(d)(2) or (d)(3) of the Act, except for
smoking cessation agents.
Medical foods that are not regulated as drugs under
section 505 of the Federal Food, Drug, and Cosmetic Act (Pub. L. 75-
717, enacted June 25, 1938).
With some limited exceptions, MA plans are statutorily required to
cover Part A and Part B benefits, including drugs. Most MA plans also
include Part D prescription drug coverage for their Medicare enrollees.
These MA-PDs include drug coverage as a single plan, and patients
enrolled in an MA-PD plan likely do not experience a distinction
between drugs that are payable under Part A or Part B and those covered
under Part D. Medicare patients who are enrolled in an MA plan that
cannot offer Part D coverage (like Medical Savings Account plans) or
choose not to offer Part D coverage (like certain MA-only plans) can
join a separate, standalone PDP.
For MA plans, the term ``drugs covered under a pharmacy benefit''
as used in this proposed rule means covered Part D drugs, as defined in
42 CFR 423.100. Conversely, ``drugs covered under a medical benefit''
as used in this rule means any drugs payable under Part A or Part B.
For Medicaid, although ``prescribed drugs'' is an optional Medicaid
benefit category under section 1905(a)(12) of the Act, all states
currently provide this benefit for all categorically eligible
individuals and most other enrollees within their Medicaid programs.
States are permitted to apply prior authorization requirements to
covered outpatient drugs as long as the prior authorization program
complies with the requirements of section 1927(d)(5) of the Act.\102\
Medicaid managed care plans must conduct their prior authorization
programs in compliance with the requirements of section 1927(d)(5) of
the Act, as if such requirements applied to the Medicaid managed care
plan, if covered outpatient drugs are included in their contracts.\103\
For CHIP, section 2110(a)(6) of the Act authorizes states to cover
drugs within CHIP. For CHIP managed care entities, 42 CFR 457.1230(d)
cross references to the Medicaid managed care regulations in 42 CFR
438.210.
---------------------------------------------------------------------------
\102\ Per section 1927(k)(3) of the Act and 42 CFR 447.502,
drugs that are provided as part of, or as incident to and in the
same setting as a service, and for which payment is made in Medicaid
as payment for part of the service, and not as direct reimbursement
are not ``covered outpatient drugs.'' Accordingly, the prior
authorization requirements in section 1927(d)(5) of the Act do not
apply to such drugs.
\103\ See 42 CFR 438.3(s)(6).
---------------------------------------------------------------------------
For Medicaid and CHIP FFS, we believe that the distinction between
drugs within the proposed scope of the Prior Authorization API and
within the scope of the proposed NCPDP standards can be distinguished
by the systems used to process claims. We expect drugs that are
processed in a claims adjudication system that is not at the point of
sale would be within the proposed scope of the Prior Authorization API.
Conversely, we expect that drugs that are processed in a point of sale
or real-time claims adjudication system would be within the scope of
the proposed NCPDP standards. Thus, the systems that state Medicaid and
CHIP FFS programs use to process claims may serve as an effective
framework for determining which drugs fit within the scope of the Prior
Authorization API and which drugs fit within the scope of the NCPDP
standards.
States that cover drugs under state Medicaid or CHIP FFS or both
programs generally use their Medicaid Management Information System
(MMIS) to process medical claims and another pharmacy system, such as
an electronic claims management system (ECMS), described in 42 CFR
456.722, or PBM, to process pharmacy claims. We believe that the
systems that states use to process claims may be directly relevant to
the state's determination of whether the proposed FHIR or NCPDP
standards should apply for particular prior authorization requests. To
meet the requirements of the 2024 CMS Interoperability and Prior
Authorization final rule, states should already be planning to
integrate the Prior Authorization API for non-drug items and services
with their MMIS or related systems.\104\ States (or their PBMs) may be
able to build the proposed NCPDP standards into the state Medicaid and
CHIP FFS pharmacy systems. If those systems accurately align with the
scope of each standard, states could use the proposed standards for the
electronic prior authorization of drugs into separate systems without
duplication or overlap. We also emphasize that this dichotomy should
not and, if finalized, would not affect any other Medicaid or CHIP
policies related to drug coverage.
---------------------------------------------------------------------------
\104\ See 42 CFR 431.80(b) for state Medicaid FFS programs and
42 CFR 457.732(b) for state CHIP FFS programs.
---------------------------------------------------------------------------
Section 1301(a)(1)(B) of the Patient Protection and Affordable Care
Act, as amended by the Health Care and Education Reconciliation Act of
2010 (hereinafter referred to as the ``Affordable Care Act'') (Pub. L.
111-148, enacted March 23, 2010 and Pub. L. 111-152, enacted March 30,
2010), and section 2707 of the PHSA require QHP issuers on the FFEs to
cover the essential health benefits (EHBs), which includes items and
services in the categories described in section 1302(b) of the
Affordable Care Act, one of which is prescription drugs. There is no
statutory or regulatory distinction between drugs covered under a
medical benefit, as described by the scope of the Prior Authorization
API, and drugs covered under a pharmacy benefit, as described by the
NCPDP SCRIPT standard, for QHP issuers on the FFEs. There are also no
existing requirements for QHP issuers on the FFEs to support electronic
prior authorization for drugs
[[Page 19925]]
in either category. However, we understand that most QHP issuers on the
FFEs structure benefits into medical and pharmacy categories and
therefore should follow their own distinctions for drug coverage.
Should these electronic prior authorization proposals be finalized,
impacted payers would need to review the list of covered drugs for
which they require prior authorization to determine whether they fit
into the scope of the Prior Authorization API (drugs covered under a
medical benefit) or the NCPDP SCRIPT standard (drugs covered under a
pharmacy benefit). Once each payer has evaluated those drugs that
require prior authorization and identified those that may be processed
through the Prior Authorization API, the applicable rules,
requirements, and templates would need to be developed and incorporated
into the API.
We are proposing compliance dates beginning October 1, 2027 for
this proposal. We believe 1 year is the appropriate period for impacted
payers to evaluate and incorporate the additional prior authorization
rules and requirements into their Prior Authorization API. In response
to the 2022 CMS Interoperability and Prior Authorization proposed rule,
commenters stated that payers and developers generally need 1 to 2
years to implement a new system (89 FR 8824-8825). In the 2024 CMS
Interoperability and Prior Authorization final rule, we finalized
compliance dates for policies that require API development and
enhancement beginning in 2027, which provided impacted payers
approximately 3 years to implement the finalized requirements (89 FR
8784, 8817, 8855, and 8897). That feedback was based on the totality of
our policies that require API development or enhancement--to require
three new APIs and to update the Patient Access API. This proposal
would not require impacted payers to build new APIs from scratch, but
to incorporate prior authorization requirements for drugs covered under
a medical benefit into the existing Prior Authorization APIs. Based on
previous industry feedback on development timelines and our experience
implementing the CMS Medicare FFS Prior Authorization API, we believe
the effort to add those prior authorization rules to the API would not
require more than a year.
In summary, we request comment on our proposals in the CFR
citations listed in Table 4, and specifically on the following:
The proposal to require impacted payers to incorporate
coverage and documentation requirements into the Prior Authorization
API to support electronic prior authorization for drugs covered under a
medical benefit, as that term describes the scope of the Prior
Authorization API FHIR standards.
The proposed October 1, 2027 compliance date for MA
organizations, state Medicaid and CHIP FFS programs, Medicaid managed
care plans, CHIP managed care entities, and QHPs issuers on the FFEs.
In addition, we request comments on the following:
Is the scope of the Prior Authorization API, as defined by
its implementation guidance and the description of drugs covered under
a medical benefit, clear and appropriate for impacted payers?
For MA organizations, are there drugs other than those
payable under Part B, such as supplemental benefits, that should be
covered by our proposals to require MA organizations to support
electronic prior authorization?
Is the rubric to categorize drugs as within the scope of
the Prior Authorization API (covered under a medical benefit) or within
the scope of the NCPDP standards (covered under a pharmacy benefit)
based on the system through which the claims are processed applicable
to and appropriate for all or most state Medicaid and CHIP FFS
programs?
Is the system through which claims are processed the
accurate and appropriate way to differentiate the categories of drugs
that are within scope of the Prior Authorization API versus the NCPDP
standards for other types of impacted payers?
4. Proposed Requirement To Support the NCPDP SCRIPT Standard for Prior
Authorization for State Medicaid and CHIP Fee-for-Service Programs,
Medicaid Managed Care Plans, CHIP Managed Care Entities, and Qualified
Health Plan Issuers on the Federally-facilitated Exchanges
We propose to require state Medicaid and CHIP FFS programs,
Medicaid managed care plans, CHIP managed care entities, and QHP
issuers on the FFEs to support an unexpired version of the NCPDP SCRIPT
standard adopted by the Secretary in 45 CFR 170.205(b) for the
electronic prior authorization of drugs covered under a pharmacy
benefit, as that term is described in the standard, further discussed
in section I.C. of this proposed rule. We are making these proposals in
response to comments we received on the 2022 CMS Interoperability and
Prior Authorization proposed rule that stated that requiring impacted
payers to support electronic prior authorization of drugs would support
faster access to necessary medications for patients and reduce
administrative burden on providers.
We are proposing an October 1, 2027 compliance date for state
Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP
managed care entities, and QHP issuers on the FFEs. Requiring state
Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP
managed care entities, and QHP issuers on the FFEs to support an
unexpired version of the NCPDP SCRIPT standard adopted by the Secretary
would align requirements for these payers with the existing requirement
for Medicare Part D sponsors, prescribers, and dispensers in 42 CFR
423.160(b)(1).
Specifically, as discussed in section II.A. of this proposed rule,
we propose that those impacted payers would be required to support an
adopted version of the NCPDP SCRIPT standard to enable providers to
electronically submit prior authorization requests and receive prior
authorization decisions for drugs covered under a pharmacy benefit
using the following transactions:
PAInitiationRequest and PAInitiationResponse
PARequest and PAResponse
PAAppealRequest and PAAppealResponse
PACancelRequest and PACancelResponse
PANotification (NCPDP SCRIPT standard version 2023011
only)
We are not proposing to require providers to use electronic prior
authorization in this proposed rule. Rather, we are proposing that an
unexpired version of the NCPDP SCRIPT standard adopted by the Secretary
must be available for providers to use for prior authorization, and
that the payer must send the response to the prior authorization
request using the same standard. If ONC establishes an expiration date
for an adopted version of the NCPDP SCRIPT standard in 45 CFR
170.205(b), upon the specified expiration date, that version would no
longer be eligible for use by impacted payers to meet the
interoperability requirements. State Medicaid and CHIP FFS programs,
Medicaid managed care plans, CHIP managed care entities, and QHP
issuers on the FFEs may continue to make non-electronic means of
conducting prior authorization (for example, fax, phone call, or direct
data entry through a payer portal) available to providers. However,
should these proposals be finalized, an unexpired version of the NCPDP
SCRIPT standard adopted by the Secretary would be the only electronic
method these payers would be
[[Page 19926]]
permitted to use for the prior authorization of drugs covered under a
pharmacy benefit as that term is described by the implementation
guidance of the NCPDP SCRIPT standard, as discussed in sections II.A.2.
and II.A.3. of this proposed rule.
The NCPDP SCRIPT standard is already used by Medicare Part D
sponsors, prescribers, and dispensers and required for various purposes
by 15 states (for example, for electronic prior authorization and for
electronic prescribing). The proposal to require other impacted payers
to support the standard should create greater efficiency for providers
and drive interoperability across CMS programs.\105\
---------------------------------------------------------------------------
\105\ American Medical Association. (2024). 2024 Prior
Authorization (PA) State Law Chart. Retrieved from https://www.ama-assn.org/system/files/prior-authorization-state-law-chart.pdf.
---------------------------------------------------------------------------
We propose an October 1, 2027 compliance date for state Medicaid
and CHIP FFS programs, Medicaid managed care plans, CHIP managed care
entities, and QHP issuers on the FFEs to support an unexpired version
of the NCPDP SCRIPT standard adopted by the Secretary. That aligns with
the feedback we received in response to the 2022 CMS Interoperability
and Prior Authorization proposed rule that payers and developers
generally need at least a year to implement a new system (89 FR 8824).
In the 2024 CMS Interoperability and Prior Authorization final rule, we
finalized compliance dates beginning in 2027 for policies that require
API development and enhancement. That afforded impacted payers
approximately 3 years to implement from when the rule was finalized (89
FR 8784, 8817, 8855, and 8897). That feedback was based on the totality
of our proposals that require API development or enhancement--to
require three new APIs and to update the Patient Access API. We believe
it is appropriate to afford payers and developers approximately a year
to implement this proposal, which will require time for programming,
testing, education, and outreach.
In summary, we request comment on our proposals in the CFR
citations listed in Table 4, and specifically on the following:
The proposal to require state Medicaid and CHIP FFS
programs, Medicaid managed care plans, CHIP managed care entities, and
QHP issuers on the FFEs to support an unexpired version of the NCPDP
SCRIPT standard adopted by the Secretary in 45 CFR 170.205(b) for the
electronic prior authorization of drugs covered under a pharmacy
benefit.
The proposal to require state Medicaid and CHIP FFS
programs, Medicaid managed care plans, CHIP managed care entities, and
QHP issuers on the FFEs to support an adopted version of the NCPDP
SCRIPT standard using the following transactions: PAInitiationRequest,
PAInitiationResponse, PARequest, PAResponse, PAAppealRequest,
PAAppealResponse, PACancelRequest, PACancelResponse, and PANotification
(currently NCPDP SCRIPT standard version 2023011 only).
The proposed October 1, 2027 compliance date for state
Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP
managed care entities, and QHP issuers on the FFEs.
5. Proposed Requirement To Support the NCPDP Formulary and Benefit
Standard for State Medicaid and CHIP Fee-for-Service Programs, Medicaid
Managed Care Plans, CHIP Managed Care Entities, and Qualified Health
Plan Issuers on the Federally-facilitated Exchanges
We are proposing to require state Medicaid and CHIP FFS programs,
Medicaid managed care plans, CHIP managed care entities, and QHP
issuers on the FFEs to support an unexpired version of the NCPDP F&B
standard adopted by the Secretary in 45 CFR 170.205(u) by October 1,
2027. Accordingly, upon the specified expiration date of a version of
the NCPDP F&B standard adopted in 45 CFR 170.205(u), that version would
no longer be eligible for use by impacted payers to meet this proposal,
if finalized.
As discussed in section II.A.2.b. of this proposed rule, the NCPDP
F&B standard enables providers to view formulary and benefit
information at a group level. The NCPDP F&B standard supports the NCPDP
SCRIPT standard by giving providers information at the point of
prescribing about whether a payer covers a particular drug and whether
the payer requires prior authorization. Therefore, our proposal to
require impacted payers to support an unexpired version of the NCPDP
F&B standard adopted by the Secretary should enhance providers' ability
to electronically request prior authorization for drugs covered under a
pharmacy benefit. As with our other proposals, the NCPDP F&B standard
should enable a more seamless exchange of prior authorization
requirements, which should help state Medicaid and CHIP FFS programs,
Medicaid managed care plans, CHIP managed care entities, and QHP
issuers on the FFEs more efficiently manage their pharmacy benefits and
prior authorization programs. A standardized approach to providing
formulary and prior authorization information could make provider and
payer operations more efficient and reduce costs.
The 2024 Part D and Health IT Standards final rule also includes
requirements for transmitting formulary and benefits information
between Part D sponsors and providers using the NCPDP F&B standard.
Specifically, until January 1, 2027, that rule requires Part D sponsors
to use either NCPDP F&B standard version 3.0 or an unexpired version of
the NCPDP F&B standard adopted by the Secretary in 45 CFR 170.205(u).
Beginning January 1, 2027, Part D sponsors are required to use an
unexpired version of a standard adopted by the Secretary in 45 CFR
170.205(u), which is currently NCPDP F&B standard version 60 (89 FR
51250-51251).\106\ Our proposal to require the other types of impacted
payers (state Medicaid and CHIP FFS programs, Medicaid managed care
plans, CHIP managed care entities, and QHP issuers on the FFEs) to
implement an unexpired version of the NCPDP F&B standard adopted by the
Secretary in 45 CFR 170.205(u) would align payers and should reduce the
burden on providers currently using disparate systems and standards
across payers.
---------------------------------------------------------------------------
\106\ National Council for Prescription Drug Programs. NCPDP
Formulary and Benefit Standard Implementation Guide, Version 60.
Retrieved from https://standards.ncpdp.org/Access-to-Standards.aspx.
NCPDP F&B standard IGs are available to NCPDP members for free and
to non-members for a fee at this website.
---------------------------------------------------------------------------
In summary, we request comment on our proposals in the CFR
citations listed in Table 4, and specifically on the following:
The proposal to require state Medicaid and CHIP FFS
programs, Medicaid managed care plans, CHIP managed care entities, and
QHP issuers on the FFEs to support an unexpired version of the NCPDP
F&B standard adopted by the Secretary in 45 CFR 170.205(u) to make
available formulary and benefits information for drugs covered under a
pharmacy benefit.
The proposed October 1, 2027 compliance date for state
Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP
managed care entities, and QHP issuers on the FFEs.
[[Page 19927]]
6. Proposed Requirement To Support the NCPDP Real-Time Prescription
Benefit Standard for State Medicaid and CHIP Fee-for-Service Programs,
Medicaid Managed Care Plans, CHIP Managed Care Entities, and Qualified
Health Plan Issuers on the Federally-facilitated Exchanges
We also propose that state Medicaid and CHIP FFS programs, Medicaid
managed care plans, CHIP managed care entities, and QHP issuers on the
FFEs support an unexpired version of the NCPDP RTPB standard adopted by
the Secretary in 45 CFR 170.205(c) by October 1, 2027.
The 2024 Part D and Health IT Standards final rule requires,
beginning January 1, 2027, Part D sponsors' real-time benefit tools to
comply with an unexpired version of a standard adopted by the Secretary
in 45 CFR 170.205(c) (89 FR 51247 and 51251).\107\ Currently, the
version of the NCPDP RTPB standard that the Secretary has adopted in 45
CFR 170.205(c) is NCPDP RTPB standard version 13, adopted in 45 CFR
170.205(c)(1). As discussed in section II.A.2.c. of this proposed rule,
the NCPDP RTPB standard enables real-time, patient-specific
prescription benefit information to be delivered to providers at the
point of prescribing. This proposal should coalesce support for the
NCPDP SCRIPT standard and improve efficiency and accuracy. By
integrating the NCPDP RTPB standard into the prior authorization
process, payers could provide immediate feedback to providers about a
patient's coverage, including whether a drug covered under a pharmacy
benefit requires prior authorization, alternative covered medications,
and patient out-of-pocket costs. State Medicaid and CHIP FFS programs,
Medicaid managed care plans, CHIP managed care entities, and QHP
issuers on the FFEs could reduce administrative costs by providing
prior authorizations and coverage information up front by avoiding
unnecessary requests. Providers and patients could benefit from
implementing the NCPDP RTPB standard because real-time benefit
information could reduce care delays or unexpected costs.
---------------------------------------------------------------------------
\107\ National Council for Prescription Drug Programs. NCPDP
Real-Time Prescription Benefit Standard, Implementation Guide,
Version 13. Retrieved from https://standards.ncpdp.org/Access-to-Standards.aspx. NCPDP RTPB standard IGs are available to NCPDP
members for free and to non-members for a fee at this website.
---------------------------------------------------------------------------
Our proposal to require these standards continues our goal towards
interoperability and adoption of modern standards, reducing industry
fragmentation. This standardization could encourage innovation and
development of more sophisticated clinical decision support tools.
In summary, we request comment on our proposals in the CFR
citations listed in Table 4, and specifically on the following:
The proposal to require state Medicaid and CHIP FFS
programs, Medicaid managed care plans, CHIP managed care entities, and
QHP issuers on the FFEs to support an unexpired version of the NCPDP
RTPB standard adopted by the Secretary in 45 CFR 170.205(c) to make
available real-time coverage information for drugs covered under a
pharmacy benefit.
The proposed October 1, 2027 compliance date for state
Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP
managed care entities, and QHP issuers on the FFEs.
7. Extensions, Exemptions, and Exceptions
In the 2024 CMS Interoperability and Prior Authorization final
rule, we finalized processes for state Medicaid and CHIP FFS programs
to request an extension to the compliance date or an exemption from
requirements to build some of the interoperability APIs if they meet
certain criteria.\108\ We also finalized a process for individual
market QHP issuers on the FFEs to request an exception from the
requirement to build the interoperability APIs under certain
circumstances.\109\
---------------------------------------------------------------------------
\108\ For the Provider Access and Payer-to-Payer APIs, see 42
CFR 431.61(c) for state Medicaid FFS programs and 42 CFR 457.731(c)
for state CHIP FFS programs. For the Prior Authorization API, see 42
CFR 431.80(c) for state Medicaid FFS programs and 42 CFR 457.732(d)
for state CHIP FFS programs.
\109\ For the Provider Access and Payer-to-Payer APIs, see 45
CFR 156.222(c). For the Prior Authorization API, see 45 CFR
156.223(d).
---------------------------------------------------------------------------
However, if HHS finalizes its proposal to adopt the FHIR
specifications that compose the Prior Authorization API as the HIPAA
standard for ``referral certification and authorization'' transactions
(further discussed in section II.H. of this proposed rule), it could
affect impacted payers' (which are HIPAA covered entities) ability to
request extensions, exemptions, and exceptions from the requirement to
implement the Prior Authorization API finalized in the 2024 CMS
Interoperability and Prior Authorization final rule.
a. State Medicaid and CHIP Fee-for-Service Programs
The process for state Medicaid and CHIP agencies to request an
exemption from the Prior Authorization API includes requirements, in 42
CFR 431.80(c)(2)(ii)(B)(2) and 42 CFR 457.732(d)(2)(ii)(B)(2), that
states must provide an alternative plan to ensure that enrolled
providers will have efficient electronic access to the same information
through other means while the exemption is in effect. At the time the
2024 CMS Interoperability and Prior Authorization final rule was
finalized and today, the existing HIPAA standard for prior
authorization transactions is the X12N 278 transaction standard. We
finalized the exemption process with the understanding that a HIPAA-
compliant X12N 278 transaction standard would be an acceptable
alternative to meet that requirement. However, if HHS's HIPAA proposals
in section II.H. are finalized, that standard would no longer be HIPAA-
compliant as of the finalized compliance date.
Because the purpose of the HIPAA Administrative Simplification
provisions is to ensure that covered entities do not use electronic
transactions other than those adopted by the Secretary, there would be
no other permissible alternative electronic methods for state Medicaid
and CHIP FFS programs to use. Since there would be no other HIPAA-
permitted alternative electronic methods once HIPAA proposals are
finalized, state Medicaid and CHIP FFS programs previously eligible for
an exemption to the Prior Authorization API would no longer have the
ability to sustain an alternative plan to support electronic prior
authorization.\110\ The HIPAA Administrative Simplification statute and
regulations do not provide for exceptions or exemptions, other than
that described in 45 CFR 162.940 to permit testing of proposed
modifications. Therefore, in order to ensure that the Prior
Authorization API exemption requirements finalized in 42 CFR
431.80(c)(2) for state Medicaid FFS programs and in 42 CFR
457.732(d)(2) for state CHIP FFS programs do not conflict with the
proposed HIPAA Administration Simplification requirements, we are
proposing to remove the policy finalized in the 2024 CMS
Interoperability and Prior Authorization final rule that allows states
with small FFS populations to request an exemption from CMS for the
non-drug items and services Prior Authorization API requirements. If
finalized as proposed, removal of this policy would result in the
eventual expiration of any approved exemptions without the possibility
of renewal. Notably, there are no HIPAA standard transactions related
to the Patient Access, Provider Directory, Provider Access, or Payer-
to-Payer APIs, so the
[[Page 19928]]
ability to request an exemption for these standards would not be
affected and we are proposing no changes to the extensions and
exemptions policies finalized in the 2024 CMS Interoperability and
Prior Authorization final rule for those APIs.
---------------------------------------------------------------------------
\110\ See 42 CFR 431.80(c)(2)(ii)(B)(2).
---------------------------------------------------------------------------
However, to provide additional flexibility to state Medicaid and
CHIP FFS programs, we are proposing to extend the policy that allows
any state to request extensions for additional years until the HIPAA
compliance date, if HHS finalizes its proposals. As discussed in
section II.H.8. of this proposed rule, we are proposing a multiple year
gap between the finalized Prior Authorization API compliance dates for
impacted payers and the proposed compliance dates to our proposals to
adopt FHIR standards as the HIPAA transaction standard for prior
authorization transactions. As discussed in section II.H. of this
proposed rule, we believe it would be appropriate to give 24 months for
implementation between the effective date of the final rule and the
proposed compliance date for most covered entities and 36 months for
small health plans. As defined in 45 CFR 160.103, small health plans
are those with annual receipts of $5 million or less. As state Medicaid
and CHIP agencies are not commercial entities, they may generally be
considered small health plans.\111\ As state Medicaid and CHIP agencies
are not considered for-profit entities, we would not expect them to
reach the small health plan $5 million dollar threshold and therefore
would be considered small health plans for the purpose of granting
extensions up to 36 months.
---------------------------------------------------------------------------
\111\ See discussion in 65 FR 82579 that clarifies that ``pure
premiums'' can be substituted for ``annual receipts,'' as
appropriate.
---------------------------------------------------------------------------
Some states may be unable to meet the proposed CMS interoperability
compliance dates in this proposed rule due to funding challenges for
necessary contracting and staff resources to develop and implement the
technical requirements, depending on when the final rule is published
in relation to a state's FY, legislative session, budget process, and
related timelines. Some states may need to initiate a public
procurement process to secure contractors with the necessary skills to
support a state's implementation of these proposals. The timeline for
an openly competed procurement process and the time required to onboard
the contractor and develop the technical capabilities proposed here can
be lengthy for states. A state might need to hire new staff with the
necessary skills to implement our finalized policies and proposals to
require impacted payers to support electronic prior authorization.
Overlapping requirements with varying timelines and exceptions add
significant uncertainty to state FFS operations and makes responsible
stewardship of federal funding more challenging. If HHS finalizes its
proposals to modify the HIPAA transaction standard for prior
authorization transactions, states would need to track multiple
compliance dates, understand which standards are permissible at
different times, and potentially procure funding and staffing to revise
new API system implementations accordingly in coordination with state
legislatures. These requirements, whether final or proposed, come at a
time when state resources are allocated toward implementation of recent
statutory changes, notably the Working Families Tax Cut legislation
(Pub. L. 119-21, enacted July 4, 2025), making it difficult for them to
reallocate or redirect resources. Providing state Medicaid and CHIP FFS
programs the ability to request extensions to the compliance dates
proposed here could mitigate these challenges. In addition, it could
align with the requirements for covered entities that are not CMS
impacted payers to use the proposed FHIR standard if they engage in
electronic prior authorization.
To align with the proposals to support electronic prior
authorization for drugs with those for electronic prior authorization
of non-drug items and services, we also propose to offer similar
flexibilities for state Medicaid and CHIP FFS programs to request
extensions to the October 1, 2027 compliance date for the proposed
requirements to incorporate drugs into the Prior Authorization API and
to support the NCPDP standards for the electronic prior authorization
of drugs.
Should our proposals be finalized, a state Medicaid or CHIP FFS
program could request from CMS extensions to the compliance dates for
(1) the non-drug items and services Prior Authorization API
requirements finalized in the 2024 CMS Interoperability and Prior
Authorization final rule; (2) the proposal to incorporate drugs into
the Prior Authorization API; and (3) the proposal to require impacted
payers to support NCPDP standards for the electronic prior
authorization of drugs. States must be clear to which of these
requirements they are requesting an extension and the required
justification must be attenuated to the specific requirements.
We propose that a state must submit that request as a part of its
annual Advance Planning Document (APD) for MMIS operations expenditures
in sufficient time to be approved before the applicable compliance
date. The state's request would have to include the following: (1) a
narrative justification describing the specific reasons why the state
cannot satisfy the requirement(s) by the compliance date and why those
reasons result from circumstances that are unique to the agency
operating the state Medicaid or CHIP FFS program; (2) a report on
completed and ongoing state activities that evidence a good faith
effort towards compliance; and (3) a comprehensive plan to meet the
requirements before a finalized HIPAA compliance date.
Under this proposal, CMS would approve an extension if, based on
the information provided in the APD, CMS were to determine that the
request adequately establishes a need to delay implementation and that
the state has a comprehensive plan to implement the proposed
requirements before a finalized HIPAA compliance date.
We understand that state Medicaid and CHIP FFS programs have
numerous competing priorities and face additional funding and staff
limitations compared to commercial entities (89 FR 8902). Therefore, we
encourage states to contact their Medicaid Enterprise Systems (MES)
officer, if necessary for proper and efficient operations, to discuss
their extenuating circumstances. Any flexibility granted to a state
Medicaid or CHIP FFS program would be temporary and limited to the
unique circumstances of the program.
b. Exceptions for Qualified Health Plan Issuers on the Federally-
facilitated Exchanges
In the 2020 CMS Interoperability and Patient Access and the 2024
CMS Interoperability and Prior Authorization final rules, we finalized
a process for individual market QHP issuers on the FFEs to submit a
request for an exception from the technical requirements finalized in
those rules.\112\ We explained that ability of QHP issuers on the FFEs
to implement the interoperability APIs might vary based on their
available resources.
---------------------------------------------------------------------------
\112\ For the Patient Access API, see 45 CFR 156.221(h). For the
Provider Access and Payer-to-Payer APIs, see 45 CFR 156.222(c). For
the Prior Authorization API, see 45 CFR 156.223(d).
---------------------------------------------------------------------------
Those final rules established that individual market QHP issuers on
the FFEs that apply for an exception must submit a narrative
justification as part of their QHP application. That narrative
[[Page 19929]]
justification must describe the reasons why the plan cannot reasonably
satisfy the requirements for the applicable plan year, the impact of
non-compliance upon providers and/or enrollees, the current or proposed
means of providing health information to the applicable recipient, and
solutions and a timeline to achieve compliance with the requirements of
the applicable section. As described previously, any current or
proposed means that differ from the finalized interoperability standard
must be compliant with the HIPAA administrative simplification
requirements. In the 2024 CMS Interoperability and Prior Authorization
final rule, we also noted that QHP issuer certification applications in
recent years indicated that most QHP issuers on the FFEs are compliant
with the requirements to implement and maintain a Patient Access API;
that is, they did not request exceptions through the process. Of the
QHP issuers on the FFEs that did request exceptions, many explained in
their justifications that they planned to become compliant with the API
requirements mid-way through the upcoming plan year (89 FR 8906).
CMS takes a similar approach during the QHP certification process
in other instances where flexibility may be warranted based on a QHP
issuer's circumstances. For example, per 45 CFR 156.230(a)(2)(ii), if a
plan applying for QHP certification to be offered through the FFE does
not satisfy the network adequacy standards described in paragraphs 45
CFR 156.230(a)(2)(i)(A) and 45 CFR 156.230(a)(2)(i)(B), as part of its
QHP application, the issuer must include a justification describing how
the plan's provider network provides an adequate level of service for
enrollees and how the plan's provider network will be strengthened and
brought closer to compliance with the network adequacy standards prior
to the start of the plan year. The issuer must provide information as
requested by the FFE to support this justification. Our experience with
these exceptions processes for rules that are currently in effect
suggest that making an exception available prevents the FFE from
potentially losing issuer participation based on concerns the issuer
will ultimately be able to address during or before the plan year,
typically resulting in no potential harm to consumers. In particular,
we have observed that QHP issuers have submitted narrative
justifications that may meet or be close to meeting the standards of
providing an adequate level of service to enrollees by the start of the
applicable plan year.
Therefore, we propose an exception process to the proposed NCPDP
standards requirements for QHP issuers on the FFEs in 45 CFR
156.223(i). We propose that if an issuer applying for QHP certification
to be offered through an FFE believes it cannot satisfy the proposed
requirement to support the proposed NCPDP standards, the issuer would
have to include in its QHP application a narrative justification
describing the reasons why it could not satisfy the requirements for
the applicable plan year, the effect of non-compliance upon providers
and enrollees, the current or proposed means of providing health
information to providers and facilitating prior authorization, and
solutions and a timeline to achieve compliance with the applicable
requirements.
We propose that an FFE may grant an exception to the proposed
requirement to support the NCPDP standards if it determines that making
QHPs of such issuer available through the Exchange is in the interests
of qualified individuals and qualified employers in the state or states
in which the Exchange operates and that an exception is warranted to
permit the issuer to offer QHPs through the FFE. This proposal is
consistent with the exceptions for individual market QHP issuers on the
FFEs that we finalized for the Patient Access, Provider Access, Payer-
to-Payer, and Prior Authorization APIs.\113\
---------------------------------------------------------------------------
\113\ For additional discussion of considerations related to
granting an exception, please see 2024 CMS Interoperability and
Prior Authorization final rule preamble (89 FR 8905-8906).
---------------------------------------------------------------------------
In addition, we propose to amend the requirements in 45 CFR
156.223(h)(1)(iii) to specify that QHP issuers on the FFEs, as part of
a request for an exception from the Prior Authorization API
requirements in 45 CFR 156.223(b), describe the current or proposed
means of conducting prior authorization. Under the current requirement
finalized in the 2024 CMS Interoperability and Prior Authorization
final rule, QHP issuers on the FFEs that are applying for an exception
must describe their current or proposed means of providing health
information to providers. However, providing health information to
providers does not describe the full scope of the Prior Authorization
API. While part of the purpose of the Prior Authorization API is to
make available to providers information about prior authorization
requirements, it is also to facilitate prior authorization using
bidirectional data exchanges between providers and payers. To align
with the full scope and purpose of the Prior Authorization API, we
believe that any QHP issuer on the FFE that applies for an exception
should describe how they will facilitate prior authorization, not just
how health information will be provided to providers.
In summary, we request comment on our proposals in the CFR
citations listed in Table 4, and specifically on the following:
The proposal to remove the policy finalized in the 2024
CMS Interoperability and Prior Authorization final rule that allows
states with small FFS populations to request an exemption from CMS for
the non-drug items and services Prior Authorization API requirements.
The proposal that state Medicaid and CHIP FFS programs may
request extensions to the finalized compliance date to implement the
Prior Authorization API and the proposed compliance date to incorporate
drugs covered under a medical benefit into the Prior Authorization API.
The proposal that state Medicaid and CHIP FFS programs may
request extensions and that QHP issuers on the FFEs may request an
exception from the proposed requirement to support an unexpired version
of the NCPDP standards that the Secretary has adopted in 45 CFR
170.205(b), (c), or (u).
The proposal to amend language in 45 CFR
156.223(i)(1)(iii) to require that a QHP issuer on the FFEs seeking an
exception from the Prior Authorization API requirements and/or proposed
requirement to support an unexpired version of the NCPDP standards that
the Secretary has adopted in 45 CFR 170.205(b), (c), or (u) to describe
their current or proposed means of conducting prior authorization.
In addition, we request comments on the following:
Flexibilities and options that can be provided to state
Medicaid and CHIP FFS programs eligible for an exemption and QHP
issuers on the FFEs eligible for an exception that would reduce burden
for the reasons outlined previously, while ensuring compliance with the
proposed or adopted HIPAA transaction standards.
[[Page 19930]]
[GRAPHIC] [TIFF OMITTED] TP14AP26.282
[[Page 19931]]
8. Statutory Authorities
a. Medicare Advantage
Section 1856(b) of the Act directs the Secretary to establish
regulatory standards for MA organizations that are consistent with and
carry out Part C of the Medicare statute, including the provisions in
section 1852 of the Act. Section 1852(c)(1)(G) of the Act requires that
MA organizations disclose to their enrollees any rules regarding prior
authorization, and section 1852(g)(1) of the Act requires MA
organizations to have procedures for making timely determinations
regarding whether an enrollee is entitled to receive a health service.
Section 1857(e)(1) of the Act authorizes the addition of contract terms
for contracts between the Secretary and an MA organization determined
by the Secretary to be ``necessary and appropriate'' for the MA
program. This broad authority encompasses the adoption of standards for
electronic prior authorization, which are important for improving
efficiency and reducing burdens in health care delivery.
The Prior Authorization API is an electronic means for receiving
and responding to requests for coverage determinations before the
services are rendered or items furnished. The proposed requirement to
incorporate drugs covered under a medical benefit that may require
prior authorization into the Prior Authorization API is consistent with
MA organizations' obligations under sections 1852(c)(1)(G) and
1852(g)(1) of the Act. Pursuant to the Secretary's authority under
sections 1856(b) and 1857(e)(1) of the Act, we are proposing to require
MA organizations to expand the scope of the Prior Authorization API to
incorporate drugs covered under a medical benefit.
We propose additional requirements for MA organizations to ensure
that providers have further information about drug prior authorization
through the Prior Authorization API required under regulations in 42
CFR 422.122(b). This proposed requirement would necessitate updating
the Prior Authorization API with information about the coverage and
documentation requirements for prior authorization of drugs covered
under a medical benefit and responding to prior authorization requests
for such drugs through the Prior Authorization API.
We propose requiring MA organizations to expand the Prior
Authorization API using recommended or updated implementation
specifications discussed in section II.A. of this proposed rule. These
implementation specifications are expected to improve the prior
authorization process by addressing absences in providers' access to
information about the prior authorization rules and documentation
requirements for drugs. Under our proposal, the mandatory Prior
Authorization API would communicate the coverage and documentation
requirements for prior authorization for drugs covered under a medical
benefit, indicating if authorization is required and what documentation
is required to support an authorization request. This electronic API-
enabled access to information should improve timely access to care for
patients by mitigating delays for necessary medications known to occur
when a provider is trying to determine drug coverage or eligibility
requirements or does not know what documents to submit to obtain prior
authorization.
If applicable, providers' burden may be reduced if they can submit
a prior authorization request and access status and decision
information for drugs through an MA organization's Prior Authorization
API. The required Prior Authorization API can potentially improve the
efficiency of the prior authorization process for drugs covered under a
medical benefit as much as it does for non-drug items and services if
the number of appeals, denials, and requests for additional
documentation can be reduced.
We believe this proposal to extend the scope of the Prior
Authorization API to incorporate drugs covered under a medical benefit
should contribute to program efficiency and effective operations and
should be in the best interest of MA enrollees.
b. State Medicaid and CHIP
For Medicaid, most of the proposals described in this section are
authorized by sections 1902(a)(4), 1902(a)(8), and 1902(a)(19) of the
Act. Section 1902(a)(4) of the Act requires that a state Medicaid plan
provide such methods of administration as are found by the Secretary to
be necessary for the proper and efficient operation of the state
Medicaid plan. Section 1902(a)(8) of the Act requires states to ensure
that Medicaid services are furnished with reasonable promptness to all
eligible individuals, which may result in faster beneficiary access to
services. Section 1902(a)(19) of the Act requires states to ensure that
care and services under a Medicaid state plan are provided in a manner
consistent with the simplicity of administration, which can result in
more uniform IT regulations and standards that are in the best
interests of the recipients. For Medicaid managed care, section
1932(c)(1)(A) of the Act requires that states that contract with
Medicaid MCOs develop and implement a quality assessment and
improvement strategy that includes standards for access to care so that
covered services are available within reasonable timeframes. CMS relies
on our authority in section 1902(a)(4) of the Act to apply these
standards for PIHPs and PAHPs.
The proposals to incorporate drugs covered under a medical benefit
into the Prior Authorization API and to improve electronic prior
authorization for covered outpatient drugs by supporting the adopted
version of the NCPDP SCRIPT standard by the Medicaid programs is
supported by the sections of the Act referenced previously. For this
proposal, CMS would rely on our authority in section 1902(a)(4) of the
Act to adopt these standards for PIHPs and PAHPs. This would ensure
that the same requirements apply to MCOs, PIHPs, and PAHPs.
The proposal for state Medicaid FFS programs and Medicaid managed
care plans to implement electronic prior authorization for drugs is
expected to improve the efficiency and timeliness of the prior
authorization process for Medicaid beneficiaries, providers, state
Medicaid agencies, and Medicaid managed care plans by addressing
inefficiencies that might exist in the process today. Support for the
proposed FHIR and NCPDP standards could allow a provider to determine
whether a prior authorization is required and the documentation
requirements for that prior authorization request. The Prior
Authorization API and NCPDP SCRIPT standard can improve the prior
authorization process by making it more efficient, including by
reducing the number of denials and appeals or eliminating requests for
additional documentation. Those standards could--
Enable providers to submit a complete prior authorization
request faster and easier;
Support more timely notice to the provider and beneficiary
of the disposition of the prior authorization request; and
Permit improved scheduling of services or filing appeals,
depending on the decision.
For CHIP, we are proposing these requirements under the authority
of section 2101(a) of the Act, which sets forth that the purpose of
Title XXI is to provide funds to states to provide child health
assistance to uninsured, low-income children effectively and
efficiently that is coordinated with other sources of health benefits
coverage.
We are proposing to require state CHIP FFS programs and CHIP
managed
[[Page 19932]]
care entities to implement systems to support electronic prior
authorization for all drugs to improve the prior authorization process
for patients, providers, and payers. We believe these proposals should
address deficiencies and inefficiencies that exist currently. Today, a
payer's rules about when prior authorization is required for drugs and
the documentation requirements are not necessarily easily accessible
for providers. The Prior Authorization API and support for the proposed
NCPDP standards should enable a provider to determine whether prior
authorization is required for a drug, to access the documentation
requirements, and to submit a prior authorization request
electronically. While we expect providers to be the primary
beneficiaries of these proposals, improving prior authorization for
drugs could also serve the requirements in section 2101(a) of the Act
that CHIP ensures access to coverage and coordinated care.
c. Qualified Health Plan Issuers on the Federally-facilitated Exchanges
Section 1311(e)(1)(A) of the Affordable Care Act requires that
Exchanges only certify plans as QHPs if they meet the requirements for
certification promulgated by the Secretary under section 1311(c)(1) of
the Affordable Care Act, while section 1311(e)(1)(B) of the Affordable
Care Act provides discretion to certify QHPs if the Exchange determines
that making such plans available is in the interests of qualified
individuals and qualified employers in the state or states in which the
Exchange operates.
For QHP issuers on the FFEs, we are proposing to amend the QHP
certification standard that we finalized in the 2024 CMS
Interoperability and Prior Authorization final rule using the same
authority under section 1311(e)(1) of the Affordable Care Act. These
proposals would expand the use of specific technology and standards to
promote efficiency and transparency in the prior authorization process
for drugs, which should improve access to care for enrollees in QHPs
offered by issuers on the FFEs by ensuring that the QHP issuers on the
FFEs respond to prior authorization requests promptly through a
modernized process and clearly explain their rationale in cases of
denial. Our proposal to require that QHP issuers on the FFEs support
electronic prior authorization for all covered drugs either through the
Prior Authorization API as described in 45 CFR 156.223(b) or through an
unexpired version of the NCPDP SCRIPT standard that the Secretary has
adopted in 45 CFR 170.205(b), combined with the ability of QHP issuers
on the FFEs to request an exception, is in the interest of qualified
individuals and qualified employers because it balances the goals of
ensuring access to health care with robust QHP issuer participation on
the FFEs.
Enrollees in QHPs on the FFEs may receive approved covered drugs
more quickly when their providers can submit a prior authorization
request electronically. These proposed requirements would allow
providers to determine whether prior authorization is required for
drugs, submit the necessary documentation, and receive an electronic
response in real-time or near real-time. As we explained in the 2024
CMS Interoperability and Prior Authorization final rule regarding the
APIs required in that final rule (89 FR 8786), we believe that, with
limited exceptions, certifying only health plans that support
electronic prior authorization for all covered drugs and adhere to the
other requirements described in this section of the preamble is in the
interests of qualified individuals and qualified employers in the state
or states in which a QHP issuer on the FFEs operates because of the
opportunities for improvements in patient care. We encourage SBEs,
including SBE-FPs, to consider whether a similar requirement should
apply to issuers participating in their Exchanges.
C. Improving Communications and Decision Timeframes for Prior
Authorizations
1. Background for Improving Prior Authorization Process
In the 2024 CMS Interoperability and Prior Authorization final
rule, we described the impact of excessive wait times for prior
authorization decisions on patients, providers, and payers (89 FR 8858
and 8859). We discussed surveys, federal reports, and studies,
including a multi-year survey conducted by the American Medical
Association (AMA) about delays in care and medical risks to patients
due to issues with prior authorization (89 FR 8859).\114\ Concerns
about prior authorization processes have remained the same. According
to a 2024 AMA report, 29 percent of physicians reported that prior
authorization had led to a severe adverse event for a patient in their
care, including hospitalization, permanent impairment, or death, and 94
percent reported that prior authorization harmed patient clinical
outcomes.\115\ In response to the 2022 CMS Interoperability and Prior
Authorization proposed rule, many commenters stated that delays in
responding to prior authorization requests for drugs significantly
impacted patient care, health, and burden on providers (89 FR 8765).
---------------------------------------------------------------------------
\114\ American Medical Association. (2025). 2024 AMA prior
authorization physician survey. Retrieved from https://www.ama-assn.org/system/files/prior-authorization-survey.pdf.
\115\ American Medical Association. (2023, March 13). Toll from
prior authorization exceeds alleged benefits, say physicians.
Retrieved from https://www.ama-assn.org/press-center/press-releases/toll-prior-authorization-exceeds-alleged-benefits-say-physicians.
---------------------------------------------------------------------------
In the 2024 CMS Interoperability and Prior Authorization final
rule, we finalized specific process requirements for impacted payers to
improve the prior authorization process for non-drug items and
services. We established prior authorization decision timeframes for
impacted payers other than QHP issuers on the FFEs (MA organizations,
state Medicaid and CHIP FFS programs, Medicaid managed care plans, and
CHIP managed care entities) and required that, when denying a prior
authorization request for non-drug items and services, impacted payers
respond to the requesting provider with a specific reason for the
denial (89 FR 8897). Shortening and standardizing timeframes for prior
authorization decisions across programs improves access to health care
and can mitigate the negative impacts of delays, particularly for
individuals with chronic or complex conditions. The term ``denial''
means that the payer has refused to authorize coverage for a
recommended medical treatment, procedure, or medication. Payers deny
coverage for various reasons, such as a determination that the service
or medication is not medically necessary or does not meet their
coverage criteria. Requesting providers need to clearly understand the
reason for denial so that additional information can be provided or
alternative care options can be considered.
In the 2024 CMS Interoperability and Prior Authorization final
rule, we also finalized requirements on impacted payers to publicly
report certain prior authorizations metrics for non-drug items and
services annually beginning in 2026.\116\ By sharing appropriate data,
payers can build trust with their patients and providers and showcase
[[Page 19933]]
their commitment to improving services. Beyond information about which
services require prior authorization and the requirements for approval,
greater transparency about payer performance on denials, timeframes,
and volumes could be helpful for the public. Such reporting improves
accountability and can identify opportunities for improvement.
---------------------------------------------------------------------------
\116\ See 42 CFR 422.122(c) for MA organizations and applicable
integrated plans, 42 CFR 440.230(e)(3) for state Medicaid FFS
programs, 42 CFR 457.732(c) for state CHIP FFS programs, 42 CFR
438.210(f) for Medicaid managed care plans, through existing cross
reference to 42 CFR 438.210 in 42 CFR 457.1230(d) for CHIP managed
care entities, and 45 CFR 156.223(c) for individual market QHP
issuers on the FFEs.
---------------------------------------------------------------------------
The proposals in this proposed rule to extend our technical and
process requirements for prior authorization to all drugs should
improve patients' access to services. We intend these proposals to
create more unified processes for providers to request and receive
prior authorization for drugs. Such standardization and consistency
should allow providers to spend more time on patient care and less time
on administrative tasks and paperwork. Additionally, standardized
processes could reduce wait times and resubmissions and result in more
efficient and accurate decision-making.
2. Proposed Requirement To Include a Specific Reason for Denial in
Response to Prior Authorization Requests for All Drugs
a. Background
In the 2024 CMS Interoperability and Prior Authorization final
rule, we finalized a requirement that, beginning in 2026, impacted
payers must provide a specific reason for denial in their response to a
provider's prior authorization request for non-drug items and services,
regardless of the method used to communicate the prior authorization
request or decision.\117\ We are now proposing to add the same
requirements for denied prior authorizations for all drugs for impacted
payers that are not already subject to such a requirement. Throughout
the 2022 CMS Interoperability and Prior Authorization proposed rule (87
FR 76238) and the 2024 CMS Interoperability and Prior Authorization
final rule (89 FR 8758), we described opportunities to improve the
prior authorization process, specifically where better communication
between payers and providers could mitigate confusion about the status
of a prior authorization and why a request was denied. Although prior
authorization has a role in the health care system, denying services
that do not meet the payer's internal coverage or utilization criteria
or do not meet regulatory or statutory requirements should not
adversely impact the health or well-being of the patient. If a denial
is ineffectively communicated, then it could cause a patient to delay
or abandon treatment.
---------------------------------------------------------------------------
\117\ See 42 CFR 422.122(a) for MA organizations and applicable
integrated plans, 42 CFR 431.80(a) for state Medicaid FFS programs,
42 CFR 457.732(a) for state CHIP FFS programs, through cross
reference to 42 CFR 431.80(a) in 42 CFR 438.242(b)(8) for Medicaid
managed care plans, through cross reference to 42 CFR 438.242 in 42
CFR 457.1233(d) for CHIP managed care entities, and 45 CFR
156.223(a) for individual market QHP issuers on the FFEs.
---------------------------------------------------------------------------
In the 2024 CMS Interoperability and Prior Authorization final
rule, we explained that payers deny prior authorizations for a variety
of reasons, including because the payer does not consider the items to
be medically necessary, the patient exceeded limits on allowable
covered care, or documentation to support the request was missing or
inadequate (89 FR 8872). The reasons for denying prior authorizations
for drugs may be similar. Health plan formularies are lists of generic
and brand-name drugs covered by a health plan and may include drug
tiering information. If prior authorization is denied because of a
payer's formulary or utilization management policies and that is not
clearly communicated, then the provider cannot effectively act on
behalf of the patient. When a payer provides a specific reason for a
denial, a provider can take appropriate actions such as resubmitting
the request with updated information, appealing the decision, or
identifying alternative drugs or treatments. Payers send denials
through various channels--electronically, by mail, via portal, or by
fax. When doing so, they often use proprietary codes or narrative text
to communicate the reasons for denial. For some payers, the process of
communicating denials remains both inefficient and inconsistent. The
result is that providers may not have timely, clear direction on the
next steps for providing appropriate care for their patients after a
denied prior authorization request.
b. Existing Requirements To Communicate With Providers About Denied
Prior Authorization Requests for Drugs
As described in the 2024 CMS Interoperability and Prior
Authorization final rule, some impacted payers are required by existing
federal laws and regulations to notify providers or patients when the
payer denies or makes an adverse decision on a prior authorization
request (89 FR 8874-8876). We are not proposing to alter or replace
existing requirements for payers to notify patients, but to add
requirements to ensure a specific reason for denial is communicated to
providers. In addition to the existing program notification
requirements, communicating specific reasons for denial increases
transparency, reduces burden, and improves efficiencies for both payers
and providers.
Under existing regulations, an MA organization must notify the
enrollee (and the prescribing physician or other prescriber involved,
as appropriate) of its determination on a request for a Part B drug as
expeditiously as the enrollee's health condition requires but no later
than 72 hours after receiving a standard request and no later than 24
hours after receiving an expedited request.\118\ When a request for a
Part B drug is denied, MA organizations must provide the specific
reasons for the denial along with certain other information, such as
how to request an appeal.\119\ CMS provides a standardized form \120\
that MA organizations must use, which captures a specific rationale of
why the item, service, or Part B drug was denied, including a
description of the applicable coverage rule or applicable plan policy
(for example, the Evidence of Coverage provision) upon which the action
was based and a specific explanation about what information is needed
to approve coverage, if applicable. Given that existing regulations
require MA organizations to notify the enrollee and the prescriber, as
appropriate, of a decision on a Part B drug request, we are not
proposing any changes related to the notice requirements for a prior
authorization decision by an MA organization in this rule. Similar
notice requirements, including a reason for denial, exist for Part D
sponsors making prior authorization decisions.\121\ Standardized MA and
Part D denial notices, which plans must send to enrollees, require a
specific reason for the denial and the following language: ``Share a
copy of this decision with your doctor and discuss next steps. If your
doctor asked for coverage on your
[[Page 19934]]
behalf, we already sent them a copy of this denial notice.'' \122\
---------------------------------------------------------------------------
\118\ See 42 CFR 422.568(b)(3) and 42 CFR 422.572(a)(2).
\119\ See 42 CFR 422.568(e) and 42 CFR 422.572(e).
\120\ See 42 CFR 422.2267(e)(16); See Integrated Denial Notice
Form 10003-NDMCP, which has the instructions, form, and Spanish
translation. See Centers for Medicare & Medicaid Services. (2024,
September 10). MA Denial Notice. Retrieved from https://www.cms.gov/medicare/forms-notices/beneficiary-notices-initiative/ma-denial-notice.
\121\ Centers for Medicare & Medicaid Services. (2024, November
18). Parts C & D Enrollee Grievances, Organization/Coverage
Determinations, and Appeals Guidance. Retrieved from https://www.cms.gov/medicare/appeals-and-grievances/mmcag/downloads/parts-c-and-d-enrollee-grievances-organization-coverage-determinations-and-appeals-guidance.pdf.
\122\ See Integrated Denial Notice Form 10003-NDMCP Eff Jan 2025
available at: Centers for Medicare & Medicaid Services. (2024,
September 10). MA Denial Notice. Retrieved from https://www.cms.gov/medicare/forms-notices/beneficiary-notices-initiative/ma-denial-notice.
---------------------------------------------------------------------------
Similarly, Medicaid managed care plans and CHIP managed care
entities must notify the requesting provider and give the beneficiary
written notice of any decision by the plan to deny a service
authorization request or to authorize a service in an amount, duration,
or scope that is less than requested.\123\ As specified in 42 CFR
438.242(b)(8), by the rating period beginning on or after January 1,
2026, Medicaid managed care plans must communicate a specific reason
for any denials to the provider, regardless of the method used to
communicate that information, for prior authorization requests for non-
drug items and services.\124\ These requirements also apply to CHIP
managed care entities by cross reference.\125\
---------------------------------------------------------------------------
\123\ See 42 CFR 438.210(c) and 438.242(b)(8) for Medicaid
managed care plans and 42 CFR 457.1230(d) for CHIP managed care
entities.
\124\ As specified in 42 CFR 438.242(b)(8) by cross-reference to
42 CFR 431.80(a).
\125\ See 42 CFR 457.1233(d).
---------------------------------------------------------------------------
While 45 CFR 156.223(a) requires QHP issuers on the FFEs to include
a specific reason for the denial of a prior authorization request to
the provider, this requirement explicitly excludes prescription drugs.
c. Proposed Requirement To Include a Specific Reason for Denial to
Providers When Denying Prior Authorization of All Drugs for State
Medicaid and CHIP Fee-for-Service Programs, Medicaid Managed Care
Plans, CHIP Managed Care Entities, and Qualified Health Plan Issuers on
the Federally-facilitated Exchanges
We propose that beginning October 1, 2027, state Medicaid and CHIP
FFS programs, Medicaid managed care plans, CHIP managed care entities,
and QHP issuers on the FFEs be required to provide a specific reason to
providers when denying a prior authorization request for drugs,
regardless of the method used to send the prior authorization request
or decision. This proposal is an effort to improve the communication
between those impacted payers and providers when they deny a prior
authorization request for drugs. This proposal would align with the
requirement finalized in the 2024 CMS Interoperability and Prior
Authorization final rule that impacted payers send to providers a
specific reason for denying a prior authorization request for non-drug
items and services.\126\ We now propose to apply that same denial
notice requirement to state Medicaid and CHIP FFS programs, Medicaid
managed care plans, CHIP managed care entities, and QHP issuers on the
FFEs for prior authorizations for drugs. This proposed change should
lead to those payers providing more transparent communication in their
decision-making, allowing providers to address any deficiencies in the
request or consider alternative treatments.
---------------------------------------------------------------------------
\126\ See 42 CFR 422.122(a) for MA organizations and applicable
integrated plans, 42 CFR 431.80(a) for state Medicaid FFS programs,
42 CFR 457.732(a) for state CHIP FFS programs, through cross
reference to 42 CFR 431.80(a) in 42 CFR 438.242(b)(8) for Medicaid
managed care plans, through cross reference to 42 CFR 438.242 in 42
CFR 457.1233(d) for CHIP managed care entities, and 45 CFR
156.223(a) for individual market QHP issuers on the FFEs.
---------------------------------------------------------------------------
The content of the response should include a specific reason for
denying a prior authorization request for drugs that helps a provider
to understand why the request was denied and what actions must be taken
to resubmit or appeal the decision. A specific reason for denial could
include information about the specific plan coverage criteria on which
the denial is based, why documentation did not support the medication
or prescription, or why the drug is not deemed necessary. This proposal
could improve the current processes and reduce manual effort and costs
by increasing the likelihood that providers whose prior authorization
request for drugs is denied have all the information they need to
decide the next steps to care for the patient, including whether and
how to appeal the denial. We are proposing an October 1, 2027 effective
date for this proposal, as these protections are important to patients.
This proposal does not affect existing patient notice requirements
for state Medicaid and CHIP FFS programs and QHP issuers on the FFEs.
State Medicaid and CHIP FFS programs are required to provide a
beneficiary with timely and adequate written notice of a ``denial or
change in benefits and services.'' \127\ In case of an adverse benefit
determination, QHP issuers on the FFEs must include in their notice to
enrollees certain information, including the reason(s) for the adverse
benefit determination, a denial code and its meaning, and a description
of the QHP issuer on the FFEs' standard that was used in the
denial.\128\ Like the requirement that we finalized in the 2024 CMS
Interoperability and Prior Authorization final rule for non-drug items
and services, our proposed requirement should ensure that providers who
submit prior authorization requests for drugs receive information
directly from impacted payers regarding an adverse prior authorization
determination, which should expedite their ability to appeal the
determination or provide additional information if needed.
---------------------------------------------------------------------------
\127\ See 42 CFR 435.917(a) for state Medicaid FFS programs and
42 CFR 457.1180 for state CHIP FFS programs.
\128\ See 29 CFR 2560.503-1(g), 45 CFR 147.136(b)(2)(i), and 45
CFR 147.136(b)(3)(ii)(E)(3).
---------------------------------------------------------------------------
In addition to these new requirements, we are proposing to
reorganize 42 CFR 438.210(c) and 42 CFR 438.242 to improve readability.
This proposal maintains existing program requirements for non-drug
items and services while proposing these new requirements for Medicaid
managed care plans to provide specific denial reasons for drug prior
authorization requests.
In summary, we request comment on our proposals in the CFR
citations listed in Table 6, and specifically on the following:
The proposal to require state Medicaid and CHIP FFS
programs, Medicaid managed care plans, CHIP managed care entities, and
QHP issuers on the FFEs to communicate to providers a specific reason
for denying a prior authorization request for any drugs, regardless of
the method used to send the prior authorization request or decision.
The proposed October 1, 2027 compliance date for state
Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP
managed care entities, and QHP issuers on the FFEs.
The proposed structural changes to 42 CFR 438.210(c) and
42 CFR 438.242 to improve readability.
3. Prior Authorization Decision Timeframes
a. Background
In the 2024 CMS Interoperability and Prior Authorization final
rule, we finalized requirements for MA organizations, state Medicaid
and CHIP FFS programs, Medicaid managed care plans, and CHIP managed
care entities to make prior authorization decision requests on non-drug
items and services as expeditiously as a patient's health condition
requires but no later than 7 calendar days after receiving a standard
request and no later than 72 hours after receiving an expedited
request, effective in 2026 (89 FR 8897). However, we did not propose or
finalize those requirements for QHP issuers on the FFEs, in part
because existing regulations in 45 CFR 147.136 establish timelines for
all non-grandfathered
[[Page 19935]]
group health plans and health insurance issuers offering individual and
group health insurance coverage (``plans and issuers'') to notify
claimants, participants, beneficiaries, and enrollees (patients) of
prior authorization (referred to in those regulations as a ``pre-
service'') decisions (89 FR 8879). Specifically, 45 CFR
147.136(b)(3)(i) generally requires plans and issuers to meet the
requirements of the claims and appeals procedures applicable to group
health plans in 29 CFR 2560.503-1, as if the coverage were a group
health plan. Under those requirements, QHP issuers on the FFEs must
notify patients of a plan's benefit determination on a prior
authorization request as expeditiously as a patient's health condition
requires but no later than 15 days after a standard request and as soon
as possible, taking into account the medical exigencies, but no later
than 72 hours for expedited requests (referred to in those regulations
as ``urgent care'' claims). Notably, these timeframes apply to non-drug
items and services, as well as drugs. While neither 45 CFR
147.136(b)(3) nor 29 CFR 2560.503-1 require plans and issuers to notify
the requesting provider of a prior authorization decision, when they
do, HHS presumes that they do so within the same timeframes that they
are required to notify patients. As a result, beginning in 2026, QHP
issuers on the FFEs effectively have longer to provide notification of
a decision on a standard prior authorization request for non-drug items
and services (a maximum of 15 days) as compared to other impacted
payers (a maximum of 7 days).\129\ In contrast, QHP issuers on the FFEs
effectively have the same amount of time to provide notification of a
decision on a standard prior authorization request for non-drug items
and services as other impacted payers (a maximum of 72 hours). Finally,
in both cases, as noted, there is no regulatory requirement that QHP
issuers on the FFEs notify providers of any prior authorization
decision.
---------------------------------------------------------------------------
\129\ As noted above, effective in 2026, MA organizations, state
Medicaid and CHIP FFS programs, Medicaid managed care plans, and
CHIP managed care entities must notify claimants and providers of
prior authorization decisions on non-drug items and services no
later than 7 calendar days for standard requests and no later than
72 hours for expedited requests
---------------------------------------------------------------------------
In addition to the requirements for non-drug items and services, MA
organizations, state Medicaid FFS programs, Medicaid managed care
plans, and CHIP managed care entities have existing decision timeframe
requirements for prior authorization of certain drugs. MA organizations
must notify the enrollee (and the prescribing physician or other
prescriber involved, as appropriate) of a determination regarding
coverage of a Part B drug as expeditiously as the enrollee's health
condition requires, but no later than 72 hours after receiving the
standard request and no later than 24 hours after receiving the
expedited request.\130\ Similarly, Part D sponsors, including MA-PDs,
have the same requirements for prior authorization decisions on Part D
drugs (with the possibility of an extension).\131\ The Part D sponsor
must notify the enrollee (and the prescribing physician or other
prescriber involved, as appropriate) of its determination as
expeditiously as the enrollee's health condition requires, but no later
than 72 hours after receiving the standard request and no later than 24
hours after receiving the expedited request. Given the existing prior
authorization decision timeframe requirements for Part B and Part D
drugs, we do not believe that additional proposals for MA organizations
or Part D sponsors are necessary or appropriate at this time. However,
we request comment on whether there are any drugs payable under Part A
that are not included as part of a larger bundle of inpatient services
to which the timeframe to make prior authorizations decisions should
apply for MA organizations. If so, we would consider finalizing a
policy to ensure that all drugs that require prior authorization have
appropriate decision timeframes.
---------------------------------------------------------------------------
\130\ See 42 CFR 422.568(b)(3) and 42 CFR 422.572(a)(2).
\131\ See 42 CFR 423.568(b) and 42 CFR 423.572(a).
---------------------------------------------------------------------------
State Medicaid FFS programs, Medicaid managed care plans, and CHIP
managed care entities also have existing decision timeframe
requirements for covered outpatient drugs.\132\ Specifically, state
Medicaid FFS programs, Medicaid managed care plans, and CHIP managed
care entities must respond to a prior authorization request for a
covered outpatient drug within 24 hours of the request and dispense at
least a 72-hour supply of the drug in emergencies. However, there is no
requirement specific to drugs for state CHIP FFS programs. Instead,
state CHIP FFS programs must adhere to the general decision-making
timeframe, which mandates that prior authorization decisions be made in
accordance with the medical needs of the patient within 14 days after
receiving a request for services (beginning on January 1, 2026, the
timeframe will be 7 calendar days for standard requests and 72 hours
for expedited requests).\133\
---------------------------------------------------------------------------
\132\ See section 1927(d)(5)(A) of the Act for state Medicaid
FFS programs, 42 CFR 438.210(d)(3) and 42 CFR 438.3(s)(6) for
Medicaid managed care plans, and through cross reference to 42 CFR
438.210(d)(3) in 42 CFR 457.1230(d) for CHIP managed care entities.
\133\ See 42 CFR 457.495(d).
---------------------------------------------------------------------------
As discussed in sections II.C.3.c. and II.C.3.d. of this proposed
rule, we are now requesting information on whether there are gaps in
timeframe requirements for some drugs and if there are we are proposing
to apply the prior authorization decision timeframes for non-drug items
and services outlined in the 2024 CMS Interoperability and Prior
Authorization final rule to that subset of drugs for which there are
not already established prior authorization timeframes. This would
apply to both state Medicaid FFS programs and Medicaid managed care
plans. We are also proposing to modify state CHIP FFS programs'
decision-making timeframes for the prior authorization of drugs comport
with section 1927(d)(5)(A) of the Act to align with the requirements
for those programs.
b. Prior Authorization Decision Timeframes for Qualified Health Plan
Issuers on the Federally-facilitated Exchanges
In response to the 2022 CMS Interoperability and Prior
Authorization proposed rule, many commenters disagreed with excluding
QHP issuers on the FFEs from the shortened timeframe requirements and
asked that CMS reconsider the exclusion. Commenters stated it would be
more consistent and equitable for CMS to apply the same timeframe
requirements for standard prior authorization decisions for all
impacted payers (89 FR 8880). Commenters stated that patients covered
by these plans should be entitled to the same protections as those
covered by other impacted payers, and that excluding QHP issuers on the
FFEs could negatively affect patients by delaying access to care based
only on the type of insurance they have. One commenter stated that they
did not believe that shortening the prior authorization decision
timeframe for QHP issuers on the FFEs from a 15 day response time for
standard requests to 7 days would cause an undue burden to those plans.
We also received many comments requesting CMS consider adding
additional standards to the prior authorization process to address the
adverse effects of delays on patients and providers (89 FR 8859).
Multiple commenters wrote that CMS should apply even shorter prior
authorization decision timeframes to QHP issuers on the FFEs, such as
72 hours for standard
[[Page 19936]]
requests and 24 hours for expedited requests.
In response to the comments received, we stated that we would
evaluate opportunities for future rulemaking to alleviate provider
burdens and mitigate delays associated with prior authorization (89 FR
8859). We are aware that a growing number of states have passed laws to
reduce prior authorization decision timeframes, require technical
standards, limit procedural justifications for denials, tie decisions
to clinical criteria, and increase transparency.\134\ In addition to
public comments that expressed concerns that patients experience
delayed or deferred care because of complex prior authorization
processes, recent research has suggested that these concerns
disproportionately impact those with chronic conditions and mental
health care needs.\135\
---------------------------------------------------------------------------
\134\ American Medical Association. (2024). 2024 Prior
Authorization (PA) State Law Chart. Retrieved from https://www.ama-assn.org/system/files/prior-authorization-state-law-chart.pdf.
\135\ Pollitz, K., Pestaina, K., Lopes, L., Wallace, R., & Lo,
J. (2023, September 29). Consumer Problems with Prior Authorization:
Evidence from KFF Survey. Retrieved from https://www.kff.org/affordable-care-act/issue-brief/consumer-problems-with-prior-authorization-evidence-from-kff-survey/.
---------------------------------------------------------------------------
Hence, we are now proposing, in 45 CFR 156.223(i)(1)(i), that
beginning October 1, 2027 in response to a request for prior
authorization for non-drug items and services, QHP issuers on the FFEs
must notify the requesting provider of their decision as expeditiously
as a patient's health condition requires but no later than 7 days after
receiving a standard prior authorization request and no later than 72
hours after receiving an expedited prior authorization request.
We also propose, in 45 CFR 156.223(i)(1)(ii), that beginning
October 1, 2027 in response to a prior authorization request for any
drug, QHP issuers on the FFEs must notify a requesting provider of
their decision as expeditiously as the enrollee's health condition
requires, but no later than 72 hours after receiving a standard prior
authorization request and no later than 24 hours after receiving an
expedited prior authorization request. These are similar to the
timeframes for prior authorization decisions for drugs that we propose
for other impacted payers in this proposed rule. The proposed
timeframes to require QHP issuers on the FFEs to notify the requesting
provider of a prior authorization decision would be new; that is, there
is currently no requirement for QHP issuers on the FFEs to notify
providers of a prior authorization decision within any specific period
of time. This proposal would not change existing prior authorization
notification requirements in 45 CFR 147.136 for patients but would
create a new requirement for QHP issuers on the FFEs to notify the
requesting provider of a prior authorization decision within a specific
timeframe based on the nature of the request, and these timeframes
would generally be shorter than the maximum amount of time that QHP
issuers on the FFEs have to notify patients regarding standard prior
authorization requests under existing regulations in 45 CFR
147.136.\136\
---------------------------------------------------------------------------
\136\ Consistent with the treatment of the requirement that
payers provide the specific reason for denying a prior authorization
request in the payer's response to the provider established in the
2024 CMS Interoperability and Prior Authorization final rule, the
burden associated with notifying the requesting provider of the
health plan's prior authorization determination is considered usual
and customary as the disclosure is integral to the business practice
and function of the health plan. Therefore, we have identified the
burden associated with communicating a prior authorization decision
as a usual and customary business practice that does not require a
burden calculation pursuant to 5 CFR 1320.3(b)(2).
---------------------------------------------------------------------------
Establishing a new requirement for QHP issuers on the FFEs to
notify providers of prior authorization decisions on non-drug items and
services and drugs, and aligning those timelines with current and
proposed timelines for other impacted payers, could improve patient
care and minimize administrative burden for providers who would be able
to expect prior authorization decisions within the same timeframe from
all impacted payers. We are not proposing to shorten the timeframes for
QHP issuers on the FFEs to notify patients of prior authorization
decisions as established in 45 CFR 147.136(b)(3); however, we recognize
that QHP issuers on the FFEs may voluntarily adopt shorter patient
notification timeframes that align with the proposed provider
notification timeframes to minimize administrative burden. Therefore,
this proposal may result in faster notification for patients than is
required by 45 CFR 147.136(b)(3) and may result in QHP issuers on the
FFEs notifying patients more quickly than plans and issuers subject to
45 CFR 147.136(b)(3), including issuers on SBEs.
We expect that the proposed timeframes for notifying providers
would be feasible for QHP issuers on the FFEs given the notification
functionality of the Prior Authorization API and NCPDP standards that
we are proposing QHP issuers on the FFEs to support for electronic
prior authorization. Those standards support direct electronic
communications between payers and providers about prior authorizations.
In addition, that available technology can accelerate the decision-
making itself and we are of the view that QHP issuers on the FFEs
should be part of this trend in process improvement.
As noted above, we are proposing that QHP issuers on the FFEs
notify the requesting provider ``as expeditiously as the enrollee's
health condition requires,'' subject to the proposed time limits, which
is the standard for non-drug items and services used by MA
organizations,\137\ Part D sponsors,\138\ Medicaid,\139\ and CHIP.\140\
We are proposing that, in determining what an enrollee's health
condition requires, QHP issuers on the FFEs must abide by the same
requirement to make decisions in accordance with established accepted
standards of medical practice in assessing an individual's medical
condition, and we solicit comment on whether any other language in
regulation or in sub-regulatory guidance is necessary to ensure that
QHP issuers on the FFEs adhere to this standard.
---------------------------------------------------------------------------
\137\ See 42 CFR 422.568(b)(1) and 42 CFR 422.568(b)(3).
\138\ See 42 CFR 423.568(b) and 42 CFR 423.572(a).
\139\ See 42 CFR 440.230(e)(1).
\140\ See 42 CFR 457.495(d), using the phrase ``In accordance
with the medical needs of the patient . . . .''
---------------------------------------------------------------------------
We also propose, in 45 CFR 156.223(i)(2), that for purposes of 45
CFR 156.223(i)(1), a standard prior authorization request has the
meaning given in 29 CFR 2560.503-1(m)(2) to a ``pre-service claim'' and
an expedited prior authorization request has the meaning given in 29
CFR 2560.503-1(m)(1) to a ``claim involving urgent care,'' as
determined by the attending provider, and the issuer shall defer to
such determination of the attending provider. By relying on existing
definitions, we seek to maintain consistency across requirements
related to prior authorization for QHP issuers on the FFEs.
We also propose, in 45 CFR 156.223(i)(3)(i), that the QHP issuer on
the FFEs may extend the timeframes to notify the requesting provider of
a prior authorization decision by up to 14 calendar days under any of
the following circumstances: (1) if the provider requests the
extension; (2) the extension is justified and in the provider's or
enrollee's interest because the QHP issuer on the FFEs needs additional
medical evidence from another provider or the enrollee in order to
issue a decision; or (3) the extension is justified due to
extraordinary, exigent, or other non-routine circumstances and is in
the provider's or enrollee's interest. If extended, the QHP issuer on
the FFEs
[[Page 19937]]
would be required to notify the provider of its determination as
expeditiously as the enrollee's health condition requires, but no later
than upon expiration of the extension. We also propose to require, in
45 CFR 156.223(i)(3)(ii), that when the QHP issuer on the FFEs extends
the timeframe, it must notify the requesting provider in writing of the
reasons for the extension and inform the provider of the right to file
an expedited grievance if the provider disagrees with the QHP issuer on
the FFE's decision to grant an extension. This language is similar to
the corresponding provision that CMS finalized in the 2024
Interoperability and Prior Authorization final rule. We believe it is
appropriate for QHP issuers on the FFEs as well, but solicit comment on
whether that is the case or if it should be amended.
In summary, we request comment on our proposals in the CFR
citations listed in Table 6, and specifically on the following:
The proposal to require QHP issuers on the FFEs to provide
notice to the requesting provider of prior authorization decisions as
expeditiously as the enrollee's health condition requires, but no later
than 7 calendar days after receiving a standard prior authorization
request for non-drug items and services and as expeditiously as the
enrollee's health condition requires, but no later than 72 hours after
receiving an expedited request for non-drug items and services.
The proposal to require QHP issuers on the FFEs to provide
notice to the requesting provider of prior authorization decisions as
expeditiously as the enrollee's health condition requires, but no later
than 72 hours after receiving a standard prior authorization request
for drugs and as expeditiously as the enrollee's health condition
requires, but no later than 24 hours after receiving an expedited
request for drugs.
The proposal that QHP issuers on the FFEs may extend the
timeframes to notify the requesting provider of a prior authorization
decision by up to 14 calendar days under certain circumstances, and the
QHP issuers on the FFEs must notify the requesting provider in writing
of the reasons for the delay and inform the provider of the right to
file an expedited grievance if the provider disagrees with the QHP
issuer on the FFEs' decision to grant an extension.
The proposal that for purposes of 45 CFR 156.223(i)(1), a
standard prior authorization request has the meaning given in 29 CFR
2560.503-1(m)(2) to a ``pre-service claim'' and an expedited prior
authorization request has the meaning given in 29 CFR 2560.503-1(m)(1)
to a ``claim involving urgent care'' for QHP issuers on the FFEs.
The proposed October 1, 2027 compliance date.
In addition, we request comments on the following:
Whether requiring QHP issuers on the FFEs to provide
notice to requesting providers of prior authorization decisions in a
shorter timeframe than they are currently required to provide notice to
patients of prior authorization decisions is sufficient to improve
enrollees' care, or if CMS should consider also applying shorter
timeframes for notification to patients, as well.
Whether there would be burden due to the different
timeframes for QHP issuers on the FFEs to notify a requesting provider
of a prior authorization decision and to notify participants,
beneficiaries, and enrollees of prior authorization decisions, and how
we could potentially alleviate that burden.
Whether we should finalize shorter timeframes for QHP
issuers on the FFEs to notify the requesting provider of prior
authorization requests for drugs, specifically, 24 hours for all
requests (standard or expedited), to align with the existing
requirements for state Medicaid FFS programs, Medicaid managed care
plans, and CHIP managed care entities, and our proposal for state CHIP
FFS programs.
Whether the requirement to make decisions as
``expeditiously as the enrollee's health condition requires'' is
appropriate, or whether additional or alternative language or sub-
regulatory guidance is necessary to help ensure impacted payers make
timely decisions and for consistency with existing decision timeframes
in 45 CFR 147.136(b)(3) and 29 CFR 2560.503-1(f).
Whether QHP issuers' parent organizations that participate
in multiple CMS-regulated programs, such as MA organizations or
Medicaid managed care plans, already have experience responding to
prior authorization requests more quickly than it is currently required
by existing market wide rules that they can leverage to improve
processes for their QHPs offered on the FFEs.
Whether QHP issuers on the FFEs' plan management systems
can readily distinguish between a policy applicable to a QHP offered on
an FFE, a policy applicable to off-Exchange individual or small group
coverage, or a QHP issuer in an SBE.
c. Prior Authorization Decision Timeframes for Drugs That Are Not
Covered Outpatient Drugs for State Medicaid Fee-for-Service Programs,
Medicaid Managed Care Plans, and CHIP Managed Care Entities
As discussed previously, section 1927(d)(5)(A) of the Act
establishes a 24-hour timeframe for state Medicaid FFS programs to
respond to requests for prior authorization of covered outpatient drugs
for which FFP is available. However, that timeframe may not apply to
all drugs that are covered by states for which states receive FFP. In
the 2022 CMS Interoperability and Prior Authorization proposed rule,
which addressed prior authorization decision timeframes for non-drug
items and services, CMS received comments indicating that drugs should
have been included in the prior authorization timeframe policies and
that gaps exist regarding timeframe requirements on prior
authorizations for certain drugs. Given that covered outpatient drugs
already have an established statutory timeframe for prior authorization
pursuant to section 1927 of the Act, we seek to address the comments
concerning a possible gap in prior authorization timeframes for a
subset of drugs which are not covered outpatient drugs. In addition, to
address concerns by commenters, we explain the prior authorization
decision timeframes for drugs that otherwise meet the definition of
covered outpatient drugs in section 1927(k)(2) of the Act but are
excluded from the definition of covered outpatient drugs due to meeting
the criteria in the limiting definition of covered outpatient drug in
section 1927(k)(3) of the Act.
Section 1927(k)(3) of the Act limits the term ``covered outpatient
drug'' to exclude any drug, biological product, or insulin provided as
part of, or as incident to and in the same setting as, certain services
(and for which payment may be made under that subchapter as part of
payment for those services and not as direct reimbursement for the
drug).\141\ To the extent that state Medicaid and CHIP programs cover
and impose prior authorization requirements on these drugs that are not
covered outpatient drugs, we believe the same decision timeframe
requirements that
[[Page 19938]]
apply to prior authorization for the non-drug items and services should
apply to a drug that is provided incident to those services. Therefore,
non-covered outpatient drugs that meet the limiting definition in
section 1927(k)(3) of the Act should align with the timeframe
requirements for non-drug items and services, which is 7 calendar days
for standard requests and 72 hours for expedited requests. We believe
it is most appropriate to align the prior authorization decision
timeframe for a drug that meets the limiting definition in section
1927(k)(3) of the Act with the services it is provided as part of, or
incident to. We believe this will ensure a prior authorization decision
is rendered for the drug and non-drug items and services within the
same timeframe as opposed to having the drug reviewed under a different
timeframe than the remainder of the service with which it is bundled
with.
---------------------------------------------------------------------------
\141\ The services listed in section 1927(k)(3) of the Act are:
inpatient hospital services; hospice services; dental services,
except that drugs for which the State plan authorizes direct
reimbursement to the dispensing dentist are covered outpatient
drugs; physicians' services; outpatient hospital services; nursing
facility services and services provided by an intermediate care
facility for the mentally retarded; other laboratory and x-ray
services; and renal dialysis.
---------------------------------------------------------------------------
One example of this subset of drugs are those that are administered
in an inpatient hospital setting. Drugs administered in an inpatient
setting are typically paid for as part of a bundled payment, which
includes a variety of items, services, and drugs. Under that payment
model, when prior authorization is required, it is typically submitted
as a bundle and drugs are not separated from non-drug items and
services; drugs and non-drug items and services are reviewed under the
same prior authorization request and therefore same timeframe. In those
situations, we do not believe there is a need for a separate timeframe
for the drug component of the prior authorization; the prior
authorization timeframes established in the 2024 CMS Interoperability
and Prior Authorization final rule would apply to the entirety of the
prior authorization request.
In addition, we request comment on whether there are categories of
non-covered outpatient drugs for which it would be more appropriate to
finalize a decision timeframe that aligns with the statutory
requirement for covered outpatient drugs at section 1927(d)(5)(A) of
the Act. It is unclear whether there are drugs (that are not covered
outpatient drugs) for which states require prior authorization and for
which 24 hours would be the appropriate decision timeframe, rather than
the longer decision timeframe for non-drug items and services. As
stated, we do not desire to create different timeframes for prior
authorization decisions for drugs versus non-drug items and services
for which reimbursement and prior authorization requests are bundled.
However, we also want to address any gaps for standalone prior
authorization requests for drugs that either do not have an existing
prior authorization decision timeframe requirement, or for which the
prior authorization decision timeframe is misaligned with our other
proposals in this proposed rule.
We propose that if commenters identify gaps in the decision
timeframe requirements for drugs, we would apply the same requirements
to Medicaid MCOs, PIHPs, and PAHPs by amending 42 CFR 438.210 and CHIP
managed care entities by the existing cross reference to 42 CFR 438.210
in 42 CFR 457.1230(d).
We are proposing an October 1, 2027 compliance date for these
proposals for state Medicaid FFS programs, Medicaid managed care plans,
and CHIP managed care entities.
In summary, we request comments on the following:
The scope of drugs for which we are proposing these prior
authorization requirements. Are there additional drugs that currently
have no established prior authorization timeframe requirements for
which such timeframes should be established? Is there a need to apply
prior authorization timeframe requirements to the scope of drugs
proposed in this rule? Are there other types of drugs for which we
should finalize a requirement that aligns with the 24 hour timeframe
established for covered outpatient drugs by section 1927(d)(5)(A) of
the Act?
The proposed October 1, 2027 compliance date for state
Medicaid FFS programs, Medicaid managed care plans, and CHIP managed
care entities.
Whether we should consider future rulemaking to propose a
requirement for MA organizations to respond to all prior authorization
requests for drugs no later than 24 hours to align with the Medicaid
and CHIP requirements for covered outpatient drugs.
Whether there are any drugs payable under Medicare Part A
that are not included as part of a larger bundle of inpatient services
to which the timeframe to make prior authorizations decisions should
apply for MA organizations.
d. Prior Authorization Decision Timeframes for Prescription Drugs for
State CHIP Fee-for-Service Programs
To align with the existing requirements for state Medicaid FFS
programs, Medicaid managed care plans, and CHIP managed care entities
requirements for covered outpatient drugs, as well as the proposals
described in section II.C.3.c. of this proposed rule, we propose to
shorten the timeframe for state CHIP FFS programs to make prior
authorization decisions on prescription drugs for which the state
receives FFP, as described in section 2110(a)(6) of the Act. As noted
previously, the current requirement is the same 7 days for standard
requests and 72 hours for expedited requests as for non-drug items and
services, while other payers have shorter decision timeframes for the
prior authorization of drugs than for non-drug items and services.
We are proposing to establish a requirement that state CHIP FFS
programs must provide notice to providers and beneficiaries of prior
authorization decisions for prescription drugs for which FFP is
available in accordance with the beneficiary's medical needs but no
later than 24 hours after receiving the prior authorization request.
This proposal would align with the existing state Medicaid FFS program
requirements for covered outpatient drugs in section 1927(d)(5)(A) of
the Act.
This proposed alignment for timeframe requirements should ensure
that providers and patients have similarly efficient processes across
all impacted payers and within CMS programs, regardless of how drugs
are categorized under the Act. We are proposing an October 1, 2027
compliance date.
In summary, we request comment on our proposals in the CFR
citations listed in Table 6, and specifically on the following:
The proposal to require state CHIP FFS programs to provide
notice to providers and patients of prior authorization decisions in
accordance with the beneficiary's medical needs, but no later than 24
hours after receiving a prior authorization request for prescription
drugs for which FFP is available.
The proposed October 1, 2027 compliance date.
4. Update to State Medicaid and CHIP Fee-for-Service Programs' Decision
Timeframe Terminology
After finalizing the 2024 CMS Interoperability and Prior
Authorization final rule, we determined that the regulations in 42 CFR
440.230(e) and 42 CFR 457.495(d) needed to be written more clearly to
align with the finalized policy as explained in that rule (89 FR 8897).
In 42 CFR 440.230(e), we established that state Medicaid FFS programs
must make prior authorization decisions on requests for non-drug items
and services no later than 7 calendar days for standard requests and 72
hours for expedited requests. We also provided that states could
establish shorter timeframes, with which the state
[[Page 19939]]
Medicaid agency would have to comply. The regulation refers to this as
a ``shorter minimum timeframe,'' but the intent of this requirement is
to establish a maximum period of time for a state to make a decision on
a prior authorization request. We are therefore proposing to remove the
word ``minimum'' to explain that states may establish timeframes that
are shorter, but not longer, than those we finalized.
Similarly, 42 CFR 457.495(d) accounts for state laws that may
establish different timeframes but does not limit those requirements to
being shorter than the 14 days for standard requests and 72 hours for
expedited requests. Therefore, we are proposing to align the language
for state CHIP FFS program timeframes with that for state Medicaid FFS
program timeframes by specifying that state CHIP FFS programs must make
prior authorization decisions for non-drug items and services no later
than 7 calendar days for standard requests and 72 hours for expedited
requests unless a shorter timeframe is established by the state. Both
these proposals are consistent with the explanation of our finalized
policies in the 2024 CMS Interoperability and Prior Authorization final
rule (89 FR 8879). We propose that this change would be effective on
the effective date of the final rule, as it does not change the
existing regulatory requirement.
In summary, we request comment on our proposals in the CFR
citations listed in Table 6, and specifically on the following:
The proposal to revise regulatory language for state
Medicaid FFS programs and add regulatory language for state CHIP FFS
programs to explain that state Medicaid and CHIP FFS programs must make
prior authorization decisions available for non-drug items and services
no later than 7 calendar days for standard requests and 72 hours for
expedited requests unless a shorter timeframe is established by the
state.
The proposal to become effective beginning on the
effective date of the final rule.
5. Proposed Changes to Reporting Deadlines and Reporting Levels for
Publicly Reported Prior Authorization Metrics for Non-Drug Items and
Services for Medicaid Managed Care Plans and CHIP Managed Care Entities
In the 2024 CMS Interoperability and Prior Authorization final
rule, we finalized requirements for impacted payers to publicly report
certain prior authorizations metrics about non-drug items and services
annually beginning in 2026.\142\ By sharing these data, payers can
build trust with their patients and providers and showcase their
commitment to improving services. We recognize the need for greater
transparency in the prior authorization process and for information to
be available to the public. Beyond information about which services
require prior authorization and the requirements for approval, greater
transparency about payer performance on denials, timeframes, and
volumes could help the public and identify opportunities for
improvement.
---------------------------------------------------------------------------
\142\ See 42 CFR 422.122(c) for MA organizations and applicable
integrated plans, 42 CFR 440.230(e)(3) for state Medicaid FFS
programs, 42 CFR 457.732(c) for state CHIP FFS programs, 42 CFR
438.210(f) for Medicaid managed care plans, through existing cross
reference to 42 CFR 438.210 in 42 CFR 457.1230(d) for CHIP managed
care entities, and 45 CFR 156.223(c) for individual market QHP
issuers on the FFEs.
---------------------------------------------------------------------------
We finalized an annual March 31 deadline for all impacted payers to
publicly post prior authorization metrics for the previous year.\31\
However, we have determined that such a deadline may not align with
Medicaid managed care plans' and CHIP managed care entities' contract
rating periods. For example, Medicaid managed care plan contract rating
periods, as defined in 42 CFR 438.2, do not all use the same time
period and each state may choose different contract rating periods for
each managed care program. Similarly (though rate certifications are
not required for CHIP managed care entities), the rating periods for
CHIP managed care entities vary across states. Because rating periods
do not necessarily align with calendar years, we now believe that the
March 31 reporting deadline finalized in the 2024 CMS Interoperability
and Prior Authorization final rule is not appropriate for all Medicaid
managed care plans and CHIP managed care entities.\143\ Therefore, to
align the reporting deadlines with the contract rating period for each
program, we are now proposing to require Medicaid managed care plans
and CHIP managed care entities to publicly post the required prior
authorization metrics no later than 90 days after the end of their
rating period.
---------------------------------------------------------------------------
\143\ See 42 CFR 422.122(c) for MA organizations and applicable
integrated plans, 42 CFR 440.230(e)(3) for state Medicaid FFS
programs, 42 CFR 457.732(c) for state CHIP FFS programs, 42 CFR
438.210(f) for Medicaid managed care plans, through cross reference
to 42 CFR 438.210 in 42 CFR 457.1230(d) for CHIP managed care
entities, and 45 CFR 1562.223(c) for individual market QHP issuers
on the FFEs.
---------------------------------------------------------------------------
We also propose to amend the existing requirements for Medicaid
managed care plans and CHIP managed care entities to require that they
report the prior authorization metrics finalized in the 2024 CMS
Interoperability and Prior Authorization final rule by program, as well
as by plan. For consistency with the other Medicaid and CHIP managed
care reporting requirements, we believe that it is appropriate to also
collect these metrics at the program level. Specifically, if a managed
care plan contracts with the state for multiple programs (for example,
an adult and child acute care program and a long-term services and
supports [LTSS] program), each program's prior authorization metrics
would be reported separately. This is also consistent with how states
must report all data in the Managed Care Program Annual Report (MCPAR),
as described in 42 CFR 438.66(e). Integrated plans would continue to
report non-drug items and services covered by MA organizations at the
MA contract level, as the separate requirements for MA organizations
and Medicaid managed care plans apply under their respective contracts.
However, integrated plans would be required to report non-drug items
and services covered by Medicaid managed care plans at both the plan
and program level. That approach is consistent with the reporting
requirements finalized in the 2024 CMS Interoperability and Prior
Authorization final rule for non-drug items and services (89 FR 8897).
We propose that this change would be effective on the effective date of
the final rule to align the reporting requirements as soon as
practicable.
In summary, we request comment on our proposals in the CFR sections
listed in Table 6, and specifically on the following:
The proposal to modify the deadlines for Medicaid managed
care plans and CHIP managed care entities to report certain metrics
about prior authorizations for non-drug items and services to be no
later than 90 days after the end of their contract rating period.
The proposal to require Medicaid managed care plans and
CHIP managed care entities to report certain metrics about prior
authorizations for non-drug items and services, finalized in the 2024
Interoperability and Prior Authorization final rule, by program, as
well as by plan.
The proposals to become effective beginning on the
effective date of the final rule.
[[Page 19940]]
6. Proposed Changes to Publicly Reported Prior Authorization Metrics
for Non-Drug Items and Services for Impacted Payers
In the 2024 CMS Interoperability and Prior Authorization final
rule, we finalized a requirement that impacted payers report certain
prior authorization metrics aggregated for all non-drug items and
services on their public websites (89 FR 8897). After further
consideration, we are proposing to amend those metrics to provide more
useful and complete information. Currently, impacted payers must report
the percentage of prior authorizations that were approved, denied,
approved after appeal, and approved after the timeframe for review was
extended (89 FR 8889-8890). We are proposing to also require impacted
payers to report a numeric count of prior authorization requests, as
well as percentages, for certain existing metrics.
In addition, we are proposing to add four metrics that are
complementary to existing metrics. For simplicity, we use the term
``reporting period'' to describe the period from which data must be
reported. Specifically, the reporting period for MA organizations,
state Medicaid and CHIP FFS programs, and QHP issuers on the FFEs would
be the calendar year and the reporting period for Medicaid managed care
plans and CHIP managed care entities would be the rating period. We
propose to require impacted payers to report the following:
The total number and percentage of standard prior
authorization requests for non-drug items and services that remain
denied after appeal during the reporting period.\144\
---------------------------------------------------------------------------
\144\ Appeals for MA organizations are described in 42 CFR 422
Subpart M. Appeals for state Medicaid FFS programs (known as fair
hearings) are described in 42 CFR 431 Subpart E and for Medicaid
managed care plans in 42 CFR 438 Subpart F. Appeals for state CHIP
FFS programs are described in 42 CFR 457 Subpart K and for CHIP
managed care entities in 42 CFR 457.1260. Appeals for QHP issuers on
the FFEs are described in 45 CFR 147.136.
---------------------------------------------------------------------------
++ Numerator: The total number of standard prior authorization
requests for non-drug items and services that were appealed and the
denial was upheld.
++ Denominator: The total number of adjudicated appeals for
standard prior authorization requests for non-drug items and services.
The total number and percentage of expedited prior
authorization requests for non-drug items and services that remain
denied after appeal during the reporting period.
++ Numerator: The total number of expedited prior authorization
requests for non-drug items and services that were appealed and the
denial was upheld.
++ Denominator: The total number of adjudicated appeals for
expedited prior authorization requests for non-drug items and services.
The total number and percentage of standard prior
authorization requests for non-drug items and services for which the
timeframe for review was extended, and the request was denied during
the reporting period.
++ Numerator: The total number of standard prior authorization
requests for non-drug items and services for which the timeframe for
review was extended and the request was denied.
++ Denominator: The total number of standard prior authorization
requests for non-drug items and services.
The total number and percentage of expedited prior
authorization requests for non-drug items and services for which the
timeframe for review was extended, and the request was denied during
the reporting period.
++ Numerator: The total number of expedited prior authorization
requests for non-drug items and services for which the timeframe for
review was extended and the request was denied.
++ Denominator: The total number of expedited prior authorization
requests for non-drug items and services.
The proposed metrics for standard prior authorization requests that
are ``denied after appeal'' and ``for which the timeframe for review
was extended and the request was denied'' are complementary to the
existing metrics for the percentage of standard prior authorization
requests that are ``approved after appeal'' or ``for which the
timeframe for review was extended and the request was approved.'' The
two sets of metrics should generally sum to the total number of
standard prior authorization requests for non-drug items and services
that were appealed and the total number of standard prior authorization
requests for non-drug items and services for which the timeframe for
review was extended. For all metrics we are proposing that are related
to appeals, appeals include both appeals reviewed internally by the
impacted payer as well as by external organizations an impacted payer
may contract with to review and process appeals. Appeals include all
levels of appeal; internal and external appeals should not be
differentiated between and should be aggregated as one metric. Appeals
that have not been fully adjudicated within the reporting period may be
excluded from the metrics. In addition, we propose that impacted payers
report on the following:
The total number and percentage of expedited prior
authorization requests for non-drug items and services for which the
timeframe for review was extended, and the request was approved during
the reporting period.
++ Numerator: The total number of expedited prior authorization
requests for non-drug items and services for which the timeframe for
review was extended and the request was approved.
++ Denominator: The total number of expedited prior authorization
requests for non-drug items and services.
The total number and percentage of expedited prior
authorization requests for non-drug items and services that were
approved after appeal during the reporting period.
++ Numerator: The total number of expedited prior authorization
requests for non-drug items and services that were appealed, and the
denial was overturned.
++ Denominator: The total number of adjudicated appeals for
expedited prior authorization requests for non-drug items and services.
These two metrics would align the metrics for expedited prior
authorizations with those for standard prior authorizations. For MA
organizations, extensions are described in 42 CFR 422.568(b)(2). For
state Medicaid FFS programs, extensions are described in 42 CFR
440.230(e)(1)(i). For state CHIP FFS programs, extensions are described
in 42 CFR 457.495(d). For Medicaid managed care plans, extensions are
described in 42 CFR 438.210(d), and by cross-reference in 42 CFR
457.1230(d) for CHIP managed care entities. For QHP issuers on the
FFEs, extensions would be described by the proposal, discussed earlier,
in 45 CFR 156.223(h)(3). Notably, 42 CFR 440.230 does not provide for
expedited prior authorization requests to be extended by state Medicaid
FFS programs. Therefore, we are not proposing those metrics for state
Medicaid FFS programs. The existing and proposed metrics for non-drug
items and services are listed in Table 5.
We are proposing to require impacted payers to publicly report
these additional data to ensure these reports are useful and robust, as
well as to align with other CMS reporting requirements. We believe that
to make these metrics truly useful, CMS and the public must understand
the scope of the prior authorization requests, both as an absolute
number and as a percentage, because these numbers are complementary.
The absolute number provides a scale and reveals the number of prior
authorization requests submitted to the payer over the previous
[[Page 19941]]
reporting period. A percentage, on the other hand, provides an easy-to-
understand metric to compare payers. Both of those numbers are
important to provide context to individuals reviewing the reported
data. Percentages and absolute numbers also allow for comparison across
impacted payers and could highlight differences between payers, both in
the number of prior authorization requests that they receive, as well
as the approval rates at each stage of the process. Furthermore, using
both the absolute number and percentage of prior authorizations in
these metrics may avoid misinterpretation of the data. For instance, a
small percentage of denied prior authorizations may seem insignificant
until one understands that it represents thousands of prior
authorizations. Conversely, for a payer that requires few prior
authorizations, a large percentage of denials may be misinterpreted.
Therefore, reporting both the number and percentage of prior
authorization decisions by payers over the previous reporting period
provides more comprehensive and useful information of these data while
ensuring that the interpretation of these data is accurate and properly
contextualized.
We also propose minor wording changes to simplify the existing
metrics and specify that the proposal include the ``total number'' of
prior authorizations for each metric rather than ``aggregated for all
items and services.'' We do not intend this proposal to change any
policy or the definition of the metrics.
[GRAPHIC] [TIFF OMITTED] TP14AP26.283
We are proposing that, if finalized, these additional metrics be
effective beginning on the effective date of the final rule to be
reported in the following year. We believe that producing these metrics
would be a relatively straightforward task for impacted payers that
have built their systems to generate the metrics required to be
reported beginning in 2026. For example, percentages are derived from
numeric counts of numerators and denominators. The numerator should
reflect the subset of interest, such as requests approved or denied,
and the denominator should be the total number of prior authorization
requests (for all metrics not related to appeals). For metrics related
to appeals, the denominator should be the total number of decided
appeals of prior authorization requests during the reporting period. If
an impacted payer has calculated the percentages for the existing
metrics, they should already have available the numeric counts without
additional burden. The proposals would require impacted payers to
publicly report those numeric counts that they should already have. In
addition, several of the proposed metrics are complementary to the
existing metrics. For example, impacted payers must currently report on
the percentage of standard prior authorization requests that were
approved after appeal. In order to calculate that percentage, impacted
payers would also have to know how many requests were denied after
appeal, as those two percentages should total to 100 percent of the
adjudicated appeals. Therefore, we believe there should be minimal
additional burden to report the proposed new metrics and impacted
payers should be able to report the additional metrics by the effective
date of the final rule. We believe that the immediate transparency
benefits to the public weigh in favor of an effective date as soon as
possible. Finally, these additional metrics should provide much-needed
context to the payer's prior authorization program; therefore, we are
proposing that the additional metrics be required for the first
reporting deadline after the effective date of the final rule.
In summary, we request comment on our proposals in the CFR
citations listed in Table 6, and specifically on the following:
The proposal to require impacted payers to report the
prior authorization metrics regarding non-drug items and services
listed as ``new'' metrics in Table 5 on their public websites.
The proposal to become effective beginning on the
effective date of the final rule.
7. Proposed Requirement To Publicly Report Prior Authorization Metrics
for Drugs for Impacted Payers
To incorporate drugs into the existing prior authorization metrics,
we are now proposing to require impacted payers to annually report
certain metrics about prior authorizations for all drugs (excluding
covered Part D drugs for MA-PDs) by posting this information on their
public website. Covered Part D drugs and PDPs are not included in this
proposal because they are covered in other reporting regulations, and
it would be burdensome to add new, duplicative reporting requirements
on these plans. The Part D program already has reporting requirements
for aggregated coverage determinations,
[[Page 19942]]
redeterminations, and reopenings for covered Part D drugs.\145\
---------------------------------------------------------------------------
\145\ Existing reporting requirements for PDPs may be found at:
Centers for Medicare & Medicaid Services. (2024). Part D Reporting
Requirements. Retrieved from https://www.cms.gov/medicare/coverage/prescription-drug-coverage-contracting/part-d-reporting-requirements.
---------------------------------------------------------------------------
We propose that impacted payers, other than Medicaid managed care
plans and CHIP managed care entities, be required to annually report
the previous calendar year's metrics regarding all drugs, excluding
covered Part D drugs for MA-PDs, on their public websites beginning in
2028 (with data from 2027) following any calendar year that any of
these impacted payers offered that type of plan. We propose to require
that these metrics be made publicly available on those impacted payers'
websites no later than March 31 to be consistent with the reporting
requirements finalized in the 2024 CMS Interoperability and Prior
Authorization final rule for non-drug items and services.\146\ To align
with our proposal to amend the reporting deadline for Medicaid managed
care plans and CHIP managed care entities, discussed previously in
section II.C.5. of this proposed rule, we are proposing to require
Medicaid managed care plans and CHIP managed care entities to publicly
post the required prior authorization metrics no later than 90 days
after the end of their rating period.
---------------------------------------------------------------------------
\146\ See 42 CFR 422.122(c) for MA organizations and applicable
integrated plans, 42 CFR 440.230(e)(3) for state Medicaid FFS
programs, 42 CFR 457.732(c) for state CHIP FFS programs, 42 CFR
438.210(f) for Medicaid managed care plans, through existing cross
reference to 42 CFR 438.210 in 42 CFR 457.1230(d) for CHIP managed
care entities, and 45 CFR 156.223(c) for individual market QHP
issuers on the FFEs.
---------------------------------------------------------------------------
To tie the metrics to the appropriate terminology for covered
drugs, we propose that for these metrics, MA organizations would
include any drugs payable under Part B that require prior
authorization. Our understanding is that MA organizations do not
require separate prior authorization requests for drugs payable under
Part A. Rather, when prior authorization is required, it is requested
and approved as part of a bundled payment for inpatient services.
Therefore, because they are aggregated into requests for other items
and services, we are not including drugs payable under Part A in the
scope of the metrics we are proposing to require MA organizations to
report. However, we request comment on whether there are drugs payable
under Part A that require prior authorization separate from other items
and services. If that is the case, we believe that metrics about drugs
payable under Part A would be as important as those we are proposing
for drugs payable under Part B. Therefore, we would consider finalizing
that MA organizations report the proposed metrics by aggregating data
from drugs payable under Part A and Part B.
State Medicaid and Medicaid managed care plans would report on all
prescribed drugs described in section 1905(a)(12) of the Act that
require prior authorization. State CHIP FFS programs and CHIP managed
care entities would report on all prescription drugs described in
section 2110(a)(6) of the Act that require prior authorization.
Finally, QHP issuers on the FFEs would include all drugs covered by the
issuer that require prior authorization.
Excluding any category of drug would provide an incomplete picture
of the burden and impact of a payer's prior authorization practices.
Some specialty and high-cost drugs may be subject to different
utilization management requirements or denial rates. By being
inclusive, we promote transparency and accountability for the prior
authorization process across all types of drugs. For all of the reports
for which we are proposing a percentage, we are also proposing that
each impacted payer provide, as part of its report, the metrics'
calculated numerators and denominators to provide a greater level of
detail. Appeals that have not been fully adjudicated within the
reporting period may be excluded. Furthermore, we recommend that
impacted payers consider the format of their reports so that the data
can be easily understood both in writing and graphically. An example of
this type of report is available on the Medicare website for the FFS
program.\147\
---------------------------------------------------------------------------
\147\ Centers for Medicare & Medicaid Services. (2023, September
15). Prior Authorization and Pre-Claim Review Program Stats.
Retrieved from https://www.cms.gov/files/document/prior-authorization-and-pre-claim-review-program-statistics.pdf.
---------------------------------------------------------------------------
We propose to require MA organizations to post the following
metrics from the previous calendar year on their public websites:
A list of all drugs payable under Part B that require
prior authorization.
The total number and percentage of approved standard prior
authorization requests for Part B drugs during the calendar year.
++ Numerator: The total number of approved standard prior
authorization requests for Part B drugs.
++ Denominator: The total number of standard prior authorization
requests for Part B drugs.
The total number and percentage of denied standard prior
authorization requests for Part B drugs during the calendar year.
++ Numerator: The total number of denied standard prior
authorization requests for Part B drugs.
++ Denominator: The total number of standard prior authorization
requests for Part B drugs.
The total number and percentage of standard prior
authorization requests for Part B drugs for which the timeframe for
review was extended, and the request was approved during the calendar
year.
++ Numerator: The total number of standard prior authorization
requests for Part B drugs for which the timeframe for review was
extended and the request was approved.
++ Denominator: The total number of standard prior authorization
requests for Part B drugs.
The total number and percentage of standard prior
authorization requests for Part B drugs for which the timeframe for
review was extended, and the request was denied during the calendar
year.
++ Numerator: The total number of standard prior authorization
requests for Part B drugs for which the timeframe for review was
extended and the request was denied.
++ Denominator: The total number of standard prior authorization
requests for Part B drugs.
The total number and percentage of standard prior
authorization requests for Part B drugs approved after appeal during
the calendar year.\148\
---------------------------------------------------------------------------
\148\ Appeals for MA organizations are described in 42 CFR 422
Subpart M.
---------------------------------------------------------------------------
++ Numerator: The total number of standard prior authorization
requests for Part B drugs that were appealed, and the denial was
overturned.
++ Denominator: The total number of adjudicated appeals for
standard prior authorization requests for Part B drugs.
The total number and percentage of standard prior
authorization requests for Part B drugs that remain denied after appeal
during the calendar year.
++ Numerator: The total number of standard prior authorization
requests for Part B drugs that were appealed, and the denial was
upheld.
++ Denominator: The total number of adjudicated appeals for
standard prior authorization requests for Part B drugs.
The average and median time that elapsed between the
submission of requests and decisions for standard prior authorizations
for Part B drugs during the calendar year.
The total number and percentage of approved expedited
prior authorization requests for Part B drugs during the calendar year.
++ Numerator: The total number of approved expedited prior
authorization requests for Part B drugs.
[[Page 19943]]
++ Denominator: The total number of expedited prior authorization
requests for Part B drugs.
The total number and percentage of denied expedited prior
authorization requests for Part B drugs during the calendar year.
++ Numerator: The total number of denied expedited prior
authorization requests for Part B drugs.
++ Denominator: The total number of expedited prior authorization
requests for Part B drugs.
The total number and percentage of expedited prior
authorization requests for Part B drugs for which the timeframe for
review was extended, and the request was approved during the calendar
year.
++ Numerator: The total number of expedited prior authorization
requests for Part B drugs for which the timeframe for review was
extended and the request was approved.
++ Denominator: The total number of expedited prior authorization
requests for Part B drugs.
The total number and percentage of expedited prior
authorization requests for Part B drugs for which the timeframe for
review was extended, and the request was denied during the calendar
year.
++ Numerator: The total number of expedited prior authorization
requests for Part B drugs for which the timeframe for review was
extended and the request was denied.
++ Denominator: The total number of expedited prior authorization
requests for Part B drugs.
The total number and percentage of expedited prior
authorization requests for Part B drugs approved after appeal during
the calendar year.
++ Numerator: The total number of expedited prior authorization
requests for Part B drugs that were appealed, and the denial was
overturned.
++ Denominator: The total number of adjudicated appeals for
expedited prior authorization requests for Part B drugs.
The total number and percentage of expedited prior
authorization requests for Part B drugs that remain denied after appeal
during the calendar year.
++ Numerator: The total number of expedited prior authorization
requests for Part B drugs that were appealed, and the denial was
upheld.
++ Denominator: The total number of adjudicated appeals for
expedited prior authorization requests for Part B drugs.
The average and median time that elapsed between the
submission of requests and decisions for expedited prior authorizations
for Part B drugs during the calendar year.
We propose to require state Medicaid and CHIP FFS programs to post
the following metrics from the previous calendar year on their public
websites and to require Medicaid managed care plans and CHIP managed
care entities to post the following metrics from the previous rating
period on their public websites:
A list of all drugs that require prior authorization.
The total number and percentage of prior authorization
requests for all drugs that were approved during the reporting period.
++ Numerator: The total number of prior authorization requests for
all drugs that were approved.
++ Denominator: The total number of prior authorization requests
for all drugs.
The total number and percentage of prior authorization
requests for all drugs that were denied during the reporting period.
++ Numerator: The total number of prior authorization requests for
all drugs that were denied.
++ Denominator: The total number of prior authorization requests
for all drugs.
The total number and percentage of prior authorization
requests for all drugs approved after appeal during the reporting
period.\149\
---------------------------------------------------------------------------
\149\ Appeals for state Medicaid FFS programs (known as fair
hearings) are described in 42 CFR 431 Subpart E and for Medicaid
managed care plans in 42 CFR 438 Subpart F. Appeals for state CHIP
FFS programs are described in 42 CFR 457 Subpart K and for CHIP
managed care entities in 42 CFR 457.1260.
---------------------------------------------------------------------------
++ Numerator: The total number of prior authorization requests for
all drugs that were appealed, and the denial was overturned.
++ Denominator: The total number of adjudicated appeals for prior
authorization requests for all drugs.
The total number and percentage of prior authorization
requests for all drugs that remain denied after appeal during the
reporting period.
++ Numerator: The total number of prior authorization requests for
all drugs that were appealed, and the denial was upheld.
++ Denominator: The total number of adjudicated appeals for prior
authorization requests for all drugs.
The average and median time that elapsed between the
submission of requests and decisions for prior authorizations for all
drugs during the reporting period.
We propose to require QHP issuers on the FFEs to post the following
metrics from the previous calendar year on their public websites:
A list of all drugs that require prior authorization.
The total number and percentage of standard prior
authorization requests for all drugs that were approved during the
calendar year.
++ Numerator: The total number of standard prior authorization
requests for all drugs that were approved.
++ Denominator: The total number of standard prior authorization
requests for all drugs.
The total number and percentage of standard prior
authorization requests for all drugs that were denied during the
calendar year.
++ Numerator: The total number of standard prior authorization
requests for all drugs that were denied.
++ Denominator: The total number of standard prior authorization
requests for all drugs.
The total number and percentage of standard prior
authorization requests for all drugs for which the timeframe for review
was extended, and the request was approved during the calendar year.
++ Numerator: The total number of standard prior authorization
requests for all drugs for which the timeframe for review was extended
and the request was approved.
++ Denominator: The total number of standard prior authorization
requests for all drugs.
The total number and percentage of standard prior
authorization requests for all drugs for which the timeframe for review
was extended, and the request was denied during the calendar year.
++ Numerator: The total number of standard prior authorization
requests for all drugs for which the timeframe for review was extended
and the request was denied.
++ Denominator: The total number of standard prior authorization
requests for all drugs.
The total number and percentage of standard prior
authorization requests for all drugs approved after appeal during the
calendar year.\150\
---------------------------------------------------------------------------
\150\ Appeals for QHP issuers on the FFEs are described in 45
CFR 147.136.
---------------------------------------------------------------------------
++ Numerator: The total number of standard prior authorization
requests for all drugs that were appealed, and the denial was
overturned.
++ Denominator: The total number of adjudicated appeals for
standard prior authorization requests for all drugs.
The total number and percentage of standard prior
authorization requests for all drugs that remain denied after appeal
during the calendar year.
++ Numerator: The total number of standard prior authorization
requests for all drugs that were appealed, and the denial was upheld.
[[Page 19944]]
++ Denominator: The total number of adjudicated appeals for
standard prior authorization requests for all drugs.
The average and median time that elapsed between the
submission of requests and decisions for standard prior authorizations
for all drugs during the calendar year.
The total number and percentage of expedited prior
authorization requests for all drugs that were approved during the
calendar year.
++ Numerator: The total number of expedited prior authorization
requests for all drugs that were approved.
++ Denominator: The total number of expedited prior authorization
requests for all drugs.
The total number and percentage of expedited prior
authorization requests for all drugs that were denied during the
calendar year.
++ Numerator: The total number of expedited prior authorization
requests for all drugs that were denied.
++ Denominator: The total number of expedited prior authorization
requests for all drugs.
The total number and percentage of expedited prior
authorization requests for all drugs for which the timeframe for review
was extended, and the request was approved during the calendar year.
++ Numerator: The total number of expedited prior authorization
requests for all drugs for which the timeframe for review was extended
and the request was approved.
++ Denominator: The total number of expedited prior authorization
requests for all drugs.
The total number and percentage of expedited prior
authorization requests for all drugs for which the timeframe for review
was extended, and the request was denied during the calendar year.
++ Numerator: The total number of expedited prior authorization
requests for all drugs for which the timeframe for review was extended
and the request was denied.
++ Denominator: The total number of expedited prior authorization
requests for all drugs.
The total number and percentage of expedited prior
authorization requests for all drugs approved after appeal during the
calendar year.
++ Numerator: The total number of expedited prior authorization
requests for all drugs that were appealed, and the denial was
overturned.
++ Denominator: The total number of adjudicated appeals for
expedited prior authorization requests for all drugs.
The total number and percentage of expedited prior
authorization requests for all drugs that remain denied after appeal
during the calendar year.
++ Numerator: The total number of expedited prior authorization
requests for all drugs that were appealed, and the denial was upheld.
++ Denominator: The total number of adjudicated appeals for
expedited prior authorization requests for all drugs.
The average and median time that elapsed between the
submission of requests and decisions for expedited prior authorizations
for all drugs during the calendar year.
We propose to align impacted payers' reporting levels with those we
finalized in the 2024 CMS Interoperability and Prior Authorization
final rule.\151\ Specifically, we propose that MA organizations would
report at the contract level (applicable integrated plans would report
drugs covered by MA organizations at the MA contract level), state
Medicaid and CHIP FFS programs would report at the state level,
Medicaid managed care plans and CHIP managed care entities would report
at the plan and program level (if coverage of drugs is included in
their contract), and QHP issuers on the FFEs would report at the issuer
level.
---------------------------------------------------------------------------
\151\ See 42 CFR 422.122(c) for MA organizations and applicable
integrated plans, 42 CFR 440.230(e)(3) for state Medicaid FFS
programs, 42 CFR 457.732(c) for state CHIP FFS programs, 42 CFR
438.210(f) for Medicaid managed care plans, through existing cross
reference to 42 CFR 438.210 in 42 CFR 457.1230(d) for CHIP managed
care entities, and 45 CFR 156.223(c) for individual market QHP
issuers on the FFEs.
---------------------------------------------------------------------------
We believe that the contract level is appropriate for MA
organizations because they generally have multiple plans under the same
contract (89 FR 8890). It is common for MA organizations to offer a
variety of plans within a service area. The contract-level data are
aggregated data collected from the plan benefit packages (PBPs) for all
MA plans provided under an individual contract. Data are specific to
the contract to which they correspond. CMS already requires MA
organizations to report some contract-level data about their
organization determinations on an annual basis and assigns Star Ratings
at the contract level.
We are proposing to align the reporting levels for state Medicaid
and CHIP FFS programs in this proposed rule with those finalized in the
2024 CMS Interoperability and Prior Authorization final rule (89 FR
8897) and the proposed amendment for Medicaid managed care plans and
CHIP managed care entities described in section II.C.5. of this
proposed rule--that is, at the state level for state Medicaid and CHIP
FFS programs and at the plan and program level for Medicaid managed
care plans and CHIP managed care entities--to create a cohesive and
standardized approach to reporting for the long-term for comparability
and analysis for both medical services and drugs.
Similarly, requiring individual market QHP issuers on the FFEs to
report at the issuer level is consistent with their reporting on
quality improvement strategies as described in section 1311(g) of the
Affordable Care Act and 45 CFR 156.1130, which also provides
consistency with other reporting requirements for QHP issuers on the
FFEs' (89 FR 8890). Our proposals for consistency across reporting
requirements aim to reduce the reporting burden on issuers and ensure
the publication of metrics in a method that issuers are familiar with.
We note that it is also consistent with the Transparency in Coverage
(TiC) reporting requirements in 45 CFR 156.220 and the level at which a
QHP issuer on the FFEs must submit its certification application to
participate in an FFE or an SBE-FP. This level is represented by the
six-digit ``Issuer ID'' assigned to each QHP issuer on the FFEs as part
of the QHP Certification application process, as explained in CMS's
Application Instructions.\152\ While a parent organization may perform
some of the work associated with reporting this information and may opt
to publish the information on its website, the information must be
available based on an issuer level as is required by regulation in 45
CFR 156.220 and as specified in the QHP Certification Application
Instructions.
---------------------------------------------------------------------------
\152\ Qualified Health Plan Certification. (2024, August 8).
Application Instructions. Retrieved from https://www.qhpcertification.cms.gov/s/Application%20Instructions.
---------------------------------------------------------------------------
In summary, we request comment on our proposals in the CFR sections
listed in Table 6, and specifically on the following:
The proposal to require MA organizations to report metrics
about prior authorization for drugs payable under Part B, and to
require state Medicaid and CHIP FFS programs, Medicaid managed care
plans, CHIP managed care entities, and QHP issuers on the FFEs to
report metrics about prior authorization metrics for drugs on their
public websites.
The proposal to require MA organizations, state Medicaid
and CHIP FFS programs, and QHP issuers on the FFEs to annually report
the previous calendar year's metrics on their public websites no later
than March 31 following any calendar year that the impacted payer
offered that type of plan.
[[Page 19945]]
The proposal to require Medicaid managed care plans and
CHIP managed care entities to annually report the previous rating
period's metrics on their public websites no later than 90 days after
the end of their rating period.
The proposal to require MA organizations to report at the
contract level (applicable integrated plans would report drugs covered
by MA organizations at the MA contract level), state Medicaid and CHIP
FFS programs to report at the state level, Medicaid managed care plans
and CHIP managed care entities to report at the plan and program level
(if coverage of drugs is included in their contract), and QHP issuers
on the FFEs to report at the issuer level.
The proposed 2028 compliance dates to report metrics from
the 2027 reporting period.
In addition, we request comments on the following:
Whether there are drugs payable under Part A that require
prior authorization separate from other non-drug items and services
that should be included in the scope of the proposed metrics for MA
organizations.
BILLING CODE 4150-28-P
[[Page 19946]]
[GRAPHIC] [TIFF OMITTED] TP14AP26.284
[[Page 19947]]
[GRAPHIC] [TIFF OMITTED] TP14AP26.285
[[Page 19948]]
BILLING CODE 4150-28-C
8. Statutory Authorities
a. Medicare Advantage
Section 1856(b) of the Act directs the Secretary to establish
regulatory standards for MA organizations that are consistent with and
carry out Part C of Title XVIII of the Act. In addition, section
1857(e)(1) of the Act explicitly authorizes the addition of reporting
requirements by MA organizations as a contract term between the
Secretary and a MA organization where not inconsistent with Part C of
Title XVIII of the Act and as the Secretary may find necessary and
appropriate. The proposal for MA plans to publicly report additional
prior authorization metrics for drugs payable under Part B reflects a
necessary and appropriate requirement that is consistent with and
carries out Part C, as it should enable patients to assess the
implementation of the proposals in this rule. A review of these metrics
on individual websites may help CMS understand the impact of the
proposed requirements, including the effects of using the Prior
Authorization API for drugs payable under Part B. These data may also
help plans evaluate and modify their operational policies, improve
their use of the Prior Authorization API, and determine if any policy
updates would be appropriate.
b. State Medicaid and CHIP
Section 1902(a)(3) of the Act addresses the requirements for the
states to provide policies to protect beneficiaries through
opportunities for fair hearings when their services are denied or not
acted upon with reasonable promptness. Section 1902(a)(19) of the Act
underpins timeliness standards and requires Medicaid state plans to
provide safeguards necessary to assure that eligibility for Medicaid-
covered services will be determined and such services will be provided
consistently with simplicity of administration and in the best
interests of recipients. We have proposed that state Medicaid FFS
programs and Medicaid managed care plans publish additional data about
their prior authorization performance specific to drugs, and we rely on
the authorities for Medicaid managed care plans under section
1932(c)(2)(A)(i) of the Act, which supports managed care access
standards and requires that states that contract with Medicaid MCOs
develop and implement a quality assessment and improvement strategy
that includes standards for access to care so that covered services are
available within reasonable timeframes. For this proposal, CMS would
rely on our authority in section 1902(a)(4) of the Act to adopt these
standards for PIHPs and PAHPs. This would ensure that the same
requirements apply to MCOs, PIHPs, and PAHPs.
For CHIP, we propose these requirements under the authority of
section 2101(a) of the Act, which sets forth that the purpose of Title
XXI is to provide funds to states to provide child health assistance to
uninsured, low-income children effectively and efficiently that is
coordinated with other sources of health benefits coverage. This
provision authorizes us to propose these requirements for CHIP to
obtain access to program data for analysis. Such analysis supports
improvements in the efficacy of CHIP programs and more efficient
administration of services.
We expect that the proposal for state CHIP FFS programs to make
prior authorization decisions on all drugs no later than 24 hours
should improve timeliness and support process improvements for the
state, which is consistent with our authorities under section 2101(a)
of the Act in that it enhances the efficiency of the CHIP program.
Further, as authorized under section 2107(b)(1) of the Act, the
proposal to require state CHIP FFS programs and CHIP managed care
entities to report prior authorization metrics publicly should also
support the states' oversight, evaluation, and administration
responsibilities.
c. Qualified Health Plan Issuers on the Federally-facilitated Exchanges
The proposals to require QHP issuers on the FFEs to provide the
specific reason for denial of prior authorizations of drugs when
notifying the provider; notify providers of prior authorization
decisions for non-drug items and services and drugs, and to do so
within specified timeframes; and publish certain metrics on their
websites, are authorized by section 1311(e)(1) of the Affordable Care
Act. Section 1311(e)(1)(A) of the Affordable Care Act requires that
Exchanges only certify plans as QHPs if they meet the requirements for
certification promulgated by the Secretary under section 1311(c)(1) of
the Affordable Care Act, and section 1311(e)(1)(B) of the Affordable
Care Act provides discretion to certify QHPs if the Exchange determines
that making available such plans available is in the interests of
qualified individuals and qualified employers in the state or states in
which such Exchange operates. We are of the view that these proposals
are appropriate QHP certification requirements because they strive to
expand several key regulatory and patient-protection obligations
established under the Affordable Care Act.
We are proposing to require QHP issuers on the FFEs to notify
providers of prior authorization decisions for non-drug items and
services within the same timeframes applicable to other impacted
payers, as established in the 2024 CMS Interoperability and Prior
Authorization final rule (89 FR 8878). Specifically, we are proposing
to require QHP issuers on the FFEs to notify providers of prior
authorization decisions on non-drug items and services as expeditiously
as a patient's health condition requires but no later than 7 calendar
days after receiving a standard request and no later than 72 hours
after receiving an expedited request. If finalized, this proposal would
allow enrollees in health plans on the FFEs to receive covered services
more quickly, which may improve patient care.
We also propose to require that QHP issuers on the FFEs make prior
authorization decisions to providers on all drugs as expeditiously as
the enrollee's health condition requires, but no later than 72 hours
after receiving a standard request and, as expeditiously as the
enrollee's health condition requires, but no later than 24 hours after
receiving an expedited request. This proposal to require QHP issuers on
the FFEs to provide notice to requesting providers of prior
authorization decisions in a shorter timeframe than they are currently
required to provide notice to patients of prior authorization decisions
should allow providers to more quickly alter treatment plans, including
to send updated prescriptions to pharmacies if a prior authorization is
denied. We consider the proposal to require QHP issuers on the FFEs to
notify the requesting provider of a prior authorization decision within
a specific timeframe based on the nature of the request necessary
because delays can directly impact a patient's health. Drugs sometimes
need to be taken soon after a diagnosis is rendered and often need to
be taken consistently and on time for optimal effectiveness. Delays in
obtaining and taking medication could lead to a worsening of a
patient's condition, create complications, and potentially require more
intensive or costly interventions at a later time.
With respect to the proposal to require QHP issuers on the FFEs to
publish certain metrics on their websites, we believe that, as payers
create and analyze prior authorization metrics reports, they would use
the data to learn about and improve their own
[[Page 19949]]
performance in adjudicating prior authorization requests. Additionally,
we believe that the public availability of prior authorization decision
data would further transparency in the interests of qualified
individuals and qualified employers in the state in which the Exchange
operates by providing clear information to consumers that they could
use when selecting a new plan. Similarly, some providers may find
metrics about prior authorization approvals or appeals useful when
selecting payer networks.
If finalized, publicly reported prior authorization metrics for
drugs could enable CMS to assess the implementation of the policies
proposed in this rule. Reviewing these metrics on individual websites
may help CMS understand the impact of the proposed requirements,
including using the Prior Authorization API for drugs. At the same
time, the reports could help QHP issuers on the FFEs evaluate and
improve their own operational processes.
For the reasons stated in the paragraphs in this section above, we
have determined that the proposed changes described in sections
II.C.2.c. and II.C.3.b. of this proposed rule are in the interests of
qualified individuals and qualified employers in the state or states in
which an QHP issuer on the FFEs operates.
D. Requirements for Issuers That Offer Small Group Market Qualified
Health Plans on the Federally-Facilitated Small Business Health Options
Program Exchanges
1. Introduction
We propose to apply the existing requirements in 45 CFR 156.221, 45
CFR 156.222, and 45 CFR 156.223, which were finalized in the 2020 CMS
Interoperability and Patient Access final rule and in the 2024 CMS
Interoperability and Prior Authorization final rule (85 FR 25510 and 89
FR 8758), to small group market QHP issuers on the FF-SHOPs. As
discussed in section I.B. of this proposed rule, we are also proposing
that small group market QHP issuers on the FF-SHOPs be considered
impacted payers for purposes of the proposed QHP issuer requirements
described throughout this proposed rule.\153\ We emphasize that neither
individual market QHP issuers on the SBEs nor small group market QHP
issuers on the SBEs are impacted payers and therefore, would not be
subject to these proposals.
---------------------------------------------------------------------------
\153\ See the following sections for these proposals: II.A.2.a.
through II.A.2.c., II.A.3., II.A.4.b.(1). and II.A.4.b.(2).,
II.A.4.b.(4). and II.A.4.b.(5)., II.B.3. through II.B.7., II.C.2.c.,
II.C.3.b. and II.C.3.d., II.C.6. and II.C.7., II.E.1. through
II.E.4., II.F.1.b., II.F.2.b., II.F.2.c., II.F.5.a., and II.F.5.b.
of this proposed rule.
---------------------------------------------------------------------------
For requirements in 45 CFR 156.221 that have already taken effect
for issuers offering individual market QHPs on the FFEs, we propose
compliance dates in the future for small group market QHP issuers on
the FF-SHOPs. For example, we are proposing a compliance date of plan
years beginning on or after January 1, 2028 for small group market QHPs
on the FF-SHOPs to comply with 45 CFR 156.221(a), whereas the
compliance date for individual market QHPs on the FFEs was for plan
years beginning on or after January 1, 2021. For requirements in 45 CFR
156.222 and 45 CFR 156.223 that we expect to take effect before this
proposed rule can be finalized, we are also proposing separate
compliance dates for small group market issuers on the FF-SHOPs that we
believe are reasonable. For example, we are proposing compliance dates
for plan years beginning on or after January 1, 2028 for the Provider
Access and Payer-to-Payer API requirements in 45 CFR 156.222(a) and
(b), and the requirement in 45 CFR 156.221(f) to report Patient Access
API usage metrics to CMS. We are also proposing compliance dates of
October 1, 2027 for the Prior Authorization API requirements in 45 CFR
156.223(b) and the requirement in 45 CFR 156.223(a) to provide a reason
to providers for denying a prior authorization for non-drug items and
services. We believe that the proposed compliance dates are the
earliest dates that are feasible to implement proposals for small group
market QHP issuers given the rulemaking timeline.
We are proposing the same compliance dates of October 1, 2027 for
certain proposals in this rule that would newly apply to both small
group market QHPs on the FF-SHOPs and individual market QHPs on the
FFEs. Those proposals include the requirements to implement and
maintain certain HL7[supreg] FHIR[supreg] and NCPDP standards to
support electronic prior authorization for drugs in 45 CFR
156.223(b)(1)(iii) and (e), as well as notice requirements that create
prior authorization decision timeframes in 45 CFR 156.223(i). We are
also proposing the same compliance dates, beginning in 2028, for
proposals in this rule that would newly apply to both small group
market QHPs on the FF-SHOPs and individual market QHPs on the FFEs
regarding reporting API usage metrics to CMS in 45 CFR 156.222(a)(6)
and (b)(8) and 45 CFR 156.223(e) and publicly reporting prior
authorization metrics for drugs in 45 CFR 156.223(d).
We did not apply these policies to small group market QHP issuers
on the FF-SHOPs in previous rulemaking due to concerns about placing
burden on these issuers (85 FR 25553 and 89 FR 8767). However, based on
additional research, all issuers that offer small group market QHPs on
the FF-SHOPs as of the time of this proposal also offer individual
market QHPs on the FFEs. Therefore, we anticipate that the burden for
these issuers to implement these policies for their small group market
QHPs on the FF-SHOPs should be relatively low because these issuers are
already required to implement the policies for their individual market
QHPs on the FFEs. Additionally, we believe that enrollees in small
group market QHPs on the FF-SHOPs should have access to the benefits of
health data transparency discussed in previous rulemaking such as
better coordinated care and the ability to make more informed decisions
about their care (85 FR 25523 and 89 FR 8820). If these policies are
finalized as proposed, and these considerations change in the future--
for example, if an issuer that does not offer one or more individual
market QHPs on the FFEs newly enters an FF-SHOP, then under this
proposal, we could consider whether to provide an exception to one or
more of these requirements through our established process, as
described in section II.D.7. of this proposed rule, during the annual
QHP certification process, if it is appropriate based on the interests
of qualified individuals and qualified employers in the state or states
in which such Exchange operates and an exception is warranted to permit
the issuer to offer QHPs through the FFE.\154\
---------------------------------------------------------------------------
\154\ For more information on interoperability and QHP
certification, including further detail on the exceptions process,
see https://www.qhpcertification.cms.gov/QHP/applicationmaterials/Interoperability. Discussion of this topic is also available in the
2024 CMS Interoperability and Prior Authorization final rule
preamble: 89 FR 8906.
---------------------------------------------------------------------------
2. General API Requirements Background
In the 2020 CMS Interoperability and Patient Access and the 2024
CMS Interoperability and Prior Authorization final rules, we finalized
general API requirements that apply across the Patient Access, Provider
Access, Payer-to-Payer, and Prior Authorization APIs.\155\ We are now
proposing to
[[Page 19950]]
require small group market QHP issuers on the FF-SHOPs to implement
these requirements, which already apply to individual market QHP
issuers on the FFEs.
---------------------------------------------------------------------------
\155\ We discuss final requirements in the 2020 CMS
Interoperability and Patient Access final rule and the 2024 CMS
Interoperability and Prior Authorization final rule for all impacted
payers, but for ease of reference, we are only providing citations
to these requirements for individual market QHP issuers on the FFEs.
See 45 CFR 156.221(a) for the Patient Access API, 45 CFR 156.222(a)
for the Provider Access API, 45 CFR 156.222(b) for the Payer-to-
Payer API, and 45 CFR 156.223(b) for the Prior Authorization API for
individual market QHP issuers on the FFEs.
---------------------------------------------------------------------------
The previously finalized rules required impacted payers, including
individual market QHP issuers on the FFEs, to implement and maintain
API technology conformant with certain applicable standards adopted by
ONC in 45 CFR 170.215.\156\ Table 3 in this proposed rule lists the
required and recommended standards and IGs to support API
implementation, including updates proposed in this rulemaking. Impacted
payers are permitted to use an updated version of a required standard
for the APIs under certain conditions. Specifically, payers may use
updated versions of standards in 45 CFR 170.213 and 45 CFR 170.215 if
the following conditions are met: (1) the National Coordinator has
approved the updated version for use in the ONC Health IT Certification
Program; (2) the updated version of the standard does not disrupt an
end user's ability to access the required data via that API; and (3)
the updated standard is not prohibited by law. Payers may also use an
updated version if required by other applicable law.\157\
---------------------------------------------------------------------------
\156\ See 45 CFR 156.221(c) for the Patient Access API, 45 CFR
156.222(a)(1)(ii) for the Provider Access API, 45 CFR
156.222(b)(1)(ii) for the Payer-to-Payer API, and 45 CFR 156.223(b)
for the Prior Authorization API.
\157\ See 45 CFR 156.221(c)(4).
---------------------------------------------------------------------------
To ensure that the APIs function properly, impacted payers must
conduct routine testing and monitoring and perform updates as
appropriate. That includes assessments to verify that the API is fully
and successfully implementing privacy and security features, such as
those required for compliance with the HIPAA Privacy Rule and
``Security Standards for the Protection of Electronic Protected Health
Information'' (68 FR 8334) (hereinafter referred to as the ``HIPAA
Security Rule'') which appeared in the Federal Register on February 20,
2003 (45 CFR part 160 and subparts A and C of part 164), 42 CFR part 2,
and other applicable laws protecting privacy and security of
individually identifiable health data.\158\
---------------------------------------------------------------------------
\158\ See 45 CFR 156.221(c)(2).
---------------------------------------------------------------------------
As established in the 2020 CMS Interoperability and Patient Access
final rule, to ensure that developers have the information necessary to
interact with the APIs, impacted payers must make publicly accessible,
by posting on their website or via publicly accessible hyperlink(s),
complete accompanying documentation. That documentation must contain:
(1) API syntax, function names, required and optional parameters
supported and their data types, return variables and their types/
structures, exceptions and exception handling methods and their
returns; (2) the software components and configurations an app must use
in order to successfully interact with the API and process its
response(s); and (3) all applicable technical requirements and
attributes necessary for an app to be registered with any authorization
server(s) deployed in conjunction with the API.\159\
---------------------------------------------------------------------------
\159\ See 45 CFR 156.221(d).
---------------------------------------------------------------------------
As established in the 2020 CMS Interoperability and Patient Access
and the 2024 CMS Interoperability and Prior Authorization final rules,
the only reason impacted payers may deny an app or developer API access
is if it would present an unacceptable level of risk to the security of
PHI on the payer's system.\160\ 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.\161\
---------------------------------------------------------------------------
\160\ See 45 CFR 156.221(e)(1).
\161\ See 45 CFR 156.221(e)(2).
---------------------------------------------------------------------------
3. Patient Access API
a. Background
As discussed in the 2020 CMS Interoperability and Patient Access
final rule, one critical issue in the U.S. health care system is that
people cannot easily access their health information in interoperable
forms. Patients and the health care providers caring for them are often
presented with an incomplete picture of their health and care as pieces
of their information are stored in various, unconnected systems and do
not accompany them to every care setting (85 FR 25511). There are
numerous benefits associated with individuals having access to their
health data through a method that is built upon widely used standards.
In the 2020 CMS Interoperability and Patient Access final rule, we
finalized requirements for impacted payers, including individual market
QHP issuers on the FFEs, to implement and maintain a Patient Access API
conformant with certain FHIR standards that permit third-party apps to
retrieve certain health information, with the approval and at the
direction of a current individual enrollee or the enrollee's personal
representative (85 FR 25558). The ability to easily obtain, use, and
share claims, encounter, and other health data enables patients to more
effectively and easily use the health care system. Providing this
ability to enrollees in all QHPs on the FFEs, including small group
market QHPs on the FF-SHOPs, would empower more people to access their
health information in a manner best suited for them.
b. Proposals
In the 2020 CMS Interoperability and Patient Access final rule, we
finalized a requirement that individual market QHP issuers on the FFEs
must implement and maintain a Patient Access API conformant with
certain FHIR standards that permit third-party apps to retrieve certain
health information, with the approval and at the direction of a current
individual enrollee or the enrollee's personal representative.\162\
Starting with plan years beginning on or after January 1, 2021,
impacted payers, including individual market QHP issuers on the FFEs,
have been required to make available any claims and encounter data and
all data classes and data elements included in a content standard in 45
CFR 170.213 (USCDI)\163\ with a date of service on or after January 1,
2016.\164\ Those data must be made available no later than 1 business
day after the claim is processed or the data are received by the
individual market QHP issuers on the FFEs.\165\
---------------------------------------------------------------------------
\162\ See 45 CFR 156.221(a).
\163\ See 45 CFR 156.221(b)(1)(iii).
\164\ See 45 CFR 156.221(i)(1).
\165\ See 45 CFR 156.221(b)(1)(iii).
---------------------------------------------------------------------------
Per the 2024 CMS Interoperability and Prior Authorization final
rule, impacted payers would be required to make available through the
Patient Access API certain data about prior authorizations for non-drug
items and services that they maintain, beginning in 2027.\166\ The
required prior authorization information includes the prior
authorization status; the date the prior authorization was approved or
denied; the date or circumstance under which the prior authorization
ends; the non-drug items and services approved; if denied, a specific
reason why the request was denied; and related structured
administrative and clinical documentation submitted by a provider.\167\
That prior authorization information must be accessible no later than 1
business day after the payer receives a prior authorization request,
must be updated no later than 1 business day after any status change,
[[Page 19951]]
and must continue to be accessible for the duration that the
authorization is active and at least 1 year after the prior
authorization's last status change.\168\
---------------------------------------------------------------------------
\166\ See 45 CFR 156.221(b)(1)(iv).
\167\ See 45 CFR 156.221(b)(1)(iv)(A).
\168\ See 45 CFR 156.221(b)(1)(iv)(B).
---------------------------------------------------------------------------
To inform and assist patients who want to access their health
information via the Patient Access API, the 2020 CMS Interoperability
and Patient Access final rule also requires impacted payers to provide,
in an easily accessible location on their public websites and through
other appropriate mechanisms that they ordinarily use to communicate
with current and former enrollees, educational resources in non-
technical, simple, and easy-to-understand language. These resources
must explain at a minimum: (1) general information on steps the
individual may consider taking to help protect the privacy and security
of their health information, including factors to consider in selecting
an app including secondary uses of data, and the importance of
understanding the security and privacy practices of any app to which
they would entrust their health information; and (2) an overview of
which types of organizations or individuals are and are not likely to
be HIPAA covered entities, the oversight responsibilities of the Office
for Civil Rights (OCR) and the Federal Trade Commission (FTC), and how
to submit a complaint to those entities.\169\
---------------------------------------------------------------------------
\169\ See 45 CFR 156.221(g).
---------------------------------------------------------------------------
In the 2024 CMS Interoperability and Prior Authorization final
rule, we also finalized a requirement that, beginning in 2026, impacted
payers, including individual market QHP issuers on the FFEs, must
annually report Patient Access API metrics to CMS in the form of
aggregated, de-identified data. Specifically, individual market QHP
issuers on the FFEs must report at the issuer level 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. The 2024 CMS Interoperability and Prior
Authorization final rule requires individual market QHP issuers on the
FFEs to report the previous calendar year's metrics to CMS by March 31
following any year that they offer an individual market QHP on the
FFEs.\170\
---------------------------------------------------------------------------
\170\ See 45 CFR 156.221(f).
---------------------------------------------------------------------------
We are now proposing to apply each of these requirements to small
group market QHP issuers on the FF-SHOPs to report data from plan years
beginning on or after January 1, 2028, with reporting deadlines
beginning in 2029.
For reporting on Patient Access API usage, we are proposing to
require small group market QHP issuers on the FF-SHOPs to annually
report the metrics in 45 CFR 156.221(f) at the issuer level in the form
and manner and within the timeframes specified by the Secretary. That
would allow flexibility for CMS to include API usage metrics reporting
within specific deadlines set for the QHP certification process, which
in practice is generally the final deadline for the QHP certification
process that takes place the following year.\171\ We are proposing to
apply this requirement to small group market QHP issuers on the FF-
SHOPs for plan years beginning on or after January 1, 2028, following
each plan year that the QHP issuer offers a small group market QHP on
the FF-SHOP. For example, QHP issuers on the FF-SHOPs would be required
to submit metrics from plan years in 2028 as part of the QHP
certification process during 2029 for plan years in 2030. This is
consistent with our proposal to modify the Patient Access API usage
reporting deadline from an annual March 31 date, as further discussed
in section II.F.2.b. of this proposed rule. We believe it is also
appropriate to align the reporting deadline for small group market QHP
issuers on the FF-SHOPs with the annual QHP certification process for
the reasons discussed in section II.F.2.b., and so that issuers do not
have to adhere to different sets of deadlines for small group market
QHPs on the FF-SHOPs and individual market QHPs on the FFEs, which
could cause administrative burden.
---------------------------------------------------------------------------
\171\ Information about QHP certification, including deadlines
can be found at https://www.qhpcertification.cms.gov/QHP/aboutthemarketplace/Timeline.
---------------------------------------------------------------------------
In summary, we request comment on our proposal to apply the
policies and their compliance dates described previously, and in the
CFR citations listed in Table 7, to small group market QHP issuers on
the FF-SHOPs.
4. Provider Access API
a. Background
While the Patient Access API was a significant first step toward
sharing individual patient health information with providers, in the
2024 CMS Interoperability and Prior Authorization final rule we
explained our belief that it would benefit patients if payers were
required to make patient data directly available to providers via an
API that is conformant with certain FHIR standards. In the normal
course of business, many providers already maintain EHRs and share data
for a variety of purposes authorized by the patient and/or existing
law. Therefore, in the 2024 CMS Interoperability and Prior
Authorization final rule, we required impacted payers to implement and
maintain a FHIR API that makes patient data available to providers who
have a contractual relationship with the payer and a treatment
relationship with the patient.\172\ The Provider Access API has the
potential to allow payers to build upon their existing systems and
processes to enhance access to patient data, while continuing to
protect patient privacy and data security (89 FR 8787).
---------------------------------------------------------------------------
\172\ See 45 CFR 156.222(a)(1).
---------------------------------------------------------------------------
b. Proposals
In the 2024 CMS Interoperability and Prior Authorization final
rule, we finalized a policy that, beginning in 2027, impacted payers,
including individual market QHP issuers on the FFEs, must implement and
maintain a Provider Access API to make available patient data upon
request from an in-network provider if all the following conditions are
met: (1) the payer authenticates the identity of the provider that
requests access and attributes the patient to the provider under the
required attribution process; (2) the patient does not opt out of the
Provider Access API; and (3) disclosure of the data is not prohibited
by law. Individual market QHP issuers on the FFEs must make those data
available no later than 1 business day after receiving a request from
such a provider.\173\
---------------------------------------------------------------------------
\173\ See 45 CFR 156.222(a)(2).
---------------------------------------------------------------------------
The data that impacted payers must make available via the Provider
Access API include claims and encounter data (excluding provider
remittances and patient cost-sharing information), all data classes and
data elements included in a content standard in 45 CFR 170.213 (USCDI),
and certain information about prior authorizations that the payer
maintains with a date of service after January 1, 2016. The required
prior authorization information includes the prior authorization
status; the date the prior authorization was approved or denied; the
date or circumstance under which the prior authorization ends; the non-
drug items and services approved; if denied, a specific reason why the
request was denied; and related structured administrative and clinical
documentation submitted by a provider. That prior authorization
information must be accessible no later than 1 business day after the
individual market QHP issuer on the FFE receives a prior authorization
request, must be updated no later than 1 business day after any
[[Page 19952]]
status change, and must continue to be accessible for the duration that
the authorization is active and at least 1 year after the prior
authorization's last status change.\174\
---------------------------------------------------------------------------
\174\ See 45 CFR 156.222(a)(2).
---------------------------------------------------------------------------
In the 2024 CMS Interoperability and Prior Authorization final
rule, we finalized a requirement that impacted payers, including
individual market QHP issuers on the FFEs, beginning in 2027, must
establish and maintain an attribution process to associate patients
with their in-network providers to ensure that the payer only sends a
patient's data to providers who have a treatment relationship with that
patient.\175\ We also finalized a requirement for impacted payers,
including individual market QHP issuers on the FFEs, to provide on
their website and through other appropriate provider communications,
information in plain language explaining the process for requesting
patient data using the Provider Access API. The resources must include
information about how to use the payer's attribution process to
associate patients with their providers.\176\
---------------------------------------------------------------------------
\175\ See 45 CFR 156.222(a)(3).
\176\ See 45 CFR 156.222(a)(5).
---------------------------------------------------------------------------
In the 2024 CMS Interoperability and Prior Authorization final
rule, we finalized a policy that impacted payers, including individual
market QHP issuers on the FFEs, beginning in plan years that start on
or after January 1, 2027, must establish and maintain a process for
patients to opt out of data exchange via the Provider Access API and
that allows patients to change their permission at any time.\177\ This
process must be made available to enrollees before the first date on
which the payer makes their information available via the Provider
Access API, and at any time during their enrollment with the
payer.\178\ Impacted payers, including individual market QHP issuers on
the FFEs, are also required to provide educational resources in plain
language to their patients about the Provider Access API.\179\ Those
resources must include information about the benefits of API data
exchange with providers; patients' opt out rights; and instructions for
both opting out of data exchange and for subsequently opting in, should
patients choose to do so.\180\ Impacted payers must make this
information available to patients before the first date on which the
payer makes their information available via the Provider Access API, no
later than 1 week after the start of coverage, and at least
annually.181 182 These resources must also be available in
an easily accessible location on payers' public websites (89 FR 8817-
8818).\183\
---------------------------------------------------------------------------
\177\ See 45 CFR 156.222(a)(4)(i).
\178\ See 45 CFR 156.222(a)(4)(i).
\179\ See 45 CFR 156.222(a)(4)(ii).
\180\ See 45 CFR 156.222(a)(4)(ii).
\181\ As discussed in the 2024 CMS Interoperability and Prior
Authorization final rule, where coverage starts prospectively, the
deadline would be based on the coverage start date (also known as
the coverage effective date). In the case of retroactive coverage,
to avoid a deadline in the past, the deadline for the payer to
provide the required information about the Payer-to-Payer API,
request identifying information about previous/concurrent payer(s),
and an opt in would be based on the date that the payer gets patient
information and makes the patient's coverage effective (89 FR 8833).
\182\ See 45 CFR 156.222(a)(4)(ii).
\183\ See 45 CFR 156.222(a)(4)(ii)(D).
---------------------------------------------------------------------------
We are now proposing to apply each of these requirements to small
group market QHP issuers on the FF-SHOPs for plan years beginning on or
after January 1, 2028. We believe that this proposal's compliance date
provides sufficient time for those issuers to incorporate their small
group market QHPs on the FF-SHOPs into their previous API
implementation for individual market QHPs on the FFEs given that small
group market QHP issuers on the FF-SHOPs also offer individual market
QHPs on the FFEs. However, we solicit comment on whether this is the
case.
In summary, we request comment on our proposal to apply the
policies and their compliance dates described previously, and in the
CFR citations listed in Table 7, to small group market QHP issuers on
the FF-SHOPs.
5. Payer-To-Payer API
a. Background
In addition to sharing data with their providers, having a
patient's data follow them when they change payers, or shared when they
have health insurance coverage through multiple payers, can have a
multitude of benefits for patient care. For example, a payer receiving
data when a new patient enrolls can better support the patient through
care coordination related to a chronic condition or ongoing treatment
needs. If necessary, patient data can give payers the information they
need to assign a case manager or help the patient find providers in
their new network. Data exchange among payers--specifically, sending
patient data from a patient's previous payer to their new one--is a
powerful way to ensure that data follows patients through the health
care system and improves care continuity, and helps patients to
maintain access to their record over time. In the 2024 CMS
Interoperability and Prior Authorization final rule, we required
impacted payers, including individual market QHP issuers on the FFEs,
to build a Payer-to-Payer API, with certain standards that would
facilitate patient data exchange at the start of coverage and between
concurrent payers.\184\
---------------------------------------------------------------------------
\184\ See 45 CFR 156.222(b).
---------------------------------------------------------------------------
b. Proposals
In the 2024 CMS Interoperability and Prior Authorization final
rule, we finalized a policy that, for plan years beginning on or after
January 1, 2027, individual market QHP issuers on the FFEs must
implement and maintain a Payer-to-Payer API to exchange patient health
information when an enrollee changes payers or has concurrent coverage
with two or more payers if the following conditions are met: (1) the
payer that requests access has its identity authenticated and includes
an attestation with the request that the patient is enrolled with the
payer and has opted into the data exchange; and (2) the exchange is not
prohibited by law. Impacted payers, including individual market QHP
issuers on the FFEs, must make those data available no later than 1
business day after receiving a request from another payer that meets
those requirements.\185\
---------------------------------------------------------------------------
\185\ See 45 CFR 156.222(b)(5).
---------------------------------------------------------------------------
The data that impacted payers must make available via the Payer-to-
Payer API include claims and encounter data (excluding provider
remittances and patient cost-sharing information), all data classes and
data elements included in a content standard in 45 CFR 170.213 (USCDI),
and certain information about prior authorizations that the payer
maintains with a date of service within 5 years of the request. The
required prior authorization information does not include denied prior
authorization requests. It does include the prior authorization status,
the date the prior authorization was approved, the date or circumstance
under which the prior authorization ends, the non-drug items and
services approved, and related structured and unstructured
administrative and clinical documentation submitted by a provider. This
prior authorization information must be accessible no later than 1
business day after the impacted payer receives a prior authorization
request, must be updated no later than 1 business day after any status
change, and must continue to be accessible for the duration that the
authorization is active and at least 1 year after the prior
authorization's last status change.\186\
---------------------------------------------------------------------------
\186\ See 45 CFR 156.222(b)(4).
---------------------------------------------------------------------------
In the 2024 CMS Interoperability and Prior Authorization final
rule, we also
[[Page 19953]]
finalized requirements that, for plan years beginning on or after
January 1, 2027, impacted payers, including individual market QHP
issuers on the FFEs, must establish and maintain processes to request
that an enrollee opt into the payer to payer data exchange and submit
information about their previous and concurrent payers.\187\ Those
processes must be in place for current enrollees by the compliance date
of plan years beginning on or after January 1, 2027, and then, for new
enrollees, no later than 1 week after the coverage start date, or, if
coverage has a retroactive start date, no later than 1 week after the
coverage is effectuated (89 FR 8855).\188\ In addition, enrollees must
be permitted to change their preference at any time.\189\ If an
enrollee does not respond or additional information is necessary, the
payer must make reasonable efforts to engage with the enrollee to
collect this information.\190\ By that compliance date, impacted
payers, including individual market QHP issuers on the FFEs, are also
required to provide educational resources in plain language to their
patients about the Payer-to-Payer API.\191\ Those resources must
include the benefits of Payer-to-Payer API data exchange, their ability
to opt in or withdraw that permission, and instructions for doing
so.\192\ Impacted payers must make this information available to
patients when requesting an enrollee's permission for Payer-to-Payer
API data exchange and at least annually thereafter.\193\ These
resources must also be available in an easily accessible location on
payers' public websites.\194\
---------------------------------------------------------------------------
\187\ See 45 CFR 156.222(b)(2).
\188\ See 45 CFR 156.222(b).
\189\ See 45 CFR 156.222(b)(2).
\190\ See 45 CFR 156.222(b)(2)(ii).
\191\ See 45 CFR 156.222(b)(7).
\192\ See 45 CFR 156.222(b)(7).
\193\ See 45 CFR 156.222(b)(7)(i)-(ii).
\194\ See 45 CFR 156.222(b)(7)(iii).
---------------------------------------------------------------------------
If an enrollee opts in and provides sufficient information about
their previous or concurrent payers, then impacted payers, including
individual market QHP issuers on the FFEs, must request the specified
data from those payers no later than 1 week after they have sufficient
identifying information about previous or concurrent payers and the
enrollee has opted in.\195\ In addition, at an enrollee's request,
payers must make the same request within 1 week.\196\ Any data received
in response to such a request must be incorporated into the payer's
records about the enrollee.\197\ In addition, if an enrollee has
concurrent payers, the payer must request data from all known
concurrent payers at least quarterly and must respond to such a request
from other concurrent payers within 1 business day.\198\
---------------------------------------------------------------------------
\195\ See 45 CFR 156.222(b)(4)(iv)(A). In the 2024 CMS
Interoperability and Prior Authorization final rule, in which this
requirement was finalized for impacted payers including individual
market QHP issuers on the FFEs, CMS noted that ``sufficient
information'' refers to information about patients' previous/
concurrent payer(s) that would allow them [the payer] to identify
and request data from those other payers. CMS left the process of
gathering this information open for payers to implement in the least
burdensome, most practical way, and noted payers often have
established points of contact and existing processes that can apply
here; for example, that they use to identify concurrent payers to
facilitate coordination of coverage and Medicare Secondary Payer/
Third Party Liability administration (89 FR 8834-8835).
\196\ See 45 CFR 156.222(b)(4)(iv)(B).
\197\ See 45 CFR 156.222(b)(4)(v).
\198\ See 45 CFR 156.222(b)(6).
---------------------------------------------------------------------------
We are now proposing to apply each of these requirements to small
group market QHP issuers on the FF-SHOPs for plan years beginning on or
after January 1, 2028. We believe that this proposal's compliance date
provides sufficient time for those issuers to incorporate their small
group market QHPs on the FF-SHOPs into their previous API
implementation for individual market QHPs on the FFEs given that small
group market QHP issuers on the FF-SHOPs also offer individual market
QHPs on the FFEs. However, we solicit comment on whether this is the
case.
In summary, we request comment on our proposal to apply the
policies and their compliance dates described previously, and in the
CFR citations listed in Table 7, to small group market QHP issuers on
the FF-SHOPs.
6. Prior Authorization API and Prior Authorization Process
a. Background
In the 2024 CMS Interoperability and Prior Authorization final
rule, we finalized a requirement for impacted payers, including
individual market QHP issuers on the FFEs, to implement and maintain a
Prior Authorization API to improve the prior authorization process
between payers and providers for non-drug items and services.\199\ This
Prior Authorization API would streamline the prior authorization
process for providers and for office staff who support the prior
authorization process by automating certain prior authorization tasks,
thereby mitigating some of the obstacles of the existing prior
authorization process and expediting approval of needed care or
explaining why a submitted request is not sufficient. The API would
also allow a provider to query the payer's system to determine whether
a prior authorization was required for certain non-drug items and
services and identify documentation requirements. It would automate the
compilation of necessary data for populating the electronic prior
authorization request and enable payers to provide the status of the
prior authorization decision, including whether the request has been
approved or denied. The 2024 CMS Interoperability and Prior
Authorization final rule also included requirements that payers include
a specific reason for denial of a prior authorization request in their
responses to providers,\200\ and publicly report certain prior
authorization metrics.\201\
---------------------------------------------------------------------------
\199\ See 45 CFR 156.223(b).
\200\ See 45 CFR 156.223(a).
\201\ See 45 CFR 156.223(c).
---------------------------------------------------------------------------
The 2022 CMS Interoperability and Prior Authorization proposed rule
and the 2024 CMS Interoperability and Prior Authorization final rule
both discussed the current burden associated with prior authorization
processes and explained how making the prior authorization process
electronic would reduce the time and burden, expediting patients'
access to care and allowing providers to put time back into direct
patient care (87 FR 76286 and 89 FR 8862). Requiring all QHP issuers on
the FFEs, including small group market QHP issuers on the FF-SHOPs, to
adopt electronic prior authorization processes for non-drug items and
services would provide these benefits to more patients, and potentially
help more providers and administrative staff to mitigate burnout.
Including small group market QHP issuers on the FF-SHOPs in
requirements to publicly report certain prior authorization metrics and
to provide a reason for denial of prior authorization in responses to
providers would improve understanding of prior authorization processes'
impact on more enrollees and help ensure transparency for more prior
authorization requests.
The 2024 CMS Interoperability and Prior Authorization final rule
also required impacted payers other than individual market QHP issuers
on the FFEs (MA organizations, state Medicaid and CHIP FFS programs,
Medicaid managed care plans, and CHIP managed care entities), to
respond to prior authorization requests within shorter timeframes than
they were previously subject to (89 FR 8897). We are proposing to apply
these requirements, and additional requirements related to drug prior
authorization, to all QHP issuers on the FFEs, including individual
market QHP issuers on the FFEs and small group market QHP
[[Page 19954]]
issuers on the FF-SHOPs, in this rule. For discussion of those
proposals please see section II.C.3. of this proposed rule.
b. Proposals
In the 2024 CMS Interoperability and Prior Authorization final
rule, we finalized a requirement for individual market QHP issuers on
the FFEs to implement and maintain a Prior Authorization API to improve
the prior authorization process between payers and providers for non-
drug items and services.\202\ The purpose of the API is to streamline
the process and ensure that payers use technology to provide more
useful information about when and how to obtain a prior authorization
and the status of an approved or denied prior authorization (89 FR
8897).
---------------------------------------------------------------------------
\202\ See 45 CFR 156.223(b).
---------------------------------------------------------------------------
We finalized a policy that, for plan years beginning on or after
January 1, 2027, individual market QHP issuers on the FFEs must
implement and maintain a Prior Authorization API that--(1) is populated
with the payer's list of non-drug items and services that require prior
authorization; (2) can identify all documentation required for approval
of any non-drug items or services that require prior authorization; (3)
supports a HIPAA-compliant prior authorization request and response;
and (4) communicates whether the payer approves the prior authorization
request (and the date or circumstance under which the authorization
ends), denies the prior authorization request (with a specific reason),
or requests more information.\203\
---------------------------------------------------------------------------
\203\ See 45 CFR 156.223(b).
---------------------------------------------------------------------------
In addition, we finalized two process requirements for impacted
payers, including individual market QHP issuers on the FFEs, to improve
the prior authorization process generally. We finalized a policy that
beginning January 1, 2026, if an impacted payer denies a prior
authorization request (excluding a request for coverage of drugs as
defined for QHPs on the FFEs in 45 CFR 156.221(b)(1)(v)), the response
to the provider must include a specific reason for the denial,
regardless of the method used to communicate that information.\204\
---------------------------------------------------------------------------
\204\ See 45 CFR 156.223(a).
---------------------------------------------------------------------------
We also finalized a requirement that beginning in 2026, following
each year it offers an individual market QHP on the FFEs, an individual
market QHP issuer on the FFE must report prior authorization data,
excluding data on drugs as defined in 45 CFR 156.221(b)(1)(v), at the
issuer level by March 31. The individual market QHP issuer on the FFE
must make the following data from the previous calendar year publicly
accessible by posting them on its website:
A list of all non-drug items and services that require
prior authorization.
The percentage of standard prior authorization requests
that were approved, aggregated for all non-drug items and services.
The percentage of standard prior authorization requests
that were denied, aggregated for all non-drug items and services.
The percentage of standard prior authorization requests
that were approved after appeal, aggregated for all non-drug items and
services.
The percentage of prior authorization requests for which
the timeframe for review was extended, and the request was approved,
aggregated for all non-drug items and services.
The percentage of expedited prior authorization requests
that were approved, aggregated for all non-drug items and services.
The percentage of expedited prior authorization requests
that were denied, aggregated for all non-drug items and services.
The average and median time that elapsed between the
submission of a request and a determination by the individual market
QHP issuer on the FFE, for standard prior authorizations, aggregated
for all non-drug items and services.
The average and median time that elapsed between the
submission of a request and a decision by the individual market QHP
issuer on the FFE for expedited prior authorizations, aggregated for
all non-drug items and services.\205\
---------------------------------------------------------------------------
\205\ See 45 CFR 156.223(c).
---------------------------------------------------------------------------
We are now proposing to apply each of these requirements to small
group market QHP issuers on the FF-SHOPs. Specifically, we propose to
amend the requirements in 45 CFR 156.223(a) to respond to providers
with a reason for denial and in 45 CFR 156.223(b) to implement and
maintain a Prior Authorization API to include small group market QHP
issuers on the FF-SHOPs with a compliance date of October 1, 2027. In
addition, we propose to amend the requirement in 45 CFR 156.223(c) to
publicly report prior authorization metrics to apply it to small group
market QHP issuers on the FF-SHOPs beginning in 2028 for calendar year
2027 data. Given that those issuers have met or are working on meeting
these proposed requirements for their individual market QHPs on the
FFEs, we believe that the proposed compliance dates provide sufficient
time to extend their technology solutions and business processes to
their small group market QHPs on the FF-SHOPs. However, we solicit
comment on whether this is the case.
In summary, we request comment on our proposal to apply the
policies and their compliance dates described previously, and in the
CFR citations listed in Table 7, to small group market QHP issuers on
the FF-SHOPs.
7. Exceptions
a. Background
The 2020 CMS Interoperability and Patient Access final rule and the
2024 CMS Interoperability and Prior Authorization final rule finalized
an exceptions process for individual market QHP issuers on the FFEs
that are not able to implement the Patient Access API. An individual
market QHP issuer on the FFE can apply for an exception for a
particular plan year by submitting a narrative justification as part of
its QHP certification application that describes the reasons why it
cannot reasonably satisfy the requirements for the applicable plan
year, the effect of non-compliance upon providers and enrollees, the
current or proposed means of providing the required information to
providers or other payers, and solutions and a timeline to achieve
compliance with the requirements.\206\
---------------------------------------------------------------------------
\206\ See 156.221(h) for the Patient Access API, 45 CFR
156.222(c) for the Provider Access and Payer-to-Payer APIs, and 45
CFR 156.223(d) for the Prior Authorization API.
---------------------------------------------------------------------------
As discussed in the 2024 CMS Interoperability and Prior
Authorization final rule, we believe that certifying only health plans
that implement these APIs is generally in the interests of enrollees
(89 FR 8786 and 8820). However, as also discussed in that final rule,
while some individual market QHP issuers on the FFEs are in a position
to implement the updates that the rule requires, a wide range of
issuers participate in the FFEs and vary in terms of available
resources to adopt these requirements (89 FR 8906). Plan offerings can
also vary by region and even by county, with some areas in the FFEs
having more limited plan offerings than others. Therefore, this
exceptions process exists as a safeguard to prevent potential enrollees
from going without access to QHP coverage because an issuer is unable
to implement these APIs.
b. Proposals
We propose to apply the same exceptions process to the proposed
requirements for small group market
[[Page 19955]]
QHP issuers on the FF-SHOPs as currently applies to individual market
QHP issuers on the FFEs per 45 CFR 156.221(h), including as cross
referenced in 45 CFR 156.222(c) and 45 CFR 156.223(d). As we discussed
in the 2024 CMS Interoperability and Prior Authorization final rule, we
anticipate that the volume of requests for exceptions should be low
based on our experience with individual market QHP issuers on the FFEs,
among which exception requests are uncommon, and a number of requests
have specified that the issuer intends to comply within the upcoming
plan year even though they may not be able to do so by January 1 of the
upcoming year (89 FR 8906). As also discussed in the 2020 CMS
Interoperability and Patient Access final rule, with regard to
individual market QHPs on the FFEs, we believe that it is important to
provide the FFEs with the option to waive this requirement on a limited
basis, for example, if not certifying the issuer's QHP or QHPs would
result in consumers having few or no plan options in certain areas (85
FR 25552). We believe that this rationale also applies to small group
market QHPs on the FF-SHOPs--that is, that the FF-SHOPs should have the
option to consider coverage availability for qualified employers and
their employees as a factor when determining whether to certify an FF-
SHOP plan notwithstanding its failure to comply with requirements for
the Patient Access API in 45 CFR 156.221, the Provider and Payer-to-
Payer APIs in 45 CFR 156.222(a) and (b), or the Prior Authorization API
in 45 CFR 156.223(b).
In summary, we request comment on our proposal to apply the
policies and their compliance dates described previously, and in the
CFR citations listed in Table 7, to small group market QHP issuers on
the FF-SHOPs.
BILLING CODE 4150-28-P
[[Page 19956]]
[GRAPHIC] [TIFF OMITTED] TP14AP26.286
[[Page 19957]]
BILLING CODE 4150-28-C
E. Reporting Payer API Endpoints and Associated Information for CMS To
Publish
1. API Endpoints
In the 2020 CMS Interoperability and Patient Access final rule, we
finalized a requirement that impacted payers must implement and
maintain Patient Access and Provider Directory APIs (85 FR 25513). In
the 2024 CMS Interoperability and Prior Authorization final rule, we
finalized requirements that impacted payers must also implement and
maintain Provider Access, Payer-to-Payer, and Prior Authorization APIs
(89 FR 8759). During those rulemakings, we received numerous public
comments that emphasized the importance of a centralized location to
discover payers' API endpoints, which would realize the full potential
of these interoperability APIs (85 FR 25562 and 89 FR 8767).
An API's endpoint is the digital location, often a URL or IP
address, that is set up to accept secure queries to the API. Developers
need to know an API's endpoint to configure their apps to interact with
the API. Without properly structured and functioning endpoints, an API
will not work as intended. APIs can be set up with multiple endpoints,
each used for specific data or purposes, or a single endpoint that
offers different data depending on how it is queried.
We have received public feedback that a centralized listing of
impacted payers' API endpoints would significantly improve the ability
of payers, providers, patients, and developers to use the
interoperability APIs (89 FR 8767). Various entities within the health
care system need to have information about payers' API endpoints to
achieve the envisioned ecosystem of data exchange via the
interoperability APIs. For the Patient Access API, app developers must
connect to payers' API endpoints for patients to access their data
maintained by that payer. For the Provider Access API, EHR developers
must configure providers' EHRs or other health IT to query payers' API
endpoints to retrieve patient information maintained by that payer. To
use the Payer-to-Payer API, payers must locate patients' previous or
concurrent payers' API endpoints in order to send a request for patient
data, as required in the 2024 CMS Interoperability and Prior
Authorization final rule. For the Prior Authorization API, providers
must be able to find the correct payer API endpoint to submit
electronic prior authorization requests. Similarly, for the Provider
Directory API, third-party developers and health care entities need
discoverable endpoints to create innovative apps that help patients
find in-network providers and enable care coordination between
providers, making centralized endpoint reporting essential for
realizing the full potential of publicly accessible provider directory
information.
Stakeholder feedback from our 2019 CMS Interoperability and Patient
Access proposed rule, 2020 CMS Interoperability and Patient Access
final rule, 2022 CMS Interoperability and Prior Authorization proposed
rule, and 2024 CMS Interoperability and Prior Authorization final rule
demonstrates that endpoint discovery remains a significant
implementation challenge, with multiple commenters requesting a
centralized directory and noting that third-party apps currently
struggle with implementation barriers when working with payers. Finding
API endpoints individually in myriad locations could be a significant
task for app developers, EHR developers, providers, and payers, because
without specific requirements, those endpoints are unlikely to be
listed or discoverable in a standardized manner. While payers may have
some incentive to make their endpoints discoverable, market dynamics
may create barriers to voluntary standardization. For example,
individual payers may invest resources into comprehensive endpoint
discovery while competitors benefit without making similar investments
or competitive considerations, which could lead some payers to maintain
integration complexity. As part of our oversight and compliance
process, CMS has engaged in exercises to discover endpoints from a
sampling of impacted payers. Our own work was heavily manual, and we
have experienced first-hand that endpoints are listed in a wide variety
of locations and formats, including PDFs, from which automated data
retrieval is particularly difficult. Instead, we believe it would help
everyone in the health care industry for CMS to collect API endpoints
and make them publicly available in a standardized format that can
easily be accessed and used by app developers, EHR developers,
providers, and payers.
Furthermore, if payers' API endpoints have to be discovered
individually by developers, or entities that want to use the API, the
endpoint is more likely to be hard coded into the software systems used
by those developers or entities. Individual endpoint discovery is
likely to create a manual, resource-intensive process where developers
must research each payer's documentation, extract endpoint information,
and integrate it directly into their code. The alternative--building a
dynamic endpoint discovery system--requires industry-wide coordination
and significant development resources that many organizations cannot
justify, making individual developer hard coding the more practical,
albeit less flexible, solution. Once endpoints are hard coded,
maintenance becomes increasingly burdensome, as developers must
manually monitor hundreds of payers for changes, modify code, test, and
redeploy systems for each endpoint update. Developers may not realize
that an endpoint has changed until they receive reports that their
software is no longer successfully connecting to an API, at which point
they would have to push software updates. This process could take days
or weeks, during which API integrations may fail and end users may
experience service disruptions. This creates operational challenges for
all entities that depend on API access; entities may need to wait for
software updates to restore connectivity and access accurate data,
potentially causing delays in patient care, data exchange, and
administrative processes. Providers using EHRs, health systems relying
on integration platforms, and payers using third-party software
solutions would all experience service interruptions when hard-coded
endpoints become outdated, regardless of whether they maintain in-house
development capabilities.
Instead, a centralized registry could create greater flexibility
and allow for more timely endpoint data availability. Software could
make a call to that registry and, with appropriate identifying data,
find the latest information about a payer's API endpoint. The software
could then automatically use that information to call the payer's API
without manual intervention by the developer or entity making the
request. Such a process could be implemented into health apps (for the
Patient Access and Provider Directory APIs), EHRs or other provider
systems (for the Provider Access, Prior Authorization, and Provider
Directory APIs), and payers' systems (for the Payer-to-Payer API).
Therefore, we are proposing to require, in the CFR citations listed
in Table 8, impacted payers to report to CMS their API endpoints for
each required interoperability API unless the impacted payer is a state
Medicaid or CHIP FFS program that has been granted an extension or a
QHP issuer on the FFEs that has been granted an exception from
implementing any or all of the
[[Page 19958]]
interoperability APIs.\207\ To ensure the standardization of payer
endpoints, we are proposing to require impacted payers to report their
API endpoints as an Endpoint Resource, as defined by an unexpired
version of the Health Level Seven (HL7[supreg]) FHIR[supreg] standard
adopted in 45 CFR 170.215(a). We are proposing that impacted payers
would be required to initially report their API endpoints no later than
60 days after the effective date of a final rule. In future years, we
are proposing that new impacted payers would be required to report this
information no later than 60 days before they begin covering patients
under the applicable CMS program. Thereafter, impacted payers would be
required to report changes to CMS within 1 week of any changes to their
API endpoint(s) and verify every 12 months that there have been no
changes and their data are accurate. API endpoints support time-
sensitive health care operations including prior authorization
requests, care coordination, and patient data access. Outdated
endpoints immediately disrupt these critical functions; the underlying
statutory requirements for timely care, efficient operations, and
patient access cannot be met with stale endpoint information.
Verification every 12 months ensures ongoing accuracy of the
centralized registry, compliance with existing statutory obligations
for current information, and efficient program administration, through
reliable endpoint data.
---------------------------------------------------------------------------
\207\ For the Patient Access API, see 45 CFR 156.221(h) for QHP
issuers on the FFEs. For the Provider Access and Payer-to-Payer
APIs, see 42 CFR 431.61(c)(1)-(2) for state Medicaid FFS programs,
42 CFR 457.731(c)(1) and (2) for state CHIP FFS programs, and 45 CFR
156.222(c) for QHP issuers on the FFEs. For the Prior Authorization
API, see 42 CFR 431.80(c)(1) for state Medicaid FFS programs, 42 CFR
457.732(d)(1) for state CHIP FFS programs, and 45 CFR 156.223(d) for
QHP issuers on the FFEs.
---------------------------------------------------------------------------
2. API Documentation
In the 2020 CMS Interoperability and Patient Access final rule, we
finalized a requirement that impacted payers make the specific business
and technical documentation necessary to interact with their Patient
Access and Provider Directory APIs freely and publicly accessible (85
FR 25542). In the 2024 CMS Interoperability and Prior Authorization
final rule, we extended that requirement to the Provider Access, Payer-
to-Payer, and Prior Authorization APIs (89 FR 8815). We explained that
transparency is necessary for developers to easily obtain the
information needed to develop systems technically compatible with the
payer's API. Transparency is also needed so that developers can
understand how to successfully interact with a payer's API. This
includes how to satisfy any requirements the payer may establish for
verifying a developer's identity and their apps' authenticity.
As explained in the preamble to the 2020 CMS Interoperability and
Patient Access final rule (85 FR 25542), impacted payers must make
publicly accessible documentation necessary to interact with their
APIs. The existing regulations in 42 CFR 422.119(d), 42 CFR 431.60(d),
42 CFR 457.730(d), and 45 CFR 156.221(d) require impacted payers to
make publicly available documentation that includes API syntax,
function names, required and optional parameters, software components
and configurations, and technical requirements for apps to interact
with their APIs. FHIR capability statements are mandatory resources, as
defined by an unexpired version of the FHIR standard adopted in 45 CFR
170.215(a), making them inherently part of this required documentation.
The required authorization and authentication protocols and
implementation details build upon the existing requirement for impacted
payers to use the SMART App Launch IG and OpenID Connect Core--to
implement certain interoperability APIs.\208\ The SMART App Launch IG
is a standards-based framework for secure app connections to health IT
systems, and OpenID Connect Core is an identity verification layer
built on OAuth 2.0. Those existing requirements necessitate public
documentation of authentication protocols. API registration
information, when required by payers, constitutes essential
documentation that falls within the existing requirement in 42 CFR
422.119(d)(3), 42 CFR 431.60(d)(3), 42 CFR 457.730(d)(3), and 45 CFR
156.221(d)(3) to make publicly accessible all applicable technical
requirements and attributes necessary for an app to be registered with
any authorization server(s) deployed in conjunction with the API.
Without registration procedures, developers cannot establish the
necessary access credentials to use the APIs.
---------------------------------------------------------------------------
\208\ See, for instance, cross-references to SMART Launch IG in
45 CFR 170.215(c) and OpenID Connect Core in 45 CFR 170.215(e), for
the Patient Access API in 42 CFR 422.119(c)(1) for MA organizations,
42 CFR 431.60(c)(1) for state Medicaid FFS programs, through cross
reference to 42 CFR 431.60 in 42 CFR 438.242(b)(5) for Medicaid
managed care plans, 42 CFR 457.730(c)(1) for CHIP FFS programs,
through cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for
CHIP managed care entities, and 45 CFR 156.221(c)(1) for individual
market QHP issuers on the FFEs.
---------------------------------------------------------------------------
To ensure that the business and technical documentation is publicly
available and easily discoverable, we are proposing to require impacted
payers to report to CMS the URLs for specific required documentation,
at the CFR citations listed in Table 8.\209\ CMS would then publish
these URLs for centralized access. CMS proposes that the required URLs
must include, as applicable: a direct URL to the FHIR capability
statement, as defined by an unexpired version of the FHIR standard
adopted in 45 CFR 170.215(a); and one or more URLs for a publicly
accessible website with authorization and authentication protocols and
implementation details; and API registration information.\210\ Each of
those items are elements of the existing standards and documentation
requirements that already must be publicly available.\211\
---------------------------------------------------------------------------
\209\ For the Patient Access API, see 45 CFR 156.221(h) for QHP
issuers on the FFEs. For the Provider Access and Payer-to-Payer
APIs, see 42 CFR 431.61(c)(1)-(2) for state Medicaid FFS programs,
42 CFR 457.731(c)(1) and (2) for state CHIP FFS programs, and 45 CFR
156.222(c) for QHP issuers on the FFEs. For the Prior Authorization
API, see 42 CFR 431.80(c)(1) for state Medicaid FFS programs, 42 CFR
457.732(d)(1) for state CHIP FFS programs, and 45 CFR 156.223(d) for
QHP issuers on the FFEs.
\210\ See 42 CFR 422.119(d) for MA organizations, 42 CFR
431.60(d) for state Medicaid FFS programs, 42 CFR 457.730(d) for
state CHIP FFS programs, through cross reference to 42 CFR 431.60 in
42 CFR 438.242(b)(5) for Medicaid managed care plans, through cross
reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed
care entities, and 45 CFR 156.221(d) for QHP issuers on the FFEs.
\211\ See 42 CFR 422.119(d) for MA organizations, 42 CFR
431.60(d) for state Medicaid FFS programs, 42 CFR 457.730(d) for
state CHIP FFS programs, through cross reference to 42 CFR 431.60 in
42 CFR 438.242(b)(5) for Medicaid managed care plans, through cross
reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP managed
care entities, and 45 CFR 156.221(d) for QHP issuers on the FFEs.
---------------------------------------------------------------------------
The proposed URL reporting requirements directly correspond to
existing requirements to make technical documentation publicly
available, as follows:
(1) FHIR Capability Statement--The capability statement can satisfy
the existing requirements to make publicly accessible documentation
that includes API syntax, function names, required and optional
parameters supported and their data types, return variables and their
types/structures, exceptions and exception handling methods and their
returns.\212\ Because capability statements document API implementation
details, functional capabilities, and operational parameters,
[[Page 19959]]
they should serve as a the primary source of technical documentation
necessary to interact with the API.
---------------------------------------------------------------------------
\212\ See 42 CFR 422.119(d)(1) for MA organizations, 42 CFR
431.60(d)(1) for state Medicaid FFS programs, 42 CFR 457.730(d)(1)
for state CHIP FFS programs, through cross reference to 42 CFR
431.60 in 42 CFR 438.242(b)(5) for Medicaid managed care plans,
through cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for
CHIP managed care entities, and 45 CFR 156.221(d)(1) for QHP issuers
on the FFEs.
---------------------------------------------------------------------------
(2) Authorization and Authentication Protocols and Implementation
Details--This documentation should satisfy the existing requirements to
make publicly accessible all applicable technical requirements and
attributes necessary for an app to be registered with any authorization
server(s) deployed in conjunction with the API.\213\ Specific
information about authorization and authentication protocols and
implementation details is essential for developers to ensure that their
software can communicate and exchange information with an API.
---------------------------------------------------------------------------
\213\ See 42 CFR 422.119(d)(3) for MA organizations, 42 CFR
431.60(d)(3) for state Medicaid FFS programs, 42 CFR 457.730(d)(3)
for state CHIP FFS programs, through cross reference to 42 CFR
431.60 in 42 CFR 438.242(b)(5) for Medicaid managed care plans,
through cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for
CHIP managed care entities, and 45 CFR 156.221(d)(3) for QHP issuers
on the FFEs.
---------------------------------------------------------------------------
(3) API Registration Information--This documentation can satisfy
the requirements to make publicly accessible the software components
and configurations an application must use in order to successfully
interact with the API and process its response(s).\214\ Without
registration procedures, developers cannot establish the necessary
access credentials to use the APIs.
---------------------------------------------------------------------------
\214\ See 42 CFR 422.119(d)(2) for MA organizations, 42 CFR
431.60(d)(2) for state Medicaid FFS programs, 42 CFR 457.730(d)(2)
for state CHIP FFS programs, through cross reference to 42 CFR
431.60 in 42 CFR 438.242(b)(5) for Medicaid managed care plans,
through cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for
CHIP managed care entities, and 45 CFR 156.221(d)(2) for QHP issuers
on the FFEs.
---------------------------------------------------------------------------
These three documentation types--capability statements,
authorization and authentication protocols and implementation details,
and API registration information--represent discrete components of the
broader documentation already required under existing regulations. The
proposed URL reporting requirements do not expand the scope of required
documentation but rather add to existing requirements by establishing a
standardized mechanism for verifying compliance and facilitating
discoverable access to required documentation.
The URL reporting proposal is integral to the effectiveness of API
endpoint reporting. API endpoints are only functional when developers
can access the technical documentation needed to integrate with them,
including FHIR capability statements, authorization and authentication
protocols and implementation details, and API registration information.
Without discoverable documentation, centralized endpoint information
provides limited value to the health care ecosystem. Both proposals, to
report API endpoints and documentation URLs, could facilitate patient
access to health information, support care coordination, enable
efficient program administration, and reduce administrative burden on
developers, providers, and payers.
While impacted payers must already make API documentation publicly
available under existing regulations, CMS currently lacks an efficient
mechanism to systematically verify compliance and facilitate
standardized discovery of this documentation across hundreds of payers.
The URL reporting proposal could enable CMS to systematically verify
that required documentation is publicly accessible, monitor ongoing
compliance with existing documentation obligations, and identify
compliance gaps more efficiently than manual discovery processes. This
could transform fragmented compliance into systematic, verifiable
accessibility that serves both regulatory oversight and industry needs.
CMS cannot efficiently gather this information independently because
doing so would require continuous monitoring of hundreds of payer
websites across multiple programs (MA, Medicaid, CHIP, and QHPs on the
FFEs), technical staff to locate and verify documentation across
varying website structures, and ongoing maintenance as payers modify
their websites. Manual discovery by CMS could result in outdated
information, discovery delays, and verification challenges, while
requiring disproportionate resource allocation compared to the benefit
for the industry.
This proposal explicitly addresses registration requirements that
impacted payers must already meet. The proposed URL reporting
requirements are authorized under the same statutory provisions that
support the existing documentation requirements and would enable CMS to
facilitate centralized discovery of documentation that must already be
publicly available under existing regulations.\215\
---------------------------------------------------------------------------
\215\ See sections 1852(d)(1)(A), 1852(g)(1)(A), 1852(h),
1856(b), and 1857(e)(1) of the Act for MA organizations; see
sections 1902(a)(4), 1902(a)(6), 1902(a)(8), 1902(a)(19),
1903(m)(2)(A)(xi), and 1932(d)(1) of the Act for state Medicaid FFS
programs and Medicaid managed care plans; see sections 2101 and 2102
of the Act for state CHIP FFS programs and CHIP managed care
entities; see sections 1311(c) and 1321(a) of the Affordable Care
Act for QHP issuers on the FFEs (42 U.S.C. 18031(c), 18041(a)). See
section II.E.7. of this proposed rule for a detailed discussion of
statutory authorities.
---------------------------------------------------------------------------
Maintaining API technology conformant with an unexpired version of
the FHIR standard adopted in 45 CFR 170.215(a) is a requirement for all
the interoperability APIs; and within that FHIR standard, capability
statements are a mandatory resource. A capability statement documents
how a FHIR API has been implemented, including the particular unexpired
version of the FHIR standard, and which aspects of the standard have
been implemented and how.\216\ The statement can be used to describe
how to interface with the FHIR server and thus can provide a degree of
self-configuration for software clients. For example, a capability
statement could indicate whether the FHIR server allows clients to push
updates to patient information, or which fields are searchable to find
the appropriate patient. Furthermore, a thorough and accurate
capability statement would help impacted payers meet their
documentation requirements.\217\
---------------------------------------------------------------------------
\216\ Health Level Seven International. (2023, March 26).
Resource Capability Statement--Content. Retrieved from https://hl7.org/fhir/capabilitystatement.html.
\217\ See 42 CFR 422.119(d)(1) for MA organizations, 42 CFR
431.60(d)(1) for state Medicaid FFS programs, 42 CFR 457.730(d)(1)
for state CHIP FFS programs, through cross reference to 42 CFR
431.60 in 42 CFR 438.242(b)(5) for Medicaid managed care plans,
through cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for
CHIP managed care entities, and 45 CFR 156.221(d)(1) for QHP issuers
on the FFEs.
---------------------------------------------------------------------------
Because capability statements document API implementation details,
functional capabilities, and operational parameters, they are a primary
source technical documentation that could satisfy the requirement to
make documentation that includes API syntax, function names, required
and optional parameters, software components and configurations, and
technical requirements for apps to interact with their APIs publicly
accessible. Ensuring that direct URLs to capability statements are
readily available for all payers in a centralized location would reduce
developer burden to find each payer's capability statement. Reducing
developer burden--whether for a developer of patient apps, EHRs, or
payer systems--could expedite patient data exchange and lead to more
timely and informed care. We emphasize that we are proposing that
impacted payers would have to provide a direct URL to the capability
statement itself and not to a documentation site that includes the
capability statement. Because the capability statement is a structured
file, we believe it is important that software be able to find it
automatically without additional manual intervention to find
[[Page 19960]]
the file within a site reported by the payer.
In addition, we propose to require impacted payers to report to CMS
a URL or URLs with information about authorization and authentication
protocols and implementation details for their API. That information is
already required to be posted in a publicly accessible location by
impacted payers, but we are now proposing to require impacted payers to
report to CMS the location where they have made it
available.218 219 Specific information about authorization
and authentication protocols and implementation details is essential
for developers to ensure that their software can communicate and
exchange information with an API. Authorization is the process by which
the server gives the requesting client permission to access data.
Authentication protocols are those that a payer uses to verify the
identity of the requesting entity. However, there is no single protocol
for authentication that will address all use cases.\220\ Additionally,
within a single API, implementers may need to utilize more than one
protocol to address specific population and trading partner needs.
Therefore, it is essential that developers know how to design their
software, whether for patients, providers, or payers, to successfully
access the appropriate data.
---------------------------------------------------------------------------
\218\ Authorization and authentication protocols are ``software
components and configurations an application must use in order to
successfully interact with the API'' and are specifically required
to be publicly posted in 42 CFR 422.119(d)(2) for MA organizations,
42 CFR 431.60(d)(2) for state Medicaid FFS programs, 42 CFR
457.730(d)(2) for state CHIP FFS programs, through cross reference
to 42 CFR 431.60 in 42 CFR 438.242(b)(5) for Medicaid managed care
plans, through cross reference to 42 CFR 438.242 in 42 CFR
457.1233(d) for CHIP managed care entities, and 45 CFR 156.221(d)(2)
for QHP issuers on the FFEs.
\219\ Authorization protocols (such as OAuth 2.0 and SMART App
Launch) define the software components and configurations that apps
must implement to obtain permission to access data from the API
server, including authorization clients, token handlers, and
redirect URI configurations. Authentication protocols (such as
OpenID Connect Core) define the software components and
configurations that apps must implement to verify the identity of
the requesting entity, including authentication flows, identity
token processors, and user credential validation modules.
\220\ Health Level Seven International. (2023, March 26). FHIR
Security. Retrieved from https://hl7.org/fhir/security.html#binding.
---------------------------------------------------------------------------
Often, API servers require apps or other software that interact
with an API to be registered with the server and receive a key that
verifies the app or program making the API call (API key).\221\ That
allows the server to identify the app and ensure it has the access
rights required to make the particular API call. API keys are not
intended to fulfill the same security functions as authorization and
authentication protocols for users, but they help payers monitor their
APIs and gather data on usage. Because registration is sometimes
necessary to connect to an API, if the payer requires registration, we
propose to require impacted payers to report to CMS a public URL with
information about how developers can register their apps with the API
server. We are making those proposals in the CFR citations listed in
Table 8. Not all APIs require registration. For example, the 2020 CMS
Interoperability and Patient Access final rule (85 FR 25583 and 25584)
established that provider directory information must be accessible via
an API without requiring authentication. Therefore, payers implementing
Provider Directory APIs would not have API registration information to
report for that API, and the requirement would not apply.
---------------------------------------------------------------------------
\221\ See, for example, the Certified Health IT Product Listing
API maintained by ONC at https://chpl.healthit.gov/#/resources/api
and the ONC Certification (g)(10) Standardized API Test Kit at
https://github.com/onc-healthit/onc-certification-g10-test-kit?tab=readme-ov-file#terminology-prerequisites.
---------------------------------------------------------------------------
We propose that CMS would publish those API endpoints and URLs in a
centralized location for easy discovery by developers. We emphasize
that we are not proposing that impacted payers would be required to
report their supporting documentation itself to CMS. Rather, we are
proposing that impacted payers would be required to report to CMS one
or more public URLs where that documentation can be publicly accessed.
However, we request comment on whether a single URL to a site that
contains the authorization and authentication protocols and
implementation details and API registration information is sufficient,
or whether impacted payers should report a separate URL for each of
these items. In addition, we request comment on whether there are
discrete pieces of information, such as the specific authentication
protocol a payer uses, that we should collect to facilitate faster API
integration with patient health apps, provider EHRs, and payer systems.
We wish to balance the benefits of making as much information available
in a standardized and centralized location against the burden of
reporting.
3. Alternative Proposal--National Directory of Healthcare Providers &
Services Implementation Guide
As an alternative to our primary proposal, the National Directory
of Healthcare Providers & Services (NDH) IG could provide a framework
for payers to report the proposed information.\222\ The NDH IG has been
developed to facilitate and standardize a national directory
infrastructure. The NDH IG provides a framework for standardized
information sharing about providers, health organizations, and related
services, their relationships, and technical connectivity details (for
example, electronic endpoints) in FHIR. Within the NDH IG is an
Endpoint Profile resource that has already been developed with the
resource structure we are proposing for payer endpoint reporting.\223\
The Endpoint Profile within the NDH IG includes several of the data
elements we are proposing here, as well as additional information for
developers. The NDH IG Endpoint Profile includes extensions to document
IG versions, authentication information, trust frameworks, UDAP dynamic
registration, environment type (production/test/development), and more.
While the NDH IG has not been adopted by HHS at this time, it may
provide a simpler method for data submission, as it has been developed
by FAST, an HL7 FHIR accelerator program, using the same FHIR standards
as the other specifications and IGs discussed in this proposed rule.
Tying reporting requirements to an existing FHIR IG may simplify the
process for payers to report the proposed data and developers to use
the data within a potential centralized registry.
---------------------------------------------------------------------------
\222\ Health Level Seven International. (2025, April 10).
National Directory of Healthcare Providers & Services (NDH) IG.
Retrieved from https://hl7.org/fhir/us/ndh/STU1/index.html.
\223\ Health Level Seven International. (2025, April 10).
Resource Profile: NDH Base Endpoint Profile. Retrieved from https://hl7.org/fhir/us/ndh/STU1/StructureDefinition-ndh-Endpoint.html.
---------------------------------------------------------------------------
Under this alternative proposal, we propose to require impacted
payers to report NDH IG Endpoint Profile compliant resources containing
the relevant information for each interoperability API. A single
Endpoint Resource would be sufficient for cases where a single endpoint
manages multiple API types with the same server or service address
(URL), requirements, and other documentation. Under this alternative
proposal, impacted payers would be required to populate all elements
and extensions identified in the profile that are relevant to the
specific interoperability API, including, but not limited to: FHIR IGs
and
[[Page 19961]]
versions, dynamic registration information, trust framework, secure
exchange artifacts, access control mechanisms, payload Multipurpose
internet Mail Extension (MIME) type, and environment type. This
alternative proposal is limited to proposing to require impacted payers
to submit relevant Endpoint Resources that are compliant with the NDH
Endpoint Profile, as opposed to proposing to require full support and
implementation of the NDH IG as a whole.
4. Reporting Timelines
In the 2020 CMS Interoperability and Patient Access final rule, we
finalized compliance dates in 2021 for the Patient Access and the
Provider Directory APIs (except for QHP issuers on the FFEs, which are
not subject to the Provider Directory API requirement) (85 FR 25558 and
25559 and 85 FR 25563 and 25564). Therefore, the information we are
proposing to require impacted payers to report to CMS should already be
publicly available for those two APIs. In the 2024 CMS Interoperability
and Prior Authorization final rule, we established compliance dates in
2027 for impacted payers to implement the Provider Access, Payer-to-
Payer, and Prior Authorization APIs. We believe that it would benefit
payers, providers, and patients to have endpoints publicly available as
soon as possible. Therefore, rather than tying a compliance date to the
beginning of a calendar year, plan year, or rating period, we are
proposing that all impacted payers be required to report the proposed
data to CMS no later than 60 days after the effective date of a final
rule. The proposed information about their own APIs should be readily
available to impacted payers. Therefore, we believe the benefits of
making endpoints publicly available, as discussed here, compel an
expedited reporting process and deadline.
As new payers participate in CMS programs, we propose that they
would be required to report the proposed information to CMS no later
than 60 days before they begin covering patients under the applicable
CMS program. Specifically, that means that a new impacted payer would
be required to report 60 days before January 1 for MA organizations and
state Medicaid and CHIP FFS programs, 60 days before the beginning of a
rating period for Medicaid managed care plans or CHIP managed care
entities, and 60 days before a plan year for QHP issuers on the FFEs,
depending on the type of plan(s) the impacted payer is offering.
After the proposed deadline, we propose that impacted payers would
be required to update the information reported to CMS within 1 week of
any changes. In addition, to ensure that the latest information is
available, we propose that impacted payers would be required to verify
that the reported information is still correct every 12 months from the
date of the last update or verification. We believe that the burden of
reporting API endpoints to CMS would be minimal compared to the burden
on payers to individually locate other payers' API endpoints for the
Payer-to-Payer API. We seek comment on the burden that reporting API
endpoints could place on payers and how CMS can reduce that burden,
either with the information we collect or the method of collection.
Impacted payers could meet the proposed requirements to verify their
information at any time during the year. For instance, we expect that
QHP issuers could report (if a new QHP issuer) or verify every 12
months (if an existing QHP issuer) at the same time they apply for
certification on the FFEs, which could streamline their reporting
requirements and allow CMS to verify that the QHP issuer has met the
conditions for certification.
While only impacted payers would be subject to these proposals, if
finalized, CMS would collect and publish API endpoints and URLs from
any payer that implements interoperability APIs, including those that
are not impacted payers under the CMS interoperability rules. As we
continue to strongly encourage payers not subject to our
interoperability rules to participate in data exchange, according to
the requirements and standards established in those rules, we would
want to facilitate their participation by publishing their API
endpoints and documentation URLs.
5. Publication
While we are not making any proposals as to the specific methods,
formats, or systems that could be used to collect and publish the
proposed information, we seek comment on how CMS could do so in a
manner that would balance the burden on payers with the benefits to
developers, patients, providers, and payers.
6. Summary
In summary, we request comment on our proposals in the CFR
citations listed in Table 8, and specifically on the following:
The proposal to require impacted payers to report all API
endpoints to CMS, in the form of an Endpoint Resource, as defined by an
unexpired version of the FHIR standard adopted in 45 CFR 170.215(a),
including, if multiple, appropriate use cases for each.
The proposal to require impacted payers to report URLs
with the required documentation for each of their interoperability
APIs, as applicable:
++ A direct URL to the API FHIR capability statement.
++ Authorization and authentication protocols and implementation
details.
++ API registration information.
The proposal to require impacted payers to report this
information to CMS no later than 60 days after the effective date of a
final rule.
The proposal to require new impacted payers to report this
information no later than 60 days before they begin covering patients
under the applicable CMS program.
The proposal to require impacted payers to update CMS
within 1 week of any changes to the reported information and verify
their information at least once every 12 months.
The alternative proposal to require impacted payers to
report to CMS all NDH IG Endpoint Profile resources containing the
relevant information for each interoperability API.
In addition, we request comment on the following:
Is the proposal to collect a direct URL for the FHIR
capability statements necessary, or would a payer endpoint be
sufficient to indicate that the capability statement is located at [API
endpoint]/metadata, as is required by the FHIR standard, or is that
data element duplicative?
Whether a single URL to a site that contains the
authorization and authentication protocols and implementation details,
and API registration information is sufficient, or whether impacted
payers should report separate direct URLs for each of these items?
Whether there are discrete pieces of information, such as
the specific authentication protocol a payer uses, that we should
collect to facilitate faster API integration with patient health apps,
provider EHRs, and payer systems?
Would aligning the reporting requirements with the NDH
Endpoint Profile resource reduce payer burden to report the proposed
information and/or developer burden to use a centralized registry?
If the alternative proposal is finalized, would it negate
the need for impacted payers to report URLs to documentation related to
authorization and authentication protocols and implementation details
and API registration information?
[[Page 19962]]
The burden that reporting API endpoints could place on
payers and how CMS can reduce that burden, either with the information
we collect or the method of collection.
How CMS could collect and publish the reported information
in a manner that would balance the burden on payers with the benefits
to developers, patients, providers, and payers. For example:
++ Would a machine-readable file on CMS's website be sufficient?
++ What would the benefits be of a FHIR-enabled registry, either
for reporting or publishing? Would using FHIR standards allow a more
streamlined and automated reporting process for payers? Would it allow
greater flexibility for third-party app developers and EHR developers,
which could improve the patient and provider experience?
BILLING CODE 4150-28-P
[[Page 19963]]
[GRAPHIC] [TIFF OMITTED] TP14AP26.287
[[Page 19964]]
[GRAPHIC] [TIFF OMITTED] TP14AP26.288
[[Page 19965]]
BILLING CODE 4150-28-C
7. Statutory Authorities
a. Medicare Advantage
For MA organizations, we are proposing these new requirements under
our authority in the following sections of the Act:
Section 1852(d)(1)(A) of the Act requires MA organizations
offering an MA plan to, as a condition of using a network of providers,
make covered benefits available and accessible to enrollees in a manner
that assures continuity in the provision of benefits.
Section 1852(g)(1)(A) of the Act requires an MA
organization to have a procedure for making determinations about
whether an enrollee is entitled to receive a health service, how much
the enrollee is required to pay for such service, and to provide an
enrollee with a written notice if the plan denies coverage. Section
1852(g)(1)(A) of the Act also requires that coverage determinations be
made on a timely basis.
Section 1852(h) of the Act requires that MA organizations
have procedures in place to maintain accurate and timely medical
records and other health information regarding MA enrollees and to
assure enrollees have timely access to such records and information.
Section 1856(b) of the Act authorizes the Secretary to
establish regulatory standards for MA organizations that are consistent
with and carry out Part C of the Medicare statute, including the
provisions in section 1852 of the Act.
Section 1857(e)(1) of the Act explicitly authorizes the
adoption of additional MA contract terms and conditions, including
required reporting to CMS by MA organizations, where necessary and
appropriate and not inconsistent with Part C of the Medicare statute.
One-Week Update Requirement--Section 1857(e)(1) of the Act
explicitly authorizes additional contract terms and conditions,
including required reporting to CMS by MA organizations, where
necessary and appropriate. The proposed 1-week update requirement is
necessary to ensure that the centralized registry maintains current
endpoint information that supports the statutory requirements in
sections 1852(d)(1)(A) (continuity of care), 1852(g)(1)(A) (timely
coverage determinations), and 1852(h) (timely access to health records)
of the Act. Section 1856(b) of the Act authorizes regulatory standards
that carry out Part C requirements. Timely endpoint updates are
essential to maintain the effectiveness of these statutory obligations,
as outdated endpoints immediately disrupt API functionality and
undermine patient access and care coordination.
Verification Requirement--The proposed requirement to verify every
12 months is necessary and appropriate to ensure ongoing compliance
with API endpoint reporting obligations and the underlying statutory
requirements they support, and therefore may be adopted by the
Secretary as an additional MA contract term under section 1857(e)(1) of
the Act. In addition, section 1856(b) of the Act authorizes the
Secretary to establish standards that ensure continued compliance with
statutory requirements, including verification that reported
information remains accurate to support ongoing patient access and care
coordination.
API URL Reporting--The proposed requirement for MA organizations to
report URLs for API documentation is supported by the same statutory
authorities as the 1-week update and verification requirements. Section
1857(e)(1) of the Act authorizes additional contract terms including
required reporting to CMS where necessary and appropriate to effectuate
the interoperability API requirements established under sections
1852(d)(1)(A), 1852(g)(1)(A), and 1852(h) of the Act. Section 1856(b)
of the Act supports the URL reporting proposal as a regulatory standard
necessary to ensure that technical information required for API
functionality is discoverable, supporting timely patient access to
health records, continuity of care, and coverage determinations.
Without discoverable documentation, the API endpoints themselves cannot
function effectively to serve these statutory purposes.
Patient Access API--If developers have to find payer API endpoints
individually, it could result in delays to the enrollee's ability to
access their records in a timely manner. Therefore, we propose to
collect and publish payer API endpoints under our authority under
section 1856(b) of the Act to establish standards to carry out section
1852(h), as well as our authority under section 1857(e)(1) of the Act.
Facilitating patients' access to their own health information could
allow them to identify errors or missing data, thus improving the
accuracy and timeliness of the medical records maintained by the MA
organization. In the 2024 CMS Interoperability and Prior Authorization
final rule, we stated that making these data available through the
Patient Access API is consistent with our programmatic authority to
establish standards to implement section 1852(h) of the Act and could
help patients be more informed about and active in their own care,
which could potentially lead to better health outcomes.\224\
---------------------------------------------------------------------------
\224\ See 89 FR 8784.
---------------------------------------------------------------------------
Provider Access API--Without a centralized location for providers
to find API endpoints, the increased burden may lead to delays in
receiving patient data, or providers deciding not to request patient
data at all. Therefore, we propose to collect and publish payer API
endpoints under our authority under section 1856(b) of the Act to
establish standards to carry out sections 1852(d)(1)(A) and 1852(h) of
the Act, as well as our authority under 1857(e)(1) of the Act.
Facilitating providers' access to patient data would give insight into
health history and previous care, thus creating conditions for benefits
to be accessible in a manner that assures the continuity of care. As
discussed in the 2024 CMS Interoperability and Prior Authorization
final rule, the Provider Access API would facilitate exchanges of
information about enrollees that are necessary for effective and
continuous patient care, which is consistent with the requirement at
section 1852(d)(1)(A) of the Act for continuing the provision of
benefits.\225\
---------------------------------------------------------------------------
\225\ See 89 FR 8818.
---------------------------------------------------------------------------
Payer-to-Payer API--One of the most important purposes of our payer
to payer data exchange policy is to facilitate care continuity at the
time a patient changes payers. Delays in being able to find the
previous payer's API endpoint to request patient data could diminish
those benefits. Therefore, we propose to collect and publish payer API
endpoints under our authority under section 1856(b) of the Act to
establish standards to carry out section 1852(d)(1)(A), as well as our
authority under section 1857(e)(1) of the Act. Per the 2024 CMS
Interoperability and Prior Authorization final rule, impacted payers
are required to make a ``reasonable effort to locate information about
a patient's previous payer,'' including that payer's API
endpoints.\226\ Requiring impacted payers to report their API endpoints
would ease the burden of finding other payers' endpoints, thus
potentially leading to more payer to payer data exchange as envisioned
by the CMS interoperability regulations.
---------------------------------------------------------------------------
\226\ See 89 FR 8840 and 8841.
---------------------------------------------------------------------------
Prior Authorization API--Collecting and publishing payer API
endpoints would allow developers to configure provider systems to
dynamically find and use the appropriate payer's API endpoint rather
than hard coding each payer API endpoint or requiring a provider to
find the API endpoint
[[Page 19966]]
themselves to submit a prior authorization request. Such process
barriers could result in untimely delays to patient care and negate
some of the benefits that the Prior Authorization API would provide.
Therefore, we propose to collect and publish payer API endpoints under
our authority under section 1856(b) of the Act to establish standards
to carry out section 1852(g)(1)(A), as well as our authority under
section 1857(e)(1) of the Act. Reporting API endpoints would facilitate
the required procedure for making determinations about enrollee
benefits and costs, which would lead to more timely coverage
determinations.
Provider Directory API--Collecting and publishing payer API
endpoints for Provider Directory APIs could facilitate provider and
patient access to current, accurate provider network information.
Without centralized endpoint discovery, providers and patients face
increased burden in locating and accessing provider directory
information, which could delay care coordination and patient access to
in-network providers. Therefore, we propose to collect and publish
payer API endpoints under our authority under section 1856(b) of the
Act to establish standards to carry out section 1852(d)(1)(A), as well
as our authority under section 1857(e)(1) of the Act. Facilitating
access to provider directory information supports the requirement that
MA organizations make covered benefits available and accessible in a
manner that assures continuity in the provision of benefits.
b. Medicaid
For state Medicaid FFS programs and Medicaid managed care plans, we
are proposing these new requirements under our authority in the
following sections of the Act:
Section 1902(a)(4) of the Act requires that a state
Medicaid plan provides such methods of administration as are found by
the Secretary to be necessary for the proper and efficient operation of
the state Medicaid plan, which includes ensuring that contracted
managed care plans comply with federal interoperability requirements.
Section 1902(a)(6) of the Act requires states to make
reports in a form and containing information required by the Secretary,
which can include ensuring that managed care plans under contract
provide necessary endpoint information to the state for reporting to
CMS.
Section 1902(a)(8) of the Act requires states to ensure
that Medicaid services are furnished with reasonable promptness to all
eligible individuals.
Section 1902(a)(19) of the Act requires states to ensure
that care and services are provided in a manner consistent with
simplicity of administration and the best interests of the recipients.
Section 1903(m)(2)(A)(xi) of the Act requires that
contracts with Medicaid MCOs include provisions that ensure compliance
with applicable requirements. This provides direct authority to impose
endpoint reporting requirements on managed care plans through their
contracts with states.
Section 1932(a) of the Act provides authority for states
to implement managed care arrangements and includes certain waiver
provisions. Section 1932(d)(1) of the Act establishes that managed care
entities must comply with requirements the Secretary determines
necessary to carry out the purposes of the Medicaid program
One-Week Update Requirement--Section 1902(a)(6) of the Act requires
states to make reports ``in a form and containing information required
by the Secretary,'' which includes the timing and frequency of such
reports. The proposed 1-week update requirement ensures that CMS
receives timely information necessary for proper program oversight.
Section 1902(a)(4) of the Act requires methods of administration
necessary for proper and efficient program operation. Outdated endpoint
information could undermine the efficient operation of the Medicaid
program by disrupting API functionality that supports beneficiary
access to care and data.
Verification Requirement--Section 1902(a)(6) of the Act supports
verification every 12 months as part of the reporting requirements
necessary for proper program oversight and monitoring. Section
1902(a)(4) of the Act requires ongoing administrative methods that
ensure proper program operation, which includes verifying the accuracy
of reported endpoint information that supports beneficiary services.
API URL Reporting--Section 1902(a)(6) of the Act supports the URL
reporting proposal as part of the reporting requirements necessary for
CMS to facilitate the interoperability framework established under our
Medicaid API requirements. This also directly supports requiring states
to collect and report API endpoint information from both their FFS
programs and contracted managed care plans. Section 1902(a)(4) of the
Act requires this as a method of administration necessary for proper
and efficient program operation, as centralized documentation discovery
supports efficient API implementation and reduces administrative burden
on providers and developers. Additionally, section 1902(a)(4) of the
Act requires states to ensure proper administration of their Medicaid
programs, which includes oversight of managed care plan compliance with
federal requirements, including endpoint reporting. States have
existing obligations to monitor and ensure managed care plans'
compliance with federal requirements, and endpoint reporting falls
within this oversight responsibility. Section 1902(a)(19) of the Act
supports this requirement as consistent with simplicity of
administration and beneficiary interests, as centralized URLs simplify
API integration and serve beneficiary interests in data access and care
coordination.
Patient Access API--We finalized the Patient Access API based on
our authority in sections 1902(a)(4) and (a)(19) of the Act. The
requirement to make Medicaid patients' health information available
through interoperable technology can facilitate beneficiary access to
their information in a convenient, timely, and portable way, which is
essential for these programs to be effectively and efficiently
administered in the best interests of beneficiaries. We have received
feedback from developers that when they have to find payer API
endpoints individually, it can delay beneficiaries' access to their
records. Making these API endpoints publicly accessible through a
centralized registry could further enhance beneficiary access by
enabling broader innovation in third-party apps and reducing barriers
for developers to create patient-friendly tools that help beneficiaries
interact with their health information. As explained in the 2020 CMS
Interoperability and Patient Access final rule, giving beneficiaries
access to their own health data is necessary for the proper and
efficient administration of the state plan.\227\ Therefore, we propose
to collect and publish payer API endpoints under our authority in
sections 1902(a)(4), (6), and (19) of the Act.
---------------------------------------------------------------------------
\227\ See 85 FR 25526.
---------------------------------------------------------------------------
Provider Access API--Collecting and publishing payer API endpoints
would decrease provider burden, which may facilitate a provider's
ability to request patient information. Otherwise, there could be
delays in receiving patient information or a provider may decide not to
request patient data due to that burden. Making patient health
information available to providers at the point of care can
significantly improve
[[Page 19967]]
their ability to render Medicaid services effectively, efficiently, and
appropriately. The Provider Access API policies should help states
fulfill their obligations to operate their state plans efficiently and
to ensure that Medicaid services are furnished with reasonable
promptness and in a manner consistent with the best interest of the
recipients.\228\ Therefore, we propose to collect and publish payer API
endpoints under our authority in sections 1902(a)(4), (6), and (19) of
the Act.
---------------------------------------------------------------------------
\228\ See 89 FR 8785.
---------------------------------------------------------------------------
Payer-to-Payer API--Collecting and publishing payer API endpoints
would decrease payer burden to locate payer API endpoints to make a
request for patient data. That would accelerate payers' ability to make
a timely request for patient data, at a point when delays could lead to
gaps in care. Those data can provide the information necessary to
ensure the beneficiary has timely continuity of care. Therefore, we
propose to collect and publish payer API endpoints under our authority
in sections 1902(a)(4), (6), (8), and (19) of the Act. Per the 2024 CMS
Interoperability and Prior Authorization final rule, impacted payers
are required to make a ``reasonable effort to locate information about
a patient's previous payer,'' including that payer's API
endpoints.\229\ Requiring impacted payers to report their API endpoints
would ease the burden of finding other payers' endpoints, thus
potentially leading to more payer to payer data exchange as envisioned
by the CMS interoperability regulations.
---------------------------------------------------------------------------
\229\ See 89 FR 8840 and 8841.
---------------------------------------------------------------------------
Prior Authorization API--As explained in the 2024 CMS
Interoperability and Prior Authorization final rule, the Prior
Authorization API should improve the efficiency and timeliness of the
prior authorization process for Medicaid beneficiaries, providers,
state Medicaid agencies, and Medicaid managed care plans by addressing
inefficiencies that exist today.\230\ Collecting and publishing payer
API endpoints would allow developers to configure provider systems to
dynamically find and use the appropriate payer's API endpoint rather
than hard coding each payer API endpoint, which may create maintenance
burdens and system fragility, or requiring a provider to find the API
endpoint themselves to submit a prior authorization request. Doing so
would significantly improve the efficiency and timeliness of the prior
authorization process, which would ensure that Medicaid services are
furnished with reasonable promptness to all eligible individuals.
Therefore, we propose to collect and publish payer API endpoints under
our authority in sections 1902(a)(4), (6), (8), and (19) of the Act.
---------------------------------------------------------------------------
\230\ See 89 FR 8899.
---------------------------------------------------------------------------
Provider Directory API--We propose to collect and publish Provider
Directory API endpoints under our authority in sections 1902(a)(4),
(6), and (19) of the Act. Section 1902(a)(4) of the Act requires states
to provide methods of administration necessary for the proper and
efficient operation of state Medicaid plans. Collecting and publishing
Provider Directory API endpoints constitutes such a method of
administration because it enables systematic verification of API
accessibility and compliance monitoring. Section 1902(a)(6) of the Act
requires states to make reports in a form and containing information
required by the Secretary, which includes the timing and frequency of
such reports. This authority supports the proposed requirement for
impacted payers to report Provider Directory API endpoints, update CMS
within 1 week of changes, and verify information every 12 months.
Section 1902(a)(19) of the Act requires states to provide safeguards to
ensure that care and services will be provided in a manner consistent
with simplicity of administration and the best interests of recipients.
Centralized endpoint discovery would serve the best interests of
Medicaid beneficiaries by facilitating access to accurate provider
directory information, which supports beneficiaries' ability to locate
in-network providers and make informed health care decisions.
Therefore, we propose to collect and publish Provider Directory API
endpoints under our authority in sections 1902(a)(4), (6), and (19) of
the Act.
c. CHIP
For state CHIP FFS programs and CHIP managed care entities, we are
proposing these new requirements under our authority in the following
sections of the Act:
We finalized the interoperability APIs under our general
authority in section 2101(a) of the Act, which sets forth that the
purpose of Title XXI is to provide funds to states to provide child
health assistance to uninsured, low-income children in an effective and
efficient manner that is coordinated with other sources of health
benefits coverage.
Section 2107(b)(1) of the Act requires state CHIP agencies
to collect data, maintain records, and furnish reports in order to
enable the Secretary to monitor state program administration and
compliance and to evaluate and compare the effectiveness of state plans
under this title.
One-Week Update and Verification Requirements--Section 2107(b)(1)
of the Act requires data collection and reporting to enable monitoring
and evaluation. Timely endpoint updates are necessary for CMS to
effectively monitor API implementation and ensure continued program
effectiveness. Verification every 12 months is necessary for ongoing
program monitoring and evaluation of API effectiveness.
API URL Reporting--Section 2107(b)(1) of the Act supports URL
reporting as necessary data collection and reporting to enable CMS to
monitor effective API implementation and evaluate program success.
Section 2101(a) of the Act establishes the purpose of providing child
health assistance in an effective and efficient manner, and centralized
documentation discovery supports efficient API implementation that
benefits CHIP beneficiaries by facilitating seamless data exchange and
care coordination.
Patient Access API--Requiring state CHIP FFS programs to make
beneficiaries' health information available through interoperable
technology increases patient access to their health information, which
can improve the efficacy of state CHIP FFS programs, allow for more
efficient communication and administration of services, and promote
coordination across various sources of health benefits coverage. As we
stated in the 2024 CMS Interoperability and Prior Authorization final
rule, the Patient Access API should increase patient access to their
health information, which can improve the efficacy of state CHIP FFS
programs, allow for more efficient communication and administration of
services, and promote coordination across various sources of health
benefits coverage.\231\ If developers have to find payer API endpoints
individually, it could result in delays to the beneficiaries' ability
to access their records in a timely manner. Therefore, we propose to
collect and publish payer API endpoints under our authority in section
2107(b)(1) of the Act to help state CHIP FFS programs provide coverage
to low-income children more effectively and efficiently.
---------------------------------------------------------------------------
\231\ See 89 FR 8786.
---------------------------------------------------------------------------
Provider Access API--The more information a provider has to make
informed decisions about a patient's care, the more likely it is that
patients will receive care that best meets their needs. As explained in
the 2024 CMS
[[Page 19968]]
Interoperability and Prior Authorization final rule, providers can be
more effective and efficient in their delivery of CHIP services by
having direct access to patient utilization and authorization
information.\232\ If a provider has information about a patient prior
to or at the point of care, the provider will be able to spend more
time focused on the patient, rather than on their need to collect
information. Therefore, we propose to collect and publish payer API
endpoints under our authority in section 2107(b)(1) of the Act to help
state CHIP FFS programs provide child health assistance to uninsured,
low-income children in an effective and efficient manner.
---------------------------------------------------------------------------
\232\ See 89 FR 8819.
---------------------------------------------------------------------------
Payer-to-Payer API--The Payer-to-Payer API is central to the goal
of coordination with other sources of health benefits coverage for
children in section 2101(a) of the Act. Centralizing payer API
endpoints could facilitate more efficient and accurate requests for
patient information, faster data exchange, and ultimately better care
continuity and coordination for CHIP beneficiaries as they enter or
exit CHIP coverage. Therefore, we propose to collect and publish payer
API endpoints under our authority in section 2101(a) of the Act to help
state CHIP agencies provide child health assistance to uninsured, low-
income children in an effective and efficient manner that is
coordinated with other sources of health benefits coverage. Per the
2024 CMS Interoperability and Prior Authorization final rule, impacted
payers are required to make a ``reasonable effort to locate information
about a patient's previous payer,'' including that payer's API
endpoints.\233\ Requiring impacted payers to report their API endpoints
would ease the burden of finding other payers' endpoints, thus
potentially leading to more payer to payer data exchange as envisioned
by the CMS interoperability regulations.
---------------------------------------------------------------------------
\233\ See 89 FR 8840 and 8841.
---------------------------------------------------------------------------
Prior Authorization API--The Prior Authorization API facilitates
the more efficient and effective exchange of information required to
submit a prior authorization request and receive a decision. An
improved process may reduce administrative costs for providers and
payers and improve timeliness in responding to providers and patients.
As explained in the 2024 CMS Interoperability and Prior Authorization
final rule, making this information available in a standardized way and
permitting access through an API will also serve the requirements in
section 2101(a) of the Act that state CHIP agencies ensure access to
coverage and coordinated care.\234\ Collecting and publishing payer API
endpoints would allow developers to configure provider systems to
dynamically find and use the appropriate payer's API endpoint rather
than hard coding each payer API endpoint or requiring a provider to
find the API endpoint themselves to submit a prior authorization
request. Therefore, we propose to collect and publish payer API
endpoints under our authority in section 2107(b)(1) of the Act to help
state CHIP agencies provide child health assistance to uninsured, low-
income children in an effective and efficient manner.
---------------------------------------------------------------------------
\234\ See 89 FR 8900.
---------------------------------------------------------------------------
Provider Directory API--Centralizing Provider Directory API
endpoints could facilitate more efficient access to provider network
information, supporting the coordination of care with other sources of
health benefits coverage as required under section 2101(a) of the Act.
This would help state CHIP agencies provide child health assistance in
an effective and efficient manner that is coordinated with other
coverage sources. Therefore, we propose to collect and publish payer
API endpoints under our authority in sections 2101(a) and 2107(b)(1) of
the Act.
d. Qualified Health Plan Issuers on the Federally-facilitated Exchanges
For QHP issuers on the FFEs, we finalized the API requirements
under our authority in section 1311(e)(1) of the Affordable Care Act.
Section 1311(e)(1)(A) of the Affordable Care Act requires that
Exchanges only certify plans as QHPs if they meet the requirements for
certification promulgated by the Secretary under section 1311(c)(1) of
the Affordable Care Act, while section 1311(e)(1)(B) of the Affordable
Care Act affords the Exchanges the discretion to certify QHPs if the
Exchange determines that making available such health plans through the
Exchange is in the interests of qualified individuals and qualified
employers in the state or states in which such Exchange operates.
One-Week Update and Verification Requirements--Section
1311(e)(1)(B) of the Affordable Care Act provides discretion to certify
QHPs if the Exchange determines that making such plans available is in
the interests of qualified individuals and qualified employers in the
state or states in which such Exchange operates. Maintaining current
endpoint information through timely updates would serve these interests
by ensuring reliable API access for enrollees--enabling them to access
their health data, coordinate care with providers, and facilitate
seamless data exchange between payers without delays caused by outdated
or inaccessible API endpoints. Verification every 12 months would
ensure that certified QHPs continue to serve the interests of qualified
individuals and qualified employers through reliable, accessible API
endpoints.
API URL Reporting--Section 1311(e)(1)(B) of the Affordable Care Act
provides discretion to certify QHPs if the Exchange determines that
making such plans available is in the interests of qualified
individuals and qualified employers in the state or states in which
such Exchange operates. The proposal to require URL reporting ensures
that certified QHPs maintain discoverable API documentation, serving
enrollee interests in data access and care coordination. We believe it
is in the interest of qualified individuals for health plans provide
accessible technical documentation that enables effective API
integration and operation.
Patient Access API--In the 2020 CMS Interoperability and Patient
Access final rule, we stated that generally certifying only health
plans that make enrollees' health information available to them in a
convenient, timely, and portable way is in the interests of enrollees
in the state or states in which a FFE operates (85 FR 25526). If
developers have to manually locate payer API endpoints individually, it
could introduce operational inefficiencies and development delays that
may hinder the enrollee's timely access to their records. Therefore, we
propose to collect and publish payer API endpoints under our authority
in section 1311(e)(1)(B) of the Affordable Care Act, as we believe it
is in the interest of qualified individuals and qualified employers to
collect and publish QHP issuers on the FFEs' API endpoints.
Provider Access API--In the 2024 CMS Interoperability and Prior
Authorization final rule, we stated that it is in the interest of
enrollees to generally only certify health plans that make enrollees'
health information available to their providers via the Provider Access
API (89 FR 8820). Giving providers access to their enrollees' health
information supplied by QHP issuers on the FFEs should ensure that
providers are better positioned to provide enrollees with seamless and
coordinated care and ensure that enrollees are not subject to duplicate
testing and procedures, and delays in care and diagnosis. Access to the
enrollee's more complete medical information could also maximize the
efficiency of an enrollee's office visits.
[[Page 19969]]
Without a centralized location to find payer API endpoints, the
increased burden may lead to delays in receiving enrollee information
or providers deciding not to request enrollee data at all. Therefore,
we propose to collect and publish payer API endpoints under our
authority in section 1311(e)(1)(B) of the Affordable Care Act, as we
believe it is in the interest of qualified individuals and qualified
employers to collect and publish QHP issuers on the FFEs' API
endpoints.
Payer-to-Payer API--In the 2024 CMS Interoperability and Prior
Authorization final rule, we stated that it is in the interest of
enrollees to generally only certify health plans that have a Payer-to-
Payer API in place to exchange information with other payers about new
enrollees, concurrent enrollees, and enrollees who have moved to
another payer (89 FR 8858). Having enrollee information at the
beginning of a new plan may assist the new payer in identifying
enrollees who need care management services, which could reduce the
cost of care. Delays in being able to find the previous payer's API
endpoint to request enrollee data could diminish those benefits. Per
the 2024 CMS Interoperability and Prior Authorization final rule,
impacted payers are required to make a ``reasonable effort to locate
information about a patient's previous payer,'' including that payer's
API endpoints.\235\ Requiring impacted payers to report their API
endpoints would ease the burden of finding other payers' endpoints,
thus potentially leading to more payer to payer data exchange as
envisioned by the CMS interoperability regulations. Therefore, we
propose to collect and publish payer API endpoints under our authority
in section 1311(e)(1)(B) of the Affordable Care Act, as we believe it
is in the interest of qualified individuals and qualified employers to
collect and publish QHP issuers on the FFEs' API endpoints.
---------------------------------------------------------------------------
\235\ See 89 FR 8840 and 8841.
---------------------------------------------------------------------------
Prior Authorization API--In the 2024 CMS Interoperability and Prior
Authorization final rule, we stated that it is in the interest of
enrollees for CMS to generally only certify health plans that have a
Prior Authorization API because it enables more accurate submission and
processing of prior authorization requests, which could improve the
delivery of services to enrollees (89 FR 8901). Collecting and
publishing payer API endpoints would allow developers to configure
provider systems to dynamically find and use the appropriate payer's
API endpoint rather than hard coding each payer API endpoint or
requiring a provider to find the API endpoint themselves to submit a
prior authorization request. We believe that in reducing provider
administrative burden, providers would spend less time on
administrative tasks, allowing them to spend more time on enrollee
care. Therefore, we propose to collect and publish payer API endpoints
under our authority in section 1311(e)(1)(B) of the Affordable Care
Act, as we believe it is in the interest of qualified individuals and
qualified employers to collect and publish QHP issuers on the FFEs' API
endpoints.
Provider Directory API--QHP issuers on the FFEs are not subject to
Provider Directory API requirements.
F. Updates to Patient Access, Provider Directory, Provider Access, and
Payer-to-Payer APIs; API Usage Metrics
1. Information About Prior Authorizations for Drugs in the Patient
Access, Provider Access, and Payer-to-Payer APIs
a. Background
In the 2024 CMS Interoperability and Prior Authorization final
rule, we required impacted payers to make available certain information
about prior authorizations for non-drug items and services via a
Patient Access API.\236\ We also required impacted payers to make
available similar information via Provider Access and Payer-to-Payer
APIs (89 FR 8817 and 8855). We finalized compliance dates beginning in
2027 for each of these APIs (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 individual market QHP issuers on the FFEs)
(89 FR 8784, 8817, and 8855). Specifically, impacted payers must make
all of the following information available about prior authorization
requests and decisions for non-drug items and services via the Patient
Access and Provider Access APIs:
---------------------------------------------------------------------------
\236\ See 42 CFR 422.119(b)(1)(iv)(A) for MA organizations, 42
CFR 431.60(b)(5)(i) for state Medicaid FFS programs, 42 CFR
457.730(b)(5)(i) for state CHIP FFS programs, through cross
reference to 42 CFR 431.60 in 42 CFR 438.242(b)(5) for Medicaid
managed care plans, through cross reference to 42 CFR 438.242 in 42
CFR 457.1233(d) for CHIP managed care entities, and 45 CFR
156.221(b)(1)(iv)(A) for individual market QHP issuers on the FFEs.
---------------------------------------------------------------------------
The prior authorization status.
The date the prior authorization was approved or denied.
The date or circumstance under which the prior
authorization ends.
The items and services approved.
If denied, a specific reason why the request was denied.
Related structured administrative and clinical
documentation submitted by a provider (89 FR 8784 and 8817).
Impacted payers must make the same prior authorization information
available through the Payer-to-Payer API, except they are not required
to include denied prior authorizations (or a specific reason why the
request was denied).\237\ Additionally, impacted payers must make
available via the Payer-to-Payer API both structured and unstructured
administrative and clinical documentation submitted by a provider.\238\
For each of these APIs--the Patient Access, Provider Access, and Payer-
to-Payer APIs (collectively ``Access APIs''), we required 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 (89 FR
8784, 8817, and 8855). Like the rest of the 2024 CMS Interoperability
and Prior Authorization final rule, those requirements do not apply to
any kind of drugs.
---------------------------------------------------------------------------
\237\ See 42 CFR 422.121(b)(4)(ii)(A) for MA organizations, 42
CFR 431.61(b)(4)(ii)(A) for state Medicaid FFS programs, 42 CFR
457.731(b)(4)(ii)(A) for state CHIP FFS programs, through cross
reference to 42 CFR 431.61(b)(4) in 42 CFR 438.242(b)(7) for
Medicaid managed care plans, through cross reference to 42 CFR
438.242 in 42 CFR 457.1233(d) for CHIP managed care entities, and 45
CFR 156.222(b)(4)(ii)(A) for individual market QHP issuers on the
FFEs.
\238\ See 42 CFR 422.121(b)(4)(ii) for MA organizations, 42 CFR
431.61(b)(4)(ii) for state Medicaid FFS programs, 42 CFR
457.731(b)(4)(ii) for state CHIP FFS programs, through cross
reference to 42 CFR 431.61(b)(4) in 42 CFR 438.242(b)(7) for
Medicaid managed care plans, through cross reference to 42 CFR
438.242 in 42 CFR 457.1233(d) for CHIP managed care entities, and 45
CFR 156.222(b)(4)(ii) for individual market QHP issuers on the FFEs.
---------------------------------------------------------------------------
b. Proposals
We emphasize the importance of access to prior authorization
information for drugs in section II.B. of this proposed rule. For the
reasons we explained in that section and in response to public feedback
received on the 2022 CMS Interoperability and Prior Authorization
proposed rule, we propose to add information about prior authorization
requests and decisions for all drugs to the categories of data impacted
payers are required to make available through the Access APIs. We
propose to amend the Access API
[[Page 19970]]
provisions that require impacted payers to make available information
about prior authorizations for non-drug items and services and drugs.
Consistent with our policies for non-drug items and services, the
information about prior authorizations for drugs that we are proposing
be made available via the Patient Access and Provider Access APIs is
the following:
The prior authorization status.
The date the prior authorization was approved or denied.
The date or circumstance under which the prior
authorization ends.
The drug or drugs approved (including the dosage).
If denied, a specific reason why the request was denied.
Related structured administrative and clinical
documentation submitted by a provider.
For the Payer-to-Payer API, the information about prior
authorizations for drugs we propose is the following:
The prior authorization status.
The date the prior authorization was approved.
The date or circumstance under which the prior
authorization ends.
The drug or drugs approved (including the dosage).
Related structured and unstructured administrative and
clinical documentation submitted by a provider.
In the 2024 CMS Interoperability and Prior Authorization final
rule, we excluded denied prior authorization requests for non-drug
items and services from the set of information that must be exchanged
between payers via the Payer-to-Payer API and are proposing the same
for prior authorizations for drugs (89 FR 8827). We propose to exclude
denied prior authorization requests because they generally would not
reflect ongoing treatment, as it does not demonstrate that patients
actually received items, services, or drugs. If a patient ultimately
received those items, services, or drugs despite the denied request,
that information would have to be gathered from elsewhere (such as
clinical data), regardless of whether the requesting payer receives
information about the prior authorization decision. Many commenters
cited similar justifications for excluding denied prior authorizations
in response to the 2022 CMS Interoperability and Prior Authorization
proposed rule, and we thus did not finalize a requirement to include
denied prior authorization decisions in the Payer-to-Payer API
policies. The value of including such information would likely be
outweighed by the additional burden on impacted payers to include it
and we therefore believe its exclusion remains justified. We refer
readers to the 2024 CMS Interoperability and Prior Authorization final
rule for a full discussion of our reasoning for this exclusion (89 FR
8830).
We propose an October 1, 2027 compliance date for MA organizations,
state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP
managed care entities, and QHP issuers on the FFEs to make the proposed
information about prior authorizations for drugs available via the
Access APIs. Because impacted payers are already required to make
available information about prior authorizations for non-drug items and
services beginning in 2027 (by January 1, 2027, for MA organizations
and state Medicaid and CHIP FFS programs; by the rating period
beginning on or after January 1, 2027, for Medicaid managed care plans
and CHIP managed care entities; and for plan years beginning on or
after January 1, 2027, for QHP issuers on the FFEs) (89 FR 8784, 8817,
and 8855), we believe a 9-month implementation window following that
date strikes the appropriate balance between urgency and operational
feasibility. An October 1, 2027 compliance date allows impacted payers
to build upon the infrastructure and processes established for the
January 1, 2027 deadline, while providing a defined period to extend
that infrastructure to drug prior authorization data. However, we
encourage these payers to make this information available via their
APIs as soon as possible to benefit their patients.
We propose that the requirement to make available information about
prior authorization for drugs would be subject to the same timeframes
established for making available prior authorization information for
non-drug items and services--no later than 1 business day after the
payer receives a prior authorization request--and the payer must update
that information no later than 1 business day after any status change.
This proposal not only aligns with our previously finalized policy, but
we continue to believe that 1 business day is the appropriate timeframe
for the reasons discussed in the 2024 CMS Interoperability and Prior
Authorization final rule (89 FR 8775-8776). Similarly, that 1 business
day timeframe aligns with the existing requirements to make claims and
encounter data and all data classes and data elements included in a
content standard in 45 CFR 170.213 (USCDI) available via the Access
APIs no later than 1 business day after being processed or received by
the payer.
Additionally, we propose that information about prior
authorizations for drugs be required to be available via the Access
APIs for as long as the authorization is active and at least 1 year
after the last status change. Information about denied and expired
prior authorizations for drugs would therefore be available for at
least 1 year after expiring or being denied. Consistent with the
requirements to make available information about prior authorizations
for non-drug items and services, we are not proposing 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. Furthermore, as payers' prior authorization
policies may change over time, that information has a limited lifespan
of usefulness for a patient's current care. However, our proposal would
require payers to make available information about all active
authorizations for as long as they are active, which may indicate a
relationship to ongoing care.
In summary, we request comment on our proposals in the CFR
citations listed in Table 10, and specifically on the following:
The proposal to require impacted payers to add information
about prior authorization requests and decisions for all drugs to the
categories of data they are required to make available through the
Access APIs, within the timeframes established for non-drug items and
services.
The proposed October 1, 2027 compliance dates for MA
organizations, state Medicaid and CHIP FFS programs, Medicaid managed
care plans, CHIP managed care entities, and QHP issuers on the FFEs.
2. Reporting Usage Metrics for Patient Access, Provider Access, Payer-
to-Payer, and Prior Authorization APIs
a. Background
Beginning in 2026, impacted payers are required to annually report
to CMS certain metrics about patient data requests made via the Patient
Access API. Impacted payers must annually report Patient Access API
metrics to CMS in the form of aggregated, de-identified data following
any year that the payer was subject to the requirement to make the
Patient Access API available. Specifically, by March 31, 2026, MA
organizations at the contract level, state Medicaid and CHIP FFS
programs at the state level, and Medicaid managed care plans and CHIP
managed care entities at the plan level must report the following
metrics: (1) the total number of unique patients whose data are
transferred via the
[[Page 19971]]
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.\239\ The current regulation in 45 CFR 156.221(f) provides that
individual market QHP issuers on the FFEs at the issuer level also
report these data by March 31, 2026, but CMS has specified to plans in
sub-regulatory guidance that we will collect Patient Access API usage
metrics during the QHP certification process.\240\
---------------------------------------------------------------------------
\239\ See 42 CFR 422.119(f) for MA organizations, 42 CFR
431.60(f) for state Medicaid FFS programs, 42 CFR 457.730(f) for
state CHIP FFS programs, through cross reference to 42 CFR 431.60 in
42 CFR 438.242(b)(5)(iii) for Medicaid managed care plans, through
cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP
managed care entities.
\240\ See Section 16. Interoperability. Center for Consumer
Information and Insurance Oversight. (2026, February 25). FFEs 2027
Draft Letter to Issuers in the Federally-facilitated Exchanges.
Retrieved from https://www.cms.gov/files/document/draft-2027-letter-issuers.pdf.
---------------------------------------------------------------------------
These data will help CMS better understand whether the Patient
Access API requirement is effectively and efficiently providing
patients access to their health information and whether payers are
providing that required information in a transparent and timely way.
Additionally, aggregated usage data from each impacted payer will help
us evaluate whether the Patient Access API policies are achieving the
desired goals. By gathering that information, we can provide targeted
support or guidance to impacted payers, if needed, to ensure that
patients have access to their data and can use their data consistently
across impacted payers. Multiple data transfers 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 (89 FR 8779).
The current regulation requires that impacted payers report metrics
from the previous calendar year to CMS by March 31 of each year.\241\
In the first year of the requirement, impacted payers will report
calendar year 2025 data by March 31, 2026. A MA organization, Medicaid
managed care plan, CHIP managed care entity, or individual market QHP
issuer on the FFEs that is newly offering coverage in a particular
market would naturally have no data to report in its first year of
operation and is required to report data following its first year
subject to the Patient Access API requirement (89 FR 8780). We did not
propose, and thus did not finalize, policies for impacted payers to
report usage metrics to CMS about Provider Access, Payer-to-Payer, or
Prior Authorization APIs.
---------------------------------------------------------------------------
\241\ See 42 CFR 422.119(f) for MA organizations, 42 CFR
431.60(f) for state Medicaid FFS programs, 42 CFR 457.730(f) for
state CHIP FFS programs, through cross reference to 42 CFR 431.60 in
42 CFR 438.242(b)(5)(iii) for Medicaid managed care plans, through
cross reference to 42 CFR 438.242 in 42 CFR 457.1233(d) for CHIP
managed care entities, and 45 CFR 156.221(f) for individual market
QHP issuers on the FFEs.
---------------------------------------------------------------------------
b. Proposed Changes to Patient Access API Usage Metrics for Medicaid
Managed Care Plans, CHIP Managed Care Entities, and Individual Market
QHP Issuers on the FFEs
After finalizing the Patient Access API usage metrics in the 2024
CMS Interoperability and Prior Authorization final rule, we determined
that additional proposals would be appropriate for Medicaid managed
care plans, CHIP managed care entities, and individual market QHP
issuers on the FFEs to align reporting deadlines for API usage metrics
with other reporting deadlines. Similar proposals for small group
market QHP issuers on the FF-SHOPs, with a later applicability date,
are discussed in section II.D. of this proposed rule.
Specifically, Medicaid managed care plans' and CHIP managed care
entities' program contracts do not all use the same time period, and
each state may choose different contract rating periods for each
managed care program. Medicaid managed care plans' and CHIP managed
care entities' contracts may use any 12-month period and collecting
Patient Access API usage data based on a calendar year would thus be
out of alignment with other reporting obligations in the contracts.
Because rating periods do not necessarily align with calendar years, we
now believe that the March 31 reporting deadline finalized in the 2024
CMS Interoperability and Prior Authorization final rule may not be
appropriate for all Medicaid managed care plans and CHIP managed care
entities. Therefore, to align the reporting deadlines with the contract
rating period and its requirements, we are now proposing to require
Medicaid managed care plans and CHIP managed care entities to report
Patient Access API usage metrics from each rating period to the state
no later than 90 days after the end of each rating period. For Medicaid
managed care plans, these metrics will be reported to CMS by states in
their MCPARs, which are due 180 days after the end of the rating
period. Having Medicaid managed care plans report Patient Access API
usage metrics to the state no later than 90 days after the end of each
rating period provides states with ample time to collect and process
the data for inclusion in their MCPARs. To simplify the cross-
referencing regulatory text, we also propose, in 42 CFR
438.242(b)(5)(ii)(B), to be explicit that the requirement for Medicaid
managed care plans and CHIP managed care entities is to report API
usage metrics to the state, rather than to CMS directly.
Furthermore, we propose to amend the requirements for Medicaid
managed care plans and CHIP managed care entities to clarify that they
would be required to report the Patient Access API usage metrics by
program, as well as by plan. We plan to collect metrics from Medicaid
managed care plans via the states through the MCPAR system, which is
set up to receive reports from plans by program.\242\ For consistency
with the other Medicaid and CHIP managed care reporting requirements,
we believe that it is appropriate to also collect these metrics at the
program level. Specifically, this proposal means that if a specific
managed care plan contracts with the state for multiple programs (for
example, an adult and child acute care program and an LTSS program),
each program would separately report Patient Access API usage metrics.
This is also consistent with how states must report all data in the
MCPAR, as described in 42 CFR 438.66(e). For CHIP managed care
entities, we are currently working to finalize the mechanism for states
to submit Patient Access API usage metrics to CMS. We plan to provide
future guidance for states on CHIP managed care entities reporting
requirements and processes.
---------------------------------------------------------------------------
\242\ See FAQ #3 citing the requirements in 42 CFR 438.66(e)(1).
(2024, March). Medicaid Managed Care Program Annual Report (MCPAR)
Technical Assistance Resource for States. Retrieved from https://www.medicaid.gov/sites/default/files/2024-04/mcpar-faq-march-2024v.2.pdf.
---------------------------------------------------------------------------
The certification process for new and existing QHP issuers on the
FFEs for the next plan year begins in the prior calendar year. QHP
issuers on the FFEs are required to submit to CMS their initial
application for plan certification for each plan year in June of the
previous calendar year. Because the current annual March 31 reporting
deadline finalized in 45 CFR 156.221(f) in the 2024 CMS
Interoperability and Prior Authorization final rule falls before the
annual QHP certification application deadline, we believe it would be
more appropriate to align the deadlines so that QHP issuers on the FFEs
can submit Patient Access API usage metrics as part of the annual QHP
certification process. Further, other
[[Page 19972]]
reporting requirements in 45 CFR part 156, subpart C do not generally
include specific dates by which issuers must report the required
information but rely on the annual application deadline.\243\
Therefore, we propose regulatory text to refer to the reporting
deadline for Patient Access API usage metrics in a manner similar to
the reporting deadlines for other plan data that CMS collects during
the annual QHP certification process. Specifically, we propose that
following each year it offers a QHP on a FFE, a QHP issuer on the FFEs
must report the specified metrics to CMS as aggregated, de-identified
data at the issuer level in the form and manner and within the
timeframes specified by the Secretary. That would allow flexibility for
CMS to include API usage metrics reporting within specific deadlines
set for the QHP certification process, which in practice, is generally
the final deadline for the QHP certification process that takes place
the following year.\244\ For example, QHP issuers on the FFEs would be
required to submit metrics from plan years in 2026 as part of the QHP
certification process during 2027 for plan years in 2028. In practice,
CMS has already issued sub-regulatory guidance that CMS will collect
Patient Access API usage metrics during the QHP certification
process.\245\ Amending the regulatory text to align with how 45 CFR
part 156, subpart C frames other QHP certification-related deadlines
would streamline reporting by allowing issuers to report metrics at the
same time and to the same systems as the QHP certification application.
We are proposing that these changes become effective beginning on the
effective date of the final rule.
---------------------------------------------------------------------------
\243\ For example, 45 CFR 156.220(b) provides that a QHP issuer
on the FFEs must submit transparency in coverage metrics described
in paragraph (a) of that section in an accurate and timely manner,
to be determined by HHS.
\244\ Information about QHP certification, including deadlines,
can be found at https://www.qhpcertification.cms.gov/QHP/aboutthemarketplace/Timeline.
\245\ See Section 16. Interoperability. Center for Consumer
Information and Insurance Oversight. (2026, February 25). FFEs 2027
Draft Letter to Issuers in the Federally-facilitated Exchanges.
Retrieved from https://www.cms.gov/files/document/draft-2027-letter-issuers.pdf.
---------------------------------------------------------------------------
In summary, we request comment on our proposals in the CFR
citations listed in Table 10, and specifically on the following:
The proposal for Medicaid managed care plans and CHIP
managed care entities to report Patient Access API usage metrics to the
state no later than 90 days after the end of each rating period.
The proposal for QHP issuers on the FFEs to report Patient
Access API usage metrics to CMS in the form and manner and within the
timeframes specified by the Secretary.
The proposal to require Medicaid managed care plans and
CHIP managed care entities to report certain metrics about Patient
Access API usage, as finalized in the 2024 CMS Interoperability and
Prior Authorization final rule, by program, as well as by plan.
The proposal to become effective beginning on the
effective date of the final rule.
c. Proposal to Report Metrics About the Provider Access, Payer-to-
Payer, and Prior Authorization API Usage for All Impacted Payers
We are proposing that impacted payers be required to report metrics
about usage of the Provider Access, Payer-to-Payer, and Prior
Authorization APIs, which are required under the 2024 CMS
Interoperability and Prior Authorization final rule. We propose that,
beginning in 2028, MA organizations, state Medicaid and CHIP FFS
programs, Medicaid managed care plans, CHIP managed care entities, and
QHP issuers on the FFEs would be required to annually report metrics in
the form of aggregated, de-identified data.
The reporting period for MA organizations, state Medicaid and CHIP
FFS programs, and QHP issuers on the FFEs would be the calendar year,
while the reporting period for Medicaid managed care plans and CHIP
managed care entities would be the rating period. We propose that,
beginning in 2028, MA organizations and state Medicaid and CHIP FFS
programs be required to report the previous calendar year's metrics to
CMS by March 31 of each year. We propose that by the first rating
period beginning on or after January 1, 2028, Medicaid managed care
plans and CHIP managed care entities be required to report metrics to
states from each rating period no later than 90 days after the end of
each rating period. We propose that for plan years beginning on or
after January 1, 2028, following each year it offers a QHP on a FFE,
unless granted an exception for the previous year, a QHP issuer on the
FFEs must report usage metrics to CMS in the form and manner and within
the timeframes specified by the Secretary. Impacted payers would thus
be required to begin reporting these data in 2028 for the previous
reporting period (for most impacted payers, calendar year 2027). As
discussed in section II.C.6. of this proposed rule, we use the term
``reporting period'' to describe the period from which data must be
reported in order to account for certain differences between impacted
payers.
We also propose that MA organizations, state Medicaid and CHIP FFS
programs, and QHP issuers on the FFEs would report the metrics at the
same reporting levels, that is, the organizational levels at which the
payer aggregates and submits the required data, as finalized for the
Patient Access API usage metrics. MA organizations would thus report at
the contract level, state Medicaid and CHIP FFS programs at the state
level, and QHP issuers on the FFEs at the issuer level. We also propose
that Medicaid managed care plans and CHIP managed care entities would
report metrics at the plan and program level for the reasons discussed
previously. By way of examples, reporting at the issuer level means
that a QHP issuer on the FFEs would aggregate data across the plans it
offers on a FFE, while reporting at the plan level means that a
Medicaid managed care plan would report data specific to that
individual plan. As we finalized for the Patient Access API (89 FR
8780), dual eligible special needs plans (D-SNPs) would report
consistent with MA organizations at the contract level, and with
Medicaid managed care plans at the plan level. Therefore, the MA
organization would report information about Provider Access, Payer-to-
Payer, and Prior Authorization API usage by its D-SNP enrollees to CMS
at the contract level. The affiliated Medicaid managed care plan would
report on information about Patient Access API usage by its enrollees
to CMS at the plan and program level.
In the 2024 CMS Interoperability and Prior Authorization final
rule, we explained that we believe that it is most appropriate for MA
organizations to report these usage data at the contract level (89 FR
8780). Contract level data represent aggregated information from all
PBPs that fall under a single MA contract, with reporting organized by
individual contracts rather than by individual plans. We already
require MA organizations to annually report contract level data about
their organization's determinations to CMS. Maintaining consistent
contract level reporting in the MA program would give us useful
information while limiting payer burden. By requiring contract level
reporting for these metrics, the format of these reported data would
remain consistent with other data that MA organizations are required to
report. There could be value in requiring MA organizations to report on
a plan level in the future to get more discrete data.
[[Page 19973]]
However, at this time, we continue to believe that the burden of
requiring MA organizations to report at the plan level, especially
given the small sample sizes of some plans, outweighs the benefits of
obtaining that information.
Commenters agreed with our proposals in the 2022 CMS
Interoperability and Prior Authorization proposed rule that requiring
state Medicaid and CHIP FFS programs to report at the state level,
Medicaid managed care plans and CHIP managed care entities to report at
the plan level, and individual market QHP issuers on the FFEs to report
at the issuer level balances the reporting burden and the
meaningfulness of the data (89 FR 8780). We explained in the 2024 CMS
Interoperability and Prior Authorization final rule that requiring
individual market QHP issuers on the FFEs to report at the issuer
level, thereby aggregating plans under their purview, is consistent
with their reporting on quality improvement strategies, as described in
section 1311(g) of the Affordable Care Act and codified in 45 CFR
156.1130(a), which provides consistency with other QHP reporting
requirements (89 FR 8890). Likewise, for these proposals, state
Medicaid and CHIP FFS programs would report at the state level,
Medicaid managed care plans and CHIP managed care entities at the plan
and program level, and QHP issuers on the FFEs at the issuer level. Our
proposed reporting levels and deadlines are summarized in Table 9.
As with the existing Patient Access API metrics (89 FR 8781), if we
finalize this proposal, we do not plan to publicly report these metrics
at the contract, state, plan and program, or issuer level, but may
reference or publish aggregated and de-identified data that does not
include names of specific payers or plans.
We are also not proposing a specific form or manner of reporting
these metrics at this time but would issue specific format and process
guidance for submitting these metrics, should they be finalized.
We propose that, beginning in 2028, impacted payers be required to
annually report Provider Access API usage metrics in the form of
aggregated, de-identified data. MA organizations, state Medicaid and
CHIP FFS programs, and QHP issuers on the FFEs would be required to
report these metrics directly to CMS and Medicaid managed care plans
and CHIP managed care entities would be required to report these
metrics to states.
Specifically, impacted payers would be required to report the
following metrics about their Provider Access API:
The total number of unique providers who requested patient
data via their Provider Access API.
The total number of unique patients whose data were
transferred via their Provider Access API to a provider's health IT
system (for example, an EHR or health IT system).
The total number of patient data transfers via their
Provider Access API.
In response to the 2022 CMS Interoperability and Prior
Authorization proposed rule, some commenters expressed skepticism that
providers would use the Provider Access API (89 FR 8792 through 8794).
We are proposing these metrics because we believe that they would give
us valuable insight into how frequently the Provider Access API is
being used. In addition, we believe that obtaining these metrics would
be manageable for impacted payers and thus not present a substantial
burden.
For the purposes of this proposal, payers must count each provider
who queries the Provider Access API. As we established in the 2024 CMS
Interoperability and Prior Authorization final rule, the Provider
Access API should be available to all providers, whether they are an
individual, a facility, or a group of providers who have come together
as an accountable care organization (ACO), who are appropriately
licensed, provide items and services, or drugs eligible for coverage by
the payer, and are enrolled with the payer or in the payer's provider
network. Though we do not require payers to share patient data with
out-of-network or unenrolled providers, we encourage them to do so to
the extent permitted by law if they can verify a treatment relationship
(89 FR 8790 and 8791). This proposed approach ensures payers would
comprehensively report all usage of the Provider Access API, including
out-of-network and unenrolled providers where applicable. We believe
that impacted payers would be able to obtain these metrics based on
their records of which providers have been authenticated and authorized
to receive requested patient data. We also recognize, however, that
there may be other ways for these payers to obtain these metrics, as
well as other outstanding factors that they would need to address to
obtain the metrics that we may not be considering.
We propose that, beginning in 2028, impacted payers be required to
annually report Payer-to-Payer API usage metrics in the form of
aggregated, de-identified data. MA organizations, state Medicaid and
CHIP FFS programs, and QHP issuers on the FFEs would be required to
report these metrics directly to CMS and Medicaid managed care plans
and CHIP managed care entities would be required to report these
metrics to states.
Specifically, impacted payers would be required to report all of
the following metrics about their Payer-to-Payer API:
The percent of patients who have opted in to the payer to
payer data exchange.
The total number of unique patients whose data have been
sent to other payers.
The total number of unique patients whose data have been
received from other payers.
We believe that by monitoring the patient opt in rate, we could
better understand patient receptiveness to payer to payer data
exchange, as well as how impacted payers are implementing it. For
example, this information may identify potential barriers to patient
opt in, such as unclear patient educational resources.
We propose that, beginning in 2028, impacted payers would be
required to annually report Prior Authorization API usage metrics in
the form of aggregated, de-identified data. MA organizations, state
Medicaid and CHIP FFS programs, and QHP issuers on the FFEs would be
required to report these metrics directly to CMS and Medicaid managed
care plans and CHIP managed care entities would be required to report
these metrics to states.
Specifically, impacted payers would be required to report all of
the following metrics about their Prior Authorization API:
The total number of unique providers who request a prior
authorization for items, services, or drugs through their Prior
Authorization API.
The number of unique prior authorization requests for
items, services, and drugs received through their Prior Authorization
API.