Proposed Rule2026-07205
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
Primary source
Metadata and text below are from the Federal Register, a public-domain U.S. government work. Always verify the official published version before relying on it for any legal matter.
Published
April 14, 2026
Issuing agencies
Health and Human Services DepartmentCenters for Medicare & Medicaid Services
Abstract
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.
Full Text
<html>
<head>
<title>Federal Register, Volume 91 Issue 71 (Tuesday, April 14, 2026)</title>
</head>
<body><pre>
[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 [<a href="http://www.gpo.gov">www.gpo.gov</a>]
[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 <a href="http://www.regulations.gov">http://www.regulations.gov</a>. 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:
<a href="/cdn-cgi/l/email-protection#11525c42587f6574637e6174637073787d78656851727c623f7979623f767e67"><span class="__cf_email__" data-cfemail="d7949a849eb9a3b2a5b8a7b2a5b6b5bebbbea3ae97b4baa4f9bfbfa4f9b0b8a1">[email protected]</span></a> 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: <a href="http://www.regulations.gov">http://www.regulations.gov</a>. Follow the search instructions on that website to
view public comments. CMS will not post on <a href="http://Regulations.gov">Regulations.gov</a> 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 <a href="https://www.regulations.gov/">https://www.regulations.gov/</a>.
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 <a href="https://hl7.org/fhir/us/davinci-pas/2.2.1/en/usecases.html">https://hl7.org/fhir/us/davinci-pas/2.2.1/en/usecases.html</a>.
---------------------------------------------------------------------------
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 <a href="https://www.qhpcertification.cms.gov/QHP/aboutthemarketplace/Timeline">https://www.qhpcertification.cms.gov/QHP/aboutthemarketplace/Timeline</a>.
---------------------------------------------------------------------------
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 <a href="https://www.qhpcertification.cms.gov/QHP/applicationmaterials/Interoperability">https://www.qhpcertification.cms.gov/QHP/applicationmaterials/Interoperability</a>. 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 <a href="https://www.cms.gov/priorities/key-initiatives/burden-reduction/administrative-simplification/hipaa/exceptions-process">https://www.cms.gov/priorities/key-initiatives/burden-reduction/administrative-simplification/hipaa/exceptions-process</a>.
---------------------------------------------------------------------------
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).<SUP>15 16</SUP> 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
<a href="https://www.hhs.gov/hipaa/for-professionals/faq/2069/under-hipaa-when-can-a-family-member/index.html">https://www.hhs.gov/hipaa/for-professionals/faq/2069/under-hipaa-when-can-a-family-member/index.html</a> and <a href="https://www.hhs.gov/hipaa/for-professionals/faq/personal-representatives-and-minors/index.html">https://www.hhs.gov/hipaa/for-professionals/faq/personal-representatives-and-minors/index.html</a>.
---------------------------------------------------------------------------
We also use terms such as ``payer,'' ``plan,'' and ``issuer'' in
this 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 <a href="http://HealthCare.gov">HealthCare.gov</a> (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 <a href="https://www.healthit.gov/api-education-module/story_html5.html">https://www.healthit.gov/api-education-module/story_html5.html</a>.
---------------------------------------------------------------------------
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 <a href="https://www.healthit.gov/sites/default/files/page/2021-04/What%20Is%20FHIR%20Fact%20Sheet.pdf">https://www.healthit.gov/sites/default/files/page/2021-04/What%20Is%20FHIR%20Fact%20Sheet.pdf</a>.
---------------------------------------------------------------------------
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:
<bullet> Health Level Seven (HL7[supreg]) Fast Healthcare
Interoperability Resources (FHIR[supreg]), Release 4.0.1 in 45 CFR
170.215(a)(1);
<bullet> HL7 FHIR US Core IG, Standard for Trial Use (STU) 3.1.1 in
45 CFR 170.215(b)(1)(i) (US Core IG);
<bullet> 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);
<bullet> FHIR Bulk Data Access (Flat FHIR) IG, v1.0.0: STU 1 in 45
CFR 170.215(d)(1) (Bulk Data Access IG); and
<bullet> 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 <a href="https://standards.ncpdp.org/Access-to-Standards.aspx">https://standards.ncpdp.org/Access-to-Standards.aspx</a>.
---------------------------------------------------------------------------
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
<a href="https://ncpdp.org/NCPDP/media/pdf/NCPDP_ePA_Fact_Sheet.doc">https://ncpdp.org/NCPDP/media/pdf/NCPDP_ePA_Fact_Sheet.doc</a>.
---------------------------------------------------------------------------
(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).'' <SUP>26 27</SUP> 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 <a href="https://hl7.org/fhir/us/davinci-pas/usecases.html">https://hl7.org/fhir/us/davinci-pas/usecases.html</a>.
---------------------------------------------------------------------------
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.<SUP>28 29</SUP>
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 <a href="https://standards.ncpdp.org/Standards/media/pdf/Correspondence/2022/202201NCPDP-SCRIPTNextVersionLetter.pdf">https://standards.ncpdp.org/Standards/media/pdf/Correspondence/2022/202201NCPDP-SCRIPTNextVersionLetter.pdf</a>.
\29\ NCPDP. (2023, February 13). Re: Proposed Rule CMS-4201-P.
Retrieved from <a href="https://standards.ncpdp.org/Standards/media/pdf/Correspondence/2023/20230213_To_CMS_CMS_4201_P_NPRM.pdf">https://standards.ncpdp.org/Standards/media/pdf/Correspondence/2023/20230213_To_CMS_CMS_4201_P_NPRM.pdf</a>.
---------------------------------------------------------------------------
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 <a href="https://standards.ncpdp.org/Access-to-Standards.aspx">https://standards.ncpdp.org/Access-to-Standards.aspx</a>.
---------------------------------------------------------------------------
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 <a href="https://www.japha.org/article/S1544-3191">https://www.japha.org/article/S1544-3191</a>(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:
<bullet> 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.
<bullet> 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.
<bullet> 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.
<bullet> 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:
<bullet> Through what mechanisms do payers make their NCPDP F&B
files available today?
<bullet> 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?
<bullet> 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?
<bullet> How frequently do providers use the NCPDP F&B standard as
part of their prior authorization workflow today?
<bullet> How well integrated is the NCPDP F&B standard into
providers' EHRs today?
<bullet> How accurate is the group-level information included in
the NCPDP F&B standard to specific patients?
<bullet> How could impacted payers utilize the NCPDP RTPB standard
to indicate whether a drug is covered under a medical benefit?
<bullet> Through what mechanisms do payers make information
available using the NCPDP RTPB standard today?
<bullet> How frequently do providers use tools conforming to the
NCPDP RTPB standard as part of their prior authorization workflow
today?
<bullet> 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?
<bullet> 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?
<bullet> 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?
<bullet> 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?
<bullet> 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:
<bullet> HL7 FHIR Standard in 45 CFR 170.215(a);
<bullet> US Core IG in 45 CFR 170.215(b)(1);
<bullet> SMART App Launch IG in 45 CFR 170.215(c);
<bullet> Bulk Data Access IG in 45 CFR 170.215(d); and
<bullet> 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:
<bullet> 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.
<bullet> The proposal to become effective beginning on the
effective date of the final rule.
In addition, we request comments on the following:
<bullet> 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.
<bullet> 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 <a href="http://hl7.org/fhir/us/carin-bb/ImplementationGuide/hl7.fhir.us.carin-bb">http://hl7.org/fhir/us/carin-bb/ImplementationGuide/hl7.fhir.us.carin-bb</a>.
---------------------------------------------------------------------------
[[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 <a href="http://hl7.org/fhir/us/davinci-pdex/ImplementationGuide/hl7.fhir.us.davinci-pdex">http://hl7.org/fhir/us/davinci-pdex/ImplementationGuide/hl7.fhir.us.davinci-pdex</a>.
---------------------------------------------------------------------------
(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 <a href="http://hl7.org/fhir/us/davinci-drug-formulary/ImplementationGuide/hl7.fhir.us.davinci-drug-formulary">http://hl7.org/fhir/us/davinci-drug-formulary/ImplementationGuide/hl7.fhir.us.davinci-drug-formulary</a>.
---------------------------------------------------------------------------
(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 <a href="http://hl7.org/fhir/us/davinci-pdex-plan-net/ImplementationGuide/hl7.fhir.us.davinci-pdex-plan-net">http://hl7.org/fhir/us/davinci-pdex-plan-net/ImplementationGuide/hl7.fhir.us.davinci-pdex-plan-net</a>.
---------------------------------------------------------------------------
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 <a href="http://hl7.org/fhir/uv/bulkdata/ImplementationGuide/hl7.fhir.uv.bulkdata">http://hl7.org/fhir/uv/bulkdata/ImplementationGuide/hl7.fhir.uv.bulkdata</a>.
---------------------------------------------------------------------------
(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 <a href="http://hl7.org/fhir/us/davinci-crd/ImplementationGuide/hl7.fhir.us.davinci-crd">http://hl7.org/fhir/us/davinci-crd/ImplementationGuide/hl7.fhir.us.davinci-crd</a>.
\41\ Health Level Seven International. (2026, March 27). Da
Vinci CRD IG, Version 2.2.1--STU 2.2. Retrieved from <a href="https://hl7.org/fhir/us/davinci-crd/2.2.1/en/">https://hl7.org/fhir/us/davinci-crd/2.2.1/en/</a>.
---------------------------------------------------------------------------
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 <a href="http://hl7.org/fhir/us/davinci-dtr/ImplementationGuide/hl7.fhir.us.davinci-dtr">http://hl7.org/fhir/us/davinci-dtr/ImplementationGuide/hl7.fhir.us.davinci-dtr</a>.
\43\ Health Level Seven International. (2026, March 27). Da
Vinci DTR IG, Version 2.2.0--STU 2.2. Retrieved from <a href="https://hl7.org/fhir/us/davinci-dtr/2.2.0/en/">https://hl7.org/fhir/us/davinci-dtr/2.2.0/en/</a>.
---------------------------------------------------------------------------
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 <a href="http://hl7.org/fhir/us/davinci-pas/ImplementationGuide/hl7.fhir.us.davinci-pas">http://hl7.org/fhir/us/davinci-pas/ImplementationGuide/hl7.fhir.us.davinci-pas</a>.
\45\ Health Level Seven International. (2026, March 27). Da
Vinci PAS IG, Version 2.2.1--STU 2.2. Retrieved from <a href="https://hl7.org/fhir/us/davinci-pas/2.2.1/en/">https://hl7.org/fhir/us/davinci-pas/2.2.1/en/</a>.
---------------------------------------------------------------------------
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):
<bullet> CARIN IG for Blue Button, Version 2.0.0--STU 2 in 45 CFR
170.215(k)(1)(i);
<bullet> PDex IG, Version 2.1.0--STU 2.1 in 45 CFR
170.215(k)(2)(i);
<bullet> PDex US Drug Formulary IG, Version 2.0.1--STU 2 in 45 CFR
170.215(m)(1);
<bullet> PDex Plan Net IG, Version 1.1.0--STU 1.1 US in 45 CFR
170.215(n)(1);
<bullet> CRD IG, Version 2.0.1--STU 2 in 45 CFR 170.215(j)(1);
<bullet> DTR IG, Version 2.0.1--STU 2 in 45 CFR 170.215(j)(2)(i);
and
<bullet> 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:
<bullet> CARIN IG for Blue Button in 45 CFR 170.215(k)(1);
<bullet> PDex IG in 45 CFR 170.215(k)(2);
<bullet> PDex US Drug Formulary IG in 45 CFR 170.215(m)(1);
<bullet> PDex Plan Net IG in 45 CFR 170.215(n)(1);
<bullet> CRD IG in 45 CFR 170.215(j)(1);
<bullet> DTR IG in 45 CFR 170.215(j)(2); and
<bullet> 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 <a href="http://hl7.org/fhir/us/davinci-crd/ImplementationGuide/hl7.fhir.us.davinci-crd">http://hl7.org/fhir/us/davinci-crd/ImplementationGuide/hl7.fhir.us.davinci-crd</a>.
\58\ Health Level Seven International. (n.d.). Da Vinci DTR IG.
Retrieved from <a href="http://hl7.org/fhir/us/davinci-dtr/ImplementationGuide/hl7.fhir.us.davinci-dtr">http://hl7.org/fhir/us/davinci-dtr/ImplementationGuide/hl7.fhir.us.davinci-dtr</a>.
\59\ Health Level Seven International. (n.d.). Da Vinci PAS IG.
Retrieved from <a href="http://hl7.org/fhir/us/davinci-pas/ImplementationGuide/hl7.fhir.us.davinci-pas">http://hl7.org/fhir/us/davinci-pas/ImplementationGuide/hl7.fhir.us.davinci-pas</a>.
---------------------------------------------------------------------------
In summary, we request comment on our proposals in the CFR
citations listed in Table 2, and specifically the following:
<bullet> 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.
<bullet> 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.
<bullet> 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.
<bullet> 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.
<bullet> 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.
<bullet> 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.
<bullet> 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
<a href="http://HealthIT.gov">HealthIT.gov</a> (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 <a href="http://HealthIT.gov">HealthIT.gov</a>.
Retrieved from <a href="https://inferno.healthit.gov/">https://inferno.healthit.gov/</a>.
\62\ Assistant Secretary for Technology Policy/Office of the
National Coordinator for Health IT. (n.d.). Inferno on <a href="http://HealthIT.gov">HealthIT.gov</a>
Test Kits. Retrieved from <a href="https://inferno.healthit.gov/test-kits/">https://inferno.healthit.gov/test-kits/</a>.
---------------------------------------------------------------------------
<bullet> CRD IG, Version 2.0.1--STU 2;
<bullet> DTR IG, Version 2.0.1--STU 2;
<bullet> PAS IG, Version 2.0.1--STU 2;
<bullet> CARIN IG for Blue Button, Version 2.0.0--STU 2;
<bullet> PDex IG, Version 2.0.0--STU 2;
<bullet> PDex US Drug Formulary IG, Version 2.0.1--STU 2; and
<bullet> 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 <a href="https://inferno.healthit.gov/">https://inferno.healthit.gov/</a>.
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
<a href="http://HealthIT.gov">HealthIT.gov</a>.\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 <a href="https://www.healthit.gov/isa/standards-version-advancement-process">https://www.healthit.gov/isa/standards-version-advancement-process</a>.
---------------------------------------------------------------------------
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 <a href="http://hl7.org/fhir/us/davinci-atr/ImplementationGuide/hl7.fhir.us.davinci-atr">http://hl7.org/fhir/us/davinci-atr/ImplementationGuide/hl7.fhir.us.davinci-atr</a>.
---------------------------------------------------------------------------
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 <a href="http://hl7.org/fhir/us/davinci-cdex/ImplementationGuide/hl7.fhir.us.davinci-cdex">http://hl7.org/fhir/us/davinci-cdex/ImplementationGuide/hl7.fhir.us.davinci-cdex</a>.
---------------------------------------------------------------------------
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 (UDAP<SUP>TM</SUP>), 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 <a href="https://build.fhir.org/ig/HL7/fhir-udap-security-ig/">https://build.fhir.org/ig/HL7/fhir-udap-security-ig/</a>.
---------------------------------------------------------------------------
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).<SUP>68 69</SUP> 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 <a href="https://www.udap.org/udap-user-auth-stu1.html">https://www.udap.org/udap-user-auth-stu1.html</a>.
\69\ Health Level Seven International. (n.d.). FAST Security IG.
Retrieved from <a href="https://build.fhir.org/ig/HL7/fhir-udap-security-ig/">https://build.fhir.org/ig/HL7/fhir-udap-security-ig/</a>.
---------------------------------------------------------------------------
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 <a href="https://hl7.org/fhir/us/carin-rtpbc/">https://hl7.org/fhir/us/carin-rtpbc/</a>.
---------------------------------------------------------------------------
In summary, we request comment on our recommendations, and
specifically on the following:
<bullet> 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.
<bullet> The recommendation for impacted payers to use the CDex IG
for the Prior Authorization API for exchanging attachments related to
prior authorization.
<bullet> 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.
<bullet> 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:
<bullet> 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?
<bullet> Should CMS consider recommending or requiring the FAST
Security IG ``Tiered OAuth'' in future rulemaking?
<bullet> 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?
<bullet> 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?
<bullet> 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?
<bullet> Should CMS consider recommending the RTPBC IG?
<bullet> 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?
<bullet> Is there value in providing patients with real-time
prescription drug cost and coverage information through the Patient
Access API?
<bullet> Are there potential technical or operational challenges
associated with implementing the RTPBC IG within the Patient Access
API?
<bullet> Is there enough patient demand via third-party apps to
justify the burden of implementing the RTPBC IG?
<bullet> Do any third-party apps currently include this
functionality, or would developers build it, if recommended?
<bullet> 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 Authorizatio
[…truncated; see source link]Indexed from Federal Register on April 14, 2026.
This is legal information, not legal advice. Laws vary by jurisdiction and change frequently. Always verify current law with official sources and consult a licensed attorney in your jurisdiction for advice on your specific situation.